* Re: [PATCH/RFC 10/12] arm64: dts: renesas: r8a774c0: Point LVDS0 to its companion LVDS1
From: Laurent Pinchart @ 2019-08-02 8:27 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Kieran Bingham, Jacopo Mondi, Rob Herring, Mark Rutland,
Simon Horman, Magnus Damm, linux-renesas-soc, devicetree,
Geert Uytterhoeven, Chris Paterson, Biju Das
In-Reply-To: <1564731249-22671-11-git-send-email-fabrizio.castro@bp.renesas.com>
Hi Fabrizio,
Thank you for the patch.
On Fri, Aug 02, 2019 at 08:34:07AM +0100, Fabrizio Castro wrote:
> Add the new renesas,companion property to the LVDS0 node to point to the
> companion LVDS encoder LVDS1.
> Based on similar work from Laurent Pinchart for the r8a7799[05].
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
and taken in my tree.
> ---
> arch/arm64/boot/dts/renesas/r8a774c0.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
> index e7b5bf2..b36d3b08 100644
> --- a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
> @@ -1844,6 +1844,8 @@
> resets = <&cpg 727>;
> status = "disabled";
>
> + renesas,companion = <&lvds1>;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] ARM: dts: stm32: add DFSDM pins to stm32mp157c
From: Alexandre Torgue @ 2019-08-02 8:09 UTC (permalink / raw)
To: Olivier Moysan, linux-stm32, robh, mark.rutland, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <1564645567-13156-1-git-send-email-olivier.moysan@st.com>
Hi Olivier
On 8/1/19 9:46 AM, Olivier Moysan wrote:
> Add DFSDM pins to stm32mp157c.
>
> Signed-off-by: Olivier Moysan <olivier.moysan@st.com>
> ---
> arch/arm/boot/dts/stm32mp157-pinctrl.dtsi | 39 +++++++++++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
> index 9eaec9bf8cb8..f96a928cbc49 100644
> --- a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
> @@ -230,6 +230,45 @@
> };
> };
>
I use to only take pinconfig which are used in board. So please resend
with the "board patch".
regards
Alex
> + dfsdm_clkout_pins_a: dfsdm-clkout-pins-0 {
> + pins {
> + pinmux = <STM32_PINMUX('B', 13, AF3)>; /* DFSDM_CKOUT */
> + bias-disable;
> + drive-push-pull;
> + slew-rate = <0>;
> + };
> + };
> +
> + dfsdm_clkout_sleep_pins_a: dfsdm-clkout-sleep-pins-0 {
> + pins {
> + pinmux = <STM32_PINMUX('B', 13, ANALOG)>; /* DFSDM_CKOUT */
> + };
> + };
> +
> + dfsdm_data1_pins_a: dfsdm-data1-pins-0 {
> + pins {
> + pinmux = <STM32_PINMUX('C', 3, AF3)>; /* DFSDM_DATA1 */
> + };
> + };
> +
> + dfsdm_data1_sleep_pins_a: dfsdm-data1-sleep-pins-0 {
> + pins {
> + pinmux = <STM32_PINMUX('C', 3, ANALOG)>; /* DFSDM_DATA1 */
> + };
> + };
> +
> + dfsdm_data3_pins_a: dfsdm-data3-pins-0 {
> + pins {
> + pinmux = <STM32_PINMUX('F', 13, AF6)>; /* DFSDM_DATA3 */
> + };
> + };
> +
> + dfsdm_data3_sleep_pins_a: dfsdm-data3-sleep-pins-0 {
> + pins {
> + pinmux = <STM32_PINMUX('F', 13, ANALOG)>; /* DFSDM_DATA3 */
> + };
> + };
> +
> ethernet0_rgmii_pins_a: rgmii-0 {
> pins1 {
> pinmux = <STM32_PINMUX('G', 5, AF11)>, /* ETH_RGMII_CLK125 */
>
^ permalink raw reply
* Re: [PATCH/RFC 04/12] dt-bindings: display: Add bindings for Advantech IDK-2121WR
From: Laurent Pinchart @ 2019-08-02 8:03 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Kieran Bingham, Jacopo Mondi, Thierry Reding, David Airlie,
Daniel Vetter, Rob Herring, Mark Rutland, Sam Ravnborg, dri-devel,
devicetree, linux-kernel, Simon Horman, Geert Uytterhoeven,
Chris Paterson, Biju Das, linux-renesas-soc
In-Reply-To: <1564731249-22671-5-git-send-email-fabrizio.castro@bp.renesas.com>
Hi Fabrizio,
Thank you for the patch.
On Fri, Aug 02, 2019 at 08:34:01AM +0100, Fabrizio Castro wrote:
> This panel is handled through the generic lvds-panel bindings,
> so only needs its additional compatible specified.
>
> Some panel specific documentation can be found here:
s/panel specific/panel-specific/
> https://buy.advantech.eu/Displays/Embedded-LCD-Kits-High-Brightness/model-IDK-2121WR-K2FHA2E.htm
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> ---
> .../display/panel/advantech,idk-2121wr.txt | 62 ++++++++++++++++++++++
> 1 file changed, 62 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.txt
>
> diff --git a/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.txt b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.txt
> new file mode 100644
> index 0000000..70b15b6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.txt
> @@ -0,0 +1,62 @@
> +Advantech Co., Ltd. IDK-2121WR 21.5" LVDS panel
> +===============================================
> +
> +Required properties:
> +- compatible: should be "advantech,idk-2121wr" followed by "panel-lvds"
> +
> +This binding is compatible with the lvds-panel binding, which is specified
> +in panel-lvds.txt in this directory.
How about adding "The panel operates in dual-link mode and thus requires
two port nodes." ?
> +
> +Example
> +-------
> +
> + panel {
> + compatible = "advantech,idk-2121wr", "panel-lvds";
> +
> + width-mm = <476>;
> + height-mm = <268>;
> +
> + data-mapping = "vesa-24";
> +
> + panel-timing {
> + clock-frequency = <148500000>;
> + hactive = <1920>;
> + vactive = <1080>;
> + hsync-len = <44>;
> + hfront-porch = <88>;
> + hback-porch = <148>;
> + vfront-porch = <4>;
> + vback-porch = <36>;
> + vsync-len = <5>;
> + };
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + lvds0_panel_in: endpoint {
> + remote-endpoint = <&lvds0_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + lvds1_panel_in: endpoint {
> + remote-endpoint = <&lvds1_out>;
> + };
> + };
> + };
> + };
> +
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = <&pwm5 0 50000>;
> +
> + brightness-levels = <0 4 8 16 32 64 128 255>;
> + default-brightness-level = <6>;
> +
> + power-supply = <®_12p0v>;
> + enable-gpios = <&gpio6 12 GPIO_ACTIVE_HIGH>;
> + };
I think you can drop the backlight here, it's a bit out of scope.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] ARM: dts: stm32: add phy-dsi-supply property on stm32mp157c-ev1
From: Yannick FERTRE @ 2019-08-02 8:01 UTC (permalink / raw)
To: Alexandre TORGUE, Maxime Coquelin, Rob Herring, Mark Rutland,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Benjamin GAIGNARD, Philippe CORNU,
Fabrice GASNIER
In-Reply-To: <346d04ad-17ed-40c8-f10a-b13a2ea79d92@st.com>
Many thanks Alex.
On 8/2/19 9:36 AM, Alexandre Torgue wrote:
> Hi Yannick
>
> On 7/29/19 4:29 PM, Yannick Fertré wrote:
>> The dsi physical layer is powered by the 1v8 power controller supply.
>>
>> Signed-off-by: Yannick Fertré <yannick.fertre@st.com>
>> ---
>> arch/arm/boot/dts/stm32mp157c-ev1.dts | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/boot/dts/stm32mp157c-ev1.dts
>> b/arch/arm/boot/dts/stm32mp157c-ev1.dts
>> index feb8f77..19d69d0 100644
>> --- a/arch/arm/boot/dts/stm32mp157c-ev1.dts
>> +++ b/arch/arm/boot/dts/stm32mp157c-ev1.dts
>> @@ -101,6 +101,7 @@
>> &dsi {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> + phy-dsi-supply = <®18>;
>> status = "okay";
>> ports {
>>
>
> Applied on stm32-next.
>
> Thanks.
> Alex
--
Yannick Fertré | TINA: 166 7152 | Tel: +33 244027152 | Mobile: +33 620600270
Microcontrollers and Digital ICs Group | Microcontrolleurs Division
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH/RFC 03/12] dt-bindings: panel: lvds: Add dual-link LVDS display support
From: Laurent Pinchart @ 2019-08-02 8:00 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Kieran Bingham, Jacopo Mondi, Thierry Reding, David Airlie,
Daniel Vetter, Rob Herring, Mark Rutland, Sam Ravnborg, dri-devel,
devicetree, linux-kernel, Simon Horman, Geert Uytterhoeven,
Chris Paterson, Biju Das, linux-renesas-soc
In-Reply-To: <1564731249-22671-4-git-send-email-fabrizio.castro@bp.renesas.com>
Hi Fabrizio,
Thank you for the patch.
On Fri, Aug 02, 2019 at 08:34:00AM +0100, Fabrizio Castro wrote:
> Dual-link LVDS displays have two ports, therefore document this
> with the bindings.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> ---
> .../bindings/display/panel/panel-lvds.txt | 91 ++++++++++++++++------
> 1 file changed, 67 insertions(+), 24 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
> index 250850a..07795441 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
> +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
> @@ -41,7 +41,8 @@ Required nodes:
>
> - panel-timing: See panel-common.txt.
> - ports: See panel-common.txt. These bindings require a single port subnode
> - corresponding to the panel LVDS input.
> + (for a single link display) or two port subnodes (for a dual link display)
> + corresponding to the panel LVDS input(s).
I think you should expand this a bit to explain what the ports
correspond to in the dual link mode.
> LVDS data mappings are defined as follows.
> @@ -92,30 +93,72 @@ CTL3: 0
> Example
> -------
>
> -panel {
> - compatible = "mitsubishi,aa121td01", "panel-lvds";
> -
> - width-mm = <261>;
> - height-mm = <163>;
> -
> - data-mapping = "jeida-24";
> -
> - panel-timing {
> - /* 1280x800 @60Hz */
> - clock-frequency = <71000000>;
> - hactive = <1280>;
> - vactive = <800>;
> - hsync-len = <70>;
> - hfront-porch = <20>;
> - hback-porch = <70>;
> - vsync-len = <5>;
> - vfront-porch = <3>;
> - vback-porch = <15>;
> +Single port:
> + panel {
> + compatible = "mitsubishi,aa121td01", "panel-lvds";
> +
> + width-mm = <261>;
> + height-mm = <163>;
> +
> + data-mapping = "jeida-24";
> +
> + panel-timing {
> + /* 1280x800 @60Hz */
> + clock-frequency = <71000000>;
> + hactive = <1280>;
> + vactive = <800>;
> + hsync-len = <70>;
> + hfront-porch = <20>;
> + hback-porch = <70>;
> + vsync-len = <5>;
> + vfront-porch = <3>;
> + vback-porch = <15>;
> + };
> +
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <&lvds_encoder>;
> + };
> + };
> };
>
> - port {
> - panel_in: endpoint {
> - remote-endpoint = <&lvds_encoder>;
> +Two ports:
> + panel {
> + compatible = "advantech,idk-2121wr", "panel-lvds";
> +
> + width-mm = <476>;
> + height-mm = <268>;
> +
> + data-mapping = "vesa-24";
> +
> + panel-timing {
> + clock-frequency = <148500000>;
> + hactive = <1920>;
> + vactive = <1080>;
> + hsync-len = <44>;
> + hfront-porch = <88>;
> + hback-porch = <148>;
> + vfront-porch = <4>;
> + vback-porch = <36>;
> + vsync-len = <5>;
> + };
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + lvds0_panel_in: endpoint {
I would name the label panel_in0 and panel_in1 below to have a common
prefix showing that both refer to the same panel.
> + remote-endpoint = <&lvds0_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + lvds1_panel_in: endpoint {
> + remote-endpoint = <&lvds1_out>;
> + };
> + };
> };
> };
> -};
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH/RFC 01/12] dt-bindings: display: renesas: lvds: RZ/G2E needs renesas,companion too
From: Laurent Pinchart @ 2019-08-02 7:48 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Mark Rutland, devicetree, Chris Paterson, Geert Uytterhoeven,
Simon Horman, David Airlie, Kieran Bingham, linux-kernel,
dri-devel, Biju Das, linux-renesas-soc, Rob Herring, Jacopo Mondi
In-Reply-To: <1564731249-22671-2-git-send-email-fabrizio.castro@bp.renesas.com>
Hello Fabrizio,
Thank you for the patch.
On Fri, Aug 02, 2019 at 08:33:58AM +0100, Fabrizio Castro wrote:
> Document RZ/G2E support for property renesas,companion.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
and taken in my tree.
> ---
> Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> index c6a196d..dece79e 100644
> --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> @@ -49,9 +49,9 @@ Each port shall have a single endpoint.
> Optional properties:
>
> - renesas,companion : phandle to the companion LVDS encoder. This property is
> - mandatory for the first LVDS encoder on D3 and E3 SoCs, and shall point to
> - the second encoder to be used as a companion in dual-link mode. It shall not
> - be set for any other LVDS encoder.
> + mandatory for the first LVDS encoder on R-Car D3, R-Car E3, and RZ/G2E SoCs,
> + and shall point to the second encoder to be used as a companion in dual-link
> + mode. It shall not be set for any other LVDS encoder.
>
>
> Example:
--
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/RFC 02/12] dt-bindings: display: renesas: lvds: Document renesas,swap-data
From: Laurent Pinchart @ 2019-08-02 7:44 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Kieran Bingham, Jacopo Mondi, David Airlie, Daniel Vetter,
Rob Herring, Mark Rutland, dri-devel, linux-renesas-soc,
devicetree, linux-kernel, Simon Horman, Geert Uytterhoeven,
Chris Paterson, Biju Das
In-Reply-To: <1564731249-22671-3-git-send-email-fabrizio.castro@bp.renesas.com>
Hi Fabrizio,
Thank you for the patch.
On Fri, Aug 02, 2019 at 08:33:59AM +0100, Fabrizio Castro wrote:
> R-Car D3, R-Car E3, and RZ/G2E support dual-link mode.
> In such a mode, the first LVDS encoder emits even data, and the
> second LVDS encoder emits odd data. This patch documents property
> renesas,swap-data, used to swap even and odd data around.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> ---
> Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> index dece79e..8980179 100644
> --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> @@ -52,6 +52,11 @@ Optional properties:
> mandatory for the first LVDS encoder on R-Car D3, R-Car E3, and RZ/G2E SoCs,
> and shall point to the second encoder to be used as a companion in dual-link
> mode. It shall not be set for any other LVDS encoder.
> +- renesas,swap-data : when in dual-link mode, the first LVDS encoder normally
> + emits even data, and the second LVDS encoder emits odd data. When property
> + renesas,swap-data is specified, the data emitted by the two encoders will be
> + swapped around. This property can only be used in conjunction with property
> + renesas,companion.
>From an LVDS encoder point of view this is more a configuration option
than a description of the hardware. Wouldn't it be better for the LVDS
sink to report which of the odd or even pixels it expects on each of its
endpoints ? The LVDS encoder driver could then query that at runtime and
configure itself accordingly. Ideally this should be queried through the
drm_bridge_timings structure (or through a similar mean), not through
DT. An LVDS sink that has a fixed mapping of odd/even pixels to
endpoints wouldn't need the information to be specified in DT at all.
>
>
> Example:
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v9 04/18] kunit: test: add kunit_stream a std::stream like logger
From: John Ogness @ 2019-08-02 7:37 UTC (permalink / raw)
To: Brendan Higgins
Cc: Petr Mladek, Jeff Dike, Kevin Hilman, Logan Gunthorpe,
Michael Ellerman, Daniel Vetter, Amir Goldstein, Frank Rowand,
Steven Rostedt, Kees Cook, David Rientjes, kunit-dev,
Kieran Bingham, Peter Zijlstra, Randy Dunlap, Joel Stanley,
Luis Chamberlain, Rob Herring, Stephen Boyd, shuah, wfg, Greg KH
In-Reply-To: <CAFd5g46iAhDZ5C_chi7oYLVOkwcoj6+0nw+kPWuXhqWwWKd9jA@mail.gmail.com>
On 2019-08-01, Brendan Higgins <brendanhiggins@google.com> wrote:
> On Fri, Jul 26, 2019 at 1:31 AM Petr Mladek <pmladek@suse.com> wrote:
>> On Thu 2019-07-25 13:21:12, Brendan Higgins wrote:
>>> On Wed, Jul 24, 2019 at 12:31 AM Petr Mladek <pmladek@suse.com> wrote:
>>>> On Mon 2019-07-22 16:54:10, Stephen Boyd wrote:
>>>>> Quoting Brendan Higgins (2019-07-22 15:30:49)
>>>>>> On Mon, Jul 22, 2019 at 1:03 PM Stephen Boyd <sboyd@kernel.org> wrote:
>>>>>>> What's the calling context of the assertions and expectations? I
>>>>>>> still don't like the fact that string stream needs to allocate
>>>>>>> buffers and throw them into a list somewhere because the calling
>>>>>>> context matters there.
>>>>>>
>>>>>> The calling context is the same as before, which is anywhere.
>>>>>
>>>>> Ok. That's concerning then.
>>>>>
>>>>>>> I'd prefer we just wrote directly to the console/log via printk
>>>>>>> instead. That way things are simple because we use the existing
>>>>>>> buffering path of printk, but maybe there's some benefit to the
>>>>>>> string stream that I don't see? Right now it looks like it
>>>>>>> builds a string and then dumps it to printk so I'm sort of lost
>>>>>>> what the benefit is over just writing directly with printk.
>>>>>>
>>>>>> It's just buffering it so the whole string gets printed
>>>>>> uninterrupted. If we were to print out piecemeal to printk,
>>>>>> couldn't we have another call to printk come in causing it to
>>>>>> garble the KUnit message we are in the middle of printing?
>>>>>
>>>>> Yes, printing piecemeal by calling printk many times could lead to
>>>>> interleaving of messages if something else comes in such as an
>>>>> interrupt printing something. Printk has some support to hold
>>>>> "records" but I'm not sure how that would work here because
>>>>> KERN_CONT talks about only being used early on in boot code. I
>>>>> haven't looked at printk in detail though so maybe I'm all wrong
>>>>> and KERN_CONT just works?
>>>>
>>>> KERN_CONT does not guarantee that the message will get printed
>>>> together. The pieces get interleaved with messages printed in
>>>> parallel.
>>>>
>>>> Note that KERN_CONT was originally really meant to be used only
>>>> during boot. It was later used more widely and ended in the best
>>>> effort category.
>>>>
>>>> There were several attempts to make it more reliable. But it was
>>>> always either too complicated or error prone or both.
>>>>
>>>> You need to use your own buffering if you rely want perfect output.
>>>> The question is if it is really worth the complexity. Also note
>>>> that any buffering reduces the chance that the messages will reach
>>>> the console.
>>>
>>> Seems like that settles it then. Thanks!
>>>
>>>> BTW: There is a work in progress on a lockless printk ring buffer.
>>>> It will make printk() more secure regarding deadlocks. But it might
>>>> make transparent handling of continuous lines even more tricky.
>>>>
>>>> I guess that local buffering, before calling printk(), will be
>>>> even more important then. Well, it might really force us to create
>>>> an API for it.
>>>
>>> Cool! Can you CC me on that discussion?
>>
>> Adding John Oggness into CC.
>>
>> John, please CC Brendan Higgins on the patchsets eventually switching
>> printk() into the lockless buffer. The test framework is going to
>> do its own buffering to keep the related messages together.
>>
>> The lockless ringbuffer might make handling of related (partial)
>> lines worse or better. It might justify KUnit's extra buffering
>> or it might allow to get rid of it.
>
> Thanks for CC'ing me on the printk ringbuffer thread. It looks like it
> actually probably won't affect my needs for KUnit logging. The biggest
> reason I need some sort of buffering system is to be able to compose
> messages piece meal into a single message that will be printed out to
> the user as a single message with no messages from other printk
> callers printed out in the middle of mine.
printk has this same requirement for its CONT messages. You can read
about how I propose to implement that here[0], using a separate prb
ringbuffer for buffered storage until all the pieces are available.
It is not my goal that multiple subsystems start making use of the prb
ringbuffer. However, its features can be attractive if you don't want to
worry about multiple writers/readers or context (including NMI). Before
writing "yet another ringbuffer" [1] it might be worth the effort to at
least see if one of the existing implementations can work (or be
extended to work) for you.
John Ogness
[0] https://lkml.kernel.org/r/87imt2bl0k.fsf@linutronix.de
[1] https://lwn.net/Articles/789603/
> The prb does look interesting; however, it appears that to get the
> semantics that I need, I would have to put my entire message in a
> single data block and would consequently need to know the size of my
> message a priori, which is problematic. Consequently, it seems as
> though I will probably need to compose my entire message using my own
> buffering system.
>
>>>> Note that stroring the messages into the printk log is basically
>>>> safe in any context. It uses temporary per-CPU buffers for
>>>> recursive messages and in NMI. The only problem is panic() when
>>>> some CPU gets stuck with the lock taken. This will get solved by
>>>> the lockless ringbuffer. Also the temporary buffers will not be
>>>> necessary any longer.
>>>
>>> Sure, I think Stephen's concern is all the supporting code that is
>>> involved. Not printk specifically. It just means a lot more of KUnit
>>> has to be IRQ safe.
>>
>> I see.
>>
>> BTW: I wonder if KUnit could reuse the existing seq_buf
>> implementation for buffering messages.
>>
>> I am sorry if it has already been proposed and rejected for some
>> reason. I might have missed it. Feel free to just point me to
>> same older mail.
>
> Yeah, we discussed it briefly here:
>
> https://lkml.org/lkml/2019/5/17/497
>
> Looks like I forgot to include my reasoning in the commit text, sorry
> about that.
>
>>>> Much bigger problems are with consoles. There are many of them. It
>>>> means a lot of code and more locks involved, including scheduler
>>>> locks. Note that console lock is a semaphore.
>>>
>>> That shouldn't affect us though, right? As long as we continue to
>>> use the printk interface?
>>
>> I guess that it should not affect KUnit.
>>
>> The only problem might be if the testing framework calls printk()
>> inside scheduler or console code. And only when the tested code
>> uses the same locks that will be used by the called printk().
>
> Yeah, well printk will not be our only problem in those instances.
>
>> To be honest I do not fully understand KUnit design. I am not
>> completely sure how the tested code is isolated from the running
>> system. Namely, I do not know if the tested code shares
>> the same locks with the system running the test.
>
> No worries, I don't expect printk to be the hang up in those cases. It
> sounds like KUnit has a long way to evolve before printk is going to
> be a limitation.
>
> Thanks!
^ permalink raw reply
* Re: [PATCH] ARM: dts: stm32: add phy-dsi-supply property on stm32mp157c-ev1
From: Alexandre Torgue @ 2019-08-02 7:36 UTC (permalink / raw)
To: Yannick Fertré, Maxime Coquelin, Rob Herring, Mark Rutland,
linux-stm32, linux-arm-kernel, devicetree, linux-kernel,
Benjamin Gaignard, Philippe Cornu, Fabrice Gasnier
In-Reply-To: <1564410548-20436-1-git-send-email-yannick.fertre@st.com>
Hi Yannick
On 7/29/19 4:29 PM, Yannick Fertré wrote:
> The dsi physical layer is powered by the 1v8 power controller supply.
>
> Signed-off-by: Yannick Fertré <yannick.fertre@st.com>
> ---
> arch/arm/boot/dts/stm32mp157c-ev1.dts | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/stm32mp157c-ev1.dts b/arch/arm/boot/dts/stm32mp157c-ev1.dts
> index feb8f77..19d69d0 100644
> --- a/arch/arm/boot/dts/stm32mp157c-ev1.dts
> +++ b/arch/arm/boot/dts/stm32mp157c-ev1.dts
> @@ -101,6 +101,7 @@
> &dsi {
> #address-cells = <1>;
> #size-cells = <0>;
> + phy-dsi-supply = <®18>;
> status = "okay";
>
> ports {
>
Applied on stm32-next.
Thanks.
Alex
^ permalink raw reply
* [PATCH/RFC 12/12] arm64: dts: renesas: Add EK874 board with idk-2121wr display support
From: Fabrizio Castro @ 2019-08-02 7:34 UTC (permalink / raw)
To: Laurent Pinchart, Kieran Bingham, Jacopo Mondi, Rob Herring,
Mark Rutland
Cc: Fabrizio Castro, Simon Horman, Magnus Damm, linux-renesas-soc,
devicetree, Geert Uytterhoeven, Chris Paterson, Biju Das,
ebiharaml
In-Reply-To: <1564731249-22671-1-git-send-email-fabrizio.castro@bp.renesas.com>
The EK874 is advertised as compatible with panel IDK-2121WR from
Advantech, however the panel isn't sold alongside the board.
A new dts, adding everything that's required to get the panel to
to work with the EK874, is the most convenient way to support the
EK874 when it's connected to the IDK-2121WR.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
---
arch/arm64/boot/dts/renesas/Makefile | 3 +-
.../boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts | 112 +++++++++++++++++++++
2 files changed, 114 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts
diff --git a/arch/arm64/boot/dts/renesas/Makefile b/arch/arm64/boot/dts/renesas/Makefile
index 42b74c2..ce48478 100644
--- a/arch/arm64/boot/dts/renesas/Makefile
+++ b/arch/arm64/boot/dts/renesas/Makefile
@@ -1,7 +1,8 @@
# SPDX-License-Identifier: GPL-2.0
dtb-$(CONFIG_ARCH_R8A774A1) += r8a774a1-hihope-rzg2m.dtb
dtb-$(CONFIG_ARCH_R8A774A1) += r8a774a1-hihope-rzg2m-ex.dtb
-dtb-$(CONFIG_ARCH_R8A774C0) += r8a774c0-cat874.dtb r8a774c0-ek874.dtb
+dtb-$(CONFIG_ARCH_R8A774C0) += r8a774c0-cat874.dtb r8a774c0-ek874.dtb \
+ r8a774c0-ek874-idk-2121wr.dtb
dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-salvator-x.dtb r8a7795-h3ulcb.dtb
dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-h3ulcb-kf.dtb
dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-salvator-xs.dtb
diff --git a/arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts b/arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts
new file mode 100644
index 0000000..d989998
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts
@@ -0,0 +1,112 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the Silicon Linux RZ/G2E evaluation kit (EK874),
+ * connected to an Advantech IDK-2121WR 21.5" LVDS panel
+ *
+ * Copyright (C) 2019 Renesas Electronics Corp.
+ */
+
+#include "r8a774c0-ek874.dts"
+
+/ {
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm5 0 50000>;
+
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <6>;
+
+ power-supply = <®_12p0v>;
+ enable-gpios = <&gpio6 12 GPIO_ACTIVE_HIGH>;
+ };
+
+ panel-lvds {
+ compatible = "advantech,idk-2121wr", "panel-lvds";
+
+ width-mm = <476>;
+ height-mm = <268>;
+
+ data-mapping = "vesa-24";
+
+ panel-timing {
+ clock-frequency = <148500000>;
+ hactive = <1920>;
+ vactive = <1080>;
+ hsync-len = <44>;
+ hfront-porch = <88>;
+ hback-porch = <148>;
+ vfront-porch = <4>;
+ vback-porch = <36>;
+ vsync-len = <5>;
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ lvds0_panel_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ lvds1_panel_in: endpoint {
+ remote-endpoint = <&lvds1_out>;
+ };
+ };
+ };
+ };
+};
+
+&gpio0 {
+ lvds-connector-en-gpio{
+ gpio-hog;
+ gpios = <17 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "lvds-connector-en-gpio";
+ };
+};
+
+&lvds0 {
+ renesas,swap-data;
+
+ ports {
+ port@1 {
+ lvds0_out: endpoint {
+ remote-endpoint = <&lvds0_panel_in>;
+ };
+ };
+ };
+};
+
+&lvds1 {
+ status = "okay";
+
+ clocks = <&cpg CPG_MOD 727>, <&x13_clk>, <&extal_clk>;
+ clock-names = "fck", "dclkin.0", "extal";
+
+ ports {
+ port@1 {
+ lvds1_out: endpoint {
+ remote-endpoint = <&lvds1_panel_in>;
+ };
+ };
+ };
+};
+
+&pfc {
+ pwm5_pins: pwm5 {
+ groups = "pwm5_a";
+ function = "pwm5";
+ };
+};
+
+&pwm5 {
+ pinctrl-0 = <&pwm5_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
--
2.7.4
^ permalink raw reply related
* [PATCH/RFC 11/12] arm64: dts: renesas: cat874: Add definition for 12V regulator
From: Fabrizio Castro @ 2019-08-02 7:34 UTC (permalink / raw)
To: Geert Uytterhoeven, Laurent Pinchart, Kieran Bingham,
Jacopo Mondi, Rob Herring, Mark Rutland
Cc: Fabrizio Castro, Simon Horman, Magnus Damm, linux-renesas-soc,
devicetree, Chris Paterson, Biju Das, ebiharaml
In-Reply-To: <1564731249-22671-1-git-send-email-fabrizio.castro@bp.renesas.com>
Power rail "D12.0V" comes straight from the power barrel connector,
and it's used in both main board and sub board.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
---
arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts b/arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts
index 46a77ee..651383c 100644
--- a/arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts
+++ b/arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts
@@ -65,6 +65,15 @@
reg = <0x0 0x48000000 0x0 0x78000000>;
};
+ reg_12p0v: regulator-12p0v {
+ compatible = "regulator-fixed";
+ regulator-name = "D12.0V";
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
sound: sound {
compatible = "simple-audio-card";
--
2.7.4
^ permalink raw reply related
* [PATCH/RFC 10/12] arm64: dts: renesas: r8a774c0: Point LVDS0 to its companion LVDS1
From: Fabrizio Castro @ 2019-08-02 7:34 UTC (permalink / raw)
To: Laurent Pinchart, Kieran Bingham, Jacopo Mondi, Rob Herring,
Mark Rutland
Cc: Fabrizio Castro, Simon Horman, Magnus Damm, linux-renesas-soc,
devicetree, Geert Uytterhoeven, Chris Paterson, Biju Das
In-Reply-To: <1564731249-22671-1-git-send-email-fabrizio.castro@bp.renesas.com>
Add the new renesas,companion property to the LVDS0 node to point to the
companion LVDS encoder LVDS1.
Based on similar work from Laurent Pinchart for the r8a7799[05].
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
---
arch/arm64/boot/dts/renesas/r8a774c0.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
index e7b5bf2..b36d3b08 100644
--- a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
@@ -1844,6 +1844,8 @@
resets = <&cpg 727>;
status = "disabled";
+ renesas,companion = <&lvds1>;
+
ports {
#address-cells = <1>;
#size-cells = <0>;
--
2.7.4
^ permalink raw reply related
* [PATCH/RFC 04/12] dt-bindings: display: Add bindings for Advantech IDK-2121WR
From: Fabrizio Castro @ 2019-08-02 7:34 UTC (permalink / raw)
To: Laurent Pinchart, Kieran Bingham, Jacopo Mondi, Thierry Reding,
David Airlie, Daniel Vetter, Rob Herring, Mark Rutland
Cc: Fabrizio Castro, Sam Ravnborg, dri-devel, devicetree,
linux-kernel, Simon Horman, Geert Uytterhoeven, Chris Paterson,
Biju Das, linux-renesas-soc
In-Reply-To: <1564731249-22671-1-git-send-email-fabrizio.castro@bp.renesas.com>
This panel is handled through the generic lvds-panel bindings,
so only needs its additional compatible specified.
Some panel specific documentation can be found here:
https://buy.advantech.eu/Displays/Embedded-LCD-Kits-High-Brightness/model-IDK-2121WR-K2FHA2E.htm
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
---
.../display/panel/advantech,idk-2121wr.txt | 62 ++++++++++++++++++++++
1 file changed, 62 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.txt
diff --git a/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.txt b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.txt
new file mode 100644
index 0000000..70b15b6
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.txt
@@ -0,0 +1,62 @@
+Advantech Co., Ltd. IDK-2121WR 21.5" LVDS panel
+===============================================
+
+Required properties:
+- compatible: should be "advantech,idk-2121wr" followed by "panel-lvds"
+
+This binding is compatible with the lvds-panel binding, which is specified
+in panel-lvds.txt in this directory.
+
+Example
+-------
+
+ panel {
+ compatible = "advantech,idk-2121wr", "panel-lvds";
+
+ width-mm = <476>;
+ height-mm = <268>;
+
+ data-mapping = "vesa-24";
+
+ panel-timing {
+ clock-frequency = <148500000>;
+ hactive = <1920>;
+ vactive = <1080>;
+ hsync-len = <44>;
+ hfront-porch = <88>;
+ hback-porch = <148>;
+ vfront-porch = <4>;
+ vback-porch = <36>;
+ vsync-len = <5>;
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ lvds0_panel_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ lvds1_panel_in: endpoint {
+ remote-endpoint = <&lvds1_out>;
+ };
+ };
+ };
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm5 0 50000>;
+
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <6>;
+
+ power-supply = <®_12p0v>;
+ enable-gpios = <&gpio6 12 GPIO_ACTIVE_HIGH>;
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH/RFC 03/12] dt-bindings: panel: lvds: Add dual-link LVDS display support
From: Fabrizio Castro @ 2019-08-02 7:34 UTC (permalink / raw)
To: Laurent Pinchart, Kieran Bingham, Jacopo Mondi, Thierry Reding,
David Airlie, Daniel Vetter, Rob Herring, Mark Rutland
Cc: Fabrizio Castro, Sam Ravnborg, dri-devel, devicetree,
linux-kernel, Simon Horman, Geert Uytterhoeven, Chris Paterson,
Biju Das, linux-renesas-soc
In-Reply-To: <1564731249-22671-1-git-send-email-fabrizio.castro@bp.renesas.com>
Dual-link LVDS displays have two ports, therefore document this
with the bindings.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
---
.../bindings/display/panel/panel-lvds.txt | 91 ++++++++++++++++------
1 file changed, 67 insertions(+), 24 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
index 250850a..07795441 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
+++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
@@ -41,7 +41,8 @@ Required nodes:
- panel-timing: See panel-common.txt.
- ports: See panel-common.txt. These bindings require a single port subnode
- corresponding to the panel LVDS input.
+ (for a single link display) or two port subnodes (for a dual link display)
+ corresponding to the panel LVDS input(s).
LVDS data mappings are defined as follows.
@@ -92,30 +93,72 @@ CTL3: 0
Example
-------
-panel {
- compatible = "mitsubishi,aa121td01", "panel-lvds";
-
- width-mm = <261>;
- height-mm = <163>;
-
- data-mapping = "jeida-24";
-
- panel-timing {
- /* 1280x800 @60Hz */
- clock-frequency = <71000000>;
- hactive = <1280>;
- vactive = <800>;
- hsync-len = <70>;
- hfront-porch = <20>;
- hback-porch = <70>;
- vsync-len = <5>;
- vfront-porch = <3>;
- vback-porch = <15>;
+Single port:
+ panel {
+ compatible = "mitsubishi,aa121td01", "panel-lvds";
+
+ width-mm = <261>;
+ height-mm = <163>;
+
+ data-mapping = "jeida-24";
+
+ panel-timing {
+ /* 1280x800 @60Hz */
+ clock-frequency = <71000000>;
+ hactive = <1280>;
+ vactive = <800>;
+ hsync-len = <70>;
+ hfront-porch = <20>;
+ hback-porch = <70>;
+ vsync-len = <5>;
+ vfront-porch = <3>;
+ vback-porch = <15>;
+ };
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&lvds_encoder>;
+ };
+ };
};
- port {
- panel_in: endpoint {
- remote-endpoint = <&lvds_encoder>;
+Two ports:
+ panel {
+ compatible = "advantech,idk-2121wr", "panel-lvds";
+
+ width-mm = <476>;
+ height-mm = <268>;
+
+ data-mapping = "vesa-24";
+
+ panel-timing {
+ clock-frequency = <148500000>;
+ hactive = <1920>;
+ vactive = <1080>;
+ hsync-len = <44>;
+ hfront-porch = <88>;
+ hback-porch = <148>;
+ vfront-porch = <4>;
+ vback-porch = <36>;
+ vsync-len = <5>;
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ lvds0_panel_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ lvds1_panel_in: endpoint {
+ remote-endpoint = <&lvds1_out>;
+ };
+ };
};
};
-};
--
2.7.4
^ permalink raw reply related
* [PATCH/RFC 02/12] dt-bindings: display: renesas: lvds: Document renesas,swap-data
From: Fabrizio Castro @ 2019-08-02 7:33 UTC (permalink / raw)
To: Laurent Pinchart, Kieran Bingham, Jacopo Mondi, David Airlie,
Daniel Vetter, Rob Herring, Mark Rutland
Cc: Fabrizio Castro, dri-devel, linux-renesas-soc, devicetree,
linux-kernel, Simon Horman, Geert Uytterhoeven, Chris Paterson,
Biju Das
In-Reply-To: <1564731249-22671-1-git-send-email-fabrizio.castro@bp.renesas.com>
R-Car D3, R-Car E3, and RZ/G2E support dual-link mode.
In such a mode, the first LVDS encoder emits even data, and the
second LVDS encoder emits odd data. This patch documents property
renesas,swap-data, used to swap even and odd data around.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
---
Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
index dece79e..8980179 100644
--- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
+++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
@@ -52,6 +52,11 @@ Optional properties:
mandatory for the first LVDS encoder on R-Car D3, R-Car E3, and RZ/G2E SoCs,
and shall point to the second encoder to be used as a companion in dual-link
mode. It shall not be set for any other LVDS encoder.
+- renesas,swap-data : when in dual-link mode, the first LVDS encoder normally
+ emits even data, and the second LVDS encoder emits odd data. When property
+ renesas,swap-data is specified, the data emitted by the two encoders will be
+ swapped around. This property can only be used in conjunction with property
+ renesas,companion.
Example:
--
2.7.4
^ permalink raw reply related
* [PATCH/RFC 01/12] dt-bindings: display: renesas: lvds: RZ/G2E needs renesas,companion too
From: Fabrizio Castro @ 2019-08-02 7:33 UTC (permalink / raw)
To: Laurent Pinchart, Kieran Bingham, Jacopo Mondi, David Airlie,
Daniel Vetter, Rob Herring, Mark Rutland
Cc: Fabrizio Castro, dri-devel, linux-renesas-soc, devicetree,
linux-kernel, Simon Horman, Geert Uytterhoeven, Chris Paterson,
Biju Das
In-Reply-To: <1564731249-22671-1-git-send-email-fabrizio.castro@bp.renesas.com>
Document RZ/G2E support for property renesas,companion.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
---
Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
index c6a196d..dece79e 100644
--- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
+++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
@@ -49,9 +49,9 @@ Each port shall have a single endpoint.
Optional properties:
- renesas,companion : phandle to the companion LVDS encoder. This property is
- mandatory for the first LVDS encoder on D3 and E3 SoCs, and shall point to
- the second encoder to be used as a companion in dual-link mode. It shall not
- be set for any other LVDS encoder.
+ mandatory for the first LVDS encoder on R-Car D3, R-Car E3, and RZ/G2E SoCs,
+ and shall point to the second encoder to be used as a companion in dual-link
+ mode. It shall not be set for any other LVDS encoder.
Example:
--
2.7.4
^ permalink raw reply related
* [PATCH/RFC 00/12] Add dual-LVDS panel support to EK874
From: Fabrizio Castro @ 2019-08-02 7:33 UTC (permalink / raw)
To: Geert Uytterhoeven, Laurent Pinchart, Kieran Bingham,
Jacopo Mondi, David Airlie, Daniel Vetter, Rob Herring,
Mark Rutland, Thierry Reding
Cc: Fabrizio Castro, Sam Ravnborg, Simon Horman, Magnus Damm,
dri-devel, linux-renesas-soc, devicetree, Chris Paterson,
Biju Das, linux-kernel, ebiharaml
Dear All,
this series adds support for dual-LVDS panel IDK-2121WR
from Advantech:
https://buy.advantech.eu/Displays/Embedded-LCD-Kits-High-Brightness/model-IDK-2121WR-K2FHA2E.htm
Dual link support is very recent for R-Car Gen3, and I couldn't
find much on dual link panels in the kernel either, therefore
comments are very welcome to get this right.
The panel doesn't come with the EK874 kit, but it's advertised as
supported, therefore this series adds a new dts file to support
the configuration of the EK874 + IDK-2121WR.
Finally, this series depends on a fix that's still pending:
https://patchwork.kernel.org/patch/11054755/
Thanks,
Fab
Fabrizio Castro (12):
dt-bindings: display: renesas: lvds: RZ/G2E needs renesas,companion
too
dt-bindings: display: renesas: lvds: Document renesas,swap-data
dt-bindings: panel: lvds: Add dual-link LVDS display support
dt-bindings: display: Add bindings for Advantech IDK-2121WR
drm: rcar-du: lvds: Add data swap support
drm: rcar-du: lvds: Do not look at ports for identifying bridges
drm: rcar-du: lvds: Add support for dual link panels
drm: rcar-du: lvds: Fix bridge_to_rcar_lvds
drm: rcar-du: lvds: Fix companion's mode
arm64: dts: renesas: r8a774c0: Point LVDS0 to its companion LVDS1
arm64: dts: renesas: cat874: Add definition for 12V regulator
arm64: dts: renesas: Add EK874 board with idk-2121wr display support
.../bindings/display/bridge/renesas,lvds.txt | 11 +-
.../display/panel/advantech,idk-2121wr.txt | 62 ++++++++++++
.../bindings/display/panel/panel-lvds.txt | 91 ++++++++++++-----
arch/arm64/boot/dts/renesas/Makefile | 3 +-
arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts | 9 ++
.../boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts | 112 +++++++++++++++++++++
arch/arm64/boot/dts/renesas/r8a774c0.dtsi | 2 +
drivers/gpu/drm/rcar-du/rcar_lvds.c | 65 ++++++------
8 files changed, 291 insertions(+), 64 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.txt
create mode 100644 arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts
--
2.7.4
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: counter: new bindings for TI eQEP
From: William Breathitt Gray @ 2019-08-02 7:25 UTC (permalink / raw)
To: Rob Herring
Cc: David Lechner, linux-iio, linux-omap, devicetree, Mark Rutland,
Jonathan Cameron, Benoît Cousson, Tony Lindgren,
Thierry Reding, linux-kernel, linux-pwm
In-Reply-To: <20190727204836.1514265d@archlinux>
On Sat, Jul 27, 2019 at 08:48:36PM +0100, Jonathan Cameron wrote:
> On Mon, 22 Jul 2019 10:45:35 -0500
> David Lechner <david@lechnology.com> wrote:
>
> > This documents device tree binding for the Texas Instruments Enhanced
> > Quadrature Encoder Pulse (eQEP) Module found in various TI SoCs.
> >
> > Signed-off-by: David Lechner <david@lechnology.com>
>
> Up to William given it is a counter binding, (unless Rob overrules)
> but new bindings are generally preferred as yaml.
>
> Content looks fine to me.
>
> Thanks,
>
> Jonathan
Rob,
Would you prefer these bindings as yaml, or shall I accept them as they
are now?
William Breathitt Gray
>
> > ---
> > .../devicetree/bindings/counter/ti-eqep.txt | 18 ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/counter/ti-eqep.txt
> >
> > diff --git a/Documentation/devicetree/bindings/counter/ti-eqep.txt b/Documentation/devicetree/bindings/counter/ti-eqep.txt
> > new file mode 100644
> > index 000000000000..fbcebc2c2cc2
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/counter/ti-eqep.txt
> > @@ -0,0 +1,18 @@
> > +Texas Instruments Enhanced Quadrature Encoder Pulse (eQEP) Module
> > +
> > +Required properties:
> > +- compatible: Must be "ti,am3352-eqep".
> > +- reg: Physical base address and size of the registers map.
> > +- clocks: Handle to the PWM's functional clock.
> > +- clock-names: Must be "fck".
> > +- interrupts: Handle to the eQEP event interrupt
> > +
> > +Example:
> > +
> > + eqep0: eqep@180 {
> > + compatible = "ti,am3352-eqep";
> > + reg = <0x180 0x80>;
> > + clocks = <&l4ls_gclk>;
> > + clock-names = "fck";
> > + interrupts = <79>;
> > + };
>
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: pinctrl: qcom: Add SC7180 pinctrl binding
From: Rajendra Nayak @ 2019-08-02 6:53 UTC (permalink / raw)
To: Vinod Koul
Cc: linus.walleij, bjorn.andersson, linux-arm-msm, agross, robh+dt,
linux-gpio, devicetree, linux-kernel, Jitendra Sharma,
Vivek Gautam
In-Reply-To: <20190802063317.GB12733@vkoul-mobl.Dlink>
On 8/2/2019 12:03 PM, Vinod Koul wrote:
> On 02-08-19, 09:45, Rajendra Nayak wrote:
>> From: Jitendra Sharma <shajit@codeaurora.org>
>>
>> Add the binding for the TLMM pinctrl block found in the SC7180 platform
>>
>> Signed-off-by: Jitendra Sharma <shajit@codeaurora.org>
>> Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org>
>> [rnayak: Fix some copy-paste issues, sort and fix functions]
>> Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
>> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>> ---
>
> changes since v1: ..?
>
>> +- reg-names:
>> + Usage: required
>> + Value type: <prop-encoded-array>
>> + Defintiion: names for the cells of reg, must contain "north", "south"
>
> s/Defintiion/Definition
>
>> +Example:
>> +
>> + tlmm: pinctrl@3000000 {
>
> this should be: pinctrl@3500000
>
> with these two nitpicks fixed:
Thanks Vinod for the review. I will fix these and respin, after I wait
a while to see if there is any more feedback :)
>
> Reviewed-by: Vinod Koul <vkoul@kernel.org>
>
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH v9 0/7] Solve postboot supplier cleanup and optimize probe ordering
From: Greg Kroah-Hartman @ 2019-08-02 6:37 UTC (permalink / raw)
To: Frank Rowand
Cc: Saravana Kannan, Rob Herring, Mark Rutland, Rafael J. Wysocki,
devicetree, linux-kernel, David Collins, kernel-team
In-Reply-To: <6366cb2a-65ea-cb44-f765-f246f3fb3bf9@gmail.com>
On Thu, Aug 01, 2019 at 12:59:25PM -0700, Frank Rowand wrote:
> On 8/1/19 12:32 PM, Greg Kroah-Hartman wrote:
> > On Thu, Aug 01, 2019 at 12:28:13PM -0700, Frank Rowand wrote:
> >> Hi Greg,
> >>
> >> On 7/31/19 11:12 PM, Greg Kroah-Hartman wrote:
> >>> On Wed, Jul 31, 2019 at 03:17:13PM -0700, Saravana Kannan wrote:
> >>>> Add device-links to track functional dependencies between devices
> >>>> after they are created (but before they are probed) by looking at
> >>>> their common DT bindings like clocks, interconnects, etc.
> >>>>
> >>>> Having functional dependencies automatically added before the devices
> >>>> are probed, provides the following benefits:
> >>>>
> >>>> - Optimizes device probe order and avoids the useless work of
> >>>> attempting probes of devices that will not probe successfully
> >>>> (because their suppliers aren't present or haven't probed yet).
> >>>>
> >>>> For example, in a commonly available mobile SoC, registering just
> >>>> one consumer device's driver at an initcall level earlier than the
> >>>> supplier device's driver causes 11 failed probe attempts before the
> >>>> consumer device probes successfully. This was with a kernel with all
> >>>> the drivers statically compiled in. This problem gets a lot worse if
> >>>> all the drivers are loaded as modules without direct symbol
> >>>> dependencies.
> >>>>
> >>>> - Supplier devices like clock providers, interconnect providers, etc
> >>>> need to keep the resources they provide active and at a particular
> >>>> state(s) during boot up even if their current set of consumers don't
> >>>> request the resource to be active. This is because the rest of the
> >>>> consumers might not have probed yet and turning off the resource
> >>>> before all the consumers have probed could lead to a hang or
> >>>> undesired user experience.
> >>>>
> >>>> Some frameworks (Eg: regulator) handle this today by turning off
> >>>> "unused" resources at late_initcall_sync and hoping all the devices
> >>>> have probed by then. This is not a valid assumption for systems with
> >>>> loadable modules. Other frameworks (Eg: clock) just don't handle
> >>>> this due to the lack of a clear signal for when they can turn off
> >>>> resources. This leads to downstream hacks to handle cases like this
> >>>> that can easily be solved in the upstream kernel.
> >>>>
> >>>> By linking devices before they are probed, we give suppliers a clear
> >>>> count of the number of dependent consumers. Once all of the
> >>>> consumers are active, the suppliers can turn off the unused
> >>>> resources without making assumptions about the number of consumers.
> >>>>
> >>>> By default we just add device-links to track "driver presence" (probe
> >>>> succeeded) of the supplier device. If any other functionality provided
> >>>> by device-links are needed, it is left to the consumer/supplier
> >>>> devices to change the link when they probe.
> >>>
> >>> All now queued up in my driver-core-testing branch, and if 0-day is
> >>> happy with this, will move it to my "real" driver-core-next branch in a
> >>> day or so to get included in linux-next.
> >>
> >> I have been slow in getting my review out.
> >>
> >> This patch series is not yet ready for sending to Linus, so if putting
> >> this in linux-next implies that it will be in your next pull request
> >> to Linus, please do not put it in linux-next.
> >
> > It means that it will be in my pull request for 5.4-rc1, many many
> > waeeks away from now.
>
> If you are willing to revert the series before the pull request _if_ I
> have significant review issues in the next couple of days, then I am happy
> to see the patches get exposure in linux-next.
If you have significant review issues, yes, I will be glad to revert them.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 2/2] pinctrl: qcom: Add SC7180 pinctrl driver
From: Vinod Koul @ 2019-08-02 6:34 UTC (permalink / raw)
To: Rajendra Nayak
Cc: linus.walleij, bjorn.andersson, linux-arm-msm, agross, robh+dt,
linux-gpio, devicetree, linux-kernel, Jitendra Sharma,
Vivek Gautam
In-Reply-To: <20190802041507.12365-2-rnayak@codeaurora.org>
On 02-08-19, 09:45, Rajendra Nayak wrote:
> From: Jitendra Sharma <shajit@codeaurora.org>
>
> Add initial pinctrl driver to support pin configuration with
> pinctrl framework for SC7180
Reviewed-by: Vinod Koul <vkoul@kernel.org>
--
~Vinod
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: pinctrl: qcom: Add SC7180 pinctrl binding
From: Vinod Koul @ 2019-08-02 6:33 UTC (permalink / raw)
To: Rajendra Nayak
Cc: linus.walleij, bjorn.andersson, linux-arm-msm, agross, robh+dt,
linux-gpio, devicetree, linux-kernel, Jitendra Sharma,
Vivek Gautam
In-Reply-To: <20190802041507.12365-1-rnayak@codeaurora.org>
On 02-08-19, 09:45, Rajendra Nayak wrote:
> From: Jitendra Sharma <shajit@codeaurora.org>
>
> Add the binding for the TLMM pinctrl block found in the SC7180 platform
>
> Signed-off-by: Jitendra Sharma <shajit@codeaurora.org>
> Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org>
> [rnayak: Fix some copy-paste issues, sort and fix functions]
> Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
changes since v1: ..?
> +- reg-names:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Defintiion: names for the cells of reg, must contain "north", "south"
s/Defintiion/Definition
> +Example:
> +
> + tlmm: pinctrl@3000000 {
this should be: pinctrl@3500000
with these two nitpicks fixed:
Reviewed-by: Vinod Koul <vkoul@kernel.org>
--
~Vinod
^ permalink raw reply
* Re: [PATCH] dt-bindings: Add pxe1610 as a trivial device
From: Joel Stanley @ 2019-08-02 6:31 UTC (permalink / raw)
To: Vijay Khemka
Cc: Rob Herring, Mark Rutland, Jiri Kosina, Guenter Roeck, Herbert Xu,
Patrick Venture, Ard Biesheuvel, Anson Huang, Jeremy Gebben,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
openbmc @ lists . ozlabs . org, linux-aspeed@lists.ozlabs.org,
Sai Dasari
In-Reply-To: <F7BAC53E-925E-4FA4-815D-ACB82DF8D240@fb.com>
Add pxe1610 as a trivial device
On Tue, 23 Jul 2019 at 17:14, Vijay Khemka <vijaykhemka@fb.com> wrote:
>
> On 7/23/19, 7:53 AM, "Rob Herring" <robh+dt@kernel.org> wrote:
>
> On Tue, Jul 23, 2019 at 8:50 AM Rob Herring <robh+dt@kernel.org> wrote:
> >
> > On Mon, Jul 22, 2019 at 6:46 PM Vijay Khemka <vijaykhemka@fb.com> wrote:
> > >
> > > The pxe1610 is a voltage regulator from Infineon. It also supports
> > > other VRs pxe1110 and pxm1310 from Infineon.
>
> What happened to the other compatibles? S/w doesn't need to know the
> differences?
> As far as driver is concerned, it doesn't need to know differences.
You have these three IDs in the driver:
pxm1310
pxm1310
pxe1610
So all three could be listed in the documentation?
Rob, is this what you wanted Vijay to do?
^ permalink raw reply
* Re: [PATCH 0/3] ARM: dts: aspeed: Deprecate g[45]-style compatibles
From: Joel Stanley @ 2019-08-02 6:15 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Linus Walleij, linux-aspeed, Lee Jones, Rob Herring, Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, linux-kernel@vger.kernel.org, open list:GPIO SUBSYSTEM
In-Reply-To: <3691f6cb-2451-43f7-9f00-d5693071ba59@www.fastmail.com>
On Thu, 1 Aug 2019 at 05:45, Andrew Jeffery <andrew@aj.id.au> wrote:
>
>
>
> On Tue, 30 Jul 2019, at 10:27, Andrew Jeffery wrote:
> >
> >
> > On Tue, 30 Jul 2019, at 07:23, Linus Walleij wrote:
> > > On Wed, Jul 24, 2019 at 10:13 AM Andrew Jeffery <andrew@aj.id.au> wrote:
> > >
> > > > It's probably best if we push the three patches all through one tree rather
> > > > than fragmenting. Is everyone happy if Joel applies them to the aspeed tree?
> > >
> > > If you are sure it will not collide with parallell work in the
> > > pinctrl tree, yes.
> > > Acked-by: Linus Walleij <linus.walleij@linaro.org>
> > >
> > > (If it does collide I'd prefer to take the pinctrl patches and fix the
> > > conflicts in my tree.)
> >
> > Fair enough, I don't know the answer so I'll poke around. I don't
> > really mind
> > where the series goes in, I just want to avoid landing only part of it
> > if I split it up.
>
> Okay, it currently conflicts with my cleanup-devicetree-warnings series.
>
> Joel, do you mind if Linus takes this series through the pinctrl tree, given
> the fix to the devicetrees is patch 1/3?
It depends if you plan more changes to that part of the device tree
this merge window :)
Linus, perhaps the safer option is for me to take 1/3 through my tree
and you can take the rest through yours?
Cheers,
Joel
^ permalink raw reply
* Re: [RFC-ish PATCH 00/17] Clean up ASPEED devicetree warnings
From: Joel Stanley @ 2019-08-02 5:51 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Rob Herring, linux-aspeed, Mark Rutland, devicetree,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-kernel@vger.kernel.org, Adriana Kobylak,
Alexander A. Filippov, Arnd Bergmann,
YangBrianC.W 楊嘉偉 TAO, Corey Minyard,
Greg Kroah-Hartman, Haiyue Wang, John Wang, Ken Chen,
Linus Walleij
In-Reply-To: <fd8e57f0-aee2-403e-b6fb-76d0c18fe306@www.fastmail.com>
On Tue, 30 Jul 2019 at 01:09, Andrew Jeffery <andrew@aj.id.au> wrote:
> > > The bang-for-buck is in fixing up the KCS bindings which removes all-but-two of
> > > the remaining warnings (which we can't feasibly remove), but doing so forces
> > > code changes (which I'd avoided up until this point).
> > >
> > > Reflecting broadly on the fixes, I think I've made a mistake way back by using
> > > syscon/simple-mfds to expose the innards of the SCU and LPC controllers in the
> > > devicetree. This series cleans up what's currently there, but I have half a
> > > mind to rev the SCU and LPC bindings to not use simple-mfd and instead have a
> > > driver implementation that uses `platform_device_register_full()` or similar to
> > > deal with the mess.
> > >
> > > Rob - I'm looking for your thoughts here and on the series, I've never felt
> > > entirely comfortable with what I cooked up. Your advice would be appreciated.
> >
> > The series generally looks fine to me from a quick scan. As far as
> > dropping 'simple-mfd', having less fine grained description in DT is
> > generally my preference. It comes down to whether what you have
> > defined is maintainable. As most of it is just additions, I think what
> > you have is fine. Maybe keep all this in mind for the next chip
> > depending how the SCU and LPC change.
>
> Okay, I think the timing of that suggestion is good given where things are with
> the AST2600. I'll keep that in mind.
>
> Consensus so far seems to be that the series is fine. I'll split it up and send out
> the sub-series to the relevant lists with the acks accumulated here.
The series look good. I suggest posting the KCS bindings and driver
changes as their own series to go through the IPMI tree.
Please add my tag to all the patches except the OCC one, which I need
to do some investigation in to.
Reviewed-by: Joel Stanley <joel@jms.id.au>
The others can go via the aspeed tree. Perhaps post them as their own
series too so I don't get confused and apply the wrong ones. That way
if Rob wants to send his reviewed-by he can.
Cheers,
Joel
^ 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