[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210819075630.upliivqux4dsohzd@gilmour>
Date: Thu, 19 Aug 2021 09:56:30 +0200
From: Maxime Ripard <maxime@...no.tech>
To: Alexandre Belloni <alexandre.belloni@...tlin.com>
Cc: Andre Przywara <andre.przywara@....com>,
Chen-Yu Tsai <wens@...e.org>,
Jernej Skrabec <jernej.skrabec@...il.com>,
Rob Herring <robh@...nel.org>, Icenowy Zheng <icenowy@...c.io>,
Samuel Holland <samuel@...lland.org>,
linux-arm-kernel@...ts.infradead.org, linux-sunxi@...glegroups.com,
linux-sunxi@...ts.linux.dev, linux-kernel@...r.kernel.org,
Ondrej Jirman <megous@...ous.com>, devicetree@...r.kernel.org,
Alessandro Zummo <a.zummo@...ertech.it>,
linux-rtc@...r.kernel.org
Subject: Re: [PATCH v8 02/11] dt-bindings: rtc: sun6i: Add H616 compatible
string
Salut Alex,
On Tue, Aug 17, 2021 at 10:13:11AM +0200, Alexandre Belloni wrote:
> On 17/08/2021 09:38:10+0200, Maxime Ripard wrote:
> > > > It's not entirely clear to me what those clocks are about though. If we
> > > > look at the clock output in the user manual, it looks like there's only
> > > > two clocks that are actually being output: the 32k "fanout" clock and
> > > > the losc. What are the 3 you're talking about?]
> > >
> > > I see three: the raw SYSTEM "CLK32K_LOSC", the RTC input + debounce
> > > clock (/32), and the multiplexed PAD.
> >
> > But the input and debounce clock is only for the RTC itself right? So it
> > should be local to the driver and doesn't need to be made available to
> > the other drivers
> >
>
> Shouldn't they be exposed to be able to use assigned-clock?
I'm not sure we would even need that? If it's an internal clock to the
RTC, then we probably won't ever need to change it from the device tree?
Maxime
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists