diff mbox

[v3,3/3] ARM: mach-shmobile: r8a7740: Setup the serial devices using DT

Message ID 1361898208-6683-3-git-send-email-hechtb+renesas@gmail.com (mailing list archive)
State Superseded
Headers show

Commit Message

Bastian Hecht Feb. 26, 2013, 5:03 p.m. UTC
We can now use the Device Tree for bringing up our serial devices. We
need to add an alternative early_devices list in setup-r8a7740 without
the serial devices and move them into the Armadillo-reference .dts config file.

Signed-off-by: Bastian Hecht <hechtb+renesas@gmail.com>
---
v3:
no changes

 .../boot/dts/r8a7740-armadillo800eva-reference.dts |   94 ++++++++++++++++++++
 arch/arm/mach-shmobile/setup-r8a7740.c             |   15 +++-
 2 files changed, 105 insertions(+), 4 deletions(-)

Comments

Simon Horman March 1, 2013, 9:42 a.m. UTC | #1
On Tue, Feb 26, 2013 at 11:03:28AM -0600, Bastian Hecht wrote:
> We can now use the Device Tree for bringing up our serial devices. We
> need to add an alternative early_devices list in setup-r8a7740 without
> the serial devices and move them into the Armadillo-reference .dts config file.

Hi Bastian,

could you please refresh this patch on top of the current topic/intc-of.
In particular, it conflicts with changes made by:

ARM: shmobile: r8a7740: Do not use early devices with DT reference
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Bastian Hecht March 1, 2013, 4:21 p.m. UTC | #2
2013/3/1 Simon Horman <horms@verge.net.au>:
> On Tue, Feb 26, 2013 at 11:03:28AM -0600, Bastian Hecht wrote:
>> We can now use the Device Tree for bringing up our serial devices. We
>> need to add an alternative early_devices list in setup-r8a7740 without
>> the serial devices and move them into the Armadillo-reference .dts config file.
>
> Hi Bastian,
>
> could you please refresh this patch on top of the current topic/intc-of.
> In particular, it conflicts with changes made by:
>
> ARM: shmobile: r8a7740: Do not use early devices with DT reference

Sure.

I've prepared the patch - but I start to wonder if the DT
specification for the SCIF devices should go into r8a7740.dtsi rather
than r8a7740-armadillo-reference.dts. So far it's included in
setup-r8a7740.c and not in the board code - that's a strong indication
for it, no?
I want to post a patchset for the CMT timer soon. There it's the same.

Cheers,

 Bastian
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Simon Horman March 2, 2013, 1:31 a.m. UTC | #3
On Fri, Mar 01, 2013 at 10:21:27AM -0600, Bastian Hecht wrote:
> 2013/3/1 Simon Horman <horms@verge.net.au>:
> > On Tue, Feb 26, 2013 at 11:03:28AM -0600, Bastian Hecht wrote:
> >> We can now use the Device Tree for bringing up our serial devices. We
> >> need to add an alternative early_devices list in setup-r8a7740 without
> >> the serial devices and move them into the Armadillo-reference .dts config file.
> >
> > Hi Bastian,
> >
> > could you please refresh this patch on top of the current topic/intc-of.
> > In particular, it conflicts with changes made by:
> >
> > ARM: shmobile: r8a7740: Do not use early devices with DT reference
> 
> Sure.
> 
> I've prepared the patch - but I start to wonder if the DT
> specification for the SCIF devices should go into r8a7740.dtsi rather
> than r8a7740-armadillo-reference.dts. So far it's included in
> setup-r8a7740.c and not in the board code - that's a strong indication
> for it, no?

I forget exactly how the discussion went, but for the kzm9g the
SDHI has ended up in the dts file for the board not the sh73a0 SoC.

So I assume that r8a7740-armadillo-reference.dts is the correct place
for SDHI on the armadillo.

Magnus, can you confirm that SDHI belongs to the board not the SoC?

> I want to post a patchset for the CMT timer soon. There it's the same.

Magnus, could you also let us know if CMT should go in the board or SoC dts?
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Magnus Damm March 4, 2013, 12:48 p.m. UTC | #4
Hi Simon,

[Added Guennadi to CC]

On Sat, Mar 2, 2013 at 10:31 AM, Simon Horman <horms@verge.net.au> wrote:
> On Fri, Mar 01, 2013 at 10:21:27AM -0600, Bastian Hecht wrote:
>> 2013/3/1 Simon Horman <horms@verge.net.au>:
>> > On Tue, Feb 26, 2013 at 11:03:28AM -0600, Bastian Hecht wrote:
>> >> We can now use the Device Tree for bringing up our serial devices. We
>> >> need to add an alternative early_devices list in setup-r8a7740 without
>> >> the serial devices and move them into the Armadillo-reference .dts config file.
>> >
>> > Hi Bastian,
>> >
>> > could you please refresh this patch on top of the current topic/intc-of.
>> > In particular, it conflicts with changes made by:
>> >
>> > ARM: shmobile: r8a7740: Do not use early devices with DT reference
>>
>> Sure.
>>
>> I've prepared the patch - but I start to wonder if the DT
>> specification for the SCIF devices should go into r8a7740.dtsi rather
>> than r8a7740-armadillo-reference.dts. So far it's included in
>> setup-r8a7740.c and not in the board code - that's a strong indication
>> for it, no?
>
> I forget exactly how the discussion went, but for the kzm9g the
> SDHI has ended up in the dts file for the board not the sh73a0 SoC.
>
> So I assume that r8a7740-armadillo-reference.dts is the correct place
> for SDHI on the armadillo.
>
> Magnus, can you confirm that SDHI belongs to the board not the SoC?

What does the data sheet say?

The SDHI hardware block is included in the SoC. It may however need
some board specific configuration. I believe the correct way is to
define the common parts in the SoC-specific dtsi file and add
board-specific configuration in the board-specific dts file. Perhaps
you can consult Guennadi about this, he has been tasked with SDHI and
MMCIF.

>> I want to post a patchset for the CMT timer soon. There it's the same.
>
> Magnus, could you also let us know if CMT should go in the board or SoC dts?

In the SoC. As a general rule, if there is a platform device in
setup-nnnn.c then the device does not need any board specific
configuration. Such devices should be put in the SoC-specific dtsi
file.

Thanks,

/ magnus
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Guennadi Liakhovetski March 4, 2013, 1:33 p.m. UTC | #5
Hi

On Mon, 4 Mar 2013, Magnus Damm wrote:

> Hi Simon,
> 
> [Added Guennadi to CC]
> 
> On Sat, Mar 2, 2013 at 10:31 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Fri, Mar 01, 2013 at 10:21:27AM -0600, Bastian Hecht wrote:
> >> 2013/3/1 Simon Horman <horms@verge.net.au>:
> >> > On Tue, Feb 26, 2013 at 11:03:28AM -0600, Bastian Hecht wrote:
> >> >> We can now use the Device Tree for bringing up our serial devices. We
> >> >> need to add an alternative early_devices list in setup-r8a7740 without
> >> >> the serial devices and move them into the Armadillo-reference .dts config file.
> >> >
> >> > Hi Bastian,
> >> >
> >> > could you please refresh this patch on top of the current topic/intc-of.
> >> > In particular, it conflicts with changes made by:
> >> >
> >> > ARM: shmobile: r8a7740: Do not use early devices with DT reference
> >>
> >> Sure.
> >>
> >> I've prepared the patch - but I start to wonder if the DT
> >> specification for the SCIF devices should go into r8a7740.dtsi rather
> >> than r8a7740-armadillo-reference.dts. So far it's included in
> >> setup-r8a7740.c and not in the board code - that's a strong indication
> >> for it, no?
> >
> > I forget exactly how the discussion went, but for the kzm9g the
> > SDHI has ended up in the dts file for the board not the sh73a0 SoC.
> >
> > So I assume that r8a7740-armadillo-reference.dts is the correct place
> > for SDHI on the armadillo.
> >
> > Magnus, can you confirm that SDHI belongs to the board not the SoC?
> 
> What does the data sheet say?
> 
> The SDHI hardware block is included in the SoC. It may however need
> some board specific configuration. I believe the correct way is to
> define the common parts in the SoC-specific dtsi file and add
> board-specific configuration in the board-specific dts file. Perhaps
> you can consult Guennadi about this, he has been tasked with SDHI and
> MMCIF.

That would be the best, I agree. However, we discussed this already on the 
example of mmcif, you might remember. I asked what's the difference 
between extending a DT node (from .dtsi) with additional properties (in a 
board-specific .dts) using an "&phandle" syntax and a full path? Or are 
they equivalent? There was no reply, so, for such nodes (MMC/SD) I so far 
settled with complete nodes in .dts. We do use the "&phandle" syntax for 
pinctrl function groups, for I2C devices. I used a complete path for 
CPUFreq... Mostly because other platforms did that too.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Bastian Hecht March 4, 2013, 3:44 p.m. UTC | #6
Hi Simon!

2013/3/4 Magnus Damm <magnus.damm@gmail.com>:
> Hi Simon,
>
> [Added Guennadi to CC]
>
> On Sat, Mar 2, 2013 at 10:31 AM, Simon Horman <horms@verge.net.au> wrote:
>> On Fri, Mar 01, 2013 at 10:21:27AM -0600, Bastian Hecht wrote:
>>> 2013/3/1 Simon Horman <horms@verge.net.au>:
>>> > On Tue, Feb 26, 2013 at 11:03:28AM -0600, Bastian Hecht wrote:
>>> >> We can now use the Device Tree for bringing up our serial devices. We
>>> >> need to add an alternative early_devices list in setup-r8a7740 without
>>> >> the serial devices and move them into the Armadillo-reference .dts config file.
>>> >
>>> > Hi Bastian,
>>> >
>>> > could you please refresh this patch on top of the current topic/intc-of.
>>> > In particular, it conflicts with changes made by:
>>> >
>>> > ARM: shmobile: r8a7740: Do not use early devices with DT reference
>>>
>>> Sure.
>>>
>>> I've prepared the patch - but I start to wonder if the DT
>>> specification for the SCIF devices should go into r8a7740.dtsi rather
>>> than r8a7740-armadillo-reference.dts. So far it's included in
>>> setup-r8a7740.c and not in the board code - that's a strong indication
>>> for it, no?
>>
>> I forget exactly how the discussion went, but for the kzm9g the
>> SDHI has ended up in the dts file for the board not the sh73a0 SoC.
>>
>> So I assume that r8a7740-armadillo-reference.dts is the correct place
>> for SDHI on the armadillo.
>>
>> Magnus, can you confirm that SDHI belongs to the board not the SoC?
>
> What does the data sheet say?
>
> The SDHI hardware block is included in the SoC. It may however need
> some board specific configuration. I believe the correct way is to
> define the common parts in the SoC-specific dtsi file and add
> board-specific configuration in the board-specific dts file. Perhaps
> you can consult Guennadi about this, he has been tasked with SDHI and
> MMCIF.
>
>>> I want to post a patchset for the CMT timer soon. There it's the same.
>>
>> Magnus, could you also let us know if CMT should go in the board or SoC dts?
>
> In the SoC. As a general rule, if there is a platform device in
> setup-nnnn.c then the device does not need any board specific
> configuration. Such devices should be put in the SoC-specific dtsi
> file.

Ok I posted a v4 SCIF DT patchset putting the SCIF devices into r8a7740.dtsi.

Simon, are you aware about this in topic/intc-of? It shows up booting
the non-DT version.

Unable to handle kernel NULL pointer dereference at virtual address 00000040
pgd = c0004000
[00000040] *pgd=00000000
Internal error: Oops: 5 [#1] ARM
CPU: 0    Not tainted  (3.8.0-rc3-00205-gfb2696a #298)
PC is at __gpio_get_value+0x18/0x5c
LR is at eva_init+0x190/0x544

We should add standard bootargs in the r8a7740-armadillo800eva.dts as
well. Shall I post a small patch?

Thanks,

 Bastian


> Thanks,
>
> / magnus
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Simon Horman March 5, 2013, 3:27 a.m. UTC | #7
On Mon, Mar 04, 2013 at 02:33:40PM +0100, Guennadi Liakhovetski wrote:
> Hi
> 
> On Mon, 4 Mar 2013, Magnus Damm wrote:
> 
> > Hi Simon,
> > 
> > [Added Guennadi to CC]
> > 
> > On Sat, Mar 2, 2013 at 10:31 AM, Simon Horman <horms@verge.net.au> wrote:
> > > On Fri, Mar 01, 2013 at 10:21:27AM -0600, Bastian Hecht wrote:
> > >> 2013/3/1 Simon Horman <horms@verge.net.au>:
> > >> > On Tue, Feb 26, 2013 at 11:03:28AM -0600, Bastian Hecht wrote:
> > >> >> We can now use the Device Tree for bringing up our serial devices. We
> > >> >> need to add an alternative early_devices list in setup-r8a7740 without
> > >> >> the serial devices and move them into the Armadillo-reference .dts config file.
> > >> >
> > >> > Hi Bastian,
> > >> >
> > >> > could you please refresh this patch on top of the current topic/intc-of.
> > >> > In particular, it conflicts with changes made by:
> > >> >
> > >> > ARM: shmobile: r8a7740: Do not use early devices with DT reference
> > >>
> > >> Sure.
> > >>
> > >> I've prepared the patch - but I start to wonder if the DT
> > >> specification for the SCIF devices should go into r8a7740.dtsi rather
> > >> than r8a7740-armadillo-reference.dts. So far it's included in
> > >> setup-r8a7740.c and not in the board code - that's a strong indication
> > >> for it, no?
> > >
> > > I forget exactly how the discussion went, but for the kzm9g the
> > > SDHI has ended up in the dts file for the board not the sh73a0 SoC.
> > >
> > > So I assume that r8a7740-armadillo-reference.dts is the correct place
> > > for SDHI on the armadillo.
> > >
> > > Magnus, can you confirm that SDHI belongs to the board not the SoC?
> > 
> > What does the data sheet say?
> > 
> > The SDHI hardware block is included in the SoC. It may however need
> > some board specific configuration. I believe the correct way is to
> > define the common parts in the SoC-specific dtsi file and add
> > board-specific configuration in the board-specific dts file. Perhaps
> > you can consult Guennadi about this, he has been tasked with SDHI and
> > MMCIF.
> 
> That would be the best, I agree. However, we discussed this already on the 
> example of mmcif, you might remember. I asked what's the difference 
> between extending a DT node (from .dtsi) with additional properties (in a 
> board-specific .dts) using an "&phandle" syntax and a full path? Or are 
> they equivalent? There was no reply, so, for such nodes (MMC/SD) I so far 
> settled with complete nodes in .dts. We do use the "&phandle" syntax for 
> pinctrl function groups, for I2C devices. I used a complete path for 
> CPUFreq... Mostly because other platforms did that too.

I am confused.

Using phandle syntax we can add a device to an soc's dtsi file and then add
extra properties in the board file.  This seems to be match the HW well.

What is your alternate suggestion?
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Simon Horman March 5, 2013, 3:36 a.m. UTC | #8
On Mon, Mar 04, 2013 at 04:44:30PM +0100, Bastian Hecht wrote:
> Hi Simon!
> 
> 2013/3/4 Magnus Damm <magnus.damm@gmail.com>:
> > Hi Simon,
> >
> > [Added Guennadi to CC]
> >
> > On Sat, Mar 2, 2013 at 10:31 AM, Simon Horman <horms@verge.net.au> wrote:
> >> On Fri, Mar 01, 2013 at 10:21:27AM -0600, Bastian Hecht wrote:
> >>> 2013/3/1 Simon Horman <horms@verge.net.au>:
> >>> > On Tue, Feb 26, 2013 at 11:03:28AM -0600, Bastian Hecht wrote:
> >>> >> We can now use the Device Tree for bringing up our serial devices. We
> >>> >> need to add an alternative early_devices list in setup-r8a7740 without
> >>> >> the serial devices and move them into the Armadillo-reference .dts config file.
> >>> >
> >>> > Hi Bastian,
> >>> >
> >>> > could you please refresh this patch on top of the current topic/intc-of.
> >>> > In particular, it conflicts with changes made by:
> >>> >
> >>> > ARM: shmobile: r8a7740: Do not use early devices with DT reference
> >>>
> >>> Sure.
> >>>
> >>> I've prepared the patch - but I start to wonder if the DT
> >>> specification for the SCIF devices should go into r8a7740.dtsi rather
> >>> than r8a7740-armadillo-reference.dts. So far it's included in
> >>> setup-r8a7740.c and not in the board code - that's a strong indication
> >>> for it, no?
> >>
> >> I forget exactly how the discussion went, but for the kzm9g the
> >> SDHI has ended up in the dts file for the board not the sh73a0 SoC.
> >>
> >> So I assume that r8a7740-armadillo-reference.dts is the correct place
> >> for SDHI on the armadillo.
> >>
> >> Magnus, can you confirm that SDHI belongs to the board not the SoC?
> >
> > What does the data sheet say?
> >
> > The SDHI hardware block is included in the SoC. It may however need
> > some board specific configuration. I believe the correct way is to
> > define the common parts in the SoC-specific dtsi file and add
> > board-specific configuration in the board-specific dts file. Perhaps
> > you can consult Guennadi about this, he has been tasked with SDHI and
> > MMCIF.
> >
> >>> I want to post a patchset for the CMT timer soon. There it's the same.
> >>
> >> Magnus, could you also let us know if CMT should go in the board or SoC dts?
> >
> > In the SoC. As a general rule, if there is a platform device in
> > setup-nnnn.c then the device does not need any board specific
> > configuration. Such devices should be put in the SoC-specific dtsi
> > file.
> 
> Ok I posted a v4 SCIF DT patchset putting the SCIF devices into r8a7740.dtsi.
> 
> Simon, are you aware about this in topic/intc-of? It shows up booting
> the non-DT version.
> 
> Unable to handle kernel NULL pointer dereference at virtual address 00000040
> pgd = c0004000
> [00000040] *pgd=00000000
> Internal error: Oops: 5 [#1] ARM
> CPU: 0    Not tainted  (3.8.0-rc3-00205-gfb2696a #298)
> PC is at __gpio_get_value+0x18/0x5c
> LR is at eva_init+0x190/0x544

Yes, I am aware of it, it is the reason that topic/intc-of is
not included in topic/all+next at the moment.

I believe it is caused by SH pinctl DT support.

http://permalink.gmane.org/gmane.linux.ports.sh.devel/19649


> We should add standard bootargs in the r8a7740-armadillo800eva.dts as
> well. Shall I post a small patch?

I have applied a patch to do that which should be present in v3.9-rc1.

Now that v3.9-rc1 has been released I will see about rebasing my
branches on top of it.
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Guennadi Liakhovetski March 5, 2013, 6:52 a.m. UTC | #9
Hi Simon

On Tue, 5 Mar 2013, Simon Horman wrote:

> On Mon, Mar 04, 2013 at 02:33:40PM +0100, Guennadi Liakhovetski wrote:

[snip]

> > That would be the best, I agree. However, we discussed this already on the 
> > example of mmcif, you might remember. I asked what's the difference 
> > between extending a DT node (from .dtsi) with additional properties (in a 
> > board-specific .dts) using an "&phandle" syntax and a full path? Or are 
> > they equivalent? There was no reply, so, for such nodes (MMC/SD) I so far 
> > settled with complete nodes in .dts. We do use the "&phandle" syntax for 
> > pinctrl function groups, for I2C devices. I used a complete path for 
> > CPUFreq... Mostly because other platforms did that too.
> 
> I am confused.
> 
> Using phandle syntax we can add a device to an soc's dtsi file and then add
> extra properties in the board file.  This seems to be match the HW well.
> 
> What is your alternate suggestion?

Let me give you examples. In sh73a0-reference.dtsi we define an I2C device 
#0:

	i2c0: i2c@0xe6820000 {
		#address-cells = <1>;
		#size-cells = <0>;
		compatible = "renesas,rmobile-iic";
		reg = <0xe6820000 0x425>;
		...
	};

Then in sh73a0-kzm9g-reference.dts I can use the phandle syntax to put 
devices on that I2C bus:

&i2c0 {
	as3711@40 {
		compatible = "ams,as3711";
		reg = <0x40>;
		...
	};
	...
};

This is one possibility. In sh73a0.dtsi we've got

	cpus {
		#address-cells = <1>;
		#size-cells = <0>;

		cpu@0 {
			device_type = "cpu";
			compatible = "arm,cortex-a9";
			reg = <0>;
		};
		...
	};

Now, I can also extend this in sh73a0-kzm9g-reference.dts to add CPUFreq 
support to CPU0:

	cpus {
		cpu@0 {
			cpu0-supply = <&vdd_dvfs>;
			operating-points = <
				/* kHz  uV */
				1196000 1315000
				 598000 1175000
				 398667 1065000
			>;
			voltage-tolerance = <1>; /* 1% */
		};
	};

Which AFAICS does a similar thing (adds more properties to an existing DT 
node) but uses a different syntax. Maybe they are completely equivalent, 
the only difference being, that the former example uses a phandle and the 
latter a complete path, maybe there are differences, I don't know.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Simon Horman March 5, 2013, 7:04 a.m. UTC | #10
On Tue, Mar 05, 2013 at 07:52:21AM +0100, Guennadi Liakhovetski wrote:
> Hi Simon
> 
> On Tue, 5 Mar 2013, Simon Horman wrote:
> 
> > On Mon, Mar 04, 2013 at 02:33:40PM +0100, Guennadi Liakhovetski wrote:
> 
> [snip]
> 
> > > That would be the best, I agree. However, we discussed this already on the 
> > > example of mmcif, you might remember. I asked what's the difference 
> > > between extending a DT node (from .dtsi) with additional properties (in a 
> > > board-specific .dts) using an "&phandle" syntax and a full path? Or are 
> > > they equivalent? There was no reply, so, for such nodes (MMC/SD) I so far 
> > > settled with complete nodes in .dts. We do use the "&phandle" syntax for 
> > > pinctrl function groups, for I2C devices. I used a complete path for 
> > > CPUFreq... Mostly because other platforms did that too.
> > 
> > I am confused.
> > 
> > Using phandle syntax we can add a device to an soc's dtsi file and then add
> > extra properties in the board file.  This seems to be match the HW well.
> > 
> > What is your alternate suggestion?
> 
> Let me give you examples. In sh73a0-reference.dtsi we define an I2C device 
> #0:
> 
> 	i2c0: i2c@0xe6820000 {
> 		#address-cells = <1>;
> 		#size-cells = <0>;
> 		compatible = "renesas,rmobile-iic";
> 		reg = <0xe6820000 0x425>;
> 		...
> 	};
> 
> Then in sh73a0-kzm9g-reference.dts I can use the phandle syntax to put 
> devices on that I2C bus:
> 
> &i2c0 {
> 	as3711@40 {
> 		compatible = "ams,as3711";
> 		reg = <0x40>;
> 		...
> 	};
> 	...
> };
> 
> This is one possibility. In sh73a0.dtsi we've got
> 
> 	cpus {
> 		#address-cells = <1>;
> 		#size-cells = <0>;
> 
> 		cpu@0 {
> 			device_type = "cpu";
> 			compatible = "arm,cortex-a9";
> 			reg = <0>;
> 		};
> 		...
> 	};
> 
> Now, I can also extend this in sh73a0-kzm9g-reference.dts to add CPUFreq 
> support to CPU0:
> 
> 	cpus {
> 		cpu@0 {
> 			cpu0-supply = <&vdd_dvfs>;
> 			operating-points = <
> 				/* kHz  uV */
> 				1196000 1315000
> 				 598000 1175000
> 				 398667 1065000
> 			>;
> 			voltage-tolerance = <1>; /* 1% */
> 		};
> 	};
> 
> Which AFAICS does a similar thing (adds more properties to an existing DT 
> node) but uses a different syntax. Maybe they are completely equivalent, 
> the only difference being, that the former example uses a phandle and the 
> latter a complete path, maybe there are differences, I don't know.

Interesting. Thanks for the example, I now understand.

To be honest I'm not sure what the answer is.
But if they are both working then I'm not particularly fussed either way.
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts b/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
index 1e339cd..52645b6 100644
--- a/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
+++ b/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
@@ -134,6 +134,100 @@ 
 		renesas,pins = "eth_base";
 		renesas,function = "eth";
 	};
+
+	sci@0xe6c40000 {
+		compatible = "renesas,sci-SCIFA-uart";
+		interrupt-parent = <&intca>;
+		reg = <0xe6c40000 0x100>;
+		interrupts = <0x0c00>, <0x0c00>, <0x0c00>, <0x0c00>;
+		cell-index = <0>;
+		renesas,scscr = <0x30>;
+		renesas,scbrr-algo-id = <4>;
+		renesas,autoconf;
+	};
+
+	sci@0xe6c50000 {
+		compatible = "renesas,sci-SCIFA-uart";
+		interrupt-parent = <&intca>;
+		reg = <0xe6c50000 0x100>;
+		interrupts = <0x0c20>, <0x0c20>, <0x0c20>, <0x0c20>;
+		cell-index = <1>;
+		renesas,scscr = <0x30>;
+		renesas,scbrr-algo-id = <4>;
+		renesas,autoconf;
+	};
+
+	sci@0xe6c60000 {
+		compatible = "renesas,sci-SCIFA-uart";
+		interrupt-parent = <&intca>;
+		reg = <0xe6c60000 0x100>;
+		interrupts = <0x0c40>, <0x0c40>, <0x0c40>, <0x0c40>;
+		cell-index = <2>;
+		renesas,scscr = <0x30>;
+		renesas,scbrr-algo-id = <4>;
+		renesas,autoconf;
+	};
+
+	sci@0xe6c70000 {
+		compatible = "renesas,sci-SCIFA-uart";
+		interrupt-parent = <&intca>;
+		reg = <0xe6c70000 0x100>;
+		interrupts = <0x0c60>, <0x0c60>, <0x0c60>, <0x0c60>;
+		cell-index = <3>;
+		renesas,scscr = <0x30>;
+		renesas,scbrr-algo-id = <4>;
+		renesas,autoconf;
+	};
+	sci@0xe6c80000 {
+		compatible = "renesas,sci-SCIFA-uart";
+		interrupt-parent = <&intca>;
+		reg = <0xe6c80000 0x100>;
+		interrupts = <0x0d20>, <0x0d20>, <0x0d20>, <0x0d20>;
+		cell-index = <4>;
+		renesas,scscr = <0x30>;
+		renesas,scbrr-algo-id = <4>;
+		renesas,autoconf;
+	};
+	sci@0xe6cb0000 {
+		compatible = "renesas,sci-SCIFA-uart";
+		interrupt-parent = <&intca>;
+		reg = <0xe6cb0000 0x100>;
+		interrupts = <0x0d40>, <0x0d40>, <0x0d40>, <0x0d40>;
+		cell-index = <5>;
+		renesas,scscr = <0x30>;
+		renesas,scbrr-algo-id = <4>;
+		renesas,autoconf;
+	};
+	sci@0xe6cc0000 {
+		compatible = "renesas,sci-SCIFA-uart";
+		interrupt-parent = <&intca>;
+		reg = <0xe6cc0000 0x100>;
+		interrupts = <0x04c0>, <0x04c0>, <0x04c0>, <0x04c0>;
+		cell-index = <6>;
+		renesas,scscr = <0x30>;
+		renesas,scbrr-algo-id = <4>;
+		renesas,autoconf;
+	};
+	sci@0xe6cd0000 {
+		compatible = "renesas,sci-SCIFA-uart";
+		interrupt-parent = <&intca>;
+		reg = <0xe6cd0000 0x100>;
+		interrupts = <0x04e0>, <0x04e0>, <0x04e0>, <0x04e0>;
+		cell-index = <7>;
+		renesas,scscr = <0x30>;
+		renesas,scbrr-algo-id = <4>;
+		renesas,autoconf;
+	};
+	sci@0xe6c30000 {
+		compatible = "renesas,sci-SCIFB-uart";
+		interrupt-parent = <&intca>;
+		reg = <0xe6c30000 0x100>;
+		interrupts = <0x0d60>, <0x0d60>, <0x0d60>, <0x0d60>;
+		cell-index = <8>;
+		renesas,scscr = <0x30>;
+		renesas,scbrr-algo-id = <4>;
+		renesas,autoconf;
+	};
 };
 
 &gpio {
diff --git a/arch/arm/mach-shmobile/setup-r8a7740.c b/arch/arm/mach-shmobile/setup-r8a7740.c
index 5312aad..5f7597a 100644
--- a/arch/arm/mach-shmobile/setup-r8a7740.c
+++ b/arch/arm/mach-shmobile/setup-r8a7740.c
@@ -394,6 +394,13 @@  static struct platform_device *r8a7740_early_devices[] __initdata = {
 	&tmu02_device,
 };
 
+static struct platform_device *r8a7740_early_devices_dt[] __initdata = {
+	&cmt10_device,
+	&tmu00_device,
+	&tmu01_device,
+	&tmu02_device,
+};
+
 /* DMA */
 static const struct sh_dmae_slave_config r8a7740_dmae_slaves[] = {
 	{
@@ -839,8 +846,8 @@  void __init r8a7740_add_early_devices_dt(void)
 {
 	shmobile_setup_delay(800, 1, 3); /* Cortex-A9 @ 800MHz */
 
-	early_platform_add_devices(r8a7740_early_devices,
-				   ARRAY_SIZE(r8a7740_early_devices));
+	early_platform_add_devices(r8a7740_early_devices_dt,
+				   ARRAY_SIZE(r8a7740_early_devices_dt));
 
 	/* setup early console here as well */
 	shmobile_setup_console();
@@ -852,8 +859,8 @@  static const struct of_dev_auxdata r8a7740_auxdata_lookup[] __initconst = {
 
 void __init r8a7740_add_standard_devices_dt(void)
 {
-	platform_add_devices(r8a7740_early_devices,
-			    ARRAY_SIZE(r8a7740_early_devices));
+	platform_add_devices(r8a7740_early_devices_dt,
+			    ARRAY_SIZE(r8a7740_early_devices_dt));
 
 	of_platform_populate(NULL, of_default_bus_match_table,
 			     r8a7740_auxdata_lookup, NULL);