2014-05-04 00:27 <qi-bot> [commit] Werner Almesberger: ircstat/ML: update for 2014-04 (master) http://qi-hw.com/p/wernermisc/3174811
2014-05-04 00:40 dos1 has quit [Ping timeout: 240 seconds]
2014-05-04 00:55 dandon has joined #qi-hardware
2014-05-04 00:59 jekhor has quit [Ping timeout: 240 seconds]
2014-05-04 01:44 atommann has joined #qi-hardware
2014-05-04 01:49 rz2k has quit []
2014-05-04 01:56 atommann has quit [Quit: Leaving]
2014-05-04 02:05 Luke-Jr has quit [Excess Flood]
2014-05-04 02:06 atommann has joined #qi-hardware
2014-05-04 02:07 Luke-Jr has joined #qi-hardware
2014-05-04 02:18 xiangfu has joined #qi-hardware
2014-05-04 03:26 jekhor has joined #qi-hardware
2014-05-04 03:27 xiangfu has quit [Ping timeout: 276 seconds]
2014-05-04 03:28 xiangfu has joined #qi-hardware
2014-05-04 03:41 michael_lee has joined #qi-hardware
2014-05-04 04:30 xiangfu has quit [Ping timeout: 276 seconds]
2014-05-04 04:31 xiangfu has joined #qi-hardware
2014-05-04 04:36 atommann has quit [Ping timeout: 245 seconds]
2014-05-04 04:45 Luke-Jr has quit [Ping timeout: 272 seconds]
2014-05-04 04:51 Luke-Jr has joined #qi-hardware
2014-05-04 06:14 atommann has joined #qi-hardware
2014-05-04 06:29 xiangfu has quit [Remote host closed the connection]
2014-05-04 06:57 michael_lee has quit [Quit: Ex-Chat]
2014-05-04 07:00 viric has quit [Ping timeout: 240 seconds]
2014-05-04 07:05 viric has joined #qi-hardware
2014-05-04 07:36 pcercuei has joined #qi-hardware
2014-05-04 07:39 <pcercuei> larsc: mth fixed the bug I told you about: https://github.com/gcwnow/linux/commit/69106c17
2014-05-04 07:44 xiangfu has joined #qi-hardware
2014-05-04 07:48 <larsc> funny
2014-05-04 07:49 <pcercuei> yes :)
2014-05-04 08:13 atommann has quit [Quit: Leaving]
2014-05-04 08:53 Ornotermes has quit [Quit: leaving]
2014-05-04 08:57 Ornotermes has joined #qi-hardware
2014-05-04 09:02 sb0 has joined #qi-hardware
2014-05-04 09:18 <whitequark> fyi: you can now get a full textual dump of qi-hw logs by doing lftp -c 'mirror http://irclog.whitequark.org/qi-hardware/index/'
2014-05-04 10:01 atommann has joined #qi-hardware
2014-05-04 10:17 <apelete> hello
2014-05-04 10:25 <apelete> larsc: found out what was wrong with my serial line on ben and fiexed it yesterday
2014-05-04 10:25 <apelete> one 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 soldering
2014-05-04 10:26 <larsc> yea, I also lost some of the pads long long time ago
2014-05-04 10:27 <apelete> larsc: so, noticed that I wasn't allocating 2 dma channels (for tx and rx) but only 1 :-/
2014-05-04 10:28 <apelete> fixed that and also wrote a filter function for dma_request_channel
2014-05-04 10:29 <larsc> you shouldn't need a filter function
2014-05-04 10:30 <apelete> problem is I'm getting weird log message:
2014-05-04 10:30 <apelete> [    2.100000] dmaengine: private_candidate: wrong capabilities
2014-05-04 10:30 <apelete> [    2.110000] dmaengine: __dma_request_channel: fail ((null))
2014-05-04 10:31 <apelete> doesn't that mean driver is getting a not capable channel ?
2014-05-04 10:31 <larsc> Just use dma_request_slave_channel()
2014-05-04 10:32 <larsc> that's the proper way to do it
2014-05-04 10:32 <larsc> the whole filter function idea is a complete abomination and should be avoided
2014-05-04 10:32 <larsc> the plan is to remove it eventually in the upstream kernel
2014-05-04 10:34 <apelete> ok, let's see how it goes with dma_request_slave_channel()
2014-05-04 11:22 Jay7 has quit [Ping timeout: 252 seconds]
2014-05-04 11:22 xiangfu has quit [Ping timeout: 240 seconds]
2014-05-04 11:25 Jay7 has joined #qi-hardware
2014-05-04 11:42 xiangfu has joined #qi-hardware
2014-05-04 12:03 <apelete> larsc: not good, dma_request_slave_channel() relies either on device-tree or acpi mechanism to get a channel
2014-05-04 12:03 <apelete> http://lxr.free-electrons.com/source/drivers/dma/dmaengine.c?v=3.12#L594
2014-05-04 12:04 <apelete> none of which is available according to gdb: http://paste.debian.net/97354/
2014-05-04 12:04 <apelete> (gdb) p dev->of_node
2014-05-04 12:04 <apelete> $2 = (struct device_node *) 0x0
2014-05-04 12:04 <apelete> (gdb) p dev->acpi_node
2014-05-04 12:04 <apelete> $4 = {<No data fields>}
2014-05-04 12:06 <apelete> larsc: I'm looking at dma_get_slave_channel(), don't know if it's the way to do it from mmc driver
2014-05-04 12:07 <apelete> http://lxr.free-electrons.com/source/drivers/dma/dmaengine.c?v=3.12#L515
2014-05-04 12:09 <larsc> hm, right
2014-05-04 12:09 <larsc> but dma_request_channel without a filter function should work
2014-05-04 12:12 jekhor has quit [Remote host closed the connection]
2014-05-04 12:21 dos1 has joined #qi-hardware
2014-05-04 12:24 xiangfu has quit [Remote host closed the connection]
2014-05-04 12:37 sb0 has quit [Quit: Leaving]
2014-05-04 12:38 <apelete> larsc: without a filter function: http://paste.debian.net/97364/
2014-05-04 12:39 <apelete> back to square one, sd init is failing and I don't know why
2014-05-04 12:41 sb0 has joined #qi-hardware
2014-05-04 12:50 jekhor has joined #qi-hardware
2014-05-04 12:51 <larsc> well at least you get something from the sd card
2014-05-04 12:51 <larsc> that's already a good thing
2014-05-04 12:53 <larsc> apelete: do you invalidate the data after the transfer
2014-05-04 13:05 <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 ?
2014-05-04 13:25 <apelete> larsc: I don't, how sould I do that ?
2014-05-04 13:27 jekhor has quit [Ping timeout: 258 seconds]
2014-05-04 13:29 <apelete> just found about cache flushing:
2014-05-04 13:29 <apelete> http://lxr.free-electrons.com/source/arch/mips/include/asm/cacheflush.h?v=3.12#L16
2014-05-04 13:30 <larsc> ysionneau: yes, that one is really good ;)
2014-05-04 13:30 * ysionneau presses the BUY button
2014-05-04 13:30 <apelete> larsc: is it better to flush entire cache with flush_cache_all() or specific pages with found flush_dcache_page()
2014-05-04 13:30 <apelete> ?
2014-05-04 13:30 <larsc> apelete: you can start with flush_cache_all
2014-05-04 13:47 <apelete> larsc: flushed before and after dma_async_issue_pending()
2014-05-04 13:47 <apelete> http://paste.debian.net/97369/
2014-05-04 13:47 <apelete> still having the same issue with sd init
2014-05-04 13:49 <nicksydney> wpwrak: 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 Taiwan
2014-05-04 13:50 <nicksydney> wpwrak: his presentation starts at 1:52:41
2014-05-04 13:52 <apelete> hmm, debugging is so much more enjoyable with a stable serial line
2014-05-04 13:52 <apelete> good joints do matter
2014-05-04 13:53 jekhor has joined #qi-hardware
2014-05-04 13:54 <larsc> apelete: you need to invalidate the cache after the transfer
2014-05-04 13:54 <larsc> for reads
2014-05-04 13:54 <larsc> for writes flush before the transfefr
2014-05-04 14:01 <apelete> larsc: like this: http://paste.debian.net/97372/ ?
2014-05-04 14:03 <larsc> flush != invalidate
2014-05-04 14:03 <larsc> flush means you write all the data that is in the cache out to the real memory
2014-05-04 14:04 <larsc> invalidate means you say that non of the data in the cache is valid and it should be re-read from real memory
2014-05-04 14:17 <apelete> larsc: documentation does not make the difference clear enough to me
2014-05-04 14:17 <apelete> the only function I found that seems to invalidate data is flush_dcache_page(), is that correct ?
2014-05-04 14:18 <apelete> http://lxr.free-electrons.com/source/arch/mips/include/asm/cacheflush.h?v=3.12#L24
2014-05-04 14:18 <ysionneau> flush will overwrite the main memory with the cache content
2014-05-04 14:19 <ysionneau> you don't want to do that I think after a from-peripheral-to-main-memory DMA transfer
2014-05-04 14:19 <ysionneau> you just want to invalidate (and not flush/write back) the cache
2014-05-04 14:19 <ysionneau> otherwise you lose the data you've just read via DMA
2014-05-04 14:20 <apelete> yes, I understand the difference, I just don't know which function to use to invalidate instead of flushing the cache
2014-05-04 14:21 <ysionneau> http://www.linux-mips.org/wiki/Caches does this help? or is it out of date?
2014-05-04 14:22 <ysionneau> ah, same issue
2014-05-04 14:22 <ysionneau> it's all "flush"
2014-05-04 14:25 <apelete> exactly, it's all flush :)
2014-05-04 14:26 <ysionneau> weird
2014-05-04 14:26 <ysionneau> there is something we don't get :)
2014-05-04 14:26 <ysionneau> it seems there are functions for dma operations
2014-05-04 14:26 <ysionneau> http://lxr.free-electrons.com/source/arch/mips/mm/cache.c?v=3.12#L58
2014-05-04 14:26 <ysionneau> dma_cache_inv
2014-05-04 14:27 <ysionneau> as well as dma_cache_wback and dma_cache_wbackinv
2014-05-04 14:29 <ysionneau> it 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_NONCOHERENT
2014-05-04 14:30 <ysionneau> http://lxr.free-electrons.com/source/arch/mips/include/asm/io.h?v=3.12#L567 <
2014-05-04 14:31 sb0 has quit [Ping timeout: 250 seconds]
2014-05-04 14:38 <apelete> nice, thnks for that
2014-05-04 14:44 sb0 has joined #qi-hardware
2014-05-04 15:02 <apelete> does this look better http://paste.debian.net/97384/ ? (it's compiling)
2014-05-04 15:03 <wpwrak> nicksydney (start at 1:52:41) you mean at the end of the video ? :)
2014-05-04 15:10 <ysionneau> apelete: is "desc" the start address of the RAM where the DMA reads/writes ?
2014-05-04 15:11 <ysionneau> or is it some "dma" structure (descriptor)
2014-05-04 15:11 <ysionneau> ?
2014-05-04 15:12 <apelete> ysionneau: it's the dma descritor indeed. should it be the start address of the ram instead ?
2014-05-04 15:12 <ysionneau> well, I think those kind of low level function which invalidate cache lines want the ram address
2014-05-04 15:13 <ysionneau> I didn't check but it feels like it :o
2014-05-04 15:13 <ysionneau> http://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 r4k
2014-05-04 15:18 <ysionneau> has anyone ever tried the "store pickup" shipping option on Seeedstudio ?
2014-05-04 15:19 <ysionneau> I wonder where are the shops addresses
2014-05-04 15:26 michael_lee has joined #qi-hardware
2014-05-04 15:29 <ysionneau> funny, you can easily find "resistor kits" or "capacitor kits" ... but no inductance kits o_o
2014-05-04 15:29 <ysionneau> ah, on ebay you can, great!
2014-05-04 15:31 <larsc> apelete: do you wait for the DMA transfer to finish?
2014-05-04 15:31 <larsc> issue_pending() starts the DMA transfer
2014-05-04 15:32 <ysionneau> ah right :)
2014-05-04 15:44 <wpwrak> ysionneau: "inductor" kits ? i have some from digi-key, so i know they exist :)
2014-05-04 15:45 <wpwrak> for 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.
2014-05-04 15:49 <apelete> larsc: ah didn't think about that, so the question is when does the transfer finish ?
2014-05-04 15:50 <apelete> from 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 ?
2014-05-04 15:57 <apelete> larsc: hmm, maybe doing the flush/invalidate operations in jz_mmc_irq_worker() according to mmc states ?
2014-05-04 15:57 <apelete> ie. flush cach before write in case JZ4740_MMC_STATE_TRANSFER_DATA
2014-05-04 15:58 <apelete> and invalidate cache after read in case JZ4740_MMC_STATE_DONE
2014-05-04 16:14 <larsc> apelete: you need to setup the 'callback' callbacl of the descriptor
2014-05-04 16:17 <apelete> larsc: what do you mean by callback, and which descriptor ? (dma descriptor I guess...)
2014-05-04 16:19 <larsc> you can assign a function to the descriptor that gets called when the descriptor has been completed
2014-05-04 16:20 <apelete> dmaengine.txt does indeed talk about descriptor callboack, but I don't see any example of how that works
2014-05-04 16:22 <larsc> http://lxr.free-electrons.com/source/drivers/mmc/host/sh_mmcif.c#L304
2014-05-04 16:25 <ysionneau> ah yes, then you can invalidate upon read is finished in the callback
2014-05-04 16:27 <larsc> usually you put the thread that waits for the data to sleep and in the callback wake it up
2014-05-04 16:30 <apelete> so the callback does not do anything special apart from calling complete() to signal completion
2014-05-04 16:30 <apelete> larsc: thanks for the tip, I'll try that
2014-05-04 16:35 atommann has quit [Quit: Leaving]
2014-05-04 16:45 <ysionneau> wpwrak: I just searched on amazon/digilentinc/seeedstudio, but indeed it's fairly easy to find on ebay for instance :)
2014-05-04 16:45 <ysionneau> thanks
2014-05-04 16:53 jekhor has quit [Ping timeout: 276 seconds]
2014-05-04 16:54 rz2k has joined #qi-hardware
2014-05-04 17:46 michael_lee has quit [Remote host closed the connection]
2014-05-04 17:48 kyak has quit [Remote host closed the connection]
2014-05-04 17:57 kyak has joined #qi-hardware
2014-05-04 17:57 kyak has joined #qi-hardware
2014-05-04 17:57 kyak has quit [Changing host]
2014-05-04 18:02 <apelete> larsc: I'm looking for physical RAM address to invalidate data cache in dma_complete() callback
2014-05-04 18:02 <apelete> is it dma_address field of struct scatterlist ?
2014-05-04 18:02 <apelete> http://lxr.free-electrons.com/source/include/asm-generic/scatterlist.h?v=3.12#L13
2014-05-04 18:03 <apelete> like ysionneau said, I think I should use ram address instead of desc in dma_cache_inv((u32) desc, sizeof(*desc));
2014-05-04 18:31 <wpwrak> ysionneau: 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/2490938
2014-05-04 19:04 jekhor has joined #qi-hardware
2014-05-04 19:13 <apelete> larsc: still the same, desc callback does not seem to be called: http://paste.debian.net/97419/
2014-05-04 19:13 <apelete> code is here, if you don't mind having a look:
2014-05-04 19:13 <apelete> http://git.seketeli.net/cgit/~apelete/qi-kernel.git/commit/?h=jz4740-dma&id=674a8eba035ab6df48d07add6875ddfa591079a1
2014-05-04 19:32 Luke-Jr has quit [Remote host closed the connection]
2014-05-04 19:36 Luke-Jr has joined #qi-hardware
2014-05-04 19:49 <ysionneau> wpwrak: thanks :)
2014-05-04 19:49 <ysionneau> wpwrak: I never bought on digi-key, dunno if they are expensive on the shipping
2014-05-04 19:49 <larsc> apelete: you need to assign slave_ids to the channels
2014-05-04 19:49 <ysionneau> let's see
2014-05-04 19:55 <apelete> larsc: slave_id...yet another thing I know nothing about, what's that ?
2014-05-04 19:55 * apelete is grepping through the code...
2014-05-04 20:16 Luke-Jr has quit [Remote host closed the connection]
2014-05-04 20:35 <apelete> I see that slave_id must be passed to dma_slave_config and should be get from device platform_data
2014-05-04 20:35 <apelete> 
2014-05-04 20:37 <apelete> larsc: how do I set slave_id in platform_data ? where does the actual id in platfrom_dat comes from ?
2014-05-04 20:38 <apelete> I see here that slave_id is set by the platform: http://lxr.free-electrons.com/source/include/linux/sh_dma.h?v=3.3#L16
2014-05-04 20:40 <apelete> I guess I need to create a slave_id field in platform_data, but I don't know what value to set in there...
2014-05-04 20:58 Luke-Jr has joined #qi-hardware
2014-05-04 21:00 Luke-Jr has quit [Read error: Connection reset by peer]
2014-05-04 21:06 Luke-Jr has joined #qi-hardware
2014-05-04 21:11 Luke-Jr has quit [Ping timeout: 252 seconds]
2014-05-04 21:19 kyak has quit [Ping timeout: 240 seconds]
2014-05-04 21:31 Luke-Jr has joined #qi-hardware
2014-05-04 21:35 Luke-Jr has quit [Excess Flood]
2014-05-04 21:36 * whitequark looks at spamassassin with disapproval
2014-05-04 21:36 <whitequark> header   FSL_CTYPE_WIN1251   Content-Type =~ /charset="Windows-1251"/
2014-05-04 21:36 <whitequark> describe FSL_CTYPE_WIN1251   Content-Type only seen in 419 spam
2014-05-04 21:36 <whitequark> Windows-1251 is cyrillic :/
2014-05-04 21:37 <wpwrak> reminds me of some mailing list once blocking *.br ;-)
2014-05-04 21:37 <whitequark> although that message took a jackpot: 43.5 points out of needed 5
2014-05-04 21:37 <whitequark> did they deliberately add funky headers?..
2014-05-04 21:38 jekhor has quit [Ping timeout: 240 seconds]
2014-05-04 21:38 <wpwrak> naw, someone just decided that all those ~200 M brazilians were spammers
2014-05-04 21:39 <whitequark> no, I mean, the one I got and SA marked with FSL_CTYPE_WIN1251
2014-05-04 21:39 <wpwrak> ah, dunno :)
2014-05-04 21:39 <whitequark> making a message look so suspicious must have taken conscious effort
2014-05-04 21:40 <whitequark> there's actually an interesting theory, that scammers deliberately write letters that look fishy as a sort of self-selection algorith
2014-05-04 21:40 <whitequark> m*
2014-05-04 21:40 Luke-Jr has joined #qi-hardware
2014-05-04 21:40 <whitequark> i.e. only gullible people will respond, or with this case, only people with no spam filter whatsoever
2014-05-04 21:41 <whitequark> it makes sense; dumb or not, they're still subject to natural selection
2014-05-04 21:41 <wpwrak> ;-)
2014-05-04 22:04 Luke-Jr has quit [Read error: Connection reset by peer]
2014-05-04 22:05 Luke-Jr has joined #qi-hardware
2014-05-04 22:17 <nicksydney> wpwrak: sorry i meant 1:18:24 :)
2014-05-04 22:18 Luke-Jr has quit [Ping timeout: 255 seconds]
2014-05-04 22:23 sb0 has quit [Quit: Leaving]
2014-05-04 22:24 kanzure has quit [Ping timeout: 245 seconds]
2014-05-04 23:39 pcercuei has quit [Quit: dodo]
2014-05-04 23:45 kanzure has joined #qi-hardware