All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@codeaurora.org>
To: Mike Turquette <mturquette@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
	Saravana Kannan <skannan@codeaurora.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH v1 09/14] clk: msm: Add support for MSM8960's global clock controller (GCC)
Date: Tue, 13 Aug 2013 11:42:48 -0700	[thread overview]
Message-ID: <20130813184248.GG14845@codeaurora.org> (raw)
In-Reply-To: <20130813142411.4443.85003@quantum>

On 08/13, Mike Turquette wrote:
> Quoting Stephen Boyd (2013-08-12 22:03:34)
> > The clock controller is hardware and the number of clock outputs
> > is fixed. Isn't all hardware fixed until you start talking about
> > FPGAs? The next minor revision of the clock controller may add
> > more clocks or remove clocks from that base design, but otherwise
> > the two are 90% the same and generally software compatible. It
> > isn't until we start a new generation of chips that we make major
> > changes to the design. Is that loose enough to qualify?
> > 
> > These bindings attempt to follow the regulator bindings. With
> > regulators there is a node for each regulator and we describe
> > physical characteristics of those regulators within the nodes but
> > we don't describe the software interface (bits, masks, shifts,
> > etc). I imagine we could extend these clock nodes to describe
> > physical characteristics such as min/max frequency or if the
> > bootloader has left the clocks on. Right now we're using the
> > nodes to describe what types of clocks there are and how the
> > clock tree is layed out.
> > 
> > Or perhaps you're talking about clock sharing? We share the clock
> > controller with multiple masters (processors running other OSes)
> > and the partitioning of the clocks is mostly predefined. We just
> > won't use some clocks because they're reserved for other
> > processors. They're still part of the same clock controller
> > hardware block but we don't want to control them on Linux because
> > we'll trample over other processors and most likely hang the
> > system. I wonder how this would work for hexagon and krait both
> > running linux on the same SoC. If all DT says is that there is a
> > gcc here at this address how are we supposed to know that we
> > shouldn't use some clock? 
> 
> Do Krait and Hexagon have the same register map? On the ARM SoCs I am
> familiar with the masters have differing views of register addresses for
> the same peripherals and hardware blocks. So you couldn't use the same
> DTS in a straightforward way if this is true for your system.
> 

They both have the same view of the register map.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

WARNING: multiple messages have this Message-ID (diff)
From: sboyd@codeaurora.org (Stephen Boyd)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v1 09/14] clk: msm: Add support for MSM8960's global clock controller (GCC)
Date: Tue, 13 Aug 2013 11:42:48 -0700	[thread overview]
Message-ID: <20130813184248.GG14845@codeaurora.org> (raw)
In-Reply-To: <20130813142411.4443.85003@quantum>

On 08/13, Mike Turquette wrote:
> Quoting Stephen Boyd (2013-08-12 22:03:34)
> > The clock controller is hardware and the number of clock outputs
> > is fixed. Isn't all hardware fixed until you start talking about
> > FPGAs? The next minor revision of the clock controller may add
> > more clocks or remove clocks from that base design, but otherwise
> > the two are 90% the same and generally software compatible. It
> > isn't until we start a new generation of chips that we make major
> > changes to the design. Is that loose enough to qualify?
> > 
> > These bindings attempt to follow the regulator bindings. With
> > regulators there is a node for each regulator and we describe
> > physical characteristics of those regulators within the nodes but
> > we don't describe the software interface (bits, masks, shifts,
> > etc). I imagine we could extend these clock nodes to describe
> > physical characteristics such as min/max frequency or if the
> > bootloader has left the clocks on. Right now we're using the
> > nodes to describe what types of clocks there are and how the
> > clock tree is layed out.
> > 
> > Or perhaps you're talking about clock sharing? We share the clock
> > controller with multiple masters (processors running other OSes)
> > and the partitioning of the clocks is mostly predefined. We just
> > won't use some clocks because they're reserved for other
> > processors. They're still part of the same clock controller
> > hardware block but we don't want to control them on Linux because
> > we'll trample over other processors and most likely hang the
> > system. I wonder how this would work for hexagon and krait both
> > running linux on the same SoC. If all DT says is that there is a
> > gcc here at this address how are we supposed to know that we
> > shouldn't use some clock? 
> 
> Do Krait and Hexagon have the same register map? On the ARM SoCs I am
> familiar with the masters have differing views of register addresses for
> the same peripherals and hardware blocks. So you couldn't use the same
> DTS in a straightforward way if this is true for your system.
> 

They both have the same view of the register map.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

  reply	other threads:[~2013-08-13 18:42 UTC|newest]

