Patchwork [GIT,PULL,v2] Renesas ARM-based SoC board updates for v3.10

login
register
mail settings
Submitter Simon Horman
Date March 22, 2013, 12:58 a.m.
Message ID <20130322005815.GG1689@verge.net.au>
Download mbox
Permalink /patch/229862/
State New
Headers show

Pull-request

git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-clocksource-for-v3.10

Comments

Simon Horman - March 22, 2013, 12:58 a.m.
On Thu, Mar 21, 2013 at 05:18:32PM +0000, Arnd Bergmann wrote:
> On Tuesday 19 March 2013, Simon Horman wrote:
> 
> > ----------------------------------------------------------------
> > Renesas ARM-based SoC board updates for v3.10
> > 
> > This is based on a merge of the following:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git renesas-pinmux-for-v3.10
> > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git renesas-soc-for-v3.10
> 
> Pulled into next/boards.
> 
> Please verify that I have pulled everything you sent me. If not, it my mistake.

Thanks.

Sorry about sending so many all at once. There were quite a few changes
queued up and it might have been better if I flushed some of them out
a bit earlier.

Of the batch that I sent last week, I think you are missing the following one:

From:	Simon Horman <horms+renesas@verge.net.au>
To:	Arnd Bergmann <arnd@arndb.de>, Olof Johansson <olof@lixom.net>
Cc:	linux-sh@vger.kernel.org, arm@kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Paul Mundt <lethal@linux-sh.org>,
	Magnus Damm <magnus.damm@gmail.com>
Subject: [GIT PULL] ARM and SH based SoC clocksource update for v3.10
Date:	Mon, 18 Mar 2013 22:02:26 +0900
Message-Id: <1363611758-6655-1-git-send-email-horms+renesas@verge.net.au>

Hi Olof, Hi Arnd,

The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:

  Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-clocksource-for-v3.10

for you to fetch changes up to 342896a5c565e38dfb87954f362735f03ae1efb0:

  clocksource: sh_mtu2: Set initcall level to subsys (2013-03-13 02:24:37 +0900)

----------------------------------------------------------------
Renesas ARM and SH based SoC clocksource update for v3.10

I has been agreed by Paul Mundt and myself, that it would be best to take
these changes through the renesas tree and in turn the arm-soc tree.

----------------------------------------------------------------
Magnus Damm (8):
      clocksource: sh_cmt: Take care of clk_put() when setup_irq() fails
      clocksource: sh_cmt: Initialize 'max_match_value' and 'lock' in sh_cmt_setup()
      clocksource: sh_cmt: Introduce per-register functions
      clocksource: sh_cmt: Consolidate platform_set_drvdata() call
      clocksource: sh_cmt: CMSTR and CMCSR register access update
      clocksource: sh_cmt: CMCNT and CMCOR register access update
      clocksource: sh_cmt: Add control register callbacks
      clocksource: sh_cmt: Add CMT register layout comment

Simon Horman (4):
      clocksource: sh_cmt: Set initcall level to subsys
      clocksource: sh_tmu: Set initcall level to subsys
      clocksource: em_sti: Set initcall level to subsys
      clocksource: sh_mtu2: Set initcall level to subsys

 drivers/clocksource/em_sti.c  |   13 ++-
 drivers/clocksource/sh_cmt.c  |  189 +++++++++++++++++++++++++----------------
 drivers/clocksource/sh_mtu2.c |    2 +-
 drivers/clocksource/sh_tmu.c  |    2 +-
 4 files changed, 132 insertions(+), 74 deletions(-)
Arnd Bergmann - March 22, 2013, 12:40 p.m.
On Friday 22 March 2013, Simon Horman wrote:
> Sorry about sending so many all at once. There were quite a few changes
> queued up and it might have been better if I flushed some of them out
> a bit earlier.
> 
> Of the batch that I sent last week, I think you are missing the following one:
> 

Right, I've pulled it into next/drivers now. Thanks for checking this.

	Arnd
