02:55 <whitequark> http://www.gazeta.ru/social/2014/07/15/6114933.shtml

03:33 <wpwrak> whitequark: the google translation is hilarious :) "web malfunction, power surges, broken arrow."

03:34 <wpwrak> the list seems to include pretty much all possibilities

03:47 <kyak> because at the moment pretty much all of them are possible

03:48 <kyak> so any discussion is merely a specilation now

10:02 <wpwrak> hmm, seems we lost the mount point again :-( no file son downloads ...

10:03 <eintopf> :-(

19:58 <apelete> Hi larsc

20:05 <larsc> hi

20:06 <apelete> larsc: got some time ? I have a log sequence I'ml trying to make sense of

20:07 <larsc> make it quick ;)

20:07 <apelete> I wrote mmc async request pre_req() and post_req() callbacks to speed up dma transfers

20:08 <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:09 <apelete> and I'm trying to figure out why

20:11 <apelete> error 145 is returned by get_card_status() in drivers/mmc/card/block.c:909

20:12 <apelete> that is in mmc_blk_cmd_recovery(): http://lxr.free-electrons.com/source/drivers/mmc/card/block.c#L909

20:13 <apelete> larsc: how is CMD13 supposed to be handled by host driver (jz4740_mmc.c) ?

20:15 <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:16 <larsc> you must submit the descriptor immediately after you allocated it

20:16 <larsc> so that should not be done in pre_request

20:17 <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:18 <apelete> that was my very first implementation, it worked but I didn't notice any speed improvement

20:19 <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:20 <apelete> larsc: ok, I'm going to revert back to my first try and only do dma_map_sg in pre_request

20:21 <apelete> larsc: thanks for your time :)

23:33 <pcercuei> what saves most power for an unused pin? Set as input, output with pullup low, pullup high?

23:36 <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:37 <wpwrak> then the best configuration would depend on what it is connected to :)

23:38 <pcercuei> allright

23:52 <wpwrak> hmm, downloads.qi-hardware.com still has no files :-(

23:53 <wpwrak> and in found some dumb mistakes in the new anelok layout. well, so far nothing catastrophic