All of lore.kernel.org
 help / color / mirror / Atom feed
From: Archit Taneja <archit@ti.com>
To: Rob Clark <robdclark@gmail.com>, tomi.valkeinen@ti.com
Cc: linux-omap@vger.kernel.org, dri-devel@lists.freedesktop.org,
	greg@kroah.com
Subject: Re: [PATCH] omapdrm: Make fixed resolution panels work
Date: Mon, 18 Feb 2013 12:53:49 +0530	[thread overview]
Message-ID: <5121D705.6040908@ti.com> (raw)
In-Reply-To: <CAF6AEGvgQxYtV=FD_B29LCONALSieR+PWVpgOD0Wn4SM88zn2g@mail.gmail.com>

On Thursday 14 February 2013 09:24 PM, Rob Clark wrote:
> On Thu, Feb 14, 2013 at 6:52 AM, Archit Taneja <archit@ti.com> 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.
>>
>> I tested this with picodlp on a OMAP4 sdp board. I couldn't get any other
>> working boards with fixed DPI panels. I could try the DSI video mode panel
>> on an OMAP5 sevm, but that will require me to patch a lot of things to get
>> omap5 dss work with DT. I can try if needed.
>>
>> Signed-off-by: Archit Taneja <archit@ti.com>
>> ---
>>   drivers/staging/omapdrm/omap_connector.c |   10 ++++++++--
>>   drivers/staging/omapdrm/omap_encoder.c   |    6 ++++--
>>   2 files changed, 12 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/staging/omapdrm/omap_connector.c b/drivers/staging/omapdrm/omap_connector.c
>> index 4cc9ee7..839c6e4 100644
>> --- a/drivers/staging/omapdrm/omap_connector.c
>> +++ b/drivers/staging/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;
>
> hmm, why not just have a default detect fxn for panel drivers which
> always returns true?  Seems a bit cleaner.. otherwise, I guess we
> could just change omap_connector so that if dssdev->detect is null,
> assume always connected.  Seems maybe a slightly better way since
> currently omap_connector doesn't really know too much about different
> sorts of panels.  But I'm not too picky if that is a big pain because
> we probably end up changing all this as CFP starts coming into
> existence.
>
> Same goes for check_timings/set_timings..  it seems a bit cleaner just
> to have default fxns in the panel drivers that do-the-right-thing,
> although I suppose it might be a bit more convenient for out-of-tree
> panel drivers to just assume fixed panel if these fxns are null.

Maybe having default functions in omapdss might be a better idea. There 
is an option of adding default functions in omap_dss_register_driver() 
(drivers/video/omap2/dss/core.c).

Tomi, do you think it's fine to add some more default panel driver funcs?

Archit

>
> BR,
> -R
>
>>          } else {
>>                  ret = connector_status_unknown;
>>          }
>> @@ -189,12 +194,13 @@ static int omap_connector_mode_valid(struct drm_connector *connector,
>>          struct omap_video_timings timings = {0};
>>          struct drm_device *dev = connector->dev;
>>          struct drm_display_mode *new_mode;
>> -       int ret = MODE_BAD;
>> +       int r, ret = MODE_BAD;
>>
>>          copy_timings_drm_to_omap(&timings, mode);
>>          mode->vrefresh = drm_mode_vrefresh(mode);
>>
>> -       if (!dssdrv->check_timings(dssdev, &timings)) {
>> +       r = dssdrv->check_timings ? dssdrv->check_timings(dssdev, &timings) : 0;
>> +       if (!r) {
>>                  /* check if vrefresh is still valid */
>>                  new_mode = drm_mode_duplicate(dev, mode);
>>                  new_mode->clock = timings.pixel_clock;
>> diff --git a/drivers/staging/omapdrm/omap_encoder.c b/drivers/staging/omapdrm/omap_encoder.c
>> index e053160..871af12e 100644
>> --- a/drivers/staging/omapdrm/omap_encoder.c
>> +++ b/drivers/staging/omapdrm/omap_encoder.c
>> @@ -128,13 +128,15 @@ int omap_encoder_update(struct drm_encoder *encoder,
>>
>>          dssdev->output->manager = mgr;
>>
>> -       ret = dssdrv->check_timings(dssdev, timings);
>> +       ret = dssdrv->check_timings ?
>> +               dssdrv->check_timings(dssdev, timings) : 0;
>>          if (ret) {
>>                  dev_err(dev->dev, "could not set timings: %d\n", ret);
>>                  return ret;
>>          }
>>
>> -       dssdrv->set_timings(dssdev, timings);
>> +       if (dssdrv->set_timings)
>> +               dssdrv->set_timings(dssdev, timings);
>>
>>          return 0;
>>   }
>> --
>> 1.7.9.5
>>
>


  reply	other threads:[~2013-02-18  7:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-14 11:52 [PATCH] omapdrm: Make fixed resolution panels work Archit Taneja
2013-02-14 15:54 ` Rob Clark
2013-02-18  7:23   ` Archit Taneja [this message]
2013-02-18  8:31     ` Tomi Valkeinen
2013-02-18 11:30       ` 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=5121D705.6040908@ti.com \
    --to=archit@ti.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=greg@kroah.com \
    --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 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.