[RFC PATCH 0/2] hw/sd: Deprecate the SPI mode and the SPI to SD adapter
I tried to maintain the SPI mode because it is useful in tiny embedded devices, and thought it would be helpful for the AVR MCUs. As AVR was blocked, I thought it was wise to deprecate the SPI mode as users are interested in the faster MMC mode. Today Thomas surprised me by posting an update of it! https://www.mail-archive.com/qemu-devel@nongnu.org/msg720089.html I'm still posting this as RFC to discuss, but I'm reconsiderating keeping this mode a bit more. Philippe Mathieu-Daudé (2): hw/sd/ssi-sd: Deprecate the SPI to SD card 'adapter' hw/sd/sdcard: Deprecate the SPI mode docs/system/deprecated.rst | 10 ++++++++++ 1 file changed, 10 insertions(+) -- 2.21.3
This device duplicate the SPI mode of the sd-card device. The SPI protocol is better handler in the sd-card, however as the TYPE_SSI_SLAVE is not an interface, the sd-card can not implement it easily to be pluggable on a SPI bus. Meanwhile the ssi-sd device acts as a bridge, but is bitroting. Deprecate it. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> --- docs/system/deprecated.rst | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst index 47f84be8e0..5e67d7f3e0 100644 --- a/docs/system/deprecated.rst +++ b/docs/system/deprecated.rst @@ -343,6 +343,11 @@ The 'ide-drive' device is deprecated. Users should use 'ide-hd' or The 'scsi-disk' device is deprecated. Users should use 'scsi-hd' or 'scsi-cd' as appropriate to get a SCSI hard disk or CD-ROM as needed. +``ssi-sd`` (since 5.1) +''''''''''''''''''''''''' + +The 'ssi-sd' (SSI to SD card adapter) device is deprecated. + System emulator machines ------------------------ -- 2.21.3
On 7/5/20 5:07 PM, Philippe Mathieu-Daudé wrote:
This device duplicate the SPI mode of the sd-card device. The
duplicates
SPI protocol is better handler in the sd-card, however as the TYPE_SSI_SLAVE is not an interface, the sd-card can not implement it easily to be pluggable on a SPI bus. Meanwhile the ssi-sd device acts as a bridge, but is bitroting. Deprecate it.
bitrotting
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> --- docs/system/deprecated.rst | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst index 47f84be8e0..5e67d7f3e0 100644 --- a/docs/system/deprecated.rst +++ b/docs/system/deprecated.rst @@ -343,6 +343,11 @@ The 'ide-drive' device is deprecated. Users should use 'ide-hd' or The 'scsi-disk' device is deprecated. Users should use 'scsi-hd' or 'scsi-cd' as appropriate to get a SCSI hard disk or CD-ROM as needed.
+``ssi-sd`` (since 5.1) +'''''''''''''''''''''''''
Inconsistent line lengths
+ +The 'ssi-sd' (SSI to SD card adapter) device is deprecated.
What is the recommended replacement? Or at least document if it is disappearing with no replacement.
+ System emulator machines ------------------------
-- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
On Mon, Jul 06, 2020 at 00:07:30 +0200, Philippe Mathieu-Daudé wrote:
This device duplicate the SPI mode of the sd-card device. The SPI protocol is better handler in the sd-card, however as the TYPE_SSI_SLAVE is not an interface, the sd-card can not implement it easily to be pluggable on a SPI bus. Meanwhile the ssi-sd device acts as a bridge, but is bitroting. Deprecate it.
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> --- docs/system/deprecated.rst | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst index 47f84be8e0..5e67d7f3e0 100644 --- a/docs/system/deprecated.rst +++ b/docs/system/deprecated.rst @@ -343,6 +343,11 @@ The 'ide-drive' device is deprecated. Users should use 'ide-hd' or The 'scsi-disk' device is deprecated. Users should use 'scsi-hd' or 'scsi-cd' as appropriate to get a SCSI hard disk or CD-ROM as needed.
+``ssi-sd`` (since 5.1) +''''''''''''''''''''''''' + +The 'ssi-sd' (SSI to SD card adapter) device is deprecated.
libvirt didn't allow configuring this device yet, so from our view it's okay to remove it. ACKed-by: Peter Krempa <pkrempa@redhat.com>
SD cards be used with SPI, SD or MMC protocol. Unfortunately, maintaining the SPI protocol make improving the MMC mode very difficult. As of 2020 users are more interested in using cards with the MMC protocol. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> --- docs/system/deprecated.rst | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst index 5e67d7f3e0..01dca3d038 100644 --- a/docs/system/deprecated.rst +++ b/docs/system/deprecated.rst @@ -384,6 +384,11 @@ full SCSI support. Use virtio-scsi instead when SCSI passthrough is required. Note this also applies to ``-device virtio-blk-pci,scsi=on|off``, which is an alias. +``-device sd-card,spi=on`` (since 5.1) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The SPI mode of the 'sd-card' device is deprecated. + Block device options '''''''''''''''''''' -- 2.21.3
On Mon, Jul 06, 2020 at 00:07:31 +0200, Philippe Mathieu-Daudé wrote:
SD cards be used with SPI, SD or MMC protocol.
Unfortunately, maintaining the SPI protocol make improving the MMC mode very difficult. As of 2020 users are more interested in using cards with the MMC protocol.
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> --- docs/system/deprecated.rst | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst index 5e67d7f3e0..01dca3d038 100644 --- a/docs/system/deprecated.rst +++ b/docs/system/deprecated.rst @@ -384,6 +384,11 @@ full SCSI support. Use virtio-scsi instead when SCSI passthrough is required. Note this also applies to ``-device virtio-blk-pci,scsi=on|off``, which is an alias.
+``-device sd-card,spi=on`` (since 5.1) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The SPI mode of the 'sd-card' device is deprecated.
libvirt didn't implement this knob so it's okay to remove it without replacement. ACKed-by: Peter Krempa <pkrempa@redhat.com>
On Sun, Jul 5, 2020 at 3:08 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
I tried to maintain the SPI mode because it is useful in tiny embedded devices, and thought it would be helpful for the AVR MCUs. As AVR was blocked, I thought it was wise to deprecate the SPI mode as users are interested in the faster MMC mode. Today Thomas surprised me by posting an update of it! https://www.mail-archive.com/qemu-devel@nongnu.org/msg720089.html
I'm still posting this as RFC to discuss, but I'm reconsiderating keeping this mode a bit more.
I think it's worth keeping. I'm pretty sure the HiFive Unleashed (sifive_u in QEMU) uses SD over SPI. There isn't an upstream model but I think there are out of tree patches that hopefully one day will make it upstream. Alistair
Philippe Mathieu-Daudé (2): hw/sd/ssi-sd: Deprecate the SPI to SD card 'adapter' hw/sd/sdcard: Deprecate the SPI mode
docs/system/deprecated.rst | 10 ++++++++++ 1 file changed, 10 insertions(+)
-- 2.21.3
On 7/6/20 6:41 PM, Alistair Francis wrote:
On Sun, Jul 5, 2020 at 3:08 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
I tried to maintain the SPI mode because it is useful in tiny embedded devices, and thought it would be helpful for the AVR MCUs. As AVR was blocked, I thought it was wise to deprecate the SPI mode as users are interested in the faster MMC mode. Today Thomas surprised me by posting an update of it! https://www.mail-archive.com/qemu-devel@nongnu.org/msg720089.html
I'm still posting this as RFC to discuss, but I'm reconsiderating keeping this mode a bit more.
I think it's worth keeping.
I'm pretty sure the HiFive Unleashed (sifive_u in QEMU) uses SD over SPI. There isn't an upstream model but I think there are out of tree patches that hopefully one day will make it upstream.
Glad to hear that! :)
Alistair
Philippe Mathieu-Daudé (2): hw/sd/ssi-sd: Deprecate the SPI to SD card 'adapter' hw/sd/sdcard: Deprecate the SPI mode
docs/system/deprecated.rst | 10 ++++++++++ 1 file changed, 10 insertions(+)
-- 2.21.3
Hi Philippe, On Mon, Jul 6, 2020 at 6:07 AM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
I tried to maintain the SPI mode because it is useful in tiny embedded devices, and thought it would be helpful for the AVR MCUs. As AVR was blocked, I thought it was wise to deprecate the SPI mode as users are interested in the faster MMC mode. Today Thomas surprised me by posting an update of it! https://www.mail-archive.com/qemu-devel@nongnu.org/msg720089.html
I'm still posting this as RFC to discuss, but I'm reconsiderating keeping this mode a bit more.
AFAIK, SiFive folks (Pragnesh in cc) are investigating supporting QSPI model on "sifive_u" machine, and it will definitely use this SPI over SD model. In fact, the QSPI is the last big gap in the "sifive_u" machine to make it a complete platform for hardware replacement. Regards, Bin
On 7/10/20 11:27 AM, Bin Meng wrote:
Hi Philippe,
On Mon, Jul 6, 2020 at 6:07 AM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
I tried to maintain the SPI mode because it is useful in tiny embedded devices, and thought it would be helpful for the AVR MCUs. As AVR was blocked, I thought it was wise to deprecate the SPI mode as users are interested in the faster MMC mode. Today Thomas surprised me by posting an update of it! https://www.mail-archive.com/qemu-devel@nongnu.org/msg720089.html
I'm still posting this as RFC to discuss, but I'm reconsiderating keeping this mode a bit more.
AFAIK, SiFive folks (Pragnesh in cc) are investigating supporting QSPI model on "sifive_u" machine, and it will definitely use this SPI over SD model.
In fact, the QSPI is the last big gap in the "sifive_u" machine to make it a complete platform for hardware replacement.
Good news! I have some idea about the design, but don't have the time to work on it. Help in this area is welcomed, and I am happy to review the patches. The way I'd do it is keep the generic sd.c code and make it an abstract class (or interface), and split SD / SPI protocols handling in different implementation files. Only the negotiation at reset is common, once you switch to a protocol mode you can't switch to another without resetting the device. Also this would make the MMC protocol (already implemented by Xilinx) upstreamable more easily. Having different files also allows different maintenance granularity. I haven't looked at QSPI, but I expect it to be quite different that the old SPI mode. Regards, Phil.
participants (5)
-
Alistair Francis -
Bin Meng -
Eric Blake -
Peter Krempa -
Philippe Mathieu-Daudé