Let's be good citizen and summarize the important points from the irc chat between Jesse&me. On Thu, Nov 20, 2014 at 8:54 PM, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> wrote: >> Hm I dind't look too closely apparently at this. You again rely upon sw >> state here, just encoder->type this time around. Which means you can't >> upcast the intel_hdmi struct, and you also can't really rely upon the >> encoder->crtc link (that's all just about to get reconstructed). Imo the >> code should have stayed in the TRANS_DDI_MODE_SELECT_HDMI case. > > Hm, we look at the encoder->type later and check for eDP, so I figured > it must be valid at this point. It's easy enough to move though if > not... eDP is special since it doesn't change its personality ever. That's why we get away with it. And there's also not really any indication whether a given port would be eDP in the hw since at least on big core the panel power sequencer is global (and not per-pipe like on vlv/bsw) so we just can't tell. Well we could poke at the dp aux stuff. >> The later depency upon encoder->crtc is an issue for everything !g4x, but >> on hsw there's the additional issue that you have to look at the cpu >> transcoder and I guess that part blows up. > > I'll check out Paulo's trace; haven't looked yet. Summary from our irc analysis is in the patch I've just submitted. Hopefully that fixes Paulo's backtrace. >> g4x infoframe readout is probably broken too because it doesn't check that >> the port selected is the one actually queried for. > > Yeah that looks like a separate bug from the infoframe_enabled > additions. > >> >> Overall I think we need to: >> - Inline the g4x readout into the hdmi get_config function and check the >> port. >> - Inline the ibx/cpt readout code into the relevant get_pipe_config >> functions (well pch config) since that state is per-pipe. We should >> probably double-check the port, too. >> - Same inline for vlv and hsw, with the addition that we need to make sure >> on hsw to not try to read this for the edp transcoder. > > I'll check, we may not need to inline since we should be able to get > the port info easily enough. Per our discussion encoder->crtc gets reconstructed properly so we should be able to rely on that relationship. Might be good paranoid practice to double-check the port mapping for ibx/vlv, but imo not really required. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
