From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/3] drm/i915: Nuke drm_driver irq vfuncs
Date: Tue, 18 Jun 2019 18:26:49 +0300 [thread overview]
Message-ID: <20190618152649.GP5942@intel.com> (raw)
In-Reply-To: <156086964155.31375.16801855183444485115@skylake-alporthouse-com>
On Tue, Jun 18, 2019 at 03:54:01PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjala (2019-06-18 15:21:07)
> [snip mechanical changes]
>
> > @@ -4839,65 +4792,18 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
> > dev->driver->get_vblank_timestamp = drm_calc_vbltimestamp_from_scanoutpos;
> > dev->driver->get_scanout_position = i915_get_crtc_scanoutpos;
> >
> > - if (IS_CHERRYVIEW(dev_priv)) {
> > - dev->driver->irq_handler = cherryview_irq_handler;
> > - dev->driver->irq_preinstall = cherryview_irq_reset;
> > - dev->driver->irq_postinstall = cherryview_irq_postinstall;
> > - dev->driver->irq_uninstall = cherryview_irq_reset;
> > - dev_priv->display.hpd_irq_setup = i915_hpd_irq_setup;
> > - } else if (IS_VALLEYVIEW(dev_priv)) {
> > - dev->driver->irq_handler = valleyview_irq_handler;
> > - dev->driver->irq_preinstall = valleyview_irq_reset;
> > - dev->driver->irq_postinstall = valleyview_irq_postinstall;
> > - dev->driver->irq_uninstall = valleyview_irq_reset;
> > - dev_priv->display.hpd_irq_setup = i915_hpd_irq_setup;
> > - } else if (INTEL_GEN(dev_priv) >= 11) {
> > - dev->driver->irq_handler = gen11_irq_handler;
> > - dev->driver->irq_preinstall = gen11_irq_reset;
> > - dev->driver->irq_postinstall = gen11_irq_postinstall;
> > - dev->driver->irq_uninstall = gen11_irq_reset;
> > - dev_priv->display.hpd_irq_setup = gen11_hpd_irq_setup;
> > - } else if (INTEL_GEN(dev_priv) >= 8) {
> > - dev->driver->irq_handler = gen8_irq_handler;
> > - dev->driver->irq_preinstall = gen8_irq_reset;
> > - dev->driver->irq_postinstall = gen8_irq_postinstall;
> > - dev->driver->irq_uninstall = gen8_irq_reset;
> > - if (IS_GEN9_LP(dev_priv))
> > + if (HAS_GMCH(dev_priv)) {
> > + if (I915_HAS_HOTPLUG(dev_priv))
> > + dev_priv->display.hpd_irq_setup = i915_hpd_irq_setup;
>
> Includes chv/vlv.
>
> > + } else {
> > + if (INTEL_GEN(dev_priv) >= 11)
> > + dev_priv->display.hpd_irq_setup = gen11_hpd_irq_setup;
>
> Ok.
>
> > + else if (IS_GEN9_LP(dev_priv))
> > dev_priv->display.hpd_irq_setup = bxt_hpd_irq_setup;
> > else if (INTEL_PCH_TYPE(dev_priv) >= PCH_SPT)
> > dev_priv->display.hpd_irq_setup = spt_hpd_irq_setup;
>
> As before.
>
> > else
> > dev_priv->display.hpd_irq_setup = ilk_hpd_irq_setup;
>
> The rest of !GMCH.
>
> Code be one level if-chain though.
"could be ..."? Sure. Not entirely sure I'd be able to follow it though.
I guess just flattening it and checking for HAS_PCH_SPLIT() for ilk+
could be a reasonably non-confusing way to write it. Silly vlv/chv
always interfering with the mostly nice chronological order.
>
> > @@ -4918,6 +4824,75 @@ void intel_irq_fini(struct drm_i915_private *i915)
> > kfree(i915->l3_parity.remap_info[i]);
> > }
> >
> > +static irq_handler_t intel_irq_handler(struct drm_i915_private *dev_priv)
> > +{
> > + if (HAS_GMCH(dev_priv)) {
> > + if (IS_CHERRYVIEW(dev_priv))
> > + return cherryview_irq_handler;
> > + else if (IS_VALLEYVIEW(dev_priv))
> > + return valleyview_irq_handler;
> > + else if (IS_GEN(dev_priv, 4))
> > + return i965_irq_handler;
> > + else if (IS_GEN(dev_priv, 3))
> > + return i915_irq_handler;
> > + else
> > + return i8xx_irq_handler;
> > + } else {
> > + if (INTEL_GEN(dev_priv) >= 11)
> > + return gen11_irq_handler;
> > + else if (INTEL_GEN(dev_priv) >= 8)
> > + return gen8_irq_handler;
> > + else
> > + return ironlake_irq_handler;
> > + }
> > +}
> > +
> > +static void intel_irq_reset(struct drm_i915_private *dev_priv)
> > +{
> > + if (HAS_GMCH(dev_priv)) {
> > + if (IS_CHERRYVIEW(dev_priv))
> > + cherryview_irq_reset(dev_priv);
> > + else if (IS_VALLEYVIEW(dev_priv))
> > + valleyview_irq_reset(dev_priv);
> > + else if (IS_GEN(dev_priv, 4))
> > + i965_irq_reset(dev_priv);
> > + else if (IS_GEN(dev_priv, 3))
> > + i915_irq_reset(dev_priv);
> > + else
> > + i8xx_irq_reset(dev_priv);
> > + } else {
> > + if (INTEL_GEN(dev_priv) >= 11)
> > + gen11_irq_reset(dev_priv);
> > + else if (INTEL_GEN(dev_priv) >= 8)
> > + gen8_irq_reset(dev_priv);
> > + else
> > + ironlake_irq_reset(dev_priv);
> > + }
> > +}
> > +
> > +static void intel_irq_postinstall(struct drm_i915_private *dev_priv)
> > +{
> > + if (HAS_GMCH(dev_priv)) {
> > + if (IS_CHERRYVIEW(dev_priv))
> > + cherryview_irq_postinstall(dev_priv);
> > + else if (IS_VALLEYVIEW(dev_priv))
> > + valleyview_irq_postinstall(dev_priv);
> > + else if (IS_GEN(dev_priv, 4))
> > + i965_irq_postinstall(dev_priv);
> > + else if (IS_GEN(dev_priv, 3))
> > + i915_irq_postinstall(dev_priv);
> > + else
> > + i8xx_irq_postinstall(dev_priv);
> > + } else {
> > + if (INTEL_GEN(dev_priv) >= 11)
> > + gen11_irq_postinstall(dev_priv);
> > + else if (INTEL_GEN(dev_priv) >= 8)
> > + gen8_irq_postinstall(dev_priv);
> > + else
> > + ironlake_irq_postinstall(dev_priv);
> > + }
> > +}
> > +
> > /**
> > * intel_irq_install - enables the hardware interrupt
> > * @dev_priv: i915 device instance
> > @@ -4931,6 +4906,9 @@ void intel_irq_fini(struct drm_i915_private *i915)
> > */
> > int intel_irq_install(struct drm_i915_private *dev_priv)
> > {
> > + int irq = dev_priv->drm.pdev->irq;
> > + int ret;
> > +
> > /*
> > * We enable some interrupt sources in our postinstall hooks, so mark
> > * interrupts as enabled _before_ actually enabling them to avoid
> > @@ -4938,7 +4916,20 @@ int intel_irq_install(struct drm_i915_private *dev_priv)
> > */
> > dev_priv->runtime_pm.irqs_enabled = true;
> >
> > - return drm_irq_install(&dev_priv->drm, dev_priv->drm.pdev->irq);
> > + dev_priv->drm.irq_enabled = true;
> > +
> > + intel_irq_reset(dev_priv);
> > +
> > + ret = request_irq(irq, intel_irq_handler(dev_priv),
>
> Oh fancy.
I was debating to vfunc or not to vfunc. Seemed simple enough without.
Though the repetition of the platform checks in intel_irq_*() is a bit
annoying.
>
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> -Chris
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2019-06-18 15:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-18 14:21 [PATCH 0/3] drm/i915: Finish drm_driver vfunc cleanup Ville Syrjala
2019-06-18 14:21 ` [PATCH 1/3] drm/i915: Fix various tracepoints for gen2 Ville Syrjala
2019-06-18 14:46 ` Chris Wilson
2019-06-18 15:14 ` Ville Syrjälä
2019-06-18 14:21 ` [PATCH 2/3] drm/i915: Nuke drm_driver irq vfuncs Ville Syrjala
2019-06-18 14:54 ` Chris Wilson
2019-06-18 15:26 ` Ville Syrjälä [this message]
2019-06-18 14:21 ` [PATCH 3/3] drm/i915: Initialize drm_driver vblank funcs at compile time Ville Syrjala
2019-06-18 14:55 ` Chris Wilson
2019-06-19 16:18 ` Ville Syrjälä
2019-06-18 15:12 ` ✗ Fi.CI.BAT: failure for drm/i915: Finish drm_driver vfunc cleanup 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=20190618152649.GP5942@intel.com \
--to=ville.syrjala@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.