On 9/8/26 11:37 AM, Richard Fitzgerald wrote:
On 08/09/2026 10:09 am, Srinivas Kandagatla wrote:
quoted
On 9/8/26 9:49 AM, Charles Keepax wrote:
quoted
On Mon, Sep 07, 2026 at 11:37:49PM +0100, Srinivas Kandagatla wrote:
quoted
On 9/7/26 8:47 PM, Pierre-Louis Bossart wrote:
quoted
My take is that rather than encode all properties in C, it's probably
worth exploring a DT representation of the concepts that *can* be used
fairly easily and make the life of codec vendors easier - not as a>
literal translation of ACPI.
I agree a DT expression of the *concepts* not a literal DisCo
mirror would be a better A. I want to bring that back to LPC 2026
DT MC as a concrete proposal grounded in the earlier DT-maintainer
feedback rather than re-litigating it inline on this series. Because
B stays put, switching A later is a change inside populate_function,
not an ABI break. so landing this series does not close the door on
the representation you're asking for.
I am still not sure I really see what the value is in a
completely different DT representation of the DisCo information,
all it does is give us potential issues with future spec versions
and create a whole bunch of new code than needs maintained. The
ACPI representation translates perfectly well to DT, should work
perfectly fine using the existing code.
I totally agree with both of your comments, there is no way we can
replicate MiPi spec into an different DT representation, this brings
both maintenance overhead and is fragile. This a very big effort.
But in your previous message in this thread you said the opposite:
Yes I did say that, and I still think an intermediate DT
representation would be a better A in principle. What I'm
highlighting is the cost side, any intermediate representation, by
definition, deviates from the original MIPI representation. That
deviation has to be kept in sync with the SDCA spec, tracked across
spec revisions, and translated back to struct sdca_function_data at
runtime. It's a real overhead, not a blocker, just something to
weigh against the "concepts read cleaner in DT" benefit.
That's why the current series takes the lower-overhead path
(mechanical transcription in C) rather than proposing an intermediate
DT format as part of this submission. If the concept-DT direction
gets traction at LPC 2026 DT MC, we can revisit.
"I agree a DT expression of the *concepts* not a literal DisCo
mirror would be a better A."
--srini