| Message ID | 20131008143403.c11f294c8a1701a2ab3bc5fd@ops.dti.ne.jp (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | ef5ecd1f20de2d1919714f029f5016bf6d061e66 |
| Headers | show |
On Tue, Oct 8, 2013 at 2:34 PM, <takasi-y@ops.dti.ne.jp> wrote: > Use common clock framework version of clock > drivers/clk/shmobile/clk-emev2.c > instead of sh-clkfwk version > arch/arm/mach-shmobile/clock-emev2.c > when it is configured as a part of multi-platform. > > Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp> > --- > arch/arm/mach-shmobile/board-kzm9d-reference.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/arch/arm/mach-shmobile/board-kzm9d-reference.c b/arch/arm/mach-shmobile/board-kzm9d-reference.c > index 054d8d5..853003c 100644 > --- a/arch/arm/mach-shmobile/board-kzm9d-reference.c > +++ b/arch/arm/mach-shmobile/board-kzm9d-reference.c > @@ -20,15 +20,14 @@ > > #include <linux/init.h> > #include <linux/of_platform.h> > +#include <linux/clk-provider.h> > #include <mach/emev2.h> > #include <mach/common.h> > #include <asm/mach/arch.h> > > static void __init kzm9d_add_standard_devices(void) > { > - if (!IS_ENABLED(CONFIG_COMMON_CLK)) > - emev2_clock_init(); > - > + of_clk_init(NULL); Hi Yoshii-san, Thanks, this looks very good. It is the correct way now when renesas-devel-20131008 includes the following series: [PATCH 00/05] ARM: shmobile: KZM9D Multiplatform update Acked-by: Magnus Damm <damm@opensource.se> Cheers, / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Oct 08, 2013 at 02:34:03PM +0900, takasi-y@ops.dti.ne.jp wrote: > Use common clock framework version of clock > drivers/clk/shmobile/clk-emev2.c > instead of sh-clkfwk version > arch/arm/mach-shmobile/clock-emev2.c > when it is configured as a part of multi-platform. > > Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp> Thanks. I plan to add this patch to a new topic branch, topic/emev2-common-clock, in the renesas tree and queue it up from there for inclusion in mainline if/when the first patch of this series is accepted by Mike Turquette. -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Simon, On Wed, Oct 9, 2013 at 12:40 PM, Simon Horman <horms@verge.net.au> wrote: > On Tue, Oct 08, 2013 at 02:34:03PM +0900, takasi-y@ops.dti.ne.jp wrote: >> Use common clock framework version of clock >> drivers/clk/shmobile/clk-emev2.c >> instead of sh-clkfwk version >> arch/arm/mach-shmobile/clock-emev2.c >> when it is configured as a part of multi-platform. >> >> Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp> > > Thanks. > > I plan to add this patch to a new topic branch, > topic/emev2-common-clock, in the renesas tree and > queue it up from there for inclusion in mainline > if/when the first patch of this series is accepted > by Mike Turquette. Thanks for picking up patches, Simon. I think you can simply merge this patch after the following series: [PATCH 00/05] ARM: shmobile: KZM9D Multiplatform update There are no build time dependencies on patch 1 and 2 so this patch can be merged independently. Regarding run-time operation, the multiplatform series above makes KZM9D DT reference only build for multiplatform, and in such case CCF is required. So if you want to keep KZM9D DT reference working until Mike Turquette accepts the CCF bits, then I recommend you to wait with "[PATCH 00/05] ARM: shmobile: KZM9D Multiplatform update" until all EMEV2 CCF bits have been merged. Another way is to merge "[PATCH 00/05] ARM: shmobile: KZM9D Multiplatform update" before the EMEV2 CCF bits, but if so you may as well merge this patch as well IMO. This multiplatform-update-series-merge-before-CCF plan will result in untestable KZM9D DT reference until EMEV2 CCF is merged. Either way is fine with me. Cheers, / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Oct 09, 2013 at 01:59:46PM +0900, Magnus Damm wrote: > Hi Simon, > > On Wed, Oct 9, 2013 at 12:40 PM, Simon Horman <horms@verge.net.au> wrote: > > On Tue, Oct 08, 2013 at 02:34:03PM +0900, takasi-y@ops.dti.ne.jp wrote: > >> Use common clock framework version of clock > >> drivers/clk/shmobile/clk-emev2.c > >> instead of sh-clkfwk version > >> arch/arm/mach-shmobile/clock-emev2.c > >> when it is configured as a part of multi-platform. > >> > >> Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp> > > > > Thanks. > > > > I plan to add this patch to a new topic branch, > > topic/emev2-common-clock, in the renesas tree and > > queue it up from there for inclusion in mainline > > if/when the first patch of this series is accepted > > by Mike Turquette. > > Thanks for picking up patches, Simon. > > I think you can simply merge this patch after the following series: > > [PATCH 00/05] ARM: shmobile: KZM9D Multiplatform update This is already queued up. > There are no build time dependencies on patch 1 and 2 so this patch > can be merged independently. Regarding run-time operation, the > multiplatform series above makes KZM9D DT reference only build for > multiplatform, and in such case CCF is required. > > So if you want to keep KZM9D DT reference working until Mike Turquette > accepts the CCF bits, then I recommend you to wait with "[PATCH 00/05] > ARM: shmobile: KZM9D Multiplatform update" until all EMEV2 CCF bits > have been merged. > > Another way is to merge "[PATCH 00/05] ARM: shmobile: KZM9D > Multiplatform update" before the EMEV2 CCF bits, but if so you may as > well merge this patch as well IMO. This > multiplatform-update-series-merge-before-CCF plan will result in > untestable KZM9D DT reference until EMEV2 CCF is merged. Either way is > fine with me. I am mainly concerned that the bindings may change before they are finally merged. And I thought it would be nice to avoid having to fix up the usage of the bindings if they change. But I'm happy to just queue-up patches 2 and 3 of this series now if you prefer. -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Simon, On Wed, Oct 9, 2013 at 3:54 PM, Simon Horman <horms@verge.net.au> wrote: > On Wed, Oct 09, 2013 at 01:59:46PM +0900, Magnus Damm wrote: >> Hi Simon, >> >> On Wed, Oct 9, 2013 at 12:40 PM, Simon Horman <horms@verge.net.au> wrote: >> > On Tue, Oct 08, 2013 at 02:34:03PM +0900, takasi-y@ops.dti.ne.jp wrote: >> >> Use common clock framework version of clock >> >> drivers/clk/shmobile/clk-emev2.c >> >> instead of sh-clkfwk version >> >> arch/arm/mach-shmobile/clock-emev2.c >> >> when it is configured as a part of multi-platform. >> >> >> >> Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp> >> > >> > Thanks. >> > >> > I plan to add this patch to a new topic branch, >> > topic/emev2-common-clock, in the renesas tree and >> > queue it up from there for inclusion in mainline >> > if/when the first patch of this series is accepted >> > by Mike Turquette. >> >> Thanks for picking up patches, Simon. >> >> I think you can simply merge this patch after the following series: >> >> [PATCH 00/05] ARM: shmobile: KZM9D Multiplatform update > > This is already queued up. Yes, I know, thanks for that. I tried to explain the dependency in the 00/00 cover letter but I will try to be more clear next time! >> There are no build time dependencies on patch 1 and 2 so this patch >> can be merged independently. Regarding run-time operation, the >> multiplatform series above makes KZM9D DT reference only build for >> multiplatform, and in such case CCF is required. >> >> So if you want to keep KZM9D DT reference working until Mike Turquette >> accepts the CCF bits, then I recommend you to wait with "[PATCH 00/05] >> ARM: shmobile: KZM9D Multiplatform update" until all EMEV2 CCF bits >> have been merged. >> >> Another way is to merge "[PATCH 00/05] ARM: shmobile: KZM9D >> Multiplatform update" before the EMEV2 CCF bits, but if so you may as >> well merge this patch as well IMO. This >> multiplatform-update-series-merge-before-CCF plan will result in >> untestable KZM9D DT reference until EMEV2 CCF is merged. Either way is >> fine with me. > > I am mainly concerned that the bindings may change before > they are finally merged. And I thought it would be nice to avoid > having to fix up the usage of the bindings if they change. Sure, but the code in this patch looks like it simply starts DT CCF probing regardless of what the bindings look like. So I don't think you will have to worry about actual bindings detail. > But I'm happy to just queue-up patches 2 and 3 of this series > now if you prefer. Well, I meant patch 3 only. Patch 1 and 2 are tied together by dependencies. =) / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Oct 09, 2013 at 04:29:56PM +0900, Magnus Damm wrote: > Hi Simon, > > On Wed, Oct 9, 2013 at 3:54 PM, Simon Horman <horms@verge.net.au> wrote: > > On Wed, Oct 09, 2013 at 01:59:46PM +0900, Magnus Damm wrote: > >> Hi Simon, > >> > >> On Wed, Oct 9, 2013 at 12:40 PM, Simon Horman <horms@verge.net.au> wrote: > >> > On Tue, Oct 08, 2013 at 02:34:03PM +0900, takasi-y@ops.dti.ne.jp wrote: > >> >> Use common clock framework version of clock > >> >> drivers/clk/shmobile/clk-emev2.c > >> >> instead of sh-clkfwk version > >> >> arch/arm/mach-shmobile/clock-emev2.c > >> >> when it is configured as a part of multi-platform. > >> >> > >> >> Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp> > >> > > >> > Thanks. > >> > > >> > I plan to add this patch to a new topic branch, > >> > topic/emev2-common-clock, in the renesas tree and > >> > queue it up from there for inclusion in mainline > >> > if/when the first patch of this series is accepted > >> > by Mike Turquette. > >> > >> Thanks for picking up patches, Simon. > >> > >> I think you can simply merge this patch after the following series: > >> > >> [PATCH 00/05] ARM: shmobile: KZM9D Multiplatform update > > > > This is already queued up. > > Yes, I know, thanks for that. I tried to explain the dependency in the > 00/00 cover letter but I will try to be more clear next time! > > >> There are no build time dependencies on patch 1 and 2 so this patch > >> can be merged independently. Regarding run-time operation, the > >> multiplatform series above makes KZM9D DT reference only build for > >> multiplatform, and in such case CCF is required. > >> > >> So if you want to keep KZM9D DT reference working until Mike Turquette > >> accepts the CCF bits, then I recommend you to wait with "[PATCH 00/05] > >> ARM: shmobile: KZM9D Multiplatform update" until all EMEV2 CCF bits > >> have been merged. > >> > >> Another way is to merge "[PATCH 00/05] ARM: shmobile: KZM9D > >> Multiplatform update" before the EMEV2 CCF bits, but if so you may as > >> well merge this patch as well IMO. This > >> multiplatform-update-series-merge-before-CCF plan will result in > >> untestable KZM9D DT reference until EMEV2 CCF is merged. Either way is > >> fine with me. > > > > I am mainly concerned that the bindings may change before > > they are finally merged. And I thought it would be nice to avoid > > having to fix up the usage of the bindings if they change. > > Sure, but the code in this patch looks like it simply starts DT CCF > probing regardless of what the bindings look like. So I don't think > you will have to worry about actual bindings detail. > > > But I'm happy to just queue-up patches 2 and 3 of this series > > now if you prefer. > > Well, I meant patch 3 only. Patch 1 and 2 are tied together by dependencies. =) Thanks, I understand now. I'll queue-up 3/3. -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Oct 09, 2013 at 07:39:18PM +0900, Simon Horman wrote: > On Wed, Oct 09, 2013 at 04:29:56PM +0900, Magnus Damm wrote: > > Hi Simon, > > > > On Wed, Oct 9, 2013 at 3:54 PM, Simon Horman <horms@verge.net.au> wrote: > > > On Wed, Oct 09, 2013 at 01:59:46PM +0900, Magnus Damm wrote: > > >> Hi Simon, > > >> > > >> On Wed, Oct 9, 2013 at 12:40 PM, Simon Horman <horms@verge.net.au> wrote: > > >> > On Tue, Oct 08, 2013 at 02:34:03PM +0900, takasi-y@ops.dti.ne.jp wrote: > > >> >> Use common clock framework version of clock > > >> >> drivers/clk/shmobile/clk-emev2.c > > >> >> instead of sh-clkfwk version > > >> >> arch/arm/mach-shmobile/clock-emev2.c > > >> >> when it is configured as a part of multi-platform. > > >> >> > > >> >> Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp> > > >> > > > >> > Thanks. > > >> > > > >> > I plan to add this patch to a new topic branch, > > >> > topic/emev2-common-clock, in the renesas tree and > > >> > queue it up from there for inclusion in mainline > > >> > if/when the first patch of this series is accepted > > >> > by Mike Turquette. > > >> > > >> Thanks for picking up patches, Simon. > > >> > > >> I think you can simply merge this patch after the following series: > > >> > > >> [PATCH 00/05] ARM: shmobile: KZM9D Multiplatform update > > > > > > This is already queued up. > > > > Yes, I know, thanks for that. I tried to explain the dependency in the > > 00/00 cover letter but I will try to be more clear next time! > > > > >> There are no build time dependencies on patch 1 and 2 so this patch > > >> can be merged independently. Regarding run-time operation, the > > >> multiplatform series above makes KZM9D DT reference only build for > > >> multiplatform, and in such case CCF is required. > > >> > > >> So if you want to keep KZM9D DT reference working until Mike Turquette > > >> accepts the CCF bits, then I recommend you to wait with "[PATCH 00/05] > > >> ARM: shmobile: KZM9D Multiplatform update" until all EMEV2 CCF bits > > >> have been merged. > > >> > > >> Another way is to merge "[PATCH 00/05] ARM: shmobile: KZM9D > > >> Multiplatform update" before the EMEV2 CCF bits, but if so you may as > > >> well merge this patch as well IMO. This > > >> multiplatform-update-series-merge-before-CCF plan will result in > > >> untestable KZM9D DT reference until EMEV2 CCF is merged. Either way is > > >> fine with me. > > > > > > I am mainly concerned that the bindings may change before > > > they are finally merged. And I thought it would be nice to avoid > > > having to fix up the usage of the bindings if they change. > > > > Sure, but the code in this patch looks like it simply starts DT CCF > > probing regardless of what the bindings look like. So I don't think > > you will have to worry about actual bindings detail. > > > > > But I'm happy to just queue-up patches 2 and 3 of this series > > > now if you prefer. > > > > Well, I meant patch 3 only. Patch 1 and 2 are tied together by dependencies. =) > > Thanks, I understand now. > > I'll queue-up 3/3. Which I did. Then some time passed... Mike has accepted my pull-request for patch 1 of this series and accordingly I have queued-up this patch for v3.14. It should appear in the devel branch the next time that I push it. -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Oct 29, 2013 at 01:42:41PM +0900, Simon Horman wrote: > On Wed, Oct 09, 2013 at 07:39:18PM +0900, Simon Horman wrote: > > On Wed, Oct 09, 2013 at 04:29:56PM +0900, Magnus Damm wrote: > > > Hi Simon, > > > > > > On Wed, Oct 9, 2013 at 3:54 PM, Simon Horman <horms@verge.net.au> wrote: > > > > On Wed, Oct 09, 2013 at 01:59:46PM +0900, Magnus Damm wrote: > > > >> Hi Simon, > > > >> > > > >> On Wed, Oct 9, 2013 at 12:40 PM, Simon Horman <horms@verge.net.au> wrote: > > > >> > On Tue, Oct 08, 2013 at 02:34:03PM +0900, takasi-y@ops.dti.ne.jp wrote: > > > >> >> Use common clock framework version of clock > > > >> >> drivers/clk/shmobile/clk-emev2.c > > > >> >> instead of sh-clkfwk version > > > >> >> arch/arm/mach-shmobile/clock-emev2.c > > > >> >> when it is configured as a part of multi-platform. > > > >> >> > > > >> >> Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp> > > > >> > > > > >> > Thanks. > > > >> > > > > >> > I plan to add this patch to a new topic branch, > > > >> > topic/emev2-common-clock, in the renesas tree and > > > >> > queue it up from there for inclusion in mainline > > > >> > if/when the first patch of this series is accepted > > > >> > by Mike Turquette. > > > >> > > > >> Thanks for picking up patches, Simon. > > > >> > > > >> I think you can simply merge this patch after the following series: > > > >> > > > >> [PATCH 00/05] ARM: shmobile: KZM9D Multiplatform update > > > > > > > > This is already queued up. > > > > > > Yes, I know, thanks for that. I tried to explain the dependency in the > > > 00/00 cover letter but I will try to be more clear next time! > > > > > > >> There are no build time dependencies on patch 1 and 2 so this patch > > > >> can be merged independently. Regarding run-time operation, the > > > >> multiplatform series above makes KZM9D DT reference only build for > > > >> multiplatform, and in such case CCF is required. > > > >> > > > >> So if you want to keep KZM9D DT reference working until Mike Turquette > > > >> accepts the CCF bits, then I recommend you to wait with "[PATCH 00/05] > > > >> ARM: shmobile: KZM9D Multiplatform update" until all EMEV2 CCF bits > > > >> have been merged. > > > >> > > > >> Another way is to merge "[PATCH 00/05] ARM: shmobile: KZM9D > > > >> Multiplatform update" before the EMEV2 CCF bits, but if so you may as > > > >> well merge this patch as well IMO. This > > > >> multiplatform-update-series-merge-before-CCF plan will result in > > > >> untestable KZM9D DT reference until EMEV2 CCF is merged. Either way is > > > >> fine with me. > > > > > > > > I am mainly concerned that the bindings may change before > > > > they are finally merged. And I thought it would be nice to avoid > > > > having to fix up the usage of the bindings if they change. > > > > > > Sure, but the code in this patch looks like it simply starts DT CCF > > > probing regardless of what the bindings look like. So I don't think > > > you will have to worry about actual bindings detail. > > > > > > > But I'm happy to just queue-up patches 2 and 3 of this series > > > > now if you prefer. > > > > > > Well, I meant patch 3 only. Patch 1 and 2 are tied together by dependencies. =) > > > > Thanks, I understand now. > > > > I'll queue-up 3/3. > > Which I did. > > Then some time passed... > > Mike has accepted my pull-request for patch 1 of this series > and accordingly I have queued-up this patch for v3.14. > It should appear in the devel branch the next time that I push it. I was mistaken. It was not queued up for v3.14. And still has not been queued up. I have un-queued this patch accordingly. -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoting Simon Horman (2013-12-01 18:25:51) > On Tue, Oct 29, 2013 at 01:42:41PM +0900, Simon Horman wrote: > > On Wed, Oct 09, 2013 at 07:39:18PM +0900, Simon Horman wrote: > > > On Wed, Oct 09, 2013 at 04:29:56PM +0900, Magnus Damm wrote: > > > > Hi Simon, > > > > > > > > On Wed, Oct 9, 2013 at 3:54 PM, Simon Horman <horms@verge.net.au> wrote: > > > > > On Wed, Oct 09, 2013 at 01:59:46PM +0900, Magnus Damm wrote: > > > > >> Hi Simon, > > > > >> > > > > >> On Wed, Oct 9, 2013 at 12:40 PM, Simon Horman <horms@verge.net.au> wrote: > > > > >> > On Tue, Oct 08, 2013 at 02:34:03PM +0900, takasi-y@ops.dti.ne.jp wrote: > > > > >> >> Use common clock framework version of clock > > > > >> >> drivers/clk/shmobile/clk-emev2.c > > > > >> >> instead of sh-clkfwk version > > > > >> >> arch/arm/mach-shmobile/clock-emev2.c > > > > >> >> when it is configured as a part of multi-platform. > > > > >> >> > > > > >> >> Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp> > > > > >> > > > > > >> > Thanks. > > > > >> > > > > > >> > I plan to add this patch to a new topic branch, > > > > >> > topic/emev2-common-clock, in the renesas tree and > > > > >> > queue it up from there for inclusion in mainline > > > > >> > if/when the first patch of this series is accepted > > > > >> > by Mike Turquette. > > > > >> > > > > >> Thanks for picking up patches, Simon. > > > > >> > > > > >> I think you can simply merge this patch after the following series: > > > > >> > > > > >> [PATCH 00/05] ARM: shmobile: KZM9D Multiplatform update > > > > > > > > > > This is already queued up. > > > > > > > > Yes, I know, thanks for that. I tried to explain the dependency in the > > > > 00/00 cover letter but I will try to be more clear next time! > > > > > > > > >> There are no build time dependencies on patch 1 and 2 so this patch > > > > >> can be merged independently. Regarding run-time operation, the > > > > >> multiplatform series above makes KZM9D DT reference only build for > > > > >> multiplatform, and in such case CCF is required. > > > > >> > > > > >> So if you want to keep KZM9D DT reference working until Mike Turquette > > > > >> accepts the CCF bits, then I recommend you to wait with "[PATCH 00/05] > > > > >> ARM: shmobile: KZM9D Multiplatform update" until all EMEV2 CCF bits > > > > >> have been merged. > > > > >> > > > > >> Another way is to merge "[PATCH 00/05] ARM: shmobile: KZM9D > > > > >> Multiplatform update" before the EMEV2 CCF bits, but if so you may as > > > > >> well merge this patch as well IMO. This > > > > >> multiplatform-update-series-merge-before-CCF plan will result in > > > > >> untestable KZM9D DT reference until EMEV2 CCF is merged. Either way is > > > > >> fine with me. > > > > > > > > > > I am mainly concerned that the bindings may change before > > > > > they are finally merged. And I thought it would be nice to avoid > > > > > having to fix up the usage of the bindings if they change. > > > > > > > > Sure, but the code in this patch looks like it simply starts DT CCF > > > > probing regardless of what the bindings look like. So I don't think > > > > you will have to worry about actual bindings detail. > > > > > > > > > But I'm happy to just queue-up patches 2 and 3 of this series > > > > > now if you prefer. > > > > > > > > Well, I meant patch 3 only. Patch 1 and 2 are tied together by dependencies. =) > > > > > > Thanks, I understand now. > > > > > > I'll queue-up 3/3. > > > > Which I did. > > > > Then some time passed... > > > > Mike has accepted my pull-request for patch 1 of this series > > and accordingly I have queued-up this patch for v3.14. > > It should appear in the devel branch the next time that I push it. > > I was mistaken. It was not queued up for v3.14. > And still has not been queued up. > > I have un-queued this patch accordingly. I have pulled in the emev2 SMU clock support patch now. Regards, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Dec 22, 2013 at 10:41:03PM -0800, Mike Turquette wrote: > Quoting Simon Horman (2013-12-01 18:25:51) > > On Tue, Oct 29, 2013 at 01:42:41PM +0900, Simon Horman wrote: > > > On Wed, Oct 09, 2013 at 07:39:18PM +0900, Simon Horman wrote: > > > > On Wed, Oct 09, 2013 at 04:29:56PM +0900, Magnus Damm wrote: > > > > > Hi Simon, > > > > > > > > > > On Wed, Oct 9, 2013 at 3:54 PM, Simon Horman <horms@verge.net.au> wrote: > > > > > > On Wed, Oct 09, 2013 at 01:59:46PM +0900, Magnus Damm wrote: > > > > > >> Hi Simon, > > > > > >> > > > > > >> On Wed, Oct 9, 2013 at 12:40 PM, Simon Horman <horms@verge.net.au> wrote: > > > > > >> > On Tue, Oct 08, 2013 at 02:34:03PM +0900, takasi-y@ops.dti.ne.jp wrote: > > > > > >> >> Use common clock framework version of clock > > > > > >> >> drivers/clk/shmobile/clk-emev2.c > > > > > >> >> instead of sh-clkfwk version > > > > > >> >> arch/arm/mach-shmobile/clock-emev2.c > > > > > >> >> when it is configured as a part of multi-platform. > > > > > >> >> > > > > > >> >> Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp> > > > > > >> > > > > > > >> > Thanks. > > > > > >> > > > > > > >> > I plan to add this patch to a new topic branch, > > > > > >> > topic/emev2-common-clock, in the renesas tree and > > > > > >> > queue it up from there for inclusion in mainline > > > > > >> > if/when the first patch of this series is accepted > > > > > >> > by Mike Turquette. > > > > > >> > > > > > >> Thanks for picking up patches, Simon. > > > > > >> > > > > > >> I think you can simply merge this patch after the following series: > > > > > >> > > > > > >> [PATCH 00/05] ARM: shmobile: KZM9D Multiplatform update > > > > > > > > > > > > This is already queued up. > > > > > > > > > > Yes, I know, thanks for that. I tried to explain the dependency in the > > > > > 00/00 cover letter but I will try to be more clear next time! > > > > > > > > > > >> There are no build time dependencies on patch 1 and 2 so this patch > > > > > >> can be merged independently. Regarding run-time operation, the > > > > > >> multiplatform series above makes KZM9D DT reference only build for > > > > > >> multiplatform, and in such case CCF is required. > > > > > >> > > > > > >> So if you want to keep KZM9D DT reference working until Mike Turquette > > > > > >> accepts the CCF bits, then I recommend you to wait with "[PATCH 00/05] > > > > > >> ARM: shmobile: KZM9D Multiplatform update" until all EMEV2 CCF bits > > > > > >> have been merged. > > > > > >> > > > > > >> Another way is to merge "[PATCH 00/05] ARM: shmobile: KZM9D > > > > > >> Multiplatform update" before the EMEV2 CCF bits, but if so you may as > > > > > >> well merge this patch as well IMO. This > > > > > >> multiplatform-update-series-merge-before-CCF plan will result in > > > > > >> untestable KZM9D DT reference until EMEV2 CCF is merged. Either way is > > > > > >> fine with me. > > > > > > > > > > > > I am mainly concerned that the bindings may change before > > > > > > they are finally merged. And I thought it would be nice to avoid > > > > > > having to fix up the usage of the bindings if they change. > > > > > > > > > > Sure, but the code in this patch looks like it simply starts DT CCF > > > > > probing regardless of what the bindings look like. So I don't think > > > > > you will have to worry about actual bindings detail. > > > > > > > > > > > But I'm happy to just queue-up patches 2 and 3 of this series > > > > > > now if you prefer. > > > > > > > > > > Well, I meant patch 3 only. Patch 1 and 2 are tied together by dependencies. =) > > > > > > > > Thanks, I understand now. > > > > > > > > I'll queue-up 3/3. > > > > > > Which I did. > > > > > > Then some time passed... > > > > > > Mike has accepted my pull-request for patch 1 of this series > > > and accordingly I have queued-up this patch for v3.14. > > > It should appear in the devel branch the next time that I push it. > > > > I was mistaken. It was not queued up for v3.14. > > And still has not been queued up. > > > > I have un-queued this patch accordingly. > > I have pulled in the emev2 SMU clock support patch now. Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Dec 23, 2013 at 05:00:36PM +0900, Simon Horman wrote: > On Sun, Dec 22, 2013 at 10:41:03PM -0800, Mike Turquette wrote: > > Quoting Simon Horman (2013-12-01 18:25:51) > > > On Tue, Oct 29, 2013 at 01:42:41PM +0900, Simon Horman wrote: > > > > On Wed, Oct 09, 2013 at 07:39:18PM +0900, Simon Horman wrote: > > > > > On Wed, Oct 09, 2013 at 04:29:56PM +0900, Magnus Damm wrote: > > > > > > Hi Simon, > > > > > > > > > > > > On Wed, Oct 9, 2013 at 3:54 PM, Simon Horman <horms@verge.net.au> wrote: > > > > > > > On Wed, Oct 09, 2013 at 01:59:46PM +0900, Magnus Damm wrote: > > > > > > >> Hi Simon, > > > > > > >> > > > > > > >> On Wed, Oct 9, 2013 at 12:40 PM, Simon Horman <horms@verge.net.au> wrote: > > > > > > >> > On Tue, Oct 08, 2013 at 02:34:03PM +0900, takasi-y@ops.dti.ne.jp wrote: > > > > > > >> >> Use common clock framework version of clock > > > > > > >> >> drivers/clk/shmobile/clk-emev2.c > > > > > > >> >> instead of sh-clkfwk version > > > > > > >> >> arch/arm/mach-shmobile/clock-emev2.c > > > > > > >> >> when it is configured as a part of multi-platform. > > > > > > >> >> > > > > > > >> >> Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp> > > > > > > >> > > > > > > > >> > Thanks. > > > > > > >> > > > > > > > >> > I plan to add this patch to a new topic branch, > > > > > > >> > topic/emev2-common-clock, in the renesas tree and > > > > > > >> > queue it up from there for inclusion in mainline > > > > > > >> > if/when the first patch of this series is accepted > > > > > > >> > by Mike Turquette. > > > > > > >> > > > > > > >> Thanks for picking up patches, Simon. > > > > > > >> > > > > > > >> I think you can simply merge this patch after the following series: > > > > > > >> > > > > > > >> [PATCH 00/05] ARM: shmobile: KZM9D Multiplatform update > > > > > > > > > > > > > > This is already queued up. > > > > > > > > > > > > Yes, I know, thanks for that. I tried to explain the dependency in the > > > > > > 00/00 cover letter but I will try to be more clear next time! > > > > > > > > > > > > >> There are no build time dependencies on patch 1 and 2 so this patch > > > > > > >> can be merged independently. Regarding run-time operation, the > > > > > > >> multiplatform series above makes KZM9D DT reference only build for > > > > > > >> multiplatform, and in such case CCF is required. > > > > > > >> > > > > > > >> So if you want to keep KZM9D DT reference working until Mike Turquette > > > > > > >> accepts the CCF bits, then I recommend you to wait with "[PATCH 00/05] > > > > > > >> ARM: shmobile: KZM9D Multiplatform update" until all EMEV2 CCF bits > > > > > > >> have been merged. > > > > > > >> > > > > > > >> Another way is to merge "[PATCH 00/05] ARM: shmobile: KZM9D > > > > > > >> Multiplatform update" before the EMEV2 CCF bits, but if so you may as > > > > > > >> well merge this patch as well IMO. This > > > > > > >> multiplatform-update-series-merge-before-CCF plan will result in > > > > > > >> untestable KZM9D DT reference until EMEV2 CCF is merged. Either way is > > > > > > >> fine with me. > > > > > > > > > > > > > > I am mainly concerned that the bindings may change before > > > > > > > they are finally merged. And I thought it would be nice to avoid > > > > > > > having to fix up the usage of the bindings if they change. > > > > > > > > > > > > Sure, but the code in this patch looks like it simply starts DT CCF > > > > > > probing regardless of what the bindings look like. So I don't think > > > > > > you will have to worry about actual bindings detail. > > > > > > > > > > > > > But I'm happy to just queue-up patches 2 and 3 of this series > > > > > > > now if you prefer. > > > > > > > > > > > > Well, I meant patch 3 only. Patch 1 and 2 are tied together by dependencies. =) > > > > > > > > > > Thanks, I understand now. > > > > > > > > > > I'll queue-up 3/3. > > > > > > > > Which I did. > > > > > > > > Then some time passed... > > > > > > > > Mike has accepted my pull-request for patch 1 of this series > > > > and accordingly I have queued-up this patch for v3.14. > > > > It should appear in the devel branch the next time that I push it. > > > > > > I was mistaken. It was not queued up for v3.14. > > > And still has not been queued up. > > > > > > I have un-queued this patch accordingly. > > > > I have pulled in the emev2 SMU clock support patch now. > > Thanks I have queued up kzm9d this patch again. -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/mach-shmobile/board-kzm9d-reference.c b/arch/arm/mach-shmobile/board-kzm9d-reference.c index 054d8d5..853003c 100644 --- a/arch/arm/mach-shmobile/board-kzm9d-reference.c +++ b/arch/arm/mach-shmobile/board-kzm9d-reference.c @@ -20,15 +20,14 @@ #include <linux/init.h> #include <linux/of_platform.h> +#include <linux/clk-provider.h> #include <mach/emev2.h> #include <mach/common.h> #include <asm/mach/arch.h> static void __init kzm9d_add_standard_devices(void) { - if (!IS_ENABLED(CONFIG_COMMON_CLK)) - emev2_clock_init(); - + of_clk_init(NULL); of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); }
Use common clock framework version of clock drivers/clk/shmobile/clk-emev2.c instead of sh-clkfwk version arch/arm/mach-shmobile/clock-emev2.c when it is configured as a part of multi-platform. Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp> --- arch/arm/mach-shmobile/board-kzm9d-reference.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)