[Intel-gfx] [PATCH 6/7] drm/i915: make SDVO TV-out work for multifunction devices

[Daniel Vetter]

On Tue, Apr 30, 2013 at 2:49 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> On Tue, Apr 30, 2013 at 02:01:45PM +0200, Daniel Vetter wrote:
>> --- a/drivers/gpu/drm/i915/intel_drv.h
>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>> @@ -223,6 +222,10 @@ struct intel_crtc_config {
>>       /* Controls for the clock computation, to override various stages. */
>>       bool clock_set;
>>
>> +     /* SDVO TV has a bunch of special case. To make multifunction encoders
>> +      * work correctly, we need to track this at runtime.*/
>> +     bool sdvo_tv_clock;
>> +
>>       /*
>>        * crtc bandwidth limit, don't increase pipe bpp or clock if not really
>>        * required. This is set in the 2nd loop of calling encoder's
>
> What is becoming less clear over time is what is derived state internal
> to the modesetting sequence, and what is the state used to select a mode
> e.g. to decide if two configs are compatible.

Atm everything is derived state and we currently have don't take the
pipe config into account for comparing state. My plan is that we
eventually add flags to the pipe_config compare function to decide
whether we need a full-blown modeset or can go with an "update pfit
state" fastpath.

So atm I'm just moving state around, since pipe_config will also be
used for atomic modeset. And checking the hw config upfront e.g. for
pll sharing has similar, but not completely overlapping needs to the
state comparison fastboot needs to do.

Another thing I don't yet have an opinion about is what we should do
if the mode matches, but the configuration details are a bit
suboptimal (like wasteful watermark settings). I guess we need to
rework the code so that we can fix this all up without stopping the
crtc. And there's tons of little bits of state like that (audio
config, infoframes, clock trees, watermarks, fdi config, ...). Added
fun is that often it is highly platform specific whether a given piece
of state must match for fastboot or not ...

My current plan is to just chip away with pipe_config conversions,
with more a focus towards atomic modeset (i.e. upfront checking),
leaving some of the harder fastboot issues for Jesse ;-)

Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch