Re: [RFC PATCH 13/14] usb: devicetree: dwc3: Add property to disable mult TRB fetch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

Rob Herring wrote:
> On Thu, Dec 19, 2019 at 3:52 PM Thinh Nguyen <Thinh.Nguyen@xxxxxxxxxxxx> wrote:
>> Hi,
>>
>> Rob Herring wrote:
>>> On Fri, Dec 13, 2019 at 09:04:54AM +0200, Felipe Balbi wrote:
>>>> Hi,
>>>>
>>>> Thinh Nguyen <Thinh.Nguyen@xxxxxxxxxxxx> writes:
>>>>>> Thinh Nguyen <Thinh.Nguyen@xxxxxxxxxxxx> writes:
>>>>>>> DWC_usb32 has a feature where it can issue multiple TRB fetch requests.
>>>>>>> Add a new property to limit and only do only single TRB fetch request.
>>>>>>>
>>>>>>> Signed-off-by: Thinh Nguyen <thinhn@xxxxxxxxxxxx>
>>>>>>> ---
>>>>>>>     Documentation/devicetree/bindings/usb/dwc3.txt | 2 ++
>>>>>>>     1 file changed, 2 insertions(+)
>>>>>>>
>>>>>>> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt
>>>>>>> index ff35fa6de2eb..29d6f9b1fc70 100644
>>>>>>> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
>>>>>>> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
>>>>>>> @@ -108,6 +108,8 @@ Optional properties:
>>>>>>>      - snps,num-trb-prefetch: max value to do TRBs cache for DWC_usb32. The value
>>>>>>>                            can be from 1 to DWC_USB32_CACHE_TRBS_PER_TRANSFER.
>>>>>>>                            Default value is DWC_USB32_CACHE_TRBS_PER_TRANSFER.
>>>>>>> + - snps,dis-mult-trb-fetch: set to issue only single TRB fetch request in
>>>>>>> +                 DWC_usb32.
>>>>>> two questions:
>>>>>>
>>>>>> - how is this different from passing 1 to the previous DT binding
>>>>> The previous DT binding is related to the number TRBs to cache while
>>>>> this one is related to whether the controller will send multiple
>>>>> (internal) fetch commands to fetch the TRBs.
>>>>>
>>>>>> - do we know of anybody having issues with multi-trb prefetch?
>>>>> No, we added this for various internal tests.
>>>> We really a better way for you guys to have your test coverage enabled
>>>> with upstream kernel. I wonder if DT guys would accept a set of bindings
>>>> marked as "for testing purposes". In any case, we really need to enable
>>>> Silicon Validation with upstream kernel.
>>> Well, anything would be better than the endless stream of new
>>> properties. Include 'test-mode' in the property names would be fine I
>>> guess.
>>>
>> Generally the properties are for some quirks or configurations that the
>> controller must use to work properly and not for debugging purposes.
>> Unfortunately, this list can be long..
> quirks or testing? Now I'm confused, which is it?

I was referring to the existing properties, they are necessary for a 
working device. Nothing "extra" solely for debugging purposes.

With the exception for these couple properties related to TRB fetching 
in this RFC series, they are for testing only. Regardless, I agreed to 
Felipe previously that we can remove them.


> I'm sure I've said this before (for DWC3), but it is better to have a
> compatible string for each implementation (usually an SoC) so you can
> address new quirks without a dtb change and continually adding new
> properties.
>
> Rob

Yes, you mentioned it before. It may work on SoC, but it won't work for 
PCI devices. We can't use VID:PID either, because the HAPS devices only 
have a set of VID:PID.

Please refer back to a couple discussions back:
1) https://www.spinics.net/lists/linux-usb/msg164494.html

This one is related to cadence's, but I think it's relevant:
2) https://www.spinics.net/lists/linux-usb/msg175199.html

There maybe more discussions previously, but I don't have the history of 
all the emails.

BR,
Thinh






[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux