12:05 <_florent_> iTitou: the CSRStorages need to be part of the Module to be collected (self.A, self.B, self.C instead of A, B, C)

14:36 <sthornington> Anyone with a ulx3s that can quickly test if the B1 button still works to rst and reload firmware?

17:06 <iTitou> _florent_: Thx !

17:35 <somlo> _florent_: is there any scenario in which the LiteSDCard gateware would be used with a non-removable card? I'm assuming No, but maybe I'm missing something

17:35 <somlo> also, any scenario where one would want to use GPIO for things like card-detect, instead of the built-in gateware functionality ?

17:36 <somlo> I'm also guessing No to this one, but with somewhat less confidence :)

17:36 <somlo> Asking because the current Linux driver checks for all of these as part of its card-detect method, and I'd like to simply remove all that dead code (on the assumption it's really *dead*)

17:42 <Finde> not in direct answer but in that theme, I seem to remember that Xilinx's vc707 board doesn't even have a CD pin

17:45 <somlo> Finde: IIRC digging through the LiteSDCard gateware sources yesterday the CSR bit dedicated to card-detect is hard-coded to "present" in that case

17:46 <somlo> whatever that is (0 I believe)

17:48 <Finde> yeah that's what we had to do for our sd device

17:48 <somlo> although in that case detecting eject and re-insert from e.g. Linux will end up being lots and lots of fun

17:49 <Finde> we just assumed it would never be unplugged...

17:49 <Finde> bit hard to give any guarantees there

17:49 <somlo> maybe that's where GPIO could come into play in some shape of form? I'm really not a hardware guy, althoug I'm trying hard to keep up ;)

17:50 <Finde> oh like to flick a separate switch after you insert kind of thing?

17:50 <Finde> seems reasonable yeah

17:53 <somlo> so you'd specify that in some DT cell in your mmc node, in which case I should probably *NOT* remove that code, as it's *NOT* dead :)

17:53 <Finde> makes sense to me

17:54 <somlo> In its current form, the driver does some trickery w.r.t. inserting a set-bus-width command into the command stream driven by the generic mmc layers *once* at the "right time" in "the beginning"

17:55 <somlo> and the "we're done with this part" flag stays set across an eject/reinsert cycle, so the card is never properly re-initialized after being ejected once

17:55 <somlo> so I'm trying to hook into the "get_cd" mmc driver method to reset that "we still need to set the bus width" flag

17:57 <somlo> so if the card is not removable, there's no problem; If we can rely on the CSR card-detect flag, we're OK; if there isn't a card-detect pin, we punt and make it GPIO's problem to signal us when the card is in/out of its slot (best effort)

17:57 <somlo> Finde: thanks for the brainstorm, I think it all starts making sense now ;)

18:48 <somlo> _florent_, Finde: https://github.com/litex-hub/linux/commit/2a99b5a0285edfb0d44f2745737feaacfb3fca14 (latest commit in the litex-rocket-rebase branch)

19:05 <Finde> at the very least your description sounds right to me

19:07 <somlo> I'm not a huge fan of how the set_bus_width is done, but given that, the fix I put in works. I'm going to look at the overall driver some more for additional clean-up opportunities :)

20:25 <somlo> as it turns out, the trellisboard's built-in sdcard reader doesn't have a card-detect pin either

20:26 <somlo> gateware hard-codes a "present" bit in the CSR card-detect register