#qi-hardware IRC log for Monday, 2010-05-17

mthlarsc: Linux 2.6.34 has been released05:31
larscmth: i know ;)05:54
mththere is no JZ driver yet that uses DMA, correct?05:56
larscthe pcm driver05:56
mthah, that is in sound/ instead of driver/05:58
mthI didn't grep there05:58
mththe UDC driver seems to have a partial DMA implementation06:10
mthor one that wasn't updated together with dma.c06:10
mthdma_alloc_coherent seems to disable caching for the area allocated06:16
mthin the case of a frame buffer, some programs may try to read it06:16
mthfor example to do semi-transparency effects06:16
mthwouldn't it be faster to flush the write cache before starting the DMA operation?06:16
mthlarsc: it looks like the order of elements in enum jz4740_dma_width is wrong...06:43
mththe data sheet says: 00, 32-bit; 01, 8-bit; 10, 16-bit; 11, reserved06:44
mthwell, I get something on the screen now, but it's not a stable image06:46
mthit does seem to be related to the framebuffer contents though: on the console it's mostly blank while in dmenu it's mostly blue06:49
MisterMohello.. :)06:54
MisterMoI just found out... that the volume keys aren't working on my ben..06:55
MisterMoat least not when playing a file with madplay06:55
MisterMoand with alsamixer I can set exactly 3 levels.. and these don't attenuate the level much, even when I set master to 006:56
MisterMois this perhaps a known issue, or is it just me? ;)06:56
larscMisterMo: known issue.07:02
larscmth: hm. i'm wondering why my dma transfer test passed, although it uses 32bit.07:03
mthprobably the test was executed by reading and writing 8-bit quantities instead of 32-bit07:04
mththe end result would be the same, but less efficient, I think07:05
mththe destination width does matter when transferring to the SLCD07:05
larsci 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 again07:07
larscand it also explains why i couldn't get 8bit pcm transfers to work.07:15
larscmth: thanks07:16
mthI'm glad I can do something back once in a while :)07:16
mthhmm, the first frame DMA-ed is fine, after that the frames are squashed to slightly less than half a frame in height07:50
mththe squashing persists after blank ; unblank, which resets the ILI933107:51
mthso it's probably a JZ or driver state that is wrong07:52
larscwhat does your code look like?07:52
mthI set it to update at 1Hz now, so I can see what is going on07:54
mthat 1Hz, DMA start and complete counts are always in sync07:54
mthit would be safer to schedule the next refresh on the DMA complete callback instead of in the routine that initiates DMA07:55
mthby the way, what is the second argument passed to the callback? it's always 0 in practice, but I don't know the meaning07:55
larscthe result07:55
larscwill be < 0 in case of an error07:55
mtherror handling for DMA is not implemented yet then? since there is no call from dma.c that passes anything other than 007:57
larschm, yes07:57
larscis src_width = 32bit correct?07:58
mthit's what the old SLCD driver uses07:58
mthand it works for the first frame07:59
mthhmm, if I set it to 16 bit, it still doesn't work, but the squashing is different08:00
mthnow it transfers exactly half a frame08:01
mthwell, not exact, but less than 1 line off08:01
larschm, the slcd fifo is 32bits wide08:06
mthyes, but not all bits are in use08:07
mthalso, bit 31 determines whether the lower bits contain a command or data08:07
mthit seems that by writing only 16-bit units, data is automatically selected08:08
mthI tried freeing and reallocating the DMA channel every frame (jz4740_dma_free ; jz4740_dma_request) but that does not make a difference08:09
mththe old SLCD driver uses descriptors in memory instead of programming the DMA controller directly, but either approach should be possible, I think08:10
mththe squashing seems to be caused by pixels being lost throughout the frame08:11
mthI see all lines, but not all pixels from each line08:11
larsclike every second is missing or more like 8 there, 8 missing?08:18
mthsomething inbetween: it seems to be multiple pixels in a row that are missing, but not necessarily a power of two08:20
mthit's also not exactly half that is missing, it seems to be slightly less than half08:20
mththe shape of the left edge of the input frame is different every time08:21
larscthe datasheet says one has to wait for busy the busy flag to be not set before starting a dma transfer08:24
mthit says you only have to wait if you want to stop the transfer, although I don't exactly know what they mean by that08:26
mththe wait is easy to add, let me try...08:27
larsc"(3) Before starting DMA, Wait for MSTATE.BUSY == 0."08:29
mthI meant the comment at step 408:29
mthanyway, adding the wait did not fix this problem08:30
mthI'll keep it though, since a clean implementation of blanking would abort any DMA transfer in progress08:30
larscah ok08:33
mthis it necessary to call jz4740_dma_disable() at the end of a completed transfer? or is that only to abort transfers?08:34
larsconly to abort it08:35
mthit seems like the old driver has a descriptor with the "next" pointing to itself08:51
mthwouldn't that cause it to immediately start a new transfer after the previous one has finished?08:52
mthsounds like a waste of bandwidth08:53
mthweird: single single mode I do get full frames; the squashing only occurs in block mode09:05
larscwait. whats the depth of the fifo?09:07
larsc"Once a channel with block mode captures the bus, it will do data transfer continuously until all data09:09
larscunits are transferred or abnormal situation occurs.09:09
mth16 units of 25 bits09:13
larscin block mode it will likely transfer data faster then the slcd can consume it09:13
mthby the way, in single mode at 1 Hz everything is fine, but at 60 Hz there is still occasionally a lost pixel09:14
mth10 Hz still works, 30 Hz does not09:19
mthin single mode, that is09:19
mthI think pixclk_falling_edge was set wrong, but changing it seems to have no effect09:35
mthchanging the value of the pixel clock does seem to have an effect on how many pixels are lost09: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_onhow can i recover it?09:57
mthlarsc: jzfb_set_par seems to be called twice in a row, once from within the driver and once from outside10:06
mththe 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_par10:06
larscmth: whats the problem with calling it twice?10:15
mthit's not a problem, but I think it's unnecessary10:15
larscwe could add a check if the current mode is the wanted mode10:15
mthI tried that, but it already said "yes" on the first call10:16
mthso I think the current mode would have to be initialized to NULL10:16
mthhmm, that mode is used to initialize var10:18
mthso this is not a small change10:18
larscwell... just use pdata->modes to initalize var10:20
wolfspraulsid_on: can't recover. you need to write u-boot to page 0 again, to overwrite the rootfs you put there10:22
sid_onwolfspraul: so i have co solder the usb like in http://en.qi-hardware.com/wiki/USB_BOOT_mode ?10:26
wolfspraulsid_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_onwolfspraul: did not work; i also tryed bridge it with a aluminium foil; but will try it 2-4 times again10:31
urandom_setting it to hardware usb mode should really be made easier in the Ya10:34
wolfspraulsid_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
wolfspraulurandom_: yes agreed10:34
sid_onurandom_: openmoko dual u-boot was/is great10:35
wolfspraulsid_on: try this: remove battery, unplug USB cable. push rubber button on USB boot pins, plug in USB cable10:35
wolfspraulnormally when you plug in the USB cable, the device will boot10:35
wolfspraulcheck on the host with 'lsusb' - if you see an ID 0x601a:4740, that's your Ben10:36
wolfspraulsorry I have to run, bbiab...10:36
kristoffersid_on, the carbonized rubber buttons work pretty well. Atleast alot better than anything else Ive tried.10:41
sid_oni got it now 2 times... just need to get routine - thanks!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
mthlarsc: 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
mththe ILI9331 data sheet unfortunately says "minimum dot clock cycle:TBD"10:47
wolfspraulurandom_: no, this makes a lot of sense [german]10:47
mthbut the ILI9325 data sheet states 100ns10:47
kristofferurandom_, more options is always better10:48
sid_onurandom_: general informations yes; detailed not, it could spread informations10:48
wolfspraulany bit that helps lower the barriers of entry helps10:48
kristofferoh, 2.6.34 is out. Ive missed that10:48
urandom_yeah i will try to translate some pages this week, and maybe try to improve the docs in general10:50
MisterMourandom_: good idea :)10:51
mthlarsc: 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
MisterMoit 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
larscmth: the datasheet says so10:55
MisterMoi just can't imagine nobody tried it out, yet ;)10:55
MisterMoand.. as i said... to find experiences from users on the web is quite hard atm... :(10:56
mthlarsc: for JZ_LCD_TYPE_GENERIC_18_BIT, jzfb_num_data_pins returns 19, looks like a bug10:59
mthlarsc: because of the self-referencing descriptor, the old SLCD driver actually only does one DMA transfer12:56
prpplaguewolfspraul: unit arrived this morning12:57
Action: prpplague has already disassembled his NN13:02
kristianpaulprpplague: serial port hacking?13:04
prpplaguekristianpaul: considering using the NN with a different motherboard13:04
kristianpaulprpplague: devel board?13:05
prpplaguekristianpaul: well more of a devel platform13:05
kristianpaulprpplague: wich board?13:06
prpplaguekristianpaul: it would be a custom board to fit inside the NN, but it would be most likely omap4 based13:06
mthlarsc: calling jz4740_dma_configure() only once seems to do the trick13:06
kristianpaulprpplague: :)13:07
mthI can do multiple transfers after that, but for some reason configuring more than once causes data to be lost in the transfers after that13:07
mtheven calling jz4740_dma_configure() twice before the first transfer causes it to bug13:08
wolfspraulprpplague: great! I tried to email you but no reply, or maybe I used the wrong email address :-)13:14
wolfspraulprpplague: did you email me?13:14
prpplaguewolfspraul: no i got your email, but have been very busy over the weekend testing some new prototype designs13:14
prpplaguewolfspraul: i had planned on sending you some detailed info later today13:15
prpplaguewolfspraul: i notice that my unit doesn't have the usb host or the boot switch14:35
prpplaguewolfspraul: i assume that is documented on the wiki and i missed it14:35
wolfspraulprpplague: there is no USB host in the regular Ben NanoNote14:51
prpplagueahh ok14:51
larscmth: thats rather strange. are you sure the current transfer is finished when calling jz4740_dma_configure?16:30
mthlarsc: yes: I moved the rescheduling of the delayed work to the DMA completion callback16:55
mththat is the version that works16:56
mthbut moving the call to jz4740_dma_configure() into jzfb_refresh_work() breaks it16:56
mtheven calling jz4740_dma_configure() twice in a row (nothing inbetween) triggers the problem16:57
mthI cannot explain it, but it is 100% reproducible16:57
mthmaybe some kind of hardware quirk?16:57
larscdoes something change if you do a jz474_dma_disable before calling configure?16:57
mthno, tried that already16:57
mthI put the disable call at the start of jzfb_refresh_work() because the pcm driver also does that16:58
mthbut it didn't help16:58
mthlarsc: it is specifically the second write to the CMD register that breaks things17:16
mthI added a second set of three register writes in jz4740_dma_configure() after the first set of three17:17
mthif I disable the second CMD write, there is no problem17:17
mthif I enable only the second CMD write and disable the second status and req type write, the problem comes back17:18
larscsame result if you do the CMD writes before the other registers?17:24
mththe order of the writes is the key17:29
mthif I do every write only one time, CSR, CRS and RCS are ok, while RSC, SRC and SCR are bad17:29
mthso the problem occurs if S is before C17:30
mth(status before cmd)17:30
larscstill doesn't make much sense for me17:33
larscdoes removeing ctrl |= JZ_DMA_STATUS_CTRL_HALT;17:37
larscchange anything?17:37
mthSCR order still has the problem without the HALT bit17:38
mththe old SLCD driver sets only the enable bit in the status reg17:41
mthbut that driver uses descriptors17:41
mthif I write 0 to the status reg before the CMD write, there is no problem17:46
larschehe, just had the same idea17:46
mthbut if I write 1 << 31 (JZ_DMA_STATUS_CTRL_NO_DESC) to the status reg before the CMD write, the problem occurs17:46
mthso it is related to descriptorless transfers, somehow17:47
larscmaybe we should only set NO_DESC when enabling the channel17:52
mthbut is that possible, since the enable bit is in the same register?17:53
mthor maybe NO_DESC should only be set on enable17:54
larscyes, that is what i meant17:59
mthit works18:02
mththe removal of the enable bits from the mask has no effect, but it was easier for me to understand that way18:03
mthsee 3rd arg of jz4740_dma_write_mask()18:04
mthah, you wrote "enabling", but I read "initializing" (as in the request function)18:05
mththe 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 steps18: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
kristianpaulurandom_: 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 up22:28
--- Tue May 18 201000:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!