* Re: [PATCH] ARM: dts: cygnus: Add HWRNG node
From: Clément Péron @ 2018-06-06 17:06 UTC (permalink / raw)
To: Florian Fainelli
Cc: scott.branden, devicetree, Rob Herring, Mark Rutland,
Russell King, Ray Jui, Scott Branden, Jon Mason,
BCM Kernel Feedback, linux-arm-kernel, linux-kernel,
Clément Peron
In-Reply-To: <c7990001-00e6-d828-bafd-3d472fcfee20@gmail.com>
Hi Scott, Florian,
On Wed, 6 Jun 2018 at 18:47, Florian Fainelli <f.fainelli@gmail.com> wrote:
>
> On 06/06/201 8 09:03 AM, Scott Branden wrote:
> > Hi Clement,
> >
> >
> > On 18-06-06 02:34 AM, Clément Péron wrote:
> >> From: Clément Peron <clement.peron@devialet.com>
> >>
> >> There is a HWRNG in Broadcom Cygnus SoC, so enable it.
> >>
> >> Signed-off-by: Clément Peron <clement.peron@devialet.com>
> > Thanks for upstreaming some missing Cygnus components.
> >
> > But, the problem is the tarball release from Broadcom you are extracting
> > these changes from does not contain git history; so, you are missing the
> > original authors and signed-off's.
> > I checked our internal git repository and for this commit the author is:
> > Mohamed Ismail Abdul Packir Mohamed <mohamed-ismail.abdul@broadcom.com>
> >
> > Please adjust author and signed-off appropriately. If there are other
> > changes you are extracting from the source tarballs you have please
> > contact me so we can construct patch appropriately.
>
> If you want the original author's Signed-off-by to be preserved, why
> don't you extract it from your internal git tree and submit the patch on
> Mohamed's behalf?
>
> AFAICT what Clement is doing here is permissible given the Linux
> developer certificate of origin though I am not a lawyer of course.
> --
> Florian
Totally not my goal to steal the author and agree to keep track of the
original author
as soon as it's possible. I didn't though it was important for this
patch as the same
code is available in the dt-bindings documentation.
Actually there are still some buggy components like DSA (Arun proposed
a patch this morning)
the PWM (config and delay aren't correct) and I2C. These are mainlined
but can't be used
and need a minimal effort to correctly work on Cygnus.
Also there are some important components like USB Phy or Mailbox that
were proposed and
almost made it, but just need a small modification to be accepted.
My idea was just to submit small patches that are trivial to review.
In order to avoid keeping
lots of patches in our kernel and also have something functional when
building a mainline kernel.
Regards,
Clement
^ permalink raw reply
* [PATCH 5/5] arm64: dts: renesas: condor: add DU/LVDS/HDMI support
From: Sergei Shtylyov @ 2018-06-06 16:59 UTC (permalink / raw)
To: Simon Horman, Rob Herring, Catalin Marinas, Will Deacon,
linux-renesas-soc, devicetree
Cc: Mark Rutland, Magnus Damm, linux-arm-kernel
In-Reply-To: <4fbd0895-c1ec-41fc-912d-8306dd933997@cogentembedded.com>
Define the Condor board dependent part of the DU and LVDS device nodes.
Also add the device nodes for Thine THC63LVD1024 LVDS decoder and Analog
Devices ADV7511W HDMI transmitter...
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>
---
arch/arm64/boot/dts/renesas/r8a77980-condor.dts | 106 ++++++++++++++++++++++++
1 file changed, 106 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
@@ -45,6 +45,56 @@
regulator-boot-on;
regulator-always-on;
};
+
+ d1_8v: regulator-2 {
+ compatible = "regulator-fixed";
+ regulator-name = "D1.8V";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ hdmi-out {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con: endpoint {
+ remote-endpoint = <&adv7511_out>;
+ };
+ };
+ };
+
+ lvds-decoder {
+ compatible = "thine,thc63lvd1024";
+ vcc-supply = <&d3_3v>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ thc63lvd1024_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ thc63lvd1024_out: endpoint {
+ remote-endpoint = <&adv7511_in>;
+ };
+ };
+ };
+ };
+
+ x1_clk: x1-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <148500000>;
+ };
};
&avb {
@@ -74,6 +124,13 @@
};
};
+&du {
+ clocks = <&cpg CPG_MOD 724>,
+ <&x1_clk>;
+ clock-names = "du.0", "dclkin.0";
+ status = "okay";
+};
+
&extal_clk {
clock-frequency = <16666666>;
};
@@ -102,6 +159,55 @@
gpio-controller;
#gpio-cells = <2>;
};
+
+ hdmi@39{
+ compatible = "adi,adv7511w";
+ reg = <0x39>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
+ avdd-supply = <&d1_8v>;
+ dvdd-supply = <&d1_8v>;
+ pvdd-supply = <&d1_8v>;
+ bgvdd-supply = <&d1_8v>;
+ dvdd-3v-supply = <&d3_3v>;
+
+ adi,input-depth = <8>;
+ adi,input-colorspace = "rgb";
+ adi,input-clock = "1x";
+ adi,input-style = <1>;
+ adi,input-justification = "evenly";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ adv7511_in: endpoint {
+ remote-endpoint = <&thc63lvd1024_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ adv7511_out: endpoint {
+ remote-endpoint = <&hdmi_con>;
+ };
+ };
+ };
+ };
+};
+
+&lvds0 {
+ status = "okay";
+
+ ports {
+ port@1 {
+ lvds0_out: endpoint {
+ remote-endpoint = <&thc63lvd1024_in>;
+ };
+ };
+ };
};
&mmc0 {
^ permalink raw reply
* [PATCH 4/5] arm64: dts: renesas: r8a77980: add LVDS support
From: Sergei Shtylyov @ 2018-06-06 16:57 UTC (permalink / raw)
To: Simon Horman, Rob Herring, Catalin Marinas, Will Deacon,
linux-renesas-soc, devicetree
Cc: Mark Rutland, Magnus Damm, linux-arm-kernel
In-Reply-To: <4fbd0895-c1ec-41fc-912d-8306dd933997@cogentembedded.com>
Define the generic R8A77980 part of the LVDS device node.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -696,6 +696,35 @@
port@1 {
reg = <1>;
du_out_lvds0: endpoint {
+ remote-endpoint = <&lvds0_in>;
+ };
+ };
+ };
+ };
+
+ lvds0: lvds-encoder@feb90000 {
+ compatible = "renesas,r8a77980-lvds";
+ reg = <0 0xfeb90000 0 0x14>;
+ clocks = <&cpg CPG_MOD 727>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 727>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ lvds0_in: endpoint {
+ remote-endpoint =
+ <&du_out_lvds0>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ lvds0_out: endpoint {
};
};
};
^ permalink raw reply
* [PATCH 3/5] arm64: dts: renesas: r8a77980: add DU support
From: Sergei Shtylyov @ 2018-06-06 16:56 UTC (permalink / raw)
To: Simon Horman, Rob Herring, Catalin Marinas, Will Deacon,
linux-renesas-soc, devicetree
Cc: Mark Rutland, Magnus Damm, linux-arm-kernel
In-Reply-To: <4fbd0895-c1ec-41fc-912d-8306dd933997@cogentembedded.com>
Define the generic R8A77980 part of the DU 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>
---
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -671,6 +671,36 @@
resets = <&cpg 603>;
};
+ du: display@feb00000 {
+ compatible = "renesas,du-r8a77980",
+ "renesas,du-r8a77970";
+ reg = <0 0xfeb00000 0 0x80000>;
+ interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 724>;
+ clock-names = "du.0";
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 724>;
+ vsps = <&vspd0>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ du_out_rgb: endpoint {
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ du_out_lvds0: endpoint {
+ };
+ };
+ };
+ };
+
prr: chipid@fff00044 {
compatible = "renesas,prr";
reg = <0 0xfff00044 0 4>;
^ permalink raw reply
* [PATCH 2/5] arm64: dts: renesas: r8a77980: add VSPD support
From: Sergei Shtylyov @ 2018-06-06 16:55 UTC (permalink / raw)
To: Simon Horman, Rob Herring, Catalin Marinas, Will Deacon,
linux-renesas-soc, devicetree
Cc: Mark Rutland, Magnus Damm, linux-arm-kernel
In-Reply-To: <4fbd0895-c1ec-41fc-912d-8306dd933997@cogentembedded.com>
Describe VSPD0 in the R8A77980 device tree; it will be used by DU in
the next patch...
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>
---
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -653,6 +653,16 @@
resets = <&cpg 408>;
};
+ vspd0: vsp@fea20000 {
+ compatible = "renesas,vsp2";
+ reg = <0 0xfea20000 0 0x4000>;
+ interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 623>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 623>;
+ renesas,fcp = <&fcpvd0>;
+ };
+
fcpvd0: fcp@fea27000 {
compatible = "renesas,fcpv";
reg = <0 0xfea27000 0 0x200>;
^ permalink raw reply
* [PATCH 1/5] arm64: dts: renesas: r8a77980: add FCPVD support
From: Sergei Shtylyov @ 2018-06-06 16:54 UTC (permalink / raw)
To: Simon Horman, Rob Herring, Catalin Marinas, Will Deacon,
linux-renesas-soc, devicetree
Cc: Mark Rutland, Magnus Damm, linux-arm-kernel
In-Reply-To: <4fbd0895-c1ec-41fc-912d-8306dd933997@cogentembedded.com>
Describe FCPVD0 in the R8A77980 device tree; it will be used by VSPD0 in
the next patch...
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>
---
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -653,6 +653,14 @@
resets = <&cpg 408>;
};
+ fcpvd0: fcp@fea27000 {
+ compatible = "renesas,fcpv";
+ reg = <0 0xfea27000 0 0x200>;
+ clocks = <&cpg CPG_MOD 603>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 603>;
+ };
+
prr: chipid@fff00044 {
compatible = "renesas,prr";
reg = <0 0xfff00044 0 4>;
^ permalink raw reply
* [PATCH 0/5] Add R8A77980/Condor LVDS/HDMI support
From: Sergei Shtylyov @ 2018-06-06 16:53 UTC (permalink / raw)
To: Simon Horman, Rob Herring, Catalin Marinas, Will Deacon,
linux-renesas-soc, devicetree
Cc: Mark Rutland, Magnus Damm, linux-arm-kernel
Hello!
Reposting with the correct subject... Sorry! :-]
Here's the set of 5 patches against Simon Horman's 'renesas.git' repo's
'renesas-devel-20180604-v4.17-rc7' tag. We're adding the R8A77980 FCPVD/VSPD/
DU/LVDS device nodes and then describing the LVDS decoder and HDMI encoder
connected to the LVDS output. These patches depend on the Thine THC63LVD1024
driver and the R8A77980 LVDS support patch in order to work, and R8A77980 GPIO
DT patches in order to apply/compile...
[1/5] arm64: dts: renesas: r8a77980: add FCPVD support
[2/5] arm64: dts: renesas: r8a77980: add VSPD support
[3/5] arm64: dts: renesas: r8a77980: add DU support
[4/5] arm64: dts: renesas: r8a77980: add LVDS support
[5/5] arm64: dts: renesas: condor: add DU/LVDS/HDMI support
WBR, Sergei
^ permalink raw reply
* [PATCH 0/5] Add R8A77970/V3MSK LVDS/HDMI support
From: Sergei Shtylyov @ 2018-06-06 16:51 UTC (permalink / raw)
To: Simon Horman, Rob Herring, Catalin Marinas, Will Deacon,
linux-renesas-soc, devicetree
Cc: Mark Rutland, Magnus Damm, linux-arm-kernel
Hello!
Here's the set of 5 patches against Simon Horman's 'renesas.git' repo's
'renesas-devel-20180604-v4.17-rc7' tag. We're adding the R8A77980 FCPVD/VSPD/
DU/LVDS device nodes and then describing the LVDS decoder and HDMI encoder
connected to the LVDS output. These patches depend on the Thine THC63LVD1024
driver and the R8A77980 LVDS support patch in order to work, and R8A77980 GPIO
DT patches in order to apply/compile...
[1/5] arm64: dts: renesas: r8a77980: add FCPVD support
[2/5] arm64: dts: renesas: r8a77980: add VSPD support
[3/5] arm64: dts: renesas: r8a77980: add DU support
[4/5] arm64: dts: renesas: r8a77980: add LVDS support
[5/5] arm64: dts: renesas: condor: add DU/LVDS/HDMI support
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] ARM: dts: cygnus: Add HWRNG node
From: Florian Fainelli @ 2018-06-06 16:47 UTC (permalink / raw)
To: Scott Branden, Clément Péron, devicetree
Cc: Rob Herring, Mark Rutland, Russell King, Ray Jui, Scott Branden,
Jon Mason, bcm-kernel-feedback-list, linux-arm-kernel,
linux-kernel, Clément Peron
In-Reply-To: <c8836130-1d96-b813-4e87-5011db679ba8@broadcom.com>
On 06/06/2018 09:03 AM, Scott Branden wrote:
> Hi Clement,
>
>
> On 18-06-06 02:34 AM, Clément Péron wrote:
>> From: Clément Peron <clement.peron@devialet.com>
>>
>> There is a HWRNG in Broadcom Cygnus SoC, so enable it.
>>
>> Signed-off-by: Clément Peron <clement.peron@devialet.com>
> Thanks for upstreaming some missing Cygnus components.
>
> But, the problem is the tarball release from Broadcom you are extracting
> these changes from does not contain git history; so, you are missing the
> original authors and signed-off's.
> I checked our internal git repository and for this commit the author is:
> Mohamed Ismail Abdul Packir Mohamed <mohamed-ismail.abdul@broadcom.com>
>
> Please adjust author and signed-off appropriately. If there are other
> changes you are extracting from the source tarballs you have please
> contact me so we can construct patch appropriately.
If you want the original author's Signed-off-by to be preserved, why
don't you extract it from your internal git tree and submit the patch on
Mohamed's behalf?
AFAICT what Clement is doing here is permissible given the Linux
developer certificate of origin though I am not a lawyer of course.
--
Florian
^ permalink raw reply
* Re: [PATCH v2 5/5] venus: register separate driver for firmware device
From: Bjorn Andersson @ 2018-06-06 16:46 UTC (permalink / raw)
To: Stanimir Varbanov
Cc: Tomasz Figa, vgarodia, Hans Verkuil, Mauro Carvalho Chehab,
Rob Herring, Mark Rutland, andy.gross, Linux Media Mailing List,
Linux Kernel Mailing List, linux-arm-msm, linux-soc, devicetree,
Alexandre Courbot
In-Reply-To: <2cf4f7e8-f9e6-d62b-45a8-2c348af4aafe@linaro.org>
On Mon 04 Jun 06:56 PDT 2018, Stanimir Varbanov wrote:
> On 06/04/2018 04:18 PM, Tomasz Figa wrote:
> > On Sat, Jun 2, 2018 at 5:27 AM Vikash Garodia <vgarodia@codeaurora.org> wrote:
[..]
> >> + venus-firmware {
> >> + compatible = "qcom,venus-firmware-no-tz";
> >
> > I don't think "-no-tz" should be mentioned here in DT, since it's a
> > firmware/software detail.
>
> I have to agree with Tomasz, non-tz or tz is a software detail and it
> shouldn't be reflected in compatible string.
>
While it is software, the alternative boot and security configuration
does imply different requirements on how the driver deals with the
hardware. I'm not sure how you expect the kernel to be informed about
the abilities of the boot/security capabilities if it's not passed
through DT.
In the other cases of firmware loading for co-processors this means that
a number of additional resources (clocks, resets) needs to be specified
in the DT node; something it seems like Venus doesn't have to do.
> Also I'm not sure but what will happen if this video-firmware subnode is
> not added, do you expect that backward compatibility is satisfied for
> older venus versions?
>
I do expect that the driver should be possible to run on a 845 with the
normal TZ based security model we've seen on e.g. 820. I don't know the
details of Venus well enough to see if this differentiation would be
sufficient.
Regards,
Bjorn
^ permalink raw reply
* Re: dt-bindings: watchdog: renesas-wdt: Add support for the R8A77990 wdt
From: Geert Uytterhoeven @ 2018-06-06 16:36 UTC (permalink / raw)
To: Guenter Roeck
Cc: Geert Uytterhoeven, Wim Van Sebroeck, Rob Herring, Mark Rutland,
Linux Watchdog Mailing List,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux-Renesas, Masaharu Hayakawa
In-Reply-To: <20180606162404.GA10066@roeck-us.net>
Hi Günter,
On Wed, Jun 6, 2018 at 6:24 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> On Tue, Jun 05, 2018 at 07:18:33PM +0200, Geert Uytterhoeven wrote:
>> From: Masaharu Hayakawa <masaharu.hayakawa.ry@renesas.com>
>>
>> Document support for the Watchdog Timer (WDT) Controller in the Renesas
>> R-Car E3 (R8A77990) SoC.
>>
>> No driver update is needed.
>>
>> Signed-off-by: Masaharu Hayakawa <masaharu.hayakawa.ry@renesas.com>
>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> This refuses to apply for me. What tree is it based on ?
Yesterday's next.
Still applies fine against next-20180606, which includes watchdog next?
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 v4 1/6] Documentation: DT: Consolidate SP805 binding docs
From: Rob Herring @ 2018-06-06 16:33 UTC (permalink / raw)
To: Guenter Roeck
Cc: Rob Herring, Ray Jui, Wim Van Sebroeck, Mark Rutland,
Frank Rowand, Catalin Marinas, Will Deacon, Robin Murphy,
linux-watchdog, devicetree, linux-arm-kernel,
Linux Kernel Mailing List, BCM Kernel Feedback
In-Reply-To: <e91c75f3-f7a4-6f51-9911-7e22d5d05084@roeck-us.net>
On Wed, Jun 6, 2018 at 11:19 AM, Guenter Roeck <linux@roeck-us.net> wrote:
> On 06/05/2018 12:41 PM, Rob Herring wrote:
>>
>> On Mon, May 28, 2018 at 11:01:32AM -0700, Ray Jui wrote:
>>>
>>> Consolidate two SP805 binding documents "arm,sp805.txt" and
>>> "sp805-wdt.txt" into "arm,sp805.txt" that matches the naming of the
>>> desired compatible string to be used
>>>
>>> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
>>> ---
>>> .../devicetree/bindings/watchdog/arm,sp805.txt | 27
>>> ++++++++++++++-----
>>> .../devicetree/bindings/watchdog/sp805-wdt.txt | 31
>>> ----------------------
>>> 2 files changed, 20 insertions(+), 38 deletions(-)
>>> delete mode 100644
>>> Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
>>
>>
>> Would be good to get a ACK from FSL/NXP person on this. It looks to me
>> like the driver fetches the wrong clock as it gets the first one and the
>> driver really wants 'wdog_clk'. In any case, their dts files should be
>> updated.
>>
>
> This is really confusing, since he deleted file lists apb_pclk first.
> Does the watchdog driver need apb_pclk or wdog_clk ? That isn't clear to me.
> arch/arm64/boot/dts/hisilicon/hi3660.dtsi only provides apb_pclk, or at
> least
> it says so.
Note that that clock source is 32KHz. That is obviously a mistake
because no one clocks their bus/register interface at 32KHz. Someone
just filled in something that happened to work.
> The fsl dts files all have apb_pclk first.
It's all kind of a mess, but fortunately one we should be able to clean-up.
The compatible string changes too, but AMBA bus devices don't actually
use the compatible string as they use the ID registers to match. I
suppose some other OS could do things differently. Worth the risk to
clean-up IMO.
>
> Either case, why are two clocks asked for in the first place ? Are there
> situations where the second clock is actually used/useful ?
For clocks, the bus needs "apb_pclk" and the driver just gets the
first clock. The driver is obviously going to want the functional
clock that determines the counter rate. That should
Primecell peripherals are about the only ones that have clear specs
WRT clock inputs. Yet we've still managed to screw them up. There are
2 clocks in the spec, so the DT has (or should have) 2 clocks.
Rob
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: clock: imx6ul: Do not change the clock definition order
From: Stefan Agner @ 2018-06-06 16:27 UTC (permalink / raw)
To: Fabio Estevam
Cc: sboyd, michael, stefan.wahren, robh+dt, devicetree, linux-clk,
anson.huang, Fabio Estevam
In-Reply-To: <1527948122-32092-1-git-send-email-festevam@gmail.com>
On 02.06.2018 16:02, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> Commit f5a4670de966 ("clk: imx: Add new clo01 and clo2 controlled
> by CCOSR") introduced the CLK_CLKO definitions, but didn't put them
> at the end of the list, which may cause dtb breakage when running an old
> dtb with a newer kernel.
>
> In order to avoid that, simply add the new CLK_CKO clock definitions
> at the end of the list.
>
> Fixes: f5a4670de966 ("clk: imx: Add new clo01 and clo2 controlled by CCOSR")
> Reported-by: Stefan Wahren <stefan.wahren@i2se.com>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> Changes since v1:
> - Use 12 char for the commit id
>
> include/dt-bindings/clock/imx6ul-clock.h | 40 +++++++++++++++-----------------
> 1 file changed, 19 insertions(+), 21 deletions(-)
>
> diff --git a/include/dt-bindings/clock/imx6ul-clock.h
> b/include/dt-bindings/clock/imx6ul-clock.h
> index 9564597..0aa1d9c 100644
> --- a/include/dt-bindings/clock/imx6ul-clock.h
> +++ b/include/dt-bindings/clock/imx6ul-clock.h
> @@ -235,27 +235,25 @@
> #define IMX6UL_CLK_CSI_PODF 222
> #define IMX6UL_CLK_PLL3_120M 223
> #define IMX6UL_CLK_KPP 224
> -#define IMX6UL_CLK_CKO1_SEL 225
> -#define IMX6UL_CLK_CKO1_PODF 226
> -#define IMX6UL_CLK_CKO1 227
> -#define IMX6UL_CLK_CKO2_SEL 228
> -#define IMX6UL_CLK_CKO2_PODF 229
> -#define IMX6UL_CLK_CKO2 230
> -#define IMX6UL_CLK_CKO 231
> -
> -/* For i.MX6ULL */
> -#define IMX6ULL_CLK_ESAI_PRED 232
> -#define IMX6ULL_CLK_ESAI_PODF 233
> -#define IMX6ULL_CLK_ESAI_EXTAL 234
> -#define IMX6ULL_CLK_ESAI_MEM 235
> -#define IMX6ULL_CLK_ESAI_IPG 236
> -#define IMX6ULL_CLK_DCP_CLK 237
> -#define IMX6ULL_CLK_EPDC_PRE_SEL 238
> -#define IMX6ULL_CLK_EPDC_SEL 239
> -#define IMX6ULL_CLK_EPDC_PODF 240
> -#define IMX6ULL_CLK_EPDC_ACLK 241
> -#define IMX6ULL_CLK_EPDC_PIX 242
> -#define IMX6ULL_CLK_ESAI_SEL 243
> +#define IMX6ULL_CLK_ESAI_PRED 225
> +#define IMX6ULL_CLK_ESAI_PODF 226
> +#define IMX6ULL_CLK_ESAI_EXTAL 227
> +#define IMX6ULL_CLK_ESAI_MEM 228
> +#define IMX6ULL_CLK_ESAI_IPG 229
> +#define IMX6ULL_CLK_DCP_CLK 230
> +#define IMX6ULL_CLK_EPDC_PRE_SEL 231
> +#define IMX6ULL_CLK_EPDC_SEL 232
> +#define IMX6ULL_CLK_EPDC_PODF 233
> +#define IMX6ULL_CLK_EPDC_ACLK 234
> +#define IMX6ULL_CLK_EPDC_PIX 235
> +#define IMX6ULL_CLK_ESAI_SEL 236
Nit: Add an empty line here?
Reviewed-by: Stefan Agner <stefan@agner.ch>
> +#define IMX6UL_CLK_CKO1_SEL 237
> +#define IMX6UL_CLK_CKO1_PODF 238
> +#define IMX6UL_CLK_CKO1 239
> +#define IMX6UL_CLK_CKO2_SEL 240
> +#define IMX6UL_CLK_CKO2_PODF 241
> +#define IMX6UL_CLK_CKO2 242
> +#define IMX6UL_CLK_CKO 243
> #define IMX6UL_CLK_END 244
>
> #endif /* __DT_BINDINGS_CLOCK_IMX6UL_H */
^ permalink raw reply
* Re: dt-bindings: watchdog: renesas-wdt: Add support for the R8A77990 wdt
From: Guenter Roeck @ 2018-06-06 16:24 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Wim Van Sebroeck, Rob Herring, Mark Rutland, linux-watchdog,
devicetree, linux-renesas-soc, Masaharu Hayakawa
In-Reply-To: <1528219113-29014-1-git-send-email-geert+renesas@glider.be>
On Tue, Jun 05, 2018 at 07:18:33PM +0200, Geert Uytterhoeven wrote:
> From: Masaharu Hayakawa <masaharu.hayakawa.ry@renesas.com>
>
> Document support for the Watchdog Timer (WDT) Controller in the Renesas
> R-Car E3 (R8A77990) SoC.
>
> No driver update is needed.
>
> Signed-off-by: Masaharu Hayakawa <masaharu.hayakawa.ry@renesas.com>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
This refuses to apply for me. What tree is it based on ?
Guenter
> ---
> Documentation/devicetree/bindings/watchdog/renesas-wdt.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt b/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt
> index f24d802b8056f6c6..5d47a262474cfe0e 100644
> --- a/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt
> +++ b/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt
> @@ -16,6 +16,7 @@ Required properties:
> - "renesas,r8a7796-wdt" (R-Car M3-W)
> - "renesas,r8a77965-wdt" (R-Car M3-N)
> - "renesas,r8a77970-wdt" (R-Car V3M)
> + - "renesas,r8a77990-wdt" (R-Car E3)
> - "renesas,r8a77995-wdt" (R-Car D3)
> - "renesas,r7s72100-wdt" (RZ/A1)
> The generic compatible string must be:
^ permalink raw reply
* Re: dt-bindings: watchdog: renesas-wdt: Add support for the R8A77990 wdt
From: Guenter Roeck @ 2018-06-06 16:21 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Wim Van Sebroeck, Rob Herring, Mark Rutland, linux-watchdog,
devicetree, linux-renesas-soc, Masaharu Hayakawa
In-Reply-To: <1528219113-29014-1-git-send-email-geert+renesas@glider.be>
On Tue, Jun 05, 2018 at 07:18:33PM +0200, Geert Uytterhoeven wrote:
> From: Masaharu Hayakawa <masaharu.hayakawa.ry@renesas.com>
>
> Document support for the Watchdog Timer (WDT) Controller in the Renesas
> R-Car E3 (R8A77990) SoC.
>
> No driver update is needed.
>
> Signed-off-by: Masaharu Hayakawa <masaharu.hayakawa.ry@renesas.com>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> ---
> Documentation/devicetree/bindings/watchdog/renesas-wdt.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt b/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt
> index f24d802b8056f6c6..5d47a262474cfe0e 100644
> --- a/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt
> +++ b/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt
> @@ -16,6 +16,7 @@ Required properties:
> - "renesas,r8a7796-wdt" (R-Car M3-W)
> - "renesas,r8a77965-wdt" (R-Car M3-N)
> - "renesas,r8a77970-wdt" (R-Car V3M)
> + - "renesas,r8a77990-wdt" (R-Car E3)
> - "renesas,r8a77995-wdt" (R-Car D3)
> - "renesas,r7s72100-wdt" (RZ/A1)
> The generic compatible string must be:
^ permalink raw reply
* Re: [PATCH v4 1/6] Documentation: DT: Consolidate SP805 binding docs
From: Guenter Roeck @ 2018-06-06 16:19 UTC (permalink / raw)
To: Rob Herring, Ray Jui
Cc: Wim Van Sebroeck, Mark Rutland, Frank Rowand, Catalin Marinas,
Will Deacon, Robin Murphy, linux-watchdog, devicetree,
linux-arm-kernel, linux-kernel, bcm-kernel-feedback-list
In-Reply-To: <20180605194124.GA26885@rob-hp-laptop>
On 06/05/2018 12:41 PM, Rob Herring wrote:
> On Mon, May 28, 2018 at 11:01:32AM -0700, Ray Jui wrote:
>> Consolidate two SP805 binding documents "arm,sp805.txt" and
>> "sp805-wdt.txt" into "arm,sp805.txt" that matches the naming of the
>> desired compatible string to be used
>>
>> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
>> ---
>> .../devicetree/bindings/watchdog/arm,sp805.txt | 27 ++++++++++++++-----
>> .../devicetree/bindings/watchdog/sp805-wdt.txt | 31 ----------------------
>> 2 files changed, 20 insertions(+), 38 deletions(-)
>> delete mode 100644 Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
>
> Would be good to get a ACK from FSL/NXP person on this. It looks to me
> like the driver fetches the wrong clock as it gets the first one and the
> driver really wants 'wdog_clk'. In any case, their dts files should be
> updated.
>
This is really confusing, since he deleted file lists apb_pclk first.
Does the watchdog driver need apb_pclk or wdog_clk ? That isn't clear to me.
arch/arm64/boot/dts/hisilicon/hi3660.dtsi only provides apb_pclk, or at least
it says so. The fsl dts files all have apb_pclk first.
Either case, why are two clocks asked for in the first place ? Are there
situations where the second clock is actually used/useful ?
Guenter
> Reviewed-by: Rob Herring <robh@kernel.org>
>
> Rob
> --
> To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] remoteproc: qcom: Introduce Hexagon V5 based WCSS driver
From: Bjorn Andersson @ 2018-06-06 16:17 UTC (permalink / raw)
To: Sricharan R
Cc: Vinod, ohad, robh+dt, mark.rutland, andy.gross, david.brown,
linux-remoteproc, devicetree, linux-kernel, linux-arm-msm,
linux-soc, sibis
In-Reply-To: <3a4c102b-7228-153a-c588-b1bf00291fa8@codeaurora.org>
On Tue 05 Jun 05:56 PDT 2018, Sricharan R wrote:
> Hi Vinod,
>
> On 6/5/2018 11:49 AM, Vinod wrote:
> > On 05-06-18, 11:12, Sricharan R wrote:
> >
> >> +config QCOM_Q6V5_WCSS
> >> + tristate "Qualcomm Hexagon based WCSS Peripheral Image Loader"
> >> + depends on OF && ARCH_QCOM
> >> + depends on QCOM_SMEM
> >> + depends on RPMSG_QCOM_SMD || (COMPILE_TEST && RPMSG_QCOM_SMD=n)
> >> + depends on RPMSG_QCOM_GLINK_SMEM || RPMSG_QCOM_GLINK_SMEM=n
> >
> > Is there a reason why it depends on RPMSG_QCOM_GLINK_SMEM=n? What would
> > happen if distro wants both this and RPMSG_QCOM_GLINK_SMEM
> >
It says that QCOM_Q6V5_WCSS either must have a compatible state (i.e.
builtin vs builtin, module vs builtin, but not builtin vs module) or
that it's disabled, in which case we will hit the stub functions in
qcom_glink.h.
I.e. this prevents QCOM_Q6V5_WCSS to be compiled builtin when
RPMSG_QCOM_GLINK_SMEM is module, as this would give us both stubs and
the module.
> RPMSG_QCOM_GLINK_SMEM=n should be for the COMPILE_TEST. Probably that
> means that it should be corrected here and for ADSP, Q6V5_PIL as well.
> Bjorn, is that correct ?, should it be, below ?
>
There are platforms with SMD, those with GLINK-SMEM and those with both.
For the two first we want it to be possible only compile the specific
transport being used and the other being stubbed.
As Sricharan's particular platform uses GLINK for communicating with the
WCSS it's perfectly fine to run this particular driver with
RPMSG_QCOM_SMD=n RPMSG_QCOM_GLINK_SMEM=y/m
As such I would recommend that you drop COMPILE_TEST from above.
Regards,
Bjorn
^ permalink raw reply
* Re: [RFC v2 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info
From: Archit Taneja @ 2018-06-06 16:07 UTC (permalink / raw)
To: Heiko Stübner, robh+dt
Cc: devicetree, boris.brezillon, linux-arm-msm, briannorris,
philippe.cornu, dri-devel, nickey.yang, tomi.valkeinen,
thierry.reding, laurent.pinchart, maxime.ripard
In-Reply-To: <14557207.bzvjUjXvdQ@diego>
On Wednesday 06 June 2018 04:16 PM, Heiko Stübner wrote:
> Hi Archit,
>
> Am Mittwoch, 6. Juni 2018, 12:21:16 CEST schrieb Archit Taneja:
>> On Wednesday 06 June 2018 02:00 PM, Heiko Stübner wrote:
>>> Am Mittwoch, 6. Juni 2018, 07:59:29 CEST schrieb Archit Taneja:
>>>> On Monday 04 June 2018 05:47 PM, Heiko Stuebner wrote:
>>>>> Am Donnerstag, 18. Januar 2018, 05:53:55 CEST schrieb Archit Taneja:
>>>>>> Add binding info for peripherals that support dual-channel DSI. Add
>>>>>> corresponding optional bindings for DSI host controllers that may
>>>>>> be configured in this mode. Add an example of an I2C controlled
>>>>>> device operating in dual-channel DSI mode.
>>>>>>
>>>>>> Signed-off-by: Archit Taneja <architt@codeaurora.org>
>>>>>
>>>>> Looks like a great solution for that problem, so
>>>>> Reviewed-by: Heiko Stuebner <heiko@sntech.de>
>>>>>
>>>>> As I'm looking into that for my rk3399-scarlet device right now and
>>>>> couldn't find this patchset in the kernel yet, is it planned to
>>>>> merge or refresh these binding changes or were problems encountered.
>>>>>
>>>>> At least an Ack/Review from Rob seems to be missing.
>>>>
>>>> I forgot about these patches. Rob had reviewed the first one in
>>>> the set the second one still needed an Ack. I'll post a v3
>>>> that adds the Reviewed-bys and fixes a small typo.
>>>
>>> very nice ... because it looks like yesterday I managed to make the
>>> Rockchip dsi work in dual mode following this.
>>>
>>> But one question came up, do you really want two input ports on the panel
>>> side? I.e. hardware-wise, I guess the panel will have one 8-lane or so
>>> input thatonly gets split up on the soc side onto 2 dsi controllers?
>>
>> I think all dual DSI panels actually have 2 DSI controllers/parsers
>> within them, one on each port. The MIPI DSI spec doesn't support 8
>> lanes. Also, the pixels coming out of the host are distributed among
>> the lanes differently than what would have been the case with a
>> 'theoretical' 8 lane receiver.
>>
>> Other than that, some dual DSI panels only accept DSI commands on the
>> 'master' port, where as others expect the same command to be sent across
>> both the ports.
>>
>> Therefore, I think it's better to represent dual DSI panels having 2
>> DSI input ports.
>>
>> Your DT looks good to me.
>
> Hmm, that doesn't match up then ;-) ... as my dt uses 2 endpoints
> in one port for the dsi-links.
>
Sorry, I didn't notice you'd created two endpoints within a single port.
I don't think I'm particular about 2 ports vs 1 port with 2 endpoints.
They both seem okay to me as long as we follow it consistently. I'm
myself not 100% sure of how to figure where one should prefer endpoints
over ports. Maybe someone more familiar with the of graph bindings
could comment here.
> The issue I see with using ports and not endpoints for dual-dsi links
> is with distinguishing between input and output ports.
>
> For a panel that's easy, as you every port will be an input port and if
> you have 2, it's supposed dual-dsi. But for example I guess there might
> exist some dual-dsi-to-something bridges, where you would end up
> with say 3 (or even more) ports ... two dual-dsi inputs and 1 or more
> outputs.
Okay, I get your point here. Although, even if the remote device had
exactly 2 ports. Is it safe to assume that port #0 is an input port and
port #1 is an output port? Is that the norm?
I've at least seen one device (toshiba,tc358767 bridge) that can
actually take either DPI as input or DSI based on how you configure it.
There are 2 input ports here, port #0 for DSI and port #1 for DPI. Would
it have made sense here to have a single port and 2 endpoints here too?
>
>
> While the following argument might not be 100% valid from a dt-purity
> standpoint implementing this might get hairy for _any_ operating system,
> as you will need each panel/bridge to tell what the ports are used for.
Yeah.
>
> I.e. in my endpoint based mapping, right now I have this nice and generic
> WIP function to parse the of_graph and get the master+slave nodes:
>
> https://github.com/mmind/linux-rockchip/blob/tmp/rk3399-gru-bob-scarlet/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c#L697
> [0]
I'd tried out something locally before posting this patch, I don't have
the code for it, but I can describe the steps I took. This code expects
the panel/bridge to have 2 input ports.
1. DSI0 host driver looks up its output port, gets the remote endpoint,
and get this endpoint's parent (using
of_graph_get_remote_port_parent()). Keeps the parent device node in a
temp variable.
2. DSI1 host driver does the same thing.
3. DSI0 and DSI1 check whether their outputs are connected to the
same device. If so, they're in dual DSI mode. If not, they are
operating independently.
The positive of this approach is that we don't need to make any
assumptions about the panel/bridge's port numbers, which is great.
The negative is that our DSI controller instances now need to query
each other, which can be messy, but not too hard to implement.
I think the choice finally boils down to what makes more sense w.r.t
representing the HW correctly. We'd need Rob's comment on that.
Thanks,
Archit
>
> So I guess my proposal would be to have one port for inputs
> and one port for outputs for dsi peripherals, with possibly
> multiple endpoints in each.
>
>
> Heiko
>
>
> [0] github seems to have reliability problems, so for reference my
> parsing function:
>
> static int dw_mipi_dsi_is_dual(struct dw_mipi_dsi_rockchip *dsi,
> struct device_node **master, struct device_node **slave)
> {
> struct device_node *local_ep, *remote_port, *ep;
> struct device_node *ctrls[2] = { NULL, NULL };
> int num = 0, ret = 0, idx;
>
> /* get local panel endpoint of the dsi controller */
> local_ep = of_graph_get_endpoint_by_regs(dsi->dev->of_node, 1, 0);
> if (!local_ep) {
> DRM_DEV_ERROR(dsi->dev, "couldn't find local panel endpoint\n");
> return -ENXIO;
> }
>
> /* get panel port */
> remote_port = of_graph_get_remote_port_parent(local_ep);
> of_node_put(local_ep);
> if (!remote_port) {
> DRM_DEV_ERROR(dsi->dev, "couldn't find panel port\n");
> return -ENXIO;
> }
>
> /* check other endpoints */
> for_each_endpoint_of_node(remote_port, ep) {
> struct device_node *np = of_graph_get_remote_port_parent(ep);
>
> if (!np)
> continue;
>
> idx = of_property_read_bool(np, "clock-master");
>
> /*
> * Either master or slave already defined, drop refcnt
> * but catch errors only after the full loop.
> */
> if (ctrls[idx])
> of_node_put(np);
> else
> ctrls[idx] = np;
>
> num++;
> }
> of_node_put(remote_port);
>
> if (num > 2) {
> DRM_DEV_ERROR(dsi->dev, "too many dsi devices linked\n");
> ret = -EINVAL;
> goto cleanup;
> }
>
> /* nothing to do */
> if (num < 1) {
> ret = 0;
> goto cleanup;
> }
>
> if (!ctrls[1]) {
> DRM_DEV_ERROR(dsi->dev, "no master defined in dual-dsi\n");
> ret = -ENODEV;
> goto cleanup;
> }
>
> if (!ctrls[0]) {
> DRM_DEV_ERROR(dsi->dev, "no slave defined in dual-dsi\n");
> ret = -ENODEV;
> goto cleanup;
> }
>
> *master = ctrls[1];
> *slave = ctrls[0];
>
> return 1;
>
> cleanup:
> for (idx = 0; idx < 2; idx++)
> if (ctrls[idx])
> of_node_put(ctrls[idx]);
> return ret;
> }
>
>>> So right now I'm operating with a devicetree like
>>>
>>> &mipi_dsi {
>>>
>>> status = "okay";
>>> clock-master;
>>>
>>> ports {
>>>
>>> mipi_out: port@1 {
>>>
>>> reg = <1>;
>>>
>>> mipi_out_panel: endpoint {
>>>
>>> remote-endpoint = <&mipi_in_panel>;
>>>
>>> };
>>>
>>> };
>>>
>>> };
>>>
>>> mipi_panel: panel@0 {
>>>
>>> compatible = "innolux,p097pfg";
>>>
>>> reg = <0>;
>>> backlight = <&backlight>;
>>> enable-gpios = <&gpio4 25 GPIO_ACTIVE_HIGH>;
>>> pinctrl-names = "default";
>>> pinctrl-0 = <&display_rst_l>;
>>>
>>> port {
>>>
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>>
>>> mipi_in_panel: endpoint@0 {
>>>
>>> reg = <0>;
>>> remote-endpoint = <&mipi_out_panel>;
>>>
>>> };
>>>
>>> mipi1_in_panel: endpoint@1 {
>>>
>>> reg = <1>;
>>> remote-endpoint = <&mipi1_out_panel>;
>>>
>>> };
>>>
>>> };
>>>
>>> };
>>>
>>> };
>>>
>>> &mipi_dsi1 {
>>>
>>> status = "okay";
>>>
>>> ports {
>>>
>>> mipi1_out: port@1 {
>>>
>>> reg = <1>;
>>>
>>> mipi1_out_panel: endpoint {
>>>
>>> remote-endpoint = <&mipi1_in_panel>;
>>>
>>> };
>>>
>>> };
>>>
>>> };
>>>
>>> };
>>>
>>>
>>> I guess it is a matter of preference on what reflects the hardware
>>> best, so maybe that's Robs call?
>>>
>>>
>>> Heiko
>>>
>>>>>> ---
>>>>>> v2:
>>>>>> - Specify that clock-master is a boolean property.
>>>>>> - Drop/add unit-address and #*-cells where applicable.
>>>>>>
>>>>>> .../devicetree/bindings/display/mipi-dsi-bus.txt | 80
>>>>>> ++++++++++++++++++++++ 1 file changed, 80 insertions(+)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
>>>>>> b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt index
>>>>>> 94fb72cb916f..7a3abbedb3fa 100644
>>>>>> --- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
>>>>>> +++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
>>>>>>
>>>>>> @@ -29,6 +29,13 @@ Required properties:
>>>>>> - #size-cells: Should be 0. There are cases where it makes sense to
>>>>>> use
>>>>>> a
>>>>>>
>>>>>> different value here. See below.
>>>>>>
>>>>>> +Optional properties:
>>>>>> +- clock-master: boolean. Should be enabled if the host is being used
>>>>>> in
>>>>>> + conjunction with another DSI host to drive the same peripheral.
>>>>>> Hardware
>>>>>> + supporting such a configuration generally requires the data on both
>>>>>> the busses + to be driven by the same clock. Only the DSI host
>>>>>> instance
>>>>>> controlling this + clock should contain this property.
>>>>>> +
>>>>>>
>>>>>> DSI peripheral
>>>>>> ==============
>>>>>>
>>>>>> @@ -62,6 +69,16 @@ primary control bus, but are also connected to a DSI
>>>>>> bus (mostly for the data>>
>>>>>>
>>>>>> path). Connections between such peripherals and a DSI host can be
>>>>>> represented using the graph bindings [1], [2].
>>>>>>
>>>>>> +Peripherals that support dual channel DSI
>>>>>> +-----------------------------------------
>>>>>> +
>>>>>> +Peripherals with higher bandwidth requirements can be connected to 2
>>>>>> DSI
>>>>>> +busses. Each DSI bus/channel drives some portion of the pixel data
>>>>>> (generally +left/right half of each line of the display, or even/odd
>>>>>> lines of the display). +The graph bindings should be used to represent
>>>>>> the multiple DSI busses that are +connected to this peripheral. Each
>>>>>> DSI
>>>>>> host's output endpoint can be linked to +an input endpoint of the DSI
>>>>>> peripheral.
>>>>>> +
>>>>>>
>>>>>> [1] Documentation/devicetree/bindings/graph.txt
>>>>>> [2] Documentation/devicetree/bindings/media/video-interfaces.txt
>>>>>>
>>>>>> @@ -71,6 +88,8 @@ Examples
>>>>>>
>>>>>> with different virtual channel configurations.
>>>>>>
>>>>>> - (4) is an example of a peripheral on a I2C control bus connected
>>>>>> with
>>>>>> to
>>>>>>
>>>>>> a DSI host using of-graph bindings.
>>>>>>
>>>>>> +- (5) is an example of 2 DSI hosts driving a dual-channel DSI
>>>>>> peripheral,
>>>>>> + which uses I2C as its primary control bus.
>>>>>>
>>>>>> 1)
>>>>>>
>>>>>> dsi-host {
>>>>>>
>>>>>> @@ -153,3 +172,64 @@ Examples
>>>>>>
>>>>>> };
>>>>>>
>>>>>> };
>>>>>>
>>>>>> };
>>>>>>
>>>>>> +
>>>>>> +5)
>>>>>> + i2c-host {
>>>>>> + dsi-bridge@35 {
>>>>>> + compatible = "...";
>>>>>> + reg = <0x35>;
>>>>>> +
>>>>>> + ports {
>>>>>> + #address-cells = <1>;
>>>>>> + #size-cells = <0>;
>>>>>> +
>>>>>> + port@0 {
>>>>>> + reg = <0>;
>>>>>> + dsi0_in: endpoint {
>>>>>> + remote-endpoint = <&dsi0_out>;
>>>>>> + };
>>>>>> + };
>>>>>> +
>>>>>> + port@1 {
>>>>>> + reg = <1>;
>>>>>> + dsi1_in: endpoint {
>>>>>> + remote-endpoint = <&dsi1_out>;
>>>>>> + };
>>>>>> + };
>>>>>> + };
>>>>>> + };
>>>>>> + };
>>>>>> +
>>>>>> + dsi0-host {
>>>>>> + ...
>>>>>> +
>>>>>> + /*
>>>>>> + * this DSI instance drives the clock for both the host
>>>>>> + * controllers
>>>>>> + */
>>>>>> + clock-master;
>>>>>> +
>>>>>> + ports {
>>>>>> + ...
>>>>>> +
>>>>>> + port {
>>>>>> + dsi0_out: endpoint {
>>>>>> + remote-endpoint = <&dsi0_in>;
>>>>>> + };
>>>>>> + };
>>>>>> + };
>>>>>> + };
>>>>>> +
>>>>>> + dsi1-host {
>>>>>> + ...
>>>>>> +
>>>>>> + ports {
>>>>>> + ...
>>>>>> +
>>>>>> + port {
>>>>>> + dsi1_out: endpoint {
>>>>>> + remote-endpoint = <&dsi1_in>;
>>>>>> + };
>>>>>> + };
>>>>>> + };
>>>>>> + };
>>>>>
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm"
>>>>> in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH] ARM: dts: cygnus: Add HWRNG node
From: Scott Branden @ 2018-06-06 16:03 UTC (permalink / raw)
To: Clément Péron, devicetree
Cc: Rob Herring, Mark Rutland, Russell King, Ray Jui, Scott Branden,
Jon Mason, bcm-kernel-feedback-list, linux-arm-kernel,
linux-kernel, Clément Peron
In-Reply-To: <20180606093441.16483-1-peron.clem@gmail.com>
Hi Clement,
On 18-06-06 02:34 AM, Clément Péron wrote:
> From: Clément Peron <clement.peron@devialet.com>
>
> There is a HWRNG in Broadcom Cygnus SoC, so enable it.
>
> Signed-off-by: Clément Peron <clement.peron@devialet.com>
Thanks for upstreaming some missing Cygnus components.
But, the problem is the tarball release from Broadcom you are extracting
these changes from does not contain git history; so, you are missing the
original authors and signed-off's.
I checked our internal git repository and for this commit the author is:
Mohamed Ismail Abdul Packir Mohamed <mohamed-ismail.abdul@broadcom.com>
Please adjust author and signed-off appropriately. If there are other
changes you are extracting from the source tarballs you have please
contact me so we can construct patch appropriately.
Regards,
Scott
> ---
> arch/arm/boot/dts/bcm-cygnus.dtsi | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
> index 1cee40ac4613..b7178e84d56d 100644
> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
> @@ -452,6 +452,11 @@
> status = "disabled";
> };
>
> + hwrng: hwrng@18032000 {
> + compatible = "brcm,iproc-rng200";
> + reg = <0x18032000 0x28>;
> + };
> +
> sdhci0: sdhci@18041000 {
> compatible = "brcm,sdhci-iproc-cygnus";
> reg = <0x18041000 0x100>;
^ permalink raw reply
* [PATCH 8/8] ARM: dts: am335x-sl50: enable tsadc on SL50 board.
From: Enric Balletbo i Serra @ 2018-06-06 15:54 UTC (permalink / raw)
To: linux-kernel
Cc: kernel, devicetree, Benoît Cousson, Rob Herring,
Tony Lindgren, Mark Rutland, linux-omap
In-Reply-To: <20180606155413.23542-1-enric.balletbo@collabora.com>
The tsadc is used to read various voltages on the board, so enable it
to be able to read these voltages from userspace.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
arch/arm/boot/dts/am335x-sl50.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-sl50.dts b/arch/arm/boot/dts/am335x-sl50.dts
index e11a6def36a4..522fc7decfd7 100644
--- a/arch/arm/boot/dts/am335x-sl50.dts
+++ b/arch/arm/boot/dts/am335x-sl50.dts
@@ -729,3 +729,11 @@
&lcdc {
status = "okay";
};
+
+&tscadc {
+ status = "okay";
+};
+
+&am335x_adc {
+ ti,adc-channels = <0 1 2 3 4 5 6 7>;
+};
--
2.17.1
^ permalink raw reply related
* [PATCH 7/8] ARM: dts: am335x-sl50: fix label names for all LEDs.
From: Enric Balletbo i Serra @ 2018-06-06 15:54 UTC (permalink / raw)
To: linux-kernel
Cc: kernel, devicetree, Benoît Cousson, Rob Herring,
Tony Lindgren, Mark Rutland, linux-omap
In-Reply-To: <20180606155413.23542-1-enric.balletbo@collabora.com>
Fix the label for all LEDs, we made a mistake setting the label names on
all LEDs, where says green should say red, and viceversa, where says red
should be green.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
arch/arm/boot/dts/am335x-sl50.dts | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-sl50.dts b/arch/arm/boot/dts/am335x-sl50.dts
index 495a4a0be25c..e11a6def36a4 100644
--- a/arch/arm/boot/dts/am335x-sl50.dts
+++ b/arch/arm/boot/dts/am335x-sl50.dts
@@ -33,25 +33,25 @@
pinctrl-0 = <&led_pins>;
led0 {
- label = "sl50:green:usr0";
+ label = "sl50:red:usr0";
gpios = <&gpio1 21 GPIO_ACTIVE_LOW>;
default-state = "off";
};
led1 {
- label = "sl50:red:usr1";
+ label = "sl50:green:usr1";
gpios = <&gpio1 22 GPIO_ACTIVE_LOW>;
default-state = "off";
};
led2 {
- label = "sl50:green:usr2";
+ label = "sl50:red:usr2";
gpios = <&gpio1 23 GPIO_ACTIVE_LOW>;
default-state = "off";
};
led3 {
- label = "sl50:red:usr3";
+ label = "sl50:green:usr3";
gpios = <&gpio1 24 GPIO_ACTIVE_LOW>;
default-state = "off";
};
@@ -430,6 +430,12 @@
/* PDI Bus - Battery system */
AM33XX_IOPAD(0x840, PIN_INPUT_PULLUP | MUX_MODE7) /* nBattReset gpmc_a0.gpio1_16 */
AM33XX_IOPAD(0x83c, PIN_INPUT_PULLUP | MUX_MODE7) /* BattPDIData gpmc_ad15.gpio1_15 */
+ /* FPGA */
+ AM33XX_IOPAD(0x820, PIN_INPUT_PULLUP | MUX_MODE7) /* FPGA_DONE - gpmc_ad8.gpio0_22 */
+ AM33XX_IOPAD(0x840, PIN_INPUT_PULLUP | MUX_MODE7) /* FPGA_NRST - gpmc_a0.gpio1_16 */
+ AM33XX_IOPAD(0x844, PIN_INPUT_PULLDOWN | MUX_MODE7) /* FPGA_RUN - gpmc_a1.gpio1_17 */
+ AM33XX_IOPAD(0x864, PIN_INPUT_PULLUP | MUX_MODE7) /* ENFPGA - gpmc_a9.gpio1_25 */
+ AM33XX_IOPAD(0x868, PIN_INPUT_PULLDOWN | MUX_MODE7) /* FPGA_PROGRAM - gpmc_a10.gpio1_26 */
>;
};
};
--
2.17.1
^ permalink raw reply related
* [PATCH 6/8] ARM: dts: am335x-sl50: use audio-graph-card for sound.
From: Enric Balletbo i Serra @ 2018-06-06 15:54 UTC (permalink / raw)
To: linux-kernel
Cc: kernel, devicetree, Benoît Cousson, Rob Herring,
Tony Lindgren, Mark Rutland, linux-omap
In-Reply-To: <20180606155413.23542-1-enric.balletbo@collabora.com>
audio-graph-card is recommended for audio bindings. Let's change to it and
improve the support by adding the Amplifier configuration and the clock
enable control.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
arch/arm/boot/dts/am335x-sl50.dts | 111 +++++++++++++++++++++---------
1 file changed, 80 insertions(+), 31 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-sl50.dts b/arch/arm/boot/dts/am335x-sl50.dts
index b15690155159..495a4a0be25c 100644
--- a/arch/arm/boot/dts/am335x-sl50.dts
+++ b/arch/arm/boot/dts/am335x-sl50.dts
@@ -105,11 +105,20 @@
#size-cells = <0>;
/* audio external oscillator */
- tlv320aic3x_mclk: oscillator@0 {
+ audio_mclk_fixed: oscillator@0 {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <24576000>; /* 24.576MHz */
};
+
+ audio_mclk: audio_mclk_gate@0 {
+ compatible = "gpio-gate-clock";
+ #clock-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&audio_mclk_pins>;
+ clocks = <&audio_mclk_fixed>;
+ enable-gpios = <&gpio1 27 0>;
+ };
};
panel: lcd_panel {
@@ -152,19 +161,29 @@
};
sound {
- compatible = "ti,da830-evm-audio";
- ti,model = "AM335x-SL50";
- ti,audio-codec = <&audio_codec>;
- ti,mcasp-controller = <&mcasp0>;
+ compatible = "audio-graph-card";
+ label = "sound-card";
+ pinctrl-names = "default";
+ pinctrl-0 = <&audio_pa_pins>;
+
+ widgets = "Headphone", "Headphone Jack",
+ "Speaker", "Speaker External",
+ "Line", "Line In",
+ "Microphone", "Microphone Jack";
- clocks = <&tlv320aic3x_mclk>;
- clock-names = "mclk";
+ routing = "Headphone Jack", "HPLOUT",
+ "Headphone Jack", "HPROUT",
+ "Amplifier", "MONO_LOUT",
+ "Speaker External", "Amplifier",
+ "LINE1R", "Line In",
+ "LINE1L", "Line In",
+ "MIC3L", "Microphone Jack",
+ "MIC3R", "Microphone Jack",
+ "Microphone Jack", "Mic Bias";
- ti,audio-routing =
- "Headphone Jack", "HPLOUT",
- "Headphone Jack", "HPROUT",
- "LINE1R", "Line In",
- "LINE1L", "Line In";
+ dais = <&cpu_port>;
+
+ pa-gpios = <&gpio3 18 GPIO_ACTIVE_HIGH>;
};
emmc_pwrseq: pwrseq@0 {
@@ -194,6 +213,28 @@
pinctrl-names = "default";
pinctrl-0 = <&lwb_pins>;
+ audio_pins: pinmux_audio_pins {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x9ac, PIN_INPUT_PULLDOWN | MUX_MODE0) /* mcasp0_ahcklx.mcasp0_ahclkx */
+ AM33XX_IOPAD(0x994, PIN_INPUT_PULLDOWN | MUX_MODE0) /* mcasp0_fsx.mcasp0_fsx */
+ AM33XX_IOPAD(0x990, PIN_INPUT_PULLDOWN | MUX_MODE0) /* mcasp0_aclkx.mcasp0_aclkx */
+ AM33XX_IOPAD(0x998, PIN_INPUT_PULLDOWN | MUX_MODE0) /* mcasp0_axr0.mcasp0_axr0 */
+ AM33XX_IOPAD(0x99c, PIN_OUTPUT_PULLDOWN | MUX_MODE2) /* mcasp0_ahclkr.mcasp0_axr2 */
+ >;
+ };
+
+ audio_pa_pins: pinmux_audio_pa_pins {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x9a0, PIN_INPUT_PULLDOWN | MUX_MODE7) /* SoundPA_en - mcasp0_aclkr.gpio3_18 */
+ >;
+ };
+
+ audio_mclk_pins: pinmux_audio_mclk_pins {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x86c, PIN_INPUT_PULLDOWN | MUX_MODE7) /* gpmc_a11.gpio1_27 */
+ >;
+ };
+
backlight0_pins: pinmux_backlight0_pins {
pinctrl-single,pins = <
AM33XX_IOPAD(0x898, PIN_OUTPUT | MUX_MODE7) /* gpmc_wen.gpio2_4 */
@@ -358,16 +399,6 @@
>;
};
- audio_pins: pinmux_audio_pins {
- pinctrl-single,pins = <
- AM33XX_IOPAD(0x9ac, PIN_INPUT_PULLDOWN | MUX_MODE0) /* mcasp0_ahcklx.mcasp0_ahclkx */
- AM33XX_IOPAD(0x994, PIN_INPUT_PULLDOWN | MUX_MODE0) /* mcasp0_fsx.mcasp0_fsx */
- AM33XX_IOPAD(0x990, PIN_INPUT_PULLDOWN | MUX_MODE0) /* mcasp0_aclkx.mcasp0_aclkx */
- AM33XX_IOPAD(0x998, PIN_INPUT_PULLDOWN | MUX_MODE0) /* mcasp0_axr0.mcasp0_axr0 */
- AM33XX_IOPAD(0x99c, PIN_OUTPUT_PULLDOWN | MUX_MODE2) /* mcasp0_ahclkr.mcasp0_axr2 */
- >;
- };
-
ehrpwm1_pins: pinmux_ehrpwm1a_pins {
pinctrl-single,pins = <
AM33XX_IOPAD(0x848, PIN_OUTPUT | MUX_MODE6) /* gpmc_a2.ehrpwm1a */
@@ -393,7 +424,6 @@
lwb_pins: pinmux_lwb_pins {
pinctrl-single,pins = <
- AM33XX_IOPAD(0x9a4, PIN_OUTPUT | MUX_MODE7) /* SoundPA_en - mcasp0_fsr.gpio3_19 */
AM33XX_IOPAD(0x830, PIN_INPUT_PULLUP | MUX_MODE7) /* nKbdInt - gpmc_ad12.gpio1_12 */
AM33XX_IOPAD(0x834, PIN_INPUT_PULLUP | MUX_MODE7) /* nKbdReset - gpmc_ad13.gpio1_13 */
AM33XX_IOPAD(0x844, PIN_INPUT_PULLUP | MUX_MODE7) /* USB1_enPower - gpmc_a1.gpio1_17 */
@@ -448,12 +478,21 @@
audio_codec: tlv320aic3106@1b {
status = "okay";
compatible = "ti,tlv320aic3106";
+ #sound-dai-cells = <0>;
reg = <0x1b>;
+ ai3x-micbias-vg = <2>; /* 2.5V */
AVDD-supply = <&ldo4_reg>;
IOVDD-supply = <&ldo4_reg>;
DRVDD-supply = <&ldo4_reg>;
DVDD-supply = <&ldo3_reg>;
+
+ codec_port: port {
+ codec_endpoint: endpoint {
+ remote-endpoint = <&cpu_endpoint>;
+ clocks = <&audio_mclk>;
+ };
+ };
};
/* Ambient Light Sensor */
@@ -519,17 +558,27 @@
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&audio_pins>;
-
+ #sound-dai-cells = <0>;
op-mode = <0>; /* MCASP_ISS_MODE */
tdm-slots = <2>;
- serial-dir = <
- 2 0 1 0
- 0 0 0 0
- 0 0 0 0
- 0 0 0 0
+ /* 4 serializers */
+ serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */
+ 0 0 1 2
>;
- tx-num-evt = <1>;
- rx-num-evt = <1>;
+ tx-num-evt = <32>;
+ rx-num-evt = <32>;
+
+ cpu_port: port {
+ cpu_endpoint: endpoint {
+ remote-endpoint = <&codec_endpoint>;
+
+ dai-format = "dsp_b";
+ bitclock-master = <&codec_port>;
+ frame-master = <&codec_port>;
+ bitclock-inversion;
+ clocks = <&audio_mclk>;
+ };
+ };
};
&uart0 {
--
2.17.1
^ permalink raw reply related
* [PATCH 5/8] ARM: dts: am335x-sl50: add support for DS1339 Real Time Clock.
From: Enric Balletbo i Serra @ 2018-06-06 15:54 UTC (permalink / raw)
To: linux-kernel
Cc: kernel, devicetree, Benoît Cousson, Rob Herring,
Tony Lindgren, Mark Rutland, linux-omap
In-Reply-To: <20180606155413.23542-1-enric.balletbo@collabora.com>
Production hardware will go with the DS1339 RTC chip, so replace the old
for the new one and also add the nIRQ pin to be able to properly wakeup
the system from suspend.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
arch/arm/boot/dts/am335x-sl50.dts | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-sl50.dts b/arch/arm/boot/dts/am335x-sl50.dts
index 1eabea4507aa..b15690155159 100644
--- a/arch/arm/boot/dts/am335x-sl50.dts
+++ b/arch/arm/boot/dts/am335x-sl50.dts
@@ -6,6 +6,7 @@
#include "am33xx.dtsi"
#include <dt-bindings/pwm/pwm.h>
+#include <dt-bindings/interrupt-controller/irq.h>
/ {
model = "Toby Churchill SL50 Series";
@@ -374,6 +375,12 @@
>;
};
+ rtc0_irq_pins: pinmux_rtc0_irq_pins {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x824, PIN_INPUT_PULLUP | MUX_MODE7) /* gpmc_ad9.gpio0_23 */
+ >;
+ };
+
spi0_pins: pinmux_spi0_pins {
pinctrl-single,pins = <
AM33XX_IOPAD(0x954, PIN_INPUT_PULLUP | MUX_MODE0) /* SPI0_MOSI - spi0_d0.spi0_d0 */
@@ -408,9 +415,14 @@
reg = <0x24>;
};
- bq32000: rtc@68 {
- compatible = "ti,bq32000";
- trickle-resistor-ohms = <1120>;
+ rtc0: rtc@68 {
+ compatible = "dallas,ds1339";
+ pinctrl-names = "default";
+ pinctrl-0 = <&rtc0_irq_pins>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <23 IRQ_TYPE_EDGE_FALLING>; /* gpio 23 */
+ wakeup-source;
+ trickle-resistor-ohms = <2000>;
reg = <0x68>;
};
--
2.17.1
^ permalink raw reply related
* [PATCH 4/8] ARM: dts: am335x-sl50: set dr_mode to otg
From: Enric Balletbo i Serra @ 2018-06-06 15:54 UTC (permalink / raw)
To: linux-kernel
Cc: kernel, devicetree, Benoît Cousson, Rob Herring,
Tony Lindgren, Mark Rutland, linux-omap
In-Reply-To: <20180606155413.23542-1-enric.balletbo@collabora.com>
The board can be either a host, or a peripheral, so set the controller as
OTG mode to reflect this.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
arch/arm/boot/dts/am335x-sl50.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-sl50.dts b/arch/arm/boot/dts/am335x-sl50.dts
index ea047b85b726..1eabea4507aa 100644
--- a/arch/arm/boot/dts/am335x-sl50.dts
+++ b/arch/arm/boot/dts/am335x-sl50.dts
@@ -473,7 +473,7 @@
&usb0 {
status = "okay";
- dr_mode = "peripheral";
+ dr_mode = "otg";
};
&usb1 {
--
2.17.1
^ permalink raw reply related
* [PATCH 3/8] ARM: dts: am335x-sl50: add a node for the LCD controller
From: Enric Balletbo i Serra @ 2018-06-06 15:54 UTC (permalink / raw)
To: linux-kernel
Cc: kernel, devicetree, Benoît Cousson, Rob Herring,
Tony Lindgren, Mark Rutland, linux-omap
In-Reply-To: <20180606155413.23542-1-enric.balletbo@collabora.com>
Add the pins used by the LCD controller, the panel-info and display-timings
information for the MIDAS displays connected to the board. There are
two displays in the board, and these, are connected to the LCD controller
through a FPGA, so the timings and the resolution is what expects the FPGA,
not the MIDAS displays.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
arch/arm/boot/dts/am335x-sl50.dts | 69 ++++++++++++++++++++++++++++++-
1 file changed, 68 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-sl50.dts b/arch/arm/boot/dts/am335x-sl50.dts
index 58fe84f2ec8b..ea047b85b726 100644
--- a/arch/arm/boot/dts/am335x-sl50.dts
+++ b/arch/arm/boot/dts/am335x-sl50.dts
@@ -111,6 +111,45 @@
};
};
+ panel: lcd_panel {
+ compatible = "ti,tilcdc,panel";
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_pins>;
+
+ panel-info {
+ ac-bias = <255>;
+ ac-bias-intrpt = <0>;
+ dma-burst-sz = <16>;
+ bpp = <16>;
+ fdd = <0x80>;
+ tft-alt-mode = <0>;
+ mono-8bit-mode = <0>;
+ sync-edge = <0>;
+ sync-ctrl = <1>;
+ raster-order = <0>;
+ fifo-th = <0>;
+ };
+
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: 960x128 {
+ clock-frequency = <18000000>;
+ hactive = <960>;
+ vactive = <272>;
+
+ hback-porch = <40>;
+ hfront-porch = <16>;
+ hsync-len = <24>;
+ hsync-active = <0>;
+
+ vback-porch = <3>;
+ vfront-porch = <8>;
+ vsync-len = <4>;
+ vsync-active = <0>;
+ };
+ };
+ };
+
sound {
compatible = "ti,da830-evm-audio";
ti,model = "AM335x-SL50";
@@ -166,6 +205,31 @@
>;
};
+ lcd_pins: pinmux_lcd_pins {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x8a0, PIN_OUTPUT | MUX_MODE0) /* lcd_data0.lcd_data0 */
+ AM33XX_IOPAD(0x8a4, PIN_OUTPUT | MUX_MODE0) /* lcd_data1.lcd_data1 */
+ AM33XX_IOPAD(0x8a8, PIN_OUTPUT | MUX_MODE0) /* lcd_data2.lcd_data2 */
+ AM33XX_IOPAD(0x8ac, PIN_OUTPUT | MUX_MODE0) /* lcd_data3.lcd_data3 */
+ AM33XX_IOPAD(0x8b0, PIN_OUTPUT | MUX_MODE0) /* lcd_data4.lcd_data4 */
+ AM33XX_IOPAD(0x8b4, PIN_OUTPUT | MUX_MODE0) /* lcd_data5.lcd_data5 */
+ AM33XX_IOPAD(0x8b8, PIN_OUTPUT | MUX_MODE0) /* lcd_data6.lcd_data6 */
+ AM33XX_IOPAD(0x8bc, PIN_OUTPUT | MUX_MODE0) /* lcd_data7.lcd_data7 */
+ AM33XX_IOPAD(0x8c0, PIN_OUTPUT | MUX_MODE0) /* lcd_data8.lcd_data8 */
+ AM33XX_IOPAD(0x8c4, PIN_OUTPUT | MUX_MODE0) /* lcd_data9.lcd_data9 */
+ AM33XX_IOPAD(0x8c8, PIN_OUTPUT | MUX_MODE0) /* lcd_data10.lcd_data10 */
+ AM33XX_IOPAD(0x8cc, PIN_OUTPUT | MUX_MODE0) /* lcd_data11.lcd_data11 */
+ AM33XX_IOPAD(0x8d0, PIN_OUTPUT | MUX_MODE0) /* lcd_data12.lcd_data12 */
+ AM33XX_IOPAD(0x8d4, PIN_OUTPUT | MUX_MODE0) /* lcd_data13.lcd_data13 */
+ AM33XX_IOPAD(0x8d8, PIN_OUTPUT | MUX_MODE0) /* lcd_data14.lcd_data14 */
+ AM33XX_IOPAD(0x8dc, PIN_OUTPUT | MUX_MODE0) /* lcd_data15.lcd_data15 */
+ AM33XX_IOPAD(0x8e0, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_vsync.lcd_vsync */
+ AM33XX_IOPAD(0x8e4, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_hsync.lcd_hsync */
+ AM33XX_IOPAD(0x8e8, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_pclk.lcd_pclk */
+ AM33XX_IOPAD(0x8ec, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_ac_bias_en.lcd_ac_bias_en */
+ >;
+ };
+
led_pins: pinmux_led_pins {
pinctrl-single,pins = <
AM33XX_IOPAD(0x854, PIN_OUTPUT | MUX_MODE7) /* gpmc_a5.gpio1_21 */
@@ -323,7 +387,6 @@
lwb_pins: pinmux_lwb_pins {
pinctrl-single,pins = <
AM33XX_IOPAD(0x9a4, PIN_OUTPUT | MUX_MODE7) /* SoundPA_en - mcasp0_fsr.gpio3_19 */
- AM33XX_IOPAD(0x828, PIN_OUTPUT | MUX_MODE7) /* nKbdOnC - gpmc_ad10.gpio0_26 */
AM33XX_IOPAD(0x830, PIN_INPUT_PULLUP | MUX_MODE7) /* nKbdInt - gpmc_ad12.gpio1_12 */
AM33XX_IOPAD(0x834, PIN_INPUT_PULLUP | MUX_MODE7) /* nKbdReset - gpmc_ad13.gpio1_13 */
AM33XX_IOPAD(0x844, PIN_INPUT_PULLUP | MUX_MODE7) /* USB1_enPower - gpmc_a1.gpio1_17 */
@@ -595,3 +658,7 @@
pinctrl-names = "default";
pinctrl-0 = <&ehrpwm1_pins>;
};
+
+&lcdc {
+ status = "okay";
+};
--
2.17.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox