Re: [PATCH 0/4] drm+dt+efi: support devices with multiple possible panels

[Rob Clark]

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