Simon Horman - March 22, 2013, 1:52 p.m.
On Fri, Mar 22, 2013 at 12:40:53PM +0000, Arnd Bergmann wrote:
> On Friday 22 March 2013, Simon Horman wrote:
> > Sorry about sending so many all at once. There were quite a few changes
> > queued up and it might have been better if I flushed some of them out
> > a bit earlier.
> > 
> > Of the batch that I sent last week, I think you are missing the following one:
> > 
> 
> Right, I've pulled it into next/drivers now. Thanks for checking this.

Thanks. I now have no outstanding pull requests.

I do have a few new patches in my tree.
I plan to let a few more accumulate before sending the next pull request(s).
Arnd Bergmann - March 22, 2013, 3:39 p.m.
On Friday 22 March 2013, Simon Horman wrote:
> On Fri, Mar 22, 2013 at 12:40:53PM +0000, Arnd Bergmann wrote:
> > On Friday 22 March 2013, Simon Horman wrote:
> > > Sorry about sending so many all at once. There were quite a few changes
> > > queued up and it might have been better if I flushed some of them out
> > > a bit earlier.
> > > 
> > > Of the batch that I sent last week, I think you are missing the following one:
> > > 
> > 
> > Right, I've pulled it into next/drivers now. Thanks for checking this.
> 
> Thanks. I now have no outstanding pull requests.
> 
> I do have a few new patches in my tree.
> I plan to let a few more accumulate before sending the next pull request(s).

Ok, sounds good.

One general question about your plans (probably more for Magnus than for you):
What is your expected time line for moving shmobile under
CONFIG_ARCH_MULTIPLATFORM? It seems you are making great progress, but
there is also still a lot to be done.

I expect that in 3.10, we will have all ARMv6 and ARMv7 platforms converted,
with the exception of realview, mmp, s5p, msm, and shmobile. I'm sure we
can do realview and mmp for 3.11, possibly also s5p. For shmobile, I think
most of the work would be changing drivers/sh/clk to integrate into the common
clk framework, and you need to find a way to enable ARM_PATCH_PHYS_VIRT and
AUTO_ZRELADDR. Are those things you think can be done for 3.11?

	Arnd
Simon Horman - March 27, 2013, 5:30 a.m.
On Fri, Mar 22, 2013 at 03:39:39PM +0000, Arnd Bergmann wrote:
> On Friday 22 March 2013, Simon Horman wrote:
> > On Fri, Mar 22, 2013 at 12:40:53PM +0000, Arnd Bergmann wrote:
> > > On Friday 22 March 2013, Simon Horman wrote:
> > > > Sorry about sending so many all at once. There were quite a few changes
> > > > queued up and it might have been better if I flushed some of them out
> > > > a bit earlier.
> > > > 
> > > > Of the batch that I sent last week, I think you are missing the following one:
> > > > 
> > > 
> > > Right, I've pulled it into next/drivers now. Thanks for checking this.
> > 
> > Thanks. I now have no outstanding pull requests.
> > 
> > I do have a few new patches in my tree.
> > I plan to let a few more accumulate before sending the next pull request(s).
> 
> Ok, sounds good.
> 
> One general question about your plans (probably more for Magnus than for you):

Indeed, it is more for Magnus than I.

> What is your expected time line for moving shmobile under
> CONFIG_ARCH_MULTIPLATFORM? It seems you are making great progress, but
> there is also still a lot to be done.
> 
> I expect that in 3.10, we will have all ARMv6 and ARMv7 platforms converted,
> with the exception of realview, mmp, s5p, msm, and shmobile. I'm sure we
> can do realview and mmp for 3.11, possibly also s5p. For shmobile, I think
> most of the work would be changing drivers/sh/clk to integrate into the common
> clk framework, and you need to find a way to enable ARM_PATCH_PHYS_VIRT and
> AUTO_ZRELADDR. Are those things you think can be done for 3.11?
Magnus Damm - March 27, 2013, 9:54 a.m.
Hi Arnd,

Thanks for your email.

