<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
<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
<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>
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
<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