On 01/24/2017 05:09 PM, Andrzej Hajda wrote:
On 24.01.2017 11:31, Archit Taneja wrote:
On 01/20/2017 01:08 PM, Andrzej Hajda wrote:
MHL3 requires that after reading EDID from the sink source should ask
peer for features. To make both protocols happy the patch splits the code
accordingly.
I was wondering about the EDID code in the driver, what does it exactly
do with the EDID? We don't seem to be populating connector modes with it.
I saw a func called sii8620_set_upstream_edid(), but didn't understand
what it does.
MHL reads EDID from TV (or MHL dongle) using MHL protocol and publish it
upstream (for example to exynos_hdmi on tm2 devices) via i2c bus.
Oh okay. So, the MHL writes it into some sort of flash, which exynos_hdmi
can access via an i2c master?
With some modifications SiI8620 could act as connector and do mode
population itself, it would require modification of exynos_hdmi, and the
main drawback is that modes unsupported by exynos_hdmi would not be
filtered out (as mode filtering is done in connector).
Yeah, I guess if exynos_hdmi as a drm_encoder wouldn't be able to drop
modes. The best it could do is return an error in mode_fixup.
Anyway, since there seems to be only one kms user for the sil8620
driver, I think we can leave it for later.
Btw, the patchset looks fine to me. It'd be great if you could have
slightly more descriptive commit messages for some of the patches.
Thanks,
Archit
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
