devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mike Turquette <mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
To: "Sören Brinkmann"
	<soren.brinkmann-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
Cc: "Josh Cartwright" <josh.cartwright-acOepvfBmUk@public.gmane.org>,
	"Jan Lübbe" <jlu-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
	devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
	"Michal Simek"
	<michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	"Lars-Peter Clausen"
	<lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>,
	git-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org,
	"Peter Crosthwaite"
	<pcrost-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>,
	"Sascha Hauer" <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: RFC v2: Zynq Clock Controller
Date: Tue, 02 Apr 2013 17:34:50 -0700	[thread overview]
Message-ID: <20130403003450.8177.2879@quantum> (raw)
In-Reply-To: <9b6821a5-8275-427e-a5aa-1bfd8e800d1b-8XeO8fnFoNFBP3niSOyP4rjjLBE8jN/0@public.gmane.org>

Quoting Sören Brinkmann (2013-03-29 15:36:18)
> On Tue, Mar 26, 2013 at 07:18:44PM -0700, Mike Turquette wrote:
> > As long as a key exists to link two clocks together then registration
> > order shouldn't matter.  Originally this key was an immutable clk name
> > string.
> > 
> > If clock parents are specified in DT then that should also suffice, in
> > place of doing string comparisons.
> > 
> > If no key to pair up clocks exists then yes we will have to rely purely
> > on the struct clk *opaque_cookie and register clocks in order.
> Okay, so I guess, the fundamental mechanisms should be in place. What is
> needed, is changing the key from being the clk name to something else.
> And preferably this something else is made up of something available
> through DT, so a child can reference its parent w/o the parent to be
> probed first. E.g. the provider's node name + the index of the clock
> output?

Right, order shouldn't matter in the sense that registering a child
before a parent should not constitute an absolute failure from the clock
framework point of view.

Folks using DT today still rely on the parent string name to link things
up.  Grep around for usage of of_clk_get_parent_name to see how several
platforms use that during registration.

> You mentioned, something like this was supposed to happen anyway, right?
> Do you already have something specific in mind/are working on a
> solution?
> 

I'm not looking at it currently.  If no one else gets around to it then
eventually I will.  It would be nice to not have to use
of_clk_get_parent_name and instead have a better way to establish
parent-child relationships at clock registration-time for DT clocks.

Regards,
Mike

>         Sören
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

      parent reply	other threads:[~2013-04-03  0:34 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-20 23:56 RFC v2: Zynq Clock Controller Sören Brinkmann
2013-03-21 18:32 ` Lars-Peter Clausen
2013-03-22 22:41   ` Sören Brinkmann
2013-03-25 14:46     ` Lars-Peter Clausen
2013-03-25 17:08       ` Sören Brinkmann
2013-03-25 17:19         ` Lars-Peter Clausen
2013-03-25 17:59           ` Sören Brinkmann
2013-03-25 18:10             ` Lars-Peter Clausen
2013-03-25 18:12               ` Sören Brinkmann
2013-03-26  0:49               ` Sören Brinkmann
     [not found]     ` <128fc723-ace7-4f4c-95d9-971b42a52080-p/+QeVIcf1ANTaRkHJHP0bjjLBE8jN/0@public.gmane.org>
2013-03-25 23:29       ` Stephen Warren
2013-03-25 23:59         ` Sören Brinkmann
     [not found] ` <27dae808-1d3a-4001-8eb2-b0a6e2a34b8f-dAX9Bq04yCTT7m58JnLnSLjjLBE8jN/0@public.gmane.org>
2013-03-25 18:13   ` Stephen Warren
2013-03-25 18:27     ` Sören Brinkmann
2013-03-25 23:33       ` Stephen Warren
2013-03-26  0:03         ` Sören Brinkmann
     [not found]           ` <b810d127-dad8-447c-bf88-8ac715debbff-QhSrsHip19vVOT3FKhN2rLjjLBE8jN/0@public.gmane.org>
2013-03-27  2:18             ` Mike Turquette
2013-03-29 22:36               ` Sören Brinkmann
     [not found]                 ` <9b6821a5-8275-427e-a5aa-1bfd8e800d1b-8XeO8fnFoNFBP3niSOyP4rjjLBE8jN/0@public.gmane.org>
2013-04-03  0:34                   ` Mike Turquette [this message]

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=20130403003450.8177.2879@quantum \
    --to=mturquette-qsej5fyqhm4dnm+yrofe0a@public.gmane.org \
    --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=git-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org \
    --cc=jlu-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
    --cc=josh.cartwright-acOepvfBmUk@public.gmane.org \
    --cc=lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org \
    --cc=pcrost-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org \
    --cc=s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
    --cc=soren.brinkmann-gjFFaj9aHVfQT0dZR+AlfA@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).