On 9/8/26 9:49 AM, Charles Keepax wrote:
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.
Either we represent full ACPI into DT or use some know representation
that linux understands and is maintained along with ACPI which is the C
structure.
However, that said if people want to work on doing so I am not
going to stand in the way. It does have the advantage it might
unblock things with the DT maintainers, since we can focus on
doing stuff in a more traditional DT style.
This is really going to be a very very long shot, but as of today the
need for this is slim, unless we see some platforms which have SDCA
compliant codecs without a reference ACPI fw entires.
I would also agree that this is reasonable as a half way house,
it seems like a good fallback mechanism to have for emergency
work arounds as well. If we can't reuse the existing parser then
there is a lot of work to define a new representation for DT.
+1
Ideally that would be worked through with the MIPI group as well
to avoid future specs causing catastrophic issues. But all that
will take significant time so we probably need an interim
solution.
--srini
Thanks,
Charles