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

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

Hi frank，
	thks for your details.

On 21/10/2026 22:37, Frank Li wrote:
> [ EXTERNAL EMAIL ]
> 
> On Wed, Oct 21, 2026 at 10:56:19AM +0800, Junyi Zhao wrote:
>> 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.
> 
> If it is in I3C memory region, you can do that by use callback. otherwise
> should go through clock framework.

The AO divider register is inside the I3C mem region, so I'll
handle it with a drvdata callback. I'll also evaluate Neil's suggestion
of modeling it as a CCF clock for v2; if that works out cleanly, the
callback goes away entirely.

> 
>>
>> - Amlogic added register blocks outside the Silvaco map: a
>>    DMA bridge and a bus monitor (0x200..0x22c).
> 
> Does DMA bridge only for I3C? It should be go through standard DMA engine.
> 
> what bus monitor use for.
> 
>>    Enabling the DMA bridge later will need hooks in the common
>>    transfer path.
> 
> We also need support DMA in future.

Yes, the bridge is dedicated to the I3C controller, and the data path
will go through the standard dmaengine framework: our SoC-internal DMA
controller has its own dmaengine driver, and the I3C driver only uses
the standard slave API .

"DMA bridge" is a small set of registers inside the I3C mem region,
  which adapt the I3C FIFOs to the SoC-internal DMA controller. 
Programming them is part of the I3C controller initialization, not part 
of the DMA engine configuration.

The bus monitor is a debug block, not necessary, i will drop it.

> 
>>
>> 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.
> 
> You can use callback function in drvdata.
> 
>> 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.
> 
> Now, there are not much user yet. Rename or re-org only when it becomes
> complex enough.
> 

Okay， isee your point.
I'll keep svc-i3c-master.c as a single file and add optional callbacks 
to struct svc_i3c_drvdata instead of the split and rename.


> Frank
> 
>>
>> 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