linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jisheng Zhang <jszhang@marvell.com>
To: Antoine Tenart <antoine.tenart@free-electrons.com>
Cc: "sebastian.hesselbarth@gmail.com"
	<sebastian.hesselbarth@gmail.com>,
	"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 11:37:38 +0800	[thread overview]
Message-ID: <20150216113738.281f226a@xhacker> (raw)
In-Reply-To: <1423845781-7480-1-git-send-email-antoine.tenart@free-electrons.com>

Hi all,

On Fri, 13 Feb 2015 08:42:54 -0800
Antoine Tenart <antoine.tenart@free-electrons.com> wrote:

> Hi,
> 
> 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.

So far, there are five type of clocks in Berlin (from the driver programmer's point
of view):

1. gate clocks. The clocks may share register. The clocks can only be gated or ungated.

2. individual clocks. The clock doesn't share registers with each other.
The gate/ungate, clock source selection, clock divider etc. bits of each clock are
put into one individual register. one register per clock.

3. group clocks. The gate/ungate bits of these clocks are grouped into one register,
the clock source selection, clock divider bits of these clocks are grouped into another
one or two register.

4. plls. The pll doesn't share registers with each other. For example, syspll,
cpupll etc. one or two register per pll

5. fixed clock. the oscillator used for reference clock.

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.

https://lkml.org/lkml/2014/3/21/413

https://lkml.org/lkml/2014/4/24/624


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!

Thanks,
Jisheng


  parent reply	other threads:[~2015-02-16  3:40 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 [this message]
2015-02-16  3:46   ` Jisheng Zhang
2015-02-16 11:05   ` Sebastian Hesselbarth

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=20150216113738.281f226a@xhacker \
    --to=jszhang@marvell.com \
    --cc=antoine.tenart@free-electrons.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mturquette@linaro.org \
    --cc=sboyd@codeaurora.org \
    --cc=sebastian.hesselbarth@gmail.com \
    --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).