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
