diff mbox

[v4,2/3] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core

Message ID 1376992565-22292-3-git-send-email-iivanov@mm-sol.com (mailing list archive)
State Not Applicable, archived
Headers show

Commit Message

Ivan T. Ivanov Aug. 20, 2013, 9:56 a.m. UTC
From: "Ivan T. Ivanov" <iivanov@mm-sol.com>

These drivers handles control and configuration of the HS
and SS USB PHY transceivers. They are part of the driver
which manage Synopsys DesignWare USB3 controller stack
inside Qualcomm SoC's.

Signed-off-by: Ivan T. Ivanov <iivanov@mm-sol.com>
---
 drivers/usb/phy/Kconfig           |   11 ++
 drivers/usb/phy/Makefile          |    2 +
 drivers/usb/phy/phy-msm-dwc3-hs.c |  327 ++++++++++++++++++++++++++++++++
 drivers/usb/phy/phy-msm-dwc3-ss.c |  374 +++++++++++++++++++++++++++++++++++++
 4 files changed, 714 insertions(+)
 create mode 100644 drivers/usb/phy/phy-msm-dwc3-hs.c
 create mode 100644 drivers/usb/phy/phy-msm-dwc3-ss.c

Comments

Felipe Balbi Aug. 20, 2013, 12:29 p.m. UTC | #1
Hi,

On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
> From: "Ivan T. Ivanov" <iivanov@mm-sol.com>
> 
> These drivers handles control and configuration of the HS
> and SS USB PHY transceivers. They are part of the driver
> which manage Synopsys DesignWare USB3 controller stack
> inside Qualcomm SoC's.
> 
> Signed-off-by: Ivan T. Ivanov <iivanov@mm-sol.com>
> ---
>  drivers/usb/phy/Kconfig           |   11 ++
>  drivers/usb/phy/Makefile          |    2 +
>  drivers/usb/phy/phy-msm-dwc3-hs.c |  327 ++++++++++++++++++++++++++++++++
>  drivers/usb/phy/phy-msm-dwc3-ss.c |  374 +++++++++++++++++++++++++++++++++++++

please rename these PHY drivers, they have nothing to do with DWC3. PHYs
don't care about the USB controller.
Ivan T. Ivanov Aug. 20, 2013, 1:32 p.m. UTC | #2
Hi,

On Tue, 2013-08-20 at 07:29 -0500, Felipe Balbi wrote: 
> Hi,
> 
> On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
> > From: "Ivan T. Ivanov" <iivanov@mm-sol.com>
> > 
> > These drivers handles control and configuration of the HS
> > and SS USB PHY transceivers. They are part of the driver
> > which manage Synopsys DesignWare USB3 controller stack
> > inside Qualcomm SoC's.
> > 
> > Signed-off-by: Ivan T. Ivanov <iivanov@mm-sol.com>
> > ---
> >  drivers/usb/phy/Kconfig           |   11 ++
> >  drivers/usb/phy/Makefile          |    2 +
> >  drivers/usb/phy/phy-msm-dwc3-hs.c |  327 ++++++++++++++++++++++++++++++++
> >  drivers/usb/phy/phy-msm-dwc3-ss.c |  374 +++++++++++++++++++++++++++++++++++++
> 
> please rename these PHY drivers, they have nothing to do with DWC3. PHYs
> don't care about the USB controller.

I think they are SNPS DesignWare PHY's, additionally
wrapped with Qualcomm logic. I could substitute "dwc3"
with just "dw", which will be more correct.

Regards,
Ivan


--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Felipe Balbi Aug. 20, 2013, 1:37 p.m. UTC | #3
Hi,

On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote:
> > On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
> > > From: "Ivan T. Ivanov" <iivanov@mm-sol.com>
> > > 
> > > These drivers handles control and configuration of the HS
> > > and SS USB PHY transceivers. They are part of the driver
> > > which manage Synopsys DesignWare USB3 controller stack
> > > inside Qualcomm SoC's.
> > > 
> > > Signed-off-by: Ivan T. Ivanov <iivanov@mm-sol.com>
> > > ---
> > >  drivers/usb/phy/Kconfig           |   11 ++
> > >  drivers/usb/phy/Makefile          |    2 +
> > >  drivers/usb/phy/phy-msm-dwc3-hs.c |  327 ++++++++++++++++++++++++++++++++
> > >  drivers/usb/phy/phy-msm-dwc3-ss.c |  374 +++++++++++++++++++++++++++++++++++++
> > 
> > please rename these PHY drivers, they have nothing to do with DWC3. PHYs
> > don't care about the USB controller.
> 
> I think they are SNPS DesignWare PHY's, additionally
> wrapped with Qualcomm logic. I could substitute "dwc3"
> with just "dw", which will be more correct.

alright, thank you. Let's add Paul to the loop since he might have very
good insight in the synopsys PHYs.

mental note: if any other platform shows up with Synopsys PHY, ask them
to use this driver instead :-)
Ivan T. Ivanov Aug. 20, 2013, 2:09 p.m. UTC | #4
Hi,

On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote: 
> Hi,
> 
> On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote:
> > > On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
> > > > From: "Ivan T. Ivanov" <iivanov@mm-sol.com>
> > > > 
> > > > These drivers handles control and configuration of the HS
> > > > and SS USB PHY transceivers. They are part of the driver
> > > > which manage Synopsys DesignWare USB3 controller stack
> > > > inside Qualcomm SoC's.
> > > > 
> > > > Signed-off-by: Ivan T. Ivanov <iivanov@mm-sol.com>
> > > > ---
> > > >  drivers/usb/phy/Kconfig           |   11 ++
> > > >  drivers/usb/phy/Makefile          |    2 +
> > > >  drivers/usb/phy/phy-msm-dwc3-hs.c |  327 ++++++++++++++++++++++++++++++++
> > > >  drivers/usb/phy/phy-msm-dwc3-ss.c |  374 +++++++++++++++++++++++++++++++++++++
> > > 
> > > please rename these PHY drivers, they have nothing to do with DWC3. PHYs
> > > don't care about the USB controller.
> > 
> > I think they are SNPS DesignWare PHY's, additionally
> > wrapped with Qualcomm logic. I could substitute "dwc3"
> > with just "dw", which will be more correct.
> 
> alright, thank you. Let's add Paul to the loop since he might have very
> good insight in the synopsys PHYs.
> 
> mental note: if any other platform shows up with Synopsys PHY, ask them
> to use this driver instead :-)

I really doubt that this will bi possible. Control of the PHY's is
not directly trough ULPI, UTMI or PIPE3 interfaces, but trough
QSCRATCH registers, which of course is highly Qualcomm specific.

Regards,
Ivan


--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Felipe Balbi Aug. 20, 2013, 2:33 p.m. UTC | #5
On Tue, Aug 20, 2013 at 05:09:11PM +0300, Ivan T. Ivanov wrote:
> Hi,
> 
> On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote: 
> > Hi,
> > 
> > On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote:
> > > > On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
> > > > > From: "Ivan T. Ivanov" <iivanov@mm-sol.com>
> > > > > 
> > > > > These drivers handles control and configuration of the HS
> > > > > and SS USB PHY transceivers. They are part of the driver
> > > > > which manage Synopsys DesignWare USB3 controller stack
> > > > > inside Qualcomm SoC's.
> > > > > 
> > > > > Signed-off-by: Ivan T. Ivanov <iivanov@mm-sol.com>
> > > > > ---
> > > > >  drivers/usb/phy/Kconfig           |   11 ++
> > > > >  drivers/usb/phy/Makefile          |    2 +
> > > > >  drivers/usb/phy/phy-msm-dwc3-hs.c |  327 ++++++++++++++++++++++++++++++++
> > > > >  drivers/usb/phy/phy-msm-dwc3-ss.c |  374 +++++++++++++++++++++++++++++++++++++
> > > > 
> > > > please rename these PHY drivers, they have nothing to do with DWC3. PHYs
> > > > don't care about the USB controller.
> > > 
> > > I think they are SNPS DesignWare PHY's, additionally
> > > wrapped with Qualcomm logic. I could substitute "dwc3"
> > > with just "dw", which will be more correct.
> > 
> > alright, thank you. Let's add Paul to the loop since he might have very
> > good insight in the synopsys PHYs.
> > 
> > mental note: if any other platform shows up with Synopsys PHY, ask them
> > to use this driver instead :-)
> 
> I really doubt that this will bi possible. Control of the PHY's is
> not directly trough ULPI, UTMI or PIPE3 interfaces, but trough
> QSCRATCH registers, which of course is highly Qualcomm specific.

isn't it a memory mapped IP ? doesn't synopsys provide their own set of
registers ?
Ivan T. Ivanov Aug. 20, 2013, 2:54 p.m. UTC | #6
Hi, 

