On Tue, Sep 08, 2026 at 01:31:37PM +0100, Srinivas Kandagatla wrote:
On 9/8/26 11:37 AM, Richard Fitzgerald wrote:
quoted
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.
I am very sorry but this reads quite strangely and I am really
struggling to understand your position. I think I am reading it
as you are happy to go with the group concensus on how the DT is
represented and don't favour either approach.
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.
This part I follow slightly better, I would be happy to proceed,
pending reviews with the current approach, although if Pierre
is or not probably remains to be seen.
I would assume the DT guys would be happy with a completely
different representation that was more idiomatic DT, that is
essentially what they have already said. The question I was
aiming for was less whether they will be on board with that
and more if it is a good idea.
Thanks,
Charles