linux-kernel - Re: [RFC 0/4] Use the Common Display Framework in tegra-drm

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: <20130130083809.GU1906@pengutronix.de>
Date:	Wed, 30 Jan 2013 09:38:09 +0100
From:	Sascha Hauer <s.hauer@...gutronix.de>
To:	Alex Courbot <acourbot@...dia.com>
Cc:	Thierry Reding <thierry.reding@...onic-design.de>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Stephen Warren <swarren@...dotorg.org>,
	Mark Zhang <markz@...dia.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-fbdev@...r.kernel.org" <linux-fbdev@...r.kernel.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	"gnurou@...il.com" <gnurou@...il.com>
Subject: Re: [RFC 0/4] Use the Common Display Framework in tegra-drm

On Wed, Jan 30, 2013 at 05:23:01PM +0900, Alex Courbot wrote:
> On 01/30/2013 04:40 PM, Thierry Reding wrote:
> >Thanks *a lot* for taking care of this Alexandre! From a quick look at
> >the patches they seem generally fine. I'll go over them in a bit more
> >detail though.
> 
> Glad you like it better than my previous attempts at controlling
> Tegra's panels and backlights. ;)
> 
> >>1) The CDF has a get_modes() hook, but this is already implemented by
> >>tegra_connector_get_modes(). Ideally everything should be moved to the CDF hook,
> >>but Tegra's implementation uses DRM functions to retrieve the EDID and CDF
> >>should, AFAIK, remain DRM-agnostic.
> >
> >Maybe a good option would be to just not implement get_modes() if the
> >same information can be retrieved via EDID. That is, the DRM driver
> >could just go and fetch EDID when the nvidia,ddc-i2c-bus is available
> >(or parse the nvidia,edid blob) and only rely on CDF otherwise.
> 
> Since EDID information is per-panel I'd intuitively say it should be
> provided by the panel driver.

Hm. If you know from the devicetree that you have a CLAA101WA01A then
you won't need EDID data at all. If instead you have EDID data you don't
have to put the information that this is a CLAA101WA01A into devicetree.

I think the next thing that will happen is that you want to use the EDID
data to 1) pick display timings 2) pick the right power sequence that
fits the panel found in EDID. You can't archieve 2) by hardcoding the
panel in the devicetree.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--
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/