On Tue, 2013-08-20 at 09:33 -0500, Felipe Balbi wrote: 
> On Tue, Aug 20, 2013 at 05:09:11PM +0300, Ivan T. Ivanov wrote:
> > Hi,
> > 
> > On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote: 
> > > Hi,
> > > 
> > > On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote:
> > > > > On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
> > > > > > From: "Ivan T. Ivanov" <iivanov@mm-sol.com>
> > > > > > 
> > > > > > These drivers handles control and configuration of the HS
> > > > > > and SS USB PHY transceivers. They are part of the driver
> > > > > > which manage Synopsys DesignWare USB3 controller stack
> > > > > > inside Qualcomm SoC's.
> > > > > > 
> > > > > > Signed-off-by: Ivan T. Ivanov <iivanov@mm-sol.com>
> > > > > > ---
> > > > > >  drivers/usb/phy/Kconfig           |   11 ++
> > > > > >  drivers/usb/phy/Makefile          |    2 +
> > > > > >  drivers/usb/phy/phy-msm-dwc3-hs.c |  327 ++++++++++++++++++++++++++++++++
> > > > > >  drivers/usb/phy/phy-msm-dwc3-ss.c |  374 +++++++++++++++++++++++++++++++++++++
> > > > > 
> > > > > please rename these PHY drivers, they have nothing to do with DWC3. PHYs
> > > > > don't care about the USB controller.
> > > > 
> > > > I think they are SNPS DesignWare PHY's, additionally
> > > > wrapped with Qualcomm logic. I could substitute "dwc3"
> > > > with just "dw", which will be more correct.
> > > 
> > > alright, thank you. Let's add Paul to the loop since he might have very
> > > good insight in the synopsys PHYs.
> > > 
> > > mental note: if any other platform shows up with Synopsys PHY, ask them
> > > to use this driver instead :-)
> > 
> > I really doubt that this will bi possible. Control of the PHY's is
> > not directly trough ULPI, UTMI or PIPE3 interfaces, but trough
> > QSCRATCH registers, which of course is highly Qualcomm specific.
> 
> isn't it a memory mapped IP ? doesn't synopsys provide their own set of
> registers ?

From what I see it is not directly mapped. How QSCRATCH write and
reads transactions are translated to DW IP is unclear to me.

Ivan




--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Kumar Gala Aug. 20, 2013, 3:01 p.m. UTC | #7
On Aug 20, 2013, at 9:54 AM, Ivan T. Ivanov wrote:

> 
> Hi, 
> 
> On Tue, 2013-08-20 at 09:33 -0500, Felipe Balbi wrote: 
>> On Tue, Aug 20, 2013 at 05:09:11PM +0300, Ivan T. Ivanov wrote:
>>> Hi,
>>> 
>>> On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote: 
>>>> Hi,
>>>> 
>>>> On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote:
>>>>>> On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
>>>>>>> From: "Ivan T. Ivanov" <iivanov@mm-sol.com>
>>>>>>> 
>>>>>>> These drivers handles control and configuration of the HS
>>>>>>> and SS USB PHY transceivers. They are part of the driver
>>>>>>> which manage Synopsys DesignWare USB3 controller stack
>>>>>>> inside Qualcomm SoC's.
>>>>>>> 
>>>>>>> Signed-off-by: Ivan T. Ivanov <iivanov@mm-sol.com>
>>>>>>> ---
>>>>>>> drivers/usb/phy/Kconfig           |   11 ++
>>>>>>> drivers/usb/phy/Makefile          |    2 +
>>>>>>> drivers/usb/phy/phy-msm-dwc3-hs.c |  327 ++++++++++++++++++++++++++++++++
>>>>>>> drivers/usb/phy/phy-msm-dwc3-ss.c |  374 +++++++++++++++++++++++++++++++++++++
>>>>>> 
>>>>>> please rename these PHY drivers, they have nothing to do with DWC3. PHYs
>>>>>> don't care about the USB controller.
>>>>> 
>>>>> I think they are SNPS DesignWare PHY's, additionally
>>>>> wrapped with Qualcomm logic. I could substitute "dwc3"
>>>>> with just "dw", which will be more correct.
>>>> 
>>>> alright, thank you. Let's add Paul to the loop since he might have very
>>>> good insight in the synopsys PHYs.
>>>> 
>>>> mental note: if any other platform shows up with Synopsys PHY, ask them
>>>> to use this driver instead :-)
>>> 
>>> I really doubt that this will bi possible. Control of the PHY's is
>>> not directly trough ULPI, UTMI or PIPE3 interfaces, but trough
>>> QSCRATCH registers, which of course is highly Qualcomm specific.
>> 
>> isn't it a memory mapped IP ? doesn't synopsys provide their own set of
>> registers ?
> 
> From what I see it is not directly mapped. How QSCRATCH write and
> reads transactions are translated to DW IP is unclear to me.


I think the question is how does SW access them?

- k
Pawel Moll Aug. 20, 2013, 3:06 p.m. UTC | #8
On Tue, 2013-08-20 at 16:01 +0100, Kumar Gala wrote:
> On Aug 20, 2013, at 9:54 AM, Ivan T. Ivanov wrote:
> 
> > 
> > Hi, 
> > 
> > On Tue, 2013-08-20 at 09:33 -0500, Felipe Balbi wrote: 
> >> On Tue, Aug 20, 2013 at 05:09:11PM +0300, Ivan T. Ivanov wrote:
> >>> Hi,
> >>> 
> >>> On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote: 
> >>>> Hi,
> >>>> 
> >>>> On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote:
> >>>>>> On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
> >>>>>>> From: "Ivan T. Ivanov" <iivanov@mm-sol.com>
> >>>>>>> 
> >>>>>>> These drivers handles control and configuration of the HS
> >>>>>>> and SS USB PHY transceivers. They are part of the driver
> >>>>>>> which manage Synopsys DesignWare USB3 controller stack
> >>>>>>> inside Qualcomm SoC's.
> >>>>>>> 
> >>>>>>> Signed-off-by: Ivan T. Ivanov <iivanov@mm-sol.com>
> >>>>>>> ---
> >>>>>>> drivers/usb/phy/Kconfig           |   11 ++
> >>>>>>> drivers/usb/phy/Makefile          |    2 +
> >>>>>>> drivers/usb/phy/phy-msm-dwc3-hs.c |  327 ++++++++++++++++++++++++++++++++
> >>>>>>> drivers/usb/phy/phy-msm-dwc3-ss.c |  374 +++++++++++++++++++++++++++++++++++++
> >>>>>> 
> >>>>>> please rename these PHY drivers, they have nothing to do with DWC3. PHYs
> >>>>>> don't care about the USB controller.
> >>>>> 
> >>>>> I think they are SNPS DesignWare PHY's, additionally
> >>>>> wrapped with Qualcomm logic. I could substitute "dwc3"
> >>>>> with just "dw", which will be more correct.
> >>>> 
> >>>> alright, thank you. Let's add Paul to the loop since he might have very
> >>>> good insight in the synopsys PHYs.
> >>>> 
> >>>> mental note: if any other platform shows up with Synopsys PHY, ask them
> >>>> to use this driver instead :-)
> >>> 
> >>> I really doubt that this will bi possible. Control of the PHY's is
> >>> not directly trough ULPI, UTMI or PIPE3 interfaces, but trough
> >>> QSCRATCH registers, which of course is highly Qualcomm specific.
> >> 
> >> isn't it a memory mapped IP ? doesn't synopsys provide their own set of
> >> registers ?
> > 
> > From what I see it is not directly mapped. How QSCRATCH write and
> > reads transactions are translated to DW IP is unclear to me.
> 
> 
> I think the question is how does SW access them?

I afraid the answer may be: "it depends on the SOC". In my past I had to
initialize a (SATA) PHY by implementing a software JTAG state machine,
as the PHY's registers were not memory mapped *at all*. And the IP
itself came from Synopsys, Cadence or yet another EDA company...

Pawe?


