[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAVeFuL_a1aAEDCFdhjMzZG40QuK3dcZqsWqfVpwmQbZsfiHRg@mail.gmail.com>
Date: Thu, 31 Jan 2013 15:36:57 +0900
From: Alexandre Courbot <gnurou@...il.com>
To: Mark Zhang <nvmarkzhang@...il.com>
Cc: Stephen Warren <swarren@...dotorg.org>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Thierry Reding <thierry.reding@...onic-design.de>,
Mark Zhang <markz@...dia.com>,
Linux Kernel Mailing List <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>,
"acourbot@...dia.com" <acourbot@...dia.com>
Subject: Re: [RFC 1/4] video: panel: add CLAA101WA01A panel support
On Thu, Jan 31, 2013 at 1:54 PM, Mark Zhang <nvmarkzhang@...il.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.
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.
Alex.
--
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/
Powered by blists - more mailing lists