On Sun, Jun 30, 2019 at 2:15 PM Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: > > Hi Rob, > > On Sun, Jun 30, 2019 at 02:05:21PM -0700, Rob Clark wrote: > > On Sun, Jun 30, 2019 at 1:47 PM Laurent Pinchart wrote: > > > On Sun, Jun 30, 2019 at 01:36:04PM -0700, Rob Clark wrote: > > > > From: Rob Clark <robdclark@xxxxxxxxxxxx> > > > > > > > > Now that we can deal gracefully with bootloader (firmware) initialized > > > > display on aarch64 laptops[1], the next step is to deal with the fact > > > > that the same model of laptop can have one of multiple different panels. > > > > (For the yoga c630 that I have, I know of at least two possible panels, > > > > there might be a third.) > > > > > > I have to ask the obvious question: why doesn't the boot loader just > > > pass a correct DT to Linux ? There's no point in passing a list of > > > panels that are not there, this seems quite a big hack to me. A proper > > > boot loader should construct the DT based on hardware detection. > > > > Hi Laurent, > > > > Actually the bootloader on these devices is passing *no* dt (they boot > > ACPI, we are loading dtb from grub currently) > > Ah, the broken promises of ACPI on ARM64. I wonder how long it will take > before a public acknowledgement that it was a bad idea. Bad ideas happen > and can be forgiven, but stubborness in claiming it was the right > decision is another story. > > (Not that you can be blamed for this of course :-)) To be fair, I think the only blame here is that MS let qcom get away with some things in their ACPI and UEFI implementation.. I think we'll need to shift to ACPI eventually for these laptops, in order to keep up. DT isn't a thing that would scale with the volume of x86 laptops that exist, and if aarch64 laptops get there too, we'll need ACPI. Lets face it, the # of different dt devices supported upstream is a drop in the bucket compared to number of *actually physically different* x86 devices supported by upstream. (And I don't mean individual models of laptops, but different production runs where they picked a different panel or trackpad or whatever.) But we have a lot of upstream work to get there to support how ACPI works on these things: * The new Platform Extension Plugin (PEP) model for device power control * untangling drm bridge hookup from DT * untangling drm panel hook from DT * figuring out how to deal with mis-matches between dt device model and ACPI device model There is some early work for ACPI support for these devices, but realistically I think it is going to take a better part of a year to get there. Until then we rely on DT. That isn't to say my proposal doesn't make a ton of sense. We also need to solve this problem for DT based devices, and I think /chosen/panel-id makes a *ton* of sense for those devices. > > I think normally a device built w/ dt in mind would populate > > /chosen/panel-id directly (rather than the way it is currently > > populated based on reading an efi variable prior to ExitBootServices). > > But that is considerably easier ask than having it re-write of_graph > > bindings. Either way, we aren't in control of the bootloader on these > > devices, > > If you can't control the initial boot loader, then I see two options, > none of which you will like I'm afraid. > > - As you pass the DT to Linux from grub, there's your intermediate boot > loader where you can construct a valid DT. not really a solution that is going to scale > - If the ACPI cult needs to be venerated, then drivers should be > converted to support ACPI without the need for DT. we're working on it > A possible a middleground could be a platform driver (in > drivers/firmware/efi/ ? in drivers/platform/ ?) that will patch the DT > to instantiate the right panel based on the information retrieved from > the boot loader. We will need something similar for the Intel IPU3 > camera driver, as Intel decided to come up with two different ACPI > "bindings", one for Windows and one for Chrome OS, leaving Windows > machine impossible to handle from a kernel driver due to required > information being hardcoded in Windows drivers shipped by Intel. This is > thus an option that may (unfortunately) need to become more widespread > for ACPI-based systems. again, a kernel (or bootloader) side massively intrusive re-write the dt approach isn't going to scale. If you keep it simple, ie. /chosen/panel-id I can see a possibility to move my patch from drivers/firmware/efi into an earlier stage. But if it has to re-write graph, that falls apart as soon as a new device comes along with a different bridge, or perhaps some vendor decides to use dsi directly and forego the bridge. usually (from what I've seen so far) there are a few gpios to probe to decide which panel you have. So after a few lines of gpio banging you can either ask fw engineers to set appropriate node in chosen.. or re-write of_graph bindings. I think the former has a chance of gaining traction on android devices.. latter not so much. You are really making too big of an ask for fw engineers ;-) > > so it is a matter of coming up with something that works on actual hw > > that we don't like rather than idealized hw that we don't have ;-) > > That doesn't however justify not going for the best solution we can > achieve. What do you like best in the above ? :-) I want a solution that is achievable ;-) BR, -R
