[PATCH 00/10] ARM: tegra: Enable a bunch of functionality on Venice2

[PATCH 00/10] ARM: tegra: Enable a bunch of functionality on Venice2

[Thierry Reding]

This series of patches adds a device tree node for the PMIC on Venice2 along
with various regulators that are used for SD/MMC, eDP and USB. Note that the
first patch in this series conflicts with one already sent in by Laxman, but
when comparing both I noticed some discrepancies, so I'm posting the version
that I have tested with so that we can hopefully unify both.

There is also support for host1x and eDP on Tegra124 along with a panel node
for the Venice2. Keyboard support is also enabled by this series.

Finally the series enables the USB ports on Venice2.

Thierry

Thierry Reding (10):
  ARM: tegra: Add AS3722 PMIC on Venice2
  ARM: tegra: Hook up SDMMC3 power-supply on Venice2
  ARM: tegra: Add Tegra124 host1x support
  ARM: tegra: Add Tegra124 eDP support
  ARM: tegra: Enable eDP for Venice2
  ARM: tegra: Add SPI controller nodes for Tegra124
  ARM: tegra: Enable Venice2 keyboard
  ARM: tegra: Enable power key on Venice2
  ARM: tegra: Add Tegra124 USB support
  ARM: tegra: Enable USB on Venice2

 arch/arm/boot/dts/tegra124-venice2.dts | 399 +++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/tegra124.dtsi        | 252 +++++++++++++++++++++
 2 files changed, 651 insertions(+)

-- 
1.8.4.2

[PATCH 01/10] ARM: tegra: Add AS3722 PMIC on Venice2

[Thierry Reding]

This also adds the vmmc-supply property to the SDMMC node on Venice2.
Otherwise the core will turn the regulator off automatically because it
is unused.

Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
Note: This was taken from a ChromeOS tree.
---
 arch/arm/boot/dts/tegra124-venice2.dts | 182 +++++++++++++++++++++++++++++++++
 1 file changed, 182 insertions(+)

diff --git a/arch/arm/boot/dts/tegra124-venice2.dts b/arch/arm/boot/dts/tegra124-venice2.dts
index d6bb25c78c62..5dc0c64b7682 100644
--- a/arch/arm/boot/dts/tegra124-venice2.dts
+++ b/arch/arm/boot/dts/tegra124-venice2.dts
@@ -392,6 +392,176 @@
 	i2c@7000d000 {
 		status = "okay";
 		clock-frequency = <100000>;
+
+		pmic: pmic@40 {
+			compatible = "ams,as3722";
+			reg = <0x40>;
+			interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_LOW>;
+
+			#interrupt-cells = <2>;
+			interrupt-controller;
+
+			#gpio-cells = <2>;
+			gpio-controller;
+
+			pinctrl-names = "default";
+			pinctrl-0 = <&as3722_default>;
+
+			as3722_default: pinmux {
+				gpio0 {
+					pins = "gpio0";
+					function = "gpio";
+					bias-pull-down;
+				};
+
+				gpio1_2_4_7 {
+					pins = "gpio1", "gpio2", "gpio4",
+					       "gpio7";
+					function = "gpio";
+					bias-pull-up;
+				};
+
+				gpio3_6 {
+					pins = "gpio3", "gpio6";
+					function = "gpio";
+					bias-high-impedance;
+				};
+
+				gpio5 {
+					pins = "gpio5";
+					function = "clk32k-out";
+					bias-pull-up;
+				};
+			};
+
+			regulators {
+				vsup-sd2-supply = <&sys_5v_reg>;
+				vsup-sd3-supply = <&sys_5v_reg>;
+				vsup-sd4-supply = <&sys_5v_reg>;
+				vsup-sd5-supply = <&sys_5v_reg>;
+				vin-ldo0-supply = <&as3722_sd2>;
+				vin-ldo1-6-supply = <&sys_5v_reg>;
+				vin-ldo2-5-7-supply = <&vddio_1v8>;
+				vin-ldo3-4-supply = <&sys_5v_reg>;
+				vin-ldo9-10-supply = <&sys_5v_reg>;
+				vin-ldo11-supply = <&sys_5v_reg>;
+
+				sd0 {
+					regulator-name = "vdd_cpu";
+					regulator-min-microvolt = <700000>;
+					regulator-max-microvolt = <1350000>;
+					regulator-always-on;
+					ams,ext-control = <2>;
+				};
+
+				sd1 {
+					regulator-name = "vdd_core";
+					regulator-min-microvolt = <700000>;
+					regulator-max-microvolt = <1350000>;
+					regulator-max-microamp = <3500000>;
+					regulator-always-on;
+					ams,ext-control = <1>;
+				};
+
+				as3722_sd2: sd2 {
+					regulator-name = "vddio_ddr";
+					regulator-min-microvolt = <1350000>;
+					regulator-max-microvolt = <1350000>;
+					regulator-always-on;
+				};
+
+				sd4 {
+					regulator-name = "avdd-hdmi-pex";
+					regulator-min-microvolt = <1050000>;
+					regulator-max-microvolt = <1050000>;
+				};
+
+				vddio_1v8: sd5 {
+					regulator-name = "vdd-1v8";
+					regulator-min-microvolt = <1800000>;
+					regulator-max-microvolt = <1800000>;
+					regulator-always-on;
+				};
+
+				sd6 {
+					regulator-name = "vdd_gpu";
+					regulator-min-microvolt = <800000>;
+					regulator-max-microvolt = <1200000>;
+					regulator-boot-on;
+					regulator-always-on;
+				};
+
+				ldo0 {
+					regulator-name = "avdd-pll";
+					regulator-min-microvolt = <1050000>;
+					regulator-max-microvolt = <1050000>;
+					regulator-always-on;
+					ams,ext-control = <1>;
+				};
+
+				ldo1 {
+					regulator-name = "vdd_cam";
+					regulator-min-microvolt = <1800000>;
+					regulator-max-microvolt = <1800000>;
+				};
+
+				ldo2 {
+					regulator-name = "vddio_hsic";
+					regulator-min-microvolt = <1200000>;
+					regulator-max-microvolt = <1200000>;
+				};
+
+				ldo3 {
+					regulator-name = "vdd_rtc";
+					regulator-min-microvolt = <1000000>;
+					regulator-max-microvolt = <1000000>;
+					regulator-always-on;
+					ams,enable-tracking;
+				};
+
+				ldo4 {
+					regulator-name = "avdd_cam";
+					regulator-min-microvolt = <2800000>;
+					regulator-max-microvolt = <2800000>;
+				};
+
+				ldo5 {
+					regulator-name = "vdig";
+					regulator-min-microvolt = <1200000>;
+					regulator-max-microvolt = <1200000>;
+				};
+
+				ldo6 {
+					regulator-name = "vddio_sdmmc";
+					regulator-min-microvolt = <3300000>;
+					regulator-max-microvolt = <3300000>;
+				};
+
+				ldo7 {
+					regulator-name = "vdd_cam1";
+					regulator-min-microvolt = <1050000>;
+					regulator-max-microvolt = <1050000>;
+				};
+
+				ldo9 {
+					regulator-name = "avdd";
+					regulator-min-microvolt = <2800000>;
+					regulator-max-microvolt = <2800000>;
+				};
+
+				ldo10 {
+					regulator-name = "avdd_af1_cam";
+					regulator-min-microvolt = <2800000>;
+					regulator-max-microvolt = <2800000>;
+				};
+
+				ldo11 {
+					regulator-name = "vpp_fuse";
+					regulator-min-microvolt = <1800000>;
+					regulator-max-microvolt = <1800000>;
+				};
+			};
+		};
 	};
 
 	pmc@7000e400 {
@@ -436,6 +606,18 @@
 		};
 	};
 
