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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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