[PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY

[PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY

[Laurent Pinchart]

SH-Mobile platforms are transitioning from non-multiplatform to
multiplatform kernel. A new ARCH_SHMOBILE_MULTI configuration symbol has
been created to group all multiplatform-enabled SH-Mobile SoCs. The
existing ARCH_SHMOBILE configuration symbol groups SoCs that haven't
been converted yet.

This arrangement works fine for the arch/ code, but lots of drivers
needed on both ARCH_SHMOBILE and ARCH_SHMOBILE_MULTI depend on
ARCH_SHMOBILE only. In order to avoid changing them, rename
ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY, and create a new boolean
ARCH_SHMOBILE configuration symbol that is selected by both
ARCH_SHMOBILE_LEGACY and ARCH_SHMOBILE_MULTI.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
---
 arch/arm/Kconfig                  | 14 ++++++++------
 arch/arm/Makefile                 |  1 -
 arch/arm/boot/compressed/Makefile |  2 +-
 arch/arm/boot/dts/Makefile        |  2 +-
 arch/arm/mach-shmobile/Kconfig    |  8 ++++++--
 drivers/Makefile                  |  2 +-
 6 files changed, 17 insertions(+), 12 deletions(-)

This patch is an alternative approach to adding ARCH_SHMOBILE_MULTI or ARM
dependencies to all the SH-Mobile-related drivers (see
http://www.spinics.net/lists/arm-kernel/msg283128.html). If accepted I will
modify the previous series to only add COMPILE_TEST support without touching
the other dependencies.

I believe this approach to be simpler. It will also not required dropping the
ARCH_SHMOBILE_MULTI dependency from all drivers when we will eventually get
rid of the non-multiplatform platforms and rename ARCH_SHMOBILE_MULTI to
ARCH_SHMOBILE.

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1ad6fb6..588b46b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -642,8 +642,9 @@ config ARCH_MSM
 	  stack and controls some vital subsystems
 	  (clock and power control, etc).
 
-config ARCH_SHMOBILE
-	bool "Renesas SH-Mobile / R-Mobile"
+config ARCH_SHMOBILE_LEGACY
+	bool "Renesas SH-Mobile / R-Mobile (non-multiplatform)"
+	select ARCH_SHMOBILE
 	select ARM_PATCH_PHYS_VIRT
 	select CLKDEV_LOOKUP
 	select GENERIC_CLOCKEVENTS
@@ -659,7 +660,8 @@ config ARCH_SHMOBILE
 	select PM_GENERIC_DOMAINS if PM
 	select SPARSE_IRQ
 	help
-	  Support for Renesas's SH-Mobile and R-Mobile ARM platforms.
+	  Support for Renesas's SH-Mobile and R-Mobile ARM platforms using
+	  a non-multiplatform kernel.
 
 config ARCH_RPC
 	bool "RiscPC"
@@ -1619,7 +1621,7 @@ config HZ_FIXED
 	default 200 if ARCH_EBSA110 || ARCH_S3C24XX || ARCH_S5P64X0 || \
 		ARCH_S5PV210 || ARCH_EXYNOS4
 	default AT91_TIMER_HZ if ARCH_AT91
-	default SHMOBILE_TIMER_HZ if ARCH_SHMOBILE
+	default SHMOBILE_TIMER_HZ if ARCH_SHMOBILE_LEGACY
 	default 0
 
 choice
@@ -1800,8 +1802,8 @@ config ARCH_WANT_GENERAL_HUGETLB
 source "mm/Kconfig"
 
 config FORCE_MAX_ZONEORDER
-	int "Maximum zone order" if ARCH_SHMOBILE
-	range 11 64 if ARCH_SHMOBILE
+	int "Maximum zone order" if ARCH_SHMOBILE_LEGACY
+	range 11 64 if ARCH_SHMOBILE_LEGACY
 	default "12" if SOC_AM33XX
 	default "9" if SA1111
 	default "11"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index db50b62..dca2e84 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -190,7 +190,6 @@ machine-$(CONFIG_ARCH_S5PV210)		+= s5pv210
 machine-$(CONFIG_ARCH_SA1100)		+= sa1100
 machine-$(CONFIG_ARCH_SHARK)		+= shark
 machine-$(CONFIG_ARCH_SHMOBILE) 	+= shmobile
-machine-$(CONFIG_ARCH_SHMOBILE_MULTI) 	+= shmobile
 machine-$(CONFIG_ARCH_SIRF)		+= prima2
 machine-$(CONFIG_ARCH_SOCFPGA)		+= socfpga
 machine-$(CONFIG_ARCH_STI)		+= sti
diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index 7ac1610..bafbb4c7 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -68,7 +68,7 @@ else
 endif
 endif
 
-ifeq ($(CONFIG_ARCH_SHMOBILE),y)
+ifeq ($(CONFIG_ARCH_SHMOBILE_LEGACY),y)
 OBJS		+= head-shmobile.o
 endif
 
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 891b724..7d98d3a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -197,7 +197,7 @@ dtb-$(CONFIG_ARCH_U8500) += ste-snowball.dtb \
 	ste-ccu8540.dtb \
 	ste-ccu9540.dtb
 dtb-$(CONFIG_ARCH_S3C24XX) += s3c2416-smdk2416.dtb
-dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \
+dtb-$(CONFIG_ARCH_SHMOBILE_LEGACY) += emev2-kzm9d.dtb \
 	r7s72100-genmai.dtb \
 	r8a7740-armadillo800eva.dtb \
 	r8a7778-bockw.dtb \
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 4bb548f..b31ceda 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -1,6 +1,10 @@
+config ARCH_SHMOBILE
+	bool
+
 config ARCH_SHMOBILE_MULTI
 	bool "SH-Mobile Series" if ARCH_MULTI_V7
 	depends on MMU
+	select ARCH_SHMOBILE
 	select CPU_V7
 	select GENERIC_CLOCKEVENTS
 	select HAVE_ARM_SCU if SMP
@@ -30,7 +34,7 @@ config MACH_KZM9D
 comment "SH-Mobile System Configuration"
 endif
 
-if ARCH_SHMOBILE
+if ARCH_SHMOBILE_LEGACY
 
 comment "SH-Mobile System Type"
 
@@ -288,7 +292,7 @@ source "drivers/sh/Kconfig"
 
 endif
 
-if ARCH_SHMOBILE || ARCH_SHMOBILE_MULTI
+if ARCH_SHMOBILE
 
 menu "Timer and clock configuration"
 
diff --git a/drivers/Makefile b/drivers/Makefile
index ab93de8..8a50222 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -116,7 +116,7 @@ obj-$(CONFIG_SGI_SN)		+= sn/
 obj-y				+= firmware/
 obj-$(CONFIG_CRYPTO)		+= crypto/
 obj-$(CONFIG_SUPERH)		+= sh/
-obj-$(CONFIG_ARCH_SHMOBILE)	+= sh/
+obj-$(CONFIG_ARCH_SHMOBILE_LEGACY)	+= sh/
 ifndef CONFIG_ARCH_USES_GETTIMEOFFSET
 obj-y				+= clocksource/
 endif
-- 
Regards,

Laurent Pinchart

Re: [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY

[Magnus Damm]

Hi Laurent,

On Thu, Nov 7, 2013 at 8:54 AM, Laurent Pinchart
<laurent.pinchart+renesas@ideasonboard.com> wrote:
> SH-Mobile platforms are transitioning from non-multiplatform to
> multiplatform kernel. A new ARCH_SHMOBILE_MULTI configuration symbol has
> been created to group all multiplatform-enabled SH-Mobile SoCs. The
> existing ARCH_SHMOBILE configuration symbol groups SoCs that haven't
> been converted yet.
>
> This arrangement works fine for the arch/ code, but lots of drivers
> needed on both ARCH_SHMOBILE and ARCH_SHMOBILE_MULTI depend on
> ARCH_SHMOBILE only. In order to avoid changing them, rename
> ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY, and create a new boolean
> ARCH_SHMOBILE configuration symbol that is selected by both
> ARCH_SHMOBILE_LEGACY and ARCH_SHMOBILE_MULTI.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Thanks, this looks good to me.

Acked-by: Magnus Damm <damm@opensource.se>

I have one semi-related question below:

> @@ -1619,7 +1621,7 @@ config HZ_FIXED
>         default 200 if ARCH_EBSA110 || ARCH_S3C24XX || ARCH_S5P64X0 || \
>                 ARCH_S5PV210 || ARCH_EXYNOS4
>         default AT91_TIMER_HZ if ARCH_AT91
> -       default SHMOBILE_TIMER_HZ if ARCH_SHMOBILE
> +       default SHMOBILE_TIMER_HZ if ARCH_SHMOBILE_LEGACY
>         default 0
>
>  choice

For the hunk above, it makes sense that we cannot HZ in the
multiplatform case, so I think your patch is right.

I do however wonder what's the plan with multiplatform and the HZ
value, how do we handle hardware platforms that use 32768 Hz as clock?
Historically those platforms work best with a
even-divide-by-a-power-of-two HZ value, so with a HZ\x100 value things
may drift slowly...

Cheers,

/ maganus

Re: [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY

[Laurent Pinchart]

Hi Magnus,

On Thursday 07 November 2013 15:04:57 Magnus Damm wrote:
> On Thu, Nov 7, 2013 at 8:54 AM, Laurent Pinchart wrote:
> > SH-Mobile platforms are transitioning from non-multiplatform to
> > multiplatform kernel. A new ARCH_SHMOBILE_MULTI configuration symbol has
> > been created to group all multiplatform-enabled SH-Mobile SoCs. The
> > existing ARCH_SHMOBILE configuration symbol groups SoCs that haven't
> > been converted yet.
> > 
> > This arrangement works fine for the arch/ code, but lots of drivers
> > needed on both ARCH_SHMOBILE and ARCH_SHMOBILE_MULTI depend on
> > ARCH_SHMOBILE only. In order to avoid changing them, rename
> > ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY, and create a new boolean
> > ARCH_SHMOBILE configuration symbol that is selected by both
> > ARCH_SHMOBILE_LEGACY and ARCH_SHMOBILE_MULTI.
> > 
> > Signed-off-by: Laurent Pinchart
> > <laurent.pinchart+renesas@ideasonboard.com>
> 
> Thanks, this looks good to me.
> 
> Acked-by: Magnus Damm <damm@opensource.se>

Thank you.

> I have one semi-related question below:
> > @@ -1619,7 +1621,7 @@ config HZ_FIXED
> >         default 200 if ARCH_EBSA110 || ARCH_S3C24XX || ARCH_S5P64X0 || \
> >                 ARCH_S5PV210 || ARCH_EXYNOS4
> >         default AT91_TIMER_HZ if ARCH_AT91
> > -       default SHMOBILE_TIMER_HZ if ARCH_SHMOBILE
> > +       default SHMOBILE_TIMER_HZ if ARCH_SHMOBILE_LEGACY
> >         default 0
> >  
> >  choice
> 
> For the hunk above, it makes sense that we cannot HZ in the multiplatform
> case, so I think your patch is right.
> 
> I do however wonder what's the plan with multiplatform and the HZ value, how
> do we handle hardware platforms that use 32768 Hz as clock?
> Historically those platforms work best with a even-divide-by-a-power-of-two
> HZ value, so with a HZ\x100 value things may drift slowly...

Good question. Would it make sense to allow freely selected HZ values on 
multiplatform kernels ? Or maybe only if if ARCH_SHMOBILE is selected ? Or 
maybe full tickless kernels are the solution :-)

-- 
Regards,

Laurent Pinchart

Re: [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY

[Simon Horman]

On Thu, Nov 07, 2013 at 03:04:57PM +0900, Magnus Damm wrote:
> Hi Laurent,
> 
> On Thu, Nov 7, 2013 at 8:54 AM, Laurent Pinchart
> <laurent.pinchart+renesas@ideasonboard.com> wrote:
> > SH-Mobile platforms are transitioning from non-multiplatform to
> > multiplatform kernel. A new ARCH_SHMOBILE_MULTI configuration symbol has
> > been created to group all multiplatform-enabled SH-Mobile SoCs. The
> > existing ARCH_SHMOBILE configuration symbol groups SoCs that haven't
> > been converted yet.
> >
> > This arrangement works fine for the arch/ code, but lots of drivers
> > needed on both ARCH_SHMOBILE and ARCH_SHMOBILE_MULTI depend on
> > ARCH_SHMOBILE only. In order to avoid changing them, rename
> > ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY, and create a new boolean
> > ARCH_SHMOBILE configuration symbol that is selected by both
> > ARCH_SHMOBILE_LEGACY and ARCH_SHMOBILE_MULTI.
> >
> > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> 
> Thanks, this looks good to me.
> 
> Acked-by: Magnus Damm <damm@opensource.se>

This seems reasonable to me.
I would pick it up now but it is marked as "RFC".
Please let me know if you wish me to pick it up.

> 
> I have one semi-related question below:
> 
> > @@ -1619,7 +1621,7 @@ config HZ_FIXED
> >         default 200 if ARCH_EBSA110 || ARCH_S3C24XX || ARCH_S5P64X0 || \
> >                 ARCH_S5PV210 || ARCH_EXYNOS4
> >         default AT91_TIMER_HZ if ARCH_AT91
> > -       default SHMOBILE_TIMER_HZ if ARCH_SHMOBILE
> > +       default SHMOBILE_TIMER_HZ if ARCH_SHMOBILE_LEGACY
> >         default 0
> >
> >  choice
> 
> For the hunk above, it makes sense that we cannot HZ in the
> multiplatform case, so I think your patch is right.
> 
> I do however wonder what's the plan with multiplatform and the HZ
> value, how do we handle hardware platforms that use 32768 Hz as clock?
> Historically those platforms work best with a
> even-divide-by-a-power-of-two HZ value, so with a HZ\x100 value things
> may drift slowly...
> 
> Cheers,
> 
> / maganus
> 

Re: [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY

[stephen.lawrence]

linux-sh-owner@vger.kernel.org wrote on 08/11/2013 06:08:05:

Hi Guys,

> From: Simon Horman <horms@verge.net.au>
> To: Magnus Damm <magnus.damm@gmail.com>, 
> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>, 
SH-Linux <linux-
> sh@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" 
<linux-arm-kernel@lists.infradead.org>
> Date: 08/11/2013 06:07
> Subject: Re: [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to 
ARCH_SHMOBILE_LEGACY
> Sent by: linux-sh-owner@vger.kernel.org
> 
> On Thu, Nov 07, 2013 at 03:04:57PM +0900, Magnus Damm wrote:
> > Hi Laurent,
> > 
> > On Thu, Nov 7, 2013 at 8:54 AM, Laurent Pinchart
> > <laurent.pinchart+renesas@ideasonboard.com> wrote:
> > > SH-Mobile platforms are transitioning from non-multiplatform to
> > > multiplatform kernel. A new ARCH_SHMOBILE_MULTI configuration symbol 
has
> > > been created to group all multiplatform-enabled SH-Mobile SoCs. The
> > > existing ARCH_SHMOBILE configuration symbol groups SoCs that haven't
> > > been converted yet.
> > >

I'm sure there are reasons for keeping it but looking forward I can't help 
but wonder if this wouldn't be a good time to lose the SHMOBILE tag for 
new platforms? It doesn't seem to be a great match to our business or the 
architectures.

I know from conversations I've had in the last year or so that external 
engineers working on R-Car sometimes do not find your good work upstream 
as the combination of sh-mobile and using the product number proved an 
effective method of concealment. Although of course they could find it by 
searching the right files.

Have a good weekend,

Steve

Re: [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY

[Laurent Pinchart]

Hi Simon,

On Friday 08 November 2013 15:08:05 Simon Horman wrote:
> On Thu, Nov 07, 2013 at 03:04:57PM +0900, Magnus Damm wrote:
> > On Thu, Nov 7, 2013 at 8:54 AM, Laurent Pinchart wrote:
> > > SH-Mobile platforms are transitioning from non-multiplatform to
> > > multiplatform kernel. A new ARCH_SHMOBILE_MULTI configuration symbol has
> > > been created to group all multiplatform-enabled SH-Mobile SoCs. The
> > > existing ARCH_SHMOBILE configuration symbol groups SoCs that haven't
> > > been converted yet.
> > > 
> > > This arrangement works fine for the arch/ code, but lots of drivers
> > > needed on both ARCH_SHMOBILE and ARCH_SHMOBILE_MULTI depend on
> > > ARCH_SHMOBILE only. In order to avoid changing them, rename
> > > ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY, and create a new boolean
> > > ARCH_SHMOBILE configuration symbol that is selected by both
> > > ARCH_SHMOBILE_LEGACY and ARCH_SHMOBILE_MULTI.
> > > 
> > > Signed-off-by: Laurent Pinchart
> > > <laurent.pinchart+renesas@ideasonboard.com>
> > 
> > Thanks, this looks good to me.
> > 
> > Acked-by: Magnus Damm <damm@opensource.se>
> 
> This seems reasonable to me.
> I would pick it up now but it is marked as "RFC".
> Please let me know if you wish me to pick it up.

I've sent a non-RFC series, please pick that one up.

> > I have one semi-related question below:
> > > @@ -1619,7 +1621,7 @@ config HZ_FIXED
> > > 
> > >         default 200 if ARCH_EBSA110 || ARCH_S3C24XX || ARCH_S5P64X0 || \
> > >         
> > >                 ARCH_S5PV210 || ARCH_EXYNOS4
> > >         
> > >         default AT91_TIMER_HZ if ARCH_AT91
> > > 
> > > -       default SHMOBILE_TIMER_HZ if ARCH_SHMOBILE
> > > +       default SHMOBILE_TIMER_HZ if ARCH_SHMOBILE_LEGACY
> > > 
> > >         default 0
> > >  
> > >  choice
> > 
> > For the hunk above, it makes sense that we cannot HZ in the
> > multiplatform case, so I think your patch is right.
> > 
> > I do however wonder what's the plan with multiplatform and the HZ
> > value, how do we handle hardware platforms that use 32768 Hz as clock?
> > Historically those platforms work best with a
> > even-divide-by-a-power-of-two HZ value, so with a HZ\x100 value things
> > may drift slowly...

-- 
Regards,

Laurent Pinchart

Re: [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY

[Laurent Pinchart]

Hi Stephen,

On Friday 08 November 2013 14:57:29 stephen.lawrence@renesas.com wrote:
> linux-sh-owner@vger.kernel.org wrote on 08/11/2013 06:08:05:
> > On Thu, Nov 07, 2013 at 03:04:57PM +0900, Magnus Damm wrote:
> > > On Thu, Nov 7, 2013 at 8:54 AM, Laurent Pinchart wrote:
> > > > SH-Mobile platforms are transitioning from non-multiplatform to
> > > > multiplatform kernel. A new ARCH_SHMOBILE_MULTI configuration symbol
> > > > has been created to group all multiplatform-enabled SH-Mobile SoCs.
> > > > The existing ARCH_SHMOBILE configuration symbol groups SoCs that
> > > > haven't been converted yet.
> 
> I'm sure there are reasons for keeping it but looking forward I can't help
> but wonder if this wouldn't be a good time to lose the SHMOBILE tag for
> new platforms? It doesn't seem to be a great match to our business or the
> architectures.
> 
> I know from conversations I've had in the last year or so that external
> engineers working on R-Car sometimes do not find your good work upstream
> as the combination of sh-mobile and using the product number proved an
> effective method of concealment. Although of course they could find it by
> searching the right files.

It's not a bad idea, but I'm not sure how we could proceed. SH-Mobile, R-
Mobile and R-Car chipsets are all supported by a single code base, for which 
we need a name. Splitting the code base wouldn't make much sense from a 
technical point of view.

-- 
Regards,

Laurent Pinchart

Re: [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY

[phil.edworthy]

Hi Laurent,

> On Friday 08 November 2013 14:57:29 stephen.lawrence@renesas.com wrote:
> > linux-sh-owner@vger.kernel.org wrote on 08/11/2013 06:08:05:
> > > On Thu, Nov 07, 2013 at 03:04:57PM +0900, Magnus Damm wrote:
> > > > On Thu, Nov 7, 2013 at 8:54 AM, Laurent Pinchart wrote:
> > > > > SH-Mobile platforms are transitioning from non-multiplatform to
> > > > > multiplatform kernel. A new ARCH_SHMOBILE_MULTI configuration 
symbol
> > > > > has been created to group all multiplatform-enabled SH-Mobile 
SoCs.
> > > > > The existing ARCH_SHMOBILE configuration symbol groups SoCs that
> > > > > haven't been converted yet.
> > 
> > I'm sure there are reasons for keeping it but looking forward I can't 
help
> > but wonder if this wouldn't be a good time to lose the SHMOBILE tag 
for
> > new platforms? It doesn't seem to be a great match to our business or 
the
> > architectures.
> > 
> > I know from conversations I've had in the last year or so that 
external
> > engineers working on R-Car sometimes do not find your good work 
upstream
> > as the combination of sh-mobile and using the product number proved an
> > effective method of concealment. Although of course they could find it 
by
> > searching the right files.
> 
> It's not a bad idea, but I'm not sure how we could proceed. SH-Mobile, 
R-
> Mobile and R-Car chipsets are all supported by a single code base, for 
which 
> we need a name. Splitting the code base wouldn't make much sense from a 
> technical point of view.

True, but it would be helpful to have Renesas in the device name 
somewhere. Maybe include Renesas in the mach-shmobile/Kconfig description 
for the devices, and also update the description in arm/Kconfig to include 
R-Car.

Cheers
Phil

Re: [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY

[Simon Horman]

On Mon, Nov 11, 2013 at 09:45:12AM +0000, phil.edworthy@renesas.com wrote:
> Hi Laurent,
> 
> > On Friday 08 November 2013 14:57:29 stephen.lawrence@renesas.com wrote:
> > > linux-sh-owner@vger.kernel.org wrote on 08/11/2013 06:08:05:
> > > > On Thu, Nov 07, 2013 at 03:04:57PM +0900, Magnus Damm wrote:
> > > > > On Thu, Nov 7, 2013 at 8:54 AM, Laurent Pinchart wrote:
> > > > > > SH-Mobile platforms are transitioning from non-multiplatform to
> > > > > > multiplatform kernel. A new ARCH_SHMOBILE_MULTI configuration 
> symbol
> > > > > > has been created to group all multiplatform-enabled SH-Mobile 
> SoCs.
> > > > > > The existing ARCH_SHMOBILE configuration symbol groups SoCs
> > > > > > that haven't been converted yet.
> > > 
> > > I'm sure there are reasons for keeping it but looking forward I can't 
> help
> > > but wonder if this wouldn't be a good time to lose the SHMOBILE tag 
> for
> > > new platforms? It doesn't seem to be a great match to our business or 
> the
> > > architectures.
> > > 
> > > I know from conversations I've had in the last year or so that 
> external
> > > engineers working on R-Car sometimes do not find your good work 
> upstream
> > > as the combination of sh-mobile and using the product number proved
> > > an effective method of concealment. Although of course they could
> > > find it 
> by
> > > searching the right files.
> > 
> > It's not a bad idea, but I'm not sure how we could proceed. SH-Mobile, 
> R-
> > Mobile and R-Car chipsets are all supported by a single code base, for 
> which 
> > we need a name. Splitting the code base wouldn't make much sense from a
> > technical point of view.
> 
> True, but it would be helpful to have Renesas in the device name
> somewhere. Maybe include Renesas in the mach-shmobile/Kconfig description
> for the devices, and also update the description in arm/Kconfig to
> include R-Car.

Hi,

I have been involved in several discussions relating to moving away from
the shmobile name.

Prior to this thread the most recent discussion I was involved in was with
Olof Johansson, ARM-SoC co-maintainer, and Magnus. Due to the amount of
churn involved in changing the name of the mach-shmobile directory or
somehow splitting the code between multiple mach- directories, which was
the variant of the topic under discussion, the consensus was that moving
things around was not on the cards at this time.  There is also, as Laurent
mentioned, the technical issue that splitting the code doesn't make a whole
lot of sense from an implementation point of view.

From my point of view changing the SHMOBILE potion of ARCH_SHMOBILE_*
only really makes sense if the name of mach-shmobile directory is changed
in a similar way, which as I mentioned above that seems to be off the cards
at this time. The reason I think this is that if the ARCH_XXX name doesn't
match the directory we will add confusion rather than removing it.

With the above in mind I think that Phil's proposal to enhance
the descriptions in mach-shmobile/Kconfig and arm/Kconfig is
an excellent one given the hand of cards we have available to play.

Re: [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY

[Simon Horman]

On Sat, Nov 09, 2013 at 01:34:31PM +0100, Laurent Pinchart wrote:
> Hi Simon,
> 
> On Friday 08 November 2013 15:08:05 Simon Horman wrote:
> > On Thu, Nov 07, 2013 at 03:04:57PM +0900, Magnus Damm wrote:
> > > On Thu, Nov 7, 2013 at 8:54 AM, Laurent Pinchart wrote:
> > > > SH-Mobile platforms are transitioning from non-multiplatform to
> > > > multiplatform kernel. A new ARCH_SHMOBILE_MULTI configuration symbol has
> > > > been created to group all multiplatform-enabled SH-Mobile SoCs. The
> > > > existing ARCH_SHMOBILE configuration symbol groups SoCs that haven't
> > > > been converted yet.
> > > > 
> > > > This arrangement works fine for the arch/ code, but lots of drivers
> > > > needed on both ARCH_SHMOBILE and ARCH_SHMOBILE_MULTI depend on
> > > > ARCH_SHMOBILE only. In order to avoid changing them, rename
> > > > ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY, and create a new boolean
> > > > ARCH_SHMOBILE configuration symbol that is selected by both
> > > > ARCH_SHMOBILE_LEGACY and ARCH_SHMOBILE_MULTI.
> > > > 
> > > > Signed-off-by: Laurent Pinchart
> > > > <laurent.pinchart+renesas@ideasonboard.com>
> > > 
> > > Thanks, this looks good to me.
> > > 
> > > Acked-by: Magnus Damm <damm@opensource.se>
> > 
> > This seems reasonable to me.
> > I would pick it up now but it is marked as "RFC".
> > Please let me know if you wish me to pick it up.
> 
> I've sent a non-RFC series, please pick that one up.

Thanks, will do.

Re: [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY

[Laurent Pinchart]

Hi,

On Tuesday 12 November 2013 11:30:22 Simon Horman wrote:
> On Mon, Nov 11, 2013 at 09:45:12AM +0000, phil.edworthy@renesas.com wrote:
> > > On Friday 08 November 2013 14:57:29 stephen.lawrence@renesas.com wrote:
> > > > linux-sh-owner@vger.kernel.org wrote on 08/11/2013 06:08:05:
> > > > > On Thu, Nov 07, 2013 at 03:04:57PM +0900, Magnus Damm wrote:
> > > > > > On Thu, Nov 7, 2013 at 8:54 AM, Laurent Pinchart wrote:
> > > > > > > SH-Mobile platforms are transitioning from non-multiplatform to
> > > > > > > multiplatform kernel. A new ARCH_SHMOBILE_MULTI configuration
> > > > > > > symbol has been created to group all multiplatform-enabled SH-
> > > > > > > Mobile SoCs.
> > > > > > >
> > > > > > > The existing ARCH_SHMOBILE configuration symbol groups SoCs
> > > > > > > that haven't been converted yet.
> > > > 
> > > > I'm sure there are reasons for keeping it but looking forward I can't
> > > > help but wonder if this wouldn't be a good time to lose the SHMOBILE
> > > > tag for new platforms? It doesn't seem to be a great match to our
> > > > business or the architectures.
> > > > 
> > > > I know from conversations I've had in the last year or so that
> > > > external engineers working on R-Car sometimes do not find your good
> > > > work upstream as the combination of sh-mobile and using the product
> > > > number proved an effective method of concealment. Although of course
> > > > they could find it by searching the right files.
> > > 
> > > It's not a bad idea, but I'm not sure how we could proceed. SH-Mobile,
> > > R-Mobile and R-Car chipsets are all supported by a single code base, for
> > > which we need a name. Splitting the code base wouldn't make much sense
> > > from a technical point of view.
> > 
> > True, but it would be helpful to have Renesas in the device name
> > somewhere. Maybe include Renesas in the mach-shmobile/Kconfig description
> > for the devices, and also update the description in arm/Kconfig to
> > include R-Car.
> 
> Hi,
> 
> I have been involved in several discussions relating to moving away from
> the shmobile name.
> 
> Prior to this thread the most recent discussion I was involved in was with
> Olof Johansson, ARM-SoC co-maintainer, and Magnus. Due to the amount of
> churn involved in changing the name of the mach-shmobile directory or
> somehow splitting the code between multiple mach- directories, which was
> the variant of the topic under discussion, the consensus was that moving
> things around was not on the cards at this time.  There is also, as Laurent
> mentioned, the technical issue that splitting the code doesn't make a whole
> lot of sense from an implementation point of view.
> 
> From my point of view changing the SHMOBILE potion of ARCH_SHMOBILE_*
> only really makes sense if the name of mach-shmobile directory is changed
> in a similar way, which as I mentioned above that seems to be off the cards
> at this time. The reason I think this is that if the ARCH_XXX name doesn't
> match the directory we will add confusion rather than removing it.
> 
> With the above in mind I think that Phil's proposal to enhance the
> descriptions in mach-shmobile/Kconfig and arm/Kconfig is an excellent one
> given the hand of cards we have available to play.

Is someone going to submit a patch or should I do it ?

-- 
Regards,

Laurent Pinchart

Re: [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY

[phil.edworthy]

Hi Laurent,

> On Tuesday 12 November 2013 11:30:22 Simon Horman wrote:
> > On Mon, Nov 11, 2013 at 09:45:12AM +0000, phil.edworthy@renesas.com 
wrote:
> > > > On Friday 08 November 2013 14:57:29 stephen.lawrence@renesas.com 
wrote:
> > > > > linux-sh-owner@vger.kernel.org wrote on 08/11/2013 06:08:05:
> > > > > > On Thu, Nov 07, 2013 at 03:04:57PM +0900, Magnus Damm wrote:
> > > > > > > On Thu, Nov 7, 2013 at 8:54 AM, Laurent Pinchart wrote:
> > > > > > > > SH-Mobile platforms are transitioning from 
non-multiplatform to
> > > > > > > > multiplatform kernel. A new ARCH_SHMOBILE_MULTI 
configuration
> > > > > > > > symbol has been created to group all multiplatform-enabled 
SH-
> > > > > > > > Mobile SoCs.
> > > > > > > >
> > > > > > > > The existing ARCH_SHMOBILE configuration symbol groups 
SoCs
> > > > > > > > that haven't been converted yet.
> > > > > 
> > > > > I'm sure there are reasons for keeping it but looking forward I 
can't
> > > > > help but wonder if this wouldn't be a good time to lose the 
SHMOBILE
> > > > > tag for new platforms? It doesn't seem to be a great match to 
our
> > > > > business or the architectures.
> > > > > 
> > > > > I know from conversations I've had in the last year or so that
> > > > > external engineers working on R-Car sometimes do not find your 
good
> > > > > work upstream as the combination of sh-mobile and using the 
product
> > > > > number proved an effective method of concealment. Although of 
course
> > > > > they could find it by searching the right files.
> > > > 
> > > > It's not a bad idea, but I'm not sure how we could proceed. 
SH-Mobile,
> > > > R-Mobile and R-Car chipsets are all supported by a single code 
base, for
> > > > which we need a name. Splitting the code base wouldn't make much 
sense
> > > > from a technical point of view.
> > > 
> > > True, but it would be helpful to have Renesas in the device name
> > > somewhere. Maybe include Renesas in the mach-shmobile/Kconfig 
description
> > > for the devices, and also update the description in arm/Kconfig to
> > > include R-Car.
> > 
> > Hi,
> > 
> > I have been involved in several discussions relating to moving away 
from
> > the shmobile name.
> > 
> > Prior to this thread the most recent discussion I was involved in was 
with
> > Olof Johansson, ARM-SoC co-maintainer, and Magnus. Due to the amount 
of
> > churn involved in changing the name of the mach-shmobile directory or
> > somehow splitting the code between multiple mach- directories, which 
was
> > the variant of the topic under discussion, the consensus was that 
moving
> > things around was not on the cards at this time.  There is also, as 
Laurent
> > mentioned, the technical issue that splitting the code doesn't make a 
whole
> > lot of sense from an implementation point of view.
> > 
> > From my point of view changing the SHMOBILE potion of ARCH_SHMOBILE_*
> > only really makes sense if the name of mach-shmobile directory is 
changed
> > in a similar way, which as I mentioned above that seems to be off the 
cards
> > at this time. The reason I think this is that if the ARCH_XXX name 
doesn't
> > match the directory we will add confusion rather than removing it.
> > 
> > With the above in mind I think that Phil's proposal to enhance the
> > descriptions in mach-shmobile/Kconfig and arm/Kconfig is an excellent 
one
> > given the hand of cards we have available to play.
> 
> Is someone going to submit a patch or should I do it ?
I am more than happy for you to do it :)

Thanks
Phil

Re: [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY

[stephen.lawrence]

linux-sh-owner@vger.kernel.org wrote on 12/11/2013 02:30:22:

Hi Guys,

> From: Simon Horman <horms@verge.net.au>
> To: phil.edworthy@renesas.com, 
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>, SH-Linux 
<linux-
> sh@vger.kernel.org>, Magnus Damm <magnus.damm@gmail.com>, 
stephen.lawrence@renesas.com
> Date: 12/11/2013 02:30
> Subject: Re: [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to 
ARCH_SHMOBILE_LEGACY
> Sent by: linux-sh-owner@vger.kernel.org
> 
> On Mon, Nov 11, 2013 at 09:45:12AM +0000, phil.edworthy@renesas.com 
wrote:
> > Hi Laurent,
> > 
> > > On Friday 08 November 2013 14:57:29 stephen.lawrence@renesas.com 
wrote:
> > > > linux-sh-owner@vger.kernel.org wrote on 08/11/2013 06:08:05:
> > > > > On Thu, Nov 07, 2013 at 03:04:57PM +0900, Magnus Damm wrote:
> > > > > > On Thu, Nov 7, 2013 at 8:54 AM, Laurent Pinchart wrote:
> > > > > > > SH-Mobile platforms are transitioning from non-multiplatform 
to
> > > > > > > multiplatform kernel. A new ARCH_SHMOBILE_MULTI 
configuration 
> > symbol
> > > > > > > has been created to group all multiplatform-enabled 
SH-Mobile 
> > SoCs.
> > > > > > > The existing ARCH_SHMOBILE configuration symbol groups SoCs
> > > > > > > that haven't been converted yet.
> > > > 
> > > > I'm sure there are reasons for keeping it but looking forward I 
can't 
> > help
> > > > but wonder if this wouldn't be a good time to lose the SHMOBILE 
tag 
> > for
> > > > new platforms? It doesn't seem to be a great match to our business 
or 
> > the
> > > > architectures.
> > > > 
> > > > I know from conversations I've had in the last year or so that 
> > external
> > > > engineers working on R-Car sometimes do not find your good work 
> > upstream
> > > > as the combination of sh-mobile and using the product number 
proved
> > > > an effective method of concealment. Although of course they could
> > > > find it 
> > by
> > > > searching the right files.
> > > 
> > > It's not a bad idea, but I'm not sure how we could proceed. 
SH-Mobile, 
> > R-
> > > Mobile and R-Car chipsets are all supported by a single code base, 
for 
> > which 
> > > we need a name. Splitting the code base wouldn't make much sense 
from a
> > > technical point of view.
> > 
> > True, but it would be helpful to have Renesas in the device name
> > somewhere. Maybe include Renesas in the mach-shmobile/Kconfig 
description
> > for the devices, and also update the description in arm/Kconfig to
> > include R-Car.
> 
> Hi,
> 
> I have been involved in several discussions relating to moving away from
> the shmobile name.
> 
> Prior to this thread the most recent discussion I was involved in was 
with
> Olof Johansson, ARM-SoC co-maintainer, and Magnus. Due to the amount of
> churn involved in changing the name of the mach-shmobile directory or
> somehow splitting the code between multiple mach- directories, which was
> the variant of the topic under discussion, the consensus was that moving
> things around was not on the cards at this time.  There is also, as 
Laurent
> mentioned, the technical issue that splitting the code doesn't make a 
whole
> lot of sense from an implementation point of view.
> 
> From my point of view changing the SHMOBILE potion of ARCH_SHMOBILE_*
> only really makes sense if the name of mach-shmobile directory is 
changed
> in a similar way, which as I mentioned above that seems to be off the 
cards
> at this time. The reason I think this is that if the ARCH_XXX name 
doesn't
> match the directory we will add confusion rather than removing it.
> 
> With the above in mind I think that Phil's proposal to enhance
> the descriptions in mach-shmobile/Kconfig and arm/Kconfig is
> an excellent one given the hand of cards we have available to play.

Thanks for the responses and sorry for the delay in replying its been a 
very heavy week.

Unfortunately this is one of those cases where someone raises an issue 
without suggesting a good solution. I certainly don't think that having 
say a ARCH_RCAR with associated mach directory would be the answer. That 
series name could change in the future and would just lead to an over 
growing list, without the other considerations such as code sharing 
Laurent raised. I can't think of a good top level name that would cover 
all eventuality. Ultimately it was just a casual remark on my part that 
going forward SH and mobile was kind of a double negative, but of course 
the mobile side will be around for a while.

Personally I think someone can find R-Car fairly easily by searching the 
configs, but it was interesting a couple of engineers had asked me about 
it. I suspect this was just the result of a first quick look on their part 
and then they had come across me at some show so asked.

It's plain you've been discussing it, so if the current setup is the best 
compromise I'm happy with that. I would need to check but I'm pretty sure 
R-Car appears in the shmobile Kconfig, but perhaps not the arm one. If 
true I agree adding R-Car to the latter would help discovery I think. 
Thanks to Laurent for raising his hand on that one :)

Cheers,

Steve