[V12,0/5] clk: imx: add imx8qxp clock support

Message ID	1544715442-8902-1-git-send-email-aisheng.dong@nxp.com (mailing list archive)
Headers	show Return-Path: <linux-clk-owner@kernel.org> From: Aisheng Dong <aisheng.dong@nxp.com> To: "linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org> CC: "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "sboyd@kernel.org" <sboyd@kernel.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>, Aisheng Dong <aisheng.dong@nxp.com> Subject: [PATCH V12 0/5] clk: imx: add imx8qxp clock support Thread-Topic: [PATCH V12 0/5] clk: imx: add imx8qxp clock support Thread-Index: AQHUkvp+2I/kA9Gq1kKYOSfh1d+qug== Date: Thu, 13 Dec 2018 15:42:46 +0000 Message-ID: <1544715442-8902-1-git-send-email-aisheng.dong@nxp.com> Accept-Language: zh-CN, en-US Content-Language: en-US received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: VsN9S7LWz8g0eP/CkZcy+4qj8b/WsLYcglhwqWmEE0phyEH+NUkI1ebwdYTcdTCmJ9hSIzY7GZg+Vya/s1watdnDN28XpOhz/oS3P90ZdhzRBGWPHyoAiUp178cAJ2UAZmdxFRWI8V6lXjf0s4QHr0m8iqumZiiWAKQOS6xZxfZjeG86exZE3RUmtagE0WiYYqBGb7heFEdFwLfaTK0yFYbptf52tf/9Me8KYaN6AacmdqoZUiZvrqMuWDkZJ5osNyF7Fbpz/xHXYBIOcfq/6j9THOgpXdJc62KvqPhvp5HO3bd3auaEu8wg6m0JLGYm spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: linux-clk-owner@vger.kernel.org Precedence: bulk
Series	clk: imx: add imx8qxp clock support \| expand [V12,0/5] clk: imx: add imx8qxp clock support [V12,1/5] clk: imx: add configuration option for mmio clks [V12,2/5] clk: imx: add scu clock common part [V12,3/5] clk: imx: add imx8qxp clk driver [V12,4/5] clk: imx: add lpcg clock support [V12,5/5] clk: imx: add imx8qxp lpcg driver

Aisheng Dong Dec. 13, 2018, 3:42 p.m. UTC

This patch series adds i.MX8QXP clock support which is based
on the clock service provided by SCU firmware.

Note: It depends on SCU driver which has already been merged by Shawn.
So this patch series could go through Shawn's tree as well.

ChangeLog:
v11->v12:
 * remove the dependency of SOC_IMX8QXP which will be deleted later
 * MXC_CLK_SCU depends on IMX_SCU
 * dropped dt-binding patches which has already been merged by Stephen
v10->v11:
 * break dependency on the arch Kconfig
v9->v10:
 * a small clean up of PATCH 2
   remove ccm_ipc_handle from headfile as no other users need it now
   and move imx_clk_scu_init() implementation into driver accordingly.
 * a typo fix of Patch 10
v8->v9:
 * add __le32 and __le16 for SCU message structure members as it's little endian
 * use readl_relaxed() as it does not need insert barrier
 * a small code logic improvement suggested by Stephen
v7->v8:
 * add more kernel doc for lpcg and scu clock structures
 * remove one unneccessry reg checking
v6->v7:
 * use struct_size()
 * remove MODULE_ macros
 * add more kernel docs/code comments
 * other small improvements
 * update reviewed-by tags
 * add the missing PATCH 1 in V6
v5->v6:
 * simply the driver a lot by re-orgnizing the driver into a few clock types:
   scu clock (merge scu divider/gate/mux) and scu gpr lock which accessing is
   through SCU protocol and LPCG clock which is directly accessible by CPU.
 * LPCG clock is separate from SCU clock, gpr clock is still not used
   and will be added later.
 * remove old year license as the code is totally rewritten
 * scu mux support will be added later as it's also still not used.
v4->v5:
 Address all Stephen and Sascha's review comments, see details in each patch
v3->v4:
 * scu headfile path update
 * no functionality change
v2->v3:
 * structures/enums name update with imx_sc prefix
 * no functionality change
v1->v2:
 * structure and enums name update
 * api usage update due to api change
 * no functionality change



