On Sun, Aug 12, 2012 at 06:15:48PM +0200, Daniel Vetter wrote: > Yet again the too close relationship between the fb helper and the > crtc helper code strikes. This time around the fb helper resets all > encoder->crtc pointers to NULL before starting to set up it's own > mode. Which is total bullocks, because this will clobber the existing > output routing, which the new drm/i915 code depends upon to be > absolutely correct. > > The crtc helper itself doesn't really care about that, since it > disables unused encoders in a rather roundabout way anyway. > > Two places call drm_setup_crts: > > - For the initial fb config. I've auditted all current drivers, and > they all allocate their encoders with kzalloc. So there's no need to > clear encoder->crtc once more. > > - When processing hotplug events while showing the fb console. This > one is a bit more tricky, but both the crtc helper code and the new > drm/i915 modeset code disable encoders if their crtc is changed and > that encoder isn't part of the new config. Also, both disable any > disconnected outputs, too. > > Which only leaves encoders that are on, connected, but for some odd > reason the fb helper code doesn't want to use. That would be a bug > in the fb configuration selector, since it tries to light up as many > outputs as possible. > > v2: Kill the now unused encoders variable. > > Signed-Off-by: Daniel Vetter <daniel.vetter at ffwll.ch> > --- > Hi Dave, > > This patch here is blocking the modeset-rework series, and I'd like to merge > that as soon as possible. You've merged the other two prep patches already for > 3.6, but this one here popped up later on in testing. > > Can you please merge this into drm-next for 3.7 so that I can backmerge it, or > smash your maintainer-ack onto it for merging through the intel tree? Merged to drm-intel-next with Dave's irc-ack. Should show up in drm-next in about 2 weeks ... -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
