On 27-05-21, 16:30, Rob Clark wrote: > On Wed, May 26, 2021 at 8:00 AM Jeffrey Hugo <jeffrey.l.hugo@xxxxxxxxx> wrote: > > On Tue, May 25, 2021 at 11:46 PM Vinod Koul <vkoul@xxxxxxxxxx> wrote: > > Frankly, I don't like the MSM ACPI solution that I've seen on the laptops. > > The ACPI assumes the entire MDSS (including DSI parts) and GPU is one > > device, and ultimately handled by one driver. That driver needs to > > get a value from UEFI (set by the bootloader) that is the "panel id". > > Then the driver calls into ACPI (I think its _ROM, but I might be > > mistaken, doing this from memory) with that id. It gets back a binary > > blob which is mostly an xml file (format is publicly documented) that > > contains the panel timings and such. > > tbh, I kinda suspect that having a single "gpu" device (which also > includes venus, in addition to display, IIRC) in the ACPI tables is a > windowsism, trying to make things look to userspace like a single "GPU > card" in the x86 world.. but either way, I think the ACPI tables on > the windows arm laptops which use dsi->bridge->edp is too much of a > lost cause to even consider here. Possibly ACPI boot on these devices > would be more feasible on newer devices which have direct eDP out of > the SoC without requiring external bridge/panel glue. yeah that is always a very different world. although it might make sense to use information in tables and try to deduce information about the system can be helpful... > I'd worry more about what makes sense in a DT world, when it comes to > DT bindings. And do you have thoughts on that..? -- ~Vinod
