All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chen-Yu Tsai <wenst@chromium.org>
To: Stephen Boyd <sboyd@kernel.org>
Cc: Chun-Jie Chen <chun-jie.chen@mediatek.com>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Rob Herring <robh@kernel.org>,
	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, 18 Jun 2021 14:32:25 +0800	[thread overview]
Message-ID: <CAGXv+5HcV6jbyDdZGzRX-2NHMztSONBKxmLxLQX6k+aQrwJ1ww@mail.gmail.com> (raw)
In-Reply-To: <c8e8535cef67adeaefcfe943bbd8287806921e03.camel@mediatek.com>

On Wed, Jun 16, 2021 at 2:34 AM Chun-Jie Chen
<chun-jie.chen@mediatek.com> wrote:
>
> 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.

Some more information:

Based on what I read in the datasheets, I'm guessing that MediaTek groups
the I2C controllers into several groups and places them in different parts
of the die. The suffix of imp_iic_wrap_XXX is likely pointing to the
placement of the group. And the imp_iic_wrap_XXX is what the name suggests
a wrapper around the group of I2C controllers. The wrapper contains clock
and reset controls, as well as other things that I can't make out.


ChenYu

WARNING: multiple messages have this Message-ID (diff)
From: Chen-Yu Tsai <wenst@chromium.org>
To: Stephen Boyd <sboyd@kernel.org>
Cc: Chun-Jie Chen <chun-jie.chen@mediatek.com>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	 Rob Herring <robh@kernel.org>,
	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, 18 Jun 2021 14:32:25 +0800	[thread overview]
Message-ID: <CAGXv+5HcV6jbyDdZGzRX-2NHMztSONBKxmLxLQX6k+aQrwJ1ww@mail.gmail.com> (raw)
In-Reply-To: <c8e8535cef67adeaefcfe943bbd8287806921e03.camel@mediatek.com>

On Wed, Jun 16, 2021 at 2:34 AM Chun-Jie Chen
<chun-jie.chen@mediatek.com> wrote:
>
> 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.

Some more information:

Based on what I read in the datasheets, I'm guessing that MediaTek groups
the I2C controllers into several groups and places them in different parts
of the die. The suffix of imp_iic_wrap_XXX is likely pointing to the
placement of the group. And the imp_iic_wrap_XXX is what the name suggests
a wrapper around the group of I2C controllers. The wrapper contains clock
and reset controls, as well as other things that I can't make out.


ChenYu

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

WARNING: multiple messages have this Message-ID (diff)
From: Chen-Yu Tsai <wenst@chromium.org>
To: Stephen Boyd <sboyd@kernel.org>
Cc: Chun-Jie Chen <chun-jie.chen@mediatek.com>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	 Rob Herring <robh@kernel.org>,
	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, 18 Jun 2021 14:32:25 +0800	[thread overview]
Message-ID: <CAGXv+5HcV6jbyDdZGzRX-2NHMztSONBKxmLxLQX6k+aQrwJ1ww@mail.gmail.com> (raw)
In-Reply-To: <c8e8535cef67adeaefcfe943bbd8287806921e03.camel@mediatek.com>

On Wed, Jun 16, 2021 at 2:34 AM Chun-Jie Chen
<chun-jie.chen@mediatek.com> wrote:
>
> 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.

Some more information:

Based on what I read in the datasheets, I'm guessing that MediaTek groups
the I2C controllers into several groups and places them in different parts
of the die. The suffix of imp_iic_wrap_XXX is likely pointing to the
placement of the group. And the imp_iic_wrap_XXX is what the name suggests
a wrapper around the group of I2C controllers. The wrapper contains clock
and reset controls, as well as other things that I can't make out.


ChenYu

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-06-18  6:32 UTC|newest]

Thread overview: 116+ 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 ` 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-05-24 12:20   ` Chun-Jie Chen
2021-05-24 12:20   ` Chun-Jie Chen
2021-06-02 17:12   ` Rob Herring
2021-06-02 17:12     ` Rob Herring
2021-06-02 17:12     ` Rob Herring
2021-06-07  5:20     ` Chun-Jie Chen
2021-06-07  5:20       ` Chun-Jie Chen
2021-06-07  5:20       ` Chun-Jie Chen
2021-06-08 14:45       ` Matthias Brugger
2021-06-08 14:45         ` Matthias Brugger
2021-06-08 14:45         ` Matthias Brugger
2021-06-10 17:41         ` Stephen Boyd
2021-06-10 17:41           ` Stephen Boyd
2021-06-10 17:41           ` Stephen Boyd
2021-06-11  9:56           ` Matthias Brugger
2021-06-11  9:56             ` Matthias Brugger
2021-06-11  9:56             ` Matthias Brugger
2021-06-15  2:34             ` Chun-Jie Chen
2021-06-15  2:34               ` Chun-Jie Chen
2021-06-15  2:34               ` Chun-Jie Chen
2021-06-18  6:32               ` Chen-Yu Tsai [this message]
2021-06-18  6:32                 ` Chen-Yu Tsai
2021-06-18  6:32                 ` Chen-Yu Tsai
2021-06-18 13:50                 ` Matthias Brugger
2021-06-18 13:50                   ` Matthias Brugger
2021-06-18 13:50                   ` Matthias Brugger
2021-06-28 12:56                   ` Chun-Jie Chen
2021-06-28 12:56                     ` Chun-Jie Chen
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-05-24 12:20   ` Chun-Jie Chen
2021-05-24 12:20   ` Chun-Jie Chen
2021-06-02 17:15   ` Rob Herring
2021-06-02 17:15     ` Rob Herring
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-05-24 12:20   ` Chun-Jie Chen
2021-05-24 12:20   ` Chun-Jie Chen
2021-06-02 17:17   ` Rob Herring
2021-06-02 17:17     ` Rob Herring
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-05-24 12:20   ` Chun-Jie Chen
2021-05-24 12:20   ` Chun-Jie Chen
2021-06-02 17:18   ` Rob Herring
2021-06-02 17:18     ` Rob Herring
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-05-24 12:20   ` Chun-Jie Chen
2021-05-24 12:20   ` Chun-Jie Chen
2021-06-02 17:20   ` Rob Herring
2021-06-02 17:20     ` Rob Herring
2021-06-03 12:26     ` Chun-Jie Chen
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   ` Chun-Jie Chen
2021-05-24 12:20   ` 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   ` Chun-Jie Chen
2021-05-24 12:20   ` 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   ` Chun-Jie Chen
2021-05-24 12:20   ` 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   ` Chun-Jie Chen
2021-05-24 12:20   ` 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   ` Chun-Jie Chen
2021-05-24 12:20   ` 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   ` Chun-Jie Chen
2021-05-24 12:20   ` 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   ` Chun-Jie Chen
2021-05-24 12:20   ` 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   ` Chun-Jie Chen
2021-05-24 12:20   ` 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   ` Chun-Jie Chen
2021-05-24 12:20   ` 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   ` Chun-Jie Chen
2021-05-24 12:20   ` 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   ` Chun-Jie Chen
2021-05-24 12:20   ` 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   ` Chun-Jie Chen
2021-05-24 12:20   ` Chun-Jie Chen
2021-05-24 12:20 ` [PATCH v9 18/22] clk: mediatek: Add MT8192 mmsys " Chun-Jie Chen
2021-05-24 12:20   ` Chun-Jie Chen
2021-05-24 12:20   ` Chun-Jie Chen
2021-06-08 14:44   ` Matthias Brugger
2021-06-08 14:44     ` Matthias Brugger
2021-06-08 14:44     ` Matthias Brugger
2021-06-08 22:38     ` Chun-Jie Chen
2021-06-08 22:38       ` Chun-Jie Chen
2021-06-09  8:08       ` Matthias Brugger
2021-06-09  8:08         ` Matthias Brugger
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   ` Chun-Jie Chen
2021-05-24 12:20   ` 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   ` Chun-Jie Chen
2021-05-24 12:20   ` 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   ` Chun-Jie Chen
2021-05-24 12:20   ` Chun-Jie Chen
2021-05-24 12:20 ` [PATCH v9 22/22] clk: mediatek: Add MT8192 vencsys " Chun-Jie Chen
2021-05-24 12:20   ` Chun-Jie Chen
2021-05-24 12:20   ` 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=CAGXv+5HcV6jbyDdZGzRX-2NHMztSONBKxmLxLQX6k+aQrwJ1ww@mail.gmail.com \
    --to=wenst@chromium.org \
    --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=matthias.bgg@gmail.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.