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