[Intel-gfx] [PATCH 05/18] drm/i915: add TRANSCODER_EDP

[Lespiau, Damien]

On Wed, Oct 24, 2012 at 6:59 PM, Paulo Zanoni <przanoni at gmail.com> wrote:
> From: Paulo Zanoni <paulo.r.zanoni at intel.com>
>
> Before Haswell we used to have the CPU pipes and the PCH transcoders.
> We had the same amount of pipes and transcoders, and there was a 1:1
> mapping between them. After Haswell what we used to call CPU pipe was
> split into CPU pipe and CPU transcoder. So now we have 3 CPU pipes (A,
> B and C), 4 CPU transcoders (A, B, C and EDP) and 1 PCH transcoder
> (only used for VGA).
>
> For all the outputs except for EDP we have an 1:1 mapping on the CPU
> pipes and CPU transcoders, so if you're using CPU pipe A you have to
> use CPU transcoder A. When have an eDP output you have to use
> transcoder EDP and you can attach this CPU transcoder to any of the 3
> CPU pipes. When using VGA you need to select a pair of matching CPU
> pipes/transcoders (A/A, B/B, C/C) and you also need to enable/use the
> PCH transcoder.
>
> For now we're just creating the cpu_transcoder definitions and setting
> cpu_transcoder to TRANSCODER_EDP on DDI eDP code, but none of the
> registers was ported to use transcoder instead of pipe. The goal is to
> keep the code backwards-compatible since on all cases except when
> using eDP we must have pipe == cpu_transcoder.
>
> V2: Comment the haswell_crtc_off chunk, suggested by Damien Lespiau
> and Daniel Vetter.
>
> We currently need the haswell_crtc_off chunk because TRANSCODER_EDP
> can be used by any CRTC, so when you stop using it you have to stop
> saying you're using it, otherwise you may have at some point 2 CRTCs
> claiming they're using TRANSCODER_EDP (a disabled CRTC and an enabled
> one), then the HW state readout code will get completely confused.
>
> In other words:
>
> Imagine the following case:
>   xrandr --output eDP1 --auto --crtc 0
>   xrandr --output eDP1 --off
>   xrandr --output eDP1 --auto --crtc 2
>
> After the last command you could get a "pipe A assertion failure
> (expected off, current on)" because CRTC 0 still claims it's using
> TRANSCODER_EDP, so the HW state readout function will read it
> (through PIPECONF) and expect it to be off, when it's actually on
> because it's being used by CRTC 2.
>
> So when we make "intel_crtc->cpu_transcoder = intel_crtc->pipe" we
> make sure we're pointing to our own original CRTC which is certainly
> not used by any other CRTC.
>
> Signed-off-by: Paulo Zanoni <paulo.r.zanoni at intel.com>

Reviewed-by: Damien Lespiau <damien.lespiau at intel.com>

-- 
Damien