Re: [PATCH v2 3/3] firmware: scpi: add device power domain support using genpd

[Sudeep Holla]

On 20/06/16 18:50, Kevin Hilman wrote:
> "Jon Medhurst (Tixy)" <tixy@xxxxxxxxxx> 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