Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Peter Chen <peter.chen@nxp.com>
To:     Pawel Laszczak <pawell@cadence.com>
CC:     Felipe Balbi <balbi@kernel.org>,
        "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
        "robh+dt@kernel.org" <robh+dt@kernel.org>,
        "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        "dan.carpenter@oracle.com" <dan.carpenter@oracle.com>,
        "ben.dooks@codethink.co.uk" <ben.dooks@codethink.co.uk>,
        "colin.king@canonical.com" <colin.king@canonical.com>,
        "rogerq@ti.com" <rogerq@ti.com>,
        "weiyongjun1@huawei.com" <weiyongjun1@huawei.com>,
        Jayshri Dajiram Pawar <jpawar@cadence.com>,
        Rahul Kumar <kurahul@cadence.com>,
        Sanket Parmar <sparmar@cadence.com>
Subject: Re: [PATCH RFC 0/5] Introduced new Cadence USBSSP DRD Driver.
Thread-Topic: [PATCH RFC 0/5] Introduced new Cadence USBSSP DRD Driver.
Thread-Index: AQHWS3Ylp2LS5pecmkenOlfLMCntJajqdbIAgAAHxACABHoqgA==
Date:   Mon, 29 Jun 2020 03:41:49 +0000
Message-ID: <20200629034213.GB30684@b29397-desktop>
References: <20200626045450.10205-1-pawell@cadence.com>
 <878sga5nfr.fsf@kernel.org>
 <BL0PR07MB5522A8796EE7BFB5062A8E76DD930@BL0PR07MB5522.namprd07.prod.outlook.com>
In-Reply-To: <BL0PR07MB5522A8796EE7BFB5062A8E76DD930@BL0PR07MB5522.namprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4877C9C125D3ED46B215D65647EB3933@eurprd04.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 93d31729-04b4-4734-7e39-08d81bde5afd
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2020 03:41:49.5749
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: f4F8qIQNHddqeJzAvebjeEizAi8Ig7AcburL8jMQVzRtJYveEJrqLFbOthXHpaOjiichxcnQp0mz4heWYiZwow==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR0402MB3654
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 20-06-26 07:19:56, Pawel Laszczak wrote:
> Hi Felipe,
>=20
> >
> >Hi,
> >
> >Pawel Laszczak <pawell@cadence.com> writes:
> >> This patch introduce new Cadence USBSS DRD driver to linux kernel.
> >>
> >> The Cadence USBSS DRD Controller is a highly configurable IP Core whic=
h
> >> 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 suppor=
t
> >> 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 Spe=
ed
> >> 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 control=
ler
> >> 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 intentionall=
y
> >>              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 ma=
in
> >>              header file for driver, 4 is the main part that implement=
s all
> >>              functionality of driver and 5 introduces tracepoints.
> >
> >I'm more interested in how is this different from CDNS3. Aren't they SW =
compatible?
>=20
> In general, the controller can be split into 2 part- DRD part and the res=
t UDC.=20
>=20
> The second part UDC which consist gadget.c, ring.c and mem.c file is comp=
letely different.=20
>=20
> The DRD part contains drd.c and core.c.=20
> cdnsp drd.c is similar to cdns3 drd.c but it's little different. CDNSP ha=
s similar, but has different register space.
> Some register was moved, some was removed and some was added. =20
>=20
> 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 st=
ill under testing and=20
> CDNS3 is used by some products on the market.=20

Pawel, I suggest adding CDNSP at driver/staging first since it is still
under testing. When you are thinking the driver (as well as hardware) are
mature, you could try to add gadget part (eg, gadget-v2) and make
necessary changes for core.c.

--=20

Thanks,
Peter Chen=