于 2021年7月29日 GMT+08:00 下午6:32:28, Maxime Ripard [off-list ref] 写到:

On Thu, Jul 29, 2021 at 04:04:10PM +0800, Icenowy Zheng wrote:

quoted

在 2021-06-16星期三的 11:14 +0200，Maxime Ripard写道：

quoted

Hi,

On Tue, Jun 15, 2021 at 12:06:23PM +0100, Andre Przywara wrote:

quoted

Some newer Allwinner RTCs (for instance the one in the H616 SoC)
lack
a pin for an external 32768 Hz oscillator. As a consequence, this
LOSC
can't be selected as the RTC clock source, and we must rely on the
internal RC oscillator.
To allow additions of clocks to the RTC node, add a feature bit to
ignore
any provided clocks for now (the current code would think this is
the
external LOSC). Later DTs and code can then for instance add the
PLL
based clock input, and older kernel won't get confused.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>

Honestly, I don't really know if it's worth it at this point.

If we sums this up:

 - The RTC has 2 features that we use, mostly centered around 2
   registers set plus a global one

 - Those 2 features are programmed in a completely different way

 - Even the common part is different, given the discussion around the
   clocks that we have.

What is there to share in that driver aside from the probe, and maybe
the interrupt handling? Instead of complicating this further with
more
special case that you were (rightfully) complaining about, shouldn't
we
just acknowledge the fact that it's a completely separate design and
should be treated as such, with a completely separate driver?

I think our problem is just that we're having a single driver for both
functionalities (clock manager and RTC).

Personally I don't think we should have seperated driver for clock
managers, although I am fine with seperated RTC driver for linear days.

Why do you think it's a bad idea to have the RTC and clocks in the same
driver?

Well you really misread, I'm just thinking we shouldn't have a new driver
from scratch. As we're going to have a single sun6i-rtc, please allow H616
and R329 to enter it.

Maxime

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel