All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
To: Liberman Igal-B31950
	<Igal.Liberman-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Cc: "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org"
	<linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>,
	Tang Yuantian-B29983
	<Yuantian.Tang-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Subject: Re: [v3] dt/bindings: qoriq-clock: Add binding for FMan clock mux
Date: Tue, 5 May 2015 16:16:33 -0500	[thread overview]
Message-ID: <1430860593.16357.269.camel@freescale.com> (raw)
In-Reply-To: <BY2PR03MB3794413FB3FF795DF520D23E6D10-+7O3WWA3DPtn35zppGJRk+O6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>

On Tue, 2015-05-05 at 16:02 -0500, Liberman Igal-B31950 wrote:
> 
> 
> Regards,
> Igal Liberman.
> 
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Saturday, May 02, 2015 2:43 AM
> > To: Liberman Igal-B31950
> > Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org; Tang
> > Yuantian-B29983
> > Subject: Re: [v3] dt/bindings: qoriq-clock: Add binding for FMan clock mux
> > 
> > On Thu, 2015-04-30 at 09:28 -0500, Liberman Igal-B31950 wrote:
> > > > -----Original Message-----
> > > > From: Wood Scott-B07421
> > > > Sent: Thursday, April 30, 2015 3:31 AM
> > > > To: Liberman Igal-B31950
> > > > Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org; Tang
> > > > Yuantian-B29983
> > > > Subject: Re: [v3] dt/bindings: qoriq-clock: Add binding for FMan
> > > > clock mux
> > > >
> > > > On Wed, 2015-04-22 at 05:47 -0500, Liberman Igal-B31950 wrote:
> > > > > We have 2 cases:
> > > > > 	- Devices (T2/T4/B4) with CLKCG1HWACSR register.
> > > > > 	- Devices (Pxxxx, T1) without CLKCG1HWACSR register (Pxxxx
> > > > devices
> > > > > have many options, T1 has only one option)
> > > > >
> > > > > For the first group, we can have " qoriq-hwacsr" property in the clock
> > node.
> > > >
> > > > No, we're not going to describe every register with its own property.
> > > > Describe the chip and let the driver be the place with the knowledge
> > > > of what each chip is like.
> > > >
> > >
> > > I think that FMan clock mux (as we defined it) is similar to other muxes
> > available in our SoC.
> > 
> > I realize that.  I'm saying the way we described existing muxes seems to be a
> > mistake.  We're putting too much complexity in the device tree.
> > Better to put the complexity in a place that isn't stable ABI.
> > 
> > > If we take T4 as example, it has 3 muxes defined in the device tree (mux0,
> > mux1 and mux2).
> > > Each mux has its own reg property (and clock providers).
> > > 	mux2: mux2@40 {
> > > 		#clock-cells = <0>;
> > > 		reg = <0x40 0x4>;
> > > 		compatible = "fsl,qoriq-core-mux-2.0";
> > > 		clocks = <&pll3 0>, <&pll3 1>, <&pll3 2>,
> > > 			<&pll4 0>, <&pll4 1>, <&pll4 2>;
> > > 		clock-names = "pll3", "pll3-div2", "pll3-div4",
> > > 			"pll4", "pll4-div2", "pll4-div4";
> > > 		clock-output-names = "cmux2";
> > > 	};
> > >
> > > I agree that "fm1-clk-mux" need to be moved from the "guts" node to
> > "clockgen" node.
> > 
> > That's not what I was saying.  I'm saying get rid of the node entirely, in favor
> > of having the clockgen node itself be a clock source with multiple post-mux
> > outputs.
> > 
> 
> Scott,
> Currently the clockgen node has a number of sub nodes (platform clock, sysclock, PLLs and muxes, the number of muxes/PLLs is SoC dependent).
> The clockgen node has reg property, however, all other nodes have reg property too (The clockgen points to the clocking block address and the sub nodes point to the specific register in the clock block).
> Do you want to change this structure completely?

Yes, I want to change it completely (while ensuring the kernel still
works, albeit without new functionality, with older device trees).

> I'm not sure I understand the exact way you want see those nodes (in the final state).

Something like:

clockgen: global-utilities@e1000 {
	compatible = "fsl,<whatever>-clockgen";
	clock-frequency = <...>;
	reg = <0xe1000 0x1000>;
	#clock-cells = <2>;
};

cpu0: PowerPC,e6500@0 {
	device_type = "cpu";
	reg = <0 1>;
	clocks = <&clockgen 0 0>;
	next-level-cache = <&L2_1>;
	fsl,portid-mapping = <0x80000000>;
};


cpu4: PowerPC,e6500@0 {
	device_type = "cpu";
	reg = <4 5>;
	clocks = <&clockgen 0 1>;
	next-level-cache = <&L2_1>;
	fsl,portid-mapping = <0x80000000>;
};

fman@... {
	...
	clocks = <&clockgen 1 0>;
	...
};

...with the clockgen binding explaining the format of the clock
specifier, and the clockgen driver containing the chip-specific muxing
details.

-Scott


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Scott Wood <scottwood@freescale.com>
To: Liberman Igal-B31950 <Igal.Liberman@freescale.com>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	Tang Yuantian-B29983 <Yuantian.Tang@freescale.com>
Subject: Re: [v3] dt/bindings: qoriq-clock: Add binding for FMan clock mux
Date: Tue, 5 May 2015 16:16:33 -0500	[thread overview]
Message-ID: <1430860593.16357.269.camel@freescale.com> (raw)
In-Reply-To: <BY2PR03MB3794413FB3FF795DF520D23E6D10@BY2PR03MB379.namprd03.prod.outlook.com>

On Tue, 2015-05-05 at 16:02 -0500, Liberman Igal-B31950 wrote:
> 
> 
> Regards,
> Igal Liberman.
> 
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Saturday, May 02, 2015 2:43 AM
> > To: Liberman Igal-B31950
> > Cc: devicetree@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Tang
> > Yuantian-B29983
> > Subject: Re: [v3] dt/bindings: qoriq-clock: Add binding for FMan clock mux
> > 
> > On Thu, 2015-04-30 at 09:28 -0500, Liberman Igal-B31950 wrote:
> > > > -----Original Message-----
> > > > From: Wood Scott-B07421
> > > > Sent: Thursday, April 30, 2015 3:31 AM
> > > > To: Liberman Igal-B31950
> > > > Cc: devicetree@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Tang
> > > > Yuantian-B29983
> > > > Subject: Re: [v3] dt/bindings: qoriq-clock: Add binding for FMan
> > > > clock mux
> > > >
> > > > On Wed, 2015-04-22 at 05:47 -0500, Liberman Igal-B31950 wrote:
> > > > > We have 2 cases:
> > > > > 	- Devices (T2/T4/B4) with CLKCG1HWACSR register.
> > > > > 	- Devices (Pxxxx, T1) without CLKCG1HWACSR register (Pxxxx
> > > > devices
> > > > > have many options, T1 has only one option)
> > > > >
> > > > > For the first group, we can have " qoriq-hwacsr" property in the clock
> > node.
> > > >
> > > > No, we're not going to describe every register with its own property.
> > > > Describe the chip and let the driver be the place with the knowledge
> > > > of what each chip is like.
> > > >
> > >
> > > I think that FMan clock mux (as we defined it) is similar to other muxes
> > available in our SoC.
> > 
> > I realize that.  I'm saying the way we described existing muxes seems to be a
> > mistake.  We're putting too much complexity in the device tree.
> > Better to put the complexity in a place that isn't stable ABI.
> > 
> > > If we take T4 as example, it has 3 muxes defined in the device tree (mux0,
> > mux1 and mux2).
> > > Each mux has its own reg property (and clock providers).
> > > 	mux2: mux2@40 {
> > > 		#clock-cells = <0>;
> > > 		reg = <0x40 0x4>;
> > > 		compatible = "fsl,qoriq-core-mux-2.0";
> > > 		clocks = <&pll3 0>, <&pll3 1>, <&pll3 2>,
> > > 			<&pll4 0>, <&pll4 1>, <&pll4 2>;
> > > 		clock-names = "pll3", "pll3-div2", "pll3-div4",
> > > 			"pll4", "pll4-div2", "pll4-div4";
> > > 		clock-output-names = "cmux2";
> > > 	};
> > >
> > > I agree that "fm1-clk-mux" need to be moved from the "guts" node to
> > "clockgen" node.
> > 
> > That's not what I was saying.  I'm saying get rid of the node entirely, in favor
> > of having the clockgen node itself be a clock source with multiple post-mux
> > outputs.
> > 
> 
> Scott,
> Currently the clockgen node has a number of sub nodes (platform clock, sysclock, PLLs and muxes, the number of muxes/PLLs is SoC dependent).
> The clockgen node has reg property, however, all other nodes have reg property too (The clockgen points to the clocking block address and the sub nodes point to the specific register in the clock block).
> Do you want to change this structure completely?

