All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
	linux-kernel@vger.kernel.org, Jon Medhurst <tixy@linaro.org>,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Rob Herring <robh+dt@kernel.org>,
	linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org
Subject: Re: [PATCH 2/3] Documentation: add DT bindings for ARM SCPI power domains
Date: Tue, 7 Jun 2016 14:39:25 +0100	[thread overview]
Message-ID: <5756CE8D.6040704@arm.com> (raw)
In-Reply-To: <20160607132223.GG2633@leverpostej>



On 07/06/16 14:22, Mark Rutland wrote:
> On Mon, Jun 06, 2016 at 04:53:58PM +0100, Sudeep Holla wrote:
>> The System Control Processor (SCP) provides peripheral devices with
>> power domains that can be enabled and disabled viathe System Control
>> and Power Interface (SCPI) Message Protocol. Add bindings to allow
>> probing of these device power domians.
>>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: devicetree@vger.kernel.org
>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>> ---
>>   Documentation/devicetree/bindings/arm/arm,scpi.txt | 34 ++++++++++++++++++++++
>>   1 file changed, 34 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> index 313dabdc14f9..7141670d649b 100644
>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> @@ -87,10 +87,33 @@ SCPI provides an API to access the various sensors on the SoC.
>>   			 implementation for the IDs to use. For Juno
>>   			 R0 and Juno R1 refer to [3].
>>
>> +Power domain bindings for the power domains based on SCPI Message Protocol
>> +------------------------------------------------------------
>> +
>> +This binding uses the generic power domain binding[4].
>> +
>> +PM domain providers
>> +===================
>> +
>> +Required properties:
>> + - #power-domain-cells : Should be 1. Contains the device or the power
>> +			 domain ID value used by SCPI commands.
>> + - num-domains: Total number of power domains provided by SCPI. This is
>> +		needed as the SCPI message protocol lacks a mechanism to
>> +		query this information runtime.
>                                        ^
> I guess there should be an 'at' here.
>

Will fix.

> Are domain IDs zero-based and definitely non-sparse?
>

Yes

> What exactly does this matter for? Just for validation at parsing time,
> or is this strictly required for correctness?
>

This is mainly to know the maximum number of power domains that firmware
supports. This will help the software handling the provider part to
setup the information in advance before any consumer request for the
service.

> If we send a command with an invalid domain ID, would the FW reliably
> report an error that we can recover from?
>

Yes for anything above this value, firmware returns invalid parameter
error. It's would be good to have that as a separate command instead
of getting it via DT. We already have that for OPPs and clocks. Just
this lacks that feature.

> Otherwise, this looks ok. I'd just like to make sure I've understood
> correctly.
>

Sure, thanks for the review.

-- 
Regards,
Sudeep

WARNING: multiple messages have this Message-ID (diff)
From: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
To: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Jon Medhurst <tixy-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Mathieu Poirier
	<mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Suzuki K Poulose <suzuki.poulose-5wv7dgnIgG8@public.gmane.org>,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 2/3] Documentation: add DT bindings for ARM SCPI power domains
Date: Tue, 7 Jun 2016 14:39:25 +0100	[thread overview]
Message-ID: <5756CE8D.6040704@arm.com> (raw)
In-Reply-To: <20160607132223.GG2633@leverpostej>



On 07/06/16 14:22, Mark Rutland wrote:
> On Mon, Jun 06, 2016 at 04:53:58PM +0100, Sudeep Holla wrote:
>> The System Control Processor (SCP) provides peripheral devices with
>> power domains that can be enabled and disabled viathe System Control
>> and Power Interface (SCPI) Message Protocol. Add bindings to allow
>> probing of these device power domians.
>>
>> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
>> Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
>> ---
>>   Documentation/devicetree/bindings/arm/arm,scpi.txt | 34 ++++++++++++++++++++++
>>   1 file changed, 34 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> index 313dabdc14f9..7141670d649b 100644
>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> @@ -87,10 +87,33 @@ SCPI provides an API to access the various sensors on the SoC.
>>   			 implementation for the IDs to use. For Juno
>>   			 R0 and Juno R1 refer to [3].
>>
>> +Power domain bindings for the power domains based on SCPI Message Protocol
>> +------------------------------------------------------------
>> +
>> +This binding uses the generic power domain binding[4].
>> +
>> +PM domain providers
>> +===================
>> +
>> +Required properties:
>> + - #power-domain-cells : Should be 1. Contains the device or the power
>> +			 domain ID value used by SCPI commands.
>> + - num-domains: Total number of power domains provided by SCPI. This is
>> +		needed as the SCPI message protocol lacks a mechanism to
>> +		query this information runtime.
>                                        ^
> I guess there should be an 'at' here.
>

Will fix.

> Are domain IDs zero-based and definitely non-sparse?
>

Yes

> What exactly does this matter for? Just for validation at parsing time,
> or is this strictly required for correctness?
>

This is mainly to know the maximum number of power domains that firmware
supports. This will help the software handling the provider part to
setup the information in advance before any consumer request for the
service.

> If we send a command with an invalid domain ID, would the FW reliably
> report an error that we can recover from?
>

Yes for anything above this value, firmware returns invalid parameter
error. It's would be good to have that as a separate command instead
of getting it via DT. We already have that for OPPs and clocks. Just
this lacks that feature.

> Otherwise, this looks ok. I'd just like to make sure I've understood
> correctly.
>

Sure, thanks for the review.

-- 
Regards,
Sudeep
--
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

WARNING: multiple messages have this Message-ID (diff)
From: sudeep.holla@arm.com (Sudeep Holla)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/3] Documentation: add DT bindings for ARM SCPI power domains
Date: Tue, 7 Jun 2016 14:39:25 +0100	[thread overview]
Message-ID: <5756CE8D.6040704@arm.com> (raw)
In-Reply-To: <20160607132223.GG2633@leverpostej>



On 07/06/16 14:22, Mark Rutland wrote:
> On Mon, Jun 06, 2016 at 04:53:58PM +0100, Sudeep Holla wrote:
>> The System Control Processor (SCP) provides peripheral devices with
>> power domains that can be enabled and disabled viathe System Control
>> and Power Interface (SCPI) Message Protocol. Add bindings to allow
>> probing of these device power domians.
>>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: devicetree at vger.kernel.org
>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>> ---
>>   Documentation/devicetree/bindings/arm/arm,scpi.txt | 34 ++++++++++++++++++++++
>>   1 file changed, 34 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> index 313dabdc14f9..7141670d649b 100644
>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> @@ -87,10 +87,33 @@ SCPI provides an API to access the various sensors on the SoC.
>>   			 implementation for the IDs to use. For Juno
>>   			 R0 and Juno R1 refer to [3].
>>
>> +Power domain bindings for the power domains based on SCPI Message Protocol
>> +------------------------------------------------------------
>> +
>> +This binding uses the generic power domain binding[4].
>> +
>> +PM domain providers
>> +===================
>> +
>> +Required properties:
>> + - #power-domain-cells : Should be 1. Contains the device or the power
>> +			 domain ID value used by SCPI commands.
>> + - num-domains: Total number of power domains provided by SCPI. This is
>> +		needed as the SCPI message protocol lacks a mechanism to
>> +		query this information runtime.
>                                        ^
> I guess there should be an 'at' here.
>

Will fix.

> Are domain IDs zero-based and definitely non-sparse?
>

Yes

> What exactly does this matter for? Just for validation at parsing time,
> or is this strictly required for correctness?
>

This is mainly to know the maximum number of power domains that firmware
supports. This will help the software handling the provider part to
setup the information in advance before any consumer request for the
service.

> If we send a command with an invalid domain ID, would the FW reliably
> report an error that we can recover from?
>

Yes for anything above this value, firmware returns invalid parameter
error. It's would be good to have that as a separate command instead
of getting it via DT. We already have that for OPPs and clocks. Just
this lacks that feature.

> Otherwise, this looks ok. I'd just like to make sure I've understood
> correctly.
>

Sure, thanks for the review.

-- 
Regards,
Sudeep

  reply	other threads:[~2016-06-07 13:39 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-06 15:53 [PATCH 0/3] firmware: scpi: add device power domain support Sudeep Holla
2016-06-06 15:53 ` [PATCH 1/3] firmware: arm_scpi: add support for device power state management Sudeep Holla
2016-06-06 15:53   ` Sudeep Holla
2016-06-07 12:58   ` Jon Medhurst (Tixy)
2016-06-07 12:58     ` Jon Medhurst (Tixy)
2016-06-07 13:00     ` Sudeep Holla
2016-06-07 13:00       ` Sudeep Holla
2016-06-06 15:53 ` [PATCH 2/3] Documentation: add DT bindings for ARM SCPI power domains Sudeep Holla
2016-06-06 15:53   ` Sudeep Holla
2016-06-06 15:53   ` Sudeep Holla
2016-06-07 13:22   ` Mark Rutland
2016-06-07 13:22     ` Mark Rutland
2016-06-07 13:39     ` Sudeep Holla [this message]
2016-06-07 13:39       ` Sudeep Holla
2016-06-07 13:39       ` Sudeep Holla
2016-06-07 14:45       ` Mark Rutland
2016-06-07 14:45         ` Mark Rutland
2016-06-07 14:45         ` Mark Rutland
2016-06-06 15:53 ` [PATCH 3/3] firmware: scpi: add device power domain support using genpd Sudeep Holla
2016-06-07 13:18   ` Jon Medhurst (Tixy)
2016-06-07 13:29     ` Sudeep Holla
2016-06-10 16:19   ` Sudeep Holla
2016-06-15 13:05   ` Ulf Hansson
2016-06-15 13:23     ` Sudeep Holla
2016-06-15 13:29       ` Ulf Hansson
2016-06-15 13:44         ` Sudeep Holla

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5756CE8D.6040704@arm.com \
    --to=sudeep.holla@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mathieu.poirier@linaro.org \
    --cc=robh+dt@kernel.org \
    --cc=suzuki.poulose@arm.com \
    --cc=tixy@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.