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