linux-tegra.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: Mark Zhang <nvmarkzhang@gmail.com>
Cc: Alexandre Courbot <acourbot@nvidia.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Thierry Reding <thierry.reding@avionic-design.de>,
	Mark Zhang <markz@nvidia.com>,
	linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org,
	linux-tegra@vger.kernel.org, gnurou@gmail.com
Subject: Re: [RFC 1/4] video: panel: add CLAA101WA01A panel support
Date: Thu, 31 Jan 2013 10:20:56 -0700	[thread overview]
Message-ID: <510AA7F8.7070000@wwwdotorg.org> (raw)
In-Reply-To: <5109EA2A.8020204@gmail.com>

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.

  parent reply	other threads:[~2013-01-31 17:20 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-30  3:02 [RFC 0/4] Use the Common Display Framework in tegra-drm Alexandre Courbot
2013-01-30  3:02 ` [RFC 1/4] video: panel: add CLAA101WA01A panel support Alexandre Courbot
2013-01-30  7:20   ` Mark Zhang
     [not found]     ` <5108C9C1.1090707-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-01-30  7:27       ` Alex Courbot
     [not found]         ` <5108CB4F.7000103-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-01-30  7:48           ` Thierry Reding
2013-01-30  8:08             ` Mark Zhang
     [not found]             ` <20130130074852.GB17547-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org>
2013-01-30  8:28               ` Alex Courbot
2013-01-30 20:19       ` Stephen Warren
     [not found]         ` <51098064.7030902-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-01-31  3:51           ` Mark Zhang
     [not found]             ` <5109EA2A.8020204-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-01-31  4:24               ` Alexandre Courbot
2013-01-31  4:54                 ` Mark Zhang
2013-01-31  6:36                   ` Alexandre Courbot
     [not found]                     ` <CAAVeFuL_a1aAEDCFdhjMzZG40QuK3dcZqsWqfVpwmQbZsfiHRg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-01-31  7:30                       ` Mark Zhang
     [not found]                         ` <510A1DAC.1070106-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-01-31 17:25                           ` Stephen Warren
2013-01-31 17:20             ` Stephen Warren [this message]
     [not found]               ` <510AA7F8.7070000-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-02-01  4:19                 ` Mark Zhang
     [not found]   ` <1359514939-15653-2-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-01-30 20:27     ` Stephen Warren
     [not found]       ` <51098229.7080508-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-01-31  4:14         ` Alexandre Courbot
     [not found]           ` <CAAVeFuJkJ4cftWvSvt1YJa6c48JyJPVTu=i18yMHptZMi3DAzg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-01-31 17:23             ` Stephen Warren
2013-01-30 20:30     ` Stephen Warren
2013-01-30  3:02 ` [RFC 2/4] tegra: ventana: add display and backlight DT nodes Alexandre Courbot
     [not found] ` <1359514939-15653-1-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-01-30  3:02   ` [RFC 3/4] drm: tegra: use the Common Display Framework Alexandre Courbot
     [not found]     ` <1359514939-15653-4-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-01-30  6:50       ` Mark Zhang
2013-01-30  7:01         ` Alex Courbot
     [not found]           ` <5108C55C.30104-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-01-30  7:24             ` Thierry Reding
     [not found]               ` <20130130072406.GA17128-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org>
2013-01-30  7:30                 ` Alex Courbot
2013-01-30  7:46             ` Mark Zhang
2013-01-30  7:40   ` [RFC 0/4] Use the Common Display Framework in tegra-drm Thierry Reding
     [not found]     ` <20130130074020.GA17547-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org>
2013-01-30  8:23       ` Alex Courbot
2013-01-30  8:38         ` Sascha Hauer
2013-01-30  3:02 ` [RFC 4/4] tegra: enable CDF and claa101 panel Alexandre Courbot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=510AA7F8.7070000@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=acourbot@nvidia.com \
    --cc=gnurou@gmail.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=markz@nvidia.com \
    --cc=nvmarkzhang@gmail.com \
    --cc=thierry.reding@avionic-design.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).