On Fri, Dec 4, 2015 at 11:24 AM, Kevin O'Connor <ke...@koconnor.net> wrote: > On Fri, Dec 04, 2015 at 10:50:21AM -0800, Peter Crosthwaite wrote: >> > FWIW, I don't think the SD card will be qdevified because it doesn't >> > need a bus. It's similar indeed to SerialState, which was supposed to >> > be the poster child of QOM embedding and never got QOMified. >> >> SD is a bus in its own right and should be busified and QOMified IMO. >> SDHCI can talk to non-sd cards (SDIO). There is also a range of >> incompatible cards that you can talk to - MMC/eMMC/SD(H|S|X)C. I think >> anything that couples the controller to an SD card is a bug, the card >> and device should be arranged as separate devices. >> >> > A host controller controls exactly one SD card, the SSI bridge is also >> > for exactly one SD card, etc. >> >> I think you can RYO chip selects with a GPIO and control multiple SD >> cards with one SDHCI. > > In practice, the SDHCI controllers are one-to-one with cards. This is > codified in the sdhci spec as it has a "card present" bit and "port > location" information that is per controller. >
But SDHCI is only one SD controller implementation. Other SD controllers may easily implement the SDIO bus as non 1:1. I also don't see why a 1:1 bus should have a completely different implementation that propagates through to UI level issues. SD is a bus like any other IMO. > I suppose in theory, one could put an SDHCI contoller into SPI > compatibility mode and "hot wire" it into a bus, but qemu doesn't > support that anyway, and it is a lot of complexity for something that > is not done in practice. > Note that the chip selects for SD are on the copper interface as well, so you can easily implement multi-device SD bus on the level above SDHCI. SPI mode should not required. Even if SDHCI does have card-detection CS control logic this can be demultiplexed to multiple cards by extra logic. We also have precedent of implementers of SDHCI opting-out of features like power control, and assumptions about how SDHCI is wired have already led to bugs like this: https://www.mail-archive.com/qemu-devel@nongnu.org/msg338495.html We don't need to be implementing the multi CS logic today, but making UI level decisions based on this 1:1 assumption seems wrong. Regards, Peter > -Kevin