On Sat, Mar 23, 2013 at 12:39 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 22 March 2013, Simon Horman wrote:
>> On Fri, Mar 22, 2013 at 12:40:53PM +0000, Arnd Bergmann wrote:
>> > On Friday 22 March 2013, Simon Horman wrote:
>> > > Sorry about sending so many all at once. There were quite a few changes
>> > > queued up and it might have been better if I flushed some of them out
>> > > a bit earlier.
>> > >
>> > > Of the batch that I sent last week, I think you are missing the following one:
>> > >
>> >
>> > Right, I've pulled it into next/drivers now. Thanks for checking this.
>>
>> Thanks. I now have no outstanding pull requests.
>>
>> I do have a few new patches in my tree.
>> I plan to let a few more accumulate before sending the next pull request(s).
>
> Ok, sounds good.
>
> One general question about your plans (probably more for Magnus than for you):
> What is your expected time line for moving shmobile under
> CONFIG_ARCH_MULTIPLATFORM? It seems you are making great progress, but
> there is also still a lot to be done.

Indeed, there is still a lot to be done!

> I expect that in 3.10, we will have all ARMv6 and ARMv7 platforms converted,
> with the exception of realview, mmp, s5p, msm, and shmobile. I'm sure we
> can do realview and mmp for 3.11, possibly also s5p. For shmobile, I think
> most of the work would be changing drivers/sh/clk to integrate into the common
> clk framework, and you need to find a way to enable ARM_PATCH_PHYS_VIRT and
> AUTO_ZRELADDR. Are those things you think can be done for 3.11?

Good to hear that most ARM platforms will be converted by v3.10. This
is definitely something that I want to make happen for mach-shmobile
as well.

Our biggest challenge now is the move to common clocks. I suspect that
moving all our boards and SoCs to common clocks will take much longer
than v3.11 I'm afraid.

Starting with something smaller like EMEV2 may be a good first step.
So somehow I'd like to start converting them one by one, perhaps also
moving over the converted SoCs/boards to CONFIG_ARCH_MULTIPLATFORM in
an incremental fashion. Do you happen to have any example subarch that
has been migrated in an increment fashion already?

Regarding ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR, I believe those
should be enabled for the mach-shmobile bits that are used with
CONFIG_ARCH_MULTIPLATFORM. Best way forward there is TBD, any
recommendations would be very welcome!

Thanks,

/ magnus
Arnd Bergmann - March 27, 2013, 11:37 a.m.
On Wednesday 27 March 2013, Magnus Damm wrote:
> On Sat, Mar 23, 2013 at 12:39 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Friday 22 March 2013, Simon Horman wrote:
> > I expect that in 3.10, we will have all ARMv6 and ARMv7 platforms converted,
> > with the exception of realview, mmp, s5p, msm, and shmobile. I'm sure we
> > can do realview and mmp for 3.11, possibly also s5p. For shmobile, I think
> > most of the work would be changing drivers/sh/clk to integrate into the common
> > clk framework, and you need to find a way to enable ARM_PATCH_PHYS_VIRT and
> > AUTO_ZRELADDR. Are those things you think can be done for 3.11?
> 
> Good to hear that most ARM platforms will be converted by v3.10. This
> is definitely something that I want to make happen for mach-shmobile
> as well.
> 
> Our biggest challenge now is the move to common clocks. I suspect that
> moving all our boards and SoCs to common clocks will take much longer
> than v3.11 I'm afraid.

Ok, I see. If you think it's not likely to be ready for 3.12, we might
need to discuss again whether there is another way of making the
common clk and the sh-clk code coexist. For instance, we could rename
all if the sh/shmobile specific clk functions and their users from
clk_* to shclk_*, and provide a thin wrapper around them that integrates
into common clk.
 
> Starting with something smaller like EMEV2 may be a good first step.
> So somehow I'd like to start converting them one by one, perhaps also
> moving over the converted SoCs/boards to CONFIG_ARCH_MULTIPLATFORM in
> an incremental fashion. Do you happen to have any example subarch that
> has been migrated in an increment fashion already?

We have had a few that were able to do both multiplatform and
single-platform for some time, but then changed to multiplatform-only.
I think mvebu and vt8500 are in this category.

> Regarding ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR, I believe those
> should be enabled for the mach-shmobile bits that are used with
> CONFIG_ARCH_MULTIPLATFORM. Best way forward there is TBD, any
> recommendations would be very welcome!

Yes, makes sense.

What I think you should do is rename CONFIG_ARCH_SHMOBILE to
CONFIG_ARCH_SHMOBILE_SINGLE, and add a new symbol in
arch/arm/mach-shmobile/Kconfig like

config ARCH_SHMOBILE
	bool "Renesas SH-Mobile / R-Mobile" if ARCH_MULTI_V6_V7
	default CONFIG_ARCH_SHMOBILE_SINGLE
        help
          Support for Renesas's SH-Mobile and R-Mobile ARM platforms.

This way, the platform is a non-exclusive option for the multiplatform
case, and a hidden enabled option when building CONFIG_ARCH_SHMOBILE_SINGLE.
Every machine that is not ready for multiplatform can then add "depends on
CONFIG_ARCH_SHMOBILE_SINGLE".

	Arnd
Magnus Damm - April 1, 2013, 9:15 a.m.
On Wed, Mar 27, 2013 at 8:37 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Wednesday 27 March 2013, Magnus Damm wrote:
> > On Sat, Mar 23, 2013 at 12:39 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Friday 22 March 2013, Simon Horman wrote:
> > > I expect that in 3.10, we will have all ARMv6 and ARMv7 platforms converted,
> > > with the exception of realview, mmp, s5p, msm, and shmobile. I'm sure we
> > > can do realview and mmp for 3.11, possibly also s5p. For shmobile, I think
> > > most of the work would be changing drivers/sh/clk to integrate into the common
> > > clk framework, and you need to find a way to enable ARM_PATCH_PHYS_VIRT and
> > > AUTO_ZRELADDR. Are those things you think can be done for 3.11?
> >
> > Good to hear that most ARM platforms will be converted by v3.10. This
> > is definitely something that I want to make happen for mach-shmobile
> > as well.
> >
> > Our biggest challenge now is the move to common clocks. I suspect that
> > moving all our boards and SoCs to common clocks will take much longer
> > than v3.11 I'm afraid.
>
> Ok, I see. If you think it's not likely to be ready for 3.12, we might
> need to discuss again whether there is another way of making the
> common clk and the sh-clk code coexist. For instance, we could rename
> all if the sh/shmobile specific clk functions and their users from
> clk_* to shclk_*, and provide a thin wrapper around them that integrates
> into common clk.

Yeah, I am not sure if it is likely that we will be able to convert
all platforms at v3.12 timing.

I actually tried to let common clocks and sh-clk coexist when the
common clock framework was under heavy development. I recall it being
far from trivial.

One possible way to develop this could be to force the mach-shmobile
"reference DT" implementations use common clocks and keep the old
boards as-is. Then we can also make sure the "reference DT"
implementations can be used as CONFIG_ARCH_MULTIPLATFORM. So if we
only have "reference DT" code as MULTIPLATFORM and then finally kill
off the old board code one by one.

> > Starting with something smaller like EMEV2 may be a good first step.
> > So somehow I'd like to start converting them one by one, perhaps also
> > moving over the converted SoCs/boards to CONFIG_ARCH_MULTIPLATFORM in
> > an incremental fashion. Do you happen to have any example subarch that
> > has been migrated in an increment fashion already?
>
> We have had a few that were able to do both multiplatform and
> single-platform for some time, but then changed to multiplatform-only.
> I think mvebu and vt8500 are in this category.

Thanks.

> > Regarding ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR, I believe those
> > should be enabled for the mach-shmobile bits that are used with
> > CONFIG_ARCH_MULTIPLATFORM. Best way forward there is TBD, any
> > recommendations would be very welcome!
>
> Yes, makes sense.
>
> What I think you should do is rename CONFIG_ARCH_SHMOBILE to
> CONFIG_ARCH_SHMOBILE_SINGLE, and add a new symbol in
> arch/arm/mach-shmobile/Kconfig like
>
> config ARCH_SHMOBILE
>         bool "Renesas SH-Mobile / R-Mobile" if ARCH_MULTI_V6_V7
>         default CONFIG_ARCH_SHMOBILE_SINGLE
>         help
>           Support for Renesas's SH-Mobile and R-Mobile ARM platforms.
>
> This way, the platform is a non-exclusive option for the multiplatform
> case, and a hidden enabled option when building CONFIG_ARCH_SHMOBILE_SINGLE.
> Every machine that is not ready for multiplatform can then add "depends on
> CONFIG_ARCH_SHMOBILE_SINGLE".

I see, that makes sense. Thanks.

Since we're on the topic of CONFIG_ARCH_MULTIPLATFORM, do you have any
recommendatoin about LPAE?

Judging by the ARM_LPAE help text it seems that selecting ARM_LPAE
will result in a kernel only working on LPAE hardware:

config ARM_LPAE
[snip]
          Say Y if you have an ARMv7 processor supporting the LPAE page
          table format and you would like to access memory beyond the
          4GB limit. The resulting kernel image will not run on
          processors without the LPA extension.

With the above text it sounds to me like we should not to a "select
ARM_LPAE" on each board in the case of CONFIG_ARCH_MULTIPLATFORM.

I sort of expect LPAE to behave similar to x86 PAE. At least the board
DT file should describe all physical memory available and depending on
kernel configuration (HIGHMEM=y/n, LPAE=y/n) we get different amounts
of usable memory in the kernel. Then if LPAE should be selected or not
is something that the distributions have to decide.

Thanks!

/ magnus
Arnd Bergmann - April 2, 2013, 10:09 a.m.
On Monday 01 April 2013, Magnus Damm wrote:
> On Wed, Mar 27, 2013 at 8:37 PM, Arnd Bergmann <arnd@arndb.de> wrote:

> > Ok, I see. If you think it's not likely to be ready for 3.12, we might
> > need to discuss again whether there is another way of making the
> > common clk and the sh-clk code coexist. For instance, we could rename
> > all if the sh/shmobile specific clk functions and their users from
> > clk_* to shclk_*, and provide a thin wrapper around them that integrates
> > into common clk.
> 
> Yeah, I am not sure if it is likely that we will be able to convert
> all platforms at v3.12 timing.
> 
> I actually tried to let common clocks and sh-clk coexist when the
> common clock framework was under heavy development. I recall it being
> far from trivial.
> 
> One possible way to develop this could be to force the mach-shmobile
> "reference DT" implementations use common clocks and keep the old
> boards as-is. Then we can also make sure the "reference DT"
> implementations can be used as CONFIG_ARCH_MULTIPLATFORM. So if we
> only have "reference DT" code as MULTIPLATFORM and then finally kill
> off the old board code one by one.

Works for me, but wouldn't that mean that half the shmobile boards
become incompatible with the other half, forcing you to build two
separate kernels if you want to run on all the machines?

Maybe that's not a problem for you, since you tend to have per-soc
defconfigs  anyway, and it will only be temporary.

> Since we're on the topic of CONFIG_ARCH_MULTIPLATFORM, do you have any
> recommendatoin about LPAE?
> 
> Judging by the ARM_LPAE help text it seems that selecting ARM_LPAE
> will result in a kernel only working on LPAE hardware:
> 
> config ARM_LPAE
> [snip]
>           Say Y if you have an ARMv7 processor supporting the LPAE page
>           table format and you would like to access memory beyond the
>           4GB limit. The resulting kernel image will not run on
>           processors without the LPA extension.
> 
> With the above text it sounds to me like we should not to a "select
> ARM_LPAE" on each board in the case of CONFIG_ARCH_MULTIPLATFORM.

Correct.

> I sort of expect LPAE to behave similar to x86 PAE. At least the board
> DT file should describe all physical memory available and depending on
> kernel configuration (HIGHMEM=y/n, LPAE=y/n) we get different amounts
> of usable memory in the kernel. Then if LPAE should be selected or not
> is something that the distributions have to decide.

Yes. I believe all distros are planning to build one non-LPAE nd one
LPAE kernel. There will have to be a way to enable all LPAE-capable
platforms in Kconfig, but I don't know if that exists already.

Presumably, the LPAE kernel will also be using THUMB2 in the kernel,
while the non-LPAE kernel may get built with ARMv6 platform support
enabled, which rules out THUMB2.

Also, we could enable KVM support in the non-LPAE kernel, but since 
all KVM capable CPU cores (Cortex-A7 and Cortex-A15) so far also
come with LPAE, that's not even necessary.

You can always use #address-cells=<2> in the DT root node if that
helps, and you can also keep your peripherals using #address-cells=<1>
with an appropriate ranges property in the soc bus node.

	Arnd