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