From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41313) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YaQDS-0005FO-MG for qemu-devel@nongnu.org; Tue, 24 Mar 2015 10:54:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YaQDO-0008CL-JW for qemu-devel@nongnu.org; Tue, 24 Mar 2015 10:54:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60701) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YaQDO-0008CD-Br for qemu-devel@nongnu.org; Tue, 24 Mar 2015 10:53:58 -0400 From: Markus Armbruster References: <1426953265-19940-1-git-send-email-pbonzini@redhat.com> <87twxct6yq.fsf@blackfin.pond.sub.org> <55100193.5000701@redhat.com> <87wq27n8ed.fsf@blackfin.pond.sub.org> Date: Tue, 24 Mar 2015 15:53:54 +0100 In-Reply-To: (Peter Crosthwaite's message of "Mon, 23 Mar 2015 20:31:05 +0530") Message-ID: <87iodq5tvh.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH for-2.3] sdhci: add "drive" property List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: Peter Maydell , "Edgar E. Iglesias" , "qemu-devel@nongnu.org Developers" , Paolo Bonzini Peter Crosthwaite writes: > On Mon, Mar 23, 2015 at 7:05 PM, Markus Armbruster wrote: >> Paolo Bonzini 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.