linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
To: Jisheng Zhang <jszhang@marvell.com>,
	Antoine Tenart <antoine.tenart@free-electrons.com>
Cc: "mturquette@linaro.org" <mturquette@linaro.org>,
	"sboyd@codeaurora.org" <sboyd@codeaurora.org>,
	Jimmy Xu <zmxu@marvell.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/7] ARM: berlin: refactor the clock
Date: Mon, 16 Feb 2015 12:05:47 +0100	[thread overview]
Message-ID: <54E1CF0B.1030901@gmail.com> (raw)
In-Reply-To: <20150216113738.281f226a@xhacker>

On 16.02.2015 04:37, Jisheng Zhang wrote:
> On Fri, 13 Feb 2015 08:42:54 -0800
> Antoine Tenart <antoine.tenart@free-electrons.com> wrote:
>> Marvell Berlin SoCs have a chip control register set providing several
>> individual registers dealing with various controllers (pinctrl, reset,
>> clk). This chip controller is described by a single DT node since the
>> individual registers are spread among the chip control register bank.
>>
>> Marvell Berlin also have a system control register set providing several
>> individual registers for pinctrl or adc.
>
> There's no chip control IP. The HW just put some HW registers into the so
> called "chip control" address space, the registers in this space are mostly used for
> "control" purpose, but some are not. Take the clk as an example, some clocks'
> registers are put into the system control register space, some clocks' are
> not.

Jisheng,

you are right, there is no specific IP for those registers. But as we
don't want these registers to be spread among our SoC nodes, we chose
to sum them all up into a single node.

Back when the clk driver was proposed, Mike requested to not expose
each of the clocks in DT - so we joined them basically into a single
node and let the driver do the rest.

Now, this patch set goes a little bit further and simply joins all of
the chip ctrl registers into a single node and just adds sub-nodes where
we need them (e.g. pinctrl).

[...]
> In newer chips, there are no group clocks any more. So the driver code can be more
> simpler and clean.
>
> So I think we'd better to implement drivers without the "chip control" concept in
> mind. The previous clock patches reflect what the HW really does.

I see no problem in what future SoCs do with register layout. It seems
that it will be fundamentally different anyway, so we might consider to
have a completely new driver for any SoC past BG2Q.

> The above is just my humble opinions and the current berlin clk driver is different
> with the previous one I dunno how can we handle this situation now. I really need
> help!

We appreciate you share your opinion!

How does having a single node  (and basically a single reg property
shared by regmap) block you from implementing support for your new SoC?

Also, you don't need to follow the chip-ctrl node concept for the new
SoC if it is too different. It is just that we kind of give up to chop
this register set into functional pieces in DT and think it will be
better dealt with in each of the drivers.

Sebastian

      parent reply	other threads:[~2015-02-16 11:05 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-13 16:42 [PATCH 0/7] ARM: berlin: refactor the clock Antoine Tenart
2015-02-13 16:42 ` [PATCH 1/7] clk: convert clock mux to accept regmap Antoine Tenart
2015-02-13 16:42 ` [PATCH 2/7] clk: convert clock gate " Antoine Tenart
2015-02-13 16:42 ` [PATCH 3/7] clk: berlin: use regmap Antoine Tenart
2015-02-13 16:42 ` [PATCH 4/7] Documentation: bindings: move the Berlin clock documentation Antoine Tenart
2015-02-13 16:42 ` [PATCH 5/7] ARM: berlin: rework the clock node for BG2 Antoine Tenart
2015-02-13 16:43 ` [PATCH 6/7] ARM: berlin: rework the clock node for BG2CD Antoine Tenart
2015-02-13 16:43 ` [PATCH 7/7] ARM: berlin: rework the clock node for BG2Q Antoine Tenart
2015-02-13 17:31 ` [PATCH 0/7] ARM: berlin: refactor the clock Andrew Lunn
2015-02-13 18:04   ` Antoine Tenart
2015-02-13 18:19   ` Thomas Petazzoni
2015-02-13 18:33     ` Sebastian Hesselbarth
2015-02-13 19:22       ` Andrew Lunn
2015-02-16  3:37 ` Jisheng Zhang
2015-02-16  3:46   ` Jisheng Zhang
2015-02-16 11:05   ` Sebastian Hesselbarth [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=54E1CF0B.1030901@gmail.com \
    --to=sebastian.hesselbarth@gmail.com \
    --cc=antoine.tenart@free-electrons.com \
    --cc=jszhang@marvell.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mturquette@linaro.org \
    --cc=sboyd@codeaurora.org \
    --cc=zmxu@marvell.com \
    /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).