* [PATCH 01/10] ARM: tegra: Add AS3722 PMIC on Venice2
2013-12-19 16:06 [PATCH 00/10] ARM: tegra: Enable a bunch of functionality on Venice2 Thierry Reding
@ 2013-12-19 16:06 ` Thierry Reding
2013-12-19 20:24 ` Stephen Warren
2013-12-19 21:47 ` Stephen Warren
2013-12-19 16:06 ` [PATCH 02/10] ARM: tegra: Hook up SDMMC3 power-supply " Thierry Reding
` (8 subsequent siblings)
9 siblings, 2 replies; 31+ messages in thread
From: Thierry Reding @ 2013-12-19 16:06 UTC (permalink / raw)
To: linux-arm-kernel
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@nvidia.com>
---
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 at 7000d000 {
status = "okay";
clock-frequency = <100000>;
+
+ pmic: pmic at 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 at 7000e400 {
@@ -436,6 +606,18 @@
};
};
+ regulators {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sys_5v_reg: regulator at 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
^ permalink raw reply related [flat|nested] 31+ messages in thread* [PATCH 01/10] ARM: tegra: Add AS3722 PMIC on Venice2
2013-12-19 16:06 ` [PATCH 01/10] ARM: tegra: Add AS3722 PMIC " Thierry Reding
@ 2013-12-19 20:24 ` Stephen Warren
2013-12-20 6:53 ` Laxman Dewangan
2013-12-19 21:47 ` Stephen Warren
1 sibling, 1 reply; 31+ messages in thread
From: Stephen Warren @ 2013-12-19 20:24 UTC (permalink / raw)
To: linux-arm-kernel
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>;
^ permalink raw reply [flat|nested] 31+ messages in thread* [PATCH 01/10] ARM: tegra: Add AS3722 PMIC on Venice2
2013-12-19 20:24 ` Stephen Warren
@ 2013-12-20 6:53 ` Laxman Dewangan
2013-12-20 10:25 ` Thierry Reding
0 siblings, 1 reply; 31+ messages in thread
From: Laxman Dewangan @ 2013-12-20 6:53 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 31+ messages in thread* [PATCH 01/10] ARM: tegra: Add AS3722 PMIC on Venice2
2013-12-20 6:53 ` Laxman Dewangan
@ 2013-12-20 10:25 ` Thierry Reding
2013-12-20 10:46 ` Laxman Dewangan
0 siblings, 1 reply; 31+ messages in thread
From: Thierry Reding @ 2013-12-20 10:25 UTC (permalink / raw)
To: linux-arm-kernel
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131220/3c9b9058/attachment.sig>
^ permalink raw reply [flat|nested] 31+ messages in thread* [PATCH 01/10] ARM: tegra: Add AS3722 PMIC on Venice2
2013-12-20 10:25 ` Thierry Reding
@ 2013-12-20 10:46 ` Laxman Dewangan
2013-12-20 16:57 ` Stephen Warren
0 siblings, 1 reply; 31+ messages in thread
From: Laxman Dewangan @ 2013-12-20 10:46 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 31+ messages in thread* [PATCH 01/10] ARM: tegra: Add AS3722 PMIC on Venice2
2013-12-20 10:46 ` Laxman Dewangan
@ 2013-12-20 16:57 ` Stephen Warren
2013-12-20 17:25 ` Laxman Dewangan
0 siblings, 1 reply; 31+ messages in thread
From: Stephen Warren @ 2013-12-20 16:57 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 31+ messages in thread* [PATCH 01/10] ARM: tegra: Add AS3722 PMIC on Venice2
2013-12-20 16:57 ` Stephen Warren
@ 2013-12-20 17:25 ` Laxman Dewangan
0 siblings, 0 replies; 31+ messages in thread
From: Laxman Dewangan @ 2013-12-20 17:25 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* [PATCH 01/10] ARM: tegra: Add AS3722 PMIC on Venice2
2013-12-19 16:06 ` [PATCH 01/10] ARM: tegra: Add AS3722 PMIC " Thierry Reding
2013-12-19 20:24 ` Stephen Warren
@ 2013-12-19 21:47 ` Stephen Warren
2013-12-20 11:14 ` Thierry Reding
1 sibling, 1 reply; 31+ messages in thread
From: Stephen Warren @ 2013-12-19 21:47 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 31+ messages in thread
* [PATCH 01/10] ARM: tegra: Add AS3722 PMIC on Venice2
2013-12-19 21:47 ` Stephen Warren
@ 2013-12-20 11:14 ` Thierry Reding
2013-12-20 17:02 ` Stephen Warren
0 siblings, 1 reply; 31+ messages in thread
From: Thierry Reding @ 2013-12-20 11:14 UTC (permalink / raw)
To: linux-arm-kernel
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131220/63ea49d8/attachment-0001.sig>
^ permalink raw reply [flat|nested] 31+ messages in thread
* [PATCH 01/10] ARM: tegra: Add AS3722 PMIC on Venice2
2013-12-20 11:14 ` Thierry Reding
@ 2013-12-20 17:02 ` Stephen Warren
0 siblings, 0 replies; 31+ messages in thread
From: Stephen Warren @ 2013-12-20 17:02 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* [PATCH 02/10] ARM: tegra: Hook up SDMMC3 power-supply on Venice2
2013-12-19 16:06 [PATCH 00/10] ARM: tegra: Enable a bunch of functionality on Venice2 Thierry Reding
2013-12-19 16:06 ` [PATCH 01/10] ARM: tegra: Add AS3722 PMIC " Thierry Reding
@ 2013-12-19 16:06 ` Thierry Reding
2013-12-19 16:06 ` [PATCH 03/10] ARM: tegra: Add Tegra124 host1x support Thierry Reding
` (7 subsequent siblings)
9 siblings, 0 replies; 31+ messages in thread
From: Thierry Reding @ 2013-12-19 16:06 UTC (permalink / raw)
To: linux-arm-kernel
The SDMMC3 interface is supplied with 1.8V by the PMICs LDO6.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
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 at 700b0600 {
--
1.8.4.2
^ permalink raw reply related [flat|nested] 31+ messages in thread* [PATCH 03/10] ARM: tegra: Add Tegra124 host1x support
2013-12-19 16:06 [PATCH 00/10] ARM: tegra: Enable a bunch of functionality on Venice2 Thierry Reding
2013-12-19 16:06 ` [PATCH 01/10] ARM: tegra: Add AS3722 PMIC " Thierry Reding
2013-12-19 16:06 ` [PATCH 02/10] ARM: tegra: Hook up SDMMC3 power-supply " Thierry Reding
@ 2013-12-19 16:06 ` Thierry Reding
2013-12-19 16:06 ` [PATCH 04/10] ARM: tegra: Add Tegra124 eDP support Thierry Reding
` (6 subsequent siblings)
9 siblings, 0 replies; 31+ messages in thread
From: Thierry Reding @ 2013-12-19 16:06 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
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 at 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 at 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 at 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 at 50041000 {
compatible = "arm,cortex-a15-gic";
#interrupt-cells = <3>;
--
1.8.4.2
^ permalink raw reply related [flat|nested] 31+ messages in thread* [PATCH 04/10] ARM: tegra: Add Tegra124 eDP support
2013-12-19 16:06 [PATCH 00/10] ARM: tegra: Enable a bunch of functionality on Venice2 Thierry Reding
` (2 preceding siblings ...)
2013-12-19 16:06 ` [PATCH 03/10] ARM: tegra: Add Tegra124 host1x support Thierry Reding
@ 2013-12-19 16:06 ` Thierry Reding
2013-12-19 20:46 ` Stephen Warren
2013-12-19 16:06 ` [PATCH 05/10] ARM: tegra: Enable eDP for Venice2 Thierry Reding
` (5 subsequent siblings)
9 siblings, 1 reply; 31+ messages in thread
From: Thierry Reding @ 2013-12-19 16:06 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
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 at 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 at 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 at 50041000 {
--
1.8.4.2
^ permalink raw reply related [flat|nested] 31+ messages in thread* [PATCH 04/10] ARM: tegra: Add Tegra124 eDP support
2013-12-19 16:06 ` [PATCH 04/10] ARM: tegra: Add Tegra124 eDP support Thierry Reding
@ 2013-12-19 20:46 ` Stephen Warren
2013-12-20 11:17 ` Thierry Reding
0 siblings, 1 reply; 31+ messages in thread
From: Stephen Warren @ 2013-12-19 20:46 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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 at 545c0000 {
> + compatible = "nvidia,tegra124-dpaux";
Same comment.
^ permalink raw reply [flat|nested] 31+ messages in thread* [PATCH 04/10] ARM: tegra: Add Tegra124 eDP support
2013-12-19 20:46 ` Stephen Warren
@ 2013-12-20 11:17 ` Thierry Reding
0 siblings, 0 replies; 31+ messages in thread
From: Thierry Reding @ 2013-12-20 11:17 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131220/78ec0c0d/attachment.sig>
^ permalink raw reply [flat|nested] 31+ messages in thread
* [PATCH 05/10] ARM: tegra: Enable eDP for Venice2
2013-12-19 16:06 [PATCH 00/10] ARM: tegra: Enable a bunch of functionality on Venice2 Thierry Reding
` (3 preceding siblings ...)
2013-12-19 16:06 ` [PATCH 04/10] ARM: tegra: Add Tegra124 eDP support Thierry Reding
@ 2013-12-19 16:06 ` Thierry Reding
2013-12-19 21:40 ` Stephen Warren
2013-12-19 16:06 ` [PATCH 06/10] ARM: tegra: Add SPI controller nodes for Tegra124 Thierry Reding
` (4 subsequent siblings)
9 siblings, 1 reply; 31+ messages in thread
From: Thierry Reding @ 2013-12-19 16:06 UTC (permalink / raw)
To: linux-arm-kernel
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@nvidia.com>
---
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 at 50000000 {
+ sor at 54540000 {
+ status = "okay";
+
+ nvidia,dpaux = <&dpaux>;
+ nvidia,panel = <&panel>;
+ };
+
+ dpaux: dpaux at 545c0000 {
+ vdd-supply = <&vdd_edp>;
+ status = "okay";
+ };
+ };
+
pinmux: pinmux at 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 at 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 at 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
^ permalink raw reply related [flat|nested] 31+ messages in thread* [PATCH 05/10] ARM: tegra: Enable eDP for Venice2
2013-12-19 16:06 ` [PATCH 05/10] ARM: tegra: Enable eDP for Venice2 Thierry Reding
@ 2013-12-19 21:40 ` Stephen Warren
2013-12-20 10:20 ` Thierry Reding
0 siblings, 1 reply; 31+ messages in thread
From: Stephen Warren @ 2013-12-19 21:40 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 31+ messages in thread* [PATCH 05/10] ARM: tegra: Enable eDP for Venice2
2013-12-19 21:40 ` Stephen Warren
@ 2013-12-20 10:20 ` Thierry Reding
2013-12-20 17:01 ` Stephen Warren
0 siblings, 1 reply; 31+ messages in thread
From: Thierry Reding @ 2013-12-20 10:20 UTC (permalink / raw)
To: linux-arm-kernel
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131220/25f9c68b/attachment-0001.sig>
^ permalink raw reply [flat|nested] 31+ messages in thread
* [PATCH 05/10] ARM: tegra: Enable eDP for Venice2
2013-12-20 10:20 ` Thierry Reding
@ 2013-12-20 17:01 ` Stephen Warren
0 siblings, 0 replies; 31+ messages in thread
From: Stephen Warren @ 2013-12-20 17:01 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* [PATCH 06/10] ARM: tegra: Add SPI controller nodes for Tegra124
2013-12-19 16:06 [PATCH 00/10] ARM: tegra: Enable a bunch of functionality on Venice2 Thierry Reding
` (4 preceding siblings ...)
2013-12-19 16:06 ` [PATCH 05/10] ARM: tegra: Enable eDP for Venice2 Thierry Reding
@ 2013-12-19 16:06 ` Thierry Reding
2013-12-19 20:38 ` Stephen Warren
2013-12-19 16:06 ` [PATCH 07/10] ARM: tegra: Enable Venice2 keyboard Thierry Reding
` (3 subsequent siblings)
9 siblings, 1 reply; 31+ messages in thread
From: Thierry Reding @ 2013-12-19 16:06 UTC (permalink / raw)
To: linux-arm-kernel
The SPI controllers on Tegra124 are compatible with those found on the
Tegra114 SoC.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
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 at 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 at 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 at 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 at 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 at 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 at 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 at 7000e000 {
compatible = "nvidia,tegra124-rtc", "nvidia,tegra20-rtc";
reg = <0x7000e000 0x100>;
--
1.8.4.2
^ permalink raw reply related [flat|nested] 31+ messages in thread* [PATCH 07/10] ARM: tegra: Enable Venice2 keyboard
2013-12-19 16:06 [PATCH 00/10] ARM: tegra: Enable a bunch of functionality on Venice2 Thierry Reding
` (5 preceding siblings ...)
2013-12-19 16:06 ` [PATCH 06/10] ARM: tegra: Add SPI controller nodes for Tegra124 Thierry Reding
@ 2013-12-19 16:06 ` Thierry Reding
2013-12-20 17:56 ` Stephen Warren
2013-12-19 16:06 ` [PATCH 08/10] ARM: tegra: Enable power key on Venice2 Thierry Reding
` (2 subsequent siblings)
9 siblings, 1 reply; 31+ messages in thread
From: Thierry Reding @ 2013-12-19 16:06 UTC (permalink / raw)
To: linux-arm-kernel
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@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
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 at 7000d400 {
+ status = "okay";
+
+ cros-ec at 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 at 7000e400 {
nvidia,invert-interrupt;
nvidia,suspend-mode = <1>;
--
1.8.4.2
^ permalink raw reply related [flat|nested] 31+ messages in thread* [PATCH 08/10] ARM: tegra: Enable power key on Venice2
2013-12-19 16:06 [PATCH 00/10] ARM: tegra: Enable a bunch of functionality on Venice2 Thierry Reding
` (6 preceding siblings ...)
2013-12-19 16:06 ` [PATCH 07/10] ARM: tegra: Enable Venice2 keyboard Thierry Reding
@ 2013-12-19 16:06 ` Thierry Reding
2013-12-19 16:06 ` [PATCH 09/10] ARM: tegra: Add Tegra124 USB support Thierry Reding
2013-12-19 16:06 ` [PATCH 10/10] ARM: tegra: Enable USB on Venice2 Thierry Reding
9 siblings, 0 replies; 31+ messages in thread
From: Thierry Reding @ 2013-12-19 16:06 UTC (permalink / raw)
To: linux-arm-kernel
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@nvidia.com>
---
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
^ permalink raw reply related [flat|nested] 31+ messages in thread* [PATCH 09/10] ARM: tegra: Add Tegra124 USB support
2013-12-19 16:06 [PATCH 00/10] ARM: tegra: Enable a bunch of functionality on Venice2 Thierry Reding
` (7 preceding siblings ...)
2013-12-19 16:06 ` [PATCH 08/10] ARM: tegra: Enable power key on Venice2 Thierry Reding
@ 2013-12-19 16:06 ` Thierry Reding
2013-12-19 16:06 ` [PATCH 10/10] ARM: tegra: Enable USB on Venice2 Thierry Reding
9 siblings, 0 replies; 31+ messages in thread
From: Thierry Reding @ 2013-12-19 16:06 UTC (permalink / raw)
To: linux-arm-kernel
The USB controllers on Tegra124 are backwards-compatible with those
found on Tegra30.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
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 at 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 at 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 at 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 at 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 at 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 at 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
^ permalink raw reply related [flat|nested] 31+ messages in thread* [PATCH 10/10] ARM: tegra: Enable USB on Venice2
2013-12-19 16:06 [PATCH 00/10] ARM: tegra: Enable a bunch of functionality on Venice2 Thierry Reding
` (8 preceding siblings ...)
2013-12-19 16:06 ` [PATCH 09/10] ARM: tegra: Add Tegra124 USB support Thierry Reding
@ 2013-12-19 16:06 ` Thierry Reding
2013-12-19 21:37 ` Stephen Warren
9 siblings, 1 reply; 31+ messages in thread
From: Thierry Reding @ 2013-12-19 16:06 UTC (permalink / raw)
To: linux-arm-kernel
USB1 and USB3 are routed to two external connectors, while USB2 is used
for the integrated webcam.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
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 at 7d000000 {
+ status = "okay";
+ };
+
+ usb-phy at 7d000000 {
+ status = "okay";
+ vbus-supply = <&usb1_vbus_reg>;
+ };
+
+ usb at 7d004000 {
+ status = "okay";
+ };
+
+ usb-phy at 7d004000 {
+ status = "okay";
+ vbus-supply = <&cam_2v8_reg>;
+ };
+
+ usb at 7d008000 {
+ status = "okay";
+ };
+
+ usb-phy at 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 at 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 at 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
^ permalink raw reply related [flat|nested] 31+ messages in thread* [PATCH 10/10] ARM: tegra: Enable USB on Venice2
2013-12-19 16:06 ` [PATCH 10/10] ARM: tegra: Enable USB on Venice2 Thierry Reding
@ 2013-12-19 21:37 ` Stephen Warren
2013-12-20 2:59 ` Jim Lin
2013-12-20 11:53 ` Thierry Reding
0 siblings, 2 replies; 31+ messages in thread
From: Stephen Warren @ 2013-12-19 21:37 UTC (permalink / raw)
To: linux-arm-kernel
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@nvidia.com>
> ---
> 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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* [PATCH 10/10] ARM: tegra: Enable USB on Venice2
2013-12-19 21:37 ` Stephen Warren
@ 2013-12-20 2:59 ` Jim Lin
2013-12-20 11:53 ` Thierry Reding
1 sibling, 0 replies; 31+ messages in thread
From: Jim Lin @ 2013-12-20 2:59 UTC (permalink / raw)
To: linux-arm-kernel
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@nvidia.com>
> > ---
> > 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 at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--nvpublic
^ permalink raw reply [flat|nested] 31+ messages in thread* [PATCH 10/10] ARM: tegra: Enable USB on Venice2
2013-12-19 21:37 ` Stephen Warren
2013-12-20 2:59 ` Jim Lin
@ 2013-12-20 11:53 ` Thierry Reding
1 sibling, 0 replies; 31+ messages in thread
From: Thierry Reding @ 2013-12-20 11:53 UTC (permalink / raw)
To: linux-arm-kernel
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@nvidia.com>
> > ---
> > 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131220/5f19b4d9/attachment.sig>
^ permalink raw reply [flat|nested] 31+ messages in thread