Two small but important fixes to SHIELD's pinmux configuration.
The use of invalid properties caused the pinmux to not be applied
at all. Also the setting for sdmmc clock lines resulted in random
errors or even the impossibility to probe attached devices.
Alexandre Courbot (2):
ARM: tegra: roth: fix unsupported pinmux properties
ARM: tegra: roth: enable input on mmc clock pins
arch/arm/boot/dts/tegra114-roth.dts | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
--
2.0.0
The pinmux subsystem complained that the nvidia,low-power-mode property
is not supported by the sdio1, sdio3 and gma drive groups. In addition
gma also does not support nvidia,drive-type. Remove these properties so
the pinmux configuration can properly be applied.
Signed-off-by: Alexandre Courbot <[email protected]>
---
arch/arm/boot/dts/tegra114-roth.dts | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/arm/boot/dts/tegra114-roth.dts b/arch/arm/boot/dts/tegra114-roth.dts
index 0b0e8e07d965..a67885250f81 100644
--- a/arch/arm/boot/dts/tegra114-roth.dts
+++ b/arch/arm/boot/dts/tegra114-roth.dts
@@ -730,7 +730,6 @@
nvidia,pins = "drive_sdio1";
nvidia,high-speed-mode = <TEGRA_PIN_ENABLE>;
nvidia,schmitt = <TEGRA_PIN_DISABLE>;
- nvidia,low-power-mode = <TEGRA_PIN_LP_DRIVE_DIV_1>;
nvidia,pull-down-strength = <36>;
nvidia,pull-up-strength = <20>;
nvidia,slew-rate-rising = <TEGRA_PIN_SLEW_RATE_SLOW>;
@@ -740,7 +739,6 @@
nvidia,pins = "drive_sdio3";
nvidia,high-speed-mode = <TEGRA_PIN_ENABLE>;
nvidia,schmitt = <TEGRA_PIN_DISABLE>;
- nvidia,low-power-mode = <TEGRA_PIN_LP_DRIVE_DIV_1>;
nvidia,pull-down-strength = <36>;
nvidia,pull-up-strength = <20>;
nvidia,slew-rate-rising = <TEGRA_PIN_SLEW_RATE_FASTEST>;
@@ -750,12 +748,10 @@
nvidia,pins = "drive_gma";
nvidia,high-speed-mode = <TEGRA_PIN_ENABLE>;
nvidia,schmitt = <TEGRA_PIN_DISABLE>;
- nvidia,low-power-mode = <TEGRA_PIN_LP_DRIVE_DIV_1>;
nvidia,pull-down-strength = <2>;
nvidia,pull-up-strength = <2>;
nvidia,slew-rate-rising = <TEGRA_PIN_SLEW_RATE_FASTEST>;
nvidia,slew-rate-falling = <TEGRA_PIN_SLEW_RATE_FASTEST>;
- nvidia,drive-type = <1>;
};
};
};
--
2.0.0
Input had been disabled by mistake on these pins, leading to issues with
SDIO devices like the Wifi module not being probed or random errors
occuring on the SD card.
Signed-off-by: Alexandre Courbot <[email protected]>
---
arch/arm/boot/dts/tegra114-roth.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/tegra114-roth.dts b/arch/arm/boot/dts/tegra114-roth.dts
index a67885250f81..ba210c6e189f 100644
--- a/arch/arm/boot/dts/tegra114-roth.dts
+++ b/arch/arm/boot/dts/tegra114-roth.dts
@@ -244,7 +244,7 @@
nvidia,function = "sdmmc1";
nvidia,pull = <TEGRA_PIN_PULL_NONE>;
nvidia,tristate = <TEGRA_PIN_DISABLE>;
- nvidia,enable-input = <TEGRA_PIN_DISABLE>;
+ nvidia,enable-input = <TEGRA_PIN_ENABLE>;
};
sdmmc1_cmd_pz1 {
nvidia,pins = "sdmmc1_cmd_pz1",
@@ -262,7 +262,7 @@
nvidia,function = "sdmmc3";
nvidia,pull = <TEGRA_PIN_PULL_NONE>;
nvidia,tristate = <TEGRA_PIN_DISABLE>;
- nvidia,enable-input = <TEGRA_PIN_DISABLE>;
+ nvidia,enable-input = <TEGRA_PIN_ENABLE>;
};
sdmmc3_cmd_pa7 {
nvidia,pins = "sdmmc3_cmd_pa7",
@@ -290,7 +290,7 @@
nvidia,function = "sdmmc4";
nvidia,pull = <TEGRA_PIN_PULL_NONE>;
nvidia,tristate = <TEGRA_PIN_DISABLE>;
- nvidia,enable-input = <TEGRA_PIN_DISABLE>;
+ nvidia,enable-input = <TEGRA_PIN_ENABLE>;
};
sdmmc4_cmd_pt7 {
nvidia,pins = "sdmmc4_cmd_pt7",
--
2.0.0
On 06/23/2014 01:32 AM, Alexandre Courbot wrote:
> Two small but important fixes to SHIELD's pinmux configuration.
> The use of invalid properties caused the pinmux to not be applied
> at all. Also the setting for sdmmc clock lines resulted in random
> errors or even the impossibility to probe attached devices.
It might be nice to add Roth's pinmux to:
https://github.com/NVIDIA/tegra-pinmux-scripts
On 06/23/2014 01:32 AM, Alexandre Courbot wrote:
> Input had been disabled by mistake on these pins, leading to issues with
> SDIO devices like the Wifi module not being probed or random errors
> occuring on the SD card.
I thought the host controller always drove the clock, so there should be
no need for the pin's input path to be enabled. Perhaps it depends on
the transfer mode (e.g. UHS)?
If this fix is valid, perhaps Jetson TK1's sdmmc3_clk and Venice2's
sdmmc1_clk need the same fix, although we'll need to file bugs against
their pinmux spreadsheets first if that's the case.
On 06/24/2014 03:46 AM, Stephen Warren wrote:
> On 06/23/2014 01:32 AM, Alexandre Courbot wrote:
>> Two small but important fixes to SHIELD's pinmux configuration.
>> The use of invalid properties caused the pinmux to not be applied
>> at all. Also the setting for sdmmc clock lines resulted in random
>> errors or even the impossibility to probe attached devices.
>
> It might be nice to add Roth's pinmux to:
> https://github.com/NVIDIA/tegra-pinmux-scripts
Certainly - will keep a note to do it sometime soon. Thanks for pointing
it out.
On 06/24/2014 04:01 AM, Stephen Warren wrote:
> On 06/23/2014 01:32 AM, Alexandre Courbot wrote:
>> Input had been disabled by mistake on these pins, leading to issues with
>> SDIO devices like the Wifi module not being probed or random errors
>> occuring on the SD card.
>
> I thought the host controller always drove the clock, so there should be
> no need for the pin's input path to be enabled. Perhaps it depends on
> the transfer mode (e.g. UHS)?
That's what I thought too, so I went against what was done downstream
and disabled input mode. Eventually noticed various issues with MMC
devices, reverted to the downstream settings and noticed my problems
were solved by this single change.
>
> If this fix is valid, perhaps Jetson TK1's sdmmc3_clk and Venice2's
> sdmmc1_clk need the same fix, although we'll need to file bugs against
> their pinmux spreadsheets first if that's the case.
>
Are we having MMC issues with Jetson? I haven't noticed anything
recently, and I have been using both eMMC and SD card.
Anyway, at least for SHIELD, this change seems to be valid.
On 06/23/2014 11:44 PM, Alexandre Courbot wrote:
> On 06/24/2014 04:01 AM, Stephen Warren wrote:
>> On 06/23/2014 01:32 AM, Alexandre Courbot wrote:
>>> Input had been disabled by mistake on these pins, leading to issues with
>>> SDIO devices like the Wifi module not being probed or random errors
>>> occuring on the SD card.
>>
>> I thought the host controller always drove the clock, so there should be
>> no need for the pin's input path to be enabled. Perhaps it depends on
>> the transfer mode (e.g. UHS)?
>
> That's what I thought too, so I went against what was done downstream
> and disabled input mode. Eventually noticed various issues with MMC
> devices, reverted to the downstream settings and noticed my problems
> were solved by this single change.
Hmm. That's odd. Can you talk to one of the HW engineers behind the
SDHCI controller and get a definitive answer. Thanks.
On 06/23/2014 01:32 AM, Alexandre Courbot wrote:
> Two small but important fixes to SHIELD's pinmux configuration.
> The use of invalid properties caused the pinmux to not be applied
> at all. Also the setting for sdmmc clock lines resulted in random
> errors or even the impossibility to probe attached devices.
>
> Alexandre Courbot (2):
> ARM: tegra: roth: fix unsupported pinmux properties
> ARM: tegra: roth: enable input on mmc clock pins
The series, applied to Tegra's for-3.17/dt branch.
Sorry for the delay; I'd forgotten that our internal discussion resolved
my questions about patch 2.
Still looking forward to internal bugs files against the Jetson TK1 and
Venice2 board pinmux spreadsheets for the same issue:-)
On Sat, Jun 28, 2014 at 7:08 AM, Stephen Warren <[email protected]> wrote:
> On 06/23/2014 01:32 AM, Alexandre Courbot wrote:
>> Two small but important fixes to SHIELD's pinmux configuration.
>> The use of invalid properties caused the pinmux to not be applied
>> at all. Also the setting for sdmmc clock lines resulted in random
>> errors or even the impossibility to probe attached devices.
>>
>> Alexandre Courbot (2):
>> ARM: tegra: roth: fix unsupported pinmux properties
>> ARM: tegra: roth: enable input on mmc clock pins
>
> The series, applied to Tegra's for-3.17/dt branch.
>
> Sorry for the delay; I'd forgotten that our internal discussion resolved
> my questions about patch 2.
Thanks! And sorry for not mirroring the discussion on the public list.
> Still looking forward to internal bugs files against the Jetson TK1 and
> Venice2 board pinmux spreadsheets for the same issue:-)
Are the spreadsheets you are talking about the following documents?
https://github.com/NVIDIA/tegra-pinmux-scripts/blob/master/configs/jetson-tk1.board
Or do we have internal structures we need to update as well?
On 06/28/2014 10:27 PM, Alexandre Courbot wrote:
> On Sat, Jun 28, 2014 at 7:08 AM, Stephen Warren <[email protected]> wrote:
>> On 06/23/2014 01:32 AM, Alexandre Courbot wrote:
>>> Two small but important fixes to SHIELD's pinmux configuration.
>>> The use of invalid properties caused the pinmux to not be applied
>>> at all. Also the setting for sdmmc clock lines resulted in random
>>> errors or even the impossibility to probe attached devices.
>>>
>>> Alexandre Courbot (2):
>>> ARM: tegra: roth: fix unsupported pinmux properties
>>> ARM: tegra: roth: enable input on mmc clock pins
>>
>> The series, applied to Tegra's for-3.17/dt branch.
>>
>> Sorry for the delay; I'd forgotten that our internal discussion resolved
>> my questions about patch 2.
>
> Thanks! And sorry for not mirroring the discussion on the public list.
>
>> Still looking forward to internal bugs files against the Jetson TK1 and
>> Venice2 board pinmux spreadsheets for the same issue:-)
>
> Are the spreadsheets you are talking about the following documents?
>
> https://github.com/NVIDIA/tegra-pinmux-scripts/blob/master/configs/jetson-tk1.board
>
> Or do we have internal structures we need to update as well?
That's data that is extracted from the internal spreadsheets. I'll try
and remember to send you the links internally (since they wouldn't be
useful to anyone on-list).