On Sat, May 12, 2012 at 3:22 PM, Daniel Vetter <daniel.vetter at ffwll.ch>wrote: > At least the worst offenders: > - SDVO specifies that the encoder should compute the ecc. Testing also > shows that we must not send the ecc field, so copy the dip_infoframe > struct to a temporay place and avoid the ecc field. This way the avi > infoframe is exactly 17 bytes long, which agrees with what the spec > mandates as a minimal storage capacity (with the ecc field it would > be 18 bytes). > - Only 17 when sending the avi infoframe. The SDVO spec explicitly > says that sending more data than what the device announces results > in undefined behaviour. > - Add __attribute__((packed)) to the avi and spd infoframes, for > otherwise they're wrongly aligned. Noticed because the avi infoframe > ended up being 18 bytes large instead of 17. We haven't noticed this > yet because we don't use the uint16_t fields yet (which are the only > ones that would be wrongly aligned). > > This regression has been introduce by > > 3c17fe4b8f40a112a85758a9ab2aebf772bdd647 is the first bad commit > commit 3c17fe4b8f40a112a85758a9ab2aebf772bdd647 > Author: David H?rdeman <david at hardeman.nu> > Date: Fri Sep 24 21:44:32 2010 +0200 > > i915: enable AVI infoframe for intel_hdmi.c [v4] > > Patch tested on my g33 with a sdvo hdmi adaptor. > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=25732 > Signed-Off-by: Daniel Vetter <daniel.vetter at ffwll.ch> > This looks correct, and the math matches the 17 bytes we need. So for the patch itself: Reviewed-by: Eugeni Dodonov <eugeni.dodonov at intel.com> (But I haven't tested it myself as I don't have such a machine). -- Eugeni Dodonov <http://eugeni.dodonov.net/> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20120520/1d3a3292/attachment.html>
