From: maxime.ripard@free-electrons.com (Maxime Ripard)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/7] clk: Add a basic factor clock
Date: Sat, 19 Sep 2015 10:19:19 +0200 [thread overview]
Message-ID: <20150919081919.GA4684@lukather> (raw)
In-Reply-To: <20150724065017.GJ2373@lukather>
Hi Jim,
On Fri, Jul 24, 2015 at 08:50:17AM +0200, Maxime Ripard wrote:
> > Jim Quinlan submitted a similar patch. See here:
> >
> > http://www.spinics.net/lists/linux-clk/msg00691.html
>
> It looks very similar indeed.
>
> > I nacked that patch because Stephen and I are trying to figure out how
> > the basic clock types should work going forward. Code reuse is good, but
> > they are not very maintainable.
>
> What are the issues with maintaining them? The only drawback I'm
> seeing with introducing such a driver is that you can't really have a
> clock that is both a divider and a multiplier, but that can be solved
> by splitting it into two sub-clocks.
>
> From a pure maintainance point of view, refusing it would mean that
> each and every platform would have to come up with its own
> implementation. For example, we do have clk-factors.c for sunxi that
> does just that, and implies some cooperation from each clock driver
> that have to provide some code to determine the various components of
> the output formula. This can prove to be very challenging (and bug
> prone) for clocks like the audio one we have where we have 1
> multiplier and 2 dividers that needs some adjusting.
>
> Splitting it into sub-clocks for each of these components would allow
> to have less bugs, while keeping the whole thing very simple, and the
> implementation on the driver side very trivial.
>
> Overall, the clk-factors code we have (client side) is approximately a
> thousand lines of code logic that could be replaced by (less) trivial
> probing code for such a driver.
>
> > Since there are two potential users of this code, I should reconsider.
>
> Like I said, eventually, I'd like to leverage that code a lot more
> than for the single clock alone, and I think it could benefit other
> platforms too (like Jim has proven).
>
> > Can you two come up with a common implementation that works for both of
> > you?
>
> Yes, sure. Jim, how do you want to go with this? Do you want to
> resubmit your patch on top of 4.2-rc something so that I could give it
> a try? Otherwise, I posted such a patch this week
>
> https://lkml.kernel.org/r/1437235304-2208-1-git-send-email-maxime.ripard at free-electrons.com
>
> Can you give it a try and your feedback?
Ping?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150919/3fd0ab8c/attachment.sig>
next prev parent reply other threads:[~2015-09-19 8:19 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-21 20:53 [PATCH v2 0/7] clk: sunxi: Add support for the Audio PLL Maxime Ripard
2015-05-21 20:54 ` [PATCH v2 1/7] clk: Add a basic factor clock Maxime Ripard
2015-05-22 4:35 ` Chen-Yu Tsai
2015-05-23 7:49 ` Maxime Ripard
2015-07-24 0:00 ` Michael Turquette
2015-07-24 6:50 ` Maxime Ripard
2015-07-24 18:26 ` Michael Turquette
2015-07-25 7:39 ` Maxime Ripard
2015-08-11 21:30 ` Michael Turquette
2015-08-19 9:13 ` Maxime Ripard
2015-09-19 8:19 ` Maxime Ripard [this message]
2015-05-21 20:54 ` [PATCH v2 2/7] clk: sunxi: Add a driver for the PLL2 Maxime Ripard
2015-05-21 20:54 ` [PATCH v2 3/7] clk: sunxi: codec clock support Maxime Ripard
2015-05-21 20:54 ` [PATCH v2 4/7] clk: sunxi: mod1 " Maxime Ripard
2015-05-21 20:54 ` [PATCH v2 5/7] ARM: sunxi: Add PLL2 support Maxime Ripard
2015-05-21 20:54 ` [PATCH v2 6/7] ARM: sunxi: Add codec clock support Maxime Ripard
2015-05-21 20:54 ` [PATCH v2 7/7] ARM: sun7i: Add mod1 clock nodes Maxime Ripard
2015-06-04 13:27 ` [PATCH v2 0/7] clk: sunxi: Add support for the Audio PLL Maxime Ripard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150919081919.GA4684@lukather \
--to=maxime.ripard@free-electrons.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).