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@xxxxxxxx> 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@xxxxxxxxxxxxxxx> 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@xxxxxxxx> 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
