[PATCH 1/3] i3c: master: Rework SVC I3C to support vendor glue layers
From: Junyi Zhao
Date: Thu Oct 22 2026 - 07:44:31 EST
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@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