lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 7 Jun 2021 08:48:19 -0700 From: Tim Harvey <tharvey@...eworks.com> To: Krzysztof Hałasa <khalasa@...p.pl> Cc: Hans Verkuil <hverkuil@...all.nl>, Mauro Carvalho Chehab <mchehab@...nel.org>, linux-media <linux-media@...r.kernel.org>, lkml <linux-kernel@...r.kernel.org> Subject: Re: [PATCH] TDA1997x: enable EDID support On Mon, Jun 7, 2021 at 4:56 AM Krzysztof Hałasa <khalasa@...p.pl> wrote: > > Hi Hans, > > Hans Verkuil <hverkuil@...all.nl> writes: > > >> Without this patch, the TDA19971 chip's EDID is inactive. > > > > Was this wrong from the very beginning? How can this ever have been tested > > without an EDID? > > It seems so. I suspect it might have worked in tests because this > register isn't cleared on reboot. I.e., setting it once after power up > makes it work to the next power up. > Or, maybe, the HDMI signal source didn't need EDID. > Krzysztof, Most likely it was that the HDMI signal source I tested with didn't need EDID. I primarily used a V-SG4K HMDI signal generator in my testing and development of the driver (http://www.marshall-usa.com/monitors/model/V-SG4K-HDI.php) which definitely doesn't need it. Other devices I tested with were another Gateworks board with HDMI out (which also didn't need EDID) and occasionally a 1st gen Google Chromecast and Amazon Fire stick (which I'm not sure about). > I'm looking at the previous version of this driver from Gateworks and it > contains: > > /* Configure EDID > * > * EDID_ENABLE bits: > * 7 - nack_off > * 6 - edid_only > * 1 - edid_b_en > * 0 - edid_a_en > */ > reg = io_read(REG_EDID_ENABLE); > if (!tda1997x->internal_edid) > reg &= ~0x83; /* EDID Nack ON */ > else > reg |= 0x83; /* EDID Nack OFF */ > io_write(REG_EDID_ENABLE, reg); > > Not sure what the "non-internal" EDID could be - a separate I2C EEPROM > chip? I'm using this on Gateworks' GW54xx boards and I can't see any > such EEPROM in the vicinity of the TDA19971, but I don't know how it is > wired - perhaps Tim has some idea? Not sure where the source above is from (this was all so long ago) but my guess is that 'internal_edid' meant an EDID had been provided via software and the else case meant there was no EDID available. There is no support on that chip for an external EEPROM. Tim
Powered by blists - more mailing lists