Re: [PATCH v2 1/5] hw/ssi: Add Synopsys DesignWare SSI standard PIO controller

Kangjie Huang <[email protected]> Wed, 5 Aug 2026 11:56:55 +0800
Newsgroups gmane.comp.emulators.qemu
Message-ID <CAAW0U4a-nG-ck4g8w0_Vt1Jbu5dNcYEDjJNR-YvGEiHa9G4Rdw@mail.gmail.com>
Anirudh Srinivasan <[email protected]> 于2026年8月5日周三 02:39写道:

> There are 2 variants of designware spi, one is called dw-apb-ssi and
> another is called dwc-ssi. If you look at their u-boot drivers, you can
> see that they differ in the location of the TMOD bits in the CTRLR0.
> dw-apb-ssi has it at bits 8 and 9, while dwc-ssi has it at 10/11.
> This implementation is for the dwc-ssi version (which is the newer one).
>
> Would it be possible to have the naming be consistent (DWC_SSI,
> dwc_ssi.c) everywhere? There are some places throught the series where
> the file names/Kconfig symbols/function names are named dw_ssi.
>
> One could argue that this model could retain the generic designware spi
> name and support both versions, but I don't think that's necessary.

I will make the naming consistently use dwc_ssi throughout the
next revision of the series.

I compared the dw-apb-ssi and dwc-ssi , as well as their Linux
and U-Boot driver implementations, and confirmed that the two variants
have distinct guest-visible register ABIs. As you note, CTRLR0.TMOD is
located at bits [9:8] in dw-apb-ssi and at bits [11:10] in DWC SSI. Also,The
layouts and supported ranges of other fields, including DFS, FRF and
SCPH/SCPOL, also differ. Linux and U-Boot likewise use explicit
capability checks to select the appropriate register field encodings.

Supporting dw-apb-ssi would require variant-specific register handling
and tests. But QEMU currently has no concrete dw-apb-ssi machine/SoC
consumer, my understanding is that this series should remain focused on
dwc-ssi, with dw-apb-ssi support added together with a concrete consumer
and its tests in the future. Please let me know if I have misunderstood.

Regards,
Kangjie