--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ivan T. Ivanov Aug. 20, 2013, 3:26 p.m. UTC | #9
On Tue, 2013-08-20 at 10:01 -0500, Kumar Gala wrote: 
> On Aug 20, 2013, at 9:54 AM, Ivan T. Ivanov wrote:
> 
> > 
> > Hi, 
> > 
> > On Tue, 2013-08-20 at 09:33 -0500, Felipe Balbi wrote: 
> >> On Tue, Aug 20, 2013 at 05:09:11PM +0300, Ivan T. Ivanov wrote:
> >>> Hi,
> >>> 
> >>> On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote: 
> >>>> Hi,
> >>>> 
> >>>> On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote:
> >>>>>> On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
> >>>>>>> From: "Ivan T. Ivanov" <iivanov@mm-sol.com>
> >>>>>>> 
> >>>>>>> These drivers handles control and configuration of the HS
> >>>>>>> and SS USB PHY transceivers. They are part of the driver
> >>>>>>> which manage Synopsys DesignWare USB3 controller stack
> >>>>>>> inside Qualcomm SoC's.
> >>>>>>> 
> >>>>>>> Signed-off-by: Ivan T. Ivanov <iivanov@mm-sol.com>
> >>>>>>> ---
> >>>>>>> drivers/usb/phy/Kconfig           |   11 ++
> >>>>>>> drivers/usb/phy/Makefile          |    2 +
> >>>>>>> drivers/usb/phy/phy-msm-dwc3-hs.c |  327 ++++++++++++++++++++++++++++++++
> >>>>>>> drivers/usb/phy/phy-msm-dwc3-ss.c |  374 +++++++++++++++++++++++++++++++++++++
> >>>>>> 
> >>>>>> please rename these PHY drivers, they have nothing to do with DWC3. PHYs
> >>>>>> don't care about the USB controller.
> >>>>> 
> >>>>> I think they are SNPS DesignWare PHY's, additionally
> >>>>> wrapped with Qualcomm logic. I could substitute "dwc3"
> >>>>> with just "dw", which will be more correct.
> >>>> 
> >>>> alright, thank you. Let's add Paul to the loop since he might have very
> >>>> good insight in the synopsys PHYs.
> >>>> 
> >>>> mental note: if any other platform shows up with Synopsys PHY, ask them
> >>>> to use this driver instead :-)
> >>> 
> >>> I really doubt that this will bi possible. Control of the PHY's is
> >>> not directly trough ULPI, UTMI or PIPE3 interfaces, but trough
> >>> QSCRATCH registers, which of course is highly Qualcomm specific.
> >> 
> >> isn't it a memory mapped IP ? doesn't synopsys provide their own set of
> >> registers ?
> > 
> > From what I see it is not directly mapped. How QSCRATCH write and
> > reads transactions are translated to DW IP is unclear to me.
> 
> 
> I think the question is how does SW access them?

"USB QSCRATCH Hardware registers" don't ask me what is this :-)
or like Pawel says: "it depends on the SOC" .

Ivan

> 
> - k
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Pawel Moll Aug. 20, 2013, 5:01 p.m. UTC | #10
On Tue, 2013-08-20 at 16:06 +0100, Pawel Moll wrote:
> On Tue, 2013-08-20 at 16:01 +0100, Kumar Gala wrote:
> > On Aug 20, 2013, at 9:54 AM, Ivan T. Ivanov wrote:
> > 
> > > 
> > > Hi, 
> > > 
> > > On Tue, 2013-08-20 at 09:33 -0500, Felipe Balbi wrote: 
> > >> On Tue, Aug 20, 2013 at 05:09:11PM +0300, Ivan T. Ivanov wrote:
> > >>> Hi,
> > >>> 
> > >>> On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote: 
> > >>>> Hi,
> > >>>> 
> > >>>> On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote:
> > >>>>>> On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
> > >>>>>>> From: "Ivan T. Ivanov" <iivanov@mm-sol.com>
> > >>>>>>> 
> > >>>>>>> These drivers handles control and configuration of the HS
> > >>>>>>> and SS USB PHY transceivers. They are part of the driver
> > >>>>>>> which manage Synopsys DesignWare USB3 controller stack
> > >>>>>>> inside Qualcomm SoC's.
> > >>>>>>> 
> > >>>>>>> Signed-off-by: Ivan T. Ivanov <iivanov@mm-sol.com>
> > >>>>>>> ---
> > >>>>>>> drivers/usb/phy/Kconfig           |   11 ++
> > >>>>>>> drivers/usb/phy/Makefile          |    2 +
> > >>>>>>> drivers/usb/phy/phy-msm-dwc3-hs.c |  327 ++++++++++++++++++++++++++++++++
> > >>>>>>> drivers/usb/phy/phy-msm-dwc3-ss.c |  374 +++++++++++++++++++++++++++++++++++++
> > >>>>>> 
> > >>>>>> please rename these PHY drivers, they have nothing to do with DWC3. PHYs
> > >>>>>> don't care about the USB controller.
> > >>>>> 
> > >>>>> I think they are SNPS DesignWare PHY's, additionally
> > >>>>> wrapped with Qualcomm logic. I could substitute "dwc3"
> > >>>>> with just "dw", which will be more correct.
> > >>>> 
> > >>>> alright, thank you. Let's add Paul to the loop since he might have very
> > >>>> good insight in the synopsys PHYs.
> > >>>> 
> > >>>> mental note: if any other platform shows up with Synopsys PHY, ask them
> > >>>> to use this driver instead :-)
> > >>> 
> > >>> I really doubt that this will bi possible. Control of the PHY's is
> > >>> not directly trough ULPI, UTMI or PIPE3 interfaces, but trough
> > >>> QSCRATCH registers, which of course is highly Qualcomm specific.
> > >> 
> > >> isn't it a memory mapped IP ? doesn't synopsys provide their own set of
> > >> registers ?
> > > 
> > > From what I see it is not directly mapped. How QSCRATCH write and
> > > reads transactions are translated to DW IP is unclear to me.
> > 
> > 
> > I think the question is how does SW access them?
> 
> I afraid the answer may be: "it depends on the SOC". In my past I had to
> initialize a (SATA) PHY by implementing a software JTAG state machine,
> as the PHY's registers were not memory mapped *at all*. And the IP
> itself came from Synopsys, Cadence or yet another EDA company...

Having said all that... If the PHY's spec at least defined layout of the
registers in question and driver was using regmap API to talk to the
device (initially regmap-mmio), it has some chances to become universal.
The SOCs designed like "my" one would have to provide a custom regmap
implementation.

Pawe?


--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ivan T. Ivanov Aug. 21, 2013, 1:06 p.m. UTC | #11
On Tue, 2013-08-20 at 18:01 +0100, Pawel Moll wrote: 
> On Tue, 2013-08-20 at 16:06 +0100, Pawel Moll wrote:
> > On Tue, 2013-08-20 at 16:01 +0100, Kumar Gala wrote:
> > > On Aug 20, 2013, at 9:54 AM, Ivan T. Ivanov wrote:
> > > 
> > > > 
> > > > Hi, 
> > > > 
> > > > On Tue, 2013-08-20 at 09:33 -0500, Felipe Balbi wrote: 
> > > >> On Tue, Aug 20, 2013 at 05:09:11PM +0300, Ivan T. Ivanov wrote:
> > > >>> Hi,
> > > >>> 
> > > >>> On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote: 
> > > >>>> Hi,
> > > >>>> 
> > > >>>> On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote:
> > > >>>>>> On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
> > > >>>>>>> From: "Ivan T. Ivanov" <iivanov@mm-sol.com>
> > > >>>>>>> 
> > > >>>>>>> These drivers handles control and configuration of the HS
> > > >>>>>>> and SS USB PHY transceivers. They are part of the driver
> > > >>>>>>> which manage Synopsys DesignWare USB3 controller stack
> > > >>>>>>> inside Qualcomm SoC's.
> > > >>>>>>> 
> > > >>>>>>> Signed-off-by: Ivan T. Ivanov <iivanov@mm-sol.com>
> > > >>>>>>> ---
> > > >>>>>>> drivers/usb/phy/Kconfig           |   11 ++
> > > >>>>>>> drivers/usb/phy/Makefile          |    2 +
> > > >>>>>>> drivers/usb/phy/phy-msm-dwc3-hs.c |  327 ++++++++++++++++++++++++++++++++
> > > >>>>>>> drivers/usb/phy/phy-msm-dwc3-ss.c |  374 +++++++++++++++++++++++++++++++++++++
> > > >>>>>> 
> > > >>>>>> please rename these PHY drivers, they have nothing to do with DWC3. PHYs
> > > >>>>>> don't care about the USB controller.
> > > >>>>> 
> > > >>>>> I think they are SNPS DesignWare PHY's, additionally
> > > >>>>> wrapped with Qualcomm logic. I could substitute "dwc3"
> > > >>>>> with just "dw", which will be more correct.
> > > >>>> 
> > > >>>> alright, thank you. Let's add Paul to the loop since he might have very
> > > >>>> good insight in the synopsys PHYs.
> > > >>>> 
> > > >>>> mental note: if any other platform shows up with Synopsys PHY, ask them
> > > >>>> to use this driver instead :-)
> > > >>> 
> > > >>> I really doubt that this will bi possible. Control of the PHY's is
> > > >>> not directly trough ULPI, UTMI or PIPE3 interfaces, but trough
> > > >>> QSCRATCH registers, which of course is highly Qualcomm specific.
> > > >> 
> > > >> isn't it a memory mapped IP ? doesn't synopsys provide their own set of
> > > >> registers ?
> > > > 
> > > > From what I see it is not directly mapped. How QSCRATCH write and
> > > > reads transactions are translated to DW IP is unclear to me.
> > > 
> > > 
> > > I think the question is how does SW access them?
> > 
> > I afraid the answer may be: "it depends on the SOC". In my past I had to
> > initialize a (SATA) PHY by implementing a software JTAG state machine,
> > as the PHY's registers were not memory mapped *at all*. And the IP
> > itself came from Synopsys, Cadence or yet another EDA company...
> 
> Having said all that... If the PHY's spec at least defined layout of the
> registers in question and driver was using regmap API to talk to the
> device (initially regmap-mmio), it has some chances to become universal.
> The SOCs designed like "my" one would have to provide a custom regmap
> implementation.

