From: Jose Abreu Subject: Re: [PATCH 3/3 v3] drm: bridge/dw-hdmi: Move edid reading to .detect() callback Date: Thu, 4 Aug 2016 14:58:00 +0100 Message-ID: <57A349E8.5040400@synopsys.com> References: <1bbffb944fb9ce0363f5544db31baf2a911c1c55.1470306826.git.joabreu@synopsys.com> <20160804104738.GR1041@n2100.armlinux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20160804104738.GR1041@n2100.armlinux.org.uk> Sender: linux-kernel-owner@vger.kernel.org To: Russell King - ARM Linux , Jose Abreu Cc: dri-devel@lists.freedesktop.org, Carlos Palminha , Archit Taneja , David Airlie , Fabio Estevam , Daniel Vetter , Takashi Iwai , Vladimir Zapolskiy , Thierry Reding , linux-kernel@vger.kernel.org List-Id: dri-devel@lists.freedesktop.org Hi Russell, On 04-08-2016 11:47, Russell King - ARM Linux wrote: > On Thu, Aug 04, 2016 at 11:44:51AM +0100, Jose Abreu wrote: >> When running HDMI compliance tests we noticed that sometimes >> the edid changes but the get_modes() function is not called >> so the edid is not updated. Moving the edid reading to the >> detect() callback ensures that the edid is correctly updated >> after an hotplug. > Wouldn't this be a bug in the higher levels of DRM? > I am not sure if this is a bug in DRM or a bad implementation of dw-hdmi. I've seen at least two more drivers that do the edid reading at the .detect() callback: nouveau and gma500. This is noticeable if while sending video the edid changes like in a compliance environment. In the environment that I tested I was sending video and swapped an edid that had support for AI packets to another one without support and I noticed that although the hotplug is generated the edid was not being updated. Best regards, Jose Miguel Abreu