| Message ID | 1387845593-10050-3-git-send-email-sboyd@codeaurora.org |
|---|---|
| State | Accepted, archived |
| Commit | 007290cb3db0bba6a7f441b3dc849b365b0d54b1 |
| Headers | show |
On Tue, Dec 24, 2013 at 12:39:46AM +0000, Stephen Boyd wrote: > The kpss acc binding describes the clock, reset, and power domain > controller for a Krait CPU. > > Cc: <devicetree@vger.kernel.org> > Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> > --- > .../devicetree/bindings/arm/msm/qcom,kpss-acc.txt | 30 ++++++++++++++++++++++ > 1 file changed, 30 insertions(+) > create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt > > diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt > new file mode 100644 > index 0000000..1333db9 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt > @@ -0,0 +1,30 @@ > +Krait Processor Sub-system (KPSS) Application Clock Controller (ACC) > + > +The KPSS ACC provides clock, power domain, and reset control to a Krait CPU. > +There is one ACC register region per CPU within the KPSS remapped region as > +well as an alias register region that remaps accesses to the ACC associated > +with the CPU accessing the region. Is the mapping of ACC register to a specific processor well-defined? I assume it's just in order of MPIDR.Aff0. To maintain our collective sanity in the face of possible future implementations, do you have an idea as to whether this might need to be extended in future for multiple clusters / reordered IDs and so on? I assume we'd just allocate a new compatible string if those get a little crazy. > + > +PROPERTIES > + > +- compatible: > + Usage: required > + Value type: <string> > + Definition: should be one of: > + "qcom,kpss-acc-v1" > + "qcom,kpss-acc-v2" > + > +- reg: > + Usage: required > + Value type: <prop-encoded-array> > + Definition: the first element specifies the base address and size of > + the register region. An optional second element specifies > + the base address and size of the alias register region. > + > +Example: > + > + clock-controller@2088000 { > + compatible = "qcom,kpss-acc-v2"; > + reg = <0x02088000 0x1000>, > + <0x02008000 0x1000>; > + }; Otherwise, this looks fine to me. Mark. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jan 08, 2014 at 02:25:41PM +0000, Mark Rutland wrote: > On Tue, Dec 24, 2013 at 12:39:46AM +0000, Stephen Boyd wrote: > > The kpss acc binding describes the clock, reset, and power domain > > controller for a Krait CPU. > > > > Cc: <devicetree@vger.kernel.org> > > Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> > > --- > > .../devicetree/bindings/arm/msm/qcom,kpss-acc.txt | 30 ++++++++++++++++++++++ > > 1 file changed, 30 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt > > > > diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt > > new file mode 100644 > > index 0000000..1333db9 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt > > @@ -0,0 +1,30 @@ > > +Krait Processor Sub-system (KPSS) Application Clock Controller (ACC) > > + > > +The KPSS ACC provides clock, power domain, and reset control to a Krait CPU. > > +There is one ACC register region per CPU within the KPSS remapped region as > > +well as an alias register region that remaps accesses to the ACC associated > > +with the CPU accessing the region. > > Is the mapping of ACC register to a specific processor well-defined? I > assume it's just in order of MPIDR.Aff0. > > To maintain our collective sanity in the face of possible future > implementations, do you have an idea as to whether this might need to be > extended in future for multiple clusters / reordered IDs and so on? > > I assume we'd just allocate a new compatible string if those get a > little crazy. Actually, I'm getting too hung-up on future-proofing. Assuming the mapping is well-defined for current implementations we can always add an additional property later if required. Acked-by: Mark Rutland <mark.rutland@arm.com> Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/08/14 06:32, Mark Rutland wrote: > On Wed, Jan 08, 2014 at 02:25:41PM +0000, Mark Rutland wrote: >> On Tue, Dec 24, 2013 at 12:39:46AM +0000, Stephen Boyd wrote: >>> The kpss acc binding describes the clock, reset, and power domain >>> controller for a Krait CPU. >>> >>> Cc: <devicetree@vger.kernel.org> >>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> >>> --- >>> .../devicetree/bindings/arm/msm/qcom,kpss-acc.txt | 30 ++++++++++++++++++++++ >>> 1 file changed, 30 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt >>> >>> diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt >>> new file mode 100644 >>> index 0000000..1333db9 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt >>> @@ -0,0 +1,30 @@ >>> +Krait Processor Sub-system (KPSS) Application Clock Controller (ACC) >>> + >>> +The KPSS ACC provides clock, power domain, and reset control to a Krait CPU. >>> +There is one ACC register region per CPU within the KPSS remapped region as >>> +well as an alias register region that remaps accesses to the ACC associated >>> +with the CPU accessing the region. >> Is the mapping of ACC register to a specific processor well-defined? I >> assume it's just in order of MPIDR.Aff0. >> >> To maintain our collective sanity in the face of possible future >> implementations, do you have an idea as to whether this might need to be >> extended in future for multiple clusters / reordered IDs and so on? >> >> I assume we'd just allocate a new compatible string if those get a >> little crazy. > Actually, I'm getting too hung-up on future-proofing. Assuming the > mapping is well-defined for current implementations we can always add an > additional property later if required. > > Acked-by: Mark Rutland <mark.rutland@arm.com> > > Thanks Mark. As far as I know it will always be a one to one relationship. I can't predict the future though so you're suggestion seems like a good escape plan if needed.
diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt new file mode 100644 index 0000000..1333db9 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt @@ -0,0 +1,30 @@ +Krait Processor Sub-system (KPSS) Application Clock Controller (ACC) + +The KPSS ACC provides clock, power domain, and reset control to a Krait CPU. +There is one ACC register region per CPU within the KPSS remapped region as +well as an alias register region that remaps accesses to the ACC associated +with the CPU accessing the region. + +PROPERTIES + +- compatible: + Usage: required + Value type: <string> + Definition: should be one of: + "qcom,kpss-acc-v1" + "qcom,kpss-acc-v2" + +- reg: + Usage: required + Value type: <prop-encoded-array> + Definition: the first element specifies the base address and size of + the register region. An optional second element specifies + the base address and size of the alias register region. + +Example: + + clock-controller@2088000 { + compatible = "qcom,kpss-acc-v2"; + reg = <0x02088000 0x1000>, + <0x02008000 0x1000>; + };
The kpss acc binding describes the clock, reset, and power domain controller for a Krait CPU. Cc: <devicetree@vger.kernel.org> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> --- .../devicetree/bindings/arm/msm/qcom,kpss-acc.txt | 30 ++++++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt