From: Mark Zhang <nvmarkzhang@gmail.com>
To: Alexandre Courbot <gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
Laurent Pinchart
<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>,
Thierry Reding
<thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>,
Mark Zhang <markz-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
Linux Kernel Mailing List
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org"
<acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Subject: Re: [RFC 1/4] video: panel: add CLAA101WA01A panel support
Date: Thu, 31 Jan 2013 07:30:52 +0000 [thread overview]
Message-ID: <510A1DAC.1070106@gmail.com> (raw)
In-Reply-To: <CAAVeFuL_a1aAEDCFdhjMzZG40QuK3dcZqsWqfVpwmQbZsfiHRg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 01/31/2013 02:36 PM, Alexandre Courbot wrote:
> On Thu, Jan 31, 2013 at 1:54 PM, Mark Zhang <nvmarkzhang@gmail.com> wrote:
>> Display controller don't know whether the panel has EDID EEPROM but the
>> panel driver knows. So why we need to make display controller queries
>> EDID blindly? Since panel driver knows about all "video modes/panel
>> size" stuffs, why not we let it handle all these things?
>
> The DC actually does know whether the connected panel supports EDID -
> in this case, the output node will have a property for the DDC bus,
> e.g.
>
> nvidia,ddc-i2c-bus = <&lcd_ddc>;
>
> If no DDC bus is specified or if transfer fails, the DC driver can
> still query the panel driver for hardcoded modes.
>
Strictly speaking, according to my understanding, "nvidia,ddc-i2c-bus"
means tegra has a hardware ddc channel, this doesn't mean we can get the
EDID from this DDC surely.
> Also passing a function pointer to get_modes() does not relief the DC
> driver from probing for the DDC bus. You will still have to handle
> both conditions (DDC bus present or not), the check will just be moved
> into your callback function.
>
Yes. But panel driver decides whether the DDC probing is needed. If the
panel has an EEPROM, it can call the function which display controller
provides to do a DDC probing, it not, panel driver just ignores this
function pointer and return the hardcoded modes directly.
> Alex.
>
WARNING: multiple messages have this Message-ID (diff)
From: Mark Zhang <nvmarkzhang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Alexandre Courbot <gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
Laurent Pinchart
<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>,
Thierry Reding
<thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>,
Mark Zhang <markz-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
Linux Kernel Mailing List
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org"
<acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Subject: Re: [RFC 1/4] video: panel: add CLAA101WA01A panel support
Date: Thu, 31 Jan 2013 15:30:52 +0800 [thread overview]
Message-ID: <510A1DAC.1070106@gmail.com> (raw)
In-Reply-To: <CAAVeFuL_a1aAEDCFdhjMzZG40QuK3dcZqsWqfVpwmQbZsfiHRg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 01/31/2013 02:36 PM, Alexandre Courbot wrote:
> On Thu, Jan 31, 2013 at 1:54 PM, Mark Zhang <nvmarkzhang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> Display controller don't know whether the panel has EDID EEPROM but the
>> panel driver knows. So why we need to make display controller queries
>> EDID blindly? Since panel driver knows about all "video modes/panel
>> size" stuffs, why not we let it handle all these things?
>
> The DC actually does know whether the connected panel supports EDID -
> in this case, the output node will have a property for the DDC bus,
> e.g.
>
> nvidia,ddc-i2c-bus = <&lcd_ddc>;
>
> If no DDC bus is specified or if transfer fails, the DC driver can
> still query the panel driver for hardcoded modes.
>
Strictly speaking, according to my understanding, "nvidia,ddc-i2c-bus"
means tegra has a hardware ddc channel, this doesn't mean we can get the
EDID from this DDC surely.
> Also passing a function pointer to get_modes() does not relief the DC
> driver from probing for the DDC bus. You will still have to handle
> both conditions (DDC bus present or not), the check will just be moved
> into your callback function.
>
Yes. But panel driver decides whether the DDC probing is needed. If the
panel has an EEPROM, it can call the function which display controller
provides to do a DDC probing, it not, panel driver just ignores this
function pointer and return the hardcoded modes directly.
> Alex.
>
WARNING: multiple messages have this Message-ID (diff)
From: Mark Zhang <nvmarkzhang@gmail.com>
To: Alexandre Courbot <gnurou@gmail.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Thierry Reding <thierry.reding@avionic-design.de>,
Mark Zhang <markz@nvidia.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
"acourbot@nvidia.com" <acourbot@nvidia.com>
Subject: Re: [RFC 1/4] video: panel: add CLAA101WA01A panel support
Date: Thu, 31 Jan 2013 15:30:52 +0800 [thread overview]
Message-ID: <510A1DAC.1070106@gmail.com> (raw)
In-Reply-To: <CAAVeFuL_a1aAEDCFdhjMzZG40QuK3dcZqsWqfVpwmQbZsfiHRg@mail.gmail.com>
On 01/31/2013 02:36 PM, Alexandre Courbot wrote:
> On Thu, Jan 31, 2013 at 1:54 PM, Mark Zhang <nvmarkzhang@gmail.com> wrote:
>> Display controller don't know whether the panel has EDID EEPROM but the
>> panel driver knows. So why we need to make display controller queries
>> EDID blindly? Since panel driver knows about all "video modes/panel
>> size" stuffs, why not we let it handle all these things?
>
> The DC actually does know whether the connected panel supports EDID -
> in this case, the output node will have a property for the DDC bus,
> e.g.
>
> nvidia,ddc-i2c-bus = <&lcd_ddc>;
>
> If no DDC bus is specified or if transfer fails, the DC driver can
> still query the panel driver for hardcoded modes.
>
Strictly speaking, according to my understanding, "nvidia,ddc-i2c-bus"
means tegra has a hardware ddc channel, this doesn't mean we can get the
EDID from this DDC surely.
> Also passing a function pointer to get_modes() does not relief the DC
> driver from probing for the DDC bus. You will still have to handle
> both conditions (DDC bus present or not), the check will just be moved
> into your callback function.
>
Yes. But panel driver decides whether the DDC probing is needed. If the
panel has an EEPROM, it can call the function which display controller
provides to do a DDC probing, it not, panel driver just ignores this
function pointer and return the hardcoded modes directly.
> Alex.
>
next prev parent reply other threads:[~2013-01-31 7:30 UTC|newest]
Thread overview: 86+ 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 ` Alexandre Courbot
2013-01-30 3:02 ` Alexandre Courbot
2013-01-30 3:02 ` [RFC 1/4] video: panel: add CLAA101WA01A panel support Alexandre Courbot
2013-01-30 3:02 ` Alexandre Courbot
2013-01-30 3:02 ` Alexandre Courbot
2013-01-30 7:20 ` Mark Zhang
2013-01-30 7:20 ` Mark Zhang
[not found] ` <5108C9C1.1090707-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-01-30 7:27 ` Alex Courbot
2013-01-30 7:27 ` Alex Courbot
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 7:48 ` Thierry Reding
2013-01-30 7:48 ` Thierry Reding
2013-01-30 8:08 ` Mark Zhang
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 8:28 ` Alex Courbot
2013-01-30 8:28 ` Alex Courbot
2013-01-30 20:19 ` Stephen Warren
2013-01-30 20:19 ` Stephen Warren
2013-01-30 20:19 ` Stephen Warren
[not found] ` <51098064.7030902-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-01-31 3:51 ` Mark Zhang
2013-01-31 3:51 ` Mark Zhang
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:24 ` Alexandre Courbot
2013-01-31 4:24 ` Alexandre Courbot
2013-01-31 4:54 ` Mark Zhang
2013-01-31 4:54 ` Mark Zhang
2013-01-31 6:36 ` Alexandre Courbot
2013-01-31 6:36 ` Alexandre Courbot
[not found] ` <CAAVeFuL_a1aAEDCFdhjMzZG40QuK3dcZqsWqfVpwmQbZsfiHRg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-01-31 7:30 ` Mark Zhang [this message]
2013-01-31 7:30 ` Mark Zhang
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:25 ` Stephen Warren
2013-01-31 17:25 ` Stephen Warren
2013-01-31 17:20 ` Stephen Warren
2013-01-31 17:20 ` Stephen Warren
[not found] ` <510AA7F8.7070000-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-02-01 4:19 ` Mark Zhang
2013-02-01 4:19 ` Mark Zhang
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
2013-01-30 20:27 ` Stephen Warren
2013-01-30 20:27 ` Stephen Warren
[not found] ` <51098229.7080508-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-01-31 4:14 ` Alexandre Courbot
2013-01-31 4:14 ` Alexandre Courbot
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-31 17:23 ` Stephen Warren
2013-01-31 17:23 ` Stephen Warren
2013-01-30 20:30 ` Stephen Warren
2013-01-30 20:30 ` 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
2013-01-30 3:02 ` Alexandre Courbot
2013-01-30 3:02 ` Alexandre Courbot
2013-01-30 3:02 ` [RFC 4/4] tegra: enable CDF and claa101 panel Alexandre Courbot
2013-01-30 3:02 ` Alexandre Courbot
2013-01-30 3:02 ` 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
2013-01-30 3:02 ` Alexandre Courbot
2013-01-30 3:02 ` 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 6:50 ` Mark Zhang
2013-01-30 6:50 ` Mark Zhang
2013-01-30 7:01 ` Alex Courbot
2013-01-30 7:01 ` Alex Courbot
[not found] ` <5108C55C.30104-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-01-30 7:24 ` Thierry Reding
2013-01-30 7:24 ` Thierry Reding
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:30 ` Alex Courbot
2013-01-30 7:30 ` Alex Courbot
2013-01-30 7:46 ` Mark Zhang
2013-01-30 7:46 ` Mark Zhang
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
2013-01-30 7:40 ` Thierry Reding
2013-01-30 7:40 ` Thierry Reding
[not found] ` <20130130074020.GA17547-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org>
2013-01-30 8:23 ` Alex Courbot
2013-01-30 8:23 ` Alex Courbot
2013-01-30 8:23 ` Alex Courbot
2013-01-30 8:38 ` Sascha Hauer
2013-01-30 8:38 ` Sascha Hauer
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=510A1DAC.1070106@gmail.com \
--to=nvmarkzhang@gmail.com \
--cc=acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org \
--cc=linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=markz-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
--cc=thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.