mbox

[GIT,PULL] Renesas ARM Based SoC Updates for v4.1

Message ID cover.1424931398.git.horms+renesas@verge.net.au
State New
Headers show

Pull-request

git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-soc-for-v4.1

Message

Simon Horman Feb. 26, 2015, 6:22 a.m. UTC
Hi Olof, Hi Kevin, Hi Arnd,

Please consider these Renesas ARM based SoC updates for v4.1.

Some of these changes are arguably cleanups and could have
been queued up in the soc-cleanups-for-v4.1 branch. However,
I am reluctant to reshuffle things between branches at this point.


The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539:

  Linux 4.0-rc1 (2015-02-22 18:21:14 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-soc-for-v4.1

for you to fetch changes up to 72016d009e6bcf6cb6a289382bfc21185122b22e:

  ARM: shmobile: r8a7740: Remove restart callback (2015-02-24 08:02:49 +0900)

----------------------------------------------------------------
Renesas ARM Based SoC Updates for v4.1

* Remove restart callback from r8a7740 SoC
* Add support SOC_BUS to R-Car Gen2
* Expose SoCs revision data for R-Car Gen2
* Remove check for CONFIG_COMMON_CLK from R-Car Gen2 code as it is always set
* Allow R-Car Gen2 platforms to boot with CMA enabled and HIGHMEM disabled

----------------------------------------------------------------
Geert Uytterhoeven (2):
      ARM: shmobile: R-Car Gen2: CONFIG_COMMON_CLK is always set
      ARM: shmobile: r8a7740: Remove restart callback

Magnus Damm (1):
      ARM: shmobile: No R-Car Gen2 CMA reservation when HIGHMEM=n

Nobuhiro Iwamatsu (2):
      ARM: shmobile: Add function to get SoCs revision data for R-Car Gen2
      ARM: shmobile: Add support SOC_BUS to R-Car Gen2

 arch/arm/mach-shmobile/Kconfig           |  1 +
 arch/arm/mach-shmobile/rcar-gen2.h       |  1 +
 arch/arm/mach-shmobile/setup-r8a7740.c   |  8 -----
 arch/arm/mach-shmobile/setup-r8a7790.c   |  1 +
 arch/arm/mach-shmobile/setup-r8a7791.c   |  1 +
 arch/arm/mach-shmobile/setup-r8a7794.c   |  1 +
 arch/arm/mach-shmobile/setup-rcar-gen2.c | 58 +++++++++++++++++++++++++++++---
 7 files changed, 58 insertions(+), 13 deletions(-)

Comments

Arnd Bergmann Feb. 26, 2015, 3:53 p.m. UTC | #1
On Thursday 26 February 2015 15:22:44 Simon Horman wrote:
> From: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
> 
> This provides information through SOC_BUS to sysfs.
> And this moves all on-SoC devices from /sys/devices/platform to
> /sys/devices/socX/.
> 
> Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> ---
>  arch/arm/mach-shmobile/Kconfig           |  1 +
>  arch/arm/mach-shmobile/setup-rcar-gen2.c | 38 ++++++++++++++++++++++++++++----
>  2 files changed, 35 insertions(+), 4 deletions(-)

I think this would be better done as a standalone driver in drivers/soc,
to avoid having to add the init_machine callbacks in patch 3.


>  void __init rcar_gen2_init_machine(void)
>  {
> -	system_rev = rcar_gen2_get_cut();
> +	struct soc_device_attribute *soc_dev_attr;
> +	struct soc_device *soc_dev;
> +	struct device *parent = NULL;
> +	u32 prr;
> +
> +	soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
> +	if (!soc_dev_attr)
> +		goto out;
> +
> +	prr = rcar_gen2_get_prr();
> +	system_rev = (prr & 0xFF) + 0x10;
> +
> +	soc_dev_attr->machine = of_flat_dt_get_machine_name();

I would not duplicate that information here. Can you find out the SoC
name from registers and put it here?

	ARnd
Simon Horman Feb. 27, 2015, 12:52 a.m. UTC | #2
Hi Arnd,

On Thu, Feb 26, 2015 at 04:53:39PM +0100, Arnd Bergmann wrote:
> On Thursday 26 February 2015 15:22:44 Simon Horman wrote:
> > From: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
> > 
> > This provides information through SOC_BUS to sysfs.
> > And this moves all on-SoC devices from /sys/devices/platform to
> > /sys/devices/socX/.
> > 
> > Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
> > Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> > ---
> >  arch/arm/mach-shmobile/Kconfig           |  1 +
> >  arch/arm/mach-shmobile/setup-rcar-gen2.c | 38 ++++++++++++++++++++++++++++----
> >  2 files changed, 35 insertions(+), 4 deletions(-)
> 
> I think this would be better done as a standalone driver in drivers/soc,
> to avoid having to add the init_machine callbacks in patch 3.

Could we handle this as follow-up work?

> >  void __init rcar_gen2_init_machine(void)
> >  {
> > -	system_rev = rcar_gen2_get_cut();
> > +	struct soc_device_attribute *soc_dev_attr;
> > +	struct soc_device *soc_dev;
> > +	struct device *parent = NULL;
> > +	u32 prr;
> > +
> > +	soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
> > +	if (!soc_dev_attr)
> > +		goto out;
> > +
> > +	prr = rcar_gen2_get_prr();
> > +	system_rev = (prr & 0xFF) + 0x10;
> > +
> > +	soc_dev_attr->machine = of_flat_dt_get_machine_name();
> 
> I would not duplicate that information here. Can you find out the SoC
> name from registers and put it here?
> 
> 	ARnd
>
Arnd Bergmann Feb. 27, 2015, 9 a.m. UTC | #3
On Friday 27 February 2015 09:52:23 Simon Horman wrote:
> 
> On Thu, Feb 26, 2015 at 04:53:39PM +0100, Arnd Bergmann wrote:
> > On Thursday 26 February 2015 15:22:44 Simon Horman wrote:
> > > From: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
> > > 
> > > This provides information through SOC_BUS to sysfs.
> > > And this moves all on-SoC devices from /sys/devices/platform to
> > > /sys/devices/socX/.
> > > 
> > > Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
> > > Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> > > ---
> > >  arch/arm/mach-shmobile/Kconfig           |  1 +
> > >  arch/arm/mach-shmobile/setup-rcar-gen2.c | 38 ++++++++++++++++++++++++++++----
> > >  2 files changed, 35 insertions(+), 4 deletions(-)
> > 
> > I think this would be better done as a standalone driver in drivers/soc,
> > to avoid having to add the init_machine callbacks in patch 3.
> 
> Could we handle this as follow-up work?

That was my first idea when I looked at patch 3, but then I had the other
comment below:

> I would not duplicate that information here. Can you find out the SoC
> name from registers and put it here?

We must not introduce the user interface in one kernel and then change
it in the next one, so I'm cautious about taking the pull request in
the current form. Once we have agreed on what the contents of the sysfs
files should be, I can take the patches, and then we are free to move
the implementation later.

	Arnd
Geert Uytterhoeven Feb. 27, 2015, 10:41 a.m. UTC | #4
Hi Arnd,

On Fri, Feb 27, 2015 at 10:00 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 27 February 2015 09:52:23 Simon Horman wrote:
>>
>> On Thu, Feb 26, 2015 at 04:53:39PM +0100, Arnd Bergmann wrote:
>> > On Thursday 26 February 2015 15:22:44 Simon Horman wrote:
>> > > From: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
>> > >
>> > > This provides information through SOC_BUS to sysfs.
>> > > And this moves all on-SoC devices from /sys/devices/platform to
>> > > /sys/devices/socX/.
>> > >
>> > > Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
>> > > Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
>> > > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>> > > ---
>> > >  arch/arm/mach-shmobile/Kconfig           |  1 +
>> > >  arch/arm/mach-shmobile/setup-rcar-gen2.c | 38 ++++++++++++++++++++++++++++----
>> > >  2 files changed, 35 insertions(+), 4 deletions(-)
>> >
>> > I think this would be better done as a standalone driver in drivers/soc,
>> > to avoid having to add the init_machine callbacks in patch 3.
>>
>> Could we handle this as follow-up work?
>
> That was my first idea when I looked at patch 3, but then I had the other
> comment below:
>

>> > > +     soc_dev_attr->machine = of_flat_dt_get_machine_name();

>> I would not duplicate that information here. Can you find out the SoC
>> name from registers and put it here?
>
> We must not introduce the user interface in one kernel and then change
> it in the next one, so I'm cautious about taking the pull request in
> the current form. Once we have agreed on what the contents of the sysfs
> files should be, I can take the patches, and then we are free to move
> the implementation later.

Currently machine contains e.g. "Koelsch", which is the name of the board,
not of the SoC.

We can derive the SoC name from soc_id, e.g. 0x47 = "R-Car M2-W".

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
Arnd Bergmann Feb. 27, 2015, 1:44 p.m. UTC | #5
On Friday 27 February 2015 11:41:04 Geert Uytterhoeven wrote:
> > We must not introduce the user interface in one kernel and then change
> > it in the next one, so I'm cautious about taking the pull request in
> > the current form. Once we have agreed on what the contents of the sysfs
> > files should be, I can take the patches, and then we are free to move
> > the implementation later.
> 
> Currently machine contains e.g. "Koelsch", which is the name of the board,
> not of the SoC.
> 
> We can derive the SoC name from soc_id, e.g. 0x47 = "R-Car M2-W".
> 

Yes, I think that would be best.

	Arnd
Simon Horman March 1, 2015, 1:52 a.m. UTC | #6
On Fri, Feb 27, 2015 at 10:00:04AM +0100, Arnd Bergmann wrote:
> On Friday 27 February 2015 09:52:23 Simon Horman wrote:
> > 
> > On Thu, Feb 26, 2015 at 04:53:39PM +0100, Arnd Bergmann wrote:
> > > On Thursday 26 February 2015 15:22:44 Simon Horman wrote:
> > > > From: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
> > > > 
> > > > This provides information through SOC_BUS to sysfs.
> > > > And this moves all on-SoC devices from /sys/devices/platform to
> > > > /sys/devices/socX/.
> > > > 
> > > > Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
> > > > Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> > > > ---
> > > >  arch/arm/mach-shmobile/Kconfig           |  1 +
> > > >  arch/arm/mach-shmobile/setup-rcar-gen2.c | 38 ++++++++++++++++++++++++++++----
> > > >  2 files changed, 35 insertions(+), 4 deletions(-)
> > > 
> > > I think this would be better done as a standalone driver in drivers/soc,
> > > to avoid having to add the init_machine callbacks in patch 3.
> > 
> > Could we handle this as follow-up work?
> 
> That was my first idea when I looked at patch 3, but then I had the other
> comment below:
> 
> > I would not duplicate that information here. Can you find out the SoC
> > name from registers and put it here?
> 
> We must not introduce the user interface in one kernel and then change
> it in the next one, so I'm cautious about taking the pull request in
> the current form. Once we have agreed on what the contents of the sysfs
> files should be, I can take the patches, and then we are free to move
> the implementation later.

Thanks for the clarification. Accordingly I'd like to withdraw this pull
request: I will drop these patches.