Thread (40 messages) 40 messages, 5 authors, 2021-06-28

Re: [PATCH v9 01/22] dt-bindings: ARM: Mediatek: Add new document bindings of imp i2c wrapper controller

From: Stephen Boyd <sboyd@kernel.org>
Date: 2021-06-10 17:41:41
Also in: linux-clk, linux-devicetree, linux-mediatek, lkml

Quoting Matthias Brugger (2021-06-08 07:45:49)

On 07/06/2021 07:20, Chun-Jie Chen wrote:
quoted
On Wed, 2021-06-02 at 12:12 -0500, Rob Herring wrote:
quoted
quoted
+
+description:
+  The Mediatek imp i2c wrapper controller provides functional
configurations and clocks to the system.
+
+properties:
+  compatible:
+    items:
+      - enum:
+          - mediatek,mt8192-imp_iic_wrap_c
+          - mediatek,mt8192-imp_iic_wrap_e
+          - mediatek,mt8192-imp_iic_wrap_s
+          - mediatek,mt8192-imp_iic_wrap_ws
+          - mediatek,mt8192-imp_iic_wrap_w
+          - mediatek,mt8192-imp_iic_wrap_n
Looks to me like these are all the same h/w, but just have differing 
sets of clocks. That's not really a reason to have different 
compatibles. 

If you need to know what clocks are present, you can walk the DT for 
all 'clocks' properties matching this clock controller instance. Or
use 
'clock-indices' to define which ones are present.
Is the idea to use clock-indices and then list all the clock ids in
there and match them up at driver probe time to register the clocks
provided by the IO region? Feels like we'll do a lot of parsing at each
boot to match up structures and register clks with the clk framework.

If it's like other SoCs then the clk id maps to a hard macro for a type
of clk, and those hard macros have been glued together with other clks
and then partitioned into different IO regions to make up a clock
controller. Or maybe in this case, those clk hard macros have been
scattered into each IP block like SPI, i2c, uart, etc. so that the clock
controller doesn't really exist and merely the gates and rate control
(mux/divider) for the clk that's clocking some particular IP block all
live inside the IP wrapper. If it's this case then I hope there are a
bunch of PLLs that are fixed rate so that the i2c clk doesn't have to go
outside the wrapper to change frequency (of which there should be two
"standard" frequencies anyway).
quoted
quoted
Rob
Some module is divided to sub-modules which are designed in different
h/w blocks for different usage, and if we want to use the same
compatible to present these h/w blocks, we need to move the clock data
provided by these h/w blocks to dts, but we usually use different
compatible to get the h/w blocks data in
Mediatek's clock driver, so do you suggest to register clock provided
by different h/w blocks using same compatible?
The mapping of them is as following:
imp_iic_wrap_c:  11007000
imp_iic_wrap_e:  11cb1000
imp_iic_wrap_s:  11d03000
imp_iic_wrap_ws: 11d23000
imp_iic_wrap_w:  11e01000
imp_iic_wrap_n:  11f02000
Sure. What is their purpose though? Are they simply a bunch of different
i2c clks?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help