All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Tero Kristo <t-kristo@ti.com>
Cc: paul@pwsan.com, linux-omap@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCHv3 34/35] ARM: dts: dra7: add system control module node
Date: Wed, 11 Mar 2015 12:26:22 -0700	[thread overview]
Message-ID: <20150311192621.GE5264@atomide.com> (raw)
In-Reply-To: <550092CA.9030008@ti.com>

* Tero Kristo <t-kristo@ti.com> [150311 12:09]:
> On 03/11/2015 07:17 PM, Tony Lindgren wrote:
> >Hi Tero,
> >
> >* Tero Kristo <t-kristo@ti.com> [150225 11:09]:
> >>Add node for system control module, and move all the existing system
> >>control IO space users under this new node as its children. A new node
> >>for scm_conf area is also added.
> >...
> >
> >>--- a/arch/arm/boot/dts/dra7.dtsi
> >>+++ b/arch/arm/boot/dts/dra7.dtsi
> >>@@ -203,26 +203,47 @@
> >>  			};
> >>  		};
> >>
> >>+		scm: scm@4a002000 {
> >>+			compatible = "ti,dra7-ctrl", "simple-bus";
> >>+			reg = <0x4a002000 0x1400>,
> >>+			      <0x4a003400 0x600>,
> >>+			      <0x4ae0c000 0x600>;
> >>+			#address-cells = <2>;
> >>+			#size-cells = <1>;
> >>+			ranges = <0 0 0x4a002000 0x1400>,
> >>+				 <1 0 0x4a003400 0x600>,
> >>+				 <2 0 0x4ae0c000 0x600>;
> >>+
> >>+			scm_conf: tisyscon@0,0 {
> >>+				compatible = "syscon";
> >>+				reg = <0 0x0 0x1400>;
> >>+				#address-cells = <1>;
> >>+				#size-cells = <1>;
> >>+			};
> >>+
> >>+			dra7_pmx_core: pinmux@1,0 {
> >>+				compatible = "ti,dra7-padconf",
> >>+					     "pinctrl-single";
> >>+				reg = <1 0x0 0x0464>;
> >>+				#address-cells = <1>;
> >>+				#size-cells = <0>;
> >>+				#interrupt-cells = <1>;
> >>+				interrupt-controller;
> >>+				pinctrl-single,register-width = <32>;
> >>+				pinctrl-single,function-mask = <0x3fffffff>;
> >>+			};
> >>+		};
> >
> >Wouldn't it make more sense to have separate device_scm, core_scm and
> >wkup_scm instead of stuffing multiple ranges here?
> >
> >Or are there other reasons for the multiple ranges?
> 
> Yea that was the alternative I was thinking about, I ended up with this for
> some reason. I think personally I liked having them all under the same SCM
> part, because they are nicely grouped then, and well, its the same system
> control part in the chip. We can split it up easily of course. Should we
> have a higher level scm part and then have core_scm and wkup_scm under this
> followed by the sub-functions, or just drop the top level scm part
> completely?

Well I'd model it after the hardware so we can have one or more scm driver
instances managing the clock for those blocks. If we squash them together,
we won't have a chance to pass interrupts and clocks device tree property
to the right driver instance. And for example 5432 TRM has them as separate
devices in "Figure 18-1. Control Module Overview".

I don't think we need the top level scm to group them under, these are all
connected seprately to the interconnect, right?
 
> This same question applies to omap4 + omap5 also. In some part for omap3
> also, as it also has pmx_core + pmx_wkup separately, even if they are part
> of the same register space.
> 
> Anyway, just a political decision from your side, I am fine either way. :)

OK thanks for confirming that, to me it makes sense to set them up as
separate instances then.

Regards,

Tony

WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv3 34/35] ARM: dts: dra7: add system control module node
Date: Wed, 11 Mar 2015 12:26:22 -0700	[thread overview]
Message-ID: <20150311192621.GE5264@atomide.com> (raw)
In-Reply-To: <550092CA.9030008@ti.com>

* Tero Kristo <t-kristo@ti.com> [150311 12:09]:
> On 03/11/2015 07:17 PM, Tony Lindgren wrote:
> >Hi Tero,
> >
> >* Tero Kristo <t-kristo@ti.com> [150225 11:09]:
> >>Add node for system control module, and move all the existing system
> >>control IO space users under this new node as its children. A new node
> >>for scm_conf area is also added.
> >...
> >
> >>--- a/arch/arm/boot/dts/dra7.dtsi
> >>+++ b/arch/arm/boot/dts/dra7.dtsi
> >>@@ -203,26 +203,47 @@
> >>  			};
> >>  		};
> >>
> >>+		scm: scm at 4a002000 {
> >>+			compatible = "ti,dra7-ctrl", "simple-bus";
> >>+			reg = <0x4a002000 0x1400>,
> >>+			      <0x4a003400 0x600>,
> >>+			      <0x4ae0c000 0x600>;
> >>+			#address-cells = <2>;
> >>+			#size-cells = <1>;
> >>+			ranges = <0 0 0x4a002000 0x1400>,
> >>+				 <1 0 0x4a003400 0x600>,
> >>+				 <2 0 0x4ae0c000 0x600>;
> >>+
> >>+			scm_conf: tisyscon at 0,0 {
> >>+				compatible = "syscon";
> >>+				reg = <0 0x0 0x1400>;
> >>+				#address-cells = <1>;
> >>+				#size-cells = <1>;
> >>+			};
> >>+
> >>+			dra7_pmx_core: pinmux at 1,0 {
> >>+				compatible = "ti,dra7-padconf",
> >>+					     "pinctrl-single";
> >>+				reg = <1 0x0 0x0464>;
> >>+				#address-cells = <1>;
> >>+				#size-cells = <0>;
> >>+				#interrupt-cells = <1>;
> >>+				interrupt-controller;
> >>+				pinctrl-single,register-width = <32>;
> >>+				pinctrl-single,function-mask = <0x3fffffff>;
> >>+			};
> >>+		};
> >
> >Wouldn't it make more sense to have separate device_scm, core_scm and
> >wkup_scm instead of stuffing multiple ranges here?
> >
> >Or are there other reasons for the multiple ranges?
> 
> Yea that was the alternative I was thinking about, I ended up with this for
> some reason. I think personally I liked having them all under the same SCM
> part, because they are nicely grouped then, and well, its the same system
> control part in the chip. We can split it up easily of course. Should we
> have a higher level scm part and then have core_scm and wkup_scm under this
> followed by the sub-functions, or just drop the top level scm part
> completely?

Well I'd model it after the hardware so we can have one or more scm driver
instances managing the clock for those blocks. If we squash them together,
we won't have a chance to pass interrupts and clocks device tree property
to the right driver instance. And for example 5432 TRM has them as separate
devices in "Figure 18-1. Control Module Overview".

I don't think we need the top level scm to group them under, these are all
connected seprately to the interconnect, right?
 
> This same question applies to omap4 + omap5 also. In some part for omap3
> also, as it also has pmx_core + pmx_wkup separately, even if they are part
> of the same register space.
> 
> Anyway, just a political decision from your side, I am fine either way. :)

OK thanks for confirming that, to me it makes sense to set them up as
separate instances then.

Regards,

Tony

  reply	other threads:[~2015-03-11 19:31 UTC|newest]

Thread overview: 100+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-25 19:04 [PATCHv3 00/35] ARM: OMAP2+: PRCM / SCM cleanups against 4.0-rc1 Tero Kristo
2015-02-25 19:04 ` Tero Kristo
2015-02-25 19:04 ` [PATCHv3 01/35] ARM: OMAP2+: PRCM: rename of_prcm_init to omap_prcm_init Tero Kristo
2015-02-25 19:04   ` Tero Kristo
2015-02-25 19:04 ` [PATCHv3 02/35] ARM: OMAP3: PRM: invert the wkst_mask for the prm_clear_mod_irqs Tero Kristo
2015-02-25 19:04   ` Tero Kristo
2015-02-25 19:04 ` [PATCHv3 03/35] ARM: OMAP2+: PRM: add generic API for clear_mod_irqs Tero Kristo
2015-02-25 19:04   ` Tero Kristo
2015-02-25 19:08   ` Felipe Balbi
2015-02-25 19:08     ` Felipe Balbi
2015-02-25 19:04 ` [PATCHv3 04/35] ARM: OMAP3+: PRM: add common APIs for prm_vp_check/clear_txdone Tero Kristo
2015-02-25 19:04   ` Tero Kristo
2015-02-25 19:09   ` Felipe Balbi
2015-02-25 19:09     ` Felipe Balbi
2015-02-25 19:44     ` Tero Kristo
2015-02-25 19:44       ` Tero Kristo
2015-02-25 19:04 ` [PATCHv3 05/35] ARM: OMAP4+: PRM: move omap_prm_base_init under OMAP4 PRM driver Tero Kristo
2015-02-25 19:04   ` Tero Kristo
2015-02-25 19:04 ` [PATCHv3 06/35] ARM: OMAP4+: CM: move omap_cm_base_init under OMAP4 CM driver Tero Kristo
2015-02-25 19:04   ` Tero Kristo
2015-02-25 19:04 ` [PATCHv3 07/35] ARM: OMAP4: PRM: move omap4xxx_prm_init earlier in init order Tero Kristo
2015-02-25 19:04   ` Tero Kristo
2015-02-25 19:04 ` [PATCHv3 08/35] clk: ti: fix ti_clk_get_reg_addr error handling Tero Kristo
2015-02-25 19:04   ` Tero Kristo
2015-03-06 19:18   ` Mike Turquette
2015-03-06 19:18     ` Mike Turquette
2015-03-17 18:38     ` Tony Lindgren
2015-03-17 18:38       ` Tony Lindgren
2015-03-18  7:06       ` Tero Kristo
2015-03-18  7:06         ` Tero Kristo
2015-03-18 17:02         ` Tony Lindgren
2015-03-18 17:02           ` Tony Lindgren
2015-03-19  7:14           ` Tero Kristo
2015-03-19  7:14             ` Tero Kristo
2015-03-20  7:00     ` Tero Kristo
2015-03-20  7:00       ` Tero Kristo
2015-02-25 19:04 ` [PATCHv3 09/35] Documentation: DT: document PRCM compatible strings for dm81x SoCs Tero Kristo
2015-02-25 19:04   ` Tero Kristo
2015-02-25 19:04 ` [PATCHv3 10/35] ARM: OMAP2+: PRCM: add support for static clock memmap indices Tero Kristo
2015-02-25 19:04   ` Tero Kristo
2015-02-25 19:04 ` [PATCHv3 11/35] ARM: OMAP2+: clock: move clock provider infrastructure to clock driver Tero Kristo
2015-02-25 19:04   ` Tero Kristo
2015-02-25 19:04 ` [PATCHv3 12/35] ARM: OMAP2+: PRCM: split PRCM module init to their own driver files Tero Kristo
2015-02-25 19:04   ` Tero Kristo
2015-02-25 19:04 ` [PATCHv3 13/35] ARM: OMAP2+: CM: determine CM base address from device tree Tero Kristo
2015-02-25 19:04   ` Tero Kristo
2015-02-25 19:04 ` [PATCHv3 14/35] ARM: OMAP2+: PRM: determine PRM " Tero Kristo
2015-02-25 19:04   ` Tero Kristo
2015-02-25 19:04 ` [PATCHv3 15/35] ARM: OMAP2+: control: determine control module base address from DT Tero Kristo
2015-02-25 19:04   ` Tero Kristo
2015-02-25 19:04 ` [PATCHv3 16/35] ARM: OMAP2+: PRM: move SoC specific init calls within a generic API Tero Kristo
2015-02-25 19:04   ` Tero Kristo
2015-02-25 19:04 ` [PATCHv3 17/35] ARM: OMAP4+: PRM: determine prm_device_inst based on DT compatibility Tero Kristo
2015-02-25 19:04   ` Tero Kristo
2015-02-25 19:04 ` [PATCHv3 18/35] ARM: OMAP2+: CM: move SoC specific init calls within a generic API Tero Kristo
2015-02-25 19:04   ` Tero Kristo
2015-02-25 19:04 ` [PATCHv3 19/35] ARM: OMAP4+: PRM: setup prm_features from the PRM init time flags Tero Kristo
2015-02-25 19:04   ` Tero Kristo
2015-02-25 19:04 ` [PATCHv3 20/35] ARM: OMAP4+: PRM: get rid of cpu_is_omap44xx calls from interrupt init Tero Kristo
2015-02-25 19:04   ` Tero Kristo
2015-02-25 19:04 ` [PATCHv3 21/35] ARM: OMAP2+: clock: add low-level support for regmap Tero Kristo
2015-02-25 19:04   ` Tero Kristo
2015-02-25 19:04 ` [PATCHv3 22/35] ARM: OMAP2+: control: remove API for getting control module base address Tero Kristo
2015-02-25 19:04   ` Tero Kristo
2015-02-25 19:04 ` [PATCHv3 23/35] ARM: OMAP2+: id: cache omap_type value Tero Kristo
2015-02-25 19:04   ` Tero Kristo
2015-02-25 19:04 ` [PATCHv3 24/35] ARM: OMAP2+: control: add syscon support for register accesses Tero Kristo
2015-02-25 19:04   ` Tero Kristo
2015-02-25 19:04 ` [PATCHv3 25/35] ARM: dts: omap24xx: merge control module features under scrm node Tero Kristo
2015-02-25 19:04   ` Tero Kristo
2015-02-25 19:04 ` [PATCHv3 26/35] ARM: dts: omap3: " Tero Kristo
2015-02-25 19:04   ` Tero Kristo
2015-02-25 19:04 ` [PATCHv3 27/35] ARM: dts: am33xx: " Tero Kristo
2015-02-25 19:04   ` Tero Kristo
2015-02-25 19:04 ` [PATCHv3 28/35] ARM: dts: am43xx-epos-evm: fix pinmux node layout Tero Kristo
2015-02-25 19:04   ` Tero Kristo
2015-02-25 19:04 ` [PATCHv3 29/35] ARM: dts: am4372: merge control module features under scrm node Tero Kristo
2015-02-25 19:04   ` Tero Kristo
2015-02-25 19:04 ` [PATCHv3 30/35] ARM: dts: omap4: add system control module node Tero Kristo
2015-02-25 19:04   ` Tero Kristo
2015-02-25 19:04 ` [PATCHv3 31/35] ARM: OMAP4: display: convert display to use syscon for dsi muxing Tero Kristo
2015-02-25 19:04   ` Tero Kristo
2015-02-25 19:04 ` [PATCHv3 32/35] ARM: OMAP4+: control: remove support for legacy pad read/write Tero Kristo
2015-02-25 19:04   ` Tero Kristo
2015-02-25 19:04 ` [PATCHv3 33/35] ARM: dts: omap5: add system control module node Tero Kristo
2015-02-25 19:04   ` Tero Kristo
2015-02-25 19:04 ` [PATCHv3 34/35] ARM: dts: dra7: " Tero Kristo
2015-02-25 19:04   ` Tero Kristo
2015-03-11 17:17   ` Tony Lindgren
2015-03-11 17:17     ` Tony Lindgren
2015-03-11 19:08     ` Tero Kristo
2015-03-11 19:08       ` Tero Kristo
2015-03-11 19:26       ` Tony Lindgren [this message]
2015-03-11 19:26         ` Tony Lindgren
2015-03-11 19:57         ` Tero Kristo
2015-03-11 19:57           ` Tero Kristo
2015-03-11 21:00           ` Tony Lindgren
2015-03-11 21:00             ` Tony Lindgren
2015-02-25 19:04 ` [PATCHv3 35/35] ARM: OMAP4+: control: add support for initializing control module via DT Tero Kristo
2015-02-25 19:04   ` Tero Kristo

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=20150311192621.GE5264@atomide.com \
    --to=tony@atomide.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=paul@pwsan.com \
    --cc=t-kristo@ti.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 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.