From: Mark Zhang <nvmarkzhang@gmail.com>
To: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
Cc: Alexandre Courbot
<acourbot-DDmLM1+adcrQT0dZR+AlfA@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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Subject: Re: [RFC 1/4] video: panel: add CLAA101WA01A panel support
Date: Fri, 01 Feb 2013 04:19:39 +0000 [thread overview]
Message-ID: <510B425B.1040807@gmail.com> (raw)
In-Reply-To: <510AA7F8.7070000-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
On 02/01/2013 01:20 AM, Stephen Warren wrote:
> 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.
>
Ah, yes, this is right. We can't write driver for every external monitor
which implements EDID. Although I think it's more reasonable that panel
decides whether the DDC probe is necessary.
> 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.
>
WARNING: multiple messages have this Message-ID (diff)
From: Mark Zhang <nvmarkzhang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
Cc: Alexandre Courbot
<acourbot-DDmLM1+adcrQT0dZR+AlfA@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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Subject: Re: [RFC 1/4] video: panel: add CLAA101WA01A panel support
Date: Fri, 01 Feb 2013 12:19:39 +0800 [thread overview]
Message-ID: <510B425B.1040807@gmail.com> (raw)
In-Reply-To: <510AA7F8.7070000-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
On 02/01/2013 01:20 AM, Stephen Warren wrote:
> 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.
>
Ah, yes, this is right. We can't write driver for every external monitor
which implements EDID. Although I think it's more reasonable that panel
decides whether the DDC probe is necessary.
> 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.
>
WARNING: multiple messages have this Message-ID (diff)
From: Mark Zhang <nvmarkzhang@gmail.com>
To: Stephen Warren <swarren@wwwdotorg.org>
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: Fri, 01 Feb 2013 12:19:39 +0800 [thread overview]
Message-ID: <510B425B.1040807@gmail.com> (raw)
In-Reply-To: <510AA7F8.7070000@wwwdotorg.org>
On 02/01/2013 01:20 AM, Stephen Warren wrote:
> 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.
>
Ah, yes, this is right. We can't write driver for every external monitor
which implements EDID. Although I think it's more reasonable that panel
decides whether the DDC probe is necessary.
> 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.
>
next prev parent reply other threads:[~2013-02-01 4:19 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
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 [this message]
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=510B425B.1040807@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.