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

[Daniel Vetter]

On Tue, May 26, 2015 at 02:20:00PM -0700, Bob Paauwe wrote:
> 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.

Yeah that shiny new world of exposing everything modeset related in a
unified way as a property has unfortunately not yet materialized. Makes
sense to figure out first what we really need.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch