Re: [Intel-gfx] [PATCH v2 09/21] drm/i915/mtl: C20 HW readout
On Fri, Mar 24, 2023 at 05:51:11PM -0300, Gustavo Sousa wrote:
> On Thu, Feb 23, 2023 at 06:47:27AM -0300, Kahola, Mika wrote:
> > > > [...]
> > > > +void intel_c20pll_readout_hw_state(struct intel_encoder *encoder,
> > > > + struct intel_c20pll_state
> > > > *pll_state) {
> > > > + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> > > > + bool cntx, use_mplla;
> > > > + u32 val;
> > > > + int i;
> > > > +
> > > > +/* 1. Read current context selection */
> > > > +cntx = intel_cx0_read(i915, encoder->port, 0,
> > > > PHY_C20_VDR_CUSTOM_SERDES_RATE) & PHY_C20_CONTEXT_TOGGLE;
> > > > +
> > > > + /* Read Tx configuration */
> > > > + for (i = 0; i < ARRAY_SIZE(pll_state->tx); i++) {
> > > > + if (cntx)
> > > > + pll_state->tx[i] = intel_c20_read(i915,
> > > > encoder->port, 0, PHY_C20_B_TX_CNTX_CFG(i));
> > > > + else
> > > > + pll_state->tx[i] = intel_c20_read(i915,
> > > > encoder->port, 0, PHY_C20_A_TX_CNTX_CFG(i));
> > > > + }
> > > > +
> > > > + /* Read common configuration */
> > > > + for (i = 0; i < ARRAY_SIZE(pll_state->cmn); i++) {
> > > > + if (cntx)
> > > > + pll_state->cmn[i] = intel_c20_read(i915,
> > > > encoder->port, 0, PHY_C20_B_CMN_CNTX_CFG(i));
> > > > + else
> > > > + pll_state->cmn[i] = intel_c20_read(i915,
> > > > encoder->port, 0, PHY_C20_A_CMN_CNTX_CFG(i));
> > > > + }
> > > > +
> > > > + val = intel_c20_read(i915, encoder->port, 0,
> > > > PHY_C20_A_MPLLA_CNTX_CFG(6));
> > > > + use_mplla = val & C20_MPLLB_FRACEN;
> > >
> > >
> > > Some questions about this:
> > >
> > > 1. This is hardcoded to read from context A. Shouldn't we read from the
> > > current context?
> > >
> > > 2. s/C20_MPLLB_FRACEN/C20_MPLLA_FRACEN/ ?
> >
> > The both uses the same bit 13 for frac_en. Maybe just renaming
> > differently C10_MPLLx_FRACEN?
> > >
> > > 3. When we are programming PLL for MPLLB, we are not clearing
> > > PHY_C20_A_MPLLA_CNTX_CFG(6). Wouldn't this be problematic if MPLLB
> > > is the
> > > current one in use MPLLB but MPLLA was already used in a previous
> > > configuration?
> >
> > Do you mean this when we are switching the context? In this case, as
> > far as I have understood the spec, we wouldn't need to clear
> > previous configuration.
>
> Hi, Mika. Sorry to taking so long to reply!
>
> What I mean is as follows. Consider the sequence of events below for an
> example:
>
> 1. For a certain PLL programming, context A was used and MPLLA was selected.
> 2. For a new PLL programming, context B is used and we are not clearing
> PHY_C20_A_MPLLA_CNTX_CFG(6).
> 3. Context A is used again for the next PLL programming, but this time MPLLB
> is selected.
>
> My concern is the following: *If* PHY_C20_A_MPLLA_CNTX_CFG(6) is not
> automatically cleared by the hardware in event (2), then after (3) this
> function
> would still think the current configuration is using MPLLA while it is in fact
> using MPLLB.
>
> Now, if we have guarantee that PHY_C20_A_MPLLA_CNTX_CFG(6) is reset
> automatically when we switch to context B, then we wouldn't have to
> worry here.
Why the PLL's FRACEN flag used here? It's a detail in how the PLL is
programmed and may be either 0 or 1 (even if it's now happens to be 1).
I think PHY_C20__TX_CNTX_CFG_0[7] should be used which is txX_mpllb_sel
(see Bspec 68862, C20 TX Context programming).
--Imre
Re: [Intel-gfx] [PATCH v2 09/21] drm/i915/mtl: C20 HW readout
On Thu, Feb 23, 2023 at 06:47:27AM -0300, Kahola, Mika wrote:
> > -Original Message-
> > From: Sousa, Gustavo
> > Sent: Tuesday, February 7, 2023 6:54 PM
> > To: Kahola, Mika ; intel-gfx@lists.freedesktop.org
> > Cc: Nikula, Jani
> > Subject: Re: [Intel-gfx] [PATCH v2 09/21] drm/i915/mtl: C20 HW readout
> >
> > On Thu, Jan 05, 2023 at 02:54:34PM +0200, Mika Kahola wrote:
> > > Create a table for C20 DP1.4, DP2.0 and HDMI2.1 rates.
> > > The PLL settings are based on table, not for algorithmic alternative.
> > > For DP 1.4 only MPLLB is in use.
> > >
> > > Once register settings are done, we read back C20 HW state.
> > >
> > > BSpec: 64568
> > >
> > > v2: Update rbr, hbr1, hbr2, and hbr3 pll configurations 4 and 5
> > > based on changes in BSpec consolidated table
> > >
> > > Signed-off-by: Mika Kahola
> > > Link:
> > > https://patchwork.freedesktop.org/patch/msgid/20221014124740.774835-10
> > > -mika.kah...@intel.com
> > > ---
> > > drivers/gpu/drm/i915/display/intel_cx0_phy.c | 495
> > > ++- drivers/gpu/drm/i915/display/intel_cx0_phy.h | 10 +-
> > > drivers/gpu/drm/i915/display/intel_ddi.c | 9 +-
> > > drivers/gpu/drm/i915/display/intel_hdmi.c| 6 +-
> > > drivers/gpu/drm/i915/display/intel_hdmi.h| 1 +
> > > 5 files changed, 513 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > index 022888050a68..285e4cdd23eb 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > @@ -11,6 +11,7 @@
> > > #include "intel_de.h"
> > > #include "intel_display_types.h"
> > > #include "intel_dp.h"
> > > +#include "intel_hdmi.h"
> > > #include "intel_panel.h"
> > > #include "intel_psr.h"
> > > #include "intel_uncore.h"
> > > @@ -247,6 +248,23 @@ static void intel_c20_write(struct drm_i915_private
> > *i915, enum port port,
> > > intel_cx0_write(i915, port, lane, PHY_C20_WR_DATA_L, data & 0xff,
> > > 1); }
> > >
> > > +static u16 intel_c20_read(struct drm_i915_private *i915, enum port port,
> > > + int lane, u16 addr)
> >
> > Similar to my comment for intel_c20_write(), I think it would be better to
> > name
> > this function intel_c20_sram_read().
>
> We can rename these read/writes differently.
> >
> > Also, this function is indented with spaces instead of tabs.
> This comes from copy-paste error. Thanks for spotting!
>
> >
> > > +{
> > > + u16 val;
> > > +
> > > + assert_dc_off(i915);
> > > +
> > > + intel_cx0_write(i915, port, lane, PHY_C20_RD_ADDRESS_L, addr &
> > > 0xff,
> > 0);
> > > + intel_cx0_write(i915, port, lane, PHY_C20_RD_ADDRESS_H, (addr
> > > + >> 8) & 0xff, 1);
> >
> > Looks like the 0xff maks is unnecessary here.
> Ok.
>
> >
> > Also, does the byte order matter here? The diagram for the read operation in
> > the BSpec suggests writing the higher part of the address first and then the
> > lower part.
> I don't think it matters here but to be aligned with the spec we could swap
> these writes.
>
> >
> > > +
> > > + val = intel_cx0_read(i915, port, lane, PHY_C20_RD_DATA_H);
> > > + val <<= 8;
> > > + val |= intel_cx0_read(i915, port, lane, PHY_C20_RD_DATA_L);
> > > +
> > > +return val;
> > > +}
> > > +
> > > static void __intel_cx0_rmw(struct drm_i915_private *i915, enum port
> > > port,
> > > int lane, u16 addr, u8 clear, u8 set, bool
> > > committed) {
> > @@
> > > -588,6 +606,192 @@ static const struct intel_c10mpllb_state * const
> > mtl_c10_edp_tables[] = {
> > > NULL,
> > > };
> > >
> > > +/* C20 basic DP 1.4 tables */
> > > +static const struct intel_c20pll_state mtl_c20_dp_rbr = {
> > > + .clock = 162000,
> > > + .tx = { 0xbe88, /* tx cfg0 */
> > > + 0x5800, /* tx cfg1 */
> > > + 0x, /* tx cfg2 */
> > > + },
> > > + .cmn = {0x0500, /* cmn cfg0*/
> > > +
Re: [Intel-gfx] [PATCH v2 09/21] drm/i915/mtl: C20 HW readout
> -Original Message-
> From: Intel-gfx On Behalf Of Kahola,
> Mika
> Sent: Thursday, February 23, 2023 11:47 AM
> To: Sousa, Gustavo ; intel-
> g...@lists.freedesktop.org
> Cc: Nikula, Jani
> Subject: Re: [Intel-gfx] [PATCH v2 09/21] drm/i915/mtl: C20 HW readout
>
> > -Original Message-
> > From: Sousa, Gustavo
> > Sent: Tuesday, February 7, 2023 6:54 PM
> > To: Kahola, Mika ;
> > intel-gfx@lists.freedesktop.org
> > Cc: Nikula, Jani
> > Subject: Re: [Intel-gfx] [PATCH v2 09/21] drm/i915/mtl: C20 HW readout
> >
> > On Thu, Jan 05, 2023 at 02:54:34PM +0200, Mika Kahola wrote:
> > > Create a table for C20 DP1.4, DP2.0 and HDMI2.1 rates.
> > > The PLL settings are based on table, not for algorithmic alternative.
> > > For DP 1.4 only MPLLB is in use.
> > >
> > > Once register settings are done, we read back C20 HW state.
> > >
> > > BSpec: 64568
> > >
> > > v2: Update rbr, hbr1, hbr2, and hbr3 pll configurations 4 and 5
> > > based on changes in BSpec consolidated table
> > >
> > > Signed-off-by: Mika Kahola
> > > Link:
> > > https://patchwork.freedesktop.org/patch/msgid/20221014124740.774835-
> > > 10
> > > -mika.kah...@intel.com
> > > ---
> > > drivers/gpu/drm/i915/display/intel_cx0_phy.c | 495
> > > ++- drivers/gpu/drm/i915/display/intel_cx0_phy.h |
> > > ++10 +-
> > > drivers/gpu/drm/i915/display/intel_ddi.c | 9 +-
> > > drivers/gpu/drm/i915/display/intel_hdmi.c| 6 +-
> > > drivers/gpu/drm/i915/display/intel_hdmi.h| 1 +
> > > 5 files changed, 513 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > index 022888050a68..285e4cdd23eb 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > @@ -11,6 +11,7 @@
> > > #include "intel_de.h"
> > > #include "intel_display_types.h"
> > > #include "intel_dp.h"
> > > +#include "intel_hdmi.h"
> > > #include "intel_panel.h"
> > > #include "intel_psr.h"
> > > #include "intel_uncore.h"
> > > @@ -247,6 +248,23 @@ static void intel_c20_write(struct
> > > drm_i915_private
> > *i915, enum port port,
> > > intel_cx0_write(i915, port, lane, PHY_C20_WR_DATA_L, data & 0xff,
> > > 1); }
> > >
> > > +static u16 intel_c20_read(struct drm_i915_private *i915, enum port port,
> > > + int lane, u16 addr)
> >
> > Similar to my comment for intel_c20_write(), I think it would be
> > better to name this function intel_c20_sram_read().
>
> We can rename these read/writes differently.
> >
> > Also, this function is indented with spaces instead of tabs.
> This comes from copy-paste error. Thanks for spotting!
>
> >
> > > +{
> > > + u16 val;
> > > +
> > > + assert_dc_off(i915);
> > > +
> > > + intel_cx0_write(i915, port, lane, PHY_C20_RD_ADDRESS_L, addr
> > > + & 0xff,
> > 0);
> > > + intel_cx0_write(i915, port, lane, PHY_C20_RD_ADDRESS_H,
> > > + (addr
> > > + >> 8) & 0xff, 1);
> >
> > Looks like the 0xff maks is unnecessary here.
> Ok.
>
> >
> > Also, does the byte order matter here? The diagram for the read
> > operation in the BSpec suggests writing the higher part of the address
> > first and then the lower part.
> I don't think it matters here but to be aligned with the spec we could swap
> these
> writes.
>
> >
> > > +
> > > + val = intel_cx0_read(i915, port, lane, PHY_C20_RD_DATA_H);
> > > + val <<= 8;
> > > + val |= intel_cx0_read(i915, port, lane, PHY_C20_RD_DATA_L);
> > > +
> > > +return val;
> > > +}
> > > +
> > > static void __intel_cx0_rmw(struct drm_i915_private *i915, enum port
> > > port,
> > > int lane, u16 addr, u8 clear, u8 set, bool
> > > committed) {
> > @@
> > > -588,6 +606,192 @@ static const struct intel_c10mpllb_state * const
> > mtl_c10_edp_tables[] = {
> > > NULL,
> > > };
> > >
> > > +/* C20 basic DP 1.4 tables */
> > > +static const struct intel_c20
Re: [Intel-gfx] [PATCH v2 09/21] drm/i915/mtl: C20 HW readout
> -Original Message-
> From: Sousa, Gustavo
> Sent: Tuesday, February 7, 2023 6:54 PM
> To: Kahola, Mika ; intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani
> Subject: Re: [Intel-gfx] [PATCH v2 09/21] drm/i915/mtl: C20 HW readout
>
> On Thu, Jan 05, 2023 at 02:54:34PM +0200, Mika Kahola wrote:
> > Create a table for C20 DP1.4, DP2.0 and HDMI2.1 rates.
> > The PLL settings are based on table, not for algorithmic alternative.
> > For DP 1.4 only MPLLB is in use.
> >
> > Once register settings are done, we read back C20 HW state.
> >
> > BSpec: 64568
> >
> > v2: Update rbr, hbr1, hbr2, and hbr3 pll configurations 4 and 5
> > based on changes in BSpec consolidated table
> >
> > Signed-off-by: Mika Kahola
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20221014124740.774835-10
> > -mika.kah...@intel.com
> > ---
> > drivers/gpu/drm/i915/display/intel_cx0_phy.c | 495
> > ++- drivers/gpu/drm/i915/display/intel_cx0_phy.h | 10 +-
> > drivers/gpu/drm/i915/display/intel_ddi.c | 9 +-
> > drivers/gpu/drm/i915/display/intel_hdmi.c| 6 +-
> > drivers/gpu/drm/i915/display/intel_hdmi.h| 1 +
> > 5 files changed, 513 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > index 022888050a68..285e4cdd23eb 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > @@ -11,6 +11,7 @@
> > #include "intel_de.h"
> > #include "intel_display_types.h"
> > #include "intel_dp.h"
> > +#include "intel_hdmi.h"
> > #include "intel_panel.h"
> > #include "intel_psr.h"
> > #include "intel_uncore.h"
> > @@ -247,6 +248,23 @@ static void intel_c20_write(struct drm_i915_private
> *i915, enum port port,
> > intel_cx0_write(i915, port, lane, PHY_C20_WR_DATA_L, data & 0xff,
> > 1); }
> >
> > +static u16 intel_c20_read(struct drm_i915_private *i915, enum port port,
> > + int lane, u16 addr)
>
> Similar to my comment for intel_c20_write(), I think it would be better to
> name
> this function intel_c20_sram_read().
We can rename these read/writes differently.
>
> Also, this function is indented with spaces instead of tabs.
This comes from copy-paste error. Thanks for spotting!
>
> > +{
> > + u16 val;
> > +
> > + assert_dc_off(i915);
> > +
> > + intel_cx0_write(i915, port, lane, PHY_C20_RD_ADDRESS_L, addr & 0xff,
> 0);
> > + intel_cx0_write(i915, port, lane, PHY_C20_RD_ADDRESS_H, (addr
> > + >> 8) & 0xff, 1);
>
> Looks like the 0xff maks is unnecessary here.
Ok.
>
> Also, does the byte order matter here? The diagram for the read operation in
> the BSpec suggests writing the higher part of the address first and then the
> lower part.
I don't think it matters here but to be aligned with the spec we could swap
these writes.
>
> > +
> > + val = intel_cx0_read(i915, port, lane, PHY_C20_RD_DATA_H);
> > + val <<= 8;
> > + val |= intel_cx0_read(i915, port, lane, PHY_C20_RD_DATA_L);
> > +
> > +return val;
> > +}
> > +
> > static void __intel_cx0_rmw(struct drm_i915_private *i915, enum port port,
> > int lane, u16 addr, u8 clear, u8 set, bool
> > committed) {
> @@
> > -588,6 +606,192 @@ static const struct intel_c10mpllb_state * const
> mtl_c10_edp_tables[] = {
> > NULL,
> > };
> >
> > +/* C20 basic DP 1.4 tables */
> > +static const struct intel_c20pll_state mtl_c20_dp_rbr = {
> > + .clock = 162000,
> > + .tx = { 0xbe88, /* tx cfg0 */
> > + 0x5800, /* tx cfg1 */
> > + 0x, /* tx cfg2 */
> > + },
> > + .cmn = {0x0500, /* cmn cfg0*/
> > + 0x0005, /* cmn cfg1 */
> > + 0x, /* cmn cfg2 */
> > + 0x, /* cmn cfg3 */
> > + },
> > + .mpllb = { 0x50a8, /* mpllb cfg0 */
> > + 0x2120, /* mpllb cfg1 */
> > + 0xcd9a, /* mpllb cfg2 */
> > + 0xbfc1, /* mpllb cfg3 */
> > + 0x5ab8, /* mpllb cfg4 */
> > + 0x4c34, /* mpllb cfg5 */
> > + 0x2000, /* mpllb cfg6 */
> > + 0x0001, /* mpllb cfg7 */
> > + 0x6000,
Re: [Intel-gfx] [PATCH v2 09/21] drm/i915/mtl: C20 HW readout
On Thu, Jan 05, 2023 at 02:54:34PM +0200, Mika Kahola wrote:
> Create a table for C20 DP1.4, DP2.0 and HDMI2.1 rates.
> The PLL settings are based on table, not for algorithmic alternative.
> For DP 1.4 only MPLLB is in use.
>
> Once register settings are done, we read back C20 HW state.
>
> BSpec: 64568
>
> v2: Update rbr, hbr1, hbr2, and hbr3 pll configurations 4 and 5
> based on changes in BSpec consolidated table
>
> Signed-off-by: Mika Kahola
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20221014124740.774835-10-mika.kah...@intel.com
> ---
> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 495 ++-
> drivers/gpu/drm/i915/display/intel_cx0_phy.h | 10 +-
> drivers/gpu/drm/i915/display/intel_ddi.c | 9 +-
> drivers/gpu/drm/i915/display/intel_hdmi.c| 6 +-
> drivers/gpu/drm/i915/display/intel_hdmi.h| 1 +
> 5 files changed, 513 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> index 022888050a68..285e4cdd23eb 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -11,6 +11,7 @@
> #include "intel_de.h"
> #include "intel_display_types.h"
> #include "intel_dp.h"
> +#include "intel_hdmi.h"
> #include "intel_panel.h"
> #include "intel_psr.h"
> #include "intel_uncore.h"
> @@ -247,6 +248,23 @@ static void intel_c20_write(struct drm_i915_private
> *i915, enum port port,
> intel_cx0_write(i915, port, lane, PHY_C20_WR_DATA_L, data & 0xff, 1);
> }
>
> +static u16 intel_c20_read(struct drm_i915_private *i915, enum port port,
> + int lane, u16 addr)
Similar to my comment for intel_c20_write(), I think it would be better to name
this function intel_c20_sram_read().
Also, this function is indented with spaces instead of tabs.
> +{
> + u16 val;
> +
> + assert_dc_off(i915);
> +
> + intel_cx0_write(i915, port, lane, PHY_C20_RD_ADDRESS_L, addr & 0xff,
> 0);
> + intel_cx0_write(i915, port, lane, PHY_C20_RD_ADDRESS_H, (addr >> 8) &
> 0xff, 1);
Looks like the 0xff maks is unnecessary here.
Also, does the byte order matter here? The diagram for the read operation in the
BSpec suggests writing the higher part of the address first and then the lower
part.
> +
> + val = intel_cx0_read(i915, port, lane, PHY_C20_RD_DATA_H);
> + val <<= 8;
> + val |= intel_cx0_read(i915, port, lane, PHY_C20_RD_DATA_L);
> +
> +return val;
> +}
> +
> static void __intel_cx0_rmw(struct drm_i915_private *i915, enum port port,
> int lane, u16 addr, u8 clear, u8 set, bool
> committed)
> {
> @@ -588,6 +606,192 @@ static const struct intel_c10mpllb_state * const
> mtl_c10_edp_tables[] = {
> NULL,
> };
>
> +/* C20 basic DP 1.4 tables */
> +static const struct intel_c20pll_state mtl_c20_dp_rbr = {
> + .clock = 162000,
> + .tx = { 0xbe88, /* tx cfg0 */
> + 0x5800, /* tx cfg1 */
> + 0x, /* tx cfg2 */
> + },
> + .cmn = {0x0500, /* cmn cfg0*/
> + 0x0005, /* cmn cfg1 */
> + 0x, /* cmn cfg2 */
> + 0x, /* cmn cfg3 */
> + },
> + .mpllb = { 0x50a8, /* mpllb cfg0 */
> + 0x2120, /* mpllb cfg1 */
> + 0xcd9a, /* mpllb cfg2 */
> + 0xbfc1, /* mpllb cfg3 */
> + 0x5ab8, /* mpllb cfg4 */
> + 0x4c34, /* mpllb cfg5 */
> + 0x2000, /* mpllb cfg6 */
> + 0x0001, /* mpllb cfg7 */
> + 0x6000, /* mpllb cfg8 */
> + 0x, /* mpllb cfg9 */
> + 0x, /* mpllb cfg10 */
> + },
> +};
> +
> +static const struct intel_c20pll_state mtl_c20_dp_hbr1 = {
> + .clock = 27,
> + .tx = { 0xbe88, /* tx cfg0 */
> + 0x4800, /* tx cfg1 */
> + 0x, /* tx cfg2 */
> + },
> + .cmn = {0x0500, /* cmn cfg0*/
> + 0x0005, /* cmn cfg1 */
> + 0x, /* cmn cfg2 */
> + 0x, /* cmn cfg3 */
> + },
> + .mpllb = { 0x308c, /* mpllb cfg0 */
> + 0x2110, /* mpllb cfg1 */
> + 0xcc9c, /* mpllb cfg2 */
> + 0xbfc1, /* mpllb cfg3 */
> + 0x489a, /* mpllb cfg4 */
> + 0x3f81, /* mpllb cfg5 */
> + 0x2000, /* mpllb cfg6 */
> + 0x0001, /* mpllb cfg7 */
> + 0x5000, /* mpllb cfg8 */
> + 0x, /* mpllb cfg9 */
> + 0x, /* mpllb cfg10 */
> + },
> +};
> +
> +static const struct intel_c20pll_state mtl_c20_dp_hbr2 = {
> + .clock = 54,
> + .tx = { 0xbe88, /* tx cfg0 */
> + 0x4800, /* tx cfg1 */
> + 0x, /* tx
[Intel-gfx] [PATCH v2 09/21] drm/i915/mtl: C20 HW readout
Create a table for C20 DP1.4, DP2.0 and HDMI2.1 rates.
The PLL settings are based on table, not for algorithmic alternative.
For DP 1.4 only MPLLB is in use.
Once register settings are done, we read back C20 HW state.
BSpec: 64568
v2: Update rbr, hbr1, hbr2, and hbr3 pll configurations 4 and 5
based on changes in BSpec consolidated table
Signed-off-by: Mika Kahola
Link:
https://patchwork.freedesktop.org/patch/msgid/20221014124740.774835-10-mika.kah...@intel.com
---
drivers/gpu/drm/i915/display/intel_cx0_phy.c | 495 ++-
drivers/gpu/drm/i915/display/intel_cx0_phy.h | 10 +-
drivers/gpu/drm/i915/display/intel_ddi.c | 9 +-
drivers/gpu/drm/i915/display/intel_hdmi.c| 6 +-
drivers/gpu/drm/i915/display/intel_hdmi.h| 1 +
5 files changed, 513 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 022888050a68..285e4cdd23eb 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -11,6 +11,7 @@
#include "intel_de.h"
#include "intel_display_types.h"
#include "intel_dp.h"
+#include "intel_hdmi.h"
#include "intel_panel.h"
#include "intel_psr.h"
#include "intel_uncore.h"
@@ -247,6 +248,23 @@ static void intel_c20_write(struct drm_i915_private *i915,
enum port port,
intel_cx0_write(i915, port, lane, PHY_C20_WR_DATA_L, data & 0xff, 1);
}
+static u16 intel_c20_read(struct drm_i915_private *i915, enum port port,
+ int lane, u16 addr)
+{
+ u16 val;
+
+ assert_dc_off(i915);
+
+ intel_cx0_write(i915, port, lane, PHY_C20_RD_ADDRESS_L, addr & 0xff, 0);
+ intel_cx0_write(i915, port, lane, PHY_C20_RD_ADDRESS_H, (addr >> 8) &
0xff, 1);
+
+ val = intel_cx0_read(i915, port, lane, PHY_C20_RD_DATA_H);
+ val <<= 8;
+ val |= intel_cx0_read(i915, port, lane, PHY_C20_RD_DATA_L);
+
+return val;
+}
+
static void __intel_cx0_rmw(struct drm_i915_private *i915, enum port port,
int lane, u16 addr, u8 clear, u8 set, bool
committed)
{
@@ -588,6 +606,192 @@ static const struct intel_c10mpllb_state * const
mtl_c10_edp_tables[] = {
NULL,
};
+/* C20 basic DP 1.4 tables */
+static const struct intel_c20pll_state mtl_c20_dp_rbr = {
+ .clock = 162000,
+ .tx = { 0xbe88, /* tx cfg0 */
+ 0x5800, /* tx cfg1 */
+ 0x, /* tx cfg2 */
+ },
+ .cmn = {0x0500, /* cmn cfg0*/
+ 0x0005, /* cmn cfg1 */
+ 0x, /* cmn cfg2 */
+ 0x, /* cmn cfg3 */
+ },
+ .mpllb = { 0x50a8, /* mpllb cfg0 */
+ 0x2120, /* mpllb cfg1 */
+ 0xcd9a, /* mpllb cfg2 */
+ 0xbfc1, /* mpllb cfg3 */
+ 0x5ab8, /* mpllb cfg4 */
+ 0x4c34, /* mpllb cfg5 */
+ 0x2000, /* mpllb cfg6 */
+ 0x0001, /* mpllb cfg7 */
+ 0x6000, /* mpllb cfg8 */
+ 0x, /* mpllb cfg9 */
+ 0x, /* mpllb cfg10 */
+ },
+};
+
+static const struct intel_c20pll_state mtl_c20_dp_hbr1 = {
+ .clock = 27,
+ .tx = { 0xbe88, /* tx cfg0 */
+ 0x4800, /* tx cfg1 */
+ 0x, /* tx cfg2 */
+ },
+ .cmn = {0x0500, /* cmn cfg0*/
+ 0x0005, /* cmn cfg1 */
+ 0x, /* cmn cfg2 */
+ 0x, /* cmn cfg3 */
+ },
+ .mpllb = { 0x308c, /* mpllb cfg0 */
+ 0x2110, /* mpllb cfg1 */
+ 0xcc9c, /* mpllb cfg2 */
+ 0xbfc1, /* mpllb cfg3 */
+ 0x489a, /* mpllb cfg4 */
+ 0x3f81, /* mpllb cfg5 */
+ 0x2000, /* mpllb cfg6 */
+ 0x0001, /* mpllb cfg7 */
+ 0x5000, /* mpllb cfg8 */
+ 0x, /* mpllb cfg9 */
+ 0x, /* mpllb cfg10 */
+ },
+};
+
+static const struct intel_c20pll_state mtl_c20_dp_hbr2 = {
+ .clock = 54,
+ .tx = { 0xbe88, /* tx cfg0 */
+ 0x4800, /* tx cfg1 */
+ 0x, /* tx cfg2 */
+ },
+ .cmn = {0x0500, /* cmn cfg0*/
+ 0x0005, /* cmn cfg1 */
+ 0x, /* cmn cfg2 */
+ 0x, /* cmn cfg3 */
+ },
+ .mpllb = { 0x108c, /* mpllb cfg0 */
+ 0x2108, /* mpllb cfg1 */
+ 0xcc9c, /* mpllb cfg2 */
+ 0xbfc1, /* mpllb cfg3 */
+ 0x489a, /* mpllb cfg4 */
+ 0x3f81, /* mpllb cfg5 */
+ 0x2000, /* mpllb cfg6 */
+ 0x0001, /* mpllb cfg7 */
+
