From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 3/4] drm/i915: Stop requiring PLL index == PLL ID
Date: Thu, 22 Sep 2022 22:57:51 +0300 [thread overview]
Message-ID: <Yyy+PxOrG2LFEx3G@intel.com> (raw)
In-Reply-To: <878rmb5s4p.fsf@intel.com>
On Thu, Sep 22, 2022 at 06:46:30PM +0300, Jani Nikula wrote:
> On Wed, 21 Sep 2022, Ville Syrjala <ville.syrjala@linux.intel.com> wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > There's no good reason to keep around this PLL index == PLL ID
> > footgun. Get rid of it.
> >
> > Both i915->shared_dplls[] and state->shared_dpll[] are indexed
> > by the same thing now, which is just the index we get at
> > initialization from dpll_mgr->dpll_info[]. The rest is all about
> > PLL IDs now.
> >
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> > drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 64 +++++++++++++------
> > .../gpu/drm/i915/display/intel_pch_refclk.c | 5 +-
> > 2 files changed, 47 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> > index f900c4c73cc6..fb09029cc4aa 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> > @@ -110,7 +110,7 @@ static void
> > intel_atomic_duplicate_dpll_state(struct drm_i915_private *dev_priv,
> > struct intel_shared_dpll_state *shared_dpll)
> > {
> > - enum intel_dpll_id i;
> > + int i;
> >
> > /* Copy shared dpll state */
> > for (i = 0; i < dev_priv->display.dpll.num_shared_dpll; i++) {
> > @@ -137,6 +137,13 @@ intel_atomic_get_shared_dpll_state(struct drm_atomic_state *s)
> > return state->shared_dpll;
> > }
> >
> > +static int
> > +intel_shared_dpll_idx(struct drm_i915_private *i915,
> > + const struct intel_shared_dpll *pll)
> > +{
> > + return pll - &i915->display.dpll.shared_dplls[0];
> > +}
>
> I liked getting rid of this magic in the previous patch, and would not
> like to have it brought back!
>
> I'm thinking
>
> static int
> intel_shared_dpll_idx(struct drm_i915_private *i915, enum intel_dpll_id id)
>
> which would loop over shared_dplls[] and return the index, similar to
> the function below. Feels more robust.
Dunno if it's more robust, but I guess it does decouple us
a bit more from the array storage of the actual plls. We
could even do this exactly like eg. drm_crtc, ie. introduce
pll->index for the atomic state indexing but could use a
linked list to keep the actual plls. Though that would
again mean more kmallocs() that can fail, so I don't think
I'll go quite that far, at least not yet. Though I suppose
I could introduce pll->index already...
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2022-09-22 19:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-21 12:23 [Intel-gfx] [PATCH 0/4] drm/i915: Start cleaning up the DPLL ID mess Ville Syrjala
2022-09-21 12:23 ` [Intel-gfx] [PATCH 1/4] drm/i915: Always initialize dpll.lock Ville Syrjala
2022-09-22 15:41 ` Jani Nikula
2022-09-21 12:23 ` [Intel-gfx] [PATCH 2/4] drm/i915: Nuke intel_get_shared_dpll_id() Ville Syrjala
2022-09-22 15:42 ` Jani Nikula
2022-09-21 12:23 ` [Intel-gfx] [PATCH 3/4] drm/i915: Stop requiring PLL index == PLL ID Ville Syrjala
2022-09-22 15:46 ` Jani Nikula
2022-09-22 19:57 ` Ville Syrjälä [this message]
2022-09-21 12:23 ` [Intel-gfx] [PATCH 4/4] drm/i915: Decouple I915_NUM_PLLS from PLL IDs Ville Syrjala
2022-09-22 15:55 ` Jani Nikula
2022-09-22 16:06 ` Ville Syrjälä
2022-09-21 12:46 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Start cleaning up the DPLL ID mess Patchwork
2022-09-21 13:07 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-09-21 14:05 ` [Intel-gfx] ✓ Fi.CI.IGT: " 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=Yyy+PxOrG2LFEx3G@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@linux.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 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.