On 17 September 2015 at 17:20, Shawn Lin [off-list ref] wrote:

On 2015/9/17 19:44, Ulf Hansson wrote:

quoted

On 14 September 2015 at 08:29, Shawn Lin [off-list ref] wrote:

quoted

This patch adds Generic PHY access for sdhci-of-arasan. Driver
can get PHY handler from dt-binding, and power-on/init the PHY.
Also we add pm ops for PHY here if CONFIG_PM_SLEEP is enabled.
Currently, it's just mandatory for arasan,sdhci-5.1.

I am trying to understand how a PHY can be used together with a
MMC/SD/SDIO controller. Normally the card connector doesn't hold any
intelligence, so I wonder if PHY is correctly used here.

Could you try to explain, HW-wise, what role the PHY has for you?

Thanks for comment, Ulf.

It's the first time we introduce phy into mmc subsystem,also it's my first
time to use phy for emmc in real Soc.
so definitely we need to discuss it deliberately.

From my view, phy is an active-power, differential sampling and more
well-designed analog *IO component* for ultra-highspeed device to guarantee
its signal integrity, like USB, UFS, DDR-RAM,MIPI and so on.

(1)Firstly it contains DLL to generate delayline and phase for sampling data
from mmc devices. When sdhci controller executes tuning and sends out tuning
sequence, and PHY can auto change its delayline and phase
in order to test if this "sample timing" is okay. If not, CRC err is
generate back to the controller. Then after SDHCI tune timing for 40 times,
also PHY have scanned all the "sample windows" by trying different delayline
and phase combination, and finally auto-select the best sample timing for
the "sample windows". And sdhci HOST CONTROL
2 Register[6:7] is controlled by PHY in my case.

(2)Then phy can programming source/sink impedance to avoid signal reflex.
Given that JEDEC has come to HS533(highspeed 533MHz), this function is
imperative to be implemented just like the role of ODT for DDR-RAM's PHY.

(3)Phy is integrated with diff pull-up/down resistance value and open-drain
type for HW design.

(4)Phy can also have some enable-bit to decide whether all mmc
signal(clk/data/cmd/strobe) can output to the devices or not.

Thanks for elaborating. It seems like using phy is justified in your case.

For the card, even for host controller itself, phy can just be regarded as a
need-to-do-something-before-used GPIO.
So, before we start initializing card, we need to power up PHY, enable clk
for it and configure all the stuffs. Also we need to power down it for
power-saving when into suspend. That's all we need to do and that's all the
generic phy framework had provided by four interface:
phy_init/phy_exit/phy_power_on/phy_power_off.


Sincerely welcome any comments here to make things better. :)

I will get back to your patch and review it in detail as soon as can.

Kind regards
Uffe