RE: [PATCH v3 2/3] mmc: sh_mobile_sdhi: explain clock bindings

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Uffe,

On Friday, January 20, 2017, Ulf Hansson wrote:
> > The reality is that the chip guys cut up the standard SDHI IP to add a
> > 'cool new feature', but all I want to do is put it back the way it was.
> >
> > NOTE: The design guys like to reuse IP blocks from previous designs
> > that they know worked and didn't have bugs. So, there is a good chance
> > you will see this change in future RZ/A devices (or even other future
> Renesas SoC devices).
> > To remove an unwanted feature adds additional design risk of breaking
> > something else....and given the cost of redoing silicon mask
> > layers...no engineer wants that mistake on their hands.
> 
> So, one should be aware of that runtime PM support in these case is going
> to be suboptimal.
> For example, when using this native card detect, you will need to keep the
> controller runtime PM resumed as the be able to keep the clock on and to
> be able to fetch the irq. Wasting power.


Wolfram already pointed that out in a reply to Geert:

On Tuesday, January 17, 2017, Wolfram Sang wrote:
> > If we handle them as one, won't we miss card detect events due to the
> > card detect clock being disabled while SDHI is idle?
> 
> You mean this?
> 
> 1208         /*
> 1209          * While using internal tmio hardware logic for card
> detection, we need
> 1210          * to ensure it stays powered for it to work.
> 1211          */
> 1212         if (_host->native_hotplug)
> 1213                 pm_runtime_get_noresume(&pdev->dev);


As per your request, I'll go back and add some text to describing that even though
this specific HW has a separate clock for card detect for PM, the existing driver
infrastructure doesn't handle that so both clocks need to be treated as one.


> Most SoC vendors are therefore using a GPIO card detect instead, although
> I assume you already knew that. :-)

My first objective for the RZ/A1 platform is to move things from a local
custom BSP into upstream and get things 'working'. Later I can go back
and tweak things here and there for runtime PM and such.


Thank you,
Chris





[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux