linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Grant Grundler <grundler@chromium.org>
Cc: Matthias Kaehlcke <mka@chromium.org>,
	Daniel Vetter <daniel.vetter@intel.com>,
	Jani Nikula <jani.nikula@linux.intel.com>,
	David Airlie <airlied@linux.ie>,
	intel-gfx@lists.freedesktop.org,
	LKML <linux-kernel@vger.kernel.org>,
	Greg Hackmann <ghackmann@google.com>,
	Michael Davidson <md@google.com>,
	dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches
Date: Fri, 5 May 2017 23:08:10 +0300	[thread overview]
Message-ID: <20170505200810.GL12629@intel.com> (raw)
In-Reply-To: <CANEJEGv5gYL0QtD992c523VA7U-kn_suPfLXTkR4Yz6AWmcA3Q@mail.gmail.com>

On Fri, May 05, 2017 at 12:12:49PM -0700, Grant Grundler wrote:
> On Fri, May 5, 2017 at 10:40 AM, Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> > On Fri, May 05, 2017 at 10:26:36AM -0700, Matthias Kaehlcke wrote:
> >> El Thu, Apr 20, 2017 at 02:56:05PM -0700 Matthias Kaehlcke ha dit:
> >>
> >> > In several instances the driver passes an 'enum pipe' value to a
> >> > function expecting an 'enum transcoder' and viceversa. Since PIPE_x and
> >> > TRANSCODER_x have the same values this doesn't cause functional
> >> > problems. Still it is incorrect and causes clang to generate warnings
> >> > like this:
> >> >
> >> > drivers/gpu/drm/i915/intel_display.c:1844:34: warning: implicit
> >> >   conversion from enumeration type 'enum transcoder' to different
> >> >   enumeration type 'enum pipe' [-Wenum-conversion]
> >> >     assert_fdi_rx_enabled(dev_priv, TRANSCODER_A);
> >> >
> >> > Change the code to pass values of the type expected by the callee.
> >> >
> >> > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> >> > ---
> >> >  drivers/gpu/drm/i915/intel_display.c | 4 ++--
> >> >  drivers/gpu/drm/i915/intel_dp.c      | 6 ++++--
> >> >  drivers/gpu/drm/i915/intel_hdmi.c    | 6 ++++--
> >> >  drivers/gpu/drm/i915/intel_sdvo.c    | 6 ++++--
> >> >  4 files changed, 14 insertions(+), 8 deletions(-)
> >>
> >> Ping, any comments on this patch?
> >
> > I'm not convinced the patch is making things any better really. To
> > fix this really properly, I think we'd need to introduce a new enum
> > pch_transcoder and thus avoid the confusion of which type of
> > transcoder we're talking about.
> 
> Is an enum better than coding an explicit conversion in an inline function?

The point of the enum would be to make it more clear which piece of
hardware we're talking to in each case. But this would require going
through the entire PCH code and changing things to use the right type
in each case. Quite a bit of work with little measurable gain I'd say.

> Then the code can do some sanity checking as well. Something like:
> 
> enum transcoder pch_to_cpu_enum(enum pipe)
> {
>     WARN_ON(pipe > FOO);
>     return (enum transcoder) pipe;
> }

That would have to be called pipe_to_pch_transcoder() or something like
that.

> 
> > Currently most places expect an
> > enum pipe when dealing with PCH transcoders, and enum transcoder
> > when dealing with CPU transcoders. But there are some exceptions
> > of course.
> 
> cheers,
> grant
> >
> > --
> > Ville Syrjälä
> > Intel OTC

-- 
Ville Syrjälä
Intel OTC

  reply	other threads:[~2017-05-05 20:09 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-20 21:56 [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches Matthias Kaehlcke
2017-05-05 17:26 ` Matthias Kaehlcke
2017-05-05 17:40   ` [Intel-gfx] " Ville Syrjälä
2017-05-05 19:12     ` Grant Grundler
2017-05-05 20:08       ` Ville Syrjälä [this message]
2017-05-05 20:29         ` Grant Grundler
2017-05-05 21:37           ` Matthias Kaehlcke
2017-05-08  7:21     ` Daniel Vetter
2017-05-08  8:17       ` Jani Nikula
2017-07-13  2:28     ` Stéphane Marchesin
2017-07-13 10:13       ` Ville Syrjälä
2017-07-13 12:24         ` Daniel Vetter
2017-07-13 16:23         ` Stéphane Marchesin
2017-07-13 17:42           ` Ville Syrjälä
2017-07-13 19:58             ` Stéphane Marchesin
2017-07-14  9:11               ` Jani Nikula
2017-07-14 17:32                 ` Grant Grundler
2017-07-14 21:35                   ` Daniel Vetter
2017-07-14 22:43                     ` Grant Grundler
2017-07-14 23:38                       ` Matthias Kaehlcke

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=20170505200810.GL12629@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=airlied@linux.ie \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ghackmann@google.com \
    --cc=grundler@chromium.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=md@google.com \
    --cc=mka@chromium.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;
as well as URLs for NNTP newsgroup(s).