Thursday, 2023-06-22

*** tpb <[email protected]> has joined #litex00:00
*** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)00:48
*** TMM_ <[email protected]> has joined #litex00:48
*** Flea86 <Flea86!~maomao@user/Flea86> has quit IRC (Read error: Connection reset by peer)01:00
*** Flea86 <Flea86!~maomao@user/Flea86> has joined #litex01:01
*** pbsds <[email protected]> has quit IRC (Quit: The Lounge - https://thelounge.chat)02:59
*** pbsds <[email protected]> has joined #litex02:59
*** Degi <[email protected]> has quit IRC (Ping timeout: 240 seconds)03:39
*** Degi <[email protected]> has joined #litex03:40
*** so-offish <so-offish!~so-offish@2610:148:610:2b11::a> has quit IRC (Ping timeout: 260 seconds)06:14
*** FabM <[email protected]> has joined #litex06:27
geertusomlo: nsectors?06:40
*** Foxyloxy <Foxyloxy!~foxyloxy@cpc151593-shef16-2-0-cust343.17-1.cable.virginm.net> has quit IRC (Ping timeout: 258 seconds)07:32
somlogeertu: thanks! I was about to give up and go with sector_count (underscore proliferation be damned :) but I'm seriously warming up to nsectors...12:08
geertusomlo: There are almost as many users of nsectors as sector_count in the Linux kernel sources12:10
somlogeertu: I should have thought of grep-ing through the Linux kernel sources :)13:08
somlogeertu: on a somewhat related topic: now that I have multi-sector DMA working in "bare metal" mode, I'm getting weird lock-ups when trying to umount an ext4 partition in linux with the litesata driver, and I'm wondering: the `submit_bio` method of a `block_device_operations` -- do I need to worry about multiple invocations of it interleaving (i.e., adding locking so that only one DMA transfer can take place, atomically, at any given time)?13:11
somloIt feels like that's the most likely reason things get messed up (given how the bare-metal "single-thread" tests seem solid)13:11
geertusomlo: Documentation/filesystems/locking.rst does not seem to document all block_device_operations methods13:34
somloI'll run some tests, try to "catch" it in the act if multiple requests are interleaved 13:35
somloof course I may still have a bug in the gateware -- guess I need to keep testing a bit longer13:36
geertusomlo: ps3vram_submit_bio() suggests it can be called while a bio is in progress13:38
geertusomlo: BTW, why is litesata a block device driver, and not an ata driver?13:44
geertuI know ps3disk is also a block device driver, but there was a good reason for that (which I forgot ;-)13:46
somlogeertu: it's a block device driver (its "sata-ness" is encapsulated mostly in the gateware layer)13:54
*** Foxyloxy <Foxyloxy!~foxyloxy@cpc151593-shef16-2-0-cust343.17-1.cable.virginm.net> has joined #litex13:57
*** so-offish <[email protected]> has joined #litex14:05
*** Flea86 <Flea86!~maomao@user/Flea86> has quit IRC (Quit: Leaving)14:16
*** Flea86 <Flea86!~maomao@user/Flea86> has joined #litex14:21
somloadded a `dev_info` before starting a DMA operation and right after the irq handler woke up the `wait_for_completion` at the end of the transfer14:46
somlostart: s:4212416 c:8 a:810c500014:47
somlodone:  s:4212416 c:8 a:810c500014:47
somlo 14:47
somlostart: s:4212424 c:8 a:810c500014:47
somlostart: s:243533824 c:8 a:82bae00014:47
somlodone:  s:243533824 c:8 a:82bae00014:47
somlo 14:47
somlostart: s:4270576 c:8 a:820a900014:47
somlodone:  s:4270576 c:8 a:820a900014:47
somlo 14:47
somlodone:  s:4212424 c:8 a:810c500014:47
somlo 14:47
somlostart: s:4212432 c:8 a:810c500014:47
somlostart: s:4204912 c:8 a:820ac00014:47
somlodone:  s:4212432 c:8 a:810c500014:47
somlo 14:47
somlodone:  s:4204912 c:8 a:820ac00014:47
somlo 14:47
somlostart: s:4212440 c:8 a:810c500014:47
somlodone:  s:4212440 c:8 a:810c500014:47
somlodoesn't happen often, but it does happen, so yes, I think I need a mutex around each multi-block DMA xfer...14:47
somloI'm a bit surprised I'm not getting errors from the gateware when this happens, though...14:48
*** so-offishul <so-offishul!~so-offish@2610:148:610:2b11::a> has joined #litex14:55
*** so-offish <[email protected]> has quit IRC (Ping timeout: 246 seconds)14:58
geertusomlo: Just keep a list of bios, and queue a new request when still busy, cfr. ps3vram_submit_bio()?15:18
*** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Quit: Leaving)15:27
*** so-offishul <so-offishul!~so-offish@2610:148:610:2b11::a> has quit IRC (Quit: Leaving)15:35
*** Finde_ <[email protected]> has joined #litex16:14
*** Finde <[email protected]> has quit IRC (Read error: Connection reset by peer)16:15
*** so-offish <so-offish!~so-offish@2610:148:610:2b11::a> has joined #litex16:31
*** Finde <[email protected]> has joined #litex16:36
*** Finde_ <[email protected]> has quit IRC (Read error: Connection reset by peer)16:36
*** so-offishul <so-offishul!~so-offish@2610:148:610:2b11::a> has joined #litex16:38
*** so-offish <so-offish!~so-offish@2610:148:610:2b11::a> has quit IRC (Ping timeout: 246 seconds)16:41
*** Finde <[email protected]> has quit IRC (Read error: Connection reset by peer)16:51
*** Finde_ <[email protected]> has joined #litex16:52
*** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)17:03
*** TMM_ <[email protected]> has joined #litex17:03
somlogeertu: I just put a mutex around the function handling an individual DMA transaction for now, which seems to have fixed the problem from a *functional* standpoint17:13
somloI'm going to look into enqueueing requests the way ps3vram does it, maybe that's going to improve performance a bit more17:14
*** so-offishul <so-offishul!~so-offish@2610:148:610:2b11::a> has quit IRC (Quit: Leaving)17:15

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!