On Wed, May 20, 2015 at 03:29:35PM +0300, Madalin Bucur wrote:
> From: Emil Medve <emilian.me...@freescale.com>
>
> Signed-off-by: Emil Medve <emilian.me...@freescale.com>
What does "DPAA Ethernet QMan support" mean? Is it ethernet support or
qman support? In any case the subject is too long.
> +/* These stubs are required to alloc qbman drivers to determine what ranges
> of
> + * resources are available for dynamic allocation, primarily because there
> are
> + * some legacy "a priori" assumptions in certain subsystems (eg. networking)
> + * that certain resources are reserved for their use. When those drivers
> (and in
> + * some cases, their corresponding device-tree nodes) are updated to
> dynamically
> + * allocate their resources, then *all* resources can be managed by the
> + * allocators and there may be no further need to define these stubs.
I thought we were doing full dynamic resource allocation for the upstream
driver and device tree binding.
> + * - Even for memory-backed resources that are software determined (FQIDs),
> this
> + * information may only be configured and available on the control-plane
> + * partition that manages the device, so in AMP or hypervised scenarios
> there
> + * may still be need to a way to provide allocation ranges. Ie. for O/S
> + * instances that don't know how many resources are available to hardware,
> and
> + * possibly even for O/S instances that do know how many are available but
> + * that should not "own" all of them.
Partial device assignment under virtualization needs special handling for
any device; no need to have a big block comment about it here.
> + */
> +
> +&qportals {
> + qman-fqids@0 {
> + compatible = "fsl,fqid-range";
> + fsl,fqid-range = <256 256>;
> + };
> + qman-fqids@1 {
> + compatible = "fsl,fqid-range";
> + fsl,fqid-range = <32768 32768>;
> + };
> + qman-pools@0 {
> + compatible = "fsl,pool-channel-range";
> + fsl,pool-channel-range = <0x21 0xf>;
> + };
> + qman-cgrids@0 {
> + compatible = "fsl,cgrid-range";
> + fsl,cgrid-range = <0 256>;
> + };
> +};
Where is the binding for this stuff?
> +/* The comments in qoriq-dpaa-res1.dtsi apply here too so will not be
> repeated.
> + * This alternative file is to support p1023 which does not have the same
> + * resource ranges as other SoCs to date. */
Then put "p1023" in the name instead of "res2" (or if the 2 really means
something, explain).
> +/* These stubs are required to alloc qbman drivers to determine what ranges
> of
> + * resources are available for dynamic allocation, primarily because there
> are
> + * some legacy "a priori" assumptions in certain subsystems (eg. networking)
> + * that certain resources are reserved for their use. When those drivers
> (and in
> + * some cases, their corresponding device-tree nodes) are updated to
> dynamically
> + * allocate their resources, then *all* resources can be managed by the
> + * allocators and there may be no further need to define these stubs.
> + *
> + * A couple of qualifiers to the above statement though:
> + *
> + * - Some resource ranges are hardware-specific, rather than being defined by
> + * software memory allocation choices. Eg. the number of available BPIDs is
> + * baked into silicon and so will probably always need to be expressed in
> the
> + * device-tree, though in that case it will express all BPIDs, not just
> those
> + * available for dynamic allocation.
> + *
> + * - Even for memory-backed resources that are software determined (FQIDs),
> this
> + * information may only be configured and available on the control-plane
> + * partition that manages the device, so in AMP or hypervised scenarios
> there
> + * may still be need to a way to provide allocation ranges. Ie. for O/S
> + * instances that don't know how many resources are available to hardware,
> and
> + * possibly even for O/S instances that do know how many are available but
> + * that should not "own" all of them.
Why is all this repeated here?
If explanation is needed about what the nodes are here for, put it in the
binding document.
-Scott
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
