* [PATCH v3 0/2] gpu: drm/panel: Add DLC DLC0700YZG-1 support
From: Marco Felsch @ 2018-05-23 9:25 UTC (permalink / raw)
To: thierry.reding, robh+dt, mark.rutland; +Cc: devicetree, kernel, dri-devel
This serie adds support for the DLC Display Co. DLC0700YZG-1 7.0" WSVGA
TFT LCD panel. The customer isn't listed as vendor so we have to add the
vendor prefix too.
Philipp Zabel (2):
dt-bindings: Add vendor prefix for DLC Display Co., Ltd.
gpu: drm/panel: Add DLC DLC0700YZG-1 panel
.../display/panel/dlc,dlc0700yzg-1.txt | 7 ++++
.../devicetree/bindings/vendor-prefixes.txt | 1 +
drivers/gpu/drm/panel/panel-simple.c | 32 +++++++++++++++++++
3 files changed, 40 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.txt
--
2.17.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v6 1/6] dt-bindings: arm: Document the RZN1D-DB board
From: Simon Horman @ 2018-05-23 9:20 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Michel Pollet, Linux-Renesas, Phil Edworthy, Michel Pollet,
Magnus Damm, Rob Herring, Mark Rutland, Michael Turquette,
Stephen Boyd, Geert Uytterhoeven,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, linux-clk
In-Reply-To: <CAMuHMdXSGHg9P-MxCHr3h2NRTKAK79KSdf+cB+3a4+pQOvpmSQ@mail.gmail.com>
On Wed, May 23, 2018 at 11:03:56AM +0200, Geert Uytterhoeven wrote:
> On Tue, May 22, 2018 at 12:01 PM, Michel Pollet
> <michel.pollet@bp.renesas.com> wrote:
> > This documents the RZ/N1 bindings for the RZN1D-DB board.
> >
> > Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
> > Reviewed-by: Rob Herring <robh@kernel.org>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks, applied.
^ permalink raw reply
* Re: [PATCH v6 4/6] ARM: dts: Renesas RZ/N1 SoC base device tree file
From: M P @ 2018-05-23 9:20 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: michel.pollet, linux-renesas-soc, Simon Horman, Phil Edworthy,
buserror+upstream, Magnus Damm, robh+dt, mark.rutland,
Michael Turquette, sboyd, geert+renesas, devicetree, linux-kernel,
linux-clk
In-Reply-To: <CAMuHMdXETt75rGyYRsNEK0O5CO3A-bG70g=-f23y6PO_uK6rWg@mail.gmail.com>
Hi Geert,
On Wed, 23 May 2018 at 10:12, Geert Uytterhoeven <geert@linux-m68k.org>
wrote:
> Hi Michel,
> On Tue, May 22, 2018 at 12:01 PM, Michel Pollet
> <michel.pollet@bp.renesas.com> wrote:
> > This adds the Renesas RZ/N1D (Part #R9A06G032) SoC bare
> > bone support.
> >
> > This currently only handles generic parts (gic, architected timer)
> > and a UART.
> > For simplicity sake, this also relies on the bootloader to set the
> > pinctrl and clocks.
> >
> > Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
> Thanks for your patch!
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > +
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + clocks = <&clock RZN1_DIV_CA7>;
> I think the clocks property should be moved to the individual CPU nodes.
Ah, I had a look around, and I found some instances that are in the cpu
sub-node, and others that are not -- it seems that having it in the cpu
sub-node would implies it's core specific... here if that clock is changed
both cores would change speed...
Either way, it's not used by the kernel in any way at the moment -- I had
hoped cpufreq or something would claim it, but it's not the case.
Thanks,
Michel
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: renesas: v3hsk: add GEther support
From: Simon Horman @ 2018-05-23 9:18 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Mark Rutland, devicetree, Magnus Damm, Catalin Marinas,
Will Deacon, linux-renesas-soc, Rob Herring, linux-arm-kernel
In-Reply-To: <20180522085220.vzffiwiwzixlvpkz@verge.net.au>
On Tue, May 22, 2018 at 10:52:21AM +0200, Simon Horman wrote:
> On Fri, May 18, 2018 at 10:46:19PM +0300, Sergei Shtylyov wrote:
> > Define the V3H Starter Kit board dependent part of the GEther device node.
> >
> > Based on the original (and large) patch by Vladimir Barinov.
> >
> > Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> > Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> This looks fine but I will wait to see if there are other reviews before
> applying.
>
> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: renesas: r8a77980: add GEther support
From: Simon Horman @ 2018-05-23 9:18 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Magnus Damm, Catalin Marinas, Will Deacon, Linux-Renesas,
Rob Herring, Geert Uytterhoeven, Linux ARM
In-Reply-To: <9f2c6e9b-a6a9-97f1-7899-3635230acd6f@cogentembedded.com>
On Wed, May 23, 2018 at 12:05:30PM +0300, Sergei Shtylyov wrote:
> Hello!
>
> On 5/23/2018 11:41 AM, Simon Horman wrote:
>
> > > > > Define the generic R8A77980 part of the GEther device node.
> > > > >
> > > > > Based on the original (and large) patch by Vladimir Barinov.
> > > > >
> > > > > Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> > > > > Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> > > >
> > > > Thanks for your patch!
> > > >
> > > > With the below addressed:
> > > > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > >
> > > Thanks!
> > >
> > > > > --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> > > > > +++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> > > > > @@ -417,6 +417,17 @@
> > > > > dma-channels = <16>;
> > > > > };
> > > > >
> > > > > + gether: ethernet@e7400000 {
> > > > > + compatible = "renesas,gether-r8a77980";
> > > > > + reg = <0 0xe7400000 0 0x1000>;
> > > > > + interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
> > > > > + clocks = <&cpg CPG_MOD 813>;
> > > > > + power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
> > > >
> > > > resets = <&cpg 813>;
> > >
> > > As usual...
> > >
> > > >
> > > > > + #address-cells = <1>;
> > > > > + #size-cells = <0>;
> > > > > + status = "disabled";
> > > >
> > > > Any default phy-mode needed?
> > >
> > > A default "phy-mode" IMO make sense when the MAC supports a single
> > > PHY interface mode. In this case, both RMII and RGMII are supported, so
> > > I coulsn't choose a default...
> >
> > I would think making an arbitrary choice is better than no choice.
> > How does the driver behave in the absence of a default?
>
> The board DT *must* assign some "phy-mode" -- it's a required prop.
> In this particular case, iff the mode is still unspecified, the driver
> will select the MII mode for the RMII_MII reg (which is a reserved value for
> this GEther)...
Thanks, if its required that boards provide this property then
this makes sense to me.
I have applied the patch after adding the resets property.
The result is as follows:
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Subject: [PATCH] arm64: dts: renesas: r8a77980: add GEther support
Define the generic R8A77980 part of the GEther device node.
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
[simon: add resets property]
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77980.dtsi b/arch/arm64/boot/dts/renesas/r8a77980.dtsi
index 6d2b61d83caf..c797db59ae18 100644
--- a/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -417,6 +417,18 @@
dma-channels = <16>;
};
+ gether: ethernet@e7400000 {
+ compatible = "renesas,gether-r8a77980";
+ reg = <0 0xe7400000 0 0x1000>;
+ interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 813>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 813>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
mmc0: mmc@ee140000 {
compatible = "renesas,sdhi-r8a77980",
"renesas,rcar-gen3-sdhi";
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v6 5/6] ARM: dts: Renesas RZN1D-DB Board base file
From: Geert Uytterhoeven @ 2018-05-23 9:13 UTC (permalink / raw)
To: Michel Pollet
Cc: Linux-Renesas, Simon Horman, Phil Edworthy, Michel Pollet,
Magnus Damm, Rob Herring, Mark Rutland, Michael Turquette,
Stephen Boyd, Geert Uytterhoeven,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, linux-clk
In-Reply-To: <1526983321-41949-6-git-send-email-michel.pollet@bp.renesas.com>
Hi Michel,
On Tue, May 22, 2018 at 12:01 PM, Michel Pollet
<michel.pollet@bp.renesas.com> wrote:
> This adds a base device tree file for the RZN1-DB board, with only the
> basic support allowing the system to boot to a prompt. Only one UART is
> used, with only a single CPU running.
>
> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
Thanks for your patch!
> --- /dev/null
> +++ b/arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts
> @@ -0,0 +1,29 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for the RZN1D-DB Board
> + *
> + * Copyright (C) 2018 Renesas Electronics Europe Limited
> + *
> + */
> +
> +/dts-v1/;
> +
> +#include "r9a06g032.dtsi"
> +
> +/ {
> + model = "RZN1D-DB Board";
> + compatible = "renesas,rzn1d400-db",
> + "renesas,r9a06g032", "renesas,rzn1";
Please drop the "renesas,rzn1".
With the above fixed:
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
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 v6 4/6] ARM: dts: Renesas RZ/N1 SoC base device tree file
From: Geert Uytterhoeven @ 2018-05-23 9:12 UTC (permalink / raw)
To: Michel Pollet
Cc: Linux-Renesas, Simon Horman, Phil Edworthy, Michel Pollet,
Magnus Damm, Rob Herring, Mark Rutland, Michael Turquette,
Stephen Boyd, Geert Uytterhoeven,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, linux-clk
In-Reply-To: <1526983321-41949-5-git-send-email-michel.pollet@bp.renesas.com>
Hi Michel,
On Tue, May 22, 2018 at 12:01 PM, Michel Pollet
<michel.pollet@bp.renesas.com> wrote:
> This adds the Renesas RZ/N1D (Part #R9A06G032) SoC bare
> bone support.
>
> This currently only handles generic parts (gic, architected timer)
> and a UART.
> For simplicity sake, this also relies on the bootloader to set the
> pinctrl and clocks.
>
> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
Thanks for your patch!
> --- /dev/null
> +++ b/arch/arm/boot/dts/r9a06g032.dtsi
> @@ -0,0 +1,86 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Base Device Tree Source for the Renesas RZ/N1D (R9A06G032)
> + *
> + * Copyright (C) 2018 Renesas Electronics Europe Limited
> + *
> + */
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/clock/rzn1-clock.h>
> +
> +/ {
> + compatible = "renesas,r9a06g032", "renesas,rzn1";
Please drop the "renesas,rzn1".
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <&clock RZN1_DIV_CA7>;
I think the clocks property should be moved to the individual CPU nodes.
> +
> + cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0>;
> + };
> +
> + cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <1>;
> + };
> + };
The rest looks OK to me (pending acceptance of the clock bindings).
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 v3 3/3] ARM: dts: imx6ull-colibri-wifi: remove operating points
From: Stefan Agner @ 2018-05-23 9:07 UTC (permalink / raw)
To: Sébastien Szymanski, Viresh Kumar
Cc: linux-arm-kernel, Rafael J . Wysocki, linux-pm, linux-kernel,
Shawn Guo, Sascha Hauer, Fabio Estevam, Rob Herring, Mark Rutland,
devicetree
In-Reply-To: <20180523043032.2htohlypynnvpiye@vireshk-i7>
On 23.05.2018 06:30, Viresh Kumar wrote:
> On 22-05-18, 08:28, Sébastien Szymanski wrote:
>> Operating points are now defined in the imx6ull.dtsi file so remove
>> them from board device trees.
>>
>> Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
>> ---
>> arch/arm/boot/dts/imx6ull-colibri-wifi.dtsi | 14 --------------
>> 1 file changed, 14 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/imx6ull-colibri-wifi.dtsi b/arch/arm/boot/dts/imx6ull-colibri-wifi.dtsi
>> index 3dffbcd50bf6..183193e8580d 100644
>> --- a/arch/arm/boot/dts/imx6ull-colibri-wifi.dtsi
>> +++ b/arch/arm/boot/dts/imx6ull-colibri-wifi.dtsi
>> @@ -20,20 +20,6 @@
>>
>> &cpu0 {
>> clock-frequency = <792000000>;
>> - operating-points = <
>> - /* kHz uV */
>> - 792000 1225000
>> - 528000 1175000
>> - 396000 1025000
>> - 198000 950000
>> - >;
>> - fsl,soc-operating-points = <
>> - /* KHz uV */
>> - 792000 1175000
>> - 528000 1175000
>> - 396000 1175000
>> - 198000 1175000
>> - >;
>> };
>>
>> &iomuxc {
>
> Maybe you should merge this with the previous patch itself.
I am with Viresh here, I rather prefer this in a single commit so it is
clear that frequencies moved to the base device tree.
Also, add a comment that frequency selection is now handled in code,
e.g.:
"The valid frequencies for a particular SKU are now selected by the
cpufreq driver according to ratings stored in OTP fuses."
But the two device tree changes with the driver do what they should do
here, so:
Tested-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Stefan Agner <stefan@agner.ch>
--
Stefan
^ permalink raw reply
* Re: [PATCH v6 4/6] ARM: dts: Renesas RZ/N1 SoC base device tree file
From: Simon Horman @ 2018-05-23 9:06 UTC (permalink / raw)
To: Michel Pollet
Cc: linux-renesas-soc, phil.edworthy, Michel Pollet, Magnus Damm,
Rob Herring, Mark Rutland, Michael Turquette, Stephen Boyd,
Geert Uytterhoeven, devicetree, linux-kernel, linux-clk
In-Reply-To: <1526983321-41949-5-git-send-email-michel.pollet@bp.renesas.com>
On Tue, May 22, 2018 at 11:01:24AM +0100, Michel Pollet wrote:
> This adds the Renesas RZ/N1D (Part #R9A06G032) SoC bare
> bone support.
>
> This currently only handles generic parts (gic, architected timer)
> and a UART.
> For simplicity sake, this also relies on the bootloader to set the
> pinctrl and clocks.
>
> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
I am marking this and the following patch as deferred
pending acceptance of the bindings it uses.
> ---
> arch/arm/boot/dts/r9a06g032.dtsi | 86 ++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 86 insertions(+)
> create mode 100644 arch/arm/boot/dts/r9a06g032.dtsi
>
> diff --git a/arch/arm/boot/dts/r9a06g032.dtsi b/arch/arm/boot/dts/r9a06g032.dtsi
> new file mode 100644
> index 0000000..c7764c7
> --- /dev/null
> +++ b/arch/arm/boot/dts/r9a06g032.dtsi
> @@ -0,0 +1,86 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Base Device Tree Source for the Renesas RZ/N1D (R9A06G032)
> + *
> + * Copyright (C) 2018 Renesas Electronics Europe Limited
> + *
> + */
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/clock/rzn1-clock.h>
> +
> +/ {
> + compatible = "renesas,r9a06g032", "renesas,rzn1";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <&clock RZN1_DIV_CA7>;
> +
> + cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0>;
> + };
> +
> + cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <1>;
> + };
> + };
> +
> + soc {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + interrupt-parent = <&gic>;
> + ranges;
> +
> + clock: clocks@4000c000 {
> + compatible = "renesas,r9a06g032-clocks",
> + "renesas,rzn1-clocks";
> + reg = <0x4000c000 0x1000>;
> + status = "okay";
> + #clock-cells = <1>;
> + };
> +
> + uart0: serial@40060000 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x40060000 0x400>;
> + interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&clock RZN1_CLK_UART0>;
> + clock-names = "baudclk";
> + status = "disabled";
> + };
> +
> + gic: gic@44101000 {
> + compatible = "arm,cortex-a7-gic", "arm,gic-400";
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + reg = <0x44101000 0x1000>, /* Distributer */
> + <0x44102000 0x2000>, /* CPU interface */
> + <0x44104000 0x2000>, /* Virt interface control */
> + <0x44106000 0x2000>; /* Virt CPU interface */
> + interrupts =
> + <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
> + };
> + };
> +
> + timer {
> + compatible = "arm,cortex-a7-timer",
> + "arm,armv7-timer";
> + interrupt-parent = <&gic>;
> + arm,cpu-registers-not-fw-configured;
> + always-on;
> + interrupts =
> + <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
> + };
> +};
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: renesas: r8a77980: add GEther support
From: Sergei Shtylyov @ 2018-05-23 9:05 UTC (permalink / raw)
To: Simon Horman
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Magnus Damm, Catalin Marinas, Will Deacon, Linux-Renesas,
Rob Herring, Geert Uytterhoeven, Linux ARM
In-Reply-To: <20180523084100.ynv3zoqrikcxem5f@verge.net.au>
Hello!
On 5/23/2018 11:41 AM, Simon Horman wrote:
>>>> Define the generic R8A77980 part of the GEther device node.
>>>>
>>>> Based on the original (and large) patch by Vladimir Barinov.
>>>>
>>>> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
>>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>>
>>> Thanks for your patch!
>>>
>>> With the below addressed:
>>> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>
>> Thanks!
>>
>>>> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
>>>> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
>>>> @@ -417,6 +417,17 @@
>>>> dma-channels = <16>;
>>>> };
>>>>
>>>> + gether: ethernet@e7400000 {
>>>> + compatible = "renesas,gether-r8a77980";
>>>> + reg = <0 0xe7400000 0 0x1000>;
>>>> + interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
>>>> + clocks = <&cpg CPG_MOD 813>;
>>>> + power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
>>>
>>> resets = <&cpg 813>;
>>
>> As usual...
>>
>>>
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> + status = "disabled";
>>>
>>> Any default phy-mode needed?
>>
>> A default "phy-mode" IMO make sense when the MAC supports a single
>> PHY interface mode. In this case, both RMII and RGMII are supported, so
>> I coulsn't choose a default...
>
> I would think making an arbitrary choice is better than no choice.
> How does the driver behave in the absence of a default?
The board DT *must* assign some "phy-mode" -- it's a required prop.
In this particular case, iff the mode is still unspecified, the driver
will select the MII mode for the RMII_MII reg (which is a reserved value for
this GEther)...
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH] cpufreq: Add Kryo CPU scaling driver
From: Ilia Lin @ 2018-05-23 9:05 UTC (permalink / raw)
To: viresh.kumar, rjw, sudeep.holla, linux
Cc: linux-clk, devicetree, linux-kernel, linux-pm, linux-arm-msm,
linux-soc, linux-arm-kernel
In-Reply-To: <1526729701-8589-1-git-send-email-ilialin@codeaurora.org>
In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO processors,
the CPU frequency subset and voltage value of each OPP varies
based on the silicon variant in use. Qualcomm Process Voltage Scaling Tables
defines the voltage and frequency value based on the msm-id in SMEM
and speedbin blown in the efuse combination.
The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
to provide the OPP framework with required information.
This is used to determine the voltage and frequency value for each OPP of
operating-points-v2 table when it is parsed by the OPP framework.
Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
---
drivers/cpufreq/Kconfig.arm | 10 +++
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/cpufreq-dt-platdev.c | 3 +
drivers/cpufreq/qcom-cpufreq-kryo.c | 163 +++++++++++++++++++++++++++++++++++
4 files changed, 177 insertions(+)
create mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index de55c7d..0bfd40e 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -124,6 +124,16 @@ config ARM_OMAP2PLUS_CPUFREQ
depends on ARCH_OMAP2PLUS
default ARCH_OMAP2PLUS
+config ARM_QCOM_CPUFREQ_KRYO
+ bool "Qualcomm Kryo based CPUFreq"
+ depends on QCOM_QFPROM
+ depends on QCOM_SMEM
+ select PM_OPP
+ help
+ This adds the CPUFreq driver for Qualcomm Kryo SoC based boards.
+
+ If in doubt, say N.
+
config ARM_S3C_CPUFREQ
bool
help
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 8d24ade..fb4a2ec 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_MACH_MVEBU_V7) += mvebu-cpufreq.o
obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o
obj-$(CONFIG_ARM_PXA2xx_CPUFREQ) += pxa2xx-cpufreq.o
obj-$(CONFIG_PXA3xx) += pxa3xx-cpufreq.o
+obj-$(CONFIG_ARM_QCOM_CPUFREQ_KRYO) += qcom-cpufreq-kryo.o
obj-$(CONFIG_ARM_S3C2410_CPUFREQ) += s3c2410-cpufreq.o
obj-$(CONFIG_ARM_S3C2412_CPUFREQ) += s3c2412-cpufreq.o
obj-$(CONFIG_ARM_S3C2416_CPUFREQ) += s3c2416-cpufreq.o
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index 3b585e4..77d6ab8 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -118,6 +118,9 @@
{ .compatible = "nvidia,tegra124", },
+ { .compatible = "qcom,apq8096", },
+ { .compatible = "qcom,msm8996", },
+
{ .compatible = "st,stih407", },
{ .compatible = "st,stih410", },
diff --git a/drivers/cpufreq/qcom-cpufreq-kryo.c b/drivers/cpufreq/qcom-cpufreq-kryo.c
new file mode 100644
index 0000000..885051e
--- /dev/null
+++ b/drivers/cpufreq/qcom-cpufreq-kryo.c
@@ -0,0 +1,163 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+/*
+ * In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO processors,
+ * the CPU frequency subset and voltage value of each OPP varies
+ * based on the silicon variant in use. Qualcomm Process Voltage Scaling Tables
+ * defines the voltage and frequency value based on the msm-id in SMEM
+ * and speedbin blown in the efuse combination.
+ * The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
+ * to provide the OPP framework with required information.
+ * This is used to determine the voltage and frequency value for each OPP of
+ * operating-points-v2 table when it is parsed by the OPP framework.
+ */
+
+#include <linux/cpu.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/nvmem-consumer.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pm_opp.h>
+#include <linux/slab.h>
+#include <linux/soc/qcom/smem.h>
+
+#define MSM_ID_SMEM 137
+
+enum _msm_id {
+ MSM8996V3 = 0xF6ul,
+ APQ8096V3 = 0x123ul,
+ MSM8996SG = 0x131ul,
+ APQ8096SG = 0x138ul,
+};
+
+enum _msm8996_version {
+ MSM8996_V3,
+ MSM8996_SG,
+ NUM_OF_MSM8996_VERSIONS,
+};
+
+static enum _msm8996_version __init qcom_cpufreq_kryo_get_msm_id(void)
+{
+ size_t len;
+ u32 *msm_id;
+ enum _msm8996_version version;
+
+ msm_id = qcom_smem_get(QCOM_SMEM_HOST_ANY, MSM_ID_SMEM, &len);
+ /* The first 4 bytes are format, next to them is the actual msm-id */
+ msm_id++;
+
+ switch ((enum _msm_id)*msm_id) {
+ case MSM8996V3:
+ case APQ8096V3:
+ version = MSM8996_V3;
+ break;
+ case MSM8996SG:
+ case APQ8096SG:
+ version = MSM8996_SG;
+ break;
+ default:
+ version = NUM_OF_MSM8996_VERSIONS;
+ }
+
+ return version;
+}
+
+static int __init qcom_cpufreq_kryo_driver_init(void)
+{
+ struct opp_table *opp_tables[NR_CPUS] = {0};
+ enum _msm8996_version msm8996_version;
+ struct nvmem_cell *speedbin_nvmem;
+ struct platform_device *pdev;
+ struct device_node *np;
+ struct device *cpu_dev;
+ unsigned cpu;
+ u8 *speedbin;
+ u32 versions;
+ size_t len;
+ int ret;
+
+ cpu_dev = get_cpu_device(0);
+ if (NULL == cpu_dev)
+ return -ENODEV;
+
+ msm8996_version = qcom_cpufreq_kryo_get_msm_id();
+ if (NUM_OF_MSM8996_VERSIONS == msm8996_version) {
+ dev_err(cpu_dev, "Not Snapdragon 820/821!");
+ return -ENODEV;
+ }
+
+ np = dev_pm_opp_of_get_opp_desc_node(cpu_dev);
+ if (IS_ERR(np))
+ return PTR_ERR(np);
+
+ if (!of_device_is_compatible(np, "operating-points-v2-kryo-cpu")) {
+ ret = -ENOENT;
+ goto free_np;
+ }
+
+ speedbin_nvmem = of_nvmem_cell_get(np, NULL);
+ if (IS_ERR(speedbin_nvmem)) {
+ ret = PTR_ERR(speedbin_nvmem);
+ dev_err(cpu_dev, "Could not get nvmem cell: %d\n", ret);
+ goto free_np;
+ }
+
+ speedbin = nvmem_cell_read(speedbin_nvmem, &len);
+ nvmem_cell_put(speedbin_nvmem);
+
+ switch (msm8996_version) {
+ case MSM8996_V3:
+ versions = 1 << (unsigned int)(*speedbin);
+ break;
+ case MSM8996_SG:
+ versions = 1 << ((unsigned int)(*speedbin) + 4);
+ break;
+ default:
+ BUG();
+ break;
+ }
+
+ for_each_possible_cpu(cpu) {
+ cpu_dev = get_cpu_device(cpu);
+ if (NULL == cpu_dev) {
+ ret = -ENODEV;
+ goto free_opp;
+ }
+
+ opp_tables[cpu] = dev_pm_opp_set_supported_hw(cpu_dev,
+ &versions, 1);
+ if (IS_ERR(opp_tables[cpu])) {
+ ret = PTR_ERR(opp_tables[cpu]);
+ dev_err(cpu_dev, "Failed to set supported hardware\n");
+ goto free_opp;
+ }
+ }
+
+ pdev = platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
+ if (!IS_ERR(pdev))
+ return 0;
+
+ ret = PTR_ERR(pdev);
+ dev_err(cpu_dev, "Failed to register platform device\n");
+
+free_opp:
+ for_each_possible_cpu(cpu) {
+ if (IS_ERR_OR_NULL(opp_tables[cpu]))
+ break;
+ dev_pm_opp_put_supported_hw(opp_tables[cpu]);
+ }
+free_np:
+ of_node_put(np);
+
+ return ret;
+}
+late_initcall(qcom_cpufreq_kryo_driver_init);
+
+MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Kryo CPUfreq driver");
+MODULE_LICENSE("GPL v2");
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v6 1/6] dt-bindings: arm: Document the RZN1D-DB board
From: Geert Uytterhoeven @ 2018-05-23 9:03 UTC (permalink / raw)
To: Michel Pollet
Cc: Linux-Renesas, Simon Horman, Phil Edworthy, Michel Pollet,
Magnus Damm, Rob Herring, Mark Rutland, Michael Turquette,
Stephen Boyd, Geert Uytterhoeven,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, linux-clk
In-Reply-To: <1526983321-41949-2-git-send-email-michel.pollet@bp.renesas.com>
On Tue, May 22, 2018 at 12:01 PM, Michel Pollet
<michel.pollet@bp.renesas.com> wrote:
> This documents the RZ/N1 bindings for the RZN1D-DB board.
>
> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
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 RFC 00/24] Lima DRM driver
From: Daniel Vetter @ 2018-05-23 9:02 UTC (permalink / raw)
To: Qiang Yu
Cc: Simon Shields, devicetree, Connor Abbott, Marek Vasut,
Neil Armstrong, Andrei Paulau, dri-devel, Vasily Khoruzhick,
Erico Nunes
In-Reply-To: <20180518092815.25280-1-yuq825@gmail.com>
On Fri, May 18, 2018 at 05:27:51PM +0800, Qiang Yu wrote:
> Kernel DRM driver for ARM Mali 400/450 GPUs.
>
> This implementation mainly take amdgpu DRM driver as reference.
>
> - Mali 4xx GPUs have two kinds of processors GP and PP. GP is for
> OpenGL vertex shader processing and PP is for fragment shader
> processing. Each processor has its own MMU so prcessors work in
> virtual address space.
> - There's only one GP but multiple PP (max 4 for mali 400 and 8
> for mali 450) in the same mali 4xx GPU. All PPs are grouped
> togather to handle a single fragment shader task divided by
> FB output tiled pixels. Mali 400 user space driver is
> responsible for assign target tiled pixels to each PP, but mali
> 450 has a HW module called DLBU to dynamically balance each
> PP's load.
> - User space driver allocate buffer object and map into GPU
> virtual address space, upload command stream and draw data with
> CPU mmap of the buffer object, then submit task to GP/PP with
> a register frame indicating where is the command stream and misc
> settings.
> - There's no command stream validation/relocation due to each user
> process has its own GPU virtual address space. GP/PP's MMU switch
> virtual address space before running two tasks from different
> user process. Error or evil user space code just get MMU fault
> or GP/PP error IRQ, then the HW/SW will be recovered.
> - Use TTM as MM. TTM_PL_TT type memory is used as the content of
> lima buffer object which is allocated from TTM page pool. all
> lima buffer object gets pinned with TTM_PL_FLAG_NO_EVICT when
> allocation, so there's no buffer eviction and swap for now. We
> need reverse engineering to see if and how GP/PP support MMU
> fault recovery (continue execution). Otherwise we have to
> pin/unpin each envolved buffer when task creation/deletion.
Curios question, but why? The one thing that ttm does help you with is
keeping track of buffer moves from/to discrete memory. You get that
benefit at the cost of a nice midlayer which tends to get in the way. If
all you do is map buffers into pagetables, then rolling your own (like
e.g. etnaviv does) is I think much better: All the other ttm functionality
(reservatsions, drm_mm allocation management, fences) has all been
extracted and is available to any driver without ttm.
-Daniel
> - Use drm_sched for GPU task schedule. Each OpenGL context should
> have a lima context object in the kernel to distinguish tasks
> from different user. drm_sched gets task from each lima context
> in a fair way.
>
> Not implemented:
> - Dump buffer support
> - Power management
> - Performance counter
>
> This patch serial just pack a pair of .c/.h files in each patch.
> For whole history of this driver's development, see:
> https://github.com/yuq/linux-lima/commits/lima-4.17-rc4
>
> Mesa driver is still in development and not ready for daily usage,
> but can run some simple tests like kmscube and glamrk2, see:
> https://github.com/yuq/mesa-lima
>
> Andrei Paulau (1):
> arm64/dts: add switch-delay for meson mali
>
> Lima Project Developers (10):
> drm/lima: add mali 4xx GPU hardware regs
> drm/lima: add lima core driver
> drm/lima: add GPU device functions
> drm/lima: add PMU related functions
> drm/lima: add PP related functions
> drm/lima: add MMU related functions
> drm/lima: add GPU virtual memory space handing
> drm/lima: add GEM related functions
> drm/lima: add GEM Prime related functions
> drm/lima: add makefile and kconfig
>
> Qiang Yu (12):
> dt-bindings: add switch-delay property for mali-utgard
> arm64/dts: add switch-delay for meson mali
> Revert "drm: Nerf the preclose callback for modern drivers"
> drm/lima: add lima uapi header
> drm/lima: add L2 cache functions
> drm/lima: add GP related functions
> drm/lima: add BCAST related function
> drm/lima: add DLBU related functions
> drm/lima: add TTM subsystem functions
> drm/lima: add buffer object functions
> drm/lima: add GPU schedule using DRM_SCHED
> drm/lima: add context related functions
>
> Simon Shields (1):
> ARM: dts: add gpu node to exynos4
>
> .../bindings/gpu/arm,mali-utgard.txt | 4 +
> arch/arm/boot/dts/exynos4.dtsi | 33 ++
> arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 1 +
> .../boot/dts/amlogic/meson-gxl-mali.dtsi | 1 +
> drivers/gpu/drm/Kconfig | 2 +
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/drm_file.c | 8 +-
> drivers/gpu/drm/lima/Kconfig | 9 +
> drivers/gpu/drm/lima/Makefile | 19 +
> drivers/gpu/drm/lima/lima_bcast.c | 65 +++
> drivers/gpu/drm/lima/lima_bcast.h | 34 ++
> drivers/gpu/drm/lima/lima_ctx.c | 143 +++++
> drivers/gpu/drm/lima/lima_ctx.h | 51 ++
> drivers/gpu/drm/lima/lima_device.c | 407 ++++++++++++++
> drivers/gpu/drm/lima/lima_device.h | 136 +++++
> drivers/gpu/drm/lima/lima_dlbu.c | 75 +++
> drivers/gpu/drm/lima/lima_dlbu.h | 37 ++
> drivers/gpu/drm/lima/lima_drv.c | 466 ++++++++++++++++
> drivers/gpu/drm/lima/lima_drv.h | 77 +++
> drivers/gpu/drm/lima/lima_gem.c | 459 ++++++++++++++++
> drivers/gpu/drm/lima/lima_gem.h | 41 ++
> drivers/gpu/drm/lima/lima_gem_prime.c | 66 +++
> drivers/gpu/drm/lima/lima_gem_prime.h | 31 ++
> drivers/gpu/drm/lima/lima_gp.c | 293 +++++++++++
> drivers/gpu/drm/lima/lima_gp.h | 34 ++
> drivers/gpu/drm/lima/lima_l2_cache.c | 98 ++++
> drivers/gpu/drm/lima/lima_l2_cache.h | 32 ++
> drivers/gpu/drm/lima/lima_mmu.c | 154 ++++++
> drivers/gpu/drm/lima/lima_mmu.h | 34 ++
> drivers/gpu/drm/lima/lima_object.c | 120 +++++
> drivers/gpu/drm/lima/lima_object.h | 87 +++
> drivers/gpu/drm/lima/lima_pmu.c | 85 +++
> drivers/gpu/drm/lima/lima_pmu.h | 30 ++
> drivers/gpu/drm/lima/lima_pp.c | 418 +++++++++++++++
> drivers/gpu/drm/lima/lima_pp.h | 37 ++
> drivers/gpu/drm/lima/lima_regs.h | 304 +++++++++++
> drivers/gpu/drm/lima/lima_sched.c | 497 ++++++++++++++++++
> drivers/gpu/drm/lima/lima_sched.h | 126 +++++
> drivers/gpu/drm/lima/lima_ttm.c | 409 ++++++++++++++
> drivers/gpu/drm/lima/lima_ttm.h | 44 ++
> drivers/gpu/drm/lima/lima_vm.c | 312 +++++++++++
> drivers/gpu/drm/lima/lima_vm.h | 73 +++
> include/drm/drm_drv.h | 23 +-
> include/uapi/drm/lima_drm.h | 195 +++++++
> 44 files changed, 5565 insertions(+), 6 deletions(-)
> create mode 100644 drivers/gpu/drm/lima/Kconfig
> create mode 100644 drivers/gpu/drm/lima/Makefile
> create mode 100644 drivers/gpu/drm/lima/lima_bcast.c
> create mode 100644 drivers/gpu/drm/lima/lima_bcast.h
> create mode 100644 drivers/gpu/drm/lima/lima_ctx.c
> create mode 100644 drivers/gpu/drm/lima/lima_ctx.h
> create mode 100644 drivers/gpu/drm/lima/lima_device.c
> create mode 100644 drivers/gpu/drm/lima/lima_device.h
> create mode 100644 drivers/gpu/drm/lima/lima_dlbu.c
> create mode 100644 drivers/gpu/drm/lima/lima_dlbu.h
> create mode 100644 drivers/gpu/drm/lima/lima_drv.c
> create mode 100644 drivers/gpu/drm/lima/lima_drv.h
> create mode 100644 drivers/gpu/drm/lima/lima_gem.c
> create mode 100644 drivers/gpu/drm/lima/lima_gem.h
> create mode 100644 drivers/gpu/drm/lima/lima_gem_prime.c
> create mode 100644 drivers/gpu/drm/lima/lima_gem_prime.h
> create mode 100644 drivers/gpu/drm/lima/lima_gp.c
> create mode 100644 drivers/gpu/drm/lima/lima_gp.h
> create mode 100644 drivers/gpu/drm/lima/lima_l2_cache.c
> create mode 100644 drivers/gpu/drm/lima/lima_l2_cache.h
> create mode 100644 drivers/gpu/drm/lima/lima_mmu.c
> create mode 100644 drivers/gpu/drm/lima/lima_mmu.h
> create mode 100644 drivers/gpu/drm/lima/lima_object.c
> create mode 100644 drivers/gpu/drm/lima/lima_object.h
> create mode 100644 drivers/gpu/drm/lima/lima_pmu.c
> create mode 100644 drivers/gpu/drm/lima/lima_pmu.h
> create mode 100644 drivers/gpu/drm/lima/lima_pp.c
> create mode 100644 drivers/gpu/drm/lima/lima_pp.h
> create mode 100644 drivers/gpu/drm/lima/lima_regs.h
> create mode 100644 drivers/gpu/drm/lima/lima_sched.c
> create mode 100644 drivers/gpu/drm/lima/lima_sched.h
> create mode 100644 drivers/gpu/drm/lima/lima_ttm.c
> create mode 100644 drivers/gpu/drm/lima/lima_ttm.h
> create mode 100644 drivers/gpu/drm/lima/lima_vm.c
> create mode 100644 drivers/gpu/drm/lima/lima_vm.h
> create mode 100644 include/uapi/drm/lima_drm.h
>
> --
> 2.17.0
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v3 1/3] cpufreq: imx6q: check speed grades for i.MX6ULL
From: Stefan Agner @ 2018-05-23 9:02 UTC (permalink / raw)
To: Sébastien Szymanski
Cc: linux-arm-kernel, Rafael J . Wysocki, Viresh Kumar, linux-pm,
linux-kernel, Shawn Guo, Sascha Hauer, Fabio Estevam, Rob Herring,
Mark Rutland, devicetree
In-Reply-To: <20180522062853.24799-1-sebastien.szymanski@armadeus.com>
On 22.05.2018 08:28, Sébastien Szymanski wrote:
> Check the max speed supported from the fuses for i.MX6ULL and update the
> operating points table accordingly.
>
> Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
Tested with a 528MHz and 792MHz rated i.MX 6ULL, looks good!
Tested-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Stefan Agner <stefan@agner.ch>
--
Stefan
> ---
>
> Changes for v3:
> - none
>
> Changes for v2:
> - none
>
> drivers/cpufreq/imx6q-cpufreq.c | 29 +++++++++++++++++++++++------
> 1 file changed, 23 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
> index 83cf631fc9bc..f094687cae52 100644
> --- a/drivers/cpufreq/imx6q-cpufreq.c
> +++ b/drivers/cpufreq/imx6q-cpufreq.c
> @@ -266,6 +266,8 @@ static void imx6q_opp_check_speed_grading(struct
> device *dev)
> }
>
> #define OCOTP_CFG3_6UL_SPEED_696MHZ 0x2
> +#define OCOTP_CFG3_6ULL_SPEED_792MHZ 0x2
> +#define OCOTP_CFG3_6ULL_SPEED_900MHZ 0x3
>
> static void imx6ul_opp_check_speed_grading(struct device *dev)
> {
> @@ -287,16 +289,30 @@ static void
> imx6ul_opp_check_speed_grading(struct device *dev)
> * Speed GRADING[1:0] defines the max speed of ARM:
> * 2b'00: Reserved;
> * 2b'01: 528000000Hz;
> - * 2b'10: 696000000Hz;
> - * 2b'11: Reserved;
> + * 2b'10: 696000000Hz on i.MX6UL, 792000000Hz on i.MX6ULL;
> + * 2b'11: 900000000Hz on i.MX6ULL only;
> * We need to set the max speed of ARM according to fuse map.
> */
> val = readl_relaxed(base + OCOTP_CFG3);
> val >>= OCOTP_CFG3_SPEED_SHIFT;
> val &= 0x3;
> - if (val != OCOTP_CFG3_6UL_SPEED_696MHZ)
> - if (dev_pm_opp_disable(dev, 696000000))
> - dev_warn(dev, "failed to disable 696MHz OPP\n");
> +
> + if (of_machine_is_compatible("fsl,imx6ul")) {
> + if (val != OCOTP_CFG3_6UL_SPEED_696MHZ)
> + if (dev_pm_opp_disable(dev, 696000000))
> + dev_warn(dev, "failed to disable 696MHz OPP\n");
> + }
> +
> + if (of_machine_is_compatible("fsl,imx6ull")) {
> + if (val != OCOTP_CFG3_6ULL_SPEED_792MHZ)
> + if (dev_pm_opp_disable(dev, 792000000))
> + dev_warn(dev, "failed to disable 792MHz OPP\n");
> +
> + if (val != OCOTP_CFG3_6ULL_SPEED_900MHZ)
> + if (dev_pm_opp_disable(dev, 900000000))
> + dev_warn(dev, "failed to disable 900MHz OPP\n");
> + }
> +
> iounmap(base);
> put_node:
> of_node_put(np);
> @@ -356,7 +372,8 @@ static int imx6q_cpufreq_probe(struct platform_device *pdev)
> goto put_reg;
> }
>
> - if (of_machine_is_compatible("fsl,imx6ul"))
> + if (of_machine_is_compatible("fsl,imx6ul") ||
> + of_machine_is_compatible("fsl,imx6ull"))
> imx6ul_opp_check_speed_grading(cpu_dev);
> else
> imx6q_opp_check_speed_grading(cpu_dev);
^ permalink raw reply
* Re: [PATCH v5 1/3] ARM: dts: tegra: Remove skeleton.dtsi and fix DTC warnings for /memory
From: Stefan Agner @ 2018-05-23 8:57 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Herring, Mark Rutland, Thierry Reding, Jonathan Hunter,
devicetree, linux-tegra, linux-kernel, Marcel Ziswiler,
Lucas Stach
In-Reply-To: <CAJKOXPdwVNtDCiow-cYFdgeUVO5UuEtgmrdmHi2SvHeoZfPupg@mail.gmail.com>
On 23.05.2018 10:34, Krzysztof Kozlowski wrote:
> On Wed, May 23, 2018 at 10:22 AM, Stefan Agner <stefan@agner.ch> wrote:
>> On 23.05.2018 09:05, Krzysztof Kozlowski wrote:
>>> On Thu, May 17, 2018 at 1:39 PM, Stefan Agner <stefan@agner.ch> wrote:
>>>> On 17.05.2018 09:45, Krzysztof Kozlowski wrote:
>>>> Could we not add
>>>>
>>>> memory { device_type = "memory"; };
>>>>
>>>> in the SoC level device trees?
>>>>
>>>> This would save device_type in all other instances.
>>>>
>>>> That is also how it is done in other places, e.g.
>>>> arch/arm/boot/dts/imx6qdl.dtsi
>>>
>>> Not really because the unit address will not match between different
>>> boards. The imx6qdl, as I see, has the same issue:
>>> - imx6qdl.dtsi defines "memory" node
>>> - imx6dl-apf6dev.dts includes the previous and defines "memory@10000000"
>>>
>>> This is wrong - two memory nodes.
>>>
>>
>> Hm I see. We could add
>>
>> memory@0 { device_type = "memory"; };
>>
>> Since the reg property is specified in the board level device tree it
>> would be still fine?
>>
>> Or probably better to provide a complete spec with length zero:
>>
>> memory@0 {
>> device_type = "memory";
>> reg = <0x0 0x0>;
>> };
>>
>> Even some boards do that and assume that boot loader will fill it
>> correctly, so that should be fine.
>
> That could be the solution although tegra30-apalis.dtsi is a problem
> here. For Tegra 114, 124 and 20 it would work fine - all boards from
> given SoC have the same address of memory (0x0 or 0x80000000). However
> for Tegra30 the Apalis did not have any memory reg before so I am not
> sure what should be used. I added 0x0. The other Tegra30 boards have
> memory@80000000.
The start address of memory is not something a board can decide on: That
is hard wired in the SoC...
In the Tegra 3 case the start address of main memory is 0x80000000.
So
memory@80000000 {
reg = <0x80000000 0x0>;
};
Should be fine.
Or you can use 0x40000000 (1GiB) since that is the smallest
configuration Toradex sells currently.
memory@80000000 {
reg = <0x80000000 0x40000000>;
};
Sorry for the hassle and thanks for fixing this!
--
Stefan
^ permalink raw reply
* Re: [PATCH v6 1/6] dt-bindings: arm: Document the RZN1D-DB board
From: Simon Horman @ 2018-05-23 8:57 UTC (permalink / raw)
To: Michel Pollet
Cc: linux-renesas-soc, phil.edworthy, Michel Pollet, Magnus Damm,
Rob Herring, Mark Rutland, Michael Turquette, Stephen Boyd,
Geert Uytterhoeven, devicetree, linux-kernel, linux-clk
In-Reply-To: <1526983321-41949-2-git-send-email-michel.pollet@bp.renesas.com>
On Tue, May 22, 2018 at 11:01:21AM +0100, Michel Pollet wrote:
> This documents the RZ/N1 bindings for the RZN1D-DB board.
>
> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
This looks fine but I will wait to see if there are other reviews before
applying.
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* [next, PATCH 6/6] usb: mtu3: fix warning of sleep in atomic context in notifier callback
From: Chunfeng Yun @ 2018-05-23 8:53 UTC (permalink / raw)
To: Greg Kroah-Hartman, Felipe Balbi
Cc: Matthias Brugger, Chunfeng Yun, linux-usb, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <1291b13a362eaa0cccd30cb8dd4f56d33e1d172d.1527065109.git.chunfeng.yun@mediatek.com>
The notifier callbacks of extcon are called in atomic context, but the
callbacks will call regulator_enable()/regulator_disable() which may
sleep caused by mutex, so use work queue to call the sleep functions.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
drivers/usb/mtu3/mtu3.h | 11 ++++++++++-
drivers/usb/mtu3/mtu3_dr.c | 44 ++++++++++++++++++++++++++++++++++++--------
2 files changed, 46 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/mtu3/mtu3.h b/drivers/usb/mtu3/mtu3.h
index a56fee0..87823ac 100644
--- a/drivers/usb/mtu3/mtu3.h
+++ b/drivers/usb/mtu3/mtu3.h
@@ -196,7 +196,12 @@ struct mtu3_gpd_ring {
* @vbus: vbus 5V used by host mode
* @edev: external connector used to detect vbus and iddig changes
* @vbus_nb: notifier for vbus detection
-* @vbus_nb: notifier for iddig(idpin) detection
+* @vbus_work : work of vbus detection notifier, used to avoid sleep in
+* notifier callback which is atomic context
+* @vbus_event : event of vbus detecion notifier
+* @id_nb : notifier for iddig(idpin) detection
+* @id_work : work of iddig detection notifier
+* @id_event : event of iddig detecion notifier
* @is_u3_drd: whether port0 supports usb3.0 dual-role device or not
* @manual_drd_enabled: it's true when supports dual-role device by debugfs
* to switch host/device modes depending on user input.
@@ -205,7 +210,11 @@ struct otg_switch_mtk {
struct regulator *vbus;
struct extcon_dev *edev;
struct notifier_block vbus_nb;
+ struct work_struct vbus_work;
+ unsigned long vbus_event;
struct notifier_block id_nb;
+ struct work_struct id_work;
+ unsigned long id_event;
bool is_u3_drd;
bool manual_drd_enabled;
};
diff --git a/drivers/usb/mtu3/mtu3_dr.c b/drivers/usb/mtu3/mtu3_dr.c
index 80083e0..8c3bbf7 100644
--- a/drivers/usb/mtu3/mtu3_dr.c
+++ b/drivers/usb/mtu3/mtu3_dr.c
@@ -174,16 +174,40 @@ static void ssusb_set_mailbox(struct otg_switch_mtk *otg_sx,
}
}
-static int ssusb_id_notifier(struct notifier_block *nb,
- unsigned long event, void *ptr)
+static void ssusb_id_work(struct work_struct *work)
{
struct otg_switch_mtk *otg_sx =
- container_of(nb, struct otg_switch_mtk, id_nb);
+ container_of(work, struct otg_switch_mtk, id_work);
- if (event)
+ if (otg_sx->id_event)
ssusb_set_mailbox(otg_sx, MTU3_ID_GROUND);
else
ssusb_set_mailbox(otg_sx, MTU3_ID_FLOAT);
+}
+
+static void ssusb_vbus_work(struct work_struct *work)
+{
+ struct otg_switch_mtk *otg_sx =
+ container_of(work, struct otg_switch_mtk, vbus_work);
+
+ if (otg_sx->vbus_event)
+ ssusb_set_mailbox(otg_sx, MTU3_VBUS_VALID);
+ else
+ ssusb_set_mailbox(otg_sx, MTU3_VBUS_OFF);
+}
+
+/*
+ * @ssusb_id_notifier is called in atomic context, but @ssusb_set_mailbox
+ * may sleep, so use work queue here
+ */
+static int ssusb_id_notifier(struct notifier_block *nb,
+ unsigned long event, void *ptr)
+{
+ struct otg_switch_mtk *otg_sx =
+ container_of(nb, struct otg_switch_mtk, id_nb);
+
+ otg_sx->id_event = event;
+ schedule_work(&otg_sx->id_work);
return NOTIFY_DONE;
}
@@ -194,10 +218,8 @@ static int ssusb_vbus_notifier(struct notifier_block *nb,
struct otg_switch_mtk *otg_sx =
container_of(nb, struct otg_switch_mtk, vbus_nb);
- if (event)
- ssusb_set_mailbox(otg_sx, MTU3_VBUS_VALID);
- else
- ssusb_set_mailbox(otg_sx, MTU3_VBUS_OFF);
+ otg_sx->vbus_event = event;
+ schedule_work(&otg_sx->vbus_work);
return NOTIFY_DONE;
}
@@ -398,6 +420,9 @@ int ssusb_otg_switch_init(struct ssusb_mtk *ssusb)
{
struct otg_switch_mtk *otg_sx = &ssusb->otg_switch;
+ INIT_WORK(&otg_sx->id_work, ssusb_id_work);
+ INIT_WORK(&otg_sx->vbus_work, ssusb_vbus_work);
+
if (otg_sx->manual_drd_enabled)
ssusb_debugfs_init(ssusb);
else
@@ -412,4 +437,7 @@ void ssusb_otg_switch_exit(struct ssusb_mtk *ssusb)
if (otg_sx->manual_drd_enabled)
ssusb_debugfs_exit(ssusb);
+
+ cancel_work_sync(&otg_sx->id_work);
+ cancel_work_sync(&otg_sx->vbus_work);
}
--
1.9.1
^ permalink raw reply related
* [next, PATCH 5/6] usb: mtu3: reset gadget when VBUS_FALL interrupt arises
From: Chunfeng Yun @ 2018-05-23 8:53 UTC (permalink / raw)
To: Greg Kroah-Hartman, Felipe Balbi
Cc: Matthias Brugger, Chunfeng Yun, linux-usb, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <1291b13a362eaa0cccd30cb8dd4f56d33e1d172d.1527065109.git.chunfeng.yun@mediatek.com>
When VBUS_FALL interrupt arises, it means U3 device is disconnected
with host, so need reset status of gadget
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
drivers/usb/mtu3/mtu3_core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/mtu3/mtu3_core.c b/drivers/usb/mtu3/mtu3_core.c
index 279f9cd..eecfd06 100644
--- a/drivers/usb/mtu3/mtu3_core.c
+++ b/drivers/usb/mtu3/mtu3_core.c
@@ -668,8 +668,10 @@ static irqreturn_t mtu3_u3_ltssm_isr(struct mtu3 *mtu)
if (ltssm & (HOT_RST_INTR | WARM_RST_INTR))
mtu3_gadget_reset(mtu);
- if (ltssm & VBUS_FALL_INTR)
+ if (ltssm & VBUS_FALL_INTR) {
mtu3_ss_func_set(mtu, false);
+ mtu3_gadget_reset(mtu);
+ }
if (ltssm & VBUS_RISE_INTR)
mtu3_ss_func_set(mtu, true);
--
1.9.1
^ permalink raw reply related
* [next, PATCH 4/6] usb: mtu3: avoid sleep in atomic context when enter test mode
From: Chunfeng Yun @ 2018-05-23 8:53 UTC (permalink / raw)
To: Greg Kroah-Hartman, Felipe Balbi
Cc: Matthias Brugger, Chunfeng Yun, linux-usb, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <1291b13a362eaa0cccd30cb8dd4f56d33e1d172d.1527065109.git.chunfeng.yun@mediatek.com>
Use readl_poll_timeout_atomic() instead of readl_poll_timeout()
in atomic context
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
drivers/usb/mtu3/mtu3_gadget_ep0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/mtu3/mtu3_gadget_ep0.c b/drivers/usb/mtu3/mtu3_gadget_ep0.c
index 0d2b1cf..25216e7 100644
--- a/drivers/usb/mtu3/mtu3_gadget_ep0.c
+++ b/drivers/usb/mtu3/mtu3_gadget_ep0.c
@@ -299,7 +299,7 @@ static int handle_test_mode(struct mtu3 *mtu, struct usb_ctrlrequest *setup)
mtu3_writel(mbase, U3D_EP0CSR, value | EP0_SETUPPKTRDY | EP0_DATAEND);
/* wait for ACK status sent by host */
- readl_poll_timeout(mbase + U3D_EP0CSR, value,
+ readl_poll_timeout_atomic(mbase + U3D_EP0CSR, value,
!(value & EP0_DATAEND), 100, 5000);
mtu3_writel(mbase, U3D_USB2_TEST_MODE, mtu->test_mode_nr);
--
1.9.1
^ permalink raw reply related
* [next, PATCH 3/6] usb: mtu3: clear test_mode flag when reset
From: Chunfeng Yun @ 2018-05-23 8:53 UTC (permalink / raw)
To: Greg Kroah-Hartman, Felipe Balbi
Cc: devicetree, linux-usb, linux-kernel, Chunfeng Yun, linux-mediatek,
Matthias Brugger, linux-arm-kernel
In-Reply-To: <1291b13a362eaa0cccd30cb8dd4f56d33e1d172d.1527065109.git.chunfeng.yun@mediatek.com>
Clear test_mode flag when the gadget is reset by host, otherwise
will affect the next test item.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
drivers/usb/mtu3/mtu3_gadget.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/mtu3/mtu3_gadget.c b/drivers/usb/mtu3/mtu3_gadget.c
index de0de01..5c60a8c 100644
--- a/drivers/usb/mtu3/mtu3_gadget.c
+++ b/drivers/usb/mtu3/mtu3_gadget.c
@@ -719,4 +719,5 @@ void mtu3_gadget_reset(struct mtu3 *mtu)
mtu->u1_enable = 0;
mtu->u2_enable = 0;
mtu->delayed_status = false;
+ mtu->test_mode = false;
}
--
1.9.1
^ permalink raw reply related
* [next, PATCH 2/6] usb: mtu3: fix uncontinuous SeqN issue after disable EP
From: Chunfeng Yun @ 2018-05-23 8:53 UTC (permalink / raw)
To: Greg Kroah-Hartman, Felipe Balbi
Cc: Matthias Brugger, Chunfeng Yun, linux-usb, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <1291b13a362eaa0cccd30cb8dd4f56d33e1d172d.1527065109.git.chunfeng.yun@mediatek.com>
Reset EP when disable it to reset data toggle for U2 EP, and
SeqN, flow control status etc for U3 EP, this can avoid
issue of uncontinuous SeqN
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
drivers/usb/mtu3/mtu3_core.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/mtu3/mtu3_core.c b/drivers/usb/mtu3/mtu3_core.c
index 65ff53a..279f9cd 100644
--- a/drivers/usb/mtu3/mtu3_core.c
+++ b/drivers/usb/mtu3/mtu3_core.c
@@ -195,6 +195,16 @@ static void mtu3_intr_enable(struct mtu3 *mtu)
mtu3_writel(mbase, U3D_DEV_LINK_INTR_ENABLE, SSUSB_DEV_SPEED_CHG_INTR);
}
+/* reset: u2 - data toggle, u3 - SeqN, flow control status etc */
+static void mtu3_ep_reset(struct mtu3_ep *mep)
+{
+ struct mtu3 *mtu = mep->mtu;
+ u32 rst_bit = EP_RST(mep->is_in, mep->epnum);
+
+ mtu3_setbits(mtu->mac_base, U3D_EP_RST, rst_bit);
+ mtu3_clrbits(mtu->mac_base, U3D_EP_RST, rst_bit);
+}
+
/* set/clear the stall and toggle bits for non-ep0 */
void mtu3_ep_stall_set(struct mtu3_ep *mep, bool set)
{
@@ -220,8 +230,7 @@ void mtu3_ep_stall_set(struct mtu3_ep *mep, bool set)
}
if (!set) {
- mtu3_setbits(mbase, U3D_EP_RST, EP_RST(mep->is_in, epnum));
- mtu3_clrbits(mbase, U3D_EP_RST, EP_RST(mep->is_in, epnum));
+ mtu3_ep_reset(mep);
mep->flags &= ~MTU3_EP_STALL;
} else {
mep->flags |= MTU3_EP_STALL;
@@ -400,6 +409,7 @@ void mtu3_deconfig_ep(struct mtu3 *mtu, struct mtu3_ep *mep)
mtu3_setbits(mbase, U3D_QIECR0, QMU_RX_DONE_INT(epnum));
}
+ mtu3_ep_reset(mep);
ep_fifo_free(mep);
dev_dbg(mtu->dev, "%s: %s\n", __func__, mep->name);
--
1.9.1
^ permalink raw reply related
* [next, PATCH 1/6] usb: mtu3: re-enable controller to accept LPM request after LPM resume
From: Chunfeng Yun @ 2018-05-23 8:53 UTC (permalink / raw)
To: Greg Kroah-Hartman, Felipe Balbi
Cc: Matthias Brugger, Chunfeng Yun, linux-usb, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek
After the controller receives a LPM request, it will reject the LPM
request, and need software to re-enable it after LPM resume if the
controller doesn't remote wakeup from L1 automatically
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
drivers/usb/mtu3/mtu3_core.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/mtu3/mtu3_core.c b/drivers/usb/mtu3/mtu3_core.c
index b1b99a8..65ff53a 100644
--- a/drivers/usb/mtu3/mtu3_core.c
+++ b/drivers/usb/mtu3/mtu3_core.c
@@ -176,7 +176,7 @@ static void mtu3_intr_enable(struct mtu3 *mtu)
mtu3_writel(mbase, U3D_LV1IESR, value);
/* Enable U2 common USB interrupts */
- value = SUSPEND_INTR | RESUME_INTR | RESET_INTR;
+ value = SUSPEND_INTR | RESUME_INTR | RESET_INTR | LPM_RESUME_INTR;
mtu3_writel(mbase, U3D_COMMON_USB_INTR_ENABLE, value);
if (mtu->is_u3_ip) {
@@ -692,6 +692,12 @@ static irqreturn_t mtu3_u2_common_isr(struct mtu3 *mtu)
if (u2comm & RESET_INTR)
mtu3_gadget_reset(mtu);
+ if (u2comm & LPM_RESUME_INTR) {
+ if (!(mtu3_readl(mbase, U3D_POWER_MANAGEMENT) & LPM_HRWE))
+ mtu3_setbits(mbase, U3D_USB20_MISC_CONTROL,
+ LPM_U3_ACK_EN);
+ }
+
return IRQ_HANDLED;
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] media: dt-bindings: media: rcar_vin: add support for r8a77965
From: Simon Horman @ 2018-05-23 8:51 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Rob Herring, devicetree, linux-media, linux-renesas-soc
In-Reply-To: <20180513185818.15359-1-niklas.soderlund+renesas@ragnatech.se>
On Sun, May 13, 2018 at 08:58:18PM +0200, Niklas Söderlund wrote:
> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> Documentation/devicetree/bindings/media/rcar_vin.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index a19517e1c669eb35..c2c57dcf73f4851b 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -21,6 +21,7 @@ on Gen3 platforms to a CSI-2 receiver.
> - "renesas,vin-r8a7794" for the R8A7794 device
> - "renesas,vin-r8a7795" for the R8A7795 device
> - "renesas,vin-r8a7796" for the R8A7796 device
> + - "renesas,vin-r8a77965" for the R8A77965 device
> - "renesas,vin-r8a77970" for the R8A77970 device
> - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible
> device.
> --
> 2.17.0
>
^ permalink raw reply
* Re: [PATCH v7 5/5] drm/rockchip: support dp training outside dp firmware
From: Enric Balletbo Serra @ 2018-05-23 8:50 UTC (permalink / raw)
To: Lin Huang
Cc: devicetree@vger.kernel.org, David Airlie, linux-kernel,
Brian Norris, Doug Anderson, dri-devel, Kishon Vijay Abraham I,
open list:ARM/Rockchip SoC..., Rob Herring, Chris Zhong,
daniel.vetter, Linux ARM
In-Reply-To: <1527061353-16902-5-git-send-email-hl@rock-chips.com>
2018-05-23 9:42 GMT+02:00 Lin Huang <hl@rock-chips.com>:
> DP firmware uses fixed phy config values to do training, but some
> boards need to adjust these values to fit for their unique hardware
> design. So get phy config values from dts and use software link training
> instead of relying on firmware, if software training fail, keep firmware
> training as a fallback if sw training fails.
>
> Signed-off-by: Chris Zhong <zyw@rock-chips.com>
> Signed-off-by: Lin Huang <hl@rock-chips.com>
> Reviewed-by: Sean Paul <seanpaul@chromium.org>
> ---
> Changes in v2:
> - update patch following Enric suggest
> Changes in v3:
> - use variable fw_training instead sw_training_success
> - base on DP SPCE, if training fail use lower link rate to retry training
> Changes in v4:
> - improve cdn_dp_get_lower_link_rate() and cdn_dp_software_train_link() follow Sean suggest
> Changes in v5:
> - fix some whitespcae issue
> Changes in v6:
> - None
> Changes in v7:
> - None
>
> drivers/gpu/drm/rockchip/Makefile | 3 +-
> drivers/gpu/drm/rockchip/cdn-dp-core.c | 24 +-
> drivers/gpu/drm/rockchip/cdn-dp-core.h | 2 +
> drivers/gpu/drm/rockchip/cdn-dp-link-training.c | 420 ++++++++++++++++++++++++
> drivers/gpu/drm/rockchip/cdn-dp-reg.c | 31 +-
> drivers/gpu/drm/rockchip/cdn-dp-reg.h | 38 ++-
> 6 files changed, 505 insertions(+), 13 deletions(-)
> create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-link-training.c
>
> diff --git a/drivers/gpu/drm/rockchip/Makefile b/drivers/gpu/drm/rockchip/Makefile
> index a314e21..b932f62 100644
> --- a/drivers/gpu/drm/rockchip/Makefile
> +++ b/drivers/gpu/drm/rockchip/Makefile
> @@ -9,7 +9,8 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
> rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
>
> rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
> -rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
> +rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o \
> + cdn-dp-link-training.o
> rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
> rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
> rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> index cce64c1..783d57a 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> @@ -629,11 +629,13 @@ static void cdn_dp_encoder_enable(struct drm_encoder *encoder)
> goto out;
> }
> }
> -
> - ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_IDLE);
> - if (ret) {
> - DRM_DEV_ERROR(dp->dev, "Failed to idle video %d\n", ret);
> - goto out;
> + if (dp->use_fw_training) {
> + ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_IDLE);
> + if (ret) {
> + DRM_DEV_ERROR(dp->dev,
> + "Failed to idle video %d\n", ret);
> + goto out;
> + }
> }
>
> ret = cdn_dp_config_video(dp);
> @@ -642,11 +644,15 @@ static void cdn_dp_encoder_enable(struct drm_encoder *encoder)
> goto out;
> }
>
> - ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_VALID);
> - if (ret) {
> - DRM_DEV_ERROR(dp->dev, "Failed to valid video %d\n", ret);
> - goto out;
> + if (dp->use_fw_training) {
> + ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_VALID);
> + if (ret) {
> + DRM_DEV_ERROR(dp->dev,
> + "Failed to valid video %d\n", ret);
> + goto out;
> + }
> }
> +
> out:
> mutex_unlock(&dp->lock);
> }
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> index 46159b2..77a9793 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> @@ -84,6 +84,7 @@ struct cdn_dp_device {
> bool connected;
> bool active;
> bool suspended;
> + bool use_fw_training;
>
> const struct firmware *fw; /* cdn dp firmware */
> unsigned int fw_version; /* cdn fw version */
> @@ -106,6 +107,7 @@ struct cdn_dp_device {
> u8 ports;
> u8 lanes;
> int active_port;
> + u8 train_set[4];
>
> u8 dpcd[DP_RECEIVER_CAP_SIZE];
> bool sink_has_audio;
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-link-training.c b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
> new file mode 100644
> index 0000000..73c3290
> --- /dev/null
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
> @@ -0,0 +1,420 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
> + * Author: Chris Zhong <zyw@rock-chips.com>
> + */
> +
> +#include <linux/device.h>
> +#include <linux/delay.h>
> +#include <linux/phy/phy.h>
> +#include <soc/rockchip/rockchip_phy_typec.h>
> +
> +#include "cdn-dp-core.h"
> +#include "cdn-dp-reg.h"
> +
> +static void cdn_dp_set_signal_levels(struct cdn_dp_device *dp)
> +{
> + struct cdn_dp_port *port = dp->port[dp->active_port];
> + struct rockchip_typec_phy *tcphy = phy_get_drvdata(port->phy);
> +
> + int rate = drm_dp_bw_code_to_link_rate(dp->link.rate);
> + u8 swing = (dp->train_set[0] & DP_TRAIN_VOLTAGE_SWING_MASK) >>
> + DP_TRAIN_VOLTAGE_SWING_SHIFT;
> + u8 pre_emphasis = (dp->train_set[0] & DP_TRAIN_PRE_EMPHASIS_MASK)
> + >> DP_TRAIN_PRE_EMPHASIS_SHIFT;
> +
> + tcphy->typec_phy_config(port->phy, rate, dp->link.num_lanes,
> + swing, pre_emphasis);
> +}
> +
> +static int cdn_dp_set_pattern(struct cdn_dp_device *dp, uint8_t dp_train_pat)
> +{
> + u32 phy_config, global_config;
> + int ret;
> + uint8_t pattern = dp_train_pat & DP_TRAINING_PATTERN_MASK;
> +
> + global_config = NUM_LANES(dp->link.num_lanes - 1) | SST_MODE |
> + GLOBAL_EN | RG_EN | ENC_RST_DIS | WR_VHSYNC_FALL;
> +
> + phy_config = DP_TX_PHY_ENCODER_BYPASS(0) |
> + DP_TX_PHY_SKEW_BYPASS(0) |
> + DP_TX_PHY_DISPARITY_RST(0) |
> + DP_TX_PHY_LANE0_SKEW(0) |
> + DP_TX_PHY_LANE1_SKEW(1) |
> + DP_TX_PHY_LANE2_SKEW(2) |
> + DP_TX_PHY_LANE3_SKEW(3) |
> + DP_TX_PHY_10BIT_ENABLE(0);
> +
> + if (pattern != DP_TRAINING_PATTERN_DISABLE) {
> + global_config |= NO_VIDEO;
> + phy_config |= DP_TX_PHY_TRAINING_ENABLE(1) |
> + DP_TX_PHY_SCRAMBLER_BYPASS(1) |
> + DP_TX_PHY_TRAINING_PATTERN(pattern);
> + }
> +
> + ret = cdn_dp_reg_write(dp, DP_FRAMER_GLOBAL_CONFIG, global_config);
> + if (ret) {
> + DRM_ERROR("fail to set DP_FRAMER_GLOBAL_CONFIG, error: %d\n",
> + ret);
> + return ret;
> + }
> +
> + ret = cdn_dp_reg_write(dp, DP_TX_PHY_CONFIG_REG, phy_config);
> + if (ret) {
> + DRM_ERROR("fail to set DP_TX_PHY_CONFIG_REG, error: %d\n",
> + ret);
> + return ret;
> + }
> +
> + ret = cdn_dp_reg_write(dp, DPTX_LANE_EN, BIT(dp->link.num_lanes) - 1);
> + if (ret) {
> + DRM_ERROR("fail to set DPTX_LANE_EN, error: %d\n", ret);
> + return ret;
> + }
> +
> + if (drm_dp_enhanced_frame_cap(dp->dpcd))
> + ret = cdn_dp_reg_write(dp, DPTX_ENHNCD, 1);
> + else
> + ret = cdn_dp_reg_write(dp, DPTX_ENHNCD, 0);
> + if (ret)
> + DRM_ERROR("failed to set DPTX_ENHNCD, error: %x\n", ret);
> +
> + return ret;
> +}
> +
> +static u8 cdn_dp_pre_emphasis_max(u8 voltage_swing)
> +{
> + switch (voltage_swing & DP_TRAIN_VOLTAGE_SWING_MASK) {
> + case DP_TRAIN_VOLTAGE_SWING_LEVEL_0:
> + return DP_TRAIN_PRE_EMPH_LEVEL_3;
> + case DP_TRAIN_VOLTAGE_SWING_LEVEL_1:
> + return DP_TRAIN_PRE_EMPH_LEVEL_2;
> + case DP_TRAIN_VOLTAGE_SWING_LEVEL_2:
> + return DP_TRAIN_PRE_EMPH_LEVEL_1;
> + default:
> + return DP_TRAIN_PRE_EMPH_LEVEL_0;
> + }
> +}
> +
> +static void cdn_dp_get_adjust_train(struct cdn_dp_device *dp,
> + uint8_t link_status[DP_LINK_STATUS_SIZE])
> +{
> + int i;
> + uint8_t v = 0, p = 0;
> + uint8_t preemph_max;
> +
> + for (i = 0; i < dp->link.num_lanes; i++) {
> + v = max(v, drm_dp_get_adjust_request_voltage(link_status, i));
> + p = max(p, drm_dp_get_adjust_request_pre_emphasis(link_status,
> + i));
> + }
> +
> + if (v >= VOLTAGE_LEVEL_2)
> + v = VOLTAGE_LEVEL_2 | DP_TRAIN_MAX_SWING_REACHED;
> +
> + preemph_max = cdn_dp_pre_emphasis_max(v);
> + if (p >= preemph_max)
> + p = preemph_max | DP_TRAIN_MAX_PRE_EMPHASIS_REACHED;
> +
> + for (i = 0; i < dp->link.num_lanes; i++)
> + dp->train_set[i] = v | p;
> +}
> +
> +/*
> + * Pick training pattern for channel equalization. Training Pattern 3 for HBR2
> + * or 1.2 devices that support it, Training Pattern 2 otherwise.
> + */
> +static u32 cdn_dp_select_chaneq_pattern(struct cdn_dp_device *dp)
> +{
> + u32 training_pattern = DP_TRAINING_PATTERN_2;
> +
> + /*
> + * cdn dp support HBR2 also support TPS3. TPS3 support is also mandatory
> + * for downstream devices that support HBR2. However, not all sinks
> + * follow the spec.
> + */
> + if (drm_dp_tps3_supported(dp->dpcd))
> + training_pattern = DP_TRAINING_PATTERN_3;
> + else
> + DRM_DEBUG_KMS("5.4 Gbps link rate without sink TPS3 support\n");
> +
> + return training_pattern;
> +}
> +
> +
> +static bool cdn_dp_link_max_vswing_reached(struct cdn_dp_device *dp)
> +{
> + int lane;
> +
> + for (lane = 0; lane < dp->link.num_lanes; lane++)
> + if ((dp->train_set[lane] & DP_TRAIN_MAX_SWING_REACHED) == 0)
> + return false;
> +
> + return true;
> +}
> +
> +static int cdn_dp_update_link_train(struct cdn_dp_device *dp)
> +{
> + int ret;
> +
> + cdn_dp_set_signal_levels(dp);
> +
> + ret = drm_dp_dpcd_write(&dp->aux, DP_TRAINING_LANE0_SET,
> + dp->train_set, dp->link.num_lanes);
> + if (ret != dp->link.num_lanes)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static int cdn_dp_set_link_train(struct cdn_dp_device *dp,
> + uint8_t dp_train_pat)
> +{
> + uint8_t buf[sizeof(dp->train_set) + 1];
> + int ret, len;
> +
> + buf[0] = dp_train_pat;
> + if ((dp_train_pat & DP_TRAINING_PATTERN_MASK) ==
> + DP_TRAINING_PATTERN_DISABLE) {
> + /* don't write DP_TRAINING_LANEx_SET on disable */
> + len = 1;
> + } else {
> + /* DP_TRAINING_LANEx_SET follow DP_TRAINING_PATTERN_SET */
> + memcpy(buf + 1, dp->train_set, dp->link.num_lanes);
> + len = dp->link.num_lanes + 1;
> + }
> +
> + ret = drm_dp_dpcd_write(&dp->aux, DP_TRAINING_PATTERN_SET,
> + buf, len);
> + if (ret != len)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static int cdn_dp_reset_link_train(struct cdn_dp_device *dp,
> + uint8_t dp_train_pat)
> +{
> + int ret;
> +
> + memset(dp->train_set, 0, sizeof(dp->train_set));
> +
> + cdn_dp_set_signal_levels(dp);
> +
> + ret = cdn_dp_set_pattern(dp, dp_train_pat);
> + if (ret)
> + return ret;
> +
> + return cdn_dp_set_link_train(dp, dp_train_pat);
> +}
> +
> +/* Enable corresponding port and start training pattern 1 */
> +static int cdn_dp_link_training_clock_recovery(struct cdn_dp_device *dp)
> +{
> + u8 voltage;
> + u8 link_status[DP_LINK_STATUS_SIZE];
> + u32 voltage_tries, max_vswing_tries;
> + int ret;
> +
> + /* clock recovery */
> + ret = cdn_dp_reset_link_train(dp, DP_TRAINING_PATTERN_1 |
> + DP_LINK_SCRAMBLING_DISABLE);
> + if (ret) {
> + DRM_ERROR("failed to start link train\n");
> + return ret;
> + }
> +
> + voltage_tries = 1;
> + max_vswing_tries = 0;
> + for (;;) {
> + drm_dp_link_train_clock_recovery_delay(dp->dpcd);
> + if (drm_dp_dpcd_read_link_status(&dp->aux, link_status) !=
> + DP_LINK_STATUS_SIZE) {
> + DRM_ERROR("failed to get link status\n");
> + return -EINVAL;
> + }
> +
> + if (drm_dp_clock_recovery_ok(link_status, dp->link.num_lanes)) {
> + DRM_DEBUG_KMS("clock recovery OK\n");
> + return 0;
> + }
> +
> + if (voltage_tries >= 5) {
> + DRM_DEBUG_KMS("Same voltage tried 5 times\n");
> + return -EINVAL;
> + }
> +
> + if (max_vswing_tries >= 1) {
> + DRM_DEBUG_KMS("Max Voltage Swing reached\n");
> + return -EINVAL;
> + }
> +
> + voltage = dp->train_set[0] & DP_TRAIN_VOLTAGE_SWING_MASK;
> +
> + /* Update training set as requested by target */
> + cdn_dp_get_adjust_train(dp, link_status);
> + if (cdn_dp_update_link_train(dp)) {
> + DRM_ERROR("failed to update link training\n");
> + return -EINVAL;
> + }
> +
> + if ((dp->train_set[0] & DP_TRAIN_VOLTAGE_SWING_MASK) ==
> + voltage)
> + ++voltage_tries;
> + else
> + voltage_tries = 1;
> +
> + if (cdn_dp_link_max_vswing_reached(dp))
> + ++max_vswing_tries;
> + }
> +}
> +
> +static int cdn_dp_link_training_channel_equalization(struct cdn_dp_device *dp)
> +{
> + int tries, ret;
> + u32 training_pattern;
> + uint8_t link_status[DP_LINK_STATUS_SIZE];
> +
> + training_pattern = cdn_dp_select_chaneq_pattern(dp);
> + training_pattern |= DP_LINK_SCRAMBLING_DISABLE;
> +
> + ret = cdn_dp_set_pattern(dp, training_pattern);
> + if (ret)
> + return ret;
> +
> + ret = cdn_dp_set_link_train(dp, training_pattern);
> + if (ret) {
> + DRM_ERROR("failed to start channel equalization\n");
> + return ret;
> + }
> +
> + for (tries = 0; tries < 5; tries++) {
> + drm_dp_link_train_channel_eq_delay(dp->dpcd);
> + if (drm_dp_dpcd_read_link_status(&dp->aux, link_status) !=
> + DP_LINK_STATUS_SIZE) {
> + DRM_ERROR("failed to get link status\n");
> + break;
> + }
> +
> + /* Make sure clock is still ok */
> + if (!drm_dp_clock_recovery_ok(link_status,
> + dp->link.num_lanes)) {
> + DRM_DEBUG_KMS("Clock recovery check failed\n");
> + break;
> + }
> +
> + if (drm_dp_channel_eq_ok(link_status, dp->link.num_lanes)) {
> + DRM_DEBUG_KMS("Channel EQ done\n");
> + return 0;
> + }
> +
> + /* Update training set as requested by target */
> + cdn_dp_get_adjust_train(dp, link_status);
> + if (cdn_dp_update_link_train(dp)) {
> + DRM_ERROR("failed to update link training\n");
> + break;
> + }
> + }
> +
> + /* Try 5 times, else fail and try at lower BW */
> + if (tries == 5)
> + DRM_DEBUG_KMS("Channel equalization failed 5 times\n");
> +
> + return -EINVAL;
> +}
> +
> +static int cdn_dp_stop_link_train(struct cdn_dp_device *dp)
> +{
> + int ret = cdn_dp_set_pattern(dp, DP_TRAINING_PATTERN_DISABLE);
> +
> + if (ret)
> + return ret;
> +
> + return cdn_dp_set_link_train(dp, DP_TRAINING_PATTERN_DISABLE);
> +}
> +
> +static int cdn_dp_get_lower_link_rate(struct cdn_dp_device *dp)
> +{
> + switch (dp->link.rate) {
> + case DP_LINK_BW_1_62:
> + return -EINVAL;
> + case DP_LINK_BW_2_7:
> + dp->link.rate = DP_LINK_BW_1_62;
> + break;
> + case DP_LINK_BW_5_4:
> + dp->link.rate = DP_LINK_BW_2_7;
> + break;
> + default:
> + dp->link.rate = DP_LINK_BW_5_4;
> + break;
> + }
> +
> + return 0;
> +}
> +
> +int cdn_dp_software_train_link(struct cdn_dp_device *dp)
> +{
> + int ret, stop_err;
> + u8 link_config[2];
> + u32 rate, sink_max, source_max;
> +
> + ret = drm_dp_dpcd_read(&dp->aux, DP_DPCD_REV, dp->dpcd,
> + sizeof(dp->dpcd));
> + if (ret < 0) {
> + DRM_DEV_ERROR(dp->dev, "Failed to get caps %d\n", ret);
> + return ret;
> + }
> +
> + source_max = dp->lanes;
> + sink_max = drm_dp_max_lane_count(dp->dpcd);
> + dp->link.num_lanes = min(source_max, sink_max);
> +
> + source_max = drm_dp_bw_code_to_link_rate(CDN_DP_MAX_LINK_RATE);
> + sink_max = drm_dp_max_link_rate(dp->dpcd);
> + rate = min(source_max, sink_max);
> + dp->link.rate = drm_dp_link_rate_to_bw_code(rate);
> +
> + link_config[0] = 0;
> + link_config[1] = 0;
> + if (dp->dpcd[DP_MAIN_LINK_CHANNEL_CODING] & 0x01)
> + link_config[1] = DP_SET_ANSI_8B10B;
> + drm_dp_dpcd_write(&dp->aux, DP_DOWNSPREAD_CTRL, link_config, 2);
> +
> + while (true) {
> +
> + /* Write the link configuration data */
> + link_config[0] = dp->link.rate;
> + link_config[1] = dp->link.num_lanes;
> + if (drm_dp_enhanced_frame_cap(dp->dpcd))
> + link_config[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
> + drm_dp_dpcd_write(&dp->aux, DP_LINK_BW_SET, link_config, 2);
> +
> + ret = cdn_dp_link_training_clock_recovery(dp);
> + if (ret) {
> + if (!cdn_dp_get_lower_link_rate(dp))
> + continue;
> +
> + DRM_ERROR("training clock recovery failed: %d\n", ret);
> + break;
> + }
> +
> + ret = cdn_dp_link_training_channel_equalization(dp);
> + if (ret) {
> + if (!cdn_dp_get_lower_link_rate(dp))
> + continue;
> +
> + DRM_ERROR("training channel eq failed: %d\n", ret);
> + break;
> + }
> +
> + break;
> + }
> +
> + stop_err = cdn_dp_stop_link_train(dp);
> + if (stop_err) {
> + DRM_ERROR("stop training fail, error: %d\n", stop_err);
> + return stop_err;
> + }
> +
> + return ret;
> +}
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> index 979355d..e1273e6 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> @@ -17,7 +17,9 @@
> #include <linux/delay.h>
> #include <linux/io.h>
> #include <linux/iopoll.h>
> +#include <linux/phy/phy.h>
> #include <linux/reset.h>
> +#include <soc/rockchip/rockchip_phy_typec.h>
>
> #include "cdn-dp-core.h"
> #include "cdn-dp-reg.h"
> @@ -189,7 +191,7 @@ static int cdn_dp_mailbox_send(struct cdn_dp_device *dp, u8 module_id,
> return 0;
> }
>
> -static int cdn_dp_reg_write(struct cdn_dp_device *dp, u16 addr, u32 val)
> +int cdn_dp_reg_write(struct cdn_dp_device *dp, u16 addr, u32 val)
> {
> u8 msg[6];
>
> @@ -609,6 +611,31 @@ int cdn_dp_train_link(struct cdn_dp_device *dp)
> {
> int ret;
>
> + /*
> + * DP firmware uses fixed phy config values to do training, but some
> + * boards need to adjust these values to fit for their unique hardware
> + * design. So if the phy is using custom config values, do software
> + * link training instead of relying on firmware, if software training
> + * fail, keep firmware training as a fallback if sw training fails.
> + */
> + ret = cdn_dp_software_train_link(dp);
> + if (ret) {
> + DRM_DEV_ERROR(dp->dev,
> + "Failed to do software training %d\n", ret);
> + goto do_fw_training;
> + }
> + ret = cdn_dp_reg_write(dp, SOURCE_HDTX_CAR, 0xf);
> + if (ret) {
> + DRM_DEV_ERROR(dp->dev,
> + "Failed to write SOURCE_HDTX_CAR register %d\n", ret);
> + goto do_fw_training;
> + }
> + dp->use_fw_training = false;
> + return 0;
> +
> +do_fw_training:
> + dp->use_fw_training = true;
> + DRM_DEV_DEBUG_KMS(dp->dev, "use fw training\n");
> ret = cdn_dp_training_start(dp);
> if (ret) {
> DRM_DEV_ERROR(dp->dev, "Failed to start training %d\n", ret);
> @@ -623,7 +650,7 @@ int cdn_dp_train_link(struct cdn_dp_device *dp)
>
> DRM_DEV_DEBUG_KMS(dp->dev, "rate:0x%x, lanes:%d\n", dp->link.rate,
> dp->link.num_lanes);
> - return ret;
> + return 0;
> }
>
> int cdn_dp_set_video_status(struct cdn_dp_device *dp, int active)
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.h b/drivers/gpu/drm/rockchip/cdn-dp-reg.h
> index 6580b11..3420771 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-reg.h
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.h
> @@ -137,7 +137,7 @@
> #define HPD_EVENT_MASK 0x211c
> #define HPD_EVENT_DET 0x2120
>
> -/* dpyx framer addr */
> +/* dptx framer addr */
> #define DP_FRAMER_GLOBAL_CONFIG 0x2200
> #define DP_SW_RESET 0x2204
> #define DP_FRAMER_TU 0x2208
> @@ -431,6 +431,40 @@
> /* Reference cycles when using lane clock as reference */
> #define LANE_REF_CYC 0x8000
>
> +/* register CM_VID_CTRL */
> +#define LANE_VID_REF_CYC(x) (((x) & (BIT(24) - 1)) << 0)
> +#define NMVID_MEAS_TOLERANCE(x) (((x) & 0xf) << 24)
> +
> +/* register DP_TX_PHY_CONFIG_REG */
> +#define DP_TX_PHY_TRAINING_ENABLE(x) ((x) & 1)
> +#define DP_TX_PHY_TRAINING_TYPE_PRBS7 (0 << 1)
> +#define DP_TX_PHY_TRAINING_TYPE_TPS1 (1 << 1)
> +#define DP_TX_PHY_TRAINING_TYPE_TPS2 (2 << 1)
> +#define DP_TX_PHY_TRAINING_TYPE_TPS3 (3 << 1)
> +#define DP_TX_PHY_TRAINING_TYPE_TPS4 (4 << 1)
> +#define DP_TX_PHY_TRAINING_TYPE_PLTPAT (5 << 1)
> +#define DP_TX_PHY_TRAINING_TYPE_D10_2 (6 << 1)
> +#define DP_TX_PHY_TRAINING_TYPE_HBR2CPAT (8 << 1)
> +#define DP_TX_PHY_TRAINING_PATTERN(x) ((x) << 1)
> +#define DP_TX_PHY_SCRAMBLER_BYPASS(x) (((x) & 1) << 5)
> +#define DP_TX_PHY_ENCODER_BYPASS(x) (((x) & 1) << 6)
> +#define DP_TX_PHY_SKEW_BYPASS(x) (((x) & 1) << 7)
> +#define DP_TX_PHY_DISPARITY_RST(x) (((x) & 1) << 8)
> +#define DP_TX_PHY_LANE0_SKEW(x) (((x) & 7) << 9)
> +#define DP_TX_PHY_LANE1_SKEW(x) (((x) & 7) << 12)
> +#define DP_TX_PHY_LANE2_SKEW(x) (((x) & 7) << 15)
> +#define DP_TX_PHY_LANE3_SKEW(x) (((x) & 7) << 18)
> +#define DP_TX_PHY_10BIT_ENABLE(x) (((x) & 1) << 21)
> +
> +/* register DP_FRAMER_GLOBAL_CONFIG */
> +#define NUM_LANES(x) ((x) & 3)
> +#define SST_MODE (0 << 2)
> +#define RG_EN (0 << 4)
> +#define GLOBAL_EN BIT(3)
> +#define NO_VIDEO BIT(5)
> +#define ENC_RST_DIS BIT(6)
> +#define WR_VHSYNC_FALL BIT(7)
> +
> enum voltage_swing_level {
> VOLTAGE_LEVEL_0,
> VOLTAGE_LEVEL_1,
> @@ -476,6 +510,7 @@ int cdn_dp_set_host_cap(struct cdn_dp_device *dp, u8 lanes, bool flip);
> int cdn_dp_event_config(struct cdn_dp_device *dp);
> u32 cdn_dp_get_event(struct cdn_dp_device *dp);
> int cdn_dp_get_hpd_status(struct cdn_dp_device *dp);
> +int cdn_dp_reg_write(struct cdn_dp_device *dp, u16 addr, u32 val);
> ssize_t cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr,
> u8 *data, u16 len);
> ssize_t cdn_dp_dpcd_read(struct cdn_dp_device *dp, u32 addr,
> @@ -489,4 +524,5 @@ int cdn_dp_config_video(struct cdn_dp_device *dp);
> int cdn_dp_audio_stop(struct cdn_dp_device *dp, struct audio_info *audio);
> int cdn_dp_audio_mute(struct cdn_dp_device *dp, bool enable);
> int cdn_dp_audio_config(struct cdn_dp_device *dp, struct audio_info *audio);
> +int cdn_dp_software_train_link(struct cdn_dp_device *dp);
> #endif /* _CDN_DP_REG_H */
> --
> 2.7.4
>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH/RFC] ARM: dts: r8a7791: Move enable-method to CPU nodes
From: Geert Uytterhoeven @ 2018-05-23 8:50 UTC (permalink / raw)
To: Simon Horman
Cc: Geert Uytterhoeven, Magnus Damm, Rob Herring, Mark Rutland,
Lorenzo Pieralisi, Stephen Boyd, Linux-Renesas, Linux ARM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List
In-Reply-To: <20180523083746.f4nkz4uhjwfgw7yz@verge.net.au>
Hi Simon,
On Wed, May 23, 2018 at 10:37 AM, Simon Horman <horms@verge.net.au> wrote:
> On Tue, May 22, 2018 at 03:29:25PM +0200, Geert Uytterhoeven wrote:
>> According to Documentation/devicetree/bindings/arm/cpus.txt, the
>> "enable-method" property should be a property of the individual CPU
>> nodes, not of the parent "cpus" node. However, on R-Car M2-W (and on
>> several other arm32 SoCs), the property is tied to the "cpus" node
>> instead.
>>
>> Secondary CPU bringup and CPU hot (un)plug work regardless, as
>> arm_dt_init_cpu_maps() falls back to looking in the "cpus" node.
>>
>> The cpuidle code does not have such a fallback, so it does not detect
>> the enable-method. Note that cpuidle does not support the
>> "renesas,apmu" enable-method yet, so for now this does not make any
>> difference.
>
> Is the implication that if we keep the current binding for cpu nodes
> then at some point we will need to update the cpuidle binding?
If we keep the current binding for cpu nodes, we indeed have to update
(common) Documentation/devicetree/bindings/arm/cpus.txt.
In addition, if we want to add renesas,apmu-based cpuidle support later,
we will have to update the common cpuidle code to look in /cpus, too.
>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>> ---
>> Arm64 and powerpc do not have such a fallback, but SH has, like arm32.
>>
>> This is marked RFC, as the alternative is to update the DT bindings to
>> keep the status quo.
>> ---
>> arch/arm/boot/dts/r8a7791.dtsi | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
>> index d568bd22d6cbd855..b214cb8f52e47109 100644
>> --- a/arch/arm/boot/dts/r8a7791.dtsi
>> +++ b/arch/arm/boot/dts/r8a7791.dtsi
>> @@ -71,7 +71,6 @@
>> cpus {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> - enable-method = "renesas,apmu";
>>
>> cpu0: cpu@0 {
>> device_type = "cpu";
>> @@ -83,6 +82,7 @@
>> clock-latency = <300000>; /* 300 us */
>> power-domains = <&sysc R8A7791_PD_CA15_CPU0>;
>> next-level-cache = <&L2_CA15>;
>> + enable-method = "renesas,apmu";
>>
>> /* kHz - uV - OPPs unknown yet */
>> operating-points = <1500000 1000000>,
>> @@ -101,6 +101,7 @@
>> clocks = <&cpg CPG_CORE R8A7791_CLK_Z>;
>> power-domains = <&sysc R8A7791_PD_CA15_CPU1>;
>> next-level-cache = <&L2_CA15>;
>> + enable-method = "renesas,apmu";
>> };
>>
>> L2_CA15: cache-controller-0 {
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
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