Thread overview: 90+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-25  0:43 [PATCH v1 00/14] Add support for MSM's mmio clocks Stephen Boyd
2013-07-25  0:43 ` Stephen Boyd
2013-07-25  0:43 ` [PATCH v1 01/14] clk: fixed-rate: Export clk_fixed_rate_register() Stephen Boyd
2013-07-25  0:43   ` Stephen Boyd
2013-08-03  3:32   ` Mike Turquette
2013-08-03  3:32     ` Mike Turquette
2013-07-25  0:43 ` [PATCH v1 02/14] clk: Add of_init_clk_data() to parse common clock bindings Stephen Boyd
2013-07-25  0:43   ` Stephen Boyd
2013-07-25  8:21   ` Tomasz Figa
2013-07-25  8:21     ` Tomasz Figa
2013-07-25 16:36     ` Stephen Boyd
2013-07-25 16:36       ` Stephen Boyd
2013-08-03  1:06       ` Mike Turquette
2013-08-03  1:06         ` Mike Turquette
2013-07-25  0:43 ` [PATCH v1 03/14] clk: Add of_clk_match() for device drivers Stephen Boyd
2013-07-25  0:43   ` Stephen Boyd
2013-07-25  8:12   ` Tomasz Figa
2013-07-25  8:12     ` Tomasz Figa
2013-07-25 16:36     ` Stephen Boyd
2013-07-25 16:36       ` Stephen Boyd
2013-08-12 20:23   ` Mike Turquette
2013-08-12 20:23     ` Mike Turquette
2013-08-13  5:48     ` Stephen Boyd
2013-08-13  5:48       ` Stephen Boyd
2013-08-15  5:02       ` Mike Turquette
2013-08-15  5:02         ` Mike Turquette
2013-08-16  1:31         ` Stephen Boyd
2013-08-16  1:31           ` Stephen Boyd
2013-08-16  3:44           ` Mike Turquette
2013-08-16  3:44             ` Mike Turquette
2013-08-16 16:43         ` Kumar Gala
2013-08-16 16:43           ` Kumar Gala
2013-08-16 17:16           ` Kumar Gala
2013-08-16 17:16             ` Kumar Gala
2013-07-25  0:43 ` [PATCH v1 04/14] clk: Add set_rate_and_parent() op Stephen Boyd
2013-07-25  0:43   ` Stephen Boyd
2013-07-25  8:26   ` Tomasz Figa
2013-07-25  8:26     ` Tomasz Figa
2013-07-25  8:26     ` Tomasz Figa
2013-07-25 16:45     ` Stephen Boyd
2013-07-25 16:45       ` Stephen Boyd
2013-08-09  5:32       ` Mike Turquette
2013-08-09  5:32         ` Mike Turquette
2013-08-09  9:11   ` James Hogan
2013-08-09  9:11     ` James Hogan
2013-08-09  9:11     ` James Hogan
2013-07-25  0:43 ` [PATCH v1 05/14] clk: msm: Add support for phase locked loops (PLLs) Stephen Boyd
2013-07-25  0:43   ` Stephen Boyd
2013-07-25  0:43   ` Stephen Boyd
2013-07-25  8:29   ` Tomasz Figa
2013-07-25  8:29     ` Tomasz Figa
2013-07-25 16:37     ` Stephen Boyd
2013-07-25 16:37       ` Stephen Boyd
2013-07-25  0:43 ` [PATCH v1 06/14] clk: msm: Add support for root clock generators (RCGs) Stephen Boyd
2013-07-25  0:43   ` Stephen Boyd
2013-07-25  0:43 ` [PATCH v1 07/14] clk: msm: Add support for branches/gate clocks Stephen Boyd
2013-07-25  0:43   ` Stephen Boyd
2013-07-25  0:43 ` [PATCH v1 08/14] clk: msm: Add MSM clock driver Stephen Boyd
2013-07-25  0:43   ` Stephen Boyd
2013-07-25  8:32   ` Tomasz Figa
2013-07-25  8:32     ` Tomasz Figa
2013-07-25 16:40     ` Stephen Boyd
2013-07-25 16:40       ` Stephen Boyd
2013-07-25  0:43 ` [PATCH v1 09/14] clk: msm: Add support for MSM8960's global clock controller (GCC) Stephen Boyd
2013-07-25  0:43   ` Stephen Boyd
2013-08-08 17:00   ` Mark Rutland
2013-08-08 17:00     ` Mark Rutland
2013-08-08 17:00     ` Mark Rutland
2013-08-13  5:03     ` Stephen Boyd
2013-08-13  5:03       ` Stephen Boyd
2013-08-13  5:03       ` Stephen Boyd
2013-08-13 14:24       ` Mike Turquette
2013-08-13 14:24         ` Mike Turquette
2013-08-13 14:24         ` Mike Turquette
2013-08-13 18:42         ` Stephen Boyd [this message]
2013-08-13 18:42           ` Stephen Boyd
2013-08-13 18:42           ` Stephen Boyd
2013-07-25  0:43 ` [PATCH v1 10/14] clk: msm: Add support for MSM8960's multimedia clock controller (MMCC) Stephen Boyd
2013-07-25  0:43   ` Stephen Boyd
2013-08-08 17:02   ` Mark Rutland
2013-08-08 17:02     ` Mark Rutland
2013-08-08 17:02     ` Mark Rutland
2013-07-25  0:43 ` [PATCH v1 11/14] ARM: dts: msm: Add MSM8960 GCC DT nodes Stephen Boyd
2013-07-25  0:43   ` Stephen Boyd
2013-07-25  0:43 ` [PATCH v1 12/14] ARM: dts: msm: Add MSM8960 MMCC " Stephen Boyd
2013-07-25  0:43   ` Stephen Boyd
2013-07-25  0:43 ` [PATCH v1 13/14] clk: msm: Add MSM8974 GCC data Stephen Boyd
2013-07-25  0:43   ` Stephen Boyd
2013-07-25  0:43 ` [PATCH v1 14/14] ARM: dts: msm: Add clock entries for MSM8960 uart device Stephen Boyd
2013-07-25  0:43   ` 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=20130813184248.GG14845@codeaurora.org \
    --to=sboyd@codeaurora.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mturquette@linaro.org \
    --cc=skannan@codeaurora.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.