* Re: [PATCH v10 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding
From: Rob Herring @ 2020-05-14 14:54 UTC (permalink / raw)
To: Xin Ji
Cc: devicetree, devel, Laurent Pinchart, Andrzej Hajda,
Nicolas Boichat, Sam Ravnborg, Neil Armstrong, Jonas Karlman,
Jernej Skrabec, David Airlie, Daniel Vetter, Dan Carpenter,
Nicolas Boichat, linux-kernel, dri-devel, Pi-Hsun Shih, Sheng Pan
In-Reply-To: <b720f7d2c5338813d31b7f715f59ca68c367d5a8.1588747998.git.xji@analogixsemi.com>
On Wed, May 06, 2020 at 03:04:20PM +0800, Xin Ji wrote:
> The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
> for portable device. It converts MIPI to DisplayPort 1.3 4K.
>
> You can add support to your board with binding.
We have an example in the binding, no reason to also put in the commit
msg.
>
> Example:
> anx7625_bridge: encoder@58 {
> compatible = "analogix,anx7625";
> reg = <0x58>;
> status = "okay";
> enable-gpios = <&pio 45 GPIO_ACTIVE_HIGH>;
> reset-gpios = <&pio 73 GPIO_ACTIVE_HIGH>;
>
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
>
> mipi2dp_bridge_in: port@0 {
> reg = <0>;
> anx7625_in: endpoint {
> remote-endpoint = <&mipi_dsi>;
> };
> };
>
> mipi2dp_bridge_out: port@1 {
> reg = <1>;
> anx7625_out: endpoint {
> remote-endpoint = <&panel_in>;
> };
> };
> };
> };
>
> Signed-off-by: Xin Ji <xji@analogixsemi.com>
> ---
> .../bindings/display/bridge/analogix,anx7625.yaml | 98 ++++++++++++++++++++++
> 1 file changed, 98 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> new file mode 100644
> index 0000000..6e54176
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> @@ -0,0 +1,98 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2019 Analogix Semiconductor, Inc.
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/display/bridge/analogix,anx7625.yaml#"
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> +
> +title: Analogix ANX7625 SlimPort (4K Mobile HD Transmitter)
> +
> +maintainers:
> + - Xin Ji <xji@analogixsemi.com>
> +
> +description: |
> + The ANX7625 is an ultra-low power 4K Mobile HD Transmitter
> + designed for portable devices.
> +
> +properties:
> + "#address-cells": true
> + "#size-cells": true
These don't belong here.
> +
> + compatible:
> + items:
> + - const: analogix,anx7625
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + description: used for interrupt pin B8.
> + maxItems: 1
> +
> + enable-gpios:
> + description: used for power on chip control, POWER_EN pin D2.
> + maxItems: 1
> +
> + reset-gpios:
> + description: used for reset chip control, RESET_N pin B7.
> + maxItems: 1
> +
> + ports:
> + type: object
> +
> + properties:
> + port@0:
> + type: object
> + description:
> + Video port for MIPI DSI input.
> +
> + port@1:
> + type: object
> + description:
> + Video port for panel or connector.
> +
> + required:
> + - port@0
> + - port@1
> +
> +required:
> + - compatible
> + - reg
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> +
> + i2c0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + anx7625_bridge: encoder@58 {
Drop any unused labels.
> + compatible = "analogix,anx7625";
> + reg = <0x58>;
> + enable-gpios = <&pio 45 GPIO_ACTIVE_HIGH>;
> + reset-gpios = <&pio 73 GPIO_ACTIVE_HIGH>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + mipi2dp_bridge_in: port@0 {
> + reg = <0>;
> + anx7625_in: endpoint {
> + remote-endpoint = <&mipi_dsi>;
> + };
> + };
> +
> + mipi2dp_bridge_out: port@1 {
> + reg = <1>;
> + anx7625_out: endpoint {
> + remote-endpoint = <&panel_in>;
> + };
> + };
> + };
> + };
> + };
> --
> 2.7.4
>
^ permalink raw reply
* Re: [RFC][PATCH 3/4] dma-buf: cma_heap: Extend logic to export CMA regions tagged with "linux,cma-heap"
From: Rob Herring @ 2020-05-14 14:52 UTC (permalink / raw)
To: Brian Starkey
Cc: John Stultz, Robin Murphy, lkml, Sumit Semwal, Andrew F. Davis,
Benjamin Gaignard, Liam Mark, Pratik Patel, Laura Abbott,
Chenbo Feng, Alistair Strachan, Sandeep Patil, Hridya Valsaraju,
Christoph Hellwig, Marek Szyprowski, Andrew Morton,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
dri-devel, linux-mm, nd
In-Reply-To: <20200513104401.lhh2m5avlasev6mj@DESKTOP-E1NTVVP.localdomain>
On Wed, May 13, 2020 at 5:44 AM Brian Starkey <brian.starkey@arm.com> wrote:
>
> Hi Rob,
>
> On Tue, May 12, 2020 at 11:37:14AM -0500, Rob Herring wrote:
> > On Mon, May 04, 2020 at 10:06:28AM +0100, Brian Starkey wrote:
> > > On Fri, May 01, 2020 at 12:01:40PM -0700, John Stultz wrote:
> > > > On Fri, May 1, 2020 at 4:08 AM Robin Murphy <robin.murphy@arm.com> wrote:
> > > > >
> > > > > On 2020-05-01 11:21 am, Brian Starkey wrote:
> > > > > > Hi John,
> > > > > >
> > > > > > On Fri, May 01, 2020 at 07:39:48AM +0000, John Stultz wrote:
> > > > > >> This patch reworks the cma_heap initialization so that
> > > > > >> we expose both the default CMA region and any CMA regions
> > > > > >> tagged with "linux,cma-heap" in the device-tree.
> > > > > >>
> > > > > >> Cc: Rob Herring <robh+dt@kernel.org>
> > > > > >> Cc: Sumit Semwal <sumit.semwal@linaro.org>
> > > > > >> Cc: "Andrew F. Davis" <afd@ti.com>
> > > > > >> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
> > > > > >> Cc: Liam Mark <lmark@codeaurora.org>
> > > > > >> Cc: Pratik Patel <pratikp@codeaurora.org>
> > > > > >> Cc: Laura Abbott <labbott@redhat.com>
> > > > > >> Cc: Brian Starkey <Brian.Starkey@arm.com>
> > > > > >> Cc: Chenbo Feng <fengc@google.com>
> > > > > >> Cc: Alistair Strachan <astrachan@google.com>
> > > > > >> Cc: Sandeep Patil <sspatil@google.com>
> > > > > >> Cc: Hridya Valsaraju <hridya@google.com>
> > > > > >> Cc: Christoph Hellwig <hch@lst.de>
> > > > > >> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> > > > > >> Cc: Robin Murphy <robin.murphy@arm.com>
> > > > > >> Cc: Andrew Morton <akpm@linux-foundation.org>
> > > > > >> Cc: devicetree@vger.kernel.org
> > > > > >> Cc: dri-devel@lists.freedesktop.org
> > > > > >> Cc: linux-mm@kvack.org
> > > > > >> Signed-off-by: John Stultz <john.stultz@linaro.org>
> > > > > >> ---
> > > > > >> drivers/dma-buf/heaps/cma_heap.c | 18 +++++++++---------
> > > > > >> 1 file changed, 9 insertions(+), 9 deletions(-)
> > > > > >>
> > > > > >> diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
> > > > > >> index 626cf7fd033a..dd154e2db101 100644
> > > > > >> --- a/drivers/dma-buf/heaps/cma_heap.c
> > > > > >> +++ b/drivers/dma-buf/heaps/cma_heap.c
> > > > > >> @@ -141,6 +141,11 @@ static int __add_cma_heap(struct cma *cma, void *data)
> > > > > >> {
> > > > > >> struct cma_heap *cma_heap;
> > > > > >> struct dma_heap_export_info exp_info;
> > > > > >> + struct cma *default_cma = dev_get_cma_area(NULL);
> > > > > >> +
> > > > > >> + /* We only add the default heap and explicitly tagged heaps */
> > > > > >> + if (cma != default_cma && !cma_dma_heap_enabled(cma))
> > > > > >> + return 0;
> > > > > >
> > > > > > Thinking about the pl111 thread[1], I'm wondering if we should also
> > > > > > let drivers call this directly to expose their CMA pools, even if they
> > > > > > aren't tagged for dma-heaps in DT. But perhaps that's too close to
> > > > > > policy.
> > > > >
> > > > > That sounds much like what my first thoughts were - apologies if I'm
> > > > > wildly off-base here, but as far as I understand:
> > > > >
> > > > > - Device drivers know whether they have their own "memory-region" or not.
> > > > > - Device drivers already have to do *something* to participate in dma-buf.
> > > > > - Device drivers know best how they make use of both the above.
> > > > > - Therefore couldn't it be left to drivers to choose whether to register
> > > > > their CMA regions as heaps, without having to mess with DT at all?
> >
> > +1, but I'm biased toward any solution not using DT. :)
> >
> > > > I guess I'm not opposed to this. But I guess I'd like to see some more
> > > > details? You're thinking the pl111 driver would add the
> > > > "memory-region" node itself?
> > > >
> > > > Assuming that's the case, my only worry is what if that memory-region
> > > > node isn't a CMA area, but instead something like a carveout? Does the
> > > > driver need to parse enough of the dt to figure out where to register
> > > > the region as a heap?
> > >
> > > My thinking was more like there would already be a reserved-memory
> > > node in DT for the chunk of memory, appropriately tagged so that it
> > > gets added as a CMA region.
> > >
> > > The device's node would have "memory-region=<&blah>;" and would use
> > > of_reserved_mem_device_init() to link up dev->cma_area to the
> > > corresponding cma region.
> > >
> > > So far, that's all in-place already. The bit that's missing is
> > > exposing that dev->cma_area to userspace as a dma_heap - so we could
> > > just have "int cma_heap_add(struct cma *cma)" or "int
> > > cma_heap_dev_add(struct device *dev)" or something exported for
> > > drivers to expose their device-assigned cma region if they wanted to.
> > >
> > > I don't think this runs into the lifetime problems of generalised
> > > heaps-as-modules either, because the CMA region will never go away
> > > even if the driver does.
> > >
> > > Alongside that, I do think the completely DT-driven approach can be
> > > useful too - because there may be regions which aren't associated with
> > > any specific device driver, that we want exported as heaps.
> >
> > And they are associated with the hardware description rather than the
> > userspace environment?
>
> I'm not sure how to answer that. We already have CMA regions being
> created from device-tree, so we're only talking about explicitly
> exposing those to userspace.
It's easier to argue that how much CMA memory a system/device needs is
h/w description as that's more a function of devices and frame sizes.
But exposing to userspace or not is an OS architecture decision. It's
not really any different than a kernel vs. userspace driver question.
What's exposed by UIO or spi-dev is purely a kernel thing.
> Are you thinking that userspace should be deciding whether they get
> exposed or not? I don't know how userspace would discover them in
> order to make that decision.
Or perhaps the kernel should be deciding. Expose to userspace what the
kernel doesn't need or drivers decide?
It's hard to argue against 1 new property. It's death by a 1000 cuts though.
Rob
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: pinctrl: qcom: Add sm8250 pinctrl bindings
From: Bjorn Andersson @ 2020-05-14 14:36 UTC (permalink / raw)
To: Linus Walleij
Cc: Rob Herring, linux-kernel@vger.kernel.org, MSM,
open list:GPIO SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <CACRpkdZpfgb0wwt2FUwqPab4XhtLXfDWOvZLdCc+NF-mVJkKYw@mail.gmail.com>
On Thu 14 May 07:12 PDT 2020, Linus Walleij wrote:
> On Thu, May 14, 2020 at 8:04 AM Bjorn Andersson
> <bjorn.andersson@linaro.org> wrote:
> > On Wed 29 Apr 14:34 PDT 2020, Rob Herring wrote:
> > > On Thu, Apr 16, 2020 at 11:19:06PM -0700, Bjorn Andersson wrote:
> > > > diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-pinctrl.yaml
> > [..]
> > > > +#PIN CONFIGURATION NODES
> > > > +patternProperties:
> > > > + '^.*$':
> > > > + if:
> > > > + type: object
> > > > + then:
> > >
> > > Needs a $ref to the standard properties.
> > >
> > > Would be good to show a child node in the example too. (And try having
> > > an error in a standard property type to verify you get an error).
> > >
> >
> > Finally looked into this.
>
> Can you send an incremental patch because otherwise I have
> to revert the patch that I merged (maybe to trigger happy, mea culpa).
>
I appreciate that you merged this already, so I'm happy to fix this
incrementally.
> (If it's too hard I can just revert it.)
>
Afaict there are two different $refs available with standard properties
and adding either one works, but I don't understand how to add both.
Also $ref'ing pincfg-node.yaml means that the binding suddenly accepts
standard properties that the hardware doesn't support, so I would like
to be able to reduce this list somehow...
But I don't see anything preventing this from being done incrementally.
Thanks,
Bjorn
^ permalink raw reply
* [PATCH v2 3/4] dt-bindings: display: ti,tfp410.txt: convert to yaml
From: Ricardo Cañuelo @ 2020-05-14 14:36 UTC (permalink / raw)
To: Laurent.pinchart
Cc: kernel, devicetree, dri-devel, linux-arm-kernel, jason,
tomi.valkeinen, robh+dt, airlied, shawnguo
In-Reply-To: <20200514143612.2094-1-ricardo.canuelo@collabora.com>
Convert the DT binding documentation for the TI TFP410 DPI-to-DVI
encoder to json-schema.
The 'ti,deskew' is now an unsigned value from 0 to 7 instead of a signed
value from -4 to 3. The rest of the binding is a direct translation from
the old one.
Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
---
.../bindings/display/bridge/ti,tfp410.txt | 66 ----------
.../bindings/display/bridge/ti,tfp410.yaml | 124 ++++++++++++++++++
2 files changed, 124 insertions(+), 66 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
deleted file mode 100644
index 5ff4f64ef8e8..000000000000
--- a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
+++ /dev/null
@@ -1,66 +0,0 @@
-TFP410 DPI to DVI encoder
-=========================
-
-Required properties:
-- compatible: "ti,tfp410"
-
-Optional properties:
-- powerdown-gpios: power-down gpio
-- reg: I2C address. If and only if present the device node should be placed
- into the I2C controller node where the TFP410 I2C is connected to.
-- ti,deskew: data de-skew in 350ps increments, from -4 to +3, as configured
- through th DK[3:1] pins. This property shall be present only if the TFP410
- is not connected through I2C.
-
-Required nodes:
-
-This device has two video ports. Their connections are modeled using the OF
-graph bindings specified in [1]. Each port node shall have a single endpoint.
-
-- Port 0 is the DPI input port. Its endpoint subnode shall contain a
- pclk-sample and bus-width property and a remote-endpoint property as specified
- in [1].
- - If pclk-sample is not defined, pclk-sample = 0 should be assumed for
- backward compatibility.
- - If bus-width is not defined then bus-width = 24 should be assumed for
- backward compatibility.
- bus-width = 24: 24 data lines are connected and single-edge mode
- bus-width = 12: 12 data lines are connected and dual-edge mode
-
-- Port 1 is the DVI output port. Its endpoint subnode shall contain a
- remote-endpoint property is specified in [1].
-
-[1] Documentation/devicetree/bindings/media/video-interfaces.txt
-
-
-Example
--------
-
-tfp410: encoder@0 {
- compatible = "ti,tfp410";
- powerdown-gpios = <&twl_gpio 2 GPIO_ACTIVE_LOW>;
- ti,deskew = <4>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
-
- tfp410_in: endpoint@0 {
- pclk-sample = <1>;
- bus-width = <24>;
- remote-endpoint = <&dpi_out>;
- };
- };
-
- port@1 {
- reg = <1>;
-
- tfp410_out: endpoint@0 {
- remote-endpoint = <&dvi_connector_in>;
- };
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml
new file mode 100644
index 000000000000..a9f4fd8ea621
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml
@@ -0,0 +1,124 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/ti,tfp410.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TFP410 DPI to DVI encoder
+
+maintainers:
+ - Tomi Valkeinen <tomi.valkeinen@ti.com>
+ - Jyri Sarha <jsarha@ti.com>
+
+properties:
+ compatible:
+ const: ti,tfp410
+
+ reg:
+ description: I2C address of the device.
+ maxItems: 1
+
+ powerdown-gpios:
+ maxItems: 1
+
+ ti,deskew:
+ description:
+ Data de-skew value in 350ps increments, from 0 to 7, as configured
+ through the DK[3:1] pins. The de-skew multiplier is computed as
+ (DK[3:1] - 4), so it ranges from -4 to 3. This property shall be
+ present only if the TFP410 is not connected through I2C.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 7
+
+ ports:
+ description:
+ A node containing input and output port nodes with endpoint
+ definitions as documented in
+ Documentation/devicetree/bindings/media/video-interfaces.txt
+ type: object
+
+ properties:
+ port@0:
+ description: DPI input port.
+ type: object
+
+ properties:
+ reg:
+ const: 0
+
+ endpoint:
+ type: object
+
+ properties:
+ pclk-sample:
+ description:
+ Endpoint sampling edge. If not defined, pclk-sample =
+ 0 should be assumed for backwards compatibility.
+ enum:
+ - 0 # Falling edge
+ - 1 # Rising edge
+ default: 0
+
+ bus-width:
+ description:
+ Endpoint bus width. If not defined, bus-width = 24
+ should be assumed for backwards compatibility.
+ enum:
+ - 12 # 12 data lines connected and dual-edge mode
+ - 24 # 24 data lines connected and single-edge mode
+ default: 24
+
+ port@1:
+ description: DVI output port.
+ type: object
+
+ properties:
+ reg:
+ const: 1
+
+ endpoint:
+ type: object
+
+ required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ tfp410: encoder {
+ compatible = "ti,tfp410";
+ powerdown-gpios = <&twl_gpio 2 GPIO_ACTIVE_LOW>;
+ ti,deskew = <3>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ tfp410_in: endpoint {
+ pclk-sample = <1>;
+ bus-width = <24>;
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ tfp410_out: endpoint {
+ remote-endpoint = <&dvi_connector_in>;
+ };
+ };
+ };
+ };
+
+...
--
2.18.0
^ permalink raw reply related
* [PATCH v2 4/4] drm/bridge: tfp410: Fix setup and hold time calculation
From: Ricardo Cañuelo @ 2020-05-14 14:36 UTC (permalink / raw)
To: Laurent.pinchart
Cc: kernel, devicetree, dri-devel, linux-arm-kernel, jason,
tomi.valkeinen, robh+dt, airlied, shawnguo
In-Reply-To: <20200514143612.2094-1-ricardo.canuelo@collabora.com>
The tfp410 has a data de-skew feature that allows the user to compensate
the skew between IDCK and the pixel data and control signals.
In the driver, the setup and hold times are calculated from the de-skew
value. This retrieves the deskew value from the DT using the proper
datatype and range check as described by the binding (u32 from 0 to 7)
and fixes the calculation of the setup and hold times.
Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
---
drivers/gpu/drm/bridge/ti-tfp410.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c b/drivers/gpu/drm/bridge/ti-tfp410.c
index e3eb6364c0f7..21d99b4ea0c9 100644
--- a/drivers/gpu/drm/bridge/ti-tfp410.c
+++ b/drivers/gpu/drm/bridge/ti-tfp410.c
@@ -220,7 +220,7 @@ static int tfp410_parse_timings(struct tfp410 *dvi, bool i2c)
struct device_node *ep;
u32 pclk_sample = 0;
u32 bus_width = 24;
- s32 deskew = 0;
+ u32 deskew = 0;
/* Start with defaults. */
*timings = tfp410_default_timings;
@@ -274,12 +274,12 @@ static int tfp410_parse_timings(struct tfp410 *dvi, bool i2c)
}
/* Get the setup and hold time from vendor-specific properties. */
- of_property_read_u32(dvi->dev->of_node, "ti,deskew", (u32 *)&deskew);
- if (deskew < -4 || deskew > 3)
+ of_property_read_u32(dvi->dev->of_node, "ti,deskew", &deskew);
+ if (deskew > 7)
return -EINVAL;
- timings->setup_time_ps = min(0, 1200 - 350 * deskew);
- timings->hold_time_ps = min(0, 1300 + 350 * deskew);
+ timings->setup_time_ps = 1200 - 350 * ((s32)deskew - 4);
+ timings->hold_time_ps = max(0, 1300 + 350 * ((s32)deskew - 4));
return 0;
}
--
2.18.0
^ permalink raw reply related
* [PATCH v2 2/4] ARM: dts: ims53: Group port definitions for the dvi-converter
From: Ricardo Cañuelo @ 2020-05-14 14:36 UTC (permalink / raw)
To: Laurent.pinchart
Cc: kernel, devicetree, dri-devel, linux-arm-kernel, jason,
tomi.valkeinen, robh+dt, airlied, shawnguo
In-Reply-To: <20200514143612.2094-1-ricardo.canuelo@collabora.com>
Group the port definitions of the dvi-converter in a 'ports' node to
make it compliant with the ti,tfp410 binding.
Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
---
arch/arm/boot/dts/imx53-cx9020.dts | 25 ++++++++++++++-----------
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/imx53-cx9020.dts b/arch/arm/boot/dts/imx53-cx9020.dts
index 0a475c234054..cfb18849a92b 100644
--- a/arch/arm/boot/dts/imx53-cx9020.dts
+++ b/arch/arm/boot/dts/imx53-cx9020.dts
@@ -59,23 +59,26 @@
};
dvi-converter {
- #address-cells = <1>;
- #size-cells = <0>;
compatible = "ti,tfp410";
- port@0 {
- reg = <0>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
- tfp410_in: endpoint {
- remote-endpoint = <&display0_out>;
+ tfp410_in: endpoint {
+ remote-endpoint = <&display0_out>;
+ };
};
- };
- port@1 {
- reg = <1>;
+ port@1 {
+ reg = <1>;
- tfp410_out: endpoint {
- remote-endpoint = <&dvi_connector_in>;
+ tfp410_out: endpoint {
+ remote-endpoint = <&dvi_connector_in>;
+ };
};
};
};
--
2.18.0
^ permalink raw reply related
* [PATCH v2 1/4] ARM: dts: dove: Make the DT compliant with the ti,tfp410 binding
From: Ricardo Cañuelo @ 2020-05-14 14:36 UTC (permalink / raw)
To: Laurent.pinchart
Cc: kernel, devicetree, dri-devel, linux-arm-kernel, jason,
tomi.valkeinen, robh+dt, airlied, shawnguo
In-Reply-To: <20200514143612.2094-1-ricardo.canuelo@collabora.com>
Define a 'ports' node for 'dvi: video@39' and use the proper naming for
the powerdown-gpios property to make it compliant with the ti,tfp410
binding.
This fills the minimum requirements to meet the binding requirements,
port endpoints are not defined.
Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
---
arch/arm/boot/dts/dove-sbc-a510.dts | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/dove-sbc-a510.dts b/arch/arm/boot/dts/dove-sbc-a510.dts
index 2bb85a9b7614..32804c981625 100644
--- a/arch/arm/boot/dts/dove-sbc-a510.dts
+++ b/arch/arm/boot/dts/dove-sbc-a510.dts
@@ -132,7 +132,18 @@
dvi: video@39 {
compatible = "ti,tfp410";
reg = <0x39>;
- powerdown-gpio = <&gpio_ext 3 GPIO_ACTIVE_LOW>;
+ powerdown-gpios = <&gpio_ext 3 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ };
+ port@1 {
+ reg = <1>;
+ };
+ };
};
};
--
2.18.0
^ permalink raw reply related
* [PATCH v2 0/4] dt-bindings: display: ti,tfp410.txt: convert to yaml
From: Ricardo Cañuelo @ 2020-05-14 14:36 UTC (permalink / raw)
To: Laurent.pinchart
Cc: kernel, devicetree, dri-devel, linux-arm-kernel, jason,
tomi.valkeinen, robh+dt, airlied, shawnguo
This series converts the DT binding documentation for the TI TFP410
DPI-to-DVI encoder to json-schema.
Some minor changes were made to two DTs in order to make them compliant
with the binding. These changes shouldn't have any functional effect.
This also fixes a minor bug in the ti-tfp410 driver that would cause a
wrong calculation of the setup and hold times when the de-skew feature
is enabled. The retrieval of the de-skew value from the DT has also been
updated to reflect the binding changes.
Changes in v2:
- ti,tfp410.yaml
- Set license as GPL-2.0-only (Sam Ravnborg)
- Complete pclk-sample and bus-width comments (Sam)
- Remove quotes from compatible value (Sam)
- Remove the allOf keyword from the ti,deskew definition (Sam)
- Set endpoint as optional in port definitions
- Set a range for ti,deskew
DTs fixes (added):
- dove-sbc-a510.dts: s/powerdown-gpio/powerdown-gpios (Sam)
- dove-sbc-a510.dts: Add dummy ports node
- imx53-cx9020.dts: Group the ports in a ports node
ti-tfp410.c (added):
- Fix setup time and hold time calculation based on the deskew value
(Laurent Pinchart)
Ricardo Cañuelo (4):
ARM: dts: dove: Make the DT compliant with the ti,tfp410 binding
ARM: dts: ims53: Group port definitions for the dvi-converter
dt-bindings: display: ti,tfp410.txt: convert to yaml
drm/bridge: tfp410: Fix setup and hold time calculation
.../bindings/display/bridge/ti,tfp410.txt | 66 ----------
.../bindings/display/bridge/ti,tfp410.yaml | 124 ++++++++++++++++++
arch/arm/boot/dts/dove-sbc-a510.dts | 13 +-
arch/arm/boot/dts/imx53-cx9020.dts | 25 ++--
drivers/gpu/drm/bridge/ti-tfp410.c | 10 +-
5 files changed, 155 insertions(+), 83 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml
--
2.18.0
^ permalink raw reply
* Re: [PATCH 11/17] spi: dw: Fix native CS being unset
From: Mark Brown @ 2020-05-14 14:35 UTC (permalink / raw)
To: Serge Semin
Cc: Linus Walleij, Serge Semin, Gregory Clement, Charles Keepax,
Georgy Vlasov, Ramil Zaripov, Alexey Malahov, Thomas Bogendoerfer,
Paul Burton, Ralf Baechle, Arnd Bergmann, Allison Randal,
Andy Shevchenko, Gareth Williams, Rob Herring, linux-mips,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Phil Edworthy, Thomas Gleixner, Alexios Zavras, Thor Thayer,
wuxu.wu, Xinwei Kong, Jarkko Nikula, linux-spi,
linux-kernel@vger.kernel.org
In-Reply-To: <20200514115558.e6cqnuxqyqkysfn7@mobilestation>
[-- Attachment #1: Type: text/plain, Size: 1354 bytes --]
On Thu, May 14, 2020 at 02:55:58PM +0300, Serge Semin wrote:
> On Thu, May 14, 2020 at 10:31:13AM +0200, Linus Walleij wrote:
> > We had some related discussion what to do with this case
> > when a controller can support active high CS if and only if
> > it is using a GPIO instead of the native CS. We didn't really
> > figure it out, I suppose ideally we should use two flags in the
> > master but that exercise is for another day.
> Even though it might be painful, but as I see it the best way to generically fix
> this problem would be to change the controller->set_cs() callback
> semantics. SPI core should pass a CS activation flag to the set_cs()
> callback instead of the CS pin logical level (just propagate the enable argument
> passed to the spi_set_cs() SPI core method). So if an SPI controller supports
> the Active-high native CS, during the set_cs() callback invocation it would
> analyze the spi_device flags state to figure out whether the slave needs the
The idea with set_cs() is to support controllers that allow the chip
select to be directly managed. If the controller is interpreting or
automatically managing chip select at all then set_cs() is not likely to
be a good fit, if the controller does support unfiltered management then
anything else is going to result in there being a bunch of duplicate
code between drivers.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 484 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4] arm64: dts: qcom: sm8250: Drop tcsr_mutex syscon
From: Vinod Koul @ 2020-05-14 14:19 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Andy Gross, Ohad Ben-Cohen, Baolin Wang, Rob Herring,
linux-arm-msm, linux-remoteproc, devicetree, linux-kernel
In-Reply-To: <20200513005441.1102586-5-bjorn.andersson@linaro.org>
On 12-05-20, 17:54, Bjorn Andersson wrote:
> Now that we don't need the intermediate syscon to represent the TCSR
> mutexes, update the dts to describe the TCSR mutex directly.
Reviewed-by: Vinod Koul <vkoul@kernel.org>
--
~Vinod
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: hwlock: qcom: Allow device on mmio bus
From: Vinod Koul @ 2020-05-14 14:19 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Andy Gross, Ohad Ben-Cohen, Baolin Wang, Rob Herring,
linux-arm-msm, linux-remoteproc, devicetree, linux-kernel
In-Reply-To: <20200513005441.1102586-3-bjorn.andersson@linaro.org>
On 12-05-20, 17:54, Bjorn Andersson wrote:
> In all modern Qualcomm platforms the mutex region of the TCSR is forked
> off into its own block, all with a offset of 0 and stride of 4096.
> Update the binding to allow the hardware block to be described directly
> on the mmio bus, in addition to allowing the existing syscon based
> definition.
Reviewed-by: Vinod Koul <vkoul@kernel.org>
--
~Vinod
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: hwlock: qcom: Migrate binding to YAML
From: Vinod Koul @ 2020-05-14 14:19 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Andy Gross, Ohad Ben-Cohen, Baolin Wang, Rob Herring,
linux-arm-msm, linux-remoteproc, devicetree, linux-kernel
In-Reply-To: <20200513005441.1102586-2-bjorn.andersson@linaro.org>
On 12-05-20, 17:54, Bjorn Andersson wrote:
> Migrate the Qualcomm TCSR mutex binding to YAML to allow validation.
Reviewed-by: Vinod Koul <vkoul@kernel.org>
--
~Vinod
^ permalink raw reply
* Re: [PATCH 3/4] hwspinlock: qcom: Allow mmio usage in addition to syscon
From: Vinod Koul @ 2020-05-14 14:15 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Andy Gross, Ohad Ben-Cohen, Baolin Wang, Rob Herring,
linux-arm-msm, linux-remoteproc, devicetree, linux-kernel
In-Reply-To: <20200513005441.1102586-4-bjorn.andersson@linaro.org>
On 12-05-20, 17:54, Bjorn Andersson wrote:
> In all modern Qualcomm platforms the mutex region of the TCSR is forked
> off into its own block, all with a offset of 0 and stride of 4096. So
> add support for directly memory mapping this register space, to avoid
> the need to represent this block using a syscon.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
> drivers/hwspinlock/qcom_hwspinlock.c | 72 +++++++++++++++++++++-------
> 1 file changed, 56 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/hwspinlock/qcom_hwspinlock.c b/drivers/hwspinlock/qcom_hwspinlock.c
> index f0da544b14d2..d8d4d729816c 100644
> --- a/drivers/hwspinlock/qcom_hwspinlock.c
> +++ b/drivers/hwspinlock/qcom_hwspinlock.c
> @@ -70,41 +70,81 @@ static const struct of_device_id qcom_hwspinlock_of_match[] = {
> };
> MODULE_DEVICE_TABLE(of, qcom_hwspinlock_of_match);
>
> -static int qcom_hwspinlock_probe(struct platform_device *pdev)
> +static struct regmap *qcom_hwspinlock_probe_syscon(struct platform_device *pdev,
> + u32 *base, u32 *stride)
> {
> - struct hwspinlock_device *bank;
> struct device_node *syscon;
> - struct reg_field field;
> struct regmap *regmap;
> - size_t array_size;
> - u32 stride;
> - u32 base;
> int ret;
> - int i;
>
> syscon = of_parse_phandle(pdev->dev.of_node, "syscon", 0);
> - if (!syscon) {
> - dev_err(&pdev->dev, "no syscon property\n");
any reason to drop the log?
> - return -ENODEV;
> - }
> + if (!syscon)
> + return ERR_PTR(-ENODEV);
>
> regmap = syscon_node_to_regmap(syscon);
> of_node_put(syscon);
> if (IS_ERR(regmap))
> - return PTR_ERR(regmap);
> + return regmap;
>
> - ret = of_property_read_u32_index(pdev->dev.of_node, "syscon", 1, &base);
> + ret = of_property_read_u32_index(pdev->dev.of_node, "syscon", 1, base);
> if (ret < 0) {
> dev_err(&pdev->dev, "no offset in syscon\n");
> - return -EINVAL;
> + return ERR_PTR(-EINVAL);
> }
>
> - ret = of_property_read_u32_index(pdev->dev.of_node, "syscon", 2, &stride);
> + ret = of_property_read_u32_index(pdev->dev.of_node, "syscon", 2, stride);
> if (ret < 0) {
> dev_err(&pdev->dev, "no stride syscon\n");
> - return -EINVAL;
> + return ERR_PTR(-EINVAL);
> }
>
> + return regmap;
> +}
> +
> +static const struct regmap_config tcsr_mutex_config = {
> + .reg_bits = 32,
> + .reg_stride = 4,
> + .val_bits = 32,
> + .max_register = 0x40000,
> + .fast_io = true,
> +};
> +
> +static struct regmap *qcom_hwspinlock_probe_mmio(struct platform_device *pdev,
> + u32 *offset, u32 *stride)
> +{
> + struct device *dev = &pdev->dev;
> + struct resource *res;
> + void __iomem *base;
> +
> + /* All modern platform has offset 0 and stride of 4k */
> + *offset = 0;
> + *stride = 0x1000;
Wouldn't it make sense to read this from DT rather than code in kernel?
--
~Vinod
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: pinctrl: qcom: Add sm8250 pinctrl bindings
From: Linus Walleij @ 2020-05-14 14:12 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Rob Herring, linux-kernel@vger.kernel.org, MSM,
open list:GPIO SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <20200514060422.GL1302550@yoga>
On Thu, May 14, 2020 at 8:04 AM Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
> On Wed 29 Apr 14:34 PDT 2020, Rob Herring wrote:
> > On Thu, Apr 16, 2020 at 11:19:06PM -0700, Bjorn Andersson wrote:
> > > diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-pinctrl.yaml
> [..]
> > > +#PIN CONFIGURATION NODES
> > > +patternProperties:
> > > + '^.*$':
> > > + if:
> > > + type: object
> > > + then:
> >
> > Needs a $ref to the standard properties.
> >
> > Would be good to show a child node in the example too. (And try having
> > an error in a standard property type to verify you get an error).
> >
>
> Finally looked into this.
Can you send an incremental patch because otherwise I have
to revert the patch that I merged (maybe to trigger happy, mea culpa).
(If it's too hard I can just revert it.)
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v7 3/6] clocksource: Ingenic: Add high resolution timer support for SMP.
From: kbuild test robot @ 2020-05-14 14:10 UTC (permalink / raw)
To: 周琰杰 (Zhou Yanjie), linux-mips
Cc: kbuild-all, linux-kernel, devicetree, tsbogend, paulburton,
jiaxun.yang, chenhc, tglx, robh+dt, daniel.lezcano
In-Reply-To: <1589395578-87441-5-git-send-email-zhouyanjie@wanyeetech.com>
[-- Attachment #1: Type: text/plain, Size: 4424 bytes --]
Hi "周琰杰,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on robh/for-next]
[also build test WARNING on tip/timers/core linus/master v5.7-rc5]
[cannot apply to linux/master next-20200512]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Zhou-Yanjie/Introduce-SMP-support-for-CI20-based-on-JZ4780/20200514-171836
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Ubuntu 7.5.0-6ubuntu2) 7.5.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
All warnings (new ones prefixed by >>, old ones prefixed by <<):
In file included from include/linux/bitops.h:5:0,
from drivers/clocksource/ingenic-timer.c:8:
drivers/clocksource/ingenic-timer.c: In function 'ingenic_tcu_init':
>> include/linux/bits.h:36:22: warning: left shift count >= width of type [-Wshift-count-overflow]
(((~UL(0)) - (UL(1) << (l)) + 1) & ^
>> include/linux/bits.h:39:31: note: in expansion of macro '__GENMASK'
(GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l))
^~~~~~~~~
>> drivers/clocksource/ingenic-timer.c:313:27: note: in expansion of macro 'GENMASK'
tcu->pwm_channels_mask = GENMASK(soc_info->num_channels - 1,
^~~~~~~
vim +/GENMASK +313 drivers/clocksource/ingenic-timer.c
288
289 static int __init ingenic_tcu_init(struct device_node *np)
290 {
291 const struct of_device_id *id = of_match_node(ingenic_tcu_of_match, np);
292 const struct ingenic_soc_info *soc_info = id->data;
293 struct ingenic_tcu *tcu;
294 struct regmap *map;
295 unsigned cpu = 0;
296 long rate;
297 int ret;
298
299 of_node_clear_flag(np, OF_POPULATED);
300
301 map = device_node_to_regmap(np);
302 if (IS_ERR(map))
303 return PTR_ERR(map);
304
305 tcu = kzalloc(sizeof(*tcu), GFP_KERNEL);
306 if (!tcu)
307 return -ENOMEM;
308
309 /*
310 * Enable all TCU channels for PWM use by default except channels 0/1,
311 * and channel 2 if target CPU is JZ4780 and SMP is selected.
312 */
> 313 tcu->pwm_channels_mask = GENMASK(soc_info->num_channels - 1,
314 NR_CPUS + 1);
315 of_property_read_u32(np, "ingenic,pwm-channels-mask",
316 (u32 *)&tcu->pwm_channels_mask);
317
318 /* Verify that we have at least NR_CPUS + 1 free channels */
319 if (hweight8(tcu->pwm_channels_mask) >
320 soc_info->num_channels - NR_CPUS + 1) {
321 pr_crit("%s: Invalid PWM channel mask: 0x%02lx\n", __func__,
322 tcu->pwm_channels_mask);
323 ret = -EINVAL;
324 goto err_free_ingenic_tcu;
325 }
326
327 tcu->map = map;
328 tcu->np = np;
329 ingenic_tcu = tcu;
330
331 tcu->timer_local[cpu] = find_first_zero_bit(&tcu->pwm_channels_mask,
332 soc_info->num_channels);
333
334 for (cpu = 1; cpu < NR_CPUS; cpu++)
335 tcu->timer_local[cpu] = find_next_zero_bit(
336 &tcu->pwm_channels_mask, soc_info->num_channels,
337 tcu->timer_local[cpu - 1] + 1);
338
339 tcu->cs_channel = find_next_zero_bit(&tcu->pwm_channels_mask,
340 soc_info->num_channels, tcu->timer_local[cpu - 1] + 1);
341
342 ret = ingenic_tcu_clocksource_init(np, tcu);
343 if (ret) {
344 pr_crit("%s: Unable to init clocksource: %d\n", __func__, ret);
345 goto err_free_ingenic_tcu;
346 }
347
348 /* Setup clock events on each CPU core */
349 ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "Ingenic XBurst: online",
350 ingenic_tcu_setup_cevt, NULL);
351 WARN_ON(ret < 0);
352
353 /* Register the sched_clock at the end as there's no way to undo it */
354 rate = clk_get_rate(tcu->cs_clk);
355 sched_clock_register(ingenic_tcu_timer_read, 16, rate);
356
357 return 0;
358
359 err_free_ingenic_tcu:
360 kfree(tcu);
361 return ret;
362 }
363
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 72336 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/3] ARM: dts: stm32: enable l3gd20 on stm32429-disco board
From: Alexandre Torgue @ 2020-05-14 14:09 UTC (permalink / raw)
To: dillon.minfei, robh+dt, mcoquelin.stm32, broonie, p.zabel
Cc: devicetree, linux-arm-kernel, linux-kernel, linux-spi,
linux-stm32, dillonhua
In-Reply-To: <1589269010-18472-3-git-send-email-dillon.minfei@gmail.com>
Hi Dillon
On 5/12/20 9:36 AM, dillon.minfei@gmail.com wrote:
> From: dillon min <dillon.minfei@gmail.com>
>
> L3gd20, st mems motion sensor, 3-axis digital output gyroscope,
> connect to stm32f429 via spi5
>
> Signed-off-by: dillon min <dillon.minfei@gmail.com>
> ---
>
> Hi Alexandre,
>
> V2:
> 1, insert blank line at stm32f420-disco.dts line 143
> 2, add more description about l3gd20 in commit message
>
> V1:
> enable l3gd20 dts binding on stm32f429-disco
>
> thanks.
>
> dillon,
>
> arch/arm/boot/dts/stm32f429-disco.dts | 25 +++++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32f429-disco.dts b/arch/arm/boot/dts/stm32f429-disco.dts
> index 30c0f67..1bfb903 100644
> --- a/arch/arm/boot/dts/stm32f429-disco.dts
> +++ b/arch/arm/boot/dts/stm32f429-disco.dts
> @@ -49,6 +49,8 @@
> #include "stm32f429.dtsi"
> #include "stm32f429-pinctrl.dtsi"
> #include <dt-bindings/input/input.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/gpio/gpio.h>
>
> / {
> model = "STMicroelectronics STM32F429i-DISCO board";
> @@ -127,3 +129,26 @@
> pinctrl-names = "default";
> status = "okay";
> };
> +
> +&spi5 {
> + status = "okay";
> + pinctrl-0 = <&spi5_pins>;
> + pinctrl-names = "default";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cs-gpios = <&gpioc 1 GPIO_ACTIVE_LOW>;
> + dmas = <&dma2 3 2 0x400 0x0>,
> + <&dma2 4 2 0x400 0x0>;
> + dma-names = "rx", "tx";
> +
You added this spi5 node in this patch but also in the display series. I
will have issue to merge. Even if I could fix it easily, as you are
going to resend, the good practice could be to have several patches in
one series: one patch for spi5 controller, another for gyro and another
for display.
And also same remark than Linus did in display series move DMA to soc
dtsi file please.
> + l3gd20: l3gd20@0 {
> + compatible = "st,l3gd20-gyro";
> + spi-max-frequency = <10000000>;
> + st,drdy-int-pin = <2>;
> + interrupt-parent = <&gpioa>;
> + interrupts = <1 IRQ_TYPE_EDGE_RISING>,
> + <2 IRQ_TYPE_EDGE_RISING>;
> + reg = <0>;
> + status = "okay";
> + };
> +};
>
^ permalink raw reply
* Re: [PATCH v3 5/5] drm/panel: Add ilitek ili9341 driver
From: Linus Walleij @ 2020-05-14 14:07 UTC (permalink / raw)
To: dillon min
Cc: Rob Herring, Maxime Coquelin, Alexandre TORGUE,
thierry.reding@gmail.com, Sam Ravnborg, Dave Airlie,
Daniel Vetter, Michael Turquette, Stephen Boyd,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-stm32, Linux ARM, linux-kernel@vger.kernel.org,
open list:DRM PANEL DRIVERS, linux-clk
In-Reply-To: <CAL9mu0LVsePqifEC+-FR+NxvuZT3UGpU86KhzaTqb7w_Px0z2g@mail.gmail.com>
On Thu, May 14, 2020 at 12:22 PM dillon min <dillon.minfei@gmail.com> wrote:
> > > + /* Gamma */
> > > + mipi_dbi_command(dbi, ILI9341_3GAMMA_EN, 0x00);
> > > + mipi_dbi_command(dbi, MIPI_DCS_SET_GAMMA_CURVE, 0x01);
> > > + mipi_dbi_command(dbi, ILI9341_PGAMMA,
> > > + 0x0f, 0x31, 0x2b, 0x0c, 0x0e, 0x08, 0x4e, 0xf1,
> > > + 0x37, 0x07, 0x10, 0x03, 0x0e, 0x09, 0x00);
> > > + mipi_dbi_command(dbi, ILI9341_NGAMMA,
> > > + 0x00, 0x0e, 0x14, 0x03, 0x11, 0x07, 0x31, 0xc1,
> > > + 0x48, 0x08, 0x0f, 0x0c, 0x31, 0x36, 0x0f);
> >
> > It seems to be copies of the stuff above, but why is there a different
> > gamma if you use DBI?
> for dbi interface, currently i just copy the code from tiny/ili9341.c.
> as so many boards use this driver now, like raspberry pi, etc
> i'm afraid it's will not work after modification. so, just leave the
> original code there.
OK if you move it to ili9341_config it will be clear which panels
need this gamma and which panels need another gamma.
I think there should be one ili9341_config for the new st,*
variant and one for the old DBI variant.
> anther question:
> is there any panel driver have dbi & dpi or dpi & dsi supported? which
> i mean support
> two different panel interface in one driver.
> thanks
Usually you split the driver in three files becuase a driver can
only list one initcall, and also it makes it modularized.
There is nothing in-tree but look at my branch here:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git/log/?h=ux500-skomer-v5.7-rc1
You see how I split up the s6e63m0 driver in one SPI part
and one DSI part:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git/commit/?h=ux500-skomer-v5.7-rc1&id=6c0e1fb5df5fa8fa857dee65f6c0f54d06d158a7
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git/commit/?h=ux500-skomer-v5.7-rc1&id=cfbf562cc709b53b62f5fbc7fedf176ffa17b088
The overall idea should work the same with DBI.
Yours,
Linus Walleij
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: c630: Add WiFi node
From: Robert Foss @ 2020-05-14 14:06 UTC (permalink / raw)
To: bjorn.andersson
Cc: agross, devicetree, linux-arm-msm, linux-kernel, mark.rutland,
robh+dt, Robert Foss
In-Reply-To: <20191018055841.3729591-1-bjorn.andersson@linaro.org>
> Specify regulators and enable the &wifi node. The firmware uses the 8
> bit version of the host capability message, so specify this quirk.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Robert Foss <robert.foss@linaro.org>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: db820c: fix audio configuration
From: Bjorn Andersson @ 2020-05-14 13:56 UTC (permalink / raw)
To: Vinod Koul
Cc: Srinivas Kandagatla, agross, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20200514134353.GT14092@vkoul-mobl>
On Thu 14 May 06:43 PDT 2020, Vinod Koul wrote:
> On 17-04-20, 10:23, Srinivas Kandagatla wrote:
> > After patch f864edff110d ("ASoC: qdsp6: q6routing: remove default routing")
> > and 9b60441692d9 ("ASoC: qdsp6: q6asm-dai: only enable dais from device tree")
> > asm dais and routing needs to be properly specified at device tree level.
> >
> > This patch fixes this.
>
> Can we add the Fixes tag here please?
>
Yes, I added that and picked this patch for 5.7-rc and sent out a pull
request. Unfortunately this does not seem to have been picked up yet.
> Other than that lgtm:
>
> Reviewed-by: Vinod Koul <vkoul@kernel.org>
Thanks
Regards,
Bjorn
> > Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> > ---
> > arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 22 +++++++++++++++++++-
> > arch/arm64/boot/dts/qcom/msm8996.dtsi | 2 ++
> > 2 files changed, 23 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
> > index 4692b7ad16b7..cf217b6b2b39 100644
> > --- a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
> > @@ -908,10 +908,30 @@
> > status = "okay";
> > };
> >
> > +&q6asmdai {
> > + dai@0 {
> > + reg = <0>;
> > + direction = <2>;
> > + };
> > +
> > + dai@1 {
> > + reg = <1>;
> > + direction = <2>;
> > + };
> > +
> > + dai@2 {
> > + reg = <2>;
> > + direction = <1>;
> > + };
> > +};
> > +
> > &sound {
> > compatible = "qcom,apq8096-sndcard";
> > model = "DB820c";
> > - audio-routing = "RX_BIAS", "MCLK";
> > + audio-routing = "RX_BIAS", "MCLK",
> > + "MM_DL1", "MultiMedia1 Playback",
> > + "MM_DL2", "MultiMedia2 Playback",
> > + "MultiMedia3 Capture", "MM_UL3";
> >
> > mm1-dai-link {
> > link-name = "MultiMedia1";
> > diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> > index 14827adebd94..98634d5c4440 100644
> > --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> > @@ -2066,6 +2066,8 @@
> > reg = <APR_SVC_ASM>;
> > q6asmdai: dais {
> > compatible = "qcom,q6asm-dais";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > #sound-dai-cells = <1>;
> > iommus = <&lpass_q6_smmu 1>;
> > };
> > --
> > 2.21.0
>
> --
> ~Vinod
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: c630: Specify UFS device reset
From: Robert Foss @ 2020-05-14 13:56 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Andy Gross, Rob Herring, linux-arm-msm,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-kernel
In-Reply-To: <20200406060049.227029-1-bjorn.andersson@linaro.org>
On Mon, 6 Apr 2020 at 08:03, Bjorn Andersson <bjorn.andersson@linaro.org> wrote:
>
> On some device the reset line for the UFS memory needs to be tickled in
> order for UFS to initialize properly, add this to the ufs_mem_hc node.
>
Reviewed-by: Robert Foss <robert.foss@linaro.org>
^ permalink raw reply
* Re: [PATCH v9 2/4] media: i2c: Add MAX9286 driver
From: Kieran Bingham @ 2020-05-14 13:50 UTC (permalink / raw)
To: Manivannan Sadhasivam, Geert Uytterhoeven
Cc: Linux-Renesas, Linux Media Mailing List,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Mauro Carvalho Chehab, Kieran Bingham,
Laurent Pinchart, Jacopo Mondi, Niklas Söderlund,
Sakari Ailus, Hans Verkuil, Hyun Kwon, Rob Herring, Jacopo Mondi,
Laurent Pinchart, Niklas Söderlund
In-Reply-To: <20200514124831.GG2877@Mani-XPS-13-9360>
On 14/05/2020 13:48, Manivannan Sadhasivam wrote:
> On Thu, May 14, 2020 at 01:59:35PM +0200, Geert Uytterhoeven wrote:
>> Hi Kieran,
>>
>> On Thu, May 14, 2020 at 1:47 PM Kieran Bingham
>> <kieran.bingham+renesas@ideasonboard.com> wrote:
>>> On 14/05/2020 11:13, Manivannan Sadhasivam wrote:
>>>> On Thu, May 14, 2020 at 11:02:53AM +0100, Kieran Bingham wrote:
>>>>> On 12/05/2020 19:17, Manivannan Sadhasivam wrote:
>>>>>> On Tue, May 12, 2020 at 04:51:03PM +0100, Kieran Bingham wrote:
>>>>>>> The MAX9286 is a 4-channel GMSL deserializer with coax or STP input and
>>>>>>> CSI-2 output. The device supports multicamera streaming applications,
>>>>>>> and features the ability to synchronise the attached cameras.
>>>>>>>
>>>>>>> CSI-2 output can be configured with 1 to 4 lanes, and a control channel
>>>>>>> is supported over I2C, which implements an I2C mux to facilitate
>>>>>>> communications with connected cameras across the reverse control
>>>>>>> channel.
>>>>>>>
>>>>>>> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>>>>>>> Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
>>>>>>> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
>>>>>>> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
>>
>>>>>>> --- /dev/null
>>>>>>> +++ b/drivers/media/i2c/max9286.c
>>
>>>>>>> +static int max9286_register_gpio(struct max9286_priv *priv)
>>>>>>> +{
>>>>>>> + struct device *dev = &priv->client->dev;
>>>>>>> + struct gpio_chip *gpio = &priv->gpio;
>>>>>>> + int ret;
>>>>>>> +
>>>>>>> + static const char * const names[] = {
>>>>>>> + "GPIO0OUT",
>>>>>>> + "GPIO1OUT",
>>>>>>> + };
>>>>>>> +
>>>>>>> + /* Configure the GPIO */
>>>>>>> + gpio->label = dev_name(dev);
>>>>>>
>>>>>> So if you have more than one MAX9286 in a system, all gpiochips will appear
>>>>>> with the same name. I'd recommend to append the index to distinguish properly.
>>>>>
>>>>> Ah yes, that's a good point, and I think I've even seen that.
>>>>>
>>>>> I'll fix it now.
>>>
>>> Oh, in fact actually this doesn't.
>>>
>>> gpiodetect prints:
>>>
>>> gpiochip10 [4-004c] (2 lines)
>>> gpiochip11 [4-006c] (2 lines)
>>>
>>> and mostly references them as gpiochip10 and gpiochip11.
>>
>> Indeed, dev_name() should be different for each instance.
>>
>
> Ah, my bad! Somehow I got confused that this delivers static name... Sorry for
> the noise, Kieran.
>
>>> However,
>>>
>>>> [ 2.318533] gpio gpiochip11: Detected name collision for GPIO name 'GPIO0OUT'
>>>> [ 2.325739] gpio gpiochip11: Detected name collision for GPIO name 'GPIO1OUT'
>>>
>>> That seems to be more of a problem for the gpio library, so I think I'll
>>> just drop the const names. I don't think they add much value.
>>
>
> Well, I should've pointed this instead of above...
>
> (lack of coffee)
>
>> These are the line names. If they're not unique, a warning is printed,
>> but they are still registered.
>> So probably you want to use kasprintf("%s.%s", dev_name(dev), names[i]) to
>> generate names.
>>
>
> Ack.
>
> I think you should CC Linus W for next iteration to get review for gpiolib
> implementation.
Good idea. I think I'll drop the names though for now.
--
Kieran
>
> Thanks,
> Mani
>
>> See "[PATCH] gpiolib: Document that GPIO line names are not globally unique"
>> (https://lore.kernel.org/linux-gpio/20200511101828.30046-1-geert+renesas@glider.be/)
>> to clear up the details.
>>
>> Gr{oetje,eeting}s,
>>
>> Geert
>>
>> --
>> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>>
>> In personal conversations with technical people, I call myself a hacker. But
>> when I'm talking to journalists I just say "programmer" or something like that.
>> -- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 2/2] remoteproc: qcom: pas: Add SM8250 PAS remoteprocs
From: Vinod Koul @ 2020-05-14 13:45 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Ohad Ben-Cohen, Rob Herring, linux-arm-msm, linux-remoteproc,
devicetree, linux-kernel, Sibi Sankar
In-Reply-To: <20200430180051.3795305-2-bjorn.andersson@linaro.org>
On 30-04-20, 11:00, Bjorn Andersson wrote:
> Add audio, compute and sensor DSP compatibles to the Qualcomm PAS
> binding and driver.
Reviewed-by: Vinod Koul <vkoul@kernel.org>
--
~Vinod
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: remoteproc: qcom: pas: Add SM8250 remoteprocs
From: Vinod Koul @ 2020-05-14 13:45 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Ohad Ben-Cohen, Rob Herring, linux-arm-msm, linux-remoteproc,
devicetree, linux-kernel, Sibi Sankar
In-Reply-To: <20200430180051.3795305-1-bjorn.andersson@linaro.org>
On 30-04-20, 11:00, Bjorn Andersson wrote:
> Add the SM8250 audio, compute and sensor remoteprocs to the PAS DT
> binding.
Reviewed-by: Vinod Koul <vkoul@kernel.org>
>
> Reviewed-by: Sibi Sankar <sibis@codeaurora.org>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
>
> Changes since v1:
> - Changed adsp power-domains to lcx and added missing lmx
>
> .../devicetree/bindings/remoteproc/qcom,adsp.txt | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
> index 9938918b2fea..c18c1b8d2869 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
> @@ -21,6 +21,9 @@ on the Qualcomm ADSP Hexagon core.
> "qcom,sm8150-cdsp-pas"
> "qcom,sm8150-mpss-pas"
> "qcom,sm8150-slpi-pas"
> + "qcom,sm8250-adsp-pas"
> + "qcom,sm8250-cdsp-pas"
> + "qcom,sm8250-slpi-pas"
>
> - interrupts-extended:
> Usage: required
> @@ -44,6 +47,9 @@ on the Qualcomm ADSP Hexagon core.
> qcom,sm8150-adsp-pas:
> qcom,sm8150-cdsp-pas:
> qcom,sm8150-slpi-pas:
> + qcom,sm8250-adsp-pas:
> + qcom,sm8250-cdsp-pas:
> + qcom,sm8250-slpi-pas:
> must be "wdog", "fatal", "ready", "handover", "stop-ack"
> qcom,qcs404-wcss-pas:
> qcom,sm8150-mpss-pas:
> @@ -105,10 +111,13 @@ on the Qualcomm ADSP Hexagon core.
> qcom,sdm845-cdsp-pas:
> qcom,sm8150-adsp-pas:
> qcom,sm8150-cdsp-pas:
> + qcom,sm8250-cdsp-pas:
> must be "cx", "load_state"
> qcom,sm8150-mpss-pas:
> must be "cx", "load_state", "mss"
> + qcom,sm8250-adsp-pas:
> qcom,sm8150-slpi-pas:
> + qcom,sm8250-slpi-pas:
> must be "lcx", "lmx", "load_state"
>
> - memory-region:
> --
> 2.24.0
--
~Vinod
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: db820c: fix audio configuration
From: Vinod Koul @ 2020-05-14 13:43 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: bjorn.andersson, agross, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20200417092327.7341-1-srinivas.kandagatla@linaro.org>
On 17-04-20, 10:23, Srinivas Kandagatla wrote:
> After patch f864edff110d ("ASoC: qdsp6: q6routing: remove default routing")
> and 9b60441692d9 ("ASoC: qdsp6: q6asm-dai: only enable dais from device tree")
> asm dais and routing needs to be properly specified at device tree level.
>
> This patch fixes this.
Can we add the Fixes tag here please?
Other than that lgtm:
Reviewed-by: Vinod Koul <vkoul@kernel.org>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
> arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 22 +++++++++++++++++++-
> arch/arm64/boot/dts/qcom/msm8996.dtsi | 2 ++
> 2 files changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
> index 4692b7ad16b7..cf217b6b2b39 100644
> --- a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
> +++ b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
> @@ -908,10 +908,30 @@
> status = "okay";
> };
>
> +&q6asmdai {
> + dai@0 {
> + reg = <0>;
> + direction = <2>;
> + };
> +
> + dai@1 {
> + reg = <1>;
> + direction = <2>;
> + };
> +
> + dai@2 {
> + reg = <2>;
> + direction = <1>;
> + };
> +};
> +
> &sound {
> compatible = "qcom,apq8096-sndcard";
> model = "DB820c";
> - audio-routing = "RX_BIAS", "MCLK";
> + audio-routing = "RX_BIAS", "MCLK",
> + "MM_DL1", "MultiMedia1 Playback",
> + "MM_DL2", "MultiMedia2 Playback",
> + "MultiMedia3 Capture", "MM_UL3";
>
> mm1-dai-link {
> link-name = "MultiMedia1";
> diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> index 14827adebd94..98634d5c4440 100644
> --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> @@ -2066,6 +2066,8 @@
> reg = <APR_SVC_ASM>;
> q6asmdai: dais {
> compatible = "qcom,q6asm-dais";
> + #address-cells = <1>;
> + #size-cells = <0>;
> #sound-dai-cells = <1>;
> iommus = <&lpass_q6_smmu 1>;
> };
> --
> 2.21.0
--
~Vinod
^ permalink raw reply
* Re: [PATCH 00/15] Fix STM32 DT issues on v5.7-rc4
From: Alexandre Torgue @ 2020-05-14 13:42 UTC (permalink / raw)
To: Benjamin Gaignard, linus.walleij, robh+dt, mcoquelin.stm32,
gregkh
Cc: linux-gpio, devicetree, linux-stm32, linux-arm-kernel,
linux-kernel, linux-usb
In-Reply-To: <20200513145935.22493-1-benjamin.gaignard@st.com>
Hi Benjamin
On 5/13/20 4:59 PM, Benjamin Gaignard wrote:
> This series fixes issues hight lighted by dtbs_check on STM32 devicetrees.
> The patches has been developped on top of v5.7-rc4 tag.
>
> Benjamin Gaignard (15):
> ARM: dts: stm32: remove useless interrupt-names property on stm32f429
> ARM: dts: stm32: update pwm pinctrl node names for stm32f4
> ARM: dts: stm32: update led nodes names for stm32f249-disco
> ARM: dts: stm32: update led nodes names for stm32f469-disco
> ARM: dts: stm32: remove useless interrupt-names property on stm32f746
> ARM: dts: stm32: update led nodes names for stm32f429-eval
> ARM: dts: stm32: update led nodes names for stm32f769-disco
> ARM: dts: stm32: update led nodes names for stm32f746-eval
> ARM: dts: stm32: remove useless interrupt-names property on stm32f743
> ARM: dts: stm32: Update nodes names for stm32h743 pinctrl
> ARM: dts: stm32: Update nodes names for stm32mp15 pinctrl
> ARM: dts: stm32: Add missing #address and #size cells on spi node for
> stm32mp151
> ARM: dts: stm32: update led nodes names for stm32f746-eval
> dt-bindings: pinctrl: stm32: Add missing interrupts property
> dt-bindings: usb: dwc2: Fix issues for stm32mp15x SoC
For dts(i) part, it looks good to me. I let Rob to review before taking
the whole series.
thanks
alex
>
> .../devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml | 3 +++
> Documentation/devicetree/bindings/usb/dwc2.yaml | 6 ++++--
> arch/arm/boot/dts/stm32429i-eval.dts | 8 ++++----
> arch/arm/boot/dts/stm32746g-eval.dts | 8 ++++----
> arch/arm/boot/dts/stm32f4-pinctrl.dtsi | 4 ++--
> arch/arm/boot/dts/stm32f429-disco.dts | 4 ++--
> arch/arm/boot/dts/stm32f429.dtsi | 1 -
> arch/arm/boot/dts/stm32f469-disco.dts | 8 ++++----
> arch/arm/boot/dts/stm32f746.dtsi | 1 -
> arch/arm/boot/dts/stm32f769-disco.dts | 4 ++--
> arch/arm/boot/dts/stm32h743-pinctrl.dtsi | 10 +++++-----
> arch/arm/boot/dts/stm32h743.dtsi | 1 -
> arch/arm/boot/dts/stm32mp15-pinctrl.dtsi | 6 +++---
> arch/arm/boot/dts/stm32mp151.dtsi | 2 ++
> arch/arm/boot/dts/stm32mp15xx-dkx.dtsi | 2 +-
> 15 files changed, 36 insertions(+), 32 deletions(-)
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox