2010-05-17 05:31 <mth> larsc: Linux 2.6.34 has been released
2010-05-17 05:54 <larsc> mth: i know ;)
2010-05-17 05:56 <mth> there is no JZ driver yet that uses DMA, correct?
2010-05-17 05:56 <larsc> nope
2010-05-17 05:56 <larsc> well
2010-05-17 05:56 <larsc> the pcm driver
2010-05-17 05:58 <mth> ah, that is in sound/ instead of driver/
2010-05-17 05:58 <mth> I didn't grep there
2010-05-17 06:10 <mth> the UDC driver seems to have a partial DMA implementation
2010-05-17 06:10 <mth> or one that wasn't updated together with dma.c
2010-05-17 06:16 <mth> dma_alloc_coherent seems to disable caching for the area allocated
2010-05-17 06:16 <mth> in the case of a frame buffer, some programs may try to read it
2010-05-17 06:16 <mth> for example to do semi-transparency effects
2010-05-17 06:16 <mth> wouldn't it be faster to flush the write cache before starting the DMA operation?
2010-05-17 06:43 <mth> larsc: it looks like the order of elements in enum jz4740_dma_width is wrong...
2010-05-17 06:44 <mth> the data sheet says: 00, 32-bit; 01, 8-bit; 10, 16-bit; 11, reserved
2010-05-17 06:46 <mth> well, I get something on the screen now, but it's not a stable image
2010-05-17 06:49 <mth> it does seem to be related to the framebuffer contents though: on the console it's mostly blank while in dmenu it's mostly blue
2010-05-17 06:54 <MisterMo> hello.. :)
2010-05-17 06:55 <MisterMo> I just found out... that the volume keys aren't working on my ben..
2010-05-17 06:55 <MisterMo> at least not when playing a file with madplay
2010-05-17 06:56 <MisterMo> and with alsamixer I can set exactly 3 levels.. and these don't attenuate the level much, even when I set master to 0
2010-05-17 06:56 <MisterMo> is this perhaps a known issue, or is it just me? ;)
2010-05-17 07:02 <larsc> MisterMo: known issue.
2010-05-17 07:03 <larsc> mth: hm. i'm wondering why my dma transfer test passed, although it uses 32bit.
2010-05-17 07:04 <mth> probably the test was executed by reading and writing 8-bit quantities instead of 32-bit
2010-05-17 07:05 <mth> the end result would be the same, but less efficient, I think
2010-05-17 07:05 <mth> the destination width does matter when transferring to the SLCD
2010-05-17 07:07 <larsc> i implemented dma for nand transfers two days ago, but throw it away again, since it was slower. but given that i used the wrong access size, i might want to try it again
2010-05-17 07:15 <larsc> and it also explains why i couldn't get 8bit pcm transfers to work.
2010-05-17 07:16 <larsc> mth: thanks
2010-05-17 07:16 <mth> I'm glad I can do something back once in a while :)
2010-05-17 07:50 <mth> hmm, the first frame DMA-ed is fine, after that the frames are squashed to slightly less than half a frame in height
2010-05-17 07:51 <mth> the squashing persists after blank ; unblank, which resets the ILI9331
2010-05-17 07:52 <mth> so it's probably a JZ or driver state that is wrong
2010-05-17 07:52 <larsc> what does your code look like?
2010-05-17 07:53 <mth> http://pastebin.com/dUhtmV8Y
2010-05-17 07:54 <mth> I set it to update at 1Hz now, so I can see what is going on
2010-05-17 07:54 <mth> at 1Hz, DMA start and complete counts are always in sync
2010-05-17 07:55 <mth> it would be safer to schedule the next refresh on the DMA complete callback instead of in the routine that initiates DMA
2010-05-17 07:55 <mth> by the way, what is the second argument passed to the callback? it's always 0 in practice, but I don't know the meaning
2010-05-17 07:55 <larsc> the result
2010-05-17 07:55 <larsc> will be < 0 in case of an error
2010-05-17 07:57 <mth> error handling for DMA is not implemented yet then? since there is no call from dma.c that passes anything other than 0
2010-05-17 07:57 <larsc> hm, yes
2010-05-17 07:58 <larsc> is src_width = 32bit correct?
2010-05-17 07:58 <mth> it's what the old SLCD driver uses
2010-05-17 07:59 <mth> and it works for the first frame
2010-05-17 08:00 <mth> hmm, if I set it to 16 bit, it still doesn't work, but the squashing is different
2010-05-17 08:01 <mth> now it transfers exactly half a frame
2010-05-17 08:01 <mth> well, not exact, but less than 1 line off
2010-05-17 08:06 <larsc> hm, the slcd fifo is 32bits wide
2010-05-17 08:07 <mth> yes, but not all bits are in use
2010-05-17 08:07 <mth> also, bit 31 determines whether the lower bits contain a command or data
2010-05-17 08:08 <mth> it seems that by writing only 16-bit units, data is automatically selected
2010-05-17 08:09 <mth> I tried freeing and reallocating the DMA channel every frame (jz4740_dma_free ; jz4740_dma_request) but that does not make a difference
2010-05-17 08:10 <mth> the old SLCD driver uses descriptors in memory instead of programming the DMA controller directly, but either approach should be possible, I think
2010-05-17 08:11 <mth> the squashing seems to be caused by pixels being lost throughout the frame
2010-05-17 08:11 <mth> I see all lines, but not all pixels from each line
2010-05-17 08:18 <larsc> like every second is missing or more like 8 there, 8 missing?
2010-05-17 08:20 <mth> something inbetween: it seems to be multiple pixels in a row that are missing, but not necessarily a power of two
2010-05-17 08:20 <mth> it's also not exactly half that is missing, it seems to be slightly less than half
2010-05-17 08:21 <mth> the shape of the left edge of the input frame is different every time
2010-05-17 08:24 <larsc> the datasheet says one has to wait for busy the busy flag to be not set before starting a dma transfer
2010-05-17 08:26 <mth> it says you only have to wait if you want to stop the transfer, although I don't exactly know what they mean by that
2010-05-17 08:27 <mth> the wait is easy to add, let me try...
2010-05-17 08:29 <larsc> "(3) Before starting DMA, Wait for MSTATE.BUSY == 0."
2010-05-17 08:29 <mth> I meant the comment at step 4
2010-05-17 08:30 <mth> anyway, adding the wait did not fix this problem
2010-05-17 08:30 <mth> I'll keep it though, since a clean implementation of blanking would abort any DMA transfer in progress
2010-05-17 08:33 <larsc> ah ok
2010-05-17 08:34 <mth> is it necessary to call jz4740_dma_disable() at the end of a completed transfer? or is that only to abort transfers?
2010-05-17 08:35 <larsc> only to abort it
2010-05-17 08:51 <mth> it seems like the old driver has a descriptor with the "next" pointing to itself
2010-05-17 08:52 <mth> wouldn't that cause it to immediately start a new transfer after the previous one has finished?
2010-05-17 08:52 <larsc> yes
2010-05-17 08:53 <mth> sounds like a waste of bandwidth
2010-05-17 09:05 <mth> weird: single single mode I do get full frames; the squashing only occurs in block mode
2010-05-17 09:07 <larsc> hm
2010-05-17 09:07 <larsc> wait. whats the depth of the fifo?
2010-05-17 09:08 <larsc> 16
2010-05-17 09:08 <larsc> hm
2010-05-17 09:09 <larsc> "Once a channel with block mode captures the bus, it will do data transfer continuously until all data
2010-05-17 09:09 <larsc> units are transferred or abnormal situation occurs.
2010-05-17 09:09 <larsc> "
2010-05-17 09:13 <mth> 16 units of 25 bits
2010-05-17 09:13 <larsc> in block mode it will likely transfer data faster then the slcd can consume it
2010-05-17 09:14 <mth> by the way, in single mode at 1 Hz everything is fine, but at 60 Hz there is still occasionally a lost pixel
2010-05-17 09:19 <mth> 10 Hz still works, 30 Hz does not
2010-05-17 09:19 <mth> in single mode, that is
2010-05-17 09:35 <mth> I think pixclk_falling_edge was set wrong, but changing it seems to have no effect
2010-05-17 09:52 <mth> changing the value of the pixel clock does seem to have an effect on how many pixels are lost
2010-05-17 09:56 <sid_on> *shame* i wrote root.ubi over u-boot - usbboot -c "boot;nprog 0  openwrt-xburst-qi_lb60-root.ubi  0 0 -n"
2010-05-17 09:57 <sid_on> how can i recover it?
2010-05-17 10:06 <mth> larsc: jzfb_set_par seems to be called twice in a row, once from within the driver and once from outside
2010-05-17 10:06 <mth> the first call is needed to set up some registers, but maybe it should be a separate routine called from both the probe and from set_par
2010-05-17 10:15 <larsc> mth: whats the problem with calling it twice?
2010-05-17 10:15 <mth> it's not a problem, but I think it's unnecessary
2010-05-17 10:15 <larsc> we could add a check if the current mode is the wanted mode
2010-05-17 10:16 <mth> I tried that, but it already said "yes" on the first call
2010-05-17 10:16 <mth> so I think the current mode would have to be initialized to NULL
2010-05-17 10:17 <larsc> yes
2010-05-17 10:18 <mth> hmm, that mode is used to initialize var
2010-05-17 10:18 <mth> so this is not a small change
2010-05-17 10:20 <larsc> well... just use pdata->modes to initalize var
2010-05-17 10:22 <wolfspraul> sid_on: can't recover. you need to write u-boot to page 0 again, to overwrite the rootfs you put there
2010-05-17 10:26 <sid_on> wolfspraul: so i have co solder the usb like in http://en.qi-hardware.com/wiki/USB_BOOT_mode ?
2010-05-17 10:29 <wolfspraul> sid_on: not solder, but yes, if you turned it off in this state, you need to short the USB boot pins with the small rubber button that's included in the box.
2010-05-17 10:31 <sid_on> wolfspraul: did not work; i also tryed bridge it with a aluminium foil; but will try it 2-4 times again
2010-05-17 10:34 <urandom_> setting it to hardware usb mode should really be made easier in the Ya
2010-05-17 10:34 <wolfspraul> sid_on: if you have the carbonized rubber button, it will work in 100% of cases once you get the hang of it. So there is no need to try aluminum or any other tricks. That will only make your life harder.
2010-05-17 10:34 <wolfspraul> urandom_: yes agreed
2010-05-17 10:35 <sid_on> urandom_: openmoko dual u-boot was/is great
2010-05-17 10:35 <wolfspraul> sid_on: try this: remove battery, unplug USB cable. push rubber button on USB boot pins, plug in USB cable
2010-05-17 10:35 <wolfspraul> normally when you plug in the USB cable, the device will boot
2010-05-17 10:36 <wolfspraul> check on the host with 'lsusb' - if you see an ID 0x601a:4740, that's your Ben
2010-05-17 10:36 <wolfspraul> sorry I have to run, bbiab...
2010-05-17 10:41 <kristoffer> sid_on, the carbonized rubber buttons work pretty well. Atleast alot better than anything else Ive tried.
2010-05-17 10:42 <sid_on> i got it now 2 times... just need to get routine - thanks!
2010-05-17 10:42 <kristoffer> goodie
2010-05-17 10:43 <urandom_> wow http://en.qi-hardware.com/wiki/Ben_NanoNote_New_User_Guide is awesome, we need more sites like this, I am thinking on translating some pages to German, someone thinks that would make sense? i mean you have to know English anyway to use the Ben, have you?
2010-05-17 10:46 <mth> larsc: for SLCD, the dot clock is determined only by how fast the receiver can handle data, not by the video mode itself, correct?
2010-05-17 10:47 <mth> the ILI9331 data sheet unfortunately says "minimum dot clock cycle:TBD"
2010-05-17 10:47 <wolfspraul> urandom_: no, this makes a lot of sense [german]
2010-05-17 10:47 <mth> but the ILI9325 data sheet states 100ns
2010-05-17 10:48 <kristoffer> urandom_, more options is always better
2010-05-17 10:48 <sid_on> urandom_: general informations yes; detailed not, it could spread informations
2010-05-17 10:48 <wolfspraul> any bit that helps lower the barriers of entry helps
2010-05-17 10:48 <wolfspraul> bbl
2010-05-17 10:48 <kristoffer> oh, 2.6.34 is out. Ive missed that
2010-05-17 10:50 <urandom_> yeah i will try to translate some pages this week, and maybe try to improve the docs in general
2010-05-17 10:51 <MisterMo> urandom_: good idea :)
2010-05-17 10:51 <mth> larsc: the LCD driver sets the LCD device clock to 3 times the pixel clock, is that because there are 3 bytes per pixel or does it have a different reason?
2010-05-17 10:55 <MisterMo> it would be really nice to see some more in-depth ressources on the web about the ben... if there are any experiences so far - but i really think there are... until now... mostly one can find "reviews"...  did anybody tried out ben's functionality as a kind of PDA? I mean... did anybody already found some nice toolset for this.. or should I just search for fitting console apps and port them?
2010-05-17 10:55 <larsc> mth: the datasheet says so
2010-05-17 10:55 <MisterMo> i just can't imagine nobody tried it out, yet ;)
2010-05-17 10:56 <MisterMo> and.. as i said... to find experiences from users on the web is quite hard atm... :(
2010-05-17 10:59 <mth> larsc: for JZ_LCD_TYPE_GENERIC_18_BIT, jzfb_num_data_pins returns 19, looks like a bug
2010-05-17 11:03 <larsc> yes
2010-05-17 12:56 <mth> larsc: because of the self-referencing descriptor, the old SLCD driver actually only does one DMA transfer
2010-05-17 12:57 <prpplague> wolfspraul: unit arrived this morning
2010-05-17 13:00 <kristianpaul> :)
2010-05-17 13:02 <prpplague> has already disassembled his NN
2010-05-17 13:04 <kristianpaul> prpplague: serial port hacking?
2010-05-17 13:04 <prpplague> kristianpaul: considering using the NN with a different motherboard
2010-05-17 13:05 <kristianpaul> prpplague: devel board?
2010-05-17 13:05 <prpplague> kristianpaul: well more of a devel platform
2010-05-17 13:06 <kristianpaul> prpplague: wich board?
2010-05-17 13:06 <prpplague> kristianpaul: it would be a custom board to fit inside the NN, but it would be most likely omap4 based
2010-05-17 13:06 <kristianpaul> ohh
2010-05-17 13:06 <mth> larsc: calling jz4740_dma_configure() only once seems to do the trick
2010-05-17 13:07 <kristianpaul> prpplague: :)
2010-05-17 13:07 <mth> I can do multiple transfers after that, but for some reason configuring more than once causes data to be lost in the transfers after that
2010-05-17 13:08 <mth> even calling jz4740_dma_configure() twice before the first transfer causes it to bug
2010-05-17 13:14 <wolfspraul> prpplague: great! I tried to email you but no reply, or maybe I used the wrong email address :-)
2010-05-17 13:14 <wolfspraul> prpplague: did you email me?
2010-05-17 13:14 <prpplague> wolfspraul: no i got your email, but have been very busy over the weekend testing some new prototype designs
2010-05-17 13:15 <prpplague> wolfspraul: i had planned on sending you some detailed info later today
2010-05-17 14:35 <prpplague> wolfspraul: i notice that my unit doesn't have the usb host or the boot switch
2010-05-17 14:35 <prpplague> wolfspraul: i assume that is documented on the wiki and i missed it
2010-05-17 14:51 <wolfspraul> prpplague: there is no USB host in the regular Ben NanoNote
2010-05-17 14:51 <prpplague> ahh ok
2010-05-17 16:30 <larsc> mth: thats rather strange. are you sure the current transfer is finished when calling jz4740_dma_configure?
2010-05-17 16:55 <mth> larsc: yes: I moved the rescheduling of the delayed work to the DMA completion callback
2010-05-17 16:55 <mth> http://github.com/mthuurne/opendingux-kernel/commit/c569e4ac39791190dc1bca61a0e94bb5935a57ea
2010-05-17 16:56 <mth> that is the version that works
2010-05-17 16:56 <mth> but moving the call to jz4740_dma_configure() into jzfb_refresh_work() breaks it
2010-05-17 16:57 <mth> even calling jz4740_dma_configure() twice in a row (nothing inbetween) triggers the problem
2010-05-17 16:57 <mth> I cannot explain it, but it is 100% reproducible
2010-05-17 16:57 <mth> maybe some kind of hardware quirk?
2010-05-17 16:57 <larsc> does something change if you do a jz474_dma_disable before calling configure?
2010-05-17 16:57 <mth> no, tried that already
2010-05-17 16:58 <mth> I put the disable call at the start of jzfb_refresh_work() because the pcm driver also does that
2010-05-17 16:58 <mth> but it didn't help
2010-05-17 17:16 <mth> larsc: it is specifically the second write to the CMD register that breaks things
2010-05-17 17:17 <mth> I added a second set of three register writes in jz4740_dma_configure() after the first set of three
2010-05-17 17:17 <mth> if I disable the second CMD write, there is no problem
2010-05-17 17:18 <mth> if I enable only the second CMD write and disable the second status and req type write, the problem comes back
2010-05-17 17:20 <larsc> hm
2010-05-17 17:24 <larsc> same result if you do the CMD writes before the other registers?
2010-05-17 17:29 <mth> the order of the writes is the key
2010-05-17 17:29 <mth> if I do every write only one time, CSR, CRS and RCS are ok, while RSC, SRC and SCR are bad
2010-05-17 17:30 <mth> so the problem occurs if S is before C
2010-05-17 17:30 <mth> (status before cmd)
2010-05-17 17:33 <larsc> still doesn't make much sense for me
2010-05-17 17:37 <larsc> does removeing ctrl |= JZ_DMA_STATUS_CTRL_HALT;
2010-05-17 17:37 <larsc> change anything?
2010-05-17 17:38 <mth> SCR order still has the problem without the HALT bit
2010-05-17 17:41 <mth> the old SLCD driver sets only the enable bit in the status reg
2010-05-17 17:41 <mth> but that driver uses descriptors
2010-05-17 17:46 <mth> if I write 0 to the status reg before the CMD write, there is no problem
2010-05-17 17:46 <larsc> hehe, just had the same idea
2010-05-17 17:46 <mth> but if I write 1 << 31 (JZ_DMA_STATUS_CTRL_NO_DESC) to the status reg before the CMD write, the problem occurs
2010-05-17 17:47 <mth> so it is related to descriptorless transfers, somehow
2010-05-17 17:52 <larsc> maybe we should only set NO_DESC when enabling the channel
2010-05-17 17:53 <mth> but is that possible, since the enable bit is in the same register?
2010-05-17 17:54 <mth> or maybe NO_DESC should only be set on enable
2010-05-17 17:59 <larsc> yes, that is what i meant
2010-05-17 18:02 <mth> it works
2010-05-17 18:03 <mth> http://pastebin.com/GmeiBWb6
2010-05-17 18:03 <mth> the removal of the enable bits from the mask has no effect, but it was easier for me to understand that way
2010-05-17 18:04 <mth> see 3rd arg of jz4740_dma_write_mask()
2010-05-17 18:05 <mth> ah, you wrote "enabling", but I read "initializing" (as in the request function)
2010-05-17 18:20 <mth> the PDF does say that the enable and the no-descriptor bit should be set in the last step, but it does not say anything about the no-descriptor bit in previous steps
2010-05-17 20:10 <urandom_> http://en.qi-hardware.com/wiki/BenOwner and http://en.qi-hardware.com/wiki/Ben_NanoNote_New_User_Guide are kind of related, should a link in the user guide be set to the BenOwner or should the useful infomations of BenOwner be merged to the user guide?
2010-05-17 21:03 <urandom_> my first edit http://en.qi-hardware.com/w/index.php?title=Ben_NanoNote_New_User_Guide&curid=1160&diff=5543&oldid=5540 , pls check if i did nothing wrong :)
2010-05-17 22:21 <kristianpaul> urandom_: all support and collaboration is wellcome :)
2010-05-17 22:28 <urandom_> well i am still not really sure about the structure of the wiki, what belongs to what page, how the style guides are and so on, so i better ask before messing everything up