Re: [PATCH 3/6] Documentation: DT: Add entry for FSL Management Complex

Re: [PATCH 3/6] Documentation: DT: Add entry for FSL Management Complex

[Mark Rutland]

[devicetree-discuss is no more, fixing up to devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org]

Hi,

On Fri, Aug 15, 2014 at 10:49:12AM +0100, Bhupesh Sharma wrote:
> This patch adds a devicetree binding documentation for FSL's
> Management Complex.
> 
> Management Complex is a hardware resource manager that manages
> specialized hardware objects used in network-oriented packet
> processing applications
> 
> Signed-off-by: Bhupesh Sharma <bhupesh.sharma-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> Signed-off-by: Stuart Yoder <stuart.yoder-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> Signed-off-by: J. German Rivera <German.Rivera-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> ---
>  .../devicetree/bindings/misc/fsl,qoriq-mc.txt      |   40 ++++++++++++++++++++
>  1 file changed, 40 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> 
> diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> new file mode 100644
> index 0000000..608529e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> @@ -0,0 +1,40 @@
> +* Freescale Management Complex
> +
> +The Freescale Management Complex (fsl-mc) is a hardware resource
> +manager that manages specialized hardware objects used in
> +network-oriented packet processing applications.  After the fsl-mc
> +block is enabled, pools of hardware resources are available, such as
> +queues, buffer pools, I/O interfaces.  These resources are building
> +blocks that can be used to create functional hardware objects/devices
> +such as network interfaces, crypto accelerator instances, L2 switches,
> +etc.
> +
> +Required properties:
> +
> +    - compatible
> +        Value type: <string>
> +        Definition: Must be "fsl,qoriq-mc".  A Freescale Management Complex
> +                    compatible with this binding must have Block Revision
> +                    Registers BRR1 and BRR2 at offset 0x0BF8 and 0x0BFC in
> +                    the MC control register region.
> +
> +    - reg
> +        Value type: <prop-encoded-array>
> +        Definition: A standard property.  Specifies one or two regions
> +                    defining the MC's registers:
> +
> +                       -the first region is the command portal for the
> +                        this machine and must always be present
> +
> +                       -the second region is the MC control registers. This
> +                        region may not be present in some scenarios, such
> +                        as in the device tree presented to a virtual machine.

This looks extremely simple. Is this unit self-contained or does it
relate to other blocks which will be described separately?

> +
> +Example:
> +
> +        fsl_mc: fsl-mc@80c000000 {
> +                compatible = "fsl,qoriq-mc";
> +                reg = <0x00000008 0x0c000000 0 0x40        // MC portal base
> +                       0x00000000 0x08340000 0 0x40000 >;  // MC control reg

Nit: could we bracket list entries individually please?

Thanks,
Mark.
--
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

RE: [PATCH 3/6] Documentation: DT: Add entry for FSL Management Complex

[Stuart Yoder]

> -----Original Message-----
> From: Mark Rutland [mailto:mark.rutland@arm.com]
> Sent: Friday, August 15, 2014 6:00 AM
> To: Sharma Bhupesh-B45370
> Cc: devicetree@vger.kernel.org; Catalin Marinas; arnd@arndb.de; Rivera Jose-
> B46482; Will Deacon; Yoder Stuart-B08248; grant.likely@secretlab.ca; Basu
> Arnab-B45036; linux-arm-kernel@lists.infradead.org
> Subject: Re: [PATCH 3/6] Documentation: DT: Add entry for FSL Management
> Complex
> 
> [devicetree-discuss is no more, fixing up to devicetree@vger.kernel.org]
> 
> Hi,
> 
> On Fri, Aug 15, 2014 at 10:49:12AM +0100, Bhupesh Sharma wrote:
> > This patch adds a devicetree binding documentation for FSL's
> > Management Complex.
> >
> > Management Complex is a hardware resource manager that manages
> > specialized hardware objects used in network-oriented packet
> > processing applications
> >
> > Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com>
> > Signed-off-by: Stuart Yoder <stuart.yoder@freescale.com>
> > Signed-off-by: J. German Rivera <German.Rivera@freescale.com>
> > ---
> >  .../devicetree/bindings/misc/fsl,qoriq-mc.txt      |   40
> ++++++++++++++++++++
> >  1 file changed, 40 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> >
> > diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> > new file mode 100644
> > index 0000000..608529e
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> > @@ -0,0 +1,40 @@
> > +* Freescale Management Complex
> > +
> > +The Freescale Management Complex (fsl-mc) is a hardware resource
> > +manager that manages specialized hardware objects used in
> > +network-oriented packet processing applications.  After the fsl-mc
> > +block is enabled, pools of hardware resources are available, such as
> > +queues, buffer pools, I/O interfaces.  These resources are building
> > +blocks that can be used to create functional hardware objects/devices
> > +such as network interfaces, crypto accelerator instances, L2 switches,
> > +etc.
> > +
> > +Required properties:
> > +
> > +    - compatible
> > +        Value type: <string>
> > +        Definition: Must be "fsl,qoriq-mc".  A Freescale Management Complex
> > +                    compatible with this binding must have Block Revision
> > +                    Registers BRR1 and BRR2 at offset 0x0BF8 and 0x0BFC in
> > +                    the MC control register region.
> > +
> > +    - reg
> > +        Value type: <prop-encoded-array>
> > +        Definition: A standard property.  Specifies one or two regions
> > +                    defining the MC's registers:
> > +
> > +                       -the first region is the command portal for the
> > +                        this machine and must always be present
> > +
> > +                       -the second region is the MC control registers. This
> > +                        region may not be present in some scenarios, such
> > +                        as in the device tree presented to a virtual
> machine.
> 
> This looks extremely simple. Is this unit self-contained or does it
> relate to other blocks which will be described separately?

The block is self-contained.  It's a complicated block, but all interactions
with happen through the command interface (1st reg region).

[The MC can do DMA and thus will relate to the SMMU, but there is some
present churn around the SMMU and we'll define the needed properties
(#stream-id-cells or whatever) when that is clear.]

Stuart

Re: [PATCH 3/6] Documentation: DT: Add entry for FSL Management Complex

[Kumar Gala]

On Aug 15, 2014, at 6:00 AM, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote:

> [devicetree-discuss is no more, fixing up to devicetree-u79uwXL29TbrhsbdSgBK9A@public.gmane.orgrg]
> 
> Hi,
> 
> On Fri, Aug 15, 2014 at 10:49:12AM +0100, Bhupesh Sharma wrote:
>> This patch adds a devicetree binding documentation for FSL's
>> Management Complex.
>> 
>> Management Complex is a hardware resource manager that manages
>> specialized hardware objects used in network-oriented packet
>> processing applications
>> 
>> Signed-off-by: Bhupesh Sharma <bhupesh.sharma-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
>> Signed-off-by: Stuart Yoder <stuart.yoder-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
>> Signed-off-by: J. German Rivera <German.Rivera-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
>> ---
>> .../devicetree/bindings/misc/fsl,qoriq-mc.txt      |   40 ++++++++++++++++++++

I’d probably start this off in bindings/soc/fsl/

>> 1 file changed, 40 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
>> 
>> diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
>> new file mode 100644
>> index 0000000..608529e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
>> @@ -0,0 +1,40 @@
>> +* Freescale Management Complex
>> +
>> +The Freescale Management Complex (fsl-mc) is a hardware resource
>> +manager that manages specialized hardware objects used in
>> +network-oriented packet processing applications.  After the fsl-mc
>> +block is enabled, pools of hardware resources are available, such as
>> +queues, buffer pools, I/O interfaces.  These resources are building
>> +blocks that can be used to create functional hardware objects/devices
>> +such as network interfaces, crypto accelerator instances, L2 switches,
>> +etc.
>> +
>> +Required properties:
>> +
>> +    - compatible
>> +        Value type: <string>
>> +        Definition: Must be "fsl,qoriq-mc".  A Freescale Management Complex
>> +                    compatible with this binding must have Block Revision
>> +                    Registers BRR1 and BRR2 at offset 0x0BF8 and 0x0BFC in
>> +                    the MC control register region.

Hmm, this BRR1/BRR2 comments are a little odd, if we keep those, we should probably
also state what value is BRR1 (I think that was the one that contented the IP ID).

>> +
>> +    - reg
>> +        Value type: <prop-encoded-array>
>> +        Definition: A standard property.  Specifies one or two regions
>> +                    defining the MC's registers:
>> +
>> +                       -the first region is the command portal for the
>> +                        this machine and must always be present
>> +
>> +                       -the second region is the MC control registers. This
>> +                        region may not be present in some scenarios, such
>> +                        as in the device tree presented to a virtual machine.

Should we distinguish the second case w/a different compat?  It seems like a major driver change if the second region isn’t there, or a different driver?

> 
> This looks extremely simple. Is this unit self-contained or does it
> relate to other blocks which will be described separately?
> 
>> +
>> +Example:
>> +
>> +        fsl_mc: fsl-mc@80c000000 {
>> +                compatible = "fsl,qoriq-mc";
>> +                reg = <0x00000008 0x0c000000 0 0x40        // MC portal base
>> +                       0x00000000 0x08340000 0 0x40000 >;  // MC control reg
> 
> Nit: could we bracket list entries individually please?
> 
> Thanks,
> Mark.
> 
> _______________________________________________

- k

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

--
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

RE: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC

[Stuart Yoder]

> -----Original Message-----
> From: Kumar Gala [mailto:galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org]
> Sent: Friday, August 15, 2014 10:26 AM
> To: Basu Arnab-B45036
> Cc: Mark Rutland; Sharma Bhupesh-B45370; arnd-r2nGTMty4D4@public.gmane.org; Catalin Marinas;
> devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org; Will Deacon; Yoder Stuart-B08248;
> grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC
> 
> 
> On Aug 15, 2014, at 10:21 AM, arnab.basu-KZfg59tc24xl57MIdRCFDg@public.gmane.org wrote:
> 
> >>>
> >>> +	cpus {
> >>> +		#address-cells = <2>;
> >>> +		#size-cells = <0>;
> >>> +
> >>> +		/* We have 4 clusters having 2 Cortex-A57 cores each */
> >>> +		cpu@0 {
> >>> +			device_type = "cpu";
> >>> +			compatible = "arm,cortex-a57";
> >>> +			reg = <0x0 0x0>;
> >>> +			enable-method = "spin-table";
> >>> +			cpu-release-addr = <0x0 0x8000fff8>;
> >>> +		};
> >>
> >> I would strongly recommend having a unique cpu-release-addr for each CPU.
> >>
> >
> > This is more of a place holder, we intend to patch this address from U-Boot
> > and use individual release addresses for each CPU.
> 
> If you are going to patch it in u-boot, than why not just have u-boot add the
> property and drop it from here.
> 
> If you intend to keep it here, than make <0x0 0x0> and add a comment that says
> u-boot will fill it out

As I said to Mark re: the comment on having different release addresses
per CPU, we are just following existing practice from the existing
arch/arm64 device trees:
   apm-storm.dtsi
   foundation-v8.dts
   rtsm_ve-aemv8a.dts

I think one of the reasons the cpu-release-addr is not 0x0 is that 
UEFI had(?)/has(?) limited ability to do device tree fix ups.  It's
not a problem at all in u-boot, but there is some reason all
existing device trees have the same hardcoded address for all
CPUs.

So we want to do the standard/conventional thing here that will
allow are device trees to be used in more than u-boot.

Thanks,
Stuart


--
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

Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC

[Kumar Gala]

On Aug 15, 2014, at 10:41 AM, Stuart Yoder <stuart.yoder-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:

> 
> 
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org]
>> Sent: Friday, August 15, 2014 10:26 AM
>> To: Basu Arnab-B45036
>> Cc: Mark Rutland; Sharma Bhupesh-B45370; arnd-r2nGTMty4D4@public.gmane.org; Catalin Marinas;
>> devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org; Will Deacon; Yoder Stuart-B08248;
>> grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>> Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC
>> 
>> 
>> On Aug 15, 2014, at 10:21 AM, arnab.basu-KZfg59tc24xl57MIdRCFDg@public.gmane.org wrote:
>> 
>>>>> 
>>>>> +	cpus {
>>>>> +		#address-cells = <2>;
>>>>> +		#size-cells = <0>;
>>>>> +
>>>>> +		/* We have 4 clusters having 2 Cortex-A57 cores each */
>>>>> +		cpu@0 {
>>>>> +			device_type = "cpu";
>>>>> +			compatible = "arm,cortex-a57";
>>>>> +			reg = <0x0 0x0>;
>>>>> +			enable-method = "spin-table";
>>>>> +			cpu-release-addr = <0x0 0x8000fff8>;
>>>>> +		};
>>>> 
>>>> I would strongly recommend having a unique cpu-release-addr for each CPU.
>>>> 
>>> 
>>> This is more of a place holder, we intend to patch this address from U-Boot
>>> and use individual release addresses for each CPU.
>> 
>> If you are going to patch it in u-boot, than why not just have u-boot add the
>> property and drop it from here.
>> 
>> If you intend to keep it here, than make <0x0 0x0> and add a comment that says
>> u-boot will fill it out
> 
> As I said to Mark re: the comment on having different release addresses
> per CPU, we are just following existing practice from the existing
> arch/arm64 device trees:
>   apm-storm.dtsi
>   foundation-v8.dts
>   rtsm_ve-aemv8a.dts
> 
> I think one of the reasons the cpu-release-addr is not 0x0 is that 
> UEFI had(?)/has(?) limited ability to do device tree fix ups.  It's
> not a problem at all in u-boot, but there is some reason all
> existing device trees have the same hardcoded address for all
> CPUs.

Are you guys planning on supporting UEFI on this platform?

> So we want to do the standard/conventional thing here that will
> allow are device trees to be used in more than u-boot.

Well, I think the guys would say the standard thing is to move to PSCI.

- k

> 
> Thanks,
> Stuart
> 
> 
> --
> 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

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

--
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

RE: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC

[Stuart Yoder]

> -----Original Message-----
> From: Kumar Gala [mailto:galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org]
> Sent: Friday, August 15, 2014 10:44 AM
> To: Yoder Stuart-B08248
> Cc: Basu Arnab-B45036; Mark Rutland; Sharma Bhupesh-B45370; arnd-r2nGTMty4D4@public.gmane.org;
> Catalin Marinas; Will Deacon; grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org; linux-arm-
> kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC
> 
> 
> On Aug 15, 2014, at 10:41 AM, Stuart Yoder <stuart.yoder-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> 
> >
> >
> >> -----Original Message-----
> >> From: Kumar Gala [mailto:galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org]
> >> Sent: Friday, August 15, 2014 10:26 AM
> >> To: Basu Arnab-B45036
> >> Cc: Mark Rutland; Sharma Bhupesh-B45370; arnd-r2nGTMty4D4@public.gmane.org; Catalin Marinas;
> >> devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org; Will Deacon; Yoder Stuart-B08248;
> >> grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> >> Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC
> >>
> >>
> >> On Aug 15, 2014, at 10:21 AM, arnab.basu-KZfg59tc24xl57MIdRCFDg@public.gmane.org wrote:
> >>
> >>>>>
> >>>>> +	cpus {
> >>>>> +		#address-cells = <2>;
> >>>>> +		#size-cells = <0>;
> >>>>> +
> >>>>> +		/* We have 4 clusters having 2 Cortex-A57 cores each */
> >>>>> +		cpu@0 {
> >>>>> +			device_type = "cpu";
> >>>>> +			compatible = "arm,cortex-a57";
> >>>>> +			reg = <0x0 0x0>;
> >>>>> +			enable-method = "spin-table";
> >>>>> +			cpu-release-addr = <0x0 0x8000fff8>;
> >>>>> +		};
> >>>>
> >>>> I would strongly recommend having a unique cpu-release-addr for each CPU.
> >>>>
> >>>
> >>> This is more of a place holder, we intend to patch this address from U-Boot
> >>> and use individual release addresses for each CPU.
> >>
> >> If you are going to patch it in u-boot, than why not just have u-boot add
> the
> >> property and drop it from here.
> >>
> >> If you intend to keep it here, than make <0x0 0x0> and add a comment that
> says
> >> u-boot will fill it out
> >
> > As I said to Mark re: the comment on having different release addresses
> > per CPU, we are just following existing practice from the existing
> > arch/arm64 device trees:
> >   apm-storm.dtsi
> >   foundation-v8.dts
> >   rtsm_ve-aemv8a.dts
> >
> > I think one of the reasons the cpu-release-addr is not 0x0 is that
> > UEFI had(?)/has(?) limited ability to do device tree fix ups.  It's
> > not a problem at all in u-boot, but there is some reason all
> > existing device trees have the same hardcoded address for all
> > CPUs.
> 
> Are you guys planning on supporting UEFI on this platform?

Yes.

> > So we want to do the standard/conventional thing here that will
> > allow are device trees to be used in more than u-boot.
> 
> Well, I think the guys would say the standard thing is to move to PSCI.

Agree.  That is our plan.  But it looks like at this point in
time all the device tree have a common denominator spin table
mechanim that gets updated/overriden if PSCI is supported.

Stuart
--
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

Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC

[Catalin Marinas]

On Fri, Aug 15, 2014 at 04:49:53PM +0100, Stuart Yoder wrote:
> > On Aug 15, 2014, at 10:41 AM, Stuart Yoder <stuart.yoder-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > So we want to do the standard/conventional thing here that will
> > > allow are device trees to be used in more than u-boot.
> > 
> > Well, I think the guys would say the standard thing is to move to PSCI.
> 
> Agree.  That is our plan.  But it looks like at this point in
> time all the device tree have a common denominator spin table
> mechanim that gets updated/overriden if PSCI is supported.

That's for historical reasons because at the time there was no PSCI and
now we have to preserve backwards compatibility with older boot
wrappers. The only hardware currently having a DT in the arm64 tree is
the APM one which cannot implement PSCI because there is no EL3.

(and I think we should really get a proper arm64 PSCI implementation in
U-Boot)

-- 
Catalin
--
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