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_nLooks 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
RobSome 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