[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <19bdc074-7f48-4df4-87c0-117f4cff54f0@kernel.org>
Date: Tue, 8 Oct 2024 14:59:28 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Joy Chakraborty <joychakr@...gle.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Thinh Nguyen
<Thinh.Nguyen@...opsys.com>, Felipe Balbi <balbi@...nel.org>,
linux-usb@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: usb: dwc3: Add binding for USB Gen2
de-emphasis
On 08/10/2024 14:40, Joy Chakraborty wrote:
> On Tue, Oct 8, 2024 at 5:40 PM Krzysztof Kozlowski <krzk@...nel.org> wrote:
>>
>> On 08/10/2024 13:59, Joy Chakraborty wrote:
>>>>>
>>>>>>
>>>>>>> + description: When set core will set Tx de-emphasis for USB Gen2
>>>>>>
>>>>>> And why it cannot be implied by compatible?
>>>>>
>>>>> As per my understanding these are tuning coefficients for de-emphasis
>>>>> particular to a platform and not the dwc3 controller, hence should not
>>>>> be a controller compatible.
>>>>
>>>> Platforms must have specific compatible, so this should be implied by
>>>> compatible.
>>>
>>> Maybe I am using the word "platform" incorrectly here, what I
>>> understand is that the same controller(in a chip) when used on 2
>>> different physical form factors might need different deemphasis
>>
>> You mean boards? This is board-level property?
>
> Yes, the USB controller can be paired with different phys in a SoC and
That's not board specific, but SoC.
> used on different board layouts where we should be able to drive
> different de-emphasis coefficients to the phy as per the link
> equalization requirements is my understanding.
You keep mixing different stories, so I am not convinced.
>
>>
>>> coefficient values to be passed to its Phy. Someone could correct me
>>> from the USB link stand point if I am mistaken here.
>>>
>>
>> Then please point me to the upstream DTS boards using these properties.
>> Lore link is enough, if board or DTS change is being upstreamed.
>>
>
> The DTS change is not being upstreamed currently.
Why do we want code without any user?
> But this change would help bring up a new or development board where
> USB compliance is being run and this parameter needs tuning, hence
> being able to upstream this would help.
To me whatever Google or any other vendor is doing downstream does not
matter, just "does not exist".
Upstream the DTS so we can verify how this is exactly used.
To me it looks so far as SoC specific and your earlier comment about
pairing USB controller with phy is confirming this.
That's a common practice from Google (but not Chromium folks, they are
awesome!) and few other vendors to upstream whatever they have in their
GKI downstream, regardless whether it is right or not, whether it
follows rules or not, whether there is any user or not (and again: users
are upstream). Rationale for all this is the same - "we have downstream
some crap thus we want it".
Nah, upstream your stuff to be considered as a user.
That's a NAK, sorry.
Best regards,
Krzysztof
Powered by blists - more mailing lists