linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: Kevin Hilman <khilman@baylibre.com>,
	"Jon Medhurst (Tixy)" <tixy@linaro.org>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
	linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>
Subject: Re: [PATCH v2 3/3] firmware: scpi: add device power domain support using genpd
Date: Mon, 20 Jun 2016 18:57:21 +0100	[thread overview]
Message-ID: <57682E81.20304@arm.com> (raw)
In-Reply-To: <m2inx3bvgy.fsf@baylibre.com>



On 20/06/16 18:50, Kevin Hilman wrote:
> "Jon Medhurst (Tixy)" <tixy@linaro.org> writes:
>
>> On Thu, 2016-06-16 at 18:59 +0100, Sudeep Holla wrote:
>>>
>>> On 16/06/16 18:47, Jon Medhurst (Tixy) wrote:
>>>> On Thu, 2016-06-16 at 11:38 +0100, Sudeep Holla wrote:
>>>> [...]
>>>>> +enum scpi_power_domain_state {
>>>>> +	SCPI_PD_STATE_ON = 0,
>>>>> +	SCPI_PD_STATE_OFF = 3,
>>>>> +};
>>>>
>>>> The SCPI doc defines the meaning of these numbers (0 and 3) in the 'Juno
>>>> specifics' chapter. So does these values need to come from device-tree
>>>> to allow for other hardware or SCP implementations?
>>>>
>>>
>>> Ah unfortunately true :(. I had not noticed that. But I would like to
>>> check if this can be made as part of the standard protocol. Adding such
>>> details to DT seems overkill and defeat of the whole purpose of the
>>> standard protocol.
>>
>> Well. it seems to me the 'standard protocol' is whatever the current
>> implementation of ARM's closed source SCP firmware is. It also seems to
>> me that people are making things up as they go along, without a clue as
>> to how to make things generic, robust and future proof. Basically,
>> Status Normal ARM Fucked Up.
>
> Fully agree here.  Just because ARM calls it a "standard" does not make
> it so.  As we've already seen[1], vendors are using initial/older/whatever
> versions of SCPI, so pushing the Juno version as standard just becuase
> it's in ARM's closed firmware is not the right way forward either.
>

I am not disagreeing on that. There's an on going effort to make it as
standard as PSCI. But that's still work in progress. We need to deal
with the existing variety of SCPI until then. No argument on that.

The only argument I had on the other thread is not to make the changes
too flexible that enabled the vendors to make up their own deviation of
SCPI even for their future platforms. All I am asking is to keep is less
flexible just to support existing platforms out there and not to help
the vendors to deviate further.

-- 
Regards,
Sudeep

  reply	other threads:[~2016-06-20 17:57 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-16 10:37 [PATCH v2 0/3] firmware: scpi: add device power domain support Sudeep Holla
2016-06-16 10:37 ` [PATCH v2 1/3] firmware: arm_scpi: add support for device power state management Sudeep Holla
2016-06-16 18:03   ` Jon Medhurst (Tixy)
2016-06-17  8:46     ` Sudeep Holla
2016-06-16 10:38 ` [PATCH v2 2/3] Documentation: add DT bindings for ARM SCPI power domains Sudeep Holla
2016-06-16 10:38 ` [PATCH v2 3/3] firmware: scpi: add device power domain support using genpd Sudeep Holla
2016-06-16 17:47   ` Jon Medhurst (Tixy)
2016-06-16 17:59     ` Sudeep Holla
2016-06-17  8:19       ` Jon Medhurst (Tixy)
2016-06-17  8:38         ` Sudeep Holla
2016-06-20 17:50         ` Kevin Hilman
2016-06-20 17:57           ` Sudeep Holla [this message]
2016-06-17  8:55   ` Sudeep Holla
2016-06-17  8:55     ` Sudeep Holla
2016-06-20 17:53   ` Kevin Hilman
2016-06-20 18:06     ` Sudeep Holla
2016-06-16 13:14 ` [PATCH v2 0/3] firmware: scpi: add device power domain support Jon Medhurst (Tixy)
2016-06-16 13:26   ` Sudeep Holla
2016-06-17  8:56     ` Ulf Hansson
2016-06-17 15:22 ` Mathieu Poirier
2016-06-17 15:34   ` Sudeep Holla
2016-06-20 17:56 ` Kevin Hilman
2016-06-20 18:02   ` 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=57682E81.20304@arm.com \
    --to=sudeep.holla@arm.com \
    --cc=khilman@baylibre.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=rjw@rjwysocki.net \
    --cc=suzuki.poulose@arm.com \
    --cc=tixy@linaro.org \
    --cc=ulf.hansson@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).