All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@kernel.org>
To: "A.s. Dong" <aisheng.dong@nxp.com>,
	"linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>
Cc: "linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"mturquette@baylibre.com" <mturquette@baylibre.com>,
	"shawnguo@kernel.org" <shawnguo@kernel.org>,
	Fabio Estevam <fabio.estevam@nxp.com>,
	dl-linux-imx <linux-imx@nxp.com>,
	"kernel@pengutronix.de" <kernel@pengutronix.de>
Subject: RE: [PATCH V5 9/9] clk: imx: add imx8qxp clk driver
Date: Wed, 14 Nov 2018 15:23:46 -0800	[thread overview]
Message-ID: <154223782682.88331.13160210691831603996@swboyd.mtv.corp.google.com> (raw)
In-Reply-To: <AM0PR04MB42115A499619B6D650C9728480C70@AM0PR04MB4211.eurprd04.prod.outlook.com>

Quoting A.s. Dong (2018-11-10 07:58:00)
> Hi Stephen,
> 
> [...]
> > > > > Where's the DT binding for this device?
> > > >
> > > > Sorry for missed to mention this.
> > > > It's been merged into scu binding doc per Rob's request which has
> > > > already been in Shawn's tree.
> > > >
> > > > Please take a look at here:
> > [...]
> > >
> > > Ok I ask because it's odd to hardcode physical addresses in a clk
> > > driver when those should come from DT in reg properties. Was Rob aware
> > > that this clk node was combining I/O memory and message passing?
> > 
> > Yes, I agree with you. That seems like a special to i.MX case.
> > The problem is not all clocks having a LPCG gate. And those LPCGs are also not
> > continuous and may be shared by many clocks which make things more
> > complicated.
> > I'm not sure parsing from device tree could be better way to do it.
> > Probably need huge changes.
> > 
> 
> I reorganized the driver a lot to address this issue.
> See:
> https://patchwork.kernel.org/cover/10677275/
> We now have a new LPCG clock type and retrieve the LPCG physical
> address from device tree.
> 
> Besides that, as LPCG is moved out from the original SCU gate clocks,
> We have a chance to merge all three type of SCU clocks (divider/gate/mux)
> together into a general SCU clock. (new API introduced imx_clk_scu()).
> Thus, the consumer driver is also simplied a lot which looks better than before.
> Hopefully this can make you happy.
> Please help review that new version.
> 

Ok I'll take a look at the new patch series.


WARNING: multiple messages have this Message-ID (diff)
From: sboyd@kernel.org (Stephen Boyd)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V5 9/9] clk: imx: add imx8qxp clk driver
Date: Wed, 14 Nov 2018 15:23:46 -0800	[thread overview]
Message-ID: <154223782682.88331.13160210691831603996@swboyd.mtv.corp.google.com> (raw)
In-Reply-To: <AM0PR04MB42115A499619B6D650C9728480C70@AM0PR04MB4211.eurprd04.prod.outlook.com>

Quoting A.s. Dong (2018-11-10 07:58:00)
> Hi Stephen,
> 
> [...]
> > > > > Where's the DT binding for this device?
> > > >
> > > > Sorry for missed to mention this.
> > > > It's been merged into scu binding doc per Rob's request which has
> > > > already been in Shawn's tree.
> > > >
> > > > Please take a look at here:
> > [...]
> > >
> > > Ok I ask because it's odd to hardcode physical addresses in a clk
> > > driver when those should come from DT in reg properties. Was Rob aware
> > > that this clk node was combining I/O memory and message passing?
> > 
> > Yes, I agree with you. That seems like a special to i.MX case.
> > The problem is not all clocks having a LPCG gate. And those LPCGs are also not
> > continuous and may be shared by many clocks which make things more
> > complicated.
> > I'm not sure parsing from device tree could be better way to do it.
> > Probably need huge changes.
> > 
> 
> I reorganized the driver a lot to address this issue.
> See:
> https://patchwork.kernel.org/cover/10677275/
> We now have a new LPCG clock type and retrieve the LPCG physical
> address from device tree.
> 
> Besides that, as LPCG is moved out from the original SCU gate clocks,
> We have a chance to merge all three type of SCU clocks (divider/gate/mux)
> together into a general SCU clock. (new API introduced imx_clk_scu()).
> Thus, the consumer driver is also simplied a lot which looks better than before.
> Hopefully this can make you happy.
> Please help review that new version.
> 

Ok I'll take a look at the new patch series.

  reply	other threads:[~2018-11-14 23:23 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-18 16:53 [PATCH V5 0/9] clk: imx: add imx8qxp clock support A.s. Dong
2018-10-18 16:53 ` A.s. Dong
2018-10-18 16:53 ` [PATCH V5 1/9] clk: imx: add configuration option for mmio clks A.s. Dong
2018-10-18 16:53   ` A.s. Dong
2018-10-18 16:53 ` [PATCH V5 2/9] clk: imx: scu: add scu clock common part A.s. Dong
2018-10-18 16:53   ` A.s. Dong
2018-10-18 16:53 ` [PATCH V5 3/9] clk: imx: scu: add scu clock divider A.s. Dong
2018-10-18 16:53   ` A.s. Dong
2018-10-18 16:53 ` [PATCH V5 4/9] clk: imx: scu: add scu clock gpr divider A.s. Dong
2018-10-18 16:53   ` A.s. Dong
2018-10-18 16:54 ` [PATCH V5 5/9] clk: imx: scu: add scu clock gate A.s. Dong
2018-10-18 16:54   ` A.s. Dong
2018-10-18 16:54 ` [PATCH V5 6/9] clk: imx: scu: add scu clock gpr gate A.s. Dong
2018-10-18 16:54   ` A.s. Dong
2018-10-18 16:54 ` [PATCH V5 7/9] clk: imx: scu: add scu clock mux A.s. Dong
2018-10-18 16:54   ` A.s. Dong
2018-10-18 16:54 ` [PATCH V5 8/9] clk: imx: scu: add scu clock gpr mux A.s. Dong
2018-10-18 16:54   ` A.s. Dong
2018-10-18 16:54 ` [PATCH V5 9/9] clk: imx: add imx8qxp clk driver A.s. Dong
2018-10-18 16:54   ` A.s. Dong
2018-10-18 17:38   ` Stephen Boyd
2018-10-18 17:38     ` Stephen Boyd
2018-10-18 18:13     ` A.s. Dong
2018-10-18 18:13       ` A.s. Dong
2018-10-18 20:46       ` Stephen Boyd
2018-10-18 20:46         ` Stephen Boyd
2018-10-19  9:05         ` A.s. Dong
2018-10-19  9:05           ` A.s. Dong
2018-10-25 14:43           ` A.s. Dong
2018-10-25 14:43             ` A.s. Dong
2018-11-10 15:58           ` A.s. Dong
2018-11-10 15:58             ` A.s. Dong
2018-11-14 23:23             ` Stephen Boyd [this message]
2018-11-14 23:23               ` Stephen Boyd

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=154223782682.88331.13160210691831603996@swboyd.mtv.corp.google.com \
    --to=sboyd@kernel.org \
    --cc=aisheng.dong@nxp.com \
    --cc=fabio.estevam@nxp.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-imx@nxp.com \
    --cc=mturquette@baylibre.com \
    --cc=shawnguo@kernel.org \
    /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.