<mth> larsc: Linux 2.6.34 has been released
<larsc> mth: i know ;)
<mth> there is no JZ driver yet that uses DMA, correct?
<larsc> nope
<larsc> well
<larsc> the pcm driver
<mth> ah, that is in sound/ instead of driver/
<mth> I didn't grep there
<mth> the UDC driver seems to have a partial DMA implementation
<mth> or one that wasn't updated together with dma.c
<mth> dma_alloc_coherent seems to disable caching for the area allocated
<mth> in the case of a frame buffer, some programs may try to read it
<mth> for example to do semi-transparency effects
<mth> wouldn't it be faster to flush the write cache before starting the DMA operation?
<mth> larsc: it looks like the order of elements in enum jz4740_dma_width is wrong...
<mth> the data sheet says: 00, 32-bit; 01, 8-bit; 10, 16-bit; 11, reserved
<mth> well, I get something on the screen now, but it's not a stable image
<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
<MisterMo> hello.. :)
<MisterMo> I just found out... that the volume keys aren't working on my ben..
<MisterMo> at least not when playing a file with madplay
<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
<MisterMo> is this perhaps a known issue, or is it just me? ;)
<larsc> MisterMo: known issue.
<larsc> mth: hm. i'm wondering why my dma transfer test passed, although it uses 32bit.
<mth> probably the test was executed by reading and writing 8-bit quantities instead of 32-bit
<mth> the end result would be the same, but less efficient, I think
<mth> the destination width does matter when transferring to the SLCD
<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
<larsc> and it also explains why i couldn't get 8bit pcm transfers to work.
<larsc> mth: thanks
<mth> I'm glad I can do something back once in a while :)
<mth> hmm, the first frame DMA-ed is fine, after that the frames are squashed to slightly less than half a frame in height
<mth> the squashing persists after blank ; unblank, which resets the ILI9331
<mth> so it's probably a JZ or driver state that is wrong
<larsc> what does your code look like?
<mth> I set it to update at 1Hz now, so I can see what is going on
<mth> at 1Hz, DMA start and complete counts are always in sync
<mth> it would be safer to schedule the next refresh on the DMA complete callback instead of in the routine that initiates DMA
<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
<larsc> the result
<larsc> will be < 0 in case of an error
<mth> error handling for DMA is not implemented yet then? since there is no call from dma.c that passes anything other than 0
<larsc> hm, yes
<larsc> is src_width = 32bit correct?
<mth> it's what the old SLCD driver uses
<mth> and it works for the first frame
<mth> hmm, if I set it to 16 bit, it still doesn't work, but the squashing is different
<mth> now it transfers exactly half a frame
<mth> well, not exact, but less than 1 line off
<larsc> hm, the slcd fifo is 32bits wide
<mth> yes, but not all bits are in use
<mth> also, bit 31 determines whether the lower bits contain a command or data
<mth> it seems that by writing only 16-bit units, data is automatically selected
<mth> I tried freeing and reallocating the DMA channel every frame (jz4740_dma_free ; jz4740_dma_request) but that does not make a difference
<mth> the old SLCD driver uses descriptors in memory instead of programming the DMA controller directly, but either approach should be possible, I think
<mth> the squashing seems to be caused by pixels being lost throughout the frame
<mth> I see all lines, but not all pixels from each line
<larsc> like every second is missing or more like 8 there, 8 missing?
<mth> something inbetween: it seems to be multiple pixels in a row that are missing, but not necessarily a power of two
<mth> it's also not exactly half that is missing, it seems to be slightly less than half
<mth> the shape of the left edge of the input frame is different every time
<larsc> the datasheet says one has to wait for busy the busy flag to be not set before starting a dma transfer
<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
<mth> the wait is easy to add, let me try...
<larsc> "(3) Before starting DMA, Wait for MSTATE.BUSY == 0."
<mth> I meant the comment at step 4
<mth> anyway, adding the wait did not fix this problem
<mth> I'll keep it though, since a clean implementation of blanking would abort any DMA transfer in progress
<larsc> ah ok
<mth> is it necessary to call jz4740_dma_disable() at the end of a completed transfer? or is that only to abort transfers?
<larsc> only to abort it
<mth> it seems like the old driver has a descriptor with the "next" pointing to itself
<mth> wouldn't that cause it to immediately start a new transfer after the previous one has finished?
<larsc> yes
<mth> sounds like a waste of bandwidth
<mth> weird: single single mode I do get full frames; the squashing only occurs in block mode
<larsc> hm
<larsc> wait. whats the depth of the fifo?
<larsc> 16
<larsc> hm
<larsc> "Once a channel with block mode captures the bus, it will do data transfer continuously until all data
<larsc> units are transferred or abnormal situation occurs.
<larsc> "
<mth> 16 units of 25 bits
<larsc> in block mode it will likely transfer data faster then the slcd can consume it
<mth> by the way, in single mode at 1 Hz everything is fine, but at 60 Hz there is still occasionally a lost pixel
<mth> 10 Hz still works, 30 Hz does not
<mth> in single mode, that is
<mth> I think pixclk_falling_edge was set wrong, but changing it seems to have no effect
<mth> changing the value of the pixel clock does seem to have an effect on how many pixels are lost
<sid_on> *shame* i wrote root.ubi over u-boot - usbboot -c "boot;nprog 0  openwrt-xburst-qi_lb60-root.ubi  0 0 -n"
<sid_on> how can i recover it?
<mth> larsc: jzfb_set_par seems to be called twice in a row, once from within the driver and once from outside
<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
<larsc> mth: whats the problem with calling it twice?
<mth> it's not a problem, but I think it's unnecessary
<larsc> we could add a check if the current mode is the wanted mode
<mth> I tried that, but it already said "yes" on the first call
<mth> so I think the current mode would have to be initialized to NULL
<larsc> yes
<mth> hmm, that mode is used to initialize var
<mth> so this is not a small change
<larsc> well... just use pdata->modes to initalize var
<wolfspraul> sid_on: can't recover. you need to write u-boot to page 0 again, to overwrite the rootfs you put there
<sid_on> wolfspraul: so i have co solder the usb like in http://en.qi-hardware.com/wiki/USB_BOOT_mode ?
<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.
<sid_on> wolfspraul: did not work; i also tryed bridge it with a aluminium foil; but will try it 2-4 times again
<urandom_> setting it to hardware usb mode should really be made easier in the Ya
<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.
<wolfspraul> urandom_: yes agreed
<sid_on> urandom_: openmoko dual u-boot was/is great
<wolfspraul> sid_on: try this: remove battery, unplug USB cable. push rubber button on USB boot pins, plug in USB cable
<wolfspraul> normally when you plug in the USB cable, the device will boot
<wolfspraul> check on the host with 'lsusb' - if you see an ID 0x601a:4740, that's your Ben
<wolfspraul> sorry I have to run, bbiab...
<kristoffer> sid_on, the carbonized rubber buttons work pretty well. Atleast alot better than anything else Ive tried.
<sid_on> i got it now 2 times... just need to get routine - thanks!
<kristoffer> goodie
<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?
<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?
<mth> the ILI9331 data sheet unfortunately says "minimum dot clock cycle:TBD"
<wolfspraul> urandom_: no, this makes a lot of sense [german]
<mth> but the ILI9325 data sheet states 100ns
<kristoffer> urandom_, more options is always better
<sid_on> urandom_: general informations yes; detailed not, it could spread informations
<wolfspraul> any bit that helps lower the barriers of entry helps
<wolfspraul> bbl
<kristoffer> oh, 2.6.34 is out. Ive missed that
<urandom_> yeah i will try to translate some pages this week, and maybe try to improve the docs in general
<MisterMo> urandom_: good idea :)
<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?
<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?
<larsc> mth: the datasheet says so
<MisterMo> i just can't imagine nobody tried it out, yet ;)
<MisterMo> and.. as i said... to find experiences from users on the web is quite hard atm... :(
<mth> larsc: for JZ_LCD_TYPE_GENERIC_18_BIT, jzfb_num_data_pins returns 19, looks like a bug
<larsc> yes
<mth> larsc: because of the self-referencing descriptor, the old SLCD driver actually only does one DMA transfer
<prpplague> wolfspraul: unit arrived this morning
<kristianpaul> :)
<prpplague> has already disassembled his NN
<kristianpaul> prpplague: serial port hacking?
<prpplague> kristianpaul: considering using the NN with a different motherboard
<kristianpaul> prpplague: devel board?
<prpplague> kristianpaul: well more of a devel platform
<kristianpaul> prpplague: wich board?
<prpplague> kristianpaul: it would be a custom board to fit inside the NN, but it would be most likely omap4 based
<kristianpaul> ohh
<mth> larsc: calling jz4740_dma_configure() only once seems to do the trick
<kristianpaul> prpplague: :)
<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
<mth> even calling jz4740_dma_configure() twice before the first transfer causes it to bug
<wolfspraul> prpplague: great! I tried to email you but no reply, or maybe I used the wrong email address :-)
<wolfspraul> prpplague: did you email me?
<prpplague> wolfspraul: no i got your email, but have been very busy over the weekend testing some new prototype designs
<prpplague> wolfspraul: i had planned on sending you some detailed info later today
<prpplague> wolfspraul: i notice that my unit doesn't have the usb host or the boot switch
<prpplague> wolfspraul: i assume that is documented on the wiki and i missed it
<wolfspraul> prpplague: there is no USB host in the regular Ben NanoNote
<prpplague> ahh ok
<larsc> mth: thats rather strange. are you sure the current transfer is finished when calling jz4740_dma_configure?
<mth> larsc: yes: I moved the rescheduling of the delayed work to the DMA completion callback
<mth> that is the version that works
<mth> but moving the call to jz4740_dma_configure() into jzfb_refresh_work() breaks it
<mth> even calling jz4740_dma_configure() twice in a row (nothing inbetween) triggers the problem
<mth> I cannot explain it, but it is 100% reproducible
<mth> maybe some kind of hardware quirk?
<larsc> does something change if you do a jz474_dma_disable before calling configure?
<mth> no, tried that already
<mth> I put the disable call at the start of jzfb_refresh_work() because the pcm driver also does that
<mth> but it didn't help
<mth> larsc: it is specifically the second write to the CMD register that breaks things
<mth> I added a second set of three register writes in jz4740_dma_configure() after the first set of three
<mth> if I disable the second CMD write, there is no problem
<mth> if I enable only the second CMD write and disable the second status and req type write, the problem comes back
<larsc> hm
<larsc> same result if you do the CMD writes before the other registers?
<mth> the order of the writes is the key
<mth> if I do every write only one time, CSR, CRS and RCS are ok, while RSC, SRC and SCR are bad
<mth> so the problem occurs if S is before C
<mth> (status before cmd)
<larsc> still doesn't make much sense for me
<larsc> does removeing ctrl |= JZ_DMA_STATUS_CTRL_HALT;
<larsc> change anything?
<mth> SCR order still has the problem without the HALT bit
<mth> the old SLCD driver sets only the enable bit in the status reg
<mth> but that driver uses descriptors
<mth> if I write 0 to the status reg before the CMD write, there is no problem
<larsc> hehe, just had the same idea
<mth> but if I write 1 << 31 (JZ_DMA_STATUS_CTRL_NO_DESC) to the status reg before the CMD write, the problem occurs
<mth> so it is related to descriptorless transfers, somehow
<larsc> maybe we should only set NO_DESC when enabling the channel
<mth> but is that possible, since the enable bit is in the same register?
<mth> or maybe NO_DESC should only be set on enable
<larsc> yes, that is what i meant
<mth> it works
<mth> the removal of the enable bits from the mask has no effect, but it was easier for me to understand that way
<mth> see 3rd arg of jz4740_dma_write_mask()
<mth> ah, you wrote "enabling", but I read "initializing" (as in the request function)
<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
<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?
<kristianpaul> urandom_: all support and collaboration is wellcome :)
<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