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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 7 Jan 2014 15:19:38 +0530
From:	Kishon Vijay Abraham I <kishon@...com>
To:	Vivek Gautam <gautamvivek1987@...il.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,

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.

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@...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

Powered by Openwall GNU/*/Linux Powered by OpenVZ