Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755632AbaAGJuR (ORCPT ); Tue, 7 Jan 2014 04:50:17 -0500 Received: from bear.ext.ti.com ([192.94.94.41]:36535 "EHLO bear.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751405AbaAGJuM (ORCPT ); Tue, 7 Jan 2014 04:50:12 -0500 Message-ID: <52CBCDB2.9080301@ti.com> Date: Tue, 7 Jan 2014 15:19:38 +0530 From: Kishon Vijay Abraham I User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Vivek Gautam CC: Jingoo Han , Kamil Debski , Vivek Gautam , Linux USB Mailing List , "linux-samsung-soc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , , Greg KH , Kukjin Kim , Sylwester Nawrocki , Tomasz Figa , Felipe Balbi , Julius Werner Subject: Re: [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver References: <1383205544-32244-1-git-send-email-gautam.vivek@samsung.com> <1383205544-32244-2-git-send-email-gautam.vivek@samsung.com> <527744B2.4090303@ti.com> <030d01ced946$d6e23490$84a69db0$%debski@samsung.com> <52779D28.9000905@ti.com> <00fe01ceda0a$941957a0$bc4c06e0$%debski@samsung.com> <000001ceda17$f41c2030$dc546090$%han@samsung.com> <000101ceda1f$04ca6f20$0e5f4d60$%han@samsung.com> <000301ceda84$1d648bf0$582da3d0$%han@samsung.com> <5280BB65.5040305@ti.com> <528C7B0E.3080401@ti.com> <528CD8EC.9050403@ti.com> <529F3C1C.2050509@ti.com> <52B9C83E.6070502@ti.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 >>> 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 >>>>>> 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 >>>>>>>> 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 >>>>>>>>>>> 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. I think for power control we should have both usb3 and usb2 power-on callback calling a single function that controls the power bit. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/