On Sun, May 20, 2012 at 11:17:36AM -0300, Eugeni Dodonov wrote: > 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> Queued for -next, thanks for the review. -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
