Re: [PATCH 1/3] i3c: master: Rework SVC I3C to support vendor glue layers

[Junyi Zhao]

Hi Frank,

Thanks for looking at this.

Amlogic A9 used the same SVC I3C IP engine, but the integration of it
differs in the resources *around* the controller, which cannot be
expressed as another quirks entry:

- On the "ao" instance the bus clock is generated by an internal
  divider (I3C_AO_FCLK_DIV_CTRL @0x304) programmed directly by the
  driver; there is no CCF clock to clk_set_rate() on, while the
  common probe assumes the fclk is a plain enable-able clock.

- Amlogic added register blocks outside the Silvaco map: a
  DMA bridge and a bus monitor (0x200..0x22c).
  Enabling the DMA bridge later will need hooks in the common
  transfer path.

Adding A9 support to svc-i3c-master.c directly, would make these
becomes if-branches in probe()/PM/transfer paths of the shared
driver, and the next vendor repeats that. With the glue layer,
i3c-main.c keeps today's logic unchanged: i3c-silvaco.c is the
current probe code moved as-is (rename with 79% similarity), so
blame/history is preserved.

If the file move is the main concern, I can keep
svc-i3c-master.c where it is and only export the alloc/probe/remove/PM/
interface for glue drivers -- the essential part for me is keeping
the resource handling out of the common code paths.

Also, per Neil's suggestion I'll try modeling the AO divider as a
CCF clock in v2, which should drop one hook.

Thanks,
Junyi


On 2026/10/20 4:32, Frank Li wrote:
> [ EXTERNAL EMAIL ]
>
> On Mon, Oct 19, 2026 at 01:34:26PM +0800, Junyi Zhao via B4 Relay wrote:
> > [You don't often get email from devnull+junyi.zhao.amlogic.com@xxxxxxxxxx. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > From: Junyi Zhao <junyi.zhao@xxxxxxxxxxx>
> >
> > The SVC I3C controller IP can be integrated into SoCs from different
> > vendors. Peripheral resources associated with the controller, such as
> > clocks, may vary between vendor implementations.
> >
> > Rework the driver to separate common functionality from
> > vendor-specific extensions. The common logic is shared across all
> > implementations, while platform-dependent operations are provided
> > through vendor-specific hooks.
> >
> > Also add a corresponding MAINTAINERS entry for the SILVACO I3C
> > controller.
> >
> > Signed-off-by: Junyi Zhao <junyi.zhao@xxxxxxxxxxx>
> > ---
>
> No big difference. Needn't rework svc-i3c-master.c, you can add amlogic at
> svc-i3c-master.c directly.
>
> Frank