* [PATCH v3 9/9] ARM: dts: stm32f4: Include auxiliary stm32f4 clock definition
From: gabriel.fernandez @ 2016-12-01 15:27 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Russell King, Maxime Coquelin,
Alexandre Torgue, Michael Turquette, Stephen Boyd, Nicolas Pitre,
Arnd Bergmann, daniel.thompson, andrea.merello, radoslaw.pietrzyk
Cc: devicetree, linux-arm-kernel, linux-kernel, linux-clk, kernel,
gabriel.fernandez, ludovic.barre, olivier.bideau, amelie.delaunay
In-Reply-To: <1480606069-5178-1-git-send-email-gabriel.fernandez@st.com>
From: Gabriel Fernandez <gabriel.fernandez@st.com>
This patch include auxiliary clock definition (clocks which are not derived
from system clock.
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
---
arch/arm/boot/dts/stm32f429.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index 7c7dfbd..223dc12 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -48,6 +48,7 @@
#include "skeleton.dtsi"
#include "armv7-m.dtsi"
#include <dt-bindings/pinctrl/stm32f429-pinfunc.h>
+#include <dt-bindings/clock/stm32f4-clock.h>
/ {
clocks {
--
1.9.1
^ permalink raw reply related
* Re: [PATCH/RFC i2c/for-next] i2c: rcar: Add per-Generation fallback bindings
From: Simon Horman @ 2016-12-01 15:32 UTC (permalink / raw)
To: Wolfram Sang
Cc: Magnus Damm, linux-i2c, linux-renesas-soc, Rob Herring,
devicetree
In-Reply-To: <1480605494-32460-1-git-send-email-horms+renesas@verge.net.au>
On Thu, Dec 01, 2016 at 04:18:14PM +0100, Simon Horman wrote:
> In the case of Renesas R-Car hardware we know that there are generations of
> SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the
> relationship between IP blocks might be. For example, I believe that
> r8a7790 is older than r8a7791 but that doesn't imply that the latter is a
> descendant of the former or vice versa.
>
> We can, however, by examining the documentation and behaviour of the
> hardware at run-time observe that the current driver implementation appears
> to be compatible with the IP blocks on SoCs within a given generation.
>
> For the above reasons and convenience when enabling new SoCs a
> per-generation fallback compatibility string scheme being adopted for
> drivers for Renesas SoCs.
>
> Also deprecate renesas,i2c-rcar. It seems poorly named as it is only
> compatible with R-Car Gen 1. It also appears unused in mainline.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Sorry, I seem to have omitted the driver (C code) portion of this change.
I send v2.
^ permalink raw reply
* [PATCH/RFC v2 i2c/for-next] i2c: rcar: Add per-Generation fallback bindings
From: Simon Horman @ 2016-12-01 15:41 UTC (permalink / raw)
To: Wolfram Sang
Cc: Magnus Damm, linux-i2c, linux-renesas-soc, Rob Herring,
devicetree, Simon Horman
In the case of Renesas R-Car hardware we know that there are generations of
SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the
relationship between IP blocks might be. For example, I believe that
r8a7790 is older than r8a7791 but that doesn't imply that the latter is a
descendant of the former or vice versa.
We can, however, by examining the documentation and behaviour of the
hardware at run-time observe that the current driver implementation appears
to be compatible with the IP blocks on SoCs within a given generation.
For the above reasons and convenience when enabling new SoCs a
per-generation fallback compatibility string scheme being adopted for
drivers for Renesas SoCs.
Also deprecate renesas,i2c-rcar. It seems poorly named as it is only
compatible with R-Car Gen 1. It also appears unused in mainline.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
Include accidently omitted i2c-rcar.c portion of patch
---
Documentation/devicetree/bindings/i2c/i2c-rcar.txt | 32 ++++++++++++++--------
drivers/i2c/busses/i2c-rcar.c | 5 +++-
2 files changed, 24 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
index 239632a0d709..8c679b17c4c6 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
@@ -1,17 +1,25 @@
I2C for R-Car platforms
Required properties:
-- compatible: Must be one of
- "renesas,i2c-rcar"
- "renesas,i2c-r8a7778"
- "renesas,i2c-r8a7779"
- "renesas,i2c-r8a7790"
- "renesas,i2c-r8a7791"
- "renesas,i2c-r8a7792"
- "renesas,i2c-r8a7793"
- "renesas,i2c-r8a7794"
- "renesas,i2c-r8a7795"
- "renesas,i2c-r8a7796"
+- compatible:
+ "renesas,i2c-r8a7778" if the device is a part of a R8A7778 SoC.
+ "renesas,i2c-r8a7779" if the device is a part of a R8A7797 SoC.
+ "renesas,i2c-r8a7790" if the device is a part of a R8A7790 SoC.
+ "renesas,i2c-r8a7791" if the device is a part of a R8A7791 SoC.
+ "renesas,i2c-r8a7792" if the device is a part of a R8A7792 SoC.
+ "renesas,i2c-r8a7793" if the device is a part of a R8A7793 SoC.
+ "renesas,i2c-r8a7794" if the device is a part of a R8A7794 SoC.
+ "renesas,i2c-r8a7795" if the device is a part of a R8A7795 SoC.
+ "renesas,i2c-r8a7796" if the device is a part of a R8A7796 SoC.
+ "renesas,i2c-rcar-gen1" for a generic R-Car Gen1 compatible device.
+ "renesas,i2c-rcar-gen2" for a generic R-Car Gen2 compatible device.
+ "renesas,i2c-rcar-gen3" for a generic R-Car Gen3 compatible device.
+ "renesas,i2c-rcar" (deprecated)
+
+ When compatible with the generic version, nodes must list the
+ SoC-specific version corresponding to the platform first followed
+ by the generic version.
+
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: interrupt specifier.
@@ -33,7 +41,7 @@ Examples :
i2c0: i2c@e6508000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7791";
+ compatible = "renesas,i2c-r8a7791", "renesas,i2c-rcar-gen2";
reg = <0 0xe6508000 0 0x40>;
interrupts = <0 287 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp9_clks R8A7791_CLK_I2C0>;
diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
index 726615e54f2a..622def6b43e2 100644
--- a/drivers/i2c/busses/i2c-rcar.c
+++ b/drivers/i2c/busses/i2c-rcar.c
@@ -793,7 +793,6 @@ static const struct i2c_algorithm rcar_i2c_algo = {
};
static const struct of_device_id rcar_i2c_dt_ids[] = {
- { .compatible = "renesas,i2c-rcar", .data = (void *)I2C_RCAR_GEN1 },
{ .compatible = "renesas,i2c-r8a7778", .data = (void *)I2C_RCAR_GEN1 },
{ .compatible = "renesas,i2c-r8a7779", .data = (void *)I2C_RCAR_GEN1 },
{ .compatible = "renesas,i2c-r8a7790", .data = (void *)I2C_RCAR_GEN2 },
@@ -803,6 +802,10 @@ static const struct of_device_id rcar_i2c_dt_ids[] = {
{ .compatible = "renesas,i2c-r8a7794", .data = (void *)I2C_RCAR_GEN2 },
{ .compatible = "renesas,i2c-r8a7795", .data = (void *)I2C_RCAR_GEN3 },
{ .compatible = "renesas,i2c-r8a7796", .data = (void *)I2C_RCAR_GEN3 },
+ { .compatible = "renesas,i2c-rcar", .data = (void *)I2C_RCAR_GEN1 }, // Deprecated
+ { .compatible = "renesas,rcar-gen1-i2c", .data = (void *)I2C_RCAR_GEN1 },
+ { .compatible = "renesas,rcar-gen2-i2c", .data = (void *)I2C_RCAR_GEN2 },
+ { .compatible = "renesas,rcar-gen3-i2c", .data = (void *)I2C_RCAR_GEN3 },
{},
};
MODULE_DEVICE_TABLE(of, rcar_i2c_dt_ids);
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* Re: [PATCH 0/5] Meson GXL and GXM USB support
From: Rob Herring @ 2016-12-01 15:54 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, kishon-l0cyMroinI0,
khilman-rdvid1DuHRBWk0Htik3J/w, carlo-KA+7E9HrN00dnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, narmstrong-rdvid1DuHRBWk0Htik3J/w
In-Reply-To: <CAFBinCC8c2sXgo80LMMg=jqZ2hr8eLM_2g03H1J99m4xxFGYFA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Nov 30, 2016 at 11:49:03PM +0100, Martin Blumenstingl wrote:
> On Wed, Nov 30, 2016 at 11:22 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> > On Sun, Nov 27, 2016 at 11:42:02PM +0100, Martin Blumenstingl wrote:
> >> Hello Kishon,
> >>
> >> On Sat, Nov 26, 2016 at 3:56 PM, Martin Blumenstingl
> >> <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
> >> > USB support on GXL and GXM differs a lot from Meson8b and GXBB:
> >> > The most obvious change is that GXL and GXM now have one dwc3
> >> > controller and one dwc2 controller (instead of two dwc2 controllers).
> >> > With that there are also new USB PHYs.
> >> >
> >> > Due to lack of hardware I was only able to test this on a board with
> >> > GXM, but as far as I understand the hardware my preparations should be
> >> > correct (so it should also work on GXL).
> >> >
> >> > dwc2 will probably stay unused on most GXM devices since it's limited
> >> > to device mode via some dwc2 hardware configuration register.
> >> >
> >> > dwc3 is probably used on all devices, even if there is more than just
> >> > one USB port. dwc3 has a built-in USB2 hub - on GXL this hub has two
> >> > ports enabled, while on GXM there are three ports enabled (see below
> >
> > This hub is an actual USB hub? If so, then you should probably model the
> > USB bus topology (which we have a binding definition for).
> (the following explanation is based on a) what I found is going on in
> the hardware registers b) reading the vendor drivers - unfortunately
> there are no datasheets available which could give more details).
> lsusb on my GXM gives:
> ...
> Hub Port Status:
> Port 1: 0000.0100 power
> Port 2: 0000.0100 power
> Port 3: 0000.0100 power
>
> The layout looks like this:
> dwc3 provides a USB hub with 2 (on GXL) or 3 (on GXM) USB ports.
> Each of the port is driven by a PHY (port 1 = abp@0x78000, port2 =
> abp@0x78020, etc...).
>
> On GXM USB2 PHY port 3 = abp@0x78040 is connected to the third dwc3 hub port.
> On GXL PHY port 3 = abp@0x78040 is connected to the dwc2 (I could not
> prove this yet as I don't have access to any GXL hardware).
>
> So the answer is: we don't have an actual USB hub here (as this hub is
> provided by dwc3), but rather a set of PHYs which is assigned to
> dwc3's hub (if we don't configure *all* PHYs then none of the USB
> ports provided by the dwc3 hub works).
>
> Could you please point me to the USB bus topology binding (is it the
> one described in usb-device.txt)?
Yes.
>
> >> > for lsusb output). There are no USB3 ports enabled in the dwc3 hardware
> >> > configuration, meaning that the SoC is limited to high-speed mode.
> >> > On my GXM device the dwc3 hardware configuration forces it into "host
> >> > only" mode.
> >> >
> >> > The SoCs contain two PHY blocks: one USB3 PHY and up to four USB2 PHYs
> >> > (on GXM there are only three enabled, but the registers should support
> >> > up to four).
> >> > The USB3 PHY also handles the OTG interrupts, but since dwc3's hardware
> >> > configuration enforces "host only" mode I was not able to test this. It
> >> > simply takes care of an interrupt and then notifies all related PHYs
> >> > about the new mode.
> >> > The USB2 PHY block is a bit different: I created one PHY driver which
> >> > spans all "PHY ports" because the handling is a bit tricky. It turns
> >> > out that for each available USB port in dwc3's hub the corresponding
> >> > PHY must be enabled (even if there is no physical port - in my case
> >> > port 3 is not connected to anything, but disabling the PHY breaks
> >> > ports 1 and 2 as well).
> >> > I decided not not pass the USB2 PHYs directly to dwc3 due to three
> >> > reasons: 1. the USB3 PHY (which holds a reference to all relevant
> >> > USB2 PHY ports) controls the mode of the USB2 PHY ports (since both
> >> > are used with the same controller and thus it makes sense to keep the
> >> > mode consistent across all ports) 2. the dwc3 driver does not support
> >> > passing multiple USB2 PHYs (only one USB2 and one USB3 PHY can be
> >> > passed to it) 3. it is similar to how the vendor reference driver
> >> > manages the PHYs. Please note that this coupling is not a fixed, this
> >> > is all configurable via devicetree (so if the third USB2 PHY has to
> >> > be passed two the dwc2 controller then this is still possible by
> >> > just moving on PHY reference in the .dts).
> >> after not staring at my own code for 24 hours I realized this:
> >> (I went through quite a few iterations before getting these drivers to work)
> >> I'm basically re-modelling an "USB PHY hub" with my USB3 PHY driver
> >> (there's one "upstream" PHY interface which is passed to dwc3 and
> >> multiple downstream PHYs, each for one port on dwc3's internal hub).
> >> With this approach I could split each of the the USB2s into separate
> >> nodes again (instead of one devicetree node with #phy-cells = <1>) as
> >> the USB3 PHY is taking care of that special "we have to enable all
> >> ports or no port will be usable".
> >>
> >> We could go even one step further: why implement this in the Meson GXL
> >> specific PHY driver - why not implement a generic "phy-hub" driver
> >> (which would be valid whenever the PHY controller has to manage
> >> multiple PHYs at once, but wants to keep them all in a consistent
> >> state).
> >> The devicetree could look like this:
> >> usb2_phy_hub: phy@0 {
> >> compatible = "phy-hub";
> >> phys = <&other_phy1>, <&other_phy 2>;
> >> };
> >>
> >> &dwc3 {
> >> phys = <&usb2_phy_hub>, <&usb3_phy0>;
> >> phy-names = "usb2-phy", "usb3-phy";
> >> };
> >
> > I'm okay with a hub if it is modeled as a USB hub. Here though, it
> > looks like you are just trying to group things which doesn't need to be
> > in DT.
> I hope my answer above makes things more clear
Yes, I thought there was some heirarchy here, but it seems not.
So you should just list the 3 phys at the controller. The controller
has 3 ports and you have a phy for each port. The fact that they all
need to be on/initialized is a quirk and shouldn't mean that you create
some heirarchy in DT.
> >> The generic phy-hub driver would then implement all phy_ops callbacks
> >> and pass then to each of it's downstream PHYs.
> >
> > You can have generic drivers without a generic binding.
> So you'd rather implement a generic driver which would provide
> functions like of_create_grouped_phy(struct device_node *np) which
> would implement the grouping logic as described (but has no binding
> itself, but rather relies on the actual platform driver taking care of
> creating that binding and re-using generic code)?
Right.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH/RFC v2 i2c/for-next] i2c: rcar: Add per-Generation fallback bindings
From: Geert Uytterhoeven @ 2016-12-01 15:55 UTC (permalink / raw)
To: Simon Horman
Cc: Wolfram Sang, Magnus Damm, Linux I2C, Linux-Renesas, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1480606863-4418-1-git-send-email-horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
Hi Simon,
On Thu, Dec 1, 2016 at 4:41 PM, Simon Horman <horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
> In the case of Renesas R-Car hardware we know that there are generations of
> SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the
> relationship between IP blocks might be. For example, I believe that
> r8a7790 is older than r8a7791 but that doesn't imply that the latter is a
> descendant of the former or vice versa.
>
> We can, however, by examining the documentation and behaviour of the
> hardware at run-time observe that the current driver implementation appears
> to be compatible with the IP blocks on SoCs within a given generation.
>
> For the above reasons and convenience when enabling new SoCs a
> per-generation fallback compatibility string scheme being adopted for
> drivers for Renesas SoCs.
>
> Also deprecate renesas,i2c-rcar. It seems poorly named as it is only
> compatible with R-Car Gen 1. It also appears unused in mainline.
>
> Signed-off-by: Simon Horman <horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
> ---
> Include accidently omitted i2c-rcar.c portion of patch
> ---
> Documentation/devicetree/bindings/i2c/i2c-rcar.txt | 32 ++++++++++++++--------
> drivers/i2c/busses/i2c-rcar.c | 5 +++-
> 2 files changed, 24 insertions(+), 13 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
> index 239632a0d709..8c679b17c4c6 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
> @@ -1,17 +1,25 @@
> I2C for R-Car platforms
>
> Required properties:
> -- compatible: Must be one of
> - "renesas,i2c-rcar"
> - "renesas,i2c-r8a7778"
> - "renesas,i2c-r8a7779"
> - "renesas,i2c-r8a7790"
> - "renesas,i2c-r8a7791"
> - "renesas,i2c-r8a7792"
> - "renesas,i2c-r8a7793"
> - "renesas,i2c-r8a7794"
> - "renesas,i2c-r8a7795"
> - "renesas,i2c-r8a7796"
> +- compatible:
> + "renesas,i2c-r8a7778" if the device is a part of a R8A7778 SoC.
> + "renesas,i2c-r8a7779" if the device is a part of a R8A7797 SoC.
> + "renesas,i2c-r8a7790" if the device is a part of a R8A7790 SoC.
> + "renesas,i2c-r8a7791" if the device is a part of a R8A7791 SoC.
> + "renesas,i2c-r8a7792" if the device is a part of a R8A7792 SoC.
> + "renesas,i2c-r8a7793" if the device is a part of a R8A7793 SoC.
> + "renesas,i2c-r8a7794" if the device is a part of a R8A7794 SoC.
> + "renesas,i2c-r8a7795" if the device is a part of a R8A7795 SoC.
> + "renesas,i2c-r8a7796" if the device is a part of a R8A7796 SoC.
> + "renesas,i2c-rcar-gen1" for a generic R-Car Gen1 compatible device.
> + "renesas,i2c-rcar-gen2" for a generic R-Car Gen2 compatible device.
> + "renesas,i2c-rcar-gen3" for a generic R-Car Gen3 compatible device.
"renesas,rcar-gen1-i2c" etc.
> + "renesas,i2c-rcar" (deprecated)
> +
> + When compatible with the generic version, nodes must list the
> + SoC-specific version corresponding to the platform first followed
> + by the generic version.
> +
> - reg: physical base address of the controller and length of memory mapped
> region.
> - interrupts: interrupt specifier.
> @@ -33,7 +41,7 @@ Examples :
> i2c0: i2c@e6508000 {
> #address-cells = <1>;
> #size-cells = <0>;
> - compatible = "renesas,i2c-r8a7791";
> + compatible = "renesas,i2c-r8a7791", "renesas,i2c-rcar-gen2";
"renesas,rcar-gen2-i2c"
> reg = <0 0xe6508000 0 0x40>;
> interrupts = <0 287 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&mstp9_clks R8A7791_CLK_I2C0>;
> diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
> index 726615e54f2a..622def6b43e2 100644
> --- a/drivers/i2c/busses/i2c-rcar.c
> +++ b/drivers/i2c/busses/i2c-rcar.c
> @@ -793,7 +793,6 @@ static const struct i2c_algorithm rcar_i2c_algo = {
> };
>
> static const struct of_device_id rcar_i2c_dt_ids[] = {
> - { .compatible = "renesas,i2c-rcar", .data = (void *)I2C_RCAR_GEN1 },
> { .compatible = "renesas,i2c-r8a7778", .data = (void *)I2C_RCAR_GEN1 },
> { .compatible = "renesas,i2c-r8a7779", .data = (void *)I2C_RCAR_GEN1 },
> { .compatible = "renesas,i2c-r8a7790", .data = (void *)I2C_RCAR_GEN2 },
> @@ -803,6 +802,10 @@ static const struct of_device_id rcar_i2c_dt_ids[] = {
> { .compatible = "renesas,i2c-r8a7794", .data = (void *)I2C_RCAR_GEN2 },
> { .compatible = "renesas,i2c-r8a7795", .data = (void *)I2C_RCAR_GEN3 },
> { .compatible = "renesas,i2c-r8a7796", .data = (void *)I2C_RCAR_GEN3 },
> + { .compatible = "renesas,i2c-rcar", .data = (void *)I2C_RCAR_GEN1 }, // Deprecated
> + { .compatible = "renesas,rcar-gen1-i2c", .data = (void *)I2C_RCAR_GEN1 },
> + { .compatible = "renesas,rcar-gen2-i2c", .data = (void *)I2C_RCAR_GEN2 },
> + { .compatible = "renesas,rcar-gen3-i2c", .data = (void *)I2C_RCAR_GEN3 },
The driver does it right ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 22/39] mtd: nand: denali_dt: remove dma-mask DT property
From: Rob Herring @ 2016-12-01 15:56 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Boris Brezillon, Marek Vasut,
Brian Norris, Richard Weinberger, David Woodhouse,
Cyrille Pitchen, Mark Rutland
In-Reply-To: <1480183585-592-23-git-send-email-yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
On Sun, Nov 27, 2016 at 03:06:08AM +0900, Masahiro Yamada wrote:
> The driver sets appropriate DMA mask. Delete the "dma-mask" DT
> property. Refer to the Link tag for negative opinions for this
> binding.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
> Link: https://lkml.org/lkml/2016/2/8/57
> ---
>
> Documentation/devicetree/bindings/mtd/denali-nand.txt | 2 --
> drivers/mtd/nand/denali_dt.c | 9 ---------
> 2 files changed, 11 deletions(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 33/39] mtd: nand: denali: support 1024 byte ECC step size
From: Rob Herring @ 2016-12-01 15:58 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Boris Brezillon, Marek Vasut,
Brian Norris, Richard Weinberger, David Woodhouse,
Cyrille Pitchen, Mark Rutland
In-Reply-To: <1480183585-592-34-git-send-email-yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
On Sun, Nov 27, 2016 at 03:06:19AM +0900, Masahiro Yamada wrote:
> This driver was originally written for the Intel MRST platform with
> several platform specific parameters hard-coded. Another thing we
> need to fix is the hard-coded ECC step size. Currently, it is
> defined as follows:
>
> #define ECC_SECTOR_SIZE 512
>
> (somehow, it is defined in both denali.c and denali.h)
>
> This must be avoided because the Denali IP supports 1024 byte ECC
> size as well. Add a new flag DENALI_CAPS_ECC_SIZE_1024. If it is
> specified, ecc.size is set to 1024, otherwise set to 512.
>
> We can use "nand-ecc-step-size" DT property to override the ecc.size
> if we want, but this capability flag can provide the reasonable
> default because it is associated with the DT compatible strings.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
> ---
>
> .../devicetree/bindings/mtd/denali-nand.txt | 4 ++++
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> drivers/mtd/nand/denali.c | 26 +++++++++++-----------
> drivers/mtd/nand/denali.h | 3 +--
> 3 files changed, 18 insertions(+), 15 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 37/39] mtd: nand: denali: support "nand-ecc-strength" DT property
From: Rob Herring @ 2016-12-01 15:59 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Mark Rutland, devicetree, Boris Brezillon, Richard Weinberger,
linux-kernel, Marek Vasut, linux-mtd, Cyrille Pitchen,
Brian Norris, David Woodhouse
In-Reply-To: <1480183585-592-38-git-send-email-yamada.masahiro@socionext.com>
On Sun, Nov 27, 2016 at 03:06:23AM +0900, Masahiro Yamada wrote:
> Historically, this driver tried to choose as big ECC strength as
> possible, but it would be reasonable to allow DT to set a particular
> ECC strength with "nand-ecc-strength" property.
>
> Going forward, DT platforms should specify "nand-ecc-strength" or
> "nand-ecc-maximize" to show the ECC strength strategy explicitly.
>
> If nothing is specified in DT, "nand-ecc-maximize" is implied since
> this was the original behavior. It applies to PCI platforms too.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
>
> .../devicetree/bindings/mtd/denali-nand.txt | 5 ++++
I'd prefer all the DT changes be in 1 patch, but
Acked-by: Rob Herring <robh@kernel.org>
> drivers/mtd/nand/denali.c | 27 +++++++++++++++++++++-
> drivers/mtd/nand/denali_pci.c | 2 ++
> 3 files changed, 33 insertions(+), 1 deletion(-)
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH 39/39] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants
From: Rob Herring @ 2016-12-01 16:05 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-mtd, devicetree, linux-kernel, Boris Brezillon, Marek Vasut,
Brian Norris, Richard Weinberger, David Woodhouse,
Cyrille Pitchen, Mark Rutland
In-Reply-To: <1480183585-592-40-git-send-email-yamada.masahiro@socionext.com>
On Sun, Nov 27, 2016 at 03:06:25AM +0900, Masahiro Yamada wrote:
> Add two compatible strings for UniPhier SoCs. The revision register
> on both shows revision 5.0, but they are different hardware.
>
> Features:
> - DMA engine with 64 bit physical address support
> - 1024 byte ECC step size
> - 8 / 16 / 24 bit ECC strength
> - The n_banks format depends on SoC
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
>
> .../devicetree/bindings/mtd/denali-nand.txt | 10 +++++--
> drivers/mtd/nand/denali_dt.c | 33 ++++++++++++++++++++--
> 2 files changed, 38 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mtd/denali-nand.txt b/Documentation/devicetree/bindings/mtd/denali-nand.txt
> index 51fe195..cea46e2 100644
> --- a/Documentation/devicetree/bindings/mtd/denali-nand.txt
> +++ b/Documentation/devicetree/bindings/mtd/denali-nand.txt
> @@ -1,13 +1,19 @@
> * Denali NAND controller
>
> Required properties:
> - - compatible : should be "denali,denali-nand-dt"
> + - compatible : should be one of the following:
> + "denali,denali-nand-dt"
There are multiple things wrong with this string. denali,denali is
redundant is one. It's also fairly useless as this IP has several
versions and numerous configuration options IIRC. This should be
deprecated IMO.
> + "denali,denali-nand-uniphier-v5a"
> + "denali,denali-nand-uniphier-v5b"
Use your vendor prefix, not denali. The 2nd denali can probably be
dropped because it is not likely you have another kind of nand
controller in the SoC.
> - reg : should contain registers location and length for data and reg.
> - reg-names: Should contain the reg names "nand_data" and "denali_reg"
> - interrupts : The interrupt number.
>
> Optional properties:
> - - nand-ecc-step-size: must be 512 or 1024. If not specified, default to 512.
> + - nand-ecc-step-size: must be 512 or 1024. If not specified, default to:
> + 512 for "denali,denali-nand-dt"
> + 1024 for "denali,denali-nand-uniphier-v5a"
> + 1024 for "denali,denali-nand-uniphier-v5b"
> see nand.txt for details.
> - nand-ecc-strength: see nand.txt for details
> - nand-ecc-maximize: see nand.txt for details
^ permalink raw reply
* Re: [PATCH 4/5] regulator: Add support for TI TWL6032
From: Rob Herring @ 2016-12-01 16:10 UTC (permalink / raw)
To: Nicolae Rosia
Cc: Lee Jones, Mark Brown, Mark Rutland, Tony Lindgren, Liam Girdwood,
Paul Gortmaker, Graeme Gregory, Baruch Siach, linux-omap,
linux-arm-kernel, linux-kernel, devicetree
In-Reply-To: <20161126181326.14951-5-Nicolae_Rosia@mentor.com>
On Sat, Nov 26, 2016 at 08:13:25PM +0200, Nicolae Rosia wrote:
> The TWL6032 PMIC is similar to TWL6030, has different
> output names, and regulator control logic.
> It is used on Barnes & Noble Nook HD and HD+.
>
> Signed-off-by: Nicolae Rosia <Nicolae_Rosia@mentor.com>
> ---
> .../bindings/regulator/twl6032-regulator.txt | 109 ++++
> drivers/regulator/Kconfig | 7 +
> drivers/regulator/Makefile | 1 +
> drivers/regulator/twl6032-regulator.c | 582 +++++++++++++++++++++
> 4 files changed, 699 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/regulator/twl6032-regulator.txt
> create mode 100644 drivers/regulator/twl6032-regulator.c
>
> diff --git a/Documentation/devicetree/bindings/regulator/twl6032-regulator.txt b/Documentation/devicetree/bindings/regulator/twl6032-regulator.txt
> new file mode 100644
> index 0000000..323f5a9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/twl6032-regulator.txt
> @@ -0,0 +1,109 @@
> +TWL6032 PMIC Voltage Regulator Bindings
> +
> +The parent node must be MFD TWL Core, ti,twl6032.
> +
> +Required properties:
> +- compatible: "ti,twl6032"
> +
> +Optional properties:
> +- regulators node containing regulator childs.
s/childs/children/
regulators node is not a property.
> +
> +The child regulators must be named after their hardware
extra space ^
> +counterparts: LDO[1-6], LDOLN, LDOUSB and VANA.
> +
> +Each regulator is defined using the standard binding
> +for regulators as described in ./regulator.txt
> +
> +Example:
> +twl {
> + compatible = "ti,twl6032";
> +
> + [...]
> +
> + pmic {
> + compatible = "ti,twl6032-regulator";
Not documented.
> +
> + regulators {
Do you really need pmic node and regulators node?
> + ldo1: LDO1 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <2500000>;
> +
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + ldo2: LDO2 {
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <3000000>;
> +
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + ldo3: LDO3 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-boot-on;
> +
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + ldo4: LDO4 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> +
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + ldo5: LDO5 {
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <3000000>;
> +
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + ldo6: LDO6 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> +
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + ldo7: LDO7 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + ldoln: LDOLN {
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <3000000>;
> + };
> +
> + ldousb: LDOUSB {
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <3000000>;
> + };
> +
> + vana: VANA {
> + regulator-min-microvolt = <2100000>;
> + regulator-max-microvolt = <2100000>;
> + regulator-always-on;
> + };
> + };
> + };
> +
> + [...]
> +};
^ permalink raw reply
* Re: [PATCH 1/2] Documentation: sample averaging for imx6ul_tsc
From: Rob Herring @ 2016-12-01 16:13 UTC (permalink / raw)
To: Guy Shapiro
Cc: dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w,
fabio.estevam-KZfg59tc24xl57MIdRCFDg, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
haibo.chen-KZfg59tc24xl57MIdRCFDg,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1480232698-23075-1-git-send-email-guy.shapiro-2HKgp+mgmS5l57MIdRCFDg@public.gmane.org>
On Sun, Nov 27, 2016 at 09:44:57AM +0200, Guy Shapiro wrote:
> The i.MX6UL internal touchscreen controller contains an option to
> average upon samples. This feature reduces noise from the produced
> touch locations.
>
> This patch introduces a new device tree optional property for this
> feature. It provides control over the amount of averaged samples per
> touch event.
>
> The property was inspired by a similar property on the
> "brcm,iproc-touchscreen" binding.
>
> Signed-off-by: Guy Shapiro <guy.shapiro-2HKgp+mgmS5l57MIdRCFDg@public.gmane.org>
> ---
> .../devicetree/bindings/input/touchscreen/imx6ul_tsc.txt | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt b/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt
> index 853dff9..a66069f 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt
> @@ -17,6 +17,13 @@ Optional properties:
> This value depends on the touch screen.
> - pre-charge-time: the touch screen need some time to precharge.
> This value depends on the touch screen.
> +- average-samples: Number of data samples which are averaged for each read.
> + Valid values 0-4
> + 0 = 1 sample
> + 1 = 4 samples
> + 2 = 8 samples
> + 3 = 16 samples
> + 4 = 32 samples
Either this needs a vendor prefix or should be documented as a generic
property. In the latter case, you should use actual number of samples
(1-32) for the values.
>
> Example:
> tsc: tsc@02040000 {
> @@ -32,5 +39,6 @@ Example:
> xnur-gpio = <&gpio1 3 GPIO_ACTIVE_LOW>;
> measure-delay-time = <0xfff>;
> pre-charge-time = <0xffff>;
> + average-samples = <4>;
> status = "okay";
> };
> --
> 2.1.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 01/14] Documentation: of: add type property
From: Rob Herring @ 2016-12-01 16:26 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: Mark Brown, Linux-ALSA, Liam Girdwood, Simon, Laurent, Guennadi,
Grant Likely, Frank Rowand, Linux-DT, Linux-Kernel
In-Reply-To: <87inr8wch8.wl%kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
On Mon, Nov 28, 2016 at 02:44:46AM +0000, Kuninori Morimoto wrote:
>
> From: Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
>
> OF graph indicates each devices connection. But it doesn't support type
> of each port. For example HDMI case, it has video port and sound port
> in one device node.
> In this case, current driver can't handle each port correctly.
> This patch enables to use type property on OF graph.
I still don't think this is necessary. Simply define which port number
is which for each HDMI chip.
If this is necessary, then the types, video and sound, are too generic.
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
> ---
> Documentation/devicetree/bindings/graph.txt | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH pci/next] PCI: rcar: Add gen3 fallback compatibility string for pcie-rcar
From: Simon Horman @ 2016-12-01 16:28 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Phil Edworthy, Magnus Damm, linux-pci, linux-renesas-soc,
Rob Herring, devicetree, Simon Horman
Add fallback compatibility string for the R-Car Gen 3 family. This is in
keeping with the both the existing fallback compatibility string for the
R-Car Gen 2 family and the fallback scheme being adopted wherever
appropriate for drivers for Renesas SoCs.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
Documentation/devicetree/bindings/pci/rcar-pci.txt | 1 +
drivers/pci/host/pcie-rcar.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt b/Documentation/devicetree/bindings/pci/rcar-pci.txt
index 6cf99690eef9..eee518db90b9 100644
--- a/Documentation/devicetree/bindings/pci/rcar-pci.txt
+++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt
@@ -7,6 +7,7 @@ compatible: "renesas,pcie-r8a7779" for the R8A7779 SoC;
"renesas,pcie-r8a7793" for the R8A7793 SoC;
"renesas,pcie-r8a7795" for the R8A7795 SoC;
"renesas,pcie-rcar-gen2" for a generic R-Car Gen2 compatible device.
+ "renesas,pcie-rcar-gen3" for a generic R-Car Gen3 compatible device.
When compatible with the generic version, nodes must list the
SoC-specific version corresponding to the platform first
diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
index 62700d1896f4..962aa3942107 100644
--- a/drivers/pci/host/pcie-rcar.c
+++ b/drivers/pci/host/pcie-rcar.c
@@ -1077,6 +1077,8 @@ static const struct of_device_id rcar_pcie_of_match[] = {
.data = rcar_pcie_hw_init_gen2 },
{ .compatible = "renesas,pcie-r8a7791",
.data = rcar_pcie_hw_init_gen2 },
+ { .compatible = "renesas,pcie-rcar-gen3",
+ .data = rcar_pcie_hw_init_hw_init },
{ .compatible = "renesas,pcie-r8a7795", .data = rcar_pcie_hw_init },
{},
};
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* Re: [PATCH/RFC v2 i2c/for-next] i2c: rcar: Add per-Generation fallback bindings
From: Simon Horman @ 2016-12-01 16:29 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Wolfram Sang, Magnus Damm, Linux I2C, Linux-Renesas, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAMuHMdXr5stBRDtD0AE=1Af3PUiA=e5pP_X1onfbfO5ri=fPrw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Dec 01, 2016 at 04:55:13PM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Thu, Dec 1, 2016 at 4:41 PM, Simon Horman <horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
> > In the case of Renesas R-Car hardware we know that there are generations of
> > SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the
> > relationship between IP blocks might be. For example, I believe that
> > r8a7790 is older than r8a7791 but that doesn't imply that the latter is a
> > descendant of the former or vice versa.
> >
> > We can, however, by examining the documentation and behaviour of the
> > hardware at run-time observe that the current driver implementation appears
> > to be compatible with the IP blocks on SoCs within a given generation.
> >
> > For the above reasons and convenience when enabling new SoCs a
> > per-generation fallback compatibility string scheme being adopted for
> > drivers for Renesas SoCs.
> >
> > Also deprecate renesas,i2c-rcar. It seems poorly named as it is only
> > compatible with R-Car Gen 1. It also appears unused in mainline.
> >
> > Signed-off-by: Simon Horman <horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
> > ---
> > Include accidently omitted i2c-rcar.c portion of patch
> > ---
> > Documentation/devicetree/bindings/i2c/i2c-rcar.txt | 32 ++++++++++++++--------
> > drivers/i2c/busses/i2c-rcar.c | 5 +++-
> > 2 files changed, 24 insertions(+), 13 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
> > index 239632a0d709..8c679b17c4c6 100644
> > --- a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
> > +++ b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
> > @@ -1,17 +1,25 @@
> > I2C for R-Car platforms
> >
> > Required properties:
> > -- compatible: Must be one of
> > - "renesas,i2c-rcar"
> > - "renesas,i2c-r8a7778"
> > - "renesas,i2c-r8a7779"
> > - "renesas,i2c-r8a7790"
> > - "renesas,i2c-r8a7791"
> > - "renesas,i2c-r8a7792"
> > - "renesas,i2c-r8a7793"
> > - "renesas,i2c-r8a7794"
> > - "renesas,i2c-r8a7795"
> > - "renesas,i2c-r8a7796"
> > +- compatible:
> > + "renesas,i2c-r8a7778" if the device is a part of a R8A7778 SoC.
> > + "renesas,i2c-r8a7779" if the device is a part of a R8A7797 SoC.
> > + "renesas,i2c-r8a7790" if the device is a part of a R8A7790 SoC.
> > + "renesas,i2c-r8a7791" if the device is a part of a R8A7791 SoC.
> > + "renesas,i2c-r8a7792" if the device is a part of a R8A7792 SoC.
> > + "renesas,i2c-r8a7793" if the device is a part of a R8A7793 SoC.
> > + "renesas,i2c-r8a7794" if the device is a part of a R8A7794 SoC.
> > + "renesas,i2c-r8a7795" if the device is a part of a R8A7795 SoC.
> > + "renesas,i2c-r8a7796" if the device is a part of a R8A7796 SoC.
> > + "renesas,i2c-rcar-gen1" for a generic R-Car Gen1 compatible device.
> > + "renesas,i2c-rcar-gen2" for a generic R-Car Gen2 compatible device.
> > + "renesas,i2c-rcar-gen3" for a generic R-Car Gen3 compatible device.
>
> "renesas,rcar-gen1-i2c" etc.
>
> > + "renesas,i2c-rcar" (deprecated)
> > +
> > + When compatible with the generic version, nodes must list the
> > + SoC-specific version corresponding to the platform first followed
> > + by the generic version.
> > +
> > - reg: physical base address of the controller and length of memory mapped
> > region.
> > - interrupts: interrupt specifier.
> > @@ -33,7 +41,7 @@ Examples :
> > i2c0: i2c@e6508000 {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > - compatible = "renesas,i2c-r8a7791";
> > + compatible = "renesas,i2c-r8a7791", "renesas,i2c-rcar-gen2";
>
> "renesas,rcar-gen2-i2c"
>
> > reg = <0 0xe6508000 0 0x40>;
> > interrupts = <0 287 IRQ_TYPE_LEVEL_HIGH>;
> > clocks = <&mstp9_clks R8A7791_CLK_I2C0>;
> > diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
> > index 726615e54f2a..622def6b43e2 100644
> > --- a/drivers/i2c/busses/i2c-rcar.c
> > +++ b/drivers/i2c/busses/i2c-rcar.c
> > @@ -793,7 +793,6 @@ static const struct i2c_algorithm rcar_i2c_algo = {
> > };
> >
> > static const struct of_device_id rcar_i2c_dt_ids[] = {
> > - { .compatible = "renesas,i2c-rcar", .data = (void *)I2C_RCAR_GEN1 },
> > { .compatible = "renesas,i2c-r8a7778", .data = (void *)I2C_RCAR_GEN1 },
> > { .compatible = "renesas,i2c-r8a7779", .data = (void *)I2C_RCAR_GEN1 },
> > { .compatible = "renesas,i2c-r8a7790", .data = (void *)I2C_RCAR_GEN2 },
> > @@ -803,6 +802,10 @@ static const struct of_device_id rcar_i2c_dt_ids[] = {
> > { .compatible = "renesas,i2c-r8a7794", .data = (void *)I2C_RCAR_GEN2 },
> > { .compatible = "renesas,i2c-r8a7795", .data = (void *)I2C_RCAR_GEN3 },
> > { .compatible = "renesas,i2c-r8a7796", .data = (void *)I2C_RCAR_GEN3 },
> > + { .compatible = "renesas,i2c-rcar", .data = (void *)I2C_RCAR_GEN1 }, // Deprecated
> > + { .compatible = "renesas,rcar-gen1-i2c", .data = (void *)I2C_RCAR_GEN1 },
> > + { .compatible = "renesas,rcar-gen2-i2c", .data = (void *)I2C_RCAR_GEN2 },
> > + { .compatible = "renesas,rcar-gen3-i2c", .data = (void *)I2C_RCAR_GEN3 },
>
> The driver does it right ;-)
Sorry, I switched things around at some point but it looks
like I only did half the job.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v4 0/3] Altera Cyclone Passive Serial SPI FPGA Manager
From: Joshua Clayton @ 2016-12-01 17:04 UTC (permalink / raw)
To: Alan Tull, Moritz Fischer, Rob Herring, Mark Rutland,
Russell King
Cc: Joshua Clayton, devicetree, linux-kernel, linux-arm-kernel
This series adds an FPGA manager for Altera cyclone FPGAs
that can program them using an spi port and a couple of gpios, using
Alteras passive serial protocol.
Changes from v3:
- Fixed up the state() function to return the state of the status pin
reqested by Alan Tull
- Switched the pin to ACTIVE_LOW and coresponding logic level, and updated
the corresponding documentation. Thanks Rob Herring for pointing out my
mistake.
- Per Rob Herring, switched from "gpio" to "gpios" in dts
Changes from v2:
- Merged patch 3 and 4 as suggested in review by Moritz Fischer
- Changed FPGA_MIN_DELAY from 250 to 50 ms is the time advertized by
Altera. This now works, as we don't assume it is done
Changes from v1:
- Changed the name from cyclone-spi-fpga-mgr to cyclone-ps-spi-fpga-mgr
This name change was requested by Alan Tull, to be specific about which
programming method is being employed on the fpga.
- Changed the name of the reset-gpio to config-gpio to closer match the
way the pins are described in the Altera manual
- Moved MODULE_LICENCE, _AUTHOR, and _DESCRIPTION to the bottom
- Added a bitrev8x4() function to the bitrev headers and implemented ARM
const, runtime, and ARM specific faster versions (This may end up
needing to be a standalone patch)
- Moved the bitswapping into cyclonespi_write(), as requested.
This falls short of my desired generic lsb first spi support, but is a step
in that direction.
- Fixed whitespace problems introduced during refactoring
- Replaced magic number for initial delay with a descriptive macro
- Poll the fpga to see when it is ready rather than a fixed 1 ms sleep
Joshua Clayton (3):
lib: add bitrev8x4()
doc: dt: add cyclone-spi binding document
fpga manager: Add cyclone-ps-spi driver for Altera FPGAs
.../bindings/fpga/cyclone-ps-spi-fpga-mgr.txt | 25 +++
arch/arm/include/asm/bitrev.h | 5 +
drivers/fpga/Kconfig | 7 +
drivers/fpga/Makefile | 1 +
drivers/fpga/cyclone-ps-spi.c | 181 +++++++++++++++++++++
include/linux/bitrev.h | 26 +++
6 files changed, 245 insertions(+)
create mode 100644 Documentation/devicetree/bindings/fpga/cyclone-ps-spi-fpga-mgr.txt
create mode 100644 drivers/fpga/cyclone-ps-spi.c
--
2.9.3
^ permalink raw reply
* [PATCH v4 1/3] lib: add bitrev8x4()
From: Joshua Clayton @ 2016-12-01 17:04 UTC (permalink / raw)
To: Alan Tull, Moritz Fischer, Rob Herring, Mark Rutland,
Russell King
Cc: Joshua Clayton, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <cover.1480551148.git.stillcompiling@gmail.com>
Add a function to reverse bytes within a 32 bit word.
This function is more efficient than using the 8 bit version when
iterating over an array
Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
---
Looking for an ACK from Russell King on this patch (or at least
the arm specific implementation)
arch/arm/include/asm/bitrev.h | 5 +++++
include/linux/bitrev.h | 26 ++++++++++++++++++++++++++
2 files changed, 31 insertions(+)
diff --git a/arch/arm/include/asm/bitrev.h b/arch/arm/include/asm/bitrev.h
index ec291c3..6d2e9ca 100644
--- a/arch/arm/include/asm/bitrev.h
+++ b/arch/arm/include/asm/bitrev.h
@@ -17,4 +17,9 @@ static __always_inline __attribute_const__ u8 __arch_bitrev8(u8 x)
return __arch_bitrev32((u32)x) >> 24;
}
+static __always_inline __attribute_const__ u32 __arch_bitrev8x4(u32 x)
+{
+ __asm__ ("rbit %0, %1; rev %0, %0" : "=r" (x) : "r" (x));
+}
+
#endif
diff --git a/include/linux/bitrev.h b/include/linux/bitrev.h
index fb790b8..b1cfa1a 100644
--- a/include/linux/bitrev.h
+++ b/include/linux/bitrev.h
@@ -9,6 +9,7 @@
#define __bitrev32 __arch_bitrev32
#define __bitrev16 __arch_bitrev16
#define __bitrev8 __arch_bitrev8
+#define __bitrev8x4 __arch_bitrev8x4
#else
extern u8 const byte_rev_table[256];
@@ -27,6 +28,14 @@ static inline u32 __bitrev32(u32 x)
return (__bitrev16(x & 0xffff) << 16) | __bitrev16(x >> 16);
}
+static inline u32 __bitrev8x4(u32 x)
+{
+ return(__bitrev8(x & 0xff) |
+ (__bitrev8((x >> 8) & 0xff) << 8) |
+ (__bitrev8((x >> 16) & 0xff) << 16) |
+ (__bitrev8((x >> 24) & 0xff) << 24));
+}
+
#endif /* CONFIG_HAVE_ARCH_BITREVERSE */
#define __constant_bitrev32(x) \
@@ -50,6 +59,15 @@ static inline u32 __bitrev32(u32 x)
__x; \
})
+#define __constant_bitrev8x4(x) \
+({ \
+ u32 __x = x; \
+ __x = ((__x & (u32)0xF0F0F0F0UL) >> 4) | ((__x & (u32)0x0F0F0F0FUL) << 4); \
+ __x = ((__x & (u32)0xCCCCCCCCUL) >> 2) | ((__x & (u32)0x33333333UL) << 2); \
+ __x = ((__x & (u32)0xAAAAAAAAUL) >> 1) | ((__x & (u32)0x55555555UL) << 1); \
+ __x; \
+})
+
#define __constant_bitrev8(x) \
({ \
u8 __x = x; \
@@ -75,6 +93,14 @@ static inline u32 __bitrev32(u32 x)
__bitrev16(__x); \
})
+#define bitrev8x4(x) \
+({ \
+ u32 __x = x; \
+ __builtin_constant_p(__x) ? \
+ __constant_bitrev8x4(__x) : \
+ __bitrev8x4(__x); \
+})
+
#define bitrev8(x) \
({ \
u8 __x = x; \
--
2.9.3
^ permalink raw reply related
* [PATCH v4 2/3] doc: dt: add cyclone-spi binding document
From: Joshua Clayton @ 2016-12-01 17:04 UTC (permalink / raw)
To: Alan Tull, Moritz Fischer, Rob Herring, Mark Rutland,
Russell King
Cc: Joshua Clayton, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <cover.1480551148.git.stillcompiling@gmail.com>
Describe a cyclonei-ps-spi devicetree entry, required features
Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
---
.../bindings/fpga/cyclone-ps-spi-fpga-mgr.txt | 25 ++++++++++++++++++++++
1 file changed, 25 insertions(+)
create mode 100644 Documentation/devicetree/bindings/fpga/cyclone-ps-spi-fpga-mgr.txt
diff --git a/Documentation/devicetree/bindings/fpga/cyclone-ps-spi-fpga-mgr.txt b/Documentation/devicetree/bindings/fpga/cyclone-ps-spi-fpga-mgr.txt
new file mode 100644
index 0000000..3f515c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/cyclone-ps-spi-fpga-mgr.txt
@@ -0,0 +1,25 @@
+Altera Cyclone Passive Serial SPI FPGA Manager
+
+Altera Cyclone FPGAs support a method of loading the bitstream over what is
+referred to as "passive serial".
+The passive serial link is not technically spi, and might require extra
+circuits in order to play nicely with other spi slaves on the same bus.
+
+See https://www.altera.com/literature/hb/cyc/cyc_c51013.pdf
+
+Required properties:
+- compatible : should contain "altr,cyclone-ps-spi-fpga-mgr"
+- reg : spi slave id of the fpga
+- config-gpios : config pin (referred to as nCONFIG in the cyclone manual)
+- status-gpios : status pin (referred to as nSTATUS in the cyclone manual)
+
+both gpio pins are normally active low open drain.
+
+Example:
+ fpga_spi: evi-fpga-spi@0 {
+ compatible = "altr,cyclone-ps-spi-fpga-mgr";
+ spi-max-frequency = <20000000>;
+ reg = <0>;
+ config-gpios = <&gpio4 9 GPIO_ACTIVE_LOW>;
+ status-gpios = <&gpio4 11 GPIO_ACTIVE_LOW>;
+ };
--
2.9.3
^ permalink raw reply related
* [PATCH v4 3/3] fpga manager: Add cyclone-ps-spi driver for Altera FPGAs
From: Joshua Clayton @ 2016-12-01 17:04 UTC (permalink / raw)
To: Alan Tull, Moritz Fischer, Rob Herring, Mark Rutland,
Russell King
Cc: Joshua Clayton, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <cover.1480551148.git.stillcompiling@gmail.com>
cyclone-ps-spi loads FPGA firmware over spi, using the "passive serial"
interface on Altera Cyclone FPGAS.
This is one of the simpler ways to set up an FPGA at runtime.
The signal interface is close to unidirectional spi with lsb first.
Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
---
drivers/fpga/Kconfig | 7 ++
drivers/fpga/Makefile | 1 +
drivers/fpga/cyclone-ps-spi.c | 181 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 189 insertions(+)
create mode 100644 drivers/fpga/cyclone-ps-spi.c
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index cd84934..2462707 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -13,6 +13,13 @@ config FPGA
if FPGA
+config FPGA_MGR_CYCLONE_PS_SPI
+ tristate "Altera Cyclone FPGA Passive Serial over SPI"
+ depends on SPI
+ help
+ FPGA manager driver support for Altera Cyclone using the
+ passive serial interface over SPI
+
config FPGA_MGR_SOCFPGA
tristate "Altera SOCFPGA FPGA Manager"
depends on ARCH_SOCFPGA
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 8d83fc6..8f93930 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -6,5 +6,6 @@
obj-$(CONFIG_FPGA) += fpga-mgr.o
# FPGA Manager Drivers
+obj-$(CONFIG_FPGA_MGR_CYCLONE_PS_SPI) += cyclone-ps-spi.o
obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA) += zynq-fpga.o
diff --git a/drivers/fpga/cyclone-ps-spi.c b/drivers/fpga/cyclone-ps-spi.c
new file mode 100644
index 0000000..82a754a
--- /dev/null
+++ b/drivers/fpga/cyclone-ps-spi.c
@@ -0,0 +1,181 @@
+/**
+ * Copyright (c) 2015 United Western Technologies, Corporation
+ *
+ * Joshua Clayton <stillcompiling@gmail.com>
+ *
+ * Manage Altera fpga firmware that is loaded over spi.
+ * Firmware must be in binary "rbf" format.
+ * Works on Cyclone V. Should work on cyclone series.
+ * May work on other Altera fpgas.
+ *
+ */
+
+#include <linux/bitrev.h>
+#include <linux/delay.h>
+#include <linux/fpga/fpga-mgr.h>
+#include <linux/gpio/consumer.h>
+#include <linux/module.h>
+#include <linux/of_gpio.h>
+#include <linux/spi/spi.h>
+#include <linux/sizes.h>
+
+#define FPGA_RESET_TIME 50 /* time in usecs to trigger FPGA config */
+#define FPGA_MIN_DELAY 50 /* min usecs to wait for config status */
+#define FPGA_MAX_DELAY 1000 /* max usecs to wait for config status */
+
+struct cyclonespi_conf {
+ struct gpio_desc *config;
+ struct gpio_desc *status;
+ struct spi_device *spi;
+};
+
+static const struct of_device_id of_ef_match[] = {
+ { .compatible = "altr,cyclone-ps-spi-fpga-mgr", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, of_ef_match);
+
+static enum fpga_mgr_states cyclonespi_state(struct fpga_manager *mgr)
+{
+ struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
+
+ if (gpiod_get_value(conf->status))
+ return FPGA_MGR_STATE_RESET;
+
+ return FPGA_MGR_STATE_UNKNOWN;
+}
+
+static int cyclonespi_write_init(struct fpga_manager *mgr, u32 flags,
+ const char *buf, size_t count)
+{
+ struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
+ int i;
+
+ if (flags & FPGA_MGR_PARTIAL_RECONFIG) {
+ dev_err(&mgr->dev, "Partial reconfiguration not supported.\n");
+ return -EINVAL;
+ }
+
+ gpiod_set_value(conf->config, 1);
+ usleep_range(FPGA_RESET_TIME, FPGA_RESET_TIME + 20);
+ if (!gpiod_get_value(conf->status)) {
+ dev_err(&mgr->dev, "Status pin should be low.\n");
+ return -EIO;
+ }
+
+ gpiod_set_value(conf->config, 0);
+ for (i = 0; i < (FPGA_MAX_DELAY / FPGA_MIN_DELAY); i++) {
+ usleep_range(FPGA_MIN_DELAY, FPGA_MIN_DELAY + 20);
+ if (!gpiod_get_value(conf->status))
+ return 0;
+ }
+
+ dev_err(&mgr->dev, "Status pin not ready.\n");
+ return -EIO;
+}
+
+static void rev_buf(void *buf, size_t len)
+{
+ u32 *fw32 = (u32 *)buf;
+ const u32 *fw_end = (u32 *)(buf + len);
+
+ /* set buffer to lsb first */
+ while (fw32 < fw_end) {
+ *fw32 = bitrev8x4(*fw32);
+ fw32++;
+ }
+}
+
+static int cyclonespi_write(struct fpga_manager *mgr, const char *buf,
+ size_t count)
+{
+ struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
+ const char *fw_data = buf;
+ const char *fw_data_end = fw_data + count;
+
+ while (fw_data < fw_data_end) {
+ int ret;
+ size_t stride = min(fw_data_end - fw_data, SZ_4K);
+
+ rev_buf((void *)fw_data, stride);
+ ret = spi_write(conf->spi, fw_data, stride);
+ if (ret) {
+ dev_err(&mgr->dev, "spi error in firmware write: %d\n",
+ ret);
+ return ret;
+ }
+ fw_data += stride;
+ }
+
+ return 0;
+}
+
+static int cyclonespi_write_complete(struct fpga_manager *mgr, u32 flags)
+{
+ struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
+
+ if (gpiod_get_value(conf->status)) {
+ dev_err(&mgr->dev, "Error during configuration.\n");
+ return -EIO;
+ }
+
+ return 0;
+}
+
+static const struct fpga_manager_ops cyclonespi_ops = {
+ .state = cyclonespi_state,
+ .write_init = cyclonespi_write_init,
+ .write = cyclonespi_write,
+ .write_complete = cyclonespi_write_complete,
+};
+
+static int cyclonespi_probe(struct spi_device *spi)
+{
+ struct cyclonespi_conf *conf = devm_kzalloc(&spi->dev, sizeof(*conf),
+ GFP_KERNEL);
+
+ if (!conf)
+ return -ENOMEM;
+
+ conf->spi = spi;
+ conf->config = devm_gpiod_get(&spi->dev, "config", GPIOD_OUT_HIGH);
+ if (IS_ERR(conf->config)) {
+ dev_err(&spi->dev, "Failed to get config gpio: %ld\n",
+ PTR_ERR(conf->config));
+ return PTR_ERR(conf->config);
+ }
+
+ conf->status = devm_gpiod_get(&spi->dev, "status", GPIOD_IN);
+ if (IS_ERR(conf->status)) {
+ dev_err(&spi->dev, "Failed to get status gpio: %ld\n",
+ PTR_ERR(conf->status));
+ return PTR_ERR(conf->status);
+ }
+
+ return fpga_mgr_register(&spi->dev,
+ "Altera Cyclone PS SPI FPGA Manager",
+ &cyclonespi_ops, conf);
+}
+
+static int cyclonespi_remove(struct spi_device *spi)
+{
+ fpga_mgr_unregister(&spi->dev);
+
+ return 0;
+}
+
+static struct spi_driver cyclonespi_driver = {
+ .driver = {
+ .name = "cyclone-ps-spi",
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(of_ef_match),
+ },
+ .probe = cyclonespi_probe,
+ .remove = cyclonespi_remove,
+};
+
+module_spi_driver(cyclonespi_driver)
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Joshua Clayton <stillcompiling@gmail.com>");
+MODULE_DESCRIPTION("Module to load Altera FPGA firmware over spi");
--
2.9.3
^ permalink raw reply related
* Re: [PATCH] ARM: BCM5301X: Enable UART by default for BCM4708(1) and BCM4709(4)
From: Jon Mason @ 2016-12-01 17:14 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Florian Fainelli, Rob Herring, Mark Rutland, Russell King,
Hauke Mehrtens, BCM Kernel Feedback,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-arm-kernel, open list, Rafał Miłecki
In-Reply-To: <20161128140134.25128-1-zajec5@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 9111 bytes --]
On Mon, Nov 28, 2016 at 9:01 AM, Rafał Miłecki <zajec5@gmail.com> wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> Every device tested so far got UART0 (at 0x18000300) working as serial
> console. It's most likely part of reference design and all vendors use
> it that way.
>
> It seems to be easier to enable it by default and just disable it if we
> ever see a device with different hardware design.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts | 4 ----
> arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts | 4 ----
> arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts | 4 ----
> arch/arm/boot/dts/bcm4708-netgear-r6250.dts | 4 ----
> arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts | 4 ----
> arch/arm/boot/dts/bcm4708.dtsi | 4 ++++
> arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts | 4 ----
> arch/arm/boot/dts/bcm47081.dtsi | 4 ++++
> arch/arm/boot/dts/bcm4709-netgear-r7000.dts | 4 ----
> arch/arm/boot/dts/bcm4709-netgear-r8000.dts | 4 ----
> arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts | 4 ----
> arch/arm/boot/dts/bcm4709.dtsi | 1 +
> arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts | 4 ----
> arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts | 4 ----
> arch/arm/boot/dts/bcm47094-netgear-r8500.dts | 4 ----
> arch/arm/boot/dts/bcm47094.dtsi | 1 +
>
I think there are a few missing here. A quick grep shows
$ grep -rI '#include "bcm470[89].dtsi"' arch/arm/boot/dts/*.dts
arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts:#include "bcm4708.dtsi"
arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts:#include "bcm4708.dtsi"
arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts:#include "bcm4708.dtsi"
arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts:#include "bcm4708.dtsi"
arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts:#include "bcm4708.dtsi"
arch/arm/boot/dts/bcm4708-netgear-r6250.dts:#include "bcm4708.dtsi"
arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts:#include "bcm4708.dtsi"
arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts:#include "bcm4708.dtsi"
arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts:#include "bcm4709.dtsi"
arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts:#include "bcm4709.dtsi"
arch/arm/boot/dts/bcm4709-netgear-r7000.dts:#include "bcm4709.dtsi"
arch/arm/boot/dts/bcm4709-netgear-r8000.dts:#include "bcm4709.dtsi"
arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts:#include "bcm4709.dtsi"
arch/arm/boot/dts/bcm94708.dts:#include "bcm4708.dtsi"
arch/arm/boot/dts/bcm94709.dts:#include "bcm4708.dtsi"
arch/arm/boot/dts/bcm953012er.dts:#include "bcm4708.dtsi"
arch/arm/boot/dts/bcm953012k.dts:#include "bcm4708.dtsi"
I specifically care about the last 4 :)
Thanks,
Jon
> 16 files changed, 10 insertions(+), 48 deletions(-)
>
> diff --git a/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
> b/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
> index 9cb186e..d49afec0 100644
> --- a/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
> +++ b/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
> @@ -136,10 +136,6 @@
> };
> };
>
> -&uart0 {
> - status = "okay";
> -};
> -
> &usb2 {
> vcc-gpio = <&chipcommon 9 GPIO_ACTIVE_HIGH>;
> };
> diff --git a/arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts
> b/arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts
> index 35e6ed6..f591b0f 100644
> --- a/arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts
> +++ b/arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts
> @@ -55,10 +55,6 @@
> };
> };
>
> -&uart0 {
> - status = "okay";
> -};
> -
> &spi_nor {
> status = "okay";
> };
> diff --git a/arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts
> b/arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts
> index 1c7e53d..50d65d8 100644
> --- a/arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts
> +++ b/arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts
> @@ -56,10 +56,6 @@
> };
> };
>
> -&uart0 {
> - status = "okay";
> -};
> -
> &spi_nor {
> status = "okay";
> };
> diff --git a/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
> b/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
> index 8ce39d5..8519548 100644
> --- a/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
> +++ b/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
> @@ -83,10 +83,6 @@
> };
> };
>
> -&uart0 {
> - status = "okay";
> -};
> -
> &usb3 {
> vcc-gpio = <&chipcommon 0 GPIO_ACTIVE_HIGH>;
> };
> diff --git a/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
> b/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
> index 70f4bb9..74cfcd3 100644
> --- a/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
> +++ b/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
> @@ -119,10 +119,6 @@
> };
> };
>
> -&uart0 {
> - status = "okay";
> -};
> -
> &spi_nor {
> status = "okay";
> };
> diff --git a/arch/arm/boot/dts/bcm4708.dtsi b/arch/arm/boot/dts/bcm4708.
> dtsi
> index eed4dd1..d0eec09 100644
> --- a/arch/arm/boot/dts/bcm4708.dtsi
> +++ b/arch/arm/boot/dts/bcm4708.dtsi
> @@ -34,3 +34,7 @@
> };
>
> };
> +
> +&uart0 {
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
> b/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
> index a9c8def..2922536 100644
> --- a/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
> +++ b/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
> @@ -122,7 +122,3 @@
> };
> };
> };
> -
> -&uart0 {
> - status = "okay";
> -};
> diff --git a/arch/arm/boot/dts/bcm47081.dtsi b/arch/arm/boot/dts/bcm47081.
> dtsi
> index f720012..c5f7619 100644
> --- a/arch/arm/boot/dts/bcm47081.dtsi
> +++ b/arch/arm/boot/dts/bcm47081.dtsi
> @@ -24,3 +24,7 @@
> };
> };
> };
> +
> +&uart0 {
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
> b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
> index fd38d2a..0225d82 100644
> --- a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
> +++ b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
> @@ -100,7 +100,3 @@
> };
> };
> };
> -
> -&uart0 {
> - status = "okay";
> -};
> diff --git a/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
> b/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
> index 92f8a72..56d38a3 100644
> --- a/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
> +++ b/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
> @@ -107,10 +107,6 @@
> };
> };
>
> -&uart0 {
> - status = "okay";
> -};
> -
> &usb2 {
> vcc-gpio = <&chipcommon 0 GPIO_ACTIVE_HIGH>;
> };
> diff --git a/arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts
> b/arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts
> index 9a92c24..c67bfaa 100644
> --- a/arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts
> +++ b/arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts
> @@ -97,10 +97,6 @@
> };
> };
>
> -&uart0 {
> - status = "okay";
> -};
> -
> &usb2 {
> vcc-gpio = <&chipcommon 13 GPIO_ACTIVE_HIGH>;
> };
> diff --git a/arch/arm/boot/dts/bcm4709.dtsi b/arch/arm/boot/dts/bcm4709.
> dtsi
> index f039765..c645fea 100644
> --- a/arch/arm/boot/dts/bcm4709.dtsi
> +++ b/arch/arm/boot/dts/bcm4709.dtsi
> @@ -8,4 +8,5 @@
>
> &uart0 {
> clock-frequency = <125000000>;
> + status = "okay";
> };
> diff --git a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
> b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
> index 661348d..7fb9270 100644
> --- a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
> +++ b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
> @@ -105,10 +105,6 @@
> };
> };
>
> -&uart0 {
> - status = "okay";
> -};
> -
> &usb3 {
> vcc-gpio = <&chipcommon 18 GPIO_ACTIVE_HIGH>;
> };
> diff --git a/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
> b/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
> index 169b35f..2f4a651 100644
> --- a/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
> +++ b/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
> @@ -98,10 +98,6 @@
> };
> };
>
> -&uart0 {
> - status = "okay";
> -};
> -
> &usb3 {
> vcc-gpio = <&chipcommon 18 GPIO_ACTIVE_HIGH>;
> };
> diff --git a/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
> b/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
> index 521b415..7ecd57c 100644
> --- a/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
> +++ b/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
> @@ -97,7 +97,3 @@
> };
> };
> };
> -
> -&uart0 {
> - status = "okay";
> -};
> diff --git a/arch/arm/boot/dts/bcm47094.dtsi b/arch/arm/boot/dts/bcm47094.
> dtsi
> index 4f09aa0..4840a78 100644
> --- a/arch/arm/boot/dts/bcm47094.dtsi
> +++ b/arch/arm/boot/dts/bcm47094.dtsi
> @@ -14,4 +14,5 @@
>
> &uart0 {
> clock-frequency = <125000000>;
> + status = "okay";
> };
> --
> 2.10.1
>
>
[-- Attachment #2: Type: text/html, Size: 11705 bytes --]
^ permalink raw reply
* Re: [PATCH] ARM: BCM5301X: Enable UART by default for BCM4708(1) and BCM4709(4)
From: Rafał Miłecki @ 2016-12-01 17:23 UTC (permalink / raw)
To: Jon Mason
Cc: Florian Fainelli, Rob Herring, Mark Rutland, Russell King,
Hauke Mehrtens, BCM Kernel Feedback,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-arm-kernel, open list, Rafał Miłecki
In-Reply-To: <CAC3K-4o3-eSDU5JvjkgohtWLUmZqQViHvX1h2zfdPAGe+qbCOg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 1 December 2016 at 18:14, Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> On Mon, Nov 28, 2016 at 9:01 AM, Rafał Miłecki <zajec5-Re5JQEeQqe8@public.gmane.orgm> wrote:
>>
>> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>>
>> Every device tested so far got UART0 (at 0x18000300) working as serial
>> console. It's most likely part of reference design and all vendors use
>> it that way.
>>
>> It seems to be easier to enable it by default and just disable it if we
>> ever see a device with different hardware design.
>>
>> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>> ---
>> arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts | 4 ----
>> arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts | 4 ----
>> arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts | 4 ----
>> arch/arm/boot/dts/bcm4708-netgear-r6250.dts | 4 ----
>> arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts | 4 ----
>> arch/arm/boot/dts/bcm4708.dtsi | 4 ++++
>> arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts | 4 ----
>> arch/arm/boot/dts/bcm47081.dtsi | 4 ++++
>> arch/arm/boot/dts/bcm4709-netgear-r7000.dts | 4 ----
>> arch/arm/boot/dts/bcm4709-netgear-r8000.dts | 4 ----
>> arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts | 4 ----
>> arch/arm/boot/dts/bcm4709.dtsi | 1 +
>> arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts | 4 ----
>> arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts | 4 ----
>> arch/arm/boot/dts/bcm47094-netgear-r8500.dts | 4 ----
>> arch/arm/boot/dts/bcm47094.dtsi | 1 +
>
>
> I think there are a few missing here. A quick grep shows
>
> $ grep -rI '#include "bcm470[89].dtsi"' arch/arm/boot/dts/*.dts
> arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts:#include "bcm4708.dtsi"
> arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts:#include "bcm4708.dtsi"
> arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts:#include "bcm4708.dtsi"
> arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts:#include "bcm4708.dtsi"
> arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts:#include "bcm4708.dtsi"
> arch/arm/boot/dts/bcm4708-netgear-r6250.dts:#include "bcm4708.dtsi"
> arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts:#include "bcm4708.dtsi"
> arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts:#include "bcm4708.dtsi"
> arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts:#include "bcm4709.dtsi"
> arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts:#include "bcm4709.dtsi"
> arch/arm/boot/dts/bcm4709-netgear-r7000.dts:#include "bcm4709.dtsi"
> arch/arm/boot/dts/bcm4709-netgear-r8000.dts:#include "bcm4709.dtsi"
> arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts:#include "bcm4709.dtsi"
> arch/arm/boot/dts/bcm94708.dts:#include "bcm4708.dtsi"
> arch/arm/boot/dts/bcm94709.dts:#include "bcm4708.dtsi"
> arch/arm/boot/dts/bcm953012er.dts:#include "bcm4708.dtsi"
> arch/arm/boot/dts/bcm953012k.dts:#include "bcm4708.dtsi"
>
> I specifically care about the last 4 :)
Actually the only missing ones are the last 4. Other ones (e.g.
bcm4709-buffalo-wxr-1900dhp.dts) never got uart0 enabled so I just
didn't need to modify these files.
I'll send V2 updating last 4 ones as well. Thanks for catching this.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 1/2] devicetree: i2c-hid: Add Wacom digitizer + regulator support
From: Brian Norris @ 2016-12-01 17:24 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Jiri Kosina, Caesar Wang, linux-rockchip, Rob Herring,
linux-input, devicetree, linux-kernel, Dmitry Torokhov,
Mark Rutland, Doug Anderson
In-Reply-To: <20161201143434.GD1280@mail.corp.redhat.com>
Hi Benjamin and Rob,
On Thu, Dec 01, 2016 at 03:34:34PM +0100, Benjamin Tissoires wrote:
> On Nov 30 2016 or thereabouts, Brian Norris wrote:
> > From: Caesar Wang <wxt@rock-chips.com>
> >
> > Add a compatible string and regulator property for Wacom W9103
> > digitizer. Its VDD supply may need to be enabled before using it.
> >
> > Signed-off-by: Caesar Wang <wxt@rock-chips.com>
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Jiri Kosina <jikos@kernel.org>
> > Cc: linux-input@vger.kernel.org
> > Signed-off-by: Brian Norris <briannorris@chromium.org>
> > ---
> > v1 was a few months back. I finally got around to rewriting it based on
> > DT binding feedback.
> >
> > v2:
> > * add compatible property for wacom
> > * name the regulator property specifically (VDD)
> >
> > Documentation/devicetree/bindings/input/hid-over-i2c.txt | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/input/hid-over-i2c.txt b/Documentation/devicetree/bindings/input/hid-over-i2c.txt
> > index 488edcb264c4..eb98054e60c9 100644
> > --- a/Documentation/devicetree/bindings/input/hid-over-i2c.txt
> > +++ b/Documentation/devicetree/bindings/input/hid-over-i2c.txt
> > @@ -11,12 +11,16 @@ If this binding is used, the kernel module i2c-hid will handle the communication
> > with the device and the generic hid core layer will handle the protocol.
> >
> > Required properties:
> > -- compatible: must be "hid-over-i2c"
> > +- compatible: must be "hid-over-i2c", or a device-specific string like:
> > + * "wacom,w9013"
>
> NACK on this one.
>
> After re-reading the v1 submission I realized Rob asked for this change,
> but I strongly disagree.
>
> HID over I2C is a generic protocol, in the same way HID over USB is. We
> can not start adding device specifics here, this is opening the can of
> worms. If the device is a HID one, nothing else should matter. The rest
> (description of the device, name, etc...) is all provided by the
> protocol.
I should have spoken up when Rob made the suggestion, because I more or
less agree with Benjamin here. I don't really see why this needs to have
a specialized compatible string, as the property is still fairly
generic, and the entire device handling is via a generic protocol. The
fact that we manage its power via a regulator is not very
device-specific.
> > - reg: i2c slave address
> > - hid-descr-addr: HID descriptor address
> > - interrupt-parent: the phandle for the interrupt controller
> > - interrupts: interrupt line
> >
> > +Optional properties:
> > +- vdd-supply: phandle of the regulator that provides the supply voltage.
>
> Agree on this one however.
Thanks.
As Benjamin noticed on patch 2, I added a delay property; I realized I
had been hacking that delay in to the regulator framework as a "ramp
delay" property, when in fact it was actually a property of *this*
device -- the 100 ms wait is a suggested wait for the HID firmware to
boot, not for the regulator to stabilize.
So, what do you two think about the following two properties?
- vdd-supply, as in the quoted patch
- init-delay-ms: time required by the device after power-on before it
is ready for communication
And I'd drop the extra compatible property.
Brian
^ permalink raw reply
* Re: [PATCH v2 2/2] HID: i2c-hid: support Wacom digitizer + regulator
From: Brian Norris @ 2016-12-01 17:30 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Jiri Kosina, Caesar Wang,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
linux-input-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Dmitry Torokhov,
Mark Rutland, Doug Anderson
In-Reply-To: <20161201144126.GE1280-/m+UfqrgI5QNLKR9yMNcA1aTQe2KTcn/@public.gmane.org>
Hi,
On Thu, Dec 01, 2016 at 03:41:26PM +0100, Benjamin Tissoires wrote:
> On Nov 30 2016 or thereabouts, Brian Norris wrote:
> > We need to power on the digitizer before using it, and it's also nice to
> > save power in suspend by disabling it. Support an optional "vdd-supply"
> > and wire it up for the new Wacom device.
> >
> > Wacom recommended waiting up to 100ms after powering on before trying to
> > access this device.
> >
> > Signed-off-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> > Signed-off-by: Caesar Wang <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> > Cc: Jiri Kosina <jikos-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > Cc: linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > ---
> > v1 was a few months back. I finally got around to rewriting it based on
> > DT binding feedback.
> >
> > v2:
> > * support compatible property for wacom, with specific "vdd-supply" name
> > * support the 100ms delay needed for this digitizer
> > * target regulator support only at specific device
> >
> > Documentation/devicetree/bindings/input/hid-over-i2c.txt | 6 +++++-
> > drivers/hid/i2c-hid/i2c-hid.c | 70 ++++++++++++++++++++++++++++++++++++++++++-
> > include/linux/i2c/i2c-hid.h | 6 ++++
> > 2 files changed, 75 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
> > index b3ec4f2de875..1bc174f3a788 100644
> > --- a/drivers/hid/i2c-hid/i2c-hid.c
> > +++ b/drivers/hid/i2c-hid/i2c-hid.c
> > @@ -37,7 +37,9 @@
> > #include <linux/mutex.h>
> > #include <linux/acpi.h>
> > #include <linux/of.h>
> > +#include <linux/of_device.h>
> > #include <linux/gpio/consumer.h>
> > +#include <linux/regulator/consumer.h>
> >
> > #include <linux/i2c/i2c-hid.h>
> >
> > @@ -918,10 +920,25 @@ static inline int i2c_hid_acpi_pdata(struct i2c_client *client,
> > #endif
> >
> > #ifdef CONFIG_OF
> > +
> > +/* of_device_id match data */
> > +struct i2c_hid_of_data {
> > + /* Name of supply regulator. */
> > + const char *supply_name;
> > + /* Delay required after powering on device before it is usable. */
> > + int init_delay_ms;
> > +};
> > +
> > +static const struct i2c_hid_of_data wacom_w9013_data = {
>
> Why is the struct "wacom" specific?
> If the vdd line is required, I don't see why there is a need to specify
> that this is a Wacom specifics. Then Elan, SYnaptics will want the same
> and we won't be able to to follow.
>
> > + .supply_name = "vdd",
> > + .init_delay_ms = 100,
>
> If the purpose of this declaration is to set the delay, why isn't this
> something provided by the device tree?
The alleged purpose wasn't just for the delay (it wasn't even mentioned
in v1), but in case there are ever devices with multiple regulators and
different power sequencing (?) I guess. I still don't see why Rob
thought it needed a separate compatible property.
About the delay: as noted in my reply to patch 1, this was actually a
property of the device/firmware -- it needs some time to initialize
before we can talk to it. I previously had included that delay in the
regulator ramp delay, but since we'd know the device info here, I found
it convenient to latch onto the same property.
IOW, typically, if you have a device-specific compatible property, it
makes sense to key device-specific info off of that property where
possible. But if (like you suggest) the compatible property is
counter-productive, then we would need a separate property for this
delay.
> > +};
> > +
> > static int i2c_hid_of_probe(struct i2c_client *client,
> > struct i2c_hid_platform_data *pdata)
> > {
> > struct device *dev = &client->dev;
> > + const struct i2c_hid_of_data *data = of_device_get_match_data(dev);
> > u32 val;
> > int ret;
> >
> > @@ -937,10 +954,33 @@ static int i2c_hid_of_probe(struct i2c_client *client,
> > }
> > pdata->hid_descriptor_address = val;
> >
> > + if (data) {
> > + pdata->init_delay_ms = data->init_delay_ms;
> > + if (data->supply_name) {
> > + pdata->supply = devm_regulator_get_optional(&client->dev,
> > + data->supply_name);
> > + if (IS_ERR(pdata->supply)) {
> > + ret = PTR_ERR(pdata->supply);
> > + pdata->supply = NULL;
> > + if (ret == -EPROBE_DEFER)
> > + return ret;
> > + if (ret == -ENODEV)
> > + return 0;
> > + dev_err(dev, "Failed to get %s regulator: %d\n",
> > + data->supply_name, ret);
> > + return ret;
> > + }
> > + }
> > + }
> > +
> > return 0;
> > }
> >
> > static const struct of_device_id i2c_hid_of_match[] = {
> > + {
> > + .compatible = "wacom,w9013",
> > + .data = &wacom_w9013_data,
> > + },
>
> NACK, see 1/2
Fine with me, if Rob is OK. I replid on 1/2.
> I don't really like the v2. IMO, v1 was less intrusive (though it was
> missing the init_delay_ms).
> I believe it's possible to have a generic device tree description which
> doesn't require us to adapt the driver for each and every device.
Brian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH dt V2] ARM: BCM5301X: Enable UART by default for BCM4708(1), BCM4709(4) & BCM53012
From: Rafał Miłecki @ 2016-12-01 17:40 UTC (permalink / raw)
To: Florian Fainelli
Cc: Rob Herring, Mark Rutland, Russell King, Hauke Mehrtens,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
In-Reply-To: <20161128140134.25128-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
Every device tested so far got UART0 (at 0x18000300) working as serial
console. It's most likely part of reference design and all vendors use
it that way.
It seems to be easier to enable it by default and just disable it if we
ever see a device with different hardware design.
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
V2: Update bcm94708.dts bcm94709.dts bcm953012er.dts & bcm953012k.dts
---
arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts | 4 ----
arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts | 4 ----
arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts | 4 ----
arch/arm/boot/dts/bcm4708-netgear-r6250.dts | 4 ----
arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts | 4 ----
arch/arm/boot/dts/bcm4708.dtsi | 4 ++++
arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts | 4 ----
arch/arm/boot/dts/bcm47081.dtsi | 4 ++++
arch/arm/boot/dts/bcm4709-netgear-r7000.dts | 4 ----
arch/arm/boot/dts/bcm4709-netgear-r8000.dts | 4 ----
arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts | 4 ----
arch/arm/boot/dts/bcm4709.dtsi | 1 +
arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts | 4 ----
arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts | 4 ----
arch/arm/boot/dts/bcm47094-netgear-r8500.dts | 4 ----
arch/arm/boot/dts/bcm47094.dtsi | 1 +
arch/arm/boot/dts/bcm94708.dts | 4 ----
arch/arm/boot/dts/bcm94709.dts | 4 ----
arch/arm/boot/dts/bcm953012er.dts | 4 ----
arch/arm/boot/dts/bcm953012k.dts | 1 -
20 files changed, 10 insertions(+), 61 deletions(-)
diff --git a/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts b/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
index 9cb186e..d49afec0 100644
--- a/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
+++ b/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
@@ -136,10 +136,6 @@
};
};
-&uart0 {
- status = "okay";
-};
-
&usb2 {
vcc-gpio = <&chipcommon 9 GPIO_ACTIVE_HIGH>;
};
diff --git a/arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts b/arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts
index 35e6ed6..f591b0f 100644
--- a/arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts
+++ b/arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts
@@ -55,10 +55,6 @@
};
};
-&uart0 {
- status = "okay";
-};
-
&spi_nor {
status = "okay";
};
diff --git a/arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts b/arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts
index 1c7e53d..50d65d8 100644
--- a/arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts
+++ b/arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts
@@ -56,10 +56,6 @@
};
};
-&uart0 {
- status = "okay";
-};
-
&spi_nor {
status = "okay";
};
diff --git a/arch/arm/boot/dts/bcm4708-netgear-r6250.dts b/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
index 8ce39d5..8519548 100644
--- a/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
+++ b/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
@@ -83,10 +83,6 @@
};
};
-&uart0 {
- status = "okay";
-};
-
&usb3 {
vcc-gpio = <&chipcommon 0 GPIO_ACTIVE_HIGH>;
};
diff --git a/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts b/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
index 70f4bb9..74cfcd3 100644
--- a/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
+++ b/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
@@ -119,10 +119,6 @@
};
};
-&uart0 {
- status = "okay";
-};
-
&spi_nor {
status = "okay";
};
diff --git a/arch/arm/boot/dts/bcm4708.dtsi b/arch/arm/boot/dts/bcm4708.dtsi
index eed4dd1..d0eec09 100644
--- a/arch/arm/boot/dts/bcm4708.dtsi
+++ b/arch/arm/boot/dts/bcm4708.dtsi
@@ -34,3 +34,7 @@
};
};
+
+&uart0 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts b/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
index a9c8def..2922536 100644
--- a/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
+++ b/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
@@ -122,7 +122,3 @@
};
};
};
-
-&uart0 {
- status = "okay";
-};
diff --git a/arch/arm/boot/dts/bcm47081.dtsi b/arch/arm/boot/dts/bcm47081.dtsi
index f720012..c5f7619 100644
--- a/arch/arm/boot/dts/bcm47081.dtsi
+++ b/arch/arm/boot/dts/bcm47081.dtsi
@@ -24,3 +24,7 @@
};
};
};
+
+&uart0 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
index fd38d2a..0225d82 100644
--- a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
+++ b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
@@ -100,7 +100,3 @@
};
};
};
-
-&uart0 {
- status = "okay";
-};
diff --git a/arch/arm/boot/dts/bcm4709-netgear-r8000.dts b/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
index 92f8a72..56d38a3 100644
--- a/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
+++ b/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
@@ -107,10 +107,6 @@
};
};
-&uart0 {
- status = "okay";
-};
-
&usb2 {
vcc-gpio = <&chipcommon 0 GPIO_ACTIVE_HIGH>;
};
diff --git a/arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts b/arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts
index 9a92c24..c67bfaa 100644
--- a/arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts
+++ b/arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts
@@ -97,10 +97,6 @@
};
};
-&uart0 {
- status = "okay";
-};
-
&usb2 {
vcc-gpio = <&chipcommon 13 GPIO_ACTIVE_HIGH>;
};
diff --git a/arch/arm/boot/dts/bcm4709.dtsi b/arch/arm/boot/dts/bcm4709.dtsi
index f039765..c645fea 100644
--- a/arch/arm/boot/dts/bcm4709.dtsi
+++ b/arch/arm/boot/dts/bcm4709.dtsi
@@ -8,4 +8,5 @@
&uart0 {
clock-frequency = <125000000>;
+ status = "okay";
};
diff --git a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
index 661348d..7fb9270 100644
--- a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
+++ b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
@@ -105,10 +105,6 @@
};
};
-&uart0 {
- status = "okay";
-};
-
&usb3 {
vcc-gpio = <&chipcommon 18 GPIO_ACTIVE_HIGH>;
};
diff --git a/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts b/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
index 169b35f..2f4a651 100644
--- a/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
+++ b/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
@@ -98,10 +98,6 @@
};
};
-&uart0 {
- status = "okay";
-};
-
&usb3 {
vcc-gpio = <&chipcommon 18 GPIO_ACTIVE_HIGH>;
};
diff --git a/arch/arm/boot/dts/bcm47094-netgear-r8500.dts b/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
index 521b415..7ecd57c 100644
--- a/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
+++ b/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
@@ -97,7 +97,3 @@
};
};
};
-
-&uart0 {
- status = "okay";
-};
diff --git a/arch/arm/boot/dts/bcm47094.dtsi b/arch/arm/boot/dts/bcm47094.dtsi
index 4f09aa0..4840a78 100644
--- a/arch/arm/boot/dts/bcm47094.dtsi
+++ b/arch/arm/boot/dts/bcm47094.dtsi
@@ -14,4 +14,5 @@
&uart0 {
clock-frequency = <125000000>;
+ status = "okay";
};
diff --git a/arch/arm/boot/dts/bcm94708.dts b/arch/arm/boot/dts/bcm94708.dts
index 251a486..42855a7 100644
--- a/arch/arm/boot/dts/bcm94708.dts
+++ b/arch/arm/boot/dts/bcm94708.dts
@@ -50,7 +50,3 @@
reg = <0x00000000 0x08000000>;
};
};
-
-&uart0 {
- status = "okay";
-};
diff --git a/arch/arm/boot/dts/bcm94709.dts b/arch/arm/boot/dts/bcm94709.dts
index b16cac9..95e8be6 100644
--- a/arch/arm/boot/dts/bcm94709.dts
+++ b/arch/arm/boot/dts/bcm94709.dts
@@ -50,7 +50,3 @@
reg = <0x00000000 0x08000000>;
};
};
-
-&uart0 {
- status = "okay";
-};
diff --git a/arch/arm/boot/dts/bcm953012er.dts b/arch/arm/boot/dts/bcm953012er.dts
index 0a9abec..decd86b 100644
--- a/arch/arm/boot/dts/bcm953012er.dts
+++ b/arch/arm/boot/dts/bcm953012er.dts
@@ -70,10 +70,6 @@
};
};
-&uart0 {
- status = "okay";
-};
-
&spi_nor {
status = "okay";
};
diff --git a/arch/arm/boot/dts/bcm953012k.dts b/arch/arm/boot/dts/bcm953012k.dts
index 05a985a..bfd9230 100644
--- a/arch/arm/boot/dts/bcm953012k.dts
+++ b/arch/arm/boot/dts/bcm953012k.dts
@@ -54,7 +54,6 @@
&uart0 {
clock-frequency = <62499840>;
- status = "okay";
};
&uart1 {
--
2.10.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v4 2/3] doc: dt: add cyclone-spi binding document
From: Moritz Fischer @ 2016-12-01 17:41 UTC (permalink / raw)
To: Joshua Clayton
Cc: Alan Tull, Rob Herring, Mark Rutland, Russell King,
Devicetree List, Linux Kernel Mailing List, linux-arm-kernel
In-Reply-To: <137f03de76e5f865430b17ca247e8f73e3315c8d.1480551148.git.stillcompiling-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, Dec 1, 2016 at 9:04 AM, Joshua Clayton <stillcompiling-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Describe a cyclonei-ps-spi devicetree entry, required features
>
> Signed-off-by: Joshua Clayton <stillcompiling-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Acked-by: Moritz Fischer <moritz.fischer-+aYTwkv1SeIAvxtiuMwx3w@public.gmane.org>
> ---
>
> .../bindings/fpga/cyclone-ps-spi-fpga-mgr.txt | 25 ++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/fpga/cyclone-ps-spi-fpga-mgr.txt
>
> diff --git a/Documentation/devicetree/bindings/fpga/cyclone-ps-spi-fpga-mgr.txt b/Documentation/devicetree/bindings/fpga/cyclone-ps-spi-fpga-mgr.txt
> new file mode 100644
> index 0000000..3f515c7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fpga/cyclone-ps-spi-fpga-mgr.txt
> @@ -0,0 +1,25 @@
> +Altera Cyclone Passive Serial SPI FPGA Manager
> +
> +Altera Cyclone FPGAs support a method of loading the bitstream over what is
> +referred to as "passive serial".
> +The passive serial link is not technically spi, and might require extra
> +circuits in order to play nicely with other spi slaves on the same bus.
> +
> +See https://www.altera.com/literature/hb/cyc/cyc_c51013.pdf
> +
> +Required properties:
> +- compatible : should contain "altr,cyclone-ps-spi-fpga-mgr"
> +- reg : spi slave id of the fpga
> +- config-gpios : config pin (referred to as nCONFIG in the cyclone manual)
> +- status-gpios : status pin (referred to as nSTATUS in the cyclone manual)
> +
> +both gpio pins are normally active low open drain.
> +
> +Example:
> + fpga_spi: evi-fpga-spi@0 {
> + compatible = "altr,cyclone-ps-spi-fpga-mgr";
> + spi-max-frequency = <20000000>;
> + reg = <0>;
> + config-gpios = <&gpio4 9 GPIO_ACTIVE_LOW>;
> + status-gpios = <&gpio4 11 GPIO_ACTIVE_LOW>;
> + };
> --
> 2.9.3
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH dt V2] ARM: BCM5301X: Enable UART by default for BCM4708(1), BCM4709(4) & BCM53012
From: Jon Mason @ 2016-12-01 18:59 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Florian Fainelli, Rob Herring, Mark Rutland, Russell King,
Hauke Mehrtens, bcm-kernel-feedback-list, devicetree,
linux-arm-kernel, linux-kernel, Rafał Miłecki
In-Reply-To: <20161201174051.4965-1-zajec5@gmail.com>
On Thu, Dec 01, 2016 at 06:40:51PM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> Every device tested so far got UART0 (at 0x18000300) working as serial
> console. It's most likely part of reference design and all vendors use
> it that way.
>
> It seems to be easier to enable it by default and just disable it if we
> ever see a device with different hardware design.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Looks good to me!
Acked-by: Jon Mason <jon.mason@broadcom.com>
> ---
> V2: Update bcm94708.dts bcm94709.dts bcm953012er.dts & bcm953012k.dts
> ---
> arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts | 4 ----
> arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts | 4 ----
> arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts | 4 ----
> arch/arm/boot/dts/bcm4708-netgear-r6250.dts | 4 ----
> arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts | 4 ----
> arch/arm/boot/dts/bcm4708.dtsi | 4 ++++
> arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts | 4 ----
> arch/arm/boot/dts/bcm47081.dtsi | 4 ++++
> arch/arm/boot/dts/bcm4709-netgear-r7000.dts | 4 ----
> arch/arm/boot/dts/bcm4709-netgear-r8000.dts | 4 ----
> arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts | 4 ----
> arch/arm/boot/dts/bcm4709.dtsi | 1 +
> arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts | 4 ----
> arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts | 4 ----
> arch/arm/boot/dts/bcm47094-netgear-r8500.dts | 4 ----
> arch/arm/boot/dts/bcm47094.dtsi | 1 +
> arch/arm/boot/dts/bcm94708.dts | 4 ----
> arch/arm/boot/dts/bcm94709.dts | 4 ----
> arch/arm/boot/dts/bcm953012er.dts | 4 ----
> arch/arm/boot/dts/bcm953012k.dts | 1 -
> 20 files changed, 10 insertions(+), 61 deletions(-)
>
> diff --git a/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts b/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
> index 9cb186e..d49afec0 100644
> --- a/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
> +++ b/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
> @@ -136,10 +136,6 @@
> };
> };
>
> -&uart0 {
> - status = "okay";
> -};
> -
> &usb2 {
> vcc-gpio = <&chipcommon 9 GPIO_ACTIVE_HIGH>;
> };
> diff --git a/arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts b/arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts
> index 35e6ed6..f591b0f 100644
> --- a/arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts
> +++ b/arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts
> @@ -55,10 +55,6 @@
> };
> };
>
> -&uart0 {
> - status = "okay";
> -};
> -
> &spi_nor {
> status = "okay";
> };
> diff --git a/arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts b/arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts
> index 1c7e53d..50d65d8 100644
> --- a/arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts
> +++ b/arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts
> @@ -56,10 +56,6 @@
> };
> };
>
> -&uart0 {
> - status = "okay";
> -};
> -
> &spi_nor {
> status = "okay";
> };
> diff --git a/arch/arm/boot/dts/bcm4708-netgear-r6250.dts b/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
> index 8ce39d5..8519548 100644
> --- a/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
> +++ b/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
> @@ -83,10 +83,6 @@
> };
> };
>
> -&uart0 {
> - status = "okay";
> -};
> -
> &usb3 {
> vcc-gpio = <&chipcommon 0 GPIO_ACTIVE_HIGH>;
> };
> diff --git a/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts b/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
> index 70f4bb9..74cfcd3 100644
> --- a/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
> +++ b/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
> @@ -119,10 +119,6 @@
> };
> };
>
> -&uart0 {
> - status = "okay";
> -};
> -
> &spi_nor {
> status = "okay";
> };
> diff --git a/arch/arm/boot/dts/bcm4708.dtsi b/arch/arm/boot/dts/bcm4708.dtsi
> index eed4dd1..d0eec09 100644
> --- a/arch/arm/boot/dts/bcm4708.dtsi
> +++ b/arch/arm/boot/dts/bcm4708.dtsi
> @@ -34,3 +34,7 @@
> };
>
> };
> +
> +&uart0 {
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts b/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
> index a9c8def..2922536 100644
> --- a/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
> +++ b/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
> @@ -122,7 +122,3 @@
> };
> };
> };
> -
> -&uart0 {
> - status = "okay";
> -};
> diff --git a/arch/arm/boot/dts/bcm47081.dtsi b/arch/arm/boot/dts/bcm47081.dtsi
> index f720012..c5f7619 100644
> --- a/arch/arm/boot/dts/bcm47081.dtsi
> +++ b/arch/arm/boot/dts/bcm47081.dtsi
> @@ -24,3 +24,7 @@
> };
> };
> };
> +
> +&uart0 {
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
> index fd38d2a..0225d82 100644
> --- a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
> +++ b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
> @@ -100,7 +100,3 @@
> };
> };
> };
> -
> -&uart0 {
> - status = "okay";
> -};
> diff --git a/arch/arm/boot/dts/bcm4709-netgear-r8000.dts b/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
> index 92f8a72..56d38a3 100644
> --- a/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
> +++ b/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
> @@ -107,10 +107,6 @@
> };
> };
>
> -&uart0 {
> - status = "okay";
> -};
> -
> &usb2 {
> vcc-gpio = <&chipcommon 0 GPIO_ACTIVE_HIGH>;
> };
> diff --git a/arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts b/arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts
> index 9a92c24..c67bfaa 100644
> --- a/arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts
> +++ b/arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts
> @@ -97,10 +97,6 @@
> };
> };
>
> -&uart0 {
> - status = "okay";
> -};
> -
> &usb2 {
> vcc-gpio = <&chipcommon 13 GPIO_ACTIVE_HIGH>;
> };
> diff --git a/arch/arm/boot/dts/bcm4709.dtsi b/arch/arm/boot/dts/bcm4709.dtsi
> index f039765..c645fea 100644
> --- a/arch/arm/boot/dts/bcm4709.dtsi
> +++ b/arch/arm/boot/dts/bcm4709.dtsi
> @@ -8,4 +8,5 @@
>
> &uart0 {
> clock-frequency = <125000000>;
> + status = "okay";
> };
> diff --git a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
> index 661348d..7fb9270 100644
> --- a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
> +++ b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
> @@ -105,10 +105,6 @@
> };
> };
>
> -&uart0 {
> - status = "okay";
> -};
> -
> &usb3 {
> vcc-gpio = <&chipcommon 18 GPIO_ACTIVE_HIGH>;
> };
> diff --git a/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts b/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
> index 169b35f..2f4a651 100644
> --- a/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
> +++ b/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
> @@ -98,10 +98,6 @@
> };
> };
>
> -&uart0 {
> - status = "okay";
> -};
> -
> &usb3 {
> vcc-gpio = <&chipcommon 18 GPIO_ACTIVE_HIGH>;
> };
> diff --git a/arch/arm/boot/dts/bcm47094-netgear-r8500.dts b/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
> index 521b415..7ecd57c 100644
> --- a/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
> +++ b/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
> @@ -97,7 +97,3 @@
> };
> };
> };
> -
> -&uart0 {
> - status = "okay";
> -};
> diff --git a/arch/arm/boot/dts/bcm47094.dtsi b/arch/arm/boot/dts/bcm47094.dtsi
> index 4f09aa0..4840a78 100644
> --- a/arch/arm/boot/dts/bcm47094.dtsi
> +++ b/arch/arm/boot/dts/bcm47094.dtsi
> @@ -14,4 +14,5 @@
>
> &uart0 {
> clock-frequency = <125000000>;
> + status = "okay";
> };
> diff --git a/arch/arm/boot/dts/bcm94708.dts b/arch/arm/boot/dts/bcm94708.dts
> index 251a486..42855a7 100644
> --- a/arch/arm/boot/dts/bcm94708.dts
> +++ b/arch/arm/boot/dts/bcm94708.dts
> @@ -50,7 +50,3 @@
> reg = <0x00000000 0x08000000>;
> };
> };
> -
> -&uart0 {
> - status = "okay";
> -};
> diff --git a/arch/arm/boot/dts/bcm94709.dts b/arch/arm/boot/dts/bcm94709.dts
> index b16cac9..95e8be6 100644
> --- a/arch/arm/boot/dts/bcm94709.dts
> +++ b/arch/arm/boot/dts/bcm94709.dts
> @@ -50,7 +50,3 @@
> reg = <0x00000000 0x08000000>;
> };
> };
> -
> -&uart0 {
> - status = "okay";
> -};
> diff --git a/arch/arm/boot/dts/bcm953012er.dts b/arch/arm/boot/dts/bcm953012er.dts
> index 0a9abec..decd86b 100644
> --- a/arch/arm/boot/dts/bcm953012er.dts
> +++ b/arch/arm/boot/dts/bcm953012er.dts
> @@ -70,10 +70,6 @@
> };
> };
>
> -&uart0 {
> - status = "okay";
> -};
> -
> &spi_nor {
> status = "okay";
> };
> diff --git a/arch/arm/boot/dts/bcm953012k.dts b/arch/arm/boot/dts/bcm953012k.dts
> index 05a985a..bfd9230 100644
> --- a/arch/arm/boot/dts/bcm953012k.dts
> +++ b/arch/arm/boot/dts/bcm953012k.dts
> @@ -54,7 +54,6 @@
>
> &uart0 {
> clock-frequency = <62499840>;
> - status = "okay";
> };
>
> &uart1 {
> --
> 2.10.1
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox