Devicetree
 help / color / mirror / Atom feed
* Re: [PATCH V2 3/4] arm64: dts: Enable SDHCI for Nexus 5X (msm8992)
From: Bjorn Andersson @ 2017-01-18 19:02 UTC (permalink / raw)
  To: Jeremy McNicoll
  Cc: linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
	linux-soc-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-mmc-u79uwXL29TY76Z2rM5mHXA,
	andy.gross-QSEj5FYQhm4dnm+yROfE0A, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
	robh-DgEjT+Ai2ygdnm+yROfE0A, arnd-r2nGTMty4D4,
	riteshh-sgV2jX0FEOL9JmXXK+q4OQ, git-LJ92rlH3Dns,
	ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
	jszhang-eYqpPyKDWXRBDgjK7y7TUQ
In-Reply-To: <1484614729-26751-4-git-send-email-jeremymc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

On Mon 16 Jan 16:58 PST 2017, Jeremy McNicoll wrote:

> Add Nexus 5X (msm8992) SDHCI support, including initial regulator
> entries to support enabling the main SDHCI/MMC.
> 
> The RPM is common between 8992 & 8994 simply reflect reality with
> a shared DT entry.
> 
> The msm8994 RPM regulator talks over SMD to the APPS processor.
> 
> Signed-off-by: Jeremy McNicoll <jeremymc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
> 
> Dropped RobH's ACK explicitly after addressing all feedback.
> The reason is that msm8994-smd-rpm.dtsi was created to allow
> for sharing between 8992 & 8994 as the RPM is common between
> the two. 
> 
>  .../bindings/regulator/qcom,smd-rpm-regulator.txt  |  40 +++
>  .../boot/dts/qcom/msm8992-bullhead-rev-101.dts     |   2 +
>  arch/arm64/boot/dts/qcom/msm8992-pins.dtsi         |  82 ++++++
>  arch/arm64/boot/dts/qcom/msm8992.dtsi              | 153 ++++++++++++
>  arch/arm64/boot/dts/qcom/msm8994-smd-rpm.dtsi      | 276 +++++++++++++++++++++
>  drivers/regulator/qcom_smd-regulator.c             |  49 ++++
>  6 files changed, 602 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/qcom/msm8994-smd-rpm.dtsi
> 
> diff --git a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt
> index 1f8d6f8..126989b 100644
> --- a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt
> +++ b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt
> @@ -23,6 +23,7 @@ Regulator nodes are identified by their compatible:
>  		    "qcom,rpm-pm8916-regulators"
>  		    "qcom,rpm-pm8941-regulators"
>  		    "qcom,rpm-pma8084-regulators"
> +		    "qcom,rpm-pm8994-regulators"
>  
>  - vdd_s1-supply:
>  - vdd_s2-supply:
> @@ -97,6 +98,40 @@ Regulator nodes are identified by their compatible:
>  	Definition: reference to regulator supplying the input pin, as
>  		    described in the data sheet
>  
> +- vdd_s1-supply:
> +- vdd_s2-supply:
> +- vdd_s3-supply:
> +- vdd_s4-supply:
> +- vdd_s5-supply:
> +- vdd_s6-supply:
> +- vdd_s7-supply:
> +- vdd_l1_l11-supply:
> +- vdd_l2_l3_l4_l27-supply:
> +- vdd_l5_l7-supply:
> +- vdd_l6_l12_l14_l15_l26-supply:
> +- vdd_l8-supply:
> +- vdd_l9_l10_l13_l20_l23_l24-supply:
> +- vdd_l1_l11-supply:
> +- vdd_l6_l12_l14_l15_l26-supply:
> +- vdd_l16_l25-supply:
> +- vdd_l17-supply:
> +- vdd_l18-supply:
> +- vdd_l19-supply:
> +- vdd_l21-supply:
> +- vdd_l22-supply:
> +- vdd_l16_l25-supply:
> +- vdd_l27-supply:
> +- vdd_l28-supply:
> +- vdd_l29-supply:
> +- vdd_l30-supply:
> +- vdd_l31-supply:
> +- vdd_l32-supply:
> +	Usage: optional (pm8994 only)
> +	Value type: <phandle>
> +	Definition: reference to regulator supplying the input pin, as
> +		    described in the data sheet.

This is not entirely correct and should be part of a "arm64: dts" patch.

It seems to be compatible with the pm8994 patch we've had sitting in the
Linaro tree for msm8996 for some time, so I did send this out; with you
Cc. Please give it a spin.

> +
> +
>  The regulator node houses sub-nodes for each regulator within the device. Each
>  sub-node is identified using the node's name, with valid values listed for each
>  of the pmics below.
> @@ -118,6 +153,11 @@ pma8084:
>  	l6, l7, l8, l9, l10, l11, l12, l13, l14, l15, l16, l17, l18, l19, l20,
>  	l21, l22, l23, l24, l25, l26, l27, lvs1, lvs2, lvs3, lvs4, 5vs1
>  
> +pm8994:
> +	s1, s2, s3, s4, s5, s6, s7, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11,
> +	l12, l13, l14, l15, l16, l17, l18, l19, l20, l21, l22, l23, l24, l25, l26,
> +	l27, l28, l29, l30, l31, l32, lvs1, lvs2
> +
>  The content of each sub-node is defined by the standard binding for regulators -
>  see regulator.txt.
>  
> diff --git a/arch/arm64/boot/dts/qcom/msm8992-bullhead-rev-101.dts b/arch/arm64/boot/dts/qcom/msm8992-bullhead-rev-101.dts
> index 4542133..3fc9a33 100644
> --- a/arch/arm64/boot/dts/qcom/msm8992-bullhead-rev-101.dts
> +++ b/arch/arm64/boot/dts/qcom/msm8992-bullhead-rev-101.dts
> @@ -39,3 +39,5 @@
>  		};
>  	};
>  };
> +
> +#include "msm8994-smd-rpm.dtsi"
> diff --git a/arch/arm64/boot/dts/qcom/msm8992-pins.dtsi b/arch/arm64/boot/dts/qcom/msm8992-pins.dtsi
> index d2a26f0..d3ae5ab 100644
> --- a/arch/arm64/boot/dts/qcom/msm8992-pins.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8992-pins.dtsi
> @@ -35,4 +35,86 @@
>  			bias-pull-down;
>  		};
>  	};
> +
> +	/* 0-3 for sdc1 4-6 for sdc2 */
> +	/* Order of pins */
> +	/* SDC1: CLK -> 0, CMD -> 1, DATA -> 2, RCLK -> 3 */
> +	/* SDC2: CLK -> 4, CMD -> 5, DATA -> 6 */
> +	pmx-sdc1-clk {
> +		sdc1_clk_on: clk-on {
> +			pinmux {
> +				pins = "sdc1_clk";
> +			};

The name of these nodes are insignificant, so you don't have to have a
pinmux and a pinconf, you can describe all properties in one node. I
even think you can flatten this and drop the inner subnode.

> +			pinconf {
> +				pins = "sdc1_clk";
> +				bias-disable = <0>; /* No pull */
> +				drive-strength = <16>; /* 16mA */
> +			};
> +		};
[..]
> diff --git a/arch/arm64/boot/dts/qcom/msm8992.dtsi b/arch/arm64/boot/dts/qcom/msm8992.dtsi
> index 44b2d37..77edffc 100644
> --- a/arch/arm64/boot/dts/qcom/msm8992.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8992.dtsi
> @@ -82,6 +82,12 @@
>  				<0xf9002000 0x1000>;
>  		};
>  
> +		apcs: syscon@f900d000 {
> +			compatible = "syscon";
> +			reg = <0xf900d000 0x2000>;
> +		};
> +
> +

Please send the SMEM/SMD-ification in a separate patch from the sdhci
addition.

>  		timer@f9020000 {
>  			#address-cells = <1>;
>  			#size-cells = <1>;
> @@ -172,12 +178,159 @@
>  			#power-domain-cells = <1>;
>  			reg = <0xfc400000 0x2000>;
>  		};
> +
> +		sdhci1: mmc@f9824900 {
> +			compatible = "qcom,sdhci-msm-v4";
> +			reg = <0xf9824900 0x1a0>, <0xf9824000 0x800>;
> +			reg-names = "hc_mem", "core_mem";
> +
> +			interrupts = <GIC_SPI 123 IRQ_TYPE_NONE>,
> +					<GIC_SPI 138 IRQ_TYPE_NONE>;
> +			interrupt-names = "hc_irq", "pwr_irq";
> +
> +			clocks = <&clock_gcc GCC_SDCC1_APPS_CLK>,
> +				<&clock_gcc GCC_SDCC1_AHB_CLK>;
> +			clock-names = "core", "iface";
> +
> +			pinctrl-names = "default", "sleep";
> +			pinctrl-0 = <&sdc1_clk_on &sdc1_cmd_on &sdc1_data_on
> +					&sdc1_rclk_on>;
> +			pinctrl-1 = <&sdc1_clk_off &sdc1_cmd_off &sdc1_data_off
> +					&sdc1_rclk_off>;
> +
> +			vdd-supply = <&pm8994_l20>;
> +			qcom,vdd-voltage-level = <2950000 2950000>;
> +			qcom,vdd-current-level = <200 570000>;

These properties are not recognized upstream, please drop.

> +
> +			vdd-io-supply = <&pm8994_s4>;
> +			qcom,vdd-io-voltage-level = <1800000 1800000>;
> +			qcom,vdd-io-current-level = <200 325000>;
> +
> +			regulator-always-on;
> +			bus-width = <8>;
> +			mmc-hs400-1_8v;
> +			status = "okay";
> +		};
> +
> +		vreg_vph_pwr: vreg-vph-pwr {
> +			compatible = "regulator-fixed";
> +			status = "okay";
> +			regulator-name = "vph-pwr";
> +
> +			regulator-min-microvolt = <3600000>;
> +			regulator-max-microvolt = <3600000>;
> +
> +			regulator-always-on;
> +		};

This doesn't have a "reg", so please move it outside "soc"

> +
> +		rpm_msg_ram: memory@fc428000 {
> +			compatible = "qcom,rpm-msg-ram";
> +			reg = <0xfc428000 0x4000>;
> +		};
> +
> +		sfpb_mutex_regs: syscon@fd484000 {
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +			compatible = "syscon";
> +			reg = <0xfd484000 0x400>;
> +		};
> +
> +		sfpb_mutex: hwmutex {
> +			compatible = "qcom,sfpb-mutex";
> +			syscon = <&sfpb_mutex_regs 0x0 0x100>;
> +			#hwlock-cells = <1>;
> +		};
> +
> +		smem {
> +			compatible = "qcom,smem";
> +			memory-region = <&smem_region>;
> +			qcom,rpm-msg-ram = <&rpm_msg_ram>;
> +			hwlocks = <&sfpb_mutex 3>;
> +		};

The smem enablement here looks reasonable, please split into a separate
patch.

>  	};
>  
>  	memory {
>  		device_type = "memory";
>  		reg = <0 0 0 0>; // bootloader will update
>  	};
> +
> +	reserved-memory {
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;
> +
> +		smem_region: smem@6a00000 {
> +			reg = <0x0 0x6a00000 0x0 0x200000>;
> +			no-map;
> +		};
> +	};
> +
> +	smd_rpm: smd {

You don't have to reference this by label, just saying "/smd" will work
just as well.

> +		compatible = "qcom,smd";
> +
> +		rpm {
> +			interrupts = <GIC_SPI 168 IRQ_TYPE_EDGE_RISING>;
> +			qcom,ipc = <&apcs 8 0>;
> +			qcom,smd-edge = <15>;
> +			qcom,local-pid = <0>;
> +			qcom,remote-pid = <6>;
> +
> +			rpm-requests {
> +				compatible = "qcom,rpm-msm8994";
> +				qcom,smd-channels = "rpm_requests";
> +
> +				rpmcc: qcom,rpmcc {
> +					/* TODO: update when rpmcc-msm8994 support added */
> +					compatible = "qcom,rpmcc-msm8916",
> +							"qcom,rpmcc";
> +					#clock-cells = <1>;
> +				};

You're not compatible with qcom,rpmcc-msm8916, so don't fool the kernel
to think you are. Just drop this node until you have a rpmcc and need
it.

> +
> +				smd_rpm_regulators: pm8994-regulators {

This label is unused.

> +					compatible = "qcom,rpm-pm8994-regulators";
> +
> +					pm8994_s1: s1 {};
> +					pm8994_s2: s2 {};
> +					pm8994_s3: s3 {};
> +					pm8994_s4: s4 {};
> +					pm8994_s5: s5 {};
> +					pm8994_s6: s6 {};
> +					pm8994_s7: s7 {};
> +
> +					pm8994_l1: l1 {};
> +					pm8994_l2: l2 {};
> +					pm8994_l3: l3 {};
> +					pm8994_l4: l4 {};
> +					pm8994_l6: l6 {};
> +					pm8994_l8: l8 {};
> +					pm8994_l9: l9 {};
> +					pm8994_l10: l10 {};
> +					pm8994_l11: l11 {};
> +					pm8994_l12: l12 {};
> +					pm8994_l13: l13 {};
> +					pm8994_l14: l14 {};
> +					pm8994_l15: l15 {};
> +					pm8994_l16: l16 {};
> +					pm8994_l17: l17 {};
> +					pm8994_l18: l18 {};
> +					pm8994_l19: l19 {};
> +					pm8994_l20: l20 {};
> +					pm8994_l21: l21 {};
> +					pm8994_l22: l22 {};
> +					pm8994_l23: l23 {};
> +					pm8994_l24: l24 {};
> +					pm8994_l25: l25 {};
> +					pm8994_l26: l26 {};
> +					pm8994_l27: l27 {};
> +					pm8994_l28: l28 {};
> +					pm8994_l29: l29 {};
> +					pm8994_l30: l30 {};
> +					pm8994_l31: l31 {};
> +					pm8994_l32: l32 {};

Add lvs1 & lvs2.

> +				};
> +			};
> +		};
> +	};
>  };
>  
>  
> diff --git a/arch/arm64/boot/dts/qcom/msm8994-smd-rpm.dtsi b/arch/arm64/boot/dts/qcom/msm8994-smd-rpm.dtsi

These rpm settings are not for msm8994, they are for your device. So
please drop this file and move below nodes into your device dts.

[..]
> +&smd_rpm {
> +	rpm {
> +		rpm_requests {
> +			pm8994-regulators {
> +
> +				vdd_l1-supply = <&pm8994_s1>;
> +				vdd_l2_26_28-supply = <&pm8994_s3>;
> +				vdd_l3_11-supply = <&pm8994_s3>;
> +				vdd_l4_27_31-supply = <&pm8994_s3>;
> +				vdd_l5_7-supply = <&pm8994_s3>;
> +				vdd_l6_12_32-supply = <&pm8994_s5>;
> +				vdd_l8_16_30-supply = <&vreg_vph_pwr>;
> +				vdd_l9_10_18_22-supply = <&vreg_vph_pwr>;
> +				vdd_l13_19_23_24-supply = <&vreg_vph_pwr>;
> +				vdd_l14_15-supply = <&pm8994_s5>;
> +				vdd_l17_29-supply = <&vreg_vph_pwr>;
> +				vdd_l20_21-supply = <&vreg_vph_pwr>;
> +				vdd_l25-supply = <&pm8994_s5>;
> +				/*vin_lvs1_2 = <&pm8994_s4>; */

I added this to the pm8994 regulator patch I just sent out, called it
"vdd_lvs1_2".

> +
[..]
> diff --git a/drivers/regulator/qcom_smd-regulator.c b/drivers/regulator/qcom_smd-regulator.c
[..]
>  
> +static const struct rpm_regulator_data rpm_pm8994_regulators[] = {
> +	{ "s1", QCOM_SMD_RPM_SMPA, 1, &pma8084_ftsmps, "vdd_s1" },

As with the binding, this isn't entirely correct. Please see my
submitted patch.

Regards,
Bjorn
--
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] ahci: qoriq: added ls2088a platforms support
From: Tejun Heo @ 2017-01-18 19:21 UTC (permalink / raw)
  To: yuantian.tang
  Cc: mark.rutland, devicetree, linux-kernel, linux-ide, robh+dt,
	linux-arm-kernel
In-Reply-To: <1484633521-10938-1-git-send-email-yuantian.tang@nxp.com>

On Tue, Jan 17, 2017 at 02:12:01PM +0800, yuantian.tang@nxp.com wrote:
> From: Tang Yuantian <Yuantian.Tang@nxp.com>
> 
> Ls2088a is new introduced arm-based soc with sata support with
> following features:
> 1. Complies with the serial ATA 3.0 specification and the AHCI 1.3.1
>    specification
> 2. Contains a high-speed descriptor-based DMA controller
> 3. Supports the following:
>    a. Speeds of 1.5 Gb/s (first-generation SATA), 3 Gb/s
>       (second-generation SATA), and 6 Gb/s (third-generation SATA)
>    b. FIS-based switching
>    c. Native command queuing (NCQ) commands
>    d. Port multiplier operation
>    e. Asynchronous notification
>    f. SATA BIST mode
> 
> Signed-off-by: Tang Yuantian <yuantian.tang@nxp.com>

Applied to libata/for-4.11.

Thanks.

-- 
tejun

^ permalink raw reply

* Re: [PATCH v2] ata: xgene: Enable NCQ support for APM X-Gene SATA controller hardware v1.1
From: Tejun Heo @ 2017-01-18 19:23 UTC (permalink / raw)
  To: Rameshwar Sahu
  Cc: Devicetree List, mlangsdo, Arnd Bergmann, linux-scsi, Jon Masters,
	patches, linux-ide, Olof Johansson, linux-arm
In-Reply-To: <CAFd313wajZzZWGQy20obf4k_7RO43Q10NiBa-8TVYxo3J93inA@mail.gmail.com>

Hello,

On Tue, Jan 17, 2017 at 08:25:21PM +0530, Rameshwar Sahu wrote:
> Hi Tejun,
> 
> On Fri, Nov 18, 2016 at 3:15 PM, Rameshwar Prasad Sahu <rsahu@apm.com> wrote:
> > This patch enables NCQ support for APM X-Gene SATA controller hardware v1.1
> > that was broken with hardware v1.0. Second thing, here we should not assume
> > XGENE_AHCI_V2 always in case of having valid _CID in ACPI table. I need to
> > remove this assumption because V1_1 also has a valid _CID for backward
> > compatibly with v1.
> >
> > v2 changes:
> >         1. Changed patch description
> >
> > Signed-off-by: Rameshwar Prasad Sahu <rsahu@apm.com>

Hmm... I don't have the patch in my queue.  Can you please resend it?

Thanks.

-- 
tejun

^ permalink raw reply

* Re: [PATCH 0/5] meson-gx: reset RGMII PHYs and configure TX delay
From: Kevin Hilman @ 2017-01-18 19:28 UTC (permalink / raw)
  To: Martin Blumenstingl
  Cc: linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	carlo-KA+7E9HrN00dnm+yROfE0A,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA, will.deacon-5wv7dgnIgG8,
	catalin.marinas-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <20161202234739.22929-1-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>

Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> writes:

> This partially fixes the 1000Mbit/s ethernet TX throughput issues (on
> networks which are not affected by the EEE problem, as reported here:

Based on the discussions with Jerome, I'm dropping this series from the
v4.11/dt64 branch for now.

This series also had a small conflict with Jerome's fix[1] for the
odroid-c2, so please rebase any updates here on my v4.10/fixes branch.

Kevin

[1] https://git.kernel.org/cgit/linux/kernel/git/khilman/linux-amlogic.git/commit/?h=v4.10/fixes
--
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 0/5] meson-gx: reset RGMII PHYs and configure TX delay
From: Martin Blumenstingl @ 2017-01-18 19:40 UTC (permalink / raw)
  To: Kevin Hilman
  Cc: mark.rutland, devicetree, catalin.marinas, will.deacon, robh+dt,
	carlo, linux-amlogic, linux-arm-kernel
In-Reply-To: <m2a8ao1833.fsf@baylibre.com>

Kevin,

On Wed, Jan 18, 2017 at 8:28 PM, Kevin Hilman <khilman@baylibre.com> wrote:
> Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
>
>> This partially fixes the 1000Mbit/s ethernet TX throughput issues (on
>> networks which are not affected by the EEE problem, as reported here:
>
> Based on the discussions with Jerome, I'm dropping this series from the
> v4.11/dt64 branch for now.
what is you opinion on having the MDIO node in meson-gx (and keeping
GXBB and GXL/GXM consistent) vs not having PHY autodetection for GXBB
(= not having the MDIO in meson-gx)?
I cannot send a v2 until we have a decision for this

> This series also had a small conflict with Jerome's fix[1] for the
> odroid-c2, so please rebase any updates here on my v4.10/fixes branch.
will keep that in mind, noted.

^ permalink raw reply

* Re: [PATCH] ahci: qoriq: added ls2088a platforms support
From: Tejun Heo @ 2017-01-18 19:53 UTC (permalink / raw)
  To: yuantian.tang
  Cc: robh+dt, mark.rutland, linux-ide, devicetree, linux-kernel,
	linux-arm-kernel
In-Reply-To: <1484633521-10938-1-git-send-email-yuantian.tang@nxp.com>

On Tue, Jan 17, 2017 at 02:12:01PM +0800, yuantian.tang@nxp.com wrote:
> From: Tang Yuantian <Yuantian.Tang@nxp.com>
> 
> Ls2088a is new introduced arm-based soc with sata support with
> following features:
> 1. Complies with the serial ATA 3.0 specification and the AHCI 1.3.1
>    specification
> 2. Contains a high-speed descriptor-based DMA controller
> 3. Supports the following:
>    a. Speeds of 1.5 Gb/s (first-generation SATA), 3 Gb/s
>       (second-generation SATA), and 6 Gb/s (third-generation SATA)
>    b. FIS-based switching
>    c. Native command queuing (NCQ) commands
>    d. Port multiplier operation
>    e. Asynchronous notification
>    f. SATA BIST mode
> 
> Signed-off-by: Tang Yuantian <yuantian.tang@nxp.com>

Reverted due to build failure.  Did you even try to compile it before
submission?  We all make mistakes and that's fine but this one seems a
bit too careless.  Please don't do this.

Thanks.

-- 
tejun

^ permalink raw reply

* Re: [PATCH v4] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range
From: Kevin Hilman @ 2017-01-18 19:54 UTC (permalink / raw)
  To: Andreas Färber
  Cc: Neil Armstrong, Olof Johansson, devicetree@vger.kernel.org,
	xypron.glpk, linux-kernel@vger.kernel.org, Carlo Caione,
	linux-amlogic, linux-arm-kernel@lists.infradead.org
In-Reply-To: <04113569-e342-77ff-f79a-2c9c4dc4c602@suse.de>

Andreas Färber <afaerber@suse.de> writes:

> Hi Neil,
>
> Am 17.01.2017 um 09:21 schrieb Neil Armstrong:
>> As I finally understand, the real issue here is the usage of the "linux,useable-memory" property that
>> overrides the reg property that is changed by the bootloader to provide the "real" memory size.
>
> Yes, exactly. It assured that 0..0x01000000 was always unavailable, as
> intended, but at the same time it ignored any lowered or heightened
> upper limit coming from the bootloader side.
>
> As a rule of thumb, any nodes that have device_type set can be expected
> to be modified during boot.
>
>> As I understand the mainline U-Boot does it right, and it's a good news, and it seems uEFI need to provide
>> some specialized memory range aswell, but the vendor U-Boot versions only provide the full memory range here.
>> It seems obvious that whatever range is provided by u-boot, the first 16MiB should be reserved.
>> 
>> The stress-ng package provides this "stress" command and is used to force the kernel to map more memory
>> zones,
>
> Thanks, its binary is called stress-ng in openSUSE Tumbleweed. ;)
>
>> but I also got the issue while running a fully fledged Desktop Environment thanks to the
>> recently merged DRM driver.
>
> I'll happily test once HDMI is ready. :)
>
>> You may not be able to trigger the issue since it seems Amlogic reduces this reserved size on GXL/GXM :
>> https://github.com/khadas/linux/commit/698df2c6cfbb0d1a9359743208e83517b31da6ce
>> But it should be confirmed.
>
> Confirming no issues on three runs on meson-gxm-rbox-pro:
>
> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s &
> [1] 2528
> boxer:~ # stress-ng: info:  [2528] dispatching hogs: 4 vm
> stress-ng: info:  [2528] cache allocate: default cache size: 256K
> stress-ng: info:  [2528] successful run completed in 10.07s
>
> [1]+  Done                    stress-ng --vm 4 --vm-bytes 128M --timeout 10s
> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s
> stress-ng: info:  [2537] dispatching hogs: 4 vm
> stress-ng: info:  [2537] cache allocate: default cache size: 256K
> stress-ng: info:  [2537] successful run completed in 10.07s
> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s
> stress-ng: info:  [2546] dispatching hogs: 4 vm
> stress-ng: info:  [2546] cache allocate: default cache size: 256K
> stress-ng: info:  [2546] successful run completed in 10.07s
> boxer:~ #
>
>> Kevin asked me initially to handle this "start of ddr" reserved zone via a reserved-memory entry, but
>> at that time it seemed a better idea to use "linux,useable-memory", but I recon it may be an error.
>> 
>> I will push a v5 with a supplementary reserved-memory entry and will postpone the boards memory size
>> fixup for a future DTS cleanup.
>> 
>> Andreas, is this ok for you ?
>
> Yes, sounds fine to me, thanks. I'll note a few more nits to consider.
>
> Kevin, I noticed that this supposedly applied patch did not show up in
> linux-next for testing - could you merge your fixes branch into for-next
> please for those of us working on new stuff?

Any fixes I have queued are always in my for-mext branch (which is
included i linux-next.)

This fix was there as well, but was removed due to objections shortly
after I added it, so it never quite made it to linux-next (or may have
for one day, I'm not sure.)

Kevin

^ permalink raw reply

* Re: [PATCH 1/3] DT/bindings: Add bindings for TI ADS7950 A/DC chips
From: Rob Herring @ 2017-01-18 19:54 UTC (permalink / raw)
  To: David Lechner
  Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-iio-u79uwXL29TY76Z2rM5mHXA, Jonathan Cameron,
	Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
	Mark Rutland, linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1484157171-15571-2-git-send-email-david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>

On Wed, Jan 11, 2017 at 11:52:49AM -0600, David Lechner wrote:
> This adds device tree bindings for the TI ADS7950 family of A/DC chips.
> 
> Signed-off-by: David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
> ---
>  .../devicetree/bindings/iio/adc/ti-ads7950.txt     | 23 ++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/adc/ti-ads7950.txt

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

^ permalink raw reply

* Re: [PATCH v2 2/3] dt-bindings: Input: Add optional amp-supply property to pwm-beeper
From: Rob Herring @ 2017-01-18 19:58 UTC (permalink / raw)
  To: David Lechner
  Cc: linux-input-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Dmitry Torokhov, Mark Rutland,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1484164921-30587-3-git-send-email-david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>

On Wed, Jan 11, 2017 at 02:02:00PM -0600, David Lechner wrote:
> This adds an optional amp-supply property to pwm-beeper. This is a
> regulator that acts as an amplifier for the beeper.
> 
> Signed-off-by: David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
> ---
>  Documentation/devicetree/bindings/input/pwm-beeper.txt | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@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 v2 1/2] dt-bindings: usb: add DT binding for s3c2410 USB device controller
From: Rob Herring @ 2017-01-18 20:08 UTC (permalink / raw)
  To: Sergio Prado
  Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, mark.rutland-5wv7dgnIgG8,
	balbi-DgEjT+Ai2ygdnm+yROfE0A, linux-usb-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1484172150-32075-2-git-send-email-sergio.prado-1e4yhPs3/ABSwrhanM7KvQ@public.gmane.org>

On Wed, Jan 11, 2017 at 08:02:29PM -0200, Sergio Prado wrote:
> Adds the device tree bindings description for Samsung S3C2410 and
> compatible USB device controller.
> 
> Signed-off-by: Sergio Prado <sergio.prado-1e4yhPs3/ABSwrhanM7KvQ@public.gmane.org>
> ---
>  .../devicetree/bindings/usb/s3c2410-usb.txt        | 28 ++++++++++++++++++++++
>  1 file changed, 28 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/s3c2410-usb.txt b/Documentation/devicetree/bindings/usb/s3c2410-usb.txt
> index e45b38ce2986..28353eea31fd 100644
> --- a/Documentation/devicetree/bindings/usb/s3c2410-usb.txt
> +++ b/Documentation/devicetree/bindings/usb/s3c2410-usb.txt
> @@ -20,3 +20,31 @@ usb0: ohci@49000000 {
>  	clocks = <&clocks UCLK>, <&clocks HCLK_USBH>;
>  	clock-names = "usb-bus-host", "usb-host";
>  };
> +
> +Samsung S3C2410 and compatible USB device controller
> +
> +Required properties:
> + - compatible: Should be one of the following
> +	       "samsung,s3c2410-udc"
> +	       "samsung,s3c2440-udc"
> + - reg: address and length of the controller memory mapped region
> + - interrupts: interrupt number for the USB device controller
> + - clocks: Should reference the bus and host clocks
> + - clock-names: Should contain two strings
> +		"uclk" for the USB bus clock
> +		"usb-device" for the USB device clock

Perhaps just "bus" and "device".

> +
> +Optional properties:
> + - samsung,vbus-gpio: specifies a gpio that allows to detect whether
> +   vbus is present - USB is connected (active high, input).
> + - samsung,pullup-gpio: If present, specifies a gpio to control the
> +   USB D+ pullup (active high, output).

"-gpios", not "-gpio" is preferred.

These should be common property names if we're going to have them. The 
problem with just "vbus-gpios" is does that mean an enable control or 
status as you have. I guess in the former case, that should always be 
modeled as a regulator.

Also, these should all be part of a connector node as these controls are 
more related to the USB connector than the controller. And I don't mean 
extcon here because those bindings are a mess.

Rob
--
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 V2 1/4] clk: gcc: Updates for SDHCI enablement
From: Jeremy McNicoll @ 2017-01-18 20:14 UTC (permalink / raw)
  To: Stephen Boyd, Jeremy McNicoll
  Cc: linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
	linux-soc-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-mmc-u79uwXL29TY76Z2rM5mHXA,
	andy.gross-QSEj5FYQhm4dnm+yROfE0A, robh-DgEjT+Ai2ygdnm+yROfE0A,
	arnd-r2nGTMty4D4, bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
	riteshh-sgV2jX0FEOL9JmXXK+q4OQ, git-LJ92rlH3Dns,
	ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
	jszhang-eYqpPyKDWXRBDgjK7y7TUQ
In-Reply-To: <20170117232542.GV17126-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>

On 2017-01-17 6:25 PM, Stephen Boyd wrote:
> On 01/16, Jeremy McNicoll wrote:
>> Global clock updates to enable onboard SDHCI / MMC.
>> Re-tabify dt-bindings to align correctly in vim.
>
> We need much more words here on what's going on in this patch.
>

Reword and redo alot of this.  Thanks for the clarifications and answers
on IRC.

-jeremy

--
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: [RFC v2 1/5] UDC: Split the driver into amd (pci) and Synopsys core driver
From: Greg Kroah-Hartman @ 2017-01-18 20:18 UTC (permalink / raw)
  To: Florian Fainelli
  Cc: Raviteja Garimella, Rob Herring, Mark Rutland, Felipe Balbi,
	devicetree, linux-kernel, bcm-kernel-feedback-list, linux-usb
In-Reply-To: <e1453122-164a-e1a8-6aa6-fb25eb33101f@gmail.com>

On Wed, Jan 18, 2017 at 10:45:39AM -0800, Florian Fainelli wrote:
> On 01/17/2017 12:05 AM, Raviteja Garimella wrote:
> > This patch splits the amd5536udc driver into two -- one that does
> > pci device registration and the other file that does the rest of
> > the driver tasks like the gadget/ep ops etc for Synopsys UDC.
> > 
> > This way of splitting helps in exporting core driver symbols which
> > can be used by any other platform/pci driver that is written for
> > the same Synopsys USB device controller.
> > 
> > The current patch also includes a change in the Kconfig and Makefile.
> > A new config option USB_SNP_CORE will be selected automatically when
> > any one of the platform or pci driver for the same UDC is selected.
> > 
> > Signed-off-by: Raviteja Garimella <raviteja.garimella@broadcom.com>
> 
> Although the changes you have done make sense and it is most certainly a
> good idea to split udc core from bus specific glue logic, it is really
> hard to review the changes per-se because of the file rename, could that
> happen at a later time?
> 
> Also, keep in mind that anytime a driver file is renamed, this poses a
> backport/maintenance issue where backporting fixes from latest upstream
> to a kernel version that has a different file/directory structure is a
> major pain.

Don't ever let stable tree work prevent you from doing the right thing.
If this needs to be split, wonderful, stable kernel work will just have
to deal with it.  Hint, we handle it all the time just fine :)

thanks,

greg k-h

^ permalink raw reply

* Re: [PATCH v13 2/5] tee: generic TEE subsystem
From: Arnd Bergmann @ 2017-01-18 20:19 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: valentin.manea, devicetree, javier, emmanuel.michel,
	Greg Kroah-Hartman, Michal Simek, Mark Rutland, Will Deacon,
	linux-kernel, Wei Xu, Nishanth Menon, Jason Gunthorpe,
	Rob Herring, broonie, Al Viro, Andrew F. Davis, Olof Johansson,
	Andrew Morton, jean-michel.delorme, Jens Wiklander
In-Reply-To: <1479480700-554-3-git-send-email-jens.wiklander@linaro.org>

On Friday, November 18, 2016 3:51:37 PM CET Jens Wiklander wrote:
> Initial patch for generic TEE subsystem.
> This subsystem provides:
> * Registration/un-registration of TEE drivers.
> * Shared memory between normal world and secure world.
> * Ioctl interface for interaction with user space.
> * Sysfs implementation_id of TEE driver
> 
> A TEE (Trusted Execution Environment) driver is a driver that interfaces
> with a trusted OS running in some secure environment, for example,
> TrustZone on ARM cpus, or a separate secure co-processor etc.
> 
> The TEE subsystem can serve a TEE driver for a Global Platform compliant
> TEE, but it's not limited to only Global Platform TEEs.
> 
> This patch builds on other similar implementations trying to solve
> the same problem:
> * "optee_linuxdriver" by among others
>   Jean-michel DELORME<jean-michel.delorme@st.com> and
>   Emmanuel MICHEL <emmanuel.michel@st.com>
> * "Generic TrustZone Driver" by Javier González <javier@javigon.com>

Can you give an example for a system that would contain more than one
TEE? I see that you support dynamic registration, and it's clear that
there can be more than one type of TEE, but why would one have more
than one at a time, and why not more than 32?

> +static int tee_ioctl_invoke(struct tee_context *ctx,
> +			    struct tee_ioctl_buf_data __user *ubuf)
> +{
> +	int rc;
> +	size_t n;
> +	struct tee_ioctl_buf_data buf;
> +	struct tee_ioctl_invoke_arg __user *uarg;
> +	struct tee_ioctl_invoke_arg arg;
> +	struct tee_ioctl_param __user *uparams = NULL;
> +	struct tee_param *params = NULL;
> +
> +	if (!ctx->teedev->desc->ops->invoke_func)
> +		return -EINVAL;
> +
> +	if (copy_from_user(&buf, ubuf, sizeof(buf)))
> +		return -EFAULT;
> +
> +	if (buf.buf_len > TEE_MAX_ARG_SIZE ||
> +	    buf.buf_len < sizeof(struct tee_ioctl_invoke_arg))
> +		return -EINVAL;
> +
> +	uarg = (struct tee_ioctl_invoke_arg __user *)(unsigned long)buf.buf_ptr;

u64_to_user_ptr()

> +	if (copy_from_user(&arg, uarg, sizeof(arg)))
> +		return -EFAULT;
> +
> +	if (sizeof(arg) + TEE_IOCTL_PARAM_SIZE(arg.num_params) != buf.buf_len)
> +		return -EINVAL;
> +
> +	if (arg.num_params) {
> +		params = kcalloc(arg.num_params, sizeof(struct tee_param),
> +				 GFP_KERNEL);
> +		if (!params)
> +			return -ENOMEM;

It would be good to have an upper bound on the number of parameters
to limit the size of the memory allocation here.

> +int tee_device_register(struct tee_device *teedev)
> +{
> +	int rc;
> +
> +	/*
> +	 * If the teedev already is registered, don't do it again. It's
> +	 * obviously an error to try to register twice, but if we return
> +	 * an error we'll force the driver to remove the teedev.
> +	 */
> +	if (teedev->flags & TEE_DEVICE_FLAG_REGISTERED) {
> +		dev_err(&teedev->dev, "attempt to register twice\n");
> +		return 0;
> +	}

I don't understand what you are protecting against here.
How would we get to this function twice for the same device?

Could you change the caller so it doesn't happen?

> +/**
> + * struct tee_ioctl_param - parameter
> + * @attr: attributes
> + * @memref: a memory reference
> + * @value: a value
> + *
> + * @attr & TEE_PARAM_ATTR_TYPE_MASK indicates if memref or value is used in
> + * the union. TEE_PARAM_ATTR_TYPE_VALUE_* indicates value and
> + * TEE_PARAM_ATTR_TYPE_MEMREF_* indicates memref. TEE_PARAM_ATTR_TYPE_NONE
> + * indicates that none of the members are used.
> + */
> +struct tee_ioctl_param {
> +	__u64 attr;
> +	union {
> +		struct tee_ioctl_param_memref memref;
> +		struct tee_ioctl_param_value value;
> +	} u;
> +};
> +
> +#define TEE_IOCTL_UUID_LEN		16
> +

Having a union in an ioctl argument seems odd. Have you considered
using two different ioctl command numbers depending on the type?

> +/**
> + * struct tee_iocl_supp_send_arg - Send a response to a received request
> + * @ret:	[out] return value
> + * @num_params	[in] number of parameters following this struct
> + */
> +struct tee_iocl_supp_send_arg {
> +	__u32 ret;
> +	__u32 num_params;
> +	/*
> +	 * this struct is 8 byte aligned since the 'struct tee_ioctl_param'
> +	 * which follows requires 8 byte alignment.
> +	 *
> +	 * Commented out element used to visualize the layout dynamic part
> +	 * of the struct. This field is not available at all if
> +	 * num_params == 0.
> +	 *
> +	 * struct tee_ioctl_param params[num_params];
> +	 */
> +} __aligned(8);

I'd make that 

	struct tee_ioctl_param params[0];

as wel here, as I also commented in patch 3 that has a similar structure.

	Arnd

^ permalink raw reply

* Re: [PATCH] of: Export of_node_ktype
From: Frank Rowand @ 2017-01-18 20:30 UTC (permalink / raw)
  To: Alexander Sverdlin; +Cc: Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170118093733.32152-1-alexander.sverdlin-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>

Hi Alexander,

On 01/18/17 01:37, Alexander Sverdlin wrote:
> This is necessary for of_node_init() to work in the modules.
> 
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> ---
>  drivers/of/base.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index d4bea3c797d6..2eb4dea62b84 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -106,6 +106,7 @@ static void of_node_release(struct kobject *kobj)
>  struct kobj_type of_node_ktype = {
>  	.release = of_node_release,
>  };
> +EXPORT_SYMBOL_GPL(of_node_ktype);
>  
>  static ssize_t of_node_property_read(struct file *filp, struct kobject *kobj,
>  				struct bin_attribute *bin_attr, char *buf,
> 

Why does your module need to call of_node_init() directly?

Thanks,

Frank
--
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 1/4] Documentation: dt: mailbox: Add Aspeed ast2400/2500 bindings
From: Rob Herring @ 2017-01-18 20:38 UTC (permalink / raw)
  To: Cyril Bur
  Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
	jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w, arnd-r2nGTMty4D4,
	gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
	joel-U3u1mxZcP9KHXe+LvDLADg, mark.rutland-5wv7dgnIgG8,
	openbmc-uLR06cmDAlY/bJ5BZ2RsiQ, andrew-zrmu5oMJ5Fs,
	benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r, xow-hpIqsD4AKlfQT0dZR+AlfA,
	jk-mnsaURCQ41sdnm+yROfE0A
In-Reply-To: <20170112002910.3650-2-cyrilbur-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

On Thu, Jan 12, 2017 at 11:29:07AM +1100, Cyril Bur wrote:
> Signed-off-by: Cyril Bur <cyrilbur-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
>  .../devicetree/bindings/mailbox/aspeed-mbox.txt    | 44 ++++++++++++++++++++++
>  1 file changed, 44 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mailbox/aspeed-mbox.txt
> 
> diff --git a/Documentation/devicetree/bindings/mailbox/aspeed-mbox.txt b/Documentation/devicetree/bindings/mailbox/aspeed-mbox.txt
> new file mode 100644
> index 000000000000..633cd534d91c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/aspeed-mbox.txt
> @@ -0,0 +1,44 @@
> +ASpeed Mailbox Driver
> +=====================
> +
> +The ASpeed mailbox allows for communication between different
> +processors. The mailbox on the ASpeed ast2400 and ast2500 is a set of
> +16 single byte data registers along with interrupt and configuration
> +registers directly on the SoC. These are memory mapped on the aspeed
> +and can be accessed via the SuperIO registers on the other processor.
> +
> +Device Node:
> +============
> +This represents the mailbox on the Soc.
> +
> +As the mailbox registers sit on the LPC bus, it makes most sense for
> +the device to be within the LPC host node. See
> +Documentation/devicetree/bindings/mfd/aspeed-lpc.txt for more
> +information. This does not have to be the case, provided the reg
> +property can give the full address of the mbox registers.

This does have to be the case. I'd expect all devices on the LPC bus to 
be under a LPC bus node.

Drop the last sentence, and:

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@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 v9 2/5] i2c: Add STM32F4 I2C driver
From: M'boumba Cedric Madianga @ 2017-01-18 20:55 UTC (permalink / raw)
  To: Uwe Kleine-König
  Cc: devicetree, Alexandre Torgue, Wolfram Sang, linux-kernel,
	Linus Walleij, Patrice Chotard, Russell King, Rob Herring,
	linux-i2c, Maxime Coquelin, linux-arm-kernel
In-Reply-To: <20170118184237.tvhlsksdcw2ckwan@pengutronix.de>

2017-01-18 19:42 GMT+01:00 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
> Hello Cedric,
>
> On Wed, Jan 18, 2017 at 04:21:17PM +0100, M'boumba Cedric Madianga wrote:
>> >> +      * In standard mode, the maximum allowed SCL rise time is 1000 ns.
>> >> +      * If, in the I2C_CR2 register, the value of FREQ[5:0] bits is equal to
>> >> +      * 0x08 so period = 125 ns therefore the TRISE[5:0] bits must be
>> >> +      * programmed with 09h.(1000 ns / 125 ns = 8 + 1)
>> >
>> >         * programmed with 0x9.
>> > (1000 ns / 125 ns = 8)
>> >
>> >> +      * So, for I2C standard mode TRISE = FREQ[5:0] + 1
>> >> +      *
>> >> +      * In fast mode, the maximum allowed SCL rise time is 300 ns.
>> >> +      * If, in the I2C_CR2 register, the value of FREQ[5:0] bits is equal to
>> >> +      * 0x08 so period = 125 ns therefore the TRISE[5:0] bits must be
>> >> +      * programmed with 03h.(300 ns / 125 ns = 2 + 1)
>> >
>> > as above s/03h/0x3/;
>>
>> ok
>>
>> > s/.(/. (/;
>> ok
>>
>> > s/+ 1//;
>> This formula is use to understand how we find the result 0x3
>> So, 0x3 => 300 ns / 125ns = 2 + 1
>
> Yeah, I understood that, but writing 300 ns / 125ns = 2 + 1 is
> irritating at best.

Ok. I will write 0x3 (300 ns / 125 ns + 1) and 0x9 (1000 ns / 125 ns + 1)

>> >         [...]
>> >         If DUTY = 1: (to reach 400 kHz)
>> >
>> > Strange.
>> >
>> >> +             val = DIV_ROUND_UP(i2c_dev->parent_rate, 400000 * 3);
>> >
>> > the manual reads:
>> >
>> >         The minimum allowed value is 0x04, except in FAST DUTY mode
>> >         where the minimum allowed value is 0x01
>> >
>> > You don't check for that, right?
>>
>> As the minimum freq value is 6 Mhz in fast mode the minimum CCR is 5
>> as described in the comment.
>> So I don't need to check that again as it is already done by checking
>> parent frequency.
>
> That would then go into a comment.

Is it really needed ?
Adding some comments to explain implementation choices or  hardware
way of working is clearly useful.
But for this kind of thing, I am really surprised...

>
>> > CCR is 11 bits wide. A comment confirming that this cannot overflow
>> > would be nice.
>>
>> Again there is no chance of overflow thanks to parent frequency check
>
> Right, this time I saw this myself, so I requested a comment stating
> this fact.

ditto

Best regards,
Cedric

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 1/2] input: touchscreen: add driver for Zeitec ZET6223
From: Jelle van der Waa @ 2017-01-18 20:57 UTC (permalink / raw)
  To: Dmitry Torokhov
  Cc: Rob Herring, linux-input-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170114191425.GA31309@dtor-ws>

On 01/14/17 at 11:14am, Dmitry Torokhov wrote:
> > +
> > +static const struct of_device_id zet6223_of_match[] = {
> > +	{ .compatible = "zeitec", "zet6223" },
> 
> The compatible should be "zeitec,zet6223", what you have here is
> equivalent of:
> 
> 	{ .compatible = "zeitec", .data = "zet6223" },

Ah that was silly, thanks :)

> I also have been looking at you previosu submission and had some draft
> changes. I reconciled them in the patch below, if it still works for you
> then I'll fold everything together and apply. Please let me know.

I'll find some time to test the patch below, I've one small suggestion
to the patch below.

> +	ts->fingernum = buf[15] & 0x7F;
> +	if (ts->fingernum > ZET6223_MAX_FINGERS) {
> +		dev_warn(&ts->client->dev,
> +			 "touchpanel reports %d fingers, limiting to %d\n",
> +			 ts->fingernum, ZET6223_MAX_FINGERS);
> +		ts->fingernum = 16;

Maybe use ZET6223_MAX_FINGERS?

-- 
Jelle van der Waa
--
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 V7 1/4] Documentation/devicetree/bindings: b850v3_lvds_dp
From: Laurent Pinchart @ 2017-01-18 21:10 UTC (permalink / raw)
  To: Peter Senna Tschudin
  Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Peter Senna Tschudin,
	Rob Herring, Mark Rutland, Daniel Vetter, Peter Senna Tschudin,
	Takashi Iwai, Yakir Yang, Jiri Slaby, Martyn Welch, Ian Campbell,
	Russell King, Javier Martinez Canillas, Thierry Reding,
	Guenter Roeck, martin.donnelly-JJi787mZWgc,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Pawel Moll,
	Mauro Carvalho Chehab, enric.balletb
In-Reply-To: <20170116083711.GA18775-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>

Hi Peter,

On Monday 16 Jan 2017 09:37:11 Peter Senna Tschudin wrote:
> On Tue, Jan 10, 2017 at 11:04:58PM +0200, Laurent Pinchart wrote:
> > On Saturday 07 Jan 2017 01:29:52 Peter Senna Tschudin wrote:
> >> On 04 January, 2017 21:39 CET, Rob Herring wrote:
> >>> On Tue, Jan 3, 2017 at 5:34 PM, Peter Senna Tschudin wrote:
> >>>> On 03 January, 2017 23:51 CET, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> >>>>> On Sun, Jan 01, 2017 at 09:24:29PM +0100, Peter Senna Tschudin wrote:
> >>>>>> Devicetree bindings documentation for the GE B850v3 LVDS/DP++
> >>>>>> display bridge.
> >>>>>> 
> >>>>>> Cc: Martyn Welch <martyn.welch-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
> >>>>>> Cc: Martin Donnelly <martin.donnelly-JJi787mZWgc@public.gmane.org>
> >>>>>> Cc: Javier Martinez Canillas <javier-0uQlZySMnqxg9hUCZPvPmw@public.gmane.org>
> >>>>>> Cc: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
> >>>>>> Cc: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> >>>>>> Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >>>>>> Cc: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
> >>>>>> Signed-off-by: Peter Senna Tschudin <peter.senna-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
> >>>>>> ---
> >>>>>> There was an Acked-by from Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> for V6,
> >>>>>> but I changed the bindings to use i2c_new_secondary_device() so I
> >>>>>> removed it from the commit message.
> >>>>>> 
> >>>>>>  .../devicetree/bindings/ge/b850v3-lvds-dp.txt      | 39 +++++++++++
> >>>>> 
> >>>>> Generally, bindings are not organized by vendor. Put in
> >>>>> bindings/display/bridge/... instead.
> >>>> 
> >>>> Will change that.
> >>>> 
> >>>>>>  1 file changed, 39 insertions(+)
> >>>>>>  create mode 100644
> >>>>>>  Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
> >>>>>> 
> >>>>>> diff --git
> >>>>>> a/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
> >>>>>> b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt new file
> >>>>>> mode 100644
> >>>>>> index 0000000..1bc6ebf
> >>>>>> --- /dev/null
> >>>>>> +++ b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
> >>>>>> @@ -0,0 +1,39 @@
> >>>>>> +Driver for GE B850v3 LVDS/DP++ display bridge
> >>>>>> +
> >>>>>> +Required properties:
> >>>>>> +  - compatible : should be "ge,b850v3-lvds-dp".
> >>>>> 
> >>>>> Isn't '-lvds-dp' redundant? The part# should be enough.
> >>>> 
> >>>> b850v3 is the name of the product, this is why the proposed name.
> >>>> What about, b850v3-dp2 dp2 indicating the second DP output?
> >>> 
> >>> Humm, b850v3 is the board name? This node should be the name of the
> >>> bridge chip.
> >> 
> >> From the cover letter:
> >> 
> >> -- // --
> >> There are two physical bridges on the video signal pipeline: a
> >> STDP4028(LVDS to DP) and a STDP2690(DP to DP++).  The hardware and
> >> firmware made it complicated for this binding to comprise two device
> >> tree nodes, as the design goal is to configure both bridges based on
> >> the LVDS signal, which leave the driver powerless to control the video
> >> processing pipeline. The two bridges behaves as a single bridge, and
> >> the driver is only needed for telling the host about EDID / HPD, and
> >> for giving the host powers to ack interrupts. The video signal pipeline
> >> is as follows:
> >>   Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video
> >>   output
> >> -- // --
> > 
> > You forgot to prefix your patch series with [HACK] ;-)
> > 
> > How about fixing the issues that make the two DT nodes solution difficult
> > ? What are they ?
> 
> The Firmware and the hardware design. Both bridges, with stock firmware,
> are fully capable of providig EDID information and handling interrupts.
> But on this specific design, with this specific firmware, I need to read
> EDID from one bridge, and handle interrupts on the other.

Which firmware are you talking about ? Firmware running on the bridges, or 
somewhere else ?

> Back when I was starting the development I could not come up with a proper
> way to split EDID and interrupts between two bridges in a way that would
> result in a fully functional connector. Did I miss something?

You didn't, we did :-) I've been telling for quite some time now that we must 
decouple bridges from connectors, and this is another example of why we have 
such a need. Bridges should expose additional functions needed to implement 
connector operations, and the connector should be instantiated by the display 
driver with the help of bridge operations. You could then create a connector 
that relies on one bridge to read the EDID and on the other bridge to handle 
HPD.

-- 
Regards,

Laurent Pinchart

--
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 2/4] Documentation: dt: misc: Add Aspeed ast2400/2500 LPC Control bindings
From: Rob Herring @ 2017-01-18 21:16 UTC (permalink / raw)
  To: Cyril Bur
  Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
	jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w, arnd-r2nGTMty4D4,
	gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
	joel-U3u1mxZcP9KHXe+LvDLADg, mark.rutland-5wv7dgnIgG8,
	openbmc-uLR06cmDAlY/bJ5BZ2RsiQ, andrew-zrmu5oMJ5Fs,
	benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r, xow-hpIqsD4AKlfQT0dZR+AlfA,
	jk-mnsaURCQ41sdnm+yROfE0A
In-Reply-To: <20170112002910.3650-3-cyrilbur-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

On Thu, Jan 12, 2017 at 11:29:08AM +1100, Cyril Bur wrote:
> Signed-off-by: Cyril Bur <cyrilbur-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
>  .../devicetree/bindings/misc/aspeed-lpc-ctrl.txt   | 78 ++++++++++++++++++++++
>  1 file changed, 78 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/misc/aspeed-lpc-ctrl.txt
> 
> diff --git a/Documentation/devicetree/bindings/misc/aspeed-lpc-ctrl.txt b/Documentation/devicetree/bindings/misc/aspeed-lpc-ctrl.txt
> new file mode 100644
> index 000000000000..f84ac83211ec
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/aspeed-lpc-ctrl.txt
> @@ -0,0 +1,78 @@
> +ASpeed LPC Control
> +==================
> +This binding defines the LPC control for ASpeed SoCs. Partitions of
> +the LPC bus can be access by other processors on the system, address
> +ranges on the bus can map accesses from another processor to regions
> +of the ASpeed SoC memory space.
> +
> +Reserved Memory:
> +================
> +The driver provides functionality to map the LPC bus to a region of
> +ASpeed ram. A phandle to a reserved memory node must be provided so
> +that the driver can safely use this region.
> +
> +Flash:
> +======
> +The driver provides functionality to unmap the LPC bus from ASpeed
> +RAM, historically the default mapping has been to the SPI flash
> +controller on the ASpeed SoC, a phandle to this node should be
> +supplied.
> +
> +Device Node:
> +============
> +
> +As LPC bus configuration registers are at the start of the LPC bus
> +memory space, it makes most sense for the device to be within the LPC
> +host node. See Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> +for more information. This does not have to be the case, provided the
> +reg property can give the full address of the LPC bus.

Same comment here.

> +
> +Required properties:
> +--------------------
> +
> +- compatible:		"aspeed,ast2400-lpc-ctrl" for ASpeed ast2400 SoCs
> +					"aspeed,ast2500-lpc-ctrl" for ASpeed ast2500 SoCs
> +
> +- reg:				Location and size of the configuration registers
> +					for the LPC bus. Note that if the device node is
> +					within the LPC host node then base is relative to
> +					that.
> +
> +- memory-region:	phandle of the reserved memory region
> +- flash:			phandle of the SPI flash controller
> +
> +Example:
> +--------
> +
> +reserved-memory {
> +	#address-cells = <1>;
> +	#size-cells = <1>;
> +	ranges;
> +
> +	...
> +
> +	flash_memory: region@54000000 {
> +		compatible = "aspeed,ast2400-lpc-ctrl";

This doesn't look right?

> +		no-map;
> +		reg = <0x54000000 0x04000000>; /* 64M */

Is this system RAM? reserved-memory is generally for carveouts in system 
RAM (e.g. the memory node).

> +	};
> +};
> +
> +host_pnor: spi@1e630000 {
> +	reg = < 0x1e630000 0x18
> +			0x30000000 0x02000000 >;
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +	compatible = "aspeed,ast2400-smc";
> +
> +	...
> +
> +};
> +
> +lpc-ctrl@0 {
> +	compatible = "aspeed,ast2400-lpc-ctrl";
> +	memory-region = <&flash_memory>;
> +	flash = <&host_pnor>;
> +	reg = <0x0 0x80>;
> +};
> +
> -- 
> 2.11.0
> 
--
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 V2 1/2] clk: vc5: Add bindings for IDT VersaClock 5P49V5923 and 5P49V5933
From: Rob Herring @ 2017-01-18 21:28 UTC (permalink / raw)
  To: Marek Vasut
  Cc: linux-clk, Michael Turquette, Stephen Boyd, Laurent Pinchart,
	devicetree, linux-renesas-soc
In-Reply-To: <20170112010324.28068-1-marek.vasut@gmail.com>

On Thu, Jan 12, 2017 at 02:03:23AM +0100, Marek Vasut wrote:
> Add bindings for IDT VersaClock 5 5P49V5923 and 5P49V5933 chips.
> These are I2C clock generators with optional clock source from
> either XTal or dedicated clock generator and, depending on the
> model, two or more clock outputs.
> 
> Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Stephen Boyd <sboyd@codeaurora.org>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: linux-renesas-soc@vger.kernel.org
> ---
> V2: Add mapping between the clock specifier and physical pins of the chip
> ---
>  .../devicetree/bindings/clock/idt,versaclock5.txt  | 65 ++++++++++++++++++++++
>  1 file changed, 65 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/idt,versaclock5.txt

Acked-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* Re: [PATCH v3] mmc: sh_mmcif: Document r7s72100 DT bindings
From: Rob Herring @ 2017-01-18 21:30 UTC (permalink / raw)
  To: Chris Brandt
  Cc: Ulf Hansson, Mark Rutland, Geert Uytterhoeven, Simon Horman,
	devicetree, linux-renesas-soc
In-Reply-To: <20170112041452.14136-1-chris.brandt@renesas.com>

On Wed, Jan 11, 2017 at 11:14:52PM -0500, Chris Brandt wrote:
> Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
> 
> ---
> v3:
> * added list of how many interrupts each SOC has
> v2:
> * added interrupt description
> ---
>  Documentation/devicetree/bindings/mmc/renesas,mmcif.txt | 8 ++++++++
>  1 file changed, 8 insertions(+)

Acked-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* Re: [PATCH] of: Export __of_find_all_nodes()
From: Frank Rowand @ 2017-01-18 21:33 UTC (permalink / raw)
  To: Alexander Sverdlin; +Cc: Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170118093849.32204-1-alexander.sverdlin-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>

On 01/18/17 01:38, Alexander Sverdlin wrote:
> This is necessary for for_each_of_allnodes() to work in the modules.
> 
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> ---
>  drivers/of/base.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index 2eb4dea62b84..f576c33e0b84 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -270,6 +270,7 @@ struct device_node *__of_find_all_nodes(struct device_node *prev)
>  	}
>  	return np;
>  }
> +EXPORT_SYMBOL_GPL(__of_find_all_nodes);
>  
>  /**
>   * of_find_all_nodes - Get next node in global list
> 

Quoting Rob from the last request for this:

"What driver needs this? This isn't really a function I'd expect drivers to use."

-Frank
--
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 2/2] mmc: dt-bindings: update Mediatek MMC bindings
From: Rob Herring @ 2017-01-18 21:34 UTC (permalink / raw)
  To: Yong Mao
  Cc: Mark Rutland, devicetree, Ulf Hansson, Nicolas Boichat,
	srv_heupstream, Javier Martinez Canillas, Catalin Marinas,
	Will Deacon, Douglas Anderson, linux-kernel, Chunfeng Yun,
	linux-mediatek, linux-arm-kernel, Philipp Zabel,
	Greg Kroah-Hartman, Matthias Brugger, linux-mmc, Eddie Huang,
	Chaotian Jing
In-Reply-To: <1484215490-7494-3-git-send-email-yong.mao@mediatek.com>

On Thu, Jan 12, 2017 at 06:04:50PM +0800, Yong Mao wrote:
> From: yong mao <yong.mao@mediatek.com>
> 
> Add description for hs200-cmd-int-delay
> Add description for hs400-cmd-int-delay
> Add description for cmd-resp-sel
> 
> Signed-off-by: Yong Mao <yong.mao@mediatek.com>
> ---
>  Documentation/devicetree/bindings/mmc/mtk-sd.txt |    6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> index 0120c7f..2dbb3b0 100644
> --- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> @@ -21,6 +21,9 @@ Optional properties:
>  - assigned-clocks: PLL of the source clock
>  - assigned-clock-parents: parent of source clock, used for HS400 mode to get 400Mhz source clock
>  - hs400-ds-delay: HS400 DS delay setting
> +- hs200-cmd-int-delay: HS200 command internal delay setting
> +- hs400-cmd-int-delay: HS400 command internal delay setting

What are the units and range of values? These need vendor prefix as 
well.

> +- cmd-resp-sel: command response sample selection

Looks like a boolean. State that and make the default the more common 
case.

>  
>  Examples:
>  mmc0: mmc@11230000 {
> @@ -38,4 +41,7 @@ mmc0: mmc@11230000 {
>  	assigned-clocks = <&topckgen CLK_TOP_MSDC50_0_SEL>;
>  	assigned-clock-parents = <&topckgen CLK_TOP_MSDCPLL_D2>;
>  	hs400-ds-delay = <0x14015>;
> +	hs200-cmd-int-delay = <26>;
> +	hs400-cmd-int-delay = <14>;
> +	cmd-resp-sel = <0>; /* 0: rising, 1: falling */
>  };
> -- 
> 1.7.9.5
> 

^ permalink raw reply

* Re: [PATCH 25/37] dt-bindings: PCI: Add dt bindings for pci designware EP mode
From: Rob Herring @ 2017-01-18 21:36 UTC (permalink / raw)
  To: Kishon Vijay Abraham I
  Cc: devicetree, Joao Pinto, Arnd Bergmann, linux-doc, Jingoo Han,
	linux-arm-msm, nsekhar, linux-kernel, linux-arm-kernel,
	linux-samsung-soc, linux-pci, Bjorn Helgaas, linux-omap,
	linuxppc-dev, linux-arm-kernel
In-Reply-To: <1484216786-17292-26-git-send-email-kishon@ti.com>

On Thu, Jan 12, 2017 at 03:56:14PM +0530, Kishon Vijay Abraham I wrote:
> Add device tree binding documentation for pci designware EP mode.
> 
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
>  .../devicetree/bindings/pci/designware-pcie.txt    |   26 ++++++++++++++------
>  1 file changed, 18 insertions(+), 8 deletions(-)

Acked-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* Re: [PATCH 1/2] pinctrl: meson: fix uart_ao_b for GXBB and GXL/GXM
From: Kevin Hilman @ 2017-01-18 21:40 UTC (permalink / raw)
  To: Martin Blumenstingl
  Cc: linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-gpio-u79uwXL29TY76Z2rM5mHXA,
	linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	carlo-KA+7E9HrN00dnm+yROfE0A, will.deacon-5wv7dgnIgG8,
	catalin.marinas-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <20170115222029.8271-2-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>

Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> writes:

> The GXBB and GXL/GXM pinctrl drivers had a configuration which conflicts
> with uart_ao_a. According to the GXBB ("S905") datasheet the AO UART
> functions are:
> - GPIOAO_0: Func1 = UART_TX_AO_A (bit 12), Func2 = UART_TX_AO_B (bit 26)
> - GPIOAO_1: Func1 = UART_RX_AO_A (bit 11), Func2 = UART_RX_AO_B (bit 25)
> - GPIOAO_4: Func2 = UART_TX_AO_B (bit 24)
> - GPIOAO_5: Func2 = UART_RX_AO_B (bit 25)
>
> The existing definition for uart_AO_A already uses GPIOAO_0 and GPIOAO_1.
> The old definition of uart_AO_B however was broken, as it used GPIOAO_0
> for TX (which would be fine) and two pins (GPIOAO_1 and GPIOAO_5) for RX
> (which does not make any sense).
>
> This fixes the uart_AO_B configuration by moving it to GPIOAO_4 and
> GPIOAO_5 (it would be possible to use GPIOAO_0 and GPIOAO_1 in theory,
> but all existing hardware uses uart_AO_A there).
> The fix for GXBB and GXL/GXM is identical since it seems that these
> specific pins are identical on both SoC variants.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>

Reviewed-by: Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>

> ---
>  drivers/pinctrl/meson/pinctrl-meson-gxbb.c | 7 +++----
>  drivers/pinctrl/meson/pinctrl-meson-gxl.c  | 7 +++----
>  2 files changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/pinctrl/meson/pinctrl-meson-gxbb.c b/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
> index c3928aa3fefa..e0bca4df2a2f 100644
> --- a/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
> +++ b/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
> @@ -253,9 +253,8 @@ static const unsigned int uart_tx_ao_a_pins[]	= { PIN(GPIOAO_0, 0) };
>  static const unsigned int uart_rx_ao_a_pins[]	= { PIN(GPIOAO_1, 0) };
>  static const unsigned int uart_cts_ao_a_pins[]	= { PIN(GPIOAO_2, 0) };
>  static const unsigned int uart_rts_ao_a_pins[]	= { PIN(GPIOAO_3, 0) };
> -static const unsigned int uart_tx_ao_b_pins[]	= { PIN(GPIOAO_0, 0) };
> -static const unsigned int uart_rx_ao_b_pins[]	= { PIN(GPIOAO_1, 0),
> -						    PIN(GPIOAO_5, 0) };
> +static const unsigned int uart_tx_ao_b_pins[]	= { PIN(GPIOAO_4, 0) };
> +static const unsigned int uart_rx_ao_b_pins[]	= { PIN(GPIOAO_5, 0) };
>  static const unsigned int uart_cts_ao_b_pins[]	= { PIN(GPIOAO_2, 0) };
>  static const unsigned int uart_rts_ao_b_pins[]	= { PIN(GPIOAO_3, 0) };
>  
> @@ -498,7 +497,7 @@ static struct meson_pmx_group meson_gxbb_aobus_groups[] = {
>  	GPIO_GROUP(GPIOAO_13, 0),
>  
>  	/* bank AO */
> -	GROUP(uart_tx_ao_b,	0,	26),
> +	GROUP(uart_tx_ao_b,	0,	24),
>  	GROUP(uart_rx_ao_b,	0,	25),
>  	GROUP(uart_tx_ao_a,	0,	12),
>  	GROUP(uart_rx_ao_a,	0,	11),
> diff --git a/drivers/pinctrl/meson/pinctrl-meson-gxl.c b/drivers/pinctrl/meson/pinctrl-meson-gxl.c
> index 25694f7094c7..b69743b07a1d 100644
> --- a/drivers/pinctrl/meson/pinctrl-meson-gxl.c
> +++ b/drivers/pinctrl/meson/pinctrl-meson-gxl.c
> @@ -214,9 +214,8 @@ static const unsigned int uart_tx_ao_a_pins[]	= { PIN(GPIOAO_0, 0) };
>  static const unsigned int uart_rx_ao_a_pins[]	= { PIN(GPIOAO_1, 0) };
>  static const unsigned int uart_cts_ao_a_pins[]	= { PIN(GPIOAO_2, 0) };
>  static const unsigned int uart_rts_ao_a_pins[]	= { PIN(GPIOAO_3, 0) };
> -static const unsigned int uart_tx_ao_b_pins[]	= { PIN(GPIOAO_0, 0) };
> -static const unsigned int uart_rx_ao_b_pins[]	= { PIN(GPIOAO_1, 0),
> -						    PIN(GPIOAO_5, 0) };
> +static const unsigned int uart_tx_ao_b_pins[]	= { PIN(GPIOAO_4, 0) };
> +static const unsigned int uart_rx_ao_b_pins[]	= { PIN(GPIOAO_5, 0) };
>  static const unsigned int uart_cts_ao_b_pins[]	= { PIN(GPIOAO_2, 0) };
>  static const unsigned int uart_rts_ao_b_pins[]	= { PIN(GPIOAO_3, 0) };
>  
> @@ -409,7 +408,7 @@ static struct meson_pmx_group meson_gxl_aobus_groups[] = {
>  	GPIO_GROUP(GPIOAO_9, 0),
>  
>  	/* bank AO */
> -	GROUP(uart_tx_ao_b,	0,	26),
> +	GROUP(uart_tx_ao_b,	0,	24),
>  	GROUP(uart_rx_ao_b,	0,	25),
>  	GROUP(uart_tx_ao_a,	0,	12),
>  	GROUP(uart_rx_ao_a,	0,	11),
--
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


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox