On Thu, Aug 28, 2014 at 03:23:49PM -0700, Olof Johansson wrote:
> On Thu, Aug 28, 2014 at 10:54 AM, Rob Herring <robh@xxxxxxxxxx> wrote:
> > On Thu, Aug 28, 2014 at 12:19 PM, Olof Johansson <olof@xxxxxxxxx> wrote:
> >> On Thu, Aug 28, 2014 at 10:03 AM, Mark Rutland <mark.rutland@xxxxxxx> wrote:
> >>> On Thu, Aug 28, 2014 at 05:28:22PM +0100, Olof Johansson wrote:
> >>>> On Thu, Aug 28, 2014 at 2:48 AM, Mark Rutland <mark.rutland@xxxxxxx> wrote:
> >>>> > Hi,
> >>>> >
> >>>> >> > + cpus {
> >>>> >> > + #address-cells = <2>;
> >>>> >> > + #size-cells = <0>;
> >>>> >>
> >>>> >> Why size-cells=2? Can you not fit a cpuid in 32 bits?
> >>>> >
> >>>> > As of commit 72aea393a2e7 (arm64: smp: honour #address-size when parsing
> >>>> > CPU reg property) Linux can handle single-cell cpu node reg entries
> >>>> > where /cpus/#address-cells = <1>.
> >>>> >
> >>>> > I can't make any guarantees about other code (e.g. bootloaders) which
> >>>> > might try to do things with cpu nodes, YMMV.
> >>>>
> >>>> Ok. If address-cells is kept at 2 the unit address needs to be changed
> >>>> to "0,0". So one or the other has to be changed.
> >>>
> >>> I'm happy either way.
> >>>
> >>> I'm not sure the rest of the tree had "0," prefixes on all of the
> >>> unit-addresses for 64-bit addresses that were under 4GB, and I'm not
> >>> sure that existing dts consistently do that either.
> >>>
> >>> Do we want to enforce that for all 64-bit unit-addresses?
> >>
> >> Yeah, I believe that's the only valid format for a 2-address-cell unit address.
> >
> > But we don't do leading 0's anywhere else like single cell unit
> > addresses. Buses expressed with ranges and offsets are one example.
> > Also, I2C addresses have a 32-bit size in DT yet are only 8-bit and we
> > don't do leading zero's there.
>
> Ok, I'm happily proven wrong here, also by confirming how this is done
> on "real" OF.
>
> According to benh:
>
> 15:20 <benh> ojn: 0,0 is not quite right, it's supposed to be used
> when the two numbers are different things, like device,fn on PCI
>
> The same is true for >2^32 unit addresses, they just use the one
> integer instead of x,y.
>
> So, I take back all I've said on this in the last 72 hours. :) It
> looks like we might need to revisit some of the 32-bit DTs. Simon,
> drop the series you had. :)
Thanks will do.
Is the way forward for me to apply my original patch to
change memory@180000000 to memory@140000000? And abandon all
the ',' only changes?This one:
This is the original patch:
From: Simon Horman <horms+renesas@xxxxxxxxxxxx>
[PATCH] ARM: shmobile: lager: correct memory map
The base address of the second memory region on the lager
board is 0x140000000. Update the tag used in the dts file accordingly.
This is a documentation fix and should have no run-time affect.
This problem was introduced when the second memory region
was added to the lager dts file by 62bc32a2573c4219
("ARM: shmobile: Include all 4 GiB of memory on Lager)"
in v3.14.
Reported-by: NAOYA SHIIBA <naoya.shiiba.nx@xxxxxxxxxxx>
Signed-off-by: Simon Horman <horms+renesas@xxxxxxxxxxxx>
---
arch/arm/boot/dts/r8a7790-lager.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts
index 0118cbf..84dcafa 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -32,7 +32,7 @@
reg = <0 0x40000000 0 0x40000000>;
};
- memory@180000000 {
+ memory@140000000 {
device_type = "memory";
reg = <1 0x40000000 0 0xc0000000>;
};
--
2.0.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
