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