lkml.org 
[lkml]   [2014]   [Oct]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH RESEND V4 5/9] of: Add NVIDIA Tegra xHCI controller binding
From
On Wed, Oct 29, 2014 at 2:43 AM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Tue, Oct 28, 2014 at 03:27:50PM -0700, Andrew Bresticker wrote:
> [...]
>> diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt
> [...]
>> +Optional properties:
>> +-------------------
>> +- vbus-{0,1,2}-supply: VBUS regulator for the corresponding UTMI pad.
>> +- vddio-hsic-supply: VDDIO regulator for the HSIC pads.
>> +- nvidia,usb3-port-{0,1}-lane: PCIe/SATA lane to which the corresponding USB3
>> + port is mapped. See <dt-bindings/pinctrl/pinctrl-tegra-xusb.h> for the list
>> + of valid values.
>
> I dislike how we now need to provide a list of all pins in the header
> file, where previously we used strings for this. This could become very
> ugly if the set of pins changes in future generations of this IP block.
>
> Could we instead derive this from the pinmux nodes? For example you have
> this in the example below:
>
> usb3p0 {
> nvidia,lanes = "pcie-0";
> ...
> };
>
> Perhaps what we need is to either key off the node name or add another
> property, such as:
>
> nvidia,usb3-port = <0>;
>
> This would match the nvidia,usb2-port property that you've added below.

That is actually how I described the USB3 port to SS lane mapping
originally, but in review of an earlier version of this series,
Stephen suggested that I make it a separate, not pinconfig property
since it wasn't a value written directly to the hardware. I'm fine
with changing it back as the pinconfig property makes more sense to me
as well.


\
 
 \ /
  Last update: 2014-10-29 18:01    [W:0.124 / U:0.780 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site