On 17 September 2015 at 17:20, Shawn Lin <shawn.lin@xxxxxxxxxxxxxx> wrote: > On 2015/9/17 19:44, Ulf Hansson wrote: >> >> On 14 September 2015 at 08:29, Shawn Lin <shawn.lin@xxxxxxxxxxxxxx> wrote: >>> >>> 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 -- 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
