devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Uwe Kleine-König" <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
To: Dirk Behme <dirk.behme-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Dirk Behme <dirk.behme-V5te9oGctAVWk0Htik3J/w@public.gmane.org>,
	Linux PM list <linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"Rafael J. Wysocki" <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org>,
	Michael Turquette
	<mturquette-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>,
	Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	Linux-Renesas
	<linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Geert Uytterhoeven
	<geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>,
	Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>,
	linux-clk <linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org
Subject: Re: Clocks used by another OS/CPU (was: Re: [RFC PATCH] clk: renesas: cpg-mssr: Add interface for critical core clocks)
Date: Sun, 2 Jul 2017 11:23:36 +0200	[thread overview]
Message-ID: <20170702092336.uxwl23kyd4koxclj@pengutronix.de> (raw)
In-Reply-To: <6098d579-f206-5a23-bbfc-ac13e0448479-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Hello Dirk,

On Sun, Jul 02, 2017 at 07:48:41AM +0200, Dirk Behme wrote:
> > On my machine (Udoo Neo, A9 + M4) the A9 is the primary CPU that is
> > started by the bootrom. If I want the M4 being the primary device I'd
> > need support in the bootloader to wait long enough (i.e. until the M4 is
> > up) before letting the A9 jump into Linux. Managable I'd say. This way
> > would even make sense if the M4 runs a rt critical OS that shouldn't be
> > forced to wait on the non-rt A9 to enable a clk.
> 
> 
> Overall, assuming that the issue we are discussing here can be solved quite
> easily in hardware (a set of clock registers for each CPU/OS domain,
> connected cleverly to effectively control each clock, with access protection
> for each set of registers) I tend to think that for a SoC supposed to run
> different OS on different cores this is a missing hardware feature (bug?).

So you want to enable bits for your CAN clock, one in each cpu's domain.

I'd say that is a nice idea that a hardware engineer might be proud to
pick up but that results in more headache than fun for the software
colleague.

There are several problems that come immediately to mind:

 - You can switch of a clk because you don't need it on, or because you
   need it off. I guess you want to have the clock on if at least one
   cpu wants it on. So you take away the freedom from the other cpu to
   force the clock off. (Yeah, the currently available clk framework
   doesn't allow that either.)
 - What if cpu 0 sets the parent of the can clk to pll2 but cpu 1 wants
   it set to pll1? How does cpu 1 notice the change?
 - On off might be relatively easy, what about clk dividers? cpu 0 sets
   2 which cpu 1 sets 6.

That convinces me that the disadvantages of having two views on the clk
core have more weight and you really want a single view and share that
by software.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
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:[~2017-07-02  9:23 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-29  9:27 Clocks used by another OS/CPU (was: Re: [RFC PATCH] clk: renesas: cpg-mssr: Add interface for critical core clocks) Geert Uytterhoeven
2017-06-29 10:28 ` Dirk Behme
2017-06-29 11:18   ` Geert Uytterhoeven
2017-06-29 13:18     ` Clocks used by another OS/CPU Dirk Behme
2017-06-29 13:22       ` Geert Uytterhoeven
     [not found] ` <CAMuHMdW9+CNTTOVO4SRRUxuz3ajLbY2j1uG8b_RpHX52NPwXrQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-06-29 11:56   ` Clocks used by another OS/CPU (was: Re: [RFC PATCH] clk: renesas: cpg-mssr: Add interface for critical core clocks) Geert Uytterhoeven
2017-06-29 12:07     ` Clocks used by another OS/CPU Dirk Behme
2017-06-29 12:45       ` Geert Uytterhoeven
2017-06-29 12:55         ` Dirk Behme
2017-06-30  8:02 ` Clocks used by another OS/CPU (was: Re: [RFC PATCH] clk: renesas: cpg-mssr: Add interface for critical core clocks) Peter De Schrijver
2017-06-30 15:58 ` Rob Herring
2017-06-30 20:24   ` Uwe Kleine-König
     [not found]     ` <20170630202453.eh6vaehkap3as4np-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2017-07-01  5:02       ` Dirk Behme
2017-07-01 18:14         ` Uwe Kleine-König
2017-07-02  5:48           ` Dirk Behme
     [not found]             ` <6098d579-f206-5a23-bbfc-ac13e0448479-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-07-02  9:23               ` Uwe Kleine-König [this message]
2017-07-03  7:40                 ` Geert Uytterhoeven
     [not found]           ` <20170701181408.yuocymwtj5dgt74d-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2017-07-03  9:17             ` Sudeep Holla
2017-07-04  7:31               ` Peter De Schrijver
2017-07-04  8:49                 ` Sudeep Holla
2017-07-05  7:25                   ` Peter De Schrijver

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=20170702092336.uxwl23kyd4koxclj@pengutronix.de \
    --to=u.kleine-koenig-bicnvbalz9megne8c9+irq@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=dirk.behme-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=dirk.behme-V5te9oGctAVWk0Htik3J/w@public.gmane.org \
    --cc=geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org \
    --cc=kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
    --cc=khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
    --cc=mturquette-rdvid1DuHRBWk0Htik3J/w@public.gmane.org \
    --cc=rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org \
    --cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
    --cc=ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@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).