| Message ID | 20180118222802.18161-1-ilina@codeaurora.org |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
| Series | None | expand |
On Thu, Jan 18, 2018 at 03:28:02PM -0700, Lina Iyer wrote: > From: Mahesh Sivasubramanian <msivasub@codeaurora.org> > > Command DB provides information on shared resources like clocks, > regulators etc., probed at boot by the remote subsytem and made > available in shared memory. > > Cc: devicetree@vger.kernel.org > Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org> > Signed-off-by: Lina Iyer <ilina@codeaurora.org> > --- > .../devicetree/bindings/arm/msm/cmd-db.txt | 37 ++++++++++++++++++++++ > 1 file changed, 37 insertions(+) > create mode 100644 Documentation/devicetree/bindings/arm/msm/cmd-db.txt > > diff --git a/Documentation/devicetree/bindings/arm/msm/cmd-db.txt b/Documentation/devicetree/bindings/arm/msm/cmd-db.txt > new file mode 100644 > index 000000000000..b56e3e3604d3 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/msm/cmd-db.txt > @@ -0,0 +1,37 @@ > +Command DB > +--------- Another strange QCom binding... > + > +Command DB is a database that provides a mapping between resource key and the > +resource address for a system resource managed by a remote processor. The data > +is stored in a shared memory region and is loaded by the remote processor. Is said shared memory described in DT. If so, this should be a child node. Only 8 bytes seems kind of fine grained for putting in DT when it could be implied by the parent shared memory node. > + > +Some of the Qualcomm Technologies Inc SoC's have hardware accelerators for > +controlling shared resources. Depending on the board configuration the shared > +resource properties may change. These properties are dynamically probed by the > +remote processor and made available in the shared memory. The table may change, but does the presence of it or shared memory location (of the pointer) change? > + > +Command DB allows drivers to query resource parameters based on pre-determined > +key strings. > + > +The devicetree representation of the command DB driver should be: > + > +PROPERTIES: > +- compatible: > + Usage: required > + Value type: <string> > + Definition: Should be "qcom,cmd-db" > + > +- reg: > + Usage: required > + Value type: <prop-encoded-array> > + Definition: First element is the base address of shared memory > + Second element is the size of the shared memory region > + Points to the dictionary address that houses the command DB > + start address and the size of the command DB region > + > +Example: > + > + qcom,cmd-db@c3f000c { > + compatible = "qcom,cmd-db"; > + reg = <0xc3f000c 0x8>; > + }; > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project > > -- > 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 -- 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
Thanks Rob, for taking time to review these bindings. On Mon, Jan 29 2018 at 19:08 +0000, Rob Herring wrote: >On Thu, Jan 18, 2018 at 03:28:02PM -0700, Lina Iyer wrote: >> From: Mahesh Sivasubramanian <msivasub@codeaurora.org> >> >> Command DB provides information on shared resources like clocks, >> regulators etc., probed at boot by the remote subsytem and made >> available in shared memory. >> >> Cc: devicetree@vger.kernel.org >> Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org> >> Signed-off-by: Lina Iyer <ilina@codeaurora.org> >> --- >> .../devicetree/bindings/arm/msm/cmd-db.txt | 37 ++++++++++++++++++++++ >> 1 file changed, 37 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/arm/msm/cmd-db.txt >> >> diff --git a/Documentation/devicetree/bindings/arm/msm/cmd-db.txt b/Documentation/devicetree/bindings/arm/msm/cmd-db.txt >> new file mode 100644 >> index 000000000000..b56e3e3604d3 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/arm/msm/cmd-db.txt >> @@ -0,0 +1,37 @@ >> +Command DB >> +--------- > >Another strange QCom binding... > :) >> + >> +Command DB is a database that provides a mapping between resource key and the >> +resource address for a system resource managed by a remote processor. The data >> +is stored in a shared memory region and is loaded by the remote processor. > >Is said shared memory described in DT. If so, this should be a child >node. Only 8 bytes seems kind of fine grained for putting in DT when it >could be implied by the parent shared memory node. > I dont believe this memory will be described in DT for this chipset. Will ask internally. >> + >> +Some of the Qualcomm Technologies Inc SoC's have hardware accelerators for >> +controlling shared resources. Depending on the board configuration the shared >> +resource properties may change. These properties are dynamically probed by the >> +remote processor and made available in the shared memory. > >The table may change, but does the presence of it or shared memory >location (of the pointer) change? > The location may change between different SoCs, but will be present in all chipsets of this architecture. Thanks, Lina >> + >> +Command DB allows drivers to query resource parameters based on pre-determined >> +key strings. >> + >> +The devicetree representation of the command DB driver should be: >> + >> +PROPERTIES: >> +- compatible: >> + Usage: required >> + Value type: <string> >> + Definition: Should be "qcom,cmd-db" >> + >> +- reg: >> + Usage: required >> + Value type: <prop-encoded-array> >> + Definition: First element is the base address of shared memory >> + Second element is the size of the shared memory region >> + Points to the dictionary address that houses the command DB >> + start address and the size of the command DB region >> + >> +Example: >> + >> + qcom,cmd-db@c3f000c { >> + compatible = "qcom,cmd-db"; >> + reg = <0xc3f000c 0x8>; >> + }; >> -- >> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, >> a Linux Foundation Collaborative Project >> >> -- >> 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 -- 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 Tue 30 Jan 08:17 PST 2018, Lina Iyer wrote: > On Mon, Jan 29 2018 at 19:08 +0000, Rob Herring wrote: > > On Thu, Jan 18, 2018 at 03:28:02PM -0700, Lina Iyer wrote: [..] > > > diff --git a/Documentation/devicetree/bindings/arm/msm/cmd-db.txt b/Documentation/devicetree/bindings/arm/msm/cmd-db.txt [..] > > > +Command DB is a database that provides a mapping between resource key and the > > > +resource address for a system resource managed by a remote processor. The data > > > +is stored in a shared memory region and is loaded by the remote processor. > > > > Is said shared memory described in DT. If so, this should be a child > > node. Only 8 bytes seems kind of fine grained for putting in DT when it > > could be implied by the parent shared memory node. > > > I dont believe this memory will be described in DT for this chipset. > Will ask internally. > Well, these things goes two ways... > > > + > > > +Some of the Qualcomm Technologies Inc SoC's have hardware accelerators for > > > +controlling shared resources. Depending on the board configuration the shared > > > +resource properties may change. These properties are dynamically probed by the > > > +remote processor and made available in the shared memory. > > > > The table may change, but does the presence of it or shared memory > > location (of the pointer) change? > > > The location may change between different SoCs, but will be present in > all chipsets of this architecture. > Where is the actual DB located? System RAM or is it some special device-memory? Regards, Bjorn -- 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 Mon, Feb 05 2018 at 22:11 +0000, Bjorn Andersson wrote: >On Tue 30 Jan 08:17 PST 2018, Lina Iyer wrote: >> On Mon, Jan 29 2018 at 19:08 +0000, Rob Herring wrote: >> > On Thu, Jan 18, 2018 at 03:28:02PM -0700, Lina Iyer wrote: >[..] >> > > diff --git a/Documentation/devicetree/bindings/arm/msm/cmd-db.txt b/Documentation/devicetree/bindings/arm/msm/cmd-db.txt >[..] >> > > +Command DB is a database that provides a mapping between resource key and the >> > > +resource address for a system resource managed by a remote processor. The data >> > > +is stored in a shared memory region and is loaded by the remote processor. >> > >> > Is said shared memory described in DT. If so, this should be a child >> > node. Only 8 bytes seems kind of fine grained for putting in DT when it >> > could be implied by the parent shared memory node. >> > >> I dont believe this memory will be described in DT for this chipset. >> Will ask internally. >> > >Well, these things goes two ways... > >> > > + >> > > +Some of the Qualcomm Technologies Inc SoC's have hardware accelerators for >> > > +controlling shared resources. Depending on the board configuration the shared >> > > +resource properties may change. These properties are dynamically probed by the >> > > +remote processor and made available in the shared memory. >> > >> > The table may change, but does the presence of it or shared memory >> > location (of the pointer) change? >> > >> The location may change between different SoCs, but will be present in >> all chipsets of this architecture. >> > >Where is the actual DB located? System RAM or is it some special >device-memory? > It's carved out of system memory and is access protected. Not a device memory. -- Lina -- 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 Tue 06 Feb 12:05 PST 2018, Lina Iyer wrote: > On Mon, Feb 05 2018 at 22:11 +0000, Bjorn Andersson wrote: > > On Tue 30 Jan 08:17 PST 2018, Lina Iyer wrote: > > > On Mon, Jan 29 2018 at 19:08 +0000, Rob Herring wrote: > > > > On Thu, Jan 18, 2018 at 03:28:02PM -0700, Lina Iyer wrote: > > [..] > > > > > diff --git a/Documentation/devicetree/bindings/arm/msm/cmd-db.txt b/Documentation/devicetree/bindings/arm/msm/cmd-db.txt > > [..] > > > > > +Command DB is a database that provides a mapping between resource key and the > > > > > +resource address for a system resource managed by a remote processor. The data > > > > > +is stored in a shared memory region and is loaded by the remote processor. > > > > > > > > Is said shared memory described in DT. If so, this should be a child > > > > node. Only 8 bytes seems kind of fine grained for putting in DT when it > > > > could be implied by the parent shared memory node. > > > > > > > I dont believe this memory will be described in DT for this chipset. > > > Will ask internally. > > > > > > > Well, these things goes two ways... > > > > > > > + > > > > > +Some of the Qualcomm Technologies Inc SoC's have hardware accelerators for > > > > > +controlling shared resources. Depending on the board configuration the shared > > > > > +resource properties may change. These properties are dynamically probed by the > > > > > +remote processor and made available in the shared memory. > > > > > > > > The table may change, but does the presence of it or shared memory > > > > location (of the pointer) change? > > > > > > > The location may change between different SoCs, but will be present in > > > all chipsets of this architecture. > > > > > > > Where is the actual DB located? System RAM or is it some special > > device-memory? > > > It's carved out of system memory and is access protected. Not a device > memory. > It sounds like this mimics the model we have for SMEM then, a chunk of System RAM with an address and size described in IMEM (iirc). The system integrator can move or resize SMEM by just modifying the reference in IMEM and all systems in the SoC will adapt. Except for the fact that once we reach the point in Linux where we read out the references Linux has already started using the part of System RAM that's associated with SMEM - so we must also describe it in a reserved-memory node; making the indirection useless for Linux. Note that the boot loader could still read the indirection and adjust the reserved-memory node accordingly - so it's useful from a systems perspective. If this is the case for Command DB then I suggest that we describe it as an explicit reserved-memory directly and just use that region, rather than the indirection. Regards, Bjorn -- 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
diff --git a/Documentation/devicetree/bindings/arm/msm/cmd-db.txt b/Documentation/devicetree/bindings/arm/msm/cmd-db.txt new file mode 100644 index 000000000000..b56e3e3604d3 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/cmd-db.txt @@ -0,0 +1,37 @@ +Command DB +--------- + +Command DB is a database that provides a mapping between resource key and the +resource address for a system resource managed by a remote processor. The data +is stored in a shared memory region and is loaded by the remote processor. + +Some of the Qualcomm Technologies Inc SoC's have hardware accelerators for +controlling shared resources. Depending on the board configuration the shared +resource properties may change. These properties are dynamically probed by the +remote processor and made available in the shared memory. + +Command DB allows drivers to query resource parameters based on pre-determined +key strings. + +The devicetree representation of the command DB driver should be: + +PROPERTIES: +- compatible: + Usage: required + Value type: <string> + Definition: Should be "qcom,cmd-db" + +- reg: + Usage: required + Value type: <prop-encoded-array> + Definition: First element is the base address of shared memory + Second element is the size of the shared memory region + Points to the dictionary address that houses the command DB + start address and the size of the command DB region + +Example: + + qcom,cmd-db@c3f000c { + compatible = "qcom,cmd-db"; + reg = <0xc3f000c 0x8>; + };