[PATCH 00/12] drm/i915: pipe_config, adjusted_mode vs. requested_mode, etc.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Currently parts of our code are really confused about which mode
structure they should be looking at.

A lot of the code never got converted to look at the pipe config modes,
and for example the watermark code still managed to look at the wrong mode
(crtc->mode, not even crtc->hwmode which would have been a bit better).

So let's convert everything over to pipe config, and let's pretend the
modes in drm_crtc don't even exist.

Also in the pipe config conversion some bits of code were made to look at
the requested_mode. If we have a fixed mode panel, requested_mode may contain
all kinds of garbage and the only two things in it we should be looking at
are hdisplay and vdisplay. Everything else should be interested in the
adjusted_mode only.

(S)DVO is a minor exception here as is wants to program the output timings
with the requested_mode. I've left that stuff alone for now since it's
essentially correct as is.

In the end I decided that digging out hdisplay/vdisplay from requested_mode
is just confusing. Instead I added explicit pipe source width/height members
to pipe config. I was also considering adding primary plane size to make it
clear which one we actually want in different places. But I opted not to do
that. It should get sorted out when we move to drm_planes. After this there
is no real need to poke around requested_mode anymore, so we could even consider
removing it, or rather rename it to indicate that it's only relevant for
(S)DVO.

I also found some bugs in LVDS adjusted_mode vs. fixed_mode handling. It was
causing the pipe config sanity checks to fail on my 855. So I ended up
fixing that stuff as well.

One extra idea that occured to me, is that we never actually update
adjusted_mode->clock with the real clock value after we've found the PLL settings.
I think that's something we should be doing since the PLL might not be
able to give an exact match, and we use the clock to compute watermarks and
check various hardware limits. But that's a patch for another day.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux