[Intel-gfx] [PATCH 00/19] [RFC] introduce struct intel_pipe_config

[Daniel Vetter]

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