From: Archit Taneja <archit@ti.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: robdclark@gmail.com, andy.gross@ti.com,
linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v3 3/8] drm/omap: Make fixed resolution panels work
Date: Wed, 27 Mar 2013 07:47:22 +0000 [thread overview]
Message-ID: <5152A13A.7060805@ti.com> (raw)
In-Reply-To: <51529EC2.4040403@ti.com>
On Wednesday 27 March 2013 12:54 PM, Tomi Valkeinen wrote:
> On 2013-03-26 15:45, Archit Taneja wrote:
>> The omapdrm driver requires omapdss panel drivers to expose ops like detect,
>> set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
>> and SDI drivers. At some places, there are no checks to see if the panel driver
>> has these ops or not, and that leads to a crash.
>>
>> The following things are done to make fixed panels work:
>>
>> - The omap_connector's detect function is modified such that it considers panel
>> types which are generally fixed panels as always connected(provided the panel
>> driver doesn't have a detect op). Hence, the connector corresponding to these
>> panels is always in a 'connected' state.
>>
>> - If a panel driver doesn't have a check_timings op, assume that it supports the
>> mode passed to omap_connector_mode_valid(the 'mode_valid' drm helper function)
>>
>> - The function omap_encoder_update shouldn't really do anything for fixed
>> resolution panels, make sure that it calls set_timings only if the panel
>> driver has one.
>>
>> Signed-off-by: Archit Taneja <archit@ti.com>
>> ---
>> v3: clear the timings local variable first before using memcmp
>> v2: make sure the timings we try to set for a fixed resolution panel match the
>> panel's timings
>>
>> drivers/gpu/drm/omapdrm/omap_connector.c | 27 +++++++++++++++++++++++++--
>> drivers/gpu/drm/omapdrm/omap_encoder.c | 17 +++++++++++++++--
>> 2 files changed, 40 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c b/drivers/gpu/drm/omapdrm/omap_connector.c
>> index c451c41..912759d 100644
>> --- a/drivers/gpu/drm/omapdrm/omap_connector.c
>> +++ b/drivers/gpu/drm/omapdrm/omap_connector.c
>> @@ -110,6 +110,11 @@ static enum drm_connector_status omap_connector_detect(
>> ret = connector_status_connected;
>> else
>> ret = connector_status_disconnected;
>> + } else if (dssdev->type = OMAP_DISPLAY_TYPE_DPI ||
>> + dssdev->type = OMAP_DISPLAY_TYPE_DBI ||
>> + dssdev->type = OMAP_DISPLAY_TYPE_SDI ||
>> + dssdev->type = OMAP_DISPLAY_TYPE_DSI) {
>> + ret = connector_status_connected;
>> } else {
>> ret = connector_status_unknown;
>> }
>
> Can we leave this part out? I don't like hardcoding things like that,
> and if I'm not mistaken, this only affects VENC.
>
> If the code above would use detect where available, and presume the
> panel is connected in other cases, it'll be right for all other displays
> but VENC, for which we have no connect information.
>
> Or, there could be a special case for VENC, like above, which sets the
> connector status to unknown for that. And connected for all others. It'd
> still be hardcoded, but for much less cases.
I guess we can leave the status for VENC as always connected too, if we
leave it as unknown by default and have no detect func for VENC, it
would never run with omapdrm.
Archit
next prev parent reply other threads:[~2013-03-27 7:47 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1362493070-17706-1-git-send-email-archit@ti.com>
2013-03-26 13:57 ` [PATCH v2 0/8] omapdss/omapdrm: Misc fixes and improvements Archit Taneja
2013-03-26 13:57 ` [PATCH v2 1/8] drm/omap: Don't return from modeset_init if a panel doesn't satisfy omapdrm requireme Archit Taneja
2013-03-26 13:57 ` [PATCH v2 2/8] drm/omap: Fix and improve crtc and overlay manager correlation Archit Taneja
2013-03-26 13:57 ` [PATCH v3 3/8] drm/omap: Make fixed resolution panels work Archit Taneja
2013-03-27 7:24 ` Tomi Valkeinen
2013-03-27 7:47 ` Archit Taneja [this message]
2013-03-26 13:57 ` [PATCH v2 4/8] omapdss: features: fixed supported outputs for OMAP4 Archit Taneja
2013-03-26 13:57 ` [PATCH v2 5/8] omapdss: DISPC: add max pixel clock limits for LCD and TV managers Archit Taneja
2013-03-27 7:30 ` Tomi Valkeinen
2013-03-27 7:48 ` Archit Taneja
2013-03-26 13:57 ` [PATCH v2 6/8] omapdss: Features: Fix some parameter ranges Archit Taneja
2013-03-27 7:33 ` Tomi Valkeinen
2013-03-27 7:50 ` Archit Taneja
2013-03-26 13:57 ` [PATCH v2 7/8] OMAPDSS: DISPC: Configure doublestride for NV12 when using 2D Tiler buffers Archit Taneja
2013-03-26 13:57 ` [PATCH v2 8/8] OMAPDSS: DISPC: Revert to older DISPC Smart Standby mechanism for OMAP5 Archit Taneja
2013-03-27 7:54 ` [PATCH v2 0/8] omapdss/omapdrm: Misc fixes and improvements Tomi Valkeinen
2013-03-27 8:47 ` Archit Taneja
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=5152A13A.7060805@ti.com \
--to=archit@ti.com \
--cc=andy.gross@ti.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=robdclark@gmail.com \
--cc=tomi.valkeinen@ti.com \
/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).