public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Imre Deak <imre.deak@intel.com>
To: "Kahola, Mika" <mika.kahola@intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH 4/7] drm/i915/mtl: Add Support for C10 PHY message bus and pll programming
Date: Tue, 4 Apr 2023 16:27:34 +0300	[thread overview]
Message-ID: <ZCwlxrm4MCZU7cQD@ideak-desk.fi.intel.com> (raw)
In-Reply-To: <MW4PR11MB7054ABBA1564C3558AB67064EF939@MW4PR11MB7054.namprd11.prod.outlook.com>

On Tue, Apr 04, 2023 at 04:01:55PM +0300, Kahola, Mika wrote:
> [...]
> > >
> > > > > +void intel_c10mpllb_readout_hw_state(struct intel_encoder *encoder,
> > > > > +                                struct intel_c10mpllb_state
> > > > > +*pll_state) {
> > > > > +   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> > > > > +   struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> > > > > +   bool lane_reversal = dig_port->saved_port_bits & DDI_BUF_PORT_REVERSAL;
> > > > > +   u8 lane = lane_reversal ? INTEL_CX0_LANE1 :
> > > > > +                             INTEL_CX0_LANE0;
> > > > > +   enum phy phy = intel_port_to_phy(i915, encoder->port);
> > > > > +   int i;
> > > > > +   u8 cmn, tx0;
> > > > > +
> > > > > +   /*
> > > > > +    * According to C10 VDR Register programming Sequence we need
> > > > > +    * to do this to read PHY internal registers from MsgBus.
> > > > > +    */
> > > > > +   intel_cx0_rmw(i915, encoder->port, lane, PHY_C10_VDR_CONTROL(1), 0,
> > > > > +                 C10_VDR_CTRL_MSGBUS_ACCESS, MB_WRITE_COMMITTED);
> > > > > +
> > > > > +   for (i = 0; i < ARRAY_SIZE(pll_state->pll); i++)
> > > > > +           pll_state->pll[i] = intel_cx0_read(i915, encoder->port, lane, PHY_C10_VDR_PLL(i));
> > > > > +
> > > > > +   cmn = intel_cx0_read(i915, encoder->port, lane, PHY_C10_VDR_CMN(0));
> > > > > +   tx0 = intel_cx0_read(i915, encoder->port, lane, PHY_C10_VDR_TX(0));
> > > >
> > > > The driver programs these registers, so why aren't they also stored
> > > > in the intell_c20pll_state struct?
> > >
> > > Maybe I'm not really following here but intel_c20pll_state has its own
> > > tx, cmn and mplla/mpllb stored.
> >
> > Yes, just typoed that, I meant struct intel_c10mpllb_state which
> > doesn't include tx and cmn.
>
> Yes, for C10 tx and cmn is missing. Maybe we could add those here as
> well. It seems that currently these are not necessary required but for
> the future use, these could be defined.

These are needed already now to make the state computation / HW readout /
state checking work for these two params the same way they do for the
rest of PLL state.

> > > > > +
> > > > > +   if (tx0 != C10_TX0_VAL || cmn != C10_CMN0_DP_VAL)
> > > > > +           drm_warn(&i915->drm, "Unexpected tx: %x or cmn: %x for phy: %c.\n",
> > > > > +                    tx0, cmn, phy_name(phy));
> > > >
> > > > Shouldn't PHY_C10_VDR_CONTROL(1)/C10_VDR_CTRL_MSGBUS_ACCESS be
> > > > cleared here?
> > >
> > > Usually this means that we are not accessing these values from the
> > > register. Was this in the spec that we would need to clear it?
> >
> > It does get cleared at the end of intel_c10_pll_program(), at least
> > from one of the PHY lanes, so was wondering why things are done
> > differently here. Yes, the spec doesn't require clearing it, but
> > then it should not be cleared at other places either (has related
> > comments on this in follow-up reviews).
> 
> To be consistent maybe we can clear this here as well.

If there is no need for it, let's follow the spec and not clear it at
any other spot either.

> 
> >
> > > > > +}
> > > > > +

  reply	other threads:[~2023-04-04 13:27 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-27 12:34 [Intel-gfx] [PATCH 0/7] drm/i915/mtl: Add Support for C10 chips Mika Kahola
2023-03-27 12:34 ` [Intel-gfx] [PATCH 1/7] drm/i915/mtl: Initial DDI port setup Mika Kahola
2023-03-28 11:41   ` Govindapillai, Vinod
2023-03-27 12:34 ` [Intel-gfx] [PATCH 2/7] drm/i915/mtl: Add DP rates Mika Kahola
2023-03-28 12:49   ` Govindapillai, Vinod
2023-03-27 12:34 ` [Intel-gfx] [PATCH 3/7] drm/i915/mtl: Create separate reg file for PICA registers Mika Kahola
2023-03-28 15:33   ` Govindapillai, Vinod
2023-03-27 12:34 ` [Intel-gfx] [PATCH 4/7] drm/i915/mtl: Add Support for C10 PHY message bus and pll programming Mika Kahola
2023-03-29 10:22   ` Govindapillai, Vinod
2023-03-29 15:40   ` Imre Deak
2023-03-29 15:59     ` Imre Deak
2023-04-04 10:43     ` Kahola, Mika
2023-04-04 11:47       ` Imre Deak
2023-04-04 13:01         ` Kahola, Mika
2023-04-04 13:27           ` Imre Deak [this message]
2023-04-04 16:50             ` Sripada, Radhakrishna
2023-04-04 18:03               ` Imre Deak
2023-04-04 19:22                 ` Sripada, Radhakrishna
2023-04-04 21:28                   ` Imre Deak
2023-04-03 10:11   ` Imre Deak
2023-04-03 10:19     ` Kahola, Mika
2023-04-03 10:36       ` Imre Deak
2023-04-03 10:43         ` Kahola, Mika
2023-03-27 12:34 ` [Intel-gfx] [PATCH 5/7] drm/i915/mtl: Add C10 phy programming for HDMI Mika Kahola
2023-04-03 10:26   ` Imre Deak
2023-03-27 12:34 ` [Intel-gfx] [PATCH 6/7] drm/i915/mtl: Add vswing programming for C10 phys Mika Kahola
2023-04-03 11:18   ` Imre Deak
2023-03-27 12:34 ` [Intel-gfx] [PATCH 7/7] drm/i915/mtl: Add support for PM DEMAND Mika Kahola
2023-03-27 19:19 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/mtl: Add Support for C10 chips Patchwork
2023-03-27 19:19 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2023-03-27 19:23 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-03-28  1:44 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2023-03-29 16:48 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/mtl: Add Support for C10 chips (rev2) Patchwork
2023-03-29 16:48 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2023-03-29 16:53 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-03-30  8:26 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2023-04-05  8:52 ` [Intel-gfx] [PATCH 0/7] drm/i915/mtl: Add Support for C10 chips Andi Shyti

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=ZCwlxrm4MCZU7cQD@ideak-desk.fi.intel.com \
    --to=imre.deak@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=mika.kahola@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