* [PATCH 3/3] dts: arm64: add LS1046A DPAA QBMan nodes
From: Madalin Bucur @ 2017-03-30 14:37 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
Gang.Liu-3arQi8VN3Tc, Madalin Bucur, Roy Pledge
In-Reply-To: <1490884672-18294-1-git-send-email-madalin.bucur-3arQi8VN3Tc@public.gmane.org>
Add the QBMan device tree nodes for LS1046A devices.
Signed-off-by: Roy Pledge <roy.pledge-3arQi8VN3Tc@public.gmane.org>
Signed-off-by: Madalin Bucur <madalin.bucur-3arQi8VN3Tc@public.gmane.org>
---
arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 52 ++++++++++++++++++++++++++
1 file changed, 52 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 4a164b8..67e073a 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -268,6 +268,30 @@
};
};
+ qman: qman@1880000 {
+ compatible = "fsl,qman";
+ reg = <0x00 0x1880000 0x0 0x10000>;
+ interrupts = <0 45 0x4>;
+ memory-region = <&qman_fqd &qman_pfdr>;
+
+ };
+
+ bman: bman@1890000 {
+ compatible = "fsl,bman";
+ reg = <0x00 0x1890000 0x0 0x10000>;
+ interrupts = <0 45 0x4>;
+ memory-region = <&bman_fbpr>;
+
+ };
+
+ qportals: qman-portals@500000000 {
+ ranges = <0x0 0x5 0x00000000 0x8000000>;
+ };
+
+ bportals: bman-portals@508000000 {
+ ranges = <0x0 0x5 0x08000000 0x8000000>;
+ };
+
dcfg: dcfg@1ee0000 {
compatible = "fsl,ls1046a-dcfg", "syscon";
reg = <0x0 0x1ee0000 0x0 0x10000>;
@@ -592,4 +616,32 @@
clocks = <&clockgen 4 1>;
};
};
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ bman_fbpr: bman-fbpr {
+ compatible = "shared-dma-pool";
+ size = <0 0x1000000>;
+ alignment = <0 0x1000000>;
+ no-map;
+ };
+ qman_fqd: qman-fqd {
+ compatible = "shared-dma-pool";
+ size = <0 0x800000>;
+ alignment = <0 0x800000>;
+ no-map;
+ };
+ qman_pfdr: qman-pfdr {
+ compatible = "shared-dma-pool";
+ size = <0 0x2000000>;
+ alignment = <0 0x2000000>;
+ no-map;
+ };
+ };
};
+
+#include "qoriq-qman1-portals.dtsi"
+#include "qoriq-bman1-portals.dtsi"
--
2.1.0
--
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
* [PATCH 2/3] dts: arm64: add LS1043A DPAA QBMan nodes
From: Madalin Bucur @ 2017-03-30 14:37 UTC (permalink / raw)
To: robh+dt, mark.rutland, devicetree
Cc: linux-arm-kernel, linux-kernel, catalin.marinas, will.deacon,
shawnguo, Gang.Liu, Madalin Bucur, Roy Pledge
In-Reply-To: <1490884672-18294-1-git-send-email-madalin.bucur@nxp.com>
Add the DPAA 1.x QMan and BMan nodes in the LS1043A device tree.
Signed-off-by: Roy Pledge <roy.pledge@nxp.com>
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 52 ++++++++++++++++++++++++++
1 file changed, 52 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index ec13a6e..8434e89 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -106,6 +106,33 @@
/* DRAM space 1, size: 2GiB DRAM */
};
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ bman_fbpr: bman-fbpr {
+ compatible = "shared-dma-pool";
+ size = <0 0x1000000>;
+ alignment = <0 0x1000000>;
+ no-map;
+ };
+
+ qman_fqd: qman-fqd {
+ compatible = "shared-dma-pool";
+ size = <0 0x400000>;
+ alignment = <0 0x400000>;
+ no-map;
+ };
+
+ qman_pfdr: qman-pfdr {
+ compatible = "shared-dma-pool";
+ size = <0 0x2000000>;
+ alignment = <0 0x2000000>;
+ no-map;
+ };
+ };
+
sysclk: sysclk {
compatible = "fixed-clock";
#clock-cells = <0>;
@@ -333,6 +360,28 @@
};
};
+ qman: qman@1880000 {
+ compatible = "fsl,qman";
+ reg = <0x00 0x1880000 0x0 0x10000>;
+ interrupts = <0 45 0x4>;
+ memory-region = <&qman_fqd &qman_pfdr>;
+ };
+
+ bman: bman@1890000 {
+ compatible = "fsl,bman";
+ reg = <0x00 0x1890000 0x0 0x10000>;
+ interrupts = <0 45 0x4>;
+ memory-region = <&bman_fbpr>;
+ };
+
+ bportals: bman-portals@508000000 {
+ ranges = <0x0 0x5 0x08000000 0x8000000>;
+ };
+
+ qportals: qman-portals@500000000 {
+ ranges = <0x0 0x5 0x00000000 0x8000000>;
+ };
+
dspi0: dspi@2100000 {
compatible = "fsl,ls1043a-dspi", "fsl,ls1021a-v1.0-dspi";
#address-cells = <1>;
@@ -686,3 +735,6 @@
};
};
+
+#include "qoriq-qman1-portals.dtsi"
+#include "qoriq-bman1-portals.dtsi"
--
2.1.0
^ permalink raw reply related
* [PATCH 1/3] dts: arm64: add DPAA QBMan portals
From: Madalin Bucur @ 2017-03-30 14:37 UTC (permalink / raw)
To: robh+dt, mark.rutland, devicetree
Cc: linux-arm-kernel, linux-kernel, catalin.marinas, will.deacon,
shawnguo, Gang.Liu, Madalin Bucur, Roy Pledge
In-Reply-To: <1490884672-18294-1-git-send-email-madalin.bucur@nxp.com>
Add the DPAA 1.x DPAA QMan and BMan portal nodes.
Signed-off-by: Roy Pledge <roy.pledge@nxp.com>
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
---
.../boot/dts/freescale/qoriq-bman1-portals.dtsi | 67 +++++++++++++++++++
.../boot/dts/freescale/qoriq-qman1-portals.dtsi | 76 ++++++++++++++++++++++
2 files changed, 143 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/qoriq-bman1-portals.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/qoriq-qman1-portals.dtsi
diff --git a/arch/arm64/boot/dts/freescale/qoriq-bman1-portals.dtsi b/arch/arm64/boot/dts/freescale/qoriq-bman1-portals.dtsi
new file mode 100644
index 0000000..b007344
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/qoriq-bman1-portals.dtsi
@@ -0,0 +1,67 @@
+/*
+ * QorIQ BMan Portals device tree
+ *
+ * Copyright 2011-2016 Freescale Semiconductor Inc.
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+ */
+
+&bportals {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+
+ bman-portal@0 {
+ compatible = "fsl,bman-portal";
+ reg = <0x0 0x4000 0x4000000 0x4000>;
+ interrupts = <0 173 0x4>;
+ };
+
+ bman-portal@10000 {
+ compatible = "fsl,bman-portal";
+ reg = <0x10000 0x4000 0x4010000 0x4000>;
+ interrupts = <0 175 0x4>;
+ };
+
+ bman-portal@20000 {
+ compatible = "fsl,bman-portal";
+ reg = <0x20000 0x4000 0x4020000 0x4000>;
+ interrupts = <0 177 0x4>;
+ };
+
+ bman-portal@30000 {
+ compatible = "fsl,bman-portal";
+ reg = <0x30000 0x4000 0x4030000 0x4000>;
+ interrupts = <0 179 0x4>;
+ };
+
+ bman-portal@40000 {
+ compatible = "fsl,bman-portal";
+ reg = <0x40000 0x4000 0x4040000 0x4000>;
+ interrupts = <0 181 0x4>;
+ };
+
+ bman-portal@50000 {
+ compatible = "fsl,bman-portal";
+ reg = <0x50000 0x4000 0x4050000 0x4000>;
+ interrupts = <0 183 0x4>;
+ };
+
+ bman-portal@60000 {
+ compatible = "fsl,bman-portal";
+ reg = <0x60000 0x4000 0x4060000 0x4000>;
+ interrupts = <0 185 0x4>;
+ };
+
+ bman-portal@70000 {
+ compatible = "fsl,bman-portal";
+ reg = <0x70000 0x4000 0x4070000 0x4000>;
+ interrupts = <0 187 0x4>;
+ };
+
+ bman-portal@80000 {
+ compatible = "fsl,bman-portal";
+ reg = <0x80000 0x4000 0x4080000 0x4000>;
+ interrupts = <0 189 0x4>;
+ };
+};
diff --git a/arch/arm64/boot/dts/freescale/qoriq-qman1-portals.dtsi b/arch/arm64/boot/dts/freescale/qoriq-qman1-portals.dtsi
new file mode 100644
index 0000000..4baec2c
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/qoriq-qman1-portals.dtsi
@@ -0,0 +1,76 @@
+/*
+ * QorIQ QMan Portals device tree
+ *
+ * Copyright 2011-2016 Freescale Semiconductor Inc.
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+ */
+
+&qportals {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+
+ qportal0: qman-portal@0 {
+ compatible = "fsl,qman-portal";
+ reg = <0x0 0x4000 0x4000000 0x4000>;
+ interrupts = <0 172 0x4>;
+ cell-index = <0>;
+ };
+
+ qportal1: qman-portal@10000 {
+ compatible = "fsl,qman-portal";
+ reg = <0x10000 0x4000 0x4010000 0x4000>;
+ interrupts = <0 174 0x4>;
+ cell-index = <1>;
+ };
+
+ qportal2: qman-portal@20000 {
+ compatible = "fsl,qman-portal";
+ reg = <0x20000 0x4000 0x4020000 0x4000>;
+ interrupts = <0 176 0x4>;
+ cell-index = <2>;
+ };
+
+ qportal3: qman-portal@30000 {
+ compatible = "fsl,qman-portal";
+ reg = <0x30000 0x4000 0x4030000 0x4000>;
+ interrupts = <0 178 0x4>;
+ cell-index = <3>;
+ };
+
+ qportal4: qman-portal@40000 {
+ compatible = "fsl,qman-portal";
+ reg = <0x40000 0x4000 0x4040000 0x4000>;
+ interrupts = <0 180 0x4>;
+ cell-index = <4>;
+ };
+
+ qportal5: qman-portal@50000 {
+ compatible = "fsl,qman-portal";
+ reg = <0x50000 0x4000 0x4050000 0x4000>;
+ interrupts = <0 182 0x4>;
+ cell-index = <5>;
+ };
+
+ qportal6: qman-portal@60000 {
+ compatible = "fsl,qman-portal";
+ reg = <0x60000 0x4000 0x4060000 0x4000>;
+ interrupts = <0 184 0x4>;
+ cell-index = <6>;
+ };
+
+ qportal7: qman-portal@70000 {
+ compatible = "fsl,qman-portal";
+ reg = <0x70000 0x4000 0x4070000 0x4000>;
+ interrupts = <0 186 0x4>;
+ cell-index = <7>;
+ };
+
+ qportal8: qman-portal@80000 {
+ compatible = "fsl,qman-portal";
+ reg = <0x80000 0x4000 0x4080000 0x4000>;
+ interrupts = <0 188 0x4>;
+ cell-index = <8>;
+ };
+};
--
2.1.0
^ permalink raw reply related
* [PATCH 0/3] introduce QorIQ DPAA 1.x QBMan device tree nodes
From: Madalin Bucur @ 2017-03-30 14:37 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
Gang.Liu-3arQi8VN3Tc, Madalin Bucur
This patch set introduces the QorIQ Data Path Acceleration Arhitecture
(DPAA) Queue Manager and Buffer Manager device tree nodes for the ARM
based DPAA 1.x platforms.
Madalin Bucur (3):
dts: arm64: add DPAA QBMan portals
dts: arm64: add LS1043A DPAA QBMan nodes
dts: arm64: add LS1046A DPAA QBMan nodes
arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 52 +++++++++++++++
arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 52 +++++++++++++++
.../boot/dts/freescale/qoriq-bman1-portals.dtsi | 67 +++++++++++++++++++
.../boot/dts/freescale/qoriq-qman1-portals.dtsi | 76 ++++++++++++++++++++++
4 files changed, 247 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/qoriq-bman1-portals.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/qoriq-qman1-portals.dtsi
--
2.1.0
--
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: [GIT PULL] generic TEE subsystem for v4.12
From: Arnd Bergmann @ 2017-03-30 14:32 UTC (permalink / raw)
To: Jens Wiklander
Cc: arm-DgEjT+Ai2ygdnm+yROfE0A, Olof Johansson, Greg Kroah-Hartman,
Andrew Morton, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Al Viro,
jean-michel.delorme-qxv4g6HH51o, emmanuel.michel-qxv4g6HH51o,
javier-5MUHepqpBA1BDgjK7y7TUQ, Jason Gunthorpe, Mark Rutland,
Michal Simek, Rob Herring, Will Deacon, Nishanth Menon,
Andrew F. Davis, broonie-DgEjT+Ai2ygdnm+yROfE0A,
scott.branden-dY08KVG/lbpWk0Htik3J/w, Loic PALLARDY,
Etienne CARRIERE, Benjamin GAIGNARD
In-Reply-To: <20170314145305.GA12937@jax>
On Tuesday, March 14, 2017 3:57:34 PM CEST Jens Wiklander wrote:
> Hi arm-soc maintainers,
>
> Please consider this pull request for v4.12
>
> This pull request contains version 16 of the generic TEE driver.
>
> The TEE subsystem will contain drivers for various TEE implementations.
> A TEE (Trusted Execution Environment) is a trusted OS running in some
> secure environment, for example, TrustZone on ARM CPUs, or a separate
> secure co-processor etc.
>
> The patch set has been reviewed by different people during the different
> versions. Now I think this has reached a state where it's mature enough
> to merge.
>
> The v16 cover letter containing detailed revision history can be found at
> https://lkml.org/lkml/2017/3/10/1277
>
> Thanks,
> Jens
>
> The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
>
> Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
>
> are available in the git repository at:
>
> git://git.linaro.org:/people/jens.wiklander/linux-tee.git tags/tee-drv-for-4.12
>
> for you to fetch changes up to 14e21cb8f811100a2104e952b8f5bc0326a5e213:
>
> arm64: dt: hikey: Add optee node (2017-03-10 14:51:58 +0100)
>
> ----------------------------------------------------------------
> Introduce generic TEE subsystem:
> - the TEE subsystem itself
> - an OP-TEE driver using the subsystem
> - optee bindings
> - optee node for hi6220-hikey.dts
(+Linus, FYI)
I've put this into a separate next/tee branch in arm-soc,
which means we will send this separately to Linus in the next
merge window for the introduction of a new kernel subsystem,
and I expect that future updates will get handled through the
next/drivers branch in arm-soc, like we do for reset controllers.
I have reviewed earlier versions in the past, and have reviewed
the latest version in person during Linaro Connect BUD17.
Here is my overall assessment of the subsystem:
* There is clearly demand for this, both for the generic
infrastructure and the specific OP-TEE implementation.
* The code has gone through a large number of reviews,
and the review comments have all been addressed, but
the reviews were not coming up with serious issues any more
and nobody volunteered to vouch for the quality.
* The user space ioctl interface is sufficient to work with the
OP-TEE driver, and it should in principle work with other
TEE implementations that follow the GlobalPlatform[1] standards,
but it might need to be extended in minor ways depending on
specific requirements of future TEE implementations
* The main downside of the API to me is how the user space
is tied to the TEE implementation in hardware or firmware,
but uses a generic way to communicate with it. This seems
to be an inherent problem with what it is trying to do,
and I could not come up with any better solution than what
is implemented here.
Arnd
[1] https://www.globalplatform.org/mediaguidetee.asp
--
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] ARM: dts: am57xx-idk: Add DCAN support
From: Sekhar Nori @ 2017-03-30 14:23 UTC (permalink / raw)
To: Tony Lindgren
Cc: Mark Rutland, Device Tree Mailing List, Schuyler Patton,
Kishon Vijay Abraham I, Rob Herring, Franklin S Cooper Jr,
Linux OMAP Mailing List, Linux ARM Mailing List, Quadros, Roger
In-Reply-To: <20170306184113.GN20572@atomide.com>
Hi Tony,
On Tuesday 07 March 2017 12:11 AM, Tony Lindgren wrote:
> * Sekhar Nori <nsekhar@ti.com> [170221 02:13]:
>> On Tuesday 21 February 2017 03:30 PM, Sekhar Nori wrote:
>>> From: Schuyler Patton <spatton@ti.com>
>>>
>>> AM571x IDK and the AM572x IDK use CAN1 interface.
>>> This patch enables it for both boards.
>>>
>>> Tested on AM572x IDK using cansequence.
>>>
>>> Signed-off-by: Schuyler Patton <spatton@ti.com>
>>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>>> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
>>> [nsekhar@ti.com: move to use DRA7XX_CORE_IOPAD())
>>> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
>>
>> I should have noted that although CAN does function on the IDK with this
>> patch, there are "omap_hwmod: dcan1: _wait_target_disable failed"
>> messages that come up due to lack of workaround for errata i893[1]
>>
>> Roger does have some patches to workaround that errata. If you want to
>> wait for those patches to be submitted and accepted first, it should be
>> fine as well.
>
> OK let's wait a bit on this then to avoid introducing extra warnings.
Now that Roger's hwmod patches for the DCAN errata are in linux-next,
this patch can be applied safely. Let me know if you need me to resend it.
Thanks,
Sekhar
^ permalink raw reply
* Re: [RFC PATCH 2/5] soc/fsl/qbman: Use shared-dma-pool for QMan private memory allocations
From: Robin Murphy @ 2017-03-30 14:09 UTC (permalink / raw)
To: roy.pledge-3arQi8VN3Tc, oss-fOR+EgIDQEHk1uMJSBkQmQ,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: madalin.bucur-3arQi8VN3Tc
In-Reply-To: <1490822037-6752-3-git-send-email-roy.pledge-3arQi8VN3Tc@public.gmane.org>
Hi Roy,
On 29/03/17 22:13, Roy Pledge wrote:
> Use the shared-memory-pool mechanism for frame queue descriptor and
> packed frame descriptor record area allocations.
Thanks for persevering with this - in my opinion it's now looking like
it was worth the effort :)
AFAICS the ioremap_wc() that this leads to does appear to give back
something non-cacheable on PPC (assuming "pgprot_noncached_wc" isn't
horrendously misnamed), and "no-map" should rule out any cacheable
linear map alias existing, so it would seem that this approach should
avert Scott's concerns about attribute mismatches.
> Signed-off-by: Roy Pledge <roy.pledge-3arQi8VN3Tc@public.gmane.org>
> ---
> drivers/soc/fsl/qbman/qman_ccsr.c | 119 +++++++++++++++++++++-----------------
> drivers/soc/fsl/qbman/qman_priv.h | 4 +-
> drivers/soc/fsl/qbman/qman_test.h | 2 -
> 3 files changed, 68 insertions(+), 57 deletions(-)
>
> diff --git a/drivers/soc/fsl/qbman/qman_ccsr.c b/drivers/soc/fsl/qbman/qman_ccsr.c
> index 90bc40c..35c59ca 100644
> --- a/drivers/soc/fsl/qbman/qman_ccsr.c
> +++ b/drivers/soc/fsl/qbman/qman_ccsr.c
> @@ -400,63 +400,19 @@ static int qm_init_pfdr(struct device *dev, u32 pfdr_start, u32 num)
> return -ENODEV;
> }
>
> -/*
> - * Ideally we would use the DMA API to turn rmem->base into a DMA address
> - * (especially if iommu translations ever get involved). Unfortunately, the
> - * DMA API currently does not allow mapping anything that is not backed with
> - * a struct page.
> - */
> +/* QMan needs two global memory areas initialized at boot time:
> + 1) FQD: Frame Queue Descriptors used to manage frame queues
> + 2) PFDR: Packed Frame Queue Descriptor Records used to store frames
> + Both areas are reserved using the device tree reserved memory framework
> + and the addresses and sizes are initialized when the QMan device is probed */
> static dma_addr_t fqd_a, pfdr_a;
> static size_t fqd_sz, pfdr_sz;
>
> -static int qman_fqd(struct reserved_mem *rmem)
> -{
> - fqd_a = rmem->base;
> - fqd_sz = rmem->size;
> -
> - WARN_ON(!(fqd_a && fqd_sz));
> -
> - return 0;
> -}
> -RESERVEDMEM_OF_DECLARE(qman_fqd, "fsl,qman-fqd", qman_fqd);
> -
> -static int qman_pfdr(struct reserved_mem *rmem)
> -{
> - pfdr_a = rmem->base;
> - pfdr_sz = rmem->size;
> -
> - WARN_ON(!(pfdr_a && pfdr_sz));
> -
> - return 0;
> -}
> -RESERVEDMEM_OF_DECLARE(qman_pfdr, "fsl,qman-pfdr", qman_pfdr);
> -
I notice that patch #1 isn't removing the equivalent bman_fbpr() handler
and declaration as here - is that deliberate or just an oversight?
> static unsigned int qm_get_fqid_maxcnt(void)
> {
> return fqd_sz / 64;
> }
>
> -/*
> - * Flush this memory range from data cache so that QMAN originated
> - * transactions for this memory region could be marked non-coherent.
> - */
> -static int zero_priv_mem(struct device *dev, struct device_node *node,
> - phys_addr_t addr, size_t sz)
> -{
> - /* map as cacheable, non-guarded */
> - void __iomem *tmpp = ioremap_prot(addr, sz, 0);
> -
> - if (!tmpp)
> - return -ENOMEM;
> -
> - memset_io(tmpp, 0, sz);
> - flush_dcache_range((unsigned long)tmpp,
> - (unsigned long)tmpp + sz);
> - iounmap(tmpp);
> -
> - return 0;
> -}
> -
> static void log_edata_bits(struct device *dev, u32 bit_count)
> {
> u32 i, j, mask = 0xffffffff;
> @@ -687,11 +643,12 @@ static int qman_resource_init(struct device *dev)
> static int fsl_qman_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> - struct device_node *node = dev->of_node;
> + struct device_node *mem_node, *node = dev->of_node;
> struct resource *res;
> int ret, err_irq;
> u16 id;
> u8 major, minor;
> + u64 size;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!res) {
> @@ -727,10 +684,66 @@ static int fsl_qman_probe(struct platform_device *pdev)
> qm_channel_caam = QMAN_CHANNEL_CAAM_REV3;
> }
>
> - ret = zero_priv_mem(dev, node, fqd_a, fqd_sz);
> - WARN_ON(ret);
> - if (ret)
> + /* Order of memory regions is assumed as FQD followed by PFDR
> + in order to ensure allocations from the correct regions the
> + driver initializes then allocates each piece in order */
> +
> + ret = of_reserved_mem_device_init_by_idx(dev, dev->of_node, 0);
> + if (ret) {
> + dev_err(dev, "of_reserved_mem_device_init_by_idx(0) failed 0x%x\n",
> + ret);
> + return -ENODEV;
> + }
> + mem_node = of_parse_phandle(dev->of_node, "memory-region", 0);
> + if (mem_node) {
> + ret = of_property_read_u64(mem_node, "size", &size);
> + if (ret) {
> + dev_err(dev, "FQD: of_address_to_resource fails 0x%x\n", ret);
Nit: of_address_to_resource?
> + return -ENODEV;
> + }
> + fqd_sz = size;
> + } else {
> + dev_err(dev, "No memory-region found for FQD\n");
> + return -ENODEV;
> + }
> + if (!dma_zalloc_coherent(dev, fqd_sz, &fqd_a, 0)) {
> + dev_err(dev, "Alloc FQD memory failed\n");
> + return -ENODEV;
> + }
Between here, below, and patch #1, it looks like this "init, get size,
alloc" pattern could be nicely factored out into a common helper function.
> +
> + dev_info(dev, "Allocated FQD 0x%llx 0x%zx\n", fqd_a, fqd_sz);
> +
> + /* Disassociate the FQD reseverd memory area from the device because
> + a device can only have one DMA memory area. This should be fine
> + since the memory is allocated and initalized and only ever accessed
> + by the QMan device from now on */
Typos: reserved, initialized.
> + of_reserved_mem_device_release(dev);
I see the driver does not implement a .remove method where you would
otherwise be technically expected to balance the allocation with a
dma_free_coherent(), so I think this trick is acceptable. If anyone
wants to change that in future, it wouldn't seem unreasonable to extend
the core code to handle multiple areas per device (and at worst, I guess
you could deviously juggle dev->dma_mem around the DMA API calls).
Other than those first few nits, and any possible PPC-specific angles
I'm not aware of, I think the series is looking good!
Thanks,
Robin.
> +
> + /* Setup PFDR memory */
> + ret = of_reserved_mem_device_init_by_idx(dev, dev->of_node, 1);
> + if (ret) {
> + dev_err(dev, "of_reserved_mem_device_init(1) failed 0x%x\n",
> + ret);
> + return -ENODEV;
> + }
> + mem_node = of_parse_phandle(dev->of_node, "memory-region", 1);
> + if (mem_node) {
> + ret = of_property_read_u64(mem_node, "size", &size);
> + if (ret) {
> + dev_err(dev, "PFDR: of_address_to_resource fails 0x%x\n", ret);
> + return -ENODEV;
> + }
> + pfdr_sz = size;
> + } else {
> + dev_err(dev, "No memory-region found for PFDR\n");
> + return -ENODEV;
> + }
> + if (!dma_zalloc_coherent(dev, pfdr_sz, &pfdr_a, 0)) {
> + dev_err(dev, "Alloc PFDR Failed size 0x%zx\n", pfdr_sz);
> return -ENODEV;
> + }
> +
> + dev_info(dev, "Allocated PFDR 0x%llx 0x%zx\n", pfdr_a, pfdr_sz);
>
> ret = qman_init_ccsr(dev);
> if (ret) {
> diff --git a/drivers/soc/fsl/qbman/qman_priv.h b/drivers/soc/fsl/qbman/qman_priv.h
> index 22725bd..1e998ea5 100644
> --- a/drivers/soc/fsl/qbman/qman_priv.h
> +++ b/drivers/soc/fsl/qbman/qman_priv.h
> @@ -28,12 +28,12 @@
> * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> */
>
> -#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> -
> #include "dpaa_sys.h"
>
> #include <soc/fsl/qman.h>
> #include <linux/iommu.h>
> +#include <linux/dma-contiguous.h>
> +#include <linux/of_address.h>
>
> #if defined(CONFIG_FSL_PAMU)
> #include <asm/fsl_pamu_stash.h>
> diff --git a/drivers/soc/fsl/qbman/qman_test.h b/drivers/soc/fsl/qbman/qman_test.h
> index d5f8cb2..41bdbc48 100644
> --- a/drivers/soc/fsl/qbman/qman_test.h
> +++ b/drivers/soc/fsl/qbman/qman_test.h
> @@ -30,7 +30,5 @@
>
> #include "qman_priv.h"
>
> -#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> -
> int qman_test_stash(void);
> int qman_test_api(void);
>
--
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 v3 14/37] mtd: nand: denali: support "nand-ecc-strength" DT property
From: Boris Brezillon @ 2017-03-30 14:02 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Enrico Jorns,
Artem Bityutskiy, Dinh Nguyen, Marek Vasut, Graham Moore,
David Woodhouse, Masami Hiramatsu, Chuanxiao Dong, Jassi Brar,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Brian Norris,
Richard Weinberger, Cyrille Pitchen, Rob Herring, Mark Rutland
In-Reply-To: <1490856383-31560-15-git-send-email-yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
On Thu, 30 Mar 2017 15:46:00 +0900
Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org> 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. This is useful
> when a particular ECC setting is hard-coded by firmware (or hard-
> wired by boot ROM).
>
> If no ECC strength is specified in DT, "nand-ecc-maximize" is implied
> since this was the original behavior.
You said there is currently no DT users, so how about changing the
"fallback to ECC maximization" behavior for DT users, and instead of
maximizing the ECC strength take the NAND requirements into account
(chip->ecc_strength_ds).
For PCI users, you explicitly set the NAND_ECC_MAXIMIZE flag, so it
shouldn't be a problem (you're still backward compatible).
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
>
> Changes in v3: None
> Changes in v2:
> - Add available values in the binding document
>
> Documentation/devicetree/bindings/mtd/denali-nand.txt | 6 ++++++
> drivers/mtd/nand/denali.c | 18 ++++++++++++++++--
> drivers/mtd/nand/denali_pci.c | 1 +
> 3 files changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mtd/denali-nand.txt b/Documentation/devicetree/bindings/mtd/denali-nand.txt
> index 25313c7..647618e 100644
> --- a/Documentation/devicetree/bindings/mtd/denali-nand.txt
> +++ b/Documentation/devicetree/bindings/mtd/denali-nand.txt
> @@ -11,6 +11,12 @@ Optional properties:
> - nand-ecc-step-size: must be 512 or 1024. If not specified, default to:
> 512 for "altr,socfpga-denali-nand"
> see nand.txt for details.
> + - nand-ecc-strength: see nand.txt for details. Available values are:
> + 8, 15 for "altr,socfpga-denali-nand"
> + - nand-ecc-maximize: see nand.txt for details
> +
> +Note:
> +Either nand-ecc-strength or nand-ecc-maximize should be specified.
>
> The device tree may optionally contain sub-nodes describing partitions of the
> address space. See partition.txt for more detail.
> diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
> index ce87b95..2f796e3 100644
> --- a/drivers/mtd/nand/denali.c
> +++ b/drivers/mtd/nand/denali.c
> @@ -1641,9 +1641,23 @@ int denali_init(struct denali_nand_info *denali)
> goto failed_req_irq;
> }
>
> - ret = denali_set_max_ecc_strength(denali);
> - if (ret)
> + if (!chip->ecc.strength && !(chip->ecc.options & NAND_ECC_MAXIMIZE)) {
> + dev_info(denali->dev,
> + "No ECC strength strategy is specified. Maximizing ECC strength\n");
> + chip->ecc.options |= NAND_ECC_MAXIMIZE;
> + }
> +
> + if (chip->ecc.options & NAND_ECC_MAXIMIZE) {
> + ret = denali_set_max_ecc_strength(denali);
> + if (ret)
> + goto failed_req_irq;
> + } else if (!(denali->ecc_strength_avail & BIT(chip->ecc.strength))) {
> + dev_err(denali->dev,
> + "ECC strength %d is not supported on this controller.\n",
> + chip->ecc.strength);
> + ret = -EINVAL;
> goto failed_req_irq;
> + }
>
> chip->ecc.bytes = denali_calc_ecc_bytes(chip->ecc.size,
> chip->ecc.strength);
> diff --git a/drivers/mtd/nand/denali_pci.c b/drivers/mtd/nand/denali_pci.c
> index a1ee9f8..a39682a5 100644
> --- a/drivers/mtd/nand/denali_pci.c
> +++ b/drivers/mtd/nand/denali_pci.c
> @@ -87,6 +87,7 @@ static int denali_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
>
> denali->ecc_strength_avail = BIT(15) | BIT(8);
> denali->caps |= DENALI_CAP_ECC_SIZE_512;
> + denali->nand.ecc.options |= NAND_ECC_MAXIMIZE;
>
> ret = denali_init(denali);
> if (ret)
--
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 6/9] coresight: add support for CPU debug module
From: Leo Yan @ 2017-03-30 13:51 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: Mike Leach, Mathieu Poirier, Jonathan Corbet, Rob Herring,
Mark Rutland, Wei Xu, Catalin Marinas, Will Deacon, Andy Gross,
David Brown, Michael Turquette, Stephen Boyd, Guodong Xu,
John Stultz, linux-doc, linux-kernel, devicetree,
linux-arm-kernel, linux-arm-msm, linux-soc, linux-clk,
Sudeep Holla <sudeep.holla>
In-Reply-To: <a9078a4e-152e-01ae-8750-1396da2bc623@arm.com>
On Thu, Mar 30, 2017 at 10:00:30AM +0100, Suzuki K Poulose wrote:
[...]
> Leo,
>
> Also, it would be good to restore the PRCR register back to the original state
> after we read the registers (if we changed them). I am exploring ways to make
> use of this feature on demand (e.g, tie it to sysrq-t or sysrq-l) and not just
> at panic time. So it would be good to have the state restored to not affect the
> normal functioning even after dumping the registers.
Got it. Will take care for this.
Thanks,
Leo Yan
> PS: I have a small hack to hook this into a sysrq-x at runtime, but on a second thought
> it is better not to consume the key and rather tie it to something which already exist,
> as mentioned above.
>
> Thanks
> Suzuki
^ permalink raw reply
* [PATCH v2] Extend pca9532 device tree support
From: Felix Brack @ 2017-03-30 13:33 UTC (permalink / raw)
To: jacek.anaszewski, rpurdie, pavel, mark.rutland, riku.voipio,
linux-leds, devicetree
Cc: linux-kernel, fb
This patch extends the device tree support for the pca9532 by adding
the leds 'default-state' property.
Changes in v2:
- remove prescaler and pwm configuration by none generic
DT properties
Signed-off-by: Felix Brack <fb@ltec.ch>
---
.../devicetree/bindings/leds/leds-pca9532.txt | 10 +++++++
drivers/leds/leds-pca9532.c | 31 +++++++++++++++++++++-
include/linux/leds-pca9532.h | 4 +--
3 files changed, 42 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/leds-pca9532.txt b/Documentation/devicetree/bindings/leds/leds-pca9532.txt
index 198f3ba..8374075 100644
--- a/Documentation/devicetree/bindings/leds/leds-pca9532.txt
+++ b/Documentation/devicetree/bindings/leds/leds-pca9532.txt
@@ -17,6 +17,8 @@ Optional sub-node properties:
- label: see Documentation/devicetree/bindings/leds/common.txt
- type: Output configuration, see dt-bindings/leds/leds-pca9532.h (default NONE)
- linux,default-trigger: see Documentation/devicetree/bindings/leds/common.txt
+ - default-state: see Documentation/devicetree/bindings/leds/common.txt
+ This property is only valid for sub-nodes of type <PCA9532_TYPE_LED>.
Example:
#include <dt-bindings/leds/leds-pca9532.h>
@@ -33,6 +35,14 @@ Example:
label = "pca:green:power";
type = <PCA9532_TYPE_LED>;
};
+ kernel-booting {
+ type = <PCA9532_TYPE_LED>;
+ default-state = "on";
+ };
+ sys-stat {
+ type = <PCA9532_TYPE_LED>;
+ default-state = "keep"; // don't touch, was set by U-Boot
+ };
};
For more product information please see the link below:
diff --git a/drivers/leds/leds-pca9532.c b/drivers/leds/leds-pca9532.c
index 06e6310..66ef280 100644
--- a/drivers/leds/leds-pca9532.c
+++ b/drivers/leds/leds-pca9532.c
@@ -254,6 +254,21 @@ static void pca9532_input_work(struct work_struct *work)
mutex_unlock(&data->update_lock);
}
+static enum pca9532_state pca9532_getled(struct pca9532_led *led)
+{
+ struct i2c_client *client = led->client;
+ struct pca9532_data *data = i2c_get_clientdata(client);
+ u8 maxleds = data->chip_info->num_leds;
+ char reg;
+ enum pca9532_state ret;
+
+ mutex_lock(&data->update_lock);
+ reg = i2c_smbus_read_byte_data(client, LED_REG(maxleds, led->id));
+ ret = reg >> LED_NUM(led->id)/2;
+ mutex_unlock(&data->update_lock);
+ return ret;
+}
+
#ifdef CONFIG_LEDS_PCA9532_GPIO
static int pca9532_gpio_request_pin(struct gpio_chip *gc, unsigned offset)
{
@@ -366,7 +381,10 @@ static int pca9532_configure(struct i2c_client *client,
gpios++;
break;
case PCA9532_TYPE_LED:
- led->state = pled->state;
+ if (pled->state == PCA9532_KEEP)
+ led->state = pca9532_getled(led);
+ else
+ led->state = pled->state;
led->name = pled->name;
led->ldev.name = led->name;
led->ldev.default_trigger = pled->default_trigger;
@@ -456,6 +474,7 @@ pca9532_of_populate_pdata(struct device *dev, struct device_node *np)
const struct of_device_id *match;
int devid, maxleds;
int i = 0;
+ const char *state;
match = of_match_device(of_pca9532_leds_match, dev);
if (!match)
@@ -475,6 +494,16 @@ pca9532_of_populate_pdata(struct device *dev, struct device_node *np)
of_property_read_u32(child, "type", &pdata->leds[i].type);
of_property_read_string(child, "linux,default-trigger",
&pdata->leds[i].default_trigger);
+ if (!of_property_read_string(child, "default-state", &state)) {
+ if (!strcmp(state, "on"))
+ pdata->leds[i].state = PCA9532_ON;
+ else if (!strcmp(state, "keep"))
+ pdata->leds[i].state = PCA9532_KEEP;
+ else if (!strcmp(state, "pwm0"))
+ pdata->leds[i].state = PCA9532_PWM0;
+ else if (!strcmp(state, "pwm1"))
+ pdata->leds[i].state = PCA9532_PWM1;
+ }
if (++i >= maxleds) {
of_node_put(child);
break;
diff --git a/include/linux/leds-pca9532.h b/include/linux/leds-pca9532.h
index d215b45..a327b1aa 100644
--- a/include/linux/leds-pca9532.h
+++ b/include/linux/leds-pca9532.h
@@ -22,7 +22,8 @@ enum pca9532_state {
PCA9532_OFF = 0x0,
PCA9532_ON = 0x1,
PCA9532_PWM0 = 0x2,
- PCA9532_PWM1 = 0x3
+ PCA9532_PWM1 = 0x3,
+ PCA9532_KEEP = 0xff
};
struct pca9532_led {
@@ -44,4 +45,3 @@ struct pca9532_platform_data {
};
#endif /* __LINUX_PCA9532_H */
-
--
2.7.4
^ permalink raw reply related
* RE: [PATCH v3 3/7] arm: dts: dt-bindings: Add Renesas RZ pinctrl header
From: Chris Brandt @ 2017-03-30 13:27 UTC (permalink / raw)
To: Linus Walleij
Cc: Jacopo Mondi, Bjorn Andersson, Geert Uytterhoeven,
Laurent Pinchart, Rob Herring, Mark Rutland, Russell King,
Linux-Renesas, linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CACRpkda_Gw9vhLqpWw8oOZyZ59nj5j9Q-T5RXVsf0vsxWcjyHg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 4517 bytes --]
On Thursday, March 30, 2017, Linus Walleij wrote:
> >> > +/*
> >> > + * Pin is bi-directional.
> >> > + * An alternate function that needs both input/output
> >> > +functionalities shall
> >> > + * be configured as bidirectional.
> >> > + * Eg. SDA/SCL pins of an I2c interface.
> >> > + */
> >> > +#define BI_DIR (1 << 3)
> >>
> >> Any specific reason why this should not simply be added to
> >> include/linux/pinctrl/pinconf-generic.h
> >> as PIN_CONFIG_BIDIRECTIONAL and parsed in drivers/pinctrl/pinconf-
> >> generic.c from the (new) DT property "bidirectional" simply?
> >
> > I see your point. It would cut down from every driver out there
> > inventing some new property or config instead of everyone just sharing
> > a fixed set.
> > Maybe someone else out there will end up having a need for a
> > "bidirectional" option.
>
> I was thinking about that one. It is a bit weird electrically, like what
> kind of electronics is really bidirectional?
>
> It seems like a fancy name for open drain/open source, what we call
> "single ended" configuration. (See docs in
> Documentation/gpio/driver.txt)
>
> It would be great if you could check if that is what they mean, actually.
Here is the definition of the register in the hardware manual:
---
54.3.13 Port Bidirection Control Register (PBDCn)
This register enables or disables the input buffer while the output buffer is enabled. When the input buffer is enabled
while the output buffer is enabled, the bidirectional mode is entered, allowing the level of the Pn_m pin to always be read
via the PPRn.PPRnm bit.
---
But...what they don't really tell you is that any peripheral that needs to TX and RX data over a pin needs this set.
In the hardware manual, there is a pretty picture (Figure 54.1 Logical Diagram of Port Control) that shows a detailed logic diagram of the interface between the peripheral bus and the pin pad.
As far as I can tell, the "function mux" portion of this controller only knows how to set a pin as direction=in or direction=out.
So, in the case of I2C where each the SCL and SDA pins needs to be driven and read...it can't do that.
Therefore, there is an additional register to manually enable the input buffer and let the mux enable the output buffer.
So while yes, I2C is open-drain, this is also the case for the data pins for the SDHI. And the MDIO pin from Ethernet. It really has to do with the fact that this pin controller wasn't designed to enable both the input and output buffers at the same time.
The situation is similar for our SWIO_IN and SWIO_OUT flags. For example, to use the SSI sound interface, you have to set the TX signals to "input" (SWIO_IN). Makes sense, right??
I could argue that all of these "FLAGS" settings should have been incorporated in the HW logic of the pin controller...but for whatever reason, the they had to make them separate registers and make SW do it.
So, I could argue that these registers settings are really part of pin muxing, not really user config....and hence belong in the "pinmux" property.
How about this compromise: Instead of BI_DIR, we use "TYPE_I2C", "TYPE_SDDATA", "TYPE_MDIO", "TYPE_LVDS", etc... to describe the 'special' ones. That way it can go back under "pinmux". Like Jacopo said, these register settings are really supposed to be set when you are selecting the pin-mux option.
Of course behind the scenes, it's really:
#define TYPE_I2C BI_DIR
#define TYPE_SDDATA BI_DIR
#define TYPE_SDCMD BI_DIR
#define TYPE_LVDS SWIO_OUT
Examples:
i2c3_pins: i2c3 {
pinmux = <PIN(1, 6) | FUNC_1 | TYPE_I2C>,
<PIN(1, 7) | FUNC_1 | TYPE_I2C>;
};
/* SHDI ch1 on CN1 */
sdhi1_pins: sdhi1 {
/* SHDI ch1 on Port 3 */
pinmux = <PIN(3, 8) | FUNC_7>, /* SDHI1 CD */
<PIN(3, 9) FUNC_7)>, /* SDHI1 WP */
<PIN(3, 10) FUNC_7 | TYPE_SDDATA)>, /* SDHI1 DAT1 */
<PIN(3, 11) FUNC_7 | TYPE_SDDATA)>, /* SDHI1 DAT0 */
<PIN(3, 12) FUNC_7)>, /* SDHI1 CLK */
<PIN(3, 13) FUNC_7 | TYPE_SDCMD)>, /* SDHI1 CMD */
<PIN(3, 14) FUNC_7 | TYPE_SDDATA)>, /* SDHI1 DAT3 */
<PIN(3, 15) FUNC_7 | TYPE_SDDATA)>; /* SDHI1 DAT2 */
};
# Honestly, I have no idea where this pin controller came from. I have not seen it in any other Renesas part (Mitsubishi/Hitachi/NEC).
Chris
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·zøœzÚÞz)í…æèw*\x1fjg¬±¨\x1e¶‰šŽŠÝ¢j.ïÛ°\½½MŽúgjÌæa×\x02››–' ™©Þ¢¸\f¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾\a«‘êçzZ+ƒùšŽŠÝ¢j"ú!¶i
^ permalink raw reply
* Re: [PATCH 1/5] ARM: dts: imx7-colibri: use OF graph to describe the display
From: Shawn Guo @ 2017-03-30 13:16 UTC (permalink / raw)
To: Stefan Agner
Cc: kernel, fabio.estevam, robh+dt, mark.rutland, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <20170329232113.19078-1-stefan@agner.ch>
On Wed, Mar 29, 2017 at 04:21:09PM -0700, Stefan Agner wrote:
> To make use of the new eLCDIF DRM driver OF graph description is
> required. Describe the display using OF graph nodes.
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
Applied all, thanks.
^ permalink raw reply
* Re: [RESEND PATCH v2 1/2] mfd: retu: Add OF device ID table
From: Javier Martinez Canillas @ 2017-03-30 12:49 UTC (permalink / raw)
To: Rob Herring
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Lee Jones
In-Reply-To: <CAL_JsqJTxT1V1Y8Wte4W22UjFcAKUuny5VCFpurwjkPz=hGxVQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hello Rob,
On 03/30/2017 08:41 AM, Rob Herring wrote:
> On Wed, Mar 15, 2017 at 5:49 AM, Javier Martinez Canillas
> <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> wrote:
>> The driver doesn't have a struct of_device_id table but supported devices
>> are registered via Device Trees. This is working on the assumption that a
>> I2C device registered via OF will always match a legacy I2C device ID and
>> that the MODALIAS reported will always be of the form i2c:<device>.
>
> It should also have the OF MODALIAS.
>
Yes, it should but currently it doesn't. This is the .uevent callback for I2C:
static int i2c_device_uevent(struct device *dev, struct kobj_uevent_env *env)
{
struct i2c_client *client = to_i2c_client(dev);
int rc;
rc = acpi_device_uevent_modalias(dev, env);
if (rc != -ENODEV)
return rc;
return add_uevent_var(env, "MODALIAS=%s%s", I2C_MODULE_PREFIX, client->name);
}
>> But this could change in the future so the correct approach is to have a
>> OF device ID table if the devices are registered via OF.
>
> I believe this is already the case.
>
No, in fact the purpose of these patches (and others that I've been posting in
all subsystems) is to make sure that adding proper OF MODALIAS support for I2C
won't cause regressions in existing drivers due not having OF device ID tables.
This is the RFC patch I posted some time ago for I2C core:
https://patchwork.ozlabs.org/patch/388200/
>> The compatible strings don't have a vendor prefix because that's how it's
>> used currently, and changing this will be a Device Tree ABI break.
>
> How so? These "compatible" strings are not documented, so there is no
> ABI. You may have been lucky to get things working using the driver
> name as the compatible string.
>
Yes, it's not documented but I thought that having users meant that it was
already an ABI.
I'm more than happy to change the upstream DTS to add a vendor prefix and
use this also in the drivers.
> Rob
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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: [REPOST PATCH] ARM: dts: imx6qp-nitrogen6_som2: add Quad Plus variant of the SOM
From: Shawn Guo @ 2017-03-30 12:49 UTC (permalink / raw)
To: Gary Bisson
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, fabio.estevam-3arQi8VN3Tc,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <20170329084523.8065-1-gary.bisson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
On Wed, Mar 29, 2017 at 10:45:23AM +0200, Gary Bisson wrote:
> https://boundarydevices.com/product/nit6x-som-v2/
>
> Reviewed-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
> Signed-off-by: Gary Bisson <gary.bisson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
Applied, thanks.
--
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: [RESEND PATCH v2 1/2] mfd: retu: Add OF device ID table
From: Rob Herring @ 2017-03-30 12:41 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Lee Jones
In-Reply-To: <20170315104958.24919-1-javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
On Wed, Mar 15, 2017 at 5:49 AM, Javier Martinez Canillas
<javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> wrote:
> The driver doesn't have a struct of_device_id table but supported devices
> are registered via Device Trees. This is working on the assumption that a
> I2C device registered via OF will always match a legacy I2C device ID and
> that the MODALIAS reported will always be of the form i2c:<device>.
It should also have the OF MODALIAS.
> But this could change in the future so the correct approach is to have a
> OF device ID table if the devices are registered via OF.
I believe this is already the case.
> The compatible strings don't have a vendor prefix because that's how it's
> used currently, and changing this will be a Device Tree ABI break.
How so? These "compatible" strings are not documented, so there is no
ABI. You may have been lucky to get things working using the driver
name as the compatible string.
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 v3 2/2] PCI: Add tango PCIe host bridge support
From: kbuild test robot @ 2017-03-30 12:09 UTC (permalink / raw)
To: Marc Gonzalez
Cc: kbuild-all, Bjorn Helgaas, Marc Zyngier, Thomas Gleixner,
Robin Murphy, Lorenzo Pieralisi, Liviu Dudau, David Laight,
linux-pci, Linux ARM, Thibaud Cornic, Phuong Nguyen, LKML, DT,
Mason
In-Reply-To: <65114e62-7458-b6f7-327c-f07a5096a452@sigmadesigns.com>
[-- Attachment #1: Type: text/plain, Size: 19079 bytes --]
Hi Marc,
[auto build test ERROR on v4.9-rc8]
[also build test ERROR on next-20170330]
[cannot apply to pci/next]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Marc-Gonzalez/Tango-PCIe-controller-support/20170330-154028
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All error/warnings (new ones prefixed by >>):
In file included from drivers/pci/host/pcie-tango.c:4:0:
>> include/linux/pci-ecam.h:29:19: error: field 'pci_ops' has incomplete type
struct pci_ops pci_ops;
^~~~~~~
>> include/linux/pci-ecam.h:57:39: warning: 'struct pci_bus' declared inside parameter list will not be visible outside of this definition or declaration
void __iomem *pci_ecam_map_bus(struct pci_bus *bus, unsigned int devfn,
^~~~~~~
>> drivers/pci/host/pcie-tango.c:198:39: warning: 'struct pci_bus' declared inside parameter list will not be visible outside of this definition or declaration
static int smp8759_config_read(struct pci_bus *bus,
^~~~~~~
drivers/pci/host/pcie-tango.c: In function 'smp8759_config_read':
>> drivers/pci/host/pcie-tango.c:202:37: error: dereferencing pointer to incomplete type 'struct pci_bus'
struct pci_config_window *cfg = bus->sysdata;
^~
>> drivers/pci/host/pcie-tango.c:211:10: error: 'PCIBIOS_FUNC_NOT_SUPPORTED' undeclared (first use in this function)
return PCIBIOS_FUNC_NOT_SUPPORTED; /* Error seems appropriate */
^~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/pci/host/pcie-tango.c:211:10: note: each undeclared identifier is reported only once for each function it appears in
>> drivers/pci/host/pcie-tango.c:219:15: error: 'PCI_BASE_ADDRESS_0' undeclared (first use in this function)
if (where == PCI_BASE_ADDRESS_0 && bus->number == 0) {
^~~~~~~~~~~~~~~~~~
>> drivers/pci/host/pcie-tango.c:221:10: error: 'PCIBIOS_SUCCESSFUL' undeclared (first use in this function)
return PCIBIOS_SUCCESSFUL; /* Should we return error or success? */
^~~~~~~~~~~~~~~~~~
>> drivers/pci/host/pcie-tango.c:233:8: error: implicit declaration of function 'pci_generic_config_read' [-Werror=implicit-function-declaration]
ret = pci_generic_config_read(bus, devfn, where, size, val);
^~~~~~~~~~~~~~~~~~~~~~~
drivers/pci/host/pcie-tango.c: At top level:
drivers/pci/host/pcie-tango.c:239:40: warning: 'struct pci_bus' declared inside parameter list will not be visible outside of this definition or declaration
static int smp8759_config_write(struct pci_bus *bus,
^~~~~~~
drivers/pci/host/pcie-tango.c: In function 'smp8759_config_write':
drivers/pci/host/pcie-tango.c:243:37: error: dereferencing pointer to incomplete type 'struct pci_bus'
struct pci_config_window *cfg = bus->sysdata;
^~
>> drivers/pci/host/pcie-tango.c:247:8: error: implicit declaration of function 'pci_generic_config_write' [-Werror=implicit-function-declaration]
ret = pci_generic_config_write(bus, devfn, where, size, val);
^~~~~~~~~~~~~~~~~~~~~~~~
drivers/pci/host/pcie-tango.c: At top level:
>> drivers/pci/host/pcie-tango.c:256:3: error: field name not in record or union initializer
.map_bus = pci_ecam_map_bus,
^
drivers/pci/host/pcie-tango.c:256:3: note: (near initialization for 'smp8759_ecam_ops.pci_ops')
drivers/pci/host/pcie-tango.c:257:3: error: field name not in record or union initializer
.read = smp8759_config_read,
^
drivers/pci/host/pcie-tango.c:257:3: note: (near initialization for 'smp8759_ecam_ops.pci_ops')
drivers/pci/host/pcie-tango.c:258:3: error: field name not in record or union initializer
.write = smp8759_config_write,
^
drivers/pci/host/pcie-tango.c:258:3: note: (near initialization for 'smp8759_ecam_ops.pci_ops')
drivers/pci/host/pcie-tango.c: In function 'tango_fixup_class':
>> drivers/pci/host/pcie-tango.c:329:5: error: dereferencing pointer to incomplete type 'struct pci_dev'
dev->class = PCI_CLASS_BRIDGE_PCI << 8;
^~
>> drivers/pci/host/pcie-tango.c:329:15: error: 'PCI_CLASS_BRIDGE_PCI' undeclared (first use in this function)
dev->class = PCI_CLASS_BRIDGE_PCI << 8;
^~~~~~~~~~~~~~~~~~~~
drivers/pci/host/pcie-tango.c: At top level:
>> drivers/pci/host/pcie-tango.c:320:22: error: expected declaration specifiers or '...' before numeric constant
#define VENDOR_SIGMA 0x1105
^
>> drivers/pci/host/pcie-tango.c:331:25: note: in expansion of macro 'VENDOR_SIGMA'
DECLARE_PCI_FIXUP_EARLY(VENDOR_SIGMA, PCI_ANY_ID, tango_fixup_class);
^~~~~~~~~~~~
In file included from include/linux/of.h:22:0,
from include/linux/irqdomain.h:34,
from drivers/pci/host/pcie-tango.c:3:
>> include/linux/mod_devicetable.h:16:20: error: expected declaration specifiers or '...' before '(' token
#define PCI_ANY_ID (~0)
^
>> drivers/pci/host/pcie-tango.c:331:39: note: in expansion of macro 'PCI_ANY_ID'
DECLARE_PCI_FIXUP_EARLY(VENDOR_SIGMA, PCI_ANY_ID, tango_fixup_class);
^~~~~~~~~~
>> drivers/pci/host/pcie-tango.c:331:51: error: expected declaration specifiers or '...' before 'tango_fixup_class'
DECLARE_PCI_FIXUP_EARLY(VENDOR_SIGMA, PCI_ANY_ID, tango_fixup_class);
^~~~~~~~~~~~~~~~~
drivers/pci/host/pcie-tango.c: In function 'tango_fixup_bar':
>> drivers/pci/host/pcie-tango.c:342:9: error: implicit declaration of function 'pci_write_config_dword' [-Werror=implicit-function-declaration]
pci_write_config_dword(dev, PCI_BASE_ADDRESS_0, 0x80000000);
^~~~~~~~~~~~~~~~~~~~~~
drivers/pci/host/pcie-tango.c:342:37: error: 'PCI_BASE_ADDRESS_0' undeclared (first use in this function)
pci_write_config_dword(dev, PCI_BASE_ADDRESS_0, 0x80000000);
^~~~~~~~~~~~~~~~~~
drivers/pci/host/pcie-tango.c: At top level:
>> drivers/pci/host/pcie-tango.c:320:22: error: expected declaration specifiers or '...' before numeric constant
#define VENDOR_SIGMA 0x1105
^
drivers/pci/host/pcie-tango.c:344:25: note: in expansion of macro 'VENDOR_SIGMA'
DECLARE_PCI_FIXUP_FINAL(VENDOR_SIGMA, PCI_ANY_ID, tango_fixup_bar);
^~~~~~~~~~~~
In file included from include/linux/of.h:22:0,
from include/linux/irqdomain.h:34,
from drivers/pci/host/pcie-tango.c:3:
>> include/linux/mod_devicetable.h:16:20: error: expected declaration specifiers or '...' before '(' token
#define PCI_ANY_ID (~0)
^
drivers/pci/host/pcie-tango.c:344:39: note: in expansion of macro 'PCI_ANY_ID'
DECLARE_PCI_FIXUP_FINAL(VENDOR_SIGMA, PCI_ANY_ID, tango_fixup_bar);
^~~~~~~~~~
--
In file included from drivers/pci//host/pcie-tango.c:4:0:
>> include/linux/pci-ecam.h:29:19: error: field 'pci_ops' has incomplete type
struct pci_ops pci_ops;
^~~~~~~
>> include/linux/pci-ecam.h:57:39: warning: 'struct pci_bus' declared inside parameter list will not be visible outside of this definition or declaration
void __iomem *pci_ecam_map_bus(struct pci_bus *bus, unsigned int devfn,
^~~~~~~
drivers/pci//host/pcie-tango.c:198:39: warning: 'struct pci_bus' declared inside parameter list will not be visible outside of this definition or declaration
static int smp8759_config_read(struct pci_bus *bus,
^~~~~~~
drivers/pci//host/pcie-tango.c: In function 'smp8759_config_read':
drivers/pci//host/pcie-tango.c:202:37: error: dereferencing pointer to incomplete type 'struct pci_bus'
struct pci_config_window *cfg = bus->sysdata;
^~
drivers/pci//host/pcie-tango.c:211:10: error: 'PCIBIOS_FUNC_NOT_SUPPORTED' undeclared (first use in this function)
return PCIBIOS_FUNC_NOT_SUPPORTED; /* Error seems appropriate */
^~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/pci//host/pcie-tango.c:211:10: note: each undeclared identifier is reported only once for each function it appears in
drivers/pci//host/pcie-tango.c:219:15: error: 'PCI_BASE_ADDRESS_0' undeclared (first use in this function)
if (where == PCI_BASE_ADDRESS_0 && bus->number == 0) {
^~~~~~~~~~~~~~~~~~
drivers/pci//host/pcie-tango.c:221:10: error: 'PCIBIOS_SUCCESSFUL' undeclared (first use in this function)
return PCIBIOS_SUCCESSFUL; /* Should we return error or success? */
^~~~~~~~~~~~~~~~~~
drivers/pci//host/pcie-tango.c:233:8: error: implicit declaration of function 'pci_generic_config_read' [-Werror=implicit-function-declaration]
ret = pci_generic_config_read(bus, devfn, where, size, val);
^~~~~~~~~~~~~~~~~~~~~~~
drivers/pci//host/pcie-tango.c: At top level:
drivers/pci//host/pcie-tango.c:239:40: warning: 'struct pci_bus' declared inside parameter list will not be visible outside of this definition or declaration
static int smp8759_config_write(struct pci_bus *bus,
^~~~~~~
drivers/pci//host/pcie-tango.c: In function 'smp8759_config_write':
drivers/pci//host/pcie-tango.c:243:37: error: dereferencing pointer to incomplete type 'struct pci_bus'
struct pci_config_window *cfg = bus->sysdata;
^~
drivers/pci//host/pcie-tango.c:247:8: error: implicit declaration of function 'pci_generic_config_write' [-Werror=implicit-function-declaration]
ret = pci_generic_config_write(bus, devfn, where, size, val);
^~~~~~~~~~~~~~~~~~~~~~~~
drivers/pci//host/pcie-tango.c: At top level:
drivers/pci//host/pcie-tango.c:256:3: error: field name not in record or union initializer
.map_bus = pci_ecam_map_bus,
^
drivers/pci//host/pcie-tango.c:256:3: note: (near initialization for 'smp8759_ecam_ops.pci_ops')
drivers/pci//host/pcie-tango.c:257:3: error: field name not in record or union initializer
.read = smp8759_config_read,
^
drivers/pci//host/pcie-tango.c:257:3: note: (near initialization for 'smp8759_ecam_ops.pci_ops')
drivers/pci//host/pcie-tango.c:258:3: error: field name not in record or union initializer
.write = smp8759_config_write,
^
drivers/pci//host/pcie-tango.c:258:3: note: (near initialization for 'smp8759_ecam_ops.pci_ops')
drivers/pci//host/pcie-tango.c: In function 'tango_fixup_class':
drivers/pci//host/pcie-tango.c:329:5: error: dereferencing pointer to incomplete type 'struct pci_dev'
dev->class = PCI_CLASS_BRIDGE_PCI << 8;
^~
drivers/pci//host/pcie-tango.c:329:15: error: 'PCI_CLASS_BRIDGE_PCI' undeclared (first use in this function)
dev->class = PCI_CLASS_BRIDGE_PCI << 8;
^~~~~~~~~~~~~~~~~~~~
drivers/pci//host/pcie-tango.c: At top level:
drivers/pci//host/pcie-tango.c:320:22: error: expected declaration specifiers or '...' before numeric constant
#define VENDOR_SIGMA 0x1105
^
drivers/pci//host/pcie-tango.c:331:25: note: in expansion of macro 'VENDOR_SIGMA'
DECLARE_PCI_FIXUP_EARLY(VENDOR_SIGMA, PCI_ANY_ID, tango_fixup_class);
^~~~~~~~~~~~
In file included from include/linux/of.h:22:0,
from include/linux/irqdomain.h:34,
from drivers/pci//host/pcie-tango.c:3:
>> include/linux/mod_devicetable.h:16:20: error: expected declaration specifiers or '...' before '(' token
#define PCI_ANY_ID (~0)
^
drivers/pci//host/pcie-tango.c:331:39: note: in expansion of macro 'PCI_ANY_ID'
DECLARE_PCI_FIXUP_EARLY(VENDOR_SIGMA, PCI_ANY_ID, tango_fixup_class);
^~~~~~~~~~
drivers/pci//host/pcie-tango.c:331:51: error: expected declaration specifiers or '...' before 'tango_fixup_class'
DECLARE_PCI_FIXUP_EARLY(VENDOR_SIGMA, PCI_ANY_ID, tango_fixup_class);
^~~~~~~~~~~~~~~~~
drivers/pci//host/pcie-tango.c: In function 'tango_fixup_bar':
drivers/pci//host/pcie-tango.c:342:9: error: implicit declaration of function 'pci_write_config_dword' [-Werror=implicit-function-declaration]
pci_write_config_dword(dev, PCI_BASE_ADDRESS_0, 0x80000000);
^~~~~~~~~~~~~~~~~~~~~~
drivers/pci//host/pcie-tango.c:342:37: error: 'PCI_BASE_ADDRESS_0' undeclared (first use in this function)
pci_write_config_dword(dev, PCI_BASE_ADDRESS_0, 0x80000000);
^~~~~~~~~~~~~~~~~~
drivers/pci//host/pcie-tango.c: At top level:
drivers/pci//host/pcie-tango.c:320:22: error: expected declaration specifiers or '...' before numeric constant
#define VENDOR_SIGMA 0x1105
^
drivers/pci//host/pcie-tango.c:344:25: note: in expansion of macro 'VENDOR_SIGMA'
DECLARE_PCI_FIXUP_FINAL(VENDOR_SIGMA, PCI_ANY_ID, tango_fixup_bar);
^~~~~~~~~~~~
In file included from include/linux/of.h:22:0,
from include/linux/irqdomain.h:34,
from drivers/pci//host/pcie-tango.c:3:
>> include/linux/mod_devicetable.h:16:20: error: expected declaration specifiers or '...' before '(' token
#define PCI_ANY_ID (~0)
^
drivers/pci//host/pcie-tango.c:344:39: note: in expansion of macro 'PCI_ANY_ID'
DECLARE_PCI_FIXUP_FINAL(VENDOR_SIGMA, PCI_ANY_ID, tango_fixup_bar);
^~~~~~~~~~
drivers/pci//host/pcie-tango.c:344:51: error: expected declaration specifiers or '...' before 'tango_fixup_bar'
DECLARE_PCI_FIXUP_FINAL(VENDOR_SIGMA, PCI_ANY_ID, tango_fixup_bar);
^~~~~~~~~~~~~~~
drivers/pci//host/pcie-tango.c:340:13: warning: 'tango_fixup_bar' defined but not used [-Wunused-function]
static void tango_fixup_bar(struct pci_dev *dev)
^~~~~~~~~~~~~~~
drivers/pci//host/pcie-tango.c:327:13: warning: 'tango_fixup_class' defined but not used [-Wunused-function]
static void tango_fixup_class(struct pci_dev *dev)
^~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/pci_ops +29 include/linux/pci-ecam.h
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 23 * struct to hold pci ops and bus shift of the config window
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 24 * for a PCI controller.
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 25 */
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 26 struct pci_config_window;
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 27 struct pci_ecam_ops {
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 28 unsigned int bus_shift;
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 @29 struct pci_ops pci_ops;
5c3d14f7 include/linux/pci-ecam.h Jayachandran C 2016-06-10 30 int (*init)(struct pci_config_window *);
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 31 };
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 32
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 33 /*
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 34 * struct to hold the mappings of a config space window. This
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 35 * is expected to be used as sysdata for PCI controllers that
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 36 * use ECAM.
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 37 */
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 38 struct pci_config_window {
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 39 struct resource res;
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 40 struct resource busr;
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 41 void *priv;
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 42 struct pci_ecam_ops *ops;
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 43 union {
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 44 void __iomem *win; /* 64-bit single mapping */
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 45 void __iomem **winp; /* 32-bit per-bus mapping */
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 46 };
5c3d14f7 include/linux/pci-ecam.h Jayachandran C 2016-06-10 47 struct device *parent;/* ECAM res was from this dev */
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 48 };
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 49
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 50 /* create and free pci_config_window */
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 51 struct pci_config_window *pci_ecam_create(struct device *dev,
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 52 struct resource *cfgres, struct resource *busr,
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 53 struct pci_ecam_ops *ops);
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 54 void pci_ecam_free(struct pci_config_window *cfg);
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 55
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 56 /* map_bus when ->sysdata is an instance of pci_config_window */
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 @57 void __iomem *pci_ecam_map_bus(struct pci_bus *bus, unsigned int devfn,
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 58 int where);
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 59 /* default ECAM ops */
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 60 extern struct pci_ecam_ops pci_generic_ecam_ops;
:::::: The code at line 29 was first introduced by commit
:::::: 35ff9477d880986441981010585399c1d7201fee PCI: Provide common functions for ECAM mapping
:::::: TO: Jayachandran C <jchandra@broadcom.com>
:::::: CC: Bjorn Helgaas <bhelgaas@google.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 59492 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC v2 0/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0
From: Geert Uytterhoeven @ 2017-03-30 12:08 UTC (permalink / raw)
To: Sjoerd Simons
Cc: Geert Uytterhoeven, Simon Horman, Magnus Damm, Yoshihiro Shimoda,
Kuninori Morimoto, Laurent Pinchart, Wolfram Sang, Rob Herring,
Mark Rutland, Linux-Renesas, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Daniel Stone, Kevin Hilman
In-Reply-To: <1490874625.3471.6.camel@collabora.co.uk>
Hi Sjoerd,
On Thu, Mar 30, 2017 at 1:50 PM, Sjoerd Simons
<sjoerd.simons@collabora.co.uk> wrote:
> On Thu, 2017-03-30 at 13:13 +0200, Geert Uytterhoeven wrote:
>> On Thu, Mar 30, 2017 at 12:48 PM, Sjoerd Simons
>> <sjoerd.simons@collabora.co.uk> wrote:
>> > On Fri, 2017-03-24 at 14:37 +0100, Geert Uytterhoeven wrote:
>> > > This patch series adds preliminary support for Renesas Salvator-X
>> > > development boards equipped with revision ES2.0 of the R-Car H3
>> > > Soc.
>> > >
>> > > - Patch 1 adds support for the R-Car H3 ES2.0 Soc,
>> > > While this patch is safe as-is, as it doesn't affect any
>> > > existing
>> > > setups, it's probably a bit premature to apply it.
>> > > - Patch 2 adds support for Salvator-X boards with R-Car H3
>> > > ES2.0.
>> > > This patch does affect existing development setups, as it
>> > > changes
>> > > the
>> > > name of the DTB for Salvator-X boards equipped with ES1.x
>> > > SoCs.
>> > > Given most developers have access to ES1.x only, this patch
>> > > must
>> > > not be
>> > > applied yet.
>> >
>> > Would it make more sense to add a new r8a7795-es2.dtsi and keep the
>> > current dtsi for es1? Having to load different device-trees based
>> > on
>> > which kernel is used would be rather nasty.
>>
>> We definitely considered that option.
>> However, we concluded that in the end, we want to mainly support
>> production
>> SoCs. Hence the default files should represent the production
>> version.
>> Using a preproduction SoC can be considered a special case, and thus
>> needs
>> a file with a special esX ID in its name.
>
> The problem is that even though they are pre-production, these are out
> there and in active use, e.g. kernelci is at least doing automated
> testing on one of those in Kevins lab and should be an additional
> soonish in the Collabora lab.
>
> And for developers it'll be extra fun if halfway through a bisect the
> dts name changes..
>
> Having a es2 in your dtb name might be a bit quirky, but it's really
> just a name without other meaning :).
>
>> We do realize this can cause some inconveniences during the
>> transition period,
>> when most developers don't have access to ES2.0 SoCs yet, or have
>> mixed
>> environments of ES1.x and ES2.0.
>
> Heh yeah, i'd expect we'd have a mixed environment for quite a while
> given these boards are a bit too expensive to just throw in the trash..
>
>> Of course you can keep on using the current DTB (binary) on your H3
>> ES1.x
>> boards, as long as you don't need to use devices not yet described in
>> that DTB.
We can keep on discussing this for a while, this is definitely v4.13+ material.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.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
^ permalink raw reply
* Re: [PATCH 1/3] pinctrl: Add bindings for ARTPEC-6 pinmux
From: Linus Walleij @ 2017-03-30 11:53 UTC (permalink / raw)
To: Jesper Nilsson
Cc: Jesper Nilsson, Lars Persson, Niklas Cassel, Rob Herring,
Mark Rutland, Greg Kroah-Hartman, David S. Miller,
Geert Uytterhoeven, Mauro Carvalho Chehab, linux-arm-kernel,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20170330112744.GE29118@axis.com>
On Thu, Mar 30, 2017 at 1:27 PM, Jesper Nilsson <jesper.nilsson@axis.com> wrote:
> Add the bindings for the pinmux functions in the
> ARTPEC-6 SoC, including bias and drive strength.
>
> Signed-off-by: Jesper Nilsson <jesper.nilsson@axis.com>
Pretty much ideal bindings. Just giving some slack for the DT
maintainers to look at it first.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] ARM: dts: da850: move spi0_cs3_pin pinconf node
From: Sekhar Nori @ 2017-03-30 11:52 UTC (permalink / raw)
To: David Lechner, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Kevin Hilman, Rob Herring, Mark Rutland,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1490663566-23062-1-git-send-email-david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
On Tuesday 28 March 2017 06:42 AM, David Lechner wrote:
> This moves the spi0_cs3_pin pinconf node from the LEGO EV3 file to the
> common DA850 include file. This node is applicable to any board, and
> therefore belongs in the common file.
>
> Signed-off-by: David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
Applied for v4.12
Thanks,
Sekhar
--
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 0/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0
From: Sjoerd Simons @ 2017-03-30 11:50 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Geert Uytterhoeven, Simon Horman, Magnus Damm, Yoshihiro Shimoda,
Kuninori Morimoto, Laurent Pinchart, Wolfram Sang, Rob Herring,
Mark Rutland, Linux-Renesas, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Daniel Stone, Kevin Hilman
In-Reply-To: <CAMuHMdV+=pNpFO7H3J0=JM1BnXtm4t=Q+1bx=R+f9=JxvJZT_Q@mail.gmail.com>
On Thu, 2017-03-30 at 13:13 +0200, Geert Uytterhoeven wrote:
> Hi Sjoerd,
>
> On Thu, Mar 30, 2017 at 12:48 PM, Sjoerd Simons
> <sjoerd.simons@collabora.co.uk> wrote:
> > On Fri, 2017-03-24 at 14:37 +0100, Geert Uytterhoeven wrote:
> > > This patch series adds preliminary support for Renesas Salvator-X
> > > development boards equipped with revision ES2.0 of the R-Car H3
> > > Soc.
> > >
> > > - Patch 1 adds support for the R-Car H3 ES2.0 Soc,
> > > While this patch is safe as-is, as it doesn't affect any
> > > existing
> > > setups, it's probably a bit premature to apply it.
> > > - Patch 2 adds support for Salvator-X boards with R-Car H3
> > > ES2.0.
> > > This patch does affect existing development setups, as it
> > > changes
> > > the
> > > name of the DTB for Salvator-X boards equipped with ES1.x
> > > SoCs.
> > > Given most developers have access to ES1.x only, this patch
> > > must
> > > not be
> > > applied yet.
> >
> > Would it make more sense to add a new r8a7795-es2.dtsi and keep the
> > current dtsi for es1? Having to load different device-trees based
> > on
> > which kernel is used would be rather nasty.
>
> We definitely considered that option.
> However, we concluded that in the end, we want to mainly support
> production
> SoCs. Hence the default files should represent the production
> version.
> Using a preproduction SoC can be considered a special case, and thus
> needs
> a file with a special esX ID in its name.
The problem is that even though they are pre-production, these are out
there and in active use, e.g. kernelci is at least doing automated
testing on one of those in Kevins lab and should be an additional
soonish in the Collabora lab.
And for developers it'll be extra fun if halfway through a bisect the
dts name changes..
Having a es2 in your dtb name might be a bit quirky, but it's really
just a name without other meaning :).
> We do realize this can cause some inconveniences during the
> transition period,
> when most developers don't have access to ES2.0 SoCs yet, or have
> mixed
> environments of ES1.x and ES2.0.
Heh yeah, i'd expect we'd have a mixed environment for quite a while
given these boards are a bit too expensive to just throw in the trash..
> Of course you can keep on using the current DTB (binary) on your H3
> ES1.x
> boards, as long as you don't need to use devices not yet described in
> that DTB.
>
> Thanks!
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linu
> x-m68k.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
--
Sjoerd Simons
Collabora Ltd.
^ permalink raw reply
* Re: [PATCHv2] phy: cpcap-usb: Add CPCAP PMIC USB support
From: Kishon Vijay Abraham I @ 2017-03-30 11:49 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Marcel Partap, Michael Scott
In-Reply-To: <20170327150518.GH10760-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Hi Tony,
On Monday 27 March 2017 08:35 PM, Tony Lindgren wrote:
> * Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org> [170326 23:27]:
>> On Thursday 23 March 2017 05:16 AM, Tony Lindgren wrote:
>>> +static const struct phy_ops ops = {
>>> + .owner = THIS_MODULE,
>>> +};
>>
>> Given that this phy doesn't have any phy_ops, Is there a reason for registering
>> this phy with the phy framework? Is it because this driver uses the phy_core's
>> pm_runtime feature?
>
> Well there's also an ULPI PHY on CPCAP, but it's not used in the
> motorola-mapphone configuration. I think some other configurations
> use it though, so probably best to keep it.
>
> And yeah, for PM runtime, I was thinking that we can have the
> UART mode be the idle state.
>
>>> +static void cpcap_usb_detect(struct work_struct *work)
>>> +{
>>> + struct cpcap_phy_ddata *ddata;
>>> + struct cpcap_usb_ints_state s;
>>> + bool vbus = false;
>>> + int error;
>>> +
>>> + ddata = container_of(work, struct cpcap_phy_ddata, detect_work.work);
>>> +
>>> + error = cpcap_phy_get_ints_state(ddata, &s);
>>> + if (error)
>>> + return;
>>> +
>>> + /* See also cpcap-charger.c phy_companion for VBUS handling */
>>
>> I think this companion should have ideally used extcon framework. Then we could
>> have used extcon_get_state() here.
>
> OK I'll take a look at that. I'd like to do that as a follow-up
> patches if that's OK with you.
>
> FYI in case you're wondering, there are ADCs on the PMIC available
> via IIO, and the charger is also using IIO framework for VBUS and
> battery voltage. And the VBUS is set up as reverse mode in the
> charger registers and the charging needs to be disabled for VBUS.
>
> I guess Ideally the VBUS would be just a regulator from Linux point
> of view that also allows negative current :)
>
>>> + ddata->vusb = devm_regulator_get(&pdev->dev, "vusb");
>>> + if (IS_ERR(ddata->vusb))
>>> + return PTR_ERR(ddata->vusb);
>>> +
>>> + error = regulator_enable(ddata->vusb);
>>> + if (error)
>>> + return error;
>>
>> Maybe we should create power_on ops and do regulator enable there?
>
> This regulator is also needed for the UART mode, so it would have
> to be disabled conditionally based on maybe a module parameter.
> But yeah thanks for the pointer I did not even realize you have
> power_on ops :)
>
> Seems this can be also done when implementing PM runtime handling.
> If you want some of these changes done for the initial patch,
> please let me know.
I think it's better we get extcon stuff in the initial patch so that we don't
have to maintain some piece of code for legacy dt. Others can be added later.
Thanks
Kishon
--
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 3/3] ARM: dts: ARTPEC-6: Add pinctrl configuration
From: Jesper Nilsson @ 2017-03-30 11:33 UTC (permalink / raw)
To: Jesper Nilsson, Lars Persson, Niklas Cassel, Rob Herring,
Mark Rutland, Russell King, linux-arm-kernel-VrBV9hrLPhE,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Enable the pinctrl driver for ARTPEC-6 in the artpec6.dtsi
with all main pinmux functions.
Add pinctrl information to the relevant (uart) nodes.
Signed-off-by: Jesper Nilsson <jesper.nilsson-VrBV9hrLPhE@public.gmane.org>
---
arch/arm/boot/dts/artpec6.dtsi | 87 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 87 insertions(+)
diff --git a/arch/arm/boot/dts/artpec6.dtsi b/arch/arm/boot/dts/artpec6.dtsi
index 767cbe8..471eaee 100644
--- a/arch/arm/boot/dts/artpec6.dtsi
+++ b/arch/arm/boot/dts/artpec6.dtsi
@@ -181,6 +181,85 @@
status = "disabled";
};
+ pinctrl: pinctrl@f801d000 {
+ compatible = "axis,artpec6-pinctrl";
+ reg = <0xf801d000 0x400>;
+
+ pinctrl_uart0: uart0grp {
+ function = "uart0";
+ groups = "uart0grp1";
+ bias-pull-up;
+ };
+ pinctrl_uart1: uart1grp {
+ function = "uart1";
+ groups = "uart1grp0";
+ bias-pull-up;
+ };
+ pinctrl_uart2: uart2grp {
+ function = "uart2";
+ groups = "uart2grp1";
+ bias-pull-up;
+ };
+ pinctrl_uart3: uart3grp {
+ function = "uart3";
+ groups = "uart3grp0";
+ bias-pull-up;
+ };
+ pinctrl_uart4: uart4grp {
+ function = "uart4";
+ groups = "uart4grp0";
+ bias-pull-up;
+ };
+ pinctrl_uart5: uart5grp {
+ function = "uart5";
+ groups = "uart5grp0";
+ bias-pull-up;
+ };
+ pinctrl_i2c1: i2c1grp {
+ function = "i2c1";
+ groups = "i2c1grp0";
+ bias-pull-up;
+ };
+ pinctrl_i2c2: i2c2grp {
+ function = "i2c2";
+ groups = "i2c2grp0";
+ bias-pull-up;
+ };
+ pinctrl_i2c3: i2c3grp {
+ function = "i2c3";
+ groups = "i2c3grp0";
+ bias-pull-up;
+ };
+ pinctrl_i2s0: i2s0grp {
+ function = "i2s0";
+ groups = "i2s0grp0";
+ bias-pull-up;
+ };
+ pinctrl_i2s1: i2s1grp {
+ function = "i2s1";
+ groups = "i2s1grp0";
+ bias-pull-up;
+ };
+ pinctrl_spi0: spi0grp {
+ function = "spi0";
+ groups = "spi0grp0";
+ bias-pull-up;
+ };
+ pinctrl_spi1: spi1grp {
+ function = "spi1";
+ groups = "spi1grp0";
+ bias-pull-up;
+ };
+ pinctrl_sdio0: sdio0grp {
+ function = "sdio0";
+ groups = "sdio0grp0";
+ };
+ pinctrl_sdio1: sdio1grp {
+ function = "sdio1";
+ groups = "sdio1grp0";
+ };
+ };
+
amba@0 {
compatible = "simple-bus";
#address-cells = <0x1>;
@@ -214,6 +293,8 @@
clocks = <&clkctrl ARTPEC6_CLK_UART_REFCLK>,
<&clkctrl ARTPEC6_CLK_UART_PCLK>;
clock-names = "uart_clk", "apb_pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart0>;
status = "disabled";
};
uart1: serial@f8037000 {
@@ -223,6 +304,8 @@
clocks = <&clkctrl ARTPEC6_CLK_UART_REFCLK>,
<&clkctrl ARTPEC6_CLK_UART_PCLK>;
clock-names = "uart_clk", "apb_pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
status = "disabled";
};
uart2: serial@f8038000 {
@@ -232,6 +315,8 @@
clocks = <&clkctrl ARTPEC6_CLK_UART_REFCLK>,
<&clkctrl ARTPEC6_CLK_UART_PCLK>;
clock-names = "uart_clk", "apb_pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
status = "disabled";
};
uart3: serial@f8039000 {
@@ -241,6 +326,8 @@
clocks = <&clkctrl ARTPEC6_CLK_UART_REFCLK>,
<&clkctrl ARTPEC6_CLK_UART_PCLK>;
clock-names = "uart_clk", "apb_pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart3>;
status = "disabled";
};
};
--
2.1.4
Reply-To:
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson-VrBV9hrLPhE@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 related
* [PATCH 1/3] pinctrl: Add bindings for ARTPEC-6 pinmux
From: Jesper Nilsson @ 2017-03-30 11:27 UTC (permalink / raw)
To: Jesper Nilsson, Lars Persson, Niklas Cassel, Linus Walleij,
Rob Herring, Mark Rutland, Greg Kroah-Hartman, David S. Miller,
Geert Uytterhoeven, Mauro Carvalho Chehab,
linux-arm-kernel-VrBV9hrLPhE, linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Add the bindings for the pinmux functions in the
ARTPEC-6 SoC, including bias and drive strength.
Signed-off-by: Jesper Nilsson <jesper.nilsson-VrBV9hrLPhE@public.gmane.org>
---
.../bindings/pinctrl/axis,artpec6-pinctrl.txt | 85 ++++++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 86 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt
diff --git a/Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt
new file mode 100644
index 0000000..47284f8
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt
@@ -0,0 +1,85 @@
+Axis ARTPEC-6 Pin Controller
+
+Required properties:
+- compatible: "axis,artpec6-pinctrl".
+- reg: Should contain the register physical address and length for the pin
+ controller.
+
+A pinctrl node should contain at least one subnode representing the pinctrl
+groups available on the machine. Each subnode will list the mux function
+required and what pin group it will use. Each subnode will also configure the
+drive strength and bias pullup of the pin group. If either of these options is
+not set, its actual value will be unspecified.
+
+
+Required subnode-properties:
+- function: Function to mux.
+- groups: Name of the pin group to use for the function above.
+
+ Available functions and groups (function: group0, group1...):
+ gpio: cpuclkoutgrp0, udlclkoutgrp0, i2c1grp0, i2c2grp0,
+ i2c3grp0, i2s0grp0, i2s1grp0, i2srefclkgrp0, spi0grp0,
+ spi1grp0, pciedebuggrp0, uart0grp0, uart0grp1, uart1grp0,
+ uart2grp0, uart2grp1, uart3grp0, uart4grp0, uart5grp0
+ cpuclkout: cpuclkoutgrp0
+ udlclkout: udlclkoutgrp0
+ i2c1: i2c1grp0
+ i2c2: i2c2grp0
+ i2c3: i2c3grp0
+ i2s0: i2s0grp0
+ i2s1: i2s1grp0
+ i2srefclk: i2srefclkgrp0
+ spi0: spi0grp0
+ spi1: spi1grp0
+ pciedebug: pciedebuggrp0
+ uart0: uart0grp0, uart0grp1
+ uart1: uart1grp0
+ uart2: uart2grp0, uart2grp1
+ uart3: uart3grp0
+ uart4: uart4grp0
+ uart5: uart5grp0
+ nand: nandgrp0
+ sdio0: sdio0grp0
+ sdio1: sdio1grp0
+ ethernet: ethernetgrp0
+
+
+Optional subnode-properties (see pinctrl-bindings.txt):
+- drive-strength: 4, 6, 8, 9 mA. For SD and NAND pins, this is for 3.3V VCCQ3.
+- bias-pull-up
+- bias-disable
+
+Examples:
+pinctrl@f801d000 {
+ compatible = "axis,artpec6-pinctrl";
+ reg = <0xf801d000 0x400>;
+
+ pinctrl_uart0: uart0grp {
+ function = "uart0";
+ groups = "uart0grp0";
+ drive-strength = <4>;
+ bias-pull-up;
+ };
+ pinctrl_uart3: uart3grp {
+ function = "uart3";
+ groups = "uart3grp0";
+ };
+};
+uart0: uart@f8036000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0xf8036000 0x1000>;
+ interrupts = <0 104 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&pll2div24>, <&apb_pclk>;
+ clock-names = "uart_clk", "apb_pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart0>;
+};
+uart3: uart@f8039000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0xf8039000 0x1000>;
+ interrupts = <0 128 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&pll2div24>, <&apb_pclk>;
+ clock-names = "uart_clk", "apb_pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart3>;
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 1b0a87f..7563bd6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1088,6 +1088,7 @@ L: linux-arm-kernel-VrBV9hrLPhE@public.gmane.org
F: arch/arm/mach-artpec
F: arch/arm/boot/dts/artpec6*
F: drivers/clk/axis
+F: Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt
ARM/ASPEED MACHINE SUPPORT
M: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
--
2.1.4
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson-VrBV9hrLPhE@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 related
* [PATCHv4 25/29] drm/omap: displays: panel-dpi: Support for handling backlight devices
From: Tomi Valkeinen @ 2017-03-30 11:15 UTC (permalink / raw)
To: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Laurent Pinchart
Cc: Jyri Sarha, Peter Ujfalusi, Tomi Valkeinen,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1490872529-23084-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
From: Peter Ujfalusi <peter.ujfalusi-l0cyMroinI0@public.gmane.org>
The associated backlight device can be configured via DT by providing the
phandle to the device.
If the backlight device is configured, the driver can manage the backligt
along with the panel's power state, iow it can turn on the backlight when
the panel is enabled and turn it off when the panel is disabled.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi-l0cyMroinI0@public.gmane.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
.../bindings/display/panel/panel-dpi.txt | 3 ++
drivers/gpu/drm/omapdrm/displays/panel-dpi.c | 37 ++++++++++++++++++++--
2 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
index d4add13e592d..6b203bc4d932 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
+++ b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
@@ -9,6 +9,7 @@ Optional properties:
- enable-gpios: panel enable gpio
- reset-gpios: GPIO to control the RESET pin
- vcc-supply: phandle of regulator that will be used to enable power to the display
+- backlight: phandle of the backlight device
Required nodes:
- "panel-timing" containing video timings
@@ -22,6 +23,8 @@ lcd0: display@0 {
compatible = "samsung,lte430wq-f0c", "panel-dpi";
label = "lcd";
+ backlight = <&backlight>;
+
port {
lcd_in: endpoint {
remote-endpoint = <&dpi_out>;
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
index 38003208d9ca..04ce8c5f2954 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
@@ -16,6 +16,7 @@
#include <linux/of.h>
#include <linux/of_gpio.h>
#include <linux/regulator/consumer.h>
+#include <linux/backlight.h>
#include <video/omap-panel-data.h>
#include <video/of_display_timing.h>
@@ -30,6 +31,8 @@ struct panel_drv_data {
struct videomode vm;
+ struct backlight_device *backlight;
+
/* used for non-DT boot, to be removed */
int backlight_gpio;
@@ -97,6 +100,11 @@ static int panel_dpi_enable(struct omap_dss_device *dssdev)
if (gpio_is_valid(ddata->backlight_gpio))
gpio_set_value_cansleep(ddata->backlight_gpio, 1);
+ if (ddata->backlight) {
+ ddata->backlight->props.power = FB_BLANK_UNBLANK;
+ backlight_update_status(ddata->backlight);
+ }
+
dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
return 0;
@@ -113,6 +121,11 @@ static void panel_dpi_disable(struct omap_dss_device *dssdev)
if (gpio_is_valid(ddata->backlight_gpio))
gpio_set_value_cansleep(ddata->backlight_gpio, 0);
+ if (ddata->backlight) {
+ ddata->backlight->props.power = FB_BLANK_POWERDOWN;
+ backlight_update_status(ddata->backlight);
+ }
+
gpiod_set_value_cansleep(ddata->enable_gpio, 0);
regulator_disable(ddata->vcc_supply);
@@ -209,6 +222,7 @@ static int panel_dpi_probe_of(struct platform_device *pdev)
{
struct panel_drv_data *ddata = platform_get_drvdata(pdev);
struct device_node *node = pdev->dev.of_node;
+ struct device_node *bl_node;
struct omap_dss_device *in;
int r;
struct display_timing timing;
@@ -236,10 +250,19 @@ static int panel_dpi_probe_of(struct platform_device *pdev)
ddata->backlight_gpio = -ENOENT;
+ bl_node = of_parse_phandle(node, "backlight", 0);
+ if (bl_node) {
+ ddata->backlight = of_find_backlight_by_node(bl_node);
+ of_node_put(bl_node);
+
+ if (!ddata->backlight)
+ return -EPROBE_DEFER;
+ }
+
r = of_get_display_timing(node, "panel-timing", &timing);
if (r) {
dev_err(&pdev->dev, "failed to get video timing\n");
- return r;
+ goto error_free_backlight;
}
videomode_from_timing(&timing, &ddata->vm);
@@ -247,12 +270,19 @@ static int panel_dpi_probe_of(struct platform_device *pdev)
in = omapdss_of_find_source_for_first_ep(node);
if (IS_ERR(in)) {
dev_err(&pdev->dev, "failed to find video source\n");
- return PTR_ERR(in);
+ r = PTR_ERR(in);
+ goto error_free_backlight;
}
ddata->in = in;
return 0;
+
+error_free_backlight:
+ if (ddata->backlight)
+ put_device(&ddata->backlight->dev);
+
+ return r;
}
static int panel_dpi_probe(struct platform_device *pdev)
@@ -321,6 +351,9 @@ static int __exit panel_dpi_remove(struct platform_device *pdev)
omap_dss_put_device(in);
+ if (ddata->backlight)
+ put_device(&ddata->backlight->dev);
+
return 0;
}
--
2.7.4
--
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/RFC v2 0/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0
From: Geert Uytterhoeven @ 2017-03-30 11:13 UTC (permalink / raw)
To: Sjoerd Simons
Cc: Geert Uytterhoeven, Simon Horman, Magnus Damm, Yoshihiro Shimoda,
Kuninori Morimoto, Laurent Pinchart, Wolfram Sang, Rob Herring,
Mark Rutland, Linux-Renesas,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <1490870898.3471.3.camel-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
Hi Sjoerd,
On Thu, Mar 30, 2017 at 12:48 PM, Sjoerd Simons
<sjoerd.simons-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org> wrote:
> On Fri, 2017-03-24 at 14:37 +0100, Geert Uytterhoeven wrote:
>> This patch series adds preliminary support for Renesas Salvator-X
>> development boards equipped with revision ES2.0 of the R-Car H3 Soc.
>>
>> - Patch 1 adds support for the R-Car H3 ES2.0 Soc,
>> While this patch is safe as-is, as it doesn't affect any existing
>> setups, it's probably a bit premature to apply it.
>> - Patch 2 adds support for Salvator-X boards with R-Car H3 ES2.0.
>> This patch does affect existing development setups, as it changes
>> the
>> name of the DTB for Salvator-X boards equipped with ES1.x SoCs.
>> Given most developers have access to ES1.x only, this patch must
>> not be
>> applied yet.
>
> Would it make more sense to add a new r8a7795-es2.dtsi and keep the
> current dtsi for es1? Having to load different device-trees based on
> which kernel is used would be rather nasty.
We definitely considered that option.
However, we concluded that in the end, we want to mainly support production
SoCs. Hence the default files should represent the production version.
Using a preproduction SoC can be considered a special case, and thus needs
a file with a special esX ID in its name.
We do realize this can cause some inconveniences during the transition period,
when most developers don't have access to ES2.0 SoCs yet, or have mixed
environments of ES1.x and ES2.0.
Of course you can keep on using the current DTB (binary) on your H3 ES1.x
boards, as long as you don't need to use devices not yet described in that DTB.
Thanks!
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
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