Dong Aisheng (5):
  clk: imx: add configuration option for mmio clks
  clk: imx: add scu clock common part
  clk: imx: add imx8qxp clk driver
  clk: imx: add lpcg clock support
  clk: imx: add imx8qxp lpcg driver

 drivers/clk/Kconfig                |   1 +
 drivers/clk/Makefile               |   2 +-
 drivers/clk/imx/Kconfig            |  16 +++
 drivers/clk/imx/Makefile           |   8 +-
 drivers/clk/imx/clk-imx8qxp-lpcg.c | 216 +++++++++++++++++++++++++++++
 drivers/clk/imx/clk-imx8qxp-lpcg.h | 102 ++++++++++++++
 drivers/clk/imx/clk-imx8qxp.c      | 153 +++++++++++++++++++++
 drivers/clk/imx/clk-lpcg-scu.c     | 114 ++++++++++++++++
 drivers/clk/imx/clk-scu.c          | 270 +++++++++++++++++++++++++++++++++++++
 drivers/clk/imx/clk-scu.h          |  18 +++
 10 files changed, 898 insertions(+), 2 deletions(-)
 create mode 100644 drivers/clk/imx/Kconfig
 create mode 100644 drivers/clk/imx/clk-imx8qxp-lpcg.c
 create mode 100644 drivers/clk/imx/clk-imx8qxp-lpcg.h
 create mode 100644 drivers/clk/imx/clk-imx8qxp.c
 create mode 100644 drivers/clk/imx/clk-lpcg-scu.c
 create mode 100644 drivers/clk/imx/clk-scu.c
 create mode 100644 drivers/clk/imx/clk-scu.h

Shawn Guo Dec. 14, 2018, 2:05 a.m. UTC | #1

On Thu, Dec 13, 2018 at 03:42:46PM +0000, Aisheng Dong wrote:
> This patch series adds i.MX8QXP clock support which is based
> on the clock service provided by SCU firmware.
> 
> Note: It depends on SCU driver which has already been merged by Shawn.
> So this patch series could go through Shawn's tree as well.

To be clear, I'm not going to take this via my tree, and it definitely
needs to go through clk tree.  If there is a dependency on my tree, you
will likely need to wait for the dependency to land on mainline and then
retry.

Shawn

Aisheng Dong Dec. 14, 2018, 2:17 a.m. UTC | #2

[...]
> > Note: It depends on SCU driver which has already been merged by Shawn.
> > So this patch series could go through Shawn's tree as well.
> 
> To be clear, I'm not going to take this via my tree, and it definitely needs to go
> through clk tree.  If there is a dependency on my tree, you will likely need to
> wait for the dependency to land on mainline and then retry.
> 

Sorry, I should have corrected that comment.
It's not depend on SCU driver which is already in the Stephen's tree.
It actually depends on the resource ID definitions[1] and the centralized PM
related service definitions headifle in in power domain series which is already
in your tree.

1. https://patchwork.kernel.org/patch/10664125/
2. https://patchwork.kernel.org/patch/10664137/

[2] can be fixed by defining them in clock driver.
But [1] seems can't be fixed as resource ID is shared by power domain
and possible many other SCU client drivers.

Any suggestion?

Regards
Dong Aisheng

> Shawn

Shawn Guo Dec. 14, 2018, 3:19 a.m. UTC | #3

On Fri, Dec 14, 2018 at 02:17:04AM +0000, Aisheng Dong wrote:
> [...]
> > > Note: It depends on SCU driver which has already been merged by Shawn.
> > > So this patch series could go through Shawn's tree as well.
> > 
> > To be clear, I'm not going to take this via my tree, and it definitely needs to go
> > through clk tree.  If there is a dependency on my tree, you will likely need to
> > wait for the dependency to land on mainline and then retry.
> > 
> 
> Sorry, I should have corrected that comment.
> It's not depend on SCU driver which is already in the Stephen's tree.
> It actually depends on the resource ID definitions[1] and the centralized PM
> related service definitions headifle in in power domain series which is already
> in your tree.
> 
> 1. https://patchwork.kernel.org/patch/10664125/
> 2. https://patchwork.kernel.org/patch/10664137/
> 
> [2] can be fixed by defining them in clock driver.
> But [1] seems can't be fixed as resource ID is shared by power domain
> and possible many other SCU client drivers.
> 
> Any suggestion?

After [1] and [2] land on v4.21-rc1, you rebase the series on that.  The
dependency will be gone, right?  This is what I suggested above.

