On 11/11/16 13:34, Rob Herring wrote:
On Fri, Nov 11, 2016 at 1:48 AM, Sudeep Holla <sudeep.holla@xxxxxxx> wrote:
On 10/11/16 19:03, Olof Johansson wrote:
On Thu, Nov 10, 2016 at 6:34 AM, Sudeep Holla <sudeep.holla@xxxxxxx>
wrote:
[...]
E.g. Amlogic follows most of the legacy protocol though it deviates in
couple of things which we can handle with platform specific compatible
(in the following patch in the series). When another user(Rockchip ?)
make use of this legacy protocol, we can start using those platform
specific compatible for deviations only.
Is that not acceptable ?
If there's no shared legacy feature set, then it's probably less
useful to have a shared less precise compatible value.
There is and will be some shared feature set for sure. At the least the
standard command set will be shared.
What the main point I was trying to get across was that we shouldn't
expand the generic binding with per-vendor compatible fields, instead
we should have those as extensions on the side.
Yes I get the point. We will have per-vendor compatibles for handle the
deviations but generic one to handle the shared set.
I'm also a little apprehensive of using "legacy", it goes in the same
bucket as "misc". At some point 1.0 will be legacy too, etc.
True and I agree, how about "arm,scpi-pre-1.0" instead ?
That's still meaningless. Convince me that multiple implementations
are identical, then we can have a common property. For example, how
many releases did ARM make before 1.0.
None officially, so I tend to agree with you on this.
But so far we have seen some commonality between Rockchip and Amlogic
implementations, which in fact shares some commonality with early
release of SCPI from ARM (there are based on the same SCP code base,
which is closed source and released to partners only). ARM improved the
specification and the code base before the official release but by then
it was adopted(as usual we were late ;))
IMO, it's might be useful to have more generic say "arm,scpi-pre-1.0"
and platform specific "amlogic,meson-gxbb-scpi"
--
Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
