devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC PATCH RESEND 0/2] clk: add clk accuracy support
@ 2013-10-13 17:17 Boris BREZILLON
  2013-10-13 17:17 ` [RFC PATCH RESEND 1/2] clk: add clk accuracy retrieval support Boris BREZILLON
  2013-10-13 17:17 ` [RFC PATCH RESEND 2/2] clk: add accuracy support for fixed clock Boris BREZILLON
  0 siblings, 2 replies; 10+ messages in thread
From: Boris BREZILLON @ 2013-10-13 17:17 UTC (permalink / raw)
  To: Rob Landley, Rob Herring, Pawel Moll, Mark Rutland,
	Stephen Warren, Ian Campbell, Mike Turquette, Russell King
  Cc: Boris BREZILLON, linux-doc, linux-kernel, devicetree,
	linux-arm-kernel

Hello,

Sorry for the noise, but I didn't get any feedback on this patch series.

This patch series is a proposal to add clock accuracy retrieval support to the
common clk framework.

The support of accuracy retrieval may benefit to the at91 platform (I explain
why in the following paragraphs).

I don't know if other platforms may benefit from this accuracy support. This
series is here to get feedbacks from other developpers/maintainers, and see if
this can be integrated in the clk framework.

Here is why at91 platform may need the clk accuracy informations:

AT91 SoCs provide a slow clock (32 KHz clock) which can be used as a clock
source for some peripherals (USART, TC blocks, ...).

This slow clock can be generated from 2 sources:
- a 32KHz internal RC with a poor accuracy (50000 ppm)
- a 32KHz external crystal oscillator

Most of the supported at91 boards (if not all) use the external 32KHz crystal
source except for the kizbox (the board I'm working with :)).
It probably comes from a bad hardware design (hardware team should have
connected a crystal oscillator to the SoC instead of relying on the unaccurate
internal RC).
Anyway, I can't change the hardware as it is already widely deployed.

What I'm proposing is to give clock users the ability to retrieve clocks
accuracies in order to choose the most accurate source (or at least discard
clocks with poor accuracy).

Could you tell me if this approach is right, and if other platforms/boards have
similar issues and would be interrested by this series ?

Best Regards,

Boris

Boris BREZILLON (2):
  clk: add clk accuracy retrieval support
  clk: add accuracy support for fixed clock

 Documentation/clk.txt                              |    4 +
 .../devicetree/bindings/clock/fixed-clock.txt      |    3 +
 drivers/clk/Kconfig                                |    4 +
 drivers/clk/clk-fixed-rate.c                       |   43 +++++++--
 drivers/clk/clk.c                                  |   92 +++++++++++++++++++-
 include/linux/clk-private.h                        |    1 +
 include/linux/clk-provider.h                       |   14 +++
 include/linux/clk.h                                |   17 ++++
 8 files changed, 168 insertions(+), 10 deletions(-)

-- 
1.7.9.5

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2013-11-18 13:20 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-10-13 17:17 [RFC PATCH RESEND 0/2] clk: add clk accuracy support Boris BREZILLON
2013-10-13 17:17 ` [RFC PATCH RESEND 1/2] clk: add clk accuracy retrieval support Boris BREZILLON
2013-11-08  0:51   ` Mike Turquette
2013-11-08  8:54     ` boris brezillon
2013-11-16  0:50       ` Mike Turquette
2013-11-17 15:33         ` boris brezillon
2013-11-17 15:42           ` boris brezillon
2013-11-16  1:59   ` Mike Turquette
2013-11-18 13:20     ` boris brezillon
2013-10-13 17:17 ` [RFC PATCH RESEND 2/2] clk: add accuracy support for fixed clock Boris BREZILLON

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).