devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mike Turquette <mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
To: Maxime Coquelin <maxime.coquelin-qxv4g6HH51o@public.gmane.org>,
	Sylwester Nawrocki
	<s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: mark.rutland-5wv7dgnIgG8@public.gmane.org,
	gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org,
	t.figa-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org,
	sw0312.kim-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	kyungmin.park-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
	grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org,
	m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org,
	t-kristo-l0cyMroinI0@public.gmane.org
Subject: Re: [RFC PATCH v2 0/2] clk: Support for DT assigned clock parents and rates
Date: Mon, 24 Mar 2014 14:57:29 -0700	[thread overview]
Message-ID: <20140324215729.32624.19272@quantum> (raw)
In-Reply-To: <532C4816.2080102-qxv4g6HH51o@public.gmane.org>

Quoting Maxime Coquelin (2014-03-21 07:09:26)
> Hi Mike,
> 
> On 03/21/2014 02:45 AM, Mike Turquette wrote:
> > Quoting Sylwester Nawrocki (2014-03-20 05:42:33)
> >> Hi Maxime,
> >>
> >> On 06/03/14 14:45, Maxime Coquelin wrote:
> >>> Hi Sylwester,
> >>>
> >>>        I like the principle of your implementation, but I have two questions:
> >>>        1 - How can we manage PM with this solution, as the parent/rate will be
> >>> set only once at probe time?
> >>>        2 - How to set the parent of a parent clock (which can be shared with
> >>> other devices)? Same question about the parent rates.
> >>
> >> Thanks for your feedback and apologies for late reply.
> >>
> >> IIUC your first concern is about a situation when clocks need to be
> >> reconfigured upon each resume from system sleep or runtime PM resume ?
> >> As I mentioned in v1 of the RFC I was considering having individual
> >> drivers calling explicitly the clocks set up routine. Presumably this
> >> would allow to resolve the power management related issue.
> >> One example I'm aware the approach as in this RFC wouldn't work is
> >> when a device in a SoC belongs to a power domain, which needs to be
> >> first switched on before we can start setting up and the clocks'
> >> configuration get lost after the power domain switch off.
> >
> > I like Sylwester's approach of handling this one-time setup in the
> > driver core.
> >
> > Any kind of fine grained power management should not be hidden by DT,
> > and by definition that logic belongs in the device driver. It can still
> > be nicely abstracted away by runtime pm[1].
> >
> > Regards,
> > Mike
> >
> > [1] Message-ID: <20140320114238.GQ7528-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
> How can I access this reference?

I was trying to provide a reference to this thread which is tangentially
related to this topic:

http://www.spinics.net/lists/arm-kernel/msg317016.html

But it hadn't hit any of the mail archives at the time of my writing so
I just copied Russell's Message-ID from his email. If you have a copy of
that email then you can search on Message-ID's for that and you will
find it. :-)

Regards,
Mike

> 
> Thanks,
> Maxime
> 
> >
> >>
> >> OTOH I suspect devices for which one-time clocks setup is sufficient
> >> will be quite common. And for these there would need to be a single
> >> call to the setup routine in probe() I guess, since it wouldn't be
> >> possible to figure out just from the DT data when the actual call
> >> should be made.
> >>
> >> For a global clocks configuration, I thought about specifying that
> >> in the clocks controller node, and then to have the setup routine
> >> called e.g. from of_clk_init(). I think that could work well enough,
> >> together with the patch [1], adding clock dependencies handling.
> >> But then the clock frequency set up function would need to be
> >> modified to respect the clock parent relationships, similarly as
> >> in patch series [2]. A just noticed [2] recently, after posting
> >> this RFC (adding Tero at Cc).
> >>
> >> --
> >> Regards,
> >> Sylwester
> >>
> >> [1] http://www.spinics.net/lists/arm-kernel/msg310507.html
> >> [2] http://www.spinics.net/lists/linux-omap/msg103069.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2014-03-24 21:57 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-03 18:15 [RFC PATCH v2 0/2] clk: Support for DT assigned clock parents and rates Sylwester Nawrocki
2014-03-03 18:22 ` [RFC PATCH v2 1/2] clk: Add function parsing arbitrary clock list DT property Sylwester Nawrocki
     [not found] ` <1393870533-20845-1-git-send-email-s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2014-03-03 18:22   ` [RFC PATCH v2 2/2] clk: Add handling of clk parent and rate assigned from DT Sylwester Nawrocki
     [not found]     ` <1393870975-21020-1-git-send-email-s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2014-03-25 11:19       ` Sylwester Nawrocki
     [not found]         ` <5331664E.2050008-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2014-03-25 22:54           ` Mike Turquette
2014-03-31 11:39             ` Sylwester Nawrocki
2014-03-06 13:45 ` [RFC PATCH v2 0/2] clk: Support for DT assigned clock parents and rates Maxime Coquelin
     [not found]   ` <53187C13.3040202-qxv4g6HH51o@public.gmane.org>
2014-03-20 12:42     ` Sylwester Nawrocki
     [not found]       ` <532AE239.9000800-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2014-03-21  1:45         ` Mike Turquette
2014-03-21 14:09           ` Maxime Coquelin
     [not found]             ` <532C4816.2080102-qxv4g6HH51o@public.gmane.org>
2014-03-24 21:57               ` Mike Turquette [this message]
2014-03-24 22:07                 ` Eric Boxer
2014-03-21 11:20       ` Maxime Coquelin
     [not found]         ` <532C206E.1020907-qxv4g6HH51o@public.gmane.org>
2014-03-21 14:56           ` Sylwester Nawrocki

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=20140324215729.32624.19272@quantum \
    --to=mturquette-qsej5fyqhm4dnm+yrofe0a@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
    --cc=grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \
    --cc=kyungmin.park-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org \
    --cc=m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
    --cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
    --cc=maxime.coquelin-qxv4g6HH51o@public.gmane.org \
    --cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
    --cc=sw0312.kim-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
    --cc=t-kristo-l0cyMroinI0@public.gmane.org \
    --cc=t.figa-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.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).