All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm: Avoid forcing a detection cycle following a hotplug event
Date: Wed, 19 Jun 2013 00:37:15 +0200	[thread overview]
Message-ID: <4133723.b76XIp3Fxx@avalon> (raw)
In-Reply-To: <20130608075330.GA7325@cantiga.alporthouse.com>

Hi Chris,

On Saturday 08 June 2013 08:53:30 Chris Wilson wrote:
> On Sat, Jun 08, 2013 at 09:28:17AM +0200, Laurent Pinchart wrote:
> > Could you please also update Documentation/DocBook/drm.tmpl ?
> 
> It looks out of context there, as nothing explains the hotplug ->
> fill_modes -> probe -> detect loop...

Sorry, I should have been more precise. You patches changes the prototype of 
the fill_modes() operation and the drm_helper_probe_single_connector_modes() 
function, documented in drm.tmpl. I'd like to keep the documentation in sync.

> 
> How about:
> 
>   <title>Modes</title>
>   <synopsis>int (*fill_modes)(struct drm_connector *connector, uint32_t
> max_width, uint32_t max_height, bool force);</synopsis>
>   <para>
>     Fill the mode list with all supported modes for the connector. If the
>     <parameter>max_width</parameter> and <parameter>max_height</parameter>
>     arguments are non-zero, the implementation must ignore all modes wider
>     than <parameter>max_width</parameter> or higher than
>     <parameter>max_height</parameter>. The driver may use the existing
>     connector status, unless <parameter>force</parameter> is passed. During
> a hotplug event, the driver may already have updated its knowledge of the
> output and so may simply refresh the modes list from the information it
> acquired whilst handling the event. However, the caller may explicitly
> request that any cached information be dropped, and for the output to be
> queried for its current status and modes - under such circumstances
> <parameter>force</parameter> is true.
>   </para>

That looks good to me (I would split this in two paragraphs, but that's just 
nitpicking).

Could you please also update the drm_helper_probe_single_connector_modes() 
description in drm.tmpl ?

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2013-06-18 22:37 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-05 15:50 [PATCH] drm: Avoid forcing a detection cycle following a hotplug event Chris Wilson
2013-06-08  7:28 ` Laurent Pinchart
2013-06-08  7:53   ` Chris Wilson
2013-06-18 22:37     ` Laurent Pinchart [this message]
2013-06-08 13:30 ` Daniel Vetter

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=4133723.b76XIp3Fxx@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=dri-devel@lists.freedesktop.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.