[PATCH 2/2] dt-bindings: introduce Command DB for QCOM SoCs

[PATCH 2/2] dt-bindings: introduce Command DB for QCOM SoCs

[Lina Iyer]

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
+---------
+
+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>;
+	};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 2/2] dt-bindings: introduce Command DB for QCOM SoCs

[Rob Herring]

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

Re: [PATCH 2/2] dt-bindings: introduce Command DB for QCOM SoCs

[Lina Iyer]

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

Re: [PATCH 2/2] dt-bindings: introduce Command DB for QCOM SoCs

[Bjorn Andersson]

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

Re: [PATCH 2/2] dt-bindings: introduce Command DB for QCOM SoCs

[Lina Iyer]

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] dt-bindings: introduce Command DB for QCOM SoCs

[Bjorn Andersson]

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html