HI Kishon On Tue, Jan 7, 2014 at 3:19 PM, Kishon Vijay Abraham I <kishon@xxxxxx> wrote: > Hi, > > On Monday 30 December 2013 03:13 PM, Vivek Gautam wrote: >> Hi Kishon, >> >> >> On Tue, Dec 24, 2013 at 11:15 PM, Kishon Vijay Abraham I <kishon@xxxxxx> wrote: >>> Hi, >>> >>> >>> On Thursday 05 December 2013 01:44 PM, Vivek Gautam wrote: >>>> >>>> Hi Kishon, >>>> >>>> >>>> On Wed, Dec 4, 2013 at 7:58 PM, Kishon Vijay Abraham I <kishon@xxxxxx> >>>> wrote: >>>>> >>>>> Hi Vivek, >>>>> >>>>> On Wednesday 20 November 2013 09:14 PM, Kishon Vijay Abraham I wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> On Wednesday 20 November 2013 03:02 PM, Vivek Gautam wrote: >>>>>>> >>>>>>> On Wed, Nov 20, 2013 at 2:34 PM, Kishon Vijay Abraham I <kishon@xxxxxx> >>>>>>> wrote: >>>>>>>> >>>>>>>> On Wednesday 20 November 2013 02:27 PM, Vivek Gautam wrote: >>>>>>>>> >>>>>>>>> Hi Kishon, >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Nov 11, 2013 at 4:41 PM, Kishon Vijay Abraham I >>>>>>>>> <kishon@xxxxxx> wrote: >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> sorry for the delayed response. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wednesday 06 November 2013 05:37 AM, Jingoo Han wrote: >>>>>>>>>>> >>>>>>>>>>> On Wednesday, November 06, 2013 2:58 AM, Vivek Gautam wrote: >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Nov 5, 2013 at 5:33 PM, Jingoo Han <jg1.han@xxxxxxxxxxx> >>>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> [.....] >>>>>>>>>>> >>>>>>>>>>>>> USB3.0 PHY consists of two blocks such as 3.0 block and 2.0 >>>>>>>>>>>>> block. >>>>>>>>>>>>> This USB3.0 PHY can support UTMI+ and PIPE3 interface for 3.0 >>>>>>>>>>>>> block >>>>>>>>>>>>> and 2.0 block, respectively. >>>>>>>>>>>>> >>>>>>>>>>>>> Conclusion: >>>>>>>>>>>>> >>>>>>>>>>>>> 1) USB2.0 PHY: USB2.0 HOST, USB2.0 Device >>>>>>>>>>>>> Base address: 0x1213 0000 >>>>>>>>>>>>> >>>>>>>>>>>>> 2) USB3.0 PHY: USB3.0 DRD (3.0 HOST & 3.0 Device) >>>>>>>>>>>>> Base address: 0x1210 0000 >>>>>>>>>>>>> 2.0 block(UTMI+) & 3.0 block(PIPE3) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> And this is of course the PHY used by DWC3 controller, which works >>>>>>>>>>>> at >>>>>>>>>>>> both High speed as well as Super Speed. >>>>>>>>>>>> Right ? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Right. >>>>>>>>>>> >>>>>>>>>>> While 3.0 block(PIPE3) can be used for Super Speed, 2.0 >>>>>>>>>>> block(UTMI+) >>>>>>>>>>> can be used for High speed. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> It should then come under *single IP muliple PHY* category similar >>>>>>>>>> to what >>>>>>>>>> Sylwester has done. >>>>>>>>> >>>>>>>>> >>>>>>>>> Do you mean that i should be including PHY IDs for UTMI+ phy and >>>>>>>>> PIPE3 >>>>>>>>> phy present in this PHY block ? >>>>>>>>> AFAICS the two phys (UTMI+ and PIPE3) do not really have separate >>>>>>>>> registers to program, and that's the reason >>>>>>>>> we program the entire PHY in a shot. >>>>>>>> >>>>>>>> >>>>>>>> you mean you program the same set of bits for UTMI+ and PIPE3? >>>>>>> >>>>>>> >>>>>>> No, looking closely into PHY datasheet as well as Exynos5250 manual, i >>>>>>> can see that UTMI+ and PIPE3 >>>>>>> phys have separate bit settings. So i think we should be able to >>>>>>> segregate the two PHYs (UTMI+ and PIPE3). >>>>>>> Pardon me for my earlier observations. >>>>>> >>>>>> >>>>>> no problem.. >>>>>>> >>>>>>> Let me clarify more with our h/w team also on this and then i will >>>>>>> confirm with this. >>>>> >>>>> >>>>> Did you get more information on this? >>>> >>>> >>>> Yes, i have been in contact with our hardware team. >>>> The functionality of setting up UTMI+ and PIPE3 phys separately, and >>>> thereby using only one functionality of the two >>>> at some point of time (either high speed or super speed) hasn't been >>>> tested so far. >>> >>> >>> Irrespective of whether we are able to test the functionality separately or >>> not, we should model it as multiple PHYs since you have separate bit >>> settings for UTMI+ and PIPE3. >>> >>> (I'll review your next patch version shortly). >> >> Thanks Kishon, i know i am disturbing you in the holiday season. :-) >> But there's one concern, on Exynos5 platforms we have only one bit to >> power control >> the entire PHY (irrespective of the two PHYs present in the USB 3.0 >> PHY controller). >> So anyways we won't be able to save anything on the power front even >> if we program only >> one PHY (UTMI/PIPE3). >> Although there are PHY settings register bits which seem separate for >> the two phys. r >> What do you suggest in that case ? > > The idea is to model the driver as close to the hardware though I understand > there won't be any advantages w.r.t power or performance. maybe in later > versions of the IP we'll have separate bits to control usb3 and usb2. Ok, i will prepare the next patchset for separating out the possible code based on the UTMI+ or PIPE3 phys. Though when experimenting with the PHY settings i can see there's little of such code :-) > > I think for power control we should have both usb3 and usb2 power-on callback > calling a single function that controls the power bit. Right. I will do that. -- Best Regards Vivek Gautam Samsung R&D Institute, Bangalore India -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