Yes, I want to change it completely (while ensuring the kernel still
works, albeit without new functionality, with older device trees).

> I'm not sure I understand the exact way you want see those nodes (in the final state).

Something like:

clockgen: global-utilities@e1000 {
	compatible = "fsl,<whatever>-clockgen";
	clock-frequency = <...>;
	reg = <0xe1000 0x1000>;
	#clock-cells = <2>;
};

cpu0: PowerPC,e6500@0 {
	device_type = "cpu";
	reg = <0 1>;
	clocks = <&clockgen 0 0>;
	next-level-cache = <&L2_1>;
	fsl,portid-mapping = <0x80000000>;
};


cpu4: PowerPC,e6500@0 {
	device_type = "cpu";
	reg = <4 5>;
	clocks = <&clockgen 0 1>;
	next-level-cache = <&L2_1>;
	fsl,portid-mapping = <0x80000000>;
};

fman@... {
	...
	clocks = <&clockgen 1 0>;
	...
};

...with the clockgen binding explaining the format of the clock
specifier, and the clockgen driver containing the chip-specific muxing
details.

-Scott

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

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-14 10:56 [v3] dt/bindings: qoriq-clock: Add binding for FMan clock mux Igal.Liberman
2015-04-14 10:56 ` Igal.Liberman
2015-04-15 17:35 ` Scott Wood
2015-04-15 17:35   ` Scott Wood
     [not found]   ` <1429119357.22867.724.camel-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2015-04-16  6:11     ` Igal.Liberman-KZfg59tc24xl57MIdRCFDg
2015-04-16  6:11       ` Igal.Liberman
     [not found]       ` <DM2PR03MB38330DBBFFD1BC45D58F447E6E40-ufbTtyGzTTRJonC5hhDUuuO6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
2015-04-17  5:41         ` Scott Wood
2015-04-17  5:41           ` Scott Wood
     [not found]           ` <1429249281.32545.52.camel-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2015-04-20 11:07             ` Igal.Liberman-KZfg59tc24xl57MIdRCFDg
2015-04-20 11:07               ` Igal.Liberman
2015-04-20 11:40           ` Igal.Liberman-KZfg59tc24xl57MIdRCFDg
2015-04-20 11:40             ` Igal.Liberman
     [not found]             ` <DM2PR03MB383E5F67C358CCE2E38EA71E6E00-ufbTtyGzTTRJonC5hhDUuuO6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
2015-04-21  0:51               ` Scott Wood
2015-04-21  0:51                 ` Scott Wood
     [not found]                 ` <1429577504.4352.67.camel-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2015-04-22 10:47                   ` Igal.Liberman-KZfg59tc24xl57MIdRCFDg
2015-04-22 10:47                     ` Igal.Liberman
     [not found]                     ` <DM2PR03MB383C35FA5959662DD48D00BE6EE0-ufbTtyGzTTRJonC5hhDUuuO6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
2015-04-30  0:30                       ` Scott Wood
2015-04-30  0:30                         ` Scott Wood
     [not found]                         ` <1430353832.16357.138.camel-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2015-04-30 14:28                           ` Igal.Liberman-KZfg59tc24xl57MIdRCFDg
2015-04-30 14:28                             ` Igal.Liberman
     [not found]                             ` <DM2PR03MB3839C9D3FDFD7978C1A3497E6D60-ufbTtyGzTTRJonC5hhDUuuO6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
2015-05-01 23:42                               ` Scott Wood
2015-05-01 23:42                                 ` Scott Wood
     [not found]                                 ` <1430523775.16357.177.camel-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2015-05-05 21:02                                   ` Igal.Liberman-KZfg59tc24xl57MIdRCFDg
2015-05-05 21:02                                     ` Igal.Liberman
     [not found]                                     ` <BY2PR03MB3794413FB3FF795DF520D23E6D10-+7O3WWA3DPtn35zppGJRk+O6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
2015-05-05 21:16                                       ` Scott Wood [this message]
2015-05-05 21:16                                         ` Scott Wood

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=1430860593.16357.269.camel@freescale.com \
    --to=scottwood-kzfg59tc24xl57midrcfdg@public.gmane.org \
    --cc=Igal.Liberman-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
    --cc=Yuantian.Tang-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.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.