#15662: intel video driver regression rev53561 -> rev53790
----------------------------------------------+----------------------------
Reporter: hugeping | Owner: pulkomandy
Type: bug | Status: assigned
Priority: normal | Milestone: Unscheduled
Component: Drivers/Graphics/intel_extreme | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Blocking: 15664
Has a Patch: 0 | Platform: All
----------------------------------------------+----------------------------
Comment (by pulkomandy):
So, here is a short explanation of what this code does:
The intel video hardware has two display "pipes". These are set with the
timing and source image for each of the two displays that can be used at
the same time (later generations add a 3rd pipe to have 3 independant
displays).
The pipes can be freely mapped to the output ports (lvds, dvi, vga, ...).
So you can have two displays using the same pipe (and displaying the same
thing), or you can have two displays each using a separate pipe.
Previously we would always return INTEL_PIPE_B for the LVDS (internal flat
panel) port here. Then, we would try to program the LVDS port to use pipe
B. But, it turns out our code to change which display pipe is used doesn't
quite work.
So, we would end up in an interesting situation: we would configure pipe
B, but let the LVDS display show the output of pipe A, which was set by
the VESA driver. Of course this would normally not work very well,
however...
Even when configuring pipe B, we did reset some of pipe A registers (the
old versions of the driver used to just set both pipes to the same things
regardless of connected monitors, hoping that one would be connected to
some display, and there were some leftovers of that). We did set just what
we needed for pipe A to show the right thing, and left pipe B in a badly
configured state (because we couldn't see what we were doing to it, and it
seemed to work because pipe A was OK and shown on display).
So, what I did here is read from the "port register" which has a bit
telling us which pipe is currently used. And we just tell the driver to
reuse that one. This way we can save us all the work of switching the
display from one pipe to the other, which we don't do correctly.
So, I would guess that something is wrong on Iron Lake with the way we set
up pipe B, and reverting this change gets us back to the initial
situation: a broken setup on pipe B, but the display is showing pipe A
anyway which was set y VESA so it doesn't really matter. I would review
all parts of the modesetting for things that I made sandybridge specific
when in fact they should also apply for iron lake (so check for Generation
= 6 or so, and verify the Iron Lake intel specs to see if it shouldinstead be >= 5 ; check places where the PCH versions are not handled the
