linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@kernel.org>
To: Janek Kotas <jank@cadence.com>
Cc: "mark.rutland@arm.com" <mark.rutland@arm.com>,
	"mturquette@baylibre.com" <mturquette@baylibre.com>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] clk: Add Fixed MMIO clock driver
Date: Thu, 29 Nov 2018 14:29:34 -0800	[thread overview]
Message-ID: <154353057449.88331.10017415440005548379@swboyd.mtv.corp.google.com> (raw)
In-Reply-To: <CAE55F09-516A-4737-8F74-07BBA3AF5737@global.cadence.com>

Quoting Janek Kotas (2018-11-15 00:27:15)
> Thanks for the reply.
> Jan
> 
> > On 14 Nov 2018, at 23:19, Stephen Boyd <sboyd@kernel.org> wrote:
> > 
> > Quoting Janek Kotas (2018-11-14 07:24:39)
> >> This patch adds a driver for Fixed MMIO clock.
> >> The driver reads a clock frequency value from a single 32-bit memory
> >> mapped register and registers it as a fixed rate clock.
> >> 
> >> It can be enabled with COMMON_CLK_FIXED_MMIO Kconfig option.
> >> 
> >> Signed-off-by: Jan Kotas <jank@cadence.com>
> > 
> > Sounds like a fine idea. Except I can see how it will be abused if there
> > are a handful of these fixed rate "clks" somewhere in memory that all
> > get populated. 
> > 
> > Do you really have a fixed rate clk in hardware that exposes a single
> > register, or do you have a set of them that some firmware is populating
> > into an I/O memory space that we can read the fixed rates from? If it's
> > the latter, I wonder why we can't just have the firmware populate the
> > fixed rate clks into DT itself?
> 
> The first case.
> We have a single register in a fixed location which contains 
> the frequency of the main system clock.
> This allows us to use the same image in emulation, FPGA
> and simulation without any changes.
> We usually don’t use a full bootloader, just a simple wrapper,
> which initializes the necessary stuff and jumps to the kernel.

So the hardware team has decided to throw a frequency register in there?
Alright! Does that fixed rate clk generate its fixed rate from some
other clk? I'm curious if this fixed rate clk has a parent source.

It would also be good to make sure that any clks registered from this
driver can't be populated from regions of memory like DDR. Can you
confirm? I think it will fail, but it would be worth checking

> 
> > 
> >> diff --git a/drivers/clk/clk-fixed-mmio.c b/drivers/clk/clk-fixed-mmio.c
> >> new file mode 100644
> >> index 0000000000..bbcadab345
> >> --- /dev/null
> >> +++ b/drivers/clk/clk-fixed-mmio.c
> 
> > 
> >> +}
> >> +
> >> +CLK_OF_DECLARE(fixed_mmio_clk, "fixed-mmio-clock", of_fixed_mmio_clk_setup);
> > 
> > Any reason why this can't be a platform driver? It would make this much
> > less DT specific and usable on other firmwares/platforms if we used a
> > platform driver here.
> > 
> 
> I looked at the fixed rate clock as a reference, but I can change it to 
> a platform driver, if that’s preferred.
> 

Yes I'd prefer a platform driver unless there's some reason it can't be
done. We may need to have both in case this needs to be populated very
early, but if that isn't the case then just a platform driver for now.


  reply	other threads:[~2018-11-29 22:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-14 15:24 [PATCH 2/2] clk: Add Fixed MMIO clock driver Janek Kotas
2018-11-14 22:19 ` Stephen Boyd
2018-11-15  8:27   ` Janek Kotas
2018-11-29 22:29     ` Stephen Boyd [this message]
     [not found]       ` <76BDCB72-CC05-41D1-93A0-6D71CBD97651@global.cadence.com>
2018-11-30  8:58         ` Stephen Boyd
     [not found]           ` <63A29785-D1AC-4B7C-952E-3A2E5799A21D@global.cadence.com>
2018-11-30 18:56             ` Stephen Boyd

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=154353057449.88331.10017415440005548379@swboyd.mtv.corp.google.com \
    --to=sboyd@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jank@cadence.com \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mturquette@baylibre.com \
    --cc=robh+dt@kernel.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).