From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: intel-gfx@lists.freedesktop.org, Chris Wilson <chris@chris-wilson.co.uk>
Subject: Re: [Intel-gfx] [PATCH] Revert "drm/i915: re-order if/else ladder for hpd_irq_setup"
Date: Tue, 1 Dec 2020 19:25:29 +0200 [thread overview]
Message-ID: <20201201172529.GC6112@intel.com> (raw)
In-Reply-To: <20201201054618.brmf3ugxhivest6q@ldmartin-desk1>
On Mon, Nov 30, 2020 at 09:46:18PM -0800, Lucas De Marchi wrote:
> On Mon, Nov 30, 2020 at 07:46:39PM +0200, Ville Syrjälä wrote:
> >On Mon, Nov 30, 2020 at 09:31:04AM -0800, Lucas De Marchi wrote:
> >> On Mon, Nov 30, 2020 at 04:19:54PM +0200, Ville Syrjälä wrote:
> >> >On Fri, Nov 27, 2020 at 08:52:29PM -0800, Lucas De Marchi wrote:
> >> >> On Fri, Nov 27, 2020 at 02:57:48PM +0000, Chris Wilson wrote:
> >> >> >We now use ilk_hpd_irq_setup for all GMCH platforms that do not have
> >> >> >hotplug. These are early gen3 and gen2 devices that now explode on boot
> >> >> >as they try to access non-existent registers.
> >> >>
> >> >> humn... true, my bad. But I don't think a revert is the right fix. It
> >> >> would be much better if we would not be setting up the hpd setup
> >> >> function at all for platforms that do not have hotplug. I think a
> >> >> separate early check for I915_HAS_HOTPLUG() would be deserved.
> >> >
> >> >I think it generally leads to much less convoluted logic when we keep
> >> >gmch vs. rest separate. So I'm confused as to what we're even trying
> >> >to achieve here?
> >>
> >> 1) Stop trying to setup hotplug in a platform that doesn't have hotplug
> >> was the main focus. Later it would be better to move some of these
> >> hotplug to display/ as they are clearly display related and account for
> >> a great portion of i915_irq.c.
> >>
> >> I left the I915_HAS_HOTPLUG() in the middle by
> >> mistake, it should had been an earlier call.
> >>
> >> 2) semi-related is the move of GMCH to the middle and I guess this is
> >> what you're complaining here. I find it's cumbersome to have it
> >> separate as we go and extend these checks for newer platforms. Almost
> >> everywhere we settled on having last platform first in the if/else
> >> ladders - this makes it much more clear on how/where to add a new
> >> platform.
> >
> >You never touch the gmch path for new platforms. What could be more
> >clear than that?
>
> the second level branch mixing the code path for new and old platform
> instead of following the convention we settled on.
The convention I care about most is "clear code" which in many
cases is best achieved with gmch vs. not split.
> But I'm ok with
> moving it back as a HAS_* check in the middle of GEN_* check is proving
> controversial.
>
> Lucas De Marchi
>
> >
> >--
> >Ville Syrjälä
> >Intel
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
prev parent reply other threads:[~2020-12-01 17:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-27 14:57 [Intel-gfx] [PATCH] Revert "drm/i915: re-order if/else ladder for hpd_irq_setup" Chris Wilson
2020-11-27 15:25 ` Jani Nikula
2020-11-27 18:40 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2020-11-27 19:50 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2020-11-28 4:52 ` [Intel-gfx] [PATCH] " Lucas De Marchi
2020-11-30 14:19 ` Ville Syrjälä
2020-11-30 17:31 ` Lucas De Marchi
2020-11-30 17:46 ` Ville Syrjälä
2020-12-01 5:46 ` Lucas De Marchi
2020-12-01 17:25 ` Ville Syrjälä [this message]
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=20201201172529.GC6112@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
--cc=lucas.demarchi@intel.com \
/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).