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 [off-list ref] wrote:

quoted

Hi,


On Thursday 05 December 2013 01:44 PM, Vivek Gautam wrote:

quoted

Hi Kishon,


On Wed, Dec 4, 2013 at 7:58 PM, Kishon Vijay Abraham I [off-list ref]
wrote:

quoted

Hi Vivek,

On Wednesday 20 November 2013 09:14 PM, Kishon Vijay Abraham I wrote:

quoted

Hi,

On Wednesday 20 November 2013 03:02 PM, Vivek Gautam wrote:

quoted

On Wed, Nov 20, 2013 at 2:34 PM, Kishon Vijay Abraham I [off-list ref]
wrote:

quoted

On Wednesday 20 November 2013 02:27 PM, Vivek Gautam wrote:

quoted

Hi Kishon,


On Mon, Nov 11, 2013 at 4:41 PM, Kishon Vijay Abraham I
[off-list ref] wrote:

quoted

Hi,

sorry for the delayed response.

quoted

On Wednesday 06 November 2013 05:37 AM, Jingoo Han wrote:

quoted

On Wednesday, November 06, 2013 2:58 AM, Vivek Gautam wrote:

quoted

On Tue, Nov 5, 2013 at 5:33 PM, Jingoo Han [off-list ref]
wrote:

[.....]

quoted

quoted

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

quoted

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