* Re: [PATCH v7 04/13] slimbus: core: Add slim controllers support
From: Greg KH @ 2017-11-17 8:13 UTC (permalink / raw)
To: Vinod Koul
Cc: Srinivas Kandagatla, broonie, alsa-devel, sdharia, bp, poeschel,
treding, andreas.noever, alan, mathieu.poirier, daniel, jkosina,
sharon.dvir1, joe, davem, james.hogan, michael.opdenacker,
robh+dt, pawel.moll, mark.rutland, devicetree, linux-kernel,
linux-arm-msm, arnd
In-Reply-To: <20171117044222.GK3187@localhost>
On Fri, Nov 17, 2017 at 10:12:22AM +0530, Vinod Koul wrote:
> On Thu, Nov 16, 2017 at 05:29:35PM +0000, Srinivas Kandagatla wrote:
> > thanks for the comments.
> >
> >
> > On 16/11/17 16:42, Vinod Koul wrote:
> > >On Wed, Nov 15, 2017 at 02:10:34PM +0000, srinivas.kandagatla@linaro.org wrote:
> > >
> > >>+static void slim_dev_release(struct device *dev)
> > >>+{
> > >>+ struct slim_device *sbdev = to_slim_device(dev);
> > >>+
> > >>+ put_device(sbdev->ctrl->dev);
> > >
> > >which device would that be?
> > This is controller device
> >
> > >
> > >>+static int slim_add_device(struct slim_controller *ctrl,
> > >>+ struct slim_device *sbdev,
> > >>+ struct device_node *node)
> > >>+{
> > >>+ sbdev->dev.bus = &slimbus_bus;
> > >>+ sbdev->dev.parent = ctrl->dev;
> > >>+ sbdev->dev.release = slim_dev_release;
> > >>+ sbdev->dev.driver = NULL;
> > >>+ sbdev->ctrl = ctrl;
> > >>+
> > >>+ dev_set_name(&sbdev->dev, "%x:%x:%x:%x",
> > >>+ sbdev->e_addr.manf_id,
> > >>+ sbdev->e_addr.prod_code,
> > >>+ sbdev->e_addr.dev_index,
> > >>+ sbdev->e_addr.instance);
> > >>+
> > >>+ get_device(ctrl->dev);
> > >
> > >is this controller device and you ensuring it doesnt go away while you have
> > >slaves on it?
> >
> > Yes.
>
> I thought since you are marking ctrl->dev as parent, the device core should
> ensure that parent doesn't go off when you have child device?
>
> Greg, is that understanding correct, if so we may not need these calls.
That understanding should be correct, as the reference count is
incremented on the parent when a child is added.
It would be trivial for this to be tested, and yes, I am pretty sure you
don't need this call.
thanks,
greg k-h
^ permalink raw reply
* [PATCH 5/5] ARM64: dts: meson-axg: enable I2C Master-1 for the audio speaker
From: Yixun Lan @ 2017-11-17 8:02 UTC (permalink / raw)
To: Wolfram Sang, Rob Herring, Mark Rutland, linux-i2c, devicetree,
Kevin Hilman
Cc: Neil Armstrong, Jerome Brunet, Carlo Caione, Yixun Lan, Jian Hu,
linux-amlogic, linux-arm-kernel, linux-kernel
In-Reply-To: <20171117080236.32504-1-yixun.lan@amlogic.com>
From: Jian Hu <jian.hu@amlogic.com>
In the S400 board, The I2C master-1 is connecting to
the audio speaker daughter board.
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 7b39a9fe2b0f..74730e40f992 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -28,3 +28,9 @@
pinctrl-0 = <ð_rgmii_y_pins>;
pinctrl-names = "default";
};
+
+&i2c_m1 {
+ status = "okay";
+ pinctrl-0 = <&i2c_m1_z_pins>;
+ pinctrl-names = "default";
+};
--
2.14.1
^ permalink raw reply related
* [PATCH 4/5] ARM64: dts: meson-axg: describe pin DT info for I2C controller
From: Yixun Lan @ 2017-11-17 8:02 UTC (permalink / raw)
To: Wolfram Sang, Rob Herring, Mark Rutland, linux-i2c, devicetree,
Kevin Hilman
Cc: Neil Armstrong, Jerome Brunet, Carlo Caione, Yixun Lan, Jian Hu,
linux-amlogic, linux-arm-kernel, linux-kernel
In-Reply-To: <20171117080236.32504-1-yixun.lan@amlogic.com>
From: Jian Hu <jian.hu@amlogic.com>
Describe all the pin mux for the I2C controller which found in
Meson-AXG SoC.
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 64 ++++++++++++++++++++++++++++++
1 file changed, 64 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 99e967aff439..edbfd6022078 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -304,6 +304,70 @@
function = "eth";
};
};
+
+ i2c_m0_pins: i2c_m0 {
+ mux {
+ groups = "i2c_sck_m0",
+ "i2c_sda_m0";
+ function = "i2c_m0";
+ };
+ };
+
+ i2c_m1_z_pins: i2c_m1_z {
+ mux {
+ groups = "i2c_sck_m1_z",
+ "i2c_sda_m1_z";
+ function = "i2c_m1";
+ };
+ };
+
+ i2c_m1_x_pins: i2c_m1_x {
+ mux {
+ groups = "i2c_sck_m1_x",
+ "i2c_sda_m1_x";
+ function = "i2c_m1";
+ };
+ };
+
+ i2c_m2_x_pins: i2c_m2_x {
+ mux {
+ groups = "i2c_sck_m2_x",
+ "i2c_sda_m2_x";
+ function = "i2c_m2";
+ };
+ };
+
+ i2c_m2_a_pins: i2c_m2_a {
+ mux {
+ groups = "i2c_sck_m2_a",
+ "i2c_sda_m2_a";
+ function = "i2c_m2";
+ };
+ };
+
+ i2c_m3_a6_pins: i2c_m3_a6 {
+ mux {
+ groups = "i2c_sda_m3_a6",
+ "i2c_sck_m3_a7";
+ function = "i2c_m3";
+ };
+ };
+
+ i2c_m3_a12_pins: i2c_m3_a12 {
+ mux {
+ groups = "i2c_sda_m3_a12",
+ "i2c_sck_m3_a13";
+ function = "i2c_m3";
+ };
+ };
+
+ i2c_m3_a19_pins: i2c_m3_a19 {
+ mux {
+ groups = "i2c_sda_m3_a19",
+ "i2c_sck_m3_a20";
+ function = "i2c_m3";
+ };
+ };
};
};
--
2.14.1
^ permalink raw reply related
* [PATCH 3/5] ARM64: dts: meson-axg: add I2C DT info for Meson-AXG SoC
From: Yixun Lan @ 2017-11-17 8:02 UTC (permalink / raw)
To: Wolfram Sang, Rob Herring, Mark Rutland, linux-i2c, devicetree,
Kevin Hilman
Cc: Neil Armstrong, Jerome Brunet, Carlo Caione, Yixun Lan, Jian Hu,
linux-amlogic, linux-arm-kernel, linux-kernel
In-Reply-To: <20171117080236.32504-1-yixun.lan@amlogic.com>
From: Jian Hu <jian.hu@amlogic.com>
There are four I2C masters in EE domain, and one I2C Master in
AO domain, the DT info here should describe them all.
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 59 ++++++++++++++++++++++++++++++
1 file changed, 59 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 57faaa9d8013..99e967aff439 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -129,6 +129,54 @@
#reset-cells = <1>;
};
+ i2c_m0: i2c@1f000 {
+ compatible = "amlogic,meson-axg-i2c";
+ status = "disabled";
+ reg = <0x0 0x1f000 0x0 0x20>;
+ interrupts = <GIC_SPI 21 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 47 IRQ_TYPE_EDGE_RISING>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clkc CLKID_I2C>;
+ clock-names = "clk_i2c";
+ };
+
+ i2c_m1: i2c@1e000 {
+ compatible = "amlogic,meson-axg-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0x1e000 0x0 0x20>;
+ status = "disabled";
+ interrupts = <GIC_SPI 214 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 48 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&clkc CLKID_I2C>;
+ clock-names = "clk_i2c";
+ };
+
+ i2c_m2: i2c@1d000 {
+ compatible = "amlogic,meson-axg-i2c";
+ status = "disabled";
+ reg = <0x0 0x1d000 0x0 0x20>;
+ interrupts = <GIC_SPI 215 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 49 IRQ_TYPE_EDGE_RISING>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clkc CLKID_I2C>;
+ clock-names = "clk_i2c";
+ };
+
+ i2c_m3: i2c@1c000 {
+ compatible = "amlogic,meson-axg-i2c";
+ status = "disabled";
+ reg = <0x0 0x1c000 0x0 0x20>;
+ interrupts = <GIC_SPI 39 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 50 IRQ_TYPE_EDGE_RISING>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clkc CLKID_I2C>;
+ clock-names = "clk_i2c";
+ };
+
uart_A: serial@24000 {
compatible = "amlogic,meson-gx-uart", "amlogic,meson-uart";
reg = <0x0 0x24000 0x0 0x14>;
@@ -312,6 +360,17 @@
};
};
+ i2c_ao: i2c@5000 {
+ compatible = "amlogic,meson-axg-i2c";
+ status = "disabled";
+ reg = <0x0 0x05000 0x0 0x20>;
+ interrupts = <GIC_SPI 195 IRQ_TYPE_EDGE_RISING>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clkc CLKID_I2C>;
+ clock-names = "clk_i2c";
+ };
+
uart_AO: serial@3000 {
compatible = "amlogic,meson-gx-uart", "amlogic,meson-ao-uart";
reg = <0x0 0x3000 0x0 0x18>;
--
2.14.1
^ permalink raw reply related
* [PATCH 2/5] i2c: meson: add configurable divider factors
From: Yixun Lan @ 2017-11-17 8:02 UTC (permalink / raw)
To: Wolfram Sang, Rob Herring, Mark Rutland, linux-i2c, devicetree,
Kevin Hilman
Cc: Neil Armstrong, Jerome Brunet, Carlo Caione, Yixun Lan, Jian Hu,
linux-amlogic, linux-arm-kernel, linux-kernel
In-Reply-To: <20171117080236.32504-1-yixun.lan@amlogic.com>
From: Jian Hu <jian.hu@amlogic.com>
This patch try to add support for I2C controller in Meson-AXG SoC,
Due to the IP changes between I2C controller, we need to introduce
a compatible data to make the divider factor configurable.
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
drivers/i2c/busses/i2c-meson.c | 32 ++++++++++++++++++++++++++++----
1 file changed, 28 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-meson.c b/drivers/i2c/busses/i2c-meson.c
index 88d15b92ec35..517f2cddeff3 100644
--- a/drivers/i2c/busses/i2c-meson.c
+++ b/drivers/i2c/busses/i2c-meson.c
@@ -16,6 +16,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/of_device.h>
#include <linux/platform_device.h>
#include <linux/types.h>
@@ -57,6 +58,10 @@ enum {
STATE_WRITE,
};
+struct meson_i2c_data {
+ unsigned char div_factor;
+};
+
/**
* struct meson_i2c - Meson I2C device private data
*
@@ -93,6 +98,8 @@ struct meson_i2c {
struct completion done;
u32 tokens[2];
int num_tokens;
+
+ struct meson_i2c_data *data;
};
static void meson_i2c_set_mask(struct meson_i2c *i2c, int reg, u32 mask,
@@ -128,7 +135,7 @@ static void meson_i2c_set_clk_div(struct meson_i2c *i2c, unsigned int freq)
unsigned long clk_rate = clk_get_rate(i2c->clk);
unsigned int div;
- div = DIV_ROUND_UP(clk_rate, freq * 4);
+ div = DIV_ROUND_UP(clk_rate, freq * i2c->data->div_factor);
/* clock divider has 12 bits */
if (div >= (1 << 12)) {
@@ -376,6 +383,9 @@ static int meson_i2c_probe(struct platform_device *pdev)
spin_lock_init(&i2c->lock);
init_completion(&i2c->done);
+ i2c->data = (struct meson_i2c_data *)
+ of_device_get_match_data(&pdev->dev);
+
i2c->clk = devm_clk_get(&pdev->dev, NULL);
if (IS_ERR(i2c->clk)) {
dev_err(&pdev->dev, "can't get device clock\n");
@@ -440,11 +450,25 @@ static int meson_i2c_remove(struct platform_device *pdev)
return 0;
}
+static const struct meson_i2c_data i2c_meson6_data = {
+ .div_factor = 4,
+};
+
+static const struct meson_i2c_data i2c_gxbb_data = {
+ .div_factor = 4,
+};
+
+static const struct meson_i2c_data i2c_axg_data = {
+ .div_factor = 3,
+};
+
static const struct of_device_id meson_i2c_match[] = {
- { .compatible = "amlogic,meson6-i2c" },
- { .compatible = "amlogic,meson-gxbb-i2c" },
- { },
+ { .compatible = "amlogic,meson6-i2c", .data = &i2c_meson6_data },
+ { .compatible = "amlogic,meson-gxbb-i2c", .data = &i2c_gxbb_data },
+ { .compatible = "amlogic,meson-axg-i2c", .data = &i2c_axg_data },
+ {},
};
+
MODULE_DEVICE_TABLE(of, meson_i2c_match);
static struct platform_driver meson_i2c_driver = {
--
2.14.1
^ permalink raw reply related
* [PATCH 1/5] dt-bindings: i2c: update documentation for the Meson-AXG
From: Yixun Lan @ 2017-11-17 8:02 UTC (permalink / raw)
To: Wolfram Sang, Rob Herring, Mark Rutland, linux-i2c, devicetree,
Kevin Hilman
Cc: Neil Armstrong, Jerome Brunet, Carlo Caione, Yixun Lan, Jian Hu,
linux-amlogic, linux-arm-kernel, linux-kernel
In-Reply-To: <20171117080236.32504-1-yixun.lan@amlogic.com>
From: Jian Hu <jian.hu@amlogic.com>
Update the doc to explicitly add Meson-AXG to support list
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
Documentation/devicetree/bindings/i2c/i2c-meson.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-meson.txt b/Documentation/devicetree/bindings/i2c/i2c-meson.txt
index 611b934c7e10..3097d2b44dad 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-meson.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-meson.txt
@@ -2,6 +2,7 @@ Amlogic Meson I2C controller
Required properties:
- compatible: must be "amlogic,meson6-i2c" or "amlogic,meson-gxbb-i2c"
+ "amlogic,meson-axg-i2c"
- reg: physical address and length of the device registers
- interrupts: a single interrupt specifier
- clocks: clock for the device
--
2.14.1
^ permalink raw reply related
* [PATCH 0/5] i2c: meson-axg: add I2C controller driver
From: Yixun Lan @ 2017-11-17 8:02 UTC (permalink / raw)
To: Wolfram Sang, Rob Herring, Mark Rutland, linux-i2c, devicetree,
Kevin Hilman
Cc: Neil Armstrong, Jerome Brunet, Carlo Caione, Yixun Lan, Jian Hu,
linux-amlogic, linux-arm-kernel, linux-kernel
This patch set try to add I2C controller driver for
the Amlogic's Meson-AXG SoC.
Jian Hu (5):
dt-bindings: i2c: update documentation for the Meson-AXG
i2c: meson: add configurable divider factors
ARM64: dts: meson-axg: add I2C DT info for Meson-AXG SoC
ARM64: dts: meson-axg: describe pin DT info for I2C controller
ARM64: dts: meson-axg: enable I2C Master-1 for the audio speaker
.../devicetree/bindings/i2c/i2c-meson.txt | 1 +
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 6 +
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 123 +++++++++++++++++++++
drivers/i2c/busses/i2c-meson.c | 32 +++++-
4 files changed, 158 insertions(+), 4 deletions(-)
--
2.14.1
^ permalink raw reply
* Re: Cedrus driver
From: Maxime Ripard @ 2017-11-17 8:01 UTC (permalink / raw)
To: Nicolas Dufresne
Cc: Giulio Benetti, Andreas Baierl,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, wens-jdAy2FN1RRM,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
thomas-XCRq7eEM0/pmR6Xm/wNWPw, linux-media-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1510862395.8053.39.camel-dDhyB4GVkw9AFePFGvp55w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2197 bytes --]
Hi Nicolas,
On Thu, Nov 16, 2017 at 02:59:55PM -0500, Nicolas Dufresne wrote:
> Le jeudi 16 novembre 2017 à 12:02 +0100, Maxime Ripard a écrit :
> > Assuming that the request API is in, we'd need to:
> > - Finish the MPEG4 support
> > - Work on more useful codecs (H264 comes to my mind)
>
> For which we will have to review the tables and make sure they match
> the spec (the easy part). But as an example, that branch uses a table
> that merge Mpeg4 VOP and VOP Short Header. We need to make sure it does
> not pause problems or split it up. On top of that, ST and Rockchip
> teams should give some help and sync with these tables on their side.
> We also need to consider decoder like Tegra 2. In H264, they don't need
> frame parsing, but just the PPS/SPS data (might just be parsed in the
> driver, like CODA ?). There is other mode of operation, specially in
> H264/HEVC low latency, where the decoder will be similar, but will
> accept and process slices right away, without waiting for the full
> frame.
Sorry if it's a dumb question, but what branches and tables are you
talking about here?
> We also need some doc, to be able to tell the GStreamer and FFMPEG team
> how to detect and handle these decoder. I doubt the libv4l2 proposed
> approach will be used for these two projects since they already have
> their own parser and would like to not parse twice. As an example, we
> need to document that V4L2_PIX_FMT_MPEG2_FRAME implies using the
> Request API and specific CID. We should probably also ping the Chrome
> Devs, which probably have couple of pending branches around this.
We've had a prototype that wasn't based on libv4l but was based on the
VA-API, and it's been working great for us so far.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH] omapdrm: hdmi4: Correct the SoC revision matching
From: Peter Ujfalusi @ 2017-11-17 8:00 UTC (permalink / raw)
To: tomi.valkeinen, laurent.pinchart, jsarha
Cc: airlied, dri-devel, devicetree, daniel, stable
I believe the intention of the commit 2c9fc9bf45f8
("drm: omapdrm: Move FEAT_HDMI_* features to hdmi4 driver")
was to identify omap4430 ES1.x, omap4430 ES2.x and other OMAP4 revisions,
like omap4460.
By using family=OMAP4 in the match the code will treat omap4460 ES1.x in a
same way as it would treat omap4430 ES1.x
This breaks HDMI audio on OMAP4460 devices (PandaES for example).
Correct the match rule so we are not going to get false positive match.
Fixes: 2c9fc9bf45f8 ("drm: omapdrm: Move FEAT_HDMI_* features to hdmi4 driver")
CC: stable@vger.kernel.org # 4.14
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/gpu/drm/omapdrm/dss/hdmi4_core.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c b/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c
index 62e451162d96..07945a40c33a 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c
@@ -902,9 +902,20 @@ static const struct hdmi4_features hdmi4_es3_features = {
};
static const struct soc_device_attribute hdmi4_soc_devices[] = {
- { .family = "OMAP4", .revision = "ES1.?", .data = &hdmi4_es1_features },
- { .family = "OMAP4", .revision = "ES2.?", .data = &hdmi4_es2_features },
- { .family = "OMAP4", .data = &hdmi4_es3_features },
+ {
+ .machine = "OMAP4430",
+ .revision = "ES1.?",
+ .data = &hdmi4_es1_features,
+ },
+ {
+ .machine = "OMAP4430",
+ .revision = "ES2.?",
+ .data = &hdmi4_es2_features,
+ },
+ {
+ .family = "OMAP4",
+ .data = &hdmi4_es3_features,
+ },
{ /* sentinel */ }
};
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply related
* Re: [PATCH] ARM: dts: bcm283x: Fix fifo size for EP 6,7
From: Minas Harutyunyan @ 2017-11-17 7:48 UTC (permalink / raw)
To: Stefan Wahren, Eric Anholt, Rob Herring, Minas Harutyunyan,
John Youn, Mark Rutland
Cc: Phil Elwell, linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Florian Fainelli,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <2056429546.196128.1510871632211@email.1und1.de>
On 11/17/2017 2:35 AM, Stefan Wahren wrote:
> Hi Eric,
>
>> Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org> hat am 31. Oktober 2017 um 09:43 geschrieben:
>>
>>
>> Hi Eric,
>>
>>> Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org> hat am 31. Oktober 2017 um 01:40 geschrieben:
>>>
>>>
>>> Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org> writes:
>>>
>>>>> Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org> hat am 7. Oktober 2017 um 12:16 geschrieben:
>>>>>
>>>>>
>>>>> In case the RPi Zero has at least a device connected to the OTG port
>>>>> at boot time, the upper limit of tx fifo size for endpoint 6 and 7 is
>>>>> also reduced to 512 bytes. So fix this accordingly.
>>>>>
>>>>> Signed-off-by: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
>>>>> Fixes: 1aa1d858f582 ("ARM: dts: bcm283x: Add dtsi for OTG mode")
>>>>
>>>> gentle ping ...
>>>
>>> I've tried to make sense of this a couple of times, but I don't get it:
>>> why does EP 6/7 get reduced to 512 bytes in this case?
>>
>> i cannot give you an answer for this specific case.
>>
>> Since the dwc2 databook isn't public, i started a thread on linux-usb [1] about proper fifo size configuration. But i didn't get any reply.
>>
>> The problem here is there different contraints:
>> * the sum of all fifo values must not exceed 3776 bytes
>> * each slot have its individual upper limit (available in the BCM2835 datasheet)
>>
>> During my tests for OTG mode i missed the specific case above. Now my determined limits of 512 for EP 6 and 7 are contrary to the BCM2835 datasheet. Maybe the Synopsys guys have an answer?
>>
>> Btw the values in the downstream tree also violate the contraints.
>>
>> [1] - https://urldefense.proofpoint.com/v2/url?u=https-3A__www.spinics.net_lists_linux-2Dusb_msg157200.html&d=DwICaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=6z9Al9FrHR_ZqbbtSAsD16pvOL2S3XHxQnSzq8kusyI&m=O2ngUGajgx3MfHk4IQKp5iRlwOOpG62gkji4R2gE64k&s=8ClOBwWN5B69mL1TDjnN3l78JBrvd1YHunRdzei-xrA&e=
>
> still concerns about this patch, because it's not included in dt-fixes?
>
Hi Stefan,
According BCM2835 datasheet Total Data FIFO RAM Depth is 4096. I assume
that in datasheet assumed 4096 dwords, not a bytes. DFIFO depth in
dwords stored GHWCFG3[31:16].
So, for buffer DMA mode max space in dwords which available to allocate
to FIFO's is 4096-8*2=4080, where 8 EP count including EP0 and 2 for
both directions of EP's. Based on bcm283x-rpi-usb-otg.dtsi:
g-rx-fifo-size + g-np-tx-fifo-size + g-tx-fifo-size[1..7] =
256+32+256+256+512+512+512+768+768 = 3872 < 4080.
So, I don't see any reason to change EP 6,7 TxFIFO sizes.
More probably comment in dtsi not correct:
"* fifo sizes shouldn't exceed 3776 bytes."
Please check FIFO depth in GHWCFG3 and if it 4096 then update the comment.
Thanks,
Minas
--
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 v7 06/13] slimbus: Add messaging APIs to slimbus framework
From: Vinod Koul @ 2017-11-17 7:48 UTC (permalink / raw)
To: srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
broonie-DgEjT+Ai2ygdnm+yROfE0A, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
sdharia-sgV2jX0FEOL9JmXXK+q4OQ, bp-l3A5Bk7waGM,
poeschel-Xtl8qvBWbHwb1SvskN2V4Q, treding-DDmLM1+adcrQT0dZR+AlfA,
andreas.noever-Re5JQEeQqe8AvxtiuMwx3w,
alan-VuQAYsv1563Yd54FQh9/CA,
mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A, daniel-/w4YWyX8dFk,
jkosina-AlSwsSmVLrQ, sharon.dvir1-MQgwKvJRKlGYZoqfULhbRA,
joe-6d6DIl74uiNBDgjK7y7TUQ, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
james.hogan-1AXoQHu6uovQT0dZR+AlfA,
michael.opdenacker-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, pawel.moll-5wv7dgnIgG8,
mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4
In-Reply-To: <20171115141043.29202-7-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Wed, Nov 15, 2017 at 02:10:36PM +0000, srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org wrote:
> +void slim_msg_response(struct slim_controller *ctrl, u8 *reply, u8 tid, u8 len)
> +{
> + struct slim_msg_txn *txn;
> + struct slim_val_inf *msg;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&ctrl->txn_lock, flags);
Do you need this to be a _irqsave variant? What is the context of io
transfers in this case
> +/**
> + * slim_do_transfer() - Process a slimbus-messaging transaction
> + *
> + * @ctrl: Controller handle
> + * @txn: Transaction to be sent over SLIMbus
> + *
> + * Called by controller to transmit messaging transactions not dealing with
> + * Interface/Value elements. (e.g. transmittting a message to assign logical
> + * address to a slave device
> + *
> + * Return: -ETIMEDOUT: If transmission of this message timed out
> + * (e.g. due to bus lines not being clocked or driven by controller)
> + * -ENOTCONN: If the transmitted message was not ACKed by destination
> + * device.
I am preferring ENODATA in SDW for this case, as Slaves didnt respond or
ACK.
ENOTCONN is defined as /* Transport endpoint is not connected */ which is
not the case here, connected yes but not responded.
> +static int slim_val_inf_sanity(struct slim_controller *ctrl,
> + struct slim_val_inf *msg, u8 mc)
> +{
> + if (!msg || msg->num_bytes > 16 ||
> + (msg->start_offset + msg->num_bytes) > 0xC00)
> + goto reterr;
> + switch (mc) {
> + case SLIM_MSG_MC_REQUEST_VALUE:
> + case SLIM_MSG_MC_REQUEST_INFORMATION:
> + if (msg->rbuf != NULL)
> + return 0;
> + break;
empty line here and after each break make it look better
> + case SLIM_MSG_MC_CHANGE_VALUE:
> + case SLIM_MSG_MC_CLEAR_INFORMATION:
> + if (msg->wbuf != NULL)
> + return 0;
> + break;
> + case SLIM_MSG_MC_REQUEST_CHANGE_VALUE:
> + case SLIM_MSG_MC_REQUEST_CLEAR_INFORMATION:
> + if (msg->rbuf != NULL && msg->wbuf != NULL)
> + return 0;
> + break;
> + default:
> + break;
this seems superflous and we can just fall thru to error below.
> + }
> +reterr:
> + dev_err(ctrl->dev, "Sanity check failed:msg:offset:0x%x, mc:%d\n",
> + msg->start_offset, mc);
> + return -EINVAL;
...
> +static int slim_xfer_msg(struct slim_controller *ctrl,
> + struct slim_device *sbdev,
> + struct slim_val_inf *msg, u8 mc)
> +{
> + DEFINE_SLIM_LDEST_TXN(txn_stack, mc, 6, sbdev->laddr, msg);
> + struct slim_msg_txn *txn = &txn_stack;
> + int ret;
> + u16 sl;
> +
> + ret = slim_val_inf_sanity(ctrl, msg, mc);
> + if (ret)
> + return ret;
> +
> + sl = slim_slicesize(msg->num_bytes);
> +
> + dev_dbg(ctrl->dev, "SB xfer msg:os:%x, len:%d, MC:%x, sl:%x\n",
> + msg->start_offset, msg->num_bytes, mc, sl);
better to add tracing support for these debug prints
> +
> + txn->ec = ((sl | (1 << 3)) | ((msg->start_offset & 0xFFF) << 4));
> +
> + switch (mc) {
> + case SLIM_MSG_MC_REQUEST_CHANGE_VALUE:
> + case SLIM_MSG_MC_CHANGE_VALUE:
> + case SLIM_MSG_MC_REQUEST_CLEAR_INFORMATION:
> + case SLIM_MSG_MC_CLEAR_INFORMATION:
> + txn->rl += msg->num_bytes;
> + default:
> + break;
> + }
> +
> + if (slim_tid_txn(txn->mt, txn->mc))
> + txn->rl++;
> +
> + return slim_do_transfer(ctrl, txn);
> +}
> +
> +/**
> + * slim_request_val_element() - request value element
> + *
> + * @sb: client handle requesting elemental message reads, writes.
> + * @msg: Input structure for start-offset, number of bytes to read.
> + * context: can sleep
> + *
> + * Return: -EINVAL: Invalid parameters
> + * -ETIMEDOUT: If transmission of this message timed out (e.g. due to
> + * bus lines not being clocked or driven by controller)
> + * -ENOTCONN: If the transmitted message was not ACKed by the device.
> + */
> +int slim_request_val_element(struct slim_device *sb,
> + struct slim_val_inf *msg)
> +{
> + struct slim_controller *ctrl = sb->ctrl;
> +
> + if (!ctrl)
> + return -EINVAL;
> +
> + return slim_xfer_msg(ctrl, sb, msg, SLIM_MSG_MC_REQUEST_VALUE);
> +}
> +EXPORT_SYMBOL_GPL(slim_request_val_element);
> +
> +/**
> + * slim_request_inf_element() - Request a info element
> + *
> + * @sb: client handle requesting elemental message reads.
> + * @msg: Input structure for start-offset, number of bytes to read
> + * wbuf will contain information element(s) bit masks to be cleared.
> + * rbuf will return what the information element value was
> + */
> +int slim_request_inf_element(struct slim_device *sb,
> + struct slim_val_inf *msg)
> +{
> + struct slim_controller *ctrl = sb->ctrl;
> +
> + if (!ctrl)
> + return -EINVAL;
> +
> + return slim_xfer_msg(ctrl, sb, msg, SLIM_MSG_MC_REQUEST_INFORMATION);
> +}
> +EXPORT_SYMBOL_GPL(slim_request_inf_element);
> +
> +/**
> + * slim_change_val_element: change a given value element
> + *
> + * @sb: client handle requesting elemental message reads, writes.
> + * @msg: Input structure for start-offset, number of bytes to write.
> + * context: can sleep
> + *
> + * Return:
> + * -EINVAL: Invalid parameters
> + * -ETIMEDOUT: If transmission of this message timed out (e.g. due to
> + * bus lines not being clocked or driven by controller)
> + * -ENOTCONN: If the transmitted message was not ACKed by the device.
> + */
> +int slim_change_val_element(struct slim_device *sb, struct slim_val_inf *msg)
> +{
> + struct slim_controller *ctrl = sb->ctrl;
> +
> + if (!ctrl)
> + return -EINVAL;
> +
> + return slim_xfer_msg(ctrl, sb, msg, SLIM_MSG_MC_CHANGE_VALUE);
> +}
> +EXPORT_SYMBOL_GPL(slim_change_val_element);
> +
> +/**
> + * slim_clear_inf_element() - Clear info element
> + *
> + * @sb: client handle requesting elemental message reads, writes.
> + * @msg: Input structure for start-offset, number of bytes to read
> + * wbuf will contain information element(s) bit masks to be cleared.
> + * rbuf will return what the information element value was
> + */
> +int slim_clear_inf_element(struct slim_device *sb, struct slim_val_inf *msg)
> +{
> + struct slim_controller *ctrl = sb->ctrl;
> +
> + if (!ctrl)
> + return -EINVAL;
> +
> + return slim_xfer_msg(ctrl, sb, msg, SLIM_MSG_MC_CLEAR_INFORMATION);
> +}
> +EXPORT_SYMBOL_GPL(slim_clear_inf_element);
> +
> +/**
> + * slim_request_val_element() - change and request a given value element
> + *
> + * @sb: client handle requesting elemental message reads, writes.
> + * @msg: Input structure for start-offset, number of bytes to write.
> + * context: can sleep
> + *
> + * Return:
> + * -EINVAL: Invalid parameters
> + * -ETIMEDOUT: If transmission of this message timed out (e.g. due to
> + * bus lines not being clocked or driven by controller)
> + * -ENOTCONN: If the transmitted message was not ACKed by the device.
> + */
> +int slim_request_change_val_element(struct slim_device *sb,
> + struct slim_val_inf *msg)
> +{
> + struct slim_controller *ctrl = sb->ctrl;
> +
> + if (!ctrl)
> + return -EINVAL;
> +
> + return slim_xfer_msg(ctrl, sb, msg, SLIM_MSG_MC_REQUEST_CHANGE_VALUE);
> +}
> +EXPORT_SYMBOL_GPL(slim_request_change_val_element);
looking at this, does it really help to have different APIs for SLIM_MSG_XXX
why not slim_xfer_msg() be an exported one..
> +int slim_write(struct slim_device *sdev, u32 addr, size_t count, u8 *val)
> +{
> + struct slim_val_inf msg;
> + int ret;
> +
> + slim_fill_msg(&msg, addr, count, val, NULL);
> + ret = slim_change_val_element(sdev, &msg);
return slim_change_val_element()
> +
> + return ret;
> +
> +}
...
> +/* Destination type Values */
> +#define SLIM_MSG_DEST_LOGICALADDR 0
> +#define SLIM_MSG_DEST_ENUMADDR 1
> +#define SLIM_MSG_DEST_BROADCAST 3
^^^
why tab here
--
~Vinod
--
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: [alsa-devel] [PATCH v7 05/13] slimbus: core: add support to device tree helper
From: Vinod Koul @ 2017-11-17 7:11 UTC (permalink / raw)
To: srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
broonie-DgEjT+Ai2ygdnm+yROfE0A, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
mark.rutland-5wv7dgnIgG8,
michael.opdenacker-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
poeschel-Xtl8qvBWbHwb1SvskN2V4Q,
andreas.noever-Re5JQEeQqe8AvxtiuMwx3w, arnd-r2nGTMty4D4,
bp-l3A5Bk7waGM, devicetree-u79uwXL29TY76Z2rM5mHXA,
james.hogan-1AXoQHu6uovQT0dZR+AlfA, pawel.moll-5wv7dgnIgG8,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
sharon.dvir1-MQgwKvJRKlGYZoqfULhbRA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, sdharia-sgV2jX0FEOL9JmXXK+q4OQ,
alan-VuQAYsv1563Yd54FQh9/CA, treding-DDmLM1+adcrQT0dZR+AlfA,
mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A, jkosina-AlSwsSmVLrQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, daniel-/w4YWyX8dFk,
joe-6d6DIl74uiNBDgjK7y7TUQ, davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <20171115141043.29202-6-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Wed, Nov 15, 2017 at 02:10:35PM +0000, srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org wrote:
> +
> + for_each_child_of_node(ctrl->dev->of_node, node) {
> + struct slim_device *sbdev;
> + struct slim_eaddr e_addr;
> + const char *compat = NULL;
> + int reg[2], ret;
> + int manf_id, prod_code;
> +
> + compat = of_get_property(node, "compatible", NULL);
> + if (!compat)
> + continue;
> +
> + ret = sscanf(compat, "slim%x,%x", &manf_id, &prod_code);
> + if (ret != 2) {
> + dev_err(dev, "Manf ID & Product code not found %s\n",
> + compat);
> + continue;
> + }
can we do xxx_property_read_u32() on compat and then use bit manupliations
to get ids rather than scanf.
> +
> + ret = of_property_read_u32_array(node, "reg", reg, 2);
I typically prefer using device_property_read_u32() but then this is of_
code so I will leave this upto you...
--
~Vinod
--
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 V1 1/4] qcom: spmi-wled: Add support for qcom wled driver
From: Bjorn Andersson @ 2017-11-17 6:56 UTC (permalink / raw)
To: kgunda
Cc: linux-arm-msm, Lee Jones, Daniel Thompson, Jingoo Han,
Richard Purdie, Jacek Anaszewski, Pavel Machek, Rob Herring,
Mark Rutland, Bartlomiej Zolnierkiewicz, linux-leds, devicetree,
linux-kernel, linux-fbdev, linux-arm-msm-owner
In-Reply-To: <208c7332234581909f159ddb33ede32b@codeaurora.org>
On Thu 16 Nov 22:36 PST 2017, kgunda@codeaurora.org wrote:
> On 2017-11-16 22:25, Bjorn Andersson wrote:
> > On Thu 16 Nov 04:18 PST 2017, Kiran Gunda wrote:
> >
> > > WLED driver provides the interface to the display driver to
> > > adjust the brightness of the display backlight.
> > >
> >
> > Hi Kiran,
> >
> > This driver has a lot in common with the already upstream pm8941-wled.c,
> > because it's just a new revision of the same block.
> >
> > Please extend the existing driver rather than providing a new one
> > (and yes, renaming the file is okay).
> >
> > Regards,
> > Bjorn
>
> Hi Bjorn,
>
> Yes this driver design is similar to pm8941, however the WLED HW block
> has undergone quite a few changes in analog and digital from PM8941 to
> PM8998.
I can see that, looking at the documentation.
> Few of them include splitting one module into wled-ctrl and wled-sink
> peripherals, changes in the register offsets and the bit
> interpretation.
This is typical and something we need to handle in all these drivers, to
avoid having one driver per platform.
> Hence we concluded that it was better to have a new driver to support
> this new gen WELD module and decouple it from the pm8941.
Okay, I can see how it's easier to not have to case about anything but
pmi8998 in this driver, but where do you add the support for other WLED
versions? What about PMI8994? Will there not be similar differences
(registers that has moved around) in the future?
> Also, going forward this driver will support AMOLED AVDD rail (not
> supported by pm8941) touching a few more registers/configuration and
> newer PMICs.
Is this a feature that was introduced in PMI8998? Will this support not
be dependent on the pmic version?
> So spinning off a new driver would make it cleaner and easier to
> extend further.
>
It's for sure easier at this point in time, but your argumentation
implies that PMI8998+1 should go into it's own driver as well.
I suspect that if you're going to reuse this driver for future PMIC
versions you will have to deal with register layout differences and new
feature set, and as such I'm not convinced that a new driver is needed.
Can you give any concrete examples of where it is not possible or
undesirable to maintain the pm8941 support in the same driver?
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH V1 1/4] qcom: spmi-wled: Add support for qcom wled driver
From: kgunda @ 2017-11-17 6:36 UTC (permalink / raw)
To: Bjorn Andersson
Cc: linux-arm-msm, Lee Jones, Daniel Thompson, Jingoo Han,
Richard Purdie, Jacek Anaszewski, Pavel Machek, Rob Herring,
Mark Rutland, Bartlomiej Zolnierkiewicz, linux-leds, devicetree,
linux-kernel, linux-fbdev, linux-arm-msm-owner
In-Reply-To: <20171116165510.GP28761@minitux>
On 2017-11-16 22:25, Bjorn Andersson wrote:
> On Thu 16 Nov 04:18 PST 2017, Kiran Gunda wrote:
>
>> WLED driver provides the interface to the display driver to
>> adjust the brightness of the display backlight.
>>
>
> Hi Kiran,
>
> This driver has a lot in common with the already upstream
> pm8941-wled.c,
> because it's just a new revision of the same block.
>
> Please extend the existing driver rather than providing a new one
> (and yes, renaming the file is okay).
>
> Regards,
> Bjorn
Hi Bjorn,
Yes this driver design is similar to pm8941, however the WLED HW block
has undergone quite a few changes in
analog and digital from PM8941 to PM8998. Few of them include splitting
one module into wled-ctrl
and wled-sink peripherals, changes in the register offsets and the bit
interpretation. Hence we
concluded that it was better to have a new driver to support this new
gen WELD module and decouple
it from the pm8941. Also, going forward this driver will support AMOLED
AVDD rail (not supported by pm8941)
touching a few more registers/configuration and newer PMICs. So spinning
off a new driver would make it
cleaner and easier to extend further.
Thanks,
Kiran
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-arm-msm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [RFCv2 PATCH 31/36] iommu/arm-smmu-v3: Add support for PCI ATS
From: Bharat Kumar Gogada @ 2017-11-17 6:11 UTC (permalink / raw)
To: Jean-Philippe Brucker,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Cc: Mark Rutland,
gabriele.paoloni-hv44wF8Li93QT0dZR+AlfA@public.gmane.org,
Catalin Marinas, Will Deacon,
okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
rfranz-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org,
lenb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org,
rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org, Sudeep Holla
In-Reply-To: <673fda01-2ae0-87e4-637e-fe27096b6be0-5wv7dgnIgG8@public.gmane.org>
> +
> + spin_lock_irqsave(&smmu_domain->devices_lock, flags);
> + list_for_each_entry(master, &smmu_domain->devices, list)
> + arm_smmu_atc_inv_master(master, &cmd);
> + spin_unlock_irqrestore(&smmu_domain->devices_lock, flags);
> +
> + return size;
> +}
> +
> /* IOMMU API */
> static bool arm_smmu_capable(enum iommu_cap cap) { @@ -2361,6 +2506,8 @@ static void arm_smmu_detach_dev(struct device *dev)
> __iommu_process_unbind_dev_all(&smmu_domain->domain, dev);
>
> if (smmu_domain) {
> + arm_smmu_atc_inv_master_all(master, 0);
> +
> In BIND flow, when VFIO_IOMMU_UNBIND is invoked invalidation is sent on allocated PASID for this application.
> When vfio group fd is closed after UNBIND, arm_smmu_detach_dev is invoked now invalidation is being sent on ssid zero.
> Why invalidation needs to be sent on ssid zero ?
It's possible to use bind/unbind and map/unmap APIs at the same time on a domain. map/unmap modifies non-ssid mappings as usual, for context descriptor 0. Note that SSID 0 is converted to "no SSID" by arm_smmu_atc_inv_to_cmd.
That said, I think VFIO cleans all DMA mappings when the VFIO group fd is closed, which will send individual ATC invalidation for each mapping. But VFIO may not be the only user of this API, and future users may be less careful. It's safer to send this global invalidation whenever we detach the domain, to ensure we're not leaving stale ATC entries for the next user.
Thanks Jean, I see that currently vfio_group_fops_open does not allow multiple instances.
If a device supports multiple PASID there might be different applications running parallel.
So why is multiple instances restricted ?
Regards,
Bharat
^ permalink raw reply
* [PATCH 4/4] arm64: dts: uniphier: add GPIO hog definition for PXs3
From: Masahiro Yamada @ 2017-11-17 5:24 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, devicetree, Catalin Marinas, Will Deacon,
linux-kernel, Masahiro Yamada, Rob Herring
In-Reply-To: <1510896288-31212-1-git-send-email-yamada.masahiro@socionext.com>
Commit 15e85695e500 ("arm64: dts: uniphier: add GPIO hog definition")
missed to update the PXs3 DTS for some reason. Do it now.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
arch/arm64/boot/dts/socionext/uniphier-pxs3-ref.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/socionext/uniphier-pxs3-ref.dts b/arch/arm64/boot/dts/socionext/uniphier-pxs3-ref.dts
index 5c5e9cb..c36106f 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-pxs3-ref.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-pxs3-ref.dts
@@ -45,6 +45,14 @@
status = "okay";
};
+&gpio {
+ xirq4 {
+ gpio-hog;
+ gpios = <UNIPHIER_GPIO_IRQ(4) 0>;
+ input;
+ };
+};
+
&i2c0 {
status = "okay";
};
--
2.7.4
^ permalink raw reply related
* [PATCH 3/4] arm64: dts: uniphier: use macros in dt-bindings header
From: Masahiro Yamada @ 2017-11-17 5:24 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, devicetree, Catalin Marinas, Will Deacon,
linux-kernel, Masahiro Yamada, Rob Herring
In-Reply-To: <1510896288-31212-1-git-send-email-yamada.masahiro@socionext.com>
The dt-bindings header was applied to the driver subsystem. I had to
wait for a merge window to use it from DT.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts | 2 +-
arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 3 ++-
arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts | 2 +-
arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 3 ++-
arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi | 3 ++-
5 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts b/arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts
index 6bdefb2..54c5317 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts
@@ -50,7 +50,7 @@
&gpio {
xirq0 {
gpio-hog;
- gpios = <120 0>;
+ gpios = <UNIPHIER_GPIO_IRQ(0) 0>;
input;
};
};
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
index 1c63d0a..ce40eb5 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
@@ -8,6 +8,7 @@
*/
#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/gpio/uniphier-gpio.h>
/memreserve/ 0x80000000 0x02000000;
@@ -100,7 +101,7 @@
emmc_pwrseq: emmc-pwrseq {
compatible = "mmc-pwrseq-emmc";
- reset-gpios = <&gpio 26 GPIO_ACTIVE_LOW>;
+ reset-gpios = <&gpio UNIPHIER_GPIO_PORT(3, 2) GPIO_ACTIVE_LOW>;
};
timer {
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts b/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
index 254d679..6933710 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
@@ -50,7 +50,7 @@
&gpio {
xirq0 {
gpio-hog;
- gpios = <120 0>;
+ gpios = <UNIPHIER_GPIO_IRQ(0) 0>;
input;
};
};
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
index 5c81070..8a3276b 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
@@ -8,6 +8,7 @@
*/
#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/gpio/uniphier-gpio.h>
#include <dt-bindings/thermal/thermal.h>
/memreserve/ 0x80000000 0x02000000;
@@ -172,7 +173,7 @@
emmc_pwrseq: emmc-pwrseq {
compatible = "mmc-pwrseq-emmc";
- reset-gpios = <&gpio 26 GPIO_ACTIVE_LOW>;
+ reset-gpios = <&gpio UNIPHIER_GPIO_PORT(3, 2) GPIO_ACTIVE_LOW>;
};
timer {
diff --git a/arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi b/arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi
index 48e7331..d2beadd 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi
@@ -8,6 +8,7 @@
*/
#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/gpio/uniphier-gpio.h>
/memreserve/ 0x80000000 0x02000000;
@@ -128,7 +129,7 @@
emmc_pwrseq: emmc-pwrseq {
compatible = "mmc-pwrseq-emmc";
- reset-gpios = <&gpio 47 GPIO_ACTIVE_LOW>;
+ reset-gpios = <&gpio UNIPHIER_GPIO_PORT(5, 7) GPIO_ACTIVE_LOW>;
};
timer {
--
2.7.4
^ permalink raw reply related
* [PATCH 2/4] arm64: dts: uniphier: remove unnecessary interrupt-parent
From: Masahiro Yamada @ 2017-11-17 5:24 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Masahiro Yamada, devicetree, linux-kernel, Rob Herring,
Will Deacon, Mark Rutland, Catalin Marinas
In-Reply-To: <1510896288-31212-1-git-send-email-yamada.masahiro@socionext.com>
These were added to make the ARM64 branch self-contained because
updates for ARM and ARM64 are supposed to be sent as separate
pull requests.
Now, they were merged together in Linus' tree and interrupt-parent
from the arch/arm/boot/dts/uniphier-support-card.dtsi is visible from
ARM64 DT files by the cross-arch reference.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts | 1 -
arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts | 1 -
arch/arm64/boot/dts/socionext/uniphier-pxs3-ref.dts | 1 -
3 files changed, 3 deletions(-)
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts b/arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts
index dd7193a..6bdefb2 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts
@@ -40,7 +40,6 @@
};
ðsc {
- interrupt-parent = <&gpio>;
interrupts = <0 8>;
};
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts b/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
index d99e373..254d679 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
@@ -40,7 +40,6 @@
};
ðsc {
- interrupt-parent = <&gpio>;
interrupts = <0 8>;
};
diff --git a/arch/arm64/boot/dts/socionext/uniphier-pxs3-ref.dts b/arch/arm64/boot/dts/socionext/uniphier-pxs3-ref.dts
index 864feeb..5c5e9cb 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-pxs3-ref.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-pxs3-ref.dts
@@ -38,7 +38,6 @@
};
ðsc {
- interrupt-parent = <&gpio>;
interrupts = <0 8>;
};
--
2.7.4
^ permalink raw reply related
* [PATCH 1/4] ARM: dts: uniphier: use macros in dt-bindings header
From: Masahiro Yamada @ 2017-11-17 5:24 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, devicetree, linux-kernel, Russell King,
Masahiro Yamada, Rob Herring
The dt-bindings header was applied to the driver subsystem. I had to
wait for a merge window to use it from DT.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
arch/arm/boot/dts/uniphier-ld4-ref.dts | 2 +-
arch/arm/boot/dts/uniphier-ld4.dtsi | 2 ++
arch/arm/boot/dts/uniphier-ld6b-ref.dts | 2 +-
arch/arm/boot/dts/uniphier-pro4-ref.dts | 2 +-
arch/arm/boot/dts/uniphier-pro4.dtsi | 2 ++
arch/arm/boot/dts/uniphier-pxs2.dtsi | 1 +
arch/arm/boot/dts/uniphier-sld8-ref.dts | 2 +-
arch/arm/boot/dts/uniphier-sld8.dtsi | 2 ++
8 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/uniphier-ld4-ref.dts b/arch/arm/boot/dts/uniphier-ld4-ref.dts
index 0056852..a3afd0c 100644
--- a/arch/arm/boot/dts/uniphier-ld4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ld4-ref.dts
@@ -56,7 +56,7 @@
&gpio {
xirq1 {
gpio-hog;
- gpios = <121 0>;
+ gpios = <UNIPHIER_GPIO_IRQ(1) 0>;
input;
};
};
diff --git a/arch/arm/boot/dts/uniphier-ld4.dtsi b/arch/arm/boot/dts/uniphier-ld4.dtsi
index 01fc3e1..1b98778 100644
--- a/arch/arm/boot/dts/uniphier-ld4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ld4.dtsi
@@ -7,6 +7,8 @@
* SPDX-License-Identifier: (GPL-2.0+ OR MIT)
*/
+#include <dt-bindings/gpio/uniphier-gpio.h>
+
/ {
compatible = "socionext,uniphier-ld4";
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/uniphier-ld6b-ref.dts b/arch/arm/boot/dts/uniphier-ld6b-ref.dts
index 0e510a7..811b999 100644
--- a/arch/arm/boot/dts/uniphier-ld6b-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ld6b-ref.dts
@@ -58,7 +58,7 @@
&gpio {
xirq4 {
gpio-hog;
- gpios = <124 0>;
+ gpios = <UNIPHIER_GPIO_IRQ(4) 0>;
input;
};
};
diff --git a/arch/arm/boot/dts/uniphier-pro4-ref.dts b/arch/arm/boot/dts/uniphier-pro4-ref.dts
index be99467..6a004e5 100644
--- a/arch/arm/boot/dts/uniphier-pro4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-pro4-ref.dts
@@ -58,7 +58,7 @@
&gpio {
xirq2 {
gpio-hog;
- gpios = <122 0>;
+ gpios = <UNIPHIER_GPIO_IRQ(2) 0>;
input;
};
};
diff --git a/arch/arm/boot/dts/uniphier-pro4.dtsi b/arch/arm/boot/dts/uniphier-pro4.dtsi
index 7955c3a..b682a42 100644
--- a/arch/arm/boot/dts/uniphier-pro4.dtsi
+++ b/arch/arm/boot/dts/uniphier-pro4.dtsi
@@ -7,6 +7,8 @@
* SPDX-License-Identifier: (GPL-2.0+ OR MIT)
*/
+#include <dt-bindings/gpio/uniphier-gpio.h>
+
/ {
compatible = "socionext,uniphier-pro4";
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/uniphier-pxs2.dtsi b/arch/arm/boot/dts/uniphier-pxs2.dtsi
index d82d6d8..eafe4dd 100644
--- a/arch/arm/boot/dts/uniphier-pxs2.dtsi
+++ b/arch/arm/boot/dts/uniphier-pxs2.dtsi
@@ -7,6 +7,7 @@
* SPDX-License-Identifier: (GPL-2.0+ OR MIT)
*/
+#include <dt-bindings/gpio/uniphier-gpio.h>
#include <dt-bindings/thermal/thermal.h>
/ {
diff --git a/arch/arm/boot/dts/uniphier-sld8-ref.dts b/arch/arm/boot/dts/uniphier-sld8-ref.dts
index 1c0e707..e052ea3 100644
--- a/arch/arm/boot/dts/uniphier-sld8-ref.dts
+++ b/arch/arm/boot/dts/uniphier-sld8-ref.dts
@@ -56,7 +56,7 @@
&gpio {
xirq0 {
gpio-hog;
- gpios = <120 0>;
+ gpios = <UNIPHIER_GPIO_IRQ(0) 0>;
input;
};
};
diff --git a/arch/arm/boot/dts/uniphier-sld8.dtsi b/arch/arm/boot/dts/uniphier-sld8.dtsi
index 7188536..89c01cc 100644
--- a/arch/arm/boot/dts/uniphier-sld8.dtsi
+++ b/arch/arm/boot/dts/uniphier-sld8.dtsi
@@ -7,6 +7,8 @@
* SPDX-License-Identifier: (GPL-2.0+ OR MIT)
*/
+#include <dt-bindings/gpio/uniphier-gpio.h>
+
/ {
compatible = "socionext,uniphier-sld8";
#address-cells = <1>;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v7 04/13] slimbus: core: Add slim controllers support
From: Vinod Koul @ 2017-11-17 4:42 UTC (permalink / raw)
To: Srinivas Kandagatla, gregkh
Cc: broonie, alsa-devel, sdharia, bp, poeschel, treding,
andreas.noever, alan, mathieu.poirier, daniel, jkosina,
sharon.dvir1, joe, davem, james.hogan, michael.opdenacker,
robh+dt, pawel.moll, mark.rutland, devicetree, linux-kernel,
linux-arm-msm, arnd
In-Reply-To: <55794ca5-b70a-4866-1e80-bc0e78880c50@linaro.org>
On Thu, Nov 16, 2017 at 05:29:35PM +0000, Srinivas Kandagatla wrote:
> thanks for the comments.
>
>
> On 16/11/17 16:42, Vinod Koul wrote:
> >On Wed, Nov 15, 2017 at 02:10:34PM +0000, srinivas.kandagatla@linaro.org wrote:
> >
> >>+static void slim_dev_release(struct device *dev)
> >>+{
> >>+ struct slim_device *sbdev = to_slim_device(dev);
> >>+
> >>+ put_device(sbdev->ctrl->dev);
> >
> >which device would that be?
> This is controller device
>
> >
> >>+static int slim_add_device(struct slim_controller *ctrl,
> >>+ struct slim_device *sbdev,
> >>+ struct device_node *node)
> >>+{
> >>+ sbdev->dev.bus = &slimbus_bus;
> >>+ sbdev->dev.parent = ctrl->dev;
> >>+ sbdev->dev.release = slim_dev_release;
> >>+ sbdev->dev.driver = NULL;
> >>+ sbdev->ctrl = ctrl;
> >>+
> >>+ dev_set_name(&sbdev->dev, "%x:%x:%x:%x",
> >>+ sbdev->e_addr.manf_id,
> >>+ sbdev->e_addr.prod_code,
> >>+ sbdev->e_addr.dev_index,
> >>+ sbdev->e_addr.instance);
> >>+
> >>+ get_device(ctrl->dev);
> >
> >is this controller device and you ensuring it doesnt go away while you have
> >slaves on it?
>
> Yes.
I thought since you are marking ctrl->dev as parent, the device core should
ensure that parent doesn't go off when you have child device?
Greg, is that understanding correct, if so we may not need these calls.
--
~Vinod
^ permalink raw reply
* Re: [PATCH v7 02/13] dt-bindings: Add SLIMbus bindings
From: Vinod Koul @ 2017-11-17 3:55 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
broonie-DgEjT+Ai2ygdnm+yROfE0A, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
sdharia-sgV2jX0FEOL9JmXXK+q4OQ, bp-l3A5Bk7waGM,
poeschel-Xtl8qvBWbHwb1SvskN2V4Q, treding-DDmLM1+adcrQT0dZR+AlfA,
andreas.noever-Re5JQEeQqe8AvxtiuMwx3w,
alan-VuQAYsv1563Yd54FQh9/CA,
mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A, daniel-/w4YWyX8dFk,
jkosina-AlSwsSmVLrQ, sharon.dvir1-MQgwKvJRKlGYZoqfULhbRA,
joe-6d6DIl74uiNBDgjK7y7TUQ, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
james.hogan-1AXoQHu6uovQT0dZR+AlfA,
michael.opdenacker-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, pawel.moll-5wv7dgnIgG8,
mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4
In-Reply-To: <a32232fc-3995-60f6-878e-76aaed4c52d6-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Thu, Nov 16, 2017 at 01:40:13PM +0000, Srinivas Kandagatla wrote:
> Thanks for the review comments.
>
> On 16/11/17 13:09, Vinod Koul wrote:
> >On Wed, Nov 15, 2017 at 02:10:32PM +0000, srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org wrote:
> >>From: Sagar Dharia <sdharia-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> >
> >>+
> >>+Child nodes:
> >>+Every SLIMbus controller node can contain zero or more child nodes
> >>+representing slave devices on the bus. Every SLIMbus slave device is
> >>+uniquely determined by the enumeration address containing 4 fields:
> >>+Manufacturer ID, Product code, Device index, and Instance value for
> >>+the device.
> >>+If child node is not present and it is instantiated after device
> >>+discovery (slave device reporting itself present).
> >
> >So you allow the devices to work even if the respective firmware description
> >is absent?
> Yes, As SLIMbus itself itself is discoverable bus.
Okay, in SDW we mandate description be present in respective firmwares so we
dont have this path. In theory this never works for you as driver cant load
without device being created and without driver load device is not powered
up so can't report...
> >>+In some cases it may be necessary to describe non-probeable device
> >>+details such as non-standard ways of powering up a device. In
> >>+such cases, child nodes for those devices will be present as
> >>+slaves of the slimbus-controller, as detailed below.
> >>+
> >>+Required property for SLIMbus child node if it is present:
> >>+- reg - Should be ('Device index', 'Instance ID') from SLIMbus
> >>+ Enumeration Address.
> >>+ Device Index Uniquely identifies multiple Devices within
> >>+ a single Component.
> >>+ Instance ID Is for the cases where multiple Devices of the
> >>+ same type or Class are attached to the bus.
> >>+
> >>+- compatible -"slimMID,PID". The textual representation of Manufacturer ID,
> >>+ Product Code, shall be in lower case hexadecimal with leading
> >>+ zeroes suppressed
> >>+
>
> >>+ codec: wcd9310@1,0{
> >>+ compatible = "slim217,60";
> >>+ reg = <1 0>;
> >>+ };
> >>+ };
> >
> >Pardon my ignorance as I am not very familiar with DT nodes, but where are
> >the Manufacturer ID, Product code, Device index, and Instance values here?
>
> Manfacturer ID and Product code is part of compatible string
> Device index and Instance value are part of reg.
hmmm, wouldn't it be more helpful to have a field(s) for these which contain
these numbers rather than coded together in a word
compatible makes sense though
--
~Vinod
--
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: Decompiled vs *tmp extended device tree
From: Frank Rowand @ 2017-11-17 3:34 UTC (permalink / raw)
To: Rob Herring, Alan Martinovic; +Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171116165212.4caconxbvfrmbs4n@rob-hp-laptop>
On 11/16/17 11:52, Rob Herring wrote:
> On Thu, Nov 16, 2017 at 01:12:55PM +0100, Alan Martinovic wrote:
>> Hi,
>> I'm trying to modify a device tree to enable support of the second UART.
>> The actual device tree which is used for the example:
>>
>> https://github.com/getsenic/senic-os-linux/blob/senic/4.13/arch/arm/boot/dts/sun8i-h3-senic-hub.dts
>>
>> The device tree includes and overrides some additional files:
>>
>> #include "sun8i-h3.dtsi"
>> #include "sunxi-common-regulators.dtsi"
>> #include <dt-bindings/gpio/gpio.h>
>> #include <dt-bindings/input/input.h>
>> #include <dt-bindings/pinctrl/sun4i-a10.h>
>>
>> I would like to know to what does the extended device tree look like,
>> and use that as my base, because I don't really have the complete picture
>> by just looking at the sun8i-h3-senic-hub.dts
>>
>> In this example I'm interested in where are "uart0_pins_a" defined.
>> sun8i-h3-senic-hub.dts references them but has no definitions,
>> so I'm assuming the definition is somewhere in the included files.
>>
>> To help me out with this task I discovered the device tree decompiler.
>> Am expecting that the decompiled dts contains all the data that
>> end up in the dtb blob, and should, among other, contain all the information
>> available in sun8i-h3-senic-hub.dts.
>>
>> scripts/dtc/dtc -I dtb -O dts -o expanded-devtree.dts
>> arch/arm/boot/dts/sun8i-h3-senic-hub.dtb
>>
>> But the decompiled extended device tree also seems to have no
>> traces of "uart0_pins_a" at all :
>>
>> grep uart0_pins_a expanded-devtree.dts
>
> labels are purely a source level construct (though overlays changes
> that some) and are lost after compiling. You have to look for 'uart0@0'.
>
>>
>> I've also discovered the hidden .tmp files:
>>
>> ⟫ ls arch/arm/boot/dts/.sun8i-h3-*
>> arch/arm/boot/dts/.sun8i-h3-senic-hub.dtb.cmd
>> arch/arm/boot/dts/.sun8i-h3-senic-hub.dtb.d.dtc.tmp
>> arch/arm/boot/dts/.sun8i-h3-senic-hub.dtb.d.pre.tmp
>> arch/arm/boot/dts/.sun8i-h3-senic-hub.dtb.dts.tmp
>>
>> and in one of them there is a definition to "uart0_pins_a":
>>
>> ⟫ grep uart0_pins_a arch/arm/boot/dts/.sun8i-h3-*
>> arch/arm/boot/dts/.sun8i-h3-senic-hub.dtb.dts.tmp: uart0_pins_a: uart0@0 {
>> arch/arm/boot/dts/.sun8i-h3-senic-hub.dtb.dts.tmp: pinctrl-0 =
>> <&uart0_pins_a>;
>>
>> My question is, which one is a more accurate representation
>> of the final device tree that I should use as a basis?
>
> Compiling dts to dts is mainly useful to get rid of all the C
> preprocessor and includes to see what the final nodes look like. You do
> lose some things though.
Some explanation of this stuff is in the slides at:
https://elinux.org/Device_Tree_Reference#Debugging
Follow the link to the slides "Solving Device Tree Issues" (updated),
ELCE October 2015 by Frank Rowand.
Info on why some things in the original source end up in the final
device tree and some don't (note that the tool "dtdiff" in the slides
is now in mainline Linux, as scripts/dtc/dtx_diff):
slides
46 - 59
68 - 75
Info on how to read .sun8i-h3-senic-hub.dtb.dts.tmp to find out
where things in the final device tree came from:
slides
80 - 84
A more elegant solution that will provide file names and line numbers
for what dts or dtsi a node or property in the final device tree came
from:
slides
85 - 92
This feature has not yet gotten into dtc, so if you want to use it
you need to patch the dtc source yourself. Link to those patches
is at the same elinux.org page, "Supporting Resources (patches, etc)".
I am hopeful that someday I or someone else will finish implementing
this feature properly so that it can be accepted into dtc.
>
>> Why isn't it correct to expect that everything from sun8i-h3-senic-hub.dts
>> will end up in the final device tree blob?
>
> That's true for every compiler. After compiling, preprocessor symbols
> are gone, functions may be inlined, etc.
>
> 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
>
--
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 v7 2/3] arm: dts: add Nuvoton NPCM750 device tree
From: Brendan Higgins @ 2017-11-17 2:50 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, Russell King, Avi Fishman, Tomer Maimon,
Rick Altherr, Florian Fainelli,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
OpenBMC Maillist
In-Reply-To: <CAL_JsqJGe85FAOQwt=zJ5jOBoT-F1itnK6kmc9k34FJu=3Z=bg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Sorry for the delay. I thought all of the comments were straightforward, but
there are a couple which need some further discussion.
On Fri, Oct 20, 2017 at 12:45 PM, Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Thu, Oct 19, 2017 at 5:50 PM, Brendan Higgins
> <brendanhiggins-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
>> Add a common device tree for all Nuvoton NPCM750 BMCs and a board
>> specific device tree for the NPCM750 (Poleg) evaluation board.
>>
>> Signed-off-by: Brendan Higgins <brendanhiggins-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
>> Reviewed-by: Tomer Maimon <tmaimon77-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Reviewed-by: Avi Fishman <avifishman70-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Reviewed-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
>> Tested-by: Tomer Maimon <tmaimon77-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Tested-by: Avi Fishman <avifishman70-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> ---
>
> [...]
>
>> diff --git a/arch/arm/boot/dts/nuvoton-npcm750.dtsi b/arch/arm/boot/dts/nuvoton-npcm750.dtsi
>> new file mode 100644
>> index 000000000000..85506b3cdd39
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/nuvoton-npcm750.dtsi
>> @@ -0,0 +1,198 @@
>> +/*
>> + * DTSi file for the NPCM750 SoC
>> + *
>> + * Copyright 2012 Tomer Maimon <tomer.maimon-KrzQf0k3Iz9BDgjK7y7TUQ@public.gmane.org>
>> + *
>> + * The code contained herein is licensed under the GNU General Public
>> + * License. You may obtain a copy of the GNU General Public License
>> + * Version 2 or later at the following locations:
>> + *
>> + * http://www.opensource.org/licenses/gpl-license.html
>> + * http://www.gnu.org/copyleft/gpl.html
>> + */
>> +
>> +#include <dt-bindings/interrupt-controller/arm-gic.h>
>> +#include <dt-bindings/clock/nuvoton,npcm7xx-clks.h>
>> +
>> +/ {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + interrupt-parent = <&gic>;
>> +
>> + cpus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + enable-method = "nuvoton,npcm7xx-smp";
>> +
>> + cpu@0 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a9";
>> + clocks = <&clk NPCM7XX_CLK_CPU>;
>> + clock-names = "clk_cpu";
>> + reg = <0>;
>> + next-level-cache = <&l2>;
>> + };
>> +
>> + cpu@1 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a9";
>> + clocks = <&clk NPCM7XX_CLK_CPU>;
>> + clock-names = "clk_cpu";
>> + reg = <1>;
>> + next-level-cache = <&l2>;
>> + };
>> + };
>> +
>> +/* external clock signal rg1refck, supplied by the phy */
>> +clk-rg1refck {
>> + compatible = "fixed-clock";
>> + #clock-cells = <0>;
>> + clock-frequency = <125000000>;
>> +};
>> +
>> +/* external clock signal rg2refck, supplied by the phy */
>> +clk-rg2refck {
>> + compatible = "fixed-clock";
>> + #clock-cells = <0>;
>> + clock-frequency = <125000000>;
>> +};
>> +
>> +clk-xin {
>> + compatible = "fixed-clock";
>> + #clock-cells = <0>;
>> + clock-frequency = <50000000>;
>> +};
>> +
>> + soc {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + compatible = "simple-bus";
>> + interrupt-parent = <&gic>;
>> + ranges = <0x0 0xf0000000 0x00900000>;
>> +
>> + gcr: gcr@f0800000 {
>
> Should be gcr@800000. Build the dtb with W=1 and it will give you
> warnings for this.
>
>> + compatible = "nuvoton,npcm750-gcr", "syscon",
>> + "simple-mfd";
>> + reg = <0x800000 0x1000>;
>> + };
>> +
>> + scu: scu@f03fe000 {
>> + compatible = "arm,cortex-a9-scu";
>> + reg = <0x3fe000 0x1000>;
>> + };
>> +
>> + l2: cache-controller@f03fc000 {
>> + compatible = "arm,pl310-cache";
>> + reg = <0x3fc000 0x1000>;
>> + interrupts = <0 21 4>;
>> + cache-unified;
>> + cache-level = <2>;
>> + clocks = <&clk NPCM7XX_CLK_AXI>;
>> + };
>> +
>> + gic: interrupt-controller@f03ff000 {
>> + compatible = "arm,cortex-a9-gic";
>> + interrupt-controller;
>> + #interrupt-cells = <3>;
>> + reg = <0x3ff000 0x1000>,
>> + <0x3fe100 0x100>;
>> + };
>> +
>> + timer@f03fe600 {
>> + compatible = "arm,cortex-a9-twd-timer";
>> + reg = <0x3fe600 0x20>;
>> + interrupts = <1 13 0x304>;
>> + clocks = <&clk NPCM7XX_CLK_TIMER>;
>> + };
>> + };
>> +
>> + ahb {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + compatible = "simple-bus";
>> + interrupt-parent = <&gic>;
>> + ranges = <0x80000000 0x80000000 0x40010000
>> + 0xe0800000 0xe0800000 0x0f800000
>> + 0x00000000 0xf0000000 0x00900000
>> + 0xf8000000 0xf8000000 0x02000000
>> + 0xfb000000 0xfb000000 0x00002000>;
>
> Just do "ranges;" here if all the translation is at the next level down.
Actually we do have some peripherals that sit directly on the AHB, they
just have not had their DTS nodes written yet. I counted at least 6
devices which probably won't get a sub-memory space.
>
> Sorry, it's hard to say exactly what to do without knowing the whole memory map.
No problem. Let me see if I can get it for you.
>
>> +
>> + clk: clock-controller@f0801000 {
>
> Seems like this belongs under /soc based on the address.
No, the AHB memory space is discontiguous. The "Cortex A9 Included" space
(/soc here) sits in one of the discontinuities.
>
>> + compatible = "nuvoton,npcm750-clk";
>> + #clock-cells = <1>;
>> + reg = <0x801000 0x1000>;
>> + status = "okay";
>> + };
>> +
>> + apb {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + compatible = "simple-bus";
>> + interrupt-parent = <&gic>;
>> + ranges = <0x0 0x0 0x00300000>;
>
> And then this would be "<0x0 0xf0000000 0x300000>".
>
>> +
>> + timer0: timer@f0000000 {
>> + compatible = "nuvoton,npcm750-timer";
>> + interrupts = <0 32 4>;
>> + reg = <0x0 0x1000>;
>> + clocks = <&clk NPCM7XX_CLK_TIMER>;
>> + };
>> +
>> + watchdog0: watchdog@f0008000 {
>> + compatible = "nuvoton,npcm750-wdt";
>> + interrupts = <0 47 4>;
>> + reg = <0x8000 0x1000>;
>> + status = "disabled";
>> + clocks = <&clk NPCM7XX_CLK_TIMER>;
>> + };
>> +
>> + watchdog1: watchdog@f0009000 {
>> + compatible = "nuvoton,npcm750-wdt";
>> + interrupts = <0 48 4>;
>> + reg = <0x9000 0x1000>;
>> + status = "disabled";
>> + clocks = <&clk NPCM7XX_CLK_TIMER>;
>> + };
>> +
>> + watchdog2: watchdog@f000a000 {
>> + compatible = "nuvoton,npcm750-wdt";
>> + interrupts = <0 49 4>;
>> + reg = <0xa000 0x1000>;
>> + status = "disabled";
>> + clocks = <&clk NPCM7XX_CLK_TIMER>;
>> + };
>> +
>> + serial0: serial@f0001000 {
>> + compatible = "nuvoton,npcm750-uart";
>> + reg = <0x1000 0x1000>;
>> + clocks = <&clk NPCM7XX_CLK_UART_CORE>;
>> + interrupts = <0 2 4>;
>> + status = "disabled";
>> + };
>> +
>> + serial1: serial@f0002000 {
>> + compatible = "nuvoton,npcm750-uart";
>> + reg = <0x2000 0x1000>;
>> + clocks = <&clk NPCM7XX_CLK_UART_CORE>;
>> + interrupts = <0 3 4>;
>> + status = "disabled";
>> + };
>> +
>> + serial2: serial@f0003000 {
>> + compatible = "nuvoton,npcm750-uart";
>> + reg = <0x3000 0x1000>;
>> + clocks = <&clk NPCM7XX_CLK_UART_CORE>;
>> + interrupts = <0 4 4>;
>> + status = "disabled";
>> + };
>> +
>> + serial3: serial@f0004000 {
>> + compatible = "nuvoton,npcm750-uart";
>> + reg = <0x4000 0x1000>;
>> + clocks = <&clk NPCM7XX_CLK_UART_CORE>;
>> + interrupts = <0 5 4>;
>> + status = "disabled";
>> + };
>> + };
>> + };
>> +};
>> diff --git a/include/dt-bindings/clock/nuvoton,npcm7xx-clks.h b/include/dt-bindings/clock/nuvoton,npcm7xx-clks.h
>> new file mode 100644
>> index 000000000000..c69d3bbf7e42
>> --- /dev/null
>> +++ b/include/dt-bindings/clock/nuvoton,npcm7xx-clks.h
>> @@ -0,0 +1,39 @@
>> +/*
>> + * Copyright (C) 2016 Nuvoton Technologies, tali.perry-KrzQf0k3Iz9BDgjK7y7TUQ@public.gmane.org
>> + *
>> + * This software is licensed under the terms of the GNU General Public
>> + * License version 2, as published by the Free Software Foundation, and
>> + * may be copied, distributed, and modified under those terms.
>> + */
>> +
>> +#ifndef _DT_BINDINGS_CLK_NPCM7XX_H
>> +#define _DT_BINDINGS_CLK_NPCM7XX_H
>> +
>> +#define NPCM7XX_CLK_PLL0 0
>> +#define NPCM7XX_CLK_PLL1 1
>> +#define NPCM7XX_CLK_PLL2 2
>> +#define NPCM7XX_CLK_GFX 3
>> +#define NPCM7XX_CLK_APB1 4
>> +#define NPCM7XX_CLK_APB2 5
>> +#define NPCM7XX_CLK_APB3 6
>> +#define NPCM7XX_CLK_APB4 7
>> +#define NPCM7XX_CLK_APB5 8
>> +#define NPCM7XX_CLK_MC 9
>> +#define NPCM7XX_CLK_CPU 10
>> +#define NPCM7XX_CLK_SPI0 11
>> +#define NPCM7XX_CLK_SPI3 12
>> +#define NPCM7XX_CLK_SPIX 13
>> +#define NPCM7XX_CLK_UART_CORE 14
>> +#define NPCM7XX_CLK_TIMER 15
>> +#define NPCM7XX_CLK_HOST_UART 16
>> +#define NPCM7XX_CLK_MMC 17
>> +#define NPCM7XX_CLK_SDHC 18
>> +#define NPCM7XX_CLK_ADC 19
>> +#define NPCM7XX_CLK_GFX_MEM 20
>> +#define NPCM7XX_CLK_USB_BRIDGE 21
>> +#define NPCM7XX_CLK_AXI 22
>> +#define NPCM7XX_CLK_AHB 23
>> +#define NPCM7XX_CLK_EMC 24
>> +#define NPCM7XX_CLK_GMAC 25
>> +
>> +#endif
>> --
>> 2.15.0.rc0.271.g36b669edcc-goog
>>
--
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] of: Document exactly what of_find_node_by_name() puts
From: Stephen Boyd @ 2017-11-17 2:44 UTC (permalink / raw)
To: Randy Dunlap
Cc: Rob Herring, Frank Rowand, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <0ef4b415-801c-cb58-5de1-01bcfba1c778-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
On 11/10, Randy Dunlap wrote:
> On 11/10/2017 05:45 PM, Stephen Boyd wrote:
> > It isn't clear if this function of_node_put()s the 'from'
> > argument, or the node it finds in the search. Clearly indicate
> > which variable is touched.
> >
> > Signed-off-by: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> > ---
> > drivers/of/base.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/of/base.c b/drivers/of/base.c
> > index 63897531cd75..602c5d65734a 100644
> > --- a/drivers/of/base.c
> > +++ b/drivers/of/base.c
> > @@ -866,7 +866,7 @@ EXPORT_SYMBOL(of_find_node_opts_by_path);> * @from: The node to start searching from or NULL, the node
>
> * @from: The node to start searching from or %NULL; the node
>
> > * you pass will not be searched, only the next one
> > * will; typically, you pass what the previous call
>
> * will. Typically, you pass what the previous call
>
Rob, do you want me to fold this in?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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] MIPS: BMIPS: Add Broadcom STB watchdog nodes
From: Jaedon Shin @ 2017-11-17 2:19 UTC (permalink / raw)
To: Ralf Baechle, James Hogan, Florian Fainelli, Rob Herring
Cc: Kevin Cernekee, Mark Rutland, linux-mips-6z/3iImG2C8G8FEW9MqTrA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Jaedon Shin
In-Reply-To: <20171117021944.894-1-jaedon.shin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Adds watchdog device nodes to BCM7xxx MIPS based SoCs.
Signed-off-by: Jaedon Shin <jaedon.shin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/mips/boot/dts/brcm/bcm7125.dtsi | 7 +++++++
arch/mips/boot/dts/brcm/bcm7346.dtsi | 7 +++++++
arch/mips/boot/dts/brcm/bcm7358.dtsi | 7 +++++++
arch/mips/boot/dts/brcm/bcm7360.dtsi | 7 +++++++
arch/mips/boot/dts/brcm/bcm7362.dtsi | 7 +++++++
arch/mips/boot/dts/brcm/bcm7420.dtsi | 7 +++++++
arch/mips/boot/dts/brcm/bcm7425.dtsi | 7 +++++++
arch/mips/boot/dts/brcm/bcm7435.dtsi | 7 +++++++
arch/mips/boot/dts/brcm/bcm97125cbmb.dts | 4 ++++
arch/mips/boot/dts/brcm/bcm97346dbsmb.dts | 4 ++++
arch/mips/boot/dts/brcm/bcm97358svmb.dts | 4 ++++
arch/mips/boot/dts/brcm/bcm97360svmb.dts | 4 ++++
arch/mips/boot/dts/brcm/bcm97362svmb.dts | 4 ++++
arch/mips/boot/dts/brcm/bcm97420c.dts | 4 ++++
arch/mips/boot/dts/brcm/bcm97425svmb.dts | 4 ++++
arch/mips/boot/dts/brcm/bcm97435svmb.dts | 4 ++++
16 files changed, 88 insertions(+)
diff --git a/arch/mips/boot/dts/brcm/bcm7125.dtsi b/arch/mips/boot/dts/brcm/bcm7125.dtsi
index 2f9ef565e5d0..5bf77b6fcceb 100644
--- a/arch/mips/boot/dts/brcm/bcm7125.dtsi
+++ b/arch/mips/boot/dts/brcm/bcm7125.dtsi
@@ -198,6 +198,13 @@
status = "disabled";
};
+ watchdog: watchdog@4067e8 {
+ clocks = <&upg_clk>;
+ compatible = "brcm,bcm7038-wdt";
+ reg = <0x4067e8 0x14>;
+ status = "disabled";
+ };
+
upg_gio: gpio@406700 {
compatible = "brcm,brcmstb-gpio";
reg = <0x406700 0x80>;
diff --git a/arch/mips/boot/dts/brcm/bcm7346.dtsi b/arch/mips/boot/dts/brcm/bcm7346.dtsi
index 228184dedada..2afa0dada575 100644
--- a/arch/mips/boot/dts/brcm/bcm7346.dtsi
+++ b/arch/mips/boot/dts/brcm/bcm7346.dtsi
@@ -233,6 +233,13 @@
status = "disabled";
};
+ watchdog: watchdog@4067e8 {
+ clocks = <&upg_clk>;
+ compatible = "brcm,bcm7038-wdt";
+ reg = <0x4067e8 0x14>;
+ status = "disabled";
+ };
+
aon_pm_l2_intc: interrupt-controller@408440 {
compatible = "brcm,l2-intc";
reg = <0x408440 0x30>;
diff --git a/arch/mips/boot/dts/brcm/bcm7358.dtsi b/arch/mips/boot/dts/brcm/bcm7358.dtsi
index 398521c7070f..6375fc77f389 100644
--- a/arch/mips/boot/dts/brcm/bcm7358.dtsi
+++ b/arch/mips/boot/dts/brcm/bcm7358.dtsi
@@ -217,6 +217,13 @@
status = "disabled";
};
+ watchdog: watchdog@4066a8 {
+ clocks = <&upg_clk>;
+ compatible = "brcm,bcm7038-wdt";
+ reg = <0x4066a8 0x14>;
+ status = "disabled";
+ };
+
aon_pm_l2_intc: interrupt-controller@408240 {
compatible = "brcm,l2-intc";
reg = <0x408240 0x30>;
diff --git a/arch/mips/boot/dts/brcm/bcm7360.dtsi b/arch/mips/boot/dts/brcm/bcm7360.dtsi
index 28f5a0c1c149..a57cacea91cf 100644
--- a/arch/mips/boot/dts/brcm/bcm7360.dtsi
+++ b/arch/mips/boot/dts/brcm/bcm7360.dtsi
@@ -209,6 +209,13 @@
status = "disabled";
};
+ watchdog: watchdog@4066a8 {
+ clocks = <&upg_clk>;
+ compatible = "brcm,bcm7038-wdt";
+ reg = <0x4066a8 0x14>;
+ status = "disabled";
+ };
+
aon_pm_l2_intc: interrupt-controller@408440 {
compatible = "brcm,l2-intc";
reg = <0x408440 0x30>;
diff --git a/arch/mips/boot/dts/brcm/bcm7362.dtsi b/arch/mips/boot/dts/brcm/bcm7362.dtsi
index ab2dd57571a0..728b9e9f84b8 100644
--- a/arch/mips/boot/dts/brcm/bcm7362.dtsi
+++ b/arch/mips/boot/dts/brcm/bcm7362.dtsi
@@ -205,6 +205,13 @@
status = "disabled";
};
+ watchdog: watchdog@4066a8 {
+ clocks = <&upg_clk>;
+ compatible = "brcm,bcm7038-wdt";
+ reg = <0x4066a8 0x14>;
+ status = "disabled";
+ };
+
aon_pm_l2_intc: interrupt-controller@408440 {
compatible = "brcm,l2-intc";
reg = <0x408440 0x30>;
diff --git a/arch/mips/boot/dts/brcm/bcm7420.dtsi b/arch/mips/boot/dts/brcm/bcm7420.dtsi
index d262e11bc3f9..9540c27f12e7 100644
--- a/arch/mips/boot/dts/brcm/bcm7420.dtsi
+++ b/arch/mips/boot/dts/brcm/bcm7420.dtsi
@@ -214,6 +214,13 @@
status = "disabled";
};
+ watchdog: watchdog@4067e8 {
+ clocks = <&upg_clk>;
+ compatible = "brcm,bcm7038-wdt";
+ reg = <0x4067e8 0x14>;
+ status = "disabled";
+ };
+
upg_gio: gpio@406700 {
compatible = "brcm,brcmstb-gpio";
reg = <0x406700 0x80>;
diff --git a/arch/mips/boot/dts/brcm/bcm7425.dtsi b/arch/mips/boot/dts/brcm/bcm7425.dtsi
index 23479f988aa5..410e61ebaf9e 100644
--- a/arch/mips/boot/dts/brcm/bcm7425.dtsi
+++ b/arch/mips/boot/dts/brcm/bcm7425.dtsi
@@ -232,6 +232,13 @@
status = "disabled";
};
+ watchdog: watchdog@4067e8 {
+ clocks = <&upg_clk>;
+ compatible = "brcm,bcm7038-wdt";
+ reg = <0x4067e8 0x14>;
+ status = "disabled";
+ };
+
aon_pm_l2_intc: interrupt-controller@408440 {
compatible = "brcm,l2-intc";
reg = <0x408440 0x30>;
diff --git a/arch/mips/boot/dts/brcm/bcm7435.dtsi b/arch/mips/boot/dts/brcm/bcm7435.dtsi
index af75b0123c06..8398b7f68bf4 100644
--- a/arch/mips/boot/dts/brcm/bcm7435.dtsi
+++ b/arch/mips/boot/dts/brcm/bcm7435.dtsi
@@ -247,6 +247,13 @@
status = "disabled";
};
+ watchdog: watchdog@4067e8 {
+ clocks = <&upg_clk>;
+ compatible = "brcm,bcm7038-wdt";
+ reg = <0x4067e8 0x14>;
+ status = "disabled";
+ };
+
aon_pm_l2_intc: interrupt-controller@408440 {
compatible = "brcm,l2-intc";
reg = <0x408440 0x30>;
diff --git a/arch/mips/boot/dts/brcm/bcm97125cbmb.dts b/arch/mips/boot/dts/brcm/bcm97125cbmb.dts
index 7f59ea2ded6c..79e9769f7e00 100644
--- a/arch/mips/boot/dts/brcm/bcm97125cbmb.dts
+++ b/arch/mips/boot/dts/brcm/bcm97125cbmb.dts
@@ -50,6 +50,10 @@
status = "okay";
};
+&watchdog {
+ status = "okay";
+};
+
/* FIXME: USB is wonky; disable it for now */
&ehci0 {
status = "disabled";
diff --git a/arch/mips/boot/dts/brcm/bcm97346dbsmb.dts b/arch/mips/boot/dts/brcm/bcm97346dbsmb.dts
index b50dbb3cbeee..28370ff77eeb 100644
--- a/arch/mips/boot/dts/brcm/bcm97346dbsmb.dts
+++ b/arch/mips/boot/dts/brcm/bcm97346dbsmb.dts
@@ -59,6 +59,10 @@
status = "okay";
};
+&watchdog {
+ status = "okay";
+};
+
&enet0 {
status = "okay";
};
diff --git a/arch/mips/boot/dts/brcm/bcm97358svmb.dts b/arch/mips/boot/dts/brcm/bcm97358svmb.dts
index 2986ce353e57..41c1b510c230 100644
--- a/arch/mips/boot/dts/brcm/bcm97358svmb.dts
+++ b/arch/mips/boot/dts/brcm/bcm97358svmb.dts
@@ -55,6 +55,10 @@
status = "okay";
};
+&watchdog {
+ status = "okay";
+};
+
&enet0 {
status = "okay";
};
diff --git a/arch/mips/boot/dts/brcm/bcm97360svmb.dts b/arch/mips/boot/dts/brcm/bcm97360svmb.dts
index 8d48ae317b8c..9f6c6c9b7ea7 100644
--- a/arch/mips/boot/dts/brcm/bcm97360svmb.dts
+++ b/arch/mips/boot/dts/brcm/bcm97360svmb.dts
@@ -50,6 +50,10 @@
status = "okay";
};
+&watchdog {
+ status = "okay";
+};
+
&enet0 {
status = "okay";
};
diff --git a/arch/mips/boot/dts/brcm/bcm97362svmb.dts b/arch/mips/boot/dts/brcm/bcm97362svmb.dts
index 4a1d0631e9e6..df8b755c390f 100644
--- a/arch/mips/boot/dts/brcm/bcm97362svmb.dts
+++ b/arch/mips/boot/dts/brcm/bcm97362svmb.dts
@@ -47,6 +47,10 @@
status = "okay";
};
+&watchdog {
+ status = "okay";
+};
+
&enet0 {
status = "okay";
};
diff --git a/arch/mips/boot/dts/brcm/bcm97420c.dts b/arch/mips/boot/dts/brcm/bcm97420c.dts
index f96241e94874..086faeaa384a 100644
--- a/arch/mips/boot/dts/brcm/bcm97420c.dts
+++ b/arch/mips/boot/dts/brcm/bcm97420c.dts
@@ -60,6 +60,10 @@
status = "okay";
};
+&watchdog {
+ status = "okay";
+};
+
/* FIXME: MAC driver comes up but cannot attach to PHY */
&enet0 {
status = "disabled";
diff --git a/arch/mips/boot/dts/brcm/bcm97425svmb.dts b/arch/mips/boot/dts/brcm/bcm97425svmb.dts
index 488e12a9e4aa..0ed22217bf3a 100644
--- a/arch/mips/boot/dts/brcm/bcm97425svmb.dts
+++ b/arch/mips/boot/dts/brcm/bcm97425svmb.dts
@@ -61,6 +61,10 @@
status = "okay";
};
+&watchdog {
+ status = "okay";
+};
+
&enet0 {
status = "okay";
};
diff --git a/arch/mips/boot/dts/brcm/bcm97435svmb.dts b/arch/mips/boot/dts/brcm/bcm97435svmb.dts
index e14337cc51fd..2c145a883aef 100644
--- a/arch/mips/boot/dts/brcm/bcm97435svmb.dts
+++ b/arch/mips/boot/dts/brcm/bcm97435svmb.dts
@@ -61,6 +61,10 @@
status = "okay";
};
+&watchdog {
+ status = "okay";
+};
+
&enet0 {
status = "okay";
};
--
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
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