Hi Stephen,
On 14 May 2015 at 08:11, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote:
> On 05/14/2015 07:09 AM, Tomeu Vizoso wrote:
>>
>> On 13 May 2015 at 16:45, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote:
>>>
>>> On 05/13/2015 08:13 AM, Simon Glass wrote:
>>>>
>>>>
>>>> Regenerate the pinmux from the latest tegra-pinmux-scripts.
>>>
>>>
>>>
>>> (Dropping most CCs; DT maintainers and lists generally don't get CC'd on
>>> simple DT content changes but rather on schema adds/changes and perhaps
>>> major DT content changes depending on context)
>>>
>>>> diff --git a/arch/arm/boot/dts/tegra124-nyan-big.dts
>>>> b/arch/arm/boot/dts/tegra124-nyan-big.dts
>>>
>>>
>>>
>>>> pinctrl-names = "default";
>>>> pinctrl-0 = <&pinmux_default>;
>>>>
>>>> - pinmux_default: common {
>>>> + state_default: pinmux {
>>>
>>>
>>>
>>> This change will break compilation, since it changes the label name, yet
>>> the
>>> old name is still referenced in pinctrl-0 above. Same applies in the
>>> other
>>> file too.
>>>
>>>> diff --git a/arch/arm/boot/dts/tegra124-nyan-blaze.dts
>>>> b/arch/arm/boot/dts/tegra124-nyan-blaze.dts
>>>
>>>
>>>
>>>> @@ -437,18 +437,18 @@
>>>> usb_vbus_en0_pn4 {
>>>> nvidia,pins = "usb_vbus_en0_pn4";
>>>> nvidia,function = "usb";
>>>> - nvidia,pull = <TEGRA_PIN_PULL_UP>;
>>>> + nvidia,pull = <TEGRA_PIN_PULL_NONE>;
>>>> nvidia,tristate = <TEGRA_PIN_DISABLE>;
>>>> nvidia,enable-input =
>>>> <TEGRA_PIN_ENABLE>;
>>>> - nvidia,open-drain = <TEGRA_PIN_DISABLE>;
>>>> + nvidia,open-drain = <TEGRA_PIN_ENABLE>;
>>>> };
>>>> usb_vbus_en1_pn5 {
>>>> nvidia,pins = "usb_vbus_en1_pn5";
>>>> nvidia,function = "usb";
>>>> - nvidia,pull = <TEGRA_PIN_PULL_UP>;
>>>> + nvidia,pull = <TEGRA_PIN_PULL_NONE>;
>>>> nvidia,tristate = <TEGRA_PIN_DISABLE>;
>>>> nvidia,enable-input =
>>>> <TEGRA_PIN_ENABLE>;
>>>> - nvidia,open-drain = <TEGRA_PIN_DISABLE>;
>>>> + nvidia,open-drain = <TEGRA_PIN_ENABLE>;
>>>> };
>>>
>>>
>>>
>>> Tomeu, can you comment on those changes? Evidently the pinmux
>>> configuration
>>> that's you added to the kernel doesn't exactly match the pinmux
>>> configuration that you added to tegra-pinmux-scripts.
>>
>>
>> Are you sure? Just checked and what tegra-pinmux-scripts currently
>> generates matches what is currently in the kernel, for both nyans.
>
>
> My apologies; you're correct.
>
> This patch to the kernel DTs includes changes that aren't generated by
> either current tegra-pinmux-scripts, nor by tegra-pinmux-scripts with
> Simon's "[pinmux scripts PATCH] Support TPM on nyan boards" applied. Simon,
> can you double-check you didn't have any local patches to
> tegra-pinmux-scripts applied when you generated the DT content for this
> patch?
Yes. Apart from my patch the top commit is 39af.
>
>>> Is the change above
>>> correct, or do we need to propagate this change from the kernel DT into
>>> tegra-pinmux-scripts, and hence also into the U-Boot pinmux setup table?
>>>
>>> My understanding of how these pins are generally used is that open-drain
>>> is
>>> likely correct. I have no idea whether Tegra should supply the pullup for
>>> these pins, or whether the board has a pullup resistor in which case
>>> Tegra
>>> doesn't need to pull up.
>>
>>
>> From what Andrew (added to CC) said when these changes were discussed,
>> it shouldn't matter as a fixed regulator is used to drive those pins
>> high.
>
>
> It looks like nyan-big and nyan-blaze configure these pins differently,
> which may be incorrect if the boards are truly almost identical. Is that
> expected? Nyan-big sets them both to open-drain but Nyan-blaze sets them to
> push-pull. The pull-up enable is different too. Typically these pins are
> open-drain, because there's often a current sensor chip on the USB port
> power rail which asserts (pulls low in open-drain mode) these signals to
> turn off the power when an over-current condition is detected. Not all
> boards do this though, so the difference may be perfectly expected; someone
> with access to the schematics would have to check.
Regards,
Simon
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
