Hi Tomasz,


On Fri, Feb 14, 2014 at 9:17 PM, Tomasz Figa [off-list ref] wrote:

mistakenly didn't do "Reply All", so sending it again.

Hi Vivek,


On 14.02.2014 14:53, Vivek Gautam wrote:

quoted

quoted

quoted

Changes from v2:
1) Added support for multiple PHYs (UTMI+ and PIPE3) and
     related changes in the driver structuring.

I'm a bit skeptical about this separation. Can the PHY operate with just
the
UTMI+ or PIPE3 part enabled alone without the other? Can any PHY consumer
operate this way?

Yes :-)
As also pointed by Kishon the PHY consumer (which is DWC3 in case of
Exynos5 SoC series)
should theoretically be able use either UTMI+ phy for High speed
operations or both (UTMI+ and PIPE3)
for Super Speed operations.

OK, that's fine then. This is the explanation I needed, thanks.

quoted

quoted

I believe the right thing to do here is to do all the initialization in
.power_on() and let the driver simply call phy_power_on() when it needs
the
PHY and phy_power_off() otherwise.

If this is what we should be doing then what will be the purpose of
two separate APIs :
phy_power_on() and phy_init().
Am i missing while understanding the things.

I don't understand this separation as well. Operations that should be done
together shouldn't be separated. Is there any case when you can call one of
phy_power_on() and phy_init() without calling another one right before/after
it?

Most of the PHY consumers need to call phy_power_on() as well as phy_init()
to get PHY working (if the PHY provider gives callback to both).
I think the idea would have been to separate out the initialization
related and power related
jobs (which may include setting up the PMUs and may be regulators ?)
But, i think it's true, if the PHY provider callback for both
phy_power_on() and phy_init()
then the consumer __has__ to call both to get things working.



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India