* [PATCH 5/6] apalis-tk1: working sd card detect on v1.1 hw
From: Marcel Ziswiler @ 2016-11-22 0:14 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Marcel Ziswiler, Thierry Reding,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Stephen Warren, Rob Herring,
linux-tegra-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
Alexandre Courbot, Russell King,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1479773647-14726-1-git-send-email-marcel.ziswiler-2KBjVHiyJgBBDgjK7y7TUQ@public.gmane.org>
Add sd card detect SD1_CD# applicable for V1.1 modules using GPIO_PV2.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler-2KBjVHiyJgBBDgjK7y7TUQ@public.gmane.org>
---
arch/arm/boot/dts/tegra124-apalis-eval.dts | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/tegra124-apalis-eval.dts b/arch/arm/boot/dts/tegra124-apalis-eval.dts
index 2b5a0f3..2715692 100644
--- a/arch/arm/boot/dts/tegra124-apalis-eval.dts
+++ b/arch/arm/boot/dts/tegra124-apalis-eval.dts
@@ -187,14 +187,8 @@
/* Apalis SD1 */
sdhci@700b0400 {
status = "okay";
- /*
- * Don't use SD1_CD# aka SDMMC3_CLK_LB_OUT for now as it
- * features some magic properties even though the external
- * loopback is disabled and the internal loopback used as per
- * SDMMC_VENDOR_MISC_CNTRL_0 register's SDMMC_SPARE1 bits being
- * set to 0xfffd according to the TRM!
- * cd-gpios = <&gpio TEGRA_GPIO(EE, 4) GPIO_ACTIVE_LOW>;
- */
+ /* SD1_CD# */
+ cd-gpios = <&gpio TEGRA_GPIO(V, 2) GPIO_ACTIVE_LOW>;
bus-width = <4>;
vqmmc-supply = <&vddio_sdmmc3>;
};
--
2.5.5
^ permalink raw reply related
* [PATCH 4/6] apalis-tk1: adjust pin muxing for v1.1 hw
From: Marcel Ziswiler @ 2016-11-22 0:14 UTC (permalink / raw)
To: devicetree
Cc: Marcel Ziswiler, Thierry Reding, linux-kernel, Stephen Warren,
Rob Herring, linux-tegra, Mark Rutland, Alexandre Courbot,
Russell King, linux-arm-kernel
In-Reply-To: <1479773647-14726-1-git-send-email-marcel.ziswiler@toradex.com>
Configure Apalis MMC1 D6 GPIO on SDMMC3_CLK_LB_IN as reserved function
without any pull-up/down.
Configure GPIO_PV2 as SD1_CD# according to latest V1.1 HW.
Leave SDMMC3_CLK_LB_OUT muxed as SDMMC3 with output driver enabled aka
not tristated and input driver enabled as well as it features some
magic properties even though the external loopback is disabled and the
internal loopback used as per SDMMC_VENDOR_MISC_CNTRL_0 register's
SDMMC_SPARE1 bits being set to 0xfffd according to the TRM! This pin is
now a not-connect on V1.1 HW in order to avoid any interference.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
---
arch/arm/boot/dts/tegra124-apalis.dtsi | 53 +++++++++++++++-------------------
1 file changed, 23 insertions(+), 30 deletions(-)
diff --git a/arch/arm/boot/dts/tegra124-apalis.dtsi b/arch/arm/boot/dts/tegra124-apalis.dtsi
index 747ce81..2bfc579 100644
--- a/arch/arm/boot/dts/tegra124-apalis.dtsi
+++ b/arch/arm/boot/dts/tegra124-apalis.dtsi
@@ -414,18 +414,10 @@
nvidia,tristate = <TEGRA_PIN_DISABLE>;
nvidia,enable-input = <TEGRA_PIN_ENABLE>;
};
- /*
- * Don't use MMC1_D6 aka SDMMC3_CLK_LB_IN for now as it
- * features some magic properties even though the
- * external loopback is disabled and the internal
- * loopback used as per SDMMC_VENDOR_MISC_CNTRL_0
- * register's SDMMC_SPARE1 bits being set to 0xfffd
- * according to the TRM!
- */
sdmmc3_clk_lb_in_pee5 { /* D6 GPIO */
nvidia,pins = "sdmmc3_clk_lb_in_pee5";
- nvidia,function = "sdmmc3";
- nvidia,pull = <TEGRA_PIN_PULL_UP>;
+ nvidia,function = "rsvd2";
+ nvidia,pull = <TEGRA_PIN_PULL_NONE>;
nvidia,tristate = <TEGRA_PIN_DISABLE>;
nvidia,enable-input = <TEGRA_PIN_ENABLE>;
};
@@ -520,20 +512,12 @@
nvidia,tristate = <TEGRA_PIN_DISABLE>;
nvidia,enable-input = <TEGRA_PIN_ENABLE>;
};
- /*
- * Don't use SD1_CD# aka SDMMC3_CLK_LB_OUT for now as it
- * features some magic properties even though the
- * external loopback is disabled and the internal
- * loopback used as per SDMMC_VENDOR_MISC_CNTRL_0
- * register's SDMMC_SPARE1 bits being set to 0xfffd
- * according to the TRM!
- */
- sdmmc3_clk_lb_out_pee4 { /* CD# GPIO */
- nvidia,pins = "sdmmc3_clk_lb_out_pee4";
- nvidia,function = "rsvd2";
- nvidia,pull = <TEGRA_PIN_PULL_NONE>;
+ sdmmc3_cd_n_pv2 { /* CD# GPIO */
+ nvidia,pins = "sdmmc3_cd_n_pv2";
+ nvidia,function = "rsvd3";
+ nvidia,pull = <TEGRA_PIN_PULL_UP>;
nvidia,tristate = <TEGRA_PIN_ENABLE>;
- nvidia,enable-input = <TEGRA_PIN_DISABLE>;
+ nvidia,enable-input = <TEGRA_PIN_ENABLE>;
};
/* Apalis SPDIF */
@@ -1512,13 +1496,6 @@
nvidia,tristate = <TEGRA_PIN_ENABLE>;
nvidia,enable-input = <TEGRA_PIN_DISABLE>;
};
- sdmmc3_cd_n_pv2 { /* NC */
- nvidia,pins = "sdmmc3_cd_n_pv2";
- nvidia,function = "rsvd3";
- nvidia,pull = <TEGRA_PIN_PULL_DOWN>;
- nvidia,tristate = <TEGRA_PIN_ENABLE>;
- nvidia,enable-input = <TEGRA_PIN_DISABLE>;
- };
gpio_x1_aud_px1 { /* NC */
nvidia,pins = "gpio_x1_aud_px1";
nvidia,function = "rsvd2";
@@ -1568,6 +1545,22 @@
nvidia,tristate = <TEGRA_PIN_ENABLE>;
nvidia,enable-input = <TEGRA_PIN_DISABLE>;
};
+ /*
+ * Leave SDMMC3_CLK_LB_OUT muxed as SDMMC3 with output
+ * driver enabled aka not tristated and input driver
+ * enabled as well as it features some magic properties
+ * even though the external loopback is disabled and the
+ * internal loopback used as per
+ * SDMMC_VENDOR_MISC_CNTRL_0 register's SDMMC_SPARE1
+ * bits being set to 0xfffd according to the TRM!
+ */
+ sdmmc3_clk_lb_out_pee4 { /* NC */
+ nvidia,pins = "sdmmc3_clk_lb_out_pee4";
+ nvidia,function = "sdmmc3";
+ nvidia,pull = <TEGRA_PIN_PULL_NONE>;
+ nvidia,tristate = <TEGRA_PIN_DISABLE>;
+ nvidia,enable-input = <TEGRA_PIN_ENABLE>;
+ };
};
};
--
2.5.5
^ permalink raw reply related
* [PATCH 3/6] apalis-tk1: optional displayport hot-plug detect
From: Marcel Ziswiler @ 2016-11-22 0:14 UTC (permalink / raw)
To: devicetree
Cc: Marcel Ziswiler, Thierry Reding, linux-kernel, Stephen Warren,
Rob Herring, linux-tegra, Mark Rutland, Alexandre Courbot,
Russell King, linux-arm-kernel
In-Reply-To: <1479773647-14726-1-git-send-email-marcel.ziswiler@toradex.com>
Configure DP_HPD_PFF0 pin as optional DisplayPort hot-plug detect.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
---
arch/arm/boot/dts/tegra124-apalis.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra124-apalis.dtsi b/arch/arm/boot/dts/tegra124-apalis.dtsi
index 0534601..747ce81 100644
--- a/arch/arm/boot/dts/tegra124-apalis.dtsi
+++ b/arch/arm/boot/dts/tegra124-apalis.dtsi
@@ -255,7 +255,7 @@
};
dp_hpd_pff0 {
nvidia,pins = "dp_hpd_pff0";
- nvidia,function = "rsvd2";
+ nvidia,function = "dp";
nvidia,pull = <TEGRA_PIN_PULL_NONE>;
nvidia,tristate = <TEGRA_PIN_DISABLE>;
nvidia,enable-input = <TEGRA_PIN_ENABLE>;
--
2.5.5
^ permalink raw reply related
* [PATCH 2/6] apalis-tk1: temp alert pull-up
From: Marcel Ziswiler @ 2016-11-22 0:14 UTC (permalink / raw)
To: devicetree
Cc: Marcel Ziswiler, Thierry Reding, linux-kernel, Stephen Warren,
Rob Herring, linux-tegra, Mark Rutland, Alexandre Courbot,
Russell King, linux-arm-kernel
In-Reply-To: <1479773647-14726-1-git-send-email-marcel.ziswiler@toradex.com>
Pull-up GPIO_PI6 connected to TMP451's ALERT#/THERM2#.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
---
arch/arm/boot/dts/tegra124-apalis.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/tegra124-apalis.dtsi b/arch/arm/boot/dts/tegra124-apalis.dtsi
index 6aa4952..0534601 100644
--- a/arch/arm/boot/dts/tegra124-apalis.dtsi
+++ b/arch/arm/boot/dts/tegra124-apalis.dtsi
@@ -1151,11 +1151,11 @@
nvidia,enable-input = <TEGRA_PIN_DISABLE>;
};
- /* GPIO_PI6 aka TEMP_ALERT_L */
+ /* GPIO_PI6 aka TMP451 ALERT#/THERM2# */
pi6 {
nvidia,pins = "pi6";
nvidia,function = "rsvd1";
- nvidia,pull = <TEGRA_PIN_PULL_NONE>;
+ nvidia,pull = <TEGRA_PIN_PULL_UP>;
nvidia,tristate = <TEGRA_PIN_ENABLE>;
nvidia,enable-input = <TEGRA_PIN_ENABLE>;
};
--
2.5.5
^ permalink raw reply related
* [PATCH 1/6] apalis-tk1: remove spurious new lines
From: Marcel Ziswiler @ 2016-11-22 0:14 UTC (permalink / raw)
To: devicetree
Cc: Mark Rutland, Alexandre Courbot, Stephen Warren, Marcel Ziswiler,
linux-kernel, Rob Herring, Russell King, Thierry Reding,
linux-tegra, linux-arm-kernel
In-Reply-To: <1479773647-14726-1-git-send-email-marcel.ziswiler@toradex.com>
Remove some spurious new lines.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
---
arch/arm/boot/dts/tegra124-apalis-eval.dts | 1 -
arch/arm/boot/dts/tegra124-apalis.dtsi | 12 ------------
2 files changed, 13 deletions(-)
diff --git a/arch/arm/boot/dts/tegra124-apalis-eval.dts b/arch/arm/boot/dts/tegra124-apalis-eval.dts
index 653044a..2b5a0f3 100644
--- a/arch/arm/boot/dts/tegra124-apalis-eval.dts
+++ b/arch/arm/boot/dts/tegra124-apalis-eval.dts
@@ -232,7 +232,6 @@
backlight: backlight {
compatible = "pwm-backlight";
-
/* BKL1_PWM */
pwms = <&pwm 3 5000000>;
brightness-levels = <255 231 223 207 191 159 127 0>;
diff --git a/arch/arm/boot/dts/tegra124-apalis.dtsi b/arch/arm/boot/dts/tegra124-apalis.dtsi
index 0819721..6aa4952 100644
--- a/arch/arm/boot/dts/tegra124-apalis.dtsi
+++ b/arch/arm/boot/dts/tegra124-apalis.dtsi
@@ -56,7 +56,6 @@
pcie-controller@01003000 {
status = "okay";
-
avddio-pex-supply = <&vdd_1v05>;
avdd-pex-pll-supply = <&vdd_1v05>;
avdd-pll-erefe-supply = <&avdd_1v05>;
@@ -85,7 +84,6 @@
hdmi@54280000 {
pll-supply = <®_1v05_avdd_hdmi_pll>;
vdd-supply = <®_3v3_avdd_hdmi>;
-
nvidia,ddc-i2c-bus = <&hdmi_ddc>;
nvidia,hpd-gpio =
<&gpio TEGRA_GPIO(N, 7) GPIO_ACTIVE_HIGH>;
@@ -1607,15 +1605,11 @@
compatible = "ams,as3722";
reg = <0x40>;
interrupts = <0 86 IRQ_TYPE_LEVEL_HIGH>;
-
ams,system-power-controller;
-
#interrupt-cells = <2>;
interrupt-controller;
-
gpio-controller;
#gpio-cells = <2>;
-
pinctrl-names = "default";
pinctrl-0 = <&as3722_default>;
@@ -1790,7 +1784,6 @@
reg = <0x4c>;
interrupt-parent = <&gpio>;
interrupts = <TEGRA_GPIO(I, 6) IRQ_TYPE_LEVEL_LOW>;
-
#thermal-sensor-cells = <1>;
};
};
@@ -1823,7 +1816,6 @@
sata@70020000 {
phys = <&{/padctl@7009f000/pads/sata/lanes/sata-0}>;
phy-names = "sata-0";
-
avdd-supply = <&vdd_1v05>;
hvdd-supply = <®_3v3>;
vddio-supply = <&vdd_1v05>;
@@ -1837,7 +1829,6 @@
<&{/padctl@7009f000/pads/usb2/lanes/usb2-2}>,
<&{/padctl@7009f000/pads/pcie/lanes/pcie-0}>;
phy-names = "usb2-0", "usb3-1", "usb2-1", "usb2-2", "usb3-0";
-
avddio-pex-supply = <&vdd_1v05>;
avdd-pll-erefe-supply = <&avdd_1v05>;
avdd-pll-utmip-supply = <&vddio_1v8>;
@@ -1919,7 +1910,6 @@
usb2-0 {
status = "okay";
mode = "otg";
-
vbus-supply = <®_usbo1_vbus>;
};
@@ -1927,7 +1917,6 @@
usb2-1 {
status = "okay";
mode = "host";
-
vbus-supply = <®_usbh_vbus>;
};
@@ -1935,7 +1924,6 @@
usb2-2 {
status = "okay";
mode = "host";
-
vbus-supply = <®_usbh_vbus>;
};
--
2.5.5
^ permalink raw reply related
* [PATCH 0/6] apalis-tk1: updates for v1.1 hw
From: Marcel Ziswiler @ 2016-11-22 0:14 UTC (permalink / raw)
To: devicetree
Cc: Marcel Ziswiler, Thierry Reding, linux-kernel, Stephen Warren,
Rob Herring, linux-tegra, Mark Rutland, Alexandre Courbot,
Russell King, linux-arm-kernel
This series updates the device tree for the upcoming V1.1 HW samples.
All changes are purely opportunistic meaning they fix stuff which on
older HW was anyway broken so there should be no backwards
compatibility issues.
Marcel Ziswiler (6):
apalis-tk1: remove spurious new lines
apalis-tk1: temp alert pull-up
apalis-tk1: optional displayport hot-plug detect
apalis-tk1: adjust pin muxing for v1.1 hw
apalis-tk1: working sd card detect on v1.1 hw
apalis-tk1: update compatibility comment
arch/arm/boot/dts/tegra124-apalis-eval.dts | 11 +----
arch/arm/boot/dts/tegra124-apalis.dtsi | 73 +++++++++++-------------------
2 files changed, 29 insertions(+), 55 deletions(-)
--
2.5.5
^ permalink raw reply
* Re: [PATCH 2/4] [media] davinci: vpif_capture: don't lock over s_stream
From: Kevin Hilman @ 2016-11-22 0:10 UTC (permalink / raw)
To: Hans Verkuil
Cc: linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Sekhar Nori, Axel Haslam,
Bartosz Gołaszewski, Alexandre Bailon, David Lechner
In-Reply-To: <f385c65b-1f73-a5b1-b498-43916d5bdfb6-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
Hans Verkuil <hverkuil-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org> writes:
> On 19/11/16 01:32, Kevin Hilman wrote:
>> Video capture subdevs may be over I2C and may sleep during xfer, so we
>> cannot do IRQ-disabled locking when calling the subdev.
>>
>> Signed-off-by: Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>> ---
>> drivers/media/platform/davinci/vpif_capture.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/media/platform/davinci/vpif_capture.c b/drivers/media/platform/davinci/vpif_capture.c
>> index 79cef74e164f..becc3e63b472 100644
>> --- a/drivers/media/platform/davinci/vpif_capture.c
>> +++ b/drivers/media/platform/davinci/vpif_capture.c
>> @@ -193,12 +193,16 @@ static int vpif_start_streaming(struct vb2_queue *vq, unsigned int count)
>> }
>> }
>>
>> + spin_unlock_irqrestore(&common->irqlock, flags);
>> +
>> ret = v4l2_subdev_call(ch->sd, video, s_stream, 1);
>> if (ret && ret != -ENOIOCTLCMD && ret != -ENODEV) {
>> vpif_dbg(1, debug, "stream on failed in subdev\n");
>> goto err;
>> }
>>
>> + spin_lock_irqsave(&common->irqlock, flags);
>
> This needs to be moved to right after the v4l2_subdev_call, otherwise the
> goto err above will not have the spinlock.
Yes indeed. Will respin.
Kevin
--
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 4/4] [media] dt-bindings: add TI VPIF documentation
From: Kevin Hilman @ 2016-11-22 0:09 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-media, Hans Verkuil, devicetree, Sekhar Nori, Axel Haslam,
Bartosz Gołaszewski, Alexandre Bailon, David Lechner,
Rob Herring
In-Reply-To: <165090919.oFnaNnsijv@wuerfel>
Arnd Bergmann <arnd@arndb.de> writes:
> On Friday, November 18, 2016 4:32:08 PM CET Kevin Hilman wrote:
>> +
>> +Required properties:
>> +- compatible: must be "ti,vpif-capture"
>> +- reg: physical base address and length of the registers set for the device;
>> +- interrupts: should contain IRQ line for the VPIF
>> +
>>
>
> Shouldn't this have a SoC specific identifier or a version number
> in the compatible string? "vpif" seems rather generic, so it's
> likely that TI made more than one variant of it.
AFAICT, they used this for a single generation of davinci SoCs (dm6467,
da850) and then moved on to using something completely different.
But, that still proves your point because it's very SoC specific, so
I'll make the compatible specific.
Thanks for the review,
Kevin
^ permalink raw reply
* Re: [PATCH 1/2] ARM64: dts: Add support for Meson GXM
From: Kevin Hilman @ 2016-11-21 23:42 UTC (permalink / raw)
To: Neil Armstrong
Cc: carlo-KA+7E9HrN00dnm+yROfE0A,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161121162905.14285-2-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Neil,
Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> writes:
> Following the Amlogic Linux kernel, it seem the only differences
> between the GXL and GXM SoCs are the CPU Clusters.
>
> This commit renames the gxl-s905d-p23x DTSI in a common file for
> S905D p20x and S912 q20x boards.
s/p20x/p23x/ ??
> Then adds a meson-gxm dtsi and reproduce the P23x to Q20x boards
> dts files since the S905D and S912 SoCs shares the same pinout
> and the P23x and Q20x boards are identical.
>
> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
I had to drop this as it breaks the network on (at least) gxbb-p200, but...
[...]
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts
> index 03e3d76..17bb77c 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts
> @@ -56,3 +56,22 @@
> pinctrl-0 = <&i2c_b_pins>;
> pinctrl-names = "default";
> };
> +
> +ðmac {
> + status = "okay";
> + pinctrl-0 = <ð_rgmii_pins>;
> + pinctrl-names = "default";
> +
> + phy-handle = <ð_phy0>;
> +
> + mdio {
> + compatible = "snps,dwmac-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + eth_phy0: ethernet-phy@0 {
> + reg = <0>;
> + realtek,disable-eee-1000t;
> + };
> + };
> +};
... backing out this change makes it work again.
This change also looks suspicious as it's using the proposed disable-eee
properties, which I don't think have been merged yet.
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts
> index 39bb037..5608c51 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts
> @@ -50,3 +50,10 @@
> compatible = "amlogic,p201", "amlogic,meson-gxbb";
> model = "Amlogic Meson GXBB P201 Development Board";
> };
> +
> +ðmac {
> + status = "okay";
> + pinctrl-0 = <ð_rmii_pins>;
> + pinctrl-names = "default";
> + phy-mode = "rmii";
> +};
This also doesn't look releveant to the GXL/GXM changes being introduced
in this patch.
Could you separate out any GXBB-related changes into a separate patch
(if they are in fact needed) and re-spin this?
Thanks,
Kevin
--
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 00/16] mmc: sdhci-msm: Add clk-rates, DDR, HS400 support
From: Stephen Boyd @ 2016-11-21 23:11 UTC (permalink / raw)
To: Ritesh Harjani
Cc: Ulf Hansson, Andy Gross, linux-mmc, Adrian Hunter, Shawn Lin,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-clk,
David Brown,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Georgi Djakov, Alex Lemberg, Mateusz Nowak, Yuliy Izrailov,
Asutosh Das, David Griego, Sahitya Tummala, Venkat Gopalakrishnan,
Rajendra Nayak
In-Reply-To: <d4d05fb9-8a9e-6cf2-dc63-0edbd27a9e55-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On 11/21, Ritesh Harjani wrote:
>
>
> On 11/21/2016 3:36 PM, Ulf Hansson wrote:
> >On 21 November 2016 at 07:37, Ritesh Harjani <riteshh-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
> >>Hi,
> >>
> >>This is v9 version of the patch series which adds support for MSM8996.
> >>Adds HS400 driver support as well.
> >>These are tested on internal msm8996 & db410c HW.
> >>
> >>The patch series is ready. Do we think we can apply these
> >>patches for next now?
> >
> >I guess the DTS changes can be picked up by Andy, so they can go via arm-soc?
> Yes.
>
> >
> >Then, does the mmc changes depend on the clock changes? If so, I can
> >pick them as well, but then I need an ack from Stephen....
> Ideal and preferable, would be that clk & mmc changes go in
> together. But either ways should be fine.
>
There's only a runtime dependency where the clk rates will be
wrong if clk tree isn't merged. I'd rather just apply the clk
ones directly to clk tree and let all three trees come together
in linux-next and work.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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
* [PATCH v4 2/2] reset: Add the TI SCI reset driver
From: Andrew F. Davis @ 2016-11-21 21:30 UTC (permalink / raw)
To: Nishanth Menon, Tero Kristo, Santosh Shilimkar, Philipp Zabel,
Rob Herring, Mark Rutland, Suman Anna
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Andrew F . Davis
In-Reply-To: <20161121213052.8684-1-afd-l0cyMroinI0@public.gmane.org>
Some TI Keystone family of SoCs contain a system controller (like the
Power Management Micro Controller (PMMC) on K2G SoCs) that manage the
low-level device control (like clocks, resets etc) for the various
hardware modules present on the SoC. These device control operations
are provided to the host processor OS through a communication protocol
called the TI System Control Interface (TI SCI) protocol.
This patch adds a reset driver that communicates to the system
controller over the TI SCI protocol for performing reset management
of various devices present on the SoC. Various reset functionalities
are achieved by the means of different TI SCI device operations
provided by the TI SCI framework.
Signed-off-by: Andrew F. Davis <afd-l0cyMroinI0@public.gmane.org>
[s-anna-l0cyMroinI0@public.gmane.org: documentation changes, revised commit message]
Signed-off-by: Suman Anna <s-anna-l0cyMroinI0@public.gmane.org>
Signed-off-by: Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>
Acked-by: Santosh Shilimkar <ssantosh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
MAINTAINERS | 1 +
drivers/reset/Kconfig | 9 ++
drivers/reset/Makefile | 1 +
drivers/reset/reset-ti-sci.c | 272 +++++++++++++++++++++++++++++++++++++++++++
4 files changed, 283 insertions(+)
create mode 100644 drivers/reset/reset-ti-sci.c
diff --git a/MAINTAINERS b/MAINTAINERS
index accf991..b93d91a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11901,6 +11901,7 @@ F: include/dt-bindings/clock/k2g.h
F: drivers/clk/keystone/sci-clk.c
F: Documentation/devicetree/bindings/reset/ti,sci-reset.txt
F: include/dt-bindings/reset/k2g.h
+F: drivers/reset/reset-ti-sci.c
THANKO'S RAREMONO AM/FM/SW RADIO RECEIVER USB DRIVER
M: Hans Verkuil <hverkuil-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 06d9fa2..4c21c9d 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -66,6 +66,15 @@ config RESET_SUNXI
help
This enables the reset driver for Allwinner SoCs.
+config RESET_TI_SCI
+ tristate "TI System Control Interface (TI-SCI) reset driver"
+ depends on RESET_CONTROLLER
+ depends on TI_SCI_PROTOCOL
+ help
+ This enables the reset driver support over TI System Control Interface
+ available on some new TI's SoCs. If you wish to use reset resources
+ managed by the TI System Controller, say Y here. Otherwise, say N.
+
config TI_SYSCON_RESET
tristate "TI SYSCON Reset Driver"
depends on HAS_IOMEM
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index bbe7026..36321f2 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_RESET_PISTACHIO) += reset-pistachio.o
obj-$(CONFIG_RESET_SOCFPGA) += reset-socfpga.o
obj-$(CONFIG_RESET_STM32) += reset-stm32.o
obj-$(CONFIG_RESET_SUNXI) += reset-sunxi.o
+obj-$(CONFIG_RESET_TI_SCI) += reset-ti-sci.o
obj-$(CONFIG_TI_SYSCON_RESET) += reset-ti-syscon.o
obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
obj-$(CONFIG_RESET_ZYNQ) += reset-zynq.o
diff --git a/drivers/reset/reset-ti-sci.c b/drivers/reset/reset-ti-sci.c
new file mode 100644
index 0000000..9ac8499
--- /dev/null
+++ b/drivers/reset/reset-ti-sci.c
@@ -0,0 +1,272 @@
+/*
+ * Texas Instrument's System Control Interface (TI-SCI) reset driver
+ *
+ * Copyright (C) 2015-2016 Texas Instruments Incorporated - http://www.ti.com/
+ * Andrew F. Davis <afd-l0cyMroinI0@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/idr.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/reset-controller.h>
+#include <linux/soc/ti/ti_sci_protocol.h>
+
+/**
+ * struct ti_sci_reset_control - reset control structure
+ * @dev_id: SoC-specific device identifier
+ * @reset_mask: reset mask to use for toggling reset
+ * @lock: synchronize reset_mask read-modify-writes
+ */
+struct ti_sci_reset_control {
+ u32 dev_id;
+ u32 reset_mask;
+ struct mutex lock;
+};
+
+/**
+ * struct ti_sci_reset_data - reset controller information structure
+ * @rcdev: reset controller entity
+ * @dev: reset controller device pointer
+ * @sci: TI SCI handle used for communication with system controller
+ * @idr: idr structure for mapping ids to reset control structures
+ */
+struct ti_sci_reset_data {
+ struct reset_controller_dev rcdev;
+ struct device *dev;
+ const struct ti_sci_handle *sci;
+ struct idr idr;
+};
+
+#define to_ti_sci_reset_data(p) \
+ container_of((p), struct ti_sci_reset_data, rcdev)
+
+/**
+ * ti_sci_reset_set() - program a device's reset
+ * @rcdev: reset controller entity
+ * @id: ID of the reset to toggle
+ * @assert: boolean flag to indicate assert or deassert
+ *
+ * This is a common internal function used to assert or deassert a device's
+ * reset using the TI SCI protocol. The device's reset is asserted if the
+ * @assert argument is true, or deasserted if @assert argument is false.
+ * The mechanism itself is a read-modify-write procedure, the current device
+ * reset register is read using a TI SCI device operation, the new value is
+ * set or un-set using the reset's mask, and the new reset value written by
+ * using another TI SCI device operation.
+ *
+ * Return: 0 for successful request, else a corresponding error value
+ */
+static int ti_sci_reset_set(struct reset_controller_dev *rcdev,
+ unsigned long id, bool assert)
+{
+ struct ti_sci_reset_data *data = to_ti_sci_reset_data(rcdev);
+ const struct ti_sci_handle *sci = data->sci;
+ const struct ti_sci_dev_ops *dev_ops = &sci->ops.dev_ops;
+ struct ti_sci_reset_control *control;
+ u32 reset_state;
+ int ret;
+
+ control = idr_find(&data->idr, id);
+ if (!control)
+ return -EINVAL;
+
+ mutex_lock(&control->lock);
+
+ ret = dev_ops->get_device_resets(sci, control->dev_id,
+ &reset_state);
+ if (ret)
+ goto out;
+
+ if (assert)
+ reset_state |= control->reset_mask;
+ else
+ reset_state &= ~control->reset_mask;
+
+ ret = dev_ops->set_device_resets(sci, control->dev_id,
+ reset_state);
+out:
+ mutex_unlock(&control->lock);
+
+ return ret;
+}
+
+/**
+ * ti_sci_reset_assert() - assert device reset
+ * @rcdev: reset controller entity
+ * @id: ID of the reset to be asserted
+ *
+ * This function implements the reset driver op to assert a device's reset
+ * using the TI SCI protocol. This invokes the function ti_sci_reset_set()
+ * with the corresponding parameters as passed in, but with the @assert
+ * argument set to true for asserting the reset.
+ *
+ * Return: 0 for successful request, else a corresponding error value
+ */
+static int ti_sci_reset_assert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ return ti_sci_reset_set(rcdev, id, true);
+}
+
+/**
+ * ti_sci_reset_deassert() - deassert device reset
+ * @rcdev: reset controller entity
+ * @id: ID of the reset to be deasserted
+ *
+ * This function implements the reset driver op to deassert a device's reset
+ * using the TI SCI protocol. This invokes the function ti_sci_reset_set()
+ * with the corresponding parameters as passed in, but with the @assert
+ * argument set to false for deasserting the reset.
+ *
+ * Return: 0 for successful request, else a corresponding error value
+ */
+static int ti_sci_reset_deassert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ return ti_sci_reset_set(rcdev, id, false);
+}
+
+/**
+ * ti_sci_reset_status() - check device reset status
+ * @rcdev: reset controller entity
+ * @id: ID of reset to be checked
+ *
+ * This function implements the reset driver op to return the status of a
+ * device's reset using the TI SCI protocol. The reset register value is read
+ * by invoking the TI SCI device operation .get_device_resets(), and the
+ * status of the specific reset is extracted and returned using this reset's
+ * reset mask.
+ *
+ * Return: 0 if reset is deasserted, or a non-zero value if reset is asserted
+ */
+static int ti_sci_reset_status(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct ti_sci_reset_data *data = to_ti_sci_reset_data(rcdev);
+ const struct ti_sci_handle *sci = data->sci;
+ const struct ti_sci_dev_ops *dev_ops = &sci->ops.dev_ops;
+ struct ti_sci_reset_control *control;
+ u32 reset_state;
+ int ret;
+
+ control = idr_find(&data->idr, id);
+ if (!control)
+ return -EINVAL;
+
+ ret = dev_ops->get_device_resets(sci, control->dev_id,
+ &reset_state);
+ if (ret)
+ return ret;
+
+ return reset_state & control->reset_mask;
+}
+
+static struct reset_control_ops ti_sci_reset_ops = {
+ .assert = ti_sci_reset_assert,
+ .deassert = ti_sci_reset_deassert,
+ .status = ti_sci_reset_status,
+};
+
+/**
+ * ti_sci_reset_of_xlate() - translate a set of OF arguments to a reset ID
+ * @rcdev: reset controller entity
+ * @reset_spec: OF reset argument specifier
+ *
+ * This function performs the translation of the reset argument specifier
+ * values defined in a reset consumer device node. The function allocates a
+ * reset control structure for that device reset, and will be used by the
+ * driver for performing any reset functions on that reset. An idr structure
+ * is allocated and used to map to the reset control structure. This idr
+ * is used by the driver to do reset lookups.
+ *
+ * Return: 0 for successful request, else a corresponding error value
+ */
+static int ti_sci_reset_of_xlate(struct reset_controller_dev *rcdev,
+ const struct of_phandle_args *reset_spec)
+{
+ struct ti_sci_reset_data *data = to_ti_sci_reset_data(rcdev);
+ struct ti_sci_reset_control *control;
+
+ if (WARN_ON(reset_spec->args_count != rcdev->of_reset_n_cells))
+ return -EINVAL;
+
+ control = devm_kzalloc(data->dev, sizeof(*control), GFP_KERNEL);
+ if (!control)
+ return -ENOMEM;
+
+ control->dev_id = reset_spec->args[0];
+ control->reset_mask = reset_spec->args[1];
+ mutex_init(&control->lock);
+
+ return idr_alloc(&data->idr, control, 0, 0, GFP_KERNEL);
+}
+
+static const struct of_device_id ti_sci_reset_of_match[] = {
+ { .compatible = "ti,sci-reset", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, ti_sci_reset_of_match);
+
+static int ti_sci_reset_probe(struct platform_device *pdev)
+{
+ struct ti_sci_reset_data *data;
+
+ if (!pdev->dev.of_node)
+ return -ENODEV;
+
+ data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->sci = devm_ti_sci_get_handle(&pdev->dev);
+ if (IS_ERR(data->sci))
+ return PTR_ERR(data->sci);
+
+ data->rcdev.ops = &ti_sci_reset_ops;
+ data->rcdev.owner = THIS_MODULE;
+ data->rcdev.of_node = pdev->dev.of_node;
+ data->rcdev.of_reset_n_cells = 2;
+ data->rcdev.of_xlate = ti_sci_reset_of_xlate;
+ data->dev = &pdev->dev;
+ idr_init(&data->idr);
+
+ platform_set_drvdata(pdev, data);
+
+ return reset_controller_register(&data->rcdev);
+}
+
+static int ti_sci_reset_remove(struct platform_device *pdev)
+{
+ struct ti_sci_reset_data *data = platform_get_drvdata(pdev);
+
+ reset_controller_unregister(&data->rcdev);
+
+ idr_destroy(&data->idr);
+
+ return 0;
+}
+
+static struct platform_driver ti_sci_reset_driver = {
+ .probe = ti_sci_reset_probe,
+ .remove = ti_sci_reset_remove,
+ .driver = {
+ .name = "ti-sci-reset",
+ .of_match_table = ti_sci_reset_of_match,
+ },
+};
+module_platform_driver(ti_sci_reset_driver);
+
+MODULE_AUTHOR("Andrew F. Davis <afd-l0cyMroinI0@public.gmane.org>");
+MODULE_DESCRIPTION("TI System Control Interface (TI SCI) Reset driver");
+MODULE_LICENSE("GPL v2");
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v4 1/2] Documentation: dt: reset: Add TI SCI reset binding
From: Andrew F. Davis @ 2016-11-21 21:30 UTC (permalink / raw)
To: Nishanth Menon, Tero Kristo, Santosh Shilimkar, Philipp Zabel,
Rob Herring, Mark Rutland, Suman Anna
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Andrew F . Davis
In-Reply-To: <20161121213052.8684-1-afd-l0cyMroinI0@public.gmane.org>
Add TI SCI reset controller binding. This describes the DT binding
details for a reset controller node providing reset management services
to hardware blocks (reset consumers) using the Texas Instrument's System
Control Interface (TI SCI) protocol to communicate to a system controller
block present on the SoC.
Signed-off-by: Andrew F. Davis <afd-l0cyMroinI0@public.gmane.org>
[s-anna-l0cyMroinI0@public.gmane.org: revise the binding format]
Signed-off-by: Suman Anna <s-anna-l0cyMroinI0@public.gmane.org>
Signed-off-by: Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>
Acked-by: Santosh Shilimkar <ssantosh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
.../devicetree/bindings/reset/ti,sci-reset.txt | 66 ++++++++++++++++++++++
MAINTAINERS | 2 +
include/dt-bindings/reset/k2g.h | 22 ++++++++
3 files changed, 90 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.txt
create mode 100644 include/dt-bindings/reset/k2g.h
diff --git a/Documentation/devicetree/bindings/reset/ti,sci-reset.txt b/Documentation/devicetree/bindings/reset/ti,sci-reset.txt
new file mode 100644
index 0000000..820c5d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/ti,sci-reset.txt
@@ -0,0 +1,66 @@
+Texas Instruments System Control Interface (TI-SCI) Reset Controller
+=====================================================================
+
+Some TI SoCs contain a system controller (like the Power Management Micro
+Controller (PMMC) on Keystone K2G SoC) that are responsible for controlling
+the state of the various hardware modules present on the SoC. Communication
+between the host processor running an OS and the system controller happens
+through a protocol called TI System Control Interface (TI-SCI protocol).
+For TI SCI details, please refer to the document,
+Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
+
+TI-SCI Reset Controller Node
+============================
+This reset controller node uses the TI SCI protocol to perform the reset
+management of various hardware modules present on the SoC. Must be a child
+node of the associated TI-SCI system controller node.
+
+Required properties:
+--------------------
+ - compatible : Should be "ti,sci-reset"
+ - #reset-cells : Should be 2. Please see the reset consumer node below for
+ usage details.
+
+TI-SCI Reset Consumer Nodes
+===========================
+Each of the reset consumer nodes should have the following properties,
+in addition to their own properties.
+
+Required properties:
+--------------------
+ - resets : A phandle and reset specifier pair, one pair for each reset
+ signal that affects the device, or that the device manages.
+ The phandle should point to the TI-SCI reset controller node,
+ and the reset specifier should have 2 cell-values. The first
+ cell should contain the device ID, the values of which are
+ specified in the <dt-bindings/genpd/<soc>.h> include file.
+ The second cell should contain the reset mask value used by
+ system controller, the values of which are specified in the
+ include file <dt-bindings/reset/<soc>.h>, where <soc> is the
+ name of the SoC involved, for example 'k2g'.
+
+Please also refer to Documentation/devicetree/bindings/reset/reset.txt for
+common reset controller usage by consumers.
+
+Example:
+--------
+The following example demonstrates both a TI-SCI reset controller node and a
+consumer (a DSP device) on the K2G SoC.
+
+#include <dt-bindings/genpd/k2g.h>
+#include <dt-bindings/reset/k2g.h>
+
+pmmc: pmmc {
+ compatible = "ti,k2g-sci";
+
+ k2g_reset: reset-controller {
+ compatible = "ti,sci-reset";
+ #reset-cells = <2>;
+ };
+};
+
+dsp0: dsp0 {
+ ...
+ resets = <&k2g_reset K2G_DEV_CGEM0 K2G_DEV_CGEM0_DSP0_RESET>;
+ ...
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 6e93976..accf991 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11899,6 +11899,8 @@ F: drivers/soc/ti/ti_sci_pm_domains.c
F: Documentation/devicetree/bindings/clock/ti,sci-clk.txt
F: include/dt-bindings/clock/k2g.h
F: drivers/clk/keystone/sci-clk.c
+F: Documentation/devicetree/bindings/reset/ti,sci-reset.txt
+F: include/dt-bindings/reset/k2g.h
THANKO'S RAREMONO AM/FM/SW RADIO RECEIVER USB DRIVER
M: Hans Verkuil <hverkuil-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
diff --git a/include/dt-bindings/reset/k2g.h b/include/dt-bindings/reset/k2g.h
new file mode 100644
index 0000000..00e2a9b
--- /dev/null
+++ b/include/dt-bindings/reset/k2g.h
@@ -0,0 +1,22 @@
+/*
+ * TI K2G SoC reset definitions
+ *
+ * Copyright (C) 2015-2016 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program 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.
+ */
+
+#ifndef __DT_BINDINGS_RESET_K2G_H__
+#define __DT_BINDINGS_RESET_K2G_H__
+
+#define K2G_DEV_CGEM0_DSP0_RESET 0x1
+
+#endif
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v4 0/2] Add TI SCI Reset Driver
From: Andrew F. Davis @ 2016-11-21 21:30 UTC (permalink / raw)
To: Nishanth Menon, Tero Kristo, Santosh Shilimkar, Philipp Zabel,
Rob Herring, Mark Rutland, Suman Anna
Cc: linux-arm-kernel, devicetree, linux-kernel, Andrew F . Davis
Hello all,
This series adds a reset controller driver that uses the TI SCI
protocol to manage resets.
The TI SCI protocol is used to communicate with power management
controllers used by some SoCs. These controllers manage the various
power domains, clocks, and resets available on a SoC.
This series is based on drivers for TI SCI and the first two controlled
elements above, these series can be found here:
TI-SCI: http://www.spinics.net/lists/arm-kernel/msg536851.html
PM Domains: http://www.spinics.net/lists/devicetree/msg146621.html
Clocks: https://www.spinics.net/lists/linux-clk/msg12785.html
Thanks,
Andrew
Changes from v3:
- Addressed Rob Herring's comments
- Added Santosh Shilimkar's Ack
Changes from v2:
- Merged DT binding patch and reset header patch
- Added locking for reset bit mask
Changes from v1:
- Revised dt binding
- CC Linux ARM list
Andrew F. Davis (2):
Documentation: dt: reset: Add TI SCI reset binding
reset: Add the TI SCI reset driver
.../devicetree/bindings/reset/ti,sci-reset.txt | 66 +++++
MAINTAINERS | 3 +
drivers/reset/Kconfig | 9 +
drivers/reset/Makefile | 1 +
drivers/reset/reset-ti-sci.c | 272 +++++++++++++++++++++
include/dt-bindings/reset/k2g.h | 22 ++
6 files changed, 373 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.txt
create mode 100644 drivers/reset/reset-ti-sci.c
create mode 100644 include/dt-bindings/reset/k2g.h
--
2.10.2
^ permalink raw reply
* Re: [PATCH v2 2/4] usb: dwc2: Add binding for AHB burst
From: Christian Lamparter @ 2016-11-21 21:10 UTC (permalink / raw)
To: John Youn
Cc: Christian Lamparter, Rob Herring, Stefan Wahren, Felipe Balbi,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Mark Rutland,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, Michael Ellerman,
Paul Mackerras, Benjamin Herrenschmidt
In-Reply-To: <e01e1b30-a399-94cc-33c9-625008b31d4b-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
Hello John,
On Monday, November 21, 2016 12:16:31 PM CET John Youn wrote:
> On 11/18/2016 12:18 PM, Christian Lamparter wrote:
> > On Friday, November 18, 2016 8:16:08 AM CET Rob Herring wrote:
> >> On Thu, Nov 17, 2016 at 04:35:10PM +0100, Stefan Wahren wrote:
> >>> Hi John,
> >>>
> >>> Am 17.11.2016 um 00:47 schrieb John Youn:
> >>>> Add the "snps,ahb-burst" binding and read it in.
> >>>>
> >>>> This property controls which burst type to perform on the AHB bus as a
> >>>> master in internal DMA mode. This overrides the legacy param value,
> >>>> which we need to keep around for now since several platforms use it.
> >>>>
> >>>> Some platforms may see better or worse performance based on this
> >>>> value. The HAPS platform is one example where all INCRx have worse
> >>>> performance than INCR.
> >>>>
> >>>> Other platforms (such as the Canyonlands board) report that the default
> >>>> value causes system hangs.
> >>>>
> >>>> Signed-off-by: John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
> >>>> Cc: Christian Lamparter <chunkeey-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> >>>> ---
> >>>> Documentation/devicetree/bindings/usb/dwc2.txt | 2 +
> >>>> drivers/usb/dwc2/core.h | 9 +++++
> >>>> drivers/usb/dwc2/params.c | 56 ++++++++++++++++++++++++++
> >>>> 3 files changed, 67 insertions(+)
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt
> >>>> index 6c7c2bce..9e7b4b4 100644
> >>>> --- a/Documentation/devicetree/bindings/usb/dwc2.txt
> >>>> +++ b/Documentation/devicetree/bindings/usb/dwc2.txt
> >>>
> >>> according to Documentation/devicetree/bindings/submitting-patches.txt
> >>> this change should be a separate patch.
> >>>
> >>>> @@ -26,6 +26,8 @@ Optional properties:
> >>>> Refer to phy/phy-bindings.txt for generic phy consumer properties
> >>>> - dr_mode: shall be one of "host", "peripheral" and "otg"
> >>>> Refer to usb/generic.txt
> >>>> +- snps,ahb-burst: specifies the ahb burst length. Valid arguments are:
> >>>> + "SINGLE", "INCR", "INCR4", "INCR8", "INCR16". Defaults to "INCR4".
> >>>
> >>> This doesn't apply in case of the bcm2835. I would prefer this option is
> >>> ignored in that case with a dev_warn("snps,ahb-burst is not supported on
> >>> this platform").
> >>
> >> Also, perhaps you should allow that the compatible string can define the
> >> default.
> >>
> > I hoped you would say that :).
> >
> > I've attached a patch (on top of John Youn changes) that does
> > just that for the amcc,dwc-otg. I put the GAHBCFG_HBSTLEN_INCR
> > value into the .data, if that's a problem, I can certainly
> > respin the patch and put it in a dedicated struct.
> >
> > Regards
> >
> > Christian
> > ---
> > From 4c31a029dde714828810b1c3e61a5b1412ac939a Mon Sep 17 00:00:00 2001
> > From: Christian Lamparter <chunkeey-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date: Fri, 18 Nov 2016 21:03:19 +0100
> > Subject: [PATCH] usb: dwc2: add a default ahb-burst setting for amcc,dwc-otg
> >
> > This patch adds a of_device_id table which can be used by
> > existing devices to supply a ahb-burst value for the platform
> > without having to add a "snps,ahb-burst" entry to the dts.
> >
> > Note: Adding new devices to this table is discouraged.
> > please consider adding the "snps,ahb-burst" property
> > with the correct configuration to your device tree
> > file instead.
> >
> > Signed-off-by: Christian Lamparter <chunkeey-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > ---
> > drivers/usb/dwc2/params.c | 22 ++++++++++++++++++++++
> > 1 file changed, 22 insertions(+)
> >
> > diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
> > index e0fc9aa..51be266 100644
> > --- a/drivers/usb/dwc2/params.c
> > +++ b/drivers/usb/dwc2/params.c
> > @@ -1097,6 +1097,22 @@ static const char *const ahb_bursts[] = {
> > [GAHBCFG_HBSTLEN_INCR16] = "INCR16",
> > };
> >
> > +/*
> > + * This table provides AHB burst configuration for existing
> > + * device tree bindings that work poorly with the default setting.
> > + *
> > + * Note: Adding new devices to this table is discouraged.
> > + * please consider adding the "snps,ahb-burst" property
> > + * with the correct configuration to your device tree
> > + * file instead.
> > + */
> > +static const struct of_device_id dwc2_compat_ahb_bursts[] = {
> > + {
> > + .compatible = "amcc,dwc-otg",
> > + .data = (void *) GAHBCFG_HBSTLEN_INCR16,
> > + },
> > +};
> > +
> > static int dwc2_get_property_ahb_burst(struct dwc2_hsotg *hsotg)
> > {
> > struct device_node *node = hsotg->dev->of_node;
> > @@ -1107,6 +1123,12 @@ static int dwc2_get_property_ahb_burst(struct dwc2_hsotg *hsotg)
> > ret = device_property_read_string(hsotg->dev,
> > "snps,ahb-burst", &str);
> > if (ret < 0) {
> > + const struct of_device_id *match;
> > +
> > + match = of_match_node(dwc2_compat_ahb_bursts, node);
> > + if (match)
> > + ret = (int)match->data;
> > +
> > return ret;
> > } else if (of_device_is_compatible(node, "brcm,bcm2835-usb")) {
> > dev_warn(hsotg->dev,
> >
> I'd prefer if you use the binding which requires no extra code in
> dwc2.
I'm fine with either option. However it think that this would require
that either Mark or Rob would allow an exception to the "keep existing
dts the way they are) and ack the following change to the canyonlands.dts.
In that case I wouldn't need the overwrite in dwc2_get_property_ahb_burst.
Regards,
Christian
---
>From e78604cb0b8ea8db277ef9bf321a613f8e0c7129 Mon Sep 17 00:00:00 2001
From: Christian Lamparter <chunkeey-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Mon, 21 Nov 2016 21:46:19 +0100
Subject: [PATCH] powerpc/dts: set snps,ahb-burst to INCR16
The dwc2 driver defaults to INCR4 which can cause a
system hang when the USB and SATA is used concurrently.
Note: This patch requires:
"usb: dwc2: add amcc,dwc-otg support"
(which already landed in the usb subsystem queue)
and "usb: dwc2: Add AHB burst configuration"
Signed-off-by: Christian Lamparter <chunkeey-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/powerpc/boot/dts/canyonlands.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/boot/dts/canyonlands.dts b/arch/powerpc/boot/dts/canyonlands.dts
index 0d6ac92..90db712 100644
--- a/arch/powerpc/boot/dts/canyonlands.dts
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -179,6 +179,7 @@
USBOTG0: usbotg@bff80000 {
compatible = "amcc,dwc-otg";
+ snps,ahb-burst = "INCR16";
reg = <0x4 0xbff80000 0x10000>;
interrupt-parent = <&USBOTG0>;
#interrupt-cells = <1>;
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH V2 2/2] pinctrl: tegra: Add driver to configure voltage and power of io pads
From: Jon Hunter @ 2016-11-21 21:01 UTC (permalink / raw)
To: Laxman Dewangan, linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
swarren-3lzwWm7+Weoh9ZMKESR00Q,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w
Cc: gnurou-Re5JQEeQqe8AvxtiuMwx3w,
yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1478696782-11657-3-git-send-email-ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On 09/11/16 13:06, Laxman Dewangan wrote:
> NVIDIA Tegra124 and later SoCs support the multi-voltage level and
> low power state of some of its IO pads. The IO pads can work in
> the voltage of the 1.8V and 3.3V of IO voltage from IO power rail
> sources. When IO interfaces are not used then IO pads can be
> configure in low power state to reduce the power consumption from
> that IO pads.
>
> On Tegra124, the voltage level of IO power rail source is auto
> detected by hardware(SoC) and hence it is only require to configure
> in low power mode if IO pads are not used.
>
> On T210 onwards, the auto-detection of voltage level from IO power
> rail is removed from SoC and hence SW need to configure the PMC
> register explicitly to set proper voltage in IO pads based on
> IO rail power source voltage.
>
> This driver adds the IO pad driver to configure the power state and
> IO pad voltage based on the usage and power tree via pincontrol
> framework. The configuration can be static and dynamic.
>
> Signed-off-by: Laxman Dewangan <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> ---
> Changes from V1:
> - Dropped the custom properties to set pad voltage and use regulator.
> - Added support for regulator to get vottage in boot and configure IO
> pad voltage.
> - Add support for callback to handle regulator notification and configure
> IO pad voltage based on voltage change.
> ---
> drivers/pinctrl/tegra/Kconfig | 12 +
> drivers/pinctrl/tegra/Makefile | 1 +
> drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c | 488 +++++++++++++++++++++++++++
> 3 files changed, 501 insertions(+)
> create mode 100644 drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c
...
> +#define TEGRA124_PAD_INFO_TABLE(_entry_) \
> + _entry_(0, "audio", AUDIO, true, NULL), \
> + _entry_(1, "bb", BB, true, NULL), \
> + _entry_(2, "cam", CAM, true, NULL), \
> + _entry_(3, "comp", COMP, true, NULL), \
> + _entry_(4, "csia", CSIA, true, NULL), \
> + _entry_(5, "csib", CSIB, true, NULL), \
> + _entry_(6, "csie", CSIE, true, NULL), \
> + _entry_(7, "dsi", DSI, true, NULL), \
> + _entry_(8, "dsib", DSIB, true, NULL), \
> + _entry_(9, "dsic", DSIC, true, NULL), \
> + _entry_(10, "dsid", DSID, true, NULL), \
> + _entry_(11, "hdmi", HDMI, true, NULL), \
> + _entry_(12, "hsic", HSIC, true, NULL), \
> + _entry_(13, "hv", HV, true, NULL), \
> + _entry_(14, "lvds", LVDS, true, NULL), \
> + _entry_(15, "mipi-bias", MIPI_BIAS, true, NULL), \
> + _entry_(16, "nand", NAND, true, NULL), \
> + _entry_(17, "pex-bias", PEX_BIAS, true, NULL), \
> + _entry_(18, "pex-clk1", PEX_CLK1, true, NULL), \
> + _entry_(19, "pex-clk2", PEX_CLK2, true, NULL), \
> + _entry_(20, "pex-ctrl", PEX_CNTRL, true, NULL), \
> + _entry_(21, "sdmmc1", SDMMC1, true, NULL), \
> + _entry_(22, "sdmmc3", SDMMC3, true, NULL), \
> + _entry_(23, "sdmmc4", SDMMC4, true, NULL), \
> + _entry_(24, "sys-ddc", SYS_DDC, true, NULL), \
> + _entry_(25, "uart", UART, true, NULL), \
> + _entry_(26, "usb0", USB0, true, NULL), \
> + _entry_(27, "usb1", USB1, true, NULL), \
> + _entry_(28, "usb2", USB2, true, NULL), \
> + _entry_(29, "usb-bias", USB_BIAS, true, NULL)
> +
> +#define TEGRA210_PAD_INFO_TABLE(_entry_) \
> + _entry_(0, "audio", AUDIO, true, "vddio-audio"), \
> + _entry_(1, "audio-hv", AUDIO_HV, true, "vddio-audio-hv"), \
> + _entry_(2, "cam", CAM, true, "vddio-cam"), \
> + _entry_(3, "csia", CSIA, true, NULL), \
> + _entry_(4, "csib", CSIB, true, NULL), \
> + _entry_(5, "csic", CSIC, true, NULL), \
> + _entry_(6, "csid", CSID, true, NULL), \
> + _entry_(7, "csie", CSIE, true, NULL), \
> + _entry_(8, "csif", CSIF, true, NULL), \
> + _entry_(9, "dbg", DBG, true, "vddio-dbg"), \
> + _entry_(10, "debug-nonao", DEBUG_NONAO, true, NULL), \
> + _entry_(11, "dmic", DMIC, true, "vddio-dmic"), \
> + _entry_(12, "dp", DP, true, NULL), \
> + _entry_(13, "dsi", DSI, true, NULL), \
> + _entry_(14, "dsib", DSIB, true, NULL), \
> + _entry_(15, "dsic", DSIC, true, NULL), \
> + _entry_(16, "dsid", DSID, true, NULL), \
> + _entry_(17, "emmc", SDMMC4, true, NULL), \
> + _entry_(18, "emmc2", EMMC2, true, NULL), \
> + _entry_(19, "gpio", GPIO, true, "vddio-gpio"), \
> + _entry_(20, "hdmi", HDMI, true, NULL), \
> + _entry_(21, "hsic", HSIC, true, NULL), \
> + _entry_(22, "lvds", LVDS, true, NULL), \
> + _entry_(23, "mipi-bias", MIPI_BIAS, true, NULL), \
> + _entry_(24, "pex-bias", PEX_BIAS, true, NULL), \
> + _entry_(25, "pex-clk1", PEX_CLK1, true, NULL), \
> + _entry_(26, "pex-clk2", PEX_CLK2, true, NULL), \
> + _entry_(27, "pex-ctrl", PEX_CNTRL, false, "vddio-pex-ctrl"), \
> + _entry_(28, "sdmmc1", SDMMC1, true, "vddio-sdmmc1"), \
> + _entry_(29, "sdmmc3", SDMMC3, true, "vddio-sdmmc3"), \
> + _entry_(30, "spi", SPI, true, "vddio-spi"), \
> + _entry_(31, "spi-hv", SPI_HV, true, "vddio-spi-hv"), \
> + _entry_(32, "uart", UART, true, "vddio-uart"), \
> + _entry_(33, "usb0", USB0, true, NULL), \
> + _entry_(34, "usb1", USB1, true, NULL), \
> + _entry_(35, "usb2", USB2, true, NULL), \
> + _entry_(36, "usb3", USB3, true, NULL), \
> + _entry_(37, "usb-bias", USB_BIAS, true, NULL)
Can you also fix these checkpatch errors ...
ERROR: Macros with complex values should be enclosed in parentheses
#424: FILE: drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c:350:
ERROR: Macros with complex values should be enclosed in parentheses
#456: FILE: drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c:382:
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH 1/2] of: base: add support to get machine model name
From: Frank Rowand @ 2016-11-21 20:49 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Arnd Bergmann,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <58334A06.103-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 11/21/16 11:24, Frank Rowand wrote:
> On 11/21/16 08:23, Sudeep Holla wrote:
>>
>>
>> On 21/11/16 16:05, Frank Rowand wrote:
>>> Hi Sudeep,
>>>
>>> On 11/18/16 12:22, Frank Rowand wrote:
>>>> On 11/18/16 02:41, Sudeep Holla wrote:
>>>>>
>>>>>
>>>>> On 17/11/16 21:00, Frank Rowand wrote:
>>>>>> On 11/17/16 07:32, Sudeep Holla wrote:
>>>>>>> Currently platforms/drivers needing to get the machine model name are
>>>>>>> replicating the same snippet of code. In some case, the OF reference
>>>>>>> counting is either missing or incorrect.
>>>>>>>
>>>>>>> This patch adds support to read the machine model name either using
>>>>>>> the "model" or the "compatible" property in the device tree root node
>>>>>>> to the core OF/DT code.
>>>>>>>
>>>>>>> This can be used to remove all the duplicate code snippets doing exactly
>>>>>>> same thing later.
>>>>>>
>>>>>> I find five instances of reading only property "model":
>>>>>>
>>>>>> arch/arm/mach-imx/cpu.c
>>>>>> arch/arm/mach-mxs/mach-mxs.c
>>>>>> arch/c6x/kernel/setup.c
>>>>>> arch/mips/cavium-octeon/setup.c
>>>>>> arch/sh/boards/of-generic.c
>>>>>>
>>>>>
>>>>> Ah sorry you were not Cc-ed in 2/2, but that shows all the instances
>>>>> that this will be used for.
>>>>
>>>> I have not seen 2/2. I do not see it on the devicetree list or on lkml.
>>>
>>> Can you please re-send patch 2/2?
>>>
>>
>> Since it is based on -next, I would prefer to wait until next merge
>> window to resend. You should be able to check in the link I sent if
>> that's OK.
>
> I am missing or misunderstanding something.
>
> I do not know what "the link I sent" means.
Ah, the links were in the email you sent before this one, but I read this
one first. Got it now.
>
> For some reason, the devicetree mail list and lmkl mail failed to send
> me a copy of patch 2/2. Or my mail server failed to receive them. That
> is why I asked you to resend the patch. I just now looked in the devicetree
> archive and found it there.
>
> So I now can see how you plan to use the new function.
>
> -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 V2 2/2] pinctrl: tegra: Add driver to configure voltage and power of io pads
From: Jon Hunter @ 2016-11-21 20:37 UTC (permalink / raw)
To: Laxman Dewangan, linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
swarren-3lzwWm7+Weoh9ZMKESR00Q,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w
Cc: gnurou-Re5JQEeQqe8AvxtiuMwx3w,
yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <5832ED69.3090903-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On 21/11/16 12:49, Laxman Dewangan wrote:
>
> On Monday 21 November 2016 04:38 PM, Jon Hunter wrote:
>>>
>>> I had a discussion with the ASIC on this and as per them
>>> 1.8 V nominal is (1.62V, 1.98V)
>>> 3.3 V nominal is (2.97V,3.63V)
>>>
>>> I am working with them to update the TRM document but we can assume that
>>> this information will be there in TRM.
>> My feeling is that if all use-cases today are using either 1.8V or 3.3V,
>> then may be we should not worry about this and only support either 1.8V
>> or 3.3V. I would be more in favour of supporting other voltages if there
>> is a real need.
>
> Sometimes, the regulator will not return exact 1.8V or 3.3V due to the
> PMIC rail resolution. On such cases, it returns nearest voltage to 1.8V
> or 3.3V.
> That's why the PMIC resolution is considered through IO pad voltage
> tolerances.
Ok, gotcha. I can see that would be the case for when you call
regulator_get_voltage() (ie. in the probe), but what about the notifier?
I imagine that in the notifier, at least for the pre-change case, that
the voltage is the target and not the actual. So I am wondering if we
need to check for a range in the notifier?
>>>>> + const struct pinctrl_pin_desc *pins_desc;
>>>>> + int num_pins_desc;
>>>>> +};
>>>>> +
>>>>> +struct tegra_io_pads_regulator_info {
>>>>> + struct device *dev;
>>>>> + const struct tegra_io_pads_cfg_info *pads_cfg;
>>>>> + struct regulator *regulator;
>>>>> + struct notifier_block regulator_nb;
>>>>> +};
>>>> Is this struct necessary? Seems to be a lot of duplicated information
>>>> from the other structs. Why not add the regulator and regulator_nb to
>>>> the main struct? OK, not all io_pads have a regulator but you are only
>>>> saving one pointer.
>>> Yes, some of IO pads support multi-voltage.
>> Yes, but I am saying why not put this information in the main struct and
>> not bother having yet another struct where half of the information is
>> duplicated.
>
> For regulator notifier callback, we will need the driver data. If I keep
> this in the main structure then I will not able to get proper structure
> until I make that as global.
>
> The notifier registration is
> ret = devm_regulator_register_notifier(regulator,
> &rinfo->regulator_nb);
>
>
> and from the pointer of rinfo->regulator_nb, I will get the rinfo as
>
> rinfo = container_of(nb, struct tegra_io_pads_regulator_info,
> regulator_nb);
>
> if I use this in main structure then I will not be able to get the
> driver data.
Ah yes, you have an array of regulators. Make sense. However, shame to
duplicate some of this data and also would be good to avoid allocating
so much memory in probe for these structs if only a few rails actually
have regulators ...
tiopi->rinfo = devm_kzalloc(dev, sizeof(*tiopi->rinfo) *
soc_data->num_pads_cfg, GFP_KERNEL);
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH 1/2] of: base: add support to get machine model name
From: Frank Rowand @ 2016-11-21 20:21 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Arnd Bergmann,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <0f150e21-ba46-d4f2-98e8-a226eb82ca3e-5wv7dgnIgG8@public.gmane.org>
On 11/21/16 08:20, Sudeep Holla wrote:
>
>
> On 18/11/16 20:22, Frank Rowand wrote:
>> On 11/18/16 02:41, Sudeep Holla wrote:
>>>
>>>
>>> On 17/11/16 21:00, Frank Rowand wrote:
>>>> On 11/17/16 07:32, Sudeep Holla wrote:
>>>>> Currently platforms/drivers needing to get the machine model name are
>>>>> replicating the same snippet of code. In some case, the OF reference
>>>>> counting is either missing or incorrect.
>>>>>
>>>>> This patch adds support to read the machine model name either using
>>>>> the "model" or the "compatible" property in the device tree root node
>>>>> to the core OF/DT code.
>>>>>
>>>>> This can be used to remove all the duplicate code snippets doing exactly
>>>>> same thing later.
>>>>
>>>> I find five instances of reading only property "model":
>>>>
>>>> arch/arm/mach-imx/cpu.c
>>>> arch/arm/mach-mxs/mach-mxs.c
>>>> arch/c6x/kernel/setup.c
>>>> arch/mips/cavium-octeon/setup.c
>>>> arch/sh/boards/of-generic.c
>>>>
>>>
>>> Ah sorry you were not Cc-ed in 2/2, but that shows all the instances
>>> that this will be used for.
>>
>> I have not seen 2/2. I do not see it on the devicetree list or on lkml.
>>
>
> Yes on both [1][2]
>
>> I did see a list of drivers in the RFC patch that you sent several hours
>> before this patch.
>>
>> In that patch you replaced reading the model name from the _flat_ device
>> tree with the new function in at least one location. That is not
>> correct.
>>
>>
>>>
>>>> I find one instance of reading property "model", then if
>>>> that does not exist, property "compatible":
>>>>
>>>> arch/mips/generic/proc.c
Just for completeness, now that I have seen patch 2/2, there is a
second location that currently uses "compatible" if "model" does
not exist: drivers/soc/fsl/guts.c
>>>>
>>>
>>> Correct as you can check in patch 2/2
>>>
>>>> The proposed patch matches the code used in one place, and thus
>>>> current usage does not match the patch description.
>>>>
>>>
>>> Yes, but does it matter ? compatibles are somewhat informative about the
>>> model IMO.
>>
>> Yes it does matter. That is just sloppy and makes devicetree yet harder
>> to understand. It hurts clarity. The new function name says get "model",
>> not get "model" or "first element of the compatible list".
An example of a function name that would not hurt clarity would be
of_model_or_1st_compatible().
>>
>
> This is a implementation in the Linux and it doesn't change anything in
> DT semantics. I am not able to get your concern.
The existing code in five locations that patch 2/2 changes only attempt
to read the value of property "model". Changing those five locations
to use of_machine_get_model_name() results in those locations using the
first string of the "compatible" property if "model" does not exist.
The value found is potentially used to determine whether to execute
model specific code. An example of this is: octeon_pcie_pcibios_map_irq().
Can you guarantee that there is no device tree that does not contain
a "model" property in the root node, but does contains a "compatible"
property in the root node whose first value is "EBH5600"?
I have pasted the relevant code from octeon_pcie_pcibios_map_irq()
below for convenient reference:
int __init octeon_pcie_pcibios_map_irq(const struct pci_dev *dev,
u8 slot, u8 pin)
{
/*
* The EBH5600 board with the PCI to PCIe bridge mistakenly
* wires the first slot for both device id 2 and interrupt
* A. According to the PCI spec, device id 2 should be C. The
* following kludge attempts to fix this.
*/
if (strstr(octeon_board_type_string(), "EBH5600") &&
dev->bus && dev->bus->parent) {
My point is that it is not possible to review patch 2/2 to verify whether
any change in kernel behavior results from the change, because we do not
have access to all device tree sources. patch 2/2 is intended to clean
up code, not to change behavior.
>
>> And using the _first_ element only of the compatible list to determine
>> model is not a good paradigm. It is yet another hidden, special case,
>> undocumented trap to lure in the unwary.
>>
>
> The function is documented and again this doesn't enforce anything in
> the bindings. It's just the way it's used by the Linux kernel.
>
> [...]
>
>>
>> You also ignored Arnd's comment in reply to your RFC patch.
>>
>
> OK, all I can see is that Arnd wanted to reuse of_root, which I did.
> Did I miss anything else ?
>
My mistake, sorry. I misread the patch.
-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 v2 2/4] usb: dwc2: Add binding for AHB burst
From: John Youn @ 2016-11-21 20:16 UTC (permalink / raw)
To: Christian Lamparter, Rob Herring
Cc: Stefan Wahren, John Youn, Felipe Balbi,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Mark Rutland
In-Reply-To: <6396482.jQaH1ArAfZ@debian64>
On 11/18/2016 12:18 PM, Christian Lamparter wrote:
> On Friday, November 18, 2016 8:16:08 AM CET Rob Herring wrote:
>> On Thu, Nov 17, 2016 at 04:35:10PM +0100, Stefan Wahren wrote:
>>> Hi John,
>>>
>>> Am 17.11.2016 um 00:47 schrieb John Youn:
>>>> Add the "snps,ahb-burst" binding and read it in.
>>>>
>>>> This property controls which burst type to perform on the AHB bus as a
>>>> master in internal DMA mode. This overrides the legacy param value,
>>>> which we need to keep around for now since several platforms use it.
>>>>
>>>> Some platforms may see better or worse performance based on this
>>>> value. The HAPS platform is one example where all INCRx have worse
>>>> performance than INCR.
>>>>
>>>> Other platforms (such as the Canyonlands board) report that the default
>>>> value causes system hangs.
>>>>
>>>> Signed-off-by: John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
>>>> Cc: Christian Lamparter <chunkeey-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
>>>> ---
>>>> Documentation/devicetree/bindings/usb/dwc2.txt | 2 +
>>>> drivers/usb/dwc2/core.h | 9 +++++
>>>> drivers/usb/dwc2/params.c | 56 ++++++++++++++++++++++++++
>>>> 3 files changed, 67 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt
>>>> index 6c7c2bce..9e7b4b4 100644
>>>> --- a/Documentation/devicetree/bindings/usb/dwc2.txt
>>>> +++ b/Documentation/devicetree/bindings/usb/dwc2.txt
>>>
>>> according to Documentation/devicetree/bindings/submitting-patches.txt
>>> this change should be a separate patch.
>>>
>>>> @@ -26,6 +26,8 @@ Optional properties:
>>>> Refer to phy/phy-bindings.txt for generic phy consumer properties
>>>> - dr_mode: shall be one of "host", "peripheral" and "otg"
>>>> Refer to usb/generic.txt
>>>> +- snps,ahb-burst: specifies the ahb burst length. Valid arguments are:
>>>> + "SINGLE", "INCR", "INCR4", "INCR8", "INCR16". Defaults to "INCR4".
>>>
>>> This doesn't apply in case of the bcm2835. I would prefer this option is
>>> ignored in that case with a dev_warn("snps,ahb-burst is not supported on
>>> this platform").
>>
>> Also, perhaps you should allow that the compatible string can define the
>> default.
>>
> I hoped you would say that :).
>
> I've attached a patch (on top of John Youn changes) that does
> just that for the amcc,dwc-otg. I put the GAHBCFG_HBSTLEN_INCR
> value into the .data, if that's a problem, I can certainly
> respin the patch and put it in a dedicated struct.
>
> Regards
>
> Christian
> ---
> From 4c31a029dde714828810b1c3e61a5b1412ac939a Mon Sep 17 00:00:00 2001
> From: Christian Lamparter <chunkeey-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date: Fri, 18 Nov 2016 21:03:19 +0100
> Subject: [PATCH] usb: dwc2: add a default ahb-burst setting for amcc,dwc-otg
>
> This patch adds a of_device_id table which can be used by
> existing devices to supply a ahb-burst value for the platform
> without having to add a "snps,ahb-burst" entry to the dts.
>
> Note: Adding new devices to this table is discouraged.
> please consider adding the "snps,ahb-burst" property
> with the correct configuration to your device tree
> file instead.
>
> Signed-off-by: Christian Lamparter <chunkeey-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> drivers/usb/dwc2/params.c | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
> index e0fc9aa..51be266 100644
> --- a/drivers/usb/dwc2/params.c
> +++ b/drivers/usb/dwc2/params.c
> @@ -1097,6 +1097,22 @@ static const char *const ahb_bursts[] = {
> [GAHBCFG_HBSTLEN_INCR16] = "INCR16",
> };
>
> +/*
> + * This table provides AHB burst configuration for existing
> + * device tree bindings that work poorly with the default setting.
> + *
> + * Note: Adding new devices to this table is discouraged.
> + * please consider adding the "snps,ahb-burst" property
> + * with the correct configuration to your device tree
> + * file instead.
> + */
> +static const struct of_device_id dwc2_compat_ahb_bursts[] = {
> + {
> + .compatible = "amcc,dwc-otg",
> + .data = (void *) GAHBCFG_HBSTLEN_INCR16,
> + },
> +};
> +
> static int dwc2_get_property_ahb_burst(struct dwc2_hsotg *hsotg)
> {
> struct device_node *node = hsotg->dev->of_node;
> @@ -1107,6 +1123,12 @@ static int dwc2_get_property_ahb_burst(struct dwc2_hsotg *hsotg)
> ret = device_property_read_string(hsotg->dev,
> "snps,ahb-burst", &str);
> if (ret < 0) {
> + const struct of_device_id *match;
> +
> + match = of_match_node(dwc2_compat_ahb_bursts, node);
> + if (match)
> + ret = (int)match->data;
> +
> return ret;
> } else if (of_device_is_compatible(node, "brcm,bcm2835-usb")) {
> dev_warn(hsotg->dev,
>
Hi Christian,
I'd prefer if you use the binding which requires no extra code in
dwc2.
Regards,
John
--
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 3/3] ARM64: dts: meson-gxbb: add the USB reset also to the second USB PHY
From: Kevin Hilman @ 2016-11-21 20:15 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, kishon-l0cyMroinI0,
carlo-KA+7E9HrN00dnm+yROfE0A, will.deacon-5wv7dgnIgG8,
catalin.marinas-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <CAFBinCBVaQ7SLwQ0M2eJj0iyQuErF1Ev5dtGzKr7itiesy11MQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> writes:
> Hi Kevin,
>
> On Wed, Nov 16, 2016 at 10:35 PM, Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> wrote:
>> Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> writes:
>>
>>> When the USB PHY driver was introduced the reset framework did not
>>> have support for triggering a reset pulse for shared resets. On GXBB
>>> however there is only one reset line for both PHYs (meaning we have a
>>> shared reset line). With the latest changes to the reset framework and
>>> the corresponding updates to the phy-meson8b-usb2 driver we can now pass
>>> the reset to the second PHY as well.
>>>
>>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
>>
>> Applied.
> Unfortunately I think I put crucial information only in the
> cover-letter's description:
> "the dts patch has a runtime-dependency on patch 1 and 2"
I saw that, but also see that both of those have been queued, so should
land in v4.10 also.
> So please feel free to keep or drop the patch as it is. In case you
> decide drop it I will re-send it for 4.11 (after all the 4.10 stuff is
> done).
IMO, it's fine to keep it. That means there may be some versions of
linux-next that have the problem where the reset will get asserted
twice, but since that is affecting very few people (probably only you),
I think it's OK, since it will be fine once v4.10-rc1 is released.
If you don't want that, let me know and I'll drop it for now.
Kevin
--
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/2] arm64: dts: NS2: Add sdio1, PCI phys
From: Florian Fainelli @ 2016-11-21 19:27 UTC (permalink / raw)
To: Jon Mason, Rob Herring, Mark Rutland, Florian Fainelli
Cc: devicetree, bcm-kernel-feedback-list, linux-arm-kernel,
linux-kernel
In-Reply-To: <1479425103-2119-1-git-send-email-jon.mason@broadcom.com>
On 11/17/2016 03:25 PM, Jon Mason wrote:
> The second SDIO seems to have been forgotten to be enabled in the
> Northstar2 SVK dts. Also, the PCI PHY entries are missing from the PCI
> bus device tree entries.
Series applied, thanks Jon
--
Florian
^ permalink raw reply
* Re: [PATCH 1/2] of: base: add support to get machine model name
From: Frank Rowand @ 2016-11-21 19:24 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Arnd Bergmann,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <55e27115-421e-b67b-eb7a-9b1c3d662711-5wv7dgnIgG8@public.gmane.org>
On 11/21/16 08:23, Sudeep Holla wrote:
>
>
> On 21/11/16 16:05, Frank Rowand wrote:
>> Hi Sudeep,
>>
>> On 11/18/16 12:22, Frank Rowand wrote:
>>> On 11/18/16 02:41, Sudeep Holla wrote:
>>>>
>>>>
>>>> On 17/11/16 21:00, Frank Rowand wrote:
>>>>> On 11/17/16 07:32, Sudeep Holla wrote:
>>>>>> Currently platforms/drivers needing to get the machine model name are
>>>>>> replicating the same snippet of code. In some case, the OF reference
>>>>>> counting is either missing or incorrect.
>>>>>>
>>>>>> This patch adds support to read the machine model name either using
>>>>>> the "model" or the "compatible" property in the device tree root node
>>>>>> to the core OF/DT code.
>>>>>>
>>>>>> This can be used to remove all the duplicate code snippets doing exactly
>>>>>> same thing later.
>>>>>
>>>>> I find five instances of reading only property "model":
>>>>>
>>>>> arch/arm/mach-imx/cpu.c
>>>>> arch/arm/mach-mxs/mach-mxs.c
>>>>> arch/c6x/kernel/setup.c
>>>>> arch/mips/cavium-octeon/setup.c
>>>>> arch/sh/boards/of-generic.c
>>>>>
>>>>
>>>> Ah sorry you were not Cc-ed in 2/2, but that shows all the instances
>>>> that this will be used for.
>>>
>>> I have not seen 2/2. I do not see it on the devicetree list or on lkml.
>>
>> Can you please re-send patch 2/2?
>>
>
> Since it is based on -next, I would prefer to wait until next merge
> window to resend. You should be able to check in the link I sent if
> that's OK.
I am missing or misunderstanding something.
I do not know what "the link I sent" means.
For some reason, the devicetree mail list and lmkl mail failed to send
me a copy of patch 2/2. Or my mail server failed to receive them. That
is why I asked you to resend the patch. I just now looked in the devicetree
archive and found it there.
So I now can see how you plan to use the new function.
-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
* Applied "spi: sh-msiof: Add support for R-Car M3-W" to the spi tree
From: Mark Brown @ 2016-11-21 19:20 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Mark Brown
In-Reply-To: <1479749095-13548-1-git-send-email-geert+renesas@glider.be>
The patch
spi: sh-msiof: Add support for R-Car M3-W
has been applied to the spi tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From eb51cffa743de5c78cfbf44f576b0f1eccc784f4 Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Mon, 21 Nov 2016 18:24:55 +0100
Subject: [PATCH] spi: sh-msiof: Add support for R-Car M3-W
MSIOF in R-Car M3-W (r8a7796) is handled fine by the existing driver.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
Documentation/devicetree/bindings/spi/sh-msiof.txt | 1 +
drivers/spi/spi-sh-msiof.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/spi/sh-msiof.txt b/Documentation/devicetree/bindings/spi/sh-msiof.txt
index aa005c1d10d9..da6614c63796 100644
--- a/Documentation/devicetree/bindings/spi/sh-msiof.txt
+++ b/Documentation/devicetree/bindings/spi/sh-msiof.txt
@@ -10,6 +10,7 @@ Required properties:
"renesas,msiof-r8a7792" (R-Car V2H)
"renesas,msiof-r8a7793" (R-Car M2-N)
"renesas,msiof-r8a7794" (R-Car E2)
+ "renesas,msiof-r8a7796" (R-Car M3-W)
"renesas,msiof-sh73a0" (SH-Mobile AG5)
- reg : A list of offsets and lengths of the register sets for
the device.
diff --git a/drivers/spi/spi-sh-msiof.c b/drivers/spi/spi-sh-msiof.c
index 1de3a772eb7d..0012ad02e569 100644
--- a/drivers/spi/spi-sh-msiof.c
+++ b/drivers/spi/spi-sh-msiof.c
@@ -980,6 +980,7 @@ static const struct of_device_id sh_msiof_match[] = {
{ .compatible = "renesas,msiof-r8a7792", .data = &r8a779x_data },
{ .compatible = "renesas,msiof-r8a7793", .data = &r8a779x_data },
{ .compatible = "renesas,msiof-r8a7794", .data = &r8a779x_data },
+ { .compatible = "renesas,msiof-r8a7796", .data = &r8a779x_data },
{},
};
MODULE_DEVICE_TABLE(of, sh_msiof_match);
--
2.10.2
^ permalink raw reply related
* Re: [PATCH v6 0/5] drm: sun8i: Add DE2 HDMI video support
From: Ondřej Jirman @ 2016-11-21 18:42 UTC (permalink / raw)
To: moinejf-Re5JQEeQqe8AvxtiuMwx3w
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <20161121191416.706b80c25d476fa002a001b1-GANU6spQydw@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 2102 bytes --]
Dne 21.11.2016 v 19:14 Jean-Francois Moine napsal(a):
> On Mon, 21 Nov 2016 01:54:53 +0100
> Ondřej Jirman <megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org> wrote:
>
>> Dne 20.11.2016 v 12:32 Jean-Francois Moine napsal(a):
>>> This patchset series adds HDMI video support to the Allwinner
>>> sun8i SoCs which include the display engine 2 (DE2).
>>> The driver contains the code for the A83T and H3, but it could be
>>> used/extended for other SoCs as the A64, H2 and H5.
>>
>> Hi,
>>
>> I'm trying to test your patches on Orange Pi PC, and I've run into a few
>> issues: (I'm using sunxi-ng with the same patches as last time, to make
>> it work with your driver)
>>
>> 1] I just get pink output on the monitor - there's some signal, but it's
>> pink (or more like magenta).
>>
>> dmesg ouput indicates no error:
>>
>> [ 1.887823] [drm] Initialized
>> [ 1.888503] sun8i-de2 1000000.de-controller: bound
>> 1c0c000.lcd-controller (ops 0xc0a63894)
>> [ 2.057298] sun8i-de2 1000000.de-controller: bound 1ee0000.hdmi (ops
>> 0xc0a63b54)
>> [ 2.057304] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>> [ 2.057307] [drm] No driver support for vblank timestamp query.
>> [ 2.690862] Console: switching to colour frame buffer device 240x67
>> [ 2.723059] sun8i-de2 1000000.de-controller: fb0: frame buffer device
> [snip]
>
> My H3 boards work correctly, except the Orange PI 2 when it cannot read
> the EDID (but it is OK after reboot).
>
> Did you check if the EDID was correctly read?
EDID is correctly read (I verified that it is the same as with the v5
version of the driver), but there's one difference I noted. v5 says dpms
is Off, while v6 says dpms is On.
> Which resolution do you expect?
>
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v6 0/5] drm: sun8i: Add DE2 HDMI video support
From: Jean-Francois Moine @ 2016-11-21 18:14 UTC (permalink / raw)
To: Ondřej Jirman
Cc: moinejf-Re5JQEeQqe8AvxtiuMwx3w, Dave Airlie, Maxime Ripard,
Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <1c9a02ff-ce6c-7ad7-36fa-8a2ea0b7675e-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org>
On Mon, 21 Nov 2016 01:54:53 +0100
Ondřej Jirman <megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org> wrote:
> Dne 20.11.2016 v 12:32 Jean-Francois Moine napsal(a):
> > This patchset series adds HDMI video support to the Allwinner
> > sun8i SoCs which include the display engine 2 (DE2).
> > The driver contains the code for the A83T and H3, but it could be
> > used/extended for other SoCs as the A64, H2 and H5.
>
> Hi,
>
> I'm trying to test your patches on Orange Pi PC, and I've run into a few
> issues: (I'm using sunxi-ng with the same patches as last time, to make
> it work with your driver)
>
> 1] I just get pink output on the monitor - there's some signal, but it's
> pink (or more like magenta).
>
> dmesg ouput indicates no error:
>
> [ 1.887823] [drm] Initialized
> [ 1.888503] sun8i-de2 1000000.de-controller: bound
> 1c0c000.lcd-controller (ops 0xc0a63894)
> [ 2.057298] sun8i-de2 1000000.de-controller: bound 1ee0000.hdmi (ops
> 0xc0a63b54)
> [ 2.057304] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [ 2.057307] [drm] No driver support for vblank timestamp query.
> [ 2.690862] Console: switching to colour frame buffer device 240x67
> [ 2.723059] sun8i-de2 1000000.de-controller: fb0: frame buffer device
[snip]
My H3 boards work correctly, except the Orange PI 2 when it cannot read
the EDID (but it is OK after reboot).
Did you check if the EDID was correctly read?
Which resolution do you expect?
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ 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