From: Matthias Brugger <matthias.bgg@gmail.com>
To: Stephen Boyd <sboyd@kernel.org>,
Chun-Jie Chen <chun-jie.chen@mediatek.com>,
Rob Herring <robh@kernel.org>
Cc: Nicolas Boichat <drinkcat@chromium.org>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
srv_heupstream@mediatek.com,
Project_Global_Chrome_Upstream_Group@mediatek.com,
Weiyi Lu <weiyi.lu@mediatek.com>
Subject: Re: [PATCH v9 01/22] dt-bindings: ARM: Mediatek: Add new document bindings of imp i2c wrapper controller
Date: Fri, 11 Jun 2021 11:56:47 +0200 [thread overview]
Message-ID: <de082c64-ace3-30b5-7404-1f4b607a83e1@gmail.com> (raw)
In-Reply-To: <162334689784.9598.2709970788186333494@swboyd.mtv.corp.google.com>
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-06-11 9:58 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-24 12:20 [PATCH v9 00/22] Mediatek MT8192 clock support Chun-Jie Chen
2021-05-24 12:20 ` [PATCH v9 01/22] dt-bindings: ARM: Mediatek: Add new document bindings of imp i2c wrapper controller Chun-Jie Chen
2021-06-02 17:12 ` Rob Herring
2021-06-07 5:20 ` Chun-Jie Chen
2021-06-08 14:45 ` Matthias Brugger
2021-06-10 17:41 ` Stephen Boyd
2021-06-11 9:56 ` Matthias Brugger [this message]
2021-06-15 2:34 ` Chun-Jie Chen
2021-06-18 6:32 ` Chen-Yu Tsai
2021-06-18 13:50 ` Matthias Brugger
2021-06-28 12:56 ` Chun-Jie Chen
2021-05-24 12:20 ` [PATCH v9 02/22] dt-bindings: ARM: Mediatek: Add new document bindings of mdpsys controller Chun-Jie Chen
2021-06-02 17:15 ` Rob Herring
2021-05-24 12:20 ` [PATCH v9 03/22] dt-bindings: ARM: Mediatek: Add new document bindings of msdc controller Chun-Jie Chen
2021-06-02 17:17 ` Rob Herring
2021-05-24 12:20 ` [PATCH v9 04/22] dt-bindings: ARM: Mediatek: Add new document bindings of scp adsp controller Chun-Jie Chen
2021-06-02 17:18 ` Rob Herring
2021-05-24 12:20 ` [PATCH v9 05/22] dt-bindings: ARM: Mediatek: Document bindings of MT8192 clock controllers Chun-Jie Chen
2021-06-02 17:20 ` Rob Herring
2021-06-03 12:26 ` Chun-Jie Chen
2021-05-24 12:20 ` [PATCH v9 06/22] clk: mediatek: Add dt-bindings of MT8192 clocks Chun-Jie Chen
2021-05-24 12:20 ` [PATCH v9 07/22] clk: mediatek: Fix asymmetrical PLL enable and disable control Chun-Jie Chen
2021-05-24 12:20 ` [PATCH v9 08/22] clk: mediatek: Add configurable enable control to mtk_pll_data Chun-Jie Chen
2021-05-24 12:20 ` [PATCH v9 09/22] clk: mediatek: Add mtk_clk_simple_probe() to simplify clock providers Chun-Jie Chen
2021-05-24 12:20 ` [PATCH v9 10/22] clk: mediatek: Add MT8192 basic clocks support Chun-Jie Chen
2021-05-24 12:20 ` [PATCH v9 11/22] clk: mediatek: Add MT8192 audio clock support Chun-Jie Chen
2021-05-24 12:20 ` [PATCH v9 12/22] clk: mediatek: Add MT8192 camsys " Chun-Jie Chen
2021-05-24 12:20 ` [PATCH v9 13/22] clk: mediatek: Add MT8192 imgsys " Chun-Jie Chen
2021-05-24 12:20 ` [PATCH v9 14/22] clk: mediatek: Add MT8192 imp i2c wrapper " Chun-Jie Chen
2021-05-24 12:20 ` [PATCH v9 15/22] clk: mediatek: Add MT8192 ipesys " Chun-Jie Chen
2021-05-24 12:20 ` [PATCH v9 16/22] clk: mediatek: Add MT8192 mdpsys " Chun-Jie Chen
2021-05-24 12:20 ` [PATCH v9 17/22] clk: mediatek: Add MT8192 mfgcfg " Chun-Jie Chen
2021-05-24 12:20 ` [PATCH v9 18/22] clk: mediatek: Add MT8192 mmsys " Chun-Jie Chen
2021-06-08 14:44 ` Matthias Brugger
2021-06-08 22:38 ` Chun-Jie Chen
2021-06-09 8:08 ` Matthias Brugger
2021-05-24 12:20 ` [PATCH v9 19/22] clk: mediatek: Add MT8192 msdc " Chun-Jie Chen
2021-05-24 12:20 ` [PATCH v9 20/22] clk: mediatek: Add MT8192 scp adsp " Chun-Jie Chen
2021-05-24 12:20 ` [PATCH v9 21/22] clk: mediatek: Add MT8192 vdecsys " Chun-Jie Chen
2021-05-24 12:20 ` [PATCH v9 22/22] clk: mediatek: Add MT8192 vencsys " Chun-Jie Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=de082c64-ace3-30b5-7404-1f4b607a83e1@gmail.com \
--to=matthias.bgg@gmail.com \
--cc=Project_Global_Chrome_Upstream_Group@mediatek.com \
--cc=chun-jie.chen@mediatek.com \
--cc=devicetree@vger.kernel.org \
--cc=drinkcat@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=robh@kernel.org \
--cc=sboyd@kernel.org \
--cc=srv_heupstream@mediatek.com \
--cc=weiyi.lu@mediatek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).