[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915/opregion: add support for mailbox #5 EDID
== Series Details == Series: series starting with [1/2] drm/i915/opregion: add support for mailbox #5 EDID URL : https://patchwork.freedesktop.org/series/81121/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/gt/intel_reset.c:1311:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gvt/mmio.c:287:23: warning: memcpy with byte count of 279040 +drivers/gpu/drm/i915/i915_perf.c:1440:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1494:15: warning: memset with byte count of 16777216 +./include/linux/seqlock.h:752:24: warning: trying to copy expression type 31 +./include/linux/seqlock.h:778:16: warning: trying to copy expression type 31 +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write8' - different lock contexts for basic block ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/opregion: add support for mailbox #5 EDID
On Fri, 28 Aug 2020, Jani Nikula wrote:
> The ACPI OpRegion Mailbox #5 ASLE extension may contain an EDID to be
> used for the embedded display. Add support for using it via the EDID
> override mechanism.
>
> Note that the override EDID may be later reset or changed via debugfs,
> as usual.
>
> Cc: Uma Shankar
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_opregion.c | 46 ++-
> drivers/gpu/drm/i915/display/intel_opregion.h | 8
> 2 files changed, 53 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c
> b/drivers/gpu/drm/i915/display/intel_opregion.c
> index de995362f428..13485969fafa 100644
> --- a/drivers/gpu/drm/i915/display/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/display/intel_opregion.c
> @@ -196,6 +196,8 @@ struct opregion_asle_ext {
> #define ASLE_IUER_WINDOWS_BTN(1 << 1)
> #define ASLE_IUER_POWER_BTN (1 << 0)
>
> +#define ASLE_PHED_EDID_VALID_MASK0x3
> +
> /* Software System Control Interrupt (SWSCI) */
> #define SWSCI_SCIC_INDICATOR (1 << 0)
> #define SWSCI_SCIC_MAIN_FUNCTION_SHIFT 1
> @@ -909,8 +911,10 @@ int intel_opregion_setup(struct drm_i915_private
> *dev_priv)
> opregion->asle->ardy = ASLE_ARDY_NOT_READY;
> }
>
> - if (mboxes & MBOX_ASLE_EXT)
> + if (mboxes & MBOX_ASLE_EXT) {
> drm_dbg(&dev_priv->drm, "ASLE extension supported\n");
> + opregion->asle_ext = base + OPREGION_ASLE_EXT_OFFSET;
> + }
>
> if (intel_load_vbt_firmware(dev_priv) == 0)
> goto out;
> @@ -1041,6 +1045,45 @@ intel_opregion_get_panel_type(struct drm_i915_private
> *dev_priv)
> return ret - 1;
> }
>
> +void intel_opregion_edid_override(struct intel_connector *intel_connector)
> +{
> + struct drm_connector *connector = &intel_connector->base;
> + struct drm_i915_private *i915 = to_i915(connector->dev);
> + struct intel_opregion *opregion = &i915->opregion;
> + const void *in_edid;
> + const struct edid *edid;
> + int len, ret;
> +
> + if (!opregion->asle_ext)
> + return;
> +
> + in_edid = opregion->asle_ext->bddc;
> +
> + /* Validity corresponds to number of 128-byte blocks */
> + len = (opregion->asle_ext->phed & ASLE_PHED_EDID_VALID_MASK) * 128;
> + if (!len || !memchr_inv(in_edid, 0, len))
> + return;
> +
> + edid = in_edid;
> +
> + /*
> + * FIXME: Might also check drm_edid_is_valid(edid) here but that
> + * requires mutable edid.
> + */
> + if (len < EDID_LENGTH * (1 + edid->extensions)) {
> + drm_dbg_kms(&i915->drm, "Invalid EDID in ACPI OpRegion (Mailbox
> #5)\n");
> + return;
> + }
> +
> + connector->override_edid = false;
> + ret = drm_connector_update_edid_property(connector, edid);
> + if (ret)
> + return;
> +
This is missing here:
connector->override_edid = true;
> + drm_dbg_kms(&i915->drm, "Using OpRegion EDID for [CONNECTOR:%d:%s]\n",
> + connector->base.id, connector->name);
> +}
> +
> void intel_opregion_register(struct drm_i915_private *i915)
> {
> struct intel_opregion *opregion = &i915->opregion;
> @@ -1131,6 +1174,7 @@ void intel_opregion_unregister(struct drm_i915_private
> *i915)
> opregion->acpi = NULL;
> opregion->swsci = NULL;
> opregion->asle = NULL;
> + opregion->asle_ext = NULL;
> opregion->vbt = NULL;
> opregion->lid_state = NULL;
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_opregion.h
> b/drivers/gpu/drm/i915/display/intel_opregion.h
> index 4aa68ffbd30e..b407a0744c40 100644
> --- a/drivers/gpu/drm/i915/display/intel_opregion.h
> +++ b/drivers/gpu/drm/i915/display/intel_opregion.h
> @@ -29,12 +29,14 @@
> #include
>
> struct drm_i915_private;
> +struct intel_connector;
> struct intel_encoder;
>
> struct opregion_header;
> struct opregion_acpi;
> struct opregion_swsci;
> struct opregion_asle;
> +struct opregion_asle_ext;
>
> struct intel_opregion {
> struct opregion_header *header;
> @@ -43,6 +45,7 @@ struct intel_opregion {
> u32 swsci_gbda_sub_functions;
> u32 swsci_sbcb_sub_functions;
> struct opregion_asle *asle;
> + struct opregion_asle_ext *asle_ext;
> void *rvda;
> void *vbt_firmware;
> const void *vbt;
> @@ -71,6 +74,7 @@ int intel_opregion_notify_encoder(struct intel_encoder
> *intel_encoder,
> int intel_opregion_notify_adapter(struct drm_i915_private *dev_priv,
> pci_power_t state);
> int intel_opregion_get_panel_type(struct drm_i915_private *dev_priv);
> +void intel_opregion_edid_override(struct intel_connector *connector);
>
> #else /* CONFIG_ACPI*/
>
> @@ -117,6 +121,10 @@ static inline int intel_opregion_get_panel_type(struct
> drm_i915_private *dev)
> return -ENODEV;
> }
>
> +void intel_opregion_edid_override
Re: [Intel-gfx] [PATCH v8 06/11] drm/i915: Enable big joiner support in enable and disable sequences.
Op 28-08-2020 om 01:35 schreef Navare, Manasi:
> On Mon, Aug 10, 2020 at 04:28:28PM -0700, Manasi Navare wrote:
>> From: Maarten Lankhorst
>>
>> Make vdsc work when no output is enabled. The big joiner needs VDSC
>> on the slave, so enable it and set the appropriate bits.
>> Also update timestamping constants, because slave crtc's are not
>> updated in drm_atomic_helper_update_legacy_modeset_state().
>>
>> This should be enough to bring up CRTC's in a big joiner configuration,
>> without any plane configuration on the second pipe yet.
>>
>> HOWEVER, we still bring up the crtc's in the wrong order. We need to
>> make sure that the master crtc is brought up after the slave crtc.
>> This is done correctly later in this series.
>>
>> The next steps are to enable planes correctly, and make sure we enable
>> and update both master and slave in the correct order.
>>
>> v2:
>> * Manual rebase (Manasi)
>>
>> v3:
>> * Rebase (Manasi)
>>
>> v4:
>> * Rebase (Manasi)
>>
>> v5:
>> * Get dsc power domain in ddi_init (Manasi)
>>
>> v6:
>> * Remove dsc power put from dsc_disable (Maarten)
>>
>> Signed-off-by: Maarten Lankhorst
>> Signed-off-by: Manasi Navare
>> ---
>> drivers/gpu/drm/i915/display/icl_dsi.c| 2 -
>> drivers/gpu/drm/i915/display/intel_ddi.c | 68 +++-
>> drivers/gpu/drm/i915/display/intel_display.c | 377 --
>> .../drm/i915/display/intel_display_types.h| 1 +
>> drivers/gpu/drm/i915/display/intel_dp.c | 6 +-
>> drivers/gpu/drm/i915/display/intel_vdsc.c | 201 +-
>> drivers/gpu/drm/i915/display/intel_vdsc.h | 7 +-
>> 7 files changed, 413 insertions(+), 249 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
>> b/drivers/gpu/drm/i915/display/icl_dsi.c
>> index 8c55f5bee9ab..26f7372b4c25 100644
>> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
>> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
>> @@ -1454,8 +1454,6 @@ static void gen11_dsi_get_config(struct intel_encoder
>> *encoder,
>> struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
>> struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
>>
>> -intel_dsc_get_config(encoder, pipe_config);
> Maarten,
> Why do we need to remove this from dsi_get_config()?
This is read by the pipe now, which is the only place that does get_config().
>
>> -
>> /* FIXME: adapt icl_ddi_clock_get() for DSI and use that? */
>> pipe_config->port_clock = intel_dpll_get_freq(i915,
>>pipe_config->shared_dpll);
>> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
>> b/drivers/gpu/drm/i915/display/intel_ddi.c
>> index de5b216561d8..6de13c67f5b8 100644
>> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
>> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
>> @@ -28,6 +28,7 @@
>> #include
>>
>> #include "i915_drv.h"
>> +#include "i915_trace.h"
>> #include "intel_audio.h"
>> #include "intel_combo_phy.h"
>> #include "intel_connector.h"
>> @@ -2093,12 +2094,6 @@ static void intel_ddi_get_power_domains(struct
>> intel_encoder *encoder,
>> intel_display_power_get(dev_priv,
>>
>> intel_ddi_main_link_aux_domain(dig_port));
>>
>> -/*
>> - * VDSC power is needed when DSC is enabled
>> - */
>> -if (crtc_state->dsc.compression_enable)
>> -intel_display_power_get(dev_priv,
>> -intel_dsc_power_domain(crtc_state));
>> }
>>
>> void intel_ddi_enable_pipe_clock(struct intel_encoder *encoder,
>> @@ -3387,7 +3382,8 @@ static void tgl_ddi_pre_enable_dp(struct
>> intel_atomic_state *state,
>>
>> /* 7.l Configure and enable FEC if needed */
>> intel_ddi_enable_fec(encoder, crtc_state);
>> -intel_dsc_enable(encoder, crtc_state);
>> +if (!crtc_state->bigjoiner)
>> +intel_dsc_enable(encoder, crtc_state);
>> }
>>
>> static void hsw_ddi_pre_enable_dp(struct intel_atomic_state *state,
>> @@ -3458,7 +3454,8 @@ static void hsw_ddi_pre_enable_dp(struct
>> intel_atomic_state *state,
>> if (!is_mst)
>> intel_ddi_enable_pipe_clock(encoder, crtc_state);
>>
>> -intel_dsc_enable(encoder, crtc_state);
>> +if (!crtc_state->bigjoiner)
>> +intel_dsc_enable(encoder, crtc_state);
>> }
>>
>> static void intel_ddi_pre_enable_dp(struct intel_atomic_state *state,
>> @@ -3713,6 +3710,21 @@ static void intel_ddi_post_disable(struct
>> intel_atomic_state *state,
>> ilk_pfit_disable(old_crtc_state);
>> }
>>
>> +if (old_crtc_state->bigjoiner_linked_crtc) {
>> +struct intel_atomic_state *state =
>> +to_intel_atomic_state(old_crtc_state->uapi.state);
>> +struct intel_crtc *slave =
>> +old_crtc_state->bigjoiner_linked_crtc;
>> +const struct intel_crtc_state *old_slave_crtc_state =
>> +intel_atomic_get_old_crtc_state(state, slave);
[Intel-gfx] [PATCH 1/2] drm/i915/opregion: add support for mailbox #5 EDID
The ACPI OpRegion Mailbox #5 ASLE extension may contain an EDID to be
used for the embedded display. Add support for using it via the EDID
override mechanism.
Note that the override EDID may be later reset or changed via debugfs,
as usual.
Cc: Uma Shankar
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_opregion.c | 46 ++-
drivers/gpu/drm/i915/display/intel_opregion.h | 8
2 files changed, 53 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c
b/drivers/gpu/drm/i915/display/intel_opregion.c
index de995362f428..13485969fafa 100644
--- a/drivers/gpu/drm/i915/display/intel_opregion.c
+++ b/drivers/gpu/drm/i915/display/intel_opregion.c
@@ -196,6 +196,8 @@ struct opregion_asle_ext {
#define ASLE_IUER_WINDOWS_BTN (1 << 1)
#define ASLE_IUER_POWER_BTN(1 << 0)
+#define ASLE_PHED_EDID_VALID_MASK 0x3
+
/* Software System Control Interrupt (SWSCI) */
#define SWSCI_SCIC_INDICATOR (1 << 0)
#define SWSCI_SCIC_MAIN_FUNCTION_SHIFT 1
@@ -909,8 +911,10 @@ int intel_opregion_setup(struct drm_i915_private *dev_priv)
opregion->asle->ardy = ASLE_ARDY_NOT_READY;
}
- if (mboxes & MBOX_ASLE_EXT)
+ if (mboxes & MBOX_ASLE_EXT) {
drm_dbg(&dev_priv->drm, "ASLE extension supported\n");
+ opregion->asle_ext = base + OPREGION_ASLE_EXT_OFFSET;
+ }
if (intel_load_vbt_firmware(dev_priv) == 0)
goto out;
@@ -1041,6 +1045,45 @@ intel_opregion_get_panel_type(struct drm_i915_private
*dev_priv)
return ret - 1;
}
+void intel_opregion_edid_override(struct intel_connector *intel_connector)
+{
+ struct drm_connector *connector = &intel_connector->base;
+ struct drm_i915_private *i915 = to_i915(connector->dev);
+ struct intel_opregion *opregion = &i915->opregion;
+ const void *in_edid;
+ const struct edid *edid;
+ int len, ret;
+
+ if (!opregion->asle_ext)
+ return;
+
+ in_edid = opregion->asle_ext->bddc;
+
+ /* Validity corresponds to number of 128-byte blocks */
+ len = (opregion->asle_ext->phed & ASLE_PHED_EDID_VALID_MASK) * 128;
+ if (!len || !memchr_inv(in_edid, 0, len))
+ return;
+
+ edid = in_edid;
+
+ /*
+* FIXME: Might also check drm_edid_is_valid(edid) here but that
+* requires mutable edid.
+*/
+ if (len < EDID_LENGTH * (1 + edid->extensions)) {
+ drm_dbg_kms(&i915->drm, "Invalid EDID in ACPI OpRegion (Mailbox
#5)\n");
+ return;
+ }
+
+ connector->override_edid = false;
+ ret = drm_connector_update_edid_property(connector, edid);
+ if (ret)
+ return;
+
+ drm_dbg_kms(&i915->drm, "Using OpRegion EDID for [CONNECTOR:%d:%s]\n",
+ connector->base.id, connector->name);
+}
+
void intel_opregion_register(struct drm_i915_private *i915)
{
struct intel_opregion *opregion = &i915->opregion;
@@ -1131,6 +1174,7 @@ void intel_opregion_unregister(struct drm_i915_private
*i915)
opregion->acpi = NULL;
opregion->swsci = NULL;
opregion->asle = NULL;
+ opregion->asle_ext = NULL;
opregion->vbt = NULL;
opregion->lid_state = NULL;
}
diff --git a/drivers/gpu/drm/i915/display/intel_opregion.h
b/drivers/gpu/drm/i915/display/intel_opregion.h
index 4aa68ffbd30e..b407a0744c40 100644
--- a/drivers/gpu/drm/i915/display/intel_opregion.h
+++ b/drivers/gpu/drm/i915/display/intel_opregion.h
@@ -29,12 +29,14 @@
#include
struct drm_i915_private;
+struct intel_connector;
struct intel_encoder;
struct opregion_header;
struct opregion_acpi;
struct opregion_swsci;
struct opregion_asle;
+struct opregion_asle_ext;
struct intel_opregion {
struct opregion_header *header;
@@ -43,6 +45,7 @@ struct intel_opregion {
u32 swsci_gbda_sub_functions;
u32 swsci_sbcb_sub_functions;
struct opregion_asle *asle;
+ struct opregion_asle_ext *asle_ext;
void *rvda;
void *vbt_firmware;
const void *vbt;
@@ -71,6 +74,7 @@ int intel_opregion_notify_encoder(struct intel_encoder
*intel_encoder,
int intel_opregion_notify_adapter(struct drm_i915_private *dev_priv,
pci_power_t state);
int intel_opregion_get_panel_type(struct drm_i915_private *dev_priv);
+void intel_opregion_edid_override(struct intel_connector *connector);
#else /* CONFIG_ACPI*/
@@ -117,6 +121,10 @@ static inline int intel_opregion_get_panel_type(struct
drm_i915_private *dev)
return -ENODEV;
}
+void intel_opregion_edid_override(struct intel_connector *connector)
+{
+}
+
#endif /* CONFIG_ACPI */
#endif
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/dp: use opregion mailbox #5 EDID for eDP, if available
If a panel's EDID is broken, there may be an override EDID set in the
ACPI OpRegion mailbox #5. Use it if available.
Cc: Uma Shankar
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index c57ac83bf563..d1307be196a2 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -8114,6 +8114,9 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
goto out_vdd_off;
}
+ /* Set up override EDID, if any, from ACPI OpRegion */
+ intel_opregion_edid_override(intel_connector);
+
mutex_lock(&dev->mode_config.mutex);
edid = drm_get_edid(connector, &intel_dp->aux.ddc);
if (edid) {
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/8] Convert the intel iommu driver to the dma-iommu api
On Thu, 27 Aug 2020 at 22:36, Logan Gunthorpe wrote:
>
>
>
> On 2020-08-23 6:04 p.m., Tom Murphy wrote:
> > I have added a check for the sg_dma_len == 0 :
> > """
> > } __sgt_iter(struct scatterlist *sgl, bool dma) {
> > struct sgt_iter s = { .sgp = sgl };
> >
> > + if (sgl && sg_dma_len(sgl) == 0)
> > + s.sgp = NULL;
> >
> > if (s.sgp) {
> > .
> > """
> > at location [1].
> > but it doens't fix the problem.
>
> Based on my read of the code, it looks like we also need to change usage
> of sgl->length... Something like the rough patch below, maybe?
>
> Also, Tom, do you have an updated version of the patchset to convert the
> Intel IOMMU to dma-iommu available? The last one I've found doesn't
> apply cleanly (I'm assuming parts of it have been merged in slightly
> modified forms).
>
I'll try and post one in the next 24hours
> Thanks,
>
> Logan
>
> --
>
> diff --git a/drivers/gpu/drm/i915/i915_scatterlist.h
> b/drivers/gpu/drm/i915/i915
> index b7b59328cb76..9367ac801f0c 100644
> --- a/drivers/gpu/drm/i915/i915_scatterlist.h
> +++ b/drivers/gpu/drm/i915/i915_scatterlist.h
> @@ -27,13 +27,19 @@ static __always_inline struct sgt_iter {
> } __sgt_iter(struct scatterlist *sgl, bool dma) {
> struct sgt_iter s = { .sgp = sgl };
>
> + if (sgl && !sg_dma_len(s.sgp))
> + s.sgp = NULL;
> +
> if (s.sgp) {
> s.max = s.curr = s.sgp->offset;
> - s.max += s.sgp->length;
> - if (dma)
> +
> + if (dma) {
> + s.max += sg_dma_len(s.sgp);
> s.dma = sg_dma_address(s.sgp);
> - else
> + } else {
> + s.max += s.sgp->length;
> s.pfn = page_to_pfn(sg_page(s.sgp));
> + }
> }
>
> return s;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 3/3] drm/i915/ehl: Update voltage swing table
On Wed, Aug 26, 2020 at 01:15:49PM -0700, José Roberto de Souza wrote:
> Update with latest tunning in the table.
>
> v3: Fix values of to last columns.
>
> BSpec: 21257
> Cc: Matt Roper
> Signed-off-by: José Roberto de Souza
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 699511872290..82c1846d9be1 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -572,13 +572,13 @@ static const struct cnl_ddi_buf_trans
> ehl_combo_phy_ddi_translations_dp[] = {
> /* NT mV Trans mV db*/
> { 0xA, 0x33, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
> { 0xA, 0x47, 0x36, 0x00, 0x09 },/* 350 500 3.1 */
> - { 0xC, 0x64, 0x30, 0x00, 0x0F },/* 350 700 6.0 */
> - { 0x6, 0x7F, 0x2C, 0x00, 0x13 },/* 350 900 8.2 */
> + { 0xC, 0x64, 0x34, 0x00, 0x0B },/* 350 700 6.0 */
> + { 0x6, 0x7F, 0x30, 0x00, 0x0F },/* 350 900 8.2 */
> { 0xA, 0x46, 0x3F, 0x00, 0x00 },/* 500 500 0.0 */
> - { 0xC, 0x64, 0x36, 0x00, 0x09 },/* 500 700 2.9 */
> - { 0x6, 0x7F, 0x30, 0x00, 0x0F },/* 500 900 5.1 */
> + { 0xC, 0x64, 0x38, 0x00, 0x07 },/* 500 700 2.9 */
> + { 0x6, 0x7F, 0x32, 0x00, 0x0D },/* 500 900 5.1 */
> { 0xC, 0x61, 0x3F, 0x00, 0x00 },/* 650 700 0.6 */
> - { 0x6, 0x7F, 0x37, 0x00, 0x08 },/* 600 900 3.5 */
> + { 0x6, 0x7F, 0x38, 0x00, 0x07 },/* 600 900 3.5 */
> { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900 900 0.0 */
> };
>
> --
> 2.28.0
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/tgl: Fix stepping WA matching (rev3)
== Series Details == Series: drm/i915/tgl: Fix stepping WA matching (rev3) URL : https://patchwork.freedesktop.org/series/80820/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8935_full -> Patchwork_18417_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18417_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18417_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_18417_full: ### IGT changes ### Possible regressions * igt@kms_flip@modeset-vs-vblank-race-interruptible@c-vga1: - shard-hsw: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8935/shard-hsw6/igt@kms_flip@modeset-vs-vblank-race-interrupti...@c-vga1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18417/shard-hsw8/igt@kms_flip@modeset-vs-vblank-race-interrupti...@c-vga1.html Known issues Here are the changes found in Patchwork_18417_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@bcs0: - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([i915#198]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8935/shard-skl9/igt@gem_ctx_isolation@preservation...@bcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18417/shard-skl2/igt@gem_ctx_isolation@preservation...@bcs0.html * igt@gem_ctx_persistence@engines-mixed-process@rcs0: - shard-apl: [PASS][5] -> [FAIL][6] ([i915#1635] / [i915#2374]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8935/shard-apl1/igt@gem_ctx_persistence@engines-mixed-proc...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18417/shard-apl7/igt@gem_ctx_persistence@engines-mixed-proc...@rcs0.html * igt@gem_exec_reloc@basic-concurrent0: - shard-glk: [PASS][7] -> [TIMEOUT][8] ([i915#1958]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8935/shard-glk2/igt@gem_exec_re...@basic-concurrent0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18417/shard-glk4/igt@gem_exec_re...@basic-concurrent0.html - shard-skl: [PASS][9] -> [TIMEOUT][10] ([i915#1958]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8935/shard-skl2/igt@gem_exec_re...@basic-concurrent0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18417/shard-skl1/igt@gem_exec_re...@basic-concurrent0.html * igt@gem_exec_reloc@basic-concurrent16: - shard-apl: [PASS][11] -> [TIMEOUT][12] ([i915#1635] / [i915#1958]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8935/shard-apl7/igt@gem_exec_re...@basic-concurrent16.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18417/shard-apl8/igt@gem_exec_re...@basic-concurrent16.html * igt@gem_exec_whisper@basic-contexts-priority: - shard-kbl: [PASS][13] -> [TIMEOUT][14] ([i915#1958]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8935/shard-kbl4/igt@gem_exec_whis...@basic-contexts-priority.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18417/shard-kbl4/igt@gem_exec_whis...@basic-contexts-priority.html * igt@kms_big_fb@y-tiled-8bpp-rotate-180: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#1635] / [i915#1982]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8935/shard-apl6/igt@kms_big...@y-tiled-8bpp-rotate-180.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18417/shard-apl1/igt@kms_big...@y-tiled-8bpp-rotate-180.html * igt@kms_cursor_edge_walk@pipe-c-128x128-top-edge: - shard-glk: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8935/shard-glk7/igt@kms_cursor_edge_w...@pipe-c-128x128-top-edge.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18417/shard-glk6/igt@kms_cursor_edge_w...@pipe-c-128x128-top-edge.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: - shard-hsw: [PASS][19] -> [FAIL][20] ([i915#96]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8935/shard-hsw2/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18417/shard-hsw8/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html * igt@kms_flip@flip-vs-suspend-interruptible@c-dp1: - shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([i915#180]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8935/shard-kbl2/igt@kms_flip@flip-vs-suspend-interrupti...@c-dp1.html
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tgl: Fix stepping WA matching (rev3)
== Series Details ==
Series: drm/i915/tgl: Fix stepping WA matching (rev3)
URL : https://patchwork.freedesktop.org/series/80820/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8935 -> Patchwork_18417
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18417/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_18417:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@runner@aborted:
- {fi-kbl-7560u}: NOTRUN -> [FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18417/fi-kbl-7560u/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_18417 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [PASS][2] -> [DMESG-WARN][3] ([i915#1982])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8935/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18417/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [PASS][4] -> [DMESG-WARN][5] ([i915#1982])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8935/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18417/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
Possible fixes
* igt@gem_exec_fence@basic-await@vcs0:
- fi-byt-j1900: [DMESG-WARN][6] ([i915#1982]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8935/fi-byt-j1900/igt@gem_exec_fence@basic-aw...@vcs0.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18417/fi-byt-j1900/igt@gem_exec_fence@basic-aw...@vcs0.html
* igt@gem_exec_parallel@engines@fds:
- fi-skl-lmem:[INCOMPLETE][8] ([i915#2398]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8935/fi-skl-lmem/igt@gem_exec_parallel@engi...@fds.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18417/fi-skl-lmem/igt@gem_exec_parallel@engi...@fds.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-icl-u2: [DMESG-WARN][10] ([i915#1982]) -> [PASS][11] +1
similar issue
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8935/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18417/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][12] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][13] ([i915#62] / [i915#92]) +3 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8935/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18417/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [DMESG-FAIL][14] ([i915#62]) -> [DMESG-FAIL][15]
([i915#62] / [i915#95])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8935/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18417/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-kbl-x1275: [DMESG-WARN][16] ([i915#1982] / [i915#62] /
[i915#92]) -> [DMESG-WARN][17] ([i915#62] / [i915#92])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8935/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18417/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-x1275: [DMESG-WARN][18] ([i915#62] / [i915#92]) ->
[DMESG-WARN][19] ([i915#62] / [i915#92] / [i915#95]) +4 similar issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8935/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18417/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2398]: https://gitlab.freedesktop.org/drm/intel/issues/2398
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating h
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/tgl: Fix stepping WA matching (rev3)
== Series Details == Series: drm/i915/tgl: Fix stepping WA matching (rev3) URL : https://patchwork.freedesktop.org/series/80820/ State : warning == Summary == $ dim checkpatch origin/drm-tip 308f1ef1a8cb drm/i915/tgl: Fix stepping WA matching -:185: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'p' - possible side-effects? #185: FILE: drivers/gpu/drm/i915/i915_drv.h:1595: +#define IS_TGL_DISP_REVID(p, since, until) \ + (IS_TIGERLAKE(p) && \ +tgl_revids_get(p)->disp_stepping >= (since) && \ +tgl_revids_get(p)->disp_stepping <= (until)) -:190: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'p' - possible side-effects? #190: FILE: drivers/gpu/drm/i915/i915_drv.h:1600: +#define IS_TGL_UY_GT_REVID(p, since, until) \ + ((IS_TGL_U(p) || IS_TGL_Y(p)) && \ +tgl_uy_revids->gt_stepping >= (since) && \ +tgl_uy_revids->gt_stepping <= (until)) -:195: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'p' - possible side-effects? #195: FILE: drivers/gpu/drm/i915/i915_drv.h:1605: +#define IS_TGL_GT_REVID(p, since, until) \ + (IS_TIGERLAKE(p) && \ +!(IS_TGL_U(p) || IS_TGL_Y(p)) && \ +tgl_revids->gt_stepping >= (since) && \ +tgl_revids->gt_stepping <= (until)) total: 0 errors, 0 warnings, 3 checks, 144 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/tgl: Fix stepping WA matching (rev2)
== Series Details == Series: drm/i915/tgl: Fix stepping WA matching (rev2) URL : https://patchwork.freedesktop.org/series/80820/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8935 -> Patchwork_18416 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18416 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18416, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18416/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_18416: ### IGT changes ### Possible regressions * igt@i915_selftest@live@hangcheck: - fi-snb-2520m: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8935/fi-snb-2520m/igt@i915_selftest@l...@hangcheck.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18416/fi-snb-2520m/igt@i915_selftest@l...@hangcheck.html * igt@runner@aborted: - fi-snb-2520m: NOTRUN -> [FAIL][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18416/fi-snb-2520m/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_18416 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@module-reload: - fi-byt-j1900: [PASS][4] -> [DMESG-WARN][5] ([i915#1982]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8935/fi-byt-j1900/igt@i915_pm_...@module-reload.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18416/fi-byt-j1900/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@execlists: - fi-icl-y: [PASS][6] -> [INCOMPLETE][7] ([i915#2276]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8935/fi-icl-y/igt@i915_selftest@l...@execlists.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18416/fi-icl-y/igt@i915_selftest@l...@execlists.html * igt@kms_busy@basic@flip: - fi-kbl-x1275: [PASS][8] -> [DMESG-WARN][9] ([i915#62] / [i915#92] / [i915#95]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8935/fi-kbl-x1275/igt@kms_busy@ba...@flip.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18416/fi-kbl-x1275/igt@kms_busy@ba...@flip.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-bsw-kefka: [PASS][10] -> [DMESG-WARN][11] ([i915#1982]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8935/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18416/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html Possible fixes * igt@gem_exec_fence@basic-await@vcs0: - fi-byt-j1900: [DMESG-WARN][12] ([i915#1982]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8935/fi-byt-j1900/igt@gem_exec_fence@basic-aw...@vcs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18416/fi-byt-j1900/igt@gem_exec_fence@basic-aw...@vcs0.html * igt@gem_exec_parallel@engines@fds: - fi-skl-lmem:[INCOMPLETE][14] ([i915#2398]) -> [PASS][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8935/fi-skl-lmem/igt@gem_exec_parallel@engi...@fds.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18416/fi-skl-lmem/igt@gem_exec_parallel@engi...@fds.html * igt@kms_cursor_legacy@basic-flip-after-cursor-atomic: - fi-icl-u2: [DMESG-WARN][16] ([i915#1982]) -> [PASS][17] +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8935/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18416/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html Warnings * igt@gem_exec_suspend@basic-s0: - fi-kbl-x1275: [DMESG-WARN][18] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][19] ([i915#62] / [i915#92]) +3 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8935/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18416/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-kbl-x1275: [DMESG-WARN][20] ([i915#1982] / [i915#62] / [i915#92]) -> [DMESG-WARN][21] ([i915#62] / [i915#92]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8935/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18416/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html * igt@prime_vgem@ba
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/tgl: Fix stepping WA matching (rev2)
== Series Details == Series: drm/i915/tgl: Fix stepping WA matching (rev2) URL : https://patchwork.freedesktop.org/series/80820/ State : warning == Summary == $ dim checkpatch origin/drm-tip 77d51c3b553c drm/i915/tgl: Fix stepping WA matching -:185: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'p' - possible side-effects? #185: FILE: drivers/gpu/drm/i915/i915_drv.h:1595: +#define IS_TGL_DISP_REVID(p, since, until) \ + (IS_TIGERLAKE(p) && \ +tgl_revids_get(p)->disp_stepping >= (since) && \ +tgl_revids_get(p)->disp_stepping <= (until)) -:190: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'p' - possible side-effects? #190: FILE: drivers/gpu/drm/i915/i915_drv.h:1600: +#define IS_TGL_UY_GT_REVID(p, since, until) \ + ((IS_TGL_U(p) || IS_TGL_Y(p)) && \ +tgl_uy_revids->gt_stepping >= (since) && \ +tgl_uy_revids->gt_stepping <= (until)) -:195: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'p' - possible side-effects? #195: FILE: drivers/gpu/drm/i915/i915_drv.h:1605: +#define IS_TGL_GT_REVID(p, since, until) \ + (IS_TIGERLAKE(p) && \ +!(IS_TGL_U(p) || IS_TGL_Y(p)) && \ +tgl_revids->gt_stepping >= (since) && \ +tgl_revids->gt_stepping <= (until)) total: 0 errors, 0 warnings, 3 checks, 144 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/tgl: Fix stepping WA matching
TGL made stepping a litte mess, workarounds refer to the stepping of
the IP(GT or Display) not of the GPU stepping so it would already
require the same solution as used in commit 96c5a15f9f39
("drm/i915/kbl: Fix revision ID checks").
But to make things even more messy it have a different IP stepping
mapping between SKUs and the same stepping revision of GT do not match
the same HW between TGL U/Y and regular TGL.
So it was required to have 2 different macros to check GT WAs while
for Display we are able to use just one macro that uses the right
revids table.
All TGL workarounds checked and updated accordingly.
v2:
- removed TODO to check if WA 14010919138 applies to regular TGL.
- fixed display stepping in regular TGL (Anusha)
BSpec: 52890
BSpec: 55378
BSpec: 44455
Reviewed-by: Anusha Srivatsa
Cc: Anusha Srivatsa
Cc: Penne Lee
Cc: Guangyao Bai
Cc: Matt Roper
Signed-off-by: José Roberto de Souza
---
.../drm/i915/display/intel_display_power.c| 2 +-
drivers/gpu/drm/i915/display/intel_psr.c | 4 +-
drivers/gpu/drm/i915/display/intel_sprite.c | 2 +-
drivers/gpu/drm/i915/gt/intel_workarounds.c | 23 ---
drivers/gpu/drm/i915/i915_drv.h | 39 ---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
6 files changed, 57 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 7946c6af4b1e..7277e58b01f1 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -5263,7 +5263,7 @@ static void tgl_bw_buddy_init(struct drm_i915_private
*dev_priv)
unsigned long abox_mask = INTEL_INFO(dev_priv)->abox_mask;
int config, i;
- if (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_B0))
+ if (IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_B0))
/* Wa_1409767108: tgl */
table = wa_1409767108_buddy_page_masks;
else
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index 2b004ee9619c..8a9d0bdde1bf 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -555,7 +555,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
if (dev_priv->psr.psr2_sel_fetch_enabled) {
/* WA 1408330847 */
- if (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0) ||
+ if (IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0) ||
IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_A0))
intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
DIS_RAM_BYPASS_PSR2_MAN_TRACK,
@@ -1109,7 +1109,7 @@ static void intel_psr_disable_locked(struct intel_dp
*intel_dp)
/* WA 1408330847 */
if (dev_priv->psr.psr2_sel_fetch_enabled &&
- (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0) ||
+ (IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0) ||
IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_A0)))
intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
DIS_RAM_BYPASS_PSR2_MAN_TRACK, 0);
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index c26ca029fc0a..1797a06cfd60 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -2845,7 +2845,7 @@ static bool gen12_plane_supports_mc_ccs(struct
drm_i915_private *dev_priv,
{
/* Wa_14010477008:tgl[a0..c0],rkl[all] */
if (IS_ROCKETLAKE(dev_priv) ||
- IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_C0))
+ IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_C0))
return false;
return plane_id < PLANE_SPRITE4;
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index b0a7cb056633..39817c5a7058 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -70,6 +70,19 @@ const struct i915_rev_steppings kbl_revids[] = {
[7] = { .gt_stepping = KBL_REVID_G0, .disp_stepping = KBL_REVID_C0 },
};
+const struct i915_rev_steppings tgl_uy_revids[] = {
+ [0] = { .gt_stepping = TGL_REVID_A0, .disp_stepping = TGL_REVID_A0 },
+ [1] = { .gt_stepping = TGL_REVID_B0, .disp_stepping = TGL_REVID_C0 },
+ [2] = { .gt_stepping = TGL_REVID_B1, .disp_stepping = TGL_REVID_C0 },
+ [3] = { .gt_stepping = TGL_REVID_C0, .disp_stepping = TGL_REVID_D0 },
+};
+
+/* Same GT stepping between tgl_uy_revids and tgl_revids don't mean the same
HW */
+const struct i915_rev_steppings tgl_revids[] = {
+ [0] = { .gt_stepping = TGL_REVID_A0, .disp_stepping = TGL_REVID_B0 },
+ [1] = { .gt_stepping = TGL_REVID_B0, .disp_stepping = TGL_REVID_D0 },
+};
+
static void wa_init_
Re: [Intel-gfx] [PATCH] drm/i915/tgl: Fix stepping WA matching
With the stepping fix mentioned below,
Reviewed-by: Anusha Srivatsa
> -Original Message-
> From: Souza, Jose
> Sent: Thursday, August 27, 2020 3:57 PM
> To: Srivatsa, Anusha ; intel-
> g...@lists.freedesktop.org
> Cc: Bai, Guangyao ; Lee, Penne Y
>
> Subject: Re: [PATCH] drm/i915/tgl: Fix stepping WA matching
>
> On Thu, 2020-08-27 at 13:48 -0700, Srivatsa, Anusha wrote:
> > > -Original Message-
> > > From: Intel-gfx <
> > > intel-gfx-boun...@lists.freedesktop.org
> > > > On Behalf Of Souza,
> > > Jose
> > > Sent: Tuesday, August 25, 2020 12:49 PM
> > > To:
> > > intel-gfx@lists.freedesktop.org
> > >
> > > Cc: Bai, Guangyao <
> > > guangyao@intel.com
> > > >; Lee, Penne Y
> > > <
> > > penne.y@intel.com
> > > >
> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/tgl: Fix stepping WA
> > > matching
> > >
> > > On Wed, 2020-08-19 at 13:33 -0700, José Roberto de Souza wrote:
> > > > TGL made stepping a litte mess, workarounds refer to the stepping
> > > > of the IP(GT or Display) not of the GPU stepping so it would
> > > > already require the same solution as used in commit 96c5a15f9f39
> > > > ("drm/i915/kbl: Fix revision ID checks").
> > > > But to make things even more messy it have a different IP stepping
> > > > mapping between SKUs and the same stepping revision of GT do not
> > > > match the same HW between TGL U/Y and regular TGL.
> > > >
> > > > So it was required to have 2 different macros to check GT WAs
> > > > while for Display we are able to use just one macro that uses the
> > > > right revids table.
> > > >
> > > > All TGL workarounds checked and updated accordingly.
> > > >
> > > > BSpec: 52890
> > > > BSpec: 55378
> > > > BSpec: 44455
> > > > Cc: Penne Lee <
> > > > penne.y@intel.com
> > > >
> > > >
> > > > Cc: Guangyao Bai <
> > > > guangyao@intel.com
> > > >
> > > >
> > > > Cc: Matt Roper <
> > > > matthew.d.ro...@intel.com
> > > >
> > > >
> > > > Signed-off-by: José Roberto de Souza < jose.so...@intel.com
> > > >
> > > >
> > > > ---
> > > > .../drm/i915/display/intel_display_power.c| 2 +-
> > > > drivers/gpu/drm/i915/display/intel_psr.c | 4 +-
> > > > drivers/gpu/drm/i915/display/intel_sprite.c | 2 +-
> > > > drivers/gpu/drm/i915/gt/intel_workarounds.c | 24 ++--
> > > > drivers/gpu/drm/i915/i915_drv.h | 39 ---
> > > > drivers/gpu/drm/i915/intel_pm.c | 2 +-
> > > > 6 files changed, 59 insertions(+), 14 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > index 7946c6af4b1e..7277e58b01f1 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > @@ -5263,7 +5263,7 @@ static void tgl_bw_buddy_init(struct
> > >
> > > drm_i915_private *dev_priv)
> > > > unsigned long abox_mask = INTEL_INFO(dev_priv)->abox_mask;
> > > > int config, i;
> > > >
> > > > - if (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_B0))
> > > > + if (IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_B0))
> > > > /* Wa_1409767108: tgl */
> > > > table = wa_1409767108_buddy_page_masks;
> > > > else
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > > index 2b004ee9619c..8a9d0bdde1bf 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > > @@ -555,7 +555,7 @@ static void hsw_activate_psr2(struct intel_dp
> > > > *intel_dp)
> > > >
> > > > if (dev_priv->psr.psr2_sel_fetch_enabled) {
> > > > /* WA 1408330847 */
> > > > - if (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0)
> > > > ||
> > > > + if (IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0,
> > >
> > > TGL_REVID_A0) ||
> > > > IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_A0))
> > > > intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
> > > > DIS_RAM_BYPASS_PSR2_MAN_TRACK,
> > >
> > > @@ -1109,7 +1109,7 @@ static
> > > > void intel_psr_disable_locked(struct intel_dp *intel_dp)
> > > >
> > > > /* WA 1408330847 */
> > > > if (dev_priv->psr.psr2_sel_fetch_enabled &&
> > > > - (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0) ||
> > > > + (IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0) ||
> > > > IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_A0)))
> > > > intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
> > > > DIS_RAM_BYPASS_PSR2_MAN_TRACK, 0); diff
> > > > --git
> > > > a/drivers/gpu/drm/i915/display/intel_sprite.c
> > > > b/drivers/gpu/drm/i915/display/intel_sprite.c
> > > > index c26ca029fc0a..1797a06cfd60 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_
Re: [Intel-gfx] [PATCH v8 06/11] drm/i915: Enable big joiner support in enable and disable sequences.
On Mon, Aug 10, 2020 at 04:28:28PM -0700, Manasi Navare wrote:
> From: Maarten Lankhorst
>
> Make vdsc work when no output is enabled. The big joiner needs VDSC
> on the slave, so enable it and set the appropriate bits.
> Also update timestamping constants, because slave crtc's are not
> updated in drm_atomic_helper_update_legacy_modeset_state().
>
> This should be enough to bring up CRTC's in a big joiner configuration,
> without any plane configuration on the second pipe yet.
>
> HOWEVER, we still bring up the crtc's in the wrong order. We need to
> make sure that the master crtc is brought up after the slave crtc.
> This is done correctly later in this series.
>
> The next steps are to enable planes correctly, and make sure we enable
> and update both master and slave in the correct order.
>
> v2:
> * Manual rebase (Manasi)
>
> v3:
> * Rebase (Manasi)
>
> v4:
> * Rebase (Manasi)
>
> v5:
> * Get dsc power domain in ddi_init (Manasi)
>
> v6:
> * Remove dsc power put from dsc_disable (Maarten)
>
> Signed-off-by: Maarten Lankhorst
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/i915/display/icl_dsi.c| 2 -
> drivers/gpu/drm/i915/display/intel_ddi.c | 68 +++-
> drivers/gpu/drm/i915/display/intel_display.c | 377 --
> .../drm/i915/display/intel_display_types.h| 1 +
> drivers/gpu/drm/i915/display/intel_dp.c | 6 +-
> drivers/gpu/drm/i915/display/intel_vdsc.c | 201 +-
> drivers/gpu/drm/i915/display/intel_vdsc.h | 7 +-
> 7 files changed, 413 insertions(+), 249 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index 8c55f5bee9ab..26f7372b4c25 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -1454,8 +1454,6 @@ static void gen11_dsi_get_config(struct intel_encoder
> *encoder,
> struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
> struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
>
> - intel_dsc_get_config(encoder, pipe_config);
Maarten,
Why do we need to remove this from dsi_get_config()?
> -
> /* FIXME: adapt icl_ddi_clock_get() for DSI and use that? */
> pipe_config->port_clock = intel_dpll_get_freq(i915,
> pipe_config->shared_dpll);
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index de5b216561d8..6de13c67f5b8 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -28,6 +28,7 @@
> #include
>
> #include "i915_drv.h"
> +#include "i915_trace.h"
> #include "intel_audio.h"
> #include "intel_combo_phy.h"
> #include "intel_connector.h"
> @@ -2093,12 +2094,6 @@ static void intel_ddi_get_power_domains(struct
> intel_encoder *encoder,
> intel_display_power_get(dev_priv,
>
> intel_ddi_main_link_aux_domain(dig_port));
>
> - /*
> - * VDSC power is needed when DSC is enabled
> - */
> - if (crtc_state->dsc.compression_enable)
> - intel_display_power_get(dev_priv,
> - intel_dsc_power_domain(crtc_state));
> }
>
> void intel_ddi_enable_pipe_clock(struct intel_encoder *encoder,
> @@ -3387,7 +3382,8 @@ static void tgl_ddi_pre_enable_dp(struct
> intel_atomic_state *state,
>
> /* 7.l Configure and enable FEC if needed */
> intel_ddi_enable_fec(encoder, crtc_state);
> - intel_dsc_enable(encoder, crtc_state);
> + if (!crtc_state->bigjoiner)
> + intel_dsc_enable(encoder, crtc_state);
> }
>
> static void hsw_ddi_pre_enable_dp(struct intel_atomic_state *state,
> @@ -3458,7 +3454,8 @@ static void hsw_ddi_pre_enable_dp(struct
> intel_atomic_state *state,
> if (!is_mst)
> intel_ddi_enable_pipe_clock(encoder, crtc_state);
>
> - intel_dsc_enable(encoder, crtc_state);
> + if (!crtc_state->bigjoiner)
> + intel_dsc_enable(encoder, crtc_state);
> }
>
> static void intel_ddi_pre_enable_dp(struct intel_atomic_state *state,
> @@ -3713,6 +3710,21 @@ static void intel_ddi_post_disable(struct
> intel_atomic_state *state,
> ilk_pfit_disable(old_crtc_state);
> }
>
> + if (old_crtc_state->bigjoiner_linked_crtc) {
> + struct intel_atomic_state *state =
> + to_intel_atomic_state(old_crtc_state->uapi.state);
> + struct intel_crtc *slave =
> + old_crtc_state->bigjoiner_linked_crtc;
> + const struct intel_crtc_state *old_slave_crtc_state =
> + intel_atomic_get_old_crtc_state(state, slave);
> +
> + intel_crtc_vblank_off(old_slave_crtc_state);
> + trace_intel_pipe_disable(slave);
> +
> + intel_dsc_disable(old_slave_crtc_state);
> + skl_scaler_disab
Re: [Intel-gfx] [PATCH] drm/i915/tgl: Fix stepping WA matching
On Thu, 2020-08-27 at 13:48 -0700, Srivatsa, Anusha wrote:
> > -Original Message-
> > From: Intel-gfx <
> > intel-gfx-boun...@lists.freedesktop.org
> > > On Behalf Of Souza,
> > Jose
> > Sent: Tuesday, August 25, 2020 12:49 PM
> > To:
> > intel-gfx@lists.freedesktop.org
> >
> > Cc: Bai, Guangyao <
> > guangyao@intel.com
> > >; Lee, Penne Y
> > <
> > penne.y@intel.com
> > >
> > Subject: Re: [Intel-gfx] [PATCH] drm/i915/tgl: Fix stepping WA matching
> >
> > On Wed, 2020-08-19 at 13:33 -0700, José Roberto de Souza wrote:
> > > TGL made stepping a litte mess, workarounds refer to the stepping of
> > > the IP(GT or Display) not of the GPU stepping so it would already
> > > require the same solution as used in commit 96c5a15f9f39
> > > ("drm/i915/kbl: Fix revision ID checks").
> > > But to make things even more messy it have a different IP stepping
> > > mapping between SKUs and the same stepping revision of GT do not match
> > > the same HW between TGL U/Y and regular TGL.
> > >
> > > So it was required to have 2 different macros to check GT WAs while
> > > for Display we are able to use just one macro that uses the right
> > > revids table.
> > >
> > > All TGL workarounds checked and updated accordingly.
> > >
> > > BSpec: 52890
> > > BSpec: 55378
> > > BSpec: 44455
> > > Cc: Penne Lee <
> > > penne.y@intel.com
> > >
> > >
> > > Cc: Guangyao Bai <
> > > guangyao@intel.com
> > >
> > >
> > > Cc: Matt Roper <
> > > matthew.d.ro...@intel.com
> > >
> > >
> > > Signed-off-by: José Roberto de Souza <
> > > jose.so...@intel.com
> > >
> > >
> > > ---
> > > .../drm/i915/display/intel_display_power.c| 2 +-
> > > drivers/gpu/drm/i915/display/intel_psr.c | 4 +-
> > > drivers/gpu/drm/i915/display/intel_sprite.c | 2 +-
> > > drivers/gpu/drm/i915/gt/intel_workarounds.c | 24 ++--
> > > drivers/gpu/drm/i915/i915_drv.h | 39 ---
> > > drivers/gpu/drm/i915/intel_pm.c | 2 +-
> > > 6 files changed, 59 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > index 7946c6af4b1e..7277e58b01f1 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > @@ -5263,7 +5263,7 @@ static void tgl_bw_buddy_init(struct
> >
> > drm_i915_private *dev_priv)
> > > unsigned long abox_mask = INTEL_INFO(dev_priv)->abox_mask;
> > > int config, i;
> > >
> > > - if (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_B0))
> > > + if (IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_B0))
> > > /* Wa_1409767108: tgl */
> > > table = wa_1409767108_buddy_page_masks;
> > > else
> > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > index 2b004ee9619c..8a9d0bdde1bf 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > @@ -555,7 +555,7 @@ static void hsw_activate_psr2(struct intel_dp
> > > *intel_dp)
> > >
> > > if (dev_priv->psr.psr2_sel_fetch_enabled) {
> > > /* WA 1408330847 */
> > > - if (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0) ||
> > > + if (IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0,
> >
> > TGL_REVID_A0) ||
> > > IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_A0))
> > > intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
> > >DIS_RAM_BYPASS_PSR2_MAN_TRACK,
> >
> > @@ -1109,7 +1109,7 @@ static
> > > void intel_psr_disable_locked(struct intel_dp *intel_dp)
> > >
> > > /* WA 1408330847 */
> > > if (dev_priv->psr.psr2_sel_fetch_enabled &&
> > > - (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0) ||
> > > + (IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0) ||
> > >IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_A0)))
> > > intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
> > >DIS_RAM_BYPASS_PSR2_MAN_TRACK, 0); diff --git
> > > a/drivers/gpu/drm/i915/display/intel_sprite.c
> > > b/drivers/gpu/drm/i915/display/intel_sprite.c
> > > index c26ca029fc0a..1797a06cfd60 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> > > @@ -2845,7 +2845,7 @@ static bool
> >
> > gen12_plane_supports_mc_ccs(struct
> > > drm_i915_private *dev_priv, {
> > > /* Wa_14010477008:tgl[a0..c0],rkl[all] */
> > > if (IS_ROCKETLAKE(dev_priv) ||
> > > - IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_C0))
> > > + IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_C0))
> > > return false;
> > >
> > > return plane_id < PLANE_SPRITE4;
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > index be5a4685c991..860d6ae1d866 100644
> > > --- a/driver
Re: [Intel-gfx] [PATCH 0/8] Convert the intel iommu driver to the dma-iommu api
On 2020-08-23 6:04 p.m., Tom Murphy wrote:
> I have added a check for the sg_dma_len == 0 :
> """
> } __sgt_iter(struct scatterlist *sgl, bool dma) {
> struct sgt_iter s = { .sgp = sgl };
>
> + if (sgl && sg_dma_len(sgl) == 0)
> + s.sgp = NULL;
>
> if (s.sgp) {
> .
> """
> at location [1].
> but it doens't fix the problem.
Based on my read of the code, it looks like we also need to change usage
of sgl->length... Something like the rough patch below, maybe?
Also, Tom, do you have an updated version of the patchset to convert the
Intel IOMMU to dma-iommu available? The last one I've found doesn't
apply cleanly (I'm assuming parts of it have been merged in slightly
modified forms).
Thanks,
Logan
--
diff --git a/drivers/gpu/drm/i915/i915_scatterlist.h
b/drivers/gpu/drm/i915/i915
index b7b59328cb76..9367ac801f0c 100644
--- a/drivers/gpu/drm/i915/i915_scatterlist.h
+++ b/drivers/gpu/drm/i915/i915_scatterlist.h
@@ -27,13 +27,19 @@ static __always_inline struct sgt_iter {
} __sgt_iter(struct scatterlist *sgl, bool dma) {
struct sgt_iter s = { .sgp = sgl };
+ if (sgl && !sg_dma_len(s.sgp))
+ s.sgp = NULL;
+
if (s.sgp) {
s.max = s.curr = s.sgp->offset;
- s.max += s.sgp->length;
- if (dma)
+
+ if (dma) {
+ s.max += sg_dma_len(s.sgp);
s.dma = sg_dma_address(s.sgp);
- else
+ } else {
+ s.max += s.sgp->length;
s.pfn = page_to_pfn(sg_page(s.sgp));
+ }
}
return s;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/tgl: Fix stepping WA matching
> -Original Message-
> From: Intel-gfx On Behalf Of Souza,
> Jose
> Sent: Tuesday, August 25, 2020 12:49 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Bai, Guangyao ; Lee, Penne Y
>
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/tgl: Fix stepping WA matching
>
> On Wed, 2020-08-19 at 13:33 -0700, José Roberto de Souza wrote:
> > TGL made stepping a litte mess, workarounds refer to the stepping of
> > the IP(GT or Display) not of the GPU stepping so it would already
> > require the same solution as used in commit 96c5a15f9f39
> > ("drm/i915/kbl: Fix revision ID checks").
> > But to make things even more messy it have a different IP stepping
> > mapping between SKUs and the same stepping revision of GT do not match
> > the same HW between TGL U/Y and regular TGL.
> >
> > So it was required to have 2 different macros to check GT WAs while
> > for Display we are able to use just one macro that uses the right
> > revids table.
> >
> > All TGL workarounds checked and updated accordingly.
> >
> > BSpec: 52890
> > BSpec: 55378
> > BSpec: 44455
> > Cc: Penne Lee <
> > penne.y@intel.com
> > >
> > Cc: Guangyao Bai <
> > guangyao@intel.com
> > >
> > Cc: Matt Roper <
> > matthew.d.ro...@intel.com
> > >
> > Signed-off-by: José Roberto de Souza < jose.so...@intel.com
> > >
> > ---
> > .../drm/i915/display/intel_display_power.c| 2 +-
> > drivers/gpu/drm/i915/display/intel_psr.c | 4 +-
> > drivers/gpu/drm/i915/display/intel_sprite.c | 2 +-
> > drivers/gpu/drm/i915/gt/intel_workarounds.c | 24 ++--
> > drivers/gpu/drm/i915/i915_drv.h | 39 ---
> > drivers/gpu/drm/i915/intel_pm.c | 2 +-
> > 6 files changed, 59 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > index 7946c6af4b1e..7277e58b01f1 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > @@ -5263,7 +5263,7 @@ static void tgl_bw_buddy_init(struct
> drm_i915_private *dev_priv)
> > unsigned long abox_mask = INTEL_INFO(dev_priv)->abox_mask;
> > int config, i;
> >
> > - if (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_B0))
> > + if (IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_B0))
> > /* Wa_1409767108: tgl */
> > table = wa_1409767108_buddy_page_masks;
> > else
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index 2b004ee9619c..8a9d0bdde1bf 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -555,7 +555,7 @@ static void hsw_activate_psr2(struct intel_dp
> > *intel_dp)
> >
> > if (dev_priv->psr.psr2_sel_fetch_enabled) {
> > /* WA 1408330847 */
> > - if (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0) ||
> > + if (IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0,
> TGL_REVID_A0) ||
> > IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_A0))
> > intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
> > DIS_RAM_BYPASS_PSR2_MAN_TRACK,
> @@ -1109,7 +1109,7 @@ static
> > void intel_psr_disable_locked(struct intel_dp *intel_dp)
> >
> > /* WA 1408330847 */
> > if (dev_priv->psr.psr2_sel_fetch_enabled &&
> > - (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0) ||
> > + (IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0) ||
> > IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_A0)))
> > intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
> > DIS_RAM_BYPASS_PSR2_MAN_TRACK, 0); diff --git
> > a/drivers/gpu/drm/i915/display/intel_sprite.c
> > b/drivers/gpu/drm/i915/display/intel_sprite.c
> > index c26ca029fc0a..1797a06cfd60 100644
> > --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> > @@ -2845,7 +2845,7 @@ static bool
> gen12_plane_supports_mc_ccs(struct
> > drm_i915_private *dev_priv, {
> > /* Wa_14010477008:tgl[a0..c0],rkl[all] */
> > if (IS_ROCKETLAKE(dev_priv) ||
> > - IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_C0))
> > + IS_TGL_DISP_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_C0))
> > return false;
> >
> > return plane_id < PLANE_SPRITE4;
> > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > index be5a4685c991..860d6ae1d866 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > @@ -70,6 +70,19 @@ const struct i915_rev_steppings kbl_revids[] = {
> > [7] = { .gt_stepping = KBL_REVID_G0, .disp_stepping = KBL_REVID_C0
> > }, };
> >
> > +const struct i915_rev_steppings tgl_uy_revids[] = {
> > + [0] = { .gt_stepping = TGL_REVID_A0, .disp_stepping = TGL_REVID_A0
> },
> > + [1] =
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v3,1/3] drm/i915/display: Compute has_drrs after compute has_psr
On Tue, 2020-08-25 at 18:50 +, Patchwork wrote: > Patch Details > Series: series starting with [v3,1/3] drm/i915/display: Compute > has_drrs after compute has_psr > URL: https://patchwork.freedesktop.org/series/80989/ > State:failure > Details: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18398/index.html > CI Bug Log - changes from CI_DRM_8924_full -> Patchwork_18398_full > Summary > FAILURE > > Serious unknown changes coming with Patchwork_18398_full absolutely need to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_18398_full, please notify your bug team to allow them > to document this new failure mode, which will reduce false positives in CI. > > Possible new issues > Here are the unknown changes that may have been introduced in > Patchwork_18398_full: > > IGT changes > Possible regressions > igt@gem_sync@basic-store-all: > shard-tglb: PASS -> FAIL Changes not related, so patches pushed to dinq.Thanks for the reviews Anshuman. > Known issues > Here are the changes found in Patchwork_18398_full that come from known > issues: > > IGT changes > Issues hit > igt@gem_exec_reloc@basic-concurrent0: > > shard-apl: PASS -> TIMEOUT (i915#1635 / i915#1958) +1 similar issue > igt@gem_exec_whisper@basic-fds-forked-all: > > shard-kbl: PASS -> TIMEOUT (i915#1958) +1 similar issue > igt@gem_exec_whisper@basic-queues-priority-all: > > shard-glk: PASS -> TIMEOUT (i915#1958) +1 similar issue > igt@i915_pm_dc@dc5-psr: > > shard-skl: PASS -> INCOMPLETE (i915#198) > igt@kms_big_fb@x-tiled-64bpp-rotate-0: > > shard-glk: PASS -> DMESG-FAIL (i915#118 / i915#95) +1 similar issue > igt@kms_big_fb@x-tiled-8bpp-rotate-0: > > shard-apl: PASS -> DMESG-WARN (i915#1635 / i915#1982) +1 similar issue > igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: > > shard-hsw: PASS -> FAIL (i915#96) > igt@kms_cursor_legacy@flip-vs-cursor-crc-atomic: > > shard-kbl: PASS -> DMESG-WARN (i915#1982) > igt@kms_cursor_legacy@flip-vs-cursor-legacy: > > shard-skl: PASS -> FAIL (i915#2346) > igt@kms_flip@flip-vs-expired-vblank@c-dp1: > > shard-apl: PASS -> FAIL (i915#1635 / i915#79) > igt@kms_flip@flip-vs-suspend@c-hdmi-a1: > > shard-hsw: PASS -> INCOMPLETE (i915#2055) > igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-mmap-wc: > > shard-tglb: PASS -> DMESG-WARN (i915#1982) +1 similar issue > igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-shrfb-draw-mmap-gtt: > > shard-skl: PASS -> FAIL (i915#49) > igt@kms_hdr@bpc-switch-suspend: > > shard-kbl: PASS -> DMESG-WARN (i915#180) +7 similar issues > igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: > > shard-skl: PASS -> FAIL (fdo#108145 / i915#265) +1 similar issue > igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: > > shard-skl: PASS -> DMESG-WARN (i915#1982) +7 similar issues > igt@kms_psr@psr2_sprite_plane_onoff: > > shard-iclb: PASS -> SKIP (fdo#109441) > igt@perf@blocking-parameterized: > > shard-iclb: PASS -> FAIL (i915#1542) > Possible fixes > igt@gem_exec_gttfill@all: > > shard-apl: TIMEOUT (i915#1635 / i915#1958) -> PASS > igt@gem_exec_nop@basic-sequential: > > shard-tglb: TIMEOUT (i915#1958) -> PASS +2 similar issues > igt@gem_exec_parallel@engines@basic: > > shard-kbl: INCOMPLETE -> PASS > igt@gem_exec_reloc@basic-concurrent0: > > shard-skl: TIMEOUT (i915#1958) -> PASS > igt@gem_exec_whisper@basic-contexts: > > shard-glk: TIMEOUT (i915#1958) -> PASS +3 similar issues > igt@gem_exec_whisper@basic-forked: > > shard-iclb: TIMEOUT (i915#1958) -> PASS +1 similar issue > igt@gem_exec_whisper@basic-normal: > > shard-kbl: TIMEOUT (i915#1958) -> PASS > igt@gem_sync@basic-store-all: > > shard-apl: FAIL (i915#1635) -> PASS > > shard-kbl: FAIL -> PASS > > igt@i915_selftest@mock@requests: > > shard-skl: INCOMPLETE (i915#198 / i915#2278) -> PASS > igt@kms_cursor_crc@pipe-b-cursor-128x128-sliding: > > shard-skl: DMESG-FAIL (i915#1982 / i915#54) -> PASS > igt@kms_flip@2x-wf_vblank-ts-check@ab-vga1-hdmi-a1: > > shard-hsw: DMESG-WARN (i915#1982) -> PASS > igt@kms_flip@flip-vs-suspend-interruptible@a-dp1: > > shard-kbl: DMESG-WARN (i915#180) -> PASS +6 similar issues > igt@kms_flip@plain-flip-fb-recreate-interruptible@a-edp1: > > shard-skl: FAIL (i915#2122) -> PASS > igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-pwrite: > > shard-kbl: DMESG-WARN (i915#1982) -> PASS > igt@kms_frontbuffer_tracking@fbcpsr-suspend: > > shard-tglb: DMESG-WARN (i915#1982) -> PASS +3 similar issues > igt@kms_hdr@bpc-switch-dpms: > > shard-skl: FAIL (i915#1188) -> PASS > igt@kms_plane_scaling@pipe-a-scaler-with-clipping-clamping: > > shard-iclb: DMESG-WARN (i915#1982) -> PASS > igt@kms_psr@psr2_primary_mmap_cpu: > > shard-iclb: SKIP (fdo#109441) -> PASS +1 similar issue > igt@perf@gen8-unprivileged-single-ctx-counters: > > shard-skl: DMESG-WARN (i915#1982) -> PASS +10 similar issues > Warnings > igt@gem_exec_reloc@basic-many-active@rcs0: > > shard-apl:
Re: [Intel-gfx] [PATCH v3 1/3] drm/i915/display: Compute has_drrs after compute has_psr
On Thu, 2020-08-27 at 17:39 +0530, Anshuman Gupta wrote:
> On 2020-08-26 at 22:17:38 +0530, Souza, Jose wrote:
> > On Wed, 2020-08-26 at 12:56 +0530, Anshuman Gupta wrote:
> > > On 2020-08-25 at 10:13:29 -0700, José Roberto de Souza wrote:
> > > > DRRS and PSR can't be enable together, so giving preference to PSR
> > > > as it allows more power-savings by complete shutting down display,
> > > > so to guarantee this, it should compute DRRS state after compute PSR.
> > > >
> > > > Cc: Srinivas K <
> > > > srinivas...@intel.com
> > > >
> > > >
> > > > Cc: Hariom Pandey <
> > > > hariom.pan...@intel.com
> > > >
> > > >
> > > > Reviewed-by: Anshuman Gupta <
> > > > anshuman.gu...@intel.com
> > > >
> > > >
> > > > Signed-off-by: José Roberto de Souza <
> > > > jose.so...@intel.com
> > > >
> > > >
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_dp.c | 52 +++--
> > > > 1 file changed, 32 insertions(+), 20 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > index 79c27f91f42c..a08d03c61b02 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > @@ -2575,6 +2575,34 @@
> > > > intel_dp_compute_hdr_metadata_infoframe_sdp(struct intel_dp *intel_dp,
> > > >
> > > > intel_hdmi_infoframe_enable(HDMI_PACKET_TYPE_GAMUT_METADATA);
> > > > }
> > > >
> > > > +static void
> > > > +intel_dp_drrs_compute_config(struct intel_dp *intel_dp,
> > > > +struct intel_crtc_state *pipe_config,
> > > > +int output_bpp, bool constant_n)
> > > > +{
> > > > + struct intel_connector *intel_connector =
> > > > intel_dp->attached_connector;
> > > > + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > > > +
> > > > + /*
> > > > +* DRRS and PSR can't be enable together, so giving preference
> > > > to PSR
> > > > +* as it allows more power-savings by complete shutting down
> > > > display,
> > > > +* so to guarantee this, intel_dp_drrs_compute_config() must be
> > > > called
> > > > +* after intel_psr_compute_config().
> > > > +*/
> > > > + if (pipe_config->has_psr)
> > > > + return;
> > > > +
> > > > + if (!intel_connector->panel.downclock_mode ||
> > > > + dev_priv->drrs.type != SEAMLESS_DRRS_SUPPORT)
> > > > + return;
> > > > +
> > > > + pipe_config->has_drrs = true;
> > > > + intel_link_compute_m_n(output_bpp, pipe_config->lane_count,
> > > > +
> > > > intel_connector->panel.downclock_mode->clock,
> > > > + pipe_config->port_clock,
> > > > &pipe_config->dp_m2_n2,
> > > > + constant_n, pipe_config->fec_enable);
> > > > +}
> > > > +
> > > > int
> > > > intel_dp_compute_config(struct intel_encoder *encoder,
> > > > struct intel_crtc_state *pipe_config,
> > > > @@ -2605,7 +2633,6 @@ intel_dp_compute_config(struct intel_encoder
> > > > *encoder,
> > > > if (ret)
> > > > return ret;
> > > >
> > > > - pipe_config->has_drrs = false;
> > >
> > > IMHO this assignment is required, i was thinking a case, when a crtc is
> > > attached to more than
> > > one connector, suppose first eDP connector supports DRRS from
> > > panel.downclock_mode and
> > > drrs.type but another DP connector won't support it in that case has_drrs
> > > will be still
> > > true.
> > > Please correct me if i am wrong here.
> >
> > i915 only supports one connector per pipe/CRTC, if that was the case all
> > other flags in intel_crtc_state would also have the same behaviour as
> > has_drrs.
>
> Actually once on kabylake i had witnessed this use case when a CRTC was
> attached to multiple connectors, AFAIU theortically also
> it seems possible as intel_modeset_pipe_config iterate for each connector in
> state for a given crtc i.e (connector_state->crtc == crtc)
> and call encoder->compute_config().
> If you are sure above case can't happen for drrs you can use my RB.
> Applicable for [PATCH 3/3] of this series,
> Reviewed-by: Anshuman Gupta <
> anshuman.gu...@intel.com
PSR would have a lot of issues if such scenario was possible.Patches pushed,
thanks for the review.
> >
> > > Thanks,
> > > Anshuman Gupta.
> > > > if (!intel_dp_port_has_audio(dev_priv, port))
> > > > pipe_config->has_audio = false;
> > > > else if (intel_conn_state->force_audio == HDMI_AUDIO_AUTO)
> > > > @@ -2657,21 +2684,12 @@ intel_dp_compute_config(struct intel_encoder
> > > > *encoder,
> > > >&pipe_config->dp_m_n,
> > > >constant_n, pipe_config->fec_enable);
> > > >
> > > > - if (intel_connector->panel.downclock_mode != NULL &&
> > > > -
Re: [Intel-gfx] [PATCH] drm/i915/vlv_dsi_pll: fix spelling mistake "Cant" -> "Can't"
On Mon, Aug 10, 2020 at 10:59:52AM +0100, Colin King wrote:
> From: Colin Ian King
>
> There is a spelling mistake in a drm_err message. Fix it.
Thanks. Applied to dinq.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/i915/display/vlv_dsi_pll.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/vlv_dsi_pll.c
> b/drivers/gpu/drm/i915/display/vlv_dsi_pll.c
> index d0a514301575..4070b00c3690 100644
> --- a/drivers/gpu/drm/i915/display/vlv_dsi_pll.c
> +++ b/drivers/gpu/drm/i915/display/vlv_dsi_pll.c
> @@ -483,7 +483,7 @@ int bxt_dsi_pll_compute(struct intel_encoder *encoder,
>
> if (dsi_ratio < dsi_ratio_min || dsi_ratio > dsi_ratio_max) {
> drm_err(&dev_priv->drm,
> - "Cant get a suitable ratio from DSI PLL ratios\n");
> + "Can't get a suitable ratio from DSI PLL ratios\n");
> return -ECHRNG;
> } else
> drm_dbg_kms(&dev_priv->drm, "DSI PLL calculation is Done!!\n");
> --
> 2.27.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-next
Hi Daniel, Dave, Here's a re-run of last week's PR (without all the -rc1 churn) plus the patches that got in this week. Thanks! Maxime drm-misc-next-2020-08-27: drm-misc-next for 5.10: UAPI Changes: Cross-subsystem Changes: Core Changes: - ttm: various cleanups and reworks of the API Driver Changes: - ast: various cleanups - gma500: A few fixes, conversion to GPIOd API - hisilicon: Change of maintainer, various reworks - ingenic: Clock handling and formats support improvements - mcde: improvements to the DSI support - mgag200: Support G200 desktop cards - mxsfb: Support the i.MX7 and i.MX8M and the alpha plane - panfrost: support devfreq - ps8640: Retrieve the EDID from eDP control, misc improvements - tidss: Add a workaround for AM65xx YUV formats handling - virtio: a few cleanups, support for virtio-gpu exported resources - bridges: Support the chained bridges on more drivers, new bridges: Toshiba TC358762, Toshiba TC358775, Lontium LT9611 - panels: Convert to dev_ based logging, read orientation from the DT, various fixes, new panels: Mantix MLAF057WE51-X, Chefree CH101OLHLWH-002, Powertip PH800480T013, KingDisplay KD116N21-30NV-A010 The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5: Linux 5.9-rc1 (2020-08-16 13:04:57 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2020-08-27 for you to fetch changes up to cd6da0b113512b15a4d35f355f9ecd8858297369: drm/mgag200: fix spelling mistake "expeced" -> "expected" (2020-08-27 11:17:52 +0200) drm-misc-next for 5.10: UAPI Changes: Cross-subsystem Changes: Core Changes: - ttm: various cleanups and reworks of the API Driver Changes: - ast: various cleanups - gma500: A few fixes, conversion to GPIOd API - hisilicon: Change of maintainer, various reworks - ingenic: Clock handling and formats support improvements - mcde: improvements to the DSI support - mgag200: Support G200 desktop cards - mxsfb: Support the i.MX7 and i.MX8M and the alpha plane - panfrost: support devfreq - ps8640: Retrieve the EDID from eDP control, misc improvements - tidss: Add a workaround for AM65xx YUV formats handling - virtio: a few cleanups, support for virtio-gpu exported resources - bridges: Support the chained bridges on more drivers, new bridges: Toshiba TC358762, Toshiba TC358775, Lontium LT9611 - panels: Convert to dev_ based logging, read orientation from the DT, various fixes, new panels: Mantix MLAF057WE51-X, Chefree CH101OLHLWH-002, Powertip PH800480T013, KingDisplay KD116N21-30NV-A010 Bernard Zhao (1): drm/panel: remove return value of function drm_panel_add Christian König (18): drm/radeon: stop using TTM_MEMTYPE_FLAG_MAPPABLE drm/amdgpu: stop using TTM_MEMTYPE_FLAG_MAPPABLE drm/ttm: remove TTM_MEMTYPE_FLAG_MAPPABLE drm/ttm: fix pipelined gutting for evictions v2 drm/ttm: initialize the system domain with defaults v2 drm/ttm: remove TTM_MEMTYPE_FLAG_FIXED v2 drm/radeon: stop implementing init_mem_type drm/amdgpu: stop implementing init_mem_type drm/vmwgfx: stop implementing init_mem_type v2 drm/nouveau: stop implementing init_mem_type drm/qxl: stop implementing init_mem_type drm/vram-helper: stop implementing init_mem_type drm/ttm: remove the init_mem_type callback drm/amdgpu: make sure userptr ttm is allocated drm/ttm: rename ttm_resource_manager_func callbacks drm/ttm: give resource functions their own [ch] files drm/radeon: drop superflous AGP handling drm/ttm: fix broken merge between drm-next and drm-misc-next Clément Péron (10): drm/panfrost: avoid static declaration drm/panfrost: clean headers in devfreq drm/panfrost: don't use pfdevfreq.busy_count to know if hw is idle drm/panfrost: introduce panfrost_devfreq struct drm/panfrost: use spinlock instead of atomic drm/panfrost: properly handle error in probe drm/panfrost: rename error labels in device_init drm/panfrost: move devfreq_init()/fini() in device drm/panfrost: dynamically alloc regulators drm/panfrost: add regulators to devfreq Colin Ian King (4): drm/gma500: fix spelling mistake "pannel" -> "panel" drm/virtgpu: remove redundant assignments to width and height drm/omap: fix spelling mistake "propert" -> "property" drm/mgag200: fix spelling mistake "expeced" -> "expected" Daniel Vetter (1): drm/syncobj: Tune down unordered timeline DRM_ERROR Dave Airlie (64): drm/vmwgfx: consolidate ttm object creation and populate drm/vmwgfx: drop bo map/unmap dma functions. nouveau: use ttm populate mapping functions. (v2) qxl/ttm: drop the unusued no wait flag to reserve function d
Re: [Intel-gfx] [PATCH 2/8] mm: Use find_get_swap_page in memcontrol
On Thu, Aug 27, 2020 at 01:59:41PM +0100, Matthew Wilcox wrote: > On Wed, Aug 26, 2020 at 10:20:02AM -0400, Johannes Weiner wrote: > > The refactor makes sense to me, but the name is confusing. We're not > > looking for a swap page, we're primarily looking for a file page in > > the page cache mapping that's handed in. Only in the special case > > where it's a shmem mapping and there is a swap entry do we consult the > > auxiliary swap cache. > > > > How about find_get_page_or_swapcache()? find_get_page_shmemswap()? > > Maybe you have a better idea. It's a fairly specialized operation that > > isn't widely used, so a longer name isn't a bad thing IMO. > > Got it. find_get_incore_page(). I was going to go with inmem, but that > it matches mincore sold me on it. > > /** > * find_get_incore_page - Find and get a page from the page or swap caches. > * @mapping: The address_space to search. > * @index: The page cache index. > * > * This differs from find_get_page() in that it will also look for the > * page in the swap cache. > * > * Return: The found page or %NULL. > */ Nice work, that's perfect. > I was focusing too much on what the function did, not why it was doing it. Me too. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 13/20] drm/i915/dp: Extract drm_dp_read_downstream_info()
On Wed, 26 Aug 2020, Lyude Paul wrote:
> We're going to be doing the same probing process in nouveau for
> determining downstream DP port capabilities, so let's deduplicate the
> work by moving i915's code for handling this into a shared helper:
> drm_dp_read_downstream_info().
>
> Note that when we do this, we also do make some functional changes while
> we're at it:
> * We always clear the downstream port info before trying to read it,
> just to make things easier for the caller
> * We skip reading downstream port info if the DPCD indicates that we
> don't support downstream port info
> * We only read as many bytes as needed for the reported number of
> downstream ports, no sense in reading the whole thing every time
>
> v2:
> * Fixup logic for calculating the downstream port length to account for
> the fact that downstream port caps can be either 1 byte or 4 bytes
> long. We can actually skip fixing the max_clock/max_bpc helpers here
> since they all check for DP_DETAILED_CAP_INFO_AVAILABLE anyway.
> * Fix ret code check for drm_dp_dpcd_read
> v5:
> * Change name from drm_dp_downstream_read_info() to
> drm_dp_read_downstream_info()
> * Also, add "See Also" sections for the various downstream info
> functions (drm_dp_read_downstream_info(), drm_dp_downstream_max_clock(),
> drm_dp_downstream_max_bpc())
>
> Reviewed-by: Sean Paul
> Signed-off-by: Lyude Paul
>
> squash! drm/i915/dp: Extract drm_dp_read_downstream_info()
Whoops!
>
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/drm_dp_helper.c | 62 -
> drivers/gpu/drm/i915/display/intel_dp.c | 14 +-
> include/drm/drm_dp_helper.h | 3 ++
> 3 files changed, 65 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 4c21cf69dad5a..f3643894ad951 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -423,6 +423,56 @@ bool drm_dp_send_real_edid_checksum(struct drm_dp_aux
> *aux,
> }
> EXPORT_SYMBOL(drm_dp_send_real_edid_checksum);
>
> +static u8 drm_dp_downstream_port_count(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> +{
> + u8 port_count = dpcd[DP_DOWN_STREAM_PORT_COUNT] & DP_PORT_COUNT_MASK;
> +
> + if (dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DETAILED_CAP_INFO_AVAILABLE &&
> port_count > 4)
> + port_count = 4;
> +
> + return port_count;
> +}
> +
> +/**
> + * drm_dp_read_downstream_info() - read DPCD downstream port info if
> available
> + * @aux: DisplayPort AUX channel
> + * @dpcd: A cached copy of the port's DPCD
> + * @downstream_ports: buffer to store the downstream port info in
> + *
> + * See also:
> + * drm_dp_downstream_max_clock()
> + * drm_dp_downstream_max_bpc()
> + *
> + * Returns: 0 if either the downstream port info was read successfully or
> + * there was no downstream info to read, or a negative error code otherwise.
> + */
> +int drm_dp_read_downstream_info(struct drm_dp_aux *aux,
> + const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> + u8 downstream_ports[DP_MAX_DOWNSTREAM_PORTS])
> +{
> + int ret;
> + u8 len;
> +
> + memset(downstream_ports, 0, DP_MAX_DOWNSTREAM_PORTS);
> +
> + /* No downstream info to read */
> + if (!drm_dp_is_branch(dpcd) ||
> + dpcd[DP_DPCD_REV] < DP_DPCD_REV_10 ||
> + !(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT))
> + return 0;
Generally I think stuff like this is easier and faster to read with
multiple if statements and early returns, but *shrug*.
I really hope we didn't have a reason to not check
DP_DWN_STRM_PORT_PRESENT here... there's been a lot of junk branch
devices in the past. Fingers crossed.
Reviewed-by: Jani Nikula
> +
> + len = drm_dp_downstream_port_count(dpcd);
> + if (dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DETAILED_CAP_INFO_AVAILABLE)
> + len *= 4;
> +
> + ret = drm_dp_dpcd_read(aux, DP_DOWNSTREAM_PORT_0, downstream_ports,
> len);
> + if (ret < 0)
> + return ret;
> +
> + return ret == len ? 0 : -EIO;
> +}
> +EXPORT_SYMBOL(drm_dp_read_downstream_info);
> +
> /**
> * drm_dp_downstream_max_clock() - extract branch device max
> * pixel rate for legacy VGA
> @@ -431,7 +481,11 @@ EXPORT_SYMBOL(drm_dp_send_real_edid_checksum);
> * @dpcd: DisplayPort configuration data
> * @port_cap: port capabilities
> *
> - * Returns max clock in kHz on success or 0 if max clock not defined
> + * See also:
> + * drm_dp_read_downstream_info()
> + * drm_dp_downstream_max_bpc()
> + *
> + * Returns: Max clock in kHz on success or 0 if max clock not defined
> */
> int drm_dp_downstream_max_clock(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> const u8 port_cap[4])
> @@ -462,7 +516,11 @@ EXPORT_SYMBOL(drm_dp_downstream_max_clock);
> * @dpcd: DisplayPort configuration data
> * @port_cap: port capabilities
> *
Re: [Intel-gfx] [PATCH v5 09/20] drm/i915/dp: Extract drm_dp_read_mst_cap()
On Wed, 26 Aug 2020, Lyude Paul wrote:
> Just a tiny drive-by cleanup, we can consolidate i915's code for
> checking for MST support into a helper to be shared across drivers.
>
> v5:
> * Drop !!()
> * Move drm_dp_has_mst() out of header
> * Change name from drm_dp_has_mst() to drm_dp_read_mst_cap()
>
> Signed-off-by: Lyude Paul
> Reviewed-by: Sean Paul
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 22 ++
> drivers/gpu/drm/i915/display/intel_dp.c | 18 ++
> include/drm/drm_dp_mst_helper.h | 3 +--
> 3 files changed, 25 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 67dd72ea200e0..17dbed0a9800d 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -3486,6 +3486,28 @@ static int drm_dp_get_vc_payload_bw(u8 dp_link_bw, u8
> dp_link_count)
> return dp_link_bw * dp_link_count / 2;
> }
>
> +/**
> + * drm_dp_read_mst_cap() - check whether or not a sink supports MST
> + * @aux: The DP AUX channel to use
> + * @dpcd: A cached copy of the DPCD capabilities for this sink
> + *
> + * Returns: %True if the sink supports MST, %false otherwise
> + */
> +bool drm_dp_read_mst_cap(struct drm_dp_aux *aux,
> + const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> +{
> + u8 mstm_cap;
> +
> + if (dpcd[DP_DPCD_REV] < DP_DPCD_REV_12)
> + return false;
> +
> + if (drm_dp_dpcd_readb(aux, DP_MSTM_CAP, &mstm_cap) != 1)
> + return false;
> +
> + return mstm_cap & DP_MST_CAP;
> +}
> +EXPORT_SYMBOL(drm_dp_read_mst_cap);
> +
> /**
> * drm_dp_mst_topology_mgr_set_mst() - Set the MST state for a topology
> manager
> * @mgr: manager to set state for
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 79c27f91f42c0..4c7314b7a84e4 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4699,20 +4699,6 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> return true;
> }
>
> -static bool
> -intel_dp_sink_can_mst(struct intel_dp *intel_dp)
> -{
> - u8 mstm_cap;
> -
> - if (intel_dp->dpcd[DP_DPCD_REV] < 0x12)
> - return false;
> -
> - if (drm_dp_dpcd_readb(&intel_dp->aux, DP_MSTM_CAP, &mstm_cap) != 1)
> - return false;
> -
> - return mstm_cap & DP_MST_CAP;
> -}
> -
> static bool
> intel_dp_can_mst(struct intel_dp *intel_dp)
> {
> @@ -4720,7 +4706,7 @@ intel_dp_can_mst(struct intel_dp *intel_dp)
>
> return i915->params.enable_dp_mst &&
> intel_dp->can_mst &&
> - intel_dp_sink_can_mst(intel_dp);
> + drm_dp_read_mst_cap(&intel_dp->aux, intel_dp->dpcd);
> }
>
> static void
> @@ -4729,7 +4715,7 @@ intel_dp_configure_mst(struct intel_dp *intel_dp)
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> struct intel_encoder *encoder =
> &dp_to_dig_port(intel_dp)->base;
> - bool sink_can_mst = intel_dp_sink_can_mst(intel_dp);
> + bool sink_can_mst = drm_dp_read_mst_cap(&intel_dp->aux, intel_dp->dpcd);
>
> drm_dbg_kms(&i915->drm,
> "[ENCODER:%d:%s] MST support: port: %s, sink: %s, modparam:
> %s\n",
> diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
> index 8b9eb4db3381c..6ae5860d8644e 100644
> --- a/include/drm/drm_dp_mst_helper.h
> +++ b/include/drm/drm_dp_mst_helper.h
> @@ -728,10 +728,9 @@ int drm_dp_mst_topology_mgr_init(struct
> drm_dp_mst_topology_mgr *mgr,
>
> void drm_dp_mst_topology_mgr_destroy(struct drm_dp_mst_topology_mgr *mgr);
>
> -
> +bool drm_dp_read_mst_cap(struct drm_dp_aux *aux, const u8
> dpcd[DP_RECEIVER_CAP_SIZE]);
> int drm_dp_mst_topology_mgr_set_mst(struct drm_dp_mst_topology_mgr *mgr,
> bool mst_state);
>
> -
> int drm_dp_mst_hpd_irq(struct drm_dp_mst_topology_mgr *mgr, u8 *esi, bool
> *handled);
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] block: convert tasklets to use new tasklet_setup() API
On Wed, Aug 26, 2020 at 8:43 PM Kees Cook wrote: > > On Wed, Aug 26, 2020 at 12:55:28PM +0300, Dan Carpenter wrote: > > On Wed, Aug 26, 2020 at 07:21:35AM +0530, Allen Pais wrote: > > > On Thu, Aug 20, 2020 at 3:09 AM James Bottomley > > > wrote: > > > > > > > > On Wed, 2020-08-19 at 21:54 +0530, Allen wrote: > > > > > > [...] > > > > > > > > Since both threads seem to have petered out, let me suggest in > > > > > > > > kernel.h: > > > > > > > > > > > > > > > > #define cast_out(ptr, container, member) \ > > > > > > > > container_of(ptr, typeof(*container), member) > > > > > > > > > > > > > > > > It does what you want, the argument order is the same as > > > > > > > > container_of with the only difference being you name the > > > > > > > > containing structure instead of having to specify its type. > > > > > > > > > > > > > > Not to incessantly bike shed on the naming, but I don't like > > > > > > > cast_out, it's not very descriptive. And it has connotations of > > > > > > > getting rid of something, which isn't really true. > > > > > > > > > > > > Um, I thought it was exactly descriptive: you're casting to the > > > > > > outer container. I thought about following the C++ dynamic casting > > > > > > style, so out_cast(), but that seemed a bit pejorative. What about > > > > > > outer_cast()? > > > > > > > > > > > > > FWIW, I like the from_ part of the original naming, as it has > > > > > > > some clues as to what is being done here. Why not just > > > > > > > from_container()? That should immediately tell people what it > > > > > > > does without having to look up the implementation, even before > > > > > > > this becomes a part of the accepted coding norm. > > > > > > > > > > > > I'm not opposed to container_from() but it seems a little less > > > > > > descriptive than outer_cast() but I don't really care. I always > > > > > > have to look up container_of() when I'm using it so this would just > > > > > > be another macro of that type ... > > > > > > > > > > > > > > > > So far we have a few which have been suggested as replacement > > > > > for from_tasklet() > > > > > > > > > > - out_cast() or outer_cast() > > > > > - from_member(). > > > > > - container_from() or from_container() > > > > > > > > > > from_container() sounds fine, would trimming it a bit work? like > > > > > from_cont(). > > > > > > > > I'm fine with container_from(). It's the same form as container_of() > > > > and I think we need urgent agreement to not stall everything else so > > > > the most innocuous name is likely to get the widest acceptance. > > > > > > Kees, > > > > > > Will you be sending the newly proposed API to Linus? I have V2 > > > which uses container_from() > > > ready to be sent out. > > > > I liked that James swapped the first two arguments so that it matches > > container_of(). Plus it's nice that when you have: > > > > struct whatever *foo = container_from(ptr, foo, member); > > > > Then it means that "ptr == &foo->member". > > I'm a bit stalled right now -- the merge window was keeping me busy, and > this week is the Linux Plumbers Conference. This is on my list, but I > haven't gotten back around to it. If you want, feel free to send the > container_from() patch; you might be able to unblock this faster than me > right now. :) > Sure, Thanks. -- - Allen ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [i915] flip_done timed out errors with i7-1065G7 on kernel > 4.19
On Wed, 12 Aug 2020, Vincent Guenat wrote: > Hello there, > > I am seeing this error after recently installing Archlinux on my Razer > Blade Stealth with the kernel version 5.7.12. I have seen it as well on > 4.19, 5.4.55 and 5.8.0. > > The error happens during boot time where it significantly increases boot > time. It starts with a time out in |drm_atomic_helper_wait_for_flip_done > followed by more time out in |||drm_atomic_helper_wait_for_dependencies > and |drm_atomic_helper_wait_for_flip_done, each of them taking about > 10 seconds (which is the value in the source code as far as I can see). > There are 11-12 time out at each boot.||| > || > |||A similar issue was already discovered in previous version of the > kernel, but the selected solution of adding video=SVIDEO-1:d to the > kernel parameters has proved unsuccessful so far.||| > Note that Xorg also fails to launch, but this may be due to a > misconfiguration from my side, as I start it with startx. > > There is more details (including a dmesg output for the kernel version > 5.8.0) in my post on the Archlinux forums: > https://bbs.archlinux.org/viewtopic.php?id=258051 Please file an issue at [1]. Please add drm.debug=14 module parameter, remove video=SVIDEO-1:d (because it doesn't matter on your hardware), and attach to the bug the full dmesg from boot. If you can, please try the drm-tip branch, otherwise latest release or -rc kernel available. BR, Jani. [1] https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/8] mm: Use find_get_swap_page in memcontrol
On Wed, Aug 26, 2020 at 10:20:02AM -0400, Johannes Weiner wrote: > The refactor makes sense to me, but the name is confusing. We're not > looking for a swap page, we're primarily looking for a file page in > the page cache mapping that's handed in. Only in the special case > where it's a shmem mapping and there is a swap entry do we consult the > auxiliary swap cache. > > How about find_get_page_or_swapcache()? find_get_page_shmemswap()? > Maybe you have a better idea. It's a fairly specialized operation that > isn't widely used, so a longer name isn't a bad thing IMO. Got it. find_get_incore_page(). I was going to go with inmem, but that it matches mincore sold me on it. /** * find_get_incore_page - Find and get a page from the page or swap caches. * @mapping: The address_space to search. * @index: The page cache index. * * This differs from find_get_page() in that it will also look for the * page in the swap cache. * * Return: The found page or %NULL. */ I was focusing too much on what the function did, not why it was doing it. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/39] drm/i915/gt: Show engine properties in the pretty printer
Chris Wilson writes:
> When debugging the engine state, include the user properties that may,
> or may not, have been adjusted by the user/test.
>
> For example,
> vecs0
> ...
> Properties:
> heartbeat_interval_ms: 2500 [default 2500]
> max_busywait_duration_ns: 8000 [default 8000]
> preempt_timeout_ms: 640 [default 640]
> stop_timeout_ms: 100 [default 100]
> timeslice_duration_ms: 1 [default 1]
>
> Suggested-by: Joonas Lahtinen
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 36 +++
> 1 file changed, 36 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index f231edd3fa3a..1579a80bc8cb 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -1599,6 +1599,41 @@ static unsigned long list_count(struct list_head *list)
> return count;
> }
>
> +static unsigned long read_ul(void *p, size_t x)
> +{
> + return *(unsigned long *)(p + x);
> +}
> +
> +static void print_properties(struct intel_engine_cs *engine,
> + struct drm_printer *m)
> +{
> + static const struct pmap {
> + size_t offset;
> + const char *name;
> + } props[] = {
> +#define P(x) { \
> + .offset = offsetof(typeof(engine->props), x), \
> + .name = #x \
> +}
> + P(heartbeat_interval_ms),
> + P(max_busywait_duration_ns),
> + P(preempt_timeout_ms),
> + P(stop_timeout_ms),
> + P(timeslice_duration_ms),
> +
> + {},
> +#undef P
> + };
> + const struct pmap *p;
> +
> + drm_printf(m, "\tProperties:\n");
> + for (p = props; p->name; p++)
> + drm_printf(m, "\t\t%s: %lu [default %lu]\n",
> +p->name,
> +read_ul(&engine->props, p->offset),
> +read_ul(&engine->defaults, p->offset));
> +}
> +
> void intel_engine_dump(struct intel_engine_cs *engine,
> struct drm_printer *m,
> const char *header, ...)
> @@ -1641,6 +1676,7 @@ void intel_engine_dump(struct intel_engine_cs *engine,
> drm_printf(m, "\tReset count: %d (global %d)\n",
> i915_reset_engine_count(error, engine),
> i915_reset_count(error));
> + print_properties(engine, m);
>
> drm_printf(m, "\tRequests:\n");
>
> --
> 2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/3] drm/i915/display: Compute has_drrs after compute has_psr
On 2020-08-26 at 22:17:38 +0530, Souza, Jose wrote:
> On Wed, 2020-08-26 at 12:56 +0530, Anshuman Gupta wrote:
> > On 2020-08-25 at 10:13:29 -0700, José Roberto de Souza wrote:
> > > DRRS and PSR can't be enable together, so giving preference to PSR
> > > as it allows more power-savings by complete shutting down display,
> > > so to guarantee this, it should compute DRRS state after compute PSR.
> > >
> > > Cc: Srinivas K <
> > > srinivas...@intel.com
> > > >
> > > Cc: Hariom Pandey <
> > > hariom.pan...@intel.com
> > > >
> > > Reviewed-by: Anshuman Gupta <
> > > anshuman.gu...@intel.com
> > > >
> > > Signed-off-by: José Roberto de Souza <
> > > jose.so...@intel.com
> > > >
> > > ---
> > > drivers/gpu/drm/i915/display/intel_dp.c | 52 +++--
> > > 1 file changed, 32 insertions(+), 20 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > index 79c27f91f42c..a08d03c61b02 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > @@ -2575,6 +2575,34 @@ intel_dp_compute_hdr_metadata_infoframe_sdp(struct
> > > intel_dp *intel_dp,
> > > intel_hdmi_infoframe_enable(HDMI_PACKET_TYPE_GAMUT_METADATA);
> > > }
> > >
> > > +static void
> > > +intel_dp_drrs_compute_config(struct intel_dp *intel_dp,
> > > + struct intel_crtc_state *pipe_config,
> > > + int output_bpp, bool constant_n)
> > > +{
> > > + struct intel_connector *intel_connector = intel_dp->attached_connector;
> > > + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > > +
> > > + /*
> > > + * DRRS and PSR can't be enable together, so giving preference to PSR
> > > + * as it allows more power-savings by complete shutting down display,
> > > + * so to guarantee this, intel_dp_drrs_compute_config() must be called
> > > + * after intel_psr_compute_config().
> > > + */
> > > + if (pipe_config->has_psr)
> > > + return;
> > > +
> > > + if (!intel_connector->panel.downclock_mode ||
> > > + dev_priv->drrs.type != SEAMLESS_DRRS_SUPPORT)
> > > + return;
> > > +
> > > + pipe_config->has_drrs = true;
> > > + intel_link_compute_m_n(output_bpp, pipe_config->lane_count,
> > > +intel_connector->panel.downclock_mode->clock,
> > > +pipe_config->port_clock, &pipe_config->dp_m2_n2,
> > > +constant_n, pipe_config->fec_enable);
> > > +}
> > > +
> > > int
> > > intel_dp_compute_config(struct intel_encoder *encoder,
> > > struct intel_crtc_state *pipe_config,
> > > @@ -2605,7 +2633,6 @@ intel_dp_compute_config(struct intel_encoder
> > > *encoder,
> > > if (ret)
> > > return ret;
> > >
> > > - pipe_config->has_drrs = false;
> >
> > IMHO this assignment is required, i was thinking a case, when a crtc is
> > attached to more than
> > one connector, suppose first eDP connector supports DRRS from
> > panel.downclock_mode and
> > drrs.type but another DP connector won't support it in that case has_drrs
> > will be still
> > true.
> > Please correct me if i am wrong here.
>
> i915 only supports one connector per pipe/CRTC, if that was the case all
> other flags in intel_crtc_state would also have the same behaviour as
> has_drrs.
Actually once on kabylake i had witnessed this use case when a CRTC was
attached to multiple connectors, AFAIU theortically also
it seems possible as intel_modeset_pipe_config iterate for each connector in
state for a given crtc i.e (connector_state->crtc == crtc)
and call encoder->compute_config().
If you are sure above case can't happen for drrs you can use my RB.
Applicable for [PATCH 3/3] of this series,
Reviewed-by: Anshuman Gupta
>
> > Thanks,
> > Anshuman Gupta.
> > > if (!intel_dp_port_has_audio(dev_priv, port))
> > > pipe_config->has_audio = false;
> > > else if (intel_conn_state->force_audio == HDMI_AUDIO_AUTO)
> > > @@ -2657,21 +2684,12 @@ intel_dp_compute_config(struct intel_encoder
> > > *encoder,
> > > &pipe_config->dp_m_n,
> > > constant_n, pipe_config->fec_enable);
> > >
> > > - if (intel_connector->panel.downclock_mode != NULL &&
> > > - dev_priv->drrs.type == SEAMLESS_DRRS_SUPPORT) {
> > > - pipe_config->has_drrs = true;
> > > - intel_link_compute_m_n(output_bpp,
> > > -pipe_config->lane_count,
> > > -
> > > intel_connector->panel.downclock_mode->clock,
> > > -pipe_config->port_clock,
> > > -&pipe_config->dp_m2_n2,
> > > -constant_n,
> > > pipe_config->fec_enable);
> > > - }
> > > -
> > > if (!HAS_DDI(dev_priv))
> > > intel_dp_set_clock(encoder, pipe_config);
> > >
>
[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave & Daniel, just one fix for -rc3. BR, Jani. The following changes since commit d012a7190fc1fd72ed48911e77ca97ba4521bccd: Linux 5.9-rc2 (2020-08-23 14:08:43 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2020-08-27 for you to fetch changes up to e5f10d6385cda083037915c12b130887c8831d2b: drm/i915: Fix cmd parser desc matching with masks (2020-08-25 11:01:34 +0300) drm/i915 fixes for v5.9-rc3: - Fix command parser desc matching with masks Mika Kuoppala (1): drm/i915: Fix cmd parser desc matching with masks drivers/gpu/drm/i915/i915_cmd_parser.c | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/fbc: disable FBC on Nightfury board
== Series Details == Series: drm/i915/fbc: disable FBC on Nightfury board URL : https://patchwork.freedesktop.org/series/81087/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8931_full -> Patchwork_18415_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18415_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18415_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_18415_full: ### IGT changes ### Possible regressions * igt@gem_ctx_persistence@processes: - shard-skl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8931/shard-skl5/igt@gem_ctx_persiste...@processes.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18415/shard-skl2/igt@gem_ctx_persiste...@processes.html Known issues Here are the changes found in Patchwork_18415_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_reloc@basic-concurrent0: - shard-tglb: [PASS][3] -> [TIMEOUT][4] ([i915#1958]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8931/shard-tglb8/igt@gem_exec_re...@basic-concurrent0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18415/shard-tglb5/igt@gem_exec_re...@basic-concurrent0.html - shard-apl: [PASS][5] -> [TIMEOUT][6] ([i915#1635] / [i915#1958]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8931/shard-apl8/igt@gem_exec_re...@basic-concurrent0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18415/shard-apl6/igt@gem_exec_re...@basic-concurrent0.html * igt@gem_exec_whisper@basic-contexts-forked-all: - shard-glk: [PASS][7] -> [DMESG-WARN][8] ([i915#118] / [i915#95]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8931/shard-glk4/igt@gem_exec_whis...@basic-contexts-forked-all.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18415/shard-glk5/igt@gem_exec_whis...@basic-contexts-forked-all.html * igt@gem_exec_whisper@basic-fds-priority-all: - shard-glk: [PASS][9] -> [TIMEOUT][10] ([i915#1958]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8931/shard-glk6/igt@gem_exec_whis...@basic-fds-priority-all.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18415/shard-glk9/igt@gem_exec_whis...@basic-fds-priority-all.html * igt@i915_selftest@mock@contexts: - shard-skl: [PASS][11] -> [INCOMPLETE][12] ([i915#198] / [i915#2278]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8931/shard-skl10/igt@i915_selftest@m...@contexts.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18415/shard-skl2/igt@i915_selftest@m...@contexts.html * igt@kms_big_fb@y-tiled-64bpp-rotate-0: - shard-iclb: [PASS][13] -> [FAIL][14] ([i915#1119]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8931/shard-iclb7/igt@kms_big...@y-tiled-64bpp-rotate-0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18415/shard-iclb1/igt@kms_big...@y-tiled-64bpp-rotate-0.html * igt@kms_color@pipe-c-ctm-0-25: - shard-skl: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) +12 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8931/shard-skl8/igt@kms_co...@pipe-c-ctm-0-25.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18415/shard-skl1/igt@kms_co...@pipe-c-ctm-0-25.html * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic: - shard-glk: [PASS][17] -> [FAIL][18] ([i915#72]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8931/shard-glk4/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18415/shard-glk5/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-gtt-xtiled: - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#1635] / [i915#1982]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8931/shard-apl6/igt@kms_draw_...@draw-method-xrgb2101010-mmap-gtt-xtiled.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18415/shard-apl4/igt@kms_draw_...@draw-method-xrgb2101010-mmap-gtt-xtiled.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@b-hdmi-a1: - shard-glk: [PASS][21] -> [FAIL][22] ([i915#79]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8931/shard-glk8/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-hdmi-a1.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18415/shard-glk4/igt@kms_flip@fli
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/gvt: Save/restore HW status for GVT during suspend/resume
On 2020-08-26 17:10, Zhenyu Wang wrote:
On 2020.08.26 14:35:05 +0800, Colin Xu wrote:
This patch save/restore necessary GVT info during i915 suspend/resume so
that GVT enabled QEMU VM can continue running.
Only GGTT and fence regs are saved/restored now. GVT will save GGTT
entries into GVT in suspend routine, and restore the saved entries
and re-init fence regs in resume routine.
V2:
- Change kzalloc/kfree to vzalloc/vfree since the space allocated
from kmalloc may not enough for all saved GGTT entries.
- Keep gvt suspend/resume wrapper in intel_gvt.h/intel_gvt.c and
move the actual implementation to gvt.h/gvt.c. (zhenyu)
- Check gvt config on and active with intel_gvt_active(). (zhenyu)
Signed-off-by: Hang Yuan
Signed-off-by: Colin Xu
---
drivers/gpu/drm/i915/gvt/gtt.c | 73 +
drivers/gpu/drm/i915/gvt/gtt.h | 2 +
drivers/gpu/drm/i915/gvt/gvt.c | 15 ++
drivers/gpu/drm/i915/gvt/gvt.h | 6 +++
drivers/gpu/drm/i915/gvt/handlers.c | 20
drivers/gpu/drm/i915/gvt/mmio.h | 3 ++
drivers/gpu/drm/i915/gvt/vgpu.c | 1 +
drivers/gpu/drm/i915/intel_gvt.c| 29
drivers/gpu/drm/i915/intel_gvt.h| 10
9 files changed, 159 insertions(+)
diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index 04bf018ecc34..7907a535d49f 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -2533,6 +2533,11 @@ static void intel_vgpu_destroy_ggtt_mm(struct intel_vgpu
*vgpu)
}
intel_vgpu_destroy_mm(vgpu->gtt.ggtt_mm);
vgpu->gtt.ggtt_mm = NULL;
+
+ if (vgpu->ggtt_entries) {
+ vfree(vgpu->ggtt_entries);
+ vgpu->ggtt_entries = NULL;
+ }
}
/**
@@ -2834,3 +2839,71 @@ void intel_vgpu_reset_ggtt(struct intel_vgpu *vgpu, bool
invalidate_old)
ggtt_invalidate(gvt->gt);
}
+
+/**
+ * intel_gvt_save_ggtt - save all vGPU's ggtt entries
+ * @gvt: intel gvt device
+ *
+ * This function is called at driver suspend stage to save
+ * GGTT entries of every active vGPU.
+ *
+ */
+void intel_gvt_save_ggtt(struct intel_gvt *gvt)
+{
+ struct intel_vgpu *vgpu;
+ int id;
+ u32 index, num_low, num_hi;
+ void __iomem *addr;
+
+ for_each_active_vgpu(gvt, vgpu, id) {
+ num_low = vgpu_aperture_sz(vgpu) >> PAGE_SHIFT;
+ num_hi = vgpu_hidden_sz(vgpu) >> PAGE_SHIFT;
+ vgpu->ggtt_entries = vzalloc((num_low + num_hi) * sizeof(u64));
+ if (!vgpu->ggtt_entries)
+ continue;
+
+ index = vgpu_aperture_gmadr_base(vgpu) >> PAGE_SHIFT;
+ addr = (gen8_pte_t __iomem *)gvt->gt->i915->ggtt.gsm + index;
+ memcpy(vgpu->ggtt_entries, addr, num_low);
Should use memcpy_fromio() and is the size right? It's the number of entries
instead of bytes count?
Indeed this is a mistake. ggtt_entries is allocated num_entries * 8bytes
(sizeof(u64)) and copy should also count on bytes instead of num entries.
+
+ index = vgpu_hidden_gmadr_base(vgpu) >> PAGE_SHIFT;
+ addr = (gen8_pte_t __iomem *)gvt->gt->i915->ggtt.gsm + index;
+ memcpy((u64 *)vgpu->ggtt_entries + num_low, addr, num_hi);
+ }
ditto
+}
+
+/**
+ * intel_gvt_restore_ggtt - restore all vGPU's ggtt entries
+ * @gvt: intel gvt device
+ *
+ * This function is called at driver resume stage to restore
+ * GGTT entries of every active vGPU.
+ *
+ */
+void intel_gvt_restore_ggtt(struct intel_gvt *gvt)
+{
+ struct intel_vgpu *vgpu;
+ int id;
+ u32 index, num_low, num_hi;
+ void __iomem *addr;
+
+ for_each_active_vgpu(gvt, vgpu, id) {
+ if (!vgpu->ggtt_entries) {
+ gvt_vgpu_err("fail to get saved ggtt\n");
+ continue;
+ }
+
+ num_low = vgpu_aperture_sz(vgpu) >> PAGE_SHIFT;
+ num_hi = vgpu_hidden_sz(vgpu) >> PAGE_SHIFT;
+
+ index = vgpu_aperture_gmadr_base(vgpu) >> PAGE_SHIFT;
+ addr = (gen8_pte_t __iomem *)gvt->gt->i915->ggtt.gsm + index;
+ memcpy(addr, vgpu->ggtt_entries, num_low);
memcpy_toio()
+ index = vgpu_hidden_gmadr_base(vgpu) >> PAGE_SHIFT;
+ addr = (gen8_pte_t __iomem *)gvt->gt->i915->ggtt.gsm + index;
+ memcpy(addr, (u64 *)vgpu->ggtt_entries + num_low, num_hi);
+
+ vfree(vgpu->ggtt_entries);
+ vgpu->ggtt_entries = NULL;
+ }
+}
diff --git a/drivers/gpu/drm/i915/gvt/gtt.h b/drivers/gpu/drm/i915/gvt/gtt.h
index b76a262dd9bc..0d2fb2714852 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.h
+++ b/drivers/gpu/drm/i915/gvt/gtt.h
@@ -279,5 +279,7 @@ int intel_vgpu_emulate_ggtt_mmio_write(struct intel_vgpu
*vgpu,
unsigned int off, void *p_data, unsigned int bytes);
void intel_vgpu_destroy_all_ppgtt_mm(struct intel_vgpu *vgpu);
+void intel_gvt_sa
Re: [Intel-gfx] [i-g-t] Fixing the latency of hrtimer
Hi Lionel,
Thanks for your suggestions. I will send the patch to
igt-...@lists.freedesktop.org.
This patch is regarding the git lab issue #1542. Based on the ftrace, a 2ms
hrtimer results in around 5000 calls to read (because test duration is 10s).
Based on average read times (30us), the total kernel_ns is larger than the
value being compared and this fix is to allow user to have a larger timer value
than the default 5ms to avoid waking up too frequently.
Thanks and Regards
Sowmya
-Original Message-
From: Landwerlin, Lionel G
Sent: 27 August 2020 13:20
To: Kaparthi, SowmyaX ;
intel-gfx@lists.freedesktop.org; Nerlige Ramappa, Umesh
Subject: Re: [i-g-t] Fixing the latency of hrtimer
Hi Sowmya,
Thanks for the patch. If you could send it to the igt-...@lists.freedesktop.org
list instead, this is where the IGT patches go.
Could you refresh my memory as to what this is fixing?
It sounds like this is just adjusting a value to match more common settings.
Cheers,
-Lionel
On 27/08/2020 10:38, Sowmya Kaparthi wrote:
> The blocking/polling parameterized tests were introduced to test
> different hrtimer configurations.These tests check how many times the
> process wakes up to read the reports with different hrtimer values (=
> duration of test / hrtimer value). A user is more likely to choose a
> larger hrtimer value than the default 5ms to avoid wake up too frequently.
>
> Cc: Landwerlin, Lionel G
> Signed-off-by: Sowmya Kaparthi
> ---
> tests/i915/perf.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tests/i915/perf.c b/tests/i915/perf.c index
> a894fd38..5fd1193f 100644
> --- a/tests/i915/perf.c
> +++ b/tests/i915/perf.c
> @@ -4995,7 +4995,7 @@ igt_main
> 40 * 1000 * 1000 /* default 40ms hrtimer */);
> test_blocking(500 * 1000 /* 500us oa period */,
> true /* set_kernel_hrtimer */,
> - 2 * 1000 * 1000 /* default 2ms hrtimer */);
> + 10 * 1000 * 1000 /* default 10ms hrtimer */);
> }
>
> igt_describe("Test polled read with default hrtimer frequency"); @@
> -5014,7 +5014,7 @@ igt_main
>40 * 1000 * 1000 /* default 40ms hrtimer */);
> test_polling(500 * 1000 /* 500us oa period */,
>true /* set_kernel_hrtimer */,
> - 2 * 1000 * 1000 /* default 2ms hrtimer */);
> + 10 * 1000 * 1000 /* default 10ms hrtimer */);
> }
>
> igt_describe("Test polled read with buffer size smaller than
> available data");
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [i-g-t] Fixing the latency of hrtimer
Hi Sowmya,
Thanks for the patch. If you could send it to the
igt-...@lists.freedesktop.org list instead, this is where the IGT
patches go.
Could you refresh my memory as to what this is fixing?
It sounds like this is just adjusting a value to match more common settings.
Cheers,
-Lionel
On 27/08/2020 10:38, Sowmya Kaparthi wrote:
The blocking/polling parameterized tests were introduced to test
different hrtimer configurations.These tests check how many times the
process wakes up to read the reports with different hrtimer values (=
duration of test / hrtimer value). A user is more likely to choose a
larger hrtimer value than the default 5ms to avoid wake up too frequently.
Cc: Landwerlin, Lionel G
Signed-off-by: Sowmya Kaparthi
---
tests/i915/perf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/i915/perf.c b/tests/i915/perf.c
index a894fd38..5fd1193f 100644
--- a/tests/i915/perf.c
+++ b/tests/i915/perf.c
@@ -4995,7 +4995,7 @@ igt_main
40 * 1000 * 1000 /* default 40ms hrtimer */);
test_blocking(500 * 1000 /* 500us oa period */,
true /* set_kernel_hrtimer */,
- 2 * 1000 * 1000 /* default 2ms hrtimer */);
+ 10 * 1000 * 1000 /* default 10ms hrtimer */);
}
igt_describe("Test polled read with default hrtimer frequency");
@@ -5014,7 +5014,7 @@ igt_main
40 * 1000 * 1000 /* default 40ms hrtimer */);
test_polling(500 * 1000 /* 500us oa period */,
true /* set_kernel_hrtimer */,
-2 * 1000 * 1000 /* default 2ms hrtimer */);
+10 * 1000 * 1000 /* default 10ms hrtimer */);
}
igt_describe("Test polled read with buffer size smaller than available data");
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [i-g-t] Fixing the latency of hrtimer
The blocking/polling parameterized tests were introduced to test
different hrtimer configurations.These tests check how many times the
process wakes up to read the reports with different hrtimer values (=
duration of test / hrtimer value). A user is more likely to choose a
larger hrtimer value than the default 5ms to avoid wake up too frequently.
Cc: Landwerlin, Lionel G
Signed-off-by: Sowmya Kaparthi
---
tests/i915/perf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/i915/perf.c b/tests/i915/perf.c
index a894fd38..5fd1193f 100644
--- a/tests/i915/perf.c
+++ b/tests/i915/perf.c
@@ -4995,7 +4995,7 @@ igt_main
40 * 1000 * 1000 /* default 40ms hrtimer */);
test_blocking(500 * 1000 /* 500us oa period */,
true /* set_kernel_hrtimer */,
- 2 * 1000 * 1000 /* default 2ms hrtimer */);
+ 10 * 1000 * 1000 /* default 10ms hrtimer */);
}
igt_describe("Test polled read with default hrtimer frequency");
@@ -5014,7 +5014,7 @@ igt_main
40 * 1000 * 1000 /* default 40ms hrtimer */);
test_polling(500 * 1000 /* 500us oa period */,
true /* set_kernel_hrtimer */,
-2 * 1000 * 1000 /* default 2ms hrtimer */);
+10 * 1000 * 1000 /* default 10ms hrtimer */);
}
igt_describe("Test polled read with buffer size smaller than available
data");
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline
Hi! > >> It's a Thinkpad T520. > > > > Oh, so this is a 64-bit machine? Yeah, that patch to flush vmalloc > > ranges won't make any difference on x86-64. > > > > Or are you for some reason running a 32-bit kernel on that thing? Have > > you tried building a 64-bit one (user-space can be 32-bit, it should > > all just work. Knock wood). > > No, I run a 64-bit kernel with 64-bit userspace (Void Linux). > Config is attached, in case anything is obvious from that. For the record, I'm running 5.9.0-rc2-next-20200825 w/o further patches, and it behaves okay on that 32-bit thinkpad x60. BTW... could we get the test farms to occassionaly boot in 32-bit mode? Those modern CPUs can still do that :-). Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
