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.
>
> >
> > > > > +}
> > > > > +
next prev parent 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 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.