whitequark | http://www.gazeta.ru/social/2014/07/15/6114933.shtml | 02:55 |
---|---|---|
wpwrak | whitequark: the google translation is hilarious :) "web malfunction, power surges, broken arrow." | 03:33 |
wpwrak | the list seems to include pretty much all possibilities | 03:34 |
kyak | because at the moment pretty much all of them are possible | 03:47 |
kyak | so any discussion is merely a specilation now | 03:48 |
wpwrak | hmm, seems we lost the mount point again :-( no file son downloads ... | 10:02 |
eintopf | :-( | 10:03 |
apelete | Hi larsc | 19:58 |
larsc | hi | 20:05 |
apelete | larsc: got some time ? I have a log sequence I'ml trying to make sense of | 20:06 |
larsc | make it quick ;) | 20:07 |
apelete | I wrote mmc async request pre_req() and post_req() callbacks to speed up dma transfers | 20:07 |
apelete | http://git.seketeli.net/cgit/~apelete/qi-kernel.git/commit/?h=jz4740-dma-async&id=a1f0c118680cbd74112510a898d0825a3d075ce8 | 20:08 |
apelete | but it fails: http://paste.debian.net/109993/ | 20:08 |
apelete | larsc: seems like CMD13 is timing out at the end of the boot sequence | 20:08 |
apelete | and I'm trying to figure out why | 20:09 |
apelete | error 145 is returned by get_card_status() in drivers/mmc/card/block.c:909 | 20:11 |
apelete | that is in mmc_blk_cmd_recovery(): http://lxr.free-electrons.com/source/drivers/mmc/card/block.c#L909 | 20:12 |
apelete | larsc: how is CMD13 supposed to be handled by host driver (jz4740_mmc.c) ? | 20:13 |
apelete | been reading the datasheet but didn't see anything wrong with the way it's being handled now | 20:15 |
larsc | apelete: probably unrelated, but the way you allocate and submit the descriptor is not safe | 20:15 |
larsc | you must submit the descriptor immediately after you allocated it | 20:16 |
larsc | so that should not be done in pre_request | 20:16 |
larsc | only the mapping of the dma area can be done there | 20:17 |
apelete | larsc: so only dma_map_sg() shoukd be done in pre_request ? | 20:17 |
apelete | ok | 20:17 |
apelete | that was my very first implementation, it worked but I didn't notice any speed improvement | 20:18 |
apelete | so I moved desc allocation to pre_request too, hoping it would speed things up further | 20:19 |
larsc | dmaengine_prep_slave_sg() is very light | 20:19 |
larsc | should make a difference performance wise | 20:19 |
apelete | larsc: ok, I'm going to revert back to my first try and only do dma_map_sg in pre_request | 20:20 |
apelete | larsc: thanks for your time :) | 20:21 |
pcercuei | what saves most power for an unused pin? Set as input, output with pullup low, pullup high? | 23:33 |
wpwrak | "unused" = unconnected ? i'd measure :) in general, output or pull is best. some chips also have an "unused" configuration which can be better. "input" is bad because you may pick up interferences, causing the input to switch violently and burning energy | 23:36 |
pcercuei | ok, that's good to know | 23:36 |
pcercuei | thanks | 23:36 |
pcercuei | not unconnected, just unused | 23:36 |
wpwrak | then the best configuration would depend on what it is connected to :) | 23:37 |
pcercuei | allright | 23:38 |
wpwrak | hmm, downloads.qi-hardware.com still has no files :-( | 23:52 |
wpwrak | and in found some dumb mistakes in the new anelok layout. well, so far nothing catastrophic | 23:53 |
--- Thu Jul 17 2014 | 00:00 |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!