Re: [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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.

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 devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux