From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 04/14] ARM: shmobile: sh73a0: Remove ->init_machine() special case
Date: Wed, 28 Aug 2013 12:08:24 +0000 [thread overview]
Message-ID: <1634183.WaD7XDSkzI@avalon> (raw)
In-Reply-To: <CANqRtoT1a7Ge2dBvNhAFK+Fpv_xC3QE_O-y6MxajwQfnbaVYHA@mail.gmail.com>
Hi Magnus,
On Wednesday 28 August 2013 15:40:50 Magnus Damm wrote:
> On Fri, Aug 9, 2013 at 7:47 PM, Laurent Pinchart wrote:
> > On Friday 09 August 2013 18:48:32 Magnus Damm wrote:
> >> From: Magnus Damm <damm@opensource.se>
> >>
> >> No need to special case sh73a0 ->init_machine(),
> >> so get rid of undesired cpufreq platform device
> >> from the generic long term sh73a0 DT support code.
> >>
> >> For short term support on KZM9D the DT reference
> >> implementation now adds a "cpufreq-cpu0" platform
> >> device so that can be used for development.
> >
> > Doesn't this go against the spirit of the -reference platforms that don't
> > use DT devices in board code ? I don't see an urgent need for this, how
> > far along are the DT cpufreq-related bindings ?
>
> I'm not sure what the latest state of DT cpufreq bindings are. Actually, it
> seems to me that the cpufreq platform device is a software policy that
> shouldn't be described with DT. And to be honest, I can't really see how
> this policy has anything to do with any particular SoC.
I'm no cpufreq expert, but if we need to register the device in C code, I'm
pretty uneasy with having that code in board files. One of the DT goals is to
get rid of most board files.
> Regarding MACHINE_START on mach-shmobile I'd like to have 3 levels:
>
> 1) MACHINE_START in setup-xxxx.c
>
> This is where we aim to be in the long term. We should be as
> theoretically correct as ever possible here. I'd like to avoid all
> platform devices here. Also, I'd like to avoid short term random
> policy setting here.
>
> 2) MACHINE_START in board-xxx-reference.c
>
> This is where we build DT support for the board. In case we don't have
> DT bindings for a certain device then using platform device here is
> acceptable. Other short term workarounds are also acceptable here.
>
> 3) MACHINE_START in board-xxx.c
>
> This is the location of the C-based board support. Some SoC-specific
> bits like CPU cores and interrupt controllers may be initialized via
> DT. Otherwise platform devices are used.
>
> Hope this clarifies my view!
--
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 04/14] ARM: shmobile: sh73a0: Remove ->init_machine() special case
Date: Wed, 28 Aug 2013 14:08:24 +0200 [thread overview]
Message-ID: <1634183.WaD7XDSkzI@avalon> (raw)
In-Reply-To: <CANqRtoT1a7Ge2dBvNhAFK+Fpv_xC3QE_O-y6MxajwQfnbaVYHA@mail.gmail.com>
Hi Magnus,
On Wednesday 28 August 2013 15:40:50 Magnus Damm wrote:
> On Fri, Aug 9, 2013 at 7:47 PM, Laurent Pinchart wrote:
> > On Friday 09 August 2013 18:48:32 Magnus Damm wrote:
> >> From: Magnus Damm <damm@opensource.se>
> >>
> >> No need to special case sh73a0 ->init_machine(),
> >> so get rid of undesired cpufreq platform device
> >> from the generic long term sh73a0 DT support code.
> >>
> >> For short term support on KZM9D the DT reference
> >> implementation now adds a "cpufreq-cpu0" platform
> >> device so that can be used for development.
> >
> > Doesn't this go against the spirit of the -reference platforms that don't
> > use DT devices in board code ? I don't see an urgent need for this, how
> > far along are the DT cpufreq-related bindings ?
>
> I'm not sure what the latest state of DT cpufreq bindings are. Actually, it
> seems to me that the cpufreq platform device is a software policy that
> shouldn't be described with DT. And to be honest, I can't really see how
> this policy has anything to do with any particular SoC.
I'm no cpufreq expert, but if we need to register the device in C code, I'm
pretty uneasy with having that code in board files. One of the DT goals is to
get rid of most board files.
> Regarding MACHINE_START on mach-shmobile I'd like to have 3 levels:
>
> 1) MACHINE_START in setup-xxxx.c
>
> This is where we aim to be in the long term. We should be as
> theoretically correct as ever possible here. I'd like to avoid all
> platform devices here. Also, I'd like to avoid short term random
> policy setting here.
>
> 2) MACHINE_START in board-xxx-reference.c
>
> This is where we build DT support for the board. In case we don't have
> DT bindings for a certain device then using platform device here is
> acceptable. Other short term workarounds are also acceptable here.
>
> 3) MACHINE_START in board-xxx.c
>
> This is the location of the C-based board support. Some SoC-specific
> bits like CPU cores and interrupt controllers may be initialized via
> DT. Otherwise platform devices are used.
>
> Hope this clarifies my view!
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2013-08-28 12:08 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-09 9:47 [PATCH 00/14] ARM: shmobile: Cleanups and machine descriptor rework Magnus Damm
2013-08-09 9:47 ` Magnus Damm
2013-08-09 9:47 ` [PATCH 01/14] ARM: shmobile: r8a7779: Remove ->init_machine() special case Magnus Damm
2013-08-09 9:47 ` Magnus Damm
2013-08-09 9:48 ` [PATCH 02/14] ARM: shmobile: r8a7740: " Magnus Damm
2013-08-09 9:48 ` Magnus Damm
2013-08-09 9:48 ` [PATCH 03/14] ARM: shmobile: sh7372: " Magnus Damm
2013-08-09 9:48 ` Magnus Damm
2013-08-09 9:48 ` [PATCH 04/14] ARM: shmobile: sh73a0: " Magnus Damm
2013-08-09 9:48 ` Magnus Damm
2013-08-09 10:47 ` Laurent Pinchart
2013-08-09 10:47 ` Laurent Pinchart
2013-08-28 6:40 ` Magnus Damm
2013-08-28 6:40 ` Magnus Damm
2013-08-28 12:08 ` Laurent Pinchart [this message]
2013-08-28 12:08 ` Laurent Pinchart
2013-08-28 12:19 ` Magnus Damm
2013-08-28 12:19 ` Magnus Damm
2013-08-30 0:30 ` Laurent Pinchart
2013-08-30 0:30 ` Laurent Pinchart
2013-08-30 6:58 ` Magnus Damm
2013-08-30 6:58 ` Magnus Damm
2013-08-09 9:48 ` [PATCH 05/14] ARM: shmobile: Remove r8a7740_add_early_devices_dt() Magnus Damm
2013-08-09 9:48 ` Magnus Damm
2013-08-09 9:48 ` [PATCH 06/14] ARM: shmobile: Remove sh73a0_init_irq_dt() Magnus Damm
2013-08-09 9:48 ` Magnus Damm
2013-08-09 9:49 ` [PATCH 07/14] ARM: shmobile: Remove r8a7779 ->nr_irqs Magnus Damm
2013-08-09 9:49 ` Magnus Damm
2013-08-09 9:49 ` [PATCH 08/14] ARM: shmobile: Remove sh73a0 ->nr_irqs Magnus Damm
2013-08-09 9:49 ` Magnus Damm
2013-08-09 9:49 ` [PATCH 09/14] ARM: shmobile: Rename to sh7372_init_early() Magnus Damm
2013-08-09 9:49 ` Magnus Damm
2013-08-09 10:40 ` Laurent Pinchart
2013-08-09 10:40 ` Laurent Pinchart
2013-08-09 9:49 ` [PATCH 10/14] ARM: shmobile: Rename to emev2_init_early(), use smp_set_ops() Magnus Damm
2013-08-09 9:49 ` Magnus Damm
2013-08-09 10:41 ` Laurent Pinchart
2013-08-09 10:41 ` Laurent Pinchart
2013-08-28 7:03 ` Magnus Damm
2013-08-28 7:03 ` Magnus Damm
2013-08-28 7:53 ` Laurent Pinchart
2013-08-28 7:53 ` Laurent Pinchart
2013-08-09 9:49 ` [PATCH 11/14] ARM: shmobile: Rename to r8a7779_init_early(), " Magnus Damm
2013-08-09 9:49 ` Magnus Damm
2013-08-09 9:49 ` [PATCH 12/14] ARM: shmobile: Rename to r8a7740_init_early() Magnus Damm
2013-08-09 9:49 ` Magnus Damm
2013-08-09 9:50 ` [PATCH 13/14] ARM: shmobile: Rename to r8a7778_init_early() Magnus Damm
2013-08-09 9:50 ` Magnus Damm
2013-08-09 9:50 ` [PATCH 14/14] ARM: shmobile: Rename to sh73a0_init_early(), use smp_set_ops() Magnus Damm
2013-08-09 9:50 ` Magnus Damm
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=1634183.WaD7XDSkzI@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.