[RFC PATCH 0/2] hw/sd: Deprecate the SPI mode and the SPI to SD adapter

[Philippe Mathieu-Daudé]

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 at 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.