Re: [Qemu-devel] [PATCH for-2.3] sdhci: add "drive" property

[Markus Armbruster]

Peter Crosthwaite <address@hidden> writes:

> On Mon, Mar 23, 2015 at 7:05 PM, Markus Armbruster <address@hidden> wrote:
>> Paolo Bonzini <address@hidden> writes:
>>
>>> On 23/03/2015 10:10, Markus Armbruster wrote:
[...]
>>>> I believe the proper solution for your problem is qdevifying the SD
>>>> card.
>>>
>>> The question is whether there is a use for qdevifying the SD card.
>>
>> Okay, that's a fair question.
>>
>>> Each SD/MMC controller will have exactly zero or one SD cards, but the
>>> hw/sd/sd.c interface already treats "BlockBackend ejected" as "zero SD
>>> cards":
>>>
>>>     if (!sd->blk || !blk_is_inserted(sd->blk) || !sd->enable) {
>>>         return 0;
>>>     }
>>>
>>> Unlike SCSI, the SD card code:
>>>
>>> 1) doesn't need multiplexing (a la scsi-hd/scsi-cd/scsi-generic)
>>>
>>> 2) doesn't have a bus to talk on (real-world SD cards are just connected
>>> with GPIO pins; hw/sd/sd.c abstracts the bitbanging protocol but still
>>> there is only one device to talk to)
>>>
>>> So in the end I think it's easier to treat hw/sd/sd.c as the common code
>>> for all hw/sd/* devices, like e.g. hw/display/vga.c.
>>
>> To pick a block device precedent: like floppy.
>>
>> I don't like that the floppy controller and its drives are fused.
>> However, the fusing has been *much* less grief than the usb-storage
>> hack: basically just a weird user interface to configure the drives,
>> namely --global instead of --device.
>>
>> If sd.c is common code rather than a device model in its own right,
>> perhaps SDState should be unboxed in SDHCIState, just like the FDrive
>> are unboxed in FDCtrl.  The "drive" property can then be connected
>> straight to SDState member blk.
>>
>
> sd.c for me is definitely a device in its own right, and SDHCI is
> quite separate. We already have multiple SD controllers connecting to
> SD cards. Ideally, SD should be bussified (or the modern equivalient
> using Links). I actually have code in my my tree that connects an
> SDHCI to two cards with muxing logic handled by another peripheral.
>
> There are a wider class of SD devices that can use the SD bus beyond
> SD cards (although we don't model any today). Another thing to
> consider is MMC support which is a subtle variant on SD card. We need
> the QOMification of sd.c to setup user-settable props or an
> inheritance hierarchy for the different flavors of SD/MMC cards. I
> don't think rolling into the controller is a good idea as then the
> controller needs to take ownership of any card configuration.
>
> I think the correct way forward is the qom/qdevification.
>
> Note that SD has a SPI mode, every SD card is in theory a valid SSI
> device. We could unify SD under SSI to achieve both QOMification and
> busification.
>
> I would then expect the block setup of sd.c to be very similar to
> hw/block/m25p80.c (SPI flash).

Do you think you'll be able to work on this?

It would be nice to have -device sdhci-pci working in 2.4.