Sound reasonable. Unfortunately I don't have PHY's IP spec. 

Regards,
Ivan

> 
> Pawe?
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Felipe Balbi Aug. 22, 2013, 8:41 p.m. UTC | #12
On Wed, Aug 21, 2013 at 10:13:28AM -0500, Kumar Gala wrote:
> 
> On Aug 21, 2013, at 8:06 AM, Ivan T. Ivanov wrote:
> 
> > On Tue, 2013-08-20 at 18:01 +0100, Pawel Moll wrote: 
> >> On Tue, 2013-08-20 at 16:06 +0100, Pawel Moll wrote:
> >>> On Tue, 2013-08-20 at 16:01 +0100, Kumar Gala wrote:
> >>>> On Aug 20, 2013, at 9:54 AM, Ivan T. Ivanov wrote:
> >>>> 
> >>>>> 
> >>>>> Hi, 
> >>>>> 
> >>>>> On Tue, 2013-08-20 at 09:33 -0500, Felipe Balbi wrote: 
> >>>>>> On Tue, Aug 20, 2013 at 05:09:11PM +0300, Ivan T. Ivanov wrote:
> >>>>>>> Hi,
> >>>>>>> 
> >>>>>>> On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote: 
> >>>>>>>> Hi,
> >>>>>>>> 
> >>>>>>>> On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote:
> >>>>>>>>>> On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
> >>>>>>>>>>> From: "Ivan T. Ivanov" <iivanov@mm-sol.com>
> >>>>>>>>>>> 
> >>>>>>>>>>> These drivers handles control and configuration of the HS
> >>>>>>>>>>> and SS USB PHY transceivers. They are part of the driver
> >>>>>>>>>>> which manage Synopsys DesignWare USB3 controller stack
> >>>>>>>>>>> inside Qualcomm SoC's.
> >>>>>>>>>>> 
> >>>>>>>>>>> Signed-off-by: Ivan T. Ivanov <iivanov@mm-sol.com>
> >>>>>>>>>>> ---
> >>>>>>>>>>> drivers/usb/phy/Kconfig           |   11 ++
> >>>>>>>>>>> drivers/usb/phy/Makefile          |    2 +
> >>>>>>>>>>> drivers/usb/phy/phy-msm-dwc3-hs.c |  327 ++++++++++++++++++++++++++++++++
> >>>>>>>>>>> drivers/usb/phy/phy-msm-dwc3-ss.c |  374 +++++++++++++++++++++++++++++++++++++
> >>>>>>>>>> 
> >>>>>>>>>> please rename these PHY drivers, they have nothing to do with DWC3. PHYs
> >>>>>>>>>> don't care about the USB controller.
> >>>>>>>>> 
> >>>>>>>>> I think they are SNPS DesignWare PHY's, additionally
> >>>>>>>>> wrapped with Qualcomm logic. I could substitute "dwc3"
> >>>>>>>>> with just "dw", which will be more correct.
> >>>>>>>> 
> >>>>>>>> alright, thank you. Let's add Paul to the loop since he might have very
> >>>>>>>> good insight in the synopsys PHYs.
> >>>>>>>> 
> >>>>>>>> mental note: if any other platform shows up with Synopsys PHY, ask them
> >>>>>>>> to use this driver instead :-)
> >>>>>>> 
> >>>>>>> I really doubt that this will bi possible. Control of the PHY's is
> >>>>>>> not directly trough ULPI, UTMI or PIPE3 interfaces, but trough
> >>>>>>> QSCRATCH registers, which of course is highly Qualcomm specific.
> >>>>>> 
> >>>>>> isn't it a memory mapped IP ? doesn't synopsys provide their own set of
> >>>>>> registers ?
> >>>>> 
> >>>>> From what I see it is not directly mapped. How QSCRATCH write and
> >>>>> reads transactions are translated to DW IP is unclear to me.
> >>>> 
> >>>> 
> >>>> I think the question is how does SW access them?
> >>> 
> >>> I afraid the answer may be: "it depends on the SOC". In my past I had to
> >>> initialize a (SATA) PHY by implementing a software JTAG state machine,
> >>> as the PHY's registers were not memory mapped *at all*. And the IP
> >>> itself came from Synopsys, Cadence or yet another EDA company...
> >> 
> >> Having said all that... If the PHY's spec at least defined layout of the
> >> registers in question and driver was using regmap API to talk to the
> >> device (initially regmap-mmio), it has some chances to become universal.
> >> The SOCs designed like "my" one would have to provide a custom regmap
> >> implementation.
> > 
> > Sound reasonable. Unfortunately I don't have PHY's IP spec. 
> 
> Looking into this it appears that the register wrapper around the IP
> is most likely highly specific to qualcomm as I'm not seeing a
> register interface around the DWC HS PHY.

Then it's set, we'll go with this driver :-)
Paul Zimmerman Aug. 22, 2013, 9:24 p.m. UTC | #13
> From: Ivan T. Ivanov [mailto:iivanov@mm-sol.com]

> Sent: Tuesday, August 20, 2013 8:26 AM

> 

> On Tue, 2013-08-20 at 10:01 -0500, Kumar Gala wrote:

> > On Aug 20, 2013, at 9:54 AM, Ivan T. Ivanov wrote:

> >

> > >

> > > Hi,

> > >

> > > On Tue, 2013-08-20 at 09:33 -0500, Felipe Balbi wrote:

> > >> On Tue, Aug 20, 2013 at 05:09:11PM +0300, Ivan T. Ivanov wrote:

> > >>>

> > >>> On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote:

> > >>>>

> > >>>> On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote:

> > >>>>>

> > >>>>> I think they are SNPS DesignWare PHY's, additionally

> > >>>>> wrapped with Qualcomm logic. I could substitute "dwc3"

> > >>>>> with just "dw", which will be more correct.

> > >>>>

> > >>>> alright, thank you. Let's add Paul to the loop since he might have very

> > >>>> good insight in the synopsys PHYs.

> > >>>>

> > >>>> mental note: if any other platform shows up with Synopsys PHY, ask them

> > >>>> to use this driver instead :-)

> > >>>

> > >>> I really doubt that this will bi possible. Control of the PHY's is

> > >>> not directly trough ULPI, UTMI or PIPE3 interfaces, but trough

> > >>> QSCRATCH registers, which of course is highly Qualcomm specific.

> > >>

> > >> isn't it a memory mapped IP ? doesn't synopsys provide their own set of

> > >> registers ?

> > >

> > > From what I see it is not directly mapped. How QSCRATCH write and

> > > reads transactions are translated to DW IP is unclear to me.

> >

> >

> > I think the question is how does SW access them?

> 

> "USB QSCRATCH Hardware registers" don't ask me what is this :-)

> or like Pawel says: "it depends on the SOC" .


To answer the question "doesn't synopsys provide their own set of
registers", we provide registers in our USB cores to access the PHYs
through I2C, ULPI/UTMI, or PIPE3 interfaces. But if someone wants to use
our PHY with some other controller that doesn't provide that, then they
may need to implement their own register set, as Qualcomm has apparently
done.

-- 
Paul
Felipe Balbi Aug. 27, 2013, 7:58 p.m. UTC | #14
Hi,

On Thu, Aug 22, 2013 at 09:24:49PM +0000, Paul Zimmerman wrote:
> > From: Ivan T. Ivanov [mailto:iivanov@mm-sol.com]
> > Sent: Tuesday, August 20, 2013 8:26 AM
> > 
> > On Tue, 2013-08-20 at 10:01 -0500, Kumar Gala wrote:
> > > On Aug 20, 2013, at 9:54 AM, Ivan T. Ivanov wrote:
> > >
> > > >
> > > > Hi,
> > > >
> > > > On Tue, 2013-08-20 at 09:33 -0500, Felipe Balbi wrote:
> > > >> On Tue, Aug 20, 2013 at 05:09:11PM +0300, Ivan T. Ivanov wrote:
> > > >>>
> > > >>> On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote:
> > > >>>>
> > > >>>> On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote:
> > > >>>>>
> > > >>>>> I think they are SNPS DesignWare PHY's, additionally
> > > >>>>> wrapped with Qualcomm logic. I could substitute "dwc3"
> > > >>>>> with just "dw", which will be more correct.
> > > >>>>
> > > >>>> alright, thank you. Let's add Paul to the loop since he might have very
> > > >>>> good insight in the synopsys PHYs.
> > > >>>>
> > > >>>> mental note: if any other platform shows up with Synopsys PHY, ask them
> > > >>>> to use this driver instead :-)
> > > >>>
> > > >>> I really doubt that this will bi possible. Control of the PHY's is
> > > >>> not directly trough ULPI, UTMI or PIPE3 interfaces, but trough
> > > >>> QSCRATCH registers, which of course is highly Qualcomm specific.
> > > >>
> > > >> isn't it a memory mapped IP ? doesn't synopsys provide their own set of
> > > >> registers ?
> > > >
> > > > From what I see it is not directly mapped. How QSCRATCH write and
> > > > reads transactions are translated to DW IP is unclear to me.
> > >
> > >
> > > I think the question is how does SW access them?
> > 
> > "USB QSCRATCH Hardware registers" don't ask me what is this :-)
> > or like Pawel says: "it depends on the SOC" .
> 
> To answer the question "doesn't synopsys provide their own set of
> registers", we provide registers in our USB cores to access the PHYs
> through I2C, ULPI/UTMI, or PIPE3 interfaces. But if someone wants to use
> our PHY with some other controller that doesn't provide that, then they
> may need to implement their own register set, as Qualcomm has apparently
> done.

thanks for clarifying. that pretty much hinders writing any sort of
generic drivers for Synopsys' PHYs though :-s

But I guess that's alright.
Ivan T. Ivanov Aug. 29, 2013, 5:28 p.m. UTC | #15
On Thu, 2013-08-22 at 15:41 -0500, Felipe Balbi wrote:
> On Wed, Aug 21, 2013 at 10:13:28AM -0500, Kumar Gala wrote:
> > 
> > On Aug 21, 2013, at 8:06 AM, Ivan T. Ivanov wrote:
> > 
> > > On Tue, 2013-08-20 at 18:01 +0100, Pawel Moll wrote: 
> > >> On Tue, 2013-08-20 at 16:06 +0100, Pawel Moll wrote:
> > >>> On Tue, 2013-08-20 at 16:01 +0100, Kumar Gala wrote:
> > >>>> On Aug 20, 2013, at 9:54 AM, Ivan T. Ivanov wrote:
> > >>>> 
> > >>>>> 
> > >>>>> Hi, 
> > >>>>> 
> > >>>>> On Tue, 2013-08-20 at 09:33 -0500, Felipe Balbi wrote: 
> > >>>>>> On Tue, Aug 20, 2013 at 05:09:11PM +0300, Ivan T. Ivanov wrote:
> > >>>>>>> Hi,
> > >>>>>>> 
> > >>>>>>> On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote: 
> > >>>>>>>> Hi,
> > >>>>>>>> 
> > >>>>>>>> On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote:
> > >>>>>>>>>> On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote:
> > >>>>>>>>>>> From: "Ivan T. Ivanov" <iivanov@mm-sol.com>
> > >>>>>>>>>>> 
> > >>>>>>>>>>> These drivers handles control and configuration of the HS
> > >>>>>>>>>>> and SS USB PHY transceivers. They are part of the driver
> > >>>>>>>>>>> which manage Synopsys DesignWare USB3 controller stack
> > >>>>>>>>>>> inside Qualcomm SoC's.
> > >>>>>>>>>>> 
> > >>>>>>>>>>> Signed-off-by: Ivan T. Ivanov <iivanov@mm-sol.com>
> > >>>>>>>>>>> ---
> > >>>>>>>>>>> drivers/usb/phy/Kconfig           |   11 ++
> > >>>>>>>>>>> drivers/usb/phy/Makefile          |    2 +
> > >>>>>>>>>>> drivers/usb/phy/phy-msm-dwc3-hs.c |  327 ++++++++++++++++++++++++++++++++
> > >>>>>>>>>>> drivers/usb/phy/phy-msm-dwc3-ss.c |  374 +++++++++++++++++++++++++++++++++++++
> > >>>>>>>>>> 
> > >>>>>>>>>> please rename these PHY drivers, they have nothing to do with DWC3. PHYs
> > >>>>>>>>>> don't care about the USB controller.
> > >>>>>>>>> 
> > >>>>>>>>> I think they are SNPS DesignWare PHY's, additionally
> > >>>>>>>>> wrapped with Qualcomm logic. I could substitute "dwc3"
> > >>>>>>>>> with just "dw", which will be more correct.
> > >>>>>>>> 
> > >>>>>>>> alright, thank you. Let's add Paul to the loop since he might have very
> > >>>>>>>> good insight in the synopsys PHYs.
> > >>>>>>>> 
> > >>>>>>>> mental note: if any other platform shows up with Synopsys PHY, ask them
> > >>>>>>>> to use this driver instead :-)
> > >>>>>>> 
> > >>>>>>> I really doubt that this will bi possible. Control of the PHY's is
> > >>>>>>> not directly trough ULPI, UTMI or PIPE3 interfaces, but trough
> > >>>>>>> QSCRATCH registers, which of course is highly Qualcomm specific.
> > >>>>>> 
> > >>>>>> isn't it a memory mapped IP ? doesn't synopsys provide their own set of
> > >>>>>> registers ?
> > >>>>> 
> > >>>>> From what I see it is not directly mapped. How QSCRATCH write and
> > >>>>> reads transactions are translated to DW IP is unclear to me.
> > >>>> 
> > >>>> 
> > >>>> I think the question is how does SW access them?
> > >>> 
> > >>> I afraid the answer may be: "it depends on the SOC". In my past I had to
> > >>> initialize a (SATA) PHY by implementing a software JTAG state machine,
> > >>> as the PHY's registers were not memory mapped *at all*. And the IP
> > >>> itself came from Synopsys, Cadence or yet another EDA company...
> > >> 
> > >> Having said all that... If the PHY's spec at least defined layout of the
> > >> registers in question and driver was using regmap API to talk to the
> > >> device (initially regmap-mmio), it has some chances to become universal.
> > >> The SOCs designed like "my" one would have to provide a custom regmap
> > >> implementation.
> > > 
> > > Sound reasonable. Unfortunately I don't have PHY's IP spec. 
> > 
> > Looking into this it appears that the register wrapper around the IP
> > is most likely highly specific to qualcomm as I'm not seeing a
> > register interface around the DWC HS PHY.
> 
> Then it's set, we'll go with this driver :-)
> 

Does this mean that driver could be merged? 

Regards,
Ivan


--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index d5589f9..c525835 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -214,6 +214,17 @@  config USB_RCAR_PHY
 	  To compile this driver as a module, choose M here: the
 	  module will be called phy-rcar-usb.
 
+config USB_MSM_DWC3_PHYS
+	tristate "Qualcomm DWC3 USB controller PHY's support"
+	depends on (USB || USB_GADGET) && ARCH_MSM
+	select USB_PHY
+	help
+	  Enable this to support the USB PHY transceivers on MSM chips with
+	  DWC3 USB core. It handles PHY initialization, clock management
+	  required after resetting the hardware and power management.
+	  This driver is required even for peripheral only or host only
+	  mode configurations.
+
 config USB_ULPI
 	bool "Generic ULPI Transceiver Driver"
 	depends on ARM
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 2135e85..8f2dd94 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -26,6 +26,8 @@  obj-$(CONFIG_USB_EHCI_TEGRA)		+= phy-tegra-usb.o
 obj-$(CONFIG_USB_GPIO_VBUS)		+= phy-gpio-vbus-usb.o
 obj-$(CONFIG_USB_ISP1301)		+= phy-isp1301.o
 obj-$(CONFIG_USB_MSM_OTG)		+= phy-msm-usb.o
+obj-$(CONFIG_USB_MSM_DWC3_PHYS)		+= phy-msm-dwc3-hs.o
+obj-$(CONFIG_USB_MSM_DWC3_PHYS)		+= phy-msm-dwc3-ss.o
 obj-$(CONFIG_USB_MV_OTG)		+= phy-mv-usb.o
 obj-$(CONFIG_USB_MXS_PHY)		+= phy-mxs-usb.o
 obj-$(CONFIG_USB_RCAR_PHY)		+= phy-rcar-usb.o
diff --git a/drivers/usb/phy/phy-msm-dwc3-hs.c b/drivers/usb/phy/phy-msm-dwc3-hs.c
new file mode 100644
index 0000000..840e766
--- /dev/null
+++ b/drivers/usb/phy/phy-msm-dwc3-hs.c
@@ -0,0 +1,327 @@ 
+/* Copyright (c) 2013, Code Aurora Forum. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
+#include <linux/usb/phy.h>
+
+/**
+ *  USB QSCRATCH Hardware registers
+ */
+#define QSCRATCH_CTRL_REG		(0x04)
+#define QSCRATCH_GENERAL_CFG		(0x08)
+#define PHY_CTRL_REG			(0x10)
+#define PARAMETER_OVERRIDE_X_REG	(0x14)
+#define CHARGING_DET_CTRL_REG		(0x18)
+#define CHARGING_DET_OUTPUT_REG		(0x1c)
+#define ALT_INTERRUPT_EN_REG		(0x20)
+#define PHY_IRQ_STAT_REG		(0x24)
+#define CGCTL_REG			(0x28)
+
+#define PHY_3P3_VOL_MIN			3050000 /* uV */
+#define PHY_3P3_VOL_MAX			3300000 /* uV */
+#define PHY_3P3_HPM_LOAD		16000	/* uA */
+
+#define PHY_1P8_VOL_MIN			1800000 /* uV */
+#define PHY_1P8_VOL_MAX			1800000 /* uV */
+#define PHY_1P8_HPM_LOAD		19000	/* uA */
+
+/* TODO: these are suspicious */
+#define USB_VDDCX_NO			1	/* uV */
+#define USB_VDDCX_MIN			5	/* uV */
+#define USB_VDDCX_MAX			7	/* uV */
+
+struct msm_dwc3_hs_phy {
+	struct usb_phy		phy;
+	void __iomem		*base;
+	struct device		*dev;
+
+	struct clk		*xo_clk;
+	struct clk		*sleep_a_clk;
+
+	struct regulator	*v3p3;
+	struct regulator	*v1p8;
+	struct regulator	*vddcx;
+	struct regulator	*vbus;
+};
+
+#define	phy_to_dwc3_phy(x)	container_of((x), struct msm_dwc3_hs_phy, phy)
+
+
+/**
+ * Write register.
+ *
+ * @base - MSM DWC3 PHY base virtual address.
+ * @offset - register offset.
+ * @val - value to write.
+ */
+static inline void msm_dwc3_hs_write(void __iomem *base, u32 offset, u32 val)
+{
+	iowrite32(val, base + offset);
+}
+
+/**
+ * Write register and read back masked value to confirm it is written
+ *
+ * @base - MSM DWC3 PHY base virtual address.
+ * @offset - register offset.
+ * @mask - register bitmask specifying what should be updated
+ * @val - value to write.
+ */
+static inline void msm_dwc3_hs_write_readback(void __iomem *base, u32 offset,
+					    const u32 mask, u32 val)
+{
+	u32 write_val, tmp = ioread32(base + offset);
+
+	tmp &= ~mask;		/* retain other bits */
+	write_val = tmp | val;
+
+	iowrite32(write_val, base + offset);
+
+	/* Read back to see if val was written */
+	tmp = ioread32(base + offset);
+	tmp &= mask;		/* clear other bits */
+
+	if (tmp != val)
+		pr_err("write: %x to QSCRATCH: %x FAILED\n", val, offset);
+}
+
+static void msm_dwc3_hs_phy_shutdown(struct usb_phy *x)
+{
+	struct msm_dwc3_hs_phy *phy = phy_to_dwc3_phy(x);
+	int ret;
+
+	ret = regulator_set_voltage(phy->v3p3, 0, PHY_3P3_VOL_MAX);
+	if (ret)
+		dev_err(phy->dev, "cannot set voltage for v3p3\n");
+
+	ret = regulator_set_voltage(phy->v1p8, 0, PHY_1P8_VOL_MAX);
+	if (ret)
+		dev_err(phy->dev, "cannot set voltage for v1p8\n");
+
+	ret = regulator_disable(phy->v1p8);
+	if (ret)
+		dev_err(phy->dev, "cannot disable v1p8\n");
+
+	ret = regulator_disable(phy->v3p3);
+	if (ret)
+		dev_err(phy->dev, "cannot disable v3p3\n");
+
+	ret = regulator_set_voltage(phy->vddcx, USB_VDDCX_NO, USB_VDDCX_MAX);
+	if (ret)
+		dev_err(phy->dev, "cannot set voltage for vddcx\n");
+
+	ret = regulator_disable(phy->vddcx);
+	if (ret)
+		dev_err(phy->dev, "cannot enable vddcx\n");
+
+	clk_disable_unprepare(phy->sleep_a_clk);
+}
+
+static int msm_dwc3_hs_phy_init(struct usb_phy *x)
+{
+	struct msm_dwc3_hs_phy	*phy = phy_to_dwc3_phy(x);
+	int ret;
+
+	clk_prepare_enable(phy->sleep_a_clk);
+
+	ret = regulator_set_voltage(phy->vddcx, USB_VDDCX_MIN, USB_VDDCX_MAX);
+	if (ret) {
+		dev_err(phy->dev, "cannot set voltage for vddcx\n");
+		return ret;
+	}
+
+	ret = regulator_enable(phy->vddcx);
+	if (ret) {
+		dev_err(phy->dev, "cannot enable vddcx\n");
+		return ret;
+	}
+
+	ret = regulator_set_voltage(phy->v3p3, PHY_3P3_VOL_MIN,
+				    PHY_3P3_VOL_MAX);
+	if (ret) {
+		dev_err(phy->dev, "cannot set voltage for v3p3\n");
+		return ret;
+	}
+
+	ret = regulator_set_voltage(phy->v1p8, PHY_1P8_VOL_MIN,
+				    PHY_1P8_VOL_MAX);
+	if (ret) {
+		dev_err(phy->dev, "cannot set voltage for v1p8\n");
+		return ret;
+	}
+
+	ret = regulator_set_optimum_mode(phy->v1p8, PHY_1P8_HPM_LOAD);
+	if (ret < 0) {
+		dev_err(phy->dev, "cannot set HPM of regulator v1p8\n");
+		return ret;
+	}
+
+	ret = regulator_enable(phy->v1p8);
+	if (ret) {
+		dev_err(phy->dev, "cannot enable v1p8\n");
+		return ret;
+	}
+
+	ret = regulator_set_optimum_mode(phy->v3p3, PHY_3P3_HPM_LOAD);
+	if (ret < 0) {
+		dev_err(phy->dev, "cannot set HPM of regulator v3p3\n");
+		return ret;
+	}
+
+	ret = regulator_enable(phy->v3p3);
+	if (ret) {
+		dev_err(phy->dev, "cannot enable v3p3\n");
+		return ret;
+	}
+
+	/*
+	 * HSPHY Initialization: Enable UTMI clock and clamp enable HVINTs,
+	 * and disable RETENTION (power-on default is ENABLED)
+	 */
+	msm_dwc3_hs_write(phy->base, PHY_CTRL_REG, 0x5220bb2);
+	usleep_range(2000, 2200);
+
+	/*
+	 * write HSPHY init value to QSCRATCH reg to set HSPHY parameters like
+	 * VBUS valid threshold, disconnect valid threshold, DC voltage level,
+	 * preempasis and rise/fall time.
+	 */
+	msm_dwc3_hs_write_readback(phy->base, PARAMETER_OVERRIDE_X_REG,
+				0x03ffffff, 0x00d191a4);
+
+	/* Disable (bypass) VBUS and ID filters */
+	msm_dwc3_hs_write(phy->base, QSCRATCH_GENERAL_CFG, 0x78);
+
+	return 0;
+}
+
+static int msm_dwc3_hs_phy_set_vbus(struct usb_phy *x, int on)
+{
+	struct msm_dwc3_hs_phy	*phy = phy_to_dwc3_phy(x);
+	int ret;
+
+	if (on)
+		ret = regulator_enable(phy->vbus);
+	else
+		ret = regulator_disable(phy->vbus);
+
+	if (ret)
+		dev_err(x->dev, "Cannot %s Vbus\n", on ? "set" : "off");
+	return ret;
+}
+
+static int msm_dwc3_hs_probe(struct platform_device *pdev)
+{
+	struct msm_dwc3_hs_phy	*phy;
+	struct resource		*res;
+	void __iomem		*base;
+
+	phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
+	if (!phy)
+		return -ENOMEM;
+
+	platform_set_drvdata(pdev, phy);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(base))
+		return PTR_ERR(base);
+
+	phy->vddcx = devm_regulator_get(&pdev->dev, "vddcx");
+	if (IS_ERR(phy->vddcx)) {
+		dev_dbg(&pdev->dev, "cannot get vddcx\n");
+		return  PTR_ERR(phy->vddcx);
+	}
+
+	phy->v3p3 = devm_regulator_get(phy->dev, "v3p3");
+	if (IS_ERR(phy->v3p3)) {
+		dev_dbg(phy->dev, "cannot get v3p3\n");
+		return PTR_ERR(phy->v3p3);
+	}
+
+	phy->v1p8 = devm_regulator_get(phy->dev, "v1p8");
+	if (IS_ERR(phy->v1p8)) {
+		dev_dbg(phy->dev, "cannot get v1p8\n");
+		return PTR_ERR(phy->v1p8);
+	}
+
+	phy->vbus = devm_regulator_get(&pdev->dev, "vbus");
+	if (IS_ERR(phy->vbus)) {
+		dev_dbg(phy->dev, "Failed to get vbus\n");
+		return PTR_ERR(phy->vbus);
+	}
+
+	phy->xo_clk = devm_clk_get(&pdev->dev, "xo");
+	if (IS_ERR(phy->xo_clk)) {
+		dev_dbg(&pdev->dev, "cannot get TCXO buffer handle\n");
+		return PTR_ERR(phy->xo_clk);
+	}
+
+	phy->sleep_a_clk = devm_clk_get(&pdev->dev, "sleep_a");
+	if (IS_ERR(phy->sleep_a_clk)) {
+		dev_dbg(&pdev->dev, "failed to get sleep_a clock\n");
+		return PTR_ERR(phy->sleep_a_clk);
+	}
+
+	clk_prepare_enable(phy->xo_clk);
+
+	phy->dev		= &pdev->dev;
+	phy->base		= base;
+	phy->phy.dev		= phy->dev;
+	phy->phy.label		= "msm-dwc3-hsphy";
+	phy->phy.init		= msm_dwc3_hs_phy_init;
+	phy->phy.shutdown	= msm_dwc3_hs_phy_shutdown;
+	phy->phy.set_vbus	= msm_dwc3_hs_phy_set_vbus;
+	phy->phy.type		= USB_PHY_TYPE_USB2;
+	phy->phy.state          = OTG_STATE_UNDEFINED;
+
+	usb_add_phy_dev(&phy->phy);
+
+	return 0;
+}
+
+static int msm_dwc3_hs_remove(struct platform_device *pdev)
+{
+	struct msm_dwc3_hs_phy *phy = platform_get_drvdata(pdev);
+
+	clk_disable_unprepare(phy->xo_clk);
+	usb_remove_phy(&phy->phy);
+	return 0;
+}
+
+static const struct of_device_id msm_dwc3_hs_id_table[] = {
+	{ .compatible = "qcom,dwc3-hsphy" },
+	{ /* Sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, msm_dwc3_hs_id_table);
+
+static struct platform_driver msm_dwc3_hs_driver = {
+	.probe		= msm_dwc3_hs_probe,
+	.remove		= msm_dwc3_hs_remove,
+	.driver		= {
+		.name	= "msm-dwc3-hsphy",
+		.owner	= THIS_MODULE,
+		.of_match_table = msm_dwc3_hs_id_table,
+	},
+};
+
+module_platform_driver(msm_dwc3_hs_driver);
+
+MODULE_ALIAS("platform:msm_dwc3_hsphy");
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("DesignWare USB3 MSM HS-PHY driver");
diff --git a/drivers/usb/phy/phy-msm-dwc3-ss.c b/drivers/usb/phy/phy-msm-dwc3-ss.c
new file mode 100644
index 0000000..9ac46bf
--- /dev/null
+++ b/drivers/usb/phy/phy-msm-dwc3-ss.c
@@ -0,0 +1,374 @@ 
+/* Copyright (c) 2013, Code Aurora Forum. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
+#include <linux/usb/phy.h>
+
+/**
+ *  USB QSCRATCH Hardware registers
+ */
+#define PHY_CTRL_REG			(0x00)
+#define PHY_PARAM_CTRL_1		(0x04)
+#define PHY_PARAM_CTRL_2		(0x08)
+#define CR_PROTOCOL_DATA_IN_REG		(0x0c)
+#define CR_PROTOCOL_DATA_OUT_REG	(0x10)
+#define CR_PROTOCOL_CAP_ADDR_REG	(0x14)
+#define CR_PROTOCOL_CAP_DATA_REG	(0x18)
+#define CR_PROTOCOL_READ_REG		(0x1c)
+#define CR_PROTOCOL_WRITE_REG		(0x20)
+
+#define PHY_1P8_VOL_MIN			1800000 /* uV */
+#define PHY_1P8_VOL_MAX			1800000 /* uV */
+#define PHY_1P8_HPM_LOAD		23000	/* uA */
+
+/* TODO: these are suspicious */
+#define USB_VDDCX_NO			1	/* uV */
+#define USB_VDDCX_MIN			5	/* uV */
+#define USB_VDDCX_MAX			7	/* uV */
+
+struct msm_dwc3_ss_phy {
+	struct usb_phy		phy;
+	void __iomem		*base;
+	struct device		*dev;
+
+	struct regulator	*v1p8;
+	struct regulator	*vddcx;
+
+	struct clk		*xo_clk;
+	struct clk		*ref_clk;
+};
+
+#define	phy_to_dwc3_phy(x)	container_of((x), struct msm_dwc3_ss_phy, phy)
+
+
+/**
+ * Write register
+ *
+ * @base - MSM DWC3 PHY base virtual address.
+ * @offset - register offset.
+ * @val - value to write.
+ */
+static inline void msm_dwc3_ss_write(void __iomem *base, u32 offset, u32 val)
+{
+	iowrite32(val, base + offset);
+}
+
+/**
+ * Write register and read back masked value to confirm it is written
+ *
+ * @base - MSM DWC3 PHY base virtual address.
+ * @offset - register offset.
+ * @mask - register bitmask specifying what should be updated
+ * @val - value to write.
+ */
+static inline void msm_dwc3_ss_write_readback(void __iomem *base, u32 offset,
+					    const u32 mask, u32 val)
+{
+	u32 write_val, tmp = ioread32(base + offset);
+
+	tmp &= ~mask;		/* retain other bits */
+	write_val = tmp | val;
+
+	iowrite32(write_val, base + offset);
+
+	/* Read back to see if val was written */
+	tmp = ioread32(base + offset);
+	tmp &= mask;		/* clear other bits */
+
+	if (tmp != val)
+		pr_err("write: %x to QSCRATCH: %x FAILED\n", val, offset);
+}
+
+/**
+ * Write SSPHY register
+ *
+ * @base - MSM DWC3 PHY base virtual address.
+ * @addr - SSPHY address to write.
+ * @val - value to write.
+ */
+static void msm_dwc3_ss_write_phycreg(void __iomem *base, u32 addr, u32 val)
+{
+	iowrite32(addr, base + CR_PROTOCOL_DATA_IN_REG);
+	iowrite32(0x1, base + CR_PROTOCOL_CAP_ADDR_REG);
+	while (ioread32(base + CR_PROTOCOL_CAP_ADDR_REG))
+		cpu_relax();
+
+	iowrite32(val, base + CR_PROTOCOL_DATA_IN_REG);
+	iowrite32(0x1, base + CR_PROTOCOL_CAP_DATA_REG);
+	while (ioread32(base + CR_PROTOCOL_CAP_DATA_REG))
+		cpu_relax();
+
+	iowrite32(0x1, base + CR_PROTOCOL_WRITE_REG);
+	while (ioread32(base + CR_PROTOCOL_WRITE_REG))
+		cpu_relax();
+}
+
+/**
+ * Read SSPHY register.
+ *
+ * @base - MSM DWC3 PHY base virtual address.
+ * @addr - SSPHY address to read.
+ */
+static u32 msm_dwc3_ss_read_phycreg(void __iomem *base, u32 addr)
+{
+	bool first_read = true;
+
+	iowrite32(addr, base + CR_PROTOCOL_DATA_IN_REG);
+	iowrite32(0x1, base + CR_PROTOCOL_CAP_ADDR_REG);
+	while (ioread32(base + CR_PROTOCOL_CAP_ADDR_REG))
+		cpu_relax();
+
+	/*
+	 * Due to hardware bug, first read of SSPHY register might be
+	 * incorrect. Hence as workaround, SW should perform SSPHY register
+	 * read twice, but use only second read and ignore first read.
+	 */
+retry:
+	iowrite32(0x1, base + CR_PROTOCOL_READ_REG);
+	while (ioread32(base + CR_PROTOCOL_READ_REG))
+		cpu_relax();
+
+	if (first_read) {
+		ioread32(base + CR_PROTOCOL_DATA_OUT_REG);
+		first_read = false;
+		goto retry;
+	}
+
+	return ioread32(base + CR_PROTOCOL_DATA_OUT_REG);
+}
+
+static void msm_dwc3_ss_phy_shutdown(struct usb_phy *x)
+{
+	struct msm_dwc3_ss_phy *phy = phy_to_dwc3_phy(x);
+	int ret;
+
+	/* Sequence to put SSPHY in low power state:
+	 * 1. Clear REF_PHY_EN in PHY_CTRL_REG
+	 * 2. Clear REF_USE_PAD in PHY_CTRL_REG
+	 * 3. Set TEST_POWERED_DOWN in PHY_CTRL_REG to enable PHY retention
+	 * 4. Disable SSPHY ref clk
+	 */
+	msm_dwc3_ss_write_readback(phy->base, PHY_CTRL_REG, (1 << 8), 0x0);
+	msm_dwc3_ss_write_readback(phy->base, PHY_CTRL_REG, (1 << 28), 0x0);
+	msm_dwc3_ss_write_readback(phy->base, PHY_CTRL_REG,
+				    (1 << 26), (1 << 26));
+
+	usleep_range(1000, 1200);
+	clk_disable_unprepare(phy->ref_clk);
+
+	ret = regulator_set_voltage(phy->vddcx, USB_VDDCX_NO, USB_VDDCX_MAX);
+	if (ret)
+		dev_err(phy->dev, "cannot set voltage for vddcx\n");
+
+	regulator_disable(phy->vddcx);
+
+	ret = regulator_set_voltage(phy->v1p8, 0, PHY_1P8_VOL_MAX);
+	if (ret)
+		dev_err(phy->dev, "cannot set v1p8\n");
+
+	regulator_disable(phy->v1p8);
+}
+
+static int msm_dwc3_ss_phy_init(struct usb_phy *x)
+{
+	struct msm_dwc3_ss_phy *phy = phy_to_dwc3_phy(x);
+	u32 data = 0;
+	int ret;
+
+	ret = regulator_set_voltage(phy->vddcx, USB_VDDCX_MIN, USB_VDDCX_MAX);
+	if (ret) {
+		dev_err(phy->dev, "cannot set voltage for vddcx\n");
+		return ret;
+	}
+
+	ret = regulator_enable(phy->vddcx);
+	if (ret) {
+		dev_err(phy->dev, "cannot enable vddcx\n");
+		return ret;
+	}
+
+	ret = regulator_set_voltage(phy->v1p8, PHY_1P8_VOL_MIN,
+				    PHY_1P8_VOL_MAX);
+	if (ret) {
+		regulator_disable(phy->vddcx);
+		dev_err(phy->dev, "cannot set v1p8\n");
+		return ret;
+	}
+
+	ret = regulator_enable(phy->v1p8);
+	if (ret) {
+		regulator_disable(phy->vddcx);
+		dev_err(phy->dev, "cannot enable v1p8\n");
+		return ret;
+	}
+
+	clk_prepare_enable(phy->ref_clk);
+	usleep_range(1000, 1200);
+
+	/* SSPHY Initialization: Use ref_clk from pads and set its parameters */
+	msm_dwc3_ss_write(phy->base, PHY_CTRL_REG, 0x10210002);
+	msleep(30);
+	/* Assert SSPHY reset */
+	msm_dwc3_ss_write(phy->base, PHY_CTRL_REG, 0x10210082);
+	usleep_range(2000, 2200);
+	/* De-assert SSPHY reset - power and ref_clock must be ON */
+	msm_dwc3_ss_write(phy->base, PHY_CTRL_REG, 0x10210002);
+	usleep_range(2000, 2200);
+	/* Ref clock must be stable now, enable ref clock for HS mode */
+	msm_dwc3_ss_write(phy->base, PHY_CTRL_REG, 0x10210102);
+	usleep_range(2000, 2200);
+
+	/*
+	 * WORKAROUND: There is SSPHY suspend bug due to which USB enumerates
+	 * in HS mode instead of SS mode. Workaround it by asserting
+	 * LANE0.TX_ALT_BLOCK.EN_ALT_BUS to enable TX to use alt bus mode
+	 */
+	data = msm_dwc3_ss_read_phycreg(phy->base, 0x102d);
+	data |= (1 << 7);
+	msm_dwc3_ss_write_phycreg(phy->base, 0x102D, data);
+
+	data = msm_dwc3_ss_read_phycreg(phy->base, 0x1010);
+	data &= ~0xff0;
+	data |= 0x20;
+	msm_dwc3_ss_write_phycreg(phy->base, 0x1010, data);
+
+	/*
+	 * Fix RX Equalization setting as follows
+	 * LANE0.RX_OVRD_IN_HI. RX_EQ_EN set to 0
+	 * LANE0.RX_OVRD_IN_HI.RX_EQ_EN_OVRD set to 1
+	 * LANE0.RX_OVRD_IN_HI.RX_EQ set to 3
+	 * LANE0.RX_OVRD_IN_HI.RX_EQ_OVRD set to 1
+	 */
+	data = msm_dwc3_ss_read_phycreg(phy->base, 0x1006);
+	data &= ~(1 << 6);
+	data |= (1 << 7);
+	data &= ~(0x7 << 8);
+	data |= (0x3 << 8);
+	data |= (0x1 << 11);
+	msm_dwc3_ss_write_phycreg(phy->base, 0x1006, data);
+
+	/*
+	 * Set EQ and TX launch amplitudes as follows
+	 * LANE0.TX_OVRD_DRV_LO.PREEMPH set to 22
+	 * LANE0.TX_OVRD_DRV_LO.AMPLITUDE set to 127
+	 * LANE0.TX_OVRD_DRV_LO.EN set to 1.
+	 */
+	data = msm_dwc3_ss_read_phycreg(phy->base, 0x1002);
+	data &= ~0x3f80;
+	data |= (0x16 << 7);
+	data &= ~0x7f;
+	data |= (0x7f | (1 << 14));
+	msm_dwc3_ss_write_phycreg(phy->base, 0x1002, data);
+
+	/*
+	 * Set the QSCRATCH PHY_PARAM_CTRL1 parameters as follows
+	 * TX_FULL_SWING [26:20] amplitude to 127
+	 * TX_DEEMPH_3_5DB [13:8] to 22
+	 * LOS_BIAS [2:0] to 0x5
+	 */
+	msm_dwc3_ss_write_readback(phy->base, PHY_PARAM_CTRL_1,
+				   0x07f03f07, 0x07f01605);
+	return 0;
+}
+
+static int msm_dwc3_ss_probe(struct platform_device *pdev)
+{
+	struct msm_dwc3_ss_phy	*phy;
+	struct resource		*res;
+	void __iomem		*base;
+
+	phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
+	if (!phy)
+		return -ENOMEM;
+
+	platform_set_drvdata(pdev, phy);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(base))
+		return PTR_ERR(base);
+
+	phy->vddcx = devm_regulator_get(phy->dev, "vddcx");
+	if (IS_ERR(phy->vddcx)) {
+		dev_dbg(&pdev->dev, "cannot get vddcx\n");
+		return  PTR_ERR(phy->vddcx);
+	}
+
+	phy->v1p8 = devm_regulator_get(phy->dev, "v1p8");
+	if (IS_ERR(phy->v1p8)) {
+		dev_dbg(&pdev->dev, "cannot get v1p8\n");
+		return  PTR_ERR(phy->v1p8);
+	}
+
+	phy->xo_clk = devm_clk_get(&pdev->dev, "xo");
+	if (IS_ERR(phy->xo_clk)) {
+		dev_dbg(&pdev->dev, "cannot get TCXO buffer handle\n");
+		return PTR_ERR(phy->xo_clk);
+	}
+
+	phy->ref_clk = devm_clk_get(&pdev->dev, "ref");
+	if (IS_ERR(phy->ref_clk)) {
+		dev_dbg(&pdev->dev, "cannot get ref clock handle\n");
+		return PTR_ERR(phy->ref_clk);
+	}
+
+	clk_prepare_enable(phy->xo_clk);
+
+	phy->dev		= &pdev->dev;
+	phy->base		= base;
+	phy->phy.dev		= phy->dev;
+	phy->phy.label		= "msm-dwc3-ssphy";
+	phy->phy.init		= msm_dwc3_ss_phy_init;
+	phy->phy.shutdown       = msm_dwc3_ss_phy_shutdown;
+	phy->phy.type		= USB_PHY_TYPE_USB3;
+
+	usb_add_phy_dev(&phy->phy);
+
+	return 0;
+}
+
+static int msm_dwc3_ss_remove(struct platform_device *pdev)
+{
+	struct msm_dwc3_ss_phy *phy = platform_get_drvdata(pdev);
+
+	clk_disable_unprepare(phy->xo_clk);
+	usb_remove_phy(&phy->phy);
+	return 0;
+}
+
+static const struct of_device_id msm_dwc3_ss_id_table[] = {
+	{ .compatible = "qcom,dwc3-ssphy" },
+	{ /* Sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, msm_dwc3_ss_id_table);
+
+static struct platform_driver msm_dwc3_ss_driver = {
+	.probe		= msm_dwc3_ss_probe,
+	.remove		= msm_dwc3_ss_remove,
+	.driver		= {
+		.name	= "msm-dwc3-ssphy",
+		.owner	= THIS_MODULE,
+		.of_match_table = msm_dwc3_ss_id_table,
+	},
+};
+
+module_platform_driver(msm_dwc3_ss_driver);
+
+MODULE_ALIAS("platform:msm_dwc3_ssphy");
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("DesignWare USB3 MSM SS-PHY driver");