Shawn

Aisheng Dong Dec. 14, 2018, 3:37 a.m. UTC | #4

> -----Original Message-----
> From: Shawn Guo [mailto:shawnguo@kernel.org]
> On Fri, Dec 14, 2018 at 02:17:04AM +0000, Aisheng Dong wrote:
> > [...]
> > > > Note: It depends on SCU driver which has already been merged by
> Shawn.
> > > > So this patch series could go through Shawn's tree as well.
> > >
> > > To be clear, I'm not going to take this via my tree, and it
> > > definitely needs to go through clk tree.  If there is a dependency
> > > on my tree, you will likely need to wait for the dependency to land on
> mainline and then retry.
> > >
> >
> > Sorry, I should have corrected that comment.
> > It's not depend on SCU driver which is already in the Stephen's tree.
> > It actually depends on the resource ID definitions[1] and the
> > centralized PM related service definitions headifle in in power domain
> > series which is already in your tree.
> >
> > [2] can be fixed by defining them in clock driver.
> > But [1] seems can't be fixed as resource ID is shared by power domain
> > and possible many other SCU client drivers.
> >
> > Any suggestion?
> 
> After [1] and [2] land on v4.21-rc1, you rebase the series on that.  The
> dependency will be gone, right?  This is what I suggested above.
> 

Okay, that may need a few more weeks.
BTW, after v4.21-rc1 is out, can the mx8qxp CLK and DTS hit the final v4.21 release?
As I understand, usually we don't receive new feature patch after the first RC,
right?

Regards
Dong Aisheng

> Shawn

Shawn Guo Dec. 14, 2018, 3:56 a.m. UTC | #5

On Fri, Dec 14, 2018 at 03:37:47AM +0000, Aisheng Dong wrote:
> > -----Original Message-----
> > From: Shawn Guo [mailto:shawnguo@kernel.org]
> > On Fri, Dec 14, 2018 at 02:17:04AM +0000, Aisheng Dong wrote:
> > > [...]
> > > > > Note: It depends on SCU driver which has already been merged by
> > Shawn.
> > > > > So this patch series could go through Shawn's tree as well.
> > > >
> > > > To be clear, I'm not going to take this via my tree, and it
> > > > definitely needs to go through clk tree.  If there is a dependency
> > > > on my tree, you will likely need to wait for the dependency to land on
> > mainline and then retry.
> > > >
> > >
> > > Sorry, I should have corrected that comment.
> > > It's not depend on SCU driver which is already in the Stephen's tree.
> > > It actually depends on the resource ID definitions[1] and the
> > > centralized PM related service definitions headifle in in power domain
> > > series which is already in your tree.
> > >
> > > [2] can be fixed by defining them in clock driver.
> > > But [1] seems can't be fixed as resource ID is shared by power domain
> > > and possible many other SCU client drivers.
> > >
> > > Any suggestion?
> > 
> > After [1] and [2] land on v4.21-rc1, you rebase the series on that.  The
> > dependency will be gone, right?  This is what I suggested above.
> > 
> 
> Okay, that may need a few more weeks.
> BTW, after v4.21-rc1 is out, can the mx8qxp CLK and DTS hit the final v4.21 release?
> As I understand, usually we don't receive new feature patch after the first RC,
> right?

Yes, they will have to land on 4.22 then.

Shawn

Aisheng Dong Dec. 14, 2018, 4:57 a.m. UTC | #6

> -----Original Message-----
> From: Shawn Guo [mailto:shawnguo@kernel.org]
> On Fri, Dec 14, 2018 at 03:37:47AM +0000, Aisheng Dong wrote:
> > > -----Original Message-----
> > > From: Shawn Guo [mailto:shawnguo@kernel.org] On Fri, Dec 14, 2018 at
> > > 02:17:04AM +0000, Aisheng Dong wrote:
> > > > [...]
> > > > > > Note: It depends on SCU driver which has already been merged
> > > > > > by
> > > Shawn.
> > > > > > So this patch series could go through Shawn's tree as well.
> > > > >
> > > > > To be clear, I'm not going to take this via my tree, and it
> > > > > definitely needs to go through clk tree.  If there is a
> > > > > dependency on my tree, you will likely need to wait for the
> > > > > dependency to land on
> > > mainline and then retry.
> > > > >
> > > >
> > > > Sorry, I should have corrected that comment.
> > > > It's not depend on SCU driver which is already in the Stephen's tree.
> > > > It actually depends on the resource ID definitions[1] and the
> > > > centralized PM related service definitions headifle in in power
> > > > domain series which is already in your tree.
> > > >
> > > > [2] can be fixed by defining them in clock driver.
> > > > But [1] seems can't be fixed as resource ID is shared by power
> > > > domain and possible many other SCU client drivers.
> > > >
> > > > Any suggestion?
> > >
> > > After [1] and [2] land on v4.21-rc1, you rebase the series on that.
> > > The dependency will be gone, right?  This is what I suggested above.
> > >
> >
> > Okay, that may need a few more weeks.
> > BTW, after v4.21-rc1 is out, can the mx8qxp CLK and DTS hit the final v4.21
> release?
> > As I understand, usually we don't receive new feature patch after the
> > first RC, right?
> 
> Yes, they will have to land on 4.22 then.

