RE: [PATCH 11/22] ASoC: rsnd: ssui: Add RZ/G3E SSIU BUSIF support

[John Madieu]

Hi Kuninori,

Thank you for the review.

> -----Original Message-----
> From: Kuninori Morimoto <kuninori.morimoto.gx@xxxxxxxxxxx>
> Sent: Monday, March 23, 2026 3:56 AM
> To: John Madieu <john.madieu.xa@xxxxxxxxxxxxxx>
> Subject: Re: [PATCH 11/22] ASoC: rsnd: ssui: Add RZ/G3E SSIU BUSIF support
> 
> 
> Hi John
> 
> > Add support for the SSIU found on the Renesas RZ/G3E SoC, which
> > provides a different BUSIF layout compared to earlier generations:
> >
> >  - SSI0-SSI4: 4 BUSIF instances each (BUSIF0-3)
> >  - SSI5-SSI8: 1 BUSIF instance each (BUSIF0 only)
> >  - SSI9: 4 BUSIF instances (BUSIF0-3)
> >  - Total: 28 BUSIFs
> >
> > RZ/G3E also differs from Gen2/Gen3 implementations in that only two
> > pairs of BUSIF error-status registers are available instead of four,
> > and the SSI always operates in BUSIF mode with no PIO fallback.
> >
> > Rather than scattering SoC-specific checks across functional code,
> > introduce two capability flags in the match data:
> >
> >  - RSND_SSI_ALWAYS_BUSIF: the SSI has no PIO mode and always uses
> >    BUSIF. Used in rsnd_ssi_use_busif() and rsnd_ssiu_init() to skip
> >    SSI_MODE0 configuration.
> >  - RSND_SSIU_BUSIF_STATUS_COUNT_2: only two BUSIF error-status
> >    register pairs are present. Used in rsnd_ssiu_busif_err_irq_ctrl()
> >    and rsnd_ssiu_busif_err_status_clear() to limit register iteration.
> >
> > Future SoCs sharing these constraints can set the flags without
> > requiring code changes.
> >
> > Signed-off-by: John Madieu <john.madieu.xa@xxxxxxxxxxxxxx>
> > ---
> (snip)
> > @@ -650,6 +651,8 @@ struct rsnd_priv {
> >  #define RSND_RZG3E	(5 << 0)
> >  #define RSND_SOC_MASK	(0xFF << 4)
> >  #define RSND_SOC_E	(1 << 4) /* E1/E2/E3 */
> > +#define RSND_SSI_ALWAYS_BUSIF	BIT(12) /* SSI has no PIO mode, always
> uses BUSIF */
> 
> I don't think we need RSND_SSI_ALWAYS_BUSIF, because PIO is used for debug
> purpose when new SoC has comming.
> 

I understand that PIO is useful as a debug fallback when bringing up new SoCs.
Looking at the RZ/G3E datasheet (section 8.5), SSITDR/SSIRDR exist as data
buffers in the SSI block, but they are accessible only through the DMA access
port - not through the register access port (CPU access).

The datasheet explicitly states "PIO access (setting prohibited)" for the
BUSIF data path. This is also why the register descriptions (8.5.2.3.29-33)
list SSICR, SSISR, SSIWSR, SSIFMR, SSIFSR but no SSITDR/SSIRDR at register
access port offsets. So PIO mode (CPU reading/writing SSITDR/SSIRDR directly)
is not supported by the hardware.

If we attempt PIO fallback on RZ/G3E, rsnd_ssi_pio_interrupt() would try to
access SSITDR/SSIRDR which are not mapped in the regmap, causing a failure.

So, should I keep RSND_SSI_ALWAYS_BUSIF to express this, or would you prefer
a direct rsnd_is_rzg3e() check in rsnd_ssi_use_busif()? I would go for the
first option as this could be reusable on other SoCs and avoid SoC-specific
checks across functional code.

Regards,
John

> 
> Thank you for your help !!
> 
> Best regards
> ---
> Kuninori Morimoto