Re: [PATCH] arm64: dts: allwinner: h6: tanix-tx6: Use internal oscillator

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Thu, Jan 16, 2020 at 05:47:12PM +0100, Jernej Škrabec wrote:
> Dne četrtek, 16. januar 2020 ob 09:06:52 CET je Maxime Ripard napisal(a):
> > Hi Jernej,
> >
> > On Mon, Jan 13, 2020 at 07:07:20PM +0100, Jernej Skrabec wrote:
> > > Tanix TX6 doesn't have external 32 kHz oscillator, so switch RTC clock
> > > to internal one.
> > >
> > > Signed-off-by: Jernej Skrabec <jernej.skrabec@xxxxxxxx>
> > > ---
> > >
> > > While this patch gives one possible solution, I mainly want to start
> > > discussion why Allwinner SoC dtsi reference external 32 kHz crystal
> > > although some boards don't have it. My proposal would be to make clock
> > > property optional, based on the fact if external crystal is present or
> > > not. However, I'm not sure if that is possible at this point or not.
> >
> > It's probably a bit of a dumb question but.. are you sure the crystal
> > is missing?
>
> Although I don't have schematic, I'm pretty sure. Without this patch or one at
> [1], RTC gives a lot of errors in dmesg. I think that unpopulated XC2 pads
> near SoC (see [2]) are probably reserved for crystal.
>
> With patch in [1], which enables automatic switching in case of error, I saw
> that on this box RTC always switched to internal RC.
>
> >
> > The H6 datasheet mentions that the 32kHz crystal needs to be there,
> > and it's part of the power sequence, so I'd expect all boards to have
> > it.
>
> Can you be more specific where it is stated that crystal is mandatory?

I was mostly referring to the power sequence mentionned in the H6
Datasheet (not the user manual, the smaller one).

https://linux-sunxi.org/images/5/5c/Allwinner_H6_V200_Datasheet_V1.1.pdf

Page 74

> Note that schematic of some boards, like OrangePi PC2 (H5) or OrangePi Zero
> (H3) don't even have 32K crystal in them.

And we can't use the compatible for these..

> >
> > > Driver also considers missing clock property as deprecated (old DT) [1],
> > > so this might complicate things even further.
> > >
> > > What do you think?
> >
> > I'm pretty sure (but that would need to be checked) that we never got
> > a node without the clocks property on the H6. If that's the case, then
> > we can add a check on the compatible.
>
> Yes, that would be nice solution. I can work something out if you agree that
> this is the way.

So if we want to have something that works for the H3 too, then I
guess we need to revert the patch that switches the 32kHz clock source
to the external one all the time, and do it only if we have a clock
provided.

If we don't, we would run from the internal oscillator (which would
work for both the H3 and H6 boards you have I guess?) and if we do we
will still use the better, more accurate, clock.

That would change a bit the behaviour of the old DTs again and revert
to the old behaviour we had, but we didn't hear anything the first
time we did, so I wouldn't be overly concerned.

Does that make sense?
Maxime

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux