linux-kernel - Re: [PATCH 0/5] Add tda998x (HDMI) support to atmel-hlcdc

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]

Message-ID: <bbc7a992-5f17-c108-2b6a-01a585e6e315@axentia.se>
Date:   Mon, 9 Apr 2018 13:44:22 +0200
From:   Peter Rosin <peda@...ntia.se>
To:     Russell King - ARM Linux <linux@...linux.org.uk>
Cc:     linux-kernel@...r.kernel.org, Mark Rutland <mark.rutland@....com>,
        Boris Brezillon <boris.brezillon@...e-electrons.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        devicetree@...r.kernel.org, David Airlie <airlied@...ux.ie>,
        dri-devel@...ts.freedesktop.org, Rob Herring <robh+dt@...nel.org>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 0/5] Add tda998x (HDMI) support to atmel-hlcdc

On 2018-04-09 13:17, Russell King - ARM Linux wrote:
> On Mon, Apr 09, 2018 at 12:59:13PM +0200, Peter Rosin wrote:
>> During this, I found that the tda998x driver never sets the format in
>> the connector display_info. Thus, the atmel-hlcdc driver fails to select
>> output format. Since I had similar problems with ds90c185 lvds encoder
>> I added patches to override the atmel-hlcdc output format via a DT
>> property and things start to play together.
> 
> That sounds like a hack.  The tda998x driver doesn't set the format
> because it pre-dates the addition of this information in the display
> info structure, and none of its current users require that information.
> 
> As you're the first to require it, rather than working around the
> driver by adding stuff to DT, it would be much better to improve the
> driver by adding this information.
> 
> Thanks.

Even if I improved the tda998x driver, it would not be correct.

The background is that while the atmel-hlcdc driver supports rgb888,
our PCB is only wired for rgb565. And the tda19988 has rgb888 input
(we have the lsb bits tied to ground on our PCB). So, the tda998x
driver can request rgb888 and the atmel-hlcdc driver can say ok,
but it still would not be correct. So, where exactly do you suggest
that I model the narrowing of the display format?

Cheers,
Peter