* Re: [PATCH 16/18] ARM64: dts: meson-gxl-s905x-nexbox-a95x: Reorder nodes
From: Neil Armstrong @ 2017-01-23 8:58 UTC (permalink / raw)
To: Andreas Färber, linux-amlogic
Cc: Mark Rutland, devicetree, Kevin Hilman, Will Deacon, linux-kernel,
Rob Herring, Catalin Marinas, Carlo Caione, linux-arm-kernel
In-Reply-To: <20170120222118.21476-17-afaerber@suse.de>
On 01/20/2017 11:21 PM, Andreas Färber wrote:
> Sort nodes referenced by label alphabetically.
>
> Signed-off-by: Andreas Färber <afaerber@suse.de>
> ---
> .../dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts | 28 +++++++++++-----------
> 1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts
> index cea4a3eded9b..9e91f0809dcd 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts
> @@ -129,10 +129,10 @@
> };
> };
>
> -&uart_AO {
> - status = "okay";
> - pinctrl-0 = <&uart_ao_a_pins>;
> - pinctrl-names = "default";
> +&cvbs_vdac_port {
> + cvbs_vdac_out: endpoint {
> + remote-endpoint = <&cvbs_connector_in>;
> + };
> };
>
> ðmac {
> @@ -147,6 +147,14 @@
> pinctrl-names = "default";
> };
>
> +&pwm_ef {
> + status = "okay";
> + pinctrl-0 = <&pwm_e_pins>;
> + pinctrl-names = "default";
> + clocks = <&clkc CLKID_FCLK_DIV4>;
> + clock-names = "clkin0";
> +};
> +
> /* Wireless SDIO Module */
> &sd_emmc_a {
> status = "okay";
> @@ -206,16 +214,8 @@
> vqmmc-supply = <&vddio_boot>;
> };
>
> -&pwm_ef {
> +&uart_AO {
> status = "okay";
> - pinctrl-0 = <&pwm_e_pins>;
> + pinctrl-0 = <&uart_ao_a_pins>;
> pinctrl-names = "default";
> - clocks = <&clkc CLKID_FCLK_DIV4>;
> - clock-names = "clkin0";
> -};
> -
> -&cvbs_vdac_port {
> - cvbs_vdac_out: endpoint {
> - remote-endpoint = <&cvbs_connector_in>;
> - };
> };
>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
^ permalink raw reply
* Re: [PATCH 17/18] ARM64: dts: meson-gxm-nexbox-a1: Reorder nodes
From: Neil Armstrong @ 2017-01-23 8:58 UTC (permalink / raw)
To: Andreas Färber, linux-amlogic
Cc: Mark Rutland, devicetree, Kevin Hilman, Will Deacon, linux-kernel,
Rob Herring, Catalin Marinas, Carlo Caione, linux-arm-kernel
In-Reply-To: <20170120222118.21476-18-afaerber@suse.de>
On 01/20/2017 11:21 PM, Andreas Färber wrote:
> Sort nodes referenced by label alphabetically.
>
> Signed-off-by: Andreas Färber <afaerber@suse.de>
> ---
> .../arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 58 +++++++++++-----------
> 1 file changed, 29 insertions(+), 29 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> index 439060652689..804e8de80f37 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> @@ -102,10 +102,35 @@
> };
> };
>
> -&uart_AO {
> +&cvbs_vdac_port {
> + cvbs_vdac_out: endpoint {
> + remote-endpoint = <&cvbs_connector_in>;
> + };
> +};
> +
> +ðmac {
> status = "okay";
> - pinctrl-0 = <&uart_ao_a_pins>;
> +
> + pinctrl-0 = <ð_pins>;
> pinctrl-names = "default";
> +
> + /* Select external PHY by default */
> + phy-handle = <&external_phy>;
> +
> + snps,reset-gpio = <&gpio GPIOZ_14 0>;
> + snps,reset-delays-us = <0 10000 1000000>;
> + snps,reset-active-low;
> +
> + /* External PHY is in RGMII */
> + phy-mode = "rgmii";
> +};
> +
> +&external_mdio {
> + external_phy: ethernet-phy@0 {
> + compatible = "ethernet-phy-id001c.c916", "ethernet-phy-ieee802.3-c22";
> + reg = <0>;
> + max-speed = <1000>;
> + };
> };
>
> &ir {
> @@ -152,33 +177,8 @@
> vqmmc-supply = <&vddio_boot>;
> };
>
> -ðmac {
> +&uart_AO {
> status = "okay";
> -
> - pinctrl-0 = <ð_pins>;
> + pinctrl-0 = <&uart_ao_a_pins>;
> pinctrl-names = "default";
> -
> - /* Select external PHY by default */
> - phy-handle = <&external_phy>;
> -
> - snps,reset-gpio = <&gpio GPIOZ_14 0>;
> - snps,reset-delays-us = <0 10000 1000000>;
> - snps,reset-active-low;
> -
> - /* External PHY is in RGMII */
> - phy-mode = "rgmii";
> -};
> -
> -&external_mdio {
> - external_phy: ethernet-phy@0 {
> - compatible = "ethernet-phy-id001c.c916", "ethernet-phy-ieee802.3-c22";
> - reg = <0>;
> - max-speed = <1000>;
> - };
> -};
> -
> -&cvbs_vdac_port {
> - cvbs_vdac_out: endpoint {
> - remote-endpoint = <&cvbs_connector_in>;
> - };
> };
>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
^ permalink raw reply
* Re: [PATCH 18/18] ARM64: dts: meson-gx-p23x-q20x: Reorder nodes
From: Neil Armstrong @ 2017-01-23 8:58 UTC (permalink / raw)
To: Andreas Färber, linux-amlogic
Cc: Mark Rutland, devicetree, Kevin Hilman, Will Deacon, linux-kernel,
Rob Herring, Catalin Marinas, Carlo Caione, linux-arm-kernel
In-Reply-To: <20170120222118.21476-19-afaerber@suse.de>
On 01/20/2017 11:21 PM, Andreas Färber wrote:
> Sort nodes referenced by label alphabetically.
>
> Signed-off-by: Andreas Färber <afaerber@suse.de>
> ---
> .../arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 24 +++++++++++-----------
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
> index 419c46cc64e4..cfc26a2a3a90 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
> @@ -100,11 +100,8 @@
> };
> };
>
> -/* This UART is brought out to the DB9 connector */
> -&uart_AO {
> +ðmac {
> status = "okay";
> - pinctrl-0 = <&uart_ao_a_pins>;
> - pinctrl-names = "default";
> };
>
> &ir {
> @@ -113,6 +110,14 @@
> pinctrl-names = "default";
> };
>
> +&pwm_ef {
> + status = "okay";
> + pinctrl-0 = <&pwm_e_pins>;
> + pinctrl-names = "default";
> + clocks = <&clkc CLKID_FCLK_DIV4>;
> + clock-names = "clkin0";
> +};
> +
> /* Wireless SDIO Module */
> &sd_emmc_a {
> status = "okay";
> @@ -177,14 +182,9 @@
> vqmmc-supply = <&vddio_boot>;
> };
>
> -&pwm_ef {
> +/* This UART is brought out to the DB9 connector */
> +&uart_AO {
> status = "okay";
> - pinctrl-0 = <&pwm_e_pins>;
> + pinctrl-0 = <&uart_ao_a_pins>;
> pinctrl-names = "default";
> - clocks = <&clkc CLKID_FCLK_DIV4>;
> - clock-names = "clkin0";
> -};
> -
> -ðmac {
> - status = "okay";
> };
>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
^ permalink raw reply
* Re: [PATCH RFC v2 1/4] ARM: dts: imx6qdl: add HummingBoard2 boards
From: Jon Nettleton @ 2017-01-23 8:58 UTC (permalink / raw)
To: Shawn Guo
Cc: Russell King, Fabio Estevam, Sascha Hauer, devicetree,
linux-arm-kernel, Rob Herring, Mark Rutland
In-Reply-To: <20170123083320.GL5662@dragon>
[-- Attachment #1: Type: text/plain, Size: 31682 bytes --]
On Mon, Jan 23, 2017 at 10:33 AM, Shawn Guo <shawnguo@kernel.org> wrote:
> On Fri, Jan 13, 2017 at 02:45:24PM +0000, Russell King wrote:
> > From: Jon Nettleton <jon@solid-run.com>
> >
> > This adds support for the Hummingboard Gate and Edge devices from
> > SolidRun.
> >
> > Signed-off-by: Jon Nettleton <jon@solid-run.com>
> > Signed-off-by: Rabeeh Khoury <rabeeh@solid-run.com>
> > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > ---
> > arch/arm/boot/dts/Makefile | 2 +
> > arch/arm/boot/dts/imx6dl-hummingboard2.dts | 52 +++
> > arch/arm/boot/dts/imx6q-hummingboard2.dts | 60 +++
> > arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi | 543
> +++++++++++++++++++++++++++
> > 4 files changed, 657 insertions(+)
> > create mode 100644 arch/arm/boot/dts/imx6dl-hummingboard2.dts
> > create mode 100644 arch/arm/boot/dts/imx6q-hummingboard2.dts
> > create mode 100644 arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
> >
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index 7327250f0bb6..09227cc15199 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -348,6 +348,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
> > imx6dl-gw552x.dtb \
> > imx6dl-gw553x.dtb \
> > imx6dl-hummingboard.dtb \
> > + imx6dl-hummingboard2.dtb \
> > imx6dl-icore.dtb \
> > imx6dl-nit6xlite.dtb \
> > imx6dl-nitrogen6x.dtb \
> > @@ -390,6 +391,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
> > imx6q-gw553x.dtb \
> > imx6q-h100.dtb \
> > imx6q-hummingboard.dtb \
> > + imx6q-hummingboard2.dtb \
> > imx6q-icore.dtb \
> > imx6q-icore-rqs.dtb \
> > imx6q-marsboard.dtb \
> > diff --git a/arch/arm/boot/dts/imx6dl-hummingboard2.dts
> b/arch/arm/boot/dts/imx6dl-hummingboard2.dts
> > new file mode 100644
> > index 000000000000..990b5050de5b
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/imx6dl-hummingboard2.dts
> > @@ -0,0 +1,52 @@
> > +/*
> > + * Device Tree file for SolidRun HummingBoard2
> > + * Copyright (C) 2015 Rabeeh Khoury <rabeeh@solid-run.com>
> > + * Based on work by Russell King
> > + *
> > + * This file is dual-licensed: you can use it either under the terms
> > + * of the GPL or the X11 license, at your option. Note that this dual
> > + * licensing only applies to this file, and not this project as a
> > + * whole.
> > + *
> > + * a) This file is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License as
> > + * published by the Free Software Foundation; either version 2 of
> the
> > + * License.
> > + *
> > + * This file is distributed in the hope that it will be useful
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + *
> > + * Or, alternatively
> > + *
> > + * b) Permission is hereby granted, free of charge, to any person
> > + * obtaining a copy of this software and associated documentation
> > + * files (the "Software"), to deal in the Software without
> > + * restriction, including without limitation the rights to use
> > + * copy, modify, merge, publish, distribute, sublicense, and/or
> > + * sell copies of the Software, and to permit persons to whom the
> > + * Software is furnished to do so, subject to the following
> > + * conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be
> > + * included in all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> > + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> > + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> > + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> > + * OTHER DEALINGS IN THE SOFTWARE.
> > + */
>
> The licence text is still the mangled version.
>
> > +/dts-v1/;
> > +
> > +#include "imx6dl.dtsi"
> > +#include "imx6qdl-hummingboard2.dtsi"
> > +
> > +/ {
> > + model = "SolidRun HummingBoard2 Solo/DualLite";
> > + compatible = "solidrun,hummingboard2/dl", "fsl,imx6dl";
> > +};
> > diff --git a/arch/arm/boot/dts/imx6q-hummingboard2.dts
> b/arch/arm/boot/dts/imx6q-hummingboard2.dts
> > new file mode 100644
> > index 000000000000..f5eec9163bb8
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/imx6q-hummingboard2.dts
> > @@ -0,0 +1,60 @@
> > +/*
> > + * Device Tree file for SolidRun HummingBoard2
> > + * Copyright (C) 2015 Rabeeh Khoury <rabeeh@solid-run.com>
> > + * Based on work by Russell King
> > + *
> > + * This file is dual-licensed: you can use it either under the terms
> > + * of the GPL or the X11 license, at your option. Note that this dual
> > + * licensing only applies to this file, and not this project as a
> > + * whole.
> > + *
> > + * a) This file is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License as
> > + * published by the Free Software Foundation; either version 2 of
> the
> > + * License.
> > + *
> > + * This file is distributed in the hope that it will be useful
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + *
> > + * Or, alternatively
> > + *
> > + * b) Permission is hereby granted, free of charge, to any person
> > + * obtaining a copy of this software and associated documentation
> > + * files (the "Software"), to deal in the Software without
> > + * restriction, including without limitation the rights to use
> > + * copy, modify, merge, publish, distribute, sublicense, and/or
> > + * sell copies of the Software, and to permit persons to whom the
> > + * Software is furnished to do so, subject to the following
> > + * conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be
> > + * included in all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> > + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> > + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> > + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> > + * OTHER DEALINGS IN THE SOFTWARE.
> > + */
>
> Ditto
>
> > +/dts-v1/;
> > +
> > +#include "imx6q.dtsi"
> > +#include "imx6qdl-hummingboard2.dtsi"
> > +
> > +/ {
> > + model = "SolidRun HummingBoard2 Dual/Quad";
> > + compatible = "solidrun,hummingboard2/q", "fsl,imx6q";
> > +};
> > +
> > +&sata {
> > + status = "okay";
> > + fsl,transmit-level-mV = <1104>;
> > + fsl,transmit-boost-mdB = <0>;
> > + fsl,transmit-atten-16ths = <9>;
> > + fsl,no-spread-spectrum;
> > +};
> > diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
> b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
> > new file mode 100644
> > index 000000000000..11b63f6f2b89
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
> > @@ -0,0 +1,543 @@
> > +/*
> > + * Device Tree file for SolidRun HummingBoard2
> > + * Copyright (C) 2015 Rabeeh Khoury <rabeeh@solid-run.com>
> > + *
> > + * This file is dual-licensed: you can use it either under the terms
> > + * of the GPL or the X11 license, at your option. Note that this dual
> > + * licensing only applies to this file, and not this project as a
> > + * whole.
> > + *
> > + * a) This file is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License as
> > + * published by the Free Software Foundation; either version 2 of
> the
> > + * License.
> > + *
> > + * This file is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + *
> > + * Or, alternatively,
> > + *
> > + * b) Permission is hereby granted, free of charge, to any person
> > + * obtaining a copy of this software and associated documentation
> > + * files (the "Software"), to deal in the Software without
> > + * restriction, including without limitation the rights to use
> > + * copy, modify, merge, publish, distribute, sublicense, and/or
> > + * sell copies of the Software, and to permit persons to whom the
> > + * Software is furnished to do so, subject to the following
> > + * conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be
> > + * included in all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> > + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> > + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> > + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> > + * OTHER DEALINGS IN THE SOFTWARE.
> > + */
>
> This one is correct.
>
> > +#include "imx6qdl-microsom.dtsi"
> > +#include "imx6qdl-microsom-ar8035.dtsi"
> > +
> > +/ {
> > + chosen {
> > + stdout-path = &uart1;
> > + };
> > +
> > + ir_recv: ir-receiver {
> > + compatible = "gpio-ir-receiver";
> > + gpios = <&gpio7 9 1>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_hummingboard2_gpio7_9>;
> > + linux,rc-map-name = "rc-rc6-mce";
> > + };
> > +
> > + usdhc2_pwrseq: usdhc2-pwrseq {
> > + compatible = "mmc-pwrseq-simple";
> > + reset-gpios = <&gpio4 30 GPIO_ACTIVE_HIGH>;
> > + };
> > +
> > + reg_3p3v: regulator-3p3v {
> > + compatible = "regulator-fixed";
> > + regulator-name = "3P3V";
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + regulator-always-on;
> > + };
> > +
> > + reg_1p8v: regulator-1p8v {
> > + compatible = "regulator-fixed";
> > + regulator-name = "1P8V";
> > + regulator-min-microvolt = <1800000>;
> > + regulator-max-microvolt = <1800000>;
> > + regulator-always-on;
> > + };
> > +
> > + reg_usbh1_vbus: regulator-usb-h1-vbus {
> > + compatible = "regulator-fixed";
> > + enable-active-high;
> > + gpio = <&gpio1 0 0>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_hummingboard2_usbh1_vbus>;
> > + regulator-name = "usb_h1_vbus";
> > + regulator-min-microvolt = <5000000>;
> > + regulator-max-microvolt = <5000000>;
> > + };
> > +
> > + reg_usbotg_vbus: regulator-usb-otg-vbus {
> > + compatible = "regulator-fixed";
> > + enable-active-high;
> > + gpio = <&gpio3 22 0>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_hummingboard2_usbotg_vbus>;
> > + regulator-name = "usb_otg_vbus";
> > + regulator-min-microvolt = <5000000>;
> > + regulator-max-microvolt = <5000000>;
> > + };
> > +
> > + reg_usbh2_vbus: regulator-usb-h2-vbus {
> > + compatible = "regulator-gpio";
> > + enable-active-high;
> > + enable-gpio = <&gpio2 13 0>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_hummingboard2_usbh2_vbus>;
> > + regulator-name = "usb_h2_vbus";
> > + regulator-min-microvolt = <5000000>;
> > + regulator-max-microvolt = <5000000>;
> > + regulator-boot-on;
> > + };
> > +
> > + reg_usbh3_vbus: regulator-usb-h3-vbus {
> > + compatible = "regulator-gpio";
> > + enable-active-high;
> > + enable-gpio = <&gpio7 10 0>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_hummingboard2_usbh3_vbus>;
> > + regulator-name = "usb_h3_vbus";
> > + regulator-min-microvolt = <5000000>;
> > + regulator-max-microvolt = <5000000>;
> > + regulator-boot-on;
> > + };
> > +
> > + sound-sgtl5000 {
> > + audio-codec = <&sgtl5000>;
> > + audio-routing =
> > + "MIC_IN", "Mic Jack",
> > + "Mic Jack", "Mic Bias",
> > + "Headphone Jack", "HP_OUT";
> > + compatible = "fsl,imx-audio-sgtl5000";
> > + model = "On-board Codec";
> > + mux-ext-port = <5>;
> > + mux-int-port = <1>;
> > + ssi-controller = <&ssi1>;
> > + };
> > +};
> > +
> > +&audmux {
> > + status = "okay";
> > +};
> > +
> > +&ecspi2 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_hummingboard2_ecspi2>;
> > + cs-gpios = <&gpio2 26 0>;
> > + status = "okay";
> > +};
> > +
> > +&hdmi {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_hummingboard2_hdmi>;
> > + ddc-i2c-bus = <&i2c2>;
> > + status = "okay";
> > +};
> > +
> > +&i2c1 {
> > + clock-frequency = <100000>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_hummingboard2_i2c1>;
> > + status = "okay";
> > +
> > + pcf8523: rtc@68 {
> > + compatible = "nxp,pcf8523";
> > + reg = <0x68>;
> > + nxp,12p5_pf;
> > + };
>
> I do not see this support in mainline kernel.
>
Sorry that is my fault. I will remove it, and re-add it after the driver
changes are upstreamed.
>
> Shawn
>
> > +
> > + sgtl5000: codec@0a {
> > + clocks = <&clks IMX6QDL_CLK_CKO>;
> > + compatible = "fsl,sgtl5000";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_hummingboard2_sgtl5000>;
> > + reg = <0x0a>;
> > + VDDA-supply = <®_3p3v>;
> > + VDDIO-supply = <®_3p3v>;
> > + };
> > +};
> > +
> > +&i2c2 {
> > + clock-frequency = <100000>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_hummingboard2_i2c2>;
> > + status = "okay";
> > +};
> > +
> > +&i2c3 {
> > + clock-frequency = <100000>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_hummingboard2_i2c3>;
> > + status = "okay";
> > +};
> > +
> > +&iomuxc {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_hog>;
> > +
> > + hummingboard2 {
> > + pinctrl_hog: hoggrp {
> > + fsl,pins = <
> > + /*
> > + * 36 pin headers GPIO description. The
> pins
> > + * numbering as following -
> > + *
> > + * 3.2v 5v 74 75
> > + * 73 72 71 70
> > + * 69 68 67 66
> > + *
> > + * 77 78 79 76
> > + * 65 64 61 60
> > + * 53 52 51 50
> > + * 49 48 166 132
> > + * 95 94 90 91
> > + * GND 54 24 204
> > + *
> > + * The GPIO numbers can be extracted using
> > + * signal name from below.
> > + * Example -
> > + * MX6QDL_PAD_EIM_DA10__GPIO3_IO10 is
> > + * GPIO(3,10) which is (3-1)*32+10 = gpio
> 74
> > + *
> > + * i.e. The mapping of GPIO(X,Y) to Linux
> gpio
> > + * number is : gpio number = (X-1) * 32 + Y
> > + */
> > + /* DI1_PIN15 */
> > + MX6QDL_PAD_EIM_DA10__GPIO3_IO10 0x400130b1
> > + /* DI1_PIN02 */
> > + MX6QDL_PAD_EIM_DA11__GPIO3_IO11 0x400130b1
> > + /* DISP1_DATA00 */
> > + MX6QDL_PAD_EIM_DA9__GPIO3_IO09 0x400130b1
> > + /* DISP1_DATA01 */
> > + MX6QDL_PAD_EIM_DA8__GPIO3_IO08 0x400130b1
> > + /* DISP1_DATA02 */
> > + MX6QDL_PAD_EIM_DA7__GPIO3_IO07 0x400130b1
> > + /* DISP1_DATA03 */
> > + MX6QDL_PAD_EIM_DA6__GPIO3_IO06 0x400130b1
> > + /* DISP1_DATA04 */
> > + MX6QDL_PAD_EIM_DA5__GPIO3_IO05 0x400130b1
> > + /* DISP1_DATA05 */
> > + MX6QDL_PAD_EIM_DA4__GPIO3_IO04 0x400130b1
> > + /* DISP1_DATA06 */
> > + MX6QDL_PAD_EIM_DA3__GPIO3_IO03 0x400130b1
> > + /* DISP1_DATA07 */
> > + MX6QDL_PAD_EIM_DA2__GPIO3_IO02 0x400130b1
> > + /* DI1_D0_CS */
> > + MX6QDL_PAD_EIM_DA13__GPIO3_IO13 0x400130b1
> > + /* DI1_D1_CS */
> > + MX6QDL_PAD_EIM_DA14__GPIO3_IO14 0x400130b1
> > + /* DI1_PIN01 */
> > + MX6QDL_PAD_EIM_DA15__GPIO3_IO15 0x400130b1
> > + /* DI1_PIN03 */
> > + MX6QDL_PAD_EIM_DA12__GPIO3_IO12 0x400130b1
> > + /* DISP1_DATA08 */
> > + MX6QDL_PAD_EIM_DA1__GPIO3_IO01 0x400130b1
> > + /* DISP1_DATA09 */
> > + MX6QDL_PAD_EIM_DA0__GPIO3_IO00 0x400130b1
> > + /* DISP1_DATA10 */
> > + MX6QDL_PAD_EIM_EB1__GPIO2_IO29 0x400130b1
> > + /* DISP1_DATA11 */
> > + MX6QDL_PAD_EIM_EB0__GPIO2_IO28 0x400130b1
> > + /* DISP1_DATA12 */
> > + MX6QDL_PAD_EIM_A17__GPIO2_IO21 0x400130b1
> > + /* DISP1_DATA13 */
> > + MX6QDL_PAD_EIM_A18__GPIO2_IO20 0x400130b1
> > + /* DISP1_DATA14 */
> > + MX6QDL_PAD_EIM_A19__GPIO2_IO19 0x400130b1
> > + /* DISP1_DATA15 */
> > + MX6QDL_PAD_EIM_A20__GPIO2_IO18 0x400130b1
> > + /* DISP1_DATA16 */
> > + MX6QDL_PAD_EIM_A21__GPIO2_IO17 0x400130b1
> > + /* DISP1_DATA17 */
> > + MX6QDL_PAD_EIM_A22__GPIO2_IO16 0x400130b1
> > + /* DISP1_DATA18 */
> > + MX6QDL_PAD_EIM_A23__GPIO6_IO06 0x400130b1
> > + /* DISP1_DATA19 */
> > + MX6QDL_PAD_EIM_A24__GPIO5_IO04 0x400130b1
> > + /* DISP1_DATA20 */
> > + MX6QDL_PAD_EIM_D31__GPIO3_IO31 0x400130b1
> > + /* DISP1_DATA21 */
> > + MX6QDL_PAD_EIM_D30__GPIO3_IO30 0x400130b1
> > + /* DISP1_DATA22 */
> > + MX6QDL_PAD_EIM_D26__GPIO3_IO26 0x400130b1
> > + /* DISP1_DATA23 */
> > + MX6QDL_PAD_EIM_D27__GPIO3_IO27 0x400130b1
> > + /* DI1_DISP_CLK */
> > + MX6QDL_PAD_EIM_A16__GPIO2_IO22 0x400130b1
> > + /* SPDIF_IN */
> > + MX6QDL_PAD_ENET_RX_ER__GPIO1_IO24
> 0x400130b1
> > + /* SPDIF_OUT */
> > + MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x400130b1
> > +
> > + /* MikroBUS GPIO pin number 10 */
> > + MX6QDL_PAD_EIM_LBA__GPIO2_IO27 0x400130b1
> > + >;
> > + };
> > +
> > + pinctrl_hummingboard2_ecspi2: hummingboard2-ecspi2grp {
> > + fsl,pins = <
> > + MX6QDL_PAD_EIM_OE__ECSPI2_MISO 0x100b1
> > + MX6QDL_PAD_EIM_CS1__ECSPI2_MOSI 0x100b1
> > + MX6QDL_PAD_EIM_CS0__ECSPI2_SCLK 0x100b1
> > + MX6QDL_PAD_EIM_RW__GPIO2_IO26 0x000b1 /*
> CS */
> > + >;
> > + };
> > +
> > + pinctrl_hummingboard2_gpio7_9: hummingboard2-gpio7_9 {
> > + fsl,pins = <
> > + MX6QDL_PAD_SD4_CMD__GPIO7_IO09 0x80000000
> > + >;
> > + };
> > +
> > + pinctrl_hummingboard2_hdmi: hummingboard2-hdmi {
> > + fsl,pins = <
> > + MX6QDL_PAD_KEY_ROW2__HDMI_TX_CEC_LINE
> 0x1f8b0
> > + >;
> > + };
> > +
> > + pinctrl_hummingboard2_i2c1: hummingboard2-i2c1 {
> > + fsl,pins = <
> > + MX6QDL_PAD_EIM_D21__I2C1_SCL 0x4001b8b1
> > + MX6QDL_PAD_EIM_D28__I2C1_SDA 0x4001b8b1
> > + >;
> > + };
> > +
> > + pinctrl_hummingboard2_i2c2: hummingboard2-i2c2 {
> > + fsl,pins = <
> > + MX6QDL_PAD_KEY_COL3__I2C2_SCL 0x4001b8b1
> > + MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
> > + >;
> > + };
> > +
> > + pinctrl_hummingboard2_i2c3: hummingboard2-i2c3 {
> > + fsl,pins = <
> > + MX6QDL_PAD_EIM_D17__I2C3_SCL 0x4001b8b1
> > + MX6QDL_PAD_EIM_D18__I2C3_SDA 0x4001b8b1
> > + >;
> > + };
> > +
> > + pinctrl_hummingboard2_mipi: hummingboard2_mipi {
> > + fsl,pins = <
> > + MX6QDL_PAD_SD4_DAT2__GPIO2_IO10 0x4001b8b1
> > + MX6QDL_PAD_KEY_COL4__GPIO4_IO14 0x4001b8b1
> > + MX6QDL_PAD_NANDF_CS2__CCM_CLKO2 0x130b0
> > + >;
> > + };
> > +
> > + pinctrl_hummingboard2_pcie_reset:
> hummingboard2-pcie-reset {
> > + fsl,pins = <
> > + MX6QDL_PAD_SD4_DAT3__GPIO2_IO11 0x1b0b1
> > + >;
> > + };
> > +
> > + pinctrl_hummingboard2_pwm1: pwm1grp {
> > + fsl,pins = <
> > + MX6QDL_PAD_DISP0_DAT8__PWM1_OUT 0x1b0b1
> > + >;
> > + };
> > +
> > + pinctrl_hummingboard2_sgtl5000: hummingboard2-sgtl5000 {
> > + fsl,pins = <
> > + MX6QDL_PAD_DISP0_DAT19__AUD5_RXD 0x130b0
> > + MX6QDL_PAD_KEY_COL0__AUD5_TXC 0x130b0
> > + MX6QDL_PAD_KEY_ROW0__AUD5_TXD 0x110b0
> > + MX6QDL_PAD_KEY_COL1__AUD5_TXFS 0x130b0
> > + MX6QDL_PAD_GPIO_5__CCM_CLKO1 0x130b0
> > + >;
> > + };
> > +
> > + pinctrl_hummingboard2_usbh1_vbus:
> hummingboard2-usbh1-vbus {
> > + fsl,pins = <MX6QDL_PAD_GPIO_0__GPIO1_IO00 0x1b0b0>;
> > + };
> > +
> > + pinctrl_hummingboard2_usbh2_vbus:
> hummingboard2-usbh2-vbus {
> > + fsl,pins = <MX6QDL_PAD_SD4_DAT5__GPIO2_IO13
> 0x1b0b0>;
> > + };
> > +
> > + pinctrl_hummingboard2_usbh3_vbus:
> hummingboard2-usbh3-vbus {
> > + fsl,pins = <MX6QDL_PAD_SD4_CLK__GPIO7_IO10
> 0x1b0b0>;
> > + };
> > +
> > + pinctrl_hummingboard2_usbotg_id: hummingboard2-usbotg-id {
> > + /*
> > + * Similar to pinctrl_usbotg_2, but we want it
> > + * pulled down for a fixed host connection.
> > + */
> > + fsl,pins = <MX6QDL_PAD_GPIO_1__USB_OTG_ID 0x13059>;
> > + };
> > +
> > + pinctrl_hummingboard2_usbotg_vbus:
> hummingboard2-usbotg-vbus {
> > + fsl,pins = <MX6QDL_PAD_EIM_D22__GPIO3_IO22
> 0x1b0b0>;
> > + };
> > +
> > + pinctrl_hummingboard2_usdhc2_aux:
> hummingboard2-usdhc2-aux {
> > + fsl,pins = <
> > + MX6QDL_PAD_GPIO_4__GPIO1_IO04 0x13071
> > + MX6QDL_PAD_KEY_ROW1__SD2_VSELECT 0x1b071
> > + MX6QDL_PAD_DISP0_DAT9__GPIO4_IO30 0x1b0b0
> > + >;
> > + };
> > +
> > + pinctrl_hummingboard2_usdhc2: hummingboard2-usdhc2 {
> > + fsl,pins = <
> > + MX6QDL_PAD_SD2_CMD__SD2_CMD 0x17059
> > + MX6QDL_PAD_SD2_CLK__SD2_CLK 0x10059
> > + MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x17059
> > + MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x17059
> > + MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x17059
> > + MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x13059
> > + >;
> > + };
> > +
> > + pinctrl_hummingboard2_usdhc2_100mhz:
> hummingboard2-usdhc2-100mhz {
> > + fsl,pins = <
> > + MX6QDL_PAD_SD2_CMD__SD2_CMD 0x170b9
> > + MX6QDL_PAD_SD2_CLK__SD2_CLK 0x100b9
> > + MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x170b9
> > + MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x170b9
> > + MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x170b9
> > + MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x130b9
> > + >;
> > + };
> > +
> > + pinctrl_hummingboard2_usdhc2_200mhz:
> hummingboard2-usdhc2-200mhz {
> > + fsl,pins = <
> > + MX6QDL_PAD_SD2_CMD__SD2_CMD 0x170f9
> > + MX6QDL_PAD_SD2_CLK__SD2_CLK 0x100f9
> > + MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x170f9
> > + MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x170f9
> > + MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x170f9
> > + MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x130f9
> > + >;
> > + };
> > +
> > + pinctrl_hummingboard2_usdhc3: hummingboard2-usdhc3 {
> > + fsl,pins = <
> > + MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17059
> > + MX6QDL_PAD_SD3_CLK__SD3_CLK 0x10059
> > + MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17059
> > + MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17059
> > + MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17059
> > + MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17059
> > + MX6QDL_PAD_SD3_DAT4__SD3_DATA4 0x17059
> > + MX6QDL_PAD_SD3_DAT5__SD3_DATA5 0x17059
> > + MX6QDL_PAD_SD3_DAT6__SD3_DATA6 0x17059
> > + MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x17059
> > + MX6QDL_PAD_SD3_RST__SD3_RESET 0x17059
> > + >;
> > + };
> > +
> > + pinctrl_hummingboard2_uart3: hummingboard2-uart3 {
> > + fsl,pins = <
> > + MX6QDL_PAD_EIM_D25__UART3_TX_DATA
> 0x1b0b1
> > + MX6QDL_PAD_EIM_D24__UART3_RX_DATA
> 0x40013000
> > + >;
> > + };
> > + };
> > +};
> > +
> > +&ldb {
> > + status = "disabled";
> > +
> > + lvds-channel@0 {
> > + fsl,data-mapping = "spwg";
> > + fsl,data-width = <18>;
> > + };
> > +};
> > +
> > +&pcie {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_hummingboard2_pcie_reset>;
> > + reset-gpio = <&gpio2 11 0>;
> > + status = "okay";
> > +};
> > +
> > +&pwm1 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_hummingboard2_pwm1>;
> > + status = "okay";
> > +};
> > +
> > +&pwm3 {
> > + status = "disabled";
> > +};
> > +
> > +&pwm4 {
> > + status = "disabled";
> > +};
> > +
> > +&ssi1 {
> > + status = "okay";
> > +};
> > +
> > +&usbh1 {
> > + disable-over-current;
> > + vbus-supply = <®_usbh1_vbus>;
> > + status = "okay";
> > +};
> > +
> > +&usbotg {
> > + disable-over-current;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_hummingboard2_usbotg_id>;
> > + vbus-supply = <®_usbotg_vbus>;
> > + status = "okay";
> > +};
> > +
> > +&usdhc2 {
> > + pinctrl-names = "default", "state_100mhz", "state_200mhz";
> > + pinctrl-0 = <
> > + &pinctrl_hummingboard2_usdhc2_aux
> > + &pinctrl_hummingboard2_usdhc2
> > + >;
> > + pinctrl-1 = <
> > + &pinctrl_hummingboard2_usdhc2_aux
> > + &pinctrl_hummingboard2_usdhc2_100mhz
> > + >;
> > + pinctrl-2 = <
> > + &pinctrl_hummingboard2_usdhc2_aux
> > + &pinctrl_hummingboard2_usdhc2_200mhz
> > + >;
> > + mmc-pwrseq = <&usdhc2_pwrseq>;
> > + cd-gpios = <&gpio1 4 0>;
> > + status = "okay";
> > +};
> > +
> > +&usdhc3 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <
> > + &pinctrl_hummingboard2_usdhc3
> > + >;
> > + vmmc-supply = <®_3p3v>;
> > + vqmmc-supply = <®_3p3v>;
> > + bus-width = <8>;
> > + non-removable;
> > + status = "okay";
> > +};
> > +
> > +&uart3 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_hummingboard2_uart3>;
> > + status = "okay";
> > +};
> > --
> > 2.7.4
> >
>
I will resubmit with the additional license changes.
[-- Attachment #2: Type: text/html, Size: 43253 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: imx6qdl: Fix "ERROR: code indent should use tabs where possible"
From: Shawn Guo @ 2017-01-23 9:01 UTC (permalink / raw)
To: Jagan Teki
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Matteo Lisi,
Michael Trimarchi, Jagan Teki
In-Reply-To: <1484517012-13321-2-git-send-email-jagan-oRp2ZoJdM/RWk0Htik3J/w@public.gmane.org>
On Sun, Jan 15, 2017 at 10:50:12PM +0100, Jagan Teki wrote:
> From: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
>
> Fixed code indent tabs in respetcive imx6qdl dtsi files and
s/respetcive/respective
I fixed it up and applied both patches.
Shawn
> also add space on imx6qdl-icore-rqs.dtsi on usdhc bus-width nodes.
>
> Cc: Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
--
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 v5 5/5] i2c: mux: pca954x: Add irq-mask-enable to delay enabling irqs
From: Phil Reid @ 2017-01-23 9:02 UTC (permalink / raw)
To: Peter Rosin, wsa, robh+dt, mark.rutland, linux-i2c, devicetree
In-Reply-To: <71f756e1-4677-8b59-81a2-2b12fbf12621@axentia.se>
On 20/01/2017 06:56, Peter Rosin wrote:
> On 2017-01-19 08:48, Phil Reid wrote:
>> On 18/01/2017 20:19, Peter Rosin wrote:
>>> On 2017-01-17 09:00, Phil Reid wrote:
[snip]
>>> Hmm, this whole thing is fiddly and while it solves your problem it doesn't
>>> allow for solving the more general problem when there are "problematic"
>>> devices mixed with other devices. At least, I don't see it. And the
>>> limitations we are walking into with tracking number of enables etc suggests
>>> that we are attacking this at the wrong level. Maybe you should try to work
>>> around the hw limitations not in the pca954x driver, but in the irq core?
>>
>> I'm looking at the option of getting the hardware changed to not route
>> the irq for my chips thru the i2c mux. Fortunately the hardware is going thru a
>> revision for some other changes. Messing with the irq core sounds dangerous
>> with my level of knowledge.
>
> Yeah, but I bet you'd get some attention from people with more irq
> experience. That can't be bad :-)
>
>> The other way I think I can tackle it after reading the datasheet for the ltc1760 is that
>> it'll deassert it's irq (smbalert) line when the host sends a ARA request on the bus segment.
>> There's a driver in the kernel for this already, but it's not DT enable and doesn't
>> handle multiple bus segments. I'll have a look at that as well.
>> Pretty sure it would need the mux to become an irq parent as per patch 1-3 of this series.
>> This would be so the system can figure out which segment to do the poll on.
>
> Yeah sounds neater. It has the slight drawback that it may not work
> for pure i2c buses since it an SMB thing??
>
> BTW, why do you need special treatment for multiple segments? Will it not
> simply have an ARA appear on whatever i2c bus the device sits on? And if
> something requests to send an ARA message on a bus that happens to be a
> muxed segment, my mental picture is that the mux will be operated as usual
> so that the ARA appears on the muxed segment. Maybe I'm missing something?
My think was the following.
When the SMBALERT is asserted a ARA needs to be sent by the master.
If the device sending the SMBALERT is behind a mux when need to know which segment of the bus to enable.
Using shared interrupts should work I think, but you have to iterate thru each bus segment.
If the alert device is nested behind a couple of muxes this could get expensive.
But yeah otherwise I think the correct mux segment will get enabled automatically.
The current SMBALERT driver only seems to attached to the root i2c adapter.
>
>> But p4-5 could be dropped which is where we're stuck I think.
>
> Yes, I dislike to add a workaround for a specific case that might get
> in the way for anybody wishing to fix a bigger, more generic, problem...
>
>> Looking at this approach it shouldn't matter if the ltc1760 driver has registered yet or not.
>> This approach possibly has a lot more generic appeal I think.
>>
>> Thoughts on just submitting p1-3 for now while I figure out the SMB alert approach?
>
> Yes, looks like a plan. Thanks in advance!
Thanks, I'll do a new version with just p1-3.
>>>>
>>>> - if (!data->irq_mask)
>>>> - enable_irq(data->client->irq);
>>>> data->irq_mask |= BIT(pos);
>>>> + if (!data->irq_enabled
>>>> + && (data->irq_mask & mask_enable) == mask_enable) {
>>>
>>> I think the coding standard says that the && should be at the end of the
>>> first line. Didn't checkpatch complain?
>>
>> No it didn't complain. and I wasn't sure which way to do this.
>
> Ah, you need the --strict option for that to show up...
>
Haven't come across that option, I'll give it a try in future.
--
Regards
Phil Reid
^ permalink raw reply
* Re: [PATCH 1/9] drm/fb-cma-helper: Add drm_fbdev_cma_set_suspend_unlocked()
From: Daniel Vetter @ 2017-01-23 9:07 UTC (permalink / raw)
To: Noralf Trønnes
Cc: thomas.petazzoni, devicetree, linux-kernel, dri-devel,
laurent.pinchart
In-Reply-To: <20170122181117.8210-2-noralf@tronnes.org>
On Sun, Jan 22, 2017 at 07:11:09PM +0100, Noralf Trønnes wrote:
> Add a CMA version of drm_fb_helper_set_suspend_unlocked().
>
> Cc: laurent.pinchart@ideasonboard.com
> Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
> ---
> drivers/gpu/drm/drm_fb_cma_helper.c | 18 ++++++++++++++++++
> include/drm/drm_fb_cma_helper.h | 2 ++
> 2 files changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c b/drivers/gpu/drm/drm_fb_cma_helper.c
> index 4364abf..0ef8b28 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -622,3 +622,21 @@ void drm_fbdev_cma_set_suspend(struct drm_fbdev_cma *fbdev_cma, int state)
> drm_fb_helper_set_suspend(&fbdev_cma->fb_helper, state);
> }
> EXPORT_SYMBOL(drm_fbdev_cma_set_suspend);
Random idea for a cleanup series: Getting rid of
drm_fb_helper_set_suspend. I thinkf for almost all drivers we can use the
unlocked one, which has the upside that it doesn't stall the resume path
on the contended console_lock.
Anyway, applied this one here, thanks.
-Daniel
> +
> +/**
> + * drm_fbdev_cma_set_suspend_unlocked - wrapper around
> + * drm_fb_helper_set_suspend_unlocked
> + * @fbdev_cma: The drm_fbdev_cma struct, may be NULL
> + * @state: desired state, zero to resume, non-zero to suspend
> + *
> + * Calls drm_fb_helper_set_suspend, which is a wrapper around
> + * fb_set_suspend implemented by fbdev core.
> + */
> +void drm_fbdev_cma_set_suspend_unlocked(struct drm_fbdev_cma *fbdev_cma,
> + int state)
> +{
> + if (fbdev_cma)
> + drm_fb_helper_set_suspend_unlocked(&fbdev_cma->fb_helper,
> + state);
> +}
> +EXPORT_SYMBOL(drm_fbdev_cma_set_suspend_unlocked);
> diff --git a/include/drm/drm_fb_cma_helper.h b/include/drm/drm_fb_cma_helper.h
> index 9f4e34e..8dd6e55 100644
> --- a/include/drm/drm_fb_cma_helper.h
> +++ b/include/drm/drm_fb_cma_helper.h
> @@ -26,6 +26,8 @@ void drm_fbdev_cma_fini(struct drm_fbdev_cma *fbdev_cma);
> void drm_fbdev_cma_restore_mode(struct drm_fbdev_cma *fbdev_cma);
> void drm_fbdev_cma_hotplug_event(struct drm_fbdev_cma *fbdev_cma);
> void drm_fbdev_cma_set_suspend(struct drm_fbdev_cma *fbdev_cma, int state);
> +void drm_fbdev_cma_set_suspend_unlocked(struct drm_fbdev_cma *fbdev_cma,
> + int state);
>
> void drm_fb_cma_destroy(struct drm_framebuffer *fb);
> int drm_fb_cma_create_handle(struct drm_framebuffer *fb,
> --
> 2.10.2
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v14 3/5] tee: add OP-TEE driver
From: Jens Wiklander @ 2017-01-23 9:08 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Greg Kroah-Hartman, Olof Johansson, Andrew Morton, Wei Xu,
linux-kernel, linux-arm-kernel, devicetree, Al Viro,
valentin.manea, jean-michel.delorme, emmanuel.michel, javier,
Jason Gunthorpe, Mark Rutland, Michal Simek, Rob Herring,
Will Deacon, Nishanth Menon, Andrew F . Davis, broonie,
scott.branden
In-Reply-To: <8183743.bSJXZpMh95@wuerfel>
On Fri, Jan 20, 2017 at 05:57:51PM +0100, Arnd Bergmann wrote:
> On Thursday, January 19, 2017 3:56:23 PM CET Jens Wiklander wrote:
> > On Wed, Jan 18, 2017 at 05:28:17PM +0100, Arnd Bergmann wrote:
> > > On Wednesday, January 18, 2017 1:58:14 PM CET Jens Wiklander wrote:
>
> > > > +static int __init optee_driver_init(void)
> > > > +{
> > > > + struct device_node *node;
> > > > +
> > > > + /*
> > > > + * Preferred path is /firmware/optee, but it's the matching that
> > > > + * matters.
> > > > + */
> > > > + for_each_matching_node(node, optee_match)
> > > > + of_platform_device_create(node, NULL, NULL);
> > > > +
> > > > + return platform_driver_register(&optee_driver);
> > > > +}
> > > > +module_init(optee_driver_init);
> > > > +
> > > > +static void __exit optee_driver_exit(void)
> > > > +{
> > > > + platform_driver_unregister(&optee_driver);
> > > > +}
> > > > +module_exit(optee_driver_exit);
> > >
> > > What is the platform driver good for if the same module has to create the
> > > platform devices itself?
> >
> > The platform device(s) are created here because the optee node is below
> > "/firmware" instead of the root where it would have had the platform
> > device created automatically.
> >
> > I think it's useful to be able to unload the module, the early reviews
> > of this patch set was much focused around that. Regardless I'll need
> > some device as parent for the devices created during optee_probe() and
> > using a platform device for that seems natural.
> >
> > I'd rather keep the platform driver. Perhaps some variant of the pattern
> > in qcom_scm_init() (drivers/firmware/qcom_scm.c) is useful, except that
> > I need to find out what to do about the life cycle of the objects
> > created with of_platform_populate().
>
> My point was that I don't think we need devices here at all. It's different
> when you talk to external hardware that has register resource etc that
> can be best abstracted as a real device, but for other firmware features
> we don't normally add one.
>
> Module unloading can also be done without the device.
>
> > >
> > > I'd just skip it and do
> > >
> > > for_each_matching_node(node, optee_match)
> > > optee_probe(node);
> > >
> > > I also suspect that module unloading is broken here if you don't clean
> > > up the platform devices in the end, so you should already remove the
> > > exit function to prevent unloading.
> >
> > Does the platform devices really need cleaning? I mean
> > of_platform_default_populate_init() creates a bunch of platform devices
> > which are just left there even if unused. Here we're doing the same
> > thing except that we're doing it for a specific node in the DT.
>
> I think it will work if you don't clean them up, but it feels wrong
> to have a loadable module that creates devices when loaded but doesn't
> remove them when unloaded.
>
> This could be done differently by having the device creation done in
> one driver and the the user of that device in another driver, but I
> think just killing off the device achieves the same in a simpler way.
I see your point. My final concern here is that with device we got
entries in sysfs and uevents that could be used to automatically start
the correct supplicant. Different drivers are likely to require
different supplicants. Starting the correct supplicant based on uevents
is a quite elegant solution which I'm not sure how to support when
skipping devices. Perhaps I could create an object below
<sysfs>/firmware/tee ?
>
> > > > +/*
> > > > + * Get revision of Trusted OS.
> > > > + *
> > > > + * Used by non-secure world to figure out which version of the Trusted OS
> > > > + * is installed. Note that the returned revision is the revision of the
> > > > + * Trusted OS, not of the API.
> > > > + *
> > > > + * Returns revision in 2 32-bit words in the same way as
> > > > + * OPTEE_MSG_CALLS_REVISION described above.
> > > > + */
> > > > +#define OPTEE_MSG_OS_OPTEE_REVISION_MAJOR 1
> > > > +#define OPTEE_MSG_OS_OPTEE_REVISION_MINOR 0
> > > > +#define OPTEE_MSG_FUNCID_GET_OS_REVISION 0x0001
> > >
> > > Just for my understanding, what is the significance of these numbers,
> > > i.e. which code (user space, kernel driver, trusted OS) provides
> > > the uuid and which one provides the version? The code comments almost
> > > make sense to me, but I don't see why specific versions are listed
> > > in this header.
> >
> > You're right, OPTEE_MSG_OS_OPTEE_REVISION_* should be removed. The
> > actual version the secure OS is of a mostly informational nature. The
> > same goes the OS UUID, but I suppose the actual UUID used by the
> > upstream version of OP-TEE OS could be interesting to know.
> ...
> > > What is the expected behavior when one side reports a version that
> > > is unknown? Can one side claim to be backwards compatible with
> > > a previous version, or does each new version need support on
> > > all three sides?
> >
> > The UUID and version of the message protocol are important to match
> > correctly as otherwise it could mean that there's something unexpected
> > in secure world that following the message protocol would be undefined
> > behaviour. All changes to the message protocol should be backwards
> > compatible in the sense that the driver and secure world need to
> > negotiate eventual extensions while probing. That's what we're doing in
> > optee_msg_exchange_capabilities().
>
> Ok, then maybe the "compatible" identifier in DT should be sufficient
> to ensure that the capability exchange works, and the rest be based
> on that?
>
> We tend to avoid version checks for APIs in the kernel because they
> never work in practice, but the capability check should be fine.
UUID and version of the message protocol is required by ARM SMC Calling
Convention. It will be there anyway so we could just as well check it in
the probe function to catch eventual mismatches in configuration. Since
we're using capabilities to manage extensions of the protocol I think
the minor version could be ignored by probe.
Thanks,
Jens
^ permalink raw reply
* Re: [PATCH 2/9] drm: debugfs: Remove all files automatically on cleanup
From: Daniel Vetter @ 2017-01-23 9:10 UTC (permalink / raw)
To: Noralf Trønnes; +Cc: thomas.petazzoni, devicetree, linux-kernel, dri-devel
In-Reply-To: <20170122181117.8210-3-noralf@tronnes.org>
On Sun, Jan 22, 2017 at 07:11:10PM +0100, Noralf Trønnes wrote:
> Instead of having the drivers call drm_debugfs_remove_files() in
> their drm_driver->debugfs_cleanup hook, do it automatically by
> traversing minor->debugfs_list.
> Also use debugfs_remove_recursive() so drivers who add their own
> debugfs files don't have to keep track of them for removal.
>
> Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Makes sense, but that leaves us with a pile of dead code in drivers? Can
you pls go through them and remove this all (including the debugfs_cleanup
hook), and then removing the remaining (now dead) code in the core?
Thanks, Daniel
> ---
> drivers/gpu/drm/drm_debugfs.c | 17 +++++++++++++++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index 37fd612..0510ce2 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -218,6 +218,19 @@ int drm_debugfs_remove_files(const struct drm_info_list *files, int count,
> }
> EXPORT_SYMBOL(drm_debugfs_remove_files);
>
> +static void drm_debugfs_remove_all_files(struct drm_minor *minor)
> +{
> + struct drm_info_node *node, *tmp;
> +
> + mutex_lock(&minor->debugfs_lock);
> + list_for_each_entry_safe(node, tmp, &minor->debugfs_list, list) {
> + debugfs_remove(node->dent);
> + list_del(&node->list);
> + kfree(node);
> + }
> + mutex_unlock(&minor->debugfs_lock);
> +}
> +
> /**
> * Cleanup the debugfs filesystem resources.
> *
> @@ -245,9 +258,9 @@ int drm_debugfs_cleanup(struct drm_minor *minor)
> }
> }
>
> - drm_debugfs_remove_files(drm_debugfs_list, DRM_DEBUGFS_ENTRIES, minor);
> + drm_debugfs_remove_all_files(minor);
>
> - debugfs_remove(minor->debugfs_root);
> + debugfs_remove_recursive(minor->debugfs_root);
> minor->debugfs_root = NULL;
>
> return 0;
> --
> 2.10.2
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: document renesas-ostm timer
From: Geert Uytterhoeven @ 2017-01-23 9:15 UTC (permalink / raw)
To: Chris Brandt
Cc: Rob Herring, Mark Rutland, Simon Horman, Magnus Damm,
Russell King, Daniel Lezcano, Thomas Gleixner, Geert Uytterhoeven,
devicetree@vger.kernel.org, Linux-Renesas
In-Reply-To: <20170120212003.4103-2-chris.brandt@renesas.com>
Hi Chris,
On Fri, Jan 20, 2017 at 10:20 PM, Chris Brandt <chris.brandt@renesas.com> wrote:
> Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
>
> ---
> v2:
> * remove sw implementation specific portions
> ---
> .../devicetree/bindings/timer/renesas,ostm.txt | 29 ++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/timer/renesas,ostm.txt
>
> diff --git a/Documentation/devicetree/bindings/timer/renesas,ostm.txt b/Documentation/devicetree/bindings/timer/renesas,ostm.txt
> new file mode 100644
> index 0000000..06d7d71
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/renesas,ostm.txt
> @@ -0,0 +1,29 @@
> +* Renesas OS Timer (OSTM)
> +
> +The OSTM is a multi-channel 32-bit timer/counter with fixed clock
> +source that can operate in either interval count down timer or free-running
> +compare match mode.
> +
> +Channels are independent from each other.
> +
> +Required Properties:
> +
> + - compatible: must be one or more of the following:
> + - "renesas,r7s72100-ostm" for the r7s72100 OSTM
> + - "renesas,ostm" for any OSTM
> + This is a fallback for the above renesas,*-ostm entries
> +
> + - reg: base address and length of the register block for a timer channel.
> +
> + - interrupts: interrupt specifier for the timer channel.
> +
> + - clocks: clock specifier for the timer channel.
> +
> +Example: R7S72100 (RZ/A1H) OSTM node
> +
> + ostm0: ostm@fcfec000 {
timer@fcfec000
If you fix that:
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> + compatible = "renesas,r7s72100-ostm", "renesas,ostm";
> + reg = <0xfcfec000 0x30>;
> + interrupts = <GIC_SPI 102 IRQ_TYPE_EDGE_RISING>;
> + clocks = <&mstp5_clks R7S72100_CLK_OSTM0>;
> + };
> --
> 2.10.1
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 v5 2/3] mmc: sh_mobile_sdhi: explain clock bindings
From: Geert Uytterhoeven @ 2017-01-23 9:18 UTC (permalink / raw)
To: Chris Brandt
Cc: Ulf Hansson, Rob Herring, Mark Rutland, Simon Horman,
Wolfram Sang, devicetree@vger.kernel.org, Linux MMC List,
Linux-Renesas
In-Reply-To: <20170121030604.7672-3-chris.brandt@renesas.com>
On Sat, Jan 21, 2017 at 4:06 AM, Chris Brandt <chris.brandt@renesas.com> wrote:
> In the case of a single clock source, you don't need names. However,
> if the controller has 2 clock sources, you need to name them correctly
> so the driver can find the 2nd one. The 2nd clock is for the internal
> card detect logic.
>
> Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: arm64: dts: mt8173: add node for thermal calibration
From: Matthias Brugger @ 2017-01-23 9:20 UTC (permalink / raw)
To: Daniel Kurtz, Dawei Chien
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
open list:OPEN FIRMWARE AND...,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-pm,
moderated list:ARM/Mediatek SoC support, srv_heupstream,
Sascha Hauer, Punit Agrawal
In-Reply-To: <CAGS+omA=aip76=8CcGY7gPUrHj9eLLem=8MBziz99fVDq86zPQ@mail.gmail.com>
On 01/13/2017 09:51 AM, Daniel Kurtz wrote:
> On Fri, Jan 13, 2017 at 1:52 PM, Dawei Chien <dawei.chien@mediatek.com> wrote:
>>
>> From: "dawei.chien@mediatek.com" <dawei.chien@mediatek.com>
>>
>> Add this for supporting thermal calibration by e-fuse data.
>>
>> Signed-off-by: Dawei Chien <dawei.chien@mediatek.com>
>
> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
>
applied, thanks
>> ---
>> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> index 12e7027..adfac1e 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> @@ -401,6 +401,11 @@
>> efuse: efuse@10206000 {
>> compatible = "mediatek,mt8173-efuse";
>> reg = <0 0x10206000 0 0x1000>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + thermal_calibration: calib@528 {
>> + reg = <0x528 0xc>;
>> + };
>> };
>>
>> apmixedsys: clock-controller@10209000 {
>> @@ -574,6 +579,8 @@
>> resets = <&pericfg MT8173_PERI_THERM_SW_RST>;
>> mediatek,auxadc = <&auxadc>;
>> mediatek,apmixedsys = <&apmixedsys>;
>> + nvmem-cells = <&thermal_calibration>;
>> + nvmem-cell-names = "calibration-data";
>> };
>>
>> nor_flash: spi@1100d000 {
>> --
>> 1.9.1
>>
^ permalink raw reply
* Re: [PATCH v5 1/3] mmc: sh_mobile_sdhi: add support for 2 clocks
From: Geert Uytterhoeven @ 2017-01-23 9:22 UTC (permalink / raw)
To: Chris Brandt
Cc: Ulf Hansson, Rob Herring, Mark Rutland, Simon Horman,
Wolfram Sang, devicetree@vger.kernel.org, Linux MMC List,
Linux-Renesas
In-Reply-To: <20170121030604.7672-2-chris.brandt@renesas.com>
Hi Chris,
On Sat, Jan 21, 2017 at 4:06 AM, Chris Brandt <chris.brandt@renesas.com> wrote:
> Some controllers have 2 clock sources instead of 1. The 2nd clock
> is for the internal card detect logic and must be enabled/disabled
> along with the main core clock for proper operation.
>
> Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
> ---
> v4:
> * add technical explanation within probe routine
> v3:
> * add more clarification to the commit log
> v2:
> * changed clk2 to clk_cd
> * disable clk if clk_cd enable fails
> * changed clock name from "carddetect" to "cd"
Thanks for the updates!
> ---
> drivers/mmc/host/sh_mobile_sdhi.c | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/drivers/mmc/host/sh_mobile_sdhi.c b/drivers/mmc/host/sh_mobile_sdhi.c
> index 59db14b..360d922 100644
> --- a/drivers/mmc/host/sh_mobile_sdhi.c
> +++ b/drivers/mmc/host/sh_mobile_sdhi.c
> @@ -143,6 +143,7 @@ MODULE_DEVICE_TABLE(of, sh_mobile_sdhi_of_match);
>
> struct sh_mobile_sdhi {
> struct clk *clk;
> + struct clk *clk_cd;
> struct tmio_mmc_data mmc_data;
> struct tmio_mmc_dma dma_priv;
> struct pinctrl *pinctrl;
> @@ -190,6 +191,12 @@ static int sh_mobile_sdhi_clk_enable(struct tmio_mmc_host *host)
> if (ret < 0)
> return ret;
>
> + ret = clk_prepare_enable(priv->clk_cd);
> + if (ret < 0) {
> + clk_disable_unprepare(priv->clk);
> + return ret;
> + }
> +
As enabling the "core" clock but not the "cd" clock is not a valid setting,
shouldn't the cd clock be enabled first?
> /*
> * The clock driver may not know what maximum frequency
> * actually works, so it should be set with the max-frequency
> @@ -255,6 +262,8 @@ static void sh_mobile_sdhi_clk_disable(struct tmio_mmc_host *host)
> struct sh_mobile_sdhi *priv = host_to_priv(host);
>
> clk_disable_unprepare(priv->clk);
> + if (priv->clk_cd)
No need to check for a NULL pointer first.
> + clk_disable_unprepare(priv->clk_cd);
Disabling is already done in the correct order ;-)
> }
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 4/9] drm: Add DRM support for tiny LCD displays
From: Daniel Vetter @ 2017-01-23 9:28 UTC (permalink / raw)
To: Noralf Trønnes; +Cc: dri-devel, devicetree, thomas.petazzoni, linux-kernel
In-Reply-To: <20170122181117.8210-5-noralf@tronnes.org>
On Sun, Jan 22, 2017 at 07:11:12PM +0100, Noralf Trønnes wrote:
> tinydrm provides helpers for very simple displays that can use
> CMA backed framebuffers and need flushing on changes.
>
> Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Looks all pretty. A bunch of ideas below, but all optional. For merging I
think simplest to first get the core patches in through drm-misc, and then
you can submit a pull request to Dave for tinydrm+backends (just needs an
ack for the dt parts from dt maintainers), including MAINTAINERS entry.
Ack from my side.
Thanks, Daniel
> ---
> Documentation/gpu/drm-kms-helpers.rst | 15 ++
> MAINTAINERS | 7 +
> drivers/gpu/drm/Kconfig | 2 +
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/tinydrm/Kconfig | 8 +
> drivers/gpu/drm/tinydrm/Makefile | 1 +
> drivers/gpu/drm/tinydrm/core/Makefile | 3 +
> drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 374 ++++++++++++++++++++++++++++
> drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c | 244 ++++++++++++++++++
> include/drm/tinydrm/tinydrm.h | 115 +++++++++
> 10 files changed, 770 insertions(+)
> create mode 100644 drivers/gpu/drm/tinydrm/Kconfig
> create mode 100644 drivers/gpu/drm/tinydrm/Makefile
> create mode 100644 drivers/gpu/drm/tinydrm/core/Makefile
> create mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-core.c
> create mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
> create mode 100644 include/drm/tinydrm/tinydrm.h
>
> diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst
> index 03040aa..a86bd7f 100644
> --- a/Documentation/gpu/drm-kms-helpers.rst
> +++ b/Documentation/gpu/drm-kms-helpers.rst
> @@ -272,3 +272,18 @@ Auxiliary Modeset Helpers
>
> .. kernel-doc:: drivers/gpu/drm/drm_modeset_helper.c
> :export:
> +
> +tinydrm Helper Reference
> +========================
> +
> +.. kernel-doc:: drivers/gpu/drm/tinydrm/core/tinydrm-core.c
> + :doc: overview
> +
> +.. kernel-doc:: include/drm/tinydrm/tinydrm.h
> + :internal:
> +
> +.. kernel-doc:: drivers/gpu/drm/tinydrm/core/tinydrm-core.c
> + :export:
> +
> +.. kernel-doc:: drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
> + :export:
Since tinydrm is more like a special driver than a helper I think it would
make sense to move the docs into the driver section, next to the include
for the i915 stuff. That means a new tinydrm.rst and including it in
gpu/index.rst.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 741f35f..817e0fe 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4365,6 +4365,13 @@ DRM DRIVER FOR TDFX VIDEO CARDS
> S: Orphan / Obsolete
> F: drivers/gpu/drm/tdfx/
>
> +DRM DRIVERS FOR TINY DISPLAYS
> +M: Noralf Trønnes <noralf@tronnes.org>
> +W: https://github.com/notro/tinydrm/wiki
> +S: Maintained
> +F: drivers/gpu/drm/tinydrm/
> +F: include/drm/tinydrm/
> +
> DRM DRIVER FOR USB DISPLAYLINK VIDEO ADAPTERS
> M: Dave Airlie <airlied@redhat.com>
> S: Odd Fixes
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 90bc65d..88e01e08e 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -263,6 +263,8 @@ source "drivers/gpu/drm/mxsfb/Kconfig"
>
> source "drivers/gpu/drm/meson/Kconfig"
>
> +source "drivers/gpu/drm/tinydrm/Kconfig"
> +
> # Keep legacy drivers last
>
> menuconfig DRM_LEGACY
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 92de399..3ee9579 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -94,3 +94,4 @@ obj-$(CONFIG_DRM_ARCPGU)+= arc/
> obj-y += hisilicon/
> obj-$(CONFIG_DRM_ZTE) += zte/
> obj-$(CONFIG_DRM_MXSFB) += mxsfb/
> +obj-$(CONFIG_DRM_TINYDRM) += tinydrm/
> diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
> new file mode 100644
> index 0000000..ffb873f
> --- /dev/null
> +++ b/drivers/gpu/drm/tinydrm/Kconfig
> @@ -0,0 +1,8 @@
> +menuconfig DRM_TINYDRM
> + tristate "Support for simple displays"
> + depends on DRM
> + select DRM_KMS_HELPER
> + select DRM_KMS_CMA_HELPER
> + help
> + Choose this option if you have a tinydrm supported display.
> + If M is selected the module will be called tinydrm.
> diff --git a/drivers/gpu/drm/tinydrm/Makefile b/drivers/gpu/drm/tinydrm/Makefile
> new file mode 100644
> index 0000000..7476ed1
> --- /dev/null
> +++ b/drivers/gpu/drm/tinydrm/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_DRM_TINYDRM) += core/
> diff --git a/drivers/gpu/drm/tinydrm/core/Makefile b/drivers/gpu/drm/tinydrm/core/Makefile
> new file mode 100644
> index 0000000..4f14a0f
> --- /dev/null
> +++ b/drivers/gpu/drm/tinydrm/core/Makefile
> @@ -0,0 +1,3 @@
> +tinydrm-y := tinydrm-core.o tinydrm-pipe.o
> +
> +obj-$(CONFIG_DRM_TINYDRM) += tinydrm.o
> diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
> new file mode 100644
> index 0000000..492b478
> --- /dev/null
> +++ b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
> @@ -0,0 +1,374 @@
> +/*
> + * Copyright (C) 2016 Noralf Trønnes
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <drm/drm_atomic.h>
> +#include <drm/drm_atomic_helper.h>
> +#include <drm/drm_crtc_helper.h>
> +#include <drm/tinydrm/tinydrm.h>
> +#include <linux/device.h>
> +#include <linux/dma-buf.h>
> +
> +/**
> + * DOC: overview
> + *
> + * This library provides driver helpers for very simple display hardware.
> + *
> + * It is based on &drm_simple_display_pipe coupled with a &drm_connector which
> + * has only one fixed &drm_display_mode. The framebuffers are backed by the
> + * cma helper and have support for framebuffer flushing (dirty).
> + * fbdev support is also included.
> + *
> + * The driver allocates &tinydrm_device, initializes it using
> + * devm_tinydrm_init(), sets up the pipeline using tinydrm_display_pipe_init()
> + * and registers the DRM device using devm_tinydrm_register().
> + */
> +
> +/**
> + * tinydrm_lastclose - DRM lastclose helper
> + * @drm: DRM device
> + *
> + * This function ensures that fbdev is restored when drm_lastclose() is called
> + * on the last drm_release(). Drivers can use this as their
> + * &drm_driver->lastclose callback.
> + */
> +void tinydrm_lastclose(struct drm_device *drm)
> +{
> + struct tinydrm_device *tdev = drm->dev_private;
> +
> + DRM_DEBUG_KMS("\n");
> + drm_fbdev_cma_restore_mode(tdev->fbdev_cma);
> +}
> +EXPORT_SYMBOL(tinydrm_lastclose);
I wonder whether we should have a pointer in dev->mode_config for the
fbdev stuff, and then a helper for generic kms lastclose in the fbdev
helper (so that it's useable for both cma and non-cma drivers). We
copy-paste this one-liner wrapper sooooo many times.
Just an idea for a follow-up/separate series.
> +
> +/**
> + * tinydrm_gem_cma_prime_import_sg_table - Produce a CMA GEM object from
> + * another driver's scatter/gather table of pinned pages
> + * @drm: DRM device to import into
> + * @attach: DMA-BUF attachment
> + * @sgt: Scatter/gather table of pinned pages
> + *
> + * This function imports a scatter/gather table exported via DMA-BUF by
> + * another driver using drm_gem_cma_prime_import_sg_table(). It sets the
> + * kernel virtual address on the CMA object. Drivers should use this as their
> + * &drm_driver->gem_prime_import_sg_table callback if they need the virtual
> + * address. tinydrm_gem_cma_free_object() should be used in combination with
> + * this function.
> + *
> + * Returns:
> + * A pointer to a newly created GEM object or an ERR_PTR-encoded negative
> + * error code on failure.
> + */
> +struct drm_gem_object *
> +tinydrm_gem_cma_prime_import_sg_table(struct drm_device *drm,
> + struct dma_buf_attachment *attach,
> + struct sg_table *sgt)
> +{
> + struct drm_gem_cma_object *cma_obj;
> + struct drm_gem_object *obj;
> + void *vaddr;
> +
> + vaddr = dma_buf_vmap(attach->dmabuf);
> + if (!vaddr) {
> + DRM_ERROR("Failed to vmap PRIME buffer\n");
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + obj = drm_gem_cma_prime_import_sg_table(drm, attach, sgt);
> + if (IS_ERR(obj)) {
> + dma_buf_vunmap(attach->dmabuf, vaddr);
> + return obj;
> + }
> +
> + cma_obj = to_drm_gem_cma_obj(obj);
> + cma_obj->vaddr = vaddr;
> +
> + return obj;
> +}
> +EXPORT_SYMBOL(tinydrm_gem_cma_prime_import_sg_table);
> +
> +/**
> + * tinydrm_gem_cma_free_object - Free resources associated with a CMA GEM
> + * object
> + * @gem_obj: GEM object to free
> + *
> + * This function frees the backing memory of the CMA GEM object, cleans up the
> + * GEM object state and frees the memory used to store the object itself using
> + * drm_gem_cma_free_object(). It also handles PRIME buffers which has the kernel
> + * virtual address set by tinydrm_gem_cma_prime_import_sg_table(). Drivers
> + * can use this as their &drm_driver->gem_free_object callback.
> + */
> +void tinydrm_gem_cma_free_object(struct drm_gem_object *gem_obj)
> +{
> + if (gem_obj->import_attach) {
> + struct drm_gem_cma_object *cma_obj;
> +
> + cma_obj = to_drm_gem_cma_obj(gem_obj);
> + dma_buf_vunmap(gem_obj->import_attach->dmabuf, cma_obj->vaddr);
> + cma_obj->vaddr = NULL;
> + }
> +
> + drm_gem_cma_free_object(gem_obj);
> +}
> +EXPORT_SYMBOL_GPL(tinydrm_gem_cma_free_object);
> +
> +const struct file_operations tinydrm_fops = {
> + .owner = THIS_MODULE,
> + .open = drm_open,
> + .release = drm_release,
> + .unlocked_ioctl = drm_ioctl,
> +#ifdef CONFIG_COMPAT
> + .compat_ioctl = drm_compat_ioctl,
> +#endif
> + .poll = drm_poll,
> + .read = drm_read,
> + .llseek = no_llseek,
> + .mmap = drm_gem_cma_mmap,
> +};
> +EXPORT_SYMBOL(tinydrm_fops);
> +
> +static struct drm_framebuffer *
> +tinydrm_fb_create(struct drm_device *drm, struct drm_file *file_priv,
> + const struct drm_mode_fb_cmd2 *mode_cmd)
> +{
> + struct tinydrm_device *tdev = drm->dev_private;
> +
> + return drm_fb_cma_create_with_funcs(drm, file_priv, mode_cmd,
> + tdev->fb_funcs);
> +}
> +
> +static const struct drm_mode_config_funcs tinydrm_mode_config_funcs = {
> + .fb_create = tinydrm_fb_create,
> + .atomic_check = drm_atomic_helper_check,
> + .atomic_commit = drm_atomic_helper_commit,
> +};
> +
> +static int tinydrm_init(struct device *parent, struct tinydrm_device *tdev,
> + const struct drm_framebuffer_funcs *fb_funcs,
> + struct drm_driver *driver)
> +{
> + struct drm_device *drm;
> +
> + mutex_init(&tdev->dirty_lock);
> + tdev->fb_funcs = fb_funcs;
> +
> + /*
> + * We don't embed drm_device, because that prevent us from using
> + * devm_kzalloc() to allocate tinydrm_device in the driver since
> + * drm_dev_unref() frees the structure. The devm_ functions provide
> + * for easy error handling.
> + */
> + drm = drm_dev_alloc(driver, parent);
There's a patch series from Chris Wilson to add a ->release callback and
properly fix this.
> + if (IS_ERR(drm))
> + return PTR_ERR(drm);
> +
> + tdev->drm = drm;
> + drm->dev_private = tdev;
> + drm_mode_config_init(drm);
> + drm->mode_config.funcs = &tinydrm_mode_config_funcs;
> +
> + return 0;
> +}
> +
> +static void tinydrm_fini(struct tinydrm_device *tdev)
> +{
> + DRM_DEBUG_KMS("\n");
> +
> + drm_mode_config_cleanup(tdev->drm);
> + mutex_destroy(&tdev->dirty_lock);
> + tdev->drm->dev_private = NULL;
> + drm_dev_unref(tdev->drm);
> +}
> +
> +static void devm_tinydrm_release(void *data)
> +{
> + tinydrm_fini(data);
> +}
> +
> +/**
> + * devm_tinydrm_init - Initialize tinydrm device
> + * @parent: Parent device object
> + * @tdev: tinydrm device
> + * @fb_funcs: Framebuffer functions
> + * @driver: DRM driver
> + *
> + * This function initializes @tdev, the underlying DRM device and it's
> + * mode_config. Resources will be automatically freed on driver detach (devres)
> + * using drm_mode_config_cleanup() and drm_dev_unref().
> + *
> + * Returns:
> + * Zero on success, negative error code on failure.
> + */
> +int devm_tinydrm_init(struct device *parent, struct tinydrm_device *tdev,
> + const struct drm_framebuffer_funcs *fb_funcs,
> + struct drm_driver *driver)
> +{
> + int ret;
> +
> + ret = tinydrm_init(parent, tdev, fb_funcs, driver);
> + if (ret)
> + return ret;
> +
> + ret = devm_add_action(parent, devm_tinydrm_release, tdev);
> + if (ret)
> + tinydrm_fini(tdev);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(devm_tinydrm_init);
> +
> +static int tinydrm_register(struct tinydrm_device *tdev)
> +{
> + struct drm_device *drm = tdev->drm;
> + int bpp = drm->mode_config.preferred_depth;
> + struct drm_fbdev_cma *fbdev;
> + int ret;
> +
> + ret = drm_dev_register(tdev->drm, 0);
> + if (ret)
> + return ret;
> +
> + fbdev = drm_fbdev_cma_init_with_funcs(drm, bpp ? bpp : 32,
> + drm->mode_config.num_crtc,
> + drm->mode_config.num_connector,
> + tdev->fb_funcs);
> + if (IS_ERR(fbdev))
> + DRM_ERROR("Failed to initialize fbdev: %ld\n", PTR_ERR(fbdev));
> + else
> + tdev->fbdev_cma = fbdev;
> +
> + return 0;
> +}
> +
> +static void tinydrm_unregister(struct tinydrm_device *tdev)
> +{
> + DRM_DEBUG_KMS("\n");
> +
> + drm_crtc_force_disable_all(tdev->drm);
> +
> + if (tdev->fbdev_cma)
> + drm_fbdev_cma_fini(tdev->fbdev_cma);
> +
> + drm_dev_unregister(tdev->drm);
> +}
> +
> +static void devm_tinydrm_register_release(void *data)
> +{
> + tinydrm_unregister(data);
> +}
> +
> +/**
> + * devm_tinydrm_register - Register tinydrm device
> + * @tdev: tinydrm device
> + *
> + * This function registers the underlying DRM device and fbdev.
> + * These resources will be automatically unregistered on driver detach (devres)
> + * and the display pipeline will be disabled.
> + *
> + * Returns:
> + * Zero on success, negative error code on failure.
> + */
> +int devm_tinydrm_register(struct tinydrm_device *tdev)
> +{
> + struct device *dev = tdev->drm->dev;
> + int ret;
> +
> + ret = tinydrm_register(tdev);
> + if (ret)
> + return ret;
> +
> + ret = devm_add_action(dev, devm_tinydrm_register_release, tdev);
> + if (ret)
> + tinydrm_unregister(tdev);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(devm_tinydrm_register);
> +
> +/**
> + * tinydrm_shutdown - Shutdown tinydrm
> + * @tdev: tinydrm device
> + *
> + * This function makes sure that the display pipeline is disabled.
> + * Used by drivers in their shutdown callback to turn off the display
> + * on machine shutdown and reboot.
> + */
> +void tinydrm_shutdown(struct tinydrm_device *tdev)
> +{
> + drm_crtc_force_disable_all(tdev->drm);
> +}
> +EXPORT_SYMBOL(tinydrm_shutdown);
> +
> +/**
> + * tinydrm_suspend - Suspend tinydrm
> + * @tdev: tinydrm device
> + *
> + * Used in driver PM operations to suspend tinydrm.
> + * Suspends fbdev and DRM.
> + * Resume with tinydrm_resume().
> + *
> + * Returns:
> + * Zero on success, negative error code on failure.
> + */
> +int tinydrm_suspend(struct tinydrm_device *tdev)
> +{
> + struct drm_atomic_state *state;
> +
> + if (tdev->suspend_state) {
> + DRM_ERROR("Failed to suspend: state already set\n");
> + return -EINVAL;
> + }
> +
> + drm_fbdev_cma_set_suspend_unlocked(tdev->fbdev_cma, 1);
Hm, random idea for faster suspend: On resume we can use the worker to
avoid stalling on console_lock. On suspedn we could use a
set_suspend_async/complete pair, which first launches the worker and later
on waits for it to complete. If we do this around the (usually rather
slow) call to drm_atomic_helper_suspend, then we could hide all that
latency.
> + state = drm_atomic_helper_suspend(tdev->drm);
> + if (IS_ERR(state)) {
> + drm_fbdev_cma_set_suspend_unlocked(tdev->fbdev_cma, 0);
> + return PTR_ERR(state);
> + }
> +
> + tdev->suspend_state = state;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(tinydrm_suspend);
> +
> +/**
> + * tinydrm_resume - Resume tinydrm
> + * @tdev: tinydrm device
> + *
> + * Used in driver PM operations to resume tinydrm.
> + * Suspend with tinydrm_suspend().
> + *
> + * Returns:
> + * Zero on success, negative error code on failure.
> + */
> +int tinydrm_resume(struct tinydrm_device *tdev)
> +{
> + struct drm_atomic_state *state = tdev->suspend_state;
> + int ret;
> +
> + if (!state) {
> + DRM_ERROR("Failed to resume: state is not set\n");
> + return -EINVAL;
> + }
> +
> + tdev->suspend_state = NULL;
> +
> + ret = drm_atomic_helper_resume(tdev->drm, state);
> + if (ret) {
> + DRM_ERROR("Error resuming state: %d\n", ret);
> + return ret;
> + }
> +
> + drm_fbdev_cma_set_suspend_unlocked(tdev->fbdev_cma, 0);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(tinydrm_resume);
> +
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
> new file mode 100644
> index 0000000..4327b04
> --- /dev/null
> +++ b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
> @@ -0,0 +1,244 @@
> +/*
> + * Copyright (C) 2016 Noralf Trønnes
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <drm/drm_atomic_helper.h>
> +#include <drm/drm_crtc_helper.h>
> +#include <drm/drm_modes.h>
> +#include <drm/tinydrm/tinydrm.h>
> +
> +struct tinydrm_connector {
> + struct drm_connector base;
> + const struct drm_display_mode *mode;
> +};
> +
> +static inline struct tinydrm_connector *
> +to_tinydrm_connector(struct drm_connector *connector)
> +{
> + return container_of(connector, struct tinydrm_connector, base);
> +}
> +
> +static int tinydrm_connector_get_modes(struct drm_connector *connector)
> +{
> + struct tinydrm_connector *tconn = to_tinydrm_connector(connector);
> + struct drm_display_mode *mode;
> +
> + mode = drm_mode_duplicate(connector->dev, tconn->mode);
> + if (!mode) {
> + DRM_ERROR("Failed to duplicate mode\n");
> + return 0;
> + }
> +
> + if (mode->name[0] == '\0')
> + drm_mode_set_name(mode);
> +
> + mode->type |= DRM_MODE_TYPE_PREFERRED;
> + drm_mode_probed_add(connector, mode);
> +
> + if (mode->width_mm) {
> + connector->display_info.width_mm = mode->width_mm;
> + connector->display_info.height_mm = mode->height_mm;
> + }
> +
> + return 1;
> +}
> +
> +static const struct drm_connector_helper_funcs tinydrm_connector_hfuncs = {
> + .get_modes = tinydrm_connector_get_modes,
> + .best_encoder = drm_atomic_helper_best_encoder,
> +};
> +
> +static enum drm_connector_status
> +tinydrm_connector_detect(struct drm_connector *connector, bool force)
> +{
> + if (drm_device_is_unplugged(connector->dev))
> + return connector_status_disconnected;
> +
> + return connector->status;
> +}
> +
> +static void tinydrm_connector_destroy(struct drm_connector *connector)
> +{
> + struct tinydrm_connector *tconn = to_tinydrm_connector(connector);
> +
> + drm_connector_cleanup(connector);
> + kfree(tconn);
> +}
> +
> +static const struct drm_connector_funcs tinydrm_connector_funcs = {
> + .dpms = drm_atomic_helper_connector_dpms,
> + .reset = drm_atomic_helper_connector_reset,
> + .detect = tinydrm_connector_detect,
> + .fill_modes = drm_helper_probe_single_connector_modes,
> + .destroy = tinydrm_connector_destroy,
> + .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> +};
> +
> +struct drm_connector *
> +tinydrm_connector_create(struct drm_device *drm,
> + const struct drm_display_mode *mode,
> + int connector_type)
> +{
> + struct tinydrm_connector *tconn;
> + struct drm_connector *connector;
> + int ret;
> +
> + tconn = kzalloc(sizeof(*tconn), GFP_KERNEL);
> + if (!tconn)
> + return ERR_PTR(-ENOMEM);
> +
> + tconn->mode = mode;
> + connector = &tconn->base;
> +
> + drm_connector_helper_add(connector, &tinydrm_connector_hfuncs);
> + ret = drm_connector_init(drm, connector, &tinydrm_connector_funcs,
> + connector_type);
> + if (ret) {
> + kfree(tconn);
> + return ERR_PTR(ret);
> + }
> +
> + connector->status = connector_status_connected;
> +
> + return connector;
> +}
> +
> +/**
> + * tinydrm_display_pipe_update - Display pipe update helper
> + * @pipe: Simple display pipe
> + * @old_state: Old plane state
> + *
> + * This function does a full framebuffer flush if the plane framebuffer
> + * has changed. It also handles vblank events. Drivers can use this as their
> + * &drm_simple_display_pipe_funcs->update callback.
> + */
> +void tinydrm_display_pipe_update(struct drm_simple_display_pipe *pipe,
> + struct drm_plane_state *old_state)
> +{
> + struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
> + struct drm_framebuffer *fb = pipe->plane.state->fb;
> + struct drm_crtc *crtc = &tdev->pipe.crtc;
> +
> + if (!fb)
> + DRM_DEBUG_KMS("fb unset\n");
> + else if (!old_state->fb)
> + DRM_DEBUG_KMS("fb set\n");
> + else if (fb != old_state->fb)
> + DRM_DEBUG_KMS("fb changed\n");
> + else
> + DRM_DEBUG_KMS("No fb change\n");
> +
> + if (fb && (fb != old_state->fb)) {
> + pipe->plane.fb = fb;
> + if (fb->funcs->dirty)
> + fb->funcs->dirty(fb, NULL, 0, 0, NULL, 0);
I like the idea, but my cunning long-term plan is that we'd extend the
atomic support to support a dirty rectangle. Together with the
non-blocking stuff we could then implement fb->funcs->dirty in terms of
atomic. But here you implement atomic in terms of ->dirty, and we'd end up
with a loop.
Personally I'd just drop this helper here and move this part into the
backend modules ...
> + }
> +
> + if (crtc->state->event) {
> + DRM_DEBUG_KMS("crtc event\n");
> + spin_lock_irq(&crtc->dev->event_lock);
> + drm_crtc_send_vblank_event(crtc, crtc->state->event);
> + spin_unlock_irq(&crtc->dev->event_lock);
> + crtc->state->event = NULL;
... because this here is kinda a hack, since it's not synchronized with
the screen update. Otoh these tiny panels are kinda special.
> + }
> +}
> +EXPORT_SYMBOL(tinydrm_display_pipe_update);
> +
> +/**
> + * tinydrm_display_pipe_prepare_fb - Display pipe prepare_fb helper
> + * @pipe: Simple display pipe
> + * @plane_state: Plane state
> + *
> + * This function uses drm_fb_cma_prepare_fb() to check if the plane FB has an
> + * dma-buf attached, extracts the exclusive fence and attaches it to plane
> + * state for the atomic helper to wait on. Drivers can use this as their
> + * &drm_simple_display_pipe_funcs->prepare_fb callback.
> + */
> +int tinydrm_display_pipe_prepare_fb(struct drm_simple_display_pipe *pipe,
> + struct drm_plane_state *plane_state)
> +{
> + return drm_fb_cma_prepare_fb(&pipe->plane, plane_state);
> +}
> +EXPORT_SYMBOL(tinydrm_display_pipe_prepare_fb);
> +
> +static int tinydrm_rotate_mode(struct drm_display_mode *mode,
> + unsigned int rotation)
> +{
> + if (rotation == 0 || rotation == 180) {
> + return 0;
> + } else if (rotation == 90 || rotation == 270) {
> + swap(mode->hdisplay, mode->vdisplay);
> + swap(mode->hsync_start, mode->vsync_start);
> + swap(mode->hsync_end, mode->vsync_end);
> + swap(mode->htotal, mode->vtotal);
> + swap(mode->width_mm, mode->height_mm);
> + return 0;
> + } else {
> + return -EINVAL;
> + }
> +}
> +
> +/**
> + * tinydrm_display_pipe_init - Initialize display pipe
> + * @tdev: tinydrm device
> + * @funcs: Display pipe functions
> + * @connector_type: Connector type
> + * @formats: Array of supported formats (DRM_FORMAT\_\*)
> + * @format_count: Number of elements in @formats
> + * @mode: Supported mode
> + * @rotation: Initial @mode rotation in degrees Counter Clock Wise
> + *
> + * This function sets up a &drm_simple_display_pipe with a &drm_connector that
> + * has one fixed &drm_display_mode which is rotated according to @rotation.
> + *
> + * Returns:
> + * Zero on success, negative error code on failure.
> + */
> +int
> +tinydrm_display_pipe_init(struct tinydrm_device *tdev,
> + const struct drm_simple_display_pipe_funcs *funcs,
> + int connector_type,
> + const uint32_t *formats,
> + unsigned int format_count,
> + const struct drm_display_mode *mode,
> + unsigned int rotation)
> +{
> + struct drm_device *drm = tdev->drm;
> + struct drm_display_mode *mode_copy;
> + struct drm_connector *connector;
> + int ret;
> +
> + mode_copy = devm_kmalloc(drm->dev, sizeof(*mode_copy), GFP_KERNEL);
> + if (!mode_copy)
> + return -ENOMEM;
> +
> + *mode_copy = *mode;
> + ret = tinydrm_rotate_mode(mode_copy, rotation);
> + if (ret) {
> + DRM_ERROR("Illegal rotation value %u\n", rotation);
> + return -EINVAL;
> + }
> +
> + drm->mode_config.min_width = mode_copy->hdisplay;
> + drm->mode_config.max_width = mode_copy->hdisplay;
> + drm->mode_config.min_height = mode_copy->vdisplay;
> + drm->mode_config.max_height = mode_copy->vdisplay;
> +
> + connector = tinydrm_connector_create(drm, mode_copy, connector_type);
> + if (IS_ERR(connector))
> + return PTR_ERR(connector);
> +
> + ret = drm_simple_display_pipe_init(drm, &tdev->pipe, funcs, formats,
> + format_count, connector);
> + if (ret)
> + return ret;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(tinydrm_display_pipe_init);
> diff --git a/include/drm/tinydrm/tinydrm.h b/include/drm/tinydrm/tinydrm.h
> new file mode 100644
> index 0000000..cf9ca20
> --- /dev/null
> +++ b/include/drm/tinydrm/tinydrm.h
> @@ -0,0 +1,115 @@
> +/*
> + * Copyright (C) 2016 Noralf Trønnes
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#ifndef __LINUX_TINYDRM_H
> +#define __LINUX_TINYDRM_H
> +
> +#include <drm/drm_gem_cma_helper.h>
> +#include <drm/drm_fb_cma_helper.h>
> +#include <drm/drm_simple_kms_helper.h>
> +
> +/**
> + * struct tinydrm_device - tinydrm device
> + * @drm: DRM device
> + * @pipe: Display pipe structure
> + * @dirty_lock: Serializes framebuffer flushing
> + * @fbdev_cma: CMA fbdev structure
> + * @suspend_state: Atomic state when suspended
> + * @fb_funcs: Framebuffer functions used when creating framebuffers
> + */
> +struct tinydrm_device {
> + struct drm_device *drm;
> + struct drm_simple_display_pipe pipe;
> + struct mutex dirty_lock;
> + struct drm_fbdev_cma *fbdev_cma;
> + struct drm_atomic_state *suspend_state;
> + const struct drm_framebuffer_funcs *fb_funcs;
> +};
> +
> +static inline struct tinydrm_device *
> +pipe_to_tinydrm(struct drm_simple_display_pipe *pipe)
> +{
> + return container_of(pipe, struct tinydrm_device, pipe);
> +}
> +
> +/**
> + * TINYDRM_GEM_DRIVER_OPS - default tinydrm gem operations
> + *
> + * This macro provides a shortcut for setting the tinydrm GEM operations in
> + * the &drm_driver structure.
> + */
> +#define TINYDRM_GEM_DRIVER_OPS \
> + .gem_free_object = tinydrm_gem_cma_free_object, \
> + .gem_vm_ops = &drm_gem_cma_vm_ops, \
> + .prime_handle_to_fd = drm_gem_prime_handle_to_fd, \
> + .prime_fd_to_handle = drm_gem_prime_fd_to_handle, \
> + .gem_prime_import = drm_gem_prime_import, \
> + .gem_prime_export = drm_gem_prime_export, \
> + .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table, \
> + .gem_prime_import_sg_table = tinydrm_gem_cma_prime_import_sg_table, \
> + .gem_prime_vmap = drm_gem_cma_prime_vmap, \
> + .gem_prime_vunmap = drm_gem_cma_prime_vunmap, \
> + .gem_prime_mmap = drm_gem_cma_prime_mmap, \
> + .dumb_create = drm_gem_cma_dumb_create, \
> + .dumb_map_offset = drm_gem_cma_dumb_map_offset, \
> + .dumb_destroy = drm_gem_dumb_destroy, \
> + .fops = &tinydrm_fops
> +
> +/**
> + * TINYDRM_MODE - tinydrm display mode
> + * @hd: Horizontal resolution, width
> + * @vd: Vertical resolution, height
> + * @hd_mm: Display width in millimeters
> + * @vd_mm: Display height in millimeters
> + *
> + * This macro creates a &drm_display_mode for use with tinydrm.
> + */
> +#define TINYDRM_MODE(hd, vd, hd_mm, vd_mm) \
> + .hdisplay = (hd), \
> + .hsync_start = (hd), \
> + .hsync_end = (hd), \
> + .htotal = (hd), \
> + .vdisplay = (vd), \
> + .vsync_start = (vd), \
> + .vsync_end = (vd), \
> + .vtotal = (vd), \
> + .width_mm = (hd_mm), \
> + .height_mm = (vd_mm), \
> + .type = DRM_MODE_TYPE_DRIVER, \
> + .clock = 1 /* pass validation */
> +
> +extern const struct file_operations tinydrm_fops;
> +void tinydrm_lastclose(struct drm_device *drm);
> +void tinydrm_gem_cma_free_object(struct drm_gem_object *gem_obj);
> +struct drm_gem_object *
> +tinydrm_gem_cma_prime_import_sg_table(struct drm_device *drm,
> + struct dma_buf_attachment *attach,
> + struct sg_table *sgt);
> +int devm_tinydrm_init(struct device *parent, struct tinydrm_device *tdev,
> + const struct drm_framebuffer_funcs *fb_funcs,
> + struct drm_driver *driver);
> +int devm_tinydrm_register(struct tinydrm_device *tdev);
> +void tinydrm_shutdown(struct tinydrm_device *tdev);
> +int tinydrm_suspend(struct tinydrm_device *tdev);
> +int tinydrm_resume(struct tinydrm_device *tdev);
> +
> +void tinydrm_display_pipe_update(struct drm_simple_display_pipe *pipe,
> + struct drm_plane_state *old_state);
> +int tinydrm_display_pipe_prepare_fb(struct drm_simple_display_pipe *pipe,
> + struct drm_plane_state *plane_state);
> +int
> +tinydrm_display_pipe_init(struct tinydrm_device *tdev,
> + const struct drm_simple_display_pipe_funcs *funcs,
> + int connector_type,
> + const uint32_t *formats,
> + unsigned int format_count,
> + const struct drm_display_mode *mode,
> + unsigned int rotation);
> +
> +#endif /* __LINUX_TINYDRM_H */
> --
> 2.10.2
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* Re: [PATCH 5/9] drm/tinydrm: Add helper functions
From: Daniel Vetter @ 2017-01-23 9:32 UTC (permalink / raw)
To: Noralf Trønnes; +Cc: dri-devel, devicetree, thomas.petazzoni, linux-kernel
In-Reply-To: <20170122181117.8210-6-noralf@tronnes.org>
On Sun, Jan 22, 2017 at 07:11:13PM +0100, Noralf Trønnes wrote:
> Add common functionality needed by many tinydrm drivers.
>
> Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Bunch of comments below, all optional.
-Daniel
> ---
> Documentation/gpu/drm-kms-helpers.rst | 6 +
> drivers/gpu/drm/tinydrm/core/Makefile | 2 +-
> drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 490 +++++++++++++++++++++++++
> include/drm/tinydrm/tinydrm-helpers.h | 100 +++++
> 4 files changed, 597 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> create mode 100644 include/drm/tinydrm/tinydrm-helpers.h
>
> diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst
> index a86bd7f..be07e76 100644
> --- a/Documentation/gpu/drm-kms-helpers.rst
> +++ b/Documentation/gpu/drm-kms-helpers.rst
> @@ -287,3 +287,9 @@ tinydrm Helper Reference
>
> .. kernel-doc:: drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
> :export:
> +
> +.. kernel-doc:: include/drm/tinydrm/tinydrm-helpers.h
> + :internal:
> +
> +.. kernel-doc:: drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> + :export:
> diff --git a/drivers/gpu/drm/tinydrm/core/Makefile b/drivers/gpu/drm/tinydrm/core/Makefile
> index 4f14a0f..fb221e6 100644
> --- a/drivers/gpu/drm/tinydrm/core/Makefile
> +++ b/drivers/gpu/drm/tinydrm/core/Makefile
> @@ -1,3 +1,3 @@
> -tinydrm-y := tinydrm-core.o tinydrm-pipe.o
> +tinydrm-y := tinydrm-core.o tinydrm-pipe.o tinydrm-helpers.o
>
> obj-$(CONFIG_DRM_TINYDRM) += tinydrm.o
> diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> new file mode 100644
> index 0000000..fc02e01
> --- /dev/null
> +++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> @@ -0,0 +1,490 @@
> +/*
> + * Copyright (C) 2016 Noralf Trønnes
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <drm/tinydrm/tinydrm.h>
> +#include <drm/tinydrm/tinydrm-helpers.h>
> +#include <linux/backlight.h>
> +#include <linux/pm.h>
> +#include <linux/spi/spi.h>
> +#include <linux/swab.h>
> +
> +static unsigned int spi_max;
> +module_param(spi_max, uint, 0400);
> +MODULE_PARM_DESC(spi_max, "Set a lower SPI max transfer size");
> +
> +/**
> + * tinydrm_merge_clips - Merge clip rectangles
> + * @dst: Destination clip rectangle
> + * @src: Source clip rectangle(s)
> + * @num_clips: Number of @src clip rectangles
> + * @flags: Dirty fb ioctl flags
> + * @max_width: Maximum width of @dst
> + * @max_height: Maximum height of @dst
> + *
> + * This function merges @src clip rectangle(s) into @dst. If @src is NULL,
> + * @max_width and @min_width is used to set a full @dst clip rectangle.
> + *
> + * Returns:
> + * true if it's a full clip, false otherwise
> + */
> +bool tinydrm_merge_clips(struct drm_clip_rect *dst,
> + struct drm_clip_rect *src, unsigned int num_clips,
> + unsigned int flags, u32 max_width, u32 max_height)
> +{
> + unsigned int i;
> +
> + if (!src || !num_clips) {
> + dst->x1 = 0;
> + dst->x2 = max_width;
> + dst->y1 = 0;
> + dst->y2 = max_height;
> + return true;
> + }
> +
> + dst->x1 = ~0;
> + dst->y1 = ~0;
> + dst->x2 = 0;
> + dst->y2 = 0;
> +
> + for (i = 0; i < num_clips; i++) {
> + if (flags & DRM_MODE_FB_DIRTY_ANNOTATE_COPY)
> + i++;
> + dst->x1 = min(dst->x1, src[i].x1);
> + dst->x2 = max(dst->x2, src[i].x2);
> + dst->y1 = min(dst->y1, src[i].y1);
> + dst->y2 = max(dst->y2, src[i].y2);
> + }
> +
> + if (dst->x2 > max_width || dst->y2 > max_height ||
> + dst->x1 >= dst->x2 || dst->y1 >= dst->y2) {
> + DRM_DEBUG_KMS("Illegal clip: x1=%u, x2=%u, y1=%u, y2=%u\n",
> + dst->x1, dst->x2, dst->y1, dst->y2);
> + dst->x1 = 0;
> + dst->y1 = 0;
> + dst->x2 = max_width;
> + dst->y2 = max_height;
> + }
> +
> + return (dst->x2 - dst->x1) == max_width &&
> + (dst->y2 - dst->y1) == max_height;
> +}
> +EXPORT_SYMBOL(tinydrm_merge_clips);
Argh, the drm_clip_rect vs. drm_rect confusion strikes again :(
> +
> +/**
> + * tinydrm_memcpy - Copy clip buffer
> + * @dst: Destination buffer
> + * @vaddr: Source buffer
> + * @fb: DRM framebuffer
> + * @clip: Clip rectangle area to copy
> + */
> +void tinydrm_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb,
> + struct drm_clip_rect *clip)
> +{
> + unsigned int cpp = drm_format_plane_cpp(fb->format->format, 0);
> + unsigned int pitch = fb->pitches[0];
> + void *src = vaddr + (clip->y1 * pitch) + (clip->x1 * cpp);
> + size_t len = (clip->x2 - clip->x1) * cpp;
> + unsigned int y;
> +
> + for (y = clip->y1; y < clip->y2; y++) {
> + memcpy(dst, src, len);
> + src += pitch;
> + dst += len;
> + }
> +}
> +EXPORT_SYMBOL(tinydrm_memcpy);
> +
> +/**
> + * tinydrm_swab16 - Swap bytes into clip buffer
> + * @dst: RGB565 destination buffer
> + * @vaddr: RGB565 source buffer
> + * @fb: DRM framebuffer
> + * @clip: Clip rectangle area to copy
> + */
> +
> +
> +/*
> +
> +FIXME
> +
> +Doing a memcpy to a temporary buffer before swapping bytes, increases
> +framerate by 26%, instead of swapping directly from the source buffer
> +which is drm_gem_cma_object->vaddr.
> +
> +Why is that?
> +
> +(swapping is needed because Raspberry Pi is Little Endian and doesn't
> +have 16-bit SPI support).
> +
> +# SPI @32MHz
> +$ modetest <...> 320x240@RG16 -v
> +
> +no tmp buffer
> +freq: 18.91Hz
> +
> +tmp buffer
> +freq: 23.98Hz
> +
> +
> +*/
> +static void *buf;
> +
> +void tinydrm_swab16(u16 *dst, void *vaddr, struct drm_framebuffer *fb,
> + struct drm_clip_rect *clip)
> +{
> +#if 1
> + unsigned int pitch = fb->pitches[0];
> + unsigned int x, y;
> + u16 *src;
> +
> + if (!buf)
> + buf = kmalloc(320 * 2, GFP_KERNEL);
> + if (WARN_ON_ONCE(!buf))
> + return;
> +
> + for (y = clip->y1; y < clip->y2; y++) {
> + src = vaddr + (y * pitch);
> + src += clip->x1;
> + memcpy(buf, src, (clip->x2 - clip->x1) * 2);
> + src = buf;
> + for (x = clip->x1; x < clip->x2; x++)
> + *dst++ = swab16(*src++);
> + }
> +#else
> + unsigned int pitch = fb->pitches[0];
> + unsigned int x, y;
> + u16 *src;
> +
> + for (y = clip->y1; y < clip->y2; y++) {
> + src = vaddr + (y * pitch);
> + src += clip->x1;
> + for (x = clip->x1; x < clip->x2; x++)
> + *dst++ = swab16(*src++);
> + }
> +#endif
> +}
> +EXPORT_SYMBOL(tinydrm_swab16);
> +
> +/**
> + * tinydrm_xrgb8888_to_rgb565 - Convert XRGB8888 to RGB565 clip buffer
> + * @dst: RGB565 destination buffer
> + * @vaddr: XRGB8888 source buffer
> + * @fb: DRM framebuffer
> + * @clip: Clip rectangle area to copy
> + * @swap: Swap bytes
> + *
> + * Drivers can use this function for RGB565 devices that don't natively
> + * support XRGB8888.
> + */
> +void tinydrm_xrgb8888_to_rgb565(u16 *dst, void *vaddr,
> + struct drm_framebuffer *fb,
> + struct drm_clip_rect *clip, bool swap)
> +{
> + unsigned int pitch = fb->pitches[0];
> + unsigned int x, y;
> + u16 val16;
> + u32 *src;
> +
> + for (y = clip->y1; y < clip->y2; y++) {
> + src = vaddr + (y * pitch);
> + src += clip->x1;
> + for (x = clip->x1; x < clip->x2; x++) {
> + val16 = ((*src & 0x00F80000) >> 8) |
> + ((*src & 0x0000FC00) >> 5) |
> + ((*src & 0x000000F8) >> 3);
> + src++;
> + if (swap)
> + *dst++ = swab16(val16);
> + else
> + *dst++ = val16;
> + }
> + }
> +}
> +EXPORT_SYMBOL(tinydrm_xrgb8888_to_rgb565);
I wonder whether the above would make sense in drm core as some kind of fb
helpers. But we can do that once there's a clear need.
> +
> +#ifdef CONFIG_BACKLIGHT_CLASS_DEVICE
> +/**
> + * tinydrm_of_find_backlight - Find backlight device in device-tree
> + * @dev: Device
> + *
> + * This function looks for a DT node pointed to by a property named 'backlight'
> + * and uses of_find_backlight_by_node() to get the backlight device.
> + * Additionally if the brightness property is zero, it is set to
> + * max_brightness.
> + *
> + * Returns:
> + * NULL if there's no backlight property.
> + * Error pointer -EPROBE_DEFER if the DT node is found, but no backlight device
> + * is found.
> + * If the backlight device is found, a pointer to the structure is returned.
> + */
> +struct backlight_device *tinydrm_of_find_backlight(struct device *dev)
> +{
> + struct backlight_device *backlight;
> + struct device_node *np;
> +
> + np = of_parse_phandle(dev->of_node, "backlight", 0);
> + if (!np)
> + return NULL;
> +
> + backlight = of_find_backlight_by_node(np);
> + of_node_put(np);
> +
> + if (!backlight)
> + return ERR_PTR(-EPROBE_DEFER);
> +
> + if (!backlight->props.brightness) {
> + backlight->props.brightness = backlight->props.max_brightness;
> + DRM_DEBUG_KMS("Backlight brightness set to %d\n",
> + backlight->props.brightness);
> + }
I
> +
> + return backlight;
> +}
> +EXPORT_SYMBOL(tinydrm_of_find_backlight);
> +
> +/**
> + * tinydrm_enable_backlight - Enable backlight helper
> + * @backlight: Backlight device
> + *
> + * Returns:
> + * Zero on success, negative error code on failure.
> + */
> +int tinydrm_enable_backlight(struct backlight_device *backlight)
> +{
> + unsigned int old_state;
> + int ret;
> +
> + if (!backlight)
> + return 0;
> +
> + old_state = backlight->props.state;
> + backlight->props.state &= ~BL_CORE_SUSPENDED;
> + DRM_DEBUG_KMS("Backlight state: 0x%x -> 0x%x\n", old_state,
> + backlight->props.state);
> +
> + ret = backlight_update_status(backlight);
> + if (ret)
> + DRM_ERROR("Failed to enable backlight %d\n", ret);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(tinydrm_enable_backlight);
> +
> +/**
> + * tinydrm_disable_backlight - Disable backlight helper
> + * @backlight: Backlight device
> + *
> + * Returns:
> + * Zero on success, negative error code on failure.
> + */
> +int tinydrm_disable_backlight(struct backlight_device *backlight)
> +{
> + unsigned int old_state;
> + int ret;
> +
> + if (!backlight)
> + return 0;
> +
> + old_state = backlight->props.state;
> + backlight->props.state |= BL_CORE_SUSPENDED;
> + DRM_DEBUG_KMS("Backlight state: 0x%x -> 0x%x\n", old_state,
> + backlight->props.state);
> + ret = backlight_update_status(backlight);
> + if (ret)
> + DRM_ERROR("Failed to disable backlight %d\n", ret);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(tinydrm_disable_backlight);
> +#endif
> +
> +#ifdef CONFIG_SPI
> +
> +/**
> + * tinydrm_spi_max_transfer_size - Determine max SPI transfer size
> + * @spi: SPI device
> + * @max_len: Maximum buffer size needed (optional)
> + *
> + * This function returns the maximum size to use for SPI transfers. It checks
> + * the SPI master, the optional @max_len and the module parameter spi_max and
> + * returns the smallest.
> + *
> + * Returns:
> + * Maximum size for SPI transfers
> + */
> +size_t tinydrm_spi_max_transfer_size(struct spi_device *spi, size_t max_len)
> +{
> + size_t ret;
> +
> + ret = min(spi_max_transfer_size(spi), spi->master->max_dma_len);
> + if (max_len)
> + ret = min(ret, max_len);
> + if (spi_max)
> + ret = min_t(size_t, ret, spi_max);
> + ret &= ~0x3;
> + if (ret < 4)
> + ret = 4;
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(tinydrm_spi_max_transfer_size);
> +
> +/**
> + * tinydrm_spi_bpw_supported - Check if bits per word is supported
> + * @spi: SPI device
> + * @bpw: Bits per word
> + *
> + * This function checks to see if the SPI master driver supports @bpw.
> + *
> + * Returns:
> + * True if @bpw is supported, false otherwise.
> + */
> +bool tinydrm_spi_bpw_supported(struct spi_device *spi, u8 bpw)
> +{
> + u32 bpw_mask = spi->master->bits_per_word_mask;
> +
> + if (bpw == 8)
> + return true;
> +
> + if (!bpw_mask) {
> + dev_warn_once(&spi->dev,
> + "bits_per_word_mask not set, assume 8-bit only\n");
> + return false;
> + }
> +
> + if (bpw_mask & SPI_BPW_MASK(bpw))
> + return true;
> +
> + return false;
> +}
> +EXPORT_SYMBOL(tinydrm_spi_bpw_supported);
> +
> +static void
> +tinydrm_dbg_spi_print(struct spi_device *spi, struct spi_transfer *tr,
> + const void *buf, int idx, bool tx)
> +{
> + u32 speed_hz = tr->speed_hz ? tr->speed_hz : spi->max_speed_hz;
> + char linebuf[3 * 32];
> +
> + hex_dump_to_buffer(buf, tr->len, 16,
> + DIV_ROUND_UP(tr->bits_per_word, 8),
> + linebuf, sizeof(linebuf), false);
> +
> + printk(KERN_DEBUG
> + " tr(%i): speed=%u%s, bpw=%i, len=%u, %s_buf=[%s%s]\n", idx,
> + speed_hz > 1000000 ? speed_hz / 1000000 : speed_hz / 1000,
> + speed_hz > 1000000 ? "MHz" : "kHz", tr->bits_per_word, tr->len,
> + tx ? "tx" : "rx", linebuf, tr->len > 16 ? " ..." : "");
> +}
> +
> +/* called through tinydrm_dbg_spi_message() */
> +void _tinydrm_dbg_spi_message(struct spi_device *spi, struct spi_message *m)
> +{
> + struct spi_transfer *tmp;
> + struct list_head *pos;
> + int i = 0;
> +
> + list_for_each(pos, &m->transfers) {
> + tmp = list_entry(pos, struct spi_transfer, transfer_list);
> +
> + if (tmp->tx_buf)
> + tinydrm_dbg_spi_print(spi, tmp, tmp->tx_buf, i, true);
> + if (tmp->rx_buf)
> + tinydrm_dbg_spi_print(spi, tmp, tmp->rx_buf, i, false);
> + i++;
> + }
> +}
> +EXPORT_SYMBOL(_tinydrm_dbg_spi_message);
> +
> +/**
> + * tinydrm_spi_transfer - SPI transfer helper
> + * @spi: SPI device
> + * @speed_hz: Override speed (optional)
> + * @header: Optional header transfer
> + * @bpw: Bits per word
> + * @buf: Buffer to transfer
> + * @len: Buffer length
> + *
> + * This SPI transfer helper breaks up the transfer of @buf into chunks which
> + * the SPI master driver can handle. If the machine is Little Endian and the
> + * SPI master driver doesn't support 16 bits per word, it swaps the bytes and
> + * does a 8-bit transfer.
> + * If @header is set, it is prepended to each SPI message.
> + *
> + * Returns:
> + * Zero on success, negative error code on failure.
> + */
> +int tinydrm_spi_transfer(struct spi_device *spi, u32 speed_hz,
> + struct spi_transfer *header, u8 bpw, const void *buf,
> + size_t len)
> +{
> + struct spi_transfer tr = {
> + .bits_per_word = bpw,
> + .speed_hz = speed_hz,
> + };
> + struct spi_message m;
> + u16 *swap_buf = NULL;
> + size_t max_chunk;
> + size_t chunk;
> + int ret = 0;
> +
> + if (WARN_ON_ONCE(bpw != 8 && bpw != 16))
> + return -EINVAL;
> +
> + max_chunk = tinydrm_spi_max_transfer_size(spi, 0);
> +
> + if (drm_debug & DRM_UT_DRIVER)
> + pr_debug("[drm:%s] bpw=%u, max_chunk=%zu, transfers:\n",
> + __func__, bpw, max_chunk);
> +
> + if (bpw == 16 && !tinydrm_spi_bpw_supported(spi, 16)) {
> + tr.bits_per_word = 8;
> + if (tinydrm_machine_little_endian()) {
> + swap_buf = kmalloc(min(len, max_chunk), GFP_KERNEL);
> + if (!swap_buf)
> + return -ENOMEM;
> + }
> + }
> +
> + spi_message_init(&m);
> + if (header)
> + spi_message_add_tail(header, &m);
> + spi_message_add_tail(&tr, &m);
> +
> + while (len) {
> + chunk = min(len, max_chunk);
> +
> + tr.tx_buf = buf;
> + tr.len = chunk;
> +
> + if (swap_buf) {
> + const u16 *buf16 = buf;
> + unsigned int i;
> +
> + for (i = 0; i < chunk / 2; i++)
> + swap_buf[i] = swab16(buf16[i]);
> +
> + tr.tx_buf = swap_buf;
> + }
> +
> + buf += chunk;
> + len -= chunk;
> +
> + tinydrm_dbg_spi_message(spi, &m);
> + ret = spi_sync(spi, &m);
> + if (ret)
> + return ret;
> + };
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(tinydrm_spi_transfer);
Hm, might be worth it to try and move the spi helpers into the spi core
code. But imo better to merge this now and move later on, than delay
merging tinydrm.
> +
> +#endif /* CONFIG_SPI */
> diff --git a/include/drm/tinydrm/tinydrm-helpers.h b/include/drm/tinydrm/tinydrm-helpers.h
> new file mode 100644
> index 0000000..78175fe
> --- /dev/null
> +++ b/include/drm/tinydrm/tinydrm-helpers.h
> @@ -0,0 +1,100 @@
> +/*
> + * Copyright (C) 2016 Noralf Trønnes
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#ifndef __LINUX_TINYDRM_HELPERS_H
> +#define __LINUX_TINYDRM_HELPERS_H
> +
> +struct backlight_device;
> +struct tinydrm_device;
> +struct drm_clip_rect;
> +struct spi_transfer;
> +struct spi_message;
> +struct spi_device;
> +struct device;
> +
> +/**
> + * tinydrm_machine_little_endian - Machine is little endian
> + *
> + * Returns:
> + * true if *defined(__LITTLE_ENDIAN)*, false otherwise
> + */
> +static inline bool tinydrm_machine_little_endian(void)
> +{
> +#if defined(__LITTLE_ENDIAN)
> + return true;
> +#else
> + return false;
> +#endif
> +}
> +
> +bool tinydrm_merge_clips(struct drm_clip_rect *dst,
> + struct drm_clip_rect *src, unsigned int num_clips,
> + unsigned int flags, u32 max_width, u32 max_height);
> +void tinydrm_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb,
> + struct drm_clip_rect *clip);
> +void tinydrm_swab16(u16 *dst, void *vaddr, struct drm_framebuffer *fb,
> + struct drm_clip_rect *clip);
> +void tinydrm_xrgb8888_to_rgb565(u16 *dst, void *vaddr,
> + struct drm_framebuffer *fb,
> + struct drm_clip_rect *clip, bool swap);
> +
> +#ifdef CONFIG_BACKLIGHT_CLASS_DEVICE
> +struct backlight_device *tinydrm_of_find_backlight(struct device *dev);
> +int tinydrm_enable_backlight(struct backlight_device *backlight);
> +int tinydrm_disable_backlight(struct backlight_device *backlight);
> +#else
> +static inline struct backlight_device *
> +tinydrm_of_find_backlight(struct device *dev)
> +{
> + return NULL;
> +}
> +
> +static inline int tinydrm_enable_backlight(struct backlight_device *backlight)
> +{
> + return 0;
> +}
> +
> +static inline int
> +tinydrm_disable_backlight(struct backlight_device *backlight)
> +{
> + return 0;
> +}
> +#endif
> +
> +size_t tinydrm_spi_max_transfer_size(struct spi_device *spi, size_t max_len);
> +bool tinydrm_spi_bpw_supported(struct spi_device *spi, u8 bpw);
> +int tinydrm_spi_transfer(struct spi_device *spi, u32 speed_hz,
> + struct spi_transfer *header, u8 bpw, const void *buf,
> + size_t len);
> +void _tinydrm_dbg_spi_message(struct spi_device *spi, struct spi_message *m);
> +
> +#ifdef DEBUG
> +/**
> + * tinydrm_dbg_spi_message - Dump SPI message
> + * @spi: SPI device
> + * @m: SPI message
> + *
> + * Dumps info about the transfers in a SPI message including buffer content.
> + * DEBUG has to be defined for this function to be enabled alongside setting
> + * the DRM_UT_DRIVER bit of &drm_debug.
> + */
> +static inline void tinydrm_dbg_spi_message(struct spi_device *spi,
> + struct spi_message *m)
> +{
> + if (drm_debug & DRM_UT_DRIVER)
> + _tinydrm_dbg_spi_message(spi, m);
> +}
> +#else
> +static inline void tinydrm_dbg_spi_message(struct spi_device *spi,
> + struct spi_message *m)
> +{
> +}
> +#endif /* DEBUG */
> +
> +#endif /* __LINUX_TINYDRM_HELPERS_H */
> --
> 2.10.2
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* Re: [PATCH v2 1/3] ARM: dts: imx6qdl: Fix "ERROR: code indent should use tabs where possible"
From: Shawn Guo @ 2017-01-23 9:45 UTC (permalink / raw)
To: Jagan Teki
Cc: linux-arm-kernel, devicetree, linux-kernel, Matteo Lisi,
Michael Trimarchi, Jagan Teki
In-Reply-To: <1484867375-22411-1-git-send-email-jagan@openedev.com>
On Fri, Jan 20, 2017 at 12:09:33AM +0100, Jagan Teki wrote:
> From: Jagan Teki <jagan@amarulasolutions.com>
>
> Fixed code indent tabs in respetcive imx6qdl dtsi files and
> also add space on imx6qdl-icore-rqs.dtsi on usdhc bus-width nodes.
>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Okay. I replaced v1 series with this version.
Shawn
^ permalink raw reply
* Re: [PATCH v2 2/3] ARM: dts: imx6ul: Add Engicam Is.IoT MX6UL eMMC initial support
From: Shawn Guo @ 2017-01-23 9:47 UTC (permalink / raw)
To: Jagan Teki
Cc: devicetree, Matteo Lisi, linux-kernel, Jagan Teki,
Michael Trimarchi, linux-arm-kernel
In-Reply-To: <1484867375-22411-2-git-send-email-jagan@openedev.com>
On Fri, Jan 20, 2017 at 12:09:34AM +0100, Jagan Teki wrote:
> From: Jagan Teki <jagan@amarulasolutions.com>
>
> Engicam Is.IoT MX6UL has separate module for eMMC, so add emmc dts
> file for imx6ul-isiot.dtsi, usdhc2 node represent eMMC.
>
> dmesg:
> -----
> mmc1: SDHCI controller on 2194000.usdhc [2194000.usdhc] using ADMA
> mmc1: new DDR MMC card at address 0001
> mmcblk1: mmc1:0001 M62704 3.53 GiB
>
> Cc: Matteo Lisi <matteo.lisi@engicam.com>
> Cc: Michael Trimarchi <michael@amarulasolutions.com>
> Cc: Signed-off-by: Shawn Guo <shawnguo@kernel.org>
You only want to Cc me, not sign it off for me. I removed the it when
applying.
Shawn
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
^ permalink raw reply
* Re: [PATCH v2 2/3] ARM: dts: imx6ul: Add Engicam Is.IoT MX6UL eMMC initial support
From: Jagan Teki @ 2017-01-23 9:49 UTC (permalink / raw)
To: Shawn Guo
Cc: linux-arm-kernel, devicetree, linux-kernel, Matteo Lisi,
Michael Trimarchi, Jagan Teki
In-Reply-To: <20170123094735.GO5662@dragon>
On Monday 23 January 2017 10:47 AM, Shawn Guo wrote:
> On Fri, Jan 20, 2017 at 12:09:34AM +0100, Jagan Teki wrote:
>> From: Jagan Teki <jagan@amarulasolutions.com>
>>
>> Engicam Is.IoT MX6UL has separate module for eMMC, so add emmc dts
>> file for imx6ul-isiot.dtsi, usdhc2 node represent eMMC.
>>
>> dmesg:
>> -----
>> mmc1: SDHCI controller on 2194000.usdhc [2194000.usdhc] using ADMA
>> mmc1: new DDR MMC card at address 0001
>> mmcblk1: mmc1:0001 M62704 3.53 GiB
>>
>> Cc: Matteo Lisi <matteo.lisi@engicam.com>
>> Cc: Michael Trimarchi <michael@amarulasolutions.com>
>> Cc: Signed-off-by: Shawn Guo <shawnguo@kernel.org>
>
> You only want to Cc me, not sign it off for me. I removed the it when
> applying.
Sorry, I accidentally did this will take care for next time.
thanks!
--
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
^ permalink raw reply
* Re: [PATCH 2/2] ARM: DTS: Fix register map for virt-capable GIC
From: Shawn Guo @ 2017-01-23 9:58 UTC (permalink / raw)
To: Marc Zyngier
Cc: linux-kernel, devicetree, linux-arm-kernel, Thomas Gleixner,
Jason Cooper, Rob Herring, Mark Rutland, Tsahee Zidenberg,
Antoine Tenart, Russell King, Benoît Cousson, Tony Lindgren,
Kukjin Kim, Krzysztof Kozlowski, Javier Martinez Canillas,
Sascha Hauer, Fabio Estevam, Santosh Shilimkar, Matthias Brugger
In-Reply-To: <1484736811-24002-3-git-send-email-marc.zyngier@arm.com>
On Wed, Jan 18, 2017 at 10:53:31AM +0000, Marc Zyngier wrote:
> Since everybody copied my own mistake from the DT binding example,
> let's address all the offenders in one swift go.
>
> Most of them got the CPU interface size wrong (4kB, while it should
> be 8kB), except for both keystone platforms which got the control
> interface wrong (4kB instead of 8kB).
>
> In the couple of cases were I knew for sure what implementation
> was used, I've added the "arm,gic-400" compatible string. I'm 99%
> sure that this is what everyong is using, but short of having the
> TRM for all the other SoCs, I've let them alone.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> arch/arm/boot/dts/imx6ul.dtsi | 4 ++--
Acked-by: Shawn Guo <shawnguo@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/1] ARM: dts: imx6dl: fix GPIO4 range
From: Shawn Guo @ 2017-01-23 10:10 UTC (permalink / raw)
To: Sébastien Szymanski
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Sascha Hauer,
Fabio Estevam, Julien Boibessot
In-Reply-To: <1484734191-18556-1-git-send-email-sebastien.szymanski-d2DlULPkwbNWk0Htik3J/w@public.gmane.org>
On Wed, Jan 18, 2017 at 11:09:51AM +0100, Sébastien Szymanski wrote:
> GPIO4_11 is on pin 152(MX6DL_PAD_KEY_ROW2) and not on pin
> 151(MX6DL_PAD_KEY_ROW1).
>
> I found the error while booting a mainline kernel on APF6S SoM and
> noticed the following message:
>
> [ 2.609337] imx6dl-pinctrl 20e0000.iomuxc: pin MX6DL_PAD_KEY_ROW1
> already requested by 20a8000.gpio:105; cannot claim for 20a8000.gpio:107
> [ 2.621884] imx6dl-pinctrl 20e0000.iomuxc: pin-151 (20a8000.gpio:107)
> status -22
> [ 2.629303] spi_imx 2008000.ecspi: Can't get CS GPIO 107
>
> With this patch, the message is gone and spi_imx driver probes correctly.
>
> Fixes: bb728d662bed ("ARM: dts: add gpio-ranges property to iMX GPIO
> controllers")
>
> Signed-off-by: Sébastien Szymanski <sebastien.szymanski-d2DlULPkwbNWk0Htik3J/w@public.gmane.org>
Applied, thanks.
--
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] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips
From: Vivek Gautam @ 2017-01-23 10:13 UTC (permalink / raw)
To: Bjorn Andersson, Kishon Vijay Abraham I
Cc: robh+dt, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
Mark Rutland, Stephen Boyd, Srinivas Kandagatla, linux-arm-msm
In-Reply-To: <20170118180347.GO10531@minitux>
On Wed, Jan 18, 2017 at 11:33 PM, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
> On Wed 18 Jan 01:13 PST 2017, Vivek Gautam wrote:
>> On 01/16/2017 02:15 PM, Kishon Vijay Abraham I wrote:
>> > Hi,
>> >
>> > On Tuesday 10 January 2017 04:21 PM, Vivek Gautam wrote:
> [..]
>> > > +static const struct qusb2_phy_init_tbl msm8996_init_tbl[] = {
>> > > + QUSB2_PHY_INIT_CFG(QUSB2PHY_PORT_TUNE1, 0xf8),
>> > > + QUSB2_PHY_INIT_CFG(QUSB2PHY_PORT_TUNE2, 0xb3),
>> > > + QUSB2_PHY_INIT_CFG(QUSB2PHY_PORT_TUNE3, 0x83),
>> > > + QUSB2_PHY_INIT_CFG(QUSB2PHY_PORT_TUNE4, 0xc0),
>> > > + QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_TUNE, 0x30),
>> > > + QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_USER_CTL1, 0x79),
>> > > + QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_USER_CTL2, 0x21),
>> > > + QUSB2_PHY_INIT_CFG(QUSB2PHY_PORT_TEST2, 0x14),
>> > > + QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_AUTOPGM_CTL1, 0x9f),
>> > > + QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_PWR_CTRL, 0x00),
>> > > +};
>> > I wish all this data comes from device tree and one API in phy-core can do all
>> > these settings. Your other driver qcom-qmp also seems to have a bunch of
>> > similar settings.
>> >
>> > The problem is every vendor driver adds a bunch of code to perform the same
>> > thing again and again when all of these settings can be done by a single phy API.
>>
>> Yes, i understand this. You have commented similar thing in the patch from
>> Jaehoon -
>> [PATCH V2 2/5] phy: phy-exynos-pcie: Add support for Exynos PCIe phy
>>
>> I would like to understand the requirements here.
>> Would you like me to get all this information from the device tree -
>> an array of register offset and value pair, which we can then program
>> by calling a phy_ops (may be calibrate) ? Something of this sort:
>>
>> phy-calibrate-data = <val1, register_offset1>,
>> <val2, register_offset2>,
>> <val3, register_offset3>,
>> ....
>>
>> I am sure having such information in the driver (like i have in my patch)
>> makes the driver look more clumsy.
>> But, all this data can be pretty huge - a set of some 100+ register-value
>> pairs
>> for QMP phy, for example. So, will it be okay to get this from device tree ?
>> We also note here that such information changes from one IP version to
>> another.
>> I remember Rob having some concerns about it.
>>
>
> The devicetree is supposed to describe which hardware components a
> certain device has, most of the time this carries a set of properties to
> describe how this piece is connected and configured.
>
> A dump of magic register values does not describe how the QMP is
> connected to anything and is, as far as this patch shows, static for
> this particular hardware block.
Yes, that's correct. The QMP and QUSB2 phy init sequences are a bunch
of static values for a particular IP version. These values hardly give a
meaningful data to put few phy bindings that could be referenced
to configure the phy further.
>
> Further more moving this blob to devicetree will not allow us to treat
> the various QMP configurations as one HW block, as there are other
> differences as well.
>
> Like many other drivers it's possible to create a generic version that
> has every bit of logic driven by configuration from devicetree, but like
> most of those cases this is not the way we split things.
>
> And this has the side effect of keeping the dts files human readable,
> human understandable and human maintainable.
That's right. These register-value pairs (100+ for qmp) don't give a human
understandable data when put in dts.
Kishon,
Please let me know if you have concerns.
If this looks good otherwise, please consider taking this for 4.11.
Regards
Vivek
>
> Regards,
> Bjorn
> --
> 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
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH 4/8] clk: renesas: cpg-mssr: Add support for reset control
From: Geert Uytterhoeven @ 2017-01-23 10:14 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Geert Uytterhoeven, Philipp Zabel, Simon Horman, Magnus Damm,
Michael Turquette, Stephen Boyd, Rob Herring, Mark Rutland,
linux-clk, devicetree@vger.kernel.org, Linux-Renesas,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170120220302.GA20610@bigcity.dyn.berto.se>
Hi Niklas,
On Fri, Jan 20, 2017 at 11:03 PM, Niklas Söderlund
<niklas.soderlund@ragnatech.se> wrote:
> Nice patch! It took me a while to understand why you didn't need to read
> the register before writing to it in cpg_mssr_deassert() :-)
Yeah, deassertion and assertion are asymmetrical.
Note that on older (not yet supported) SH/R-Mobile parts, there are no
reset clear registers, and deassertion is symmetrical.
> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Thanks!
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 v8 12/12] mux: support simplified bindings for single-user gpio mux
From: Peter Rosin @ 2017-01-23 10:24 UTC (permalink / raw)
To: Jonathan Cameron, linux-kernel
Cc: Wolfram Sang, Rob Herring, Mark Rutland, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Jonathan Corbet,
Andrew Morton, linux-i2c, devicetree, linux-iio, linux-doc
In-Reply-To: <33b29f7e-3e48-b85d-ccf9-93b1d67ac634@kernel.org>
On 2017-01-22 14:30, Jonathan Cameron wrote:
> On 18/01/17 15:57, Peter Rosin wrote:
>> Allow bindings for a GPIO controlled mux to be specified in the
>> mux consumer node.
>>
>> Signed-off-by: Peter Rosin <peda@axentia.se>
> Code is good as far as I am concerned. Only question is whether this
Hmmm, now that I think some more about it, the code supporting the
simplified binding (patch 12/12) is a bit fishy in one respect.
A driver that calls mux_control_get and gets a mux_control that happens
to be backed by an implicit mux chip (i.e. using the simplified binding)
will not be able to reverse the resource allocation with less than a
complete destruction of itself. Now, this is likely not a problem in
most cases, but I bet it will creep up at the most inopportune time. And
your remark that I'm the one that has to maintain this makes me dislike
this concept...
I.e. mux_control_put *should* reverse mux_control_get, but this simply
does not happen for the implicit mux chips, as implicit mux chips are
not put away until the owning device is put away.
Every time I have tried to come up with a way to implement the simplified
bindings I seem to hit one of these subtleties.
> is worth the hassle given the normal bindings don't give that high
> a burden in complexity!
I am missing an ack from Rob though.
> I don't really care either way:)
But Rob seems to care, this series just has to find a way to get out of
his too-much-churn-will-look-at-it-later list. I sadly don't know how to
pull that trick...
Cheers,
peda
^ permalink raw reply
* Re: [PATCH 1/3] ARM: dts: Add support for phyCORE-AM335x PCM-953 carrier board
From: Teresa Remmet @ 2017-01-23 10:27 UTC (permalink / raw)
To: Rob Herring
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Benoît Cousson, Tony Lindgren, Mark Rutland, Wadim Egorov
In-Reply-To: <20170121205345.oij67ai5d7q7k74d@rob-hp-laptop>
Hello Rob,
Am Samstag, den 21.01.2017, 14:53 -0600 schrieb Rob Herring:
> On Thu, Jan 19, 2017 at 02:07:48PM +0100, Teresa Remmet wrote:
> >
> > The phyCORE-AM335x development kit is a combination of the
> > phyCORE-AM335x SoM and a PCM-953 carrier board. The features
> > of the PCM-953 are:
> > * ETH phy on carrier board: 1x RGMII
> > * 1x CAN
> > * Up to 4x UART
> > * USB0 (otg)
> > * USB1 (host)
> > * SD slot
> > * User gpio-keys
> > * User LEDs
> >
> > Signed-off-by: Teresa Remmet <t.remmet-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
> > Reviewed-by: Wadim Egorov <w.egorov-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
> > ---
> > .../devicetree/bindings/arm/omap/omap.txt | 3 +
> > arch/arm/boot/dts/Makefile | 1 +
> > arch/arm/boot/dts/am335x-pcm-953.dtsi | 303
> > +++++++++++++++++++++
> > arch/arm/boot/dts/am335x-phycore-rdk.dts | 27 ++
> > 4 files changed, 334 insertions(+)
> > create mode 100644 arch/arm/boot/dts/am335x-pcm-953.dtsi
> > create mode 100644 arch/arm/boot/dts/am335x-phycore-rdk.dts
> [...]
>
> >
> > + user_leds: user_leds {
> > + compatible = "gpio-leds";
> > + };
> > +
> > + user_buttons: user_buttons {
> > + compatible = "gpio-keys";
> > + };
> With only a compatible, I don't think there's much gain to split
> these 2
> nodes. Otherwse,
whould it be ok to open up the root node again below? Or should I
better move the nodes up? Which does mess up the order then. We
orinented here on the am335x-pepper.dts. They also only keep the
compatibles in the root node.
Thanks,
Teresa
>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> >
> > +&user_buttons {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&user_buttons_pins>;
> > + status = "okay";
> > +
> > + button@0 {
> > + label = "home";
> > + linux,code = <KEY_HOME>;
> > + gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>;
> > + gpio-key,wakeup;
> > + };
> > +
> > + button@1 {
> > + label = "menu";
> > + linux,code = <KEY_MENU>;
> > + gpios = <&gpio3 8 GPIO_ACTIVE_HIGH>;
> > + gpio-key,wakeup;
> > + };
> > +};
> > +
> > +&user_leds {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&user_leds_pins>;
> > + status = "okay";
> > +
> > + green {
> > + label = "green:user";
> > + gpios = <&gpio1 30 GPIO_ACTIVE_HIGH>;
> > + linux,default-trigger = "gpio";
> > + default-state = "on";
> > + };
> > +
> > + yellow {
> > + label = "yellow:user";
> > + gpios = <&gpio1 31 GPIO_ACTIVE_LOW>;
> > + linux,default-trigger = "gpio";
> > + default-state = "on";
> > + };
> > +};
--
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 v9 0/4] arm64: arch_timer: Add workaround for hisilicon-161010101 erratum
From: Mark Rutland @ 2017-01-23 10:31 UTC (permalink / raw)
To: Hanjun Guo
Cc: Ding Tianhong, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, Daniel Lezcano, Thomas Gleixner,
devicetree-u79uwXL29TY76Z2rM5mHXA, marc.zyngier-5wv7dgnIgG8,
stuart.yoder-3arQi8VN3Tc, linuxarm-hv44wF8Li93QT0dZR+AlfA,
oss-fOR+EgIDQEHk1uMJSBkQmQ, shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Fu Wei
In-Reply-To: <8818973b-602b-e71f-a12b-3e894aa0e619-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Sun, Jan 22, 2017 at 03:59:57PM +0800, Hanjun Guo wrote:
> On 2017/1/20 23:04, Mark Rutland wrote:
> >On Thu, Jan 19, 2017 at 09:35:12PM +0800, Ding Tianhong wrote:
> >>Ding Tianhong (4):
> >> arm64: arch_timer: Add device tree binding for hisilicon-161010101
> >> erratum
> >> arm64: arch_timer: Introduce a generic erratum handing mechanism for
> >> fsl-a008585
> >> arm64: arch_timer: Work around Erratum Hisilicon-161010101
> >> arm64: arch timer: Add timer erratum property for Hip05-d02 and
> >> Hip06-d03
> >>
> >> Documentation/admin-guide/kernel-parameters.txt | 9 --
> >> Documentation/arm64/silicon-errata.txt | 43 +++---
> >> .../devicetree/bindings/arm/arch_timer.txt | 6 +
> >> arch/arm64/boot/dts/hisilicon/hip05.dtsi | 1 +
> >> arch/arm64/boot/dts/hisilicon/hip06.dtsi | 1 +
> >> arch/arm64/include/asm/arch_timer.h | 38 ++----
> >> drivers/clocksource/Kconfig | 18 +++
> >> drivers/clocksource/arm_arch_timer.c | 150 +++++++++++++++------
> >> 8 files changed, 171 insertions(+), 95 deletions(-)
> >
> >I've picked these up (with a few local cleanups), given that some local
> >testing, and pushed the result to a branch [1] on my git repo.
> >
> >There are likely to be clashes with the arm64 tree (e.g. for
> >silicon-errata.txt), and we're also likely to have more arch timer
> >updates shortly for the GTDT stuff,
>
> Yes, GTDT patches conflict with this patch set but it's easy to
> fix.
Sure. What I meant is that I'd prefer to fix any such conflict myself
(i.e. by basing the GTDT patches atop of this), before passing this
upwards.
> >so I think the best bet is for both arm64 and the clocksource tree to
> >pull that branch for v4.11.
> >
> >Alternatively, we could take this all through the arm64 tree, if the
> >clocksource maintainers are happy with that.
> >
> >Thoughts?
>
> GTDT patch set is adding ACPI support for arch timer, and it's
> only used for ARM64 now, in order to handler the conflict easily,
> I think take them all through arm64 tree is better
In either case I believe we should be able to handle the conflict. Going
through one tree (i.e. arm64) would simplify things substantially,
though.
This really comes down to what the clocksource maintainers prefer.
> (I was working with Fuwei for the GTDT patch set and I hope it's not
> blocked by "who will merge the code"...)
Hopefully this is just a formality. :)
Thanks,
Mark.
--
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
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