Message ID | 1364879246-9470-1-git-send-email-horms+renesas@verge.net.au |
---|---|
State | New |
Headers | show |
Hello. On 02-04-2013 9:07, Simon Horman wrote: > From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> > Current clock-sh7372 is using own implement > for each divX clocks. > This patch switches to use fixed ratio clock, > and was tesed on mackerel board. > > Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> > Acked-by: Magnus Damm <damm@opensource.se> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au> > --- > arch/arm/mach-shmobile/clock-sh7372.c | 44 ++++++--------------------------- > 1 file changed, 7 insertions(+), 37 deletions(-) > diff --git a/arch/arm/mach-shmobile/clock-sh7372.c b/arch/arm/mach-shmobile/clock-sh7372.c > index 6c23e3f..7e10593 100644 > --- a/arch/arm/mach-shmobile/clock-sh7372.c > +++ b/arch/arm/mach-shmobile/clock-sh7372.c [...] > @@ -83,39 +84,12 @@ struct clk sh7372_extal2_clk = { [...] > +SH_FIXED_RATIO_CLKg(sh7372_dv_clki_div2_clk, sh7372_dv_clki_clk, div2); > +SH_FIXED_RATIO_CLK(extal1_div2_clk, sh7372_extal1_clk, div2); > +SH_FIXED_RATIO_CLK(extal2_div2_clk, sh7372_extal2_clk, div2); > +SH_FIXED_RATIO_CLK(extal2_div4_clk, extal2_div2_clk, div2); Note that SH_FIXED_RATIO_CLK() definition already includes ; -- it probably should be removed from there. WBR, Sergei
On Tuesday 02 April 2013, Sergei Shtylyov wrote: > > @@ -83,39 +84,12 @@ struct clk sh7372_extal2_clk = { > [...] > > +SH_FIXED_RATIO_CLKg(sh7372_dv_clki_div2_clk, sh7372_dv_clki_clk, div2); > > +SH_FIXED_RATIO_CLK(extal1_div2_clk, sh7372_extal1_clk, div2); > > +SH_FIXED_RATIO_CLK(extal2_div2_clk, sh7372_extal2_clk, div2); > > +SH_FIXED_RATIO_CLK(extal2_div4_clk, extal2_div2_clk, div2); > > Note that SH_FIXED_RATIO_CLK() definition already includes ; -- it > probably should be removed from there. Most macros that we have in the kernel like this don't include the semicolon, which seems better since it is harder to misuse (the compiler will complain about a missing semicolon but not always about an extranous one) and gives a more consistent syntax overall. It's probably not worth changing it now for the shmobile clock code, since that is getting changed over to common clock in the future, but you may want to remember this for future macro definitions. Arnd
On Tue, Apr 02, 2013 at 02:06:56PM +0900, Simon Horman wrote: > Hi Arnd, Hi Olof, > > The following changes since commit 4c82e452732784419fd616cf1acf2bc9b004aae1: > > Merge tag 'renesas-intc-external-irq2-for-v3.10' into soc-base (2013-04-02 10:55:57 +0900) > > are available in the git repository at: > > > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-soc2-for-v3.10 > > for you to fetch changes up to 8585deb18580d04209a2986430aa0959ef38fce2: > > ARM: shmobile: r8a7790 SoC 64-bit DT support (2013-04-02 11:02:21 +0900) > > ---------------------------------------------------------------- > Second round of Renesas ARM SoC updates for v3.10 > > Some Highlights: > > * Add r8a7790 SoC > * Add r8a73a4 SoC > * Migrate r8a7740 SoC from INTC to GIC > * Add thermal driver support to r8a73a4 SoC > * Add irqpin DT nodes to sh73a0 SoC > * Add SCIF support to r8a7778 SoC > > This pull request is based on a merge of: > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas renesas-soc-for-v3.10 > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas renesas-intc-external-irq2-for-v3.10 Ugh. So, the irq branch depends on the old soc branch, and now this depends on the irq branch (and it is soc code). That's a circular dependency. I'll add this as a next/soc2 branch in arm-soc, but please think about these kind of circular dependencies in the future, and try to avoid them if you can by splitting the branch contents in separate topics if possible. Likewise, there's a bunch of patches in this branch such as the fixed divisor clock patches that could be considered cleanup. Not a big deal to group them with the soc code, but if you're already doing cleanup branches it'd be just as well to put them in those. -Olof
On Tue, Apr 02, 2013 at 01:25:03PM -0700, Olof Johansson wrote: > On Tue, Apr 02, 2013 at 02:06:56PM +0900, Simon Horman wrote: > > Hi Arnd, Hi Olof, > > > > The following changes since commit 4c82e452732784419fd616cf1acf2bc9b004aae1: > > > > Merge tag 'renesas-intc-external-irq2-for-v3.10' into soc-base (2013-04-02 10:55:57 +0900) > > > > are available in the git repository at: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-soc2-for-v3.10 > > > > for you to fetch changes up to 8585deb18580d04209a2986430aa0959ef38fce2: > > > > ARM: shmobile: r8a7790 SoC 64-bit DT support (2013-04-02 11:02:21 +0900) > > > > ---------------------------------------------------------------- > > Second round of Renesas ARM SoC updates for v3.10 > > > > Some Highlights: > > > > * Add r8a7790 SoC > > * Add r8a73a4 SoC > > * Migrate r8a7740 SoC from INTC to GIC > > * Add thermal driver support to r8a73a4 SoC > > * Add irqpin DT nodes to sh73a0 SoC > > * Add SCIF support to r8a7778 SoC > > > > This pull request is based on a merge of: > > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas renesas-soc-for-v3.10 > > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas renesas-intc-external-irq2-for-v3.10 > > Ugh. So, the irq branch depends on the old soc branch, and now this depends on > the irq branch (and it is soc code). That's a circular dependency. > > I'll add this as a next/soc2 branch in arm-soc, but please think about these > kind of circular dependencies in the future, and try to avoid them if you can > by splitting the branch contents in separate topics if possible. Sorry about that. I have been having a bit of trouble managing the dependencies and some assumptions I made with earlier branches turned out to be invalid as new patches came in. I'll try to be more careful in future. > Likewise, there's a bunch of patches in this branch such as the fixed > divisor clock patches that could be considered cleanup. Not a big deal to > group them with the soc code, but if you're already doing cleanup > branches it'd be just as well to put them in those. I'm not carrying any cleanup branches at this time. I will keep in in mind for future patches of this nature.