On Tue, Jul 11, 2017 at 5:05 PM, John Stultz <john.stultz@xxxxxxxxxx> wrote: >>> > be even better if you could calculate whether the mode is valid, but I didn't >>> > spend enough time to figure out if this is possible. >>> >>> Theoretically that might be possible, checking if the requested freq >>> matches the calculated freq, and I've tried that but so far I've not >>> been able to get it to work, as in some cases the freq on the current >>> whitelist don't exactly match but do work on the large majority of >>> monitors tested (while other freq have a similar error but don't work >>> on most monitors). >>> >>> I'd like to spend some more time to try to refine and tune this, but >>> having the current whitelist works fairly well, so I'm not sure its >>> worth sitting on (this is basically the last functional patch >>> outstanding for HiKey to fully work upstream - except the mali gpu of >>> course), while I try to tinker and tune it. >>> >>> Thanks so much for the feedback! >> >> Yeah the proper approach is to compute your pll/clock settings and bail >> out if those don't work. That's generally a magic spreadsheet supplied by >> the hw validation engineers, and I honestly don't want to know how they >> create it. Explicit modelist in the kernel sounds like a very bad hack. > > So without such a magic spreadsheet, how would you suggest I move this forward? > Not having the whitelist hack and picking modes the device can't > generate is a fairly major usability issue. I guess if the whitelist is the only thing I'd do 2 things differently: - Whitelist the clocks, not modes, since that's what seems to matter here. - Put it as close as possible to the code that comuptes the clock settings (yet if you use the clock subsystem that's a bit hard, but for an atomic driver this should be where this is done ...). Whitelist of modes looks super-hacky. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
