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" <iiva...@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 <iiva...@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-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/