On ti, 2016-11-29 at 23:00 +0200, Ville Syrjälä wrote: > [...] > > > > > There is a slight concern on g4x/vlv/chv that an AUX interrupts > > > > > would > > > > > trigger the hpd irq handler, which doesn't realize it's supposed > > > > > to > > > > > ignore the actual hpd bits in PORT_HOTPLUG_STAT. So any aux > > > > > before we > > > > > enable hpd processing for real could do something bad. So I guess > > > > > we > > > > > should add some kind of software tracking for that stuff like we > > > > > have > > > > > for PIPESTAT. > > > > > > > > Didn't think about that, but BSpec tells me those are masked by the > > > > HPD > > > > IRQ enable bits in PORT_HOTPLUG_EN and those we enable only later. > > > > Otherwise this would be also a problem during output setup time. > > > > > > Hmm. Are they really masked? I though it's just an IER effectively. > > > > I only tried for real on BXT/SKL where I had to enable the interrupts > > (in PCH_PORT_HOTPLUG) for HPD sensing. The CHV BSpec suggests the same > > for the live state bits, but yes it's not clear if the long/short > > detect bits are completely masked by the enable flags or they are just > > not propagated if not enabled. Will give it a try tomorrow. > > Hmm. Yeah, we did in fact chat about this. Already forgot. Spec seems to > suggest you are correct. But checking on actual hw is always a good > idea. Checked now both on BXT and VLV both the live state and short/long detect bits in the hotplug_stat reg are masked by the hotplug_en bits. (And we clear any stale short/long bits during IRQ reset.) --Imre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
