On Wed, Feb 13, 2013 at 3:03 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote: > On Wed, Feb 13, 2013 at 12:32:03PM +0100, Daniel Vetter wrote: >> Hi all >> >> So this is my old attempt to push our modeset infrastructure a bit further, >> rebased on top of latest dinq. Originally I wanted to push this a bit further >> still before submitting for rfc, but with fastboot picking up I think it's >> better to throw it out there now. > > [snip] > >> Comments, flames and ideas for the patches themselves, but also for the above >> issues in general highly welcome. > > It's a good idea, as tracking the pipe config rather than attempting to > reconstruct and compare a mode is far more likely not to fail during > fastboot for the initial takeover. However, we will still need mode > reconstruction for the user facing aspects - but we may just get away > with a few white lies as the modeset itself will still be detected as a > no-op when comparing the pipe configs. Yeah, reconstructing the userspace facing mode (or the one used for fbcon) is somewhat orthogonal to this. Imo we should move the fastboot mode readout to pipe_config, but reconstructing the fbdev setup from the pipe_config would still be a separate step. Another idea I have in mind is to use two modes two compare pipe_configs eventually: - A strict mode for the hw state check after each modeset. - A permissive mode in the modeset sequence to compare the new pipe_config with the current one. That would then allow for a bit of fuzz in e.g. the dotclock to handle fastboot. But we need to be careful with this since when the BIOS selects different pll values than what we'd do, we might accidentally break a 3 pipe config (when the 3rd pipe is not brought up by the BIOS and i915.ko picks different PLL settings for the same mode). Another idea I have is to add a pipe_config->crazy flag which the get_pipe_config callbacks would always set when encountering a mode which we can't map well enough with our own state tracking (e.g. panel fitter on a non-lvds/edp output). The lazy pipe_config comparison would then always fail in that case (whereas the strict checks after modeset would need to ignore this do avoid WARN spam at boot-up when not all crazy bios modes are yet fully disabled). Bikesheds for a better name for crazy appreciated btw ;-) So summarizing the pipe_config stuff here is imo mostly complementary to the fastboot patches floating around already. The exception being the clock handling, which I think should be unified into the pipe_config first. Otherwise we'll have a really hard time to get 3 pipe pll sharing on ivb right for fastboot. Other global resources like shared fdi lanes are similar, but much easier to fix than the clock computation code (i.e. working on it already). Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
