Thread (8 messages) 8 messages, 2 authors, 2014-02-19

RE: [PATCH V5 4/8] phy: st-miphy-40lp: Add skeleton driver

From: Mohit KUMAR DCG <hidden>
Date: 2014-02-12 04:52:47
Also in: linux-arm-kernel, lkml

Hello Arnd,
-----Original Message-----
From: Arnd Bergmann [mailto:arnd@arndb.de]
Sent: Tuesday, February 11, 2014 8:09 PM
To: Mohit KUMAR DCG
Cc: Pratyush ANAND; Kishon Vijay Abraham I; spear-devel; linux-arm-
kernel@lists.infradead.org; devicetree@vger.kernel.org; linux-
kernel@vger.kernel.org; Lee Jones
Subject: Re: [PATCH V5 4/8] phy: st-miphy-40lp: Add skeleton driver

On Tuesday 11 February 2014 11:57:46 Mohit KUMAR DCG wrote:
quoted
quoted
Maybe mention that this phy is used inside the spear13xx SoC here
rather than a standalone phy.
- Yes, for spear13xx its used internally. Do you think that it
requires to be mentioned here?
We have few prototype boards that uses this as external phy.
[adding Lee since he mentioned working on a similar part]

I'm a bit confused. Is it actually the same IP block that can be used internally
as part of a SoC and as a standalone chip?

Since some of the settings of the PHY are controlled through the misc
register in case of spear13xx, I assume that part is different on the
standalone version. How do you actually select the mode in that case?

It would certainly be helpful to explain this somewhere, and the binding
might not be the worst place for this.

On a related note, the driver in its current shape looks a bit silly since it
doesn't contain any of the miphy specific code but only the SoC specific parts
(as I suggested you do, so I'm not blaming you :-)) and a multiplexer that
switches between the two possible implementations.
- yes, thats what we were explaining earlier. If it is integrated into some SoC 
Then there are some soc specific configurations. Actual phy reg settings could
also vary for the different SoCs for the best tuning.

However we agreed to your idea as miphy40lp register definitions would remain
same across the SoCs.
What is your plan for the future, do you intend to add the actual miphy code
soon, or is that something you just want to leave as an option for the future
but have no specific plans to do right now? If not, the driver would probably
look nicer if it were split into two separate implementations, one for each
spear13xx SoC and with a separate set of phy_ops but no multiplexer.
Do you want  it to split the code into two different files like phy-miphyspear1310.c
and phy-miphyspear1340.c ?

Regards
Mohit
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help