Re: [RFC 09/12] drm/i915/config: Add VBT settings configuration.

[Daniel Vetter <daniel@ffwll.ch>]

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@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@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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx