* [PATCH 02/20] coresight: of: Fix refcounting for graph nodes
From: Suzuki K Poulose @ 2018-06-05 21:43 UTC (permalink / raw)
To: linux-arm-kernel
Cc: mark.rutland, robh, mathieu.poirier, devicetree, coresight,
Suzuki K Poulose, john.horley, linux-kernel, arm, sudeep.holla,
matt.sealey, mike.leach, frowand.list, charles.garcia-tobin
In-Reply-To: <1528235011-30691-1-git-send-email-suzuki.poulose@arm.com>
The coresight driver doesn't drop the references on the
remote endpoint/port nodes. Add the missing of_node_put()
calls. To make it easier to handle different corner cases
cleanly, move the parsing of an endpoint to separate
function.
Reported-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
drivers/hwtracing/coresight/of_coresight.c | 139 +++++++++++++++++------------
1 file changed, 84 insertions(+), 55 deletions(-)
diff --git a/drivers/hwtracing/coresight/of_coresight.c b/drivers/hwtracing/coresight/of_coresight.c
index a33a92e..8a23c63 100644
--- a/drivers/hwtracing/coresight/of_coresight.c
+++ b/drivers/hwtracing/coresight/of_coresight.c
@@ -111,17 +111,80 @@ int of_coresight_get_cpu(const struct device_node *node)
}
EXPORT_SYMBOL_GPL(of_coresight_get_cpu);
+/*
+ * of_coresight_parse_endpoint : Parse the given output endpoint @ep
+ * and fill the connection information in @pdata[*@i].
+ *
+ * Parses the local port, remote device name and the remote port. Also
+ * updates *@i to point to the next index, when an entry is added.
+ *
+ * Returns :
+ * 0 - If the parsing completed without any fatal errors.
+ * -Errno - Fatal error, abort the scanning.
+ */
+static int of_coresight_parse_endpoint(struct device_node *ep,
+ struct coresight_platform_data *pdata,
+ int *i)
+{
+ int ret = 0;
+ struct of_endpoint endpoint, rendpoint;
+ struct device_node *rparent = NULL;
+ struct device_node *rport = NULL;
+ struct device *rdev = NULL;
+
+ do {
+ /*
+ * No need to deal with input ports, processing for as
+ * processing for output ports will deal with them.
+ */
+ if (of_find_property(ep, "slave-mode", NULL))
+ break;
+
+ /* Parse the local port details */
+ if (of_graph_parse_endpoint(ep, &endpoint))
+ break;
+ /*
+ * Get a handle on the remote port and parent
+ * attached to it.
+ */
+ rparent = of_graph_get_remote_port_parent(ep);
+ if (!rparent)
+ break;
+ rport = of_graph_get_remote_port(ep);
+ if (!rport)
+ break;
+ if (of_graph_parse_endpoint(rport, &rendpoint))
+ break;
+
+ /* If the remote device is not available, defer probing */
+ rdev = of_coresight_get_endpoint_device(rparent);
+ if (!rdev) {
+ ret = -EPROBE_DEFER;
+ break;
+ }
+
+ pdata->outports[*i] = endpoint.port;
+ pdata->child_names[*i] = dev_name(rdev);
+ pdata->child_ports[*i] = rendpoint.id;
+ /* Move the index */
+ (*i)++;
+ } while (0);
+
+ if (rparent)
+ of_node_put(rparent);
+ if (rport)
+ of_node_put(rport);
+
+ return ret;
+}
+
struct coresight_platform_data *
of_get_coresight_platform_data(struct device *dev,
const struct device_node *node)
{
int i = 0, ret = 0;
struct coresight_platform_data *pdata;
- struct of_endpoint endpoint, rendpoint;
- struct device *rdev;
struct device_node *ep = NULL;
- struct device_node *rparent = NULL;
- struct device_node *rport = NULL;
pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata)
@@ -129,63 +192,29 @@ of_get_coresight_platform_data(struct device *dev,
/* Use device name as sysfs handle */
pdata->name = dev_name(dev);
+ pdata->cpu = of_coresight_get_cpu(node);
/* Get the number of input and output port for this component */
of_coresight_get_ports(node, &pdata->nr_inport, &pdata->nr_outport);
- if (pdata->nr_outport) {
- ret = of_coresight_alloc_memory(dev, pdata);
+ /* If there are not output connections, we are done */
+ if (!pdata->nr_outport)
+ return pdata;
+
+ ret = of_coresight_alloc_memory(dev, pdata);
+ if (ret)
+ return ERR_PTR(ret);
+
+ /* Iterate through each port to discover topology */
+ do {
+ /* Get a handle on a port */
+ ep = of_graph_get_next_endpoint(node, ep);
+ if (!ep)
+ break;
+ ret = of_coresight_parse_endpoint(ep, pdata, &i);
if (ret)
return ERR_PTR(ret);
-
- /* Iterate through each port to discover topology */
- do {
- /* Get a handle on a port */
- ep = of_graph_get_next_endpoint(node, ep);
- if (!ep)
- break;
-
- /*
- * No need to deal with input ports, processing for as
- * processing for output ports will deal with them.
- */
- if (of_find_property(ep, "slave-mode", NULL))
- continue;
-
- /* Get a handle on the local endpoint */
- ret = of_graph_parse_endpoint(ep, &endpoint);
-
- if (ret)
- continue;
-
- /* The local out port number */
- pdata->outports[i] = endpoint.port;
-
- /*
- * Get a handle on the remote port and parent
- * attached to it.
- */
- rparent = of_graph_get_remote_port_parent(ep);
- rport = of_graph_get_remote_port(ep);
-
- if (!rparent || !rport)
- continue;
-
- if (of_graph_parse_endpoint(rport, &rendpoint))
- continue;
-
- rdev = of_coresight_get_endpoint_device(rparent);
- if (!rdev)
- return ERR_PTR(-EPROBE_DEFER);
-
- pdata->child_names[i] = dev_name(rdev);
- pdata->child_ports[i] = rendpoint.id;
-
- i++;
- } while (ep);
- }
-
- pdata->cpu = of_coresight_get_cpu(node);
+ } while (ep);
return pdata;
}
--
2.7.4
^ permalink raw reply related
* [PATCH 01/20] coresight: Fix memory leak in coresight_register
From: Suzuki K Poulose @ 2018-06-05 21:43 UTC (permalink / raw)
To: linux-arm-kernel
Cc: mathieu.poirier, robh, frowand.list, mark.rutland, sudeep.holla,
arm, linux-kernel, matt.sealey, john.horley, charles.garcia-tobin,
coresight, devicetree, mike.leach, Suzuki K Poulose, Arvind Yadav
In-Reply-To: <1528235011-30691-1-git-send-email-suzuki.poulose@arm.com>
commit 6403587a930c ("coresight: use put_device() instead of kfree()")
introduced a memory leak where, if we fail to register the device
for coresight_device, we don't free the "coresight_device" object,
which was allocated via kzalloc(). Fix this by jumping to the
appropriate error path.
Fixes: commit 6403587a930c ("coresight: use put_device() instead of kfree()")
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
drivers/hwtracing/coresight/coresight.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
index 4969b32..2893cfe 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -1020,7 +1020,7 @@ struct coresight_device *coresight_register(struct coresight_desc *desc)
ret = device_register(&csdev->dev);
if (ret) {
put_device(&csdev->dev);
- goto err_kzalloc_csdev;
+ goto err_kzalloc_refcnts;
}
mutex_lock(&coresight_mutex);
--
2.7.4
^ permalink raw reply related
* [PATCH 00/20] coresight: Update device tree bindings
From: Suzuki K Poulose @ 2018-06-05 21:43 UTC (permalink / raw)
To: linux-arm-kernel
Cc: mathieu.poirier, robh, frowand.list, mark.rutland, sudeep.holla,
arm, linux-kernel, matt.sealey, john.horley, charles.garcia-tobin,
coresight, devicetree, mike.leach, Suzuki K Poulose
Coresight uses DT graph bindings to describe the connections of the
components. However we have some undocumented usage of the bindings
to describe some of the properties of the connections.
The coresight driver needs to know the hardware ports invovled
in the connection and the direction of data flow to effectively
manage the trace sessions. So far we have relied on the "port"
address (as described by the generic graph bindings) to represent
the hardware port of the component for a connection.
The hardware uses separate numbering scheme for input and output
ports, which implies, we could have two different (input and output)
ports with the same port number. This could create problems in the
graph bindings where the label of the port wouldn't match the address.
e.g, with the existing bindings we get :
port@0{ // Output port 0
reg = <0>;
...
};
port@1{
reg = <0>; // Input port 0
endpoint {
slave-mode;
...
};
};
With the new enforcement in the DT rules, mismatches in label and address
are not allowed (as see in the case for port@1). So, we need a new mechanism
to describe the hardware port number reliably.
Also, we relied on an undocumented "slave-mode" property (see the above
example) to indicate if the port is an input port. Let us formalise and
switch to a new property to describe the direction of data flow.
There were three options considered for the hardware port number scheme:
1) Use natural ordering in the DT to infer the hardware port number.
i.e, Mandate that the all ports are listed in the DT and in the ascending
order for each class (input and output respectively).
Pros :
- We don't need new properties and if the existing DTS list them in
order (which most of them do), they work out of the box.
Cons :
- We must list all the ports even if the system cannot/shouldn't use
it.
- It is prone to human errors (if the order is not kept).
2) Use an explicit property to list both the direction and the hw port
number and direction. Define "coresight,hwid" as 2 member array of u32,
where the members are port number and the direction respectively.
e.g
port@0{
reg = <0>;
endpoint {
coresight,hwid = <0 1>; // Port # 0, Output
}
};
port@1{
reg = <1>;
endpoint {
coresight,hwid = <0 0>; // Port # 0, Input
};
};
Pros:
- The bindings are formal but not so reader friendly and could potentially
lead to human errors.
Cons:
- Backward compatiblity is lost.
3) Use explicit properties (implemented in the series) for the hardware
port id and direction. We define a new property "coresight,hwid" for
each endpoint in coresight devices to specify the hardware port number
explicitly. Also use a separate property "direction" to specify the
direction of the data flow.
e.g,
port@0{
reg = <0>;
endpoint {
direction = <1>; // Output
coresight,hwid = <0>; // Port # 0
}
};
port@1{
reg = <1>;
endpoint {
direction = <0>; // Input
coresight,hwid = <0>; // Port # 0
};
};
Pros:
- The bindings are formal and reader friendly, and less prone to errors.
Cons:
- Backward compatibility is lost.
This series implements Option (3) listed above and falls back to the old
bindings if the new bindings are not available. This allows the systems
with old bindings work with the new driver. The driver now issues a warning
(once) when it encounters the old bindings.
It also cleans up the platform parsing code to reduce the memory usage by
reusing the platform description.
I am not sure what is the best route to push these DTS changes. Thoughts ?
Changes since RFC [0] :
- Fixed style issues
- Fix an existing memory leak coresight_register (Found in code update)
- Fix missing of_node_put() in the existing driver (Reported-by Mathieu)
- Update the existing dts in kernel tree.
- Rename new helper functions for consistency
Suzuki K Poulose (20):
coresight: Fix memory leak in coresight_register
coresight: of: Fix refcounting for graph nodes
coresight: Fix remote endpoint parsing
coresight: Cleanup platform description data
coresight: platform: Cleanup coresight connection handling
coresight: Handle errors in finding input/output ports
coresight: dts: Document usage of graph bindings
coresight: dts: Cleanup device tree graph bindings
coresight: dts: Define new bindings for direction of data flow
dts: juno: Update coresight bindings for hw port
dts: hisilicon: Update coresight bindings for hw ports
dts: spreadtrum: Update coresight bindings for hw ports
dts: qcom: Update coresight bindings for hw ports
dts: arm: hisilicon: Update coresight bindings for hardware port
dts: arm: imx7{d,s}: Update coresight binding for hardware ports
dts: arm: omap: Update coresight bindings for hardware ports
dts: arm: qcom: Update coresight bindings for hardware ports
dts: sama5d2: Update coresight bindings for hardware ports
dts: ste-dbx5x0: Update coresight bindings for hardware port
dts: tc2: Update coresight bindings for hardware ports
.../devicetree/bindings/arm/coresight.txt | 76 +++++--
arch/arm/boot/dts/hip04.dtsi | 195 +++++++++++++-----
arch/arm/boot/dts/imx7d.dtsi | 5 +-
arch/arm/boot/dts/imx7s.dtsi | 41 ++--
arch/arm/boot/dts/omap3-beagle-xm.dts | 5 +-
arch/arm/boot/dts/omap3-beagle.dts | 5 +-
arch/arm/boot/dts/qcom-apq8064.dtsi | 37 +++-
arch/arm/boot/dts/qcom-msm8974.dtsi | 60 ++++--
arch/arm/boot/dts/sama5d2.dtsi | 5 +-
arch/arm/boot/dts/ste-dbx5x0.dtsi | 31 ++-
arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 48 +++--
arch/arm64/boot/dts/arm/juno-base.dtsi | 82 +++++---
arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi | 26 ++-
arch/arm64/boot/dts/arm/juno.dts | 5 +-
.../arm64/boot/dts/hisilicon/hi6220-coresight.dtsi | 89 ++++++---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 55 ++++--
arch/arm64/boot/dts/sprd/sc9836.dtsi | 40 ++--
arch/arm64/boot/dts/sprd/sc9860.dtsi | 101 +++++++---
drivers/hwtracing/coresight/coresight.c | 30 +--
drivers/hwtracing/coresight/of_coresight.c | 219 +++++++++++++--------
include/linux/coresight.h | 11 +-
21 files changed, 818 insertions(+), 348 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH V2 1/2] clk: imx6ul: add GPIO clock gates
From: Rob Herring @ 2018-06-05 21:10 UTC (permalink / raw)
To: Anson Huang
Cc: shawnguo, kernel, fabio.estevam, mark.rutland, mturquette, sboyd,
michael, matteo.lisi, devicetree, linux-clk, Linux-imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <1527990245-13619-1-git-send-email-Anson.Huang@nxp.com>
On Sun, Jun 03, 2018 at 09:44:04AM +0800, Anson Huang wrote:
> i.MX6UL has GPIO clock gates in CCM CCGR,
> add them into clock tree for clock management.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> changes since V1:
> Move IMX6UL_CLK_GPIOx definition to end of clock table;
> Based on Fabio's patch "[v2] dt-bindings: clock: imx6ul: Do not change the clock definition order".
> drivers/clk/imx/clk-imx6ul.c | 5 +++++
> include/dt-bindings/clock/imx6ul-clock.h | 8 +++++++-
> 2 files changed, 12 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: clock: imx6ul: Do not change the clock definition order
From: Rob Herring @ 2018-06-05 21:08 UTC (permalink / raw)
To: Fabio Estevam
Cc: sboyd, michael, stefan.wahren, devicetree, linux-clk, anson.huang,
stefan, Fabio Estevam
In-Reply-To: <1527948122-32092-1-git-send-email-festevam@gmail.com>
On Sat, Jun 02, 2018 at 11:02:02AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> Commit f5a4670de966 ("clk: imx: Add new clo01 and clo2 controlled
> by CCOSR") introduced the CLK_CLKO definitions, but didn't put them
> at the end of the list, which may cause dtb breakage when running an old
> dtb with a newer kernel.
>
> In order to avoid that, simply add the new CLK_CKO clock definitions
> at the end of the list.
>
> Fixes: f5a4670de966 ("clk: imx: Add new clo01 and clo2 controlled by CCOSR")
> Reported-by: Stefan Wahren <stefan.wahren@i2se.com>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> Changes since v1:
> - Use 12 char for the commit id
>
> include/dt-bindings/clock/imx6ul-clock.h | 40 +++++++++++++++-----------------
> 1 file changed, 19 insertions(+), 21 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 5/5] venus: register separate driver for firmware device
From: Rob Herring @ 2018-06-05 21:07 UTC (permalink / raw)
To: Vikash Garodia
Cc: hverkuil, mchehab, mark.rutland, andy.gross, bjorn.andersson,
stanimir.varbanov, linux-media, linux-kernel, linux-arm-msm,
linux-soc, devicetree, acourbot
In-Reply-To: <1527884768-22392-6-git-send-email-vgarodia@codeaurora.org>
On Sat, Jun 02, 2018 at 01:56:08AM +0530, Vikash Garodia wrote:
> A separate child device is added for video firmware.
> This is needed to
> [1] configure the firmware context bank with the desired SID.
> [2] ensure that the iova for firmware region is from 0x0.
>
> Signed-off-by: Vikash Garodia <vgarodia@codeaurora.org>
> ---
> .../devicetree/bindings/media/qcom,venus.txt | 8 +++-
> drivers/media/platform/qcom/venus/core.c | 48 +++++++++++++++++++---
> drivers/media/platform/qcom/venus/firmware.c | 20 ++++++++-
> drivers/media/platform/qcom/venus/firmware.h | 2 +
> 4 files changed, 71 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/qcom,venus.txt b/Documentation/devicetree/bindings/media/qcom,venus.txt
> index 00d0d1b..701cbe8 100644
> --- a/Documentation/devicetree/bindings/media/qcom,venus.txt
> +++ b/Documentation/devicetree/bindings/media/qcom,venus.txt
> @@ -53,7 +53,7 @@
>
> * Subnodes
> The Venus video-codec node must contain two subnodes representing
> -video-decoder and video-encoder.
> +video-decoder and video-encoder, one optional firmware subnode.
>
> Every of video-encoder or video-decoder subnode should have:
>
> @@ -79,6 +79,8 @@ Every of video-encoder or video-decoder subnode should have:
> power domain which is responsible for collapsing
> and restoring power to the subcore.
>
> +The firmware sub node must contain the iommus specifiers for ARM9.
> +
> * An Example
> video-codec@1d00000 {
> compatible = "qcom,msm8916-venus";
> @@ -105,4 +107,8 @@ Every of video-encoder or video-decoder subnode should have:
> clock-names = "core";
> power-domains = <&mmcc VENUS_CORE1_GDSC>;
> };
> + venus-firmware {
> + compatible = "qcom,venus-firmware-no-tz";
> + iommus = <&apps_smmu 0x10b2 0x0>;
This mostly looks like you are adding a node in order to create a
platform device. DT is not the only way to create platform devices and
shouldn't be used when the device is not really a separate h/w device.
Plus it seems like it is debatable that you even need a driver.
For iommus, just move it up to the parent (or add to existing prop).
Rob
^ permalink raw reply
* Re: [PATCH v2 13/16] dt-bindings/interrupt-controller: add documentation for Marvell SEI controller
From: Rob Herring @ 2018-06-05 20:51 UTC (permalink / raw)
To: Miquel Raynal
Cc: Thomas Gleixner, Jason Cooper, Marc Zyngier, Catalin Marinas,
Will Deacon, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Mark Rutland, devicetree, linux-arm-kernel, Thomas Petazzoni,
Antoine Tenart, Maxime Chevallier, Nadav Haklai, Haim Boot,
Hanna Hawa, linux-kernel
In-Reply-To: <20180522094042.24770-14-miquel.raynal@bootlin.com>
On Tue, May 22, 2018 at 11:40:39AM +0200, Miquel Raynal wrote:
> Describe the System Error Interrupt (SEI) controller. It aggregates two
> types of interrupts, wired and MSIs from respectively the AP and the
> CPs, into a single SPI interrupt.
>
> Suggested-by: Haim Boot <hayim@marvell.com>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
> .../bindings/interrupt-controller/marvell,sei.txt | 50 ++++++++++++++++++++++
> 1 file changed, 50 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/interrupt-controller/marvell,sei.txt
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/marvell,sei.txt b/Documentation/devicetree/bindings/interrupt-controller/marvell,sei.txt
> new file mode 100644
> index 000000000000..689981036c30
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interrupt-controller/marvell,sei.txt
> @@ -0,0 +1,50 @@
> +Marvell SEI (System Error Interrupt) Controller
> +-----------------------------------------------
> +
> +Marvell SEI (System Error Interrupt) controller is an interrupt
> +aggregator. It receives interrupts from several sources and aggregates
> +them to a single interrupt line (an SPI) on the parent interrupt
> +controller.
> +
> +This interrupt controller can handle up to 64 SEIs, a set comes from the
> +AP and is wired while a second set comes from the CPs by the mean of
> +MSIs. Each 'domain' is represented as a subnode.
> +
> +Required properties:
> +
> +- compatible: should be "marvell,armada-8k-sei".
> +- reg: SEI registers location and length.
> +- interrupts: identifies the parent IRQ that will be triggered.
> +
> +Child node 'sei-wired-controller' required properties:
> +
> +- marvell,sei-ranges: ranges of wired interrupts.
> +- #interrupt-cells: number of cells to define an SEI wired interrupt
> + coming from the AP, should be 1. The cell is the IRQ
> + number.
> +- interrupt-controller: identifies the node as an interrupt controller.
> +
> +Child node 'sei-msi-controller' required properties:
> +
> +- marvell,sei-ranges: ranges of non-wired interrupts triggered by way of
> + MSIs.
> +- msi-controller: identifies the node as an MSI controller.
> +
> +Example:
> +
> + sei: sei@3f0200 {
> + compatible = "marvell,armada-8k-sei";
> + reg = <0x3f0200 0x40>;
> + interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
> +
> + sei_wired_controller: sei-wired-controller@0 {
> + marvell,sei-ranges = <0 21>;
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + };
> +
> + sei_msi_controller: sei-msi-controller@21 {
> + marvell,sei-ranges = <21 43>;
> + msi-controller;
> + };
I still think this should just be all one node. There's several examples
in the tree of nodes which are both interrupt-controller and
msi-controller. Marvell MPIC is one example.
Rob
^ permalink raw reply
* Re: [PATCH v7 3/3] gpio: pca953x: fix address calculation for pcal6524
From: Pavel Machek @ 2018-06-05 20:39 UTC (permalink / raw)
To: Andy Shevchenko
Cc: H. Nikolaus Schaller, Kumar Gala, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Linus Walleij, Alexandre Courbot,
devicetree, open list:GPIO SUBSYSTEM, Linux Kernel Mailing List,
Discussions about the Letux Kernel, kernel
In-Reply-To: <CAHp75VfxN1RZBFRK6oJ5AzCe_2ej9eYdwt96X+fJZgFy65eaFg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1711 bytes --]
On Tue 2018-06-05 18:37:21, Andy Shevchenko wrote:
> On Wed, May 23, 2018 at 5:06 PM, Pavel Machek <pavel@ucw.cz> wrote:
> > On Thu 2018-05-17 06:59:49, H. Nikolaus Schaller wrote:
> >> The register constants are so far defined in a way that they fit
> >> for the pcal9555a when shifted by the number of banks, i.e. are
> >> multiplied by 2 in the accessor function.
> >>
> >> Now, the pcal6524 has 3 banks which means the relative offset
> >> is multiplied by 4 for the standard registers.
> >>
> >> Simply applying the bit shift to the extended registers gives
> >> a wrong result, since the base offset is already included in
> >> the offset.
> >>
> >> Therefore, we have to add code to the 24 bit accessor functions
> >> that adjusts the register number for these exended registers.
> >>
> >> The formula finally used was developed and proposed by
> >> Andy Shevchenko <andy.shevchenko@gmail.com>.
>
> >> int bank_shift = fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
> >> + int addr = (reg & PCAL_GPIO_MASK) << bank_shift;
> >> + int pinctrl = (reg & PCAL_PINCTRL_MASK) << 1;
>
> > Is this reasonable to do on each register access? Compiler will not be
> > able to optimize out fls and shifts, right?
>
> On modern CPUs fls() is one assembly command. OTOH, any proposal to do
> this better?
>
> What I can see is that bank_shift is invariant to the function, and
> maybe cached.
Yes, I thought that caching bank_shift might be good idea. I thought
it was constant for given chip...
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH v2 12/16] dt-bindings/interrupt-controller: update Marvell ICU bindings
From: Thomas Petazzoni @ 2018-06-05 20:35 UTC (permalink / raw)
To: Rob Herring
Cc: Miquel Raynal, Thomas Gleixner, Jason Cooper, Marc Zyngier,
Catalin Marinas, Will Deacon, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, Mark Rutland, devicetree, linux-arm-kernel,
Antoine Tenart, Maxime Chevallier, Nadav Haklai, Haim Boot,
Hanna Hawa, linux-kernel
In-Reply-To: <20180605202902.GA8875@rob-hp-laptop>
Hello,
On Tue, 5 Jun 2018 14:29:02 -0600, Rob Herring wrote:
> On Tue, May 22, 2018 at 11:40:38AM +0200, Miquel Raynal wrote:
> > Change the documentation to reflect the new bindings used for Marvell
> > ICU. This involves describing each interrupt group as a subnode of the
> > ICU node. Each of them having their own compatible.
>
> Need to explain why you need to do this and why breaking backwards
> compatibility is okay.
It does not break backward compatibility. The driver changes keep
support for the previous DT binding where there was a single node with
no subnodes.
The DT binding documentation still documents the legacy binding,
because it is still supported, and still works.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2 12/16] dt-bindings/interrupt-controller: update Marvell ICU bindings
From: Rob Herring @ 2018-06-05 20:29 UTC (permalink / raw)
To: Miquel Raynal
Cc: Thomas Gleixner, Jason Cooper, Marc Zyngier, Catalin Marinas,
Will Deacon, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Mark Rutland, devicetree, linux-arm-kernel, Thomas Petazzoni,
Antoine Tenart, Maxime Chevallier, Nadav Haklai, Haim Boot,
Hanna Hawa, linux-kernel
In-Reply-To: <20180522094042.24770-13-miquel.raynal@bootlin.com>
On Tue, May 22, 2018 at 11:40:38AM +0200, Miquel Raynal wrote:
> Change the documentation to reflect the new bindings used for Marvell
> ICU. This involves describing each interrupt group as a subnode of the
> ICU node. Each of them having their own compatible.
Need to explain why you need to do this and why breaking backwards
compatibility is okay.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
> .../bindings/interrupt-controller/marvell,icu.txt | 81 ++++++++++++++++++----
> 1 file changed, 69 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/marvell,icu.txt b/Documentation/devicetree/bindings/interrupt-controller/marvell,icu.txt
> index 649b7ec9d9b1..6f7e4355b3d8 100644
> --- a/Documentation/devicetree/bindings/interrupt-controller/marvell,icu.txt
> +++ b/Documentation/devicetree/bindings/interrupt-controller/marvell,icu.txt
> @@ -5,6 +5,8 @@ The Marvell ICU (Interrupt Consolidation Unit) controller is
> responsible for collecting all wired-interrupt sources in the CP and
> communicating them to the GIC in the AP, the unit translates interrupt
> requests on input wires to MSG memory mapped transactions to the GIC.
> +These messages will access a different GIC memory area depending on
> +their type (NSR, SR, SEI, REI, etc).
>
> Required properties:
>
> @@ -12,20 +14,19 @@ Required properties:
>
> - reg: Should contain ICU registers location and length.
>
> +Subnodes: Each group of interrupt is declared as a subnode of the ICU,
> +with their own compatible.
> +
> +Required properties for the icu_nsr/icu_sei subnodes:
> +
> +- compatible: Should be "marvell,cp110-icu-nsr" or "marvell,cp110-icu-sei".
> +
> - #interrupt-cells: Specifies the number of cells needed to encode an
> - interrupt source. The value shall be 3.
> + interrupt source. The value shall be 2.
>
> - The 1st cell is the group type of the ICU interrupt. Possible group
> - types are:
> + The 1st cell is the index of the interrupt in the ICU unit.
>
> - ICU_GRP_NSR (0x0) : Shared peripheral interrupt, non-secure
> - ICU_GRP_SR (0x1) : Shared peripheral interrupt, secure
> - ICU_GRP_SEI (0x4) : System error interrupt
> - ICU_GRP_REI (0x5) : RAM error interrupt
What happens to SR and REI interrupts?
> -
> - The 2nd cell is the index of the interrupt in the ICU unit.
> -
> - The 3rd cell is the type of the interrupt. See arm,gic.txt for
> + The 2nd cell is the type of the interrupt. See arm,gic.txt for
> details.
>
> - interrupt-controller: Identifies the node as an interrupt
> @@ -35,17 +36,73 @@ Required properties:
> that allows to trigger interrupts using MSG memory mapped
> transactions.
>
> +Note: each 'interrupts' property referring to any 'icu_xxx' node shall
> + have a different number within [0:206].
> +
> Example:
>
> icu: interrupt-controller@1e0000 {
> compatible = "marvell,cp110-icu";
> reg = <0x1e0000 0x440>;
> +
> + CP110_LABEL(icu_nsr): icu-nsr {
'interrupt-controller' is the proper node name. Is there no register
range associated sub nodes?
> + compatible = "marvell,cp110-icu-nsr";
> + #interrupt-cells = <2>;
> + interrupt-controller;
> + msi-parent = <&gicp>;
> + };
> +
> + CP110_LABEL(icu_sei): icu-sei {
> + compatible = "marvell,cp110-icu-sei";
> + #interrupt-cells = <2>;
> + interrupt-controller;
> + msi-parent = <&sei>;
> + };
Mixture of tabs and spaces.
> +};
> +
> +node1 {
> + interrupt-parent = <&icu_nsr>;
> + interrupts = <106 IRQ_TYPE_LEVEL_HIGH>;
> +};
> +
> +node2 {
> + interrupt-parent = <&icu_sei>;
> + interrupts = <107 IRQ_TYPE_LEVEL_HIGH>;
> +};
> +
> +/* Would not work with the above nodes */
> +node3 {
> + interrupt-parent = <&icu_nsr>;
> + interrupts = <107 IRQ_TYPE_LEVEL_HIGH>;
> +};
> +
> +Note on legacy bindings:
> +Before using a subnode for each domain, only NSR were
> +supported. Bindings were different in this way:
> +
> +- #interrupt-cells: The value was 3.
> + The 1st cell was the group type of the ICU interrupt. Possible
> + group types were:
> + ICU_GRP_NSR (0x0) : Shared peripheral interrupt, non-secure
> + ICU_GRP_SR (0x1) : Shared peripheral interrupt, secure
> + ICU_GRP_SEI (0x4) : System error interrupt
> + ICU_GRP_REI (0x5) : RAM error interrupt
> + The 2nd cell was the index of the interrupt in the ICU unit.
> + The 3rd cell was the type of the interrupt. See arm,gic.txt for
> + details.
> +
> +Example:
> +
> +icu: interrupt-controller@1e0000 {
> + compatible = "marvell,cp110-icu";
> + reg = <0x1e0000 0x440>;
> +
> #interrupt-cells = <3>;
> interrupt-controller;
> msi-parent = <&gicp>;
> };
>
> -usb3h0: usb3@500000 {
> +node1 {
> interrupt-parent = <&icu>;
> interrupts = <ICU_GRP_NSR 106 IRQ_TYPE_LEVEL_HIGH>;
> };
> --
> 2.14.1
>
^ permalink raw reply
* [PATCH 1/2] dt-bindings: display: renesas: lvds: document R8A77980 bindings
From: Sergei Shtylyov @ 2018-06-05 20:28 UTC (permalink / raw)
To: Laurent Pinchart, David Airlie, Rob Herring, dri-devel,
linux-renesas-soc, devicetree
Cc: Mark Rutland
In-Reply-To: <ef3c6b7e-98f2-7012-71c5-6693e6e48999@cogentembedded.com>
Document the R-Car V3H (R8A77980) SoC in the R-Car LVDS bindings.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt | 1 +
1 file changed, 1 insertion(+)
Index: drm/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
===================================================================
--- drm.orig/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
+++ drm/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
@@ -14,6 +14,7 @@ Required properties:
- "renesas,r8a7795-lvds" for R8A7795 (R-Car H3) compatible LVDS encoders
- "renesas,r8a7796-lvds" for R8A7796 (R-Car M3-W) compatible LVDS encoders
- "renesas,r8a77970-lvds" for R8A77970 (R-Car V3M) compatible LVDS encoders
+ - "renesas,r8a77980-lvds" for R8A77980 (R-Car V3H) compatible LVDS encoders
- "renesas,r8a77995-lvds" for R8A77995 (R-Car D3) compatible LVDS encoders
- reg: Base address and length for the memory-mapped registers
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH 0/2] Add R-Car V3H (R8A77980) support to the R-Car LVDS driver
From: Sergei Shtylyov @ 2018-06-05 20:25 UTC (permalink / raw)
To: Laurent Pinchart, David Airlie, Rob Herring, dri-devel,
linux-renesas-soc, devicetree
Cc: Mark Rutland
Hello!
Here's the set of 2 patches against the 'drm-next' branch of the 'drm.git' repo.
The purpose of these patches is to add the R-Car V3H (R8A77980) support to the
R-Car LVDS driver.
[1/2] dt-bindings: display: renesas: lvds: document R8A77980 bindings
[2/2] drm: rcar-du: lvds: add R8A77980 support
MBR, Sergei
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH] dt-bindings: display: renesas: du: document R8A77980 bindings
From: Laurent Pinchart @ 2018-06-05 20:24 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Mark Rutland, devicetree, David Airlie, dri-devel,
linux-renesas-soc, Rob Herring
In-Reply-To: <50730759-dfda-12c5-a7f3-4e8a9b7b1eb9@cogentembedded.com>
Hi Sergei,
On Tuesday, 5 June 2018 22:49:57 EEST Sergei Shtylyov wrote:
> On 06/05/2018 10:16 PM, Laurent Pinchart wrote:
> >>>> Document the R-Car V3H (R8A77980) SoC in the R-Car DU bindings; the DU
> >>>> hardware seems the same as in the R-Car V3M (R8A77970).
> >>>
> >>> How about "the DU hardware has the same topology as in the R-Car V3M
> >>> (R8A77970)" ? "seems" sounds like we're very unsure :-)
> >>
> >> That's probably better, indeed.
> >>
> >>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> >>>>
> >>>> ---
> >>>> The patch is against the 'drm-next' branch of David Airlie's
> >>>> 'linux.git' repo.
> >>>
> >>> Then you might want to switch to git://anongit.freedesktop.org/drm/drm
> >>> :-)
> >>
> >> No, the corresponding MAINTAINERS records don't include
> >> drivers/gpu/drm/rcar-du/ or worse yet, the DU bindings. :-)
>
> Well, there is still no corresponding record, actually...
>
> > My point is that Dave's tree has moved.
>
> How am I supposed to learn about it, from gossips? :-)
I learnt it the hard way when a pull request I had prepared against the old
tree conflicted (at compile time) with patches merged in the new tree. This
broke the build, and I learnt about the new tree from a kbuild bot report.
> >> Seriously, I thought you've done a patch to remove your dead 'fbdev' repo
> >> months ago and IO'm still seeing it listed... :-/
> >
> > I'll address that now.
>
> TIA.
>
> >>> Apart from that,
> >>>
> >>> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> >>>
> >>> If you agree with the small change to the commit message I'll fix the
> >>> conflict locally, there's no need to resubmit.
> >>
> >> I do agree, except I don't know what conflict you mean.
> >>
> >> [...]
> >
> > I mean the conflict with
> >
> > commit dc8142901befabea974393d49b803f131243feb4
> > Author: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
> > Date: Thu Apr 26 17:53:31 2018 +0100
> >
> > dt-bindings: display: renesas: du: Document the r8a77965 bindings
> >
> > that is present in Dave's new tree.
>
> Ah... TIA again. :-)
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v3 3/6] mtd: rawnand: tegra: add devicetree binding
From: Dmitry Osipenko @ 2018-06-05 20:19 UTC (permalink / raw)
To: Boris Brezillon, Stefan Agner
Cc: dwmw2, computersforpeace, marek.vasut, robh+dt, mark.rutland,
thierry.reding, benjamin.lindqvist, pgaikwad, dev, mirza.krak,
richard, pdeschrijver, linux-kernel, krzk, jonathanh, devicetree,
linux-mtd, marcel, miquel.raynal, linux-tegra
In-Reply-To: <20180601093025.2817ff30@bbrezillon>
On 01.06.2018 10:30, Boris Brezillon wrote:
> On Fri, 1 Jun 2018 00:16:34 +0200
> Stefan Agner <stefan@agner.ch> wrote:
>
>> This adds the devicetree binding for the Tegra 2 NAND flash
>> controller.
>>
>> Signed-off-by: Lucas Stach <dev@lynxeye.de>
>> Signed-off-by: Stefan Agner <stefan@agner.ch>
>> ---
>> .../bindings/mtd/nvidia-tegra20-nand.txt | 64 +++++++++++++++++++
>> 1 file changed, 64 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt b/Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt
>> new file mode 100644
>> index 000000000000..5cd984ef046b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt
>> @@ -0,0 +1,64 @@
>> +NVIDIA Tegra NAND Flash controller
>> +
>> +Required properties:
>> +- compatible: Must be one of:
>> + - "nvidia,tegra20-nand"
>
> As discussed previously, I prefer "nvidia,tegra20-nand-controller" or
> "nvidia,tegra20-nfc".
>
>> +- reg: MMIO address range
>> +- interrupts: interrupt output of the NFC controller
>> +- clocks: Must contain an entry for each entry in clock-names.
>> + See ../clocks/clock-bindings.txt for details.
>> +- clock-names: Must include the following entries:
>> + - nand
>> +- resets: Must contain an entry for each entry in reset-names.
>> + See ../reset/reset.txt for details.
>> +- reset-names: Must include the following entries:
>> + - nand
>> +
>> +Optional children nodes:
>> +Individual NAND chips are children of the NAND controller node. Currently
>> +only one NAND chip supported.
>> +
>> +Required children node properties:
>> +- reg: An integer ranging from 1 to 6 representing the CS line to use.
>> +
>> +Optional children node properties:
>> +- nand-ecc-mode: String, operation mode of the NAND ecc mode. Currently only
>> + "hw" is supported.
>> +- nand-ecc-algo: string, algorithm of NAND ECC.
>> + Supported values with "hw" ECC mode are: "rs", "bch".
>> +- nand-bus-width : See nand.txt
>> +- nand-on-flash-bbt: See nand.txt
>> +- nand-ecc-strength: integer representing the number of bits to correct
>> + per ECC step (always 512). Supported strength using HW ECC
>> + modes are:
>> + - RS: 4, 6, 8
>> + - BCH: 4, 8, 14, 16
>> +- nand-ecc-maximize: See nand.txt
>> +- nand-is-boot-medium: Makes sure only ECC strengths supported by the boot ROM
>> + are choosen.
>> +- wp-gpios: GPIO specifier for the write protect pin.
>> +
>> +Optional child node of NAND chip nodes:
>> +Partitions: see partition.txt
>> +
>> + Example:
>> + nand@70008000 {
>
> nand-controller@70008000 {
>
>> + compatible = "nvidia,tegra20-nand";
>
> compatible = "nvidia,tegra20-nand-controller";
>
> or
>
> compatible = "nvidia,tegra20-nfc";
>
Maybe it's just me, but when I'm reading "nfc", my first association is the
"Near Field Communication". Probably an explicit
"nvidia,tegra20-nand-controller" variant is more preferable.
>> + reg = <0x70008000 0x100>;
>> + interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
>> + clocks = <&tegra_car TEGRA20_CLK_NDFLASH>;
>> + clock-names = "nand";
>> + resets = <&tegra_car 13>;
>> + reset-names = "nand";
>> +
>> + nand-chip@0 {
>
> nand@0 {
>
>> + reg = <0>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + nand-bus-width = <8>;
>> + nand-on-flash-bbt;
>> + nand-ecc-algo = "bch";
>> + nand-ecc-strength = <8>;
>> + wp-gpios = <&gpio TEGRA_GPIO(S, 0) GPIO_ACTIVE_LOW>;
>> + };
>> + };
>
> With this addressed,
>
> Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com>
>
^ permalink raw reply
* Re: [PATCH v3 2/2] dt-bindings: power: sbs-battery: re-document "ti,bq20z75"
From: Rob Herring @ 2018-06-05 20:18 UTC (permalink / raw)
To: Brian Norris
Cc: Sebastian Reichel, linux-kernel, linux-pm, devicetree,
Rhyland Klein, Alexandru Stan, Guenter Roeck, Doug Anderson
In-Reply-To: <20180602012900.181352-2-briannorris@chromium.org>
On Fri, Jun 01, 2018 at 06:29:00PM -0700, Brian Norris wrote:
> This compatible property was documented before the driver was renamed to
> "SBS" (see commit e57f1b68c406 ("devicetree-bindings: Propagate
> bq20z75->sbs rename to dt bindings")). The driver has continued to
> support this property as an alternative to "sbs,sbs-battery", and
> because we've noticed there are some lingering TI specifics (in the
> manufacturer-specific portion of the SBS spec), we'd like to start using
> this property again to differentiate.
>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> Acked-by: Rhyland Klein <rklein@nvidia.com>
> ---
> v2: add Rhyland's Acked-by
> v3: no change
> ---
> .../devicetree/bindings/power/supply/sbs_sbs-battery.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 3/6] mtd: rawnand: tegra: add devicetree binding
From: Rob Herring @ 2018-06-05 20:13 UTC (permalink / raw)
To: Stefan Agner
Cc: boris.brezillon, dwmw2, computersforpeace, marek.vasut,
mark.rutland, thierry.reding, dev, miquel.raynal, richard, marcel,
krzk, digetx, benjamin.lindqvist, jonathanh, pdeschrijver,
pgaikwad, mirza.krak, linux-mtd, linux-tegra, devicetree,
linux-kernel
In-Reply-To: <20180531221637.6017-4-stefan@agner.ch>
On Fri, Jun 01, 2018 at 12:16:34AM +0200, Stefan Agner wrote:
> This adds the devicetree binding for the Tegra 2 NAND flash
> controller.
>
> Signed-off-by: Lucas Stach <dev@lynxeye.de>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
> ---
> .../bindings/mtd/nvidia-tegra20-nand.txt | 64 +++++++++++++++++++
> 1 file changed, 64 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 2/6] mtd: rawnand: add an option to specify NAND chip as a boot device
From: Rob Herring @ 2018-06-05 20:11 UTC (permalink / raw)
To: Stefan Agner
Cc: boris.brezillon, dwmw2, computersforpeace, marek.vasut,
mark.rutland, thierry.reding, dev, miquel.raynal, richard, marcel,
krzk, digetx, benjamin.lindqvist, jonathanh, pdeschrijver,
pgaikwad, mirza.krak, linux-mtd, linux-tegra, devicetree,
linux-kernel
In-Reply-To: <20180531221637.6017-3-stefan@agner.ch>
On Fri, Jun 01, 2018 at 12:16:33AM +0200, Stefan Agner wrote:
> Allow to define a NAND chip as a boot device. This can be helpful
> for the selection of the ECC algorithm and strength in case the boot
> ROM supports only a subset of controller provided options.
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
> ---
> Documentation/devicetree/bindings/mtd/nand.txt | 4 ++++
> drivers/mtd/nand/raw/nand_base.c | 3 +++
> include/linux/mtd/rawnand.h | 6 ++++++
> 3 files changed, 13 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mtd/nand.txt b/Documentation/devicetree/bindings/mtd/nand.txt
> index 8bb11d809429..8daf81b9748c 100644
> --- a/Documentation/devicetree/bindings/mtd/nand.txt
> +++ b/Documentation/devicetree/bindings/mtd/nand.txt
> @@ -43,6 +43,10 @@ Optional NAND chip properties:
> This is particularly useful when only the in-band area is
> used by the upper layers, and you want to make your NAND
> as reliable as possible.
> +- nand-is-boot-medium: Whether the NAND chip is a boot medium. Drivers might use
> + this information to select ECC algorithms supported by
> + the boot ROM or similar restrictions.
> +
Shouldn't this be a partition level option? You could conceivably do one
ECC type for boot area and something else for the rest of the NAND.
> - nand-rb: shall contain the native Ready/Busy ids.
>
> The ECC strength and ECC step size properties define the correction capability
> diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
> index 9eb5678dd6d0..c8fb7c9855e2 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -5826,6 +5826,9 @@ static int nand_dt_init(struct nand_chip *chip)
> if (of_get_nand_bus_width(dn) == 16)
> chip->options |= NAND_BUSWIDTH_16;
>
> + if (of_property_read_bool(dn, "nand-is-boot-medium"))
> + chip->options |= NAND_IS_BOOT_MEDIUM;
> +
> if (of_get_nand_on_flash_bbt(dn))
> chip->bbt_options |= NAND_BBT_USE_FLASH;
>
> diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
> index 6a82da8c44ce..8e54fcf2fa94 100644
> --- a/include/linux/mtd/rawnand.h
> +++ b/include/linux/mtd/rawnand.h
> @@ -212,6 +212,12 @@ enum nand_ecc_algo {
> */
> #define NAND_WAIT_TCCS 0x00200000
>
> +/*
> + * Whether the NAND chip is a boot medium. Drivers might use this information
> + * to select ECC algorithms supported by the boot ROM or similar restrictions.
> + */
> +#define NAND_IS_BOOT_MEDIUM 0x00400000
> +
> /* Options set by nand scan */
> /* Nand scan has allocated controller struct */
> #define NAND_CONTROLLER_ALLOC 0x80000000
> --
> 2.17.0
>
^ permalink raw reply
* Re: [PATCH v3 2/3] USB: DT probing support to ehci-npcm7xx
From: Rob Herring @ 2018-06-05 20:01 UTC (permalink / raw)
To: avifishman70
Cc: gregkh, stern, tmaimon77, venture, yuenn, brendanhiggins,
mathias.nyman, bjorn.andersson, jhogan, albeu, chunfeng.yun, tony,
baolu.lu, elder, digetx, kstewart, hdegoede, linux-kernel,
linux-usb, openbmc, mark.rutland, devicetree
In-Reply-To: <1527788430-12494-3-git-send-email-avifishman70@gmail.com>
On Thu, May 31, 2018 at 08:40:29PM +0300, avifishman70@gmail.com wrote:
> From: Avi Fishman <AviFishman70@gmail.com>
The subject sounds like a driver change, not a binding doc. To start
with, the subject prefix should be "dt-bindings: usb: ..."
> Device Tree documentation for Nuvoton npcm7xx EHCI.
>
> Signed-off-by: Avi Fishman <AviFishman70@gmail.com>
> ---
> Documentation/devicetree/bindings/usb/npcm7xx-usb.txt | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/usb/npcm7xx-usb.txt
Otherwise,
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 2/5] gpio: syscon: rockchip: add GPIO_MUTE support for rk3328
From: Rob Herring @ 2018-06-05 19:58 UTC (permalink / raw)
To: Levin Du
Cc: open list:ARM/Rockchip SoC..., Wayne Chou, Heiko Stuebner,
devicetree, Linus Walleij, linux-kernel@vger.kernel.org,
open list:GPIO SUBSYSTEM, Mark Rutland,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <87zi0d8tue.fsf@t-chip.com.cn>
On Sat, Jun 02, 2018 at 04:40:09PM +0800, Levin Du wrote:
>
> Rob Herring <robh+dt@kernel.org> writes:
>
> > On Thu, May 31, 2018 at 9:05 PM, Levin <djw@t-chip.com.cn> wrote:
> > > Hi Rob,
> > >
> > >
> > > On 2018-05-31 10:45 PM, Rob Herring wrote:
> > > >
> > > > On Wed, May 30, 2018 at 10:27 PM, <djw@t-chip.com.cn> wrote:
> > > > >
> > > > > From: Levin Du <djw@t-chip.com.cn>
> > > > >
> > > > > In Rockchip RK3328, the output only GPIO_MUTE pin,
> > > > > originally for codec
> > > > > mute control, can also be used for general purpose. It is
> > > > > manipulated by
> > > > > the GRF_SOC_CON10 register.
> > > > >
> > > > > Signed-off-by: Levin Du <djw@t-chip.com.cn>
> > > > >
> > > > > ---
> > > > >
> > > > > Changes in v3:
> > > > > - Change from general gpio-syscon to specific
> > > > > rk3328-gpio-mute
> > > > >
> > > > > Changes in v2:
> > > > > - Rename gpio_syscon10 to gpio_mute in doc
> > > > >
> > > > > Changes in v1:
> > > > > - Refactured for general gpio-syscon usage for Rockchip SoCs.
> > > > > - Add doc rockchip,gpio-syscon.txt
> > > > >
> > > > > .../bindings/gpio/rockchip,rk3328-gpio-mute.txt | 28
> > > > > +++++++++++++++++++
> > > > > drivers/gpio/gpio-syscon.c | 31
> > > > > ++++++++++++++++++++++
> > > > > 2 files changed, 59 insertions(+)
> > > > > create mode 100644
> > > > > Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
> > > > >
> > > > > diff --git
> > > > > a/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
> > > > > b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
> > > > > new file mode 100644
> > > > > index 0000000..10bc632
> > > > > --- /dev/null
> > > > > +++
> > > > > b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
> > > > > @@ -0,0 +1,28 @@
> > > > > +Rockchip RK3328 GPIO controller dedicated for the GPIO_MUTE
> > > > > pin.
> > > > > +
> > > > > +In Rockchip RK3328, the output only GPIO_MUTE pin,
> > > > > originally for codec
> > > > > mute
> > > > > +control, can also be used for general purpose. It is
> > > > > manipulated by the
> > > > > +GRF_SOC_CON10 register.
> > > > > +
> > > > > +Required properties:
> > > > > +- compatible: Should contain "rockchip,rk3328-gpio-mute".
> > > > > +- gpio-controller: Marks the device node as a gpio
> > > > > controller.
> > > > > +- #gpio-cells: Should be 2. The first cell is the pin
> > > > > number and
> > > > > + the second cell is used to specify the gpio polarity:
> > > > > + 0 = Active high,
> > > > > + 1 = Active low.
> > > > > +
> > > > > +Example:
> > > > > +
> > > > > + grf: syscon@ff100000 {
> > > > > + compatible = "rockchip,rk3328-grf", "syscon",
> > > > > "simple-mfd";
> > > > > +
> > > > > + gpio_mute: gpio-mute {
> > > >
> > > > Node names should be generic:
> > > >
> > > > gpio {
> > > >
> > > > This also means you can't add another GPIO node in the future
> > > > and
> > > > you'll have to live with "rockchip,rk3328-gpio-mute" covering
> > > > more
> > > > than 1 GPIO if you do need to add more GPIOs.
> > >
> > >
> > > As the first line describes, this GPIO controller is dedicated for
> > > the
> > > GPIO_MUTE pin.
> > > There's only one GPIO pin in the GRF_SOC_CON10 register. Therefore
> > > the
> > > gpio_mute
> > > name is proper IMHO.
> >
> > It's how many GPIOs in the GRF, not this register. What I'm saying is
> > when you come along later to add another GPIO in the GRF, you had
> > better just add it to this same node. I'm not going to accept another
> > GPIO controller node within the GRF. You have the cells to support
> > more than 1, so it would only be a driver change. The compatible
> > string would then not be ideally named at that point. But compatible
> > strings are just unique identifiers, so it doesn't really matter what
> > the string is.
> >
>
> I'll try my best to introduce the situation here. The GRF, GPIO0~GPIO3
> are register blocks in the RK3328 Soc. The GPIO0~GPIO3 contain registers
> for GPIO operations like reading/writing data, setting direction,
> interruption etc, which corresponds to the GPIO banks (gpio0~gpio3)
> defined in rk3328.dtsi:
I'm only talking about GRF functions, not "regular" GPIOs.
> pinctrl: pinctrl {
> compatible = "rockchip,rk3328-pinctrl";
> rockchip,grf = <&grf>;
> #address-cells = <2>;
> #size-cells = <2>;
> ranges;
>
> gpio0: gpio0@ff210000 {
> compatible = "rockchip,gpio-bank";
> reg = <0x0 0xff210000 0x0 0x100>;
> interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&cru PCLK_GPIO0>;
>
> gpio-controller;
> #gpio-cells = <2>;
>
> interrupt-controller;
> #interrupt-cells = <2>;
> };
>
> gpio1: gpio1@ff220000 {
> //...
> };
>
> gpio2: gpio2@ff230000 {
> //...
> };
>
> gpio3: gpio3@ff240000 {
> //...
> };
> }
>
> However, these general GPIO pins has multiplexed functions and their
> pull up/down and driving strength can also be configured. These settings
> are manipulated by the GRF registers in pinctrl driver. Quoted from the
> TRM, the GRF has the following function:
>
> - IOMUX control
> - Control the state of GPIO in power-down mode
> - GPIO PAD pull down and pull up control
> - Used for common system control
> - Used to record the system state
>
> Therefore the functions of the GRF are messy and scattered in different
> nodes. The so-called GPIO_MUTE does not belong to GPIO0~GPIO3. It is
> manipulated by the GRF_SOC_CON10 register in the GRF block.
>
> > I'm being told both "this is the only GPIO" and "the GRF has too many
> > different functions for us to tell you what they all are". So which is
> > it?
> >
> > Rob
>
> They are both true, but lack of context. See the above description.
What I meant was "only GPIO in GRF registers"...
Rob
^ permalink raw reply
* Re: [PATCH v4 2/6] Documentation: DT: Add optional 'timeout-sec' property for sp805
From: Rob Herring @ 2018-06-05 19:55 UTC (permalink / raw)
To: Ray Jui
Cc: Wim Van Sebroeck, Guenter Roeck, Mark Rutland, Frank Rowand,
Catalin Marinas, Will Deacon, Robin Murphy, linux-watchdog,
devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list
In-Reply-To: <1527530497-10392-3-git-send-email-ray.jui@broadcom.com>
On Mon, May 28, 2018 at 11:01:33AM -0700, Ray Jui wrote:
> Update the SP805 binding document to add optional 'timeout-sec'
> devicetree property
Note "dt-bindings: watchdog: ..." is the preferred subject prefix.
>
> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> ---
> Documentation/devicetree/bindings/watchdog/arm,sp805.txt | 2 ++
> 1 file changed, 2 insertions(+)
Otherwise,
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] dt-bindings: display: renesas: du: document R8A77980 bindings
From: Sergei Shtylyov @ 2018-06-05 19:49 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Mark Rutland, devicetree, David Airlie, dri-devel,
linux-renesas-soc, Rob Herring
In-Reply-To: <3434502.pBJZTsWR88@avalon>
On 06/05/2018 10:16 PM, Laurent Pinchart wrote:
>>>> Document the R-Car V3H (R8A77980) SoC in the R-Car DU bindings; the DU
>>>> hardware seems the same as in the R-Car V3M (R8A77970).
>>>
>>> How about "the DU hardware has the same topology as in the R-Car V3M
>>> (R8A77970)" ? "seems" sounds like we're very unsure :-)
>>
>> That's probably better, indeed.
>>
>>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>>>
>>>> ---
>>>> The patch is against the 'drm-next' branch of David Airlie's 'linux.git'
>>>> repo.
>>>
>>> Then you might want to switch to git://anongit.freedesktop.org/drm/drm :-)
>>
>> No, the corresponding MAINTAINERS records don't include
>> drivers/gpu/drm/rcar-du/ or worse yet, the DU bindings. :-)
Well, there is still no corresponding record, actually...
> My point is that Dave's tree has moved.
How am I supposed to learn about it, from gossips? :-)
>> Seriously, I thought you've done a patch to remove your dead 'fbdev' repo
>> months ago and IO'm still seeing it listed... :-/
>
> I'll address that now.
TIA.
>>> Apart from that,
>>>
>>> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>>>
>>> If you agree with the small change to the commit message I'll fix the
>>> conflict locally, there's no need to resubmit.
>>
>> I do agree, except I don't know what conflict you mean.
>>
>> [...]
>
> I mean the conflict with
>
> commit dc8142901befabea974393d49b803f131243feb4
> Author: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
> Date: Thu Apr 26 17:53:31 2018 +0100
>
> dt-bindings: display: renesas: du: Document the r8a77965 bindings
>
> that is present in Dave's new tree.
Ah... TIA again. :-)
MBR, Sergei
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v4 1/6] Documentation: DT: Consolidate SP805 binding docs
From: Rob Herring @ 2018-06-05 19:41 UTC (permalink / raw)
To: Ray Jui
Cc: Wim Van Sebroeck, Guenter Roeck, Mark Rutland, Frank Rowand,
Catalin Marinas, Will Deacon, Robin Murphy, linux-watchdog,
devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list
In-Reply-To: <1527530497-10392-2-git-send-email-ray.jui@broadcom.com>
On Mon, May 28, 2018 at 11:01:32AM -0700, Ray Jui wrote:
> Consolidate two SP805 binding documents "arm,sp805.txt" and
> "sp805-wdt.txt" into "arm,sp805.txt" that matches the naming of the
> desired compatible string to be used
>
> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> ---
> .../devicetree/bindings/watchdog/arm,sp805.txt | 27 ++++++++++++++-----
> .../devicetree/bindings/watchdog/sp805-wdt.txt | 31 ----------------------
> 2 files changed, 20 insertions(+), 38 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
Would be good to get a ACK from FSL/NXP person on this. It looks to me
like the driver fetches the wrong clock as it gets the first one and the
driver really wants 'wdog_clk'. In any case, their dts files should be
updated.
Reviewed-by: Rob Herring <robh@kernel.org>
Rob
^ permalink raw reply
* Re: [PATCH] dt-bindings: display: renesas: du: document R8A77980 bindings
From: Laurent Pinchart @ 2018-06-05 19:16 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Mark Rutland, devicetree, David Airlie, dri-devel,
linux-renesas-soc, Rob Herring
In-Reply-To: <df4d4207-5343-36c0-7ca8-d431999a3f31@cogentembedded.com>
Hi Sergei,
On Tuesday, 5 June 2018 21:57:47 EEST Sergei Shtylyov wrote:
> On 06/05/2018 01:09 PM, Laurent Pinchart wrote:
> >> Document the R-Car V3H (R8A77980) SoC in the R-Car DU bindings; the DU
> >> hardware seems the same as in the R-Car V3M (R8A77970).
> >
> > How about "the DU hardware has the same topology as in the R-Car V3M
> > (R8A77970)" ? "seems" sounds like we're very unsure :-)
>
> That's probably better, indeed.
>
> >> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> >>
> >> ---
> >> The patch is against the 'drm-next' branch of David Airlie's 'linux.git'
> >> repo.
> >
> > Then you might want to switch to git://anongit.freedesktop.org/drm/drm :-)
>
> No, the corresponding MAINTAINERS records don't include
> drivers/gpu/drm/rcar-du/ or worse yet, the DU bindings. :-)
My point is that Dave's tree has moved.
> Seriously, I thought you've done a patch to remove your dead 'fbdev' repo
> months ago and IO'm still seeing it listed... :-/
I'll address that now.
> > Apart from that,
> >
> > Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> >
> > If you agree with the small change to the commit message I'll fix the
> > conflict locally, there's no need to resubmit.
>
> I do agree, except I don't know what conflict you mean.
>
> [...]
I mean the conflict with
commit dc8142901befabea974393d49b803f131243feb4
Author: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Date: Thu Apr 26 17:53:31 2018 +0100
dt-bindings: display: renesas: du: Document the r8a77965 bindings
that is present in Dave's new tree.
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH] dt-bindings: display: renesas: du: document R8A77980 bindings
From: Sergei Shtylyov @ 2018-06-05 18:57 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Mark Rutland, devicetree, David Airlie, dri-devel,
linux-renesas-soc, Rob Herring
In-Reply-To: <3941727.PNGxG4XCLb@avalon>
On 06/05/2018 01:09 PM, Laurent Pinchart wrote:
>> Document the R-Car V3H (R8A77980) SoC in the R-Car DU bindings; the DU
>> hardware seems the same as in the R-Car V3M (R8A77970).
>
> How about "the DU hardware has the same topology as in the R-Car V3M
> (R8A77970)" ? "seems" sounds like we're very unsure :-)
That's probably better, indeed.
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>
>> ---
>> The patch is against the 'drm-next' branch of David Airlie's 'linux.git'
>> repo.
>
> Then you might want to switch to git://anongit.freedesktop.org/drm/drm :-)
No, the corresponding MAINTAINERS records don't include drivers/gpu/drm/rcar-du/
or worse yet, the DU bindings. :-)
Seriously, I thought you've done a patch to remove your dead 'fbdev' repo months
ago and IO'm still seeing it listed... :-/
> Apart from that,
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
> If you agree with the small change to the commit message I'll fix the conflict
> locally, there's no need to resubmit.
I do agree, except I don't know what conflict you mean.
[...]
MBR, Sergei
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH V3] ARM: dts: armada388-helios4
From: Dennis Gilmore @ 2018-06-05 18:48 UTC (permalink / raw)
To: linux-kernel, jason, andrew, gregory.clement,
sebastian.hesselbarth, robh+dt, mark.rutland, linux-arm-kernel,
devicetree
Cc: Dennis Gilmore
The helios4 is a Armada388 based nas board designed by SolidRun and
based on their SOM. It is sold by kobol.io the dts file came from
https://raw.githubusercontent.com/armbian/build/master/patch/kernel/mvebu-default/95-helios4-device-tree.patch
I added a SPDX license line to match the clearfog it says it was based
on and a compatible line for "kobol,helios4"
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
changes since first submission
change solidrun to kobol in compatible line based on feedback
changes since v2
remove commented out nodes based on feedback
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-388-helios4.dts | 313 +++++++++++++++++++++++
2 files changed, 314 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-388-helios4.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7e2424957809..490bfd586198 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1123,6 +1123,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
armada-388-clearfog-pro.dtb \
armada-388-db.dtb \
armada-388-gp.dtb \
+ armada-388-helios4.dtb \
armada-388-rd.dtb
dtb-$(CONFIG_MACH_ARMADA_39X) += \
armada-398-db.dtb
diff --git a/arch/arm/boot/dts/armada-388-helios4.dts b/arch/arm/boot/dts/armada-388-helios4.dts
new file mode 100644
index 000000000000..59048740ae06
--- /dev/null
+++ b/arch/arm/boot/dts/armada-388-helios4.dts
@@ -0,0 +1,313 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Device Tree file for Helios4
+ * based on SolidRun Clearfog revision A1 rev 2.0 (88F6828)
+ *
+ * Copyright (C) 2017
+ *
+ */
+
+/dts-v1/;
+#include "armada-388.dtsi"
+#include "armada-38x-solidrun-microsom.dtsi"
+
+/ {
+ model = "Helios4";
+ compatible = "kobol,helios4", "marvell,armada388",
+ "marvell,armada385", "marvell,armada380";
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x80000000>; /* 2 GB */
+ };
+
+ aliases {
+ /* So that mvebu u-boot can update the MAC addresses */
+ ethernet1 = ð0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ reg_12v: regulator-12v {
+ compatible = "regulator-fixed";
+ regulator-name = "power_brick_12V";
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ regulator-always-on;
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ vin-supply = <®_12v>;
+ };
+
+ reg_5p0v_hdd: regulator-5v-hdd {
+ compatible = "regulator-fixed";
+ regulator-name = "5V_HDD";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ vin-supply = <®_12v>;
+ };
+
+ reg_5p0v_usb: regulator-5v-usb {
+ compatible = "regulator-fixed";
+ regulator-name = "USB-PWR";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ enable-active-high;
+ gpio = <&expander0 6 GPIO_ACTIVE_HIGH>;
+ vin-supply = <®_12v>;
+ };
+
+ system-leds {
+ compatible = "gpio-leds";
+ status-led {
+ label = "helios4:green:status";
+ gpios = <&gpio0 24 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "heartbeat";
+ default-state = "on";
+ };
+
+ fault-led {
+ label = "helios4:red:fault";
+ gpios = <&gpio0 25 GPIO_ACTIVE_LOW>;
+ default-state = "keep";
+ };
+ };
+
+ io-leds {
+ compatible = "gpio-leds";
+ sata1-led {
+ label = "helios4:green:ata1";
+ gpios = <&gpio1 17 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "ata1";
+ default-state = "off";
+ };
+ sata2-led {
+ label = "helios4:green:ata2";
+ gpios = <&gpio1 18 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "ata2";
+ default-state = "off";
+ };
+ sata3-led {
+ label = "helios4:green:ata3";
+ gpios = <&gpio1 20 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "ata3";
+ default-state = "off";
+ };
+ sata4-led {
+ label = "helios4:green:ata4";
+ gpios = <&gpio1 21 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "ata4";
+ default-state = "off";
+ };
+ usb-led {
+ label = "helios4:green:usb";
+ gpios = <&gpio1 22 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "usb-host";
+ default-state = "off";
+ };
+ };
+
+ fan1: j10-pwm {
+ compatible = "pwm-fan";
+ pwms = <&gpio1 9 40000>; /* Target freq:25 kHz */
+ };
+
+ fan2: j17-pwm {
+ compatible = "pwm-fan";
+ pwms = <&gpio1 23 40000>; /* Target freq:25 kHz */
+ };
+
+ usb2_phy: usb2-phy {
+ compatible = "usb-nop-xceiv";
+ vbus-regulator = <®_5p0v_usb>;
+ };
+
+ usb3_phy: usb3-phy {
+ compatible = "usb-nop-xceiv";
+ };
+
+ soc {
+ internal-regs {
+ i2c@11000 {
+ clock-frequency = <400000>;
+ pinctrl-0 = <&i2c0_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ /*
+ * PCA9655 GPIO expander, up to 1MHz clock.
+ * 0-Board Revision bit 0 #
+ * 1-Board Revision bit 1 #
+ * 5-USB3 overcurrent
+ * 6-USB3 power
+ */
+ expander0: gpio-expander@20 {
+ /*
+ * This is how it should be:
+ * compatible = "onnn,pca9655",
+ * "nxp,pca9555";
+ * but you can't do this because of
+ * the way I2C works.
+ */
+ compatible = "nxp,pca9555";
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0x20>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pca0_pins>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <23 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ board_rev_bit_0 {
+ gpio-hog;
+ gpios = <0 GPIO_ACTIVE_LOW>;
+ input;
+ line-name = "board-rev-0";
+ };
+ board_rev_bit_1 {
+ gpio-hog;
+ gpios = <1 GPIO_ACTIVE_LOW>;
+ input;
+ line-name = "board-rev-1";
+ };
+ usb3_ilimit {
+ gpio-hog;
+ gpios = <5 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "usb-overcurrent-status";
+ };
+ };
+
+ temp_sensor: temp@4c {
+ compatible = "ti,lm75";
+ reg = <0x4c>;
+ vcc-supply = <®_3p3v>;
+ };
+ };
+
+ i2c@11100 {
+ /*
+ * External I2C Bus for user peripheral
+ */
+ clock-frequency = <400000>;
+ pinctrl-0 = <&helios_i2c1_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ };
+
+ sata@a8000 {
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sata0: sata-port@0 {
+ reg = <0>;
+ };
+
+ sata1: sata-port@1 {
+ reg = <1>;
+ };
+ };
+
+ sata@e0000 {
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sata2: sata-port@0 {
+ reg = <0>;
+ };
+
+ sata3: sata-port@1 {
+ reg = <1>;
+ };
+ };
+
+ spi@10680 {
+ pinctrl-0 = <&spi1_pins
+ µsom_spi1_cs_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ };
+
+ sdhci@d8000 {
+ bus-width = <4>;
+ cd-gpios = <&gpio0 20 GPIO_ACTIVE_LOW>;
+ no-1-8-v;
+ pinctrl-0 = <&helios_sdhci_pins
+ &helios_sdhci_cd_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ vmmc = <®_3p3v>;
+ wp-inverted;
+ };
+
+ usb@58000 {
+ usb-phy = <&usb2_phy>;
+ status = "okay";
+ };
+
+ usb3@f0000 {
+ status = "okay";
+ };
+
+ usb3@f8000 {
+ status = "okay";
+ };
+
+ pinctrl@18000 {
+ pca0_pins: pca0-pins {
+ marvell,pins = "mpp23";
+ marvell,function = "gpio";
+ };
+ microsom_phy0_int_pins: microsom-phy0-int-pins {
+ marvell,pins = "mpp18";
+ marvell,function = "gpio";
+ };
+ helios_i2c1_pins: i2c1-pins {
+ marvell,pins = "mpp26", "mpp27";
+ marvell,function = "i2c1";
+ };
+ helios_sdhci_cd_pins: helios-sdhci-cd-pins {
+ marvell,pins = "mpp20";
+ marvell,function = "gpio";
+ };
+ helios_sdhci_pins: helios-sdhci-pins {
+ marvell,pins = "mpp21", "mpp28",
+ "mpp37", "mpp38",
+ "mpp39", "mpp40";
+ marvell,function = "sd0";
+ };
+ helios_led_pins: helios-led-pins {
+ marvell,pins = "mpp24", "mpp25",
+ "mpp49", "mpp50",
+ "mpp52", "mpp53",
+ "mpp54";
+ marvell,function = "gpio";
+ };
+ helios_fan_pins: helios-fan-pins {
+ marvell,pins = "mpp41", "mpp43",
+ "mpp48", "mpp55";
+ marvell,function = "gpio";
+ };
+ microsom_spi1_cs_pins: spi1-cs-pins {
+ marvell,pins = "mpp59";
+ marvell,function = "spi1";
+ };
+ };
+ };
+ };
+};
--
2.17.1
^ 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