stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>,
	intel-gfx@lists.freedesktop.org, stable@vger.kernel.org
Subject: Re: [Intel-gfx] [PATCH 1/3] drm/i915/tgl+: Add locking around DKL PHY register accesses
Date: Wed, 19 Oct 2022 12:19:49 +0300	[thread overview]
Message-ID: <Y0/BNSKHS+GYkLCw@intel.com> (raw)
In-Reply-To: <87bkq8i3xp.fsf@intel.com>

On Wed, Oct 19, 2022 at 12:00:02PM +0300, Jani Nikula wrote:
> On Tue, 18 Oct 2022, Imre Deak <imre.deak@intel.com> wrote:
> > Accessing the TypeC DKL PHY registers during modeset-commit,
> > -verification, DP link-retraining and AUX power well toggling is racy
> > due to these code paths being concurrent and the PHY register bank
> > selection register (HIP_INDEX_REG) being shared between PHY instances
> > (aka TC ports) and the bank selection being not atomic wrt. the actual
> > PHY register access.
> >
> > Add the required locking around each PHY register bank selection->
> > register access sequence.
> 
> I honestly think the abstraction here is at a too low level.
> 
> Too many places are doing DKL PHY register access to begin with. IMO the
> solution should be to abstract DKL PHY better, not to provide low level
> DKL PHY register accessors.
> 
> Indeed, this level of granularity leads to a lot of unnecessary
> lock/unlock that could have a longer span otherwise, and the interface
> does not lend itself for that.

It's no worse than uncore.lock. No one cares about that in
these codepaths either.

> Also requires separate bank selection for
> every write, nearly doubling the MMIO writes.

Drop in the ocean. This is all slow modeset stuff anyway.

IMO separate reg accessors is the correct way to handle indexed
registers unless you have some very specific performance concerns
to deal with.

> I think the choice of intel_tc.c is indicative of the problems in
> abstraction. That file has zero DKL PHY register access currently, but
> becomes the focal point of DKL PHY.
> 
> I'd aim at adding intel_dkl_phy.c which is the only place that includes
> intel_dkl_phy_regs.h and only place that directly uses the DKL PHY
> registers. And with that, maybe you don't need to add any DKL PHY
> specific register accessors.

Ripping out the PHY specific junk from eg. intel_ddi.c I
think would be a good goal. But that should also be done
for the mg phy.

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2022-10-19 10:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-18 17:20 [PATCH 1/3] drm/i915/tgl+: Add locking around DKL PHY register accesses Imre Deak
2022-10-19  9:00 ` [Intel-gfx] " Jani Nikula
2022-10-19  9:19   ` Ville Syrjälä [this message]
2022-10-19  9:30     ` Ville Syrjälä
2022-10-19 12:30       ` Jani Nikula
2022-10-19 13:41         ` Imre Deak
2022-10-19 14:57           ` Jani Nikula
2022-10-19 20:12             ` Imre Deak

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=Y0/BNSKHS+GYkLCw@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=imre.deak@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=stable@vger.kernel.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).