* Re: [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY
2013-11-06 23:54 [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY Laurent Pinchart
@ 2013-11-07 6:04 ` Magnus Damm
2013-11-07 13:35 ` Laurent Pinchart
2013-11-08 6:08 ` Simon Horman
2013-11-08 14:57 ` stephen.lawrence
` (6 subsequent siblings)
7 siblings, 2 replies; 13+ messages in thread
From: Magnus Damm @ 2013-11-07 6:04 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY
2013-11-07 6:04 ` Magnus Damm
@ 2013-11-07 13:35 ` Laurent Pinchart
2013-11-08 6:08 ` Simon Horman
1 sibling, 0 replies; 13+ messages in thread
From: Laurent Pinchart @ 2013-11-07 13:35 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY
2013-11-07 6:04 ` Magnus Damm
2013-11-07 13:35 ` Laurent Pinchart
@ 2013-11-08 6:08 ` Simon Horman
2013-11-09 12:34 ` Laurent Pinchart
1 sibling, 1 reply; 13+ messages in thread
From: Simon Horman @ 2013-11-08 6:08 UTC (permalink / raw)
To: linux-arm-kernel
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
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY
2013-11-08 6:08 ` Simon Horman
@ 2013-11-09 12:34 ` Laurent Pinchart
2013-11-12 2:30 ` Simon Horman
0 siblings, 1 reply; 13+ messages in thread
From: Laurent Pinchart @ 2013-11-09 12:34 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY
2013-11-09 12:34 ` Laurent Pinchart
@ 2013-11-12 2:30 ` Simon Horman
0 siblings, 0 replies; 13+ messages in thread
From: Simon Horman @ 2013-11-12 2:30 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY
2013-11-06 23:54 [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY Laurent Pinchart
2013-11-07 6:04 ` Magnus Damm
@ 2013-11-08 14:57 ` stephen.lawrence
2013-11-09 12:39 ` Laurent Pinchart
` (5 subsequent siblings)
7 siblings, 0 replies; 13+ messages in thread
From: stephen.lawrence @ 2013-11-08 14:57 UTC (permalink / raw)
To: linux-sh
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
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY
2013-11-06 23:54 [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY Laurent Pinchart
2013-11-07 6:04 ` Magnus Damm
2013-11-08 14:57 ` stephen.lawrence
@ 2013-11-09 12:39 ` Laurent Pinchart
2013-11-11 9:45 ` phil.edworthy
` (4 subsequent siblings)
7 siblings, 0 replies; 13+ messages in thread
From: Laurent Pinchart @ 2013-11-09 12:39 UTC (permalink / raw)
To: linux-sh
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
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY
2013-11-06 23:54 [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY Laurent Pinchart
` (2 preceding siblings ...)
2013-11-09 12:39 ` Laurent Pinchart
@ 2013-11-11 9:45 ` phil.edworthy
2013-11-12 2:30 ` Simon Horman
` (3 subsequent siblings)
7 siblings, 0 replies; 13+ messages in thread
From: phil.edworthy @ 2013-11-11 9:45 UTC (permalink / raw)
To: linux-sh
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
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY
2013-11-06 23:54 [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY Laurent Pinchart
` (3 preceding siblings ...)
2013-11-11 9:45 ` phil.edworthy
@ 2013-11-12 2:30 ` Simon Horman
2013-11-13 2:50 ` Laurent Pinchart
` (2 subsequent siblings)
7 siblings, 0 replies; 13+ messages in thread
From: Simon Horman @ 2013-11-12 2:30 UTC (permalink / raw)
To: linux-sh
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY
2013-11-06 23:54 [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY Laurent Pinchart
` (4 preceding siblings ...)
2013-11-12 2:30 ` Simon Horman
@ 2013-11-13 2:50 ` Laurent Pinchart
2013-11-13 13:47 ` phil.edworthy
2013-11-14 12:04 ` stephen.lawrence
7 siblings, 0 replies; 13+ messages in thread
From: Laurent Pinchart @ 2013-11-13 2:50 UTC (permalink / raw)
To: linux-sh
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
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY
2013-11-06 23:54 [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY Laurent Pinchart
` (5 preceding siblings ...)
2013-11-13 2:50 ` Laurent Pinchart
@ 2013-11-13 13:47 ` phil.edworthy
2013-11-14 12:04 ` stephen.lawrence
7 siblings, 0 replies; 13+ messages in thread
From: phil.edworthy @ 2013-11-13 13:47 UTC (permalink / raw)
To: linux-sh
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
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY
2013-11-06 23:54 [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY Laurent Pinchart
` (6 preceding siblings ...)
2013-11-13 13:47 ` phil.edworthy
@ 2013-11-14 12:04 ` stephen.lawrence
7 siblings, 0 replies; 13+ messages in thread
From: stephen.lawrence @ 2013-11-14 12:04 UTC (permalink / raw)
To: linux-sh
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
^ permalink raw reply [flat|nested] 13+ messages in thread