Re: [Qemu-devel] [PATCH 1/3] hw/sd/pxa2xx_mmci: convert to SysBusDevice object

[Peter Crosthwaite]

On Fri, Dec 4, 2015 at 11:24 AM, Kevin O'Connor <address@hidden> 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/address@hidden/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