All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Martin <dave.martin@linaro.org>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Mark Rutland <Mark.Rutland@arm.com>,
	Tomasz Figa <tomasz.figa@gmail.com>,
	"linux-samsung-soc@vger.kernel.org"
	<linux-samsung-soc@vger.kernel.org>,
	"kgene.kim@samsung.com" <kgene.kim@samsung.com>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"kwangwoo.lee@gmail.com" <kwangwoo.lee@gmail.com>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>,
	"broonie@opensource.wolfsonmicro.com"
	<broonie@opensource.wolfsonmicro.com>,
	"mcuelenaere@gmail.com" <mcuelenaere@gmail.com>,
	"augulis.darius@gmail.com" <augulis.darius@gmail.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 5/6] ARM: dts: Add basic dts include files for Samsung S3C64xx SoCs
Date: Wed, 16 Jan 2013 10:59:57 +0000	[thread overview]
Message-ID: <20130116105957.GA1963@linaro.org> (raw)
In-Reply-To: <20130114150531.GE21142@e102568-lin.cambridge.arm.com>

On Mon, Jan 14, 2013 at 03:05:32PM +0000, Lorenzo Pieralisi wrote:
> On Mon, Jan 14, 2013 at 02:48:41PM +0000, Mark Rutland wrote:
> > Hello,
> > 
> > This all looks good. I just have a couple of comments about the cpus node.
> > 
> > On Sun, Jan 13, 2013 at 01:10:57AM +0000, Tomasz Figa wrote:
> > > This patch adds basic device tree definitions for Samsung S3C64xx SoCs.
> > > 
> > > Since all the SoCs in the series are very similar, the files are created
> > > hierarchically - one file for the whole series and then separate files
> > > for particular SoCs including the common one.
> > > 
> > > Signed-off-by: Tomasz Figa <tomasz.figa@gmail.com>
> > 
> > [...]
> > 
> > > diff --git a/arch/arm/boot/dts/s3c64xx.dtsi b/arch/arm/boot/dts/s3c64xx.dtsi
> > > new file mode 100644
> > > index 0000000..55d6e08
> > > --- /dev/null
> > > +++ b/arch/arm/boot/dts/s3c64xx.dtsi
> > > @@ -0,0 +1,97 @@
> > > +/*
> > > + * Samsung's S3C64xx SoC series common device tree source
> > > + *
> > > + * Copyright (c) 2013 Tomasz Figa <tomasz.figa@gmail.com>
> > > + *
> > > + * Samsung's S3C64xx SoC series device nodes are listed in this file.
> > > + * Particular SoCs from S3C64xx series can include this file and provide
> > > + * values for SoCs specfic bindings.
> > > + *
> > > + * Note: This file does not include device nodes for all the controllers in
> > > + * S3C64xx SoCs. As device tree coverage for S3C64xx increases, additional
> > > + * nodes can be added to this file.
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License version 2 as
> > > + * published by the Free Software Foundation.
> > > + */
> > > +
> > > +/include/ "skeleton.dtsi"
> > > +
> > > +/ {
> > > +	cpus {
> > > +		cpu@0 {
> > > +			compatible = "arm,arm1176jzf-s";
> > > +		};
> > > +	};
> > 
> > You can drop the unit address from the cpu node - it's meant to be there to
> > differentiate multiple nodes (and is supposed to match the reg property, which
> > the 1176jzf-s can't have, as it doesn't have an MPIDR).
> 
> Well, this is a point that I should consider since the kernel docs I wrote are
> misleading, they require the reg property that can not be there on UP.
> True, MPIDR does not exist in this case, but I have to document this in the
> bindings since it is unclear.
> 
> > 
> > Also, "arm,arm1176jzf-s" isn't listed in the binding doc. There was a question
> > about how to maintain this list [1], but I can't seem to find a conclusion, if
> > any were reached.  It might be worth appending "arm,arm1176" to the compatible
> > list for the cpu node in case we want to enable something via dt for all 1176
> > variations.
> > 
> > Dave, Lorenzo, any thoughts?
> 
> Eh, frankly I do not know how to handle this. Either we add a compatible
> string to the bindings anytime a DT gets merged in the kernel but how
> to maintain it, it has to be defined. Happy to hear some feedback on
> this.

Well, the number of CPU types does not grow rapidly.  It will be much
less than one per SoC -- so keeping the list up to date shouldn't be
that much effort.

For ARM1176JZF-S, it could make sense for the comatible list to be

	"arm,arm1176jzf-s", "arm,arm1176"

...since the differences between 1176 variants are software probeable
(i.e., whether there is an FPU or not).  AFAIK the J, Z apply to all
ARM1176, and the -S (synthesisable RTL) is nothing to do with software.
The kernel probably only really needs to know "arm,arm1176".

Cheers
---Dave

> 
> Lorenzo
> 

WARNING: multiple messages have this Message-ID (diff)
From: dave.martin@linaro.org (Dave Martin)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 5/6] ARM: dts: Add basic dts include files for Samsung S3C64xx SoCs
Date: Wed, 16 Jan 2013 10:59:57 +0000	[thread overview]
Message-ID: <20130116105957.GA1963@linaro.org> (raw)
In-Reply-To: <20130114150531.GE21142@e102568-lin.cambridge.arm.com>

On Mon, Jan 14, 2013 at 03:05:32PM +0000, Lorenzo Pieralisi wrote:
> On Mon, Jan 14, 2013 at 02:48:41PM +0000, Mark Rutland wrote:
> > Hello,
> > 
> > This all looks good. I just have a couple of comments about the cpus node.
> > 
> > On Sun, Jan 13, 2013 at 01:10:57AM +0000, Tomasz Figa wrote:
> > > This patch adds basic device tree definitions for Samsung S3C64xx SoCs.
> > > 
> > > Since all the SoCs in the series are very similar, the files are created
> > > hierarchically - one file for the whole series and then separate files
> > > for particular SoCs including the common one.
> > > 
> > > Signed-off-by: Tomasz Figa <tomasz.figa@gmail.com>
> > 
> > [...]
> > 
> > > diff --git a/arch/arm/boot/dts/s3c64xx.dtsi b/arch/arm/boot/dts/s3c64xx.dtsi
> > > new file mode 100644
> > > index 0000000..55d6e08
> > > --- /dev/null
> > > +++ b/arch/arm/boot/dts/s3c64xx.dtsi
> > > @@ -0,0 +1,97 @@
> > > +/*
> > > + * Samsung's S3C64xx SoC series common device tree source
> > > + *
> > > + * Copyright (c) 2013 Tomasz Figa <tomasz.figa@gmail.com>
> > > + *
> > > + * Samsung's S3C64xx SoC series device nodes are listed in this file.
> > > + * Particular SoCs from S3C64xx series can include this file and provide
> > > + * values for SoCs specfic bindings.
> > > + *
> > > + * Note: This file does not include device nodes for all the controllers in
> > > + * S3C64xx SoCs. As device tree coverage for S3C64xx increases, additional
> > > + * nodes can be added to this file.
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License version 2 as
> > > + * published by the Free Software Foundation.
> > > + */
> > > +
> > > +/include/ "skeleton.dtsi"
> > > +
> > > +/ {
> > > +	cpus {
> > > +		cpu at 0 {
> > > +			compatible = "arm,arm1176jzf-s";
> > > +		};
> > > +	};
> > 
> > You can drop the unit address from the cpu node - it's meant to be there to
> > differentiate multiple nodes (and is supposed to match the reg property, which
> > the 1176jzf-s can't have, as it doesn't have an MPIDR).
> 
> Well, this is a point that I should consider since the kernel docs I wrote are
> misleading, they require the reg property that can not be there on UP.
> True, MPIDR does not exist in this case, but I have to document this in the
> bindings since it is unclear.
> 
> > 
> > Also, "arm,arm1176jzf-s" isn't listed in the binding doc. There was a question
> > about how to maintain this list [1], but I can't seem to find a conclusion, if
> > any were reached.  It might be worth appending "arm,arm1176" to the compatible
> > list for the cpu node in case we want to enable something via dt for all 1176
> > variations.
> > 
> > Dave, Lorenzo, any thoughts?
> 
> Eh, frankly I do not know how to handle this. Either we add a compatible
> string to the bindings anytime a DT gets merged in the kernel but how
> to maintain it, it has to be defined. Happy to hear some feedback on
> this.

Well, the number of CPU types does not grow rapidly.  It will be much
less than one per SoC -- so keeping the list up to date shouldn't be
that much effort.

For ARM1176JZF-S, it could make sense for the comatible list to be

	"arm,arm1176jzf-s", "arm,arm1176"

...since the differences between 1176 variants are software probeable
(i.e., whether there is an FPU or not).  AFAIK the J, Z apply to all
ARM1176, and the -S (synthesisable RTL) is nothing to do with software.
The kernel probably only really needs to know "arm,arm1176".

Cheers
---Dave

> 
> Lorenzo
> 

  reply	other threads:[~2013-01-16 11:00 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-13  1:10 [PATCH 0/6] Initial Device Tree support for S3C64xx Tomasz Figa
2013-01-13  1:10 ` Tomasz Figa
2013-01-13  1:10 ` [PATCH 1/6] ARM: common: vic: Parse interrupt and resume masks from device tree Tomasz Figa
2013-01-13  1:10   ` Tomasz Figa
2013-01-14  1:08   ` Rob Herring
2013-01-14  1:08     ` Rob Herring
2013-01-14 10:44     ` Tomasz Figa
2013-01-14 10:44       ` Tomasz Figa
2013-01-13  1:10 ` [PATCH 2/6] ARM: common: vic: Fix invalid first IRQ number in OF-based registration Tomasz Figa
2013-01-13  1:10   ` Tomasz Figa
2013-01-13  1:10 ` [PATCH 3/6] ARM: s3c64xx: Add support for OF-based VIC initialization Tomasz Figa
2013-01-13  1:10   ` Tomasz Figa
2013-01-13  1:10 ` [PATCH 4/6] ARM: s3c64xx: Add board file for boot using Device Tree Tomasz Figa
2013-01-13  1:10   ` Tomasz Figa
2013-01-13  1:10 ` [PATCH 5/6] ARM: dts: Add basic dts include files for Samsung S3C64xx SoCs Tomasz Figa
2013-01-13  1:10   ` Tomasz Figa
2013-01-14 14:48   ` Mark Rutland
2013-01-14 14:48     ` Mark Rutland
2013-01-14 15:05     ` Lorenzo Pieralisi
2013-01-14 15:05       ` Lorenzo Pieralisi
2013-01-16 10:59       ` Dave Martin [this message]
2013-01-16 10:59         ` Dave Martin
2013-01-25 19:08         ` Tomasz Figa
2013-01-25 19:08           ` Tomasz Figa
2013-01-25 19:15           ` Kukjin Kim
2013-01-25 19:15             ` Kukjin Kim
2013-01-28  9:02             ` Mark Rutland
2013-01-28  9:02               ` Mark Rutland
2013-01-28 13:04               ` Dave Martin
2013-01-28 13:04                 ` Dave Martin
2013-01-13  1:10 ` [PATCH 6/6] ARM: dts: Add dts file for S3C6410-based Mini6410 board Tomasz Figa
2013-01-13  1:10   ` Tomasz Figa
2013-01-25 19:09 ` [PATCH 0/6] Initial Device Tree support for S3C64xx Tomasz Figa
2013-01-25 19:09   ` Tomasz Figa
2013-01-25 19:25   ` Kukjin Kim
2013-01-25 19:25     ` Kukjin Kim

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=20130116105957.GA1963@linaro.org \
    --to=dave.martin@linaro.org \
    --cc=Mark.Rutland@arm.com \
    --cc=augulis.darius@gmail.com \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=kgene.kim@samsung.com \
    --cc=kwangwoo.lee@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mcuelenaere@gmail.com \
    --cc=tomasz.figa@gmail.com \
    /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.