Re: [PATCH 3/3] drm/i915: Make infoframe trnsmission more reliable on g4x

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

 



On Mon, Feb 10, 2014 at 12:16:14PM +0000, Damien Lespiau wrote:
> On Thu, Jan 23, 2014 at 11:15:35PM +0200, ville.syrjala@xxxxxxxxxxxxxxx wrote:
> > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
> > 
> > On g4x there's just one video DIP, but there can be two HDMI/DVI
> > ports. Currently even a DVI monitor on another port can clobber
> > the infoframes meant for a real HDMI monitor on the other port.
> > 
> > Make sure we only ever send DIPs to one port. The first port with a
> > HDMI sink to get there gets to own the DIP until such time that the
> > port is completely turned off (ie. not just DPMS off). If there are
> > two HDMI sinks attached, the one to arrive second doesn't get any
> > infoframes. And if there's a DVI sink on the other port, it will
> > no longer disable DIP transmission for the other port.
> > 
> > Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
> 
> Reviewed-by: Damien Lespiau <damien.lespiau@xxxxxxxxx>
> 
> I guess follow-up patches could turn off Video DIPs on other platforms,
> if I read the code correctly we're always leaving Video DIPs on when
> disabling the pipe.

Yeah. Actually I realized afterwards that that's also a problem if we
switch from say HDMI->DP on the same transcoder. We might end up
sending infoframes to the DP sink that we constructed for the HDMI sink.
Or if the video DIP has port select bits (not all platforms do), then
I think we might even end up sending infoframes from some transcoder to
a port that isn't connected to said transcoder. I have no idea if the
hardware can even do that, but it would seem safer not to program it
that way in the first place.

But the .off hook isn't sufficient to fix that since we could switch the
output without calling the .off hook. I think the real solution would to
always disable infoframes in hdmi disable or post_disable, and always
re-enabling them in enable or pre_enable.

That would require changing the new g4x logic you just reviewed since
we couldn't track the owner of the video DIP by the register contents
anymore. So I think we'd need to add a piece of software state for that
purpose instead.

If anyone's looking for a relatively straightforward small project,
this would seem to fit the bill.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
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