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

[Bob Paauwe]

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. 

> > 
> > We need a lot of the dp things already anyway for the dp validation stuff,
> > but since that was debug Dave shot down my idea to just go with props. But
> > here we have another user, and this one will have full abi compat
> > requirements. So no longer any reasons to not go with props imo.
> > 
> > Or else we just smash an entire vbt into acpi, for my that's ok (we need
> > to deal with vbt anyway).
> > -Daniel
> > -- 
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>