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

From: Chris Brandt <Chris.Brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
To: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
	Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>,
	Wolfram Sang
	<wsa+renesas-jBu1N2QxHDJrcw3mvpCnnVaTQe2KTcn/@public.gmane.org>,
	Geert Uytterhoeven
	<geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Linux-Renesas
	<linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: RE: [PATCH v3 2/3] mmc: sh_mobile_sdhi: explain clock bindings
Date: Fri, 20 Jan 2017 16:05:45 +0000	[thread overview]
Message-ID: <SG2PR06MB1165B5BF4296DB866F3D418B8A710@SG2PR06MB1165.apcprd06.prod.outlook.com> (raw)
In-Reply-To: <CAPDyKFq9psGMnKUx+SM_QGt6OKoMHgNFop6ANagtLOLwsMTT8w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

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.

> > +Example showing 2 clocks:
> > +       sdhi0: sd@e804e000 {
> > +               compatible = "renesas,sdhi-r7s72100";
> > +               reg = <0xe804e000 0x100>;
> > +               interrupts = <GIC_SPI 270 IRQ_TYPE_LEVEL_HIGH
> > +                             GIC_SPI 271 IRQ_TYPE_LEVEL_HIGH
> > +                             GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>;
> > +
> > +               clocks = <&mstp12_clks R7S72100_CLK_SDHI00>,
> > +                        <&mstp12_clks R7S72100_CLK_SDHI01>;
> > +               clock-names = "core", "cd";
> > +               cap-sd-highspeed;
> > +               cap-sdio-irq;
> > +               status = "disabled";
> 
> The last line seems a bit odd to include in an example.

You're right. I'll take that out.

Thanks,
Chris