Hi Thomas,
On 3-Jul-25 8:47 AM, Thomas Zimmermann wrote:
HiThe driver code for this can still be generic and since the driver
Am 02.07.25 um 22:43 schrieb Krzysztof Kozlowski:
On 30/06/2025 10:40, Hans de Goede wrote:But does that work with *any* device that requires interconnects? The next such simple-framebuffer device should work out of the box *without* the kernel knowing anything about it. That's one of the key features of the simple-framebuffer. If we have to maintainer per-device feature sets, it breaks that assumption.
IMO yes (after adjusting above to coding style), but as mentioned inNo one asks to drop them from the driver. I only want specific frontSo what you are saying is that you want something like:
compatible which will list and constrain the properties. It is not
contradictory to your statements, U-boot support, driver support. I
really do not see ANY argument why this cannot follow standard DT rules.
framebuffer0: framebuffer@1d385000 {
compatible = "qcom.simple-framebuffer-sm8650-mdss", "simple-framebuffer";
}
and that the binding for qcom.simple-framebuffer-sm8650-mdss
can then list interconnects ?
other response you can just get an ack or opinion from Rob or Conor.
will bind to the fallback plain "simple-framebuffer" compatible
this should also work for new platforms.
The e.g. "qcom.simple-framebuffer-sm8650-mdss" compatible would
purely be something in the dt-bindings to document which simplefb
implementations will have interconnects and which ones will not.
The driver does not necessarily need to check these more
precise compatibles, it can still just check for the generic
presence of interconnects.
Regards,
Hans