On Tue, Aug 02, 2016 at 03:05:08PM +0300, Jyri Sarha wrote: > + memcpy(audio.status, params->iec.status, > + min(sizeof(audio.status), sizeof(params->iec.status))); As mentioned in the other patch, the audio status does not directly correspond with the AES bytes, so this ends up causing the driver to write the wrong bytes to the wrong registers. > + ret = tda998x_configure_audio(priv, > + &audio, > + priv->encoder.crtc->hwmode.clock); What happens if audio changes at the same time that the video mode changes? What protection is there against two threads concurrently executing tda998x_configure_audio() ? > + priv->audio_pdev = platform_device_register_data( > + dev, HDMI_CODEC_DRV_NAME, PLATFORM_DEVID_AUTO, > + &codec_data, sizeof(codec_data)); I'd much prefer that this was a child of the I2C device, which will show the relationship between this virtual platform device and the device which it's associated with. That can be done via platform_device_register_full(). Thanks. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
