From: sudeep.holla@arm.com (Sudeep Holla)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 0/2] scpi: Add SCPI framework to handle vendors variants
Date: Mon, 20 Jun 2016 16:01:11 +0100 [thread overview]
Message-ID: <57680537.1080009@arm.com> (raw)
In-Reply-To: <5767C492.60201@baylibre.com>
On 20/06/16 11:25, Neil Armstrong wrote:
> On 06/06/2016 07:10 PM, Sudeep Holla wrote:
[...]
>>
>> Though this initial version of SCPI is not published, I am sure it is
>> almost same as v1.0 except that the CMD is not part of payload like
>> v1.0. In v1.0 it's part of payload and the mailbox is used just for
>> doorbell mechanism.
> I hoped it would be this simple, but it touches core defines and structure
> that will over complicate the current driver. (i.e. the CMD indexes that differs,
> the CMD size shift, the high and low priority redirection or struct ordering)
>
Ah ok, understood.
>> IMO, we can add some compatible to indicate the pre v1.0 protocol
>> and add the support to the existing driver itself. Let me know your
>> thoughts.
>>
>
> My proposal is :
> - add a registry layer but with only a single scpi instance (no mode OF involved, remove drivers changes)
> - add a scpi_legacy.c driver that only supports the old SCPI like Amlogic and Rockchip, and add a disclaimer for new developed SoCs
> - add your extension capability to handle Amlogic's and Rockchip's extended commands
>
> If you agree, I'll post a new patchset for review with these changes.
>
Yes that sounds better. Also post along with the users to make it easy
to review even if they are not completely ready for upstream.
--
Regards,
Sudeep
WARNING: multiple messages have this Message-ID (diff)
From: Sudeep Holla <sudeep.holla@arm.com>
To: Neil Armstrong <narmstrong@baylibre.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 0/2] scpi: Add SCPI framework to handle vendors variants
Date: Mon, 20 Jun 2016 16:01:11 +0100 [thread overview]
Message-ID: <57680537.1080009@arm.com> (raw)
In-Reply-To: <5767C492.60201@baylibre.com>
On 20/06/16 11:25, Neil Armstrong wrote:
> On 06/06/2016 07:10 PM, Sudeep Holla wrote:
[...]
>>
>> Though this initial version of SCPI is not published, I am sure it is
>> almost same as v1.0 except that the CMD is not part of payload like
>> v1.0. In v1.0 it's part of payload and the mailbox is used just for
>> doorbell mechanism.
> I hoped it would be this simple, but it touches core defines and structure
> that will over complicate the current driver. (i.e. the CMD indexes that differs,
> the CMD size shift, the high and low priority redirection or struct ordering)
>
Ah ok, understood.
>> IMO, we can add some compatible to indicate the pre v1.0 protocol
>> and add the support to the existing driver itself. Let me know your
>> thoughts.
>>
>
> My proposal is :
> - add a registry layer but with only a single scpi instance (no mode OF involved, remove drivers changes)
> - add a scpi_legacy.c driver that only supports the old SCPI like Amlogic and Rockchip, and add a disclaimer for new developed SoCs
> - add your extension capability to handle Amlogic's and Rockchip's extended commands
>
> If you agree, I'll post a new patchset for review with these changes.
>
Yes that sounds better. Also post along with the users to make it easy
to review even if they are not completely ready for upstream.
--
Regards,
Sudeep
next prev parent reply other threads:[~2016-06-20 15:01 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-26 9:38 [RFC PATCH 0/2] scpi: Add SCPI framework to handle vendors variants Neil Armstrong
2016-05-26 9:38 ` Neil Armstrong
2016-05-26 9:38 ` [RFC PATCH 1/2] firmware: Add a SCPI framework to handle multiple vendors implementation Neil Armstrong
2016-05-26 9:38 ` Neil Armstrong
2016-05-26 9:38 ` [RFC PATCH 2/2] firmware: scpi: Switch scpi drivers to use new Framework calls Neil Armstrong
2016-05-26 9:38 ` Neil Armstrong
2016-05-26 16:29 ` [RFC PATCH 0/2] scpi: Add SCPI framework to handle vendors variants Sudeep Holla
2016-05-26 16:29 ` Sudeep Holla
2016-05-27 8:17 ` Neil Armstrong
2016-05-27 8:17 ` Neil Armstrong
2016-05-27 15:17 ` Neil Armstrong
2016-05-27 15:17 ` Neil Armstrong
2016-05-30 8:30 ` Neil Armstrong
2016-05-30 8:30 ` Neil Armstrong
2016-06-01 10:10 ` Sudeep Holla
2016-06-01 10:10 ` Sudeep Holla
2016-06-01 16:30 ` Kevin Hilman
2016-06-01 16:30 ` Kevin Hilman
2016-06-01 16:34 ` Sudeep Holla
2016-06-01 16:34 ` Sudeep Holla
2016-06-01 18:48 ` Heiko Stübner
2016-06-01 18:48 ` Heiko Stübner
2016-06-06 17:10 ` Sudeep Holla
2016-06-06 17:10 ` Sudeep Holla
2016-06-20 10:25 ` Neil Armstrong
2016-06-20 10:25 ` Neil Armstrong
2016-06-20 15:01 ` Sudeep Holla [this message]
2016-06-20 15:01 ` 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=57680537.1080009@arm.com \
--to=sudeep.holla@arm.com \
--cc=linux-arm-kernel@lists.infradead.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.