[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181127103253.ubbjjy2ji6sxc7xs@flea>
Date: Tue, 27 Nov 2018 11:32:53 +0100
From: Maxime Ripard <maxime.ripard@...tlin.com>
To: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
Cc: Hao Zhang <hao5781286@...il.com>, robh+dt@...nel.org,
mark.rutland@....com, wens@...e.org, mturquette@...libre.com,
sboyd@...nel.org, thierry.reding@...il.com,
linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-pwm@...r.kernel.org, linux-sunxi@...glegroups.com
Subject: Re: [PATCH v3 1/6] Documentation: ARM: sunxi: pwm: add Allwinner
sun8i.
On Tue, Nov 27, 2018 at 09:35:23AM +0100, Uwe Kleine-König wrote:
> Hello,
>
> On Tue, Nov 27, 2018 at 08:52:26AM +0100, Maxime Ripard wrote:
> > On Mon, Nov 26, 2018 at 12:18:59AM +0800, Hao Zhang wrote:
> > > + - clocks: From common clock binding, handle to the parent clock.
> > > + - clock-names: Must contain the clock names described just above.
> >
> > [...]
> >
> > You seem to have used mux-0 and mux-1 for the clock names. I guess we
> > don't have to use a name there, we can simply use the position to find
> > out (as long as it's documented in the binding)
>
> I also wondered if the driver relies on the fact that the second clock
> is the faster running one. Is this sensible?
Not really, I'm not sure we can make those expectations in the DT
binding, especially since clock rate can change at runtime.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists