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

Hi,

On Tue, Aug 4, 2026 at 10:57 PM Kangjie Huang <[email protected]> wrote:
>
> 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.

Sounds good. I wouldn't worry about supporting dw-apb-ssi.

>
> Regards,
> Kangjie