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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox