SDIO Mux Linux support

[SuperFungus]

I've been exploring something where I'd like to put multiple SDIO devices (SD Cards, Multiple Wifi Adapters) on a single SDIO bus to a Linux SOC.  I see there are parts like https://www.onsemi.com/pdf/datasheet/fssd06-d.pdf and https://www.ti.com/lit/ds/symlink/txs02612.pdf which are designed to do this, but I'm hitting a dead end trying to figure out if Linux can support this... I imagine if Linux did there would be someway to configure the device tree similar to how the I2C muxing works, but after looking for actual details on how I'd go about this I'm coming up empty...

Does Linux support having a switch/mux between multiple SDIO devices and the SDIO bus master? If so, can someone point me in the direction of the documentation I would need to read in order to understand how to configure it?

Thanks!

Edit:

Well, as is so often the case soon after posting this question I finally dug something up which seems more or less definitive: https://www.spinics.net/lists/linux-mmc/msg49815.html 

Kind of disappointing, going to have to figure something else out I guess...

[Postal2]

...I'd like to put multiple SDIO devices (SD Cards, Multiple Wifi Adapters) on a single SDIO bus to a Linux SOC.

I don't know about wi-fi, but the protocol for sd-cards and emmc is designed in such a way that you can connect them completely in parallel.

[SiliconWizard]

Normally, any SDIO device uses the same physical signals as well.

Now, that doesn't mean you can wire several devices in parallel at the same time. I'm actually working on using SDIO for communicating with a SoC, and at this point in my journey, I don't see a way to share the same SDIO host controller for several devices, as I don't think there is any "device addressing" feature. I may be missing it though.

[Postal2]

... I don't see a way to share the same SDIO host controller for several devices, as I don't think there is any "device addressing" feature. I may be missing it though. ...

I'm surprised you don't know how an SD card works. Read some popular description, Wikipedia...

[SiliconWizard]

... I don't see a way to share the same SDIO host controller for several devices, as I don't think there is any "device addressing" feature. I may be missing it though. ...

I'm surprised you don't know how an SD card works. Read some popular description, Wikipedia...

I must say I'm not sure I get the gist of most of your replies.

The OP has clearly answered his own question anyway. But my point (which the OP knew) is that there is no direct way you can share a single SDIO host controller with several devices.

I know quite well how SD cards work, and how SDIO works in general (I've implemented SD on MCUs), but I just said "I may be missing", because the SD specs are hundreds of pages long in total and while I know a part of that, I can't claim I know it all, and I never ran into the need of sharing one controller with multiple devices so far, so I wasn't sure. Now after reading a bit more on the topic, I'm almost 100% positive you can't, short of using external multiplexing, which is not part of the standard. So you can do it any way you see fit, multiplexing SDIO lines as needed. Which was what the OP was going to do. They just wanted to know, from what I get, if there was some existing Linux support for this, and apparently there isn't, which isn't too surprising, as it's again possible, but non-standard. So I'm not sure how one could write a generic driver for this.

You can always do it "by hand" though, selecting the device you want to communicate with via a multiplexer (with GPIOs), and then using standard SDIO functions.

But there is indeed no provision with the SD specs to "address" a particular SD device that I know of. You can have only one connected to a particular controller at any given time. (But you can again always multiplex.)
Anyway.

[Postal2]

.... Now after reading a bit more on the topic, I'm almost 100% positive you can't, short of using external multiplexing, ...

You are unusually stubborn and have absolutely no desire to read, even if you are told to do so.

[Berni]

It is indeed possible to address multiple SD cards wired parallel on the same SD bus.

However this part of the SD spec is an old and abandoned feature that technically exists but pretty much nothing uses. Real world devices didn't really have a need for this feature, so people never bothered implementing it, now the vast majority of drivers for SD card controllers are missing support for this feature, hence why it has become common knowledge that you "can't have multiple SD cards on a bus", even tho you can in certain cases if you put the work into it.

The other reason this feature became abandoned is that while this might have been a good idea back in the days when the classic SDR 25Mhz mode was used, now the SD bus runs much much faster like the DDR200 mode that does 208MHz DDR over those pins, as a result wiring two or more SD slots to the bus in a way that doesn't wreck the signal integrity becomes too difficult to bother with. So a SD bus MUX becomes a easier solution to having multiple devices.

I have seen a SD bus MUX used on a Linux SoC before, but it is very rare. Id take it you need to be lucky enough to have a SoC that comes with a SD bus controller driver with support for a bus mux. If not, then you will likely have to rewrite a lot of the driver yourself to have any chance of getting this working.

[Postal2]

...when the classic SDR 25Mhz mode was used, now the SD bus runs much much faster like the DDR200 mode that does 208MHz DDR over those pins, ....

[Berni]

Go read so more since you love digging trough details of datasheets. DDR200 is actually a SanDisk extension so you wont find it in the SD spec, but you will find SDR104 mode in the SD spec for UHS cards that also does 208MHz.

Once you get into the proper high speed UHS II modes the speeds go into the GHz where you obviously can't just parallel things.

[Postal2]

Go read so more since you love digging trough details of datasheets. ...

Well, for example, I know (because I read) that parallel connection is part of the standard, it has always been and Linux is required to support it. Multiplexers are needed so that one faulty card does not block the other.

[Berni]

Well, for example, I know (because I read) that parallel connection is part of the standard, it has always been and Linux is required to support it. Multiplexers are needed so that one faulty card does not block the other.

Yes Linux supports it just fine. The problem is the vendor specific driver for the particular SD/MMC controller in the particular SoC will usually not support multiple cards on a bus, not even using a mux (that is the more sensible solution for modern SD cards anyway as it could do UHS II modes).

While there is typically no hardware reason why it wouldn't work, the real reason is usually somewhere along the software stack that runs the show. Sometimes the lazy piece of code that stops this feature from working is buried inside a vendor supplied binary blob driver, so fixing it yourself could involve a considerable amount of reverse engineering effort.

If you don't believe me, go ahead and try to wire up two SD cards in parallel on some random device and see if it can read both.

[Postal2]

... vendor specific driver for the particular SD/MMC controller in the particular SoC will usually not support multiple cards on a bus, ....

For this you need to read another document. Because if you can communicate with one card - what prevents you from addressing another RCA (this is called relative card address). You can just as well say that only one device is possible on the i2c bus.

If you don't believe me, go ahead and try to wire up two SD cards in parallel on some random device and see if it can read both.

This is already the top level, above the driver. You can easily handle several cards in your code.

[Berni]

The driver prevents you because they are typically hard coded to only try to assign one RCA to a card and not even bother talking to the rest of them.

As i said nothing in hardware prevents you from doing this. But the drivers you get from your SoC vendor as part of the Linux BSP are usually written without support for this feature. You can get this feature working by fixing the driver yourself, but not many people want to deal with doing that (especially if the driver is in the form of a binary blob so you have to first decompile and reverse engineer it).

Yes i know, it is dumb that a part of the SD spec was just tossed aside because people just don't want to bother implementing it. The spec doesn't say that you must communicate with all cards if all you want to talk to is one card(especially when you only have 1 SD socket connected), so the industry did that. I am not saying this is the right way to do it, just saying how it is. Hence anyone trying to use this multiple cards feature on hardware currently out there will very likely run into problems, hence the OP of this post has to be concerned with this.

[Postal2]

The driver prevents you because they are typically hard coded to only try to assign one RCA to a card and not even bother talking to the rest of them.

If you don't read it yourself, it's a big burden for me to explain everything to you. Yes, the driver will give you one RCA, because that's how it's supposed to be. Then you call enumeration again, and it will give you a second RCA. That's how it works.

[Berni]

Go ahead and try calling the driver to do that on a typical Linux machine with a SD card slot and see how far you get.

[Postal2]

Go ahead and try calling the driver to do that on a typical Linux machine with a SD card slot and see how far you get.

It doesn't depend on the driver or Linux. That's how the protocol works, read it. If you want to use a multiplexer - it's the same, you just need to switch the direction between accessing different RCA.