#qi-hardware IRC log for Sunday, 2014-05-04

qi-bot[commit] Werner Almesberger: ircstat/ML: update for 2014-04 (master) http://qi-hw.com/p/wernermisc/317481100:27
pcercueilarsc: mth fixed the bug I told you about: https://github.com/gcwnow/linux/commit/69106c1707:39
pcercueiyes :)07:49
whitequarkfyi: you can now get a full textual dump of qi-hw logs by doing lftp -c 'mirror http://irclog.whitequark.org/qi-hardware/index/'09:18
apeletelarsc: found out what was wrong with my serial line on ben and fiexed it yesterday10:25
apeleteone of the joints was indeed broken: it came off with the adhesive tape I was using to keep everything in place when I removed it to inspect the soldering10:25
larscyea, I also lost some of the pads long long time ago10:26
apeletelarsc: so, noticed that I wasn't allocating 2 dma channels (for tx and rx) but only 1 :-/10:27
apeletefixed that and also wrote a filter function for dma_request_channel10:28
larscyou shouldn't need a filter function10:29
apeleteproblem is I'm getting weird log message:10:30
apelete[    2.100000] dmaengine: private_candidate: wrong capabilities10:30
apelete[    2.110000] dmaengine: __dma_request_channel: fail ((null))10:30
apeletedoesn't that mean driver is getting a not capable channel ?10:31
larscJust use dma_request_slave_channel()10:31
larscthat's the proper way to do it10:32
larscthe whole filter function idea is a complete abomination and should be avoided10:32
larscthe plan is to remove it eventually in the upstream kernel10:32
apeleteok, let's see how it goes with dma_request_slave_channel()10:34
apeletelarsc: not good, dma_request_slave_channel() relies either on device-tree or acpi mechanism to get a channel12:03
apeletenone of which is available according to gdb: http://paste.debian.net/97354/12:04
apelete(gdb) p dev->of_node12:04
apelete$2 = (struct device_node *) 0x012:04
apelete(gdb) p dev->acpi_node12:04
apelete$4 = {<No data fields>}12:04
apeletelarsc: I'm looking at dma_get_slave_channel(), don't know if it's the way to do it from mmc driver12:06
larschm, right12:09
larscbut dma_request_channel without a filter function should work12:09
apeletelarsc: without a filter function: http://paste.debian.net/97364/12:38
apeleteback to square one, sd init is failing and I don't know why12:39
larscwell at least you get something from the sd card12:51
larscthat's already a good thing12:51
larscapelete: do you invalidate the data after the transfer12:53
ysionneau(off topic) does someone know of a good "analog part kit" to begin playing a bit with a breadboard? like http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,1040,1066&Prod=APK ?13:05
apeletelarsc: I don't, how sould I do that ?13:25
apeletejust found about cache flushing:13:29
larscysionneau: yes, that one is really good ;)13:30
Action: ysionneau presses the BUY button13:30
apeletelarsc: is it better to flush entire cache with flush_cache_all() or specific pages with found flush_dcache_page()13:30
larscapelete: you can start with flush_cache_all13:30
apeletelarsc: flushed before and after dma_async_issue_pending()13:47
apeletestill having the same issue with sd init13:47
nicksydneywpwrak: saw this video https://www.youtube.com/watch?v=41kjXza2nG0 and one of the presenter his name is Tully mentioned he worked on OpenMoko in Taiwan13:49
nicksydneywpwrak: his presentation starts at 1:52:4113:50
apeletehmm, debugging is so much more enjoyable with a stable serial line13:52
apeletegood joints do matter13:52
larscapelete: you need to invalidate the cache after the transfer13:54
larscfor reads13:54
larscfor writes flush before the transfefr13:54
apeletelarsc: like this: http://paste.debian.net/97372/ ?14:01
larscflush != invalidate14:03
larscflush means you write all the data that is in the cache out to the real memory14:03
larscinvalidate means you say that non of the data in the cache is valid and it should be re-read from real memory14:04
apeletelarsc: documentation does not make the difference clear enough to me14:17
apeletethe only function I found that seems to invalidate data is flush_dcache_page(), is that correct ?14:17
ysionneauflush will overwrite the main memory with the cache content14:18
ysionneauyou don't want to do that I think after a from-peripheral-to-main-memory DMA transfer14:19
ysionneauyou just want to invalidate (and not flush/write back) the cache14:19
ysionneauotherwise you lose the data you've just read via DMA14:19
apeleteyes, I understand the difference, I just don't know which function to use to invalidate instead of flushing the cache14:20
ysionneauhttp://www.linux-mips.org/wiki/Caches does this help? or is it out of date?14:21
ysionneauah, same issue14:22
ysionneauit's all "flush"14:22
apeleteexactly, it's all flush :)14:25
ysionneauthere is something we don't get :)14:26
ysionneauit seems there are functions for dma operations14:26
ysionneauas well as dma_cache_wback and dma_cache_wbackinv14:27
ysionneauit seems that in some MIPS SoC, you don't need to take care of cache invalidation or flushing, since there is a kernel config symbol for that : CONFIG_DMA_NONCOHERENT14:29
ysionneauhttp://lxr.free-electrons.com/source/arch/mips/include/asm/io.h?v=3.12#L567 <14:30
apeletenice, thnks for that14:38
apeletedoes this look better http://paste.debian.net/97384/ ? (it's compiling)15:02
wpwraknicksydney (start at 1:52:41) you mean at the end of the video ? :)15:03
ysionneauapelete: is "desc" the start address of the RAM where the DMA reads/writes ?15:10
ysionneauor is it some "dma" structure (descriptor)15:11
apeleteysionneau: it's the dma descritor indeed. should it be the start address of the ram instead ?15:12
ysionneauwell, I think those kind of low level function which invalidate cache lines want the ram address15:12
ysionneauI didn't check but it feels like it :o15:13
ysionneauhttp://lxr.free-electrons.com/source/arch/mips/mm/c-r4k.c?v=3.12#L634 < an example of implementation of the dma_cache_inv for the MIPS r4k15:13
ysionneauhas anyone ever tried the "store pickup" shipping option on Seeedstudio ?15:18
ysionneauI wonder where are the shops addresses15:19
ysionneaufunny, you can easily find "resistor kits" or "capacitor kits" ... but no inductance kits o_o15:29
ysionneauah, on ebay you can, great!15:29
larscapelete: do you wait for the DMA transfer to finish?15:31
larscissue_pending() starts the DMA transfer15:31
ysionneauah right :)15:32
wpwrakysionneau: "inductor" kits ? i have some from digi-key, so i know they exist :)15:44
wpwrakfor resistors, i'd just get 1000 pieces of every E12 value from 10 Ohm to 1 MOhm. they're cheap and you get enough components to last you for a while, unlike the few pieces in those kits.15:45
apeletelarsc: ah didn't think about that, so the question is when does the transfer finish ?15:49
apeletefrom mmc driver point of view, where do I know that the transfer is done, since dmaengine is taking care of everything once it's started ?15:50
apeletelarsc: hmm, maybe doing the flush/invalidate operations in jz_mmc_irq_worker() according to mmc states ?15:57
apeleteie. flush cach before write in case JZ4740_MMC_STATE_TRANSFER_DATA15:57
apeleteand invalidate cache after read in case JZ4740_MMC_STATE_DONE15:58
larscapelete: you need to setup the 'callback' callbacl of the descriptor16:14
apeletelarsc: what do you mean by callback, and which descriptor ? (dma descriptor I guess...)16:17
larscyou can assign a function to the descriptor that gets called when the descriptor has been completed16:19
apeletedmaengine.txt does indeed talk about descriptor callboack, but I don't see any example of how that works16:20
ysionneauah yes, then you can invalidate upon read is finished in the callback16:25
larscusually you put the thread that waits for the data to sleep and in the callback wake it up16:27
apeleteso the callback does not do anything special apart from calling complete() to signal completion16:30
apeletelarsc: thanks for the tip, I'll try that16:30
ysionneauwpwrak: I just searched on amazon/digilentinc/seeedstudio, but indeed it's fairly easy to find on ebay for instance :)16:45
apeletelarsc: I'm looking for physical RAM address to invalidate data cache in dma_complete() callback18:02
apeleteis it dma_address field of struct scatterlist ?18:02
apeletelike ysionneau said, I think I should use ram address instead of desc in dma_cache_inv((u32) desc, sizeof(*desc));18:03
wpwrakysionneau: on digi-key, they have a product category "kits", sub-category "Inductors, Coils, Chokes Kits": http://www.digikey.com/product-search/en/kits/inductors-coils-chokes-kits/249093818:31
apeletelarsc: still the same, desc callback does not seem to be called: http://paste.debian.net/97419/19:13
apeletecode is here, if you don't mind having a look:19:13
ysionneauwpwrak: thanks :)19:49
ysionneauwpwrak: I never bought on digi-key, dunno if they are expensive on the shipping19:49
larscapelete: you need to assign slave_ids to the channels 19:49
ysionneaulet's see19:49
apeletelarsc: slave_id...yet another thing I know nothing about, what's that ?19:55
Action: apelete is grepping through the code...19:55
apeleteI see that slave_id must be passed to dma_slave_config and should be get from device platform_data20:35
apelete 20:35
apeletelarsc: how do I set slave_id in platform_data ? where does the actual id in platfrom_dat comes from ?20:37
apeleteI see here that slave_id is set by the platform: http://lxr.free-electrons.com/source/include/linux/sh_dma.h?v=3.3#L1620:38
apeleteI guess I need to create a slave_id field in platform_data, but I don't know what value to set in there...20:40
Action: whitequark looks at spamassassin with disapproval21:36
whitequarkheader   FSL_CTYPE_WIN1251   Content-Type =~ /charset="Windows-1251"/21:36
whitequarkdescribe FSL_CTYPE_WIN1251   Content-Type only seen in 419 spam21:36
whitequarkWindows-1251 is cyrillic :/21:36
wpwrakreminds me of some mailing list once blocking *.br ;-)21:37
whitequarkalthough that message took a jackpot: 43.5 points out of needed 521:37
whitequarkdid they deliberately add funky headers?..21:37
wpwraknaw, someone just decided that all those ~200 M brazilians were spammers21:38
whitequarkno, I mean, the one I got and SA marked with FSL_CTYPE_WIN125121:39
wpwrakah, dunno :)21:39
whitequarkmaking a message look so suspicious must have taken conscious effort21:39
whitequarkthere's actually an interesting theory, that scammers deliberately write letters that look fishy as a sort of self-selection algorith21:40
whitequarki.e. only gullible people will respond, or with this case, only people with no spam filter whatsoever21:40
whitequarkit makes sense; dumb or not, they're still subject to natural selection21:41
nicksydneywpwrak: sorry i meant 1:18:24 :)22:17
--- Mon May 5 201400:00

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