[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YRtvl2FWKqAw4b3l@piout.net>
Date: Tue, 17 Aug 2021 10:13:11 +0200
From: Alexandre Belloni <alexandre.belloni@...tlin.com>
To: Maxime Ripard <maxime@...no.tech>
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
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?
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Powered by blists - more mailing lists