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