From: Jani Nikula <jani.nikula@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915/tv: Cleanup up obsolete comments
Date: Wed, 14 Feb 2018 12:19:18 +0200 [thread overview]
Message-ID: <871shn7u1l.fsf@intel.com> (raw)
In-Reply-To: <20180214085814.2565-1-chris@chris-wilson.co.uk>
On Wed, 14 Feb 2018, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> The ages old kerneldoc-esque comments still refer to the original sutbs
"Sutbs" sounds like a profanity that should have an urban dictionary
definition. As it doesn't (not yet at least!) I presume it's just a
boring typo for "stubs".
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
> and not the more complete functions. As they were only describing the
> external entry points (or at least thought themselves to be, they had
> drifted!), they don't provide any commentary for the code flow.
>
> drivers/gpu/drm/i915/intel_tv.c:379: warning: cannot understand function prototype: 'const struct tv_mode tv_modes[] = '
> drivers/gpu/drm/i915/intel_tv.c:1133: warning: bad line:
> drivers/gpu/drm/i915/intel_tv.c:1140: warning: Function parameter or member 'intel_tv' not described in 'intel_tv_detect_type'
> drivers/gpu/drm/i915/intel_tv.c:1140: warning: Function parameter or member 'connector' not described in 'intel_tv_detect_type'
> drivers/gpu/drm/i915/intel_tv.c:1272: warning: Function parameter or member 'connector' not described in 'intel_tv_detect'
> drivers/gpu/drm/i915/intel_tv.c:1272: warning: Function parameter or member 'ctx' not described in 'intel_tv_detect'
> drivers/gpu/drm/i915/intel_tv.c:1272: warning: Function parameter or member 'force' not described in 'intel_tv_detect'
> drivers/gpu/drm/i915/intel_tv.c:1351: warning: Function parameter or member 'connector' not described in 'intel_tv_get_modes'
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
> drivers/gpu/drm/i915/intel_tv.c | 28 +++-------------------------
> 1 file changed, 3 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index b3dabc219e6a..885fc3809f7f 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -43,7 +43,6 @@ enum tv_margin {
> TV_MARGIN_RIGHT, TV_MARGIN_BOTTOM
> };
>
> -/** Private structure for the integrated TV support */
> struct intel_tv {
> struct intel_encoder base;
>
> @@ -370,12 +369,11 @@ struct tv_mode {
> * The constants below were all computed using a 107.520MHz clock
> */
>
> -/**
> +/*
> * Register programming values for TV modes.
> *
> * These values account for -1s required.
> */
> -
> static const struct tv_mode tv_modes[] = {
> {
> .name = "NTSC-M",
> @@ -1126,14 +1124,6 @@ static const struct drm_display_mode reported_modes[] = {
> },
> };
>
> -/**
> - * Detects TV presence by checking for load.
> - *
> - * Requires that the current pipe's DPLL is active.
> -
> - * \return true if TV is connected.
> - * \return false if TV is disconnected.
> - */
> static int
> intel_tv_detect_type(struct intel_tv *intel_tv,
> struct drm_connector *connector)
> @@ -1259,12 +1249,6 @@ static void intel_tv_find_better_format(struct drm_connector *connector)
> connector->state->tv.mode = i;
> }
>
> -/**
> - * Detect the TV connection.
> - *
> - * Currently this always returns CONNECTOR_STATUS_UNKNOWN, as we need to be sure
> - * we have a pipe programmed in order to probe the TV.
> - */
> static int
> intel_tv_detect(struct drm_connector *connector,
> struct drm_modeset_acquire_ctx *ctx,
> @@ -1339,13 +1323,6 @@ intel_tv_choose_preferred_modes(const struct tv_mode *tv_mode,
> }
> }
>
> -/**
> - * Stub get_modes function.
> - *
> - * This should probably return a set of fixed modes, unless we can figure out
> - * how to probe modes off of TV connections.
> - */
> -
> static int
> intel_tv_get_modes(struct drm_connector *connector)
> {
> @@ -1512,7 +1489,8 @@ intel_tv_init(struct drm_i915_private *dev_priv)
> connector = &intel_connector->base;
> state = connector->state;
>
> - /* The documentation, for the older chipsets at least, recommend
> + /*
> + * The documentation, for the older chipsets at least, recommend
> * using a polling method rather than hotplug detection for TVs.
> * This is because in order to perform the hotplug detection, the PLLs
> * for the TV must be kept alive increasing power drain and starving
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2018-02-14 10:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-14 8:58 [PATCH] drm/i915/tv: Cleanup up obsolete comments Chris Wilson
2018-02-14 9:35 ` ✓ Fi.CI.BAT: success for " Patchwork
2018-02-14 10:19 ` Jani Nikula [this message]
2018-02-14 11:59 ` ✗ Fi.CI.IGT: warning " Patchwork
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=871shn7u1l.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@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.