Peter Crosthwaite <[email protected]> writes: > On Mon, Mar 23, 2015 at 7:05 PM, Markus Armbruster <[email protected]> wrote: >> Paolo Bonzini <[email protected]> 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.