+	regulators {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		sys_5v_reg: regulator@0 {
+			compatible = "regulator-fixed";
+			reg = <0>;
+			regulator-name = "sys_5v";
+		};
+	};
+
 	sound {
 		compatible = "nvidia,tegra-audio-max98090-venice2",
 			     "nvidia,tegra-audio-max98090";
-- 
1.8.4.2

Re: [PATCH 01/10] ARM: tegra: Add AS3722 PMIC on Venice2

[Stephen Warren]

On 12/19/2013 09:06 AM, Thierry Reding wrote:
> This also adds the vmmc-supply property to the SDMMC node on Venice2.
> Otherwise the core will turn the regulator off automatically because it
> is unused.

Laxman sent a version of this patch first, which I have already applied.
His version is almost a pure subset of yours. I've pointed out the
differences (other than simple naming) below so you two can work
together to resolve them.

(Laxman, as an aside, I'm not sure why you're upstreaming patches that
don't exactly match the existing kernel support for this board...)

> diff --git a/arch/arm/boot/dts/tegra124-venice2.dts b/arch/arm/boot/dts/tegra124-venice2.dts

> +				sd0 {
> +					regulator-name = "vdd_cpu";
> +					regulator-min-microvolt = <700000>;
> +					regulator-max-microvolt = <1350000>;

Laxman's patch has:

 					regulator-max-microvolt = <1400000>;


> +					regulator-always-on;
> +					ams,ext-control = <2>;
> +				};

Laxman's patch adds:

 					regulator-min-microamp = <3500000>;
 					regulator-max-microamp = <3500000>;
 					regulator-boot-on;

Those properties (with various values) are added to quite a few nodes; I
won't bother pointing them out elsewhere.


> +				sd1 {
...
> +					regulator-max-microamp = <3500000>;

Laxman's patch has:

 					regulator-max-microamp = <2500000>;

Laxman's patch adds the following node:

 				sd3 {
 					regulator-name = "vddio-ddr-2phase";
 					regulator-min-microvolt = <1350000>;
 					regulator-max-microvolt = <1350000>;
 					regulator-always-on;
 					regulator-boot-on;
 				};


> +				sd6 {
...
> +					regulator-min-microvolt = <800000>;

Laxman's patch has:

 					regulator-min-microvolt = <650000>;

> +				ldo6 {
...
> +					regulator-min-microvolt = <3300000>;

Laxman's patch has:

 					regulator-min-microvolt = <1800000>;

Re: [PATCH 01/10] ARM: tegra: Add AS3722 PMIC on Venice2

[Laxman Dewangan]

On Friday 20 December 2013 01:54 AM, Stephen Warren wrote:
> On 12/19/2013 09:06 AM, Thierry Reding wrote:

> (Laxman, as an aside, I'm not sure why you're upstreaming patches that
> don't exactly match the existing kernel support for this board...)

I did not get this based on what context it is. Can you please elaborate 
where I am missing the stuff?


>
>> diff --git a/arch/arm/boot/dts/tegra124-venice2.dts b/arch/arm/boot/dts/tegra124-venice2.dts
>> +				sd0 {
>> +					regulator-name = "vdd_cpu";
>> +					regulator-min-microvolt = <700000>;
>> +					regulator-max-microvolt = <1350000>;
> Laxman's patch has:
>
>   					regulator-max-microvolt = <1400000>;

We have the Laguna platform on which Android and L4T is running fine. 
This is based on same PMIC used for Venice2. As we are running the more 
cpu stress on Laguna, I took this parameter from the Laguna Power tree 
where it is maximum 1.4V. Chrome have maximum as 1.35mV.



>
>> +					regulator-always-on;
>> +					ams,ext-control = <2>;
>> +				};
> Laxman's patch adds:
>
>   					regulator-min-microamp = <3500000>;
>   					regulator-max-microamp = <3500000>;
>   					regulator-boot-on;
>
> Those properties (with various values) are added to quite a few nodes; I
> won't bother pointing them out elsewhere.


All rails does not support the current configuration. SD0, SD1 and SD6 
supports this. We have configured these value on Laguna as per system 
eng recommendation for this rails. As the power tree s almost same, I 
configured same here for Venice2. SD0 and SD6 on 3500mA and SD1 is on 
2500mA.



>
>> +				sd1 {
> ...
>> +					regulator-max-microamp = <3500000>;
> Laxman's patch has:
>
>   					regulator-max-microamp = <2500000>;
>
> Laxman's patch adds the following node:
>
>   				sd3 {
>   					regulator-name = "vddio-ddr-2phase";
>   					regulator-min-microvolt = <1350000>;
>   					regulator-max-microvolt = <1350000>;
>   					regulator-always-on;
>   					regulator-boot-on;
>   				};
As per schematic, SD2 and SD3 make 2 phase supply for the DDR. I added 
SD3 so that it should not get disabled at time of unused regulator 
disabled by regulator framework.
>
>> +				sd6 {
> ...
>> +					regulator-min-microvolt = <800000>;
> Laxman's patch has:
>
>   					regulator-min-microvolt = <650000>;

Again from downstream Laguna platform.

>
>> +				ldo6 {
> ...
>> +					regulator-min-microvolt = <3300000>;
> Laxman's patch has:
>
>   					regulator-min-microvolt = <1800000>;
VDDIO SDMMC and I think it is for SD3.0 (UHS) which switches voltage 
from 3.3 to 1.8 on UHS mode by sdmmc driver.

Re: [PATCH 01/10] ARM: tegra: Add AS3722 PMIC on Venice2

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1364 bytes --]

On Fri, Dec 20, 2013 at 12:23:28PM +0530, Laxman Dewangan wrote:
> On Friday 20 December 2013 01:54 AM, Stephen Warren wrote:
> >On 12/19/2013 09:06 AM, Thierry Reding wrote:
> 
> >(Laxman, as an aside, I'm not sure why you're upstreaming patches that
> >don't exactly match the existing kernel support for this board...)
> 
> I did not get this based on what context it is. Can you please elaborate
> where I am missing the stuff?
> 
> 
> >
> >>diff --git a/arch/arm/boot/dts/tegra124-venice2.dts b/arch/arm/boot/dts/tegra124-venice2.dts
> >>+				sd0 {
> >>+					regulator-name = "vdd_cpu";
> >>+					regulator-min-microvolt = <700000>;
> >>+					regulator-max-microvolt = <1350000>;
> >Laxman's patch has:
> >
> >  					regulator-max-microvolt = <1400000>;
> 
> We have the Laguna platform on which Android and L4T is running fine. This
> is based on same PMIC used for Venice2. As we are running the more cpu
> stress on Laguna, I took this parameter from the Laguna Power tree where it
> is maximum 1.4V. Chrome have maximum as 1.35mV.

Whether this is used on Android, ChromeOS or L4T doesn't matter at all.
It specifies hardware constraints and thus must be agnostic of the OS
and workload.

Also this file describes the power tree for Venice2, so using values
from Laguna is wrong, no matter how similar they are.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 01/10] ARM: tegra: Add AS3722 PMIC on Venice2

[Laxman Dewangan]

On Friday 20 December 2013 03:55 PM, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Fri, Dec 20, 2013 at 12:23:28PM +0530, Laxman Dewangan wrote:
>> On Friday 20 December 2013 01:54 AM, Stephen Warren wrote:
>>> On 12/19/2013 09:06 AM, Thierry Reding wrote:
>>> (Laxman, as an aside, I'm not sure why you're upstreaming patches that
>>> don't exactly match the existing kernel support for this board...)
>> I did not get this based on what context it is. Can you please elaborate
>> where I am missing the stuff?
>>
>>
>>>> diff --git a/arch/arm/boot/dts/tegra124-venice2.dts b/arch/arm/boot/dts/tegra124-venice2.dts
>>>> +				sd0 {
>>>> +					regulator-name = "vdd_cpu";
>>>> +					regulator-min-microvolt = <700000>;
>>>> +					regulator-max-microvolt = <1350000>;
>>> Laxman's patch has:
>>>
>>>   					regulator-max-microvolt = <1400000>;
>> We have the Laguna platform on which Android and L4T is running fine. This
>> is based on same PMIC used for Venice2. As we are running the more cpu
>> stress on Laguna, I took this parameter from the Laguna Power tree where it
>> is maximum 1.4V. Chrome have maximum as 1.35mV.
> Whether this is used on Android, ChromeOS or L4T doesn't matter at all.
> It specifies hardware constraints and thus must be agnostic of the OS
> and workload.
>
> Also this file describes the power tree for Venice2, so using values
> from Laguna is wrong, no matter how similar they are.
>

Here, I used term "similar" means the which rail is feeding to Tegra's 
which vdd?
So by this, if AMS SD0 is feeding to Tegra vdd-cpu then it should be 
same for Laguna.
This is maximum possible for Tegra cpu  from PMIC. Tegra can use desired 
voltage limited to this max based on their sku for going to maximum 
frequency.
If we program less voltage as maximum then Tegra will not go to higher 
frequency assuming PMIC limitation which is not correct.

Re: [PATCH 01/10] ARM: tegra: Add AS3722 PMIC on Venice2

[Stephen Warren]

On 12/20/2013 03:46 AM, Laxman Dewangan wrote:
> On Friday 20 December 2013 03:55 PM, Thierry Reding wrote:
>> * PGP Signed by an unknown key
>>
>> On Fri, Dec 20, 2013 at 12:23:28PM +0530, Laxman Dewangan wrote:
>>> On Friday 20 December 2013 01:54 AM, Stephen Warren wrote:
>>>> On 12/19/2013 09:06 AM, Thierry Reding wrote:
>>>> (Laxman, as an aside, I'm not sure why you're upstreaming patches that
>>>> don't exactly match the existing kernel support for this board...)
>>> I did not get this based on what context it is. Can you please elaborate
>>> where I am missing the stuff?
>>>
>>>
>>>>> diff --git a/arch/arm/boot/dts/tegra124-venice2.dts
>>>>> b/arch/arm/boot/dts/tegra124-venice2.dts
>>>>> +                sd0 {
>>>>> +                    regulator-name = "vdd_cpu";
>>>>> +                    regulator-min-microvolt = <700000>;
>>>>> +                    regulator-max-microvolt = <1350000>;
>>>> Laxman's patch has:
>>>>
>>>>                       regulator-max-microvolt = <1400000>;
>>> We have the Laguna platform on which Android and L4T is running fine.
>>> This
>>> is based on same PMIC used for Venice2. As we are running the more cpu
>>> stress on Laguna, I took this parameter from the Laguna Power tree
>>> where it
>>> is maximum 1.4V. Chrome have maximum as 1.35mV.
>> Whether this is used on Android, ChromeOS or L4T doesn't matter at all.
>> It specifies hardware constraints and thus must be agnostic of the OS
>> and workload.
>>
>> Also this file describes the power tree for Venice2, so using values
>> from Laguna is wrong, no matter how similar they are.
>>
> 
> Here, I used term "similar" means the which rail is feeding to Tegra's
> which vdd?
> So by this, if AMS SD0 is feeding to Tegra vdd-cpu then it should be
> same for Laguna.

Look, this situation is very simple. This file describe Venice2. It
doesn't matter whether Laguna "should be" similar to Venice2 or not, the
file needs to describe Venice2 and not Laguna.

Equally, we have a downstream kernel that fully supports Venice2. There
is therefore absolutely ZERO reason why we should use the downstream
Laguna board support to create the upstream Venice2 board support,
rather than using the downstream Venice2 board support to create the
upstream Venice2 board support.

Please do let me know that you fully understand this issue. If not,
future patches from you are going to need a heck of a lot more detailed
review and manual checking, rather than my trusting you got it right.

Re: [PATCH 01/10] ARM: tegra: Add AS3722 PMIC on Venice2

[Laxman Dewangan]

On Friday 20 December 2013 10:27 PM, Stephen Warren wrote:
> On 12/20/2013 03:46 AM, Laxman Dewangan wrote:
>> On Friday 20 December 2013 03:55 PM, Thierry Reding wrote:
>>> * PGP Signed by an unknown key
>>>
>>> On Fri, Dec 20, 2013 at 12:23:28PM +0530, Laxman Dewangan wrote:
>>>> On Friday 20 December 2013 01:54 AM, Stephen Warren wrote:
>>>>> On 12/19/2013 09:06 AM, Thierry Reding wrote:
>>>>> (Laxman, as an aside, I'm not sure why you're upstreaming patches that
>>>>> don't exactly match the existing kernel support for this board...)
>>>> I did not get this based on what context it is. Can you please elaborate
>>>> where I am missing the stuff?
>>>>
>>>>
>>>>>> diff --git a/arch/arm/boot/dts/tegra124-venice2.dts
>>>>>> b/arch/arm/boot/dts/tegra124-venice2.dts
>>>>>> +                sd0 {
>>>>>> +                    regulator-name = "vdd_cpu";
>>>>>> +                    regulator-min-microvolt = <700000>;
>>>>>> +                    regulator-max-microvolt = <1350000>;
>>>>> Laxman's patch has:
>>>>>
>>>>>                        regulator-max-microvolt = <1400000>;
>>>> We have the Laguna platform on which Android and L4T is running fine.
>>>> This
>>>> is based on same PMIC used for Venice2. As we are running the more cpu
>>>> stress on Laguna, I took this parameter from the Laguna Power tree
>>>> where it
>>>> is maximum 1.4V. Chrome have maximum as 1.35mV.
>>> Whether this is used on Android, ChromeOS or L4T doesn't matter at all.
>>> It specifies hardware constraints and thus must be agnostic of the OS
>>> and workload.
>>>
>>> Also this file describes the power tree for Venice2, so using values
>>> from Laguna is wrong, no matter how similar they are.
>>>
>> Here, I used term "similar" means the which rail is feeding to Tegra's
>> which vdd?
>> So by this, if AMS SD0 is feeding to Tegra vdd-cpu then it should be
>> same for Laguna.
> Look, this situation is very simple. This file describe Venice2. It
> doesn't matter whether Laguna "should be" similar to Venice2 or not, the
> file needs to describe Venice2 and not Laguna.
>
> Equally, we have a downstream kernel that fully supports Venice2. There
> is therefore absolutely ZERO reason why we should use the downstream
> Laguna board support to create the upstream Venice2 board support,
> rather than using the downstream Venice2 board support to create the
> upstream Venice2 board support.
>
> Please do let me know that you fully understand this issue. If not,
> future patches from you are going to need a heck of a lot more detailed
> review and manual checking, rather than my trusting you got it right.

I like to continue this discussion internally so that we can have proper 
expectations before sending patches.

Re: [PATCH 01/10] ARM: tegra: Add AS3722 PMIC on Venice2

[Stephen Warren]

On 12/19/2013 09:06 AM, Thierry Reding wrote:
> This also adds the vmmc-supply property to the SDMMC node on Venice2.
> Otherwise the core will turn the regulator off automatically because it
> is unused.

Note: If I revert Laxman's "" and apply your patches 01/10 and 02/10 in
its place, then I see the following during boot, and audio playback
doesn't work any more:

> [   14.768649] max98090 0-0010: ASoC: Right Receiver Mixer DAPM update failed: -121
> [   14.776715] max98090 0-0010: ASoC: Left Receiver Mixer DAPM update failed: -121
> [   14.784601] max98090 0-0010: ASoC: Right Speaker Mixer DAPM update failed: -121
> [   14.792602] max98090 0-0010: ASoC: Left Speaker Mixer DAPM update failed: -121
> [   14.800423] max98090 0-0010: ASoC: Right Headphone Mixer DAPM update failed: -121
> [   14.808655] max98090 0-0010: ASoC: Left Headphone Mixer DAPM update failed: -121
> [   14.817628] max98090 0-0010: ASoC: Right ADC Mixer DAPM update failed: -121
> [   14.825582] max98090 0-0010: ASoC: Left ADC Mixer DAPM update failed: -121

Re: [PATCH 01/10] ARM: tegra: Add AS3722 PMIC on Venice2

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1552 bytes --]

On Thu, Dec 19, 2013 at 02:47:09PM -0700, Stephen Warren wrote:
> On 12/19/2013 09:06 AM, Thierry Reding wrote:
> > This also adds the vmmc-supply property to the SDMMC node on Venice2.
> > Otherwise the core will turn the regulator off automatically because it
> > is unused.
> 
> Note: If I revert Laxman's "" and apply your patches 01/10 and 02/10 in
> its place, then I see the following during boot, and audio playback
> doesn't work any more:
> 
> > [   14.768649] max98090 0-0010: ASoC: Right Receiver Mixer DAPM update failed: -121
> > [   14.776715] max98090 0-0010: ASoC: Left Receiver Mixer DAPM update failed: -121
> > [   14.784601] max98090 0-0010: ASoC: Right Speaker Mixer DAPM update failed: -121
> > [   14.792602] max98090 0-0010: ASoC: Left Speaker Mixer DAPM update failed: -121
> > [   14.800423] max98090 0-0010: ASoC: Right Headphone Mixer DAPM update failed: -121
> > [   14.808655] max98090 0-0010: ASoC: Left Headphone Mixer DAPM update failed: -121
> > [   14.817628] max98090 0-0010: ASoC: Right ADC Mixer DAPM update failed: -121
> > [   14.825582] max98090 0-0010: ASoC: Left ADC Mixer DAPM update failed: -121

That's odd, I don't those errors in my local tree. When I try to play
back audio I do get this one:

	[  380.093679] max98090 0-0010: No audio clocks configured

But other than that everything seems to work fine. I don't hear anything
on the speakers or the headphones, but I'm likely missing the proper
mixer settings. Can you provide an asound.conf that works for you?

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 01/10] ARM: tegra: Add AS3722 PMIC on Venice2

[Stephen Warren]

On 12/20/2013 04:14 AM, Thierry Reding wrote:
> On Thu, Dec 19, 2013 at 02:47:09PM -0700, Stephen Warren wrote:
>> On 12/19/2013 09:06 AM, Thierry Reding wrote:
>>> This also adds the vmmc-supply property to the SDMMC node on Venice2.
>>> Otherwise the core will turn the regulator off automatically because it
>>> is unused.
>>
>> Note: If I revert Laxman's "" and apply your patches 01/10 and 02/10 in
>> its place, then I see the following during boot, and audio playback
>> doesn't work any more:
>>
>>> [   14.768649] max98090 0-0010: ASoC: Right Receiver Mixer DAPM update failed: -121
>>> [   14.776715] max98090 0-0010: ASoC: Left Receiver Mixer DAPM update failed: -121
>>> [   14.784601] max98090 0-0010: ASoC: Right Speaker Mixer DAPM update failed: -121
>>> [   14.792602] max98090 0-0010: ASoC: Left Speaker Mixer DAPM update failed: -121
>>> [   14.800423] max98090 0-0010: ASoC: Right Headphone Mixer DAPM update failed: -121
>>> [   14.808655] max98090 0-0010: ASoC: Left Headphone Mixer DAPM update failed: -121
>>> [   14.817628] max98090 0-0010: ASoC: Right ADC Mixer DAPM update failed: -121
>>> [   14.825582] max98090 0-0010: ASoC: Left ADC Mixer DAPM update failed: -121
> 
> That's odd, I don't those errors in my local tree. When I try to play
> back audio I do get this one:
> 
> 	[  380.093679] max98090 0-0010: No audio clocks configured

I do see that too. In practice it's harmless since audio does work, and
I /think/ it's really a false startup-condition error from the CODEC
driver, but I need to investigate it sometime.

> But other than that everything seems to work fine. I don't hear anything
> on the speakers or the headphones, but I'm likely missing the proper
> mixer settings. Can you provide an asound.conf that works for you?

Yes, you will need to configure the mixer. Our internal kernel testing
wiki page has asound.state attached. I'll send you a link to that
internally.

[PATCH 02/10] ARM: tegra: Hook up SDMMC3 power-supply on Venice2

[Thierry Reding]

The SDMMC3 interface is supplied with 1.8V by the PMICs LDO6.

Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
 arch/arm/boot/dts/tegra124-venice2.dts | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/tegra124-venice2.dts b/arch/arm/boot/dts/tegra124-venice2.dts
index 5dc0c64b7682..7a4d5e23ddf4 100644
--- a/arch/arm/boot/dts/tegra124-venice2.dts
+++ b/arch/arm/boot/dts/tegra124-venice2.dts
@@ -531,7 +531,7 @@
 					regulator-max-microvolt = <1200000>;
 				};
 
-				ldo6 {
+				vddio_sdmmc3: ldo6 {
 					regulator-name = "vddio_sdmmc";
 					regulator-min-microvolt = <3300000>;
 					regulator-max-microvolt = <3300000>;
@@ -580,6 +580,7 @@
 		power-gpios = <&gpio TEGRA_GPIO(R, 0) GPIO_ACTIVE_HIGH>;
 		status = "okay";
 		bus-width = <4>;
+		vmmc-supply = <&vddio_sdmmc3>;
 	};
 
 	sdhci@700b0600 {
-- 
1.8.4.2

[PATCH 03/10] ARM: tegra: Add Tegra124 host1x support

[Thierry Reding]

Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
 arch/arm/boot/dts/tegra124.dtsi | 37 +++++++++++++++++++++++++++++++++++++
 1 file changed, 37 insertions(+)

diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index ec0698a8354a..0a4e5271b5f9 100644
--- a/arch/arm/boot/dts/tegra124.dtsi
+++ b/arch/arm/boot/dts/tegra124.dtsi
@@ -9,6 +9,43 @@
 	compatible = "nvidia,tegra124";
 	interrupt-parent = <&gic>;
 
+	host1x@50000000 {
+		compatible = "nvidia,tegra124-host1x", "simple-bus";
+		reg = <0x50000000 0x00034000>;
+		interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>, /* syncpt */
+			     <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>; /* general */
+		clocks = <&tegra_car TEGRA124_CLK_HOST1X>;
+		resets = <&tegra_car 28>;
+		reset-names = "host1x";
+
+		#address-cells = <1>;
+		#size-cells = <1>;
+
+		ranges = <0x54000000 0x54000000 0x01000000>;
+
+		dc@54200000 {
+			compatible = "nvidia,tegra124-dc";
+			reg = <0x54200000 0x00040000>;
+			interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&tegra_car TEGRA124_CLK_DISP1>,
+				 <&tegra_car TEGRA124_CLK_PLL_P>;
+			clock-names = "dc", "parent";
+			resets = <&tegra_car 27>;
+			reset-names = "dc";
+		};
+
+		dc@54240000 {
+			compatible = "nvidia,tegra124-dc";
+			reg = <0x54240000 0x00040000>;
+			interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&tegra_car TEGRA124_CLK_DISP2>,
+				 <&tegra_car TEGRA124_CLK_PLL_P>;
+			clock-names = "dc", "parent";
+			resets = <&tegra_car 26>;
+			reset-names = "dc";
+		};
+	};
+
 	gic: interrupt-controller@50041000 {
 		compatible = "arm,cortex-a15-gic";
 		#interrupt-cells = <3>;
-- 
1.8.4.2

[PATCH 04/10] ARM: tegra: Add Tegra124 eDP support

[Thierry Reding]

Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
 arch/arm/boot/dts/tegra124.dtsi | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index 0a4e5271b5f9..39d77aa936f9 100644
--- a/arch/arm/boot/dts/tegra124.dtsi
+++ b/arch/arm/boot/dts/tegra124.dtsi
@@ -44,6 +44,32 @@
 			resets = <&tegra_car 26>;
 			reset-names = "dc";
 		};
+
+		sor@54540000 {
+			compatible = "nvidia,tegra124-sor";
+			reg = <0x54540000 0x00040000>;
+			interrupts = <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&tegra_car TEGRA124_CLK_SOR0>,
+				 <&tegra_car TEGRA124_CLK_PLL_D_OUT0>,
+				 <&tegra_car TEGRA124_CLK_PLL_DP>,
+				 <&tegra_car TEGRA124_CLK_CLK_M>;
+			clock-names = "sor", "parent", "dp", "safe";
+			resets = <&tegra_car 182>;
+			reset-names = "sor";
+			status = "disabled";
+		};
+
+		dpaux@545c0000 {
+			compatible = "nvidia,tegra124-dpaux";
+			reg = <0x545c0000 0x00040000>;
+			interrupts = <GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&tegra_car TEGRA124_CLK_DPAUX>,
+				 <&tegra_car TEGRA124_CLK_PLL_DP>;
+			clock-names = "dpaux", "parent";
+			resets = <&tegra_car 181>;
+			reset-names = "dpaux";
+			status = "disabled";
+		};
 	};
 
 	gic: interrupt-controller@50041000 {
-- 
1.8.4.2

Re: [PATCH 04/10] ARM: tegra: Add Tegra124 eDP support

[Stephen Warren]

On 12/19/2013 09:06 AM, Thierry Reding wrote:

> diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi

> +		sor@54540000 {
> +			compatible = "nvidia,tegra124-sor";

I don't see a binding document for that compatible value anywhere in
next-20131219, nor in your drm/for-next branch. Still, the DT
content/schema is essentially identical to many others that already
exist, so I won't block applying the series because of that. Please do
write a binding document though!

> +		dpaux@545c0000 {
> +			compatible = "nvidia,tegra124-dpaux";

Same comment.

Re: [PATCH 04/10] ARM: tegra: Add Tegra124 eDP support

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 940 bytes --]

On Thu, Dec 19, 2013 at 01:46:13PM -0700, Stephen Warren wrote:
> On 12/19/2013 09:06 AM, Thierry Reding wrote:
> 
> > diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
> 
> > +		sor@54540000 {
> > +			compatible = "nvidia,tegra124-sor";
> 
> I don't see a binding document for that compatible value anywhere in
> next-20131219, nor in your drm/for-next branch. Still, the DT
> content/schema is essentially identical to many others that already
> exist, so I won't block applying the series because of that. Please do
> write a binding document though!
> 
> > +		dpaux@545c0000 {
> > +			compatible = "nvidia,tegra124-dpaux";
> 
> Same comment.

The binding documentation for those nodes is part of the eDP patch
that's still awaiting internal review, that's why it hasn't appeared yet
in linux-next or my drm/for-next branch. I'm hoping that will happen any
day now, though.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

[PATCH 05/10] ARM: tegra: Enable eDP for Venice2

[Thierry Reding]

Venice2 has a 12.9" (2560x1700) panel connected to the eDP output of the
Tegra124. The panel has an EDID to describe the video timings but needs
a few extra nodes to get the backlight to come up.

Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
 arch/arm/boot/dts/tegra124-venice2.dts | 52 ++++++++++++++++++++++++++++++++++
 1 file changed, 52 insertions(+)

diff --git a/arch/arm/boot/dts/tegra124-venice2.dts b/arch/arm/boot/dts/tegra124-venice2.dts
index 7a4d5e23ddf4..b435cb5ec664 100644
--- a/arch/arm/boot/dts/tegra124-venice2.dts
+++ b/arch/arm/boot/dts/tegra124-venice2.dts
@@ -10,6 +10,20 @@
 		reg = <0x80000000 0x80000000>;
 	};
 
+	host1x@50000000 {
+		sor@54540000 {
+			status = "okay";
+
+			nvidia,dpaux = <&dpaux>;
+			nvidia,panel = <&panel>;
+		};
+
+		dpaux: dpaux@545c0000 {
+			vdd-supply = <&vdd_edp>;
+			status = "okay";
+		};
+	};
+
 	pinmux: pinmux@70000868 {
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinmux_default>;
@@ -594,6 +608,17 @@
 		};
 	};
 
+	backlight: backlight {
+		compatible = "pwm-backlight";
+
+		enable-gpios = <&gpio TEGRA_GPIO(H, 2) GPIO_ACTIVE_HIGH>;
+		power-supply = <&vdd_led>;
+		pwms = <&pwm 1 1000000>;
+
+		brightness-levels = <0 4 8 16 32 64 128 255>;
+		default-brightness-level = <6>;
+	};
+
 	clocks {
 		compatible = "simple-bus";
 		#address-cells = <1>;
@@ -607,6 +632,13 @@
 		};
 	};
 
+	panel: panel {
+		compatible = "lg,lp129qe", "simple-panel";
+
+		backlight = <&backlight>;
+		ddc-i2c-bus = <&dpaux>;
+	};
+
 	regulators {
 		compatible = "simple-bus";
 		#address-cells = <1>;
@@ -617,6 +649,26 @@
 			reg = <0>;
 			regulator-name = "sys_5v";
 		};
+
+		vdd_edp: regulator@1 {
+			compatible = "regulator-fixed";
+			reg = <1>;
+			regulator-name = "avdd_lcd";
+			regulator-min-microvolt = <3300000>;
+			regulator-max-microvolt = <3300000>;
+			gpio = <&pmic 4 0 GPIO_ACTIVE_HIGH>;
+			enable-active-high;
+		};
+
+		vdd_led: regulator@2 {
+			compatible = "regulator-fixed";
+			reg = <2>;
+			regulator-name = "vdd_led";
+			regulator-min-microvolt = <45000000>;
+			regulator-max-microvolt = <45000000>;
+			gpio = <&gpio TEGRA_GPIO(P, 2) 0 GPIO_ACTIVE_HIGH>;
+			enable-active-high;
+		};
 	};
 
 	sound {
-- 
1.8.4.2

Re: [PATCH 05/10] ARM: tegra: Enable eDP for Venice2

[Stephen Warren]

On 12/19/2013 09:06 AM, Thierry Reding wrote:
> Venice2 has a 12.9" (2560x1700) panel connected to the eDP output of the
> Tegra124. The panel has an EDID to describe the video timings but needs
> a few extra nodes to get the backlight to come up.

I started with next-20131219, merged your latest drm/for-next branch,
and this doesn't seem to work.

With Laxman's regulator patch applied and your 1/10 dropped since it's a
duplicate, the LCD backlight doesn't light up. I extracted the following
from this patch to fix Laxman's regulator definitions:

                        gpio = <&gpio TEGRA_GPIO(P, 2) GPIO_ACTIVE_LOW>;
+                       enable-active-high;
                };

and the backlight does light up, but that's all.

With Laxman's regulator patch reverted and your patch 1/10 applied to
replace it, I see the backlight working without having to manually fix
up the device tree. However, that's still all; nothing is actually
displayed.

Again, can you please rebase this whole series on the latest Tegra
for-3.14/dt and sort out the issues? Thanks.

Re: [PATCH 05/10] ARM: tegra: Enable eDP for Venice2

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1830 bytes --]

On Thu, Dec 19, 2013 at 02:40:23PM -0700, Stephen Warren wrote:
> On 12/19/2013 09:06 AM, Thierry Reding wrote:
> > Venice2 has a 12.9" (2560x1700) panel connected to the eDP output of the
> > Tegra124. The panel has an EDID to describe the video timings but needs
> > a few extra nodes to get the backlight to come up.
> 
> I started with next-20131219, merged your latest drm/for-next branch,
> and this doesn't seem to work.
> 
> With Laxman's regulator patch applied and your 1/10 dropped since it's a
> duplicate, the LCD backlight doesn't light up. I extracted the following
> from this patch to fix Laxman's regulator definitions:
> 
>                         gpio = <&gpio TEGRA_GPIO(P, 2) GPIO_ACTIVE_LOW>;
> +                       enable-active-high;
>                 };
> 
> and the backlight does light up, but that's all.
> 
> With Laxman's regulator patch reverted and your patch 1/10 applied to
> replace it, I see the backlight working without having to manually fix
> up the device tree. However, that's still all; nothing is actually
> displayed.

Nothing's displayed because the driver isn't actually there yet. It's
still stuck in internal review for some reason.

I should've probably been explicit about that.

> Again, can you please rebase this whole series on the latest Tegra
> for-3.14/dt and sort out the issues? Thanks.

Grmpf... yes, I suppose I'll go do that then. That's exactly the reason
why I said the other day that we shouldn't be adding regulators
willy-nilly without any means of actually testing.

We've seen this happen on Dalmore before, and it's now happening with
Venice2. The same applies to pinmux. If we keep having to correct the
DTS files because it was all applied at once "to avoid churn" we're not
actually gaining anything.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 05/10] ARM: tegra: Enable eDP for Venice2

[Stephen Warren]

On 12/20/2013 03:20 AM, Thierry Reding wrote:
> On Thu, Dec 19, 2013 at 02:40:23PM -0700, Stephen Warren wrote:
>> On 12/19/2013 09:06 AM, Thierry Reding wrote:
>>> Venice2 has a 12.9" (2560x1700) panel connected to the eDP output of the
>>> Tegra124. The panel has an EDID to describe the video timings but needs
>>> a few extra nodes to get the backlight to come up.
>>
>> I started with next-20131219, merged your latest drm/for-next branch,
>> and this doesn't seem to work.
>>
>> With Laxman's regulator patch applied and your 1/10 dropped since it's a
>> duplicate, the LCD backlight doesn't light up. I extracted the following
>> from this patch to fix Laxman's regulator definitions:
>>
>>                         gpio = <&gpio TEGRA_GPIO(P, 2) GPIO_ACTIVE_LOW>;
>> +                       enable-active-high;
>>                 };
>>
>> and the backlight does light up, but that's all.
>>
>> With Laxman's regulator patch reverted and your patch 1/10 applied to
>> replace it, I see the backlight working without having to manually fix
>> up the device tree. However, that's still all; nothing is actually
>> displayed.
> 
> Nothing's displayed because the driver isn't actually there yet. It's
> still stuck in internal review for some reason.
> 
> I should've probably been explicit about that.
> 
>> Again, can you please rebase this whole series on the latest Tegra
>> for-3.14/dt and sort out the issues? Thanks.
> 
> Grmpf... yes, I suppose I'll go do that then. That's exactly the reason
> why I said the other day that we shouldn't be adding regulators
> willy-nilly without any means of actually testing.
> 
> We've seen this happen on Dalmore before, and it's now happening with
> Venice2. The same applies to pinmux. If we keep having to correct the
> DTS files because it was all applied at once "to avoid churn" we're not
> actually gaining anything.

Sorry. My original thoughts were that the schematics and specifications
are all completely available (internally) for these boards, as is a
complete known-working/tested DT for the board, so it's a relatively
simple exercise to take that and upstream it. As such, if we just did
all that in one go, it'd reduce churn by making a single patch to do the
whole thing once, rather than having lots of patches that build the
configuration up bit-by-bit. There's also the issue that we really do
need to set up the complete pinctrl configuration once up-front, to
avoid conflicts due to the same HW block being routed to multiple sets
of pins.

That's what I was thinking anyway. Evidently, I was wrong:-( Sorry.

[PATCH 06/10] ARM: tegra: Add SPI controller nodes for Tegra124

[Thierry Reding]

The SPI controllers on Tegra124 are compatible with those found on the
Tegra114 SoC.

Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
 arch/arm/boot/dts/tegra124.dtsi | 90 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 90 insertions(+)

diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index 39d77aa936f9..cf4558257e8c 100644
--- a/arch/arm/boot/dts/tegra124.dtsi
+++ b/arch/arm/boot/dts/tegra124.dtsi
@@ -430,6 +430,96 @@
 		status = "disabled";
 	};
 
+	spi@7000d400 {
+		compatible = "nvidia,tegra124-spi", "nvidia,tegra114-spi";
+		reg = <0x7000d400 0x200>;
+		interrupts = <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		clocks = <&tegra_car TEGRA124_CLK_SBC1>;
+		clock-names = "spi";
+		resets = <&tegra_car 41>;
+		reset-names = "spi";
+		dmas = <&apbdma 15>, <&apbdma 15>;
+		dma-names = "rx", "tx";
+		status = "disabled";
+	};
+
+	spi@7000d600 {
+		compatible = "nvidia,tegra124-spi", "nvidia,tegra114-spi";
+		reg = <0x7000d600 0x200>;
+		interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		clocks = <&tegra_car TEGRA124_CLK_SBC2>;
+		clock-names = "spi";
+		resets = <&tegra_car 44>;
+		reset-names = "spi";
+		dmas = <&apbdma 16>, <&apbdma 16>;
+		dma-names = "rx", "tx";
+		status = "disabled";
+	};
+
+	spi@7000d800 {
+		compatible = "nvidia,tegra124-spi", "nvidia,tegra114-spi";
+		reg = <0x7000d800 0x200>;
+		interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		clocks = <&tegra_car TEGRA124_CLK_SBC3>;
+		clock-names = "spi";
+		resets = <&tegra_car 46>;
+		reset-names = "spi";
+		dmas = <&apbdma 17>, <&apbdma 17>;
+		dma-names = "rx", "tx";
+		status = "disabled";
+	};
+
+	spi@7000da00 {
+		compatible = "nvidia,tegra124-spi", "nvidia,tegra114-spi";
+		reg = <0x7000da00 0x200>;
+		interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		clocks = <&tegra_car TEGRA124_CLK_SBC4>;
+		clock-names = "spi";
+		resets = <&tegra_car 68>;
+		reset-names = "spi";
+		dmas = <&apbdma 18>, <&apbdma 18>;
+		dma-names = "rx", "tx";
+		status = "disabled";
+	};
+
+	spi@7000dc00 {
+		compatible = "nvidia,tegra124-spi", "nvidia,tegra114-spi";
+		reg = <0x7000dc00 0x200>;
+		interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		clocks = <&tegra_car TEGRA124_CLK_SBC5>;
+		clock-names = "spi";
+		resets = <&tegra_car 104>;
+		reset-names = "spi";
+		dmas = <&apbdma 27>, <&apbdma 27>;
+		dma-names = "rx", "tx";
+		status = "disabled";
+	};
+
+	spi@7000de00 {
+		compatible = "nvidia,tegra124-spi", "nvidia,tegra114-spi";
+		reg = <0x7000de00 0x200>;
+		interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		clocks = <&tegra_car TEGRA124_CLK_SBC6>;
+		clock-names = "spi";
+		resets = <&tegra_car 105>;
+		reset-names = "spi";
+		dmas = <&apbdma 28>, <&apbdma 28>;
+		dma-names = "rx", "tx";
+		status = "disabled";
+	};
+
 	rtc@7000e000 {
 		compatible = "nvidia,tegra124-rtc", "nvidia,tegra20-rtc";
 		reg = <0x7000e000 0x100>;
-- 
1.8.4.2

Re: [PATCH 06/10] ARM: tegra: Add SPI controller nodes for Tegra124

[Stephen Warren]

On 12/19/2013 09:06 AM, Thierry Reding wrote:
> The SPI controllers on Tegra124 are compatible with those found on the
> Tegra114 SoC.

This patch is already in Tegra's for-3.14/dt branch.

Re: [PATCH 06/10] ARM: tegra: Add SPI controller nodes for Tegra124

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 393 bytes --]

On Thu, Dec 19, 2013 at 01:38:28PM -0700, Stephen Warren wrote:
> On 12/19/2013 09:06 AM, Thierry Reding wrote:
> > The SPI controllers on Tegra124 are compatible with those found on the
> > Tegra114 SoC.
> 
> This patch is already in Tegra's for-3.14/dt branch.

Okay, hadn't seen it in linux-next yet, so I included it in case anyone
was going to give this series a try.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

[PATCH 07/10] ARM: tegra: Enable Venice2 keyboard

[Thierry Reding]

The keyboard on Venice2 is attached to the ChromeOS embedded controller.
Add the corresponding device tree nodes and use the MATRIX_KEY define to
encode keycodes.

Signed-off-by: Rhyland Klein <rklein-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
 arch/arm/boot/dts/tegra124-venice2.dts | 107 +++++++++++++++++++++++++++++++++
 1 file changed, 107 insertions(+)

diff --git a/arch/arm/boot/dts/tegra124-venice2.dts b/arch/arm/boot/dts/tegra124-venice2.dts
index b435cb5ec664..0f6ff681b14b 100644
--- a/arch/arm/boot/dts/tegra124-venice2.dts
+++ b/arch/arm/boot/dts/tegra124-venice2.dts
@@ -1,5 +1,6 @@
 /dts-v1/;
 
+#include <dt-bindings/input/input.h>
 #include "tegra124.dtsi"
 
 / {
@@ -578,6 +579,112 @@
 		};
 	};
 
+	spi@7000d400 {
+		status = "okay";
+
+		cros-ec@0 {
+			compatible = "google,cros-ec-spi";
+			spi-max-frequency = <4000000>;
+			interrupt-parent = <&gpio>;
+			interrupts = <TEGRA_GPIO(C, 7) IRQ_TYPE_LEVEL_LOW>;
+			reg = <0>;
+
+			google,cros-ec-spi-msg-delay = <2000>;
+
+			cros-ec-keyb {
+				compatible = "google,cros-ec-keyb";
+				keypad,num-rows = <8>;
+				keypad,num-columns = <13>;
+				google,needs-ghost-filter;
+
+				linux,keymap = <
+					MATRIX_KEY(0x00, 0x01, KEY_LEFTMETA)
+					MATRIX_KEY(0x00, 0x02, KEY_F1)
+					MATRIX_KEY(0x00, 0x03, KEY_B)
+					MATRIX_KEY(0x00, 0x04, KEY_F10)
+					MATRIX_KEY(0x00, 0x06, KEY_N)
+					MATRIX_KEY(0x00, 0x08, KEY_EQUAL)
+					MATRIX_KEY(0x00, 0x0a, KEY_RIGHTALT)
+
+					MATRIX_KEY(0x01, 0x01, KEY_ESC)
+					MATRIX_KEY(0x01, 0x02, KEY_F4)
+					MATRIX_KEY(0x01, 0x03, KEY_G)
+					MATRIX_KEY(0x01, 0x04, KEY_F7)
+					MATRIX_KEY(0x01, 0x06, KEY_H)
+					MATRIX_KEY(0x01, 0x08, KEY_APOSTROPHE)
+					MATRIX_KEY(0x01, 0x09, KEY_F9)
+					MATRIX_KEY(0x01, 0x0b, KEY_BACKSPACE)
+
+					MATRIX_KEY(0x02, 0x00, KEY_LEFTCTRL)
+					MATRIX_KEY(0x02, 0x01, KEY_TAB)
+					MATRIX_KEY(0x02, 0x02, KEY_F3)
+					MATRIX_KEY(0x02, 0x03, KEY_T)
+					MATRIX_KEY(0x02, 0x04, KEY_F6)
+					MATRIX_KEY(0x02, 0x05, KEY_RIGHTBRACE)
+					MATRIX_KEY(0x02, 0x06, KEY_Y)
+					MATRIX_KEY(0x02, 0x07, KEY_102ND)
+					MATRIX_KEY(0x02, 0x08, KEY_LEFTBRACE)
+					MATRIX_KEY(0x02, 0x09, KEY_F8)
+
+					MATRIX_KEY(0x03, 0x01, KEY_GRAVE)
+					MATRIX_KEY(0x03, 0x02, KEY_F2)
+					MATRIX_KEY(0x03, 0x03, KEY_5)
+					MATRIX_KEY(0x03, 0x04, KEY_F5)
+					MATRIX_KEY(0x03, 0x06, KEY_6)
+					MATRIX_KEY(0x03, 0x08, KEY_MINUS)
+					MATRIX_KEY(0x03, 0x0b, KEY_BACKSLASH)
+
+					MATRIX_KEY(0x04, 0x00, KEY_RIGHTCTRL)
+					MATRIX_KEY(0x04, 0x01, KEY_A)
+					MATRIX_KEY(0x04, 0x02, KEY_D)
+					MATRIX_KEY(0x04, 0x03, KEY_F)
+					MATRIX_KEY(0x04, 0x04, KEY_S)
+					MATRIX_KEY(0x04, 0x05, KEY_K)
+					MATRIX_KEY(0x04, 0x06, KEY_J)
+					MATRIX_KEY(0x04, 0x08, KEY_SEMICOLON)
+					MATRIX_KEY(0x04, 0x09, KEY_L)
+					MATRIX_KEY(0x04, 0x0a, KEY_BACKSLASH)
+					MATRIX_KEY(0x04, 0x0b, KEY_ENTER)
+
+					MATRIX_KEY(0x05, 0x01, KEY_Z)
+					MATRIX_KEY(0x05, 0x02, KEY_C)
+					MATRIX_KEY(0x05, 0x03, KEY_V)
+					MATRIX_KEY(0x05, 0x04, KEY_X)
+					MATRIX_KEY(0x05, 0x05, KEY_COMMA)
+					MATRIX_KEY(0x05, 0x06, KEY_M)
+					MATRIX_KEY(0x05, 0x07, KEY_LEFTSHIFT)
+					MATRIX_KEY(0x05, 0x08, KEY_SLASH)
+					MATRIX_KEY(0x05, 0x09, KEY_DOT)
+					MATRIX_KEY(0x05, 0x0b, KEY_SPACE)
+
+					MATRIX_KEY(0x06, 0x01, KEY_1)
+					MATRIX_KEY(0x06, 0x02, KEY_3)
+					MATRIX_KEY(0x06, 0x03, KEY_4)
+					MATRIX_KEY(0x06, 0x04, KEY_2)
+					MATRIX_KEY(0x06, 0x05, KEY_8)
+					MATRIX_KEY(0x06, 0x06, KEY_7)
+					MATRIX_KEY(0x06, 0x08, KEY_0)
+					MATRIX_KEY(0x06, 0x09, KEY_9)
+					MATRIX_KEY(0x06, 0x0a, KEY_LEFTALT)
+					MATRIX_KEY(0x06, 0x0b, KEY_DOWN)
+					MATRIX_KEY(0x06, 0x0c, KEY_RIGHT)
+
+					MATRIX_KEY(0x07, 0x01, KEY_Q)
+					MATRIX_KEY(0x07, 0x02, KEY_E)
+					MATRIX_KEY(0x07, 0x03, KEY_R)
+					MATRIX_KEY(0x07, 0x04, KEY_W)
+					MATRIX_KEY(0x07, 0x05, KEY_I)
+					MATRIX_KEY(0x07, 0x06, KEY_U)
+					MATRIX_KEY(0x07, 0x07, KEY_RIGHTSHIFT)
+					MATRIX_KEY(0x07, 0x08, KEY_P)
+					MATRIX_KEY(0x07, 0x09, KEY_O)
+					MATRIX_KEY(0x07, 0x0b, KEY_UP)
+					MATRIX_KEY(0x07, 0x0c, KEY_LEFT)
+				>;
+			};
+		};
+	};
+
 	pmc@7000e400 {
 		nvidia,invert-interrupt;
 		nvidia,suspend-mode = <1>;
-- 
1.8.4.2

Re: [PATCH 07/10] ARM: tegra: Enable Venice2 keyboard

[Stephen Warren]

On 12/19/2013 09:06 AM, Thierry Reding wrote:
> The keyboard on Venice2 is attached to the ChromeOS embedded controller.
> Add the corresponding device tree nodes and use the MATRIX_KEY define to
> encode keycodes.

Patches 7/10 and 8/10 do work fine with the current pinmux/regulator
setup in Tegra's for-3.14/dt, so I have applied those patches.

[PATCH 08/10] ARM: tegra: Enable power key on Venice2

[Thierry Reding]

Contrary to the rest of the keyboard, which is connected to the ChromeOS
embedded controller, the power key is hooked up to a GPIO. Add a device
tree node to handle it.

Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
 arch/arm/boot/dts/tegra124-venice2.dts | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/tegra124-venice2.dts b/arch/arm/boot/dts/tegra124-venice2.dts
index 0f6ff681b14b..b770e903fabb 100644
--- a/arch/arm/boot/dts/tegra124-venice2.dts
+++ b/arch/arm/boot/dts/tegra124-venice2.dts
@@ -739,6 +739,18 @@
 		};
 	};
 
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		power {
+			label = "Power";
+			gpios = <&gpio TEGRA_GPIO(Q, 0) GPIO_ACTIVE_LOW>;
+			linux,code = <KEY_POWER>;
+			debounce-interval = <10>;
+			gpio-key,wakeup;
+		};
+	};
+
 	panel: panel {
 		compatible = "lg,lp129qe", "simple-panel";
 
-- 
1.8.4.2

[PATCH 09/10] ARM: tegra: Add Tegra124 USB support

[Thierry Reding]

The USB controllers on Tegra124 are backwards-compatible with those
found on Tegra30.

Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
 arch/arm/boot/dts/tegra124.dtsi | 99 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 99 insertions(+)

diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index cf4558257e8c..a2ebe8972ea0 100644
--- a/arch/arm/boot/dts/tegra124.dtsi
+++ b/arch/arm/boot/dts/tegra124.dtsi
@@ -677,6 +677,105 @@
 		};
 	};
 
+	usb@7d000000 {
+		compatible = "nvidia,tegra30-ehci", "usb-ehci";
+		reg = <0x7d000000 0x4000>;
+		interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
+		phy_type = "utmi";
+		clocks = <&tegra_car TEGRA124_CLK_USBD>;
+		resets = <&tegra_car 22>;
+		reset-names = "usb";
+		nvidia,phy = <&phy1>;
+		status = "disabled";
+	};
+
+	phy1: usb-phy@7d000000 {
+		compatible = "nvidia,tegra30-usb-phy";
+		reg = <0x7d000000 0x4000 0x7d000000 0x4000>;
+		phy_type = "utmi";
+		clocks = <&tegra_car TEGRA124_CLK_USBD>,
+			 <&tegra_car TEGRA124_CLK_PLL_U>,
+			 <&tegra_car TEGRA124_CLK_USBD>;
+		clock-names = "reg", "pll_u", "utmi-pads";
+		nvidia,hssync-start-delay = <0>;
+		nvidia,idle-wait-delay = <17>;
+		nvidia,elastic-limit = <16>;
+		nvidia,term-range-adj = <6>;
+		nvidia,xcvr-setup = <9>;
+		nvidia,xcvr-lsfslew = <0>;
+		nvidia,xcvr-lsrslew = <3>;
+		nvidia,hssquelch-level = <2>;
+		nvidia,hsdiscon-level = <5>;
+		nvidia,xcvr-hsslew = <12>;
+		status = "disabled";
+	};
+
+	usb@7d004000 {
+		compatible = "nvidia,tegra30-ehci", "usb-ehci";
+		reg = <0x7d004000 0x4000>;
+		interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+		phy_type = "utmi";
+		clocks = <&tegra_car TEGRA124_CLK_USB2>;
+		resets = <&tegra_car 58>;
+		reset-names = "usb";
+		nvidia,phy = <&phy2>;
+		status = "disabled";
+	};
+
+	phy2: usb-phy@7d004000 {
+		compatible = "nvidia,tegra30-usb-phy";
+		reg = <0x7d004000 0x4000 0x7d000000 0x4000>;
+		phy_type = "utmi";
+		clocks = <&tegra_car TEGRA124_CLK_USB2>,
+			 <&tegra_car TEGRA124_CLK_PLL_U>,
+			 <&tegra_car TEGRA124_CLK_USBD>;
+		clock-names = "reg", "pll_u", "utmi-pads";
+		nvidia,hssync-start-delay = <0>;
+		nvidia,idle-wait-delay = <17>;
+		nvidia,elastic-limit = <16>;
+		nvidia,term-range-adj = <6>;
+		nvidia,xcvr-setup = <9>;
+		nvidia,xcvr-lsfslew = <0>;
+		nvidia,xcvr-lsrslew = <3>;
+		nvidia,hssquelch-level = <2>;
+		nvidia,hsdiscon-level = <5>;
+		nvidia,xcvr-hsslew = <12>;
+		status = "disabled";
+	};
+
+	usb@7d008000 {
+		compatible = "nvidia,tegra30-ehci", "usb-ehci";
+		reg = <0x7d008000 0x4000>;
+		interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>;
+		phy_type = "utmi";
+		clocks = <&tegra_car TEGRA124_CLK_USB3>;
+		resets = <&tegra_car 59>;
+		reset-names = "usb";
+		nvidia,phy = <&phy3>;
+		status = "disabled";
+	};
+
+	phy3: usb-phy@7d008000 {
+		compatible = "nvidia,tegra30-usb-phy";
+		reg = <0x7d008000 0x4000 0x7d000000 0x4000>;
+		phy_type = "utmi";
+		clocks = <&tegra_car TEGRA124_CLK_USB3>,
+			 <&tegra_car TEGRA124_CLK_PLL_U>,
+			 <&tegra_car TEGRA124_CLK_USBD>;
+		clock-names = "reg", "pll_u", "utmi-pads";
+		nvidia,hssync-start-delay = <0>;
+		nvidia,idle-wait-delay = <17>;
+		nvidia,elastic-limit = <16>;
+		nvidia,term-range-adj = <6>;
+		nvidia,xcvr-setup = <9>;
+		nvidia,xcvr-lsfslew = <0>;
+		nvidia,xcvr-lsrslew = <3>;
+		nvidia,hssquelch-level = <2>;
+		nvidia,hsdiscon-level = <5>;
+		nvidia,xcvr-hsslew = <12>;
+		status = "disabled";
+	};
+
 	cpus {
 		#address-cells = <1>;
 		#size-cells = <0>;
-- 
1.8.4.2

[PATCH 10/10] ARM: tegra: Enable USB on Venice2

[Thierry Reding]

USB1 and USB3 are routed to two external connectors, while USB2 is used
for the integrated webcam.

Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
Note: connecting a USB mouse to USB3 works properly and lsusb also detects
the integrated webcam, though I haven't tested whether the camera actually
works.

USB1 doesn't seem to work, but I suspect that might just be because it's
used for recovery mode and we can't switch it around at runtime yet.
---
 arch/arm/boot/dts/tegra124-venice2.dts | 47 +++++++++++++++++++++++++++++++++-
 1 file changed, 46 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/tegra124-venice2.dts b/arch/arm/boot/dts/tegra124-venice2.dts
index b770e903fabb..efdf93e6f5cc 100644
--- a/arch/arm/boot/dts/tegra124-venice2.dts
+++ b/arch/arm/boot/dts/tegra124-venice2.dts
@@ -534,7 +534,7 @@
 					ams,enable-tracking;
 				};
 
-				ldo4 {
+				cam_2v8_reg: ldo4 {
 					regulator-name = "avdd_cam";
 					regulator-min-microvolt = <2800000>;
 					regulator-max-microvolt = <2800000>;
@@ -715,6 +715,33 @@
 		};
 	};
 
+	usb@7d000000 {
+		status = "okay";
+	};
+
+	usb-phy@7d000000 {
+		status = "okay";
+		vbus-supply = <&usb1_vbus_reg>;
+	};
+
+	usb@7d004000 {
+		status = "okay";
+	};
+
+	usb-phy@7d004000 {
+		status = "okay";
+		vbus-supply = <&cam_2v8_reg>;
+	};
+
+	usb@7d008000 {
+		status = "okay";
+	};
+
+	usb-phy@7d008000 {
+		status = "okay";
+		vbus-supply = <&usb3_vbus_reg>;
+	};
+
 	backlight: backlight {
 		compatible = "pwm-backlight";
 
@@ -788,6 +815,24 @@
 			gpio = <&gpio TEGRA_GPIO(P, 2) 0 GPIO_ACTIVE_HIGH>;
 			enable-active-high;
 		};
+
+		usb1_vbus_reg: regulator@3 {
+			compatible = "regulator-fixed";
+			reg = <3>;
+			regulator-name = "usb1_vbus";
+			regulator-min-microvolt = <5000000>;
+			regulator-max-microvolt = <5000000>;
+			regulator-boot-on;
+		};
+
+		usb3_vbus_reg: regulator@4 {
+			compatible = "regulator-fixed";
+			reg = <4>;
+			regulator-name = "usb3_vbus";
+			regulator-min-microvolt = <5000000>;
+			regulator-max-microvolt = <5000000>;
+			regulator-boot-on;
+		};
 	};
 
 	sound {
-- 
1.8.4.2

Re: [PATCH 10/10] ARM: tegra: Enable USB on Venice2

[Stephen Warren]

On 12/19/2013 09:06 AM, Thierry Reding wrote:
> USB1 and USB3 are routed to two external connectors, while USB2 is used
> for the integrated webcam.
> 
> Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> Note: connecting a USB mouse to USB3 works properly and lsusb also detects
> the integrated webcam, though I haven't tested whether the camera actually
> works.
> 
> USB1 doesn't seem to work, but I suspect that might just be because it's
> used for recovery mode and we can't switch it around at runtime yet.

The two regulators you added don't actually hook up to any GPIOs for
control of VBUS, so perhaps this isn't surprising. The regulators added
for VBUS control by Laxman's patch (which I already applied) *do* have
some gpio properties. However, testing indicates:

* With Laxman's patch applied, and your patch 1/10 not applied since
it's a duplicate, this patch doesn't work, i.e. I see no USB devices.

* With Laxman's patch reverted and your patch 1/10 replacing it, I do
see USB devices, and they work. However, then we're not actually
controlling VBUS, so USB1 doesn't work.

Can you please rebase this whole series on the latest Tegra for-3.14/dt
and sort out the issues? Thanks.

Re: [PATCH 10/10] ARM: tegra: Enable USB on Venice2

[Jim Lin]

About USB1 issue, for chips after Tegra30 (including Tegra30), BIASPD is
controlled by USB1 controller.
In ehci-tegra.c probe phase, we assert reset and deassert reset on
controller clock.
If initializing sequence follows USB1 and then USB2, we are safe.
If initializing sequence follows USB2 and then USB1, then in
phy-tegra-usb.c a counter utmip_pad_count which has been increased for
USB2 will prevent UTMIP_BIASPD from being cleared while initializing for
USB1 controller (UTMIP_BIASPD will be set again after asserting and
deasserting reset on USB1 controller clock in ehci-tegra.c probe for
USB1 controller).

There are several ways to fix.
The local workaround I use is as following in phy-tegra-usb.c.

static void utmip_pad_power_on(struct tegra_usb_phy *phy)
{
	unsigned long val, flags;
	void __iomem *base = phy->pad_regs;
	struct tegra_utmip_config *config = phy->config;

	clk_prepare_enable(phy->pad_clk);

	spin_lock_irqsave(&utmip_pad_lock, flags);

	val = readl(base + UTMIP_BIAS_CFG0);
	if ((utmip_pad_count++ == 0) || (val & UTMIP_BIASPD)) {
		val &= ~(UTMIP_OTGPD | UTMIP_BIASPD)

On Fri, 2013-12-20 at 05:37 +0800, Stephen Warren wrote:
> On 12/19/2013 09:06 AM, Thierry Reding wrote:
> > USB1 and USB3 are routed to two external connectors, while USB2 is used
> > for the integrated webcam.
> > 
> > Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > ---
> > Note: connecting a USB mouse to USB3 works properly and lsusb also detects
> > the integrated webcam, though I haven't tested whether the camera actually
> > works.
> > 
> > USB1 doesn't seem to work, but I suspect that might just be because it's
> > used for recovery mode and we can't switch it around at runtime yet.
> 
> The two regulators you added don't actually hook up to any GPIOs for
> control of VBUS, so perhaps this isn't surprising. The regulators added
> for VBUS control by Laxman's patch (which I already applied) *do* have
> some gpio properties. However, testing indicates:
> 
> * With Laxman's patch applied, and your patch 1/10 not applied since
> it's a duplicate, this patch doesn't work, i.e. I see no USB devices.
> 
> * With Laxman's patch reverted and your patch 1/10 replacing it, I do
> see USB devices, and they work. However, then we're not actually
> controlling VBUS, so USB1 doesn't work.
> 
> Can you please rebase this whole series on the latest Tegra for-3.14/dt
> and sort out the issues? Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--nvpublic 

Re: [PATCH 10/10] ARM: tegra: Enable USB on Venice2

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1653 bytes --]

On Thu, Dec 19, 2013 at 02:37:36PM -0700, Stephen Warren wrote:
> On 12/19/2013 09:06 AM, Thierry Reding wrote:
> > USB1 and USB3 are routed to two external connectors, while USB2 is used
> > for the integrated webcam.
> > 
> > Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > ---
> > Note: connecting a USB mouse to USB3 works properly and lsusb also detects
> > the integrated webcam, though I haven't tested whether the camera actually
> > works.
> > 
> > USB1 doesn't seem to work, but I suspect that might just be because it's
> > used for recovery mode and we can't switch it around at runtime yet.
> 
> The two regulators you added don't actually hook up to any GPIOs for
> control of VBUS, so perhaps this isn't surprising. The regulators added
> for VBUS control by Laxman's patch (which I already applied) *do* have
> some gpio properties. However, testing indicates:
> 
> * With Laxman's patch applied, and your patch 1/10 not applied since
> it's a duplicate, this patch doesn't work, i.e. I see no USB devices.
> 
> * With Laxman's patch reverted and your patch 1/10 replacing it, I do
> see USB devices, and they work. However, then we're not actually
> controlling VBUS, so USB1 doesn't work.
> 
> Can you please rebase this whole series on the latest Tegra for-3.14/dt
> and sort out the issues? Thanks.

I've looked into this a bit, but I don't see why it isn't working. The
PN4 and PN5 are the correct GPIOs for USB1 and USB3 VBUS, but hooking
them up indeed breaks things. For some reason adding those even causes
the camera on USB2 to not work properly.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]