Re: [PATCH] ARM64: dts: vexpress: Use a symlink to vexpress-v2m-rs1.dtsi from arch=arm
On Mon, 2015-10-05 at 12:53 +0100, Ian Campbell wrote: Ping? > Commit 9ccd608070b6 "arm64: dts: add device tree for ARM SMM-A53x2 on > LogicTile Express 20MG" added a new dts file to arch/arm64 which > included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a > .dtsi supplied by arch/arm. > > Unfortunately this causes some issues for the split device tree > repository[0], since things get moved around there. In that context > the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts > while the include is at src/arm/vexpress-v2m-rs1.dtsi. > > The sharing of the .dtsi is legitimate since the baseboard is the same > for various vexpress systems whatever processor they use. > > Previously I attempted to resolve this by creating a shared location > for such things but we have been unable to come to a consensus on > where that should be. > > Instead this patch simply replaces the use of ../../ in the dts > /include/ with a symlink in arch/arm64/boot/dts/arm pointing to the > file arch/arm/boot/dts. > > Since the split device tree repo will shortly be required to flatten > symlinks for other reasons this will cause the dtsi file to appear in > both src/arm and src/arm64 in the split repo, which is an improvement > on not building for arm64 now. > > [0] https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-re > basing.git/ > > Signed-off-by: Ian Campbell > Cc: Rob Herring > Cc: Pawel Moll > Cc: Mark Rutland > Cc: Kumar Gala > Cc: Liviu Dudau > Cc: Sudeep Holla > Cc: Lorenzo Pieralisi > Cc: Russell King > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Kristina Martsenko > Cc: Kevin Hilman > Cc: Frank Rowand > Cc: Olof Johansson > Cc: devicetree@vger.kernel.org > Cc: linux-ker...@vger.kernel.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: a...@kernel.org > Cc: linux-kbu...@vger.kernel.org > --- > For more on flattening symlinks see > http://thread.gmane.org/gmane.linux.kernel.input/45646/focus=45742 > --- > arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts | 2 +- > arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi| 1 + > 2 files changed, 2 insertions(+), 1 deletion(-) > create mode 12 arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi > > diff --git a/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts > b/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts > index 5b1d018..bb3c26d 100644 > --- a/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts > +++ b/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts > @@ -186,6 +186,6 @@ > <0 0 41 &gic GIC_SPI 41 > IRQ_TYPE_LEVEL_HIGH>, > <0 0 42 &gic GIC_SPI 42 > IRQ_TYPE_LEVEL_HIGH>; > > - /include/ "../../../../arm/boot/dts/vexpress-v2m > -rs1.dtsi" > + /include/ "vexpress-v2m-rs1.dtsi" > }; > }; > diff --git a/arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi > b/arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi > new file mode 12 > index 000..68fd0f8 > --- /dev/null > +++ b/arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi > @@ -0,0 +1 @@ > +../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi > \ No newline at end of file -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM64: dts: vexpress: Use a symlink to vexpress-v2m-rs1.dtsi from arch=arm
Commit 9ccd608070b6 "arm64: dts: add device tree for ARM SMM-A53x2 on LogicTile Express 20MG" added a new dts file to arch/arm64 which included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a .dtsi supplied by arch/arm. Unfortunately this causes some issues for the split device tree repository[0], since things get moved around there. In that context the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts while the include is at src/arm/vexpress-v2m-rs1.dtsi. The sharing of the .dtsi is legitimate since the baseboard is the same for various vexpress systems whatever processor they use. Previously I attempted to resolve this by creating a shared location for such things but we have been unable to come to a consensus on where that should be. Instead this patch simply replaces the use of ../../ in the dts /include/ with a symlink in arch/arm64/boot/dts/arm pointing to the file arch/arm/boot/dts. Since the split device tree repo will shortly be required to flatten symlinks for other reasons this will cause the dtsi file to appear in both src/arm and src/arm64 in the split repo, which is an improvement on not building for arm64 now. [0] https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/ Signed-off-by: Ian Campbell Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Kumar Gala Cc: Liviu Dudau Cc: Sudeep Holla Cc: Lorenzo Pieralisi Cc: Russell King Cc: Catalin Marinas Cc: Will Deacon Cc: Kristina Martsenko Cc: Kevin Hilman Cc: Frank Rowand Cc: Olof Johansson Cc: devicetree@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: a...@kernel.org Cc: linux-kbu...@vger.kernel.org --- For more on flattening symlinks see http://thread.gmane.org/gmane.linux.kernel.input/45646/focus=45742 --- arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts | 2 +- arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi| 1 + 2 files changed, 2 insertions(+), 1 deletion(-) create mode 12 arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi diff --git a/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts b/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts index 5b1d018..bb3c26d 100644 --- a/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts +++ b/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts @@ -186,6 +186,6 @@ <0 0 41 &gic GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>, <0 0 42 &gic GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>; - /include/ "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi" + /include/ "vexpress-v2m-rs1.dtsi" }; }; diff --git a/arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi b/arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi new file mode 12 index 000..68fd0f8 --- /dev/null +++ b/arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi @@ -0,0 +1 @@ +../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi \ No newline at end of file -- 2.5.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
"clk: sunxi: Add a simple gates driver" breaks kernel with older DTB
Booting a recent kernel with the DTB supplied with Debian Jessie (3.16 based) breaks on Cubietruck because that DTB lacks the clock-indices nodes which the new driver from the commit below adds (replacing the hardcoding which used to be in clk-sunxi.c). It is panicing in drivers/clocksource/timer-sun5i.c with: [0.015413] clocksource: timer: mask: 0x max_cycles: 0x, max_idle_ns: 79635851949 ns [0.025049] Kernel panic - not syncing: Can't get timer clock [0.030794] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.3.0-rc2-arm-native+ #6 [0.038002] Hardware name: Allwinner sun7i (A20) Family [0.043253] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [0.050992] [] (show_stack) from [] (dump_stack+0x88/0x98) [0.058213] [] (dump_stack) from [] (panic+0xa4/0x22c) [0.065090] [] (panic) from [] (sun5i_timer_init+0x80/0x384) [0.072482] [] (sun5i_timer_init) from [] (clocksource_of_init+0x4c/0x8c) [0.081001] [] (clocksource_of_init) from [] (start_kernel+0x28c/0x3c4) [0.089343] [] (start_kernel) from [<4020807c>] (0x4020807c) [0.095866] ---[ end Kernel panic - not syncing: Can't get timer clock Reverting ee38b2698ae2 fixes this specific issue for me (it boots further, but there seems to be other problems later when earlycon hands over to proper console, which I've not yet looked into). Is this considered acceptable linkage between the kernel and the dtbs? I suspect that even if anyone does care this is going to be an uphill struggle for that minority so I'm going to adjust our test infrastructure to pickup the dtbs from the kernel it is trying to test rather then reusing the one from the OS install. Ian. commit ee38b2698ae234c03f65ccafa1811d4dda3c316d Author: Maxime Ripard Date: Fri Jul 31 19:46:22 2015 +0200 clk: sunxi: Add a simple gates driver The gates were handled with a common piece of framework that was registering all gates array, that was not using the CLK_OF_DECLARE logic, and was not using clock-indices but some private masks that were pretty much equivalent. Move this code in a new driver that handles all the gates array and solves both these issues. Signed-off-by: Maxime Ripard Signed-off-by: Michael Turquette [sb...@codeaurora.org: Include clk.h for consumer API usage] Signed-off-by: Stephen Boyd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] dtb: Create a common home for cross-architecture dtsi files.
Hi Olof, On Mon, 2015-08-24 at 15:22 -0700, Olof Johansson wrote: A little while ago you were trying to explain the scheme you would like to see on IRC but my thick skull was getting in the way :-/ Then you had to run... So, ping? Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] devicetree: bindings: use input-event-codes.h for evdev codes
On Wed, 2015-09-16 at 15:40 +0100, Ian Campbell wrote:
> > The intend of the symlink was that the conversion script would copy the
> > target,
> > rather then follow the symlink. This sorta assumes that there are will be
> > not
> > symlinks under dt-bindings which link to files inside dt-bindings and thus
> > should be preserved as symlinks.
> >
> > If the copy done in the script will follow the symlink then nothing should
> > really change for the split DT repo.
>
> Interesting idea. I'll see if I can make the conversion routine do that.
>
> TBH I have a horrid feeling that this is going to be beyond git rewrite
> -branch, at least in the mode it is used in today.
It seems that it is possible, after a fashion.
The downside is that either _all_ symlinks (which end up in the output) get
flattened or some sort of black/whitelisting is needed in the conversion
scripts themselves (potentially leading to issues or discontinuities) as
new stuff arrives).
It isn't possible AFAICT tell if a symlink points to something outside of
the converted set of paths and adjust, at least not without an unreasonable
amount of overhead on each commit during the rewrite.
Since this new file would be the first symlink in the converted repo I took
the former approach in my lash up to try it out, which was essentially to
insert the below script into the middle of the "git ls-files | rewrite
-paths.sed" pipeline which is called by git filter-branch --index-filter.
Not pretty but it does seem to work.
I want to avoid switching to --tree-filter if at all possible because it
checks out the tree and is therefore a _little_ I/O intensive ;-)
Ian.
#!/bin/bash
set -e
while read mode object stage path ; do
case "$mode" in
12)
# symbolic link
deref=$(echo $GIT_COMMIT:$path | git cat-file
--batch-check='deref-ok %(objectname)' --follow-symlinks)
case "$deref" in
deref-ok*)
echo -e "100644 ${deref#deref-ok } $stage\t$path"
;;
dangling*) # skip
;;
*) # the rest, missing etc
echo >&2 "Failed to parse symlink $GIT_COMMIT:$path $deref"
exit 1
;;
esac
;;
100*)
# Regular file, just pass through
echo -e "$mode $object $stage\t$path"
;;
*)
echo >&2 "Unhandled ls-tree entry: $line"
exit 1
;;
esac
done
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] devicetree: bindings: use input-event-codes.h for evdev codes
On Wed, 2015-09-16 at 10:27 -0400, Hans de Goede wrote: > Hi, > > On 09/15/2015 07:24 AM, Ian Campbell wrote: > > On Sat, 2015-09-12 at 15:26 +0200, Hans de Goede wrote: > > > Add a symlink to uapi/linux/input-event-codes.h, and include that > > > instead > > > of (re)defining all the evdev type and code values in > > > dt-bindings/input/input.h. This way we do not need to keep all the > > > event codes synced manually. > > > > > > Signed-off-by: Hans de Goede > > > --- > > > include/dt-bindings/input/input-event-codes.h | 1 + > > > include/dt-bindings/input/input.h | 510 +-- > > > - > > > -- > > > 2 files changed, 2 insertions(+), 509 deletions(-) > > > create mode 12 include/dt-bindings/input/input-event-codes.h > > > > > > diff --git a/include/dt-bindings/input/input-event-codes.h > > > b/include/dt > > > -bindings/input/input-event-codes.h > > > new file mode 12 > > > index 000..693bbcd > > > --- /dev/null > > > +++ b/include/dt-bindings/input/input-event-codes.h > > > @@ -0,0 +1 @@ > > > +../../uapi/linux/input-event-codes.h > > > \ No newline at end of file > > > > Hrm, I think this is going to cause trouble for the split DT repository > > at > > https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-reba > > sing.git/ > > > > Since ../../ == include in both trees I think I can make it work by > > including include/uapi/linux in the conversion, either wholesale > > (easiest) > > or partially (potentially cleaner). > > > > Any opinions on that? > > The intend of the symlink was that the conversion script would copy the > target, > rather then follow the symlink. This sorta assumes that there are will be not > symlinks under dt-bindings which link to files inside dt-bindings and thus > should be preserved as symlinks. > > If the copy done in the script will follow the symlink then nothing should > really change for the split DT repo. Interesting idea. I'll see if I can make the conversion routine do that. TBH I have a horrid feeling that this is going to be beyond git rewrite -branch, at least in the mode it is used in today. > > In principal I ought to regenerate the tree from scratch such that > > include/uapi/linux was "always" there and has history but I think we > > can > > live with it just appearing at some point in time wen the conversion > > script > > was updated? > > > > AIUI these values are required to only be used with properties whose > > names > > are of the form "linux,*", otherwise there would be strong complaints > > about > > include Linux uapi stuff into a generic device-tree binding. > > Correct, these values are only for linux,* properties, which is why I > initially put them in a file named dt-bindings/input/linux-event-codes.h I think that would be a better name for the symlink (but not the target of that symlink) and usage in the .dts*, given it's (hopefully) going to turn into a regular file in the exported repo. Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] devicetree: bindings: use input-event-codes.h for evdev codes
On Sat, 2015-09-12 at 15:26 +0200, Hans de Goede wrote: > Add a symlink to uapi/linux/input-event-codes.h, and include that instead > of (re)defining all the evdev type and code values in > dt-bindings/input/input.h. This way we do not need to keep all the > event codes synced manually. > > Signed-off-by: Hans de Goede > --- > include/dt-bindings/input/input-event-codes.h | 1 + > include/dt-bindings/input/input.h | 510 +--- > -- > 2 files changed, 2 insertions(+), 509 deletions(-) > create mode 12 include/dt-bindings/input/input-event-codes.h > > diff --git a/include/dt-bindings/input/input-event-codes.h b/include/dt > -bindings/input/input-event-codes.h > new file mode 12 > index 000..693bbcd > --- /dev/null > +++ b/include/dt-bindings/input/input-event-codes.h > @@ -0,0 +1 @@ > +../../uapi/linux/input-event-codes.h > \ No newline at end of file Hrm, I think this is going to cause trouble for the split DT repository at https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/ Since ../../ == include in both trees I think I can make it work by including include/uapi/linux in the conversion, either wholesale (easiest) or partially (potentially cleaner). Any opinions on that? In principal I ought to regenerate the tree from scratch such that include/uapi/linux was "always" there and has history but I think we can live with it just appearing at some point in time wen the conversion script was updated? AIUI these values are required to only be used with properties whose names are of the form "linux,*", otherwise there would be strong complaints about include Linux uapi stuff into a generic device-tree binding. Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters
On Thu, 2015-09-10 at 17:10 +0100, Stefano Stabellini wrote: > > C) When you could go: > > > >DT -> Discover Xen -> Xen-specific stuff -> Xen-specific EFI/ACPI > > discovery > > I take you mean discovering Xen with the usual Xen hypervisor node on > device tree. There may be other options, such as ARM defining an architectural mechanism to do early detection of hypervisors e.g. by defining some bit in some hypervisor controllable register (MPIDR?) to say "a hypervisor is present" and defining an hvc or smc call which can be used to ask which one it is. Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters
On Thu, 2015-09-10 at 07:08 -0600, Jan Beulich wrote: > > > > On 10.09.15 at 14:58, wrote: > > On Thu, 2015-09-10 at 13:15 +0100, Mark Rutland wrote: > > > > > > In any case this should be separate from the shim ABI discussion. > > > > > > I disagree; I think this is very much relevant to the ABI discussion. > > > That's not to say that I insist on a particular approach, but I think > > > that they need to be considered together. > > > > Taking a step back, the reason for using the EFI stub parameters is > > only > > (AFAIK) in order to be able to locate the ACPI RDSP (the root table > > pointer), which as it happens is normally passed via one of the EFI > > firmware tables. > > > > If there was a way to achieve that goal (i.e. another way to find the > > RSDP) > > without opening the can of UEFI worms then we could consider that > > opiton > > too. > > > > a way != the legacy x86 thing of scanning low memory of the signature, > > of > > course. > > But even x86 doesn't do that (other than as a fallback) on EFI. Indeed, I was referring legacy (non-EFI) mode. > The > configuration table is available to Dom0 (via XENPF_firmware_info: > XEN_FW_EFI_INFO:XEN_FW_EFI_CONFIG_TABLE). Under ARM we find out we are running under Xen from the ACPI tables, so there is a chicken and egg situation there. Not insoluble I'm sure, if we want to go down this route. Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters
On Thu, 2015-09-10 at 13:15 +0100, Mark Rutland wrote: > > In any case this should be separate from the shim ABI discussion. > > I disagree; I think this is very much relevant to the ABI discussion. > That's not to say that I insist on a particular approach, but I think > that they need to be considered together. Taking a step back, the reason for using the EFI stub parameters is only (AFAIK) in order to be able to locate the ACPI RDSP (the root table pointer), which as it happens is normally passed via one of the EFI firmware tables. If there was a way to achieve that goal (i.e. another way to find the RSDP) without opening the can of UEFI worms then we could consider that opiton too. a way != the legacy x86 thing of scanning low memory of the signature, of course. Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] dtb: Create a common home for cross-architecture dtsi files.
On Mon, 2015-08-24 at 15:22 -0700, Olof Johansson wrote:
> Hi,
>
> On Mon, Aug 24, 2015 at 1:58 PM, Rob Herring
> wrote:
> > On Sun, Aug 23, 2015 at 6:52 PM, Olof Johansson wrote:
> > > On Sun, Aug 23, 2015 at 4:42 PM, Rob Herring
> > > wrote:
> > > > On Sun, Aug 23, 2015 at 6:13 PM, Olof Johansson
> > > > wrote:
> > > > >
> > > Right now it's not possible to do even per-arch "all-dtbs" since only
> > > the currently configured platforms will get their dtbs compiled.
> >
> > I know. It's been on my todo list for a while. Having that per arch at
> > least would be an improvement. Having it arch independent would mean I
> > don't even need a cross-compiler (probably).
>
> Yeah, seems like something that should work quite well in the scope of
> Ian's tree if nothing else.
In the split tree "make all -k" will already build every dtb (and always
has done), in fact this is how I discovered the breakage which I'm trying
to address with this patch since the daily cronjob which does the
conversion runs this.
> Something like lib/ seems more appropriate. Or drivers/..., but I
> suspect that could cause further confusion on the expected separation
> of binding/hardware description and the consuming drivers.
I'm quite happy to rework the patch with whatever path is settled upon.
Or if someone has an alternative suggestion for how to fix the build in the
split devicetree git tree I'm happy to give that a go too.
> > > > We could also see sharing between PPC and ARM on FSL networking
> > > > parts,
> > > > but I've not heard if they actually have that problem.
> > >
> > > Yeah, there could potentially be some sharing between MIPS and
> > > ARM{,64} too, but I don't know if we'll actually see it done.
> >
> > Yep, hard to say.
> >
> > Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] dtb: Create a common home for cross-architecture dtsi files.
On Fri, 2015-08-14 at 16:21 -0500, Rob Herring wrote:
> +arm-soc
I could've sworn I did the same at one point. Obviously not.
>
> On Tue, Aug 11, 2015 at 5:07 AM, Ian Campbell <
> ian.campb...@citrix.com> wrote:
> > On Mon, 2015-08-03 at 17:06 +0100, Ian Campbell wrote:
> > > Commit 9ccd608070b6 ("arm64: dts: add device tree for ARM SMM
> > > -A53x2 on
> > > LogicTile Express 20MG") added a new dts file to arch/arm64 which
> > > included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a
> > > .dtsi supplied by arch/arm.
> > >
> > > Unfortunately this causes some issues for the split device tree
> > > repository[0], since things get moved around there. In that
> > > context
> > > the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7
> > > -ca53x2.dts
> > > while the include is at src/arm/vexpress-v2m-rs1.dtsi.
> >
> > Hi Grant,
> >
> > Do you think there is any chance of getting this into 4.2-rc$NEXT
> > or shall
> > we wait until 4.3? I'm assuming this should go via the DT tree, but
> > maybe
> > it should go via an ARM tree?
>
> I was assuming this would go thru the arm-soc tree which is why I
> acked it. It is getting a bit late for 4.2 at this point, but I guess
> the standalone tree remains broken for these platforms until this is
> done.
Correct.
> Probably not such a big deal in grand scheme of things.
I guess not. FWIW I've not pushed since the breakage started happening,
so the split tree isn't broken, but it's also now however many weeks
behind. Once 4.3-rc1 arrives with this fixed I'll push all the 4.2-rcN
and 4.2 as well.
Ian.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] dtb: Create a common home for cross-architecture dtsi files.
On Mon, 2015-08-03 at 17:06 +0100, Ian Campbell wrote:
> Commit 9ccd608070b6 ("arm64: dts: add device tree for ARM SMM-A53x2 on
> LogicTile Express 20MG") added a new dts file to arch/arm64 which
> included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a
> .dtsi supplied by arch/arm.
>
> Unfortunately this causes some issues for the split device tree
> repository[0], since things get moved around there. In that context
> the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
> while the include is at src/arm/vexpress-v2m-rs1.dtsi.
Hi Grant,
Do you think there is any chance of getting this into 4.2-rc$NEXT or shall
we wait until 4.3? I'm assuming this should go via the DT tree, but maybe
it should go via an ARM tree?
Ian.
>
> The sharing of the .dtsi is legitimate since the baseboard is the same
> for various vexpress systems whatever processor they use.
>
> Rather than using ../../ tricks to pickup .dtsi files from another
> arch this patch creates a new directory kernel/dts as a home for such
> cross-arch .dtsi files and arranges for it to be in the include path
> for both dtc and cpp. The dtsi file itself is moved into a vendor
> subdir in this case "arm" (the vendor, not the ARCH=).
>
> [0] https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree
> -rebasing.git/
>
> Signed-off-by: Ian Campbell
> Cc: Rob Herring
> Cc: Pawel Moll
> Cc: Mark Rutland
> Cc: Kumar Gala
> Cc: Liviu Dudau
> Cc: Sudeep Holla
> Cc: Lorenzo Pieralisi
> Cc: Russell King
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Kristina Martsenko
> Cc: Kevin Hilman
> Cc: devicetree@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kbu...@vger.kernel.org
> Acked-by: Mark Rutland
> Acked-by: Rob Herring
> Acked-by: Liviu Dudau
> Reviewed-by: Masahiro Yamada
> ---
> v2: Move to include/dt-dtsi and introduce a per-vendor subdirectory.
>
> v3: Move to kernel/dts.
> Include new directory in DTC include path as well as cpp path, and
> therefore switch back to /include/.
> Update MAINTAINERS
>
> v4: Change path in changelog too.
> Add ()s to title of 9ccd608070b6.
>
> v5: Remove stale reference to switching from /include/ to #include.
> ---
> Documentation/devicetree/bindings/arm/vexpress.txt | 2 +-
> MAINTAINERS | 1 +
> arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 2 +-
> arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 2 +-
> arch/arm/boot/dts/vexpress-v2p-ca5s.dts | 2 +-
> arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts| 2 +-
> {arch/arm/boot/dts => kernel/dts/arm}/vexpress-v2m-rs1.dtsi | 0
> scripts/Makefile.lib| 3 ++-
> 8 files changed, 8 insertions(+), 6 deletions(-)
> rename {arch/arm/boot/dts => kernel/dts/arm}/vexpress-v2m-rs1.dtsi
> (100%)
>
> diff --git a/Documentation/devicetree/bindings/arm/vexpress.txt
> b/Documentation/devicetree/bindings/arm/vexpress.txt
> index 39844cd..b6031d9 100644
> --- a/Documentation/devicetree/bindings/arm/vexpress.txt
> +++ b/Documentation/devicetree/bindings/arm/vexpress.txt
> @@ -223,7 +223,7 @@ Example of a VE tile description (simplified)
> /* Active high IRQ 0 is connected to GIC's SPI0 */
> interrupt-map = <0 0 0 &gic 0 0 4>;
>
> - /include/ "vexpress-v2m-rs1.dtsi"
> + /include/ "arm/vexpress-v2m-rs1.dtsi"
> };
> };
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a226416..1941078 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7537,6 +7537,7 @@ S: Maintained
> F: Documentation/devicetree/
> F: arch/*/boot/dts/
> F: include/dt-bindings/
> +F: kernel/dts/
>
> OPEN FIRMWARE AND DEVICE TREE OVERLAYS
> M: Pantelis Antoniou
> diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
> b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
> index 9420053..b144092 100644
> --- a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
> +++ b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
> @@ -278,6 +278,6 @@
> <0 0 41 &gic 0 41 4>,
> <0 0 42 &gic 0 42 4>;
>
> - /include/ "vexpress-v2m-rs1.dtsi"
> + /include/ "arm/vexpress-v2m-rs1.dtsi"
> };
> };
> diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
> b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
> index 17f63f7..350f402 100644
> --- a/arch/arm/boot/d
Re: [PATCH v4] dtb: Create a common home for cross-architecture dtsi files.
On Tue, 2015-08-11 at 13:00 +0900, Masahiro Yamada wrote:
> Hi
>
> 2015-08-04 1:06 GMT+09:00 Ian Campbell :
> > Commit 9ccd608070b6 ("arm64: dts: add device tree for ARM SMM-A53x2 on
> > LogicTile Express 20MG") added a new dts file to arch/arm64 which
> > included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a
> > .dtsi supplied by arch/arm.
> >
> > Unfortunately this causes some issues for the split device tree
> > repository[0], since things get moved around there. In that context
> > the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
> > while the include is at src/arm/vexpress-v2m-rs1.dtsi.
> >
> > The sharing of the .dtsi is legitimate since the baseboard is the same
> > for various vexpress systems whatever processor they use.
> >
> > Rather than using ../../ tricks to pickup .dtsi files from another
> > arch this patch creates a new directory kernel/dts as a home for such
> > cross-arch .dtsi files and arranges for it to be in the include path
> > for both dtc and cpp. The dtsi file itself is moved into a vendor
> > subdir in this case "arm" (the vendor, not the ARCH=).
>
>
> Question:
> If this patch is applied, which directory will be created in
> device-tree-rebasing?
> src/kernel/, src/common/, or something else?
> Either will do, of course.
Below is the patch against the device-tree-rebasing.git, I went (pretty
much arbitrarily) with common at the top level.
commit 0524b00e5bd7b98a2a9ef85c1f5f2a8d93bcbeb6
Author: Ian Campbell
Date: Tue Jul 21 17:27:13 2015 +0100
Handle new kernel/dts subtree.
Rewrite its contents to common/ and include in the CPP and DTC include
paths.
Signed-off-by: Ian Campbell
diff --git a/Makefile b/Makefile
index 5e8930c..b57107d 100644
--- a/Makefile
+++ b/Makefile
@@ -114,12 +114,13 @@ dtc-tmp = $(subst $(comma),_,$(dot-target).dts.tmp)
dtc_cpp_flags = -Wp,-MD,$(depfile).pre.tmp -nostdinc \
-Iinclude -I$(src) -Itestcase-data\
+ -Icommon \
-undef -D__DTS__
quiet_cmd_dtc = DTC $@
cmd_dtc = $(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $< ; \
$(DTC) -O dtb -o $@ -b 0 \
--i $(src) $(DTC_FLAGS) \
+-i $(src) -i common $(DTC_FLAGS) \
-d $(depfile).dtc.tmp $(dtc-tmp) ; \
cat $(depfile).pre.tmp $(depfile).dtc.tmp > $(depfile)
diff --git a/scripts/rewrite-paths.sed b/scripts/rewrite-paths.sed
index b73fbce..5269769 100644
--- a/scripts/rewrite-paths.sed
+++ b/scripts/rewrite-paths.sed
@@ -33,6 +33,7 @@ s,\tarch/\([^/]*\)/boot/dts/\(.*\.h\)$,\tsrc/\1/\2,gp
# Also rewrite the DTS include paths for dtc+cpp support
s,\tarch/\([^/]*\)/include/dts/,\tsrc/\1/include/,gp
s,\tinclude/dt-bindings/,\tinclude/dt-bindings/,gp
+s,\tkernel/dts/,\tcommon/,gp
# Rewrite the bindings subdirectory
s,\tDocumentation/devicetree/bindings/,\tBindings/,gp
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5] dtb: Create a common home for cross-architecture dtsi files.
Commit 9ccd608070b6 ("arm64: dts: add device tree for ARM SMM-A53x2 on
LogicTile Express 20MG") added a new dts file to arch/arm64 which
included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a
.dtsi supplied by arch/arm.
Unfortunately this causes some issues for the split device tree
repository[0], since things get moved around there. In that context
the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
while the include is at src/arm/vexpress-v2m-rs1.dtsi.
The sharing of the .dtsi is legitimate since the baseboard is the same
for various vexpress systems whatever processor they use.
Rather than using ../../ tricks to pickup .dtsi files from another
arch this patch creates a new directory kernel/dts as a home for such
cross-arch .dtsi files and arranges for it to be in the include path
for both dtc and cpp. The dtsi file itself is moved into a vendor
subdir in this case "arm" (the vendor, not the ARCH=).
[0]
https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/
Signed-off-by: Ian Campbell
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Kumar Gala
Cc: Liviu Dudau
Cc: Sudeep Holla
Cc: Lorenzo Pieralisi
Cc: Russell King
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Kristina Martsenko
Cc: Kevin Hilman
Cc: devicetree@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kbu...@vger.kernel.org
Acked-by: Mark Rutland
Acked-by: Rob Herring
Acked-by: Liviu Dudau
Reviewed-by: Masahiro Yamada
---
v2: Move to include/dt-dtsi and introduce a per-vendor subdirectory.
v3: Move to kernel/dts.
Include new directory in DTC include path as well as cpp path, and
therefore switch back to /include/.
Update MAINTAINERS
v4: Change path in changelog too.
Add ()s to title of 9ccd608070b6.
v5: Remove stale reference to switching from /include/ to #include.
---
Documentation/devicetree/bindings/arm/vexpress.txt | 2 +-
MAINTAINERS | 1 +
arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 2 +-
arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 2 +-
arch/arm/boot/dts/vexpress-v2p-ca5s.dts | 2 +-
arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts| 2 +-
{arch/arm/boot/dts => kernel/dts/arm}/vexpress-v2m-rs1.dtsi | 0
scripts/Makefile.lib| 3 ++-
8 files changed, 8 insertions(+), 6 deletions(-)
rename {arch/arm/boot/dts => kernel/dts/arm}/vexpress-v2m-rs1.dtsi (100%)
diff --git a/Documentation/devicetree/bindings/arm/vexpress.txt
b/Documentation/devicetree/bindings/arm/vexpress.txt
index 39844cd..b6031d9 100644
--- a/Documentation/devicetree/bindings/arm/vexpress.txt
+++ b/Documentation/devicetree/bindings/arm/vexpress.txt
@@ -223,7 +223,7 @@ Example of a VE tile description (simplified)
/* Active high IRQ 0 is connected to GIC's SPI0 */
interrupt-map = <0 0 0 &gic 0 0 4>;
- /include/ "vexpress-v2m-rs1.dtsi"
+ /include/ "arm/vexpress-v2m-rs1.dtsi"
};
};
diff --git a/MAINTAINERS b/MAINTAINERS
index a226416..1941078 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7537,6 +7537,7 @@ S:Maintained
F: Documentation/devicetree/
F: arch/*/boot/dts/
F: include/dt-bindings/
+F: kernel/dts/
OPEN FIRMWARE AND DEVICE TREE OVERLAYS
M: Pantelis Antoniou
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
index 9420053..b144092 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
@@ -278,6 +278,6 @@
<0 0 41 &gic 0 41 4>,
<0 0 42 &gic 0 42 4>;
- /include/ "vexpress-v2m-rs1.dtsi"
+ /include/ "arm/vexpress-v2m-rs1.dtsi"
};
};
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
index 17f63f7..350f402 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
@@ -636,6 +636,6 @@
<0 0 41 &gic 0 41 4>,
<0 0 42 &gic 0 42 4>;
- /include/ "vexpress-v2m-rs1.dtsi"
+ /include/ "arm/vexpress-v2m-rs1.dtsi"
};
};
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
index d2709b7..585ced0 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
@@ -248,6 +248,6 @@
<0 0 41 &gic 0 41 4>,
<0 0 42 &gic 0 42 4>;
- /include/ "vexpress-v2m-rs1.dtsi
[PATCH v4] dtb: Create a common home for cross-architecture dtsi files.
Commit 9ccd608070b6 ("arm64: dts: add device tree for ARM SMM-A53x2 on
LogicTile Express 20MG") added a new dts file to arch/arm64 which
included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a
.dtsi supplied by arch/arm.
Unfortunately this causes some issues for the split device tree
repository[0], since things get moved around there. In that context
the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
while the include is at src/arm/vexpress-v2m-rs1.dtsi.
The sharing of the .dtsi is legitimate since the baseboard is the same
for various vexpress systems whatever processor they use.
Rather than using ../../ tricks to pickup .dtsi files from another
arch this patch creates a new directory kernel/dts as a home for such
cross-arch .dtsi files and arranges for it to be in the include path
for both dtc and cpp. The dtsi file itself is moved into a vendor
subdir in this case "arm" (the vendor, not the ARCH=).
[0]
https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/
Signed-off-by: Ian Campbell
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Kumar Gala
Cc: Liviu Dudau
Cc: Sudeep Holla
Cc: Lorenzo Pieralisi
Cc: Russell King
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Kristina Martsenko
Cc: Kevin Hilman
Cc: devicetree@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kbu...@vger.kernel.org
Acked-by: Mark Rutland
Acked-by: Rob Herring
Acked-by: Liviu Dudau
Reviewed-by: Masahiro Yamada
---
v2: Move to include/dt-dtsi and introduce a per-vendor subdirectory.
v3: Move to kernel/dts.
Include new directory in DTC include path as well as cpp path, and
therefore switch back to /include/.
Update MAINTAINERS
v4: Change path in changelog too.
Add ()s to title of 9ccd608070b6.
v5: Remove stale reference to switching from /include/ to #include.
---
Documentation/devicetree/bindings/arm/vexpress.txt | 2 +-
MAINTAINERS | 1 +
arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 2 +-
arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 2 +-
arch/arm/boot/dts/vexpress-v2p-ca5s.dts | 2 +-
arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts| 2 +-
{arch/arm/boot/dts => kernel/dts/arm}/vexpress-v2m-rs1.dtsi | 0
scripts/Makefile.lib| 3 ++-
8 files changed, 8 insertions(+), 6 deletions(-)
rename {arch/arm/boot/dts => kernel/dts/arm}/vexpress-v2m-rs1.dtsi (100%)
diff --git a/Documentation/devicetree/bindings/arm/vexpress.txt
b/Documentation/devicetree/bindings/arm/vexpress.txt
index 39844cd..b6031d9 100644
--- a/Documentation/devicetree/bindings/arm/vexpress.txt
+++ b/Documentation/devicetree/bindings/arm/vexpress.txt
@@ -223,7 +223,7 @@ Example of a VE tile description (simplified)
/* Active high IRQ 0 is connected to GIC's SPI0 */
interrupt-map = <0 0 0 &gic 0 0 4>;
- /include/ "vexpress-v2m-rs1.dtsi"
+ /include/ "arm/vexpress-v2m-rs1.dtsi"
};
};
diff --git a/MAINTAINERS b/MAINTAINERS
index a226416..1941078 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7537,6 +7537,7 @@ S:Maintained
F: Documentation/devicetree/
F: arch/*/boot/dts/
F: include/dt-bindings/
+F: kernel/dts/
OPEN FIRMWARE AND DEVICE TREE OVERLAYS
M: Pantelis Antoniou
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
index 9420053..b144092 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
@@ -278,6 +278,6 @@
<0 0 41 &gic 0 41 4>,
<0 0 42 &gic 0 42 4>;
- /include/ "vexpress-v2m-rs1.dtsi"
+ /include/ "arm/vexpress-v2m-rs1.dtsi"
};
};
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
index 17f63f7..350f402 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
@@ -636,6 +636,6 @@
<0 0 41 &gic 0 41 4>,
<0 0 42 &gic 0 42 4>;
- /include/ "vexpress-v2m-rs1.dtsi"
+ /include/ "arm/vexpress-v2m-rs1.dtsi"
};
};
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
index d2709b7..585ced0 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
@@ -248,6 +248,6 @@
<0 0 41 &gic 0 41 4>,
<0 0 42 &gic 0 42 4>;
- /include/ "vexpress-v2m-rs1.dtsi
Re: [PATCH v4] dtb: Create a common home for cross-architecture dtsi files.
On Mon, 2015-08-03 at 10:55 -0500, Rob Herring wrote:
> On Mon, Aug 3, 2015 at 3:55 AM, Ian Campbell
> wrote:
> > Commit 9ccd608070b6 ("arm64: dts: add device tree for ARM SMM-A53x2 on
> > LogicTile Express 20MG") added a new dts file to arch/arm64 which
> > included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a
> > .dtsi supplied by arch/arm.
> >
> > Unfortunately this causes some issues for the split device tree
> > repository[0], since things get moved around there. In that context
> > the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
> > while the include is at src/arm/vexpress-v2m-rs1.dtsi.
> >
> > The sharing of the .dtsi is legitimate since the baseboard is the same
> > for various vexpress systems whatever processor they use.
> >
> > Rather than using ../../ tricks to pickup .dtsi files from another
> > arch this patch creates a new directory kernel/dts as a home for such
> > cross-arch .dtsi files, arranges for it to be in the include path when
> > the .dts files are processed by cpp and switches the .dts files to use
> > cpp #include instead of /include/. The dtsi file itself is moved into
> > a vendor subdir in this case "arm" (the vendor, not the ARCH=).
>
> Sigh, it was not the include path I was referring to being wrong
> although that was too. It was the part about using #include instead of
> /include/.
Damn, how did I miss that!
v5 coming up, sorry :-/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4] dtb: Create a common home for cross-architecture dtsi files.
Commit 9ccd608070b6 ("arm64: dts: add device tree for ARM SMM-A53x2 on
LogicTile Express 20MG") added a new dts file to arch/arm64 which
included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a
.dtsi supplied by arch/arm.
Unfortunately this causes some issues for the split device tree
repository[0], since things get moved around there. In that context
the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
while the include is at src/arm/vexpress-v2m-rs1.dtsi.
The sharing of the .dtsi is legitimate since the baseboard is the same
for various vexpress systems whatever processor they use.
Rather than using ../../ tricks to pickup .dtsi files from another
arch this patch creates a new directory kernel/dts as a home for such
cross-arch .dtsi files, arranges for it to be in the include path when
the .dts files are processed by cpp and switches the .dts files to use
cpp #include instead of /include/. The dtsi file itself is moved into
a vendor subdir in this case "arm" (the vendor, not the ARCH=).
[0]
https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/
Signed-off-by: Ian Campbell
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Kumar Gala
Cc: Liviu Dudau
Cc: Sudeep Holla
Cc: Lorenzo Pieralisi
Cc: Russell King
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Kristina Martsenko
Cc: Kevin Hilman
Cc: devicetree@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kbu...@vger.kernel.org
Acked-by: Mark Rutland
Acked-by: Rob Herring
Acked-by: Liviu Dudau
Reviewed-by: Masahiro Yamada
---
v2: Move to include/dt-dtsi and introduce a per-vendor subdirectory.
v3: Move to kernel/dts.
Include new directory in DTC include path as well as cpp path, and
therefore switch back to /include/.
Update MAINTAINERS
v4: Change path in changelog too.
Add ()s to title of 9ccd608070b6.
---
Documentation/devicetree/bindings/arm/vexpress.txt | 2 +-
MAINTAINERS | 1 +
arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 2 +-
arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 2 +-
arch/arm/boot/dts/vexpress-v2p-ca5s.dts | 2 +-
arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts| 2 +-
{arch/arm/boot/dts => kernel/dts/arm}/vexpress-v2m-rs1.dtsi | 0
scripts/Makefile.lib| 3 ++-
8 files changed, 8 insertions(+), 6 deletions(-)
rename {arch/arm/boot/dts => kernel/dts/arm}/vexpress-v2m-rs1.dtsi (100%)
diff --git a/Documentation/devicetree/bindings/arm/vexpress.txt
b/Documentation/devicetree/bindings/arm/vexpress.txt
index 39844cd..b6031d9 100644
--- a/Documentation/devicetree/bindings/arm/vexpress.txt
+++ b/Documentation/devicetree/bindings/arm/vexpress.txt
@@ -223,7 +223,7 @@ Example of a VE tile description (simplified)
/* Active high IRQ 0 is connected to GIC's SPI0 */
interrupt-map = <0 0 0 &gic 0 0 4>;
- /include/ "vexpress-v2m-rs1.dtsi"
+ /include/ "arm/vexpress-v2m-rs1.dtsi"
};
};
diff --git a/MAINTAINERS b/MAINTAINERS
index a226416..1941078 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7537,6 +7537,7 @@ S:Maintained
F: Documentation/devicetree/
F: arch/*/boot/dts/
F: include/dt-bindings/
+F: kernel/dts/
OPEN FIRMWARE AND DEVICE TREE OVERLAYS
M: Pantelis Antoniou
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
index 9420053..b144092 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
@@ -278,6 +278,6 @@
<0 0 41 &gic 0 41 4>,
<0 0 42 &gic 0 42 4>;
- /include/ "vexpress-v2m-rs1.dtsi"
+ /include/ "arm/vexpress-v2m-rs1.dtsi"
};
};
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
index 17f63f7..350f402 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
@@ -636,6 +636,6 @@
<0 0 41 &gic 0 41 4>,
<0 0 42 &gic 0 42 4>;
- /include/ "vexpress-v2m-rs1.dtsi"
+ /include/ "arm/vexpress-v2m-rs1.dtsi"
};
};
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
index d2709b7..585ced0 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
@@ -248,6 +248,6 @@
<0 0 41 &gic 0 41 4>,
<0 0 42 &gic 0 42 4>;
- /include/ "vexp
Re: [PATCH v3] dtb: Create a common home for cross-architecture dtsi files.
On Sat, 2015-08-01 at 15:43 +0900, Masahiro Yamada wrote: > 2015-08-01 15:21 GMT+09:00 Masahiro Yamada >: > > 2015-07-31 23:31 GMT+09:00 Ian Campbell : > > > Commit 9ccd608070b6 "arm64: dts: add device tree for ARM SMM-A53x2 on > > > LogicTile Express 20MG" added a new dts file to arch/arm64 which > > > included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a > > > .dtsi supplied by arch/arm. > > > > > > Unfortunately this causes some issues for the split device tree > > > repository[0], since things get moved around there. In that context > > > the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts > > > while the include is at src/arm/vexpress-v2m-rs1.dtsi. > > > > Typo? > > > > src/arm64 -> arch/arm64 > > src/arm-> arch/arm > > > > > I retract this comment with my apology. > (I was seeing the kernel tree, not devicetree-rebasing) Right ;-) I fixed the commit formatting and took your Reviewed-by. I shall post v4 shortly. Thanks, Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] dtb: Create a common home for cross-architecture dtsi files.
Commit 9ccd608070b6 "arm64: dts: add device tree for ARM SMM-A53x2 on
LogicTile Express 20MG" added a new dts file to arch/arm64 which
included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a
.dtsi supplied by arch/arm.
Unfortunately this causes some issues for the split device tree
repository[0], since things get moved around there. In that context
the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
while the include is at src/arm/vexpress-v2m-rs1.dtsi.
The sharing of the .dtsi is legitimate since the baseboard is the same
for various vexpress systems whatever processor they use.
Rather than using ../../ tricks to pickup .dtsi files from another
arch this patch creates a new directory include/dt-dtsi as a
home for such cross-arch .dtsi files, arranges for it to be in the
include path when the .dts files are processed by cpp and switches the
.dts files to use cpp #include instead of /include/. The dtsi file
itself is moved into a vendor subdir in this case "arm" (the vendor,
not the ARCH=).
[0]
https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/
Signed-off-by: Ian Campbell
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Kumar Gala
Cc: Liviu Dudau
Cc: Sudeep Holla
Cc: Lorenzo Pieralisi
Cc: Russell King
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Kristina Martsenko
Cc: Kevin Hilman
Cc: devicetree@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kbu...@vger.kernel.org
---
v2: Move to include/dt-dtsi and introduce a per-vendor subdirectory.
v3: Move to kernel/dts.
Include new directory in DTC include path as well as cpp path, and
therefore switch back to /include/.
Update MAINTAINERS
---
Documentation/devicetree/bindings/arm/vexpress.txt | 2 +-
MAINTAINERS | 1 +
arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 2 +-
arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 2 +-
arch/arm/boot/dts/vexpress-v2p-ca5s.dts | 2 +-
arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts| 2 +-
{arch/arm/boot/dts => kernel/dts/arm}/vexpress-v2m-rs1.dtsi | 0
scripts/Makefile.lib| 3 ++-
8 files changed, 8 insertions(+), 6 deletions(-)
rename {arch/arm/boot/dts => kernel/dts/arm}/vexpress-v2m-rs1.dtsi (100%)
diff --git a/Documentation/devicetree/bindings/arm/vexpress.txt
b/Documentation/devicetree/bindings/arm/vexpress.txt
index 39844cd..b6031d9 100644
--- a/Documentation/devicetree/bindings/arm/vexpress.txt
+++ b/Documentation/devicetree/bindings/arm/vexpress.txt
@@ -223,7 +223,7 @@ Example of a VE tile description (simplified)
/* Active high IRQ 0 is connected to GIC's SPI0 */
interrupt-map = <0 0 0 &gic 0 0 4>;
- /include/ "vexpress-v2m-rs1.dtsi"
+ /include/ "arm/vexpress-v2m-rs1.dtsi"
};
};
diff --git a/MAINTAINERS b/MAINTAINERS
index a226416..1941078 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7537,6 +7537,7 @@ S:Maintained
F: Documentation/devicetree/
F: arch/*/boot/dts/
F: include/dt-bindings/
+F: kernel/dts/
OPEN FIRMWARE AND DEVICE TREE OVERLAYS
M: Pantelis Antoniou
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
index 9420053..b144092 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
@@ -278,6 +278,6 @@
<0 0 41 &gic 0 41 4>,
<0 0 42 &gic 0 42 4>;
- /include/ "vexpress-v2m-rs1.dtsi"
+ /include/ "arm/vexpress-v2m-rs1.dtsi"
};
};
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
index 17f63f7..350f402 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
@@ -636,6 +636,6 @@
<0 0 41 &gic 0 41 4>,
<0 0 42 &gic 0 42 4>;
- /include/ "vexpress-v2m-rs1.dtsi"
+ /include/ "arm/vexpress-v2m-rs1.dtsi"
};
};
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
index d2709b7..585ced0 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
@@ -248,6 +248,6 @@
<0 0 41 &gic 0 41 4>,
<0 0 42 &gic 0 42 4>;
- /include/ "vexpress-v2m-rs1.dtsi"
+ /include/ "arm/vexpress-v2m-rs1.dtsi"
};
};
diff --git a/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts
Re: [PATCH v2] dtb: Create a common home for cross-architecture dtsi files.
On Wed, 2015-07-29 at 14:27 +0100, Mark Rutland wrote: > On Wed, Jul 29, 2015 at 02:22:54PM +0100, Ian Campbell wrote: > > On Wed, 2015-07-29 at 20:07 +0900, Masahiro Yamada wrote: > > > Hi Ian, > > > > > > > > > 2015-07-27 19:35 GMT+09:00 Ian Campbell : > > > > Commit 9ccd608070b6 "arm64: dts: add device tree for ARM SMM-A53x2 > > > > on > > > > LogicTile Express 20MG" added a new dts file to arch/arm64 which > > > > included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a > > > > .dtsi supplied by arch/arm. > > > > > > > > Unfortunately this causes some issues for the split device tree > > > > repository[0], since things get moved around there. In that context > > > > the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts > > > > while the include is at src/arm/vexpress-v2m-rs1.dtsi. > > > > > > > > The sharing of the .dtsi is legitimate since the baseboard is the > > > > same > > > > for various vexpress systems whatever processor they use. > > > > > > > > Rather than using ../../ tricks to pickup .dtsi files from another > > > > arch this patch creates a new directory include/dt-dtsi as a > > > > home for such cross-arch .dtsi files, arranges for it to be in the > > > > include path when the .dts files are processed by cpp and switches > > > > the > > > > > > > > > "include/dt-dtsi/" can be referenced from normal C sources. > > > > > > I think another possible home for cross-arch DTSI is "kernel/dts/". > > > This directory can be hidden from C sources. > > > > I suppose, I don't really mind and will follow the direction of the > > other > > DTB maintainers. It doesn't seem like a big deal to me. > > I don't really have a preference either way. I'm inclined to leave it, "visible to C sources" doesn't seem like that much of an issue and IMHO the cure (kernel/dts/...) is worse than the disease. @@ -223,7 +223,7 @@ Example of a VE tile description (simplified) > > > > /* Active high IRQ 0 is connected to GIC's SPI0 */ > > > > interrupt-map = <0 0 0 &gic 0 0 4>; > > > > > > > > - /include/ "vexpress-v2m-rs1.dtsi" > > > > + #include > > > > }; > > > > }; > > > > > > > > > > > > You do not have to replace /include/ with #include, > > > if you add the include path for DTC. > > > > Ah, I looked for this but -i is not documented in the man page. > > > > Is there any reason to prefer one over the other? > > #include allows you to use CPP in the file you're including, /include/ > does not. > > I would imagine we have to use #include in case the dtsi itself has > #include statements... If it did, yes. I don't think vexpress-v2m-rs1.dtsi does, since it is using /include/ today. I'm inclined to switch back to /include/ unless someone objects. > > > Please add include path for DTC too > > > so that both /include/ and #include are available. > > ... though that does not preclude adding it to the path for /include/. Indeed, I've done that locally already. Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] dtb: Create a common home for cross-architecture dtsi files.
On Wed, 2015-07-29 at 20:07 +0900, Masahiro Yamada wrote:
> Hi Ian,
>
>
> 2015-07-27 19:35 GMT+09:00 Ian Campbell :
> > Commit 9ccd608070b6 "arm64: dts: add device tree for ARM SMM-A53x2 on
> > LogicTile Express 20MG" added a new dts file to arch/arm64 which
> > included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a
> > .dtsi supplied by arch/arm.
> >
> > Unfortunately this causes some issues for the split device tree
> > repository[0], since things get moved around there. In that context
> > the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
> > while the include is at src/arm/vexpress-v2m-rs1.dtsi.
> >
> > The sharing of the .dtsi is legitimate since the baseboard is the same
> > for various vexpress systems whatever processor they use.
> >
> > Rather than using ../../ tricks to pickup .dtsi files from another
> > arch this patch creates a new directory include/dt-dtsi as a
> > home for such cross-arch .dtsi files, arranges for it to be in the
> > include path when the .dts files are processed by cpp and switches the
>
>
> "include/dt-dtsi/" can be referenced from normal C sources.
>
> I think another possible home for cross-arch DTSI is "kernel/dts/".
> This directory can be hidden from C sources.
I suppose, I don't really mind and will follow the direction of the other
DTB maintainers. It doesn't seem like a big deal to me.
> >@@ -223,7 +223,7 @@ Example of a VE tile description (simplified)
> > /* Active high IRQ 0 is connected to GIC's SPI0 */
> > interrupt-map = <0 0 0 &gic 0 0 4>;
> >
> > - /include/ "vexpress-v2m-rs1.dtsi"
> > + #include
> > };
> > };
>
>
>
> You do not have to replace /include/ with #include,
> if you add the include path for DTC.
Ah, I looked for this but -i is not documented in the man page.
Is there any reason to prefer one over the other?
> Please add include path for DTC too
> so that both /include/ and #include are available.
OK.
I shall await further feedback on what path to use before spinning a v3.
Ian.
>
>
>
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index 79e8661..fc6c06c 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -285,7 +285,7 @@ quiet_cmd_dtc = DTC $@
> cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
> $(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $< ;
> \
> $(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 \
> - -i $(dir $<) $(DTC_FLAGS) \
> + -i $(dir $<) -i $(srctree)/kernel/dts $(DTC_FLAGS) \
> -d $(depfile).dtc.tmp $(dtc-tmp) ; \
> cat $(depfile).pre.tmp $(depfile).dtc.tmp > $(depfile)
>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] dtb: Create a common home for cross-architecture dtsi files.
Commit 9ccd608070b6 "arm64: dts: add device tree for ARM SMM-A53x2 on
LogicTile Express 20MG" added a new dts file to arch/arm64 which
included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a
.dtsi supplied by arch/arm.
Unfortunately this causes some issues for the split device tree
repository[0], since things get moved around there. In that context
the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
while the include is at src/arm/vexpress-v2m-rs1.dtsi.
The sharing of the .dtsi is legitimate since the baseboard is the same
for various vexpress systems whatever processor they use.
Rather than using ../../ tricks to pickup .dtsi files from another
arch this patch creates a new directory include/dt-dtsi as a
home for such cross-arch .dtsi files, arranges for it to be in the
include path when the .dts files are processed by cpp and switches the
.dts files to use cpp #include instead of /include/. The dtsi file
itself is moved into a vendor subdir in this case "arm" (the vendor,
not the ARCH=).
[0]
https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/
Signed-off-by: Ian Campbell
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Kumar Gala
Cc: Liviu Dudau
Cc: Sudeep Holla
Cc: Lorenzo Pieralisi
Cc: Russell King
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Kristina Martsenko
Cc: Kevin Hilman
Cc: devicetree@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kbu...@vger.kernel.org
---
v2: Move to include/dt-dtsi and introduce a per-vendor subdirectory.
---
Documentation/devicetree/bindings/arm/vexpress.txt | 4 ++--
arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 2 +-
arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 2 +-
arch/arm/boot/dts/vexpress-v2p-ca5s.dts | 2 +-
arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts | 2 +-
{arch/arm/boot/dts => include/dt-dtsi/arm}/vexpress-v2m-rs1.dtsi | 0
scripts/Makefile.lib | 1 +
7 files changed, 7 insertions(+), 6 deletions(-)
rename {arch/arm/boot/dts => include/dt-dtsi/arm}/vexpress-v2m-rs1.dtsi (100%)
diff --git a/Documentation/devicetree/bindings/arm/vexpress.txt
b/Documentation/devicetree/bindings/arm/vexpress.txt
index 39844cd..dccf570 100644
--- a/Documentation/devicetree/bindings/arm/vexpress.txt
+++ b/Documentation/devicetree/bindings/arm/vexpress.txt
@@ -7,7 +7,7 @@ peripherals. Processor and RAM "live" on the tiles.
The motherboard and each core tile should be described by a separate
Device Tree source file, with the tile's description including
-the motherboard file using a /include/ directive. As the motherboard
+the motherboard file using a #include directive. As the motherboard
can be initialized in one of two different configurations ("memory
maps"), care must be taken to include the correct one.
@@ -223,7 +223,7 @@ Example of a VE tile description (simplified)
/* Active high IRQ 0 is connected to GIC's SPI0 */
interrupt-map = <0 0 0 &gic 0 0 4>;
- /include/ "vexpress-v2m-rs1.dtsi"
+ #include
};
};
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
index 9420053..7ea7054 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
@@ -278,6 +278,6 @@
<0 0 41 &gic 0 41 4>,
<0 0 42 &gic 0 42 4>;
- /include/ "vexpress-v2m-rs1.dtsi"
+ #include
};
};
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
index 17f63f7..afe997a4 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
@@ -636,6 +636,6 @@
<0 0 41 &gic 0 41 4>,
<0 0 42 &gic 0 42 4>;
- /include/ "vexpress-v2m-rs1.dtsi"
+ #include
};
};
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
index d2709b7..498181c 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
@@ -248,6 +248,6 @@
<0 0 41 &gic 0 41 4>,
<0 0 42 &gic 0 42 4>;
- /include/ "vexpress-v2m-rs1.dtsi"
+ #include
};
};
diff --git a/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts
b/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts
index 5b1d018..b86c5a8 100644
--- a/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts
+++ b/arch/arm64/boot/dts
Re: [PATCH] dtb: Create a common home for cross-architecture dtsi files.
On Fri, 2015-07-24 at 12:31 +0100, Mark Rutland wrote: > On Wed, Jul 22, 2015 at 10:47:18AM +0100, Ian Campbell wrote: > > On Wed, 2015-07-22 at 09:47 +0100, Liviu Dudau wrote: > > > > > > Acked-by: Liviu Dudau > > > > Thanks. > > > > > Picking your brains here: would it be worth to have some vendor > > > directories in > > > this shared area or we can hope that there will be very few files > > > living here? > > > > I'm honestly not sure. > > > > I don't expect there will be very many files under here, and I > > would > > expect the norm would be that common .dtsi files used by multiple > > arches would be things from the same vendor, but I don't think we > > can > > guarantee that. > > I'm not so sure that this area will remain small. I suspect we'll see > a reasonable amount of sharing for arm/arm64 where two SoCs differ > sith > s/Cortex-A7/Cortex-A53/, for example. > > Perhaps we could wait until the that starts to happen; we managed to > survive for a while before moving arm64's dts into subdirs. If we think it is inevitable we may as well bite the bullet, plus I've already done "git commit --amend" to move it to include/dt-dtsi/arm ;-) Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dtb: Create a common home for cross-architecture dtsi files.
On Wed, 2015-07-22 at 09:47 +0100, Liviu Dudau wrote: > > Acked-by: Liviu Dudau Thanks. > Picking your brains here: would it be worth to have some vendor directories in > this shared area or we can hope that there will be very few files living here? I'm honestly not sure. I don't expect there will be very many files under here, and I would expect the norm would be that common .dtsi files used by multiple arches would be things from the same vendor, but I don't think we can guarantee that. Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dtb: Create a common home for cross-architecture dtsi files.
Commit 9ccd608070b6 "arm64: dts: add device tree for ARM SMM-A53x2 on
LogicTile Express 20MG" added a new dts file to arch/arm64 which
included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a
.dtsi supplied by arch/arm.
Unfortunately this causes some issues for the split device tree
repository[0], since things get moved around there. In that context
the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
while the include is at src/arm/vexpress-v2m-rs1.dtsi.
The sharing of the .dtsi is legitimate since the baseboard is the same
for various vexpress systems whatever processor they use.
Rather than using ../../ tricks to pickup .dtsi files from another
arch this patch creates a new directory include/dt-bindings/dtsi as a
home for such cross-arch .dtsi files, arranges for it to be in the
include path when the .dts files are processed by cpp and switches the
.dts files to use cpp #include instead of /include/.
[0]
https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/
Signed-off-by: Ian Campbell
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Kumar Gala
Cc: Liviu Dudau
Cc: Sudeep Holla
Cc: Lorenzo Pieralisi
Cc: Russell King
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Kristina Martsenko
Cc: Kevin Hilman
Cc: devicetree@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kbu...@vger.kernel.org
---
Documentation/devicetree/bindings/arm/vexpress.txt| 2 +-
arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 2 +-
arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts| 2 +-
arch/arm/boot/dts/vexpress-v2p-ca5s.dts | 2 +-
arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts | 2 +-
{arch/arm/boot/dts => include/dt-bindings/dtsi}/vexpress-v2m-rs1.dtsi | 0
scripts/Makefile.lib | 1 +
7 files changed, 6 insertions(+), 5 deletions(-)
rename {arch/arm/boot/dts => include/dt-bindings/dtsi}/vexpress-v2m-rs1.dtsi
(100%)
diff --git a/Documentation/devicetree/bindings/arm/vexpress.txt
b/Documentation/devicetree/bindings/arm/vexpress.txt
index 39844cd..46c6b04 100644
--- a/Documentation/devicetree/bindings/arm/vexpress.txt
+++ b/Documentation/devicetree/bindings/arm/vexpress.txt
@@ -223,7 +223,7 @@ Example of a VE tile description (simplified)
/* Active high IRQ 0 is connected to GIC's SPI0 */
interrupt-map = <0 0 0 &gic 0 0 4>;
- /include/ "vexpress-v2m-rs1.dtsi"
+ #include
};
};
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
index 9420053..85b201e 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
@@ -278,6 +278,6 @@
<0 0 41 &gic 0 41 4>,
<0 0 42 &gic 0 42 4>;
- /include/ "vexpress-v2m-rs1.dtsi"
+ #include
};
};
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
index 17f63f7..fe5091d 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
@@ -636,6 +636,6 @@
<0 0 41 &gic 0 41 4>,
<0 0 42 &gic 0 42 4>;
- /include/ "vexpress-v2m-rs1.dtsi"
+ #include
};
};
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
index d2709b7..a028d59 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
@@ -248,6 +248,6 @@
<0 0 41 &gic 0 41 4>,
<0 0 42 &gic 0 42 4>;
- /include/ "vexpress-v2m-rs1.dtsi"
+ #include
};
};
diff --git a/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts
b/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts
index 5b1d018..b4257ee 100644
--- a/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts
+++ b/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts
@@ -186,6 +186,6 @@
<0 0 41 &gic GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>,
<0 0 42 &gic GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
- /include/ "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi"
+ #include
};
};
diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
b/include/dt-bindings/dtsi/vexpress-v2m-rs1.dtsi
similarity index 100%
rename from arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
rename to include/dt-bindings/dtsi/vexpress-v2m-rs1.dtsi
diff --git a/scripts/Makefile.lib
Re: [PATCH 3/3] arm64: dts: add device tree for ARM SMM-A53x2 on LogicTile Express 20MG
On Tue, 2015-07-14 at 12:13 +0100, Sudeep Holla wrote: > > On 14/07/15 09:37, Ian Campbell wrote: > > On Wed, 2015-07-01 at 13:36 +0100, Sudeep Holla wrote: > > > >> diff --git a/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts > >> b/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts > >> new file mode 100644 > >> index ..5b1d0181023b > >> --- /dev/null > >> +++ b/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts > > [...] > >> + /include/ "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi" > > > > Unfortunately this causes some issues for the split device tree > > repository[0], since things get moved around there. > > > > This new file ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts > > while the include is at src/arm/vexpress-v2m-rs1.dtsi. > > > > Ah sorry, wasn't aware of such a effort to move DTS files out. > > > Any ideas how best to deal with this? > > > > Honestly no idea. We did discuss this internally with 2 options: > > 1. Specifying the relative path as done in this patch > 2. Creating symlink, something like how kvm manages files today > > I agree both are not elegant but (1) was chosen to be better of the two. > We are open for any suggestions. 3. Some path for DTSI files which are not specific to a particular architecture, picked up by dtc by default (via -I in default flags)? 4. DTC_FLAGS += -I../../../../arm/boot/dts in arch/arm64/boot/dts/Makefile and using #include "vexpressdtsi", with the split repo using a different -I in its build system (essentially codifying the relationship between arm64 and arm in the build system instead of the code). IMHO 4 is better than 1 or 3, although still not great. Not sure about 2 myself (from the PoV of working in both contexts). Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] arm64: dts: add device tree for ARM SMM-A53x2 on LogicTile Express 20MG
On Wed, 2015-07-01 at 13:36 +0100, Sudeep Holla wrote: > diff --git a/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts > b/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts > new file mode 100644 > index ..5b1d0181023b > --- /dev/null > +++ b/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts [...] > + /include/ "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi" Unfortunately this causes some issues for the split device tree repository[0], since things get moved around there. This new file ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts while the include is at src/arm/vexpress-v2m-rs1.dtsi. Any ideas how best to deal with this? I'm willing to try and work around in the conversion scripts but while rewriting the paths to things on conversion is easy, rewriting the contents of the files themselves is much less so (or at least would be prohibitively expensive on input the size of Linux). Cheers, Ian. [0] https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/ -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: sun6i: Add a dts file for the Mele A1000G quad top set box
On Mon, 2015-06-01 at 17:02 +0200, Hans de Goede wrote: > The Mele A1000G-quad and the Mele M9 have the same PCB, sofar we've been using > the same dts for both models. Unfortunately this does not work for the otg > controller, on the M9 this is routed to a micro-usb connector on the outside, > while as on the A1000G-quad it is connected to an usb to sata bridge > (which is not populated on the M9 pcb). > > This commit adds a new dts for the Mele-A1000G-quad to allow using > different otg controller settings on the 2 boards. But isn't intending to actually change the otg settings, right? -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-sunxi] Re: [PATCH] ARM: sun6i: dt: Add new Mele I7 device
On Tue, 2015-03-10 at 12:16 +0100, Hans de Goede wrote: > I'm not sure if stdout-path supports aliases I thought it did but ePAPR section 3.5 says "A string that specifies the full path to the node" which suggests not, and AFAICT the code doesn't try to handle alias. Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] dtb: xgene: fix: Backward compatibility with older firmware
On Fri, 2015-01-09 at 15:59 +, Ian Campbell wrote: > I'm running mustang_sw_1.13.29-beta, using the mustang_tianocore_ubt.fd > method to launch from u-boot. I realised shortly after that I had downloaded 1.14.14 too, but it behaves the same. I rebuilt mustang_tianocore_ubt.fd with the first hunk of this patch and things now work. Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] dtb: xgene: fix: Backward compatibility with older firmware
Hi Iyappan, On Mon, 2014-11-03 at 11:59 -0800, Iyappan Subramanian wrote: > The following kernel crash was reported when using older firmware (<= > 1.13.28). > > [0.98] libphy: APM X-Gene MDIO bus: probed > [1.13] Unhandled fault: synchronous external abort (0x9610) at > 0xff89a17c > [1.14] Internal error: : 9610 [#1] SMP > [1.14] Modules linked in: > [1.14] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.17.0+ #21 > [1.14] task: ffc3f011 ti: ffc3f0064000 task.ti: > ffc3f0064000 > [1.14] PC is at ioread32+0x58/0x68 > [1.14] LR is at xgene_enet_setup_ring+0x18c/0x1cc I'm seeing what appears to be a similar crash (see the end) when booting using UEFI firmware, which provides the DTB itself (as opposed to using the kernel provided one like with u-boot). Trying to boot using the kernel DTB instead of the firmware provided one fails, I think because the UEFI firmware normally updates a bunch of stuff at runtime in what it provides, but it can't in the external one. (i.e. it has the wrong spintable stuff for cpu bringup) This is running Debian's 3.16 kernel, which has the APM Ethernet related stuff backported: $ git log --oneline v3.16.7..debian/jessie/xgene b2553d6 arm64: removed using of the mask attribute in the dts for reset bit. 2d209a4 arm64: add missing dts entry for X-Gene platform. 60651f8 dtb: Add SGMII based 1GbE node to APM X-Gene SoC device tree 3f3c3da dtb: Add 10GbE node to APM X-Gene SoC device tree 33b5408 drivers: net: xgene: fix: Use separate resources 092e35e drivers: net: xgene: Backward compatibility with older firmware 9f2bc2c drivers: net: xgene: Rewrite buggy loop in xgene_enet_ecc_init() c566829 drivers: net: xgene: Add SGMII based 1GbE ethtool support 30bf224 drivers: net: xgene: Add SGMII based 1GbE support 0d03931 drivers: net: xgene: Preparing for adding SGMII based 1GbE 23a92cd drivers: net: xgene: Add 10GbE ethtool support 226068a drivers: net: xgene: Add 10GbE support 33f8dba drivers: net: xgene: Preparing for adding 10GbE support a7b5fd0 dts: Add bindings for APM X-Gene SoC ethernet driver 82df3ba drivers: net: NET_XGENE should depend on HAS_DMA 0dcba55 net: xgene: fix possible NULL dereference in xgene_enet_free_desc_rings() 2aa3e0d net: xgene: Check negative return value of xgene_enet_get_ring_size() 589e045 drivers: net: Add APM X-Gene SoC ethernet driver support. With the builtin DTB I see: (initramfs) od -A x -t x4 /proc/device-tree/soc/ethernet@1702/reg 00 0217 00d1 10 0317 0004 20 0010 0002 Which seems to correspond to before your patch. I'm running mustang_sw_1.13.29-beta, using the mustang_tianocore_ubt.fd method to launch from u-boot. Ian. [7.662085] Unhandled fault: synchronous external abort (0x9610) at 0xff89a208 [7.670332] Internal error: : 9610 [#1] SMP [7.674839] Modules linked in: xgene_enet(+) of_mdio libphy dm_mod(+) [7.681300] CPU: 0 PID: 97 Comm: systemd-udevd Not tainted 3.16.0-4-arm64 #1 Debian 3.16.7-ckt2-1 [7.690126] task: ffc3f9ca0c80 ti: ffc3f9d2c000 task.ti: ffc3f9d2c000 [7.697571] PC is at ioread32+0x58/0x68 [7.701388] LR is at xgene_ring_mgr_init+0x28/0x58 [xgene_enet] [7.707276] pc : [] lr : [] pstate: a145 [7.714632] sp : ffc3f9d2f9c0 [7.717926] x29: ffc3f9d2f9c0 x28: 0001 [7.723229] x27: ffc0006fa000 x26: [7.728533] x25: ffc3f9ce9000 x24: ffc3f9ce9000 [7.733836] x23: ffc3eb876010 x22: ffc3eb876000 [7.739138] x21: ffc000763000 x20: ffc3f9ce98c0 [7.73] x19: ffc3f9ce98c0 x18: c3663f63 [7.749745] x17: c14123be x16: ca92bd38 [7.755048] x15: d02a0bde x14: [7.760350] x13: x12: [7.765652] x11: x10: [7.770955] x9 : x8 : [7.776257] x7 : x6 : [7.781559] x5 : ffc00074b310 x4 : [7.786861] x3 : x2 : 0003 [7.792165] x1 : ff89a208 x0 : ff89a208 [7.797467] [7.798948] Process systemd-udevd (pid: 97, stack limit = 0xffc3f9d2c058) [7.806046] Stack: (0xffc3f9d2f9c0 to 0xffc3f9d3) [7.811762] f9c0: f9d2f9d0 ffc3 fc035d18 ffbf f9d2f9f0 ffc3 fc035d6c ffbf [7.819897] f9e0: f9ce98c0 ffc3 f9d2f9e0 ffc3 f9d2fa30 ffc3 fc038110 ffbf [7.828032] fa00: f9ce98c0 ffc3 f9ce9000 ffc3 00763000 ffc0 f9ce9000 ffc3 [7.836167] fa20: 005c 00
Re: [PATCH] of/fdt: memblock_reserve /memreserve/ regions in the case of partial overlap
On Tue, 2014-11-25 at 13:31 -0600, Rob Herring wrote:
> On Tue, Nov 25, 2014 at 8:37 AM, Grant Likely wrote:
> > On Tue, 25 Nov 2014 12:54:55 +0000
> > , Ian Campbell
> > wrote:
> >> memblock_is_region_reserved() returns true in the case of a partial
> >> overlap, meaning that the current code fails to reserve the
> >> non-overlapping portion.
> >>
> >> I observed this causing a Midway system with a buggy fdt (the header
> >> declares itself to be larger than it really is) failing to boot
> >> because the over-inflated size of the fdt was causing it to seem to
> >> run into the swapper_pg_dir region, meaning the DT wasn't reserved.
> >> The symptoms were failing to find an disks or network and failing to
> >> boot. I think it is work printing a warning in this case.
> >>
> >> However given the ambiguity of whether things like the initrd are
> >> covered by /memreserve/ and similar I think it is best to also
> >> register the region rather than just ignoring it.
> >>
> >> Since memblock_reserve() handles overlaps just fine lets just warn and
> >> carry on.
> >>
> >> Signed-off-by: Ian Campbell
> >> Cc: Grant Likely
> >> Cc: Rob Herring
> >> Cc: devicetree@vger.kernel.org
> >> ---
> >> drivers/of/fdt.c |3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> >> index 30e97bc..4f0f24c 100644
> >> --- a/drivers/of/fdt.c
> >> +++ b/drivers/of/fdt.c
> >> @@ -965,7 +965,8 @@ int __init __weak
> >> early_init_dt_reserve_memory_arch(phys_addr_t base,
> >> phys_addr_t size, bool nomap)
> >> {
> >> if (memblock_is_region_reserved(base, size))
> >> - return -EBUSY;
> >> + pr_warning("DT reserved region at 0x%pa is already
> >> reserved\n",
> >> +&base);
> >
> > Since memblock_remove/reserve does the right thing anyway, let's just
> > drop the test entirely.
>
> If the region completely overlaps, then I agree it is okay to be
> quiet. But if we have partially overlapping region already with the
> dtb, then we should warn here. We want to know if someone passes a dtb
> that is too big.
Unfortunately memblock isn't currently capable of distinguishing partial
vs total overlap.
We could perhaps warn iff only on of the first and last byte of the new
region are already reserved, but not if they both are. i.e.
if (memblock_is_region_reserved(base, size) &&
!!memblock_is_region_reserved(base, 1) !=
!!memblock_is_region_reserved(base+size-1, 1))
That wouldn't handle
RESERVED---||RESERVED-
|- NEW REGION|
But maybe it's better than nothing.
Or we could pull the warning up to the caller which reserves the DTB but
not for the /memreserve/ loop.
Ian.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] of: support passing console options with stdout-path
On Tue, 2014-11-25 at 15:39 +, Grant Likely wrote: > On Tue, Nov 25, 2014 at 3:24 PM, Ian Campbell wrote: > >> sed s/of_find_node_by_path\((.*)\)/of_find_node_by_path\(\1, NULL\) > > > > Coccinelle rules for this sort of transformation... > > /me still hasn't gotten his head around how to use Coccinelle properly. :-( Me neither, but for the "add an extra NULL parameter" case I can generally find something to cargo cult from ;-) (it's been ages since I had a need though) Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] of: support passing console options with stdout-path
On Tue, 2014-11-25 at 15:20 +, Grant Likely wrote:
> On Tue, Nov 25, 2014 at 3:15 PM, Leif Lindholm
> wrote:
> > On Tue, Nov 25, 2014 at 02:58:54PM +, Grant Likely wrote:
> >> > + len = strchrnul(path, ':') - path;
> >> > +
> >> > for_each_property_of_node(of_aliases, pp) {
> >> > if (strlen(pp->name) == len && !strncmp(pp->name,
> >> > path, len)) {
> >> > np = of_find_node_by_path(pp->value);
> >>
> >> Can you add a testcase to drivers/of/unittests.c for this new path
> >> parsing? Then we know it's correct!
> >
> > Will do.
> >
> >> > @@ -1830,8 +1835,12 @@ void of_alias_scan(void * (*dt_alloc)(u64 size,
> >> > u64 align))
> >> > name = of_get_property(of_chosen,
> >> > "linux,stdout-path", NULL);
> >> > if (IS_ENABLED(CONFIG_PPC) && !name)
> >> > name = of_get_property(of_aliases, "stdout", NULL);
> >> > - if (name)
> >> > + if (name) {
> >> > of_stdout = of_find_node_by_path(name);
> >> > + of_stdout_options = strchr(name, ':');
> >> > + if (of_stdout_options != NULL)
> >> > + of_stdout_options++;
> >> > + }
> >>
> >> Not so good. The ':' should actually be a generic part of
> >> of_find_node_by_path(), it doesn't have to be limited to stdout parsing.
> >> There are other places that would use it. I would add a second,
> >> optional, argument to of_find_node_by_path() that will update a pointer
> >> to the arguments after the ':'.
> >
> > So, I agree this would be nicer...
> >
> > However, I'm counting 157 callers of this function outside of
> > drivers/of and 43 inside. Any chance you'd let me get away with a
> > separate of_find_extra_options_by_path()?
>
> I'd rather not. It is a trivial change and can be pretty much done
> mechanically. Something like (I think; I always have to look up the
> sed syntax):
>
> sed s/of_find_node_by_path\((.*)\)/of_find_node_by_path\(\1, NULL\)
Coccinelle rules for this sort of transformation...
Ian.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] of/fdt: memblock_reserve /memreserve/ regions in the case of partial overlap
memblock_is_region_reserved() returns true in the case of a partial
overlap, meaning that the current code fails to reserve the
non-overlapping portion.
This call was introduced as part of d1552ce449eb "of/fdt: move
memreserve and dtb memory reservations into core" which went into
v3.16.
I observed this causing a Midway system with a buggy fdt (the header
declares itself to be larger than it really is) failing to boot
because the over-inflated size of the fdt was causing it to seem to
run into the swapper_pg_dir region, meaning the DT wasn't reserved.
The symptoms were failing to find an disks or network and failing to
boot.
However given the ambiguity of whether things like the initrd are
covered by /memreserve/ and similar I think it is best to also
register the region rather than just ignoring it.
Since memblock_reserve() handles overlaps just fine lets just warn and
carry on.
Signed-off-by: Ian Campbell
Cc: Grant Likely
Cc: Rob Herring
Cc: devicetree@vger.kernel.org
Cc: sta...@vger.kernel.org # v3.16+
---
v2: Tag for stable v3.16+
Just drop the test, no need to log.
---
drivers/of/fdt.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 30e97bc..d134710 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -964,8 +964,6 @@ void __init __weak early_init_dt_add_memory_arch(u64 base,
u64 size)
int __init __weak early_init_dt_reserve_memory_arch(phys_addr_t base,
phys_addr_t size, bool nomap)
{
- if (memblock_is_region_reserved(base, size))
- return -EBUSY;
if (nomap)
return memblock_remove(base, size);
return memblock_reserve(base, size);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] of/fdt: memblock_reserve /memreserve/ regions in the case of partial overlap
memblock_is_region_reserved() returns true in the case of a partial
overlap, meaning that the current code fails to reserve the
non-overlapping portion.
I observed this causing a Midway system with a buggy fdt (the header
declares itself to be larger than it really is) failing to boot
because the over-inflated size of the fdt was causing it to seem to
run into the swapper_pg_dir region, meaning the DT wasn't reserved.
The symptoms were failing to find an disks or network and failing to
boot. I think it is work printing a warning in this case.
However given the ambiguity of whether things like the initrd are
covered by /memreserve/ and similar I think it is best to also
register the region rather than just ignoring it.
Since memblock_reserve() handles overlaps just fine lets just warn and
carry on.
Signed-off-by: Ian Campbell
Cc: Grant Likely
Cc: Rob Herring
Cc: devicetree@vger.kernel.org
---
drivers/of/fdt.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 30e97bc..4f0f24c 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -965,7 +965,8 @@ int __init __weak
early_init_dt_reserve_memory_arch(phys_addr_t base,
phys_addr_t size, bool nomap)
{
if (memblock_is_region_reserved(base, size))
- return -EBUSY;
+ pr_warning("DT reserved region at 0x%pa is already reserved\n",
+ &base);
if (nomap)
return memblock_remove(base, size);
return memblock_reserve(base, size);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] of: support passing console options with stdout-path
On Tue, 2014-11-25 at 11:17 +, Leif Lindholm wrote:
> On Tue, Nov 25, 2014 at 10:35:04AM +, Mark Rutland wrote:
> > On Mon, Nov 24, 2014 at 10:23:58PM +, Leif Lindholm wrote:
> > > Support specifying console options (like with console=ttyXN,)
> > > by appending them to the stdout-path property after a separating ':'.
> > >
> > > Example:
> > > stdout-path = "uart0:115200";
> >
> > I would very much like to be able to use this -- it will allow
> > distributions to boot on a board without having to know _anything_ about
> > the console UART until userspace is up, which would make it possible to
> > have a completely generic installer image, without requiring the
> > platform to provide bootargs.
> >
> > My only concern is that this conflates the set of kernel command line
> > options for the UART wit the DT binding for it. I don't know how good
> > people are at keeping those options stable, and I know they are
> > currently not documented -- we would need to add a stdout-path options
> > section to relevant UART bindings.
>
> I don't disagree.
>
> Current options are fairly well defined and stable, at least for any
> driver that uses uart_parse_options() (documented in
> Documentation/serial/driver).
My concern is that this is Linux specific, other OSes may have different
ideas about how stdout options should be formatted within this property.
(At least I don't know of any standardisation of the 115200n8 thing --
I'd love to be corrected!)
If I were a firmware author I'd be wary of specifying a stdout-path with
a Linux specific suffix.
Search ePAPR for baud it seems that the generic serial binding includes
a current-speed property in 6.2.1.2. It then goes on a bit ambiguously
to talk about the NS16550 in 6.2.2 but I think 6.2.1.2 was intended to
be generic. No mention of stop-bits/parity etc though, they are assumed
to be set already I think
One thought I had was to define a dt-stdout "pseudo-console" so that
console=dt-stdout,115200n8 or something could be used.
Anyway I applied your patch to v3.18-rc5 and ran it on a Mustang and it
didn't work for some reason. I'm using:
fdt set /chosen stdout-path "/soc/serial@1c02:115200"
setenv bootargs "earlycon=uart8250,mmio32,0x1c02 root=/dev/sda3 rw
debug"
So I get earlycon but then no proper console. Removing earlycon just
makes that stop working.
With:
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 89c6b33..5dc1718 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1840,6 +1840,8 @@ void of_alias_scan(void * (*dt_alloc)(u64 size, u64
align))
of_stdout_options = strchr(name, ':');
if (of_stdout_options != NULL)
of_stdout_options++;
+ printk(KERN_CRIT "%s: name=%s of_stdout=%p
options=%s\n",
+ __func__, name, of_stdout, of_stdout_options);
}
}
I can see in dmesg:
[0.00] of_alias_scan: name=/soc/serial@1c02:115200 of_stdout=
(null) options=115200
So it seems like of_find_node_by_path() is confused by the ":".
I've not tried it but I'd have expected something more like:
if (name) {
of_stdout_options = strchr(name, ':');
if (of_stdout_options != NULL) {
*of_stdout_options = '0';
of_stdout_options++;
}
of_stdout = of_find_node_by_path(name);
}
i.e. strip the options then do the patch lookup. name is const so this
won't actually work, but something like it...
Ian.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5.5] of/fdt: export fdt blob as /sys/firmware/fdt
On Tue, 2014-11-18 at 22:11 +, Grant Likely wrote: > > > * It also helps with exposing the reserved map to userspace, but kexec > > > has done without that feature for years, and it is in the process of > > > being deprecated in favour of /reserved-memory anyway. > > > > This is the first I'd heard of the reserve map being deprecated, and > > we're going to have DTs with reserved map entries for a long time going > > forwards. > > Deprecated, not removed or disabled. It will still work pretty much > forever, but users should be encouraged to move to the reserve-memory > tree. I'm curious why that should be for the "OS should never touch this, here be dragons" type memory, what are the benefits of the new scheme in that case? I can see it for e.g. framebuffer or cma which the OS might actually use under special circumstances and therefore need more info than just "don't use this". It looks like as well as observing the requested reservations Xen might also need to somehow reflect them to dom0, I need to think on this. If there are any useful references over and above Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt then I'd be glad to see them. Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] dt-bindings: simplefb-sunxi: Add sunxi simplefb extensions
On Tue, 2014-11-18 at 09:15 +0100, Hans de Goede wrote:
> Hi,
>
> On 11/17/2014 04:55 PM, Maxime Ripard wrote:
> > On Mon, Nov 17, 2014 at 01:39:18PM +, Grant Likely wrote:
> >> On Mon, Nov 17, 2014 at 12:47 PM, Maxime Ripard
> >> wrote:
> >>> On Mon, Nov 17, 2014 at 12:34:46PM +0100, Hans de Goede wrote:
> If pre-filled framebuffer nodes are used, the firmware may need extra
> properties to find the right node. This documents the properties to use
> for this on sunxi platforms.
>
> Signed-off-by: Hans de Goede
> ---
> .../bindings/video/simple-framebuffer-sunxi.txt| 33
> ++
> 1 file changed, 33 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
>
> diff --git
> a/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
> b/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
> new file mode 100644
> index 000..84ca264
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
> @@ -0,0 +1,33 @@
> +Sunxi specific Simple Framebuffer bindings
> +
> +This binding documents sunxi specific extensions to the
> simple-framebuffer
> +bindings. The sunxi simplefb u-boot code relies on the devicetree
> containing
> +pre-populated simplefb nodes.
> +
> +These extensions are intended so that u-boot can select the right node
> based
> +on which pipeline and output is being used. As such they are solely
> intended
> +for firmware / bootloader use, and the OS should ignore them.
> +
> +Required properties:
> +- compatible: "sunxi,framebuffer"
> +- sunxi,pipeline:
> + <0> for the de_be0 -> lcdc0 -> output pipeline
> + <1> for the de_be1 -> lcdc1 -> output pipeline
> +- sunxi,output: One of: "hdmi", "lcd", "vga", and "composite"
> +
> +Example:
> +
> +chosen {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + framebuffer@0 {
> + compatible = "sunxi,framebuffer", "simple-framebuffer";
> + sunxi,pipeline = <0>;
> + sunxi,output = "hdmi";
> + clocks = <&pll5 1>, <&ahb_gates 36>, <&ahb_gates 43>,
> + <&ahb_gates 44>;
> >>>
> >>> If we're going that way, then maybe having to specify clock-names
> >>> would be better in order to know which clock is what?
> >>
> >> I wouldn't go that way with this binding since the driver has no need
> >> to differentiate between the clocks, and driver authors shouldn't be
> >> encouraged to do so. The purpose of the clocks in this node is only
> >> for itemizing dependencies, not for how to configure the clocks.
> >> Firmware shouldn't care at all about the clocks list, it only needs to
> >> find the correct pre-populated node to fill in and enable.
> >
> > Well, if we want to play the "DT as an ABI" stuff, you have no
> > guarantee that in the future, simplefb will still be the driver bound
> > to "sunxi,framebuffer"
>
> Huh? We do have that guarantee, or at least that a simplefb bindings
> compatible driver is, the "sunxi,framebuffer" bindings live in:
>
> Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
>
> With the filename already being a big hint, further more it states that:
>
> "This binding documents sunxi specific extensions to the simple-framebuffer
> bindings. The sunxi simplefb u-boot code relies on the devicetree containing
> pre-populated simplefb nodes.
>
> These extensions are intended so that u-boot can select the right node based
> on which pipeline is being used. As such they are solely intended for
> firmware / bootloader use, and the OS should ignore them."
There may be an argument here for using the slightly redundant compat
string "allwinner,simple-framebuffer" in order to reinforce that this is
an extension to simple-framebuffer, as opposed to a binding for a
completely separate "non-simple" sunxi framebuffer driver which I think
is what Maxime may be imagining.
Alternatively (or as well) perhaps these extension should be a series of
extensions (one per platform) described in "appendices" of the main
simple-framebuffer.txt. I know Grant expressed a preference for a
separate document though and I think just using the more expressive name
above would be sufficient, but thought I'd mention it as a possible
option.
Ian.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] dt-bindings: simplefb-sunxi: Add sunxi simplefb extensions
On Mon, 2014-11-17 at 12:34 +0100, Hans de Goede wrote:
> +- sunxi,pipeline:
> + <0> for the de_be0 -> lcdc0 -> output pipeline
> + <1> for the de_be1 -> lcdc1 -> output pipeline
Can we express this as a more descriptive string rather than a number,
to better handle future developments?
Otherwise both patches in this series look good to me.
> +- sunxi,output: One of: "hdmi", "lcd", "vga", and "composite"
> +
> +Example:
> +
> +chosen {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + framebuffer@0 {
> + compatible = "sunxi,framebuffer", "simple-framebuffer";
> + sunxi,pipeline = <0>;
> + sunxi,output = "hdmi";
> + clocks = <&pll5 1>, <&ahb_gates 36>, <&ahb_gates 43>,
> + <&ahb_gates 44>;
> + status = "disabled";
> + };
> +};
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [PATCH 5/6] sunxi: video: Add simplefb support
On Mon, 2014-11-17 at 09:58 +, Grant Likely wrote: > I /DO/ want comments though. Putting the node in /chosen is > unconventional. I want to hear if anyone has a good reason why the > framebuffers shouldn't be placed into /chosen. I don't think putting it under /chosen is a problem at all. THe semantics of some of hte convention properties are a bit odd under there, but that's not insurmountable. > >> AFAIK Grant agrees with v5 > > > > AFAIK Grant hasn't actually said that. If he does ack it (or if someone > > points me to the correct mail) then I have no further objections. > > My word also isn't gospel. I suppose I should have said something like "I trust Grant's judgement more than my own on things relating to DT" ;-). > On controversial stuff I want to have > consensus. For the clock patches and had a long conversation with Rob > to make sure we were both in agreement before giving my final ack. > > > In fact it's a bit odd to have a reg property under /chosen at all, > > since it doesn't really fit in with the bus structure. I've done > > something similar in some bindings I've authored[0], but AIUI I got that > > wrong and really should have used a set of non-reg properties with a > > single value so there was no need to parse using #*-cells (cf the > > initrd-start + initrd-end properties under /chosen). Sadly DT is an ABI, > > so for my bindings I'm kind of stuck with it for the foreseeable future. > > > > [0] > > http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/device-tree/booting.txt;h=08ed7751859dbe2d2c32d86d7df371057d7b45a4;hb=HEAD > > Ironic isn't it that I though of that as precedence when I suggested > /chosen! :-) :-) > I actually don't have a problem with it. We do need a way to specify > runtime memory usage, and /chosen is as good a place as any, > particularly when it represents things that won't necessarily be > relevant on kexec or dom0 boot. The main issue which was explained to me with my Xen bindings was that reg = <> isn't all that meaningful under /chosen because it doesn't fit into the bus structure, so the #address-/size-cells stuff gets a bit strange. It's probably tolerable for things which are strictly physical RAM addresses (as opposed to mmio) since RAM isn't typically behind a visible bus. The scheme used for initrds sidesteps all those issues by using separate (multicellular) properties for the start and end regions and not using reg=<> and therefore naturally breaking the expected semantic link with bus topology which reg implies etc. > The other options are under either the /memory or the /reserved-memory > tree. Rob and I talked about /reserved-memory quite a lot. We could > put all the framebuffer details into the memory node that reserves the > framebuffer. However, I don't like that idea because it kind of makes > assumptions about how the framebuffer will be located inside the > memory region and doesn't allow for multiple framebuffers within a > single region. Yes, that sounds strictly worse than the current solution to me. Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [PATCH 5/6] sunxi: video: Add simplefb support
On Sun, 2014-11-16 at 16:11 +, Ian Campbell wrote: > > > AFAIK Grant agrees with v5 > > AFAIK Grant hasn't actually said that. If he does ack it (or if > someone > points me to the correct mail) then I have no further objections. I finally found which for some reason isn't in my devicetree@ folder nor in any of the archives online I looked at earlier (I could only find it by message-id now I know it), but it was in my sunxi folder. So with Grant and Rob having accepted them you can consider my concerns with the bindings alleviated. Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] sunxi: video: Add simplefb support
On Sun, 2014-11-16 at 16:11 +0100, Hans de Goede wrote:
> Hi,
>
> On 11/16/2014 03:38 PM, Ian Campbell wrote:
> > devicetree@, comments on the requirement that a node have a specific
> > path welcomed.
> >
> > On Sun, 2014-11-16 at 14:52 +0100, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 11/16/2014 12:50 PM, Ian Campbell wrote:
> >>> On Fri, 2014-11-14 at 17:54 +0100, Hans de Goede wrote:
> >>>> From: Luc Verhaegen
> >>>>
> >>>> Add simplefb support, note this depends on the kernel having support for
> >>>> the clocks property which has recently been added to the simplefb
> >>>> devicetree
> >>>> binding.
> >>>
> >>> Link please, Linus's tree[0] doesn't seem to have it yet, I suppose it
> >>> is in some maintainer tree at the moment? It's not even in linux-next
> >>> yet though[1]. Maybe simple-framebuffer.txt isn't the right place to
> >>> look?
> >>
> >> Right now it is sitting here, which is the fbdev maintainers official tree:
> >> https://git.kernel.org/cgit/linux/kernel/git/tomba/linux.git/log/?h=for-next
> >>
> >>>
> >>> [0]
> >>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> >>> [1]
> >>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> >>>
> >>>> +#if defined(CONFIG_OF_BOARD_SETUP) && defined(CONFIG_VIDEO_DT_SIMPLEFB)
> >>>> +void
> >>>> +sunxi_simplefb_setup(void *blob)
> >>>> +{
> >>>> +static GraphicDevice *graphic_device =
> >>>> &sunxi_display.graphic_device;
> >>>> +const char *node = "/chosen/framebuffer0-hdmi";
> >>>> +const char *format = "x8r8g8b8";
> >>>
> >>> The bindings doc currently says:
> >>>
> >>> - format: The format of the framebuffer surface. Valid values are:
> >>> - r5g6b5 (16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b).
> >>> - a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g,
> >>> d[7:0]=r).
> >>>
> >>> Perhaps x8r8g8b8 is defined in the updated version?
> >>
> >> Erm, no, I don't think anyone has actually bothered to keep the list in the
> >> binding up2date with what the kernel actually supports, x8r8g8b8 has been
> >> supported in the kernel before sunxi + simplefb every became a topic.
> >
> > That's a shame, OS authors shouldn't really be expected to scrobble
> > about in Linux source to figure out what a binding is.
> >
> >>>> +const char *okay = "okay";
> >>>> +char name[32];
> >>>> +fdt32_t cells[2];
> >>>> +int offset, stride, ret;
> >>>> +
> >>>> +if (!sunxi_display.enabled)
> >>>> +return;
> >>>> +
> >>>> +offset = fdt_path_offset(blob, node);
> >>>
> >>> I think you should use fdt_node_offset_by_compatible here instead of
> >>> hardcoding a path.
> >>
> >> Hardcoding a path is deliberate. I don't know if you've read the
> >> previous u-boot code for this, but it did a lot of dt parsing to
> >> find clocks and add phandles to them, the way we eventually settled
> >> on when discussing this is for the dts to contain pre-populated simplefb
> >> nodes which u-boot just needs to fill with the mode info and enable, this
> >> way as we add support for more clocks (like the module clocks for the
> >> various display pipeline blocks), we don't need to update u-boot in
> >> lock-step,
> >> we just add the clocks to the simplefb node in the dts file when they get
> >> added to the dts file in the first place. See the updated bindings.
> >
> > AFAICT this in no way invalidates what I suggested. There's no reason
> > why the need to populate/tweak a pre-existing node should have anything
> > to do with where the node is in the device-tree.
>
> Right, I forgot to add one important bit to my explanation, sorry, if
> you look at the binding then it says that the name should be suffixed
> with the output type, so currently the sunxi u-boot code will
Re: [PATCH 5/6] sunxi: video: Add simplefb support
devicetree@, comments on the requirement that a node have a specific
path welcomed.
On Sun, 2014-11-16 at 14:52 +0100, Hans de Goede wrote:
> Hi,
>
> On 11/16/2014 12:50 PM, Ian Campbell wrote:
> > On Fri, 2014-11-14 at 17:54 +0100, Hans de Goede wrote:
> >> From: Luc Verhaegen
> >>
> >> Add simplefb support, note this depends on the kernel having support for
> >> the clocks property which has recently been added to the simplefb
> >> devicetree
> >> binding.
> >
> > Link please, Linus's tree[0] doesn't seem to have it yet, I suppose it
> > is in some maintainer tree at the moment? It's not even in linux-next
> > yet though[1]. Maybe simple-framebuffer.txt isn't the right place to
> > look?
>
> Right now it is sitting here, which is the fbdev maintainers official tree:
> https://git.kernel.org/cgit/linux/kernel/git/tomba/linux.git/log/?h=for-next
>
> >
> > [0]
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> > [1]
> > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> >
> >> +#if defined(CONFIG_OF_BOARD_SETUP) && defined(CONFIG_VIDEO_DT_SIMPLEFB)
> >> +void
> >> +sunxi_simplefb_setup(void *blob)
> >> +{
> >> + static GraphicDevice *graphic_device = &sunxi_display.graphic_device;
> >> + const char *node = "/chosen/framebuffer0-hdmi";
> >> + const char *format = "x8r8g8b8";
> >
> > The bindings doc currently says:
> >
> > - format: The format of the framebuffer surface. Valid values are:
> > - r5g6b5 (16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b).
> > - a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g,
> > d[7:0]=r).
> >
> > Perhaps x8r8g8b8 is defined in the updated version?
>
> Erm, no, I don't think anyone has actually bothered to keep the list in the
> binding up2date with what the kernel actually supports, x8r8g8b8 has been
> supported in the kernel before sunxi + simplefb every became a topic.
That's a shame, OS authors shouldn't really be expected to scrobble
about in Linux source to figure out what a binding is.
> >> + const char *okay = "okay";
> >> + char name[32];
> >> + fdt32_t cells[2];
> >> + int offset, stride, ret;
> >> +
> >> + if (!sunxi_display.enabled)
> >> + return;
> >> +
> >> + offset = fdt_path_offset(blob, node);
> >
> > I think you should use fdt_node_offset_by_compatible here instead of
> > hardcoding a path.
>
> Hardcoding a path is deliberate. I don't know if you've read the
> previous u-boot code for this, but it did a lot of dt parsing to
> find clocks and add phandles to them, the way we eventually settled
> on when discussing this is for the dts to contain pre-populated simplefb
> nodes which u-boot just needs to fill with the mode info and enable, this
> way as we add support for more clocks (like the module clocks for the
> various display pipeline blocks), we don't need to update u-boot in lock-step,
> we just add the clocks to the simplefb node in the dts file when they get
> added to the dts file in the first place. See the updated bindings.
AFAICT this in no way invalidates what I suggested. There's no reason
why the need to populate/tweak a pre-existing node should have anything
to do with where the node is in the device-tree.
My suggestion literally amounts to:
- offset = fdt_path_offset(blob, node);
+ offset = fdt_node_offset_by_compatible(blob, -1, "simple-framebuffer");
Nothing else in the code changes. You can still add the required details
to the prepopulated node, no matter where it lives.
I notice that v1 of these bindings was posted mid last week and were
still being discussed (at v5) on Friday, where there was active
discussion by DT maintainers (Grant, who hasn't yet acked it AFAICT). So
why is this in the fb tree already?
It seems to me that this binding is not yet at the point where u-boot
should be basing implementation on it. I'm sorry if this means this
feature misses the current u-boot merge window, but there will be
another soon. (didn't this one close on the 8th anyway?)
> > common/lcd.c does it this way too, it also doesn't
> > appear to use a node under /chosen. Perhaps this is changed in the more
> > uptodate binding which I've not seen yet.
>
> The use of /chosen is part of the updated bindings, which were discussed
>
Re: devicetree repository separation/migration
On Tue, 2014-02-25 at 07:36 +, Ian Campbell wrote: > On Tue, 2014-02-25 at 08:26 +0100, Sascha Hauer wrote: > > On Mon, Feb 24, 2014 at 03:59:17PM +0000, Ian Campbell wrote: > > > On Fri, 2014-02-21 at 15:11 +0100, Sascha Hauer wrote: > > > > Ians dts repository is a good start, but it contains a complete kernel > > > > history and this is not very suitable as a submodule for other > > > > projects. > > > > > > It only contains the full history for the files which it contains, not a > > > complete kernel history. This is deliberate so that "git annotate" etc > > > still works to tell you where a particular line came from. > > > > I have cloned git://xenbits.xen.org/people/ianc/device-tree-rebasing.git. > > .git is 843MB in size and after a 'git checkout v3.13' I see a vanilla v3.13 > > checked out. I may have done something wrong, but I don't see what it > > could be. > > There is a branch with the full Linux stuff in there too. It is needed > in the tree doing the conversion but doesn't really need to be > published. I pushed it in the early days without really thinking about > the size impact. I'll remove that stuff from the published tree. Done. The tree now has only a master branch and the vX.Y-dts tags (it is still pushing the historical ones, they'll be there soon). .git of a fresh clone is now 22M, which is more like it ;-) I've moved the tree with all the conversion state aside into device-tree-conversion.git. Most people won't need what is in there. Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: devicetree repository separation/migration
On Tue, 2014-02-25 at 08:26 +0100, Sascha Hauer wrote: > On Mon, Feb 24, 2014 at 03:59:17PM +0000, Ian Campbell wrote: > > On Fri, 2014-02-21 at 15:11 +0100, Sascha Hauer wrote: > > > Ians dts repository is a good start, but it contains a complete kernel > > > history and this is not very suitable as a submodule for other > > > projects. > > > > It only contains the full history for the files which it contains, not a > > complete kernel history. This is deliberate so that "git annotate" etc > > still works to tell you where a particular line came from. > > I have cloned git://xenbits.xen.org/people/ianc/device-tree-rebasing.git. > .git is 843MB in size and after a 'git checkout v3.13' I see a vanilla v3.13 > checked out. I may have done something wrong, but I don't see what it > could be. There is a branch with the full Linux stuff in there too. It is needed in the tree doing the conversion but doesn't really need to be published. I pushed it in the early days without really thinking about the size impact. I'll remove that stuff from the published tree. The master branch, which you should have got by default, contains the converted stuff and the tags have -dts appended (e.g. checkout v3.13-dts). Checkout one of those and you should see the expected thing. Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Movement of testcases.dtsi
On Mon, 2014-02-24 at 19:48 +, Grant Likely wrote: > On Mon, 24 Feb 2014 10:25:42 +0000, Ian Campbell wrote: > > My device-tree-rebasing.git repo no longer builds, it fails with: > > src/arm/versatile-pb.dts:50:26: fatal error: testcases.dtsi: No such file > > or directory > > > > I suspect this is due to b5190516b282 "of: Move testcase FDT data into > > drivers/of". I think I need to add drivers/of/testcase-data to the list > > of paths to convert, probably extracting it to /testcase-data in the dt > > repo and teach the build system about the new path in the obvious way. > > > > Does that make sense? > > Yup, that's the right thing to do... Thanks, I'll look into it. > although I would like it to be a > short term solution. Ultimately I want the testcase data to be loaded at > runtime by the selftest module. I suppose at this point linux.git will have a git rm done and my conversion script will just import that as expected? Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: devicetree repository separation/migration
On Fri, 2014-02-21 at 15:11 +0100, Sascha Hauer wrote: > Ians dts repository is a good start, but it contains a complete kernel > history and this is not very suitable as a submodule for other > projects. It only contains the full history for the files which it contains, not a complete kernel history. This is deliberate so that "git annotate" etc still works to tell you where a particular line came from. The are a lot of merge NULL-commits which aren't strictly needed (they have no content and only a single parent) but I didn't manage to get git rewrite-branch to omit them. They are mostly harmless I think. I'm not sure how any of that makes it unsuitable for use as a submodule though, the history contained in a git tree seems pretty orthogonal to that to me. TBH, I'm not sure what the requirements for a submodule are -- IME when something is used as a submodule it is up to the outer git tree to call into the inner build system in the correct way, whatever that may be. Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Movement of testcases.dtsi
My device-tree-rebasing.git repo no longer builds, it fails with: src/arm/versatile-pb.dts:50:26: fatal error: testcases.dtsi: No such file or directory I suspect this is due to b5190516b282 "of: Move testcase FDT data into drivers/of". I think I need to add drivers/of/testcase-data to the list of paths to convert, probably extracting it to /testcase-data in the dt repo and teach the build system about the new path in the obvious way. Does that make sense? Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] arm/xen: Don't use xen DMA ops when the device is protected by an IOMMU
Adding the -spec list for the generic IOMMU binding question. On Thu, 2014-02-20 at 16:21 +, Julien Grall wrote: > diff --git a/Documentation/devicetree/bindings/arm/xen.txt > b/Documentation/devicetree/bindings/arm/xen.txt > index 0f7b9c2..ee25a57 100644 > --- a/Documentation/devicetree/bindings/arm/xen.txt > +++ b/Documentation/devicetree/bindings/arm/xen.txt > @@ -15,6 +15,8 @@ the following properties: > - interrupts: the interrupt used by Xen to inject event notifications. >A GIC node is also required. > > +- protected-devices: (optional) List of phandles to device node where the > +IOMMU has been programmed by Xen. Is there some common/generic IOMMU binding which we can reuse here? Although this isn't exactly an IOMMU it certainly has some similarities -- it is providing IOMMU like functionality (albeit a very inflexible IOMMU which you don't need to/can't actually program). I'd far rather we followed existing patterns rather than invent our own things. I'm wondering if perhaps we didn't ought to integrate this as an actual IOMMU driver, although I'm not convinced this would make sense. I'm also not sure about shovelling everything as properties under a single Xen node, should this not be its own node with compatible = "xen,(pv)iommu"? Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] arm/xen: Don't use xen DMA ops when the device is protected by an IOMMU
On Thu, 2014-02-20 at 16:21 +, Julien Grall wrote: > Only Xen is able to know if a device can safely avoid to use xen-swiotlb. > This patch introduce a new property "protected-devices" for the hypervisor > node which list device which the IOMMU are been correctly programmed by Xen. > > During Linux boot, Xen specific code will create an hash table which > contains all these devices. The hash table will be used in need_xen_dma_ops > to check if the Xen DMA ops needs to be used for the current device. Is it out of the question to find a field within struct device itself to store this e.g. in struct device_dma_parameters perhaps and avoid the need for a hashtable lookup. device->iommu_group might be another option, if we can create our own group? Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: devicetree repository separation/migration
On Wed, 2014-02-19 at 13:23 -0700, Warner Losh wrote: > On Feb 19, 2014, at 11:32 AM, Jason Cooper wrote: > > > On Tue, Feb 18, 2014 at 11:47:56AM -0800, Olof Johansson wrote: > >> On Tue, Feb 18, 2014 at 10:18 AM, Jason Cooper > >> wrote: > >> I think we have two options: > >> > >> 1. Bring out everything in the current kernel repo to a separate one, > >> but do it my mirroring over. Changes go into the kernel repo first and > >> then comes over to this one, but other projects can mirror the > >> standalone repo without downloading a whole kernel tree. > > > > I prefer this one. Assuming that a separate repo is mostly agreed upon, > > this allows us to provide the tree in an easily digestible way without > > impacting the current workflow. > > > > Also, if it works for the other projects, no one says we have to move > > beyond this step. > > I just joined this list... What's the scope of what would move into the new > repo? The dts files with the binding docs, or also the code to implement > those bindings? Just the dts(i) and Bindings docs, not the code. e.g. something like http://xenbits.xen.org/gitweb/?p=people/ianc/device-tree-rebasing.git would be the ultimate goal. Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: devicetree repository separation/migration
On Wed, 2014-02-19 at 12:18 -0800, Frank Rowand wrote: > I am predicting increased pain for little gain if the dts files move out > of the linux kernel repository. That's only the case if you take a very Linux centric point of view and as others have pointed out there are numerous other projects which would like to both consume and contribute to the set of DTS files, forcing all those people to take part in Linux development in order to do so is a barrier which has been shown to be too high in many cases, which is already leading to fragmentation. If DTB is to be taken seriously as a generic standard for describing hardware then IMHO it cannot afford to remain so closely tied to a single consumer. Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: devicetree repository separation/migration
On Wed, 2014-02-19 at 13:20 -0800, Olof Johansson wrote: > On Wed, Feb 19, 2014 at 1:12 PM, Rob Herring wrote: > > One way to minimize the inconvenience is keep versioning and dev > > cycles in sync with the kernel. We could also start doing things to > > align the kernel workflow with how things will work when we do have a > > separate repository. > > I don't think aligning development cycles is what we want most here it > might be useful for us in Linux but it'll make things difficult for > other projects since they're not aware of our release cycles. The > device tree bindings and DT contents in that repo should be "always > stable", i.e. no merge window / rc concept. As soon as something goes > in it's live, and from then out only fixes to the DTS files (or > appending the binding). I agree, but I also think it would be useful to draw the occasional line in the sand and do e.g. monthly or quarterly tagged releases e.g. for distros who want a tarball package to work off. There's no reason for that to be tied to any other projects dev cycle though. Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: devicetree repository separation/migration
On Thu, 2014-02-20 at 08:14 +, Grant Likely wrote: > >> The other argument is shared source between > >> BSD/U-Boot/Barebox/Linux/etc. Until we have a separate .dts repo there ^/Xen ;-) > >> is no good way to share the database of hardware descriptions. > > > > We could provide an easy export (see below). What do you think? > > Ian Campbell is already maintaining an export tree as a staging area > for an eventual split. He's had it up and running for almost a year > now: > > http://xenbits.xen.org/gitweb/?p=people/ianc/device-tree-rebasing.git NB, per the name it is potentially rebasing, effectively until if/when it becomes the primary. In practice it hasn't been rebased since the early days while I was sorting out the translations. I've got an open action to move it somewhere other than xenbits, probably git.kernel.org unless someone can supply a more neutral place. WRT people wanting a more staged transition rather than a flag day: I think I could tweaking things to rewrite each arch onto its own branch, which could all be merged up into a single master branch. Then as $ARCH moves over to using device.tree.git rather than linux.git as their primary location for DTS we can simply drop the conversion for that branch and start accepting patches onto master. I think doing anything more fine-grained than per-arch would be tricky, at least to do automagically. Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] ARM: Kirkwood: Add support for many Synology NAS devices
On Thu, 2014-02-06 at 17:01 +0100, Andrew Lunn wrote: > Synology seem to build there devices like lego. They have two > different RTC blocks. They have three different fan alarm blocks, four > different led blocks, etc. And to build a product, the just select a > group of blocks and put them together. > > The board setup code which Ben Peddell wrote has a somewhat similar > structure: > > http://klightspeed.killerwolves.net/synology/linux-3.4-synology-0.1.patch > > It has a set of functions which add platform devices. And a table > driven piece of code which based on the product name calls these > functions to add the needed platform devices. Take a look at the table > to get a better idea of the re-use factor of the blocks. > > In this DT version, i have a dtsi file for each function, and a dti > file for each table entry. At least some other platforms deal with this by having a baseline dtsi where most things have status="disabled" and then a per-board .dts file which contains status="okay" and perhaps any specific pin bindings etc. See arch/arm/boot/dts/sun?i* for an example of this approach. Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Devicetree Maintenance in barebox
On Fri, 2014-02-07 at 09:10 -0500, Jason Cooper wrote: > Hi Sascha, > > + Grant Likely, Ian Campbell, devicetree ML > > This discussion started on the barebox bootloader mailinglist > > On Fri, Feb 07, 2014 at 08:13:32AM +0100, Sascha Hauer wrote: > > It's becoming more obvious that devicetree maintenance is painful > > because we have to sync them to the kernel regularly. My hope was that > > this would get simpler once the devicetrees get their own repository > > outside the kernel, but it seems that won't happen anytime soon. > > hmm. Ian Campbell has a tree he is working on: > > git://xenbits.xen.org/people/ianc/device-tree-rebasing.git This is automatically extracted out of the linux git tree (using git-filter-branch), maintaining all the history etc. I intend to keep this running until such a time as the DTS files are migrated out of Linux. For the time being though patches to this tree need to go through the Linux tree in the normal way. (also, as the name states it is potentially rebasing, although there hasn't been an actual need since the early days when I was still getting things working) Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Devicetree Maintenance in barebox
On Sun, 2014-02-09 at 11:58 -0600, Jon Loeliger wrote: > > Hi Sascha, > > > > + Grant Likely, Ian Campbell, devicetree ML > > > > Also, In the DT meeting earlier this week, Grant Likely said he has the > > request in to create a separate mailinglist for collaboration between > > the different devicetree users (BSD, Linux, etc). > > ... > > > I think the proper solution will percolate out of the first > > cross-project discussions on the new ML. > > ... > > > Definitely fodder for the new ML. > > > > Grant, can you please add Sascha to the list of folks to notify when > > the new ML is ready? > > I don't think there needs to be a different mailing list > in order to combine or discuss other OS's use of the device > tree compiler. The DTC is OS and Use-agnostic. Discussions > of DTC needs for FreeBSD can happen right here as the orginal > purpose of this list was DTC discussion. > > Are you, and Grant(?), suggesting that a separate list > should be created for FreeBSD use of DTS-file contents? > Or that DTS-file-content related discussions should be > separated from DTC discussions? The latter. See http://www.spinics.net/lists/devicetree/msg19209.html . The issue is the enormous volume of Linux specific stuff which is too much of a firehose to sensibly suggest non-Linux people to subscribe too. > > > imho, the goal is to not have any project tied to a specific version > > of the devicetree. > > > > iow, we don't break backwards compatibility in the > > devicetrees, and projects should revert to default behavior if new dt > > parameters are missing. This means Linux and BSD shouldn't need to keep > > a current copy of the devicetree in their trees. However, building the > > bootloader is a different animal. It needs to provide the dt blob... > > The devicetree source file format hasn't changed in years. > Yes, it is enhanced, but compatibly. Or do you mean the > contents of the DTB for some specific platform? > > Thanks, > jdl > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] ARM: Kirkwood: Add support for many Synology NAS devices
On Thu, 2014-02-06 at 10:39 -0500, Jason Cooper wrote:
>
> > + pmx_fan_33: pmx-fan-33 {
> > + marvell,pins = "mpp33";
> > + marvell,function = "gpo";
> > + };
Typo I think.
Ian.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] ARM: Kirkwood: Add support for many Synology NAS devices
On Thu, 2014-02-06 at 17:50 +0100, Andrew Lunn wrote:
> On Thu, Feb 06, 2014 at 04:39:25PM +0000, Ian Campbell wrote:
> > On Thu, 2014-02-06 at 10:39 -0500, Jason Cooper wrote:
> > >
> > > > + pmx_fan_33: pmx-fan-33 {
> > > > + marvell,pins = "mpp33";
> > > > + marvell,function = "gpo";
> > > > + };
> >
> > Typo I think.
>
> Hi Ian
>
> drivers/pinctrl/mvebu/pinctrl-kirkwood.c:
>
> MPP_MODE(33,
> MPP_VAR_FUNCTION(0x0, "gpo", NULL, V(0, 1, 1, 1, 1, 0)),
> MPP_VAR_FUNCTION(0x2, "tdm", "dtx", V(0, 0, 1, 1, 1, 0)),
> MPP_VAR_FUNCTION(0x3, "ge1", "txctl",V(0, 1, 1, 1, 1, 0)),
> MPP_VAR_FUNCTION(0xb, "lcd", "d13", V(0, 0, 0, 0, 1,
> 0))),
> MPP_MODE(34,
>
> It is output only.
Oops, Sorry for the noise!
>
> I actually had the opposite bug in v1, setup two gpo's as gpio's.
>
> Andrew
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: document "mach-virt" platform.
On Sun, 2014-02-02 at 20:56 -0800, Christoffer Dall wrote: > On Thu, Jan 30, 2014 at 11:54:46AM -0500, Christopher Covington wrote: > > Hi Ian, > > > > On 01/30/2014 11:11 AM, Ian Campbell wrote: > > > mach-virt has existed for a while but it is not written down what it > > > actually > > > consists of. Although it seems a bit unusual to document a binding for an > > > entire platform since mach-virt is entirely virtual it is helpful to have > > > something to refer to in the absence of a single concrete implementation. > > > > > > I've done my best to capture the requirements based on the git log and my > > > memory/understanding. > > > > > > While here remove the xenvm dts example, the Xen tools will now build a > > > suitable mach-virt compatible dts when launching the guest. > > > > [...] > > > > +The platform may also provide hypervisor specific functionality > > > +(e.g. PV I/O), if it does so then this functionality must be > > > +discoverable (directly or indirectly) via device tree. > > > > I think it would be informative to provide pointers here to commonly used > > paravirtualized devices, especially VirtIO PCI/MMIO. > > > > I disagree: that would only encourage limited testing or assumptions > about these specific devices when really this platform is just a > bare-bones platform driven by device tree which should make no > preference, whatsoever, about which devices are used with the platform. Thanks, I think this is exactly what I was failing to express coherently last week ;-) Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: document "mach-virt" platform.
On Thu, 2014-01-30 at 18:28 +0100, Arnd Bergmann wrote: > On Thursday 30 January 2014, Ian Campbell wrote: > > mach-virt has existed for a while but it is not written down what it > > actually > > consists of. Although it seems a bit unusual to document a binding for an > > entire platform since mach-virt is entirely virtual it is helpful to have > > something to refer to in the absence of a single concrete implementation. > > > > I've done my best to capture the requirements based on the git log and my > > memory/understanding. > > > > While here remove the xenvm dts example, the Xen tools will now build a > > suitable mach-virt compatible dts when launching the guest. > > It might be worth noting in the changeset comment that the 'compatible' > string is actually no longer needed on newer kernels: All the members > of the machine descriptor are now the defaults (we should remove the > virt_init() function as well), and the fallback machine descriptor should > work just fine if any other string gets passed. So Marc's plan has actually happened. Neat. In that case is there even any point in listing explicit compatiblity strings (except perhaps as a historical note) -- I can just say that this is the fallback/default machine? I'll leave the virt_init change to a separate patch if that's ok. Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: document "mach-virt" platform.
On Thu, 2014-01-30 at 17:24 +, Marc Zyngier wrote: > >> I'm afraid I disagree with most of the above. The whole point of > >> mach-virt is to provide a shell for DT platforms. None of this hardware > >> is mandated. Instead, all the necessary information should be described > >> in DT. > > > > "Add support for the smallest, dumbest possible platform, to be > > used as a guest for KVM or other hypervisors. > > > > It only mandates a GIC and architected timers" > > > > (your original commit message :-P) > > Right. 1984, here we come. I'll disappear for a while, rewriting the > history. More seriously, that was just me scheming to get it merged, > hiding my cunning plan for mach-virt world domination! :-) > >> Actually, mach-virt doesn't really stand for Virtual Machine. It stands > >> for virtual mach-* directory! Eventually, mach-virt should become the > >> default platform, the one we use when we don't match anything else in > >> the kernel > > > > I can word it more like that for sure, along with the alternative > > wording suggested by Christopher/Stefano to clarify the intent that > > everything comes from DTB and removal of the specific requirements for > > GIC/timer/PSCI I think that suit the (new) intention better? > > Yes, please! :-) OK, I'll come up with an updated version. Cheers, Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: document "mach-virt" platform.
On Thu, 2014-01-30 at 17:13 +, Marc Zyngier wrote: > Hi Ian, > > On 30/01/14 16:11, Ian Campbell wrote: > > mach-virt has existed for a while but it is not written down what it > > actually > > consists of. Although it seems a bit unusual to document a binding for an > > entire platform since mach-virt is entirely virtual it is helpful to have > > something to refer to in the absence of a single concrete implementation. > > > > I've done my best to capture the requirements based on the git log and my > > memory/understanding. > > > > While here remove the xenvm dts example, the Xen tools will now build a > > suitable mach-virt compatible dts when launching the guest. > > > > Signed-off-by: Ian Campbell > > Cc: Rob Herring > > Cc: Pawel Moll > > Cc: Mark Rutland > > Cc: Kumar Gala > > Cc: Olof Johansson > > Cc: Arnd Bergmann > > Cc: Marc Zyngier > > Cc: Will Deacon > > Cc: Stefano Stabellini > > Cc: devicetree@vger.kernel.org > > Cc: linux-ker...@vger.kernel.org > > Cc: linux-arm-ker...@lists.infradead.org > > --- > > I'm not sure which tree this sort of thing should go though, sorry for the > > huge Cc. > > --- > > .../devicetree/bindings/arm/mach-virt.txt | 32 > > arch/arm/boot/dts/xenvm-4.2.dts| 81 > > > > 2 files changed, 32 insertions(+), 81 deletions(-) > > create mode 100644 Documentation/devicetree/bindings/arm/mach-virt.txt > > delete mode 100644 arch/arm/boot/dts/xenvm-4.2.dts > > > > diff --git a/Documentation/devicetree/bindings/arm/mach-virt.txt > > b/Documentation/devicetree/bindings/arm/mach-virt.txt > > new file mode 100644 > > index 000..562bcda > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/arm/mach-virt.txt > > @@ -0,0 +1,32 @@ > > +* Mach-virt "Dummy Virtual Machine" platform > > + > > +"mach-virt" is the smallest, dumbest platform possible, to be used as > > +a guest for Xen, KVM and other hypervisors. It has no > > +properties/functionality of its own and is driven entirely by device > > +tree. > > + > > +This document defines the requirements for such a platform. > > + > > +* Required properties: > > + > > +- compatible: should be one of: > > + "linux,dummy-virt" > > + "xen,xenvm" > > + > > +In addition to the standard nodes (chosen, cpus, memory etc) the > > +platform is required to provide certain other basic functionality > > +which must be described in the device tree: > > + > > +The platform must provide an ARM Generic Interrupt Controller > > +(GIC), defined in Documentation/devicetree/bindings/arm/gic.txt. > > + > > +The platform must provide ARM architected timer, defined in > > +Documentation/devicetree/bindings/arm/arch_timer.txt. > > + > > +If the platform is SMP then it must provide the Power State > > +Coordination Interface (PSCI) described in > > +Documentation/devicetree/bindings/arm/psci.txt. > > I'm afraid I disagree with most of the above. The whole point of > mach-virt is to provide a shell for DT platforms. None of this hardware > is mandated. Instead, all the necessary information should be described > in DT. "Add support for the smallest, dumbest possible platform, to be used as a guest for KVM or other hypervisors. It only mandates a GIC and architected timers" (your original commit message :-P) > Actually, mach-virt doesn't really stand for Virtual Machine. It stands > for virtual mach-* directory! Eventually, mach-virt should become the > default platform, the one we use when we don't match anything else in > the kernel I can word it more like that for sure, along with the alternative wording suggested by Christopher/Stefano to clarify the intent that everything comes from DTB and removal of the specific requirements for GIC/timer/PSCI I think that suit the (new) intention better? > What you've described here are requirements for a hypervisor like Xen or > KVM. mach-virt itself shouldn't have any of that. > > Cheers, > > M. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: document "mach-virt" platform.
On Thu, 2014-01-30 at 11:54 -0500, Christopher Covington wrote: > > +++ b/Documentation/devicetree/bindings/arm/mach-virt.txt > > @@ -0,0 +1,32 @@ > > +* Mach-virt "Dummy Virtual Machine" platform > > + > > +"mach-virt" is the smallest, dumbest platform possible, to be used as > > +a guest for Xen, KVM and other hypervisors. > > The platform is also useful to, and used by, simulators like QEMU in TCG mode. I can mention this, although I don't think the list needs to be exhaustive. It has no > > +properties/functionality of its own and is driven entirely by device > > +tree. > > I find this wording confusing. I read it as saying the platform has no > properties or functionality. Perhaps you could phrase it slightly differently, > such as having no properties or functionality beyond what's described in the > device tree. Yes, this is what I was trying to say, I'll update with something along those lines. > > +The platform may also provide hypervisor specific functionality > > +(e.g. PV I/O), if it does so then this functionality must be > > +discoverable (directly or indirectly) via device tree. > > I think it would be informative to provide pointers here to commonly used > paravirtualized devices, especially VirtIO PCI/MMIO. Under what criteria would something be eligible/appropriate to be listed? I was trying to avoid "advocating" any particular type of PV devices. We already have something of a problem with people incorrectly assuming that mach-virt == virtio, which is not the case. If we did want to include an explicit list here at a minimum I would also want to include the Xen PV devices as well and surely there would be others which ought to be included too. Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: document "mach-virt" platform.
mach-virt has existed for a while but it is not written down what it actually
consists of. Although it seems a bit unusual to document a binding for an
entire platform since mach-virt is entirely virtual it is helpful to have
something to refer to in the absence of a single concrete implementation.
I've done my best to capture the requirements based on the git log and my
memory/understanding.
While here remove the xenvm dts example, the Xen tools will now build a
suitable mach-virt compatible dts when launching the guest.
Signed-off-by: Ian Campbell
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Kumar Gala
Cc: Olof Johansson
Cc: Arnd Bergmann
Cc: Marc Zyngier
Cc: Will Deacon
Cc: Stefano Stabellini
Cc: devicetree@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
I'm not sure which tree this sort of thing should go though, sorry for the
huge Cc.
---
.../devicetree/bindings/arm/mach-virt.txt | 32
arch/arm/boot/dts/xenvm-4.2.dts| 81
2 files changed, 32 insertions(+), 81 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/mach-virt.txt
delete mode 100644 arch/arm/boot/dts/xenvm-4.2.dts
diff --git a/Documentation/devicetree/bindings/arm/mach-virt.txt
b/Documentation/devicetree/bindings/arm/mach-virt.txt
new file mode 100644
index 000..562bcda
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mach-virt.txt
@@ -0,0 +1,32 @@
+* Mach-virt "Dummy Virtual Machine" platform
+
+"mach-virt" is the smallest, dumbest platform possible, to be used as
+a guest for Xen, KVM and other hypervisors. It has no
+properties/functionality of its own and is driven entirely by device
+tree.
+
+This document defines the requirements for such a platform.
+
+* Required properties:
+
+- compatible: should be one of:
+ "linux,dummy-virt"
+ "xen,xenvm"
+
+In addition to the standard nodes (chosen, cpus, memory etc) the
+platform is required to provide certain other basic functionality
+which must be described in the device tree:
+
+The platform must provide an ARM Generic Interrupt Controller
+(GIC), defined in Documentation/devicetree/bindings/arm/gic.txt.
+
+The platform must provide ARM architected timer, defined in
+Documentation/devicetree/bindings/arm/arch_timer.txt.
+
+If the platform is SMP then it must provide the Power State
+Coordination Interface (PSCI) described in
+Documentation/devicetree/bindings/arm/psci.txt.
+
+The platform may also provide hypervisor specific functionality
+(e.g. PV I/O), if it does so then this functionality must be
+discoverable (directly or indirectly) via device tree.
diff --git a/arch/arm/boot/dts/xenvm-4.2.dts b/arch/arm/boot/dts/xenvm-4.2.dts
deleted file mode 100644
index 3369151..000
--- a/arch/arm/boot/dts/xenvm-4.2.dts
+++ /dev/null
@@ -1,81 +0,0 @@
-/*
- * Xen Virtual Machine for unprivileged guests
- *
- * Based on ARM Ltd. Versatile Express CoreTile Express (single CPU)
- * Cortex-A15 MPCore (V2P-CA15)
- *
- */
-
-/dts-v1/;
-
-/ {
- model = "XENVM-4.2";
- compatible = "xen,xenvm-4.2", "xen,xenvm";
- interrupt-parent = <&gic>;
- #address-cells = <2>;
- #size-cells = <2>;
-
- chosen {
- /* this field is going to be adjusted by the hypervisor */
- bootargs = "console=hvc0 root=/dev/xvda";
- };
-
- cpus {
- #address-cells = <1>;
- #size-cells = <0>;
-
- cpu@0 {
- device_type = "cpu";
- compatible = "arm,cortex-a15";
- reg = <0>;
- };
-
- cpu@1 {
- device_type = "cpu";
- compatible = "arm,cortex-a15";
- reg = <1>;
- };
- };
-
- psci {
- compatible = "arm,psci";
- method = "hvc";
- cpu_off = <1>;
- cpu_on = <2>;
- };
-
- memory@8000 {
- device_type = "memory";
- /* this field is going to be adjusted by the hypervisor */
- reg = <0 0x8000 0 0x0800>;
- };
-
- gic: interrupt-controller@2c001000 {
- compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
- #interrupt-cells = <3>;
- #address-cells = <0>;
- interrupt-controller;
- reg = <0 0x2c001000 0 0x1000>,
- <0 0x2c002000 0 0x100>;
- };
-
- timer {
- compatible = "arm,armv7-timer";
-
[PATCH REPOST] of: Add vendor prefix for Xen hypervisor
I suppose vendors of virtual hardware ought to be listed here as well. Signed-off-by: Ian Campbell Acked-by: Stefano Stabellini Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Kumar Gala Cc: Stephen Warren Acked-by: Stephen Warren Cc: devicetree@vger.kernel.org --- v2: rebased for repost. --- Documentation/devicetree/bindings/vendor-prefixes.txt |1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 3f900cd..a30e3b7 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -90,4 +90,5 @@ via VIA Technologies, Inc. winbond Winbond Electronics corp. wlfWolfson Microelectronics wm Wondermedia Technologies, Inc. +xenXen Hypervisor xlnx Xilinx -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Culling traffic volume on devicetree mailing list
On Wed, 2014-01-22 at 10:35 -0800, Olof Johansson wrote: > > devicetree-spec: For discussing 'core' device tree bindings. ie. > > anything that would be a candidate for putting into an ePAPR type > > spec. Individual device bindings would continue to be posted to > > devicetree@vger.kernel.org, but anything affecting subsystems or > > generic patterns should be posted to this new list. > > I predict that it will be hard for someone posting a patch to tell if > they should send it to this list or some other list. It might be > convenient for you guys to ignore the high-volume list and just focus > on this one, but for the people who post patches it just makes it more > complicated. IMHO. The issue with the current list is that it is too much of a firehose of Linux patches for other non-Linux consumers of DTB e.g. BSD folks, me with my Xen hat, see [0] for the intersection of those two which prompted me to mention this on the call. The firehose means that these people don't subscribe and therefore lack visibility into what is going on with the core bindings (e.g. BSD seems to have a different binding for gic interrupts, mentioned in the linked thread). I don't think the intention of the split was/should be that "core" Linux/DTB people should only subscribe to -spec@, rather that it be a more targeted list which non-Linux/DTB folks can be involved with to discuss core binding issues and standardisation etc. It seems like devicetree@ would be the right default destination for any patch and so should be what is listed in MAINTAINERS etc. Anyone who is doing actual core/spec work appropriate to -spec@ is either going to be involved enough to know this themselves or can be asked to CC the other list too as part of the first round of review. The number of patches which would need to go to -spec should be a pretty small fraction. Ian. [0] http://thread.gmane.org/gmane.os.freebsd.xen/1976 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-sunxi] Re: [PATCH 1/5] ARM: sunxi: Add driver for SD/MMC hosts found on Allwinner sunxi SoCs
On Mon, 2013-12-16 at 12:59 +0100, Michal Suchanek wrote: > On 16 December 2013 11:05, Maxime Ripard > wrote: > > On Sun, Dec 15, 2013 at 11:01:17PM +0100, Michal Suchanek wrote: > >> On 15 December 2013 14:44, Maxime Ripard > >> wrote: > >> >> --- a/drivers/mmc/host/Kconfig > >> >> +++ b/drivers/mmc/host/Kconfig > >> >> @@ -665,3 +665,11 @@ config MMC_REALTEK_PCI > >> >> help > >> >> Say Y here to include driver code to support SD/MMC card > >> >> interface > >> >> of Realtek PCI-E card reader > >> >> + > >> >> +config MMC_SUNXI > >> >> + tristate "Allwinner sunxi SD/MMC Host Controller support" > >> >> + depends on ARCH_SUNXI > >> >> + default y > >> > > >> > I'm not that fond of these "default y" patterns. It forces the driver > >> > down to every user of the multiplatform kernels. I'd suggest removing > >> > the default and adding the driver to the defconfigs we have. > >> > >> And why would you build support for sunxi without building support for > >> sunxi mmc? > > > > Because you can? > > But does that need to be the default? And is that sane default? > > > > > And where am I actually suggesting to do so? > > Just a few lines above. You suggest it should not be built by default. I'm pretty sure this isn't specific to sunxi, in the past Linus has complained about the inappropriate use of "default y". Apparently it should only be used rarely. Note that default in the Kconfig is different to the defconfig file. Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Device Tree Maturity Project
On Wed, 2013-11-27 at 14:36 +, Grant Likely wrote: > On Fri, 22 Nov 2013 11:22:23 +, Mark Rutland wrote: > > On Wed, Nov 20, 2013 at 11:56:39AM +, Grant Likely wrote: > > > On Wed, Nov 20, 2013 at 11:55 AM, Grant Likely > > > wrote: > > > > To help keep track of what is going on, I would like to have a short > > > > stand up meeting once a week. Looking at my calendar, I can make > > > > 14:00UTC on Tuesday, Wednesday or Friday work (9:00EST, 7:00PST). I > > > > > > Correction: Tuesday, Thursday or Friday. Wednesday I'm booked. > > > > Apologies for begin a little late to the party... > > > > I have a regular fortnightly meeting on Thursdays, and for the next few > > weeks (until the new year) I'm otherwise engaged on Fridays, so Tuesdays > > would be preferable for me. > > I started with Fridays, but it sounds like Tuesday works for everyone. > I've moved the meeting to next Tuesday. Should I have gotten an update meeting request? > This Friday would have been off > anyway because of some minor holiday in the US. :-) Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] powerpc/dts/virtex440: declare address/size-cells for phy device
This fixes a warning:
DTC arch/powerpc/boot/virtex440-ml507.dtb
Warning (reg_format): "reg" property in
/plb@0/xps-ll-temac@81c0/ethernet@81c0/phy@7 has invalid length (4
bytes) (#address-cells == 2, #size-cells == 1)
Warning (avoid_default_addr_size): Relying on default #address-cells value for
/plb@0/xps-ll-temac@81c0/ethernet@81c0/phy@7
Warning (avoid_default_addr_size): Relying on default #size-cells value for
/plb@0/xps-ll-temac@81c0/ethernet@81c0/phy@7
Signed-off-by: Ian Campbell
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Gernot Vormayr
Cc: devicetree@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
No reply since June. http://patchwork.ozlabs.org/patch/248235/
---
arch/powerpc/boot/dts/virtex440-ml507.dts |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/boot/dts/virtex440-ml507.dts
b/arch/powerpc/boot/dts/virtex440-ml507.dts
index fc7073b..391a4e2 100644
--- a/arch/powerpc/boot/dts/virtex440-ml507.dts
+++ b/arch/powerpc/boot/dts/virtex440-ml507.dts
@@ -257,6 +257,8 @@
#size-cells = <1>;
compatible = "xlnx,compound";
ethernet@81c0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
compatible = "xlnx,xps-ll-temac-1.01.b";
device_type = "network";
interrupt-parent = <&xps_intc_0>;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] powerpc/4xx: Fix warning in kilauea.dtb
Currently I see:
DTC arch/powerpc/boot/kilauea.dtb
Warning (reg_format): "reg" property in /plb/ppc4xx-msi@C1000 has invalid
length (12 bytes) (#address-cells == 1, #size-cells == 1)
It appears that unlike the other platforms handled by 3fb7933850fa
"powerpc/4xx: Adding PCIe MSI support" this platform does not use
address-cells=2.
Signed-off-by: Ian Campbell
Acked-by: Josh Boyer
Cc: Rupjyoti Sarmah
Cc: Tirumala R Marri
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: devicetree@vger.kernel.org (open list:OPEN FIRMWARE AND...)
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
Resending, this hasn't been picked up since June
http://patchwork.ozlabs.org/patch/248234/
---
arch/powerpc/boot/dts/kilauea.dts |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/boot/dts/kilauea.dts
b/arch/powerpc/boot/dts/kilauea.dts
index 1613d6e..5ba7f01 100644
--- a/arch/powerpc/boot/dts/kilauea.dts
+++ b/arch/powerpc/boot/dts/kilauea.dts
@@ -406,7 +406,7 @@
MSI: ppc4xx-msi@C1000 {
compatible = "amcc,ppc4xx-msi", "ppc4xx-msi";
- reg = < 0x0 0xEF62 0x100>;
+ reg = <0xEF62 0x100>;
sdr-base = <0x4B0>;
msi-data = <0x>;
msi-mask = <0x>;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Device Tree Maturity Project
On Wed, 2013-11-20 at 07:06 -0600, Rob Herring wrote: > On 11/20/2013 05:56 AM, Grant Likely wrote: > > On Wed, Nov 20, 2013 at 11:55 AM, Grant Likely > > wrote: > >> To help keep track of what is going on, I would like to have a short > >> stand up meeting once a week. Looking at my calendar, I can make > >> 14:00UTC on Tuesday, Wednesday or Friday work (9:00EST, 7:00PST). I > > > > Correction: Tuesday, Thursday or Friday. Wednesday I'm booked. > > That's 6:00PST. > > Any of those days work for me. Me too. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] arm: Support for platforms with split GIC cpu interface registers.
At least one platform (APM Storm) places the two pages of the GIC cpu interface
(and the vcpu side) at non-contiguous locations. Document two additional
regions to cover this split and update the corresponding dtsi. Note that Linux
(including KVM) does not use any registers in the second page so there is no
associated code change here. Xen will use these new regions, although I've not
written the corresponding code yet.
The ordering of these new regs is slightly counter intuitive but is inteded to
be backward compatible. It is also assumed that all such systems will implement
the GIC virtualisation extensions.
Add comments to all of the reg examples to help clarify what is going on.
Signed-off-by: Ian Campbell
Cc: devicetree@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: Kumar Sankaran
Cc: Loc Ho
Cc: Feng Kan
---
Documentation/devicetree/bindings/arm/gic.txt | 57 +--
arch/arm64/boot/dts/apm-storm.dtsi| 6 ++-
2 files changed, 50 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/gic.txt
b/Documentation/devicetree/bindings/arm/gic.txt
index ea215e8..00836d9 100644
--- a/Documentation/devicetree/bindings/arm/gic.txt
+++ b/Documentation/devicetree/bindings/arm/gic.txt
@@ -38,7 +38,8 @@ Main node required properties:
- reg : Specifies base physical address(s) and size of the GIC registers. The
first region is the GIC distributor register base and size. The 2nd region is
- the GIC cpu interface register base and size.
+ the GIC cpu interface register base and size (See also "Split GIC
+ cpu interface", below).
Optional
- interrupts : Interrupt source of the parent interrupt controller on
@@ -56,8 +57,8 @@ Example:
#interrupt-cells = <3>;
#address-cells = <1>;
interrupt-controller;
- reg = <0xfff11000 0x1000>,
- <0xfff10100 0x100>;
+ reg = <0xfff11000 0x1000>, /* GIC Dist */
+ <0xfff10100 0x100>; /* GIC CPU */
};
@@ -70,9 +71,11 @@ primary interrupt controller).
Required properties:
- reg : Additional regions specifying the base physical address and
- size of the VGIC registers. The first additional region is the GIC
- virtual interface control register base and size. The 2nd additional
- region is the GIC virtual cpu interface register base and size.
+ size of the VGIC registers. The first additional region (i.e. third
+ overall) is the GIC virtual interface control register base and
+ size. The 2nd additional region (i.e. forth overall) is the GIC
+ virtual cpu interface register base and size (See also "Split GIC
+ cpu interface", below).
- interrupts : VGIC maintenance interrupt.
@@ -82,9 +85,41 @@ Example:
compatible = "arm,cortex-a15-gic";
#interrupt-cells = <3>;
interrupt-controller;
- reg = <0x2c001000 0x1000>,
- <0x2c002000 0x2000>,
- <0x2c004000 0x2000>,
- <0x2c006000 0x2000>;
- interrupts = <1 9 0xf04>;
+ reg = <0x2c001000 0x1000>, /* GIC Dist */
+ <0x2c002000 0x2000>, /* GIC CPU */
+ <0x2c004000 0x2000>, /* GIC VCPU Control */
+ <0x2c006000 0x2000>; /* GIC VCPU1 */
+ interrupts = <1 9 0xf04>; /* GIC Maintenence IRQ */
+ };
+
+* Split GIC cpu interface
+
+ The cpu interfaces (bare-metal in region 2 and virtual in region 4)
+ may be spread over two pages, with the GICC_DIR (Deactivate
+ Interrupt Register) register falling at the start of the second
+ page. If these pages are contiguous then this is described via the
+ size of the second and fourth entries as described above
+ (e.g. 0x2000 rather than 0x1000).
+
+ However if the two pages are not contiguous then two additional
+ regions are present (5th and 6th) describing the location of the the
+ second half of the GIC cpu interface and GIC virtual cpu interface
+ respectively.
+
+ It is assumed that all such systems will implement the GIC
+ virtualisation extensions.
+
+Example:
+
+ gic: interrupt-controller@7801 {
+ compatible = "arm,cortex-a15-gic";
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ reg = <0x7801 0x1000>, /* GIC Dist */
+ <0x7802 0x1000>, /* GIC CPU1 */
+ <0x7804 0x2000>, /* GIC VCPU Control */
+ <0x7806 0x1000>, /* GIC VCPU1 */
+ <0x7803 0x1000>, /* GIC CPU2 */
+ <0x7807 0x1000>; /* GIC VCPU2 */
+
[PATCH 1/2] arm: correct GIC cpu interface range for Cortex A15/GIC 400
GICv2 (Cortex A15/GIC 400) have CPU interface registers up to offset 0x1004 (the 32-bit GICC_DIR register a 0x1000). The GIC 400 documentation specifies the CPU interface region as being 0x2000 in size. Update all DTS entries claiming "arm,cortex-a15-gic" compatibility. Of these I only have personal experience with the vexpress a Calxeda (ecx) platforms and annecdotal evidence for omap and exynos. For the others I'm just assuming. Also update the example a15 binding in the documentation. The "Texas Instruments Keystone 2 SoC" platform which claim to have an a15 compatible GIC but does not include the GICH/GICV registers. I've not touched that here. Signed-off-by: Ian Campbell Cc: devicetree@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org --- Documentation/devicetree/bindings/arm/gic.txt | 2 +- arch/arm/boot/dts/ecx-2000.dts| 2 +- arch/arm/boot/dts/exynos5.dtsi| 2 +- arch/arm/boot/dts/exynos5440.dtsi | 2 +- arch/arm/boot/dts/omap5.dtsi | 2 +- arch/arm/boot/dts/tegra114.dtsi | 2 +- arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 2 +- arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts| 2 +- arch/arm/boot/dts/xenvm-4.2.dts | 2 +- arch/arm64/boot/dts/foundation-v8.dts | 2 +- arch/arm64/boot/dts/rtsm_ve-aemv8a.dts| 2 +- 11 files changed, 11 insertions(+), 11 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt index 3dfb0c0..ea215e8 100644 --- a/Documentation/devicetree/bindings/arm/gic.txt +++ b/Documentation/devicetree/bindings/arm/gic.txt @@ -83,7 +83,7 @@ Example: #interrupt-cells = <3>; interrupt-controller; reg = <0x2c001000 0x1000>, - <0x2c002000 0x1000>, + <0x2c002000 0x2000>, <0x2c004000 0x2000>, <0x2c006000 0x2000>; interrupts = <1 9 0xf04>; diff --git a/arch/arm/boot/dts/ecx-2000.dts b/arch/arm/boot/dts/ecx-2000.dts index 139b40c..61927de 100644 --- a/arch/arm/boot/dts/ecx-2000.dts +++ b/arch/arm/boot/dts/ecx-2000.dts @@ -93,7 +93,7 @@ interrupt-controller; interrupts = <1 9 0xf04>; reg = <0xfff11000 0x1000>, - <0xfff12000 0x1000>, + <0xfff12000 0x2000>, <0xfff14000 0x2000>, <0xfff16000 0x2000>; }; diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi index f65e124..c72782f 100644 --- a/arch/arm/boot/dts/exynos5.dtsi +++ b/arch/arm/boot/dts/exynos5.dtsi @@ -44,7 +44,7 @@ #interrupt-cells = <3>; interrupt-controller; reg = <0x10481000 0x1000>, - <0x10482000 0x1000>, + <0x10482000 0x2000>, <0x10484000 0x2000>, <0x10486000 0x2000>; interrupts = <1 9 0xf04>; diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi index ff7f5d8..19c9636 100644 --- a/arch/arm/boot/dts/exynos5440.dtsi +++ b/arch/arm/boot/dts/exynos5440.dtsi @@ -31,7 +31,7 @@ #interrupt-cells = <3>; interrupt-controller; reg = <0x2E1000 0x1000>, - <0x2E2000 0x1000>, + <0x2E2000 0x2000>, <0x2E4000 0x2000>, <0x2E6000 0x2000>; interrupts = <1 9 0xf04>; diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index e643620..6c4fe08 100644 --- a/arch/arm/boot/dts/omap5.dtsi +++ b/arch/arm/boot/dts/omap5.dtsi @@ -60,7 +60,7 @@ interrupt-controller; #interrupt-cells = <3>; reg = <0x48211000 0x1000>, - <0x48212000 0x1000>, + <0x48212000 0x2000>, <0x48214000 0x2000>, <0x48216000 0x2000>; }; diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi index abf6c40..eb7a0c4 100644 --- a/arch/arm/boot/dts/tegra114.dtsi +++ b/arch/arm/boot/dts/tegra114.dtsi @@ -20,7 +20,7 @@ #interrupt-cells = <3>; interrupt-controller; reg = <0x50041000 0x1000>, - <0x50042000 0x1000>, + <0x50042000 0x2000>, <0x50044000 0x2000>, <0x50046000 0x2000>; interrupts = ;
[PATCH 0/2] DT: correctly describe GIC400 virtualisation regions
Several existing platforms which sport an A15 compatible GIC to not include the extended GIC cpu interface regisiters in their device tree. Fix these. Also extend the bindings to cope with cpu intefface registers which are not in contiguous pages. Ian. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
