* [PATCH 1/3] dt-bindings: arm: update Armada CP110 system controller binding
From: Thomas Petazzoni @ 2016-12-13 12:41 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Michael Turquette,
Stephen Boyd, linux-clk-u79uwXL29TY76Z2rM5mHXA
Cc: Marcin Wojtas, Nadav Haklai, Hanna Hawa, Yehuda Yitschak,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni
In-Reply-To: <1481632880-9198-1-git-send-email-thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
It turns out that in the CP110 HW block present in Marvell Armada
7K/8K SoCs, gatable clock n°18 not only controls SD/MMC, but also the
GOP block. This commit updates the Device Tree binding for this piece
of hardware accordingly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
.../devicetree/bindings/arm/marvell/cp110-system-controller0.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt b/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
index 30c5469..07dbb35 100644
--- a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
+++ b/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
@@ -45,7 +45,7 @@ The following clocks are available:
- 1 15 SATA
- 1 16 SATA USB
- 1 17 Main
- - 1 18 SD/MMC
+ - 1 18 SD/MMC/GOP
- 1 21 Slow IO (SPI, NOR, BootROM, I2C, UART)
- 1 22 USB3H0
- 1 23 USB3H1
@@ -65,7 +65,7 @@ Required properties:
"cpm-audio", "cpm-communit", "cpm-nand", "cpm-ppv2", "cpm-sdio",
"cpm-mg-domain", "cpm-mg-core", "cpm-xor1", "cpm-xor0", "cpm-gop-dp", "none",
"cpm-pcie_x10", "cpm-pcie_x11", "cpm-pcie_x4", "cpm-pcie-xor", "cpm-sata",
- "cpm-sata-usb", "cpm-main", "cpm-sd-mmc", "none", "none", "cpm-slow-io",
+ "cpm-sata-usb", "cpm-main", "cpm-sd-mmc-gop", "none", "none", "cpm-slow-io",
"cpm-usb3h0", "cpm-usb3h1", "cpm-usb3dev", "cpm-eip150", "cpm-eip197";
Example:
@@ -78,6 +78,6 @@ Example:
gate-clock-output-names = "cpm-audio", "cpm-communit", "cpm-nand", "cpm-ppv2", "cpm-sdio",
"cpm-mg-domain", "cpm-mg-core", "cpm-xor1", "cpm-xor0", "cpm-gop-dp", "none",
"cpm-pcie_x10", "cpm-pcie_x11", "cpm-pcie_x4", "cpm-pcie-xor", "cpm-sata",
- "cpm-sata-usb", "cpm-main", "cpm-sd-mmc", "none", "none", "cpm-slow-io",
+ "cpm-sata-usb", "cpm-main", "cpm-sd-mmc-gop", "none", "none", "cpm-slow-io",
"cpm-usb3h0", "cpm-usb3h1", "cpm-usb3dev", "cpm-eip150", "cpm-eip197";
};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 0/3] arm64/clk: update Marvell Armada CP110 system controller driver
From: Thomas Petazzoni @ 2016-12-13 12:41 UTC (permalink / raw)
To: devicetree, Rob Herring, Ian Campbell, Pawel Moll, Mark Rutland,
Kumar Gala, Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Gregory Clement, Michael Turquette, Stephen Boyd, linux-clk
Cc: Marcin Wojtas, Nadav Haklai, Hanna Hawa, Yehuda Yitschak,
linux-arm-kernel, Thomas Petazzoni
Hello,
This small set of commits updates the Marvell Armada CP110 system
controller driver, its Device Tree binding, and Device Tree
representation, to take into account two new things:
- The clock driver now handles clock n°9 (GOP) as a child of clock
n°18 (controls SD/MMC and GOP)
- The DT representation is adjusted to name clock n°18 "sd-mmc-gop"
instead of just "sd-mmc".
This set of commits is some preparation work to add networking support
for Marvell Armada 7K/8K.
I would expect patches 1 and 2 to be taken by the clock maintainers,
and patch 3 be taken by the Marvell EBU maintainers.
Thanks,
Thomas
Thomas Petazzoni (3):
dt-bindings: arm: update Armada CP110 system controller binding
clk: mvebu: adjust clock handling for the CP110 system controller
arm64: dts: marvell: adjust name of sd-mmc-gop clock in syscon
.../devicetree/bindings/arm/marvell/cp110-system-controller0.txt | 6 +++---
arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 2 +-
arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 2 +-
drivers/clk/mvebu/cp110-system-controller.c | 6 ++++--
4 files changed, 9 insertions(+), 7 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH v2 3/9] ARM: dts: dra72: Add separate dtsi for tps65917
From: Roger Quadros @ 2016-12-13 12:40 UTC (permalink / raw)
To: Lokesh Vutla, Tony Lindgren, Linux OMAP Mailing List,
Tomi Valkeinen, KISHON VIJAY ABRAHAM
Cc: Tero Kristo, Sekhar Nori, Nishanth Menon,
Device Tree Mailing List, Rob Herring, Linux ARM Mailing List,
Carlos Hernandez
In-Reply-To: <20161021103841.8044-4-lokeshvutla-l0cyMroinI0@public.gmane.org>
+Tomi, Kishon, Carlos
Hi,
On 21/10/16 13:38, Lokesh Vutla wrote:
> dra72-evm-common.dtsi consolidates dra72-evm.dts and dra72-evm-revc.dts
> which also include tps65917 pmic support as both the evms uses the same
> pmic. But, dra71-evm has mostly similar features with a different pmic.
> In order to exploit dra72-evm-common.dtsi, creating a separate dtsi
> for tps65915 support and including it in respective board files.
>
> Signed-off-by: Lokesh Vutla <lokeshvutla-l0cyMroinI0@public.gmane.org>
> ---
> arch/arm/boot/dts/dra72-evm-common.dtsi | 128 ----------------------------
> arch/arm/boot/dts/dra72-evm-revc.dts | 21 +++--
> arch/arm/boot/dts/dra72-evm-tps65917.dtsi | 134 ++++++++++++++++++++++++++++++
> arch/arm/boot/dts/dra72-evm.dts | 14 ++--
> 4 files changed, 154 insertions(+), 143 deletions(-)
> create mode 100644 arch/arm/boot/dts/dra72-evm-tps65917.dtsi
>
This patch breaks USB XHCI and boot on dra72-evm (both revC and non revC)
I'll explain why below.
[ 13.625167] Unhandled fault: imprecise external abort (0x1406) at 0x00000000
[ 13.632557] pgd = ede10000
[ 13.635390] [00000000] *pgd=00000000
[ 13.639145] Internal error: : 1406 [#1] SMP ARM
[ 13.643893] Modules linked in: xhci_plat_hcd(+) xhci_hcd usbcore omapfb dwc3 cfbfillrect snd_soc_davinci_mcasp cfbimgblt cfbcopyarea udc_core connector_hdmi encoder_tpd12s015 snd_soc_edma m25p80 snd_soc_simpe
[ 13.695557] CPU: 0 PID: 440 Comm: modprobe Not tainted 4.9.0-rc1 #1050
[ 13.702399] Hardware name: Generic DRA72X (Flattened Device Tree)
[ 13.708786] task: edb5c040 task.stack: edd10000
[ 13.713540] PC is at _raw_spin_unlock_irqrestore+0x0/0x44
[ 13.719219] LR is at xhci_hub_control+0xc2c/0x15e0 [xhci_hcd]
[ 13.725242] pc : [<c07df718>] lr : [<bf486300>] psr: a0000093
[ 13.725242] sp : edd118c0 ip : c0e306b4 fp : 00000000
[ 13.737278] r10: 00000000 r9 : 60000013 r8 : edf28218
[ 13.742753] r7 : edf28000 r6 : 00000000 r5 : 00000000 r4 : edf2a000
[ 13.749593] r3 : 00000000 r2 : 00000000 r1 : 60000013 r0 : edf28218
> diff --git a/arch/arm/boot/dts/dra72-evm-common.dtsi b/arch/arm/boot/dts/dra72-evm-common.dtsi
> index 8537b6a..9903ac7 100644
> --- a/arch/arm/boot/dts/dra72-evm-common.dtsi
> +++ b/arch/arm/boot/dts/dra72-evm-common.dtsi
> @@ -214,123 +214,6 @@
> status = "okay";
> clock-frequency = <400000>;
>
> - tps65917: tps65917@58 {
> - compatible = "ti,tps65917";
> - reg = <0x58>;
> -
> - interrupts = <GIC_SPI 2 IRQ_TYPE_NONE>; /* IRQ_SYS_1N */
> - interrupt-controller;
> - #interrupt-cells = <2>;
> -
> - ti,system-power-controller;
> -
> - tps65917_pmic {
> - compatible = "ti,tps65917-pmic";
> -
> - smps1-in-supply = <&vsys_3v3>;
> - smps2-in-supply = <&vsys_3v3>;
> - smps3-in-supply = <&vsys_3v3>;
> - smps4-in-supply = <&vsys_3v3>;
> - smps5-in-supply = <&vsys_3v3>;
> - ldo1-in-supply = <&vsys_3v3>;
> - ldo2-in-supply = <&vsys_3v3>;
> - ldo3-in-supply = <&vsys_3v3>;
> - ldo4-in-supply = <&evm_5v0>;
> - ldo5-in-supply = <&vsys_3v3>;
> -
> - tps65917_regulators: regulators {
> - smps1_reg: smps1 {
> - /* VDD_MPU */
> - regulator-name = "smps1";
> - regulator-min-microvolt = <850000>;
> - regulator-max-microvolt = <1250000>;
> - regulator-always-on;
> - regulator-boot-on;
> - };
> -
> - smps2_reg: smps2 {
> - /* VDD_CORE */
> - regulator-name = "smps2";
> - regulator-min-microvolt = <850000>;
> - regulator-max-microvolt = <1150000>;
> - regulator-boot-on;
> - regulator-always-on;
> - };
> -
> - smps3_reg: smps3 {
> - /* VDD_GPU IVA DSPEVE */
> - regulator-name = "smps3";
> - regulator-min-microvolt = <850000>;
> - regulator-max-microvolt = <1250000>;
> - regulator-boot-on;
> - regulator-always-on;
> - };
> -
> - smps4_reg: smps4 {
> - /* VDDS1V8 */
> - regulator-name = "smps4";
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <1800000>;
> - regulator-always-on;
> - regulator-boot-on;
> - };
> -
> - smps5_reg: smps5 {
> - /* VDD_DDR */
> - regulator-name = "smps5";
> - regulator-min-microvolt = <1350000>;
> - regulator-max-microvolt = <1350000>;
> - regulator-boot-on;
> - regulator-always-on;
> - };
> -
> - ldo1_reg: ldo1 {
> - /* LDO1_OUT --> SDIO */
> - regulator-name = "ldo1";
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <3300000>;
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-allow-bypass;
> - };
> -
> - ldo3_reg: ldo3 {
> - /* VDDA_1V8_PHY */
> - regulator-name = "ldo3";
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <1800000>;
> - regulator-boot-on;
> - regulator-always-on;
> - };
> -
> - ldo5_reg: ldo5 {
> - /* VDDA_1V8_PLL */
> - regulator-name = "ldo5";
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <1800000>;
> - regulator-always-on;
> - regulator-boot-on;
> - };
> -
> - ldo4_reg: ldo4 {
> - /* VDDA_3V_USB: VDDA_USBHS33 */
> - regulator-name = "ldo4";
> - regulator-min-microvolt = <3300000>;
> - regulator-max-microvolt = <3300000>;
> - regulator-boot-on;
> - };
> - };
> - };
> -
> - tps65917_power_button {
> - compatible = "ti,palmas-pwrbutton";
> - interrupt-parent = <&tps65917>;
> - interrupts = <1 IRQ_TYPE_NONE>;
> - wakeup-source;
> - ti,palmas-long-press-seconds = <6>;
> - };
> - };
> -
> pcf_gpio_21: gpio@21 {
> compatible = "ti,pcf8575", "nxp,pcf8575";
> reg = <0x21>;
> @@ -480,14 +363,6 @@
> };
> };
>
> -&usb2_phy1 {
> - phy-supply = <&ldo4_reg>;
> -};
> -
> -&usb2_phy2 {
> - phy-supply = <&ldo4_reg>;
> -};
> -
You remove this here but don't add them in the board dts files.
> &omap_dwc3_1 {
> extcon = <&extcon_usb1>;
> };
> @@ -509,7 +384,6 @@
> pinctrl-names = "default";
> pinctrl-0 = <&mmc1_pins_default>;
> vmmc-supply = <&evm_3v3_sd>;
> - vmmc_aux-supply = <&ldo1_reg>;
What about this?
> bus-width = <4>;
> /*
> * SDCD signal is not being used here - using the fact that GPIO mode
> @@ -606,8 +480,6 @@
>
> &dss {
> status = "ok";
> -
> - vdda_video-supply = <&ldo5_reg>;
and this?
> };
>
> &hdmi {
> diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts b/arch/arm/boot/dts/dra72-evm-revc.dts
> index 064b322..4ea2a0c 100644
> --- a/arch/arm/boot/dts/dra72-evm-revc.dts
> +++ b/arch/arm/boot/dts/dra72-evm-revc.dts
> @@ -17,17 +17,22 @@
> };
> };
>
> -&tps65917_regulators {
> - ldo2_reg: ldo2 {
> - /* LDO2_OUT --> VDDA_1V8_PHY2 */
> - regulator-name = "ldo2";
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <1800000>;
> - regulator-always-on;
> - regulator-boot-on;
> +&i2c1 {
> + tps65917: tps65917@58 {
> + reg = <0x58>;
> +
> + interrupts = <GIC_SPI 2 IRQ_TYPE_NONE>; /* IRQ_SYS_1N */
> };
> };
>
> +#include "dra72-evm-tps65917.dtsi"
> +
> +&ldo2_reg {
> + /* LDO2_OUT --> VDDA_1V8_PHY2 */
> + regulator-always-on;
> + regulator-boot-on;
> +};
> +
Here you need to add the usb2_phy1 & 2 supplies.
> &hdmi {
> vdda-supply = <&ldo2_reg>;
> };
> diff --git a/arch/arm/boot/dts/dra72-evm-tps65917.dtsi b/arch/arm/boot/dts/dra72-evm-tps65917.dtsi
> new file mode 100644
> index 0000000..ee6dac4
> --- /dev/null
> +++ b/arch/arm/boot/dts/dra72-evm-tps65917.dtsi
> @@ -0,0 +1,134 @@
> +/*
> + * Copyright (C) 2016 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +/*
> + * Integrated Power Management Chip
> + * http://www.ti.com/lit/ds/symlink/tps65917-q1.pdf
> + */
> +
> +&tps65917 {
> + compatible = "ti,tps65917";
> +
> + interrupt-controller;
> + #interrupt-cells = <2>;
> +
> + ti,system-power-controller;
> +
> + tps65917_pmic {
> + compatible = "ti,tps65917-pmic";
> +
> + smps1-in-supply = <&vsys_3v3>;
> + smps2-in-supply = <&vsys_3v3>;
> + smps3-in-supply = <&vsys_3v3>;
> + smps4-in-supply = <&vsys_3v3>;
> + smps5-in-supply = <&vsys_3v3>;
> + ldo1-in-supply = <&vsys_3v3>;
> + ldo2-in-supply = <&vsys_3v3>;
> + ldo3-in-supply = <&vsys_3v3>;
> + ldo4-in-supply = <&evm_5v0>;
> + ldo5-in-supply = <&vsys_3v3>;
> +
> + tps65917_regulators: regulators {
> + smps1_reg: smps1 {
> + /* VDD_MPU */
> + regulator-name = "smps1";
> + regulator-min-microvolt = <850000>;
> + regulator-max-microvolt = <1250000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + smps2_reg: smps2 {
> + /* VDD_CORE */
> + regulator-name = "smps2";
> + regulator-min-microvolt = <850000>;
> + regulator-max-microvolt = <1150000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + smps3_reg: smps3 {
> + /* VDD_GPU IVA DSPEVE */
> + regulator-name = "smps3";
> + regulator-min-microvolt = <850000>;
> + regulator-max-microvolt = <1250000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + smps4_reg: smps4 {
> + /* VDDS1V8 */
> + regulator-name = "smps4";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + smps5_reg: smps5 {
> + /* VDD_DDR */
> + regulator-name = "smps5";
> + regulator-min-microvolt = <1350000>;
> + regulator-max-microvolt = <1350000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + ldo1_reg: ldo1 {
> + /* LDO1_OUT --> SDIO */
> + regulator-name = "ldo1";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-allow-bypass;
> + };
> +
> + ldo2_reg: ldo2 {
> + regulator-name = "ldo2";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-allow-bypass;
> + };
> +
> + ldo3_reg: ldo3 {
> + /* VDDA_1V8_PHY */
> + regulator-name = "ldo3";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + ldo5_reg: ldo5 {
> + /* VDDA_1V8_PLL */
> + regulator-name = "ldo5";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + ldo4_reg: ldo4 {
> + /* VDDA_3V_USB: VDDA_USBHS33 */
> + regulator-name = "ldo4";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-boot-on;
> + };
> + };
> + };
> +
> + tps65917_power_button {
> + compatible = "ti,palmas-pwrbutton";
> + interrupt-parent = <&tps65917>;
> + interrupts = <1 IRQ_TYPE_NONE>;
> + wakeup-source;
> + ti,palmas-long-press-seconds = <6>;
> + };
> +};
> diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
> index e3a9b69..cd9c4ff 100644
> --- a/arch/arm/boot/dts/dra72-evm.dts
> +++ b/arch/arm/boot/dts/dra72-evm.dts
> @@ -15,16 +15,16 @@
> };
> };
>
> -&tps65917_regulators {
> - ldo2_reg: ldo2 {
> - /* LDO2_OUT --> TP1017 (UNUSED) */
> - regulator-name = "ldo2";
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <3300000>;
> - regulator-allow-bypass;
> +&i2c1 {
> + tps65917: tps65917@58 {
> + reg = <0x58>;
> +
> + interrupts = <GIC_SPI 2 IRQ_TYPE_NONE>; /* IRQ_SYS_1N */
> };
> };
>
> +#include "dra72-evm-tps65917.dtsi"
> +
> &hdmi {
> vdda-supply = <&ldo3_reg>;
> };
>
Here as well you need to add the usb2_phy1 & 2 supplies.
We probably need to add dss and mmc supplies as well to both the board dts files?
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 6/6] mfd: dt: Move syscon bindings to syscon subdirectory
From: Andrew Jeffery @ 2016-12-13 12:39 UTC (permalink / raw)
To: Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Lee Jones, Mark Rutland, Corey Minyard,
devicetree-u79uwXL29TY76Z2rM5mHXA, Linus Walleij,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Cédric Le Goater,
Joel Stanley
In-Reply-To: <5094120.Y7DXfRGTEm@wuerfel>
[-- Attachment #1: Type: text/plain, Size: 1800 bytes --]
On Tue, 2016-12-13 at 13:17 +0100, Arnd Bergmann wrote:
> On Tuesday, December 13, 2016 10:35:34 PM CET Andrew Jeffery wrote:
> > On Tue, 2016-12-13 at 11:07 +0000, Lee Jones wrote:
> > > On Tue, 13 Dec 2016, Andrew Jeffery wrote:
> > > > On Mon, 2016-12-12 at 09:39 -0600, Rob Herring wrote:
> > > > > On Tue, Dec 06, 2016 at 01:53:21PM +1100, Andrew Jeffery wrote:
> > > >
> > > > Lee's next email in the chain poked Arnd for an opinion, but Arnd
> > > > didn't reply.
> > > >
> > > > I don't mind. I moved these bindings separately so we could just drop
> > > > the patch if there was push-back. If we drop the whole idea I'll need
> > > > to apply a small fix to patch 5/6 to avoid creating the syscon
> > > > subdirectory.
> > >
> > > The sub-directory is a good idea for drivers who are *solely* syscon
> > > based.
> > >
> >
> > Yes, I wasn't saying otherwise, just commenting on my motivation and
> > approach.
> >
> > As far as I can tell all of the bindings I move here describe solely
> > syscon-based devices.
> >
>
> But do we know which ones they are?
>
> In principle, any syscon device node can have a specialized driver
> exporting an interface, the bindings always allow it to be done
> one way or the other, and we may change the driver or run a different
> OS that has decided differently.
>
Right; for the Linux case there are currently no driver implementations
that match on the compatible strings in the documents I moved (save for
qcom,tcsr, except that it's the qcom,gsbi compatible driver parsing a
phandle to the qcom,tcsr syscon node).
However, I can't guarantee the solely-syscon property for other
operating systems. Given that, it now looks to me like we shouldn't
have such a directory at all.
Cheers,
Andrew
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting
From: Hans Verkuil @ 2016-12-13 12:34 UTC (permalink / raw)
To: Krzysztof Kozlowski, devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc, linux-mmc, linux-pm, linux-usb, Ulf Hansson,
Sebastian Reichel, Dmitry Eremin-Solenikov, David Woodhouse,
Greg Kroah-Hartman, Mark Brown
Cc: tjakobi, m.szyprowski, Bartlomiej Zolnierkiewicz
In-Reply-To: <c956e27e-7e01-2a2f-0e35-796c4a6556ae@xs4all.nl>
Try again, this time with Krzysztof's new email address...
On 13/12/16 13:20, Hans Verkuil wrote:
> Hi Krzysztof,
>
> This still seems to be broken with the latest 4.9 kernel, right?
>
> Has there been any progress on this? Do you have an updated patch series
> for me to use?
>
> Regards,
>
> Hans
>
> On 05/05/16 14:34, Krzysztof Kozlowski wrote:
>> Hi,
>>
>> This is a different, second try to fix usb3503+lan on Odroid U3 board
>> if it was initialized by bootloader (e.g. for TFTP boot).
>>
>> First version:
>> http://www.spinics.net/lists/linux-usb/msg140042.html
>>
>>
>> Problem
>> =======
>> When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP),
>> the usb3503 and LAN smsc95xx do not show up in "lsusb". Hard-reset
>> is required, e.g. by suspend to RAM. The actual TFTP boot does
>> not have to happen. Just "usb start" from U-Boot is sufficient.
>>
>
>
^ permalink raw reply
* Re: [PATCH v4 1/4] mtd: spi-nor: add memory controllers for the Aspeed AST2500 SoC
From: Cédric Le Goater @ 2016-12-13 12:22 UTC (permalink / raw)
To: Marek Vasut, linux-mtd
Cc: Mark Rutland, Boris Brezillon, devicetree, Richard Weinberger,
Rob Herring, Joel Stanley, Cyrille Pitchen, Brian Norris,
David Woodhouse
In-Reply-To: <3f3260d1-e677-b6d9-5571-a08a80344495@gmail.com>
On 12/13/2016 08:50 AM, Marek Vasut wrote:
> On 12/12/2016 04:40 PM, Cédric Le Goater wrote:
>> This driver adds mtd support for the Aspeed AST2500 SoC static memory
>> controllers :
>
> [...]
>
>> +#define DEVICE_NAME "aspeed-smc"
>> +
>> +/*
>> + * The driver only support SPI flash
>> + */
>> +enum aspeed_smc_flash_type {
>> + smc_type_nor = 0,
>> + smc_type_nand = 1,
>> + smc_type_spi = 2,
>> +};
>
> So why is this here ? :)
well, because we do enforce the SPI type in aspeed_smc_chip_set_type()
but I agree, we could be a bit more direct with it and just write
the SPI type. May be in a followup patch then.
>
>> +struct aspeed_smc_chip;
>> +
>> +struct aspeed_smc_info {
>> + u32 maxsize; /* maximum size of chip window */
>> + u8 nce; /* number of chip enables */
>> + bool hastype; /* flash type field exists in config reg */
>> + u8 we0; /* shift for write enable bit for CE0 */
>> + u8 ctl0; /* offset in regs of ctl for CE0 */
>> +
>> + void (*set_4b)(struct aspeed_smc_chip *chip);
>> +};
>
> Otherwise looks good:
> Reviewed-by: Marek Vasut <marek.vasut@gmail.com>
>
Thanks for the review,
C.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting
From: Hans Verkuil @ 2016-12-13 12:20 UTC (permalink / raw)
To: Krzysztof Kozlowski, devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc, linux-mmc, linux-pm, linux-usb, Ulf Hansson,
Sebastian Reichel, Dmitry Eremin-Solenikov, David Woodhouse,
Greg Kroah-Hartman, Mark Brown
Cc: tjakobi, m.szyprowski, Bartlomiej Zolnierkiewicz
In-Reply-To: <1462451666-17945-1-git-send-email-k.kozlowski@samsung.com>
Hi Krzysztof,
This still seems to be broken with the latest 4.9 kernel, right?
Has there been any progress on this? Do you have an updated patch series
for me to use?
Regards,
Hans
On 05/05/16 14:34, Krzysztof Kozlowski wrote:
> Hi,
>
> This is a different, second try to fix usb3503+lan on Odroid U3 board
> if it was initialized by bootloader (e.g. for TFTP boot).
>
> First version:
> http://www.spinics.net/lists/linux-usb/msg140042.html
>
>
> Problem
> =======
> When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP),
> the usb3503 and LAN smsc95xx do not show up in "lsusb". Hard-reset
> is required, e.g. by suspend to RAM. The actual TFTP boot does
> not have to happen. Just "usb start" from U-Boot is sufficient.
>
^ permalink raw reply
* Re: [PATCH v3 6/6] mfd: dt: Move syscon bindings to syscon subdirectory
From: Arnd Bergmann @ 2016-12-13 12:17 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Andrew Jeffery, Lee Jones, Mark Rutland, Corey Minyard,
devicetree-u79uwXL29TY76Z2rM5mHXA, Linus Walleij,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Cédric Le Goater,
Joel Stanley
In-Reply-To: <1481630734.3112.40.camel-zrmu5oMJ5Fs@public.gmane.org>
On Tuesday, December 13, 2016 10:35:34 PM CET Andrew Jeffery wrote:
> On Tue, 2016-12-13 at 11:07 +0000, Lee Jones wrote:
> > On Tue, 13 Dec 2016, Andrew Jeffery wrote:
> > > On Mon, 2016-12-12 at 09:39 -0600, Rob Herring wrote:
> > > > On Tue, Dec 06, 2016 at 01:53:21PM +1100, Andrew Jeffery wrote:
> > >
> > > Lee's next email in the chain poked Arnd for an opinion, but Arnd
> > > didn't reply.
> > >
> > > I don't mind. I moved these bindings separately so we could just drop
> > > the patch if there was push-back. If we drop the whole idea I'll need
> > > to apply a small fix to patch 5/6 to avoid creating the syscon
> > > subdirectory.
> >
> > The sub-directory is a good idea for drivers who are *solely* syscon
> > based.
> >
>
> Yes, I wasn't saying otherwise, just commenting on my motivation and
> approach.
>
> As far as I can tell all of the bindings I move here describe solely
> syscon-based devices.
>
But do we know which ones they are?
In principle, any syscon device node can have a specialized driver
exporting an interface, the bindings always allow it to be done
one way or the other, and we may change the driver or run a different
OS that has decided differently.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 6/6] mfd: dt: Move syscon bindings to syscon subdirectory
From: Andrew Jeffery @ 2016-12-13 12:05 UTC (permalink / raw)
To: Lee Jones
Cc: Mark Rutland, Corey Minyard, devicetree, Linus Walleij,
linux-kernel, Cédric Le Goater, linux-arm-kernel,
Joel Stanley
In-Reply-To: <20161213110710.GV3625@dell.home>
[-- Attachment #1.1: Type: text/plain, Size: 2716 bytes --]
On Tue, 2016-12-13 at 11:07 +0000, Lee Jones wrote:
> On Tue, 13 Dec 2016, Andrew Jeffery wrote:
>
> > On Mon, 2016-12-12 at 09:39 -0600, Rob Herring wrote:
> > > On Tue, Dec 06, 2016 at 01:53:21PM +1100, Andrew Jeffery wrote:
> > > > The use of syscons is growing, lets collate them in their own part of
> > > > the bindings tree.
> > > >
> > > > > > Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> > > >
> > > > ---
> > > > Documentation/devicetree/bindings/mfd/{ => syscon}/aspeed-scu.txt | 0
> > > > Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-gpbr.txt | 0
> > > > Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-matrix.txt | 0
> > > > Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-smc.txt | 0
> > > > Documentation/devicetree/bindings/mfd/{ => syscon}/qcom,tcsr.txt | 0
> > > > Documentation/devicetree/bindings/mfd/{ => syscon}/syscon.txt | 0
> > > > .../devicetree/bindings/mfd/{ => syscon}/ti-keystone-devctrl.txt | 0
> > > > 7 files changed, 0 insertions(+), 0 deletions(-)
> > > > rename Documentation/devicetree/bindings/mfd/{ => syscon}/aspeed-scu.txt (100%)
> > > > rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-gpbr.txt (100%)
> > > > rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-matrix.txt (100%)
> > > > rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-smc.txt (100%)
> > > > rename Documentation/devicetree/bindings/mfd/{ => syscon}/qcom,tcsr.txt (100%)
> > > > rename Documentation/devicetree/bindings/mfd/{ => syscon}/syscon.txt (100%)
> > > > rename Documentation/devicetree/bindings/mfd/{ => syscon}/ti-keystone-devctrl.txt (100%)
> > >
> > > I'm not so sure this is the right direction. syscon usage is pretty much
> > > spread throughout the tree.
> >
> > This patch was created based on my interpretation of Lee's feedback
> > here:
> >
> > https://lkml.org/lkml/2016/11/18/650
> >
> > Lee's next email in the chain poked Arnd for an opinion, but Arnd
> > didn't reply.
> >
> > I don't mind. I moved these bindings separately so we could just drop
> > the patch if there was push-back. If we drop the whole idea I'll need
> > to apply a small fix to patch 5/6 to avoid creating the syscon
> > subdirectory.
>
> The sub-directory is a good idea for drivers who are *solely* syscon
> based.
>
Yes, I wasn't saying otherwise, just commenting on my motivation and
approach.
As far as I can tell all of the bindings I move here describe solely
syscon-based devices.
Cheers,
Andrew
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/7] ath9k: EEPROM swapping improvements
From: Valo, Kalle @ 2016-12-13 12:03 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: ath9k-devel,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
ath9k-devel-xDcbHBWguxHbcTqmT+pZeQ@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
arnd-r2nGTMty4D4@public.gmane.org,
chunkeey-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org,
nbd-Vt+b4OUoWG0@public.gmane.org
In-Reply-To: <CAFBinCC6JWBhZwma=66fBi3_to2SaHOMNDQS23jHNhcc+RUcYQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> writes:
> Hello Kalle,
>
> On Fri, Nov 25, 2016 at 4:06 PM, Valo, Kalle <kvalo-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org> wrote:
>> Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> writes:
>>
>>> Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> writes:
>>>
>>>> There are two types of swapping the EEPROM data in the ath9k driver.
>>>> Before this series one type of swapping could not be used without the
>>>> other.
>>>>
>>>> The first type of swapping looks at the "magic bytes" at the start of
>>>> the EEPROM data and performs swab16 on the EEPROM contents if needed.
>>>> The second type of swapping is EEPROM format specific and swaps
>>>> specific fields within the EEPROM itself (swab16, swab32 - depends on
>>>> the EEPROM format).
>>>>
>>>> With this series the second part now looks at the EEPMISC register
>>>> inside the EEPROM, which uses a bit to indicate if the EEPROM data
>>>> is Big Endian (this is also done by the FreeBSD kernel).
>>>> This has a nice advantage: currently there are some out-of-tree hacks
>>>> (in OpenWrt and LEDE) where the EEPROM has a Big Endian header on a
>>>> Big Endian system (= no swab16 is performed) but the EEPROM itself
>>>> indicates that it's data is Little Endian. Until now the out-of-tree
>>>> code simply did a swab16 before passing the data to ath9k, so ath9k
>>>> first did the swab16 - this also enabled the format specific swapping.
>>>> These out-of-tree hacks are still working with the new logic, but it
>>>> is recommended to remove them. This implementation is based on a
>>>> discussion with Arnd Bergmann who raised concerns about the
>>>> robustness and portability of the swapping logic in the original OF
>>>> support patch review, see [0].
>>>>
>>>> After a second round of patches (= v1 of this series) neither Arnd
>>>> Bergmann nor I were really happy with the complexity of the EEPROM
>>>> swapping logic. Based on a discussion (see [1] and [2]) we decided
>>>> that ath9k should use a defined format (specifying the endianness
>>>> of the data - I went with __le16 and __le32) when accessing the
>>>> EEPROM fields. A benefit of this is that we enable the EEPMISC based
>>>> swapping logic by default, just like the FreeBSD driver, see [3]. On
>>>> the devices which I have tested (see below) ath9k now works without
>>>> having to specify the "endian_check" field in ath9k_platform_data (or
>>>> a similar logic which could provide this via devicetree) as ath9k now
>>>> detects the endianness automatically. Only EEPROMs which are mangled
>>>> by some out-of-tree code still need the endian_check flag (or one can
>>>> simply remove that mangling from the out-of-tree code).
>>>>
>>>> Testing:
>>>> - tested by myself on AR9287 with Big Endian EEPROM
>>>> - tested by myself on AR9227 with Little Endian EEPROM
>>>> - tested by myself on AR9381 (using the ar9003_eeprom implementation,
>>>> which did not suffer from this whole problem)
>>>> - how do we proceed with testing? maybe we could keep this in a
>>>> feature-branch and add these patches to LEDE once we have an ACK to
>>>> get more people to test this
>>>>
>>>> This series depends on my other series (v7):
>>>> "add devicetree support to ath9k" - see [4]
>>>
>>> I think this looks pretty good. If there's a bug somewhere it should be
>>> quite easy to fix so I'm not that worried and would be willing to take
>>> these as soon as I have applied the dependency series. IIRC your
>>> devicetree patches will have at least one more review round so that will
>>> take some time still. In the meantime it would be great if LEDE folks
>>> could take a look at these and comment (or test).
>>
>> So are everyone happy with this? I haven't seen any comments. If I don't
>> here anything I'm planning to take these, most likely for 4.11.
>
> the patches have been in LEDE for almost two weeks now and I did not
> see any reports of ath9k breakage (footnote below).
>
> It seems that there are a few devices out there where the whole EEPROM
> is swab16'ed which switches the position of the 1-byte fields
> opCapFlags and eepMisc.
> those still work fine with the new code, however I had a second patch
> in LEDE [0] which results in ath9k_platform_data.endian_check NOT
> being set anymore.
> that endian_check flag was used before to swab16 the whole EEPROM, to
> correct the position of the 1-byte fields again.
> Currently we are fixing this in the firmware hotplug script: [1]
> This is definitely not a blocker for this series though (if we want to
> have a devicetree replacement for "ath9k_platform_data.endian_check"
> then I'd work on that within a separate series, but I somewhat
> consider these EEPROMs as "broken" so fixing them in
> userspace/firmware hotplug script is fine for me)
Sounds good to me, thanks for the thorough followup. I'm planning to
apply these any day.
--
Kalle Valo--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 2/4] cpuidle:powernv: Add helper function to populate powernv idle states.
From: Balbir Singh @ 2016-12-13 11:51 UTC (permalink / raw)
To: Gautham R. Shenoy, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Rafael J. Wysocki, Daniel Lezcano,
Michael Neuling, Vaidyanathan Srinivasan, Shreyas B. Prabhu,
Shilpasri G Bhat, Stewart Smith, Oliver O'Halloran
Cc: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland
In-Reply-To: <36f9cd2d944772d8e414a8240f9ec36eaec65ebd.1481288905.git.ego-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
On 10/12/16 00:32, Gautham R. Shenoy wrote:
> From: "Gautham R. Shenoy" <ego-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
>
> In the current code for powernv_add_idle_states, there is a lot of code
> duplication while initializing an idle state in powernv_states table.
>
> Add an inline helper function to populate the powernv_states[] table for
> a given idle state. Invoke this for populating the "Nap", "Fastsleep"
> and the stop states in powernv_add_idle_states.
>
> Signed-off-by: Gautham R. Shenoy <ego-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
> ---
> drivers/cpuidle/cpuidle-powernv.c | 85 ++++++++++++++++++++++-----------------
> include/linux/cpuidle.h | 1 +
> 2 files changed, 50 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/cpuidle/cpuidle-powernv.c b/drivers/cpuidle/cpuidle-powernv.c
> index 7fe442c..db18af1 100644
> --- a/drivers/cpuidle/cpuidle-powernv.c
> +++ b/drivers/cpuidle/cpuidle-powernv.c
> @@ -167,6 +167,24 @@ static int powernv_cpuidle_driver_init(void)
> return 0;
> }
>
> +static inline void add_powernv_state(int index, const char *name,
> + unsigned int flags,
> + int (*idle_fn)(struct cpuidle_device *,
> + struct cpuidle_driver *,
> + int),
> + unsigned int target_residency,
> + unsigned int exit_latency,
> + u64 psscr_val)
> +{
> + strlcpy(powernv_states[index].name, name, CPUIDLE_NAME_LEN);
> + strlcpy(powernv_states[index].desc, name, CPUIDLE_NAME_LEN);
Do name and desc ever diverge?
> + powernv_states[index].flags = flags;
> + powernv_states[index].target_residency = target_residency;
> + powernv_states[index].exit_latency = exit_latency;
> + powernv_states[index].enter = idle_fn;
Why not call it idle_fn instead of enter?
> + stop_psscr_table[index] = psscr_val;
> +}
> +
> static int powernv_add_idle_states(void)
> {
> struct device_node *power_mgt;
> @@ -236,6 +254,7 @@ static int powernv_add_idle_states(void)
> "ibm,cpu-idle-state-residency-ns", residency_ns, dt_idle_states);
>
> for (i = 0; i < dt_idle_states; i++) {
> + unsigned int exit_latency, target_residency;
> /*
> * If an idle state has exit latency beyond
> * POWERNV_THRESHOLD_LATENCY_NS then don't use it
> @@ -243,28 +262,33 @@ static int powernv_add_idle_states(void)
> */
> if (latency_ns[i] > POWERNV_THRESHOLD_LATENCY_NS)
Ideally this should be called POWERNV_MAX_THRESHOLD_LATENCY_NS then
> continue;
> + /*
> + * Firmware passes residency and latency values in ns.
> + * cpuidle expects it in us.
> + */
> + exit_latency = ((unsigned int)latency_ns[i]) / 1000;
> + if (!rc)
> + target_residency = residency_ns[i] / 1000;
> + else
> + target_residency = 0;
Where do we get rc from? what does target_residency = 0 mean?
Balbir Singh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v6 3/8] PWM: add pwm-stm32 DT bindings
From: Lee Jones @ 2016-12-13 11:11 UTC (permalink / raw)
To: Rob Herring
Cc: Benjamin Gaignard, mark.rutland-5wv7dgnIgG8,
alexandre.torgue-qxv4g6HH51o, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
linux-pwm-u79uwXL29TY76Z2rM5mHXA, jic23-DgEjT+Ai2ygdnm+yROfE0A,
knaack.h-Mmb7MZpHnFY, lars-Qo5EllUWu/uELgA04lAiVw,
pmeerw-jW+XmwGofnusTnJN9+BGXg, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
fabrice.gasnier-qxv4g6HH51o, gerald.baeza-qxv4g6HH51o,
arnaud.pouliquen-qxv4g6HH51o,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
linaro-kernel-cunTk1MwBs8s++Sfvej+rw, Benjamin Gaignard
In-Reply-To: <20161212190205.b5t3x6i2o7igldlo@rob-hp-laptop>
On Mon, 12 Dec 2016, Rob Herring wrote:
> On Fri, Dec 09, 2016 at 03:15:14PM +0100, Benjamin Gaignard wrote:
> > Define bindings for pwm-stm32
> >
> > version 6:
> > - change st,breakinput parameter format to make it usuable on stm32f7 too.
> >
> > version 2:
> > - use parameters instead of compatible of handle the hardware configuration
> >
> > Signed-off-by: Benjamin Gaignard <benjamin.gaignard-qxv4g6HH51o@public.gmane.org>
> > ---
> > .../devicetree/bindings/pwm/pwm-stm32.txt | 33 ++++++++++++++++++++++
> > 1 file changed, 33 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> >
> > diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32.txt b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> > new file mode 100644
> > index 0000000..866f222
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> > @@ -0,0 +1,33 @@
> > +STMicroelectronics STM32 Timers PWM bindings
> > +
> > +Must be a sub-node of an STM32 Timers device tree node.
> > +See ../mfd/stm32-timers.txt for details about the parent node.
> > +
> > +Required parameters:
> > +- compatible: Must be "st,stm32-pwm".
> > +- pinctrl-names: Set to "default".
> > +- pinctrl-0: List of phandles pointing to pin configuration nodes for PWM module.
> > + For Pinctrl properties see ../pinctrl/pinctrl-bindings.txt
> > +
> > +Optional parameters:
> > +- st,breakinput: Arrays of three u32 <index level filter> to describe break input configurations.
> > + "index" indicates on which break input the configuration should be applied.
> > + "level" gives the active level (0=low or 1=high) for this configuration.
> > + "filter" gives the filtering value to be applied.
> > +
> > +Example:
> > + timers@40010000 {
>
> timer@...
No, it should be timers.
The 's' is intentional, since this parent (MFD) device houses 3
different types of timers. The "timer" node is a child of this one.
> With that,
>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
>
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + compatible = "st,stm32-timers";
> > + reg = <0x40010000 0x400>;
> > + clocks = <&rcc 0 160>;
> > + clock-names = "clk_int";
> > +
> > + pwm {
> > + compatible = "st,stm32-pwm";
> > + pinctrl-0 = <&pwm1_pins>;
> > + pinctrl-names = "default";
> > + st,breakinput = <0 1 5>;
> > + };
> > + };
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 6/6] mfd: dt: Move syscon bindings to syscon subdirectory
From: Lee Jones @ 2016-12-13 11:07 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Rob Herring, Mark Rutland, Linus Walleij, Corey Minyard,
Cédric Le Goater, Joel Stanley, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <1481604793.3112.32.camel@aj.id.au>
On Tue, 13 Dec 2016, Andrew Jeffery wrote:
> On Mon, 2016-12-12 at 09:39 -0600, Rob Herring wrote:
> > On Tue, Dec 06, 2016 at 01:53:21PM +1100, Andrew Jeffery wrote:
> > > The use of syscons is growing, lets collate them in their own part of
> > > the bindings tree.
> > >
> > > > > Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> > > ---
> > > Documentation/devicetree/bindings/mfd/{ => syscon}/aspeed-scu.txt | 0
> > > Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-gpbr.txt | 0
> > > Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-matrix.txt | 0
> > > Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-smc.txt | 0
> > > Documentation/devicetree/bindings/mfd/{ => syscon}/qcom,tcsr.txt | 0
> > > Documentation/devicetree/bindings/mfd/{ => syscon}/syscon.txt | 0
> > > .../devicetree/bindings/mfd/{ => syscon}/ti-keystone-devctrl.txt | 0
> > > 7 files changed, 0 insertions(+), 0 deletions(-)
> > > rename Documentation/devicetree/bindings/mfd/{ => syscon}/aspeed-scu.txt (100%)
> > > rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-gpbr.txt (100%)
> > > rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-matrix.txt (100%)
> > > rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-smc.txt (100%)
> > > rename Documentation/devicetree/bindings/mfd/{ => syscon}/qcom,tcsr.txt (100%)
> > > rename Documentation/devicetree/bindings/mfd/{ => syscon}/syscon.txt (100%)
> > > rename Documentation/devicetree/bindings/mfd/{ => syscon}/ti-keystone-devctrl.txt (100%)
> >
> > I'm not so sure this is the right direction. syscon usage is pretty much
> > spread throughout the tree.
>
> This patch was created based on my interpretation of Lee's feedback
> here:
>
> https://lkml.org/lkml/2016/11/18/650
>
> Lee's next email in the chain poked Arnd for an opinion, but Arnd
> didn't reply.
>
> I don't mind. I moved these bindings separately so we could just drop
> the patch if there was push-back. If we drop the whole idea I'll need
> to apply a small fix to patch 5/6 to avoid creating the syscon
> subdirectory.
The sub-directory is a good idea for drivers who are *solely* syscon
based.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* RE: [PATCH v4 3/5] i2c: designware: Add slave definitions
From: Luis de Oliveira @ 2016-12-13 10:50 UTC (permalink / raw)
To: Rob Herring, Luis de Oliveira
Cc: wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
jarkko.nikula-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Ramiro.Oliveira-HKixBCOQz3hWk0Htik3J/w@public.gmane.org,
Joao.Pinto-HKixBCOQz3hWk0Htik3J/w@public.gmane.org,
CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w@public.gmane.org
In-Reply-To: <CAL_JsqJwjX1Y=bDD-hKcXqa1aBKjVhXjEZm6j2tMAQszyv-QhA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
The controller for i2c-designware cannot be slave/master at the same time and it has to be enabled knowing beforehand if we want it to be slave or master by something outside of the controller itself.
I as looking and I see the use of this I2C_OWN_SLAVE_ADDRESS with the "linux,slave-24c02" slave interface but I am not seeing how it will help me identify a selected i2c-designware block as a "slave" device before instantiation. I'm sorry if I'm not understanding properly.
I use the "linux,slave-24c02" to instantiate the i2c-designware as a slave with an address so I can do write/read operations, it is how I tested it.
Luis
-----Original Message-----
From: Rob Herring [mailto:robh@kernel.org]
Sent: Monday, December 12, 2016 23:16
To: Luis de Oliveira <Luis.Oliveira@synopsys.com>
Cc: wsa@the-dreams.de; mark.rutland@arm.com; jarkko.nikula@linux.intel.com; andriy.shevchenko@linux.intel.com; mika.westerberg@linux.intel.com; linux-i2c@vger.kernel.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; Ramiro.Oliveira@synopsys.com; Joao.Pinto@synopsys.com; CARLOS.PALMINHA@synopsys.com
Subject: Re: [PATCH v4 3/5] i2c: designware: Add slave definitions
On Mon, Dec 12, 2016 at 12:35 PM, Luis de Oliveira <Luis.Oliveira@synopsys.com> wrote:
> Hi all,
Please don't top post.
>
> The slave address could be set by the I2C slave backend so I can't use it to setup the controller.
> A boolean property was my initial approach then Andy and Wolfram Sang suggested the use of compatible strings and later It was suggested to use a property to select mode but I can do it again if it's the best way.
> Can you please tell me where should it be documented?
bindings/i2c/i2c.txt.
Actually, looking at this some more, we already have a way to describe the controller being a slave device with the I2C_OWN_SLAVE_ADDRESS flag in the reg property. We should just need a helper to read reg property of each child and check for the bit set.
Rob
^ permalink raw reply
* Re: [PATCH v3 0/2] power: supply: add sbs-charger driver
From: Nicolas Saenz Julienne @ 2016-12-13 10:41 UTC (permalink / raw)
To: sre, mark.rutland; +Cc: linux-kernel, devicetree, linux-pm
In-Reply-To: <1479990823-25841-1-git-send-email-nicolas.saenz@prodys.net>
On 24/11/16 13:33, Nicolas Saenz Julienne wrote:
> Hi,
>
> This series adds support for all SBS compatible battery chargers, as defined
> here: http://sbs-forum.org/specs/sbc110.pdf.
>
> The first patch changes the sbs-battery device name in order to be able to
> create a proper supplier/supplied relation between the two of them.
>
> The second introduces the driver.
>
> Regards,
> Nicolas
>
> changes since v2:
> - updated driver and dt-binding with Sebatian's comments
>
> changes since v1:
> - added dt bindings
> - updated driver with Sebastian's comments
> - s/Nicola/Nicolas/ in commits
>
> Nicolas Saenz Julienne (2):
> power: supply: add sbs-charger driver
> dt-bindings: power: add bindings for sbs-charger
>
> .../bindings/power/supply/sbs_sbs-charger.txt | 24 ++
> drivers/power/supply/Kconfig | 6 +
> drivers/power/supply/Makefile | 1 +
> drivers/power/supply/sbs-charger.c | 275 +++++++++++++++++++++
> 4 files changed, 306 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/supply/sbs_sbs-charger.txt
> create mode 100644 drivers/power/supply/sbs-charger.c
>
Hi,
any update?
Kind Regards,
Nicolas
^ permalink raw reply
* Re: [PATCH v6 4/5] ARM: dts: da850-lcdk: add the vga-bridge node
From: Bartosz Golaszewski @ 2016-12-13 10:18 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Jyri Sarha, David Airlie, Kevin Hilman, Michael Turquette,
Sekhar Nori, Rob Herring, Frank Rowand, Mark Rutland,
Laurent Pinchart, Peter Ujfalusi, Russell King, LKML, arm-soc,
linux-drm, linux-devicetree
In-Reply-To: <9d5fa409-bb4f-f62b-2548-0a3b82228e08-l0cyMroinI0@public.gmane.org>
2016-12-13 9:46 GMT+01:00 Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>:
> Hi,
>
> On 12/12/16 15:05, Bartosz Golaszewski wrote:
>
>> +&lcdc {
>> + status = "okay";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&lcd_pins>;
>> +
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + lcdc_out: port@1 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <1>;
>> +
>> + lcdc_out_vga: endpoint {
>> + reg = <0>;
>> + remote-endpoint = <&vga_bridge_in>;
>> + };
>> + };
>> + };
>> +};
>>
>
> This is not correct. LCDC has just one output, so port@1 doesn't make
> sense. It's port@0. But with just one port, you can leave "ports" away.
> And you don't need the port's label for anything, if I'm not mistaken. So:
>
> &lcdc {
> status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <&lcd_pins>;
>
> port {
> lcdc_out_vga: endpoint {
> remote-endpoint = <&vga_bridge_in>;
> };
> };
> };
>
> Tomi
>
Right, fixed in v7.
Thanks,
Bartosz
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 1/4] powernv:idle: Add IDLE_STATE_ENTER_SEQ_NORET macro
From: Balbir Singh @ 2016-12-13 10:13 UTC (permalink / raw)
To: Gautham R. Shenoy, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Rafael J. Wysocki, Daniel Lezcano,
Michael Neuling, Vaidyanathan Srinivasan, Shreyas B. Prabhu,
Shilpasri G Bhat, Stewart Smith, Oliver O'Halloran
Cc: linuxppc-dev, linux-kernel, linux-pm, devicetree, Rob Herring,
Mark Rutland
In-Reply-To: <0947ced2f87c68a0a10ede8e1aaf39838a6f8d52.1481288905.git.ego@linux.vnet.ibm.com>
On 10/12/16 00:32, Gautham R. Shenoy wrote:
> From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
>
> Currently all the low-power idle states are expected to wake up
> at reset vector 0x100. Which is why the macro IDLE_STATE_ENTER_SEQ
> that puts the CPU to an idle state and never returns.
>
> On ISA_300, when the ESL and EC bits in the PSSCR are zero, the
> CPU is expected to wake up at the next instruction of the idle
> instruction.
>
> This patch adds a new macro named IDLE_STATE_ENTER_SEQ_NORET for the
> no-return variant and reuses the name IDLE_STATE_ENTER_SEQ
> for a variant that allows resuming operation at the instruction next
> to the idle-instruction.
>
> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/cpuidle.h | 5 ++++-
> arch/powerpc/kernel/exceptions-64s.S | 6 +++---
> arch/powerpc/kernel/idle_book3s.S | 10 +++++-----
> 3 files changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/cpuidle.h b/arch/powerpc/include/asm/cpuidle.h
> index 3919332..0a3255b 100644
> --- a/arch/powerpc/include/asm/cpuidle.h
> +++ b/arch/powerpc/include/asm/cpuidle.h
> @@ -21,7 +21,7 @@
>
> /* Idle state entry routines */
> #ifdef CONFIG_PPC_P7_NAP
> -#define IDLE_STATE_ENTER_SEQ(IDLE_INST) \
> +#define IDLE_STATE_ENTER_SEQ(IDLE_INST) \
> /* Magic NAP/SLEEP/WINKLE mode enter sequence */ \
> std r0,0(r1); \
> ptesync; \
> @@ -29,6 +29,9 @@
> 1: cmpd cr0,r0,r0; \
> bne 1b; \
> IDLE_INST; \
> +
Is the power saving magic sequence the same as before for power 9
as well?
Balbir Singh
^ permalink raw reply
* [PATCH v7 5/5] ARM: dts: da850: specify the maximum pixel clock rate for tilcdc
From: Bartosz Golaszewski @ 2016-12-13 10:09 UTC (permalink / raw)
To: Jyri Sarha, Tomi Valkeinen, David Airlie, Kevin Hilman,
Michael Turquette, Sekhar Nori, Rob Herring, Frank Rowand,
Mark Rutland, Laurent Pinchart, Peter Ujfalusi, Russell King,
Maxime Ripard
Cc: linux-devicetree, linux-drm, LKML, arm-soc, Bartosz Golaszewski
In-Reply-To: <1481623759-12786-1-git-send-email-bgolaszewski@baylibre.com>
At maximum CPU frequency of 300 MHz the maximum pixel clock frequency
is 37.5 MHz[1]. We must filter out any mode for which the calculated
pixel clock rate would exceed this value.
Specify the max-pixelclock property for the display node for
da850-lcdk.
[1] http://processors.wiki.ti.com/index.php/OMAP-L1x/C674x/AM1x_LCD_Controller_(LCDC)_Throughput_and_Optimization_Techniques
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/boot/dts/da850.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 6b0ef3d..58b1566 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -462,6 +462,7 @@
compatible = "ti,da850-tilcdc";
reg = <0x213000 0x1000>;
interrupts = <52>;
+ max-pixelclock = <37500>;
status = "disabled";
};
};
--
2.9.3
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH v7 4/5] ARM: dts: da850-lcdk: add the vga-bridge node
From: Bartosz Golaszewski @ 2016-12-13 10:09 UTC (permalink / raw)
To: Jyri Sarha, Tomi Valkeinen, David Airlie, Kevin Hilman,
Michael Turquette, Sekhar Nori, Rob Herring, Frank Rowand,
Mark Rutland, Laurent Pinchart, Peter Ujfalusi, Russell King,
Maxime Ripard
Cc: linux-devicetree, linux-drm, LKML, arm-soc, Bartosz Golaszewski
In-Reply-To: <1481623759-12786-1-git-send-email-bgolaszewski@baylibre.com>
Add the vga-bridge node to the board DT together with corresponding
ports and vga connector. This allows to retrieve the edid info from
the display automatically.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
arch/arm/boot/dts/da850-lcdk.dts | 51 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 51 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index afcb482..1ae2260 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -51,6 +51,45 @@
system-clock-frequency = <24576000>;
};
};
+
+ vga-bridge {
+ compatible = "ti,ths8135";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ vga_bridge_in: endpoint {
+ remote-endpoint = <&lcdc_out_vga>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ vga_bridge_out: endpoint {
+ remote-endpoint = <&vga_con_in>;
+ };
+ };
+ };
+ };
+
+ vga {
+ compatible = "vga-connector";
+
+ ddc-i2c-bus = <&i2c0>;
+
+ port {
+ vga_con_in: endpoint {
+ remote-endpoint = <&vga_bridge_out>;
+ };
+ };
+ };
};
&pmx_core {
@@ -236,3 +275,15 @@
&memctrl {
status = "okay";
};
+
+&lcdc {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_pins>;
+
+ port {
+ lcdc_out_vga: endpoint {
+ remote-endpoint = <&vga_bridge_in>;
+ };
+ };
+};
--
2.9.3
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH v7 3/5] drm: bridge: add support for TI ths8135
From: Bartosz Golaszewski @ 2016-12-13 10:09 UTC (permalink / raw)
To: Jyri Sarha, Tomi Valkeinen, David Airlie, Kevin Hilman,
Michael Turquette, Sekhar Nori, Rob Herring, Frank Rowand,
Mark Rutland, Laurent Pinchart, Peter Ujfalusi, Russell King,
Maxime Ripard
Cc: linux-devicetree, linux-drm, LKML, arm-soc, Bartosz Golaszewski
In-Reply-To: <1481623759-12786-1-git-send-email-bgolaszewski@baylibre.com>
THS8135 is a configurable video DAC, but no configuration is actually
necessary to make it work.
For now use the dumb-vga-dac driver to support it.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/gpu/drm/bridge/dumb-vga-dac.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c b/drivers/gpu/drm/bridge/dumb-vga-dac.c
index e570698..86e9f9c 100644
--- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
+++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
@@ -237,6 +237,7 @@ static int dumb_vga_remove(struct platform_device *pdev)
static const struct of_device_id dumb_vga_match[] = {
{ .compatible = "dumb-vga-dac" },
+ { .compatible = "ti,ths8135" },
{},
};
MODULE_DEVICE_TABLE(of, dumb_vga_match);
--
2.9.3
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH v7 2/5] drm: bridge: add DT bindings for TI ths8135
From: Bartosz Golaszewski @ 2016-12-13 10:09 UTC (permalink / raw)
To: Jyri Sarha, Tomi Valkeinen, David Airlie, Kevin Hilman,
Michael Turquette, Sekhar Nori, Rob Herring, Frank Rowand,
Mark Rutland, Laurent Pinchart, Peter Ujfalusi, Russell King,
Maxime Ripard
Cc: linux-devicetree, linux-drm, LKML, arm-soc, Bartosz Golaszewski
In-Reply-To: <1481623759-12786-1-git-send-email-bgolaszewski@baylibre.com>
THS8135 is a configurable video DAC. Add DT bindings for this chip.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Rob Herring <robh@kernel.org>
---
.../bindings/display/bridge/ti,ths8135.txt | 46 ++++++++++++++++++++++
1 file changed, 46 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
new file mode 100644
index 0000000..6ec1a88
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
@@ -0,0 +1,46 @@
+THS8135 Video DAC
+-----------------
+
+This is the binding for Texas Instruments THS8135 Video DAC bridge.
+
+Required properties:
+
+- compatible: Must be "ti,ths8135"
+
+Required nodes:
+
+This device has two video ports. Their connections are modelled using the OF
+graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 for RGB input
+- Video port 1 for VGA output
+
+Example
+-------
+
+vga-bridge {
+ compatible = "ti,ths8135";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ vga_bridge_in: endpoint {
+ remote-endpoint = <&lcdc_out_vga>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ vga_bridge_out: endpoint {
+ remote-endpoint = <&vga_con_in>;
+ };
+ };
+ };
+};
--
2.9.3
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH v7 1/5] ARM: dts: da850: rename the display node label
From: Bartosz Golaszewski @ 2016-12-13 10:09 UTC (permalink / raw)
To: Jyri Sarha, Tomi Valkeinen, David Airlie, Kevin Hilman,
Michael Turquette, Sekhar Nori, Rob Herring, Frank Rowand,
Mark Rutland, Laurent Pinchart, Peter Ujfalusi, Russell King,
Maxime Ripard
Cc: LKML, arm-soc, linux-drm, linux-devicetree, Bartosz Golaszewski
In-Reply-To: <1481623759-12786-1-git-send-email-bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
The tilcdc node name is 'display' as per the ePAPR 1.1 recommendation.
The label is also 'display', but change it to 'lcdc' to make it clear
what the underlying hardware is.
Signed-off-by: Bartosz Golaszewski <bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
---
arch/arm/boot/dts/da850.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 104155d..6b0ef3d 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -458,7 +458,7 @@
dma-names = "tx", "rx";
};
- display: display@213000 {
+ lcdc: display@213000 {
compatible = "ti,da850-tilcdc";
reg = <0x213000 0x1000>;
interrupts = <52>;
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v7 0/5] ARM: dts: da850: tilcdc related DT changes
From: Bartosz Golaszewski @ 2016-12-13 10:09 UTC (permalink / raw)
To: Jyri Sarha, Tomi Valkeinen, David Airlie, Kevin Hilman,
Michael Turquette, Sekhar Nori, Rob Herring, Frank Rowand,
Mark Rutland, Laurent Pinchart, Peter Ujfalusi, Russell King,
Maxime Ripard
Cc: LKML, arm-soc, linux-drm, linux-devicetree, Bartosz Golaszewski
This series contains the last DT changes required for LCDC support
on da850-lcdk. The first one adds the dumb-vga-dac nodes, the second
limits the maximum pixel clock rate.
v1 -> v2:
- drop patch 3/3 (already merged)
- use max-pixelclock instead of max-bandwidth for display mode limiting
v2 -> v3:
- make the commit message in patch [2/2] more detailed
- move the max-pixelclock property to da850.dtsi as the limit
affects all da850-based boards
v3 -> v4:
- remove the input port from the display node
- move the display ports node to da850-lcdk.dts
- rename the vga_bridge node to vga-bridge
- move the LCDC pins to the LCDC node (from the vga bridge node)
v4 -> v5:
- rename the display label to lcdc
- instead of using the 'dumb-vga-dac' compatible, add bindings for
ti,ths8135 and use it as the vga-bridge node compatible
v5 -> v6:
- drop the endpoint numbers for nodes with single endpoints
- split patch 2/4 from v5 into two separate patches: one adding DT
bindings and one adding actual support for ths8135
v6 -> v7:
- simplified patch 4/5 by removing unnecessary properties from ports
and endpoints nodes
Bartosz Golaszewski (5):
ARM: dts: da850: rename the display node label
drm: bridge: add DT bindings for TI ths8135
drm: bridge: add support for TI ths8135
ARM: dts: da850-lcdk: add the vga-bridge node
ARM: dts: da850: specify the maximum pixel clock rate for tilcdc
.../bindings/display/bridge/ti,ths8135.txt | 46 +++++++++++++++++++
arch/arm/boot/dts/da850-lcdk.dts | 51 ++++++++++++++++++++++
arch/arm/boot/dts/da850.dtsi | 3 +-
drivers/gpu/drm/bridge/dumb-vga-dac.c | 1 +
4 files changed, 100 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v6 5/5] ARM: configs: stm32: Add I2C support for STM32 defconfig
From: Alexandre Torgue @ 2016-12-13 10:03 UTC (permalink / raw)
To: M'boumba Cedric Madianga, wsa-z923LK4zBo2bacvFa/9K2g,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A, patrice.chotard-qxv4g6HH51o,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1481559342-6106-6-git-send-email-cedric.madianga-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Cedric,
On 12/12/2016 05:15 PM, M'boumba Cedric Madianga wrote:
> Signed-off-by: M'boumba Cedric Madianga <cedric.madianga-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Can you please add a commit message.
Thx in advance
Alex
> ---
> arch/arm/configs/stm32_defconfig | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
> index e7b56d4..9494eaf 100644
> --- a/arch/arm/configs/stm32_defconfig
> +++ b/arch/arm/configs/stm32_defconfig
> @@ -52,6 +52,9 @@ CONFIG_SERIAL_NONSTANDARD=y
> CONFIG_SERIAL_STM32=y
> CONFIG_SERIAL_STM32_CONSOLE=y
> # CONFIG_HW_RANDOM is not set
> +CONFIG_I2C=y
> +CONFIG_I2C_CHARDEV=y
> +CONFIG_I2C_STM32F4=y
> # CONFIG_HWMON is not set
> # CONFIG_USB_SUPPORT is not set
> CONFIG_NEW_LEDS=y
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v6 4/5] ARM: dts: stm32: Add I2C1 support for STM32429 eval board
From: Alexandre Torgue @ 2016-12-13 10:02 UTC (permalink / raw)
To: M'boumba Cedric Madianga, wsa, robh+dt, mcoquelin.stm32,
linus.walleij, patrice.chotard, linux, linux-i2c, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <1481559342-6106-5-git-send-email-cedric.madianga@gmail.com>
Hi Cedric,
On 12/12/2016 05:15 PM, M'boumba Cedric Madianga wrote:
> Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
Can you please add a commit message.
> ---
> arch/arm/boot/dts/stm32429i-eval.dts | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts b/arch/arm/boot/dts/stm32429i-eval.dts
> index afb90bc..74e0045 100644
> --- a/arch/arm/boot/dts/stm32429i-eval.dts
> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
> @@ -141,3 +141,9 @@
> pinctrl-names = "default";
> status = "okay";
> };
> +
> +&i2c1 {
> + pinctrl-0 = <&i2c1_pins_b>;
> + pinctrl-names = "default";
> + status = "okay";
> +};
>
^ 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