That's unfortunately and may need wait 3 more months.
I really wish we can hit v4.21-rc1, then other modules driver can start
their work based on it.

Stephen,
What's your option?

Can we try the same way as Shawn did for arch and dts part?

Regards
Dong Aisheng

> 
> Shawn

Shawn Guo Dec. 14, 2018, 5:30 a.m. UTC | #7

On Fri, Dec 14, 2018 at 04:57:46AM +0000, Aisheng Dong wrote:
> > -----Original Message-----
> > From: Shawn Guo [mailto:shawnguo@kernel.org]
> > On Fri, Dec 14, 2018 at 03:37:47AM +0000, Aisheng Dong wrote:
> > > > -----Original Message-----
> > > > From: Shawn Guo [mailto:shawnguo@kernel.org] On Fri, Dec 14, 2018 at
> > > > 02:17:04AM +0000, Aisheng Dong wrote:
> > > > > [...]
> > > > > > > Note: It depends on SCU driver which has already been merged
> > > > > > > by
> > > > Shawn.
> > > > > > > So this patch series could go through Shawn's tree as well.
> > > > > >
> > > > > > To be clear, I'm not going to take this via my tree, and it
> > > > > > definitely needs to go through clk tree.  If there is a
> > > > > > dependency on my tree, you will likely need to wait for the
> > > > > > dependency to land on
> > > > mainline and then retry.
> > > > > >
> > > > >
> > > > > Sorry, I should have corrected that comment.
> > > > > It's not depend on SCU driver which is already in the Stephen's tree.
> > > > > It actually depends on the resource ID definitions[1] and the
> > > > > centralized PM related service definitions headifle in in power
> > > > > domain series which is already in your tree.
> > > > >
> > > > > [2] can be fixed by defining them in clock driver.
> > > > > But [1] seems can't be fixed as resource ID is shared by power
> > > > > domain and possible many other SCU client drivers.
> > > > >
> > > > > Any suggestion?
> > > >
> > > > After [1] and [2] land on v4.21-rc1, you rebase the series on that.
> > > > The dependency will be gone, right?  This is what I suggested above.
> > > >
> > >
> > > Okay, that may need a few more weeks.
> > > BTW, after v4.21-rc1 is out, can the mx8qxp CLK and DTS hit the final v4.21
> > release?
> > > As I understand, usually we don't receive new feature patch after the
> > > first RC, right?
> > 
> > Yes, they will have to land on 4.22 then.
> 
> That's unfortunately and may need wait 3 more months.
> I really wish we can hit v4.21-rc1, then other modules driver can start
> their work based on it.

You can not always expect all the pieces get in with one merge window.
It's very usual in upstreaming process that the dependant parts lands in
mainline with multiple release cycles.

> Stephen,
> What's your option?
> 
> Can we try the same way as Shawn did for arch and dts part?

In case Stephen is fine by pulling dependency from my tree, it's all on
branch below, which has been pulled/queued by arm-soc folks for 4.21
merge window.

 git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git imx/drivers

Shawn

Aisheng Dong Dec. 14, 2018, 5:38 a.m. UTC | #8

> -----Original Message-----
> From: Shawn Guo [mailto:shawnguo@kernel.org]
> On Fri, Dec 14, 2018 at 04:57:46AM +0000, Aisheng Dong wrote:
> > > -----Original Message-----
> > > From: Shawn Guo [mailto:shawnguo@kernel.org] On Fri, Dec 14, 2018 at
> > > 03:37:47AM +0000, Aisheng Dong wrote:
> > > > > -----Original Message-----
> > > > > From: Shawn Guo [mailto:shawnguo@kernel.org] On Fri, Dec 14,
> > > > > 2018 at 02:17:04AM +0000, Aisheng Dong wrote:
> > > > > > [...]
> > > > > > > > Note: It depends on SCU driver which has already been
> > > > > > > > merged by
> > > > > Shawn.
> > > > > > > > So this patch series could go through Shawn's tree as well.
> > > > > > >
> > > > > > > To be clear, I'm not going to take this via my tree, and it
> > > > > > > definitely needs to go through clk tree.  If there is a
> > > > > > > dependency on my tree, you will likely need to wait for the
> > > > > > > dependency to land on
> > > > > mainline and then retry.
> > > > > > >
> > > > > >
> > > > > > Sorry, I should have corrected that comment.
> > > > > > It's not depend on SCU driver which is already in the Stephen's tree.
> > > > > > It actually depends on the resource ID definitions[1] and the
> > > > > > centralized PM related service definitions headifle in in
> > > > > > power domain series which is already in your tree.
> > > > > >
> > > > > > [2] can be fixed by defining them in clock driver.
> > > > > > But [1] seems can't be fixed as resource ID is shared by power
> > > > > > domain and possible many other SCU client drivers.
> > > > > >
> > > > > > Any suggestion?
> > > > >
> > > > > After [1] and [2] land on v4.21-rc1, you rebase the series on that.
> > > > > The dependency will be gone, right?  This is what I suggested above.
> > > > >
> > > >
> > > > Okay, that may need a few more weeks.
> > > > BTW, after v4.21-rc1 is out, can the mx8qxp CLK and DTS hit the
> > > > final v4.21
> > > release?
> > > > As I understand, usually we don't receive new feature patch after
> > > > the first RC, right?
> > >
> > > Yes, they will have to land on 4.22 then.
> >
> > That's unfortunately and may need wait 3 more months.
> > I really wish we can hit v4.21-rc1, then other modules driver can
> > start their work based on it.
> 
> You can not always expect all the pieces get in with one merge window.
> It's very usual in upstreaming process that the dependant parts lands in
> mainline with multiple release cycles.
> 

Yes, i understand.
Thanks for the clarification.

> > Stephen,
> > What's your option?
> >
> > Can we try the same way as Shawn did for arch and dts part?
> 
> In case Stephen is fine by pulling dependency from my tree, it's all on branch
> below, which has been pulled/queued by arm-soc folks for 4.21 merge window.
> 
>  git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git imx/drivers
> 

Thanks

Regards
Dong Aisheng

> Shawn

Stephen Boyd Dec. 14, 2018, 5:44 a.m. UTC | #9

Quoting Aisheng Dong (2018-12-13 20:57:46)
> > -----Original Message-----
> > From: Shawn Guo [mailto:shawnguo@kernel.org]
> > On Fri, Dec 14, 2018 at 03:37:47AM +0000, Aisheng Dong wrote:
> > > > -----Original Message-----
> > > > From: Shawn Guo [mailto:shawnguo@kernel.org] On Fri, Dec 14, 2018 at
> > > > 02:17:04AM +0000, Aisheng Dong wrote:
> > > > > [...]
> > > > > > > Note: It depends on SCU driver which has already been merged
> > > > > > > by
> > > > Shawn.
> > > > > > > So this patch series could go through Shawn's tree as well.
> > > > > >
> > > > > > To be clear, I'm not going to take this via my tree, and it
> > > > > > definitely needs to go through clk tree.  If there is a
> > > > > > dependency on my tree, you will likely need to wait for the
> > > > > > dependency to land on
> > > > mainline and then retry.
> > > > > >
> > > > >
> > > > > Sorry, I should have corrected that comment.
> > > > > It's not depend on SCU driver which is already in the Stephen's tree.
> > > > > It actually depends on the resource ID definitions[1] and the
> > > > > centralized PM related service definitions headifle in in power
> > > > > domain series which is already in your tree.
> > > > >
> > > > > [2] can be fixed by defining them in clock driver.
> > > > > But [1] seems can't be fixed as resource ID is shared by power
> > > > > domain and possible many other SCU client drivers.
> > > > >
> > > > > Any suggestion?
> > > >
> > > > After [1] and [2] land on v4.21-rc1, you rebase the series on that.
> > > > The dependency will be gone, right?  This is what I suggested above.
> > > >
> > >
> > > Okay, that may need a few more weeks.
> > > BTW, after v4.21-rc1 is out, can the mx8qxp CLK and DTS hit the final v4.21
> > release?
> > > As I understand, usually we don't receive new feature patch after the
> > > first RC, right?
> > 
> > Yes, they will have to land on 4.22 then.
> 
> That's unfortunately and may need wait 3 more months.
> I really wish we can hit v4.21-rc1, then other modules driver can start
> their work based on it.
> 
> Stephen,
> What's your option?
> 
> Can we try the same way as Shawn did for arch and dts part?
> 

I see some options:

	1. Shawn can provide the required header files in some signed
	tag that I can pull into clk tree and then apply these patches
	on top and merge it all up into clk-next.

	2. I can pick any patches required for the header files the clk
	driver needs into clk tree and duplicate the commits in Shawn's
	tree. I don't see a big downside here, git manages just fine
	when it sees duplicate content on both sides of a merge so it's
	just more noise than anything else.

	3. I apply the clk driver bits but nobody tries to enable the
	config option around it just yet. Instead, we wait for
	everything to meet up in linux-next via different trees and then
	enable compilation later. This is bad for compile testing
	drivers and makes it harder to bisect problems later. Probably
	not a big deal here for bringing in new hardware support but it
	might work out.

	4. We all wait three months (happy new year!) but otherwise are
	sad that we can't figure this out.

Stephen Boyd Dec. 14, 2018, 6:07 a.m. UTC | #10

Quoting Shawn Guo (2018-12-13 21:30:35)
> 
> In case Stephen is fine by pulling dependency from my tree, it's all on
> branch below, which has been pulled/queued by arm-soc folks for 4.21
> merge window.
> 
>  git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git imx/drivers
> 

I can pull just the first patch from this branch and then everything
will compile? That should be OK.

Stephen Boyd Dec. 14, 2018, 6:15 a.m. UTC | #11

Quoting Stephen Boyd (2018-12-13 22:07:08)
> Quoting Shawn Guo (2018-12-13 21:30:35)
> > 
> > In case Stephen is fine by pulling dependency from my tree, it's all on
> > branch below, which has been pulled/queued by arm-soc folks for 4.21
> > merge window.
> > 
> >  git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git imx/drivers
> > 
> 
> I can pull just the first patch from this branch and then everything
> will compile? That should be OK.
> 

Hm.. turns out I need to pull up to

0a914a4948d4 firmware: imx: add pm svc headfile

but then it all compiles fine. Ok I can do that.

Aisheng Dong Dec. 14, 2018, 6:15 a.m. UTC | #12

> From: Stephen Boyd [mailto:sboyd@kernel.org]
> Quoting Shawn Guo (2018-12-13 21:30:35)
> >
> > In case Stephen is fine by pulling dependency from my tree, it's all
> > on branch below, which has been pulled/queued by arm-soc folks for
> > 4.21 merge window.
> >
> >  git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git
> > imx/drivers
> >
> 
> I can pull just the first patch from this branch and then everything will compile?
> That should be OK.

It also needs the 4th patch "firmware: imx: add pm svc headfile".
But I can copy the required definitions into clk driver and clean up the original one later
after merge if you think it's ok.

Regards
Dong Aisheng

Aisheng Dong Dec. 14, 2018, 6:16 a.m. UTC | #13

> -----Original Message-----
> From: Stephen Boyd [mailto:sboyd@kernel.org]
> Quoting Stephen Boyd (2018-12-13 22:07:08)
> > Quoting Shawn Guo (2018-12-13 21:30:35)
> > >
> > > In case Stephen is fine by pulling dependency from my tree, it's all
> > > on branch below, which has been pulled/queued by arm-soc folks for
> > > 4.21 merge window.
> > >
> > >  git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git
> > > imx/drivers
> > >
> >
> > I can pull just the first patch from this branch and then everything
> > will compile? That should be OK.
> >
> 
> Hm.. turns out I need to pull up to
> 
> 0a914a4948d4 firmware: imx: add pm svc headfile
> 
> but then it all compiles fine. Ok I can do that.

Yes, it is.
Really appreciate for your kind help.

Regards
Dong Aisheng

[V12,0/5] clk: imx: add imx8qxp clock support

Message

Comments