[Intel-gfx] [RFC 09/12] drm/i915/config: Add VBT settings configuration.

[Bob Paauwe]

On Thu, 21 May 2015 10:37:07 +0200
Daniel Vetter <daniel at ffwll.ch> wrote:

> On Wed, May 20, 2015 at 10:07:58AM -0700, Bob Paauwe wrote:
> > On Fri, 15 May 2015 12:39:20 +0300
> > Ville Syrjälä <ville.syrjala at linux.intel.com> wrote:
> > 
> > > On Tue, Feb 24, 2015 at 09:52:16PM +0100, Daniel Vetter wrote:
> > > > On Tue, Feb 24, 2015 at 10:37:10AM -0800, Bob Paauwe wrote:
> > > > > On Tue, 24 Feb 2015 14:57:48 +0100
> > > > > Daniel Vetter <daniel at ffwll.ch> wrote:
> > > > > > As Jani points out we already have vbt headaches, it would be good if we
> > > > > > only have those once ;-)
> > > > > > -Daniel
> > > > > 
> > > > > I've been trying to think of a better way but not really coming up with
> > > > > something that scales well. EMGD took the approach of create
> > > > > configuration for only those values that we had customer requests for.
> > > > > And that was primarily just the panel power up/down timing sequence and
> > > > > some backlight control. We never tried to replicate everything that
> > > > > could be set via vbt.
> > > > 
> > > > If it's only a very few select things we could just add them as atomic
> > > > properties to connectors. No need for anything special, and we could even
> > > > use that to debug panel issues at runtime.
> > > 
> > > I think properties should only be used for something that the user
> > > might actually want to configure. Not sure what exactly we're talking
> > > about here, but eg. panel timings are definitely not in that category
> > > IMO.
> > > 
> > I did create an implementation that used properties for this (and a
> > couple of other things) and that was my conclusion as well. These would
> > probably have to be read-only properties with the values set by some
> > configuration framework (like the ACPI property framework this was
> > originally part of).
> > 
> > I also did an implementation where I set these via module parameters
> > and, to me, that seems more reasonable. It's easy to implement and a
> > fairly simple patch to maintain. 
> > 
> > Given the small number of items that EMGD can currently configure at
> > driver load that i915 can't, I'm really questioning the need for a
> > full configuration framework.  I'm also trying to determine if we even
> > have requirements for these anymore or if they were added in to EMGD at
> > some point to workaround broken firmware.  If we do end up with a
> > customer requirement to configure the panel power sequence, maintaining
> > an embedded only patch to add module parameters may suffice.
> > 
> > The two other items that EMGD has currently are backlight related (max
> > and level) and DPCD max link rate. I'm also trying to determine if
> > there's really a requirement for overriding these. If there is, module
> > parameters would be the easiest way here too.
> > 
> > When I started looking at configuration at driver load I thought we
> > had a lot of different things that needed to be configured, which is
> > why I discounted using module parameters and was looking at a larger
> > framework solution.  Another consideration that has come into play is
> > that a framework solution, like the ACPI one that I posted, has
> > negative impact on driver load time. And driver load time is
> > very important to some customers. 
> 
> For me the big reason for an entire framework was that we also wanted to
> spec the initial modeset, including any kind of splash screen loaded as
> firmware blobs. That's also the reason for aiming for properties by
> default (that's the new transport for all things modeset after all), and
> using hidden configuration variables only for cases where a prop really
> doesn't make any sense.
> 
> But if that initial modeset use-cases is nuked too I agreee there's indeed
> not much left to justify an entire framework ...
> -Daniel

The initial mode set use-case isn't nuked but that use-case exist
to try and parallelize the mode in the kernel boot phase as a way to
reduce time to first flip.  Right now, the ACPI functions add enough
overhead that I'm concerned it will negate the advantage of doing the
initial mode set in the driver.

With the framework, read-only properties is compelling. I'm
experimenting with an number of different implementations and trying to
get feedback on all of them.  Nothing yet has jumped out as the perfect
implementation.

This is mostly back-burned right now as I wait for all the atomic
mode setting code to land.