RE: [PATCH RFC 0/5] Introduced new Cadence USBSSP DRD Driver.

[Pawel Laszczak]

Hi Felipe,

>
>Hi,
>
>Pawel Laszczak <pawell@xxxxxxxxxxx> writes:
>> 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 host 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 DT binding.
>> The patch 2: adds PCI to platform wrapper used on Cadnece testing
>>              platform. It is FPGA based on platform.
>> The patches 3-5: 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 (4/5) is little smaller. Patch 3 introduces main
>>              header file for driver, 4 is the main part that implements all
>>              functionality of driver and 5 introduces tracepoints.
>
>I'm more interested in how is this different from CDNS3. Aren't they SW compatible?

In general, the controller can be split into 2 part- DRD part and the rest UDC. 

The second part UDC which consist gadget.c, ring.c and mem.c file is completely different. 

The DRD part contains drd.c and core.c. 
cdnsp drd.c is similar to cdns3 drd.c but it's little different. CDNSP has similar, but has different register space.
Some register was moved, some was removed and some was added.  

core.c is very similar and eventually could be common for both drivers.  I thought about this but
I wanted to avoid interfering with cdns3 driver at this point CDNSP is still under testing and 
CDNS3 is used by some products on the market. 

I thought about merging cdnsp core.c  with cdns3 core.c but after upstreaming over, but 
I'm not sure if it's a good idea.

>
>--
>balbi

pawel