Re: [PATCH v3 1/5] hw/ssi: Add Synopsys DWC SSI standard PIO controller
Portia Stephens <[email protected]>
| Newsgroups | org.nongnu.qemu-riscv,org.nongnu.qemu-devel |
|---|---|
| Message-ID | <[email protected]> |
On 21/8/2026 1:56 PM, Kangjie Huang wrote: > Portia Stephens <[email protected]> 于2026年8月21日周五 09:11写道: >> >> I don't think this will work for frame != 8-bit with the m25p80 flash >> model used by k230. ssi_transfer() takes a 32-bit value but it then >> calls m25p80_transfer8() which will just transfer the bottom 8-bits and >> drop the rest. >> >> I don't know if this is an issue with your code or with the ssi_transfer >> function though. It seems like ssi_transfer intends to accept 32-bit >> values. >> > Hi Portia, > > Thanks for the review. > > On SPI_FRF: you are right, the explicit clearing in dw_ssi_write() is > redundant because dw_ssi_write_masked() already drops the bits that are > not in the writable mask. I will remove it and add a LOG_UNIMP warning > when a non-zero SPI_FRF value is written. > > On the frame width: ssi_transfer() takes a uint32_t word. The issue is > that the DWC model uses CTRLR0.DFS (4..32 bits) to define each > transmitted frame, while SPI NOR is an 8-bit consumer, so the two are > aligned only when DFS is 8. The K230 SDK SPI-NOR paths use 8-bit > frames, so this case is not exposed by the current K230 use case. > Maybe either add a DFS != 8 restriction with a LOG_UNIMP warning, or > have the DWC model split byte-aligned 16/24/32-bit frames into > multiple 8-bit ssi_transfer() calls? I think either option is fine. If there isn't anything testing the variable frame width it might make sense to just restrict the width to what is tested. > > Thanks, > Kangjie