On Fri, 2021-06-11 at 11:56 +0200, Matthias Brugger wrote: > > On 10/06/2021 19:41, Stephen Boyd wrote: > > Quoting Matthias Brugger (2021-06-08 07:45:49) > > > > > > > > > On 07/06/2021 07:20, Chun-Jie Chen wrote: > > > > On Wed, 2021-06-02 at 12:12 -0500, Rob Herring wrote: > > > > > > + > > > > > > +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). > > > > > > > > > > > > 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? > > > > That would be need to be answered by MediaTek as I don't have access > to any > documentation. > > Regards, > Matthias We describe which clock controllers are exist in dts and get the clock data provided by clock controller in driver data by matching device compatible. The clock data contains several clocks which includes the clock index, parent clock source and the details of reg control inside the IP block of clock controller. In MT8192 platform, some IP block is divide to several sub-blocks and each sub-block provides clock control by itself. Best Regards, Chun-Jie
