| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAFp+6iGYapTX0tfTLaoiF02n+hNdXN2OEphOCkb3dAYvqA4N5g@mail.gmail.com> Date: Tue, 7 Jan 2014 16:33:04 +0530 From: Vivek Gautam <gautamvivek1987@...il.com> To: Kishon Vijay Abraham I <kishon@...com> Cc: Jingoo Han <jg1.han@...sung.com>, Kamil Debski <k.debski@...sung.com>, Vivek Gautam <gautam.vivek@...sung.com>, Linux USB Mailing List <linux-usb@...r.kernel.org>, "linux-samsung-soc@...r.kernel.org" <linux-samsung-soc@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, linux-doc@...r.kernel.org, Greg KH <gregkh@...uxfoundation.org>, Kukjin Kim <kgene.kim@...sung.com>, Sylwester Nawrocki <s.nawrocki@...sung.com>, Tomasz Figa <t.figa@...sung.com>, Felipe Balbi <balbi@...com>, Julius Werner <jwerner@...omium.org> Subject: Re: [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver HI Kishon On Tue, Jan 7, 2014 at 3:19 PM, Kishon Vijay Abraham I <kishon@...com> 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@...com> 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@...com> >>>> 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@...com> >>>>>>> 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@...com> 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@...sung.com> >>>>>>>>>>>> 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-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists