* at91 slow clock with an external crystal (on Atmel SAM9G25)
@ 2016-05-18 8:04 Mickael GARDET
2016-05-20 9:38 ` Boris Brezillon
0 siblings, 1 reply; 2+ messages in thread
From: Mickael GARDET @ 2016-05-18 8:04 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
I have one question about usage of slow clock with an external crystal
(on Atmel SAM9G25).
All work fine If I set CONFIG_SCLK=y in at91bootstrap but we wouldn't
update at91bootstrap.
If I force usage of external crystal (like the enclosed patch) it work
for me but what's the recommended way to do this ?
My kernel version is 4.1.13.
Best regards.
Mickael GARDET
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-force_external_osc.patch
Type: text/x-patch
Size: 2077 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160518/2a4552b7/attachment.bin>
^ permalink raw reply [flat|nested] 2+ messages in thread
* at91 slow clock with an external crystal (on Atmel SAM9G25)
2016-05-18 8:04 at91 slow clock with an external crystal (on Atmel SAM9G25) Mickael GARDET
@ 2016-05-20 9:38 ` Boris Brezillon
0 siblings, 0 replies; 2+ messages in thread
From: Boris Brezillon @ 2016-05-20 9:38 UTC (permalink / raw)
To: linux-arm-kernel
+ Atmel and clk maintainers.
Hi Mickael,
Please use get_maintainer.pl (or the MAINTAINERS file) to find people
you should send your questions too
On Wed, 18 May 2016 10:04:35 +0200
Mickael GARDET <m.gardet@overkiz.com> wrote:
> Hi,
>
> I have one question about usage of slow clock with an external crystal
> (on Atmel SAM9G25).
>
> All work fine If I set CONFIG_SCLK=y in at91bootstrap but we wouldn't
> update at91bootstrap.
Yes, the 'external crystal'/'internal RC osc' selection is currently
done in at91bootstrap, and Linux just use what has been configured by
the bootstrap.
>
> If I force usage of external crystal (like this [1]) it work
> for me but what's the recommended way to do this ?
I'd rather see something more generic for mainline, but you can keep it
in your own tree ;).
IMHO, the proper solution would be to add a min_accuracy field in
struct clk_rate_request (and a clk_set_min_accuracy() helper), implement
->determine_rate() in clk-slow.c to find the parent matching this
constraint, and patch all users of the slow clk to set this constraint
to something appropriate (100ppm ?).
At least, slow clock users should check if the accuracy provided by the
slow clock match what they expect and complain if it's not the case
(it's already doable thanks to the clk_get_accuracy() function).
Best Regards,
Boris
> [1]http://code.bulix.org/kpzu92-98883
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2016-05-20 9:38 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-05-18 8:04 at91 slow clock with an external crystal (on Atmel SAM9G25) Mickael GARDET
2016-05-20 9:38 ` Boris Brezillon
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox