* [PATCH v2 08/11] ARM: dts: imx7s: Add unit address and reg for the anatop nodes
From: Fabio Estevam @ 2017-11-29 18:54 UTC (permalink / raw)
To: shawnguo-DgEjT+Ai2ygdnm+yROfE0A
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Fabio Estevam
In-Reply-To: <1511981684-13433-1-git-send-email-festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
Add unit address and reg for the anatop nodes in order to fix the
following build warnings with W=1:
arch/arm/boot/dts/imx7d-cl-som-imx7.dtb: Warning (simple_bus_reg): Node /soc/aips-bus@30000000/anatop@30360000/regulator-vdd1p0d missing or empty reg/ranges property
Signed-off-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
---
Changes since v1:
- None
arch/arm/boot/dts/imx7s.dtsi | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 81467ac..2ceb37d 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -522,8 +522,11 @@
reg = <0x30360000 0x10000>;
interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
- reg_1p0d: regulator-vdd1p0d {
+ reg_1p0d: regulator-vdd1p0d@30360210 {
+ reg = <0x30360210>;
compatible = "fsl,anatop-regulator";
regulator-name = "vdd1p0d";
regulator-min-microvolt = <800000>;
--
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
* [PATCH v2 09/11] ARM: dts: vfxxx: Move nodes which have no reg property out of bus
From: Fabio Estevam @ 2017-11-29 18:54 UTC (permalink / raw)
To: shawnguo-DgEjT+Ai2ygdnm+yROfE0A
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Fabio Estevam
In-Reply-To: <1511981684-13433-1-git-send-email-festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
Move iio-hwmon node from soc node to root node.
iio-hwmon node does not have any register properties and thus
shouldn't be placed on the bus.
This fixes the following build warnings with W=1:
arch/arm/boot/dts/vf500-colibri-eval-v3.dtb: Warning (simple_bus_reg): Node /soc/iio-hwmon missing or empty reg/ranges property
Based on a patch from Simon Horman for the renesas r8a7795 dtsi.
Signed-off-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
---
Changes since v1:
- None
arch/arm/boot/dts/vfxxx.dtsi | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 5d654b5..c3f09b7 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -84,6 +84,11 @@
mask = <0x1000>;
};
+ iio-hwmon {
+ compatible = "iio-hwmon";
+ io-channels = <&adc0 16>, <&adc1 16>;
+ };
+
soc {
#address-cells = <1>;
#size-cells = <1>;
@@ -762,10 +767,5 @@
status = "disabled";
};
};
-
- iio-hwmon {
- compatible = "iio-hwmon";
- io-channels = <&adc0 16>, <&adc1 16>;
- };
};
};
--
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
* [PATCH v2 10/11] ARM: dts: imx6sx: Fix spba-bus unit address
From: Fabio Estevam @ 2017-11-29 18:54 UTC (permalink / raw)
To: shawnguo-DgEjT+Ai2ygdnm+yROfE0A
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Fabio Estevam
In-Reply-To: <1511981684-13433-1-git-send-email-festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
The correct unit address for spba-bus is 0x2240000, so change it
accordingly in order to fix the following build warning with W=1:
arch/arm/boot/dts/imx6sx-sabreauto.dtb: Warning (simple_bus_reg): Node /soc/aips-bus@2200000/spba-bus@2200000 simple-bus unit address format error, expected "2240000"
Signed-off-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
---
arch/arm/boot/dts/imx6sx.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 07ba518..5a5f796 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -1150,7 +1150,7 @@
reg = <0x02200000 0x100000>;
ranges;
- spba-bus@2200000 {
+ spba-bus@2240000 {
compatible = "fsl,spba-bus", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
--
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
* [PATCH v2 11/11] ARM: dts: vf500: Fix interrupt-controller unit address
From: Fabio Estevam @ 2017-11-29 18:54 UTC (permalink / raw)
To: shawnguo-DgEjT+Ai2ygdnm+yROfE0A
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Fabio Estevam
In-Reply-To: <1511981684-13433-1-git-send-email-festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
The correct unit address for interrupt-controller is 0x40003000, so
change it accordingly in order to fix the following build warning
with W=1:
arch/arm/boot/dts/vf500-colibri-eval-v3.dtb: Warning (simple_bus_reg): Node /soc/aips-bus@40000000/interrupt-controller@40002000 simple-bus unit address format error, expected "40003000"
Signed-off-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
---
Changes since v1:
- None
arch/arm/boot/dts/vf500.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/vf500.dtsi b/arch/arm/boot/dts/vf500.dtsi
index 3d98961..348bcd3 100644
--- a/arch/arm/boot/dts/vf500.dtsi
+++ b/arch/arm/boot/dts/vf500.dtsi
@@ -58,7 +58,7 @@
soc {
aips-bus@40000000 {
- intc: interrupt-controller@40002000 {
+ intc: interrupt-controller@40003000 {
compatible = "arm,cortex-a9-gic";
#interrupt-cells = <3>;
interrupt-controller;
--
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 v4 7/8] netdev: octeon-ethernet: Add Cavium Octeon III support.
From: Dan Carpenter @ 2017-11-29 19:11 UTC (permalink / raw)
To: Souptick Joarder
Cc: Mark Rutland, linux-mips, devel, devicetree, netdev, David Daney,
linux-kernel, ralf, Carlos Munoz, Rob Herring, Andrew Lunn,
Steven J. Hill, Greg Kroah-Hartman, Florian Fainelli, James Hogan,
David S. Miller
In-Reply-To: <CAFqt6zZAPxKm663yEHD0Rx2SPye9Nvoax0RMroDQuF8BpZchsA@mail.gmail.com>
On Wed, Nov 29, 2017 at 09:37:15PM +0530, Souptick Joarder wrote:
> >> +static int bgx_port_sgmii_set_link_speed(struct bgx_port_priv *priv, struct port_status status)
> >> +{
> >> + u64 data;
> >> + u64 prtx;
> >> + u64 miscx;
> >> + int timeout;
> >> +
>
> >> +
> >> + switch (status.speed) {
> >> + case 10:
> >
> > In my opinion, instead of hard coding the value, is it fine to use ENUM ?
> Similar comments applicable in other places where hard coded values are used.
>
10 means 10M right? That's not really a magic number. It's fine.
> >> +static int bgx_port_init_xaui_link(struct bgx_port_priv *priv)
> >> +{
>
> >> +
> >> + if (use_ber) {
> >> + timeout = 10000;
> >> + do {
> >> + data =
> >> + oct_csr_read(BGX_SPU_BR_STATUS1(priv->node, priv->bgx, priv->index));
> >> + if (data & BIT(0))
> >> + break;
> >> + timeout--;
> >> + udelay(1);
> >> + } while (timeout);
> >
> > In my opinion, it's better to implement similar kind of loops inside macros.
I don't understand what you mean here. For what it's worth this code
seems clear enough to me (except for the bad indenting of oct_csr_read().
It should be something like:
data = oct_csr_read(BGX_SPU_BR_STATUS1(priv->node,
priv->bgx, priv->index));
That's over the 80 char limit but so is the original code.
regards,
dan carpenter
^ permalink raw reply
* [PATCH] of: overlay: fix memory leak of ovcs on error exit path
From: Colin King @ 2017-11-29 19:17 UTC (permalink / raw)
To: Pantelis Antoniou, Rob Herring, Frank Rowand,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: kernel-janitors-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
From: Colin Ian King <colin.king-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
Currently if the call to of_resolve_phandles fails then then ovcs
is not kfree'd on the error exit path. Rather than try and make
the clean up exit path more convoluted, fix this by just kfree'ing
ovcs at the point of error detection and exit via the same exit
path.
Detected by CoverityScan, CID#1462296 ("Resource Leak")
Fixes: f948d6d8b792 ("of: overlay: avoid race condition between applying multiple overlays")
Signed-off-by: Colin Ian King <colin.king-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
---
drivers/of/overlay.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index 53bc9e3f0b98..6c8efe7d8cbb 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -708,8 +708,10 @@ int of_overlay_apply(struct device_node *tree, int *ovcs_id)
of_overlay_mutex_lock();
ret = of_resolve_phandles(tree);
- if (ret)
+ if (ret) {
+ kfree(ovcs);
goto err_overlay_unlock;
+ }
mutex_lock(&of_mutex);
--
2.14.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 7/8] netdev: octeon-ethernet: Add Cavium Octeon III support.
From: David Daney @ 2017-11-29 19:20 UTC (permalink / raw)
To: Souptick Joarder, David Daney
Cc: linux-mips-6z/3iImG2C8G8FEW9MqTrA, ralf-6z/3iImG2C8G8FEW9MqTrA,
James Hogan, netdev-u79uwXL29TY76Z2rM5mHXA, David S. Miller,
Rob Herring, Mark Rutland, devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
Greg Kroah-Hartman, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Steven J. Hill, devicetree-u79uwXL29TY76Z2rM5mHXA, Andrew Lunn,
Florian Fainelli, Carlos Munoz
In-Reply-To: <CAFqt6zZAPxKm663yEHD0Rx2SPye9Nvoax0RMroDQuF8BpZchsA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 11/29/2017 08:07 AM, Souptick Joarder wrote:
> On Wed, Nov 29, 2017 at 4:00 PM, Souptick Joarder <jrdr.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Wed, Nov 29, 2017 at 6:25 AM, David Daney <david.daney-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org> wrote:
>>> From: Carlos Munoz <cmunoz-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
>>>
>>> The Cavium OCTEON cn78xx and cn73xx SoCs have network packet I/O
>>> hardware that is significantly different from previous generations of
>>> the family.
>
>>> diff --git a/drivers/net/ethernet/cavium/octeon/octeon3-bgx-port.c b/drivers/net/ethernet/cavium/octeon/octeon3-bgx-port.c
>>> new file mode 100644
>>> index 000000000000..4dad35fa4270
>>> --- /dev/null
>>> +++ b/drivers/net/ethernet/cavium/octeon/octeon3-bgx-port.c
>>> @@ -0,0 +1,2033 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/* Copyright (c) 2017 Cavium, Inc.
>>> + *
>>> + * This file is subject to the terms and conditions of the GNU General Public
>>> + * License. See the file "COPYING" in the main directory of this archive
>>> + * for more details.
>>> + */
>>> +#include <linux/platform_device.h>
>>> +#include <linux/netdevice.h>
>>> +#include <linux/etherdevice.h>
>>> +#include <linux/of_platform.h>
>>> +#include <linux/of_address.h>
>>> +#include <linux/of_mdio.h>
>>> +#include <linux/of_net.h>
>>> +#include <linux/module.h>
>>> +#include <linux/slab.h>
>>> +#include <linux/list.h>
>>> +
>
>>> +static void bgx_port_sgmii_set_link_down(struct bgx_port_priv *priv)
>>> +{
>>> + u64 data;
>
>>> + data = oct_csr_read(BGX_GMP_PCS_MISC_CTL(priv->node, priv->bgx, priv->index));
>>> + data |= BIT(11);
>>> + oct_csr_write(data, BGX_GMP_PCS_MISC_CTL(priv->node, priv->bgx, priv->index));
>>> + data = oct_csr_read(BGX_GMP_PCS_MISC_CTL(priv->node, priv->bgx, priv->index));
>>
>> Any particular reason to read immediately after write ?
>
Yes, to ensure the write is committed to hardware before the next step.
>
>
>>> +static int bgx_port_sgmii_set_link_speed(struct bgx_port_priv *priv, struct port_status status)
>>> +{
>>> + u64 data;
>>> + u64 prtx;
>>> + u64 miscx;
>>> + int timeout;
>>> +
>
>>> +
>>> + switch (status.speed) {
>>> + case 10:
>>
>> In my opinion, instead of hard coding the value, is it fine to use ENUM ?
> Similar comments applicable in other places where hard coded values are used.
>
There is nothing to be gained by interposing an extra layer of
abstraction in this case. The code is more clear with the raw numbers
in this particular case.
>
>
>>> +static int bgx_port_gser_27882(struct bgx_port_priv *priv)
>>> +{
>>> + u64 data;
>>> + u64 addr;
>>
>>> + int timeout = 200;
>>> +
>>> + // timeout = 200;
> Better to initialize the timeout value
What are you talking about? It is properly initialized using valid C code.
>
>
>>> +static int bgx_port_qlm_rx_equalization(struct bgx_port_priv *priv, int qlm, int lane)
>>> +{
>>> + lmode = oct_csr_read(GSER_LANE_MODE(priv->node, qlm));
>>> + lmode &= 0xf;
>>> + addr = GSER_LANE_P_MODE_1(priv->node, qlm, lmode);
>>> + data = oct_csr_read(addr);
>>> + /* Don't complete rx equalization if in VMA manual mode */
>>> + if (data & BIT(14))
>>> + return 0;
>>> +
>>> + /* Apply rx equalization for speed > 6250 */
>>> + if (bgx_port_get_qlm_speed(priv, qlm) < 6250)
>>> + return 0;
>>> +
>>> + /* Wait until rx data is valid (CDRLOCK) */
>>> + timeout = 500;
>>
>> 500 us is the min required value or it can be further reduced ?
>
500 uS works well and is shorter than the 2000 uS from the hardware manual.
If you would like to verify shorter timeout values, we could consider
merging such a patch. But really, this doesn't matter as it is a very
short one-off action when the link is brought up.
>
>>> +static int bgx_port_init_xaui_link(struct bgx_port_priv *priv)
>>> +{
>
>>> +
>>> + if (use_ber) {
>>> + timeout = 10000;
>>> + do {
>>> + data =
>>> + oct_csr_read(BGX_SPU_BR_STATUS1(priv->node, priv->bgx, priv->index));
>>> + if (data & BIT(0))
>>> + break;
>>> + timeout--;
>>> + udelay(1);
>>> + } while (timeout);
>>
>> In my opinion, it's better to implement similar kind of loops inside macros.
Ok, duly noted. I think we are in disagreement with respect to this point.
>>
>>> + if (!timeout) {
>>> + pr_debug("BGX%d:%d:%d: BLK_LOCK timeout\n",
>>> + priv->bgx, priv->index, priv->node);
>>> + return -1;
>>> + }
>>> + } else {
>>> + timeout = 10000;
>>> + do {
>>> + data =
>>> + oct_csr_read(BGX_SPU_BX_STATUS(priv->node, priv->bgx, priv->index));
>>> + if (data & BIT(12))
>>> + break;
>>> + timeout--;
>>> + udelay(1);
>>> + } while (timeout);
>> same here
--
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 v12 1/2] rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver documentation
From: Niklas Söderlund @ 2017-11-29 19:32 UTC (permalink / raw)
To: Laurent Pinchart, Hans Verkuil, linux-media, Sakari Ailus
Cc: linux-renesas-soc, tomoharu.fukawa.eb, Kieran Bingham,
Geert Uytterhoeven, Niklas Söderlund, Rob Herring,
devicetree
In-Reply-To: <20171129193235.25423-1-niklas.soderlund+renesas@ragnatech.se>
Documentation for Renesas R-Car MIPI CSI-2 receiver. The CSI-2 receivers
are located between the video sources (CSI-2 transmitters) and the video
grabbers (VIN) on Gen3 of Renesas R-Car SoC.
Each CSI-2 device is connected to more then one VIN device which
simultaneously can receive video from the same CSI-2 device. Each VIN
device can also be connected to more then one CSI-2 device. The routing
of which link are used are controlled by the VIN devices. There are only
a few possible routes which are set by hardware limitations, which are
different for each SoC in the Gen3 family.
To work with the limitations of routing possibilities it is necessary
for the DT bindings to describe which VIN device is connected to which
CSI-2 device. This is why port 1 needs to to assign reg numbers for each
VIN device that be connected to it. To setup and to know which links are
valid for each SoC is the responsibility of the VIN driver since the
register to configure it belongs to the VIN hardware.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Acked-by: Rob Herring <robh@kernel.org>
---
.../bindings/media/renesas,rcar-csi2.txt | 105 +++++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 106 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt
diff --git a/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt
new file mode 100644
index 0000000000000000..688afd83bf66f8cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt
@@ -0,0 +1,105 @@
+Renesas R-Car MIPI CSI-2
+------------------------
+
+The rcar-csi2 device provides MIPI CSI-2 capabilities for the Renesas R-Car
+family of devices. It is to be used in conjunction with the R-Car VIN module,
+which provides the video capture capabilities.
+
+Mandatory properties
+--------------------
+ - compatible: Must be one or more of the following
+ - "renesas,r8a7795-csi2" for the R8A7795 device.
+ - "renesas,r8a7796-csi2" for the R8A7796 device.
+
+ - reg: the register base and size for the device registers
+ - interrupts: the interrupt for the device
+ - clocks: Reference to the parent clock
+
+The device node shall contain two 'port' child nodes according to the
+bindings defined in Documentation/devicetree/bindings/media/
+video-interfaces.txt. Port 0 shall connect the node that is the video
+source for to the CSI-2. Port 1 shall connect all the R-Car VIN
+modules, which can make use of the CSI-2 module.
+
+- Port 0 - Video source (Mandatory)
+ - Endpoint 0 - sub-node describing the endpoint that is the video source
+
+- Port 1 - VIN instances (Mandatory for all VIN present in the SoC)
+ - Endpoint 0 - sub-node describing the endpoint that is VIN0
+ - Endpoint 1 - sub-node describing the endpoint that is VIN1
+ - Endpoint 2 - sub-node describing the endpoint that is VIN2
+ - Endpoint 3 - sub-node describing the endpoint that is VIN3
+ - Endpoint 4 - sub-node describing the endpoint that is VIN4
+ - Endpoint 5 - sub-node describing the endpoint that is VIN5
+ - Endpoint 6 - sub-node describing the endpoint that is VIN6
+ - Endpoint 7 - sub-node describing the endpoint that is VIN7
+
+Example:
+
+ csi20: csi2@fea80000 {
+ compatible = "renesas,r8a7796-csi2";
+ reg = <0 0xfea80000 0 0x10000>;
+ interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 714>;
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ resets = <&cpg 714>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reg = <0>;
+
+ csi20_in: endpoint@0 {
+ reg = <0>;
+ clock-lanes = <0>;
+ data-lanes = <1>;
+ remote-endpoint = <&adv7482_txb>;
+ };
+ };
+
+ port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reg = <1>;
+
+ csi20vin0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&vin0csi20>;
+ };
+ csi20vin1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&vin1csi20>;
+ };
+ csi20vin2: endpoint@2 {
+ reg = <2>;
+ remote-endpoint = <&vin2csi20>;
+ };
+ csi20vin3: endpoint@3 {
+ reg = <3>;
+ remote-endpoint = <&vin3csi20>;
+ };
+ csi20vin4: endpoint@4 {
+ reg = <4>;
+ remote-endpoint = <&vin4csi20>;
+ };
+ csi20vin5: endpoint@5 {
+ reg = <5>;
+ remote-endpoint = <&vin5csi20>;
+ };
+ csi20vin6: endpoint@6 {
+ reg = <6>;
+ remote-endpoint = <&vin6csi20>;
+ };
+ csi20vin7: endpoint@7 {
+ reg = <7>;
+ remote-endpoint = <&vin7csi20>;
+ };
+ };
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index aa71ab52fd76d160..4737de9f41bff570 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8652,6 +8652,7 @@ L: linux-media@vger.kernel.org
L: linux-renesas-soc@vger.kernel.org
T: git git://linuxtv.org/media_tree.git
S: Supported
+F: Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt
F: Documentation/devicetree/bindings/media/rcar_vin.txt
F: drivers/media/platform/rcar-vin/
--
2.15.0
^ permalink raw reply related
* Re: [PATCH v3 2/3] clk: meson-axg: add clock controller drivers
From: Stephen Boyd @ 2017-11-29 19:34 UTC (permalink / raw)
To: Yixun Lan
Cc: Neil Armstrong, Jerome Brunet, Kevin Hilman, Rob Herring,
Mark Rutland, Michael Turquette, Carlo Caione, Qiufang Dai,
linux-amlogic, devicetree, linux-clk, linux-arm-kernel,
linux-kernel
In-Reply-To: <20171128125330.363-3-yixun.lan@amlogic.com>
On 11/28, Yixun Lan wrote:
> diff --git a/drivers/clk/meson/axg.c b/drivers/clk/meson/axg.c
> new file mode 100644
> index 000000000000..51c5b4062715
> --- /dev/null
> +++ b/drivers/clk/meson/axg.c
> @@ -0,0 +1,948 @@
> +/*
> + * AmLogic Meson-AXG Clock Controller Driver
> + *
> + * Copyright (c) 2016 Baylibre SAS.
> + * Author: Michael Turquette <mturquette@baylibre.com>
> + *
> + * Copyright (c) 2017 Amlogic, inc.
> + * Author: Qiufang Dai <qiufang.dai@amlogic.com>
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/clk-provider.h>
> +#include <linux/of_address.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/init.h>
> +
> +#include "clkc.h"
> +#include "axg.h"
> +
> +static DEFINE_SPINLOCK(clk_lock);
meson_axg_clk_lock?
> +
> +static const struct pll_rate_table sys_pll_rate_table[] = {
> + PLL_RATE(24000000, 56, 1, 2),
> + PLL_RATE(48000000, 64, 1, 2),
> + PLL_RATE(72000000, 72, 1, 2),
> + PLL_RATE(96000000, 64, 1, 2),
> + PLL_RATE(120000000, 80, 1, 2),
> + PLL_RATE(144000000, 96, 1, 2),
> + PLL_RATE(168000000, 56, 1, 1),
> + PLL_RATE(192000000, 64, 1, 1),
> + PLL_RATE(216000000, 72, 1, 1),
> + PLL_RATE(240000000, 80, 1, 1),
[...]
> +
> +static const struct clkc_data axg_clkc_data = {
> + .clk_gates = axg_clk_gates,
> + .clk_gates_count = ARRAY_SIZE(axg_clk_gates),
> + .clk_mplls = axg_clk_mplls,
> + .clk_mplls_count = ARRAY_SIZE(axg_clk_mplls),
> + .clk_plls = axg_clk_plls,
> + .clk_plls_count = ARRAY_SIZE(axg_clk_plls),
> + .clk_muxes = axg_clk_muxes,
> + .clk_muxes_count = ARRAY_SIZE(axg_clk_muxes),
> + .clk_dividers = axg_clk_dividers,
> + .clk_dividers_count = ARRAY_SIZE(axg_clk_dividers),
> + .hw_onecell_data = &axg_hw_onecell_data,
> +};
> +
> +static const struct of_device_id clkc_match_table[] = {
> + { .compatible = "amlogic,axg-clkc", .data = &axg_clkc_data },
> + {},
Nitpick: Drop the comma. Nothing comes after this.
> +};
> +
> +static int axg_clkc_probe(struct platform_device *pdev)
> +{
> + const struct clkc_data *clkc_data;
> + void __iomem *clk_base;
> + int ret, clkid, i;
> + struct device *dev = &pdev->dev;
> +
> + clkc_data = of_device_get_match_data(&pdev->dev);
> + if (!clkc_data)
> + return -EINVAL;
> +
> + /* Generic clocks and PLLs */
> + clk_base = of_iomap(dev->of_node, 0);
Use platform device APIs for ioremapping?
> + if (!clk_base) {
> + pr_err("%s: Unable to map clk base\n", __func__);
> + return -ENXIO;
> + }
> +
> + /* Populate base address for PLLs */
> + for (i = 0; i < clkc_data->clk_plls_count; i++)
> + clkc_data->clk_plls[i]->base = clk_base;
> +
> + /* Populate base address for MPLLs */
> + for (i = 0; i < clkc_data->clk_mplls_count; i++)
> + clkc_data->clk_mplls[i]->base = clk_base;
> +
> + /* Populate base address for gates */
> + for (i = 0; i < clkc_data->clk_gates_count; i++)
> + clkc_data->clk_gates[i]->reg = clk_base +
> + (u64)clkc_data->clk_gates[i]->reg;
> +
> + /* Populate base address for muxes */
> + for (i = 0; i < clkc_data->clk_muxes_count; i++)
> + clkc_data->clk_muxes[i]->reg = clk_base +
> + (u64)clkc_data->clk_muxes[i]->reg;
> +
> + /* Populate base address for dividers */
> + for (i = 0; i < clkc_data->clk_dividers_count; i++)
> + clkc_data->clk_dividers[i]->reg = clk_base +
> + (u64)clkc_data->clk_dividers[i]->reg;
> +
> + /*
> + * register all clks
> + */
Yes, that's obvious..
> + for (clkid = 0; clkid < clkc_data->hw_onecell_data->num; clkid++) {
> + /* array might be sparse */
> + if (!clkc_data->hw_onecell_data->hws[clkid])
> + continue;
> +
> + ret = devm_clk_hw_register(dev,
> + clkc_data->hw_onecell_data->hws[clkid]);
> + if (ret)
> + goto iounmap;
> + }
> +
> + return of_clk_add_hw_provider(dev->of_node, of_clk_hw_onecell_get,
> + clkc_data->hw_onecell_data);
> +
> +iounmap:
> + iounmap(clk_base);
> + return ret;
> +}
> +
> +static struct platform_driver axg_driver = {
> + .probe = axg_clkc_probe,
> + .driver = {
> + .name = "axg-clkc",
> + .of_match_table = clkc_match_table,
> + },
> +};
> +
> +builtin_platform_driver(axg_driver);
> diff --git a/include/dt-bindings/clock/axg-clkc.h b/include/dt-bindings/clock/axg-clkc.h
> new file mode 100644
> index 000000000000..d2c0f49ba0df
> --- /dev/null
> +++ b/include/dt-bindings/clock/axg-clkc.h
> @@ -0,0 +1,72 @@
> +/*
> + * Meson-AXG clock tree IDs
> + *
> + * Copyright (c) 2017 Amlogic, Inc. All rights reserved.
> + *
> + * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
There's a standard way to add these it seems. They should be the
first line in the file and look like
/* SPDX-License-Identifier: */
for header files and
// SPDX-License-Identifier:
for C files.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v3 3/3] arm64: dts: meson-axg: add clock DT info for Meson AXG SoC
From: Stephen Boyd @ 2017-11-29 19:35 UTC (permalink / raw)
To: Yixun Lan
Cc: Neil Armstrong, Jerome Brunet, Kevin Hilman, Rob Herring,
Mark Rutland, Michael Turquette, Carlo Caione, Qiufang Dai,
linux-amlogic, devicetree, linux-clk, linux-arm-kernel,
linux-kernel
In-Reply-To: <20171128125330.363-4-yixun.lan@amlogic.com>
On 11/28, Yixun Lan wrote:
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> index b932a784b02a..36a2e98338a8 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> @@ -7,6 +7,7 @@
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/clock/axg-clkc.h>
>
> / {
> compatible = "amlogic,meson-axg";
> @@ -148,6 +149,20 @@
> #address-cells = <0>;
> };
>
> + hiubus: hiubus@ff63c000 {
Maybe just call the node "bus@ff63c000"?
> + compatible = "simple-bus";
> + reg = <0x0 0xff63c000 0x0 0x1c00>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges = <0x0 0x0 0x0 0xff63c000 0x0 0x1c00>;
> +
> + clkc: clock-controller@0 {
> + compatible = "amlogic,axg-clkc";
> + #clock-cells = <1>;
> + reg = <0x0 0x0 0x0 0x320>;
> + };
> + };
> +
> mailbox: mailbox@ff63dc00 {
> compatible = "amlogic,meson-gx-mhu", "amlogic,meson-gxbb-mhu";
> reg = <0 0xff63dc00 0 0x400>;
> --
> 2.15.0
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v8 01/28] rcar-vin: add Gen3 devicetree bindings documentation
From: Niklas Söderlund @ 2017-11-29 19:43 UTC (permalink / raw)
To: Laurent Pinchart, Hans Verkuil, linux-media
Cc: linux-renesas-soc, tomoharu.fukawa.eb, Kieran Bingham,
Niklas Söderlund, Rob Herring, devicetree
In-Reply-To: <20171129194342.26239-1-niklas.soderlund+renesas@ragnatech.se>
Document the devicetree bindings for the CSI-2 inputs available on Gen3.
There is a need to add a custom property 'renesas,id' and to define
which CSI-2 input is described in which endpoint under the port@1 node.
This information is needed since there are a set of predefined routes
between each VIN and CSI-2 block. This routing table will be kept
inside the driver but in order for it to act on it it must know which
VIN and CSI-2 is which.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/media/rcar_vin.txt | 116 ++++++++++++++++++---
1 file changed, 104 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt
index ff9697ed81396e64..5a95d9668d2c7dfd 100644
--- a/Documentation/devicetree/bindings/media/rcar_vin.txt
+++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
@@ -2,8 +2,12 @@ Renesas R-Car Video Input driver (rcar_vin)
-------------------------------------------
The rcar_vin device provides video input capabilities for the Renesas R-Car
-family of devices. The current blocks are always slaves and suppot one input
-channel which can be either RGB, YUYV or BT656.
+family of devices.
+
+Each VIN instance has a single parallel input that supports RGB and YUV video,
+with both external synchronization and BT.656 synchronization for the latter.
+Depending on the instance the VIN input is connected to external SoC pins, or
+on Gen3 to a CSI-2 receiver.
- compatible: Must be one or more of the following
- "renesas,vin-r8a7743" for the R8A7743 device
@@ -31,21 +35,38 @@ channel which can be either RGB, YUYV or BT656.
Additionally, an alias named vinX will need to be created to specify
which video input device this is.
-The per-board settings:
+The per-board settings Gen2:
- port sub-node describing a single endpoint connected to the vin
as described in video-interfaces.txt[1]. Only the first one will
be considered as each vin interface has one input port.
- These settings are used to work out video input format and widths
- into the system.
+The per-board settings Gen3:
+
+Gen3 can support both a single connected parallel input source from
+external SoC pins (port0) and/or multiple parallel input sources from
+local SoC CSI-2 receivers (port1) depending on SoC.
+- renesas,id - ID number of the VIN, VINx in the documentation.
+- ports
+ - port0 - sub-node describing a single endpoint connected to the VIN
+ from external SoC pins described in video-interfaces.txt[1]. Only
+ the first one will be considered as each VIN interface has at most
+ one set of SoC external input pins.
+ - port1 - sub-nodes describing one or more endpoints connected to
+ the VIN from local SoC CSI-2 receivers. The endpoint numbers must
+ use the following schema.
-Device node example
--------------------
+ - Endpoint 0 - sub-node describing the endpoint which is CSI20
+ - Endpoint 1 - sub-node describing the endpoint which is CSI21
+ - Endpoint 2 - sub-node describing the endpoint which is CSI40
+ - Endpoint 3 - sub-node describing the endpoint which is CSI41
- aliases {
- vin0 = &vin0;
- };
+Device node example Gen2
+------------------------
+
+ aliases {
+ vin0 = &vin0;
+ };
vin0: vin@0xe6ef0000 {
compatible = "renesas,vin-r8a7790", "renesas,rcar-gen2-vin";
@@ -55,8 +76,8 @@ Device node example
status = "disabled";
};
-Board setup example (vin1 composite video input)
-------------------------------------------------
+Board setup example Gen2 (vin1 composite video input)
+-----------------------------------------------------
&i2c2 {
status = "ok";
@@ -95,6 +116,77 @@ Board setup example (vin1 composite video input)
};
};
+Device node example Gen3
+------------------------
+
+ vin0: video@e6ef0000 {
+ compatible = "renesas,vin-r8a7795";
+ reg = <0 0xe6ef0000 0 0x1000>;
+ interrupts = <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 811>;
+ power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
+ resets = <&cpg 811>;
+ renesas,id = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reg = <1>;
+
+ vin0csi20: endpoint@0 {
+ reg = <0>;
+ remote-endpoint= <&csi20vin0>;
+ };
+ vin0csi21: endpoint@1 {
+ reg = <1>;
+ remote-endpoint= <&csi21vin0>;
+ };
+ vin0csi40: endpoint@2 {
+ reg = <2>;
+ remote-endpoint= <&csi40vin0>;
+ };
+ };
+ };
+ };
+
+ csi20: csi2@fea80000 {
+ compatible = "renesas,r8a7795-csi2";
+ reg = <0 0xfea80000 0 0x10000>;
+ interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 714>;
+ power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
+ resets = <&cpg 714>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ csi20_in: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <1>;
+ remote-endpoint = <&adv7482_txb>;
+ };
+ };
+
+ port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ csi20vin0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&vin0csi20>;
+ };
+ };
+ };
+ };
[1] video-interfaces.txt common video media interface
--
2.15.0
^ permalink raw reply related
* [PATCH v8 26/28] rcar-vin: enable support for r8a7795
From: Niklas Söderlund @ 2017-11-29 19:43 UTC (permalink / raw)
To: Laurent Pinchart, Hans Verkuil,
linux-media-u79uwXL29TY76Z2rM5mHXA
Cc: linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
tomoharu.fukawa.eb-zM6kxYcvzFBBDgjK7y7TUQ, Kieran Bingham,
Niklas Söderlund, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171129194342.26239-1-niklas.soderlund+renesas-1zkq55x86MTxsAP9Fp7wbw@public.gmane.org>
Add the SoC specific information for Renesas r8a7795 ES1.x and ES2.0.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas-1zkq55x86MTxsAP9Fp7wbw@public.gmane.org>
Reviewed-by: Hans Verkuil <hans.verkuil-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
---
drivers/media/platform/rcar-vin/Kconfig | 2 +-
drivers/media/platform/rcar-vin/rcar-core.c | 150 ++++++++++++++++++++++++++++
2 files changed, 151 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/rcar-vin/Kconfig b/drivers/media/platform/rcar-vin/Kconfig
index af4c98b44d2e22cb..8fa7ee468c63afb9 100644
--- a/drivers/media/platform/rcar-vin/Kconfig
+++ b/drivers/media/platform/rcar-vin/Kconfig
@@ -6,7 +6,7 @@ config VIDEO_RCAR_VIN
select V4L2_FWNODE
---help---
Support for Renesas R-Car Video Input (VIN) driver.
- Supports R-Car Gen2 SoCs.
+ Supports R-Car Gen2 and Gen3 SoCs.
To compile this driver as a module, choose M here: the
module will be called rcar-vin.
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c b/drivers/media/platform/rcar-vin/rcar-core.c
index 456f93d60b40fb80..9da5aff33fd224f2 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -21,6 +21,7 @@
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/slab.h>
+#include <linux/sys_soc.h>
#include <media/v4l2-async.h>
#include <media/v4l2-fwnode.h>
@@ -956,6 +957,134 @@ static const struct rvin_info rcar_info_gen2 = {
.max_height = 2048,
};
+static const struct rvin_info rcar_info_r8a7795 = {
+ .chip = RCAR_GEN3,
+ .use_mc = true,
+ .max_width = 4096,
+ .max_height = 4096,
+
+ .num_chsels = 5,
+ .chsels = {
+ {
+ { .csi = RVIN_CSI40, .chan = 0 },
+ { .csi = RVIN_CSI20, .chan = 0 },
+ { .csi = RVIN_CSI40, .chan = 1 },
+ { .csi = RVIN_CSI40, .chan = 0 },
+ { .csi = RVIN_CSI20, .chan = 0 },
+ }, {
+ { .csi = RVIN_CSI20, .chan = 0 },
+ { .csi = RVIN_CSI40, .chan = 1 },
+ { .csi = RVIN_CSI40, .chan = 0 },
+ { .csi = RVIN_CSI40, .chan = 1 },
+ { .csi = RVIN_CSI20, .chan = 1 },
+ }, {
+ { .csi = RVIN_CSI20, .chan = 1 },
+ { .csi = RVIN_CSI40, .chan = 0 },
+ { .csi = RVIN_CSI20, .chan = 0 },
+ { .csi = RVIN_CSI40, .chan = 2 },
+ { .csi = RVIN_CSI20, .chan = 2 },
+ }, {
+ { .csi = RVIN_CSI40, .chan = 1 },
+ { .csi = RVIN_CSI20, .chan = 1 },
+ { .csi = RVIN_CSI20, .chan = 1 },
+ { .csi = RVIN_CSI40, .chan = 3 },
+ { .csi = RVIN_CSI20, .chan = 3 },
+ }, {
+ { .csi = RVIN_CSI41, .chan = 0 },
+ { .csi = RVIN_CSI20, .chan = 0 },
+ { .csi = RVIN_CSI41, .chan = 1 },
+ { .csi = RVIN_CSI41, .chan = 0 },
+ { .csi = RVIN_CSI20, .chan = 0 },
+ }, {
+ { .csi = RVIN_CSI20, .chan = 0 },
+ { .csi = RVIN_CSI41, .chan = 1 },
+ { .csi = RVIN_CSI41, .chan = 0 },
+ { .csi = RVIN_CSI41, .chan = 1 },
+ { .csi = RVIN_CSI20, .chan = 1 },
+ }, {
+ { .csi = RVIN_CSI20, .chan = 1 },
+ { .csi = RVIN_CSI41, .chan = 0 },
+ { .csi = RVIN_CSI20, .chan = 0 },
+ { .csi = RVIN_CSI41, .chan = 2 },
+ { .csi = RVIN_CSI20, .chan = 2 },
+ }, {
+ { .csi = RVIN_CSI41, .chan = 1 },
+ { .csi = RVIN_CSI20, .chan = 1 },
+ { .csi = RVIN_CSI20, .chan = 1 },
+ { .csi = RVIN_CSI41, .chan = 3 },
+ { .csi = RVIN_CSI20, .chan = 3 },
+ },
+ },
+};
+
+static const struct rvin_info rcar_info_r8a7795es1 = {
+ .chip = RCAR_GEN3,
+ .use_mc = true,
+ .max_width = 4096,
+ .max_height = 4096,
+
+ .num_chsels = 6,
+ .chsels = {
+ {
+ { .csi = RVIN_CSI40, .chan = 0 },
+ { .csi = RVIN_CSI20, .chan = 0 },
+ { .csi = RVIN_CSI21, .chan = 0 },
+ { .csi = RVIN_CSI40, .chan = 0 },
+ { .csi = RVIN_CSI20, .chan = 0 },
+ { .csi = RVIN_CSI21, .chan = 0 },
+ }, {
+ { .csi = RVIN_CSI20, .chan = 0 },
+ { .csi = RVIN_CSI21, .chan = 0 },
+ { .csi = RVIN_CSI40, .chan = 0 },
+ { .csi = RVIN_CSI40, .chan = 1 },
+ { .csi = RVIN_CSI20, .chan = 1 },
+ { .csi = RVIN_CSI21, .chan = 1 },
+ }, {
+ { .csi = RVIN_CSI21, .chan = 0 },
+ { .csi = RVIN_CSI40, .chan = 0 },
+ { .csi = RVIN_CSI20, .chan = 0 },
+ { .csi = RVIN_CSI40, .chan = 2 },
+ { .csi = RVIN_CSI20, .chan = 2 },
+ { .csi = RVIN_CSI21, .chan = 2 },
+ }, {
+ { .csi = RVIN_CSI40, .chan = 1 },
+ { .csi = RVIN_CSI20, .chan = 1 },
+ { .csi = RVIN_CSI21, .chan = 1 },
+ { .csi = RVIN_CSI40, .chan = 3 },
+ { .csi = RVIN_CSI20, .chan = 3 },
+ { .csi = RVIN_CSI21, .chan = 3 },
+ }, {
+ { .csi = RVIN_CSI41, .chan = 0 },
+ { .csi = RVIN_CSI20, .chan = 0 },
+ { .csi = RVIN_CSI21, .chan = 0 },
+ { .csi = RVIN_CSI41, .chan = 0 },
+ { .csi = RVIN_CSI20, .chan = 0 },
+ { .csi = RVIN_CSI21, .chan = 0 },
+ }, {
+ { .csi = RVIN_CSI20, .chan = 0 },
+ { .csi = RVIN_CSI21, .chan = 0 },
+ { .csi = RVIN_CSI41, .chan = 0 },
+ { .csi = RVIN_CSI41, .chan = 1 },
+ { .csi = RVIN_CSI20, .chan = 1 },
+ { .csi = RVIN_CSI21, .chan = 1 },
+ }, {
+ { .csi = RVIN_CSI21, .chan = 0 },
+ { .csi = RVIN_CSI41, .chan = 0 },
+ { .csi = RVIN_CSI20, .chan = 0 },
+ { .csi = RVIN_CSI41, .chan = 2 },
+ { .csi = RVIN_CSI20, .chan = 2 },
+ { .csi = RVIN_CSI21, .chan = 2 },
+ }, {
+ { .csi = RVIN_CSI41, .chan = 1 },
+ { .csi = RVIN_CSI20, .chan = 1 },
+ { .csi = RVIN_CSI21, .chan = 1 },
+ { .csi = RVIN_CSI41, .chan = 3 },
+ { .csi = RVIN_CSI20, .chan = 3 },
+ { .csi = RVIN_CSI21, .chan = 3 },
+ },
+ },
+};
+
static const struct of_device_id rvin_of_id_table[] = {
{
.compatible = "renesas,vin-r8a7778",
@@ -985,12 +1114,25 @@ static const struct of_device_id rvin_of_id_table[] = {
.compatible = "renesas,rcar-gen2-vin",
.data = &rcar_info_gen2,
},
+ {
+ .compatible = "renesas,vin-r8a7795",
+ .data = &rcar_info_r8a7795,
+ },
{ },
};
MODULE_DEVICE_TABLE(of, rvin_of_id_table);
+static const struct soc_device_attribute r8a7795es1[] = {
+ {
+ .soc_id = "r8a7795", .revision = "ES1.*",
+ .data = &rcar_info_r8a7795es1,
+ },
+ { /* sentinel */ }
+};
+
static int rcar_vin_probe(struct platform_device *pdev)
{
+ const struct soc_device_attribute *attr;
struct rvin_dev *vin;
struct resource *mem;
int irq, ret;
@@ -1002,6 +1144,14 @@ static int rcar_vin_probe(struct platform_device *pdev)
vin->dev = &pdev->dev;
vin->info = of_device_get_match_data(&pdev->dev);
+ /*
+ * Special care is needed on r8a7795 ES1.x since it
+ * uses different routing than r8a7795 ES2.0.
+ */
+ attr = soc_device_match(r8a7795es1);
+ if (attr)
+ vin->info = attr->data;
+
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (mem == NULL)
return -EINVAL;
--
2.15.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 v8 27/28] rcar-vin: enable support for r8a7796
From: Niklas Söderlund @ 2017-11-29 19:43 UTC (permalink / raw)
To: Laurent Pinchart, Hans Verkuil,
linux-media-u79uwXL29TY76Z2rM5mHXA
Cc: linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
tomoharu.fukawa.eb-zM6kxYcvzFBBDgjK7y7TUQ, Kieran Bingham,
Niklas Söderlund, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171129194342.26239-1-niklas.soderlund+renesas-1zkq55x86MTxsAP9Fp7wbw@public.gmane.org>
Add the SoC specific information for Renesas r8a7796.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas-1zkq55x86MTxsAP9Fp7wbw@public.gmane.org>
Reviewed-by: Hans Verkuil <hans.verkuil-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
---
.../devicetree/bindings/media/rcar_vin.txt | 1 +
drivers/media/platform/rcar-vin/rcar-core.c | 64 ++++++++++++++++++++++
2 files changed, 65 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt
index 5a95d9668d2c7dfd..314743532bbb4523 100644
--- a/Documentation/devicetree/bindings/media/rcar_vin.txt
+++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
@@ -20,6 +20,7 @@ on Gen3 to a CSI-2 receiver.
- "renesas,vin-r8a7793" for the R8A7793 device
- "renesas,vin-r8a7794" for the R8A7794 device
- "renesas,vin-r8a7795" for the R8A7795 device
+ - "renesas,vin-r8a7796" for the R8A7796 device
- "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible
device.
- "renesas,rcar-gen3-vin" for a generic R-Car Gen3 compatible device.
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c b/drivers/media/platform/rcar-vin/rcar-core.c
index 9da5aff33fd224f2..62eb89b36fbb2ee1 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -1085,6 +1085,66 @@ static const struct rvin_info rcar_info_r8a7795es1 = {
},
};
+static const struct rvin_info rcar_info_r8a7796 = {
+ .chip = RCAR_GEN3,
+ .use_mc = true,
+ .max_width = 4096,
+ .max_height = 4096,
+
+ .num_chsels = 5,
+ .chsels = {
+ {
+ { .csi = RVIN_CSI40, .chan = 0 },
+ { .csi = RVIN_CSI20, .chan = 0 },
+ { .csi = RVIN_NC, .chan = 0 },
+ { .csi = RVIN_CSI40, .chan = 0 },
+ { .csi = RVIN_CSI20, .chan = 0 },
+ }, {
+ { .csi = RVIN_CSI20, .chan = 0 },
+ { .csi = RVIN_NC, .chan = 0 },
+ { .csi = RVIN_CSI40, .chan = 0 },
+ { .csi = RVIN_CSI40, .chan = 1 },
+ { .csi = RVIN_CSI20, .chan = 1 },
+ }, {
+ { .csi = RVIN_NC, .chan = 0 },
+ { .csi = RVIN_CSI40, .chan = 0 },
+ { .csi = RVIN_CSI20, .chan = 0 },
+ { .csi = RVIN_CSI40, .chan = 2 },
+ { .csi = RVIN_CSI20, .chan = 2 },
+ }, {
+ { .csi = RVIN_CSI40, .chan = 1 },
+ { .csi = RVIN_CSI20, .chan = 1 },
+ { .csi = RVIN_NC, .chan = 1 },
+ { .csi = RVIN_CSI40, .chan = 3 },
+ { .csi = RVIN_CSI20, .chan = 3 },
+ }, {
+ { .csi = RVIN_CSI40, .chan = 0 },
+ { .csi = RVIN_CSI20, .chan = 0 },
+ { .csi = RVIN_NC, .chan = 0 },
+ { .csi = RVIN_CSI40, .chan = 0 },
+ { .csi = RVIN_CSI20, .chan = 0 },
+ }, {
+ { .csi = RVIN_CSI20, .chan = 0 },
+ { .csi = RVIN_NC, .chan = 0 },
+ { .csi = RVIN_CSI40, .chan = 0 },
+ { .csi = RVIN_CSI40, .chan = 1 },
+ { .csi = RVIN_CSI20, .chan = 1 },
+ }, {
+ { .csi = RVIN_NC, .chan = 0 },
+ { .csi = RVIN_CSI40, .chan = 0 },
+ { .csi = RVIN_CSI20, .chan = 0 },
+ { .csi = RVIN_CSI40, .chan = 2 },
+ { .csi = RVIN_CSI20, .chan = 2 },
+ }, {
+ { .csi = RVIN_CSI40, .chan = 1 },
+ { .csi = RVIN_CSI20, .chan = 1 },
+ { .csi = RVIN_NC, .chan = 1 },
+ { .csi = RVIN_CSI40, .chan = 3 },
+ { .csi = RVIN_CSI20, .chan = 3 },
+ },
+ },
+};
+
static const struct of_device_id rvin_of_id_table[] = {
{
.compatible = "renesas,vin-r8a7778",
@@ -1118,6 +1178,10 @@ static const struct of_device_id rvin_of_id_table[] = {
.compatible = "renesas,vin-r8a7795",
.data = &rcar_info_r8a7795,
},
+ {
+ .compatible = "renesas,vin-r8a7796",
+ .data = &rcar_info_r8a7796,
+ },
{ },
};
MODULE_DEVICE_TABLE(of, rvin_of_id_table);
--
2.15.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 v8 28/28] rcar-vin: enable support for r8a77970
From: Niklas Söderlund @ 2017-11-29 19:43 UTC (permalink / raw)
To: Laurent Pinchart, Hans Verkuil, linux-media
Cc: linux-renesas-soc, tomoharu.fukawa.eb, Kieran Bingham,
Niklas Söderlund, Rob Herring, devicetree
In-Reply-To: <20171129194342.26239-1-niklas.soderlund+renesas@ragnatech.se>
Add the SoC specific information for Renesas r8a77970.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
---
.../devicetree/bindings/media/rcar_vin.txt | 1 +
drivers/media/platform/rcar-vin/rcar-core.c | 40 ++++++++++++++++++++++
2 files changed, 41 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt
index 314743532bbb4523..6b98f8a3398fa493 100644
--- a/Documentation/devicetree/bindings/media/rcar_vin.txt
+++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
@@ -21,6 +21,7 @@ on Gen3 to a CSI-2 receiver.
- "renesas,vin-r8a7794" for the R8A7794 device
- "renesas,vin-r8a7795" for the R8A7795 device
- "renesas,vin-r8a7796" for the R8A7796 device
+ - "renesas,vin-r8a77970" for the R8A77970 device
- "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible
device.
- "renesas,rcar-gen3-vin" for a generic R-Car Gen3 compatible device.
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c b/drivers/media/platform/rcar-vin/rcar-core.c
index 62eb89b36fbb2ee1..bbdf36b5c3c8178d 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -1145,6 +1145,42 @@ static const struct rvin_info rcar_info_r8a7796 = {
},
};
+static const struct rvin_info rcar_info_r8a77970 = {
+ .chip = RCAR_GEN3,
+ .use_mc = true,
+ .max_width = 4096,
+ .max_height = 4096,
+
+ .num_chsels = 5,
+ .chsels = {
+ {
+ { .csi = RVIN_CSI40, .chan = 0 },
+ { .csi = RVIN_NC, .chan = 0 },
+ { .csi = RVIN_NC, .chan = 0 },
+ { .csi = RVIN_CSI40, .chan = 0 },
+ { .csi = RVIN_NC, .chan = 0 },
+ }, {
+ { .csi = RVIN_NC, .chan = 0 },
+ { .csi = RVIN_NC, .chan = 0 },
+ { .csi = RVIN_CSI40, .chan = 0 },
+ { .csi = RVIN_CSI40, .chan = 1 },
+ { .csi = RVIN_NC, .chan = 0 },
+ }, {
+ { .csi = RVIN_NC, .chan = 0 },
+ { .csi = RVIN_CSI40, .chan = 0 },
+ { .csi = RVIN_NC, .chan = 0 },
+ { .csi = RVIN_CSI40, .chan = 2 },
+ { .csi = RVIN_NC, .chan = 0 },
+ }, {
+ { .csi = RVIN_CSI40, .chan = 1 },
+ { .csi = RVIN_NC, .chan = 0 },
+ { .csi = RVIN_NC, .chan = 0 },
+ { .csi = RVIN_CSI40, .chan = 3 },
+ { .csi = RVIN_NC, .chan = 0 },
+ },
+ },
+};
+
static const struct of_device_id rvin_of_id_table[] = {
{
.compatible = "renesas,vin-r8a7778",
@@ -1182,6 +1218,10 @@ static const struct of_device_id rvin_of_id_table[] = {
.compatible = "renesas,vin-r8a7796",
.data = &rcar_info_r8a7796,
},
+ {
+ .compatible = "renesas,vin-r8a77970",
+ .data = &rcar_info_r8a77970,
+ },
{ },
};
MODULE_DEVICE_TABLE(of, rvin_of_id_table);
--
2.15.0
^ permalink raw reply related
* [PATCH 0/9] soc: brcmstb: biuctrl updates for 64-bit chips
From: Florian Fainelli @ 2017-11-29 20:18 UTC (permalink / raw)
To: bcm-kernel-feedback-list
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Florian Fainelli, open list, Rob Herring, Gregory Fong,
Brian Norris, moderated list:BROADCOM BCM7XXX ARM ARCHITECTURE
Hi all,
This patch series updates the Broadcom STB Bus Interface Unit controller to
support newer chips such as 7260, 7268, 7271 and 7278. These chips require
additional tuning in order to provide the expected bus throughput.
In the process, we need to re-organize the common.c file a little bit in order
to extract the family and product identifiers a little earlier.
Finally, by moving the biuctrl initialization an early_initcall level, we can
remove some code from the ARM-32bit machine descriptor file.
Provided that we are happy with these changes, I would route them through my
drivers/next branch and a subsequent Broadcom ARM SoC pull request.
Thank you
Florian Fainelli (9):
dt-bindings: arm: Add entry for Broadcom Brahma-B53
dt-bindings: arm: brcmstb: Correct BIUCTRL node documentation
soc: brcmstb: Make CPU credit offset more parameterized
soc: brcmstb: Correct CPU_CREDIT_REG offset for Brahma-B53 CPUs
soc: brcmstb: biuctrl: Prepare for saving/restoring other registers
soc: brcmstb: biuctrl: Wire-up new registers
soc: brcmstb: biuctrl: Fine tune B53 MCP interface settings
soc: brcmstb: Split initialization
soc: brcmstb: biuctrl: Move to early_initcall
.../devicetree/bindings/arm/bcm/brcm,brcmstb.txt | 22 +--
Documentation/devicetree/bindings/arm/cpus.txt | 1 +
arch/arm/mach-bcm/brcmstb.c | 2 -
drivers/soc/bcm/brcmstb/biuctrl.c | 176 +++++++++++++++++++--
drivers/soc/bcm/brcmstb/common.c | 27 ++--
include/linux/soc/brcmstb/brcmstb.h | 6 -
6 files changed, 186 insertions(+), 48 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH 1/9] dt-bindings: arm: Add entry for Broadcom Brahma-B53
From: Florian Fainelli @ 2017-11-29 20:18 UTC (permalink / raw)
To: bcm-kernel-feedback-list
Cc: Florian Fainelli, Rob Herring, Mark Rutland, Brian Norris,
Gregory Fong,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:BROADCOM BCM7XXX ARM ARCHITECTURE, open list
In-Reply-To: <20171129201849.17522-1-f.fainelli@gmail.com>
Broadcom's Brahma-B53 CPU is an ARMv8A processor used on a number of
DSL, Cable Modem and Set-top-box SoCs.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
Documentation/devicetree/bindings/arm/cpus.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
index a0009b72e9be..f4a777039f03 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -169,6 +169,7 @@ described below.
"arm,cortex-r5"
"arm,cortex-r7"
"brcm,brahma-b15"
+ "brcm,brahma-b53"
"brcm,vulcan"
"cavium,thunder"
"cavium,thunder2"
--
2.9.3
^ permalink raw reply related
* [PATCH 2/9] dt-bindings: arm: brcmstb: Correct BIUCTRL node documentation
From: Florian Fainelli @ 2017-11-29 20:18 UTC (permalink / raw)
To: bcm-kernel-feedback-list
Cc: Florian Fainelli, Rob Herring, Mark Rutland, Brian Norris,
Gregory Fong,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:BROADCOM BCM7XXX ARM ARCHITECTURE, open list
In-Reply-To: <20171129201849.17522-1-f.fainelli@gmail.com>
Correct the Device Tree bindings for the HIF_CPUBIUCTRL node whose
compatible string is actually brcm,bcm<chip-id>-cpu-biu-ctrl. Also
document in the binding the fallback property
("brcm,brcmstb-cpu-biu-ctrl") and update the example accordingly.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
.../devicetree/bindings/arm/bcm/brcm,brcmstb.txt | 22 ++++++++++++----------
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt b/Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt
index 790e6b0b8306..05be8d1f7be6 100644
--- a/Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt
@@ -17,21 +17,23 @@ Further, syscon nodes that map platform-specific registers used for general
system control is required:
- compatible: "brcm,bcm<chip_id>-sun-top-ctrl", "syscon"
- - compatible: "brcm,bcm<chip_id>-hif-cpubiuctrl", "syscon"
+ - compatible: "brcm,bcm<chip_id>-cpu-biu-ctrl",
+ "brcm,brcmstb-cpu-biu-ctrl",
+ "syscon"
- compatible: "brcm,bcm<chip_id>-hif-continuation", "syscon"
-hif-cpubiuctrl node
+cpu-biu-ctrl node
-------------------
-SoCs with Broadcom Brahma15 ARM-based CPUs have a specific Bus Interface Unit
-(BIU) block which controls and interfaces the CPU complex to the different
-Memory Controller Ports (MCP), one per memory controller (MEMC). This BIU block
-offers a feature called Write Pairing which consists in collapsing two adjacent
-cache lines into a single (bursted) write transaction towards the memory
-controller (MEMC) to maximize write bandwidth.
+SoCs with Broadcom Brahma15 ARM-based and Brahma53 ARM64-based CPUs have a
+specific Bus Interface Unit (BIU) block which controls and interfaces the CPU
+complex to the different Memory Controller Ports (MCP), one per memory
+controller (MEMC). This BIU block offers a feature called Write Pairing which
+consists in collapsing two adjacent cache lines into a single (bursted) write
+transaction towards the memory controller (MEMC) to maximize write bandwidth.
Required properties:
- - compatible: must be "brcm,bcm7445-hif-cpubiuctrl", "syscon"
+ - compatible: must be "brcm,bcm7445-cpu-biu-ctrl", "syscon"
Optional properties:
@@ -52,7 +54,7 @@ example:
};
hif_cpubiuctrl: syscon@3e2400 {
- compatible = "brcm,bcm7445-hif-cpubiuctrl", "syscon";
+ compatible = "brcm,bcm7445-cpu-biu-ctrl", "brcm,brcmstb-cpu-biu-ctrl", "syscon";
reg = <0x3e2400 0x5b4>;
brcm,write-pairing;
};
--
2.9.3
^ permalink raw reply related
* [PATCH 3/9] soc: brcmstb: Make CPU credit offset more parameterized
From: Florian Fainelli @ 2017-11-29 20:18 UTC (permalink / raw)
To: bcm-kernel-feedback-list
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Florian Fainelli, open list, Rob Herring, Gregory Fong,
Brian Norris, moderated list:BROADCOM BCM7XXX ARM ARCHITECTURE
In-Reply-To: <20171129201849.17522-1-f.fainelli@gmail.com>
In preparation for fixing and changing values in the CPU_CREDIT_REG
register for B53-based systems, make the offset parameterized.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/soc/bcm/brcmstb/biuctrl.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/soc/bcm/brcmstb/biuctrl.c b/drivers/soc/bcm/brcmstb/biuctrl.c
index 3c39415d484f..c3c548fcaa8c 100644
--- a/drivers/soc/bcm/brcmstb/biuctrl.c
+++ b/drivers/soc/bcm/brcmstb/biuctrl.c
@@ -26,6 +26,7 @@
static void __iomem *cpubiuctrl_base;
static bool mcp_wr_pairing_en;
+static unsigned int cpu_credit_reg_offset = CPU_CREDIT_REG_OFFSET;
static int __init mcp_write_pairing_set(void)
{
@@ -34,15 +35,15 @@ static int __init mcp_write_pairing_set(void)
if (!cpubiuctrl_base)
return -1;
- creds = readl_relaxed(cpubiuctrl_base + CPU_CREDIT_REG_OFFSET);
+ creds = readl_relaxed(cpubiuctrl_base + cpu_credit_reg_offset);
if (mcp_wr_pairing_en) {
pr_info("MCP: Enabling write pairing\n");
writel_relaxed(creds | CPU_CREDIT_REG_MCPx_WR_PAIRING_EN_MASK,
- cpubiuctrl_base + CPU_CREDIT_REG_OFFSET);
+ cpubiuctrl_base + cpu_credit_reg_offset);
} else if (creds & CPU_CREDIT_REG_MCPx_WR_PAIRING_EN_MASK) {
pr_info("MCP: Disabling write pairing\n");
writel_relaxed(creds & ~CPU_CREDIT_REG_MCPx_WR_PAIRING_EN_MASK,
- cpubiuctrl_base + CPU_CREDIT_REG_OFFSET);
+ cpubiuctrl_base + cpu_credit_reg_offset);
} else {
pr_info("MCP: Write pairing already disabled\n");
}
@@ -81,7 +82,7 @@ static int brcmstb_cpu_credit_reg_suspend(void)
{
if (cpubiuctrl_base)
cpu_credit_reg_dump =
- readl_relaxed(cpubiuctrl_base + CPU_CREDIT_REG_OFFSET);
+ readl_relaxed(cpubiuctrl_base + cpu_credit_reg_offset);
return 0;
}
@@ -89,7 +90,7 @@ static void brcmstb_cpu_credit_reg_resume(void)
{
if (cpubiuctrl_base)
writel_relaxed(cpu_credit_reg_dump,
- cpubiuctrl_base + CPU_CREDIT_REG_OFFSET);
+ cpubiuctrl_base + cpu_credit_reg_offset);
}
static struct syscore_ops brcmstb_cpu_credit_syscore_ops = {
--
2.9.3
^ permalink raw reply related
* [PATCH 4/9] soc: brcmstb: Correct CPU_CREDIT_REG offset for Brahma-B53 CPUs
From: Florian Fainelli @ 2017-11-29 20:18 UTC (permalink / raw)
To: bcm-kernel-feedback-list
Cc: Florian Fainelli, Rob Herring, Mark Rutland, Brian Norris,
Gregory Fong,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:BROADCOM BCM7XXX ARM ARCHITECTURE, open list
In-Reply-To: <20171129201849.17522-1-f.fainelli@gmail.com>
On Broadcom Brahma-B53 CPUs, the CPU_CREDIT_REG offset got moved to
0x0b0 instead of 0x184, correct this such that we correcty
enable/disable write-pairing for these chips.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/soc/bcm/brcmstb/biuctrl.c | 24 +++++++++++++++++++++---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/soc/bcm/brcmstb/biuctrl.c b/drivers/soc/bcm/brcmstb/biuctrl.c
index c3c548fcaa8c..e8322e663831 100644
--- a/drivers/soc/bcm/brcmstb/biuctrl.c
+++ b/drivers/soc/bcm/brcmstb/biuctrl.c
@@ -21,12 +21,13 @@
#include <linux/syscore_ops.h>
#include <linux/soc/brcmstb/brcmstb.h>
-#define CPU_CREDIT_REG_OFFSET 0x184
+#define B15_CPU_CREDIT_REG_OFFSET 0x184
+#define B53_CPU_CREDIT_REG_OFFSET 0x0b0
#define CPU_CREDIT_REG_MCPx_WR_PAIRING_EN_MASK 0x70000000
static void __iomem *cpubiuctrl_base;
static bool mcp_wr_pairing_en;
-static unsigned int cpu_credit_reg_offset = CPU_CREDIT_REG_OFFSET;
+static unsigned int cpu_credit_reg_offset;
static int __init mcp_write_pairing_set(void)
{
@@ -53,7 +54,7 @@ static int __init mcp_write_pairing_set(void)
static int __init setup_hifcpubiuctrl_regs(void)
{
- struct device_node *np;
+ struct device_node *np, *cpu_dn;
int ret = 0;
np = of_find_compatible_node(NULL, NULL, "brcm,brcmstb-cpu-biu-ctrl");
@@ -70,6 +71,23 @@ static int __init setup_hifcpubiuctrl_regs(void)
}
mcp_wr_pairing_en = of_property_read_bool(np, "brcm,write-pairing");
+
+ cpu_dn = of_get_cpu_node(0, NULL);
+ if (!cpu_dn) {
+ pr_err("failed to obtain CPU device node\n");
+ ret = -ENODEV;
+ goto out;
+ }
+
+ if (of_device_is_compatible(cpu_dn, "brcm,brahma-b15"))
+ cpu_credit_reg_offset = B15_CPU_CREDIT_REG_OFFSET;
+ else if (of_device_is_compatible(cpu_dn, "brcm,brahma-b53"))
+ cpu_credit_reg_offset = B53_CPU_CREDIT_REG_OFFSET;
+ else {
+ pr_err("unsupported CPU\n");
+ ret = -EINVAL;
+ }
+ of_node_put(cpu_dn);
out:
of_node_put(np);
return ret;
--
2.9.3
^ permalink raw reply related
* [PATCH 5/9] soc: brcmstb: biuctrl: Prepare for saving/restoring other registers
From: Florian Fainelli @ 2017-11-29 20:18 UTC (permalink / raw)
To: bcm-kernel-feedback-list
Cc: Florian Fainelli, Rob Herring, Mark Rutland, Brian Norris,
Gregory Fong,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:BROADCOM BCM7XXX ARM ARCHITECTURE, open list
In-Reply-To: <20171129201849.17522-1-f.fainelli@gmail.com>
In preparation for saving/restoring additional registers required on
some newer platforms (7268, 7271, 7278), migrate the code to use enums
and helper functions to access registers.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/soc/bcm/brcmstb/biuctrl.c | 75 ++++++++++++++++++++++++++++++---------
1 file changed, 58 insertions(+), 17 deletions(-)
diff --git a/drivers/soc/bcm/brcmstb/biuctrl.c b/drivers/soc/bcm/brcmstb/biuctrl.c
index e8322e663831..16cbfc2e953a 100644
--- a/drivers/soc/bcm/brcmstb/biuctrl.c
+++ b/drivers/soc/bcm/brcmstb/biuctrl.c
@@ -21,13 +21,45 @@
#include <linux/syscore_ops.h>
#include <linux/soc/brcmstb/brcmstb.h>
-#define B15_CPU_CREDIT_REG_OFFSET 0x184
-#define B53_CPU_CREDIT_REG_OFFSET 0x0b0
#define CPU_CREDIT_REG_MCPx_WR_PAIRING_EN_MASK 0x70000000
static void __iomem *cpubiuctrl_base;
static bool mcp_wr_pairing_en;
-static unsigned int cpu_credit_reg_offset;
+static const int *cpubiuctrl_regs;
+
+static inline u32 cbc_readl(int reg)
+{
+ int offset = cpubiuctrl_regs[reg];
+
+ if (offset == -1)
+ return (u32)-1;
+
+ return readl_relaxed(cpubiuctrl_base + offset);
+}
+
+static inline void cbc_writel(u32 val, int reg)
+{
+ int offset = cpubiuctrl_regs[reg];
+
+ if (offset == -1)
+ return;
+
+ writel_relaxed(val, cpubiuctrl_base + offset);
+}
+
+enum cpubiuctrl_regs {
+ CPU_CREDIT_REG = 0,
+};
+
+static const int b15_cpubiuctrl_regs[] = {
+ [CPU_CREDIT_REG] = 0x184,
+};
+
+static const int b53_cpubiuctrl_regs[] = {
+ [CPU_CREDIT_REG] = 0x0b0,
+};
+
+#define NUM_CPU_BIUCTRL_REGS 1
static int __init mcp_write_pairing_set(void)
{
@@ -36,15 +68,15 @@ static int __init mcp_write_pairing_set(void)
if (!cpubiuctrl_base)
return -1;
- creds = readl_relaxed(cpubiuctrl_base + cpu_credit_reg_offset);
+ creds = cbc_readl(CPU_CREDIT_REG);
if (mcp_wr_pairing_en) {
pr_info("MCP: Enabling write pairing\n");
- writel_relaxed(creds | CPU_CREDIT_REG_MCPx_WR_PAIRING_EN_MASK,
- cpubiuctrl_base + cpu_credit_reg_offset);
+ cbc_writel(creds | CPU_CREDIT_REG_MCPx_WR_PAIRING_EN_MASK,
+ CPU_CREDIT_REG);
} else if (creds & CPU_CREDIT_REG_MCPx_WR_PAIRING_EN_MASK) {
pr_info("MCP: Disabling write pairing\n");
- writel_relaxed(creds & ~CPU_CREDIT_REG_MCPx_WR_PAIRING_EN_MASK,
- cpubiuctrl_base + cpu_credit_reg_offset);
+ cbc_writel(creds & ~CPU_CREDIT_REG_MCPx_WR_PAIRING_EN_MASK,
+ CPU_CREDIT_REG);
} else {
pr_info("MCP: Write pairing already disabled\n");
}
@@ -80,9 +112,9 @@ static int __init setup_hifcpubiuctrl_regs(void)
}
if (of_device_is_compatible(cpu_dn, "brcm,brahma-b15"))
- cpu_credit_reg_offset = B15_CPU_CREDIT_REG_OFFSET;
+ cpubiuctrl_regs = b15_cpubiuctrl_regs;
else if (of_device_is_compatible(cpu_dn, "brcm,brahma-b53"))
- cpu_credit_reg_offset = B53_CPU_CREDIT_REG_OFFSET;
+ cpubiuctrl_regs = b53_cpubiuctrl_regs;
else {
pr_err("unsupported CPU\n");
ret = -EINVAL;
@@ -94,21 +126,30 @@ static int __init setup_hifcpubiuctrl_regs(void)
}
#ifdef CONFIG_PM_SLEEP
-static u32 cpu_credit_reg_dump; /* for save/restore */
+static u32 cpubiuctrl_reg_save[NUM_CPU_BIUCTRL_REGS];
static int brcmstb_cpu_credit_reg_suspend(void)
{
- if (cpubiuctrl_base)
- cpu_credit_reg_dump =
- readl_relaxed(cpubiuctrl_base + cpu_credit_reg_offset);
+ unsigned int i;
+
+ if (!cpubiuctrl_base)
+ return 0;
+
+ for (i = 0; i < NUM_CPU_BIUCTRL_REGS; i++)
+ cpubiuctrl_reg_save[i] = cbc_readl(i);
+
return 0;
}
static void brcmstb_cpu_credit_reg_resume(void)
{
- if (cpubiuctrl_base)
- writel_relaxed(cpu_credit_reg_dump,
- cpubiuctrl_base + cpu_credit_reg_offset);
+ unsigned int i;
+
+ if (!cpubiuctrl_base)
+ return;
+
+ for (i = 0; i < NUM_CPU_BIUCTRL_REGS; i++)
+ cbc_writel(cpubiuctrl_reg_save[i], i);
}
static struct syscore_ops brcmstb_cpu_credit_syscore_ops = {
--
2.9.3
^ permalink raw reply related
* [PATCH 6/9] soc: brcmstb: biuctrl: Wire-up new registers
From: Florian Fainelli @ 2017-11-29 20:18 UTC (permalink / raw)
To: bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w
Cc: Florian Fainelli, Rob Herring, Mark Rutland, Brian Norris,
Gregory Fong,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:BROADCOM BCM7XXX ARM ARCHITECTURE, open list
In-Reply-To: <20171129201849.17522-1-f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Add definitions for B53 systems register: CPU_MCP_FLOW_REG and
CPU_WRITEBACK_CTRL_REG. These register will be saved and restored
accordingly.
Signed-off-by: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/soc/bcm/brcmstb/biuctrl.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/bcm/brcmstb/biuctrl.c b/drivers/soc/bcm/brcmstb/biuctrl.c
index 16cbfc2e953a..d498f9db01ab 100644
--- a/drivers/soc/bcm/brcmstb/biuctrl.c
+++ b/drivers/soc/bcm/brcmstb/biuctrl.c
@@ -49,17 +49,23 @@ static inline void cbc_writel(u32 val, int reg)
enum cpubiuctrl_regs {
CPU_CREDIT_REG = 0,
+ CPU_MCP_FLOW_REG,
+ CPU_WRITEBACK_CTRL_REG
};
static const int b15_cpubiuctrl_regs[] = {
[CPU_CREDIT_REG] = 0x184,
+ [CPU_MCP_FLOW_REG] = -1,
+ [CPU_WRITEBACK_CTRL_REG] = -1,
};
static const int b53_cpubiuctrl_regs[] = {
[CPU_CREDIT_REG] = 0x0b0,
+ [CPU_MCP_FLOW_REG] = 0x0b4,
+ [CPU_WRITEBACK_CTRL_REG] = 0x22c,
};
-#define NUM_CPU_BIUCTRL_REGS 1
+#define NUM_CPU_BIUCTRL_REGS 3
static int __init mcp_write_pairing_set(void)
{
--
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 related
* [PATCH 7/9] soc: brcmstb: biuctrl: Fine tune B53 MCP interface settings
From: Florian Fainelli @ 2017-11-29 20:18 UTC (permalink / raw)
To: bcm-kernel-feedback-list
Cc: Florian Fainelli, Rob Herring, Mark Rutland, Brian Norris,
Gregory Fong,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:BROADCOM BCM7XXX ARM ARCHITECTURE, open list
In-Reply-To: <20171129201849.17522-1-f.fainelli@gmail.com>
In order to achieve expected MCP bus throughput on 3 particular chips:
7268, 7271 and 7278, do the appropriate programming of the MCP
interface: increase number of MCP write credits, turn on write-back
throttling when present.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/soc/bcm/brcmstb/biuctrl.c | 76 +++++++++++++++++++++++++++++++++++++++
1 file changed, 76 insertions(+)
diff --git a/drivers/soc/bcm/brcmstb/biuctrl.c b/drivers/soc/bcm/brcmstb/biuctrl.c
index d498f9db01ab..dd45bbfe64dd 100644
--- a/drivers/soc/bcm/brcmstb/biuctrl.c
+++ b/drivers/soc/bcm/brcmstb/biuctrl.c
@@ -22,6 +22,18 @@
#include <linux/soc/brcmstb/brcmstb.h>
#define CPU_CREDIT_REG_MCPx_WR_PAIRING_EN_MASK 0x70000000
+#define CPU_CREDIT_REG_MCPx_READ_CRED_MASK 0xf
+#define CPU_CREDIT_REG_MCPx_WRITE_CRED_MASK 0xf
+#define CPU_CREDIT_REG_MCPx_READ_CRED_SHIFT(x) ((x) * 8)
+#define CPU_CREDIT_REG_MCPx_WRITE_CRED_SHIFT(x) (((x) * 8) + 4)
+
+#define CPU_MCP_FLOW_REG_MCPx_RDBUFF_CRED_SHIFT(x) ((x) * 8)
+#define CPU_MCP_FLOW_REG_MCPx_RDBUFF_CRED_MASK 0xff
+
+#define CPU_WRITEBACK_CTRL_REG_WB_THROTTLE_THRESHOLD_MASK 0xf
+#define CPU_WRITEBACK_CTRL_REG_WB_THROTTLE_TIMEOUT_MASK 0xf
+#define CPU_WRITEBACK_CTRL_REG_WB_THROTTLE_TIMEOUT_SHIFT 4
+#define CPU_WRITEBACK_CTRL_REG_WB_THROTTLE_ENABLE BIT(8)
static void __iomem *cpubiuctrl_base;
static bool mcp_wr_pairing_en;
@@ -59,6 +71,13 @@ static const int b15_cpubiuctrl_regs[] = {
[CPU_WRITEBACK_CTRL_REG] = -1,
};
+/* Odd cases, e.g: 7260 */
+static const int b53_cpubiuctrl_no_wb_regs[] = {
+ [CPU_CREDIT_REG] = 0x0b0,
+ [CPU_MCP_FLOW_REG] = 0x0b4,
+ [CPU_WRITEBACK_CTRL_REG] = -1,
+};
+
static const int b53_cpubiuctrl_regs[] = {
[CPU_CREDIT_REG] = 0x0b0,
[CPU_MCP_FLOW_REG] = 0x0b4,
@@ -90,6 +109,59 @@ static int __init mcp_write_pairing_set(void)
return 0;
}
+static const u32 b53_mach_compat[] = {
+ 0x7268,
+ 0x7271,
+ 0x7278,
+};
+
+static void __init mcp_b53_set(void)
+{
+ unsigned int i;
+ u32 reg;
+
+ reg = brcmstb_get_family_id();
+
+ for (i = 0; i < ARRAY_SIZE(b53_mach_compat); i++) {
+ if (BRCM_ID(reg) == b53_mach_compat[i])
+ break;
+ }
+
+ if (i == ARRAY_SIZE(b53_mach_compat))
+ return;
+
+ /* Set all 3 MCP interfaces to 8 credits */
+ reg = cbc_readl(CPU_CREDIT_REG);
+ for (i = 0; i < 3; i++) {
+ reg &= ~(CPU_CREDIT_REG_MCPx_WRITE_CRED_MASK <<
+ CPU_CREDIT_REG_MCPx_WRITE_CRED_SHIFT(i));
+ reg &= ~(CPU_CREDIT_REG_MCPx_READ_CRED_MASK <<
+ CPU_CREDIT_REG_MCPx_READ_CRED_SHIFT(i));
+ reg |= 8 << CPU_CREDIT_REG_MCPx_WRITE_CRED_SHIFT(i);
+ reg |= 8 << CPU_CREDIT_REG_MCPx_READ_CRED_SHIFT(i);
+ }
+ cbc_writel(reg, CPU_CREDIT_REG);
+
+ /* Max out the number of in-flight Jwords reads on the MCP interface */
+ reg = cbc_readl(CPU_MCP_FLOW_REG);
+ for (i = 0; i < 3; i++)
+ reg |= CPU_MCP_FLOW_REG_MCPx_RDBUFF_CRED_MASK <<
+ CPU_MCP_FLOW_REG_MCPx_RDBUFF_CRED_SHIFT(i);
+ cbc_writel(reg, CPU_MCP_FLOW_REG);
+
+ /* Enable writeback throttling, set timeout to 128 cycles, 256 cycles
+ * threshold
+ */
+ reg = cbc_readl(CPU_WRITEBACK_CTRL_REG);
+ reg |= CPU_WRITEBACK_CTRL_REG_WB_THROTTLE_ENABLE;
+ reg &= ~CPU_WRITEBACK_CTRL_REG_WB_THROTTLE_THRESHOLD_MASK;
+ reg &= ~(CPU_WRITEBACK_CTRL_REG_WB_THROTTLE_TIMEOUT_MASK <<
+ CPU_WRITEBACK_CTRL_REG_WB_THROTTLE_TIMEOUT_SHIFT);
+ reg |= 8;
+ reg |= 7 << CPU_WRITEBACK_CTRL_REG_WB_THROTTLE_TIMEOUT_SHIFT;
+ cbc_writel(reg, CPU_WRITEBACK_CTRL_REG);
+}
+
static int __init setup_hifcpubiuctrl_regs(void)
{
struct device_node *np, *cpu_dn;
@@ -126,6 +198,9 @@ static int __init setup_hifcpubiuctrl_regs(void)
ret = -EINVAL;
}
of_node_put(cpu_dn);
+
+ if (BRCM_ID(brcmstb_get_family_id()) == 0x7260)
+ cpubiuctrl_regs = b53_cpubiuctrl_no_wb_regs;
out:
of_node_put(np);
return ret;
@@ -177,6 +252,7 @@ void __init brcmstb_biuctrl_init(void)
return;
}
+ mcp_b53_set();
#ifdef CONFIG_PM_SLEEP
register_syscore_ops(&brcmstb_cpu_credit_syscore_ops);
#endif
--
2.9.3
^ permalink raw reply related
* [PATCH 8/9] soc: brcmstb: Split initialization
From: Florian Fainelli @ 2017-11-29 20:18 UTC (permalink / raw)
To: bcm-kernel-feedback-list
Cc: Florian Fainelli, Rob Herring, Mark Rutland, Brian Norris,
Gregory Fong,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:BROADCOM BCM7XXX ARM ARCHITECTURE, open list
In-Reply-To: <20171129201849.17522-1-f.fainelli@gmail.com>
We may need access to family_id and product_id fairly early on boot for
other parts of the code (e.g: biuctrl.c), so split the initialization
between an early_init() and an arch_initcall() which allows us to do
that.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/soc/bcm/brcmstb/common.c | 27 +++++++++++++--------------
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/drivers/soc/bcm/brcmstb/common.c b/drivers/soc/bcm/brcmstb/common.c
index a71730da6385..781ada62d0a3 100644
--- a/drivers/soc/bcm/brcmstb/common.c
+++ b/drivers/soc/bcm/brcmstb/common.c
@@ -66,13 +66,10 @@ static const struct of_device_id sun_top_ctrl_match[] = {
{ }
};
-static int __init brcmstb_soc_device_init(void)
+static int __init brcmstb_soc_device_early_init(void)
{
- struct soc_device_attribute *soc_dev_attr;
- struct soc_device *soc_dev;
struct device_node *sun_top_ctrl;
void __iomem *sun_top_ctrl_base;
- int ret = 0;
sun_top_ctrl = of_find_matching_node(NULL, sun_top_ctrl_match);
if (!sun_top_ctrl)
@@ -84,12 +81,19 @@ static int __init brcmstb_soc_device_init(void)
family_id = readl(sun_top_ctrl_base);
product_id = readl(sun_top_ctrl_base + 0x4);
+ iounmap(sun_top_ctrl_base);
+ return 0;
+}
+early_initcall(brcmstb_soc_device_early_init);
+
+static int __init brcmstb_soc_device_init(void)
+{
+ struct soc_device_attribute *soc_dev_attr;
+ struct soc_device *soc_dev;
soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
- if (!soc_dev_attr) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!soc_dev_attr)
+ return -ENOMEM;
soc_dev_attr->family = kasprintf(GFP_KERNEL, "%x",
family_id >> 28 ?
@@ -107,14 +111,9 @@ static int __init brcmstb_soc_device_init(void)
kfree(soc_dev_attr->soc_id);
kfree(soc_dev_attr->revision);
kfree(soc_dev_attr);
- ret = -ENODEV;
- goto out;
+ return -ENOMEM;
}
return 0;
-
-out:
- iounmap(sun_top_ctrl_base);
- return ret;
}
arch_initcall(brcmstb_soc_device_init);
--
2.9.3
^ permalink raw reply related
* [PATCH 9/9] soc: brcmstb: biuctrl: Move to early_initcall
From: Florian Fainelli @ 2017-11-29 20:18 UTC (permalink / raw)
To: bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w
Cc: Florian Fainelli, Rob Herring, Mark Rutland, Brian Norris,
Gregory Fong,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:BROADCOM BCM7XXX ARM ARCHITECTURE, open list
In-Reply-To: <20171129201849.17522-1-f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Being called during early_initcall() is early enough that it occurs
before SMP initialization, which is all we care about for the Bus
Interface Unit configuration.
This solves lack of BIU initialization on ARM64 platforms where we do
not have an anchor where to put the BIU initialization (since there are
no machine descriptors).
Signed-off-by: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm/mach-bcm/brcmstb.c | 2 --
drivers/soc/bcm/brcmstb/biuctrl.c | 6 ++++--
include/linux/soc/brcmstb/brcmstb.h | 6 ------
3 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-bcm/brcmstb.c b/arch/arm/mach-bcm/brcmstb.c
index 07e3a86c6466..5f127d5f1045 100644
--- a/arch/arm/mach-bcm/brcmstb.c
+++ b/arch/arm/mach-bcm/brcmstb.c
@@ -14,7 +14,6 @@
#include <linux/init.h>
#include <linux/irqchip.h>
#include <linux/of_platform.h>
-#include <linux/soc/brcmstb/brcmstb.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -38,7 +37,6 @@ u32 brcmstb_uart_config[3] = {
static void __init brcmstb_init_irq(void)
{
irqchip_init();
- brcmstb_biuctrl_init();
}
static const char *const brcmstb_match[] __initconst = {
diff --git a/drivers/soc/bcm/brcmstb/biuctrl.c b/drivers/soc/bcm/brcmstb/biuctrl.c
index dd45bbfe64dd..2b23ae7b5e9b 100644
--- a/drivers/soc/bcm/brcmstb/biuctrl.c
+++ b/drivers/soc/bcm/brcmstb/biuctrl.c
@@ -240,7 +240,7 @@ static struct syscore_ops brcmstb_cpu_credit_syscore_ops = {
#endif
-void __init brcmstb_biuctrl_init(void)
+static int __init brcmstb_biuctrl_init(void)
{
int ret;
@@ -249,11 +249,13 @@ void __init brcmstb_biuctrl_init(void)
ret = mcp_write_pairing_set();
if (ret) {
pr_err("MCP: Unable to disable write pairing!\n");
- return;
+ return ret;
}
mcp_b53_set();
#ifdef CONFIG_PM_SLEEP
register_syscore_ops(&brcmstb_cpu_credit_syscore_ops);
#endif
+ return 0;
}
+early_initcall(brcmstb_biuctrl_init);
diff --git a/include/linux/soc/brcmstb/brcmstb.h b/include/linux/soc/brcmstb/brcmstb.h
index 12e548938bbb..8e884e0dda0a 100644
--- a/include/linux/soc/brcmstb/brcmstb.h
+++ b/include/linux/soc/brcmstb/brcmstb.h
@@ -13,12 +13,6 @@ static inline u32 BRCM_REV(u32 reg)
}
/*
- * Bus Interface Unit control register setup, must happen early during boot,
- * before SMP is brought up, called by machine entry point.
- */
-void brcmstb_biuctrl_init(void);
-
-/*
* Helper functions for getting family or product id from the
* SoC driver.
*/
--
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 related
* Re: [PATCH v2 25/35] nds32: Build infrastructure
From: Arnd Bergmann @ 2017-11-29 20:27 UTC (permalink / raw)
To: Greentime Hu
Cc: Geert Uytterhoeven, Greentime, Linux Kernel Mailing List,
linux-arch, Thomas Gleixner, Jason Cooper, Marc Zyngier,
Rob Herring, Networking, Vincent Chen, DTML, Al Viro,
David Howells, Will Deacon, Daniel Lezcano,
linux-serial@vger.kernel.org, Vincent Chen
In-Reply-To: <CAEbi=3fmXP=n_tS+-TSFhdht2G=VHOzVCVU=SRy4A6Ym_GToUQ@mail.gmail.com>
On Wed, Nov 29, 2017 at 3:10 PM, Greentime Hu <green.hu@gmail.com> wrote:
> 2017-11-29 19:57 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
>> On Wed, Nov 29, 2017 at 12:39 PM, Greentime Hu <green.hu@gmail.com> wrote:
>>>
>>> How about this?
>>>
>>> choice
>>> prompt "CPU type"
>>> default CPU_N13
>>> config CPU_N15
>>> bool "AndesCore N15"
>>> select CPU_CACHE_NONALIASING
>>> config CPU_N13
>>> bool "AndesCore N13"
>>> select CPU_CACHE_NONALIASING if ANDES_PAGE_SIZE_8KB
>>> config CPU_N10
>>> bool "AndesCore N10"
>>> select CPU_CACHE_NONALIASING if ANDES_PAGE_SIZE_8KB
>>> config CPU_D15
>>> bool "AndesCore D15"
>>> select CPU_CACHE_NONALIASING
>>> select HWZOL
>>> config CPU_D10
>>> bool "AndesCore D10"
>>> select CPU_CACHE_NONALIASING if ANDES_PAGE_SIZE_8KB
>>> endchoice
>>
>> With a 'choice' statement this works, but I would consider that
>> suboptimal for another reason: now you cannot build a kernel that
>> works on e.g. both N13 and N15.
>>
>> This is what we had on ARM a long time ago and on MIPS not so long
>> ago, but it's really a burden for testing and distribution once you get
>> support for more than a handful of machines supported in the mainline
>> kernel: If each CPU core is mutually incompatible with the other ones,
>> this means you likely end up having one defconfig per CPU core,
>> or even one defconfig per SoC or board.
>>
>> I would always try to get the largest amount of hardware to work
>> in the same kernel concurrently.
>>
>> One way of of this would be to define the "CPU type" as the minimum
>> supported CPU, e.g. selecting D15 would result in a kernel that
>> only works on D15, while selecting N15 would work on both N15 and
>> D15, and selecting D10 would work on both D10 and D15.
>>
>
> Hi, Arnd:
>
> Maybe we should keep the original implementation for this reason.
> The default value of CPU_CACHE_NONALIASING and ANDES_PAGE_SIZE_8KB is
> available for all CPU types for now.
> User can use these configs built kernel to boot on almost all nds32 CPUs.
>
> It might be a little bit weird if we config CPU_N10 but run on a N13 CPU.
> This might confuse our users.
I think it really depends on how much flexibility you want to give to users.
The way I suggested first was to allow selecting an arbitrary combination
of CPUs, and then let Kconfig derive the correct set of optimization flags
and other options that work with those. That is probably the easiest for
the users, but can be tricky to get right for all combinations.
When you put them in a sorted list like I mentioned for simplicity, you
could reduce the confusion by naming them differently, e.g.
CONFIG_CPU_N10_OR_NEWER.
Having only the CPU_CACHE_NONALIASING option is fine if you
never need to make any other decisions based on the CPU core
type, but then the help text should describe specifically which cases
are affected (N10/N13/D13 with 4K page size), and you can decide to
hide the option and make it always-on when using 8K page size.
Arnd
^ 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