linux-kernel - Re: [RFC 1/4] video: panel: add CLAA101WA01A panel support

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: <510AA7F8.7070000@wwwdotorg.org>
Date:	Thu, 31 Jan 2013 10:20:56 -0700
From:	Stephen Warren <swarren@...dotorg.org>
To:	Mark Zhang <nvmarkzhang@...il.com>
CC:	Alexandre Courbot <acourbot@...dia.com>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Thierry Reding <thierry.reding@...onic-design.de>,
	Mark Zhang <markz@...dia.com>, linux-kernel@...r.kernel.org,
	linux-fbdev@...r.kernel.org, linux-tegra@...r.kernel.org,
	gnurou@...il.com
Subject: Re: [RFC 1/4] video: panel: add CLAA101WA01A panel support

On 01/30/2013 08:51 PM, Mark Zhang wrote:
> On 01/31/2013 04:19 AM, Stephen Warren wrote:
>> On 01/30/2013 12:20 AM, Mark Zhang wrote:
>>> On 01/30/2013 11:02 AM, Alexandre Courbot wrote:
>>>> Add support for the Chunghwa CLAA101WA01A display panel.
>>
>>>> +static int panel_claa101_get_modes(struct display_entity *entity,
>>>> +				   const struct videomode **modes)
>>>> +{
>>>> +	/* TODO get modes from EDID? */
>>>
>>> Why not move the "nvidia,ddc" from encoder's DT to panel's DT? In that
>>> case, you can get EDID here. I know drm has some helpers to fetch EDID
>>> but I recall there are some other functions which has no drm
>>> dependencies which may be suitable for you.
>>
>> DDC access is a property of the display controller, not the panel
>> itself. The panel might be hooked up to a display controller's DDC/I2C
>> channel as the target, but it isn't the host/controller of the DDC/I2C
>> channel. As such, placing the nvidia,ddc property into the display
>> controller node makes sense.
> 
> Yes, DC triggers the DDC access and is the host of the DDC/I2C channel.
> So I think it's reasonable to put nvidia,ddc property into the display
> controller node. But the video mode info in EDID which be fetched via
> DDC is the property of the panel, so this info should be provided by
> panel driver.

No, that makes absolutely no sense at all in the EDID case.

By the same argument, we'd need a panel driver for every external
monitor which implemented EDID, just to transfer the EDID results from
the display controller's DDC channel into the panel driver and back into
the display controller code, which wants the mode list.

Again, if the mode list is coming from DDC, the display controller
should retrieve it in exactly the same way it retrieves it for any
external monitor - by direct control of the DDC channel to read the
EDID. The only time it makes sense for the panel driver to get involved
in supplying the mode list is when there's no EDID, so the list must be
hard-coded into the driver.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/