[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <24639633-919c-7082-fbde-dc613a7a71d0@ti.com>
Date: Wed, 25 Nov 2020 20:33:54 +0530
From: Sekhar Nori <nsekhar@...com>
To: Pawel Laszczak <pawell@...ence.com>,
Peter Chen <peter.chen@....com>
CC: "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"balbi@...nel.org" <balbi@...nel.org>,
"colin.king@...onical.com" <colin.king@...onical.com>,
"rogerq@...com" <rogerq@...com>, Rahul Kumar <kurahul@...ence.com>,
"Govindraju, Aswath" <a-govindraju@...com>,
Kishon Vijay Abraham I <kishon@...com>
Subject: Re: [PATCH v3 00/10] Introduced new Cadence USBSSP DRD Driver.
On 24/11/20 3:22 PM, Pawel Laszczak wrote:
> Sekhar,
>
>>
>>
>> On 24/11/20 2:51 PM, Pawel Laszczak wrote:
>>> Peter,
>>>
>>>> On 20-11-19 15:12:57, Pawel Laszczak wrote:
>>>>> This patch introduce new Cadence USBSS DRD driver to linux kernel.
>>>>>
>>>>> The Cadence USBSS DRD Controller is a highly configurable IP Core which
>>>>> can be instantiated as Dual-Role Device (DRD), Peripheral Only and
>>>>> Host Only (XHCI)configurations.
>>>>>
>>>>> The current driver has been validated with FPGA burned. We have support
>>>>> for PCIe bus, which is used on FPGA prototyping.
>>>>>
>>>>> The host side of USBSS-DRD controller is compliance with XHCI
>>>>> specification, so it works with standard XHCI Linux driver.
>>>>>
>>>>> The device side of USBSS DRD controller is compliant with XHCI.
>>>>> The architecture for device side is almost the same as for host side,
>>>>> and most of the XHCI specification can be used to understand how
>>>>> this controller operates.
>>>>>
>>>>> This controller and driver support Full Speed, Hight Speed, Supper Speed
>>>>> and Supper Speed Plus USB protocol.
>>>>>
>>>>> The prefix cdnsp used in driver has chosen by analogy to cdn3 driver.
>>>>> The last letter of this acronym means PLUS. The formal name of controller
>>>>> is USBSSP but it's to generic so I've decided to use CDNSP.
>>>>>
>>>>> The patch 1: adds support for DRD CDNSP.
>>>>> The patch 2: separates common code that can be reusable by cdnsp driver.
>>>>> The patch 3: moves reusable code to separate module.
>>>>> The patch 4: changes prefixes in reusable code from cdns3 to common cdns.
>>>>> The patch 5: adopts gadget_dev pointer in cdns structure to make possible
>>>>> use it in both drivers.
>>>>> The patches 6-8: add the main part of driver and has been intentionally
>>>>> split into 3 part. In my opinion such division should not
>>>>> affect understanding and reviewing the driver, and cause that
>>>>> main patch (7/8) is little smaller. Patch 6 introduces main
>>>>> header file for driver, 7 is the main part that implements all
>>>>> functionality of driver and 8 introduces tracepoints.
>>>>> The patch 9: Adds cdns3 prefixes to files related with USBSS driver.
>>>>> the patch 10: Adds USBSSP DRD IP driver entry to MAINTAINERS file.
>>>>>
>>>>> Changlog from v2:
>>>>> - removed not used pdev parameter from cdnsp_read/wite_64 functions
>>>>> - fixed incorrect value assigned to CDNSP_ENDPOINTS_NUM (32 -> 31)
>>>>> - replaced some constant value with CDNSP_ENDPOINTS_NUM macro
>>>>> - replaced 'true' with '1' in bits description in cdnsp-gadget.h file
>>>>> - fixed some typos
>>>>> - some other less important changes suggested by Peter Chen
>>>>
>>>> Hi Pawel,
>>>>
>>>> I have updated my -next tree as the latest usb-next tree which v5.10-rc4
>>>> is included, would you please rebase my tree and send again, I could apply your
>>>> patches and test, if test could pass, I will apply it to my -next tree.
>>>> You don't need to rebase again since it is a huge patch set, will take some
>>>> efforts for rebase.
>>>>
>>>
>>> I'll try to post it tomorrow.
>>
>> Pawel, have you tested TI J7 for regressions after this series? After
>> your latest changes, can you post a tree which someone in TI can test?
>
> No I haven't test it on J7. For testing I'm using PCIe based platform for
> both cnds3 and cdnsp driver.
Do you have access to J7 EVM? Are you willing to test it there to make
sure nothing broke?
>
> Why you can't use the latest kernel version and current series ?
Sure. Let me try that. Looking at some other traffic on this thread, I
was not sure where this applies. So, this applies to latest of Linus's
tree? I re-read the cover letter but cannot find this information.
Thanks,
Sekhar
Powered by blists - more mailing lists