All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY
Date: Thu, 07 Nov 2013 13:35:33 +0000	[thread overview]
Message-ID: <1696243.pS6uAl3J52@avalon> (raw)
In-Reply-To: <CANqRtoRDo6_VYhaq9KkSCo2TnhmwW-vFK99HuBS=umrC1_fD_g@mail.gmail.com>

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


WARNING: multiple messages have this Message-ID (diff)
From: laurent.pinchart@ideasonboard.com (Laurent Pinchart)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY
Date: Thu, 07 Nov 2013 14:35:33 +0100	[thread overview]
Message-ID: <1696243.pS6uAl3J52@avalon> (raw)
In-Reply-To: <CANqRtoRDo6_VYhaq9KkSCo2TnhmwW-vFK99HuBS=umrC1_fD_g@mail.gmail.com>

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=100 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

  reply	other threads:[~2013-11-07 13:35 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-06 23:54 [PATCH/RFC] ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY Laurent Pinchart
2013-11-06 23:54 ` Laurent Pinchart
2013-11-07  6:04 ` Magnus Damm
2013-11-07  6:04   ` Magnus Damm
2013-11-07 13:35   ` Laurent Pinchart [this message]
2013-11-07 13:35     ` Laurent Pinchart
2013-11-08  6:08   ` Simon Horman
2013-11-08  6:08     ` Simon Horman
2013-11-09 12:34     ` Laurent Pinchart
2013-11-09 12:34       ` Laurent Pinchart
2013-11-12  2:30       ` Simon Horman
2013-11-12  2:30         ` Simon Horman
2013-11-08 14:57 ` stephen.lawrence
2013-11-09 12:39 ` Laurent Pinchart
2013-11-11  9:45 ` phil.edworthy
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1696243.pS6uAl3J52@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.