On 20 January 2017 at 17:05, Chris Brandt <Chris.Brandt@xxxxxxxxxxx> wrote: > Hello Ulf, > > Friday, January 20, 2017, Ulf Hansson wrote: >> > +- clocks: Most controllers only have 1 clock source per channel. >> However, some >> > + have a second clock dedicated to card detection. If 2 clocks >> are >> > + specified, you must name them as "core" and "cd". If the >> controller >> > + only has 1 clock, naming is not required. >> >> Could you please elaborate a bit on the card detection clock? >> >> I guess that there is some kind of internal card detection logic (native >> card detect) in the SDHI IP, which requires a separate clock for it to >> work? Perhaps you can state that somehow? > > > 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. Most SoC vendors are therefore using a GPIO card detect instead, although I assume you already knew that. :-) [...] 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
