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

[Junyi Zhao <junyi.zhao@amlogic.com>]

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@kernel.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>>
>> From: Junyi Zhao <junyi.zhao@amlogic.com>
>>
>> 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@amlogic.com>
>> ---
> 
> No big difference. Needn't rework svc-i3c-master.c, you can add amlogic at
> svc-i3c-master.c directly.
> 
> Frank