[Intel-gfx] [PATCH AUTOSEL 4.14 55/95] drm/i915: Downgrade Gen9 Plane WM latency error
From: Chris Wilson
[ Upstream commit 86c1c87d0e6241cbe35bd52badfc84b154e1b959 ]
According to intel_read_wm_latency() it is perfectly legal for one WM
and all subsequent levels to be 0 (and the deeper powersaving states
disabled), so don't shout *ERROR*, over and over again.
Signed-off-by: Chris Wilson
Cc: Maarten Lankhorst
Cc: Ville Syrjala
Acked-by: Maarten Lankhorst
Link:
https://patchwork.freedesktop.org/patch/msgid/20180726161527.10516-1-ch...@chris-wilson.co.uk
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 96a5237741e0..cb377b003321 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2934,8 +2934,8 @@ static void intel_print_wm_latency(struct
drm_i915_private *dev_priv,
unsigned int latency = wm[level];
if (latency == 0) {
- DRM_ERROR("%s WM%d latency not provided\n",
- name, level);
+ DRM_DEBUG_KMS("%s WM%d latency not provided\n",
+ name, level);
continue;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH AUTOSEL 4.14 49/95] drm/i915: Disable LP3 watermarks on all SNB machines
From: Ville Syrjälä
[ Upstream commit 03981c6ebec4fc7056b9b45f847393aeac90d060 ]
I have a Thinkpad X220 Tablet in my hands that is losing vblank
interrupts whenever LP3 watermarks are used.
If I nudge the latency value written to the WM3 register just
by one in either direction the problem disappears. That to me
suggests that the punit will not enter the corrsponding
powersave mode (MPLL shutdown IIRC) unless the latency value
in the register matches exactly what we read from SSKPD. Ie.
it's not really a latency value but rather just a cookie
by which the punit can identify the desired power saving state.
On HSW/BDW this was changed such that we actually just write
the WM level number into those bits, which makes much more
sense given the observed behaviour.
We could try to handle this by disallowing LP3 watermarks
only when vblank interrupts are enabled but we'd first have
to prove that only vblank interrupts are affected, which
seems unlikely. Also we can't grab the wm mutex from the
vblank enable/disable hooks because those are called with
various spinlocks held. Thus we'd have to redesigne the
watermark locking. So to play it safe and keep the code
simple we simply disable LP3 watermarks on all SNB machines.
To do that we simply zero out the latency values for
watermark level 3, and we adjust the watermark computation
to check for that. The behaviour now matches that of the
g4x/vlv/skl wm code in the presence of a zeroed latency
value.
v2: s/USHRT_MAX/U32_MAX/ for consistency with the types (Chris)
Cc: sta...@vger.kernel.org
Cc: Chris Wilson
Acked-by: Chris Wilson
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101269
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103713
Signed-off-by: Ville Syrjälä
Link:
https://patchwork.freedesktop.org/patch/msgid/20181114173440.6730-1-ville.syrj...@linux.intel.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/i915/intel_pm.c | 41 -
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 87cccb5f8c5d..96a5237741e0 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2471,6 +2471,9 @@ static uint32_t ilk_compute_pri_wm(const struct
intel_crtc_state *cstate,
uint32_t method1, method2;
int cpp;
+ if (mem_value == 0)
+ return U32_MAX;
+
if (!intel_wm_plane_visible(cstate, pstate))
return 0;
@@ -2500,6 +2503,9 @@ static uint32_t ilk_compute_spr_wm(const struct
intel_crtc_state *cstate,
uint32_t method1, method2;
int cpp;
+ if (mem_value == 0)
+ return U32_MAX;
+
if (!intel_wm_plane_visible(cstate, pstate))
return 0;
@@ -2523,6 +2529,9 @@ static uint32_t ilk_compute_cur_wm(const struct
intel_crtc_state *cstate,
{
int cpp;
+ if (mem_value == 0)
+ return U32_MAX;
+
if (!intel_wm_plane_visible(cstate, pstate))
return 0;
@@ -2981,6 +2990,34 @@ static void snb_wm_latency_quirk(struct drm_i915_private
*dev_priv)
intel_print_wm_latency(dev_priv, "Cursor", dev_priv->wm.cur_latency);
}
+static void snb_wm_lp3_irq_quirk(struct drm_i915_private *dev_priv)
+{
+ /*
+* On some SNB machines (Thinkpad X220 Tablet at least)
+* LP3 usage can cause vblank interrupts to be lost.
+* The DEIIR bit will go high but it looks like the CPU
+* never gets interrupted.
+*
+* It's not clear whether other interrupt source could
+* be affected or if this is somehow limited to vblank
+* interrupts only. To play it safe we disable LP3
+* watermarks entirely.
+*/
+ if (dev_priv->wm.pri_latency[3] == 0 &&
+ dev_priv->wm.spr_latency[3] == 0 &&
+ dev_priv->wm.cur_latency[3] == 0)
+ return;
+
+ dev_priv->wm.pri_latency[3] = 0;
+ dev_priv->wm.spr_latency[3] = 0;
+ dev_priv->wm.cur_latency[3] = 0;
+
+ DRM_DEBUG_KMS("LP3 watermarks disabled due to potential for lost
interrupts\n");
+ intel_print_wm_latency(dev_priv, "Primary", dev_priv->wm.pri_latency);
+ intel_print_wm_latency(dev_priv, "Sprite", dev_priv->wm.spr_latency);
+ intel_print_wm_latency(dev_priv, "Cursor", dev_priv->wm.cur_latency);
+}
+
static void ilk_setup_wm_latency(struct drm_i915_private *dev_priv)
{
intel_read_wm_latency(dev_priv, dev_priv->wm.pri_latency);
@@ -2997,8 +3034,10 @@ static void ilk_setup_wm_latency(struct drm_i915_private
*dev_priv)
intel_print_wm_latency(dev_priv, "Sprite", dev_priv->wm.spr_latency);
intel_print_wm_latency(dev_priv, "Cursor", dev_priv->wm.cur_latency);
- if (IS_GEN6(dev_priv))
+ if (IS_GEN6(dev_priv)) {
snb_wm_latency_quirk(dev_priv);
+ snb_wm_lp3_irq_quirk(dev_priv);
+ }
}
static void
Re: [Intel-gfx] [PATCH v3 2/2] drm/i915: Make sure we have enough memory bandwidth on ICL
On 5/3/19 12:08 PM, Ville Syrjala wrote:
From: Ville Syrjälä
ICL has so many planes that it can easily exceed the maximum
effective memory bandwidth of the system. We must therefore check
that we don't exceed that limit.
The algorithm is very magic number heavy and lacks sufficient
explanation for now. We also have no sane way to query the
memory clock and timings, so we must rely on a combination of
raw readout from the memory controller and hardcoded assumptions.
The memory controller values obviously change as the system
jumps between the different SAGV points, so we try to stabilize
it first by disabling SAGV for the duration of the readout.
The utilized bandwidth is tracked via a device wide atomic
private object. That is actually not robust because we can't
afford to enforce strict global ordering between the pipes.
Thus I think I'll need to change this to simply chop up the
available bandwidth between all the active pipes. Each pipe
can then do whatever it wants as long as it doesn't exceed
its budget. That scheme will also require that we assume that
any number of planes could be active at any time.
TODO: make it robust and deal with all the open questions
TODO: Add comments detailing structures
v2: Sleep longer after disabling SAGV
v3: Poll for the dclk to get raised (seen it take 250ms!)
If the system has 2133MT/s memory then we pointlessly
wait one full second :(
v4: Use the new pcode interface to get the qgv points rather
that using hardcoded numbers
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_drv.c | 229 ++
drivers/gpu/drm/i915/i915_drv.h | 10 +
drivers/gpu/drm/i915/i915_reg.h | 3 +
drivers/gpu/drm/i915/intel_atomic_plane.c | 20 ++
drivers/gpu/drm/i915/intel_atomic_plane.h | 2 +
drivers/gpu/drm/i915/intel_bw.c | 181 +
drivers/gpu/drm/i915/intel_bw.h | 46 +
drivers/gpu/drm/i915/intel_display.c | 40 +++-
drivers/gpu/drm/i915/intel_drv.h | 2 +
10 files changed, 533 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/intel_bw.c
create mode 100644 drivers/gpu/drm/i915/intel_bw.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 68106fe35a04..139a0fc19390 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -138,6 +138,7 @@ i915-y += intel_audio.o \
intel_atomic.o \
intel_atomic_plane.o \
intel_bios.o \
+ intel_bw.o \
intel_cdclk.o \
intel_color.o \
intel_combo_phy.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 5ed864752c7b..b7fa7b51c2e2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -70,6 +70,7 @@
#include "intel_overlay.h"
#include "intel_pipe_crc.h"
#include "intel_pm.h"
+#include "intel_sideband.h"
#include "intel_sprite.h"
#include "intel_uc.h"
@@ -1435,6 +1436,232 @@ bxt_get_dram_info(struct drm_i915_private *dev_priv)
return 0;
}
+struct intel_qgv_point {
+ u16 dclk, t_rp, t_rdpre, t_rc, t_ras, t_rcd;
+};
+
+struct intel_sagv_info {
+ struct intel_qgv_point points[3];
+ u8 num_points;
+ u8 num_channels;
+ u8 t_bl;
+ enum intel_dram_type dram_type;
+};
+
+static int icl_pcode_read_mem_global_info(struct drm_i915_private *dev_priv,
+ struct intel_sagv_info *si)
+{
+ u32 val = 0;
+ int ret;
+
+ ret = sandybridge_pcode_read(dev_priv,
+ICL_PCODE_MEM_SUBSYSYSTEM_INFO |
+ICL_PCODE_MEM_SS_READ_GLOBAL_INFO,
+, NULL);
+ if (ret)
+ return ret;
+
+ switch (val & 0xf) {
+ case 0:
+ si->dram_type = INTEL_DRAM_DDR4;
+ break;
+ case 1:
+ si->dram_type = INTEL_DRAM_DDR3;
+ break;
+ case 2:
+ si->dram_type = INTEL_DRAM_LPDDR3;
+ break;
+ case 3:
+ si->dram_type = INTEL_DRAM_LPDDR3;
+ break;
+ default:
+ MISSING_CASE(val & 0xf);
+ break;
+ }
+
+ si->num_channels = (val & 0xf0) >> 4;
+ si->num_points = (val & 0xf00) >> 8;
+
+ si->t_bl = si->dram_type == INTEL_DRAM_DDR4 ? 4 : 8;
+
+ return 0;
+}
+
+static int icl_pcode_read_qgv_point_info(struct drm_i915_private *dev_priv,
+struct intel_qgv_point *sp,
+int point)
+{
+ u32 val = 0, val2;
+ int ret;
+
+ ret = sandybridge_pcode_read(dev_priv,
+ICL_PCODE_MEM_SUBSYSYSTEM_INFO |
+
Re: [Intel-gfx] [PATCH v3 1/2] drm/i915: Make sandybridge_pcode_read() deal with the second data register
Very straight forward. Nit variable names val and val1, maybe val0 and val1.
Reviewed-by: Clint Taylor
-Clint
On 5/3/19 12:08 PM, Ville Syrjala wrote:
From: Ville Syrjälä
The pcode mailbox has two data registers. So far we've only ever used
the one, but that's about to change. Expose the second data register to
the callers of sandybridge_pcode_read().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
drivers/gpu/drm/i915/intel_pm.c | 12 +++-
drivers/gpu/drm/i915/intel_sideband.c | 15 +--
drivers/gpu/drm/i915/intel_sideband.h | 3 ++-
4 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 14cd83e9ea8b..203088f6f269 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1494,7 +1494,7 @@ static int gen6_drpc_info(struct seq_file *m)
if (INTEL_GEN(dev_priv) <= 7)
sandybridge_pcode_read(dev_priv, GEN6_PCODE_READ_RC6VIDS,
- );
+ , NULL);
seq_printf(m, "RC1e Enabled: %s\n",
yesno(rcctl1 & GEN6_RC_CTL_RC1e_ENABLE));
@@ -1777,7 +1777,7 @@ static int i915_ring_freq_table(struct seq_file *m, void
*unused)
ia_freq = gpu_freq;
sandybridge_pcode_read(dev_priv,
GEN6_PCODE_READ_MIN_FREQ_TABLE,
- _freq);
+ _freq, NULL);
seq_printf(m, "%d\t\t%d\t\t\t\t%d\n",
intel_gpu_freq(dev_priv, (gpu_freq *
(IS_GEN9_BC(dev_priv) ||
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ef9fc77f8162..b043a96e123c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2822,7 +2822,7 @@ static void intel_read_wm_latency(struct drm_i915_private
*dev_priv,
val = 0; /* data0 to be programmed to 0 for first set */
ret = sandybridge_pcode_read(dev_priv,
GEN9_PCODE_READ_MEM_LATENCY,
-);
+, NULL);
if (ret) {
DRM_ERROR("SKL Mailbox read error = %d\n", ret);
@@ -2841,7 +2841,7 @@ static void intel_read_wm_latency(struct drm_i915_private
*dev_priv,
val = 1; /* data0 to be programmed to 1 for second set */
ret = sandybridge_pcode_read(dev_priv,
GEN9_PCODE_READ_MEM_LATENCY,
-);
+, NULL);
if (ret) {
DRM_ERROR("SKL Mailbox read error = %d\n", ret);
return;
@@ -7061,7 +7061,7 @@ static void gen6_init_rps_frequencies(struct
drm_i915_private *dev_priv)
if (sandybridge_pcode_read(dev_priv,
HSW_PCODE_DYNAMIC_DUTY_CYCLE_CONTROL,
- _status) == 0)
+ _status, NULL) == 0)
rps->efficient_freq =
clamp_t(u8,
((ddcc_status >> 8) & 0xff),
@@ -7408,7 +7408,8 @@ static void gen6_enable_rc6(struct drm_i915_private
*dev_priv)
GEN6_RC_CTL_HW_ENABLE);
rc6vids = 0;
- ret = sandybridge_pcode_read(dev_priv, GEN6_PCODE_READ_RC6VIDS,
);
+ ret = sandybridge_pcode_read(dev_priv, GEN6_PCODE_READ_RC6VIDS,
+, NULL);
if (IS_GEN(dev_priv, 6) && ret) {
DRM_DEBUG_DRIVER("Couldn't check for BIOS workaround\n");
} else if (IS_GEN(dev_priv, 6) && (GEN6_DECODE_RC6_VID(rc6vids & 0xff)
< 450)) {
@@ -8555,7 +8556,8 @@ void intel_init_gt_powersave(struct drm_i915_private
*dev_priv)
IS_IVYBRIDGE(dev_priv) || IS_HASWELL(dev_priv)) {
u32 params = 0;
- sandybridge_pcode_read(dev_priv, GEN6_READ_OC_PARAMS, );
+ sandybridge_pcode_read(dev_priv, GEN6_READ_OC_PARAMS,
+ , NULL);
if (params & BIT(31)) { /* OC supported */
DRM_DEBUG_DRIVER("Overclocking supported, max: %dMHz,
overclock: %dMHz\n",
(rps->max_freq & 0xff) * 50,
diff --git a/drivers/gpu/drm/i915/intel_sideband.c
b/drivers/gpu/drm/i915/intel_sideband.c
index 87b5a14c7ca8..a115625e980c 100644
--- a/drivers/gpu/drm/i915/intel_sideband.c
+++ b/drivers/gpu/drm/i915/intel_sideband.c
@@ -374,7 +374,7 @@ static inline int gen7_check_mailbox_status(u32 mbox)
}
static int __sandybridge_pcode_rw(struct
Re: [Intel-gfx] [PATCH v6 03/10] drm: revocation check at drm subsystem
On Mon, May 06, 2019 at 06:56:03PM +0200, Daniel Vetter wrote:
> On Thu, May 02, 2019 at 06:52:56PM +0530, Ramalingam C wrote:
> > On every hdcp revocation check request SRM is read from fw file
> > /lib/firmware/display_hdcp_srm.bin
> >
> > SRM table is parsed and stored at drm_hdcp.c, with functions exported
> > for the services for revocation check from drivers (which
> > implements the HDCP authentication)
> >
> > This patch handles the HDCP1.4 and 2.2 versions of SRM table.
> >
> > v2:
> > moved the uAPI to request_firmware_direct() [Daniel]
> > v3:
> > kdoc added. [Daniel]
> > srm_header unified and bit field definitions are removed. [Daniel]
> > locking improved. [Daniel]
> > vrl length violation is fixed. [Daniel]
> >
> > Signed-off-by: Ramalingam C
> > Suggested-by: Daniel Vetter
>
> Found a few small details to polish, but looks good to me. With the
> details addressed:
>
> Reviewed-by: Daniel Vetter
>
> We also still need an ack on the firmware blob approach from Matt Roper or
> someone else at iotg I think.
+Satyeshwar
Satyeshwar's probably the best person from IOTG to give the Ack since
he's part of the group that needs this functionality and is involved in
the userspace/compositor side as well.
Matt
>
> Cheers, Daniel
>
> > ---
> > Documentation/gpu/drm-kms-helpers.rst | 6 +
> > drivers/gpu/drm/Makefile | 2 +-
> > drivers/gpu/drm/drm_hdcp.c| 342 ++
> > drivers/gpu/drm/drm_internal.h| 4 +
> > drivers/gpu/drm/drm_sysfs.c | 2 +
> > include/drm/drm_hdcp.h| 24 ++
> > 6 files changed, 379 insertions(+), 1 deletion(-)
> > create mode 100644 drivers/gpu/drm/drm_hdcp.c
> >
> > diff --git a/Documentation/gpu/drm-kms-helpers.rst
> > b/Documentation/gpu/drm-kms-helpers.rst
> > index 14102ae035dc..0fe726a6ee67 100644
> > --- a/Documentation/gpu/drm-kms-helpers.rst
> > +++ b/Documentation/gpu/drm-kms-helpers.rst
> > @@ -181,6 +181,12 @@ Panel Helper Reference
> > .. kernel-doc:: drivers/gpu/drm/drm_panel_orientation_quirks.c
> > :export:
> >
> > +HDCP Helper Functions Reference
> > +===
> > +
> > +.. kernel-doc:: drivers/gpu/drm/drm_hdcp.c
> > + :export:
> > +
> > Display Port Helper Functions Reference
> > ===
> >
> > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > index 72f5036d9bfa..dd02e9dec810 100644
> > --- a/drivers/gpu/drm/Makefile
> > +++ b/drivers/gpu/drm/Makefile
> > @@ -17,7 +17,7 @@ drm-y :=drm_auth.o drm_cache.o \
> > drm_plane.o drm_color_mgmt.o drm_print.o \
> > drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
> > drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
> > - drm_atomic_uapi.o
> > + drm_atomic_uapi.o drm_hdcp.o
> >
> > drm-$(CONFIG_DRM_LEGACY) += drm_legacy_misc.o drm_bufs.o drm_context.o
> > drm_dma.o drm_scatter.o drm_lock.o
> > drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
> > diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
> > new file mode 100644
> > index ..dc0e13409221
> > --- /dev/null
> > +++ b/drivers/gpu/drm/drm_hdcp.c
> > @@ -0,0 +1,342 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2019 Intel Corporation.
> > + *
> > + * Authors:
> > + * Ramalingam C
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +struct hdcp_srm {
> > + u8 *srm_buf;
>
> Allocated, but seems to not be used.
>
> > + size_t received_srm_sz;
>
> Seems to be unused. Seems to both be leftovers from the sysfs interface.
>
> > + u32 revoked_ksv_cnt;
> > + u8 *revoked_ksv_list;
> > +
> > + /* Mutex to protect above struct member */
> > + struct mutex mutex;
> > +} *srm_data;
> > +
> > +static inline void drm_hdcp_print_ksv(const u8 *ksv)
> > +{
> > + DRM_DEBUG("\t%#02x, %#02x, %#02x, %#02x, %#02x\n",
> > + ksv[0], ksv[1], ksv[2], ksv[3], ksv[4]);
> > +}
> > +
> > +static u32 drm_hdcp_get_revoked_ksv_count(const u8 *buf, u32 vrls_length)
> > +{
> > + u32 parsed_bytes = 0, ksv_count = 0, vrl_ksv_cnt, vrl_sz;
> > +
> > + while (parsed_bytes < vrls_length) {
> > + vrl_ksv_cnt = *buf;
> > + ksv_count += vrl_ksv_cnt;
> > +
> > + vrl_sz = (vrl_ksv_cnt * DRM_HDCP_KSV_LEN) + 1;
> > + buf += vrl_sz;
> > + parsed_bytes += vrl_sz;
> > + }
> > +
> > + /*
> > +* When vrls are not valid, ksvs are not considered.
> > +* Hence SRM will be discarded.
> > +*/
> > + if (parsed_bytes != vrls_length)
> > + ksv_count = 0;
> > +
> > + return ksv_count;
> > +}
> > +
> > +static u32 drm_hdcp_get_revoked_ksvs(const u8 *buf, u8 *revoked_ksv_list,
> > +u32 vrls_length)
> > +{
> > + u32
Re: [Intel-gfx] [PATCH] drm/i915: add force_probe module parameter to replace alpha_support
Hi Jani,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20190506]
[cannot apply to v5.1]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Jani-Nikula/drm-i915-add-force_probe-module-parameter-to-replace-alpha_support/20190507-045927
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-x009-201918 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All error/warnings (new ones prefixed by >>):
In file included from arch/x86/include/asm/bug.h:83:0,
from include/linux/bug.h:5,
from include/linux/mmdebug.h:5,
from include/linux/gfp.h:5,
from include/linux/firmware.h:7,
from drivers/gpu/drm/i915/intel_csr.c:25:
drivers/gpu/drm/i915/intel_csr.c: In function 'intel_csr_ucode_init':
>> drivers/gpu/drm/i915/intel_csr.c:532:12: error: implicit declaration of
>> function 'IS_ALPHA_SUPPORT'; did you mean 'DP_PSR_SUPPORT'?
>> [-Werror=implicit-function-declaration]
WARN_ON(!IS_ALPHA_SUPPORT(INTEL_INFO(dev_priv)));
^
include/asm-generic/bug.h:131:25: note: in definition of macro 'WARN'
int __ret_warn_on = !!(condition);\
^
>> drivers/gpu/drm/i915/intel_csr.c:532:3: note: in expansion of macro 'WARN_ON'
WARN_ON(!IS_ALPHA_SUPPORT(INTEL_INFO(dev_priv)));
^~~
cc1: some warnings being treated as errors
vim +532 drivers/gpu/drm/i915/intel_csr.c
eb805623 Daniel Vetter 2015-05-04 462
aa9145c4 Animesh Manna 2015-05-13 463 /**
aa9145c4 Animesh Manna 2015-05-13 464 * intel_csr_ucode_init() -
initialize the firmware loading.
f4448375 Daniel Vetter 2015-10-28 465 * @dev_priv: i915 drm device.
aa9145c4 Animesh Manna 2015-05-13 466 *
aa9145c4 Animesh Manna 2015-05-13 467 * This function is called at the
time of loading the display driver to read
aa9145c4 Animesh Manna 2015-05-13 468 * firmware from a .bin file and
copied into a internal memory.
aa9145c4 Animesh Manna 2015-05-13 469 */
f4448375 Daniel Vetter 2015-10-28 470 void intel_csr_ucode_init(struct
drm_i915_private *dev_priv)
eb805623 Daniel Vetter 2015-05-04 471 {
eb805623 Daniel Vetter 2015-05-04 472struct intel_csr *csr =
_priv->csr;
8144ac59 Daniel Vetter 2015-10-28 473
8144ac59 Daniel Vetter 2015-10-28 474INIT_WORK(_priv->csr.work,
csr_load_work_fn);
eb805623 Daniel Vetter 2015-05-04 475
f4448375 Daniel Vetter 2015-10-28 476if (!HAS_CSR(dev_priv))
eb805623 Daniel Vetter 2015-05-04 477return;
eb805623 Daniel Vetter 2015-05-04 478
d8a5b7d7 Jani Nikula 2018-09-26 479/*
d8a5b7d7 Jani Nikula 2018-09-26 480 * Obtain a runtime pm
reference, until CSR is loaded, to avoid entering
d8a5b7d7 Jani Nikula 2018-09-26 481 * runtime-suspend.
d8a5b7d7 Jani Nikula 2018-09-26 482 *
d8a5b7d7 Jani Nikula 2018-09-26 483 * On error, we return with the
rpm wakeref held to prevent runtime
d8a5b7d7 Jani Nikula 2018-09-26 484 * suspend as runtime suspend
*requires* a working CSR for whatever
d8a5b7d7 Jani Nikula 2018-09-26 485 * reason.
d8a5b7d7 Jani Nikula 2018-09-26 486 */
0e6e0be4 Chris Wilson2019-01-14 487
intel_csr_runtime_pm_get(dev_priv);
d8a5b7d7 Jani Nikula 2018-09-26 488
02c07b76 Lucas De Marchi 2018-11-16 489if (INTEL_GEN(dev_priv) >= 12) {
02c07b76 Lucas De Marchi 2018-11-16 490/* Allow to load fw via
parameter using the last known size */
02c07b76 Lucas De Marchi 2018-11-16 491csr->max_fw_size =
GEN12_CSR_MAX_FW_SIZE;
4b225248 Anusha Srivatsa 2019-03-22 492} else if (IS_GEN(dev_priv,
11)) {
7fe78985 Jani Nikula 2018-09-27 493csr->fw_path =
ICL_CSR_PATH;
180e9d23 Jani Nikula 2018-09-26 494csr->required_version =
ICL_CSR_VERSION_REQUIRED;
d8a5b7d7 Jani Nikula 2018-09-26 495csr->max_fw_size =
ICL_CSR_MAX_FW_SIZE;
180e9d23 Jani Nikula 2018-09-26 496} else if
(IS_CANNONLAKE(dev_priv)) {
7fe78985 Jani Nikula 2018-09-27 497csr->fw_path =
CNL_CSR_PATH;
180e9d23 Jani Nikula 2018-09-26 498csr->required_version =
CNL_CSR_VERSION_REQUIRED;
7fe78985 Jani Nikula 2018-09-27 499csr->max_fw_size =
CNL_CSR_MAX_FW_SIZE;
180e9d23 Jani Nikula 2018-09-26 500} else if
(IS_GEMINILAKE(dev_priv)) {
7fe78985
Re: [Intel-gfx] [PATCH] drm/i915: Engine relative MMIO
On Tue, Apr 23, 2019 at 06:50:13PM -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> With virtual engines, it is no longer possible to know which specific
> physical engine a given request will be executed on at the time that
> request is generated. This means that the request itself must be engine
> agnostic - any direct register writes must be relative to the engine
> and not absolute addresses.
>
> The LRI command has support for engine relative addressing. However,
> the mechanism is not transparent to the driver. The scheme for Gen11
> (MI_LRI_ADD_CS_MMIO_START) requires the LRI address to have no
> absolute engine base component. The hardware then adds on the correct
> engine offset at execution time.
>
> Due to the non-trivial and differing schemes on different hardware, it
> is not possible to simply update the code that creates the LRI
> commands to set a remap flag and let the hardware get on with it.
> Instead, this patch adds function wrappers for generating the LRI
> command itself and then for constructing the correct address to use
> with the LRI.
>
> v2: Fix build break in GVT. Remove flags parameter [review feedback
> from Chris W].
>
> v3: Fix build break in selftest. Rebase to newer base tree and fix
> merge conflict.
>
> v4: More rebasing. Rmoved relative addressing support from Gen7-9 only
> code paths [review feedback from Chris W].
First of all, would you have a rebased version after gt/ ?
So, from my point of view v3 was better than this because this spread
the __MI_LOAD_REGISTER_IMM everywhere.
Maybe I just disagree with Chris and I'd prefer a single place
like v3, but anyway we could probably arrive in an intermediate
solution like: Couldn't we do in a way that we keep the MI_LRI without
'__' and use this new function only on the paths needed?
and maybe name this function gen11_get_lri_cmd? to make it clear
that gen11+ needs to use this path.
>
> Signed-off-by: John Harrison
> ---
> drivers/gpu/drm/i915/gvt/mmio_context.c | 16 +++-
> drivers/gpu/drm/i915/i915_cmd_parser.c| 4 +-
> drivers/gpu/drm/i915/i915_gem_context.c | 12 +--
> drivers/gpu/drm/i915/i915_gem_execbuffer.c| 3 +-
> drivers/gpu/drm/i915/i915_perf.c | 19 +++--
> drivers/gpu/drm/i915/intel_engine_cs.c| 11 +++
> drivers/gpu/drm/i915/intel_gpu_commands.h | 6 +-
> drivers/gpu/drm/i915/intel_lrc.c | 79 ++-
> drivers/gpu/drm/i915/intel_lrc_reg.h | 4 +-
> drivers/gpu/drm/i915/intel_mocs.c | 17 ++--
> drivers/gpu/drm/i915/intel_ringbuffer.c | 45 +--
> drivers/gpu/drm/i915/intel_ringbuffer.h | 4 +
> drivers/gpu/drm/i915/intel_workarounds.c | 4 +-
> .../drm/i915/selftests/intel_workarounds.c| 9 ++-
> 14 files changed, 154 insertions(+), 79 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/mmio_context.c
> b/drivers/gpu/drm/i915/gvt/mmio_context.c
> index e7e14c842be4..1b4d78e55ed6 100644
> --- a/drivers/gpu/drm/i915/gvt/mmio_context.c
> +++ b/drivers/gpu/drm/i915/gvt/mmio_context.c
> @@ -199,14 +199,14 @@ restore_context_mmio_for_inhibit(struct intel_vgpu
> *vgpu,
> if (IS_ERR(cs))
> return PTR_ERR(cs);
>
> - *cs++ = MI_LOAD_REGISTER_IMM(count);
> + *cs++ = i915_get_lri_cmd(req->engine, count);
> for (mmio = gvt->engine_mmio_list.mmio;
>i915_mmio_reg_valid(mmio->reg); mmio++) {
> if (mmio->ring_id != ring_id ||
> !mmio->in_context)
> continue;
>
> - *cs++ = i915_mmio_reg_offset(mmio->reg);
> + *cs++ = i915_get_lri_reg(req->engine, mmio->reg);
> *cs++ = vgpu_vreg_t(vgpu, mmio->reg) |
> (mmio->mask << 16);
> gvt_dbg_core("add lri reg pair 0x%x:0x%x in inhibit ctx,
> vgpu:%d, rind_id:%d\n",
> @@ -234,7 +234,11 @@ restore_render_mocs_control_for_inhibit(struct
> intel_vgpu *vgpu,
> if (IS_ERR(cs))
> return PTR_ERR(cs);
>
> - *cs++ = MI_LOAD_REGISTER_IMM(GEN9_MOCS_SIZE);
> + /*
> + * GEN9_GFX_MOCS is not engine relative, therefore there is no
> + * need for relative addressing.
> + */
> + *cs++ = __MI_LOAD_REGISTER_IMM(GEN9_MOCS_SIZE);
>
> for (index = 0; index < GEN9_MOCS_SIZE; index++) {
> *cs++ = i915_mmio_reg_offset(GEN9_GFX_MOCS(index));
> @@ -261,7 +265,11 @@ restore_render_mocs_l3cc_for_inhibit(struct intel_vgpu
> *vgpu,
> if (IS_ERR(cs))
> return PTR_ERR(cs);
>
> - *cs++ = MI_LOAD_REGISTER_IMM(GEN9_MOCS_SIZE / 2);
> + /*
> + * GEN9_LNCFCMOCS is not engine relative, therefore there is no
> + * need for relative addressing.
> + */
> + *cs++ = __MI_LOAD_REGISTER_IMM(GEN9_MOCS_SIZE / 2);
>
> for (index = 0; index < GEN9_MOCS_SIZE / 2; index++) {
> *cs++ = i915_mmio_reg_offset(GEN9_LNCFCMOCS(index));
> diff --git
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/fb-helper: Move modesetting code to drm_client (rev6)
== Series Details == Series: drm/fb-helper: Move modesetting code to drm_client (rev6) URL : https://patchwork.freedesktop.org/series/58597/ State : success == Summary == CI Bug Log - changes from CI_DRM_6051_full -> Patchwork_12973_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12973_full that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@dpms-lpsp: - shard-skl: [PASS][1] -> [INCOMPLETE][2] ([fdo#107807]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/shard-skl7/igt@i915_pm_...@dpms-lpsp.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12973/shard-skl2/igt@i915_pm_...@dpms-lpsp.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +4 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/shard-apl2/igt@i915_susp...@fence-restore-tiled2untiled.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12973/shard-apl8/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-pwrite: - shard-iclb: [PASS][5] -> [FAIL][6] ([fdo#103167]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/shard-iclb6/igt@kms_frontbuffer_track...@fbcpsr-1p-offscren-pri-shrfb-draw-pwrite.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12973/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-offscren-pri-shrfb-draw-pwrite.html * igt@kms_plane_scaling@pipe-c-scaler-with-pixel-format: - shard-glk: [PASS][7] -> [SKIP][8] ([fdo#109271] / [fdo#109278]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/shard-glk9/igt@kms_plane_scal...@pipe-c-scaler-with-pixel-format.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12973/shard-glk1/igt@kms_plane_scal...@pipe-c-scaler-with-pixel-format.html * igt@kms_psr@psr2_cursor_plane_onoff: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109441]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/shard-iclb2/igt@kms_psr@psr2_cursor_plane_onoff.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12973/shard-iclb7/igt@kms_psr@psr2_cursor_plane_onoff.html * igt@kms_sysfs_edid_timing: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#100047]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/shard-iclb6/igt@kms_sysfs_edid_timing.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12973/shard-iclb2/igt@kms_sysfs_edid_timing.html Possible fixes * igt@i915_pm_rpm@dpms-mode-unset-lpsp: - shard-skl: [INCOMPLETE][13] ([fdo#107807]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/shard-skl10/igt@i915_pm_...@dpms-mode-unset-lpsp.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12973/shard-skl8/igt@i915_pm_...@dpms-mode-unset-lpsp.html * igt@i915_suspend@sysfs-reader: - shard-apl: [DMESG-WARN][15] ([fdo#108566]) -> [PASS][16] +6 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/shard-apl5/igt@i915_susp...@sysfs-reader.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12973/shard-apl5/igt@i915_susp...@sysfs-reader.html * igt@kms_cursor_legacy@pipe-c-forked-move: - shard-hsw: [INCOMPLETE][17] ([fdo#103540]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/shard-hsw4/igt@kms_cursor_leg...@pipe-c-forked-move.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12973/shard-hsw4/igt@kms_cursor_leg...@pipe-c-forked-move.html * igt@kms_flip@flip-vs-blocking-wf-vblank: - shard-skl: [FAIL][19] ([fdo#100368]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/shard-skl9/igt@kms_f...@flip-vs-blocking-wf-vblank.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12973/shard-skl1/igt@kms_f...@flip-vs-blocking-wf-vblank.html * igt@kms_flip@flip-vs-expired-vblank: - shard-glk: [FAIL][21] ([fdo#105363]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/shard-glk9/igt@kms_f...@flip-vs-expired-vblank.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12973/shard-glk9/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-skl: [INCOMPLETE][23] ([fdo#109507]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/shard-skl8/igt@kms_f...@flip-vs-suspend-interruptible.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12973/shard-skl7/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_flip@modeset-vs-vblank-race-interruptible: - shard-glk:
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gen11: enable support for headerless msgs (rev4)
This doesn't seem to be a valid failure. I just reran the test using trybot and there were no failures. https://lists.freedesktop.org/archives/intel-gfx-trybot/2019-May/071989.html On Thu, Apr 25, 2019 at 07:54:51AM +, intel-gfx-requ...@lists.freedesktop.org wrote: > Date: Thu, 25 Apr 2019 07:54:50 - > From: Patchwork > To: "Chris Wilson" > Cc: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gen11: enable > support for headerless msgs (rev4) > Message-ID: <20190425075450.550.19...@emeril.freedesktop.org> > Content-Type: text/plain; charset="utf-8" > > == Series Details == > > Series: drm/i915/gen11: enable support for headerless msgs (rev4) > URL : https://patchwork.freedesktop.org/series/59839/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_5995 -> Patchwork_12869 > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_12869 absolutely need to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_12869, please notify your bug team to allow them > to document this new failure mode, which will reduce false positives in CI. > > External URL: > https://patchwork.freedesktop.org/api/1.0/series/59839/revisions/4/mbox/ > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_12869: > > ### IGT changes ### > > Possible regressions > > * igt@gem_exec_suspend@basic-s3: > - fi-apl-guc: NOTRUN -> [DMESG-WARN][1] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12869/fi-apl-guc/igt@gem_exec_susp...@basic-s3.html > > > Known issues > > > Here are the changes found in Patchwork_12869 that come from known issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_exec_suspend@basic-s4-devices: > - fi-blb-e6850: [PASS][2] -> [INCOMPLETE][3] ([fdo#107718]) >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5995/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12869/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html > > * igt@i915_selftest@live_contexts: > - fi-bdw-gvtdvm: [PASS][4] -> [DMESG-FAIL][5] ([fdo#110235 ]) >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5995/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12869/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html > > > [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 > [fdo#110235 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 > > > Participating hosts (32 -> 42) > -- > > Additional (15): fi-bxt-dsi fi-skl-gvtdvm fi-bsw-n3050 fi-byt-j1900 > fi-skl-6770hq fi-apl-guc fi-snb-2520m fi-byt-clapper fi-bxt-j4205 fi-icl-u3 > fi-pnv-d510 fi-icl-y fi-byt-n2820 fi-bsw-kefka fi-skl-6700k2 > Missing(5): fi-kbl-soraka fi-ilk-m540 fi-bsw-cyan fi-ctg-p8600 > fi-bdw-samus > > > Build changes > - > > * Linux: CI_DRM_5995 -> Patchwork_12869 > > CI_DRM_5995: 290f6892805fb22466c77e373ffd4c8f9e028f7f @ > git://anongit.freedesktop.org/gfx-ci/linux > IGT_4963: 11e10bc575516c56978640fcc697c27f277c660a @ > git://anongit.freedesktop.org/xorg/app/intel-gpu-tools > Patchwork_12869: 95faef437aa7e6333a2bef8134a5b3eee82f68c1 @ > git://anongit.freedesktop.org/gfx-ci/linux > > > == Linux commits == > > 95faef437aa7 drm/i915/gen11: enable support for headerless msgs > > == Logs == > > For more details see: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12869/ > > > -- > > Subject: Digest Footer > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > > End of Intel-gfx Digest, Vol 135, Issue 507 > *** ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/icl: Fix setting 10 bit deep color mode (rev2)
== Series Details == Series: drm/i915/icl: Fix setting 10 bit deep color mode (rev2) URL : https://patchwork.freedesktop.org/series/60080/ State : success == Summary == CI Bug Log - changes from CI_DRM_6051_full -> Patchwork_12972_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12972_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_tiled_swapping@non-threaded: - shard-glk: [PASS][1] -> [DMESG-WARN][2] ([fdo#108686]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/shard-glk4/igt@gem_tiled_swapp...@non-threaded.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12972/shard-glk1/igt@gem_tiled_swapp...@non-threaded.html * igt@kms_cursor_crc@cursor-256x256-suspend: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/shard-apl5/igt@kms_cursor_...@cursor-256x256-suspend.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12972/shard-apl7/igt@kms_cursor_...@cursor-256x256-suspend.html * igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: - shard-glk: [PASS][5] -> [FAIL][6] ([fdo#106509] / [fdo#107409]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/shard-glk1/igt@kms_cursor_leg...@2x-nonblocking-modeset-vs-cursor-atomic.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12972/shard-glk6/igt@kms_cursor_leg...@2x-nonblocking-modeset-vs-cursor-atomic.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-mmap-gtt: - shard-iclb: [PASS][7] -> [FAIL][8] ([fdo#103167]) +6 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/shard-iclb3/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-mmap-gtt.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12972/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-mmap-gtt.html * igt@kms_plane@pixel-format-pipe-b-planes: - shard-glk: [PASS][9] -> [SKIP][10] ([fdo#109271]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/shard-glk9/igt@kms_pl...@pixel-format-pipe-b-planes.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12972/shard-glk2/igt@kms_pl...@pixel-format-pipe-b-planes.html * igt@kms_plane_lowres@pipe-a-tiling-x: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103166]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/shard-iclb4/igt@kms_plane_low...@pipe-a-tiling-x.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12972/shard-iclb7/igt@kms_plane_low...@pipe-a-tiling-x.html * igt@kms_plane_scaling@pipe-c-scaler-with-pixel-format: - shard-glk: [PASS][13] -> [SKIP][14] ([fdo#109271] / [fdo#109278]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/shard-glk9/igt@kms_plane_scal...@pipe-c-scaler-with-pixel-format.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12972/shard-glk4/igt@kms_plane_scal...@pipe-c-scaler-with-pixel-format.html * igt@kms_psr@psr2_cursor_plane_onoff: - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109441]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/shard-iclb2/igt@kms_psr@psr2_cursor_plane_onoff.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12972/shard-iclb3/igt@kms_psr@psr2_cursor_plane_onoff.html * igt@kms_rotation_crc@multiplane-rotation-cropping-top: - shard-glk: [PASS][17] -> [DMESG-FAIL][18] ([fdo#105763] / [fdo#106538]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/shard-glk6/igt@kms_rotation_...@multiplane-rotation-cropping-top.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12972/shard-glk3/igt@kms_rotation_...@multiplane-rotation-cropping-top.html Possible fixes * igt@i915_pm_rpm@dpms-mode-unset-lpsp: - shard-skl: [INCOMPLETE][19] ([fdo#107807]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/shard-skl10/igt@i915_pm_...@dpms-mode-unset-lpsp.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12972/shard-skl6/igt@i915_pm_...@dpms-mode-unset-lpsp.html * igt@i915_suspend@sysfs-reader: - shard-apl: [DMESG-WARN][21] ([fdo#108566]) -> [PASS][22] +3 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/shard-apl5/igt@i915_susp...@sysfs-reader.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12972/shard-apl7/igt@i915_susp...@sysfs-reader.html * igt@kms_cursor_legacy@pipe-c-forked-move: - shard-hsw: [INCOMPLETE][23] ([fdo#103540]) -> [PASS][24] +1 similar issue [23]:
[Intel-gfx] Cannot submit merge request for xf86-video-intel
Hi, everyone.
I am having trouble submitting a merge request on
gitlab.freedesktop.org for xf86-video-intel, even though doing so for
xserver works fine. The README for xf86-video-intel states that its
mailing list is intel-gfx@lists.freedesktop.org, so I am asking here,
even though most of the discussion on this list appears to be Linux
DRM patches.
On gitlab.freedesktop.org, I forked a personal copy of
xf86-video-intel and pushed a change to it, but when I try to create a
new pull request, the web page only offers me the options of
submitting the merge request to one of two other users' tree.
If I explicitly type "xorg/driver/xf86-video-intel" into the pull down
menu for "Target branch" (because the menu does have a box for
entering the text directly), the target repository name is updated,
but when I click on "Compare branches and continue", I get a screen
that states "You must select different branches," and has the target
and source both set to my repository and branch.
My understanding is that, on Linux these days, the X server now has
xf86-video-modesetting merged in and normally uses that instead of
xf86-video-intel, but xf86-video-intel is not marked as "archived" on
gitlab.freedesktop.org, so I am guessing that changes to it are still
potentially useful on some other operating systems or in some other
unusual cases.
In case anyone is curious about what the patch is, it is just
essentially mechanical conversions of "assert(a && b)" to "assert(a)"
and "assert(b)", hopefully for more efficient diagnosis of assertion
failure reports, which I have attached to this message for reference.
I submitting a similar merge request for the core X server a few days
ago, and it apparently got a positive feedback, and I expect it to be
merged shortly.
Anyhow, any advice on how I should proceed, including simply
redirecting me to a more appropriate mailing list, would be
appreciated. Thanks for reading this far, and thanks in advance for
any guidance on this.
Adam
commit 3816fe4ebb1050ffe8195174d3810573ebfc7dde
Author: Adam Richter
Date: Sat May 4 16:06:17 2019 -0700
Separate each "assert(a && b)" statement into "assert(a)" and "assert(b)".
This should provide more precise diagnostics when an assertion failure
is detected, which can sometimes be rare and difficult to generate.
diff --git a/src/intel_device.c b/src/intel_device.c
index 21955073..ca028e2c 100644
--- a/src/intel_device.c
+++ b/src/intel_device.c
@@ -669,7 +669,8 @@ int __intel_peek_fd(ScrnInfoPtr scrn)
struct intel_device *dev;
dev = intel_device(scrn);
- assert(dev && dev->fd != -1);
+ assert(dev);
+ assert(dev->fd != -1);
return dev->fd;
}
@@ -678,7 +679,8 @@ int intel_has_render_node(struct intel_device *dev)
{
struct stat st;
- assert(dev && dev->fd != -1);
+ assert(dev);
+ assert(dev->fd != -1);
return is_render_node(dev->fd, );
}
@@ -730,13 +732,15 @@ struct intel_device *intel_get_device(ScrnInfoPtr scrn, int *fd)
const char *intel_get_master_name(struct intel_device *dev)
{
- assert(dev && dev->master_node);
+ assert(dev);
+ assert(dev->master_node);
return dev->master_node;
}
const char *intel_get_client_name(struct intel_device *dev)
{
- assert(dev && dev->render_node);
+ assert(dev);
+ assert(dev->render_node);
return dev->render_node;
}
@@ -755,7 +759,8 @@ int intel_get_client_fd(struct intel_device *dev)
{
int fd = -1;
- assert(dev && dev->fd != -1);
+ assert(dev);
+ assert(dev->fd != -1);
assert(dev->render_node);
#ifdef O_CLOEXEC
@@ -778,7 +783,8 @@ int intel_get_client_fd(struct intel_device *dev)
int intel_get_device_id(struct intel_device *dev)
{
- assert(dev && dev->fd != -1);
+ assert(dev);
+ assert(dev->fd != -1);
return dev->device_id;
}
@@ -786,7 +792,8 @@ int intel_get_master(struct intel_device *dev)
{
int ret;
- assert(dev && dev->fd != -1);
+ assert(dev);
+ assert(dev->fd != -1);
ret = 0;
if (dev->master_count++ == 0) {
@@ -808,7 +815,8 @@ int intel_put_master(struct intel_device *dev)
{
int ret;
- assert(dev && dev->fd != -1);
+ assert(dev);
+ assert(dev->fd != -1);
ret = 0;
assert(dev->master_count);
@@ -823,7 +831,8 @@ int intel_put_master(struct intel_device *dev)
void intel_put_device(struct intel_device *dev)
{
- assert(dev && dev->fd != -1);
+ assert(dev);
+ assert(dev->fd != -1);
assert(dev->open_count);
if (--dev->open_count)
diff --git a/src/sna/blt.c b/src/sna/blt.c
index cb90437a..2c2f89a0 100644
--- a/src/sna/blt.c
+++ b/src/sna/blt.c
@@ -647,7 +647,8 @@ memcpy_blt(const void *src, void *dst, int bpp,
assert(src);
assert(dst);
- assert(width && height);
+ assert(width);
+ assert(height);
assert(bpp >= 8);
assert(width*bpp <= 8*src_stride);
assert(width*bpp <= 8*dst_stride);
@@ -1372,7 +1373,8 @@ memcpy_xor(const void *src, void *dst, int bpp,
uint8_t *dst_bytes;
int i, w;
- assert(width && height);
+ assert(width);
+ assert(height);
assert(bpp >= 8);
assert(width*bpp <=
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/fb-helper: Move modesetting code to drm_client (rev6)
== Series Details ==
Series: drm/fb-helper: Move modesetting code to drm_client (rev6)
URL : https://patchwork.freedesktop.org/series/58597/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6051 -> Patchwork_12973
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12973/
Known issues
Here are the changes found in Patchwork_12973 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: [PASS][1] -> [DMESG-WARN][2] ([fdo#108965])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12973/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html
* igt@i915_selftest@live_contexts:
- fi-bdw-gvtdvm: [PASS][3] -> [DMESG-FAIL][4] ([fdo#110235])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12973/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
- fi-skl-gvtdvm: [PASS][5] -> [DMESG-FAIL][6] ([fdo#110235])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12973/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html
[fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
[fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235
Participating hosts (53 -> 45)
--
Additional (1): fi-pnv-d510
Missing(9): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-bsw-n3050
fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6051 -> Patchwork_12973
CI_DRM_6051: fac89f79a454771f6595bcd11d9a119d5acc42d0 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4972: f052e49a43cc9704ea5f240df15dd9d3dfed68ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12973: 8cff9bd3b41e3359d563d63a9b368eb4ea9cc3a0 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
8cff9bd3b41e drm/client: Hack: Add bootsplash example
8b19c7eddb5d drm/fb-helper: Move out modeset config code
455217b5f670 drm/fb-helper: Prepare to move out modeset config code
d699e67d9ac1 drm/fb-helper: Remove drm_fb_helper_connector
61691a1645f3 drm/fb-helper: Move out commit code
ae3299140ceb drm/fb-helper: Prepare to move out commit code
e2cdc53e8315 drm/fb-helper: Remove drm_fb_helper_crtc
a196fbcfb902 drm/fb-helper: Remove drm_fb_helper_crtc->{x, y, desired_mode}
05a044850b72 drm/fb-helper: No need to cache rotation and sw_rotations
449ad53787d2 drm/fb-helper: Avoid race with DRM userspace
8412c5a47e6f drm/atomic: Move __drm_atomic_helper_disable_plane/set_config()
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12973/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v5][PATCH 11/11] drm/i915: Add intel_color_lut_equal() to compare hw and sw gamma/degamma lut values
On 07-May-19 12:03 AM, Ville Syrjälä wrote:
On Sat, May 04, 2019 at 10:41:40PM +0530, Swati Sharma wrote:
v3: Rebase
v4: -Renamed intel_compare_color_lut() to intel_color_lut_equal() [Jani]
-Added the default label above the correct label [Jani]
-Corrected smatch warn "variable dereferenced before check" [Dan Carpenter]
v5: -Added condition (!blob1 && !blob2) return true [Jani]
-Called PIPE_CONF_CHECK_COLOR_LUT inside if (!adjust) [Jani]
-Added #undef PIPE_CONF_CHECK_COLOR_LUT [Jani]
There are few things wrong in this patch:
[1] For chv bit precision is 14, on what basis it should be assigned?
Like everything else it will more or less be a reverse of the
compute side. For CHV we need to look at cgm_mode, gamma_enable,
gamma_mode, and c8_planes. Hmm. We actually don't have readout for
c8_planes so I guess we'll have to make some kind of exception for
that one.
By this I meant was, since I am assigning bit_precision on the basis
of gamma_mode in the compare function like
+ case GAMMA_MODE_MODE_8BIT:
+ bit_precision = 8;
etc. We have 8BIT, 10BIT and 12BIT GAMMA_MODES only.How will I
assign 14BIT on the basis of GAMMA_MODES (or) is there some other
option to assign precision. Please see the comparison code below.
[2] For glk and icl, degamma LUT values are not rounded off, there
should err=0 if using same function, how to make that exception?
You mean the degamma? Just set precision==16? Maybe I'm not
understanding the question.
Again same query as above, if I set precision as 16..on what basis?
Which GAMMA_MODE? (or) default i should set as 16?
[3] For glk, bit precision is 10 but gamma mode is 8BIT?
Not sure what you mean. glk gamma_mode works just like with
other ilk+ platforms (apart from not having the csc_mode
gamma vs. degamma control).
Sorry..my bad!
I suspect the most annoying case is ivb-bdw 10bit gamma mode
since we probably don't have the full readout to do the reverse
mapping of whether the LUT is used as gamma or degamma. But I
guess we'll just have to compare it against whichever one the
software state has.
One last query, as there is difference in precision of gamma and
degamma..we have one comparison function..how will we get to know whether
blob received is degamma or gamma? Do we need to pass some kind of enum value
to know comparison needs to be done for gamma or degamma?
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i915/intel_color.c | 54
drivers/gpu/drm/i915/intel_color.h | 6
drivers/gpu/drm/i915/intel_display.c | 12
3 files changed, 72 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 695b76d..73cb901 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -1630,6 +1630,60 @@ static void ilk_read_luts(struct intel_crtc_state
*crtc_state)
crtc_state->base.gamma_lut = ilk_read_gamma_lut(crtc_state);
}
+static inline bool err_check(struct drm_color_lut *sw_lut, struct drm_color_lut *hw_lut, u32 err)
+{
+return ((abs((long)hw_lut->red - sw_lut->red)) <= err) &&
+ ((abs((long)hw_lut->blue - sw_lut->blue)) <= err) &&
+ ((abs((long)hw_lut->green - sw_lut->green)) <= err);
+}
+
+bool intel_color_lut_equal(struct drm_property_blob *blob1,
+ struct drm_property_blob *blob2,
+ u32 gamma_mode)
+{
+ struct drm_color_lut *sw_lut, *hw_lut;
+ int sw_lut_size, hw_lut_size, i;
+ u32 bit_precision, err;
+
+ if (!blob1 && !blob2)
+ return true;
+
+ if (!blob1 || !blob2)
+ return false;
+
+ sw_lut_size = drm_color_lut_size(blob1);
+ hw_lut_size = drm_color_lut_size(blob2);
+
+ if (sw_lut_size != hw_lut_size)
+ return false;
+
+ switch(gamma_mode) {
+ default:
+ case GAMMA_MODE_MODE_8BIT:
+ bit_precision = 8;
+ break;
+ case GAMMA_MODE_MODE_10BIT:
+ case GAMMA_MODE_MODE_SPLIT:
+ bit_precision = 10;
+ break;
+ case GAMMA_MODE_MODE_12BIT:
+ bit_precision = 12;
+ break;
+ }
+
+ sw_lut = blob1->data;
+ hw_lut = blob2->data;
+
+ err = 0x >> bit_precision;
+
+ for (i = 0; i < sw_lut_size; i++) {
+if (!err_check(_lut[i], _lut[i], err))
+ return false;
+ }
+
+ return true;
+}
+
void intel_color_init(struct intel_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
diff --git a/drivers/gpu/drm/i915/intel_color.h
b/drivers/gpu/drm/i915/intel_color.h
index fc53de9..b525c80 100644
--- a/drivers/gpu/drm/i915/intel_color.h
+++ b/drivers/gpu/drm/i915/intel_color.h
@@ -6,13 +6,19 @@
#ifndef __INTEL_COLOR_H__
#define __INTEL_COLOR_H__
+#include
+
struct
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/fb-helper: Move modesetting code to drm_client (rev6)
== Series Details ==
Series: drm/fb-helper: Move modesetting code to drm_client (rev6)
URL : https://patchwork.freedesktop.org/series/58597/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/atomic: Move __drm_atomic_helper_disable_plane/set_config()
Okay!
Commit: drm/fb-helper: Avoid race with DRM userspace
Okay!
Commit: drm/fb-helper: No need to cache rotation and sw_rotations
Okay!
Commit: drm/fb-helper: Remove drm_fb_helper_crtc->{x, y, desired_mode}
-O:drivers/gpu/drm/drm_fb_helper.c:2045:40: warning: expression using
sizeof(void)
-O:drivers/gpu/drm/drm_fb_helper.c:2045:40: warning: expression using
sizeof(void)
-O:drivers/gpu/drm/drm_fb_helper.c:2046:40: warning: expression using
sizeof(void)
-O:drivers/gpu/drm/drm_fb_helper.c:2046:40: warning: expression using
sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:2045:40: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:2045:40: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:2046:40: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:2046:40: warning: expression using sizeof(void)
Commit: drm/fb-helper: Remove drm_fb_helper_crtc
-O:drivers/gpu/drm/drm_fb_helper.c:2062:43: warning: expression using
sizeof(void)
-O:drivers/gpu/drm/drm_fb_helper.c:2062:43: warning: expression using
sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:2025:43: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:2025:43: warning: expression using sizeof(void)
-./include/linux/slab.h:666:13: error: not a function
+./include/linux/slab.h:666:13: error: undefined identifier
'__builtin_mul_overflow'
+./include/linux/slab.h:666:13: warning: call with no type!
Commit: drm/fb-helper: Prepare to move out commit code
+drivers/gpu/drm/drm_fb_helper.c:404:6: warning: symbol
'drm_client_panel_rotation' was not declared. Should it be static?
+drivers/gpu/drm/drm_fb_helper.c:579:5: warning: symbol
'drm_client_modeset_commit_force' was not declared. Should it be static?
+drivers/gpu/drm/drm_fb_helper.c:603:5: warning: symbol
'drm_client_modeset_commit' was not declared. Should it be static?
+drivers/gpu/drm/drm_fb_helper.c:749:5: warning: symbol
'drm_client_modeset_dpms' was not declared. Should it be static?
Commit: drm/fb-helper: Move out commit code
+drivers/gpu/drm/drm_fb_helper.c:1766:40: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:1766:40: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:1767:40: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:1767:40: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:1781:43: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:1781:43: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:1783:43: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:1783:43: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:2287:30: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:3234:12: warning: symbol
'drm_fb_helper_modinit' was not declared. Should it be static?
-drivers/gpu/drm/drm_fb_helper.c:1766:40: warning: expression using sizeof(void)
-drivers/gpu/drm/drm_fb_helper.c:1766:40: warning: expression using sizeof(void)
-drivers/gpu/drm/drm_fb_helper.c:1767:40: warning: expression using sizeof(void)
-drivers/gpu/drm/drm_fb_helper.c:1767:40: warning: expression using sizeof(void)
-drivers/gpu/drm/drm_fb_helper.c:1781:43: warning: expression using sizeof(void)
-drivers/gpu/drm/drm_fb_helper.c:1781:43: warning: expression using sizeof(void)
-drivers/gpu/drm/drm_fb_helper.c:1783:43: warning: expression using sizeof(void)
-drivers/gpu/drm/drm_fb_helper.c:1783:43: warning: expression using sizeof(void)
-drivers/gpu/drm/drm_fb_helper.c:2287:30: warning: expression using sizeof(void)
-O:drivers/gpu/drm/drm_fb_helper.c:404:6: warning: symbol
'drm_client_panel_rotation' was not declared. Should it be static?
-O:drivers/gpu/drm/drm_fb_helper.c:579:5: warning: symbol
'drm_client_modeset_commit_force' was not declared. Should it be static?
-O:drivers/gpu/drm/drm_fb_helper.c:603:5: warning: symbol
'drm_client_modeset_commit' was not declared. Should it be static?
-O:drivers/gpu/drm/drm_fb_helper.c:749:5: warning: symbol
'drm_client_modeset_dpms' was not declared. Should it be static?
Commit: drm/fb-helper: Remove drm_fb_helper_connector
-O:drivers/gpu/drm/drm_fb_helper.c:2287:30: warning: expression using
sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:2086:30: warning: expression using sizeof(void)
-./include/linux/slab.h:666:13: error: not a function
Commit: drm/fb-helper: Prepare to move out modeset config code
-O:drivers/gpu/drm/drm_fb_helper.c:2086:30: warning: expression using
sizeof(void)
+drivers/gpu/drm/drm_fb_helper.c:2090:30: warning: expression using sizeof(void)
Commit: drm/fb-helper: Move out modeset config code
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/fb-helper: Move modesetting code to drm_client (rev6)
== Series Details ==
Series: drm/fb-helper: Move modesetting code to drm_client (rev6)
URL : https://patchwork.freedesktop.org/series/58597/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8412c5a47e6f drm/atomic: Move __drm_atomic_helper_disable_plane/set_config()
449ad53787d2 drm/fb-helper: Avoid race with DRM userspace
05a044850b72 drm/fb-helper: No need to cache rotation and sw_rotations
a196fbcfb902 drm/fb-helper: Remove drm_fb_helper_crtc->{x, y, desired_mode}
e2cdc53e8315 drm/fb-helper: Remove drm_fb_helper_crtc
-:123: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#123:
new file mode 100644
-:200: CHECK:LINE_SPACING: Please use a blank line after
function/struct/union/enum declarations
#200: FILE: drivers/gpu/drm/drm_client_modeset.c:73:
+}
+/* TODO: Remove export when modeset code has been moved over */
-:230: CHECK:LINE_SPACING: Please use a blank line after
function/struct/union/enum declarations
#230: FILE: drivers/gpu/drm/drm_client_modeset.c:103:
+}
+/* TODO: Remove export when modeset code has been moved over */
-:924: WARNING:LONG_LINE: line over 100 characters
#924: FILE: drivers/gpu/drm/drm_fb_helper.c:2766:
+ if (WARN_ON_ONCE(modeset->num_connectors ==
DRM_CLIENT_MAX_CLONED_CONNECTORS ||
-:925: WARNING:LONG_LINE: line over 100 characters
#925: FILE: drivers/gpu/drm/drm_fb_helper.c:2767:
+(dev->mode_config.num_crtc > 1 &&
modeset->num_connectors == 1)))
-:1059: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'modeset' - possible
side-effects?
#1059: FILE: include/drm/drm_client.h:164:
+#define drm_client_for_each_modeset(modeset, client) \
+ for (({ lockdep_assert_held(&(client)->modeset_mutex); }), \
+modeset = (client)->modesets; modeset->crtc; modeset++)
-:1059: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'client' - possible
side-effects?
#1059: FILE: include/drm/drm_client.h:164:
+#define drm_client_for_each_modeset(modeset, client) \
+ for (({ lockdep_assert_held(&(client)->modeset_mutex); }), \
+modeset = (client)->modesets; modeset->crtc; modeset++)
total: 0 errors, 3 warnings, 4 checks, 958 lines checked
ae3299140ceb drm/fb-helper: Prepare to move out commit code
61691a1645f3 drm/fb-helper: Move out commit code
-:152: WARNING:LONG_LINE: line over 100 characters
#152: FILE: drivers/gpu/drm/drm_client_modeset.c:223:
+ struct drm_crtc_state *crtc_state =
drm_atomic_get_new_crtc_state(state, crtc);
-:285: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#285: FILE: drivers/gpu/drm/drm_client_modeset.c:356:
+ drm_object_property_set_value(>base,
+ dev->mode_config.dpms_property, dpms_mode);
total: 0 errors, 1 warnings, 1 checks, 610 lines checked
d699e67d9ac1 drm/fb-helper: Remove drm_fb_helper_connector
-:589: WARNING:LONG_LINE: line over 100 characters
#589: FILE: drivers/gpu/drm/drm_fb_helper.c:1969:
+ connector->base.id, connector->tile_group
? connector->tile_group->id : 0);
-:946: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in
parentheses
#946: FILE: include/drm/drm_client.h:183:
+#define drm_client_for_each_connector_iter(connector, iter) \
+ drm_for_each_connector_iter(connector, iter) \
+ if (connector->connector_type != DRM_MODE_CONNECTOR_WRITEBACK)
-:946: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'connector' - possible
side-effects?
#946: FILE: include/drm/drm_client.h:183:
+#define drm_client_for_each_connector_iter(connector, iter) \
+ drm_for_each_connector_iter(connector, iter) \
+ if (connector->connector_type != DRM_MODE_CONNECTOR_WRITEBACK)
total: 1 errors, 1 warnings, 1 checks, 1007 lines checked
455217b5f670 drm/fb-helper: Prepare to move out modeset config code
-:169: WARNING:LONG_LINE: line over 100 characters
#169: FILE: drivers/gpu/drm/drm_fb_helper.c:2362:
+(dev->mode_config.num_crtc > 1 &&
modeset->num_connectors == 1))) {
total: 0 errors, 1 warnings, 0 checks, 179 lines checked
8b19c7eddb5d drm/fb-helper: Move out modeset config code
-:99: CHECK:BOOL_COMPARISON: Using comparison to false is error prone
#99: FILE: drivers/gpu/drm/drm_client_modeset.c:140:
+ if (cmdline_mode->specified == false)
-:170: WARNING:LONG_LINE: line over 100 characters
#170: FILE: drivers/gpu/drm/drm_client_modeset.c:211:
+ connector->display_info.non_desktop ? "non
desktop" : enabled[i] ? "yes" : "no");
-:314: CHECK:BOOL_COMPARISON: Using comparison to false is error prone
#314: FILE: drivers/gpu/drm/drm_client_modeset.c:355:
+ if (enabled[i] == false) {
-:348: WARNING:LONG_LINE: line over 100 characters
#348: FILE: drivers/gpu/drm/drm_client_modeset.c:389:
+ connector->base.id,
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Kill PCH_KBP
== Series Details == Series: drm/i915: Kill PCH_KBP URL : https://patchwork.freedesktop.org/series/60327/ State : success == Summary == CI Bug Log - changes from CI_DRM_6051_full -> Patchwork_12971_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12971_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_softpin@noreloc-s3: - shard-snb: [PASS][1] -> [DMESG-WARN][2] ([fdo#102365]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/shard-snb5/igt@gem_soft...@noreloc-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12971/shard-snb7/igt@gem_soft...@noreloc-s3.html * igt@i915_pm_rpm@universal-planes-dpms: - shard-iclb: [PASS][3] -> [INCOMPLETE][4] ([fdo#107713] / [fdo#108840]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/shard-iclb5/igt@i915_pm_...@universal-planes-dpms.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12971/shard-iclb4/igt@i915_pm_...@universal-planes-dpms.html * igt@i915_suspend@fence-restore-untiled: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/shard-apl6/igt@i915_susp...@fence-restore-untiled.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12971/shard-apl8/igt@i915_susp...@fence-restore-untiled.html * igt@kms_draw_crc@draw-method-xrgb-render-xtiled: - shard-skl: [PASS][7] -> [FAIL][8] ([fdo#103184] / [fdo#103232]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/shard-skl5/igt@kms_draw_...@draw-method-xrgb-render-xtiled.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12971/shard-skl4/igt@kms_draw_...@draw-method-xrgb-render-xtiled.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-hsw: [PASS][9] -> [INCOMPLETE][10] ([fdo#103540]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/shard-hsw4/igt@kms_f...@flip-vs-suspend-interruptible.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12971/shard-hsw2/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-pwrite: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103167]) +5 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/shard-iclb6/igt@kms_frontbuffer_track...@fbcpsr-1p-offscren-pri-shrfb-draw-pwrite.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12971/shard-iclb4/igt@kms_frontbuffer_track...@fbcpsr-1p-offscren-pri-shrfb-draw-pwrite.html * igt@kms_plane@pixel-format-pipe-b-planes: - shard-glk: [PASS][13] -> [SKIP][14] ([fdo#109271]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/shard-glk9/igt@kms_pl...@pixel-format-pipe-b-planes.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12971/shard-glk8/igt@kms_pl...@pixel-format-pipe-b-planes.html * igt@kms_plane_scaling@pipe-c-scaler-with-pixel-format: - shard-glk: [PASS][15] -> [SKIP][16] ([fdo#109271] / [fdo#109278]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/shard-glk9/igt@kms_plane_scal...@pipe-c-scaler-with-pixel-format.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12971/shard-glk8/igt@kms_plane_scal...@pipe-c-scaler-with-pixel-format.html * igt@kms_psr@psr2_cursor_plane_onoff: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/shard-iclb2/igt@kms_psr@psr2_cursor_plane_onoff.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12971/shard-iclb8/igt@kms_psr@psr2_cursor_plane_onoff.html Possible fixes * igt@i915_pm_rpm@dpms-mode-unset-lpsp: - shard-skl: [INCOMPLETE][19] ([fdo#107807]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/shard-skl10/igt@i915_pm_...@dpms-mode-unset-lpsp.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12971/shard-skl5/igt@i915_pm_...@dpms-mode-unset-lpsp.html * igt@i915_pm_rpm@i2c: - shard-iclb: [FAIL][21] ([fdo#104097]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/shard-iclb4/igt@i915_pm_...@i2c.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12971/shard-iclb3/igt@i915_pm_...@i2c.html * igt@i915_suspend@sysfs-reader: - shard-apl: [DMESG-WARN][23] ([fdo#108566]) -> [PASS][24] +2 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/shard-apl5/igt@i915_susp...@sysfs-reader.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12971/shard-apl3/igt@i915_susp...@sysfs-reader.html * igt@kms_flip@2x-flip-vs-suspend: - shard-hsw:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: Fix setting 10 bit deep color mode (rev2)
== Series Details == Series: drm/i915/icl: Fix setting 10 bit deep color mode (rev2) URL : https://patchwork.freedesktop.org/series/60080/ State : success == Summary == CI Bug Log - changes from CI_DRM_6051 -> Patchwork_12972 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12972/ Known issues Here are the changes found in Patchwork_12972 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3: - fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12972/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html * igt@i915_selftest@live_contexts: - fi-skl-gvtdvm: [PASS][3] -> [DMESG-FAIL][4] ([fdo#110235]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12972/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html Warnings * igt@i915_selftest@live_hangcheck: - fi-apl-guc: [DMESG-FAIL][5] ([fdo#110620]) -> [INCOMPLETE][6] ([fdo#103927] / [fdo#110624]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/fi-apl-guc/igt@i915_selftest@live_hangcheck.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12972/fi-apl-guc/igt@i915_selftest@live_hangcheck.html * igt@runner@aborted: - fi-apl-guc: [FAIL][7] ([fdo#110622]) -> [FAIL][8] ([fdo#110624]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/fi-apl-guc/igt@run...@aborted.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12972/fi-apl-guc/igt@run...@aborted.html [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 [fdo#110620]: https://bugs.freedesktop.org/show_bug.cgi?id=110620 [fdo#110622]: https://bugs.freedesktop.org/show_bug.cgi?id=110622 [fdo#110624]: https://bugs.freedesktop.org/show_bug.cgi?id=110624 Participating hosts (53 -> 46) -- Additional (1): fi-pnv-d510 Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_6051 -> Patchwork_12972 CI_DRM_6051: fac89f79a454771f6595bcd11d9a119d5acc42d0 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4972: f052e49a43cc9704ea5f240df15dd9d3dfed68ab @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12972: f8f207bb24ae50ed56c49454f224dfd0e940d08b @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == f8f207bb24ae drm/i915/icl: Fix setting 10 bit deep color mode == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12972/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v5][PATCH 11/11] drm/i915: Add intel_color_lut_equal() to compare hw and sw gamma/degamma lut values
On Sat, May 04, 2019 at 10:41:40PM +0530, Swati Sharma wrote:
> v3: Rebase
> v4: -Renamed intel_compare_color_lut() to intel_color_lut_equal() [Jani]
> -Added the default label above the correct label [Jani]
> -Corrected smatch warn "variable dereferenced before check" [Dan
> Carpenter]
> v5: -Added condition (!blob1 && !blob2) return true [Jani]
> -Called PIPE_CONF_CHECK_COLOR_LUT inside if (!adjust) [Jani]
> -Added #undef PIPE_CONF_CHECK_COLOR_LUT [Jani]
>
> There are few things wrong in this patch:
> [1] For chv bit precision is 14, on what basis it should be assigned?
Like everything else it will more or less be a reverse of the
compute side. For CHV we need to look at cgm_mode, gamma_enable,
gamma_mode, and c8_planes. Hmm. We actually don't have readout for
c8_planes so I guess we'll have to make some kind of exception for
that one.
> [2] For glk and icl, degamma LUT values are not rounded off, there
> should err=0 if using same function, how to make that exception?
You mean the degamma? Just set precision==16? Maybe I'm not
understanding the question.
> [3] For glk, bit precision is 10 but gamma mode is 8BIT?
Not sure what you mean. glk gamma_mode works just like with
other ilk+ platforms (apart from not having the csc_mode
gamma vs. degamma control).
I suspect the most annoying case is ivb-bdw 10bit gamma mode
since we probably don't have the full readout to do the reverse
mapping of whether the LUT is used as gamma or degamma. But I
guess we'll just have to compare it against whichever one the
software state has.
>
> Signed-off-by: Swati Sharma
> ---
> drivers/gpu/drm/i915/intel_color.c | 54
>
> drivers/gpu/drm/i915/intel_color.h | 6
> drivers/gpu/drm/i915/intel_display.c | 12
> 3 files changed, 72 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_color.c
> b/drivers/gpu/drm/i915/intel_color.c
> index 695b76d..73cb901 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -1630,6 +1630,60 @@ static void ilk_read_luts(struct intel_crtc_state
> *crtc_state)
> crtc_state->base.gamma_lut = ilk_read_gamma_lut(crtc_state);
> }
>
> +static inline bool err_check(struct drm_color_lut *sw_lut, struct
> drm_color_lut *hw_lut, u32 err)
> +{
> + return ((abs((long)hw_lut->red - sw_lut->red)) <= err) &&
> + ((abs((long)hw_lut->blue - sw_lut->blue)) <= err) &&
> + ((abs((long)hw_lut->green - sw_lut->green)) <= err);
> +}
> +
> +bool intel_color_lut_equal(struct drm_property_blob *blob1,
> +struct drm_property_blob *blob2,
> +u32 gamma_mode)
> +{
> + struct drm_color_lut *sw_lut, *hw_lut;
> + int sw_lut_size, hw_lut_size, i;
> + u32 bit_precision, err;
> +
> + if (!blob1 && !blob2)
> + return true;
> +
> + if (!blob1 || !blob2)
> + return false;
> +
> + sw_lut_size = drm_color_lut_size(blob1);
> + hw_lut_size = drm_color_lut_size(blob2);
> +
> + if (sw_lut_size != hw_lut_size)
> + return false;
> +
> + switch(gamma_mode) {
> + default:
> + case GAMMA_MODE_MODE_8BIT:
> + bit_precision = 8;
> + break;
> + case GAMMA_MODE_MODE_10BIT:
> + case GAMMA_MODE_MODE_SPLIT:
> + bit_precision = 10;
> + break;
> + case GAMMA_MODE_MODE_12BIT:
> + bit_precision = 12;
> + break;
> + }
> +
> + sw_lut = blob1->data;
> + hw_lut = blob2->data;
> +
> + err = 0x >> bit_precision;
> +
> + for (i = 0; i < sw_lut_size; i++) {
> + if (!err_check(_lut[i], _lut[i], err))
> + return false;
> + }
> +
> + return true;
> +}
> +
> void intel_color_init(struct intel_crtc *crtc)
> {
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> diff --git a/drivers/gpu/drm/i915/intel_color.h
> b/drivers/gpu/drm/i915/intel_color.h
> index fc53de9..b525c80 100644
> --- a/drivers/gpu/drm/i915/intel_color.h
> +++ b/drivers/gpu/drm/i915/intel_color.h
> @@ -6,13 +6,19 @@
> #ifndef __INTEL_COLOR_H__
> #define __INTEL_COLOR_H__
>
> +#include
> +
> struct intel_crtc_state;
> struct intel_crtc;
> +struct drm_property_blob;
>
> void intel_color_init(struct intel_crtc *crtc);
> int intel_color_check(struct intel_crtc_state *crtc_state);
> void intel_color_commit(const struct intel_crtc_state *crtc_state);
> void intel_color_load_luts(const struct intel_crtc_state *crtc_state);
> void intel_color_read_luts(struct intel_crtc_state *crtc_state);
> +bool intel_color_lut_equal(struct drm_property_blob *blob1,
> + struct drm_property_blob *blob2,
> + u32 gamma_mode);
>
> #endif /* __INTEL_COLOR_H__ */
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 791974b..a713171 100644
[Intel-gfx] [PATCH v5 00/11] drm/fb-helper: Move modesetting code to drm_client
This moves the modesetting code from drm_fb_helper to drm_client so it
can be shared by all internal clients.
Changes this time:
- Use restore_fbdev_mode_force() in
drm_fb_helper_restore_fbdev_mode_unlocked() to please igt tests. I'm not
currently motivated to learn igt so I have added a todo entry for this.
- Rebase on drm-next (drm_fb_helper and drm_legacy patches)
Noralf.
Noralf Trønnes (11):
drm/atomic: Move __drm_atomic_helper_disable_plane/set_config()
drm/fb-helper: Avoid race with DRM userspace
drm/fb-helper: No need to cache rotation and sw_rotations
drm/fb-helper: Remove drm_fb_helper_crtc->{x,y,desired_mode}
drm/fb-helper: Remove drm_fb_helper_crtc
drm/fb-helper: Prepare to move out commit code
drm/fb-helper: Move out commit code
drm/fb-helper: Remove drm_fb_helper_connector
drm/fb-helper: Prepare to move out modeset config code
drm/fb-helper: Move out modeset config code
drm/client: Hack: Add bootsplash example
Documentation/gpu/drm-client.rst |3 +
Documentation/gpu/todo.rst | 15 +
drivers/gpu/drm/Kconfig |5 +
drivers/gpu/drm/Makefile |3 +-
drivers/gpu/drm/drm_atomic.c | 168
drivers/gpu/drm/drm_atomic_helper.c | 164 ---
drivers/gpu/drm/drm_auth.c | 20 +
drivers/gpu/drm/drm_bootsplash.c | 358 +++
drivers/gpu/drm/drm_client.c | 17 +-
drivers/gpu/drm/drm_client_modeset.c | 1086
drivers/gpu/drm/drm_crtc_internal.h |5 +
drivers/gpu/drm/drm_drv.c|4 +
drivers/gpu/drm/drm_fb_helper.c | 1392 +++---
drivers/gpu/drm/drm_internal.h |2 +
include/drm/drm_atomic_helper.h |4 -
include/drm/drm_client.h | 49 +
include/drm/drm_fb_helper.h | 102 +-
17 files changed, 1876 insertions(+), 1521 deletions(-)
create mode 100644 drivers/gpu/drm/drm_bootsplash.c
create mode 100644 drivers/gpu/drm/drm_client_modeset.c
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 07/11] drm/fb-helper: Move out commit code
Move the modeset commit code to drm_client_modeset.
No changes except exporting API.
v2: Move to drm_client_modeset.c instead of drm_client.c
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_client_modeset.c | 287 +++
drivers/gpu/drm/drm_fb_helper.c | 282 --
include/drm/drm_client.h | 4 +
3 files changed, 291 insertions(+), 282 deletions(-)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index 66770ed3299e..b2aedec65637 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -11,9 +11,14 @@
#include
#include
+#include
#include
#include
#include
+#include
+
+#include "drm_crtc_internal.h"
+#include "drm_internal.h"
int drm_client_modeset_create(struct drm_client_dev *client)
{
@@ -102,3 +107,285 @@ struct drm_mode_set *drm_client_find_modeset(struct
drm_client_dev *client, stru
}
/* TODO: Remove export when modeset code has been moved over */
EXPORT_SYMBOL(drm_client_find_modeset);
+
+/**
+ * drm_client_panel_rotation() - Check panel orientation
+ * @modeset: DRM modeset
+ * @rotation: Returned rotation value
+ *
+ * This function checks if the primary plane in @modeset can hw rotate to match
+ * the panel orientation on its connector.
+ *
+ * Note: Currently only 0 and 180 degrees are supported.
+ *
+ * Return:
+ * True if the plane can do the rotation, false otherwise.
+ */
+bool drm_client_panel_rotation(struct drm_mode_set *modeset, unsigned int
*rotation)
+{
+ struct drm_connector *connector = modeset->connectors[0];
+ struct drm_plane *plane = modeset->crtc->primary;
+ u64 valid_mask = 0;
+ unsigned int i;
+
+ if (!modeset->num_connectors)
+ return false;
+
+ switch (connector->display_info.panel_orientation) {
+ case DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP:
+ *rotation = DRM_MODE_ROTATE_180;
+ break;
+ case DRM_MODE_PANEL_ORIENTATION_LEFT_UP:
+ *rotation = DRM_MODE_ROTATE_90;
+ break;
+ case DRM_MODE_PANEL_ORIENTATION_RIGHT_UP:
+ *rotation = DRM_MODE_ROTATE_270;
+ break;
+ default:
+ *rotation = DRM_MODE_ROTATE_0;
+ }
+
+ /*
+* TODO: support 90 / 270 degree hardware rotation,
+* depending on the hardware this may require the framebuffer
+* to be in a specific tiling format.
+*/
+ if (*rotation != DRM_MODE_ROTATE_180 || !plane->rotation_property)
+ return false;
+
+ for (i = 0; i < plane->rotation_property->num_values; i++)
+ valid_mask |= (1ULL << plane->rotation_property->values[i]);
+
+ if (!(*rotation & valid_mask))
+ return false;
+
+ return true;
+}
+
+static int drm_client_modeset_commit_atomic(struct drm_client_dev *client,
bool active)
+{
+ struct drm_device *dev = client->dev;
+ struct drm_plane_state *plane_state;
+ struct drm_plane *plane;
+ struct drm_atomic_state *state;
+ struct drm_modeset_acquire_ctx ctx;
+ struct drm_mode_set *mode_set;
+ int ret;
+
+ drm_modeset_acquire_init(, 0);
+
+ state = drm_atomic_state_alloc(dev);
+ if (!state) {
+ ret = -ENOMEM;
+ goto out_ctx;
+ }
+
+ state->acquire_ctx =
+retry:
+ drm_for_each_plane(plane, dev) {
+ plane_state = drm_atomic_get_plane_state(state, plane);
+ if (IS_ERR(plane_state)) {
+ ret = PTR_ERR(plane_state);
+ goto out_state;
+ }
+
+ plane_state->rotation = DRM_MODE_ROTATE_0;
+
+ /* disable non-primary: */
+ if (plane->type == DRM_PLANE_TYPE_PRIMARY)
+ continue;
+
+ ret = __drm_atomic_helper_disable_plane(plane, plane_state);
+ if (ret != 0)
+ goto out_state;
+ }
+
+ drm_client_for_each_modeset(mode_set, client) {
+ struct drm_plane *primary = mode_set->crtc->primary;
+ unsigned int rotation;
+
+ if (drm_client_panel_rotation(mode_set, )) {
+ /* Cannot fail as we've already gotten the plane state
above */
+ plane_state = drm_atomic_get_new_plane_state(state,
primary);
+ plane_state->rotation = rotation;
+ }
+
+ ret = __drm_atomic_helper_set_config(mode_set, state);
+ if (ret != 0)
+ goto out_state;
+
+ /*
+* __drm_atomic_helper_set_config() sets active when a
+* mode is set, unconditionally clear it if we force DPMS off
+*/
+ if (!active) {
+ struct drm_crtc *crtc = mode_set->crtc;
+
[Intel-gfx] [PATCH v5 02/11] drm/fb-helper: Avoid race with DRM userspace
drm_fb_helper_is_bound() is used to check if DRM userspace is in control.
This is done by looking at the fb on the primary plane. By the time
fb-helper gets around to committing, it's possible that the facts have
changed.
Avoid this race by holding the drm_device->master_mutex lock while
committing. When DRM userspace does its first open, it will now wait
until fb-helper is done. The helper will stay away if there's a master.
Two igt tests fail with the new 'bail out if master' rule. Work around
this by relaxing this rule for drm_fb_helper_restore_fbdev_mode_unlocked()
until the tests have been fixed. Add todo entry for this.
Locking rule: Always take the fb-helper lock first.
v5: drm_fb_helper_restore_fbdev_mode_unlocked(): Use
restore_fbdev_mode_force()
v2:
- Remove drm_fb_helper_is_bound() (Daniel Vetter)
- No need to check fb_helper->dev->master in
drm_fb_helper_single_fb_probe(), restore_fbdev_mode() has the check.
Suggested-by: Daniel Vetter
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
---
Documentation/gpu/todo.rst | 8 +++
drivers/gpu/drm/drm_auth.c | 20 +++
drivers/gpu/drm/drm_fb_helper.c | 102 ++--
drivers/gpu/drm/drm_internal.h | 2 +
4 files changed, 86 insertions(+), 46 deletions(-)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 06ccff9165d5..66f05f4e469f 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -281,6 +281,14 @@ it to use drm_mode_hsync() instead.
Contact: Sean Paul
+drm_fb_helper tasks
+---
+
+- drm_fb_helper_restore_fbdev_mode_unlocked() should call restore_fbdev_mode()
+ not the _force variant so it can bail out if there is a master. But first
+ these igt tests need to be fixed: kms_fbcon_fbt@psr and
+ kms_fbcon_fbt@psr-suspend.
+
Core refactorings
=
diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index e88151b65c22..33aa459a1b8f 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -353,3 +353,23 @@ void drm_master_put(struct drm_master **master)
*master = NULL;
}
EXPORT_SYMBOL(drm_master_put);
+
+/* Used by drm_client and drm_fb_helper */
+bool drm_master_internal_acquire(struct drm_device *dev)
+{
+ mutex_lock(>master_mutex);
+ if (dev->master) {
+ mutex_unlock(>master_mutex);
+ return false;
+ }
+
+ return true;
+}
+EXPORT_SYMBOL(drm_master_internal_acquire);
+
+/* Used by drm_client and drm_fb_helper */
+void drm_master_internal_release(struct drm_device *dev)
+{
+ mutex_unlock(>master_mutex);
+}
+EXPORT_SYMBOL(drm_master_internal_release);
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 45c5128a783b..6b4ce6060984 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -44,6 +44,7 @@
#include "drm_crtc_internal.h"
#include "drm_crtc_helper_internal.h"
+#include "drm_internal.h"
static bool drm_fbdev_emulation = true;
module_param_named(fbdev_emulation, drm_fbdev_emulation, bool, 0600);
@@ -509,7 +510,7 @@ static int restore_fbdev_mode_legacy(struct drm_fb_helper
*fb_helper)
return ret;
}
-static int restore_fbdev_mode(struct drm_fb_helper *fb_helper)
+static int restore_fbdev_mode_force(struct drm_fb_helper *fb_helper)
{
struct drm_device *dev = fb_helper->dev;
@@ -519,6 +520,21 @@ static int restore_fbdev_mode(struct drm_fb_helper
*fb_helper)
return restore_fbdev_mode_legacy(fb_helper);
}
+static int restore_fbdev_mode(struct drm_fb_helper *fb_helper)
+{
+ struct drm_device *dev = fb_helper->dev;
+ int ret;
+
+ if (!drm_master_internal_acquire(dev))
+ return -EBUSY;
+
+ ret = restore_fbdev_mode_force(fb_helper);
+
+ drm_master_internal_release(dev);
+
+ return ret;
+}
+
/**
* drm_fb_helper_restore_fbdev_mode_unlocked - restore fbdev configuration
* @fb_helper: driver-allocated fbdev helper, can be NULL
@@ -542,7 +558,17 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct
drm_fb_helper *fb_helper)
return 0;
mutex_lock(_helper->lock);
- ret = restore_fbdev_mode(fb_helper);
+ /*
+* TODO:
+* We should bail out here if there is a master by dropping _force.
+* Currently these igt tests fail if we do that:
+* - kms_fbcon_fbt@psr
+* - kms_fbcon_fbt@psr-suspend
+*
+* So first these tests need to be fixed so they drop master or don't
+* have an fd open.
+*/
+ ret = restore_fbdev_mode_force(fb_helper);
do_delayed = fb_helper->delayed_hotplug;
if (do_delayed)
@@ -556,34 +582,6 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct
drm_fb_helper *fb_helper)
}
EXPORT_SYMBOL(drm_fb_helper_restore_fbdev_mode_unlocked);
-static bool drm_fb_helper_is_bound(struct drm_fb_helper *fb_helper)
-{
-
[Intel-gfx] [PATCH v5 08/11] drm/fb-helper: Remove drm_fb_helper_connector
All drivers add all their connectors so there's no need to keep around an
array of available connectors.
Rename functions which signature is changed since they will be moved to
drm_client in a later patch.
Signed-off-by: Noralf Trønnes
---
Documentation/gpu/todo.rst | 4 +
drivers/gpu/drm/drm_fb_helper.c | 498 ++--
include/drm/drm_client.h| 15 +
include/drm/drm_fb_helper.h | 80 ++---
4 files changed, 193 insertions(+), 404 deletions(-)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 9d4038c50013..ab96ba0600a9 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -292,6 +292,10 @@ drm_fb_helper tasks
- The max connector argument for drm_fb_helper_init() and
drm_fb_helper_fbdev_setup() isn't used anymore and can be removed.
+- The helper doesn't keep an array of connectors anymore so these can be
+ removed: drm_fb_helper_single_add_all_connectors(),
+ drm_fb_helper_add_one_connector() and drm_fb_helper_remove_one_connector().
+
Core refactorings
=
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index afb540f56555..ee0af5534f7d 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -90,12 +90,6 @@ static DEFINE_MUTEX(kernel_fb_helper_lock);
* Setup fbdev emulation by calling drm_fb_helper_fbdev_setup() and tear it
* down by calling drm_fb_helper_fbdev_teardown().
*
- * Drivers that need to handle connector hotplugging (e.g. dp mst) can't use
- * the setup helper and will need to do the whole four-step setup process with
- * drm_fb_helper_prepare(), drm_fb_helper_init(),
- * drm_fb_helper_single_add_all_connectors(), enable hotplugging and
- * drm_fb_helper_initial_config() to avoid a possible race window.
- *
* At runtime drivers should restore the fbdev console by using
* drm_fb_helper_lastclose() as their _driver.lastclose callback.
* They should also notify the fb helper code from updates to the output
@@ -118,8 +112,7 @@ static DEFINE_MUTEX(kernel_fb_helper_lock);
* encoders and connectors. To finish up the fbdev helper initialization, the
* drm_fb_helper_init() function is called. To probe for all attached displays
* and set up an initial configuration using the detected hardware, drivers
- * should call drm_fb_helper_single_add_all_connectors() followed by
- * drm_fb_helper_initial_config().
+ * should call drm_fb_helper_initial_config().
*
* If _framebuffer_funcs.dirty is set, the
* drm_fb_helper_{cfb,sys}_{write,fillrect,copyarea,imageblit} functions will
@@ -132,165 +125,6 @@ static DEFINE_MUTEX(kernel_fb_helper_lock);
* deferred I/O (coupled with drm_fb_helper_fbdev_teardown()).
*/
-#define drm_fb_helper_for_each_connector(fbh, i__) \
- for (({ lockdep_assert_held(&(fbh)->lock); }), \
-i__ = 0; i__ < (fbh)->connector_count; i__++)
-
-static int __drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper,
-struct drm_connector *connector)
-{
- struct drm_fb_helper_connector *fb_conn;
- struct drm_fb_helper_connector **temp;
- unsigned int count;
-
- if (!drm_fbdev_emulation)
- return 0;
-
- lockdep_assert_held(_helper->lock);
-
- count = fb_helper->connector_count + 1;
-
- if (count > fb_helper->connector_info_alloc_count) {
- size_t size = count * sizeof(fb_conn);
-
- temp = krealloc(fb_helper->connector_info, size, GFP_KERNEL);
- if (!temp)
- return -ENOMEM;
-
- fb_helper->connector_info_alloc_count = count;
- fb_helper->connector_info = temp;
- }
-
- fb_conn = kzalloc(sizeof(*fb_conn), GFP_KERNEL);
- if (!fb_conn)
- return -ENOMEM;
-
- drm_connector_get(connector);
- fb_conn->connector = connector;
- fb_helper->connector_info[fb_helper->connector_count++] = fb_conn;
-
- return 0;
-}
-
-int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper,
- struct drm_connector *connector)
-{
- int err;
-
- if (!fb_helper)
- return 0;
-
- mutex_lock(_helper->lock);
- err = __drm_fb_helper_add_one_connector(fb_helper, connector);
- mutex_unlock(_helper->lock);
-
- return err;
-}
-EXPORT_SYMBOL(drm_fb_helper_add_one_connector);
-
-/**
- * drm_fb_helper_single_add_all_connectors() - add all connectors to fbdev
- *emulation helper
- * @fb_helper: fbdev initialized with drm_fb_helper_init, can be NULL
- *
- * This functions adds all the available connectors for use with the given
- * fb_helper. This is a separate step to allow drivers to freely assign
- * connectors to the fbdev, e.g. if some are reserved for special purposes or
- * not adequate to be used for the fbcon.
- *
- * This
[Intel-gfx] [PATCH v5 10/11] drm/fb-helper: Move out modeset config code
No functional changes, just moving code as-is and fixing includes.
Signed-off-by: Noralf Trønnes
Reviewed-by: Maxime Ripard
---
drivers/gpu/drm/drm_client_modeset.c | 707 ++-
drivers/gpu/drm/drm_fb_helper.c | 692 --
include/drm/drm_client.h | 5 +-
3 files changed, 702 insertions(+), 702 deletions(-)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index b2aedec65637..e8b5c54d6c05 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -13,13 +13,22 @@
#include
#include
+#include
#include
#include
#include
+#include
+#include
#include "drm_crtc_internal.h"
#include "drm_internal.h"
+#define DRM_CLIENT_MAX_CLONED_CONNECTORS 8
+
+struct drm_client_offset {
+ int x, y;
+};
+
int drm_client_modeset_create(struct drm_client_dev *client)
{
struct drm_device *dev = client->dev;
@@ -58,7 +67,7 @@ int drm_client_modeset_create(struct drm_client_dev *client)
return -ENOMEM;
}
-void drm_client_modeset_release(struct drm_client_dev *client)
+static void drm_client_modeset_release(struct drm_client_dev *client)
{
struct drm_mode_set *modeset;
unsigned int i;
@@ -75,8 +84,6 @@ void drm_client_modeset_release(struct drm_client_dev *client)
modeset->num_connectors = 0;
}
}
-/* TODO: Remove export when modeset code has been moved over */
-EXPORT_SYMBOL(drm_client_modeset_release);
void drm_client_modeset_free(struct drm_client_dev *client)
{
@@ -95,7 +102,8 @@ void drm_client_modeset_free(struct drm_client_dev *client)
kfree(client->modesets);
}
-struct drm_mode_set *drm_client_find_modeset(struct drm_client_dev *client,
struct drm_crtc *crtc)
+static struct drm_mode_set *
+drm_client_find_modeset(struct drm_client_dev *client, struct drm_crtc *crtc)
{
struct drm_mode_set *modeset;
@@ -105,8 +113,695 @@ struct drm_mode_set *drm_client_find_modeset(struct
drm_client_dev *client, stru
return NULL;
}
-/* TODO: Remove export when modeset code has been moved over */
-EXPORT_SYMBOL(drm_client_find_modeset);
+
+static struct drm_display_mode *
+drm_connector_has_preferred_mode(struct drm_connector *connector, int width,
int height)
+{
+ struct drm_display_mode *mode;
+
+ list_for_each_entry(mode, >modes, head) {
+ if (mode->hdisplay > width ||
+ mode->vdisplay > height)
+ continue;
+ if (mode->type & DRM_MODE_TYPE_PREFERRED)
+ return mode;
+ }
+ return NULL;
+}
+
+static struct drm_display_mode *
+drm_connector_pick_cmdline_mode(struct drm_connector *connector)
+{
+ struct drm_cmdline_mode *cmdline_mode;
+ struct drm_display_mode *mode;
+ bool prefer_non_interlace;
+
+ cmdline_mode = >cmdline_mode;
+ if (cmdline_mode->specified == false)
+ return NULL;
+
+ /* attempt to find a matching mode in the list of modes
+* we have gotten so far, if not add a CVT mode that conforms
+*/
+ if (cmdline_mode->rb || cmdline_mode->margins)
+ goto create_mode;
+
+ prefer_non_interlace = !cmdline_mode->interlace;
+again:
+ list_for_each_entry(mode, >modes, head) {
+ /* check width/height */
+ if (mode->hdisplay != cmdline_mode->xres ||
+ mode->vdisplay != cmdline_mode->yres)
+ continue;
+
+ if (cmdline_mode->refresh_specified) {
+ if (mode->vrefresh != cmdline_mode->refresh)
+ continue;
+ }
+
+ if (cmdline_mode->interlace) {
+ if (!(mode->flags & DRM_MODE_FLAG_INTERLACE))
+ continue;
+ } else if (prefer_non_interlace) {
+ if (mode->flags & DRM_MODE_FLAG_INTERLACE)
+ continue;
+ }
+ return mode;
+ }
+
+ if (prefer_non_interlace) {
+ prefer_non_interlace = false;
+ goto again;
+ }
+
+create_mode:
+ mode = drm_mode_create_from_cmdline_mode(connector->dev, cmdline_mode);
+ list_add(>head, >modes);
+
+ return mode;
+}
+
+static bool drm_connector_enabled(struct drm_connector *connector, bool strict)
+{
+ bool enable;
+
+ if (connector->display_info.non_desktop)
+ return false;
+
+ if (strict)
+ enable = connector->status == connector_status_connected;
+ else
+ enable = connector->status != connector_status_disconnected;
+
+ return enable;
+}
+
+static void drm_client_connectors_enabled(struct drm_connector **connectors,
+ unsigned int connector_count,
+
[Intel-gfx] [PATCH v5 04/11] drm/fb-helper: Remove drm_fb_helper_crtc->{x, y, desired_mode}
The values are already present in the modeset.
This is done in preparation for the removal of struct drm_fb_helper_crtc.
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
Reviewed-by: Maxime Ripard
---
drivers/gpu/drm/drm_fb_helper.c | 12
include/drm/drm_fb_helper.h | 2 --
2 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 64650bb2a46b..af2e74c742a4 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2031,16 +2031,16 @@ static int drm_fb_helper_single_fb_probe(struct
drm_fb_helper *fb_helper,
*/
bool lastv = true, lasth = true;
- desired_mode = fb_helper->crtc_info[i].desired_mode;
mode_set = _helper->crtc_info[i].mode_set;
+ desired_mode = mode_set->mode;
if (!desired_mode)
continue;
crtc_count++;
- x = fb_helper->crtc_info[i].x;
- y = fb_helper->crtc_info[i].y;
+ x = mode_set->x;
+ y = mode_set->y;
sizes.surface_width = max_t(u32, desired_mode->hdisplay + x,
sizes.surface_width);
sizes.surface_height = max_t(u32, desired_mode->vdisplay + y,
sizes.surface_height);
@@ -2814,11 +2814,7 @@ static void drm_setup_crtcs(struct drm_fb_helper
*fb_helper,
DRM_DEBUG_KMS("desired mode %s set on crtc %d
(%d,%d)\n",
mode->name,
fb_crtc->mode_set.crtc->base.id, offset->x, offset->y);
- fb_crtc->desired_mode = mode;
- fb_crtc->x = offset->x;
- fb_crtc->y = offset->y;
- modeset->mode = drm_mode_duplicate(dev,
-
fb_crtc->desired_mode);
+ modeset->mode = drm_mode_duplicate(dev, mode);
drm_connector_get(connector);
modeset->connectors[modeset->num_connectors++] =
connector;
modeset->x = offset->x;
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index b0a14aef2e39..2af1c6d3e147 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -49,8 +49,6 @@ struct drm_fb_offset {
struct drm_fb_helper_crtc {
struct drm_mode_set mode_set;
- struct drm_display_mode *desired_mode;
- int x, y;
};
/**
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 01/11] drm/atomic: Move __drm_atomic_helper_disable_plane/set_config()
Prepare for moving drm_fb_helper modesetting code to drm_client.
drm_client will be linked to drm.ko, so move
__drm_atomic_helper_disable_plane() and __drm_atomic_helper_set_config()
out of drm_kms_helper.ko.
While at it, fix two checkpatch complaints:
- WARNING: Block comments use a trailing */ on a separate line
- CHECK: Alignment should match open parenthesis
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
Reviewed-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic.c| 168
drivers/gpu/drm/drm_atomic_helper.c | 164 ---
drivers/gpu/drm/drm_crtc_internal.h | 5 +
include/drm/drm_atomic_helper.h | 4 -
4 files changed, 173 insertions(+), 168 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 5eb40130fafb..c3a9ffbf2310 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1130,6 +1130,174 @@ int drm_atomic_nonblocking_commit(struct
drm_atomic_state *state)
}
EXPORT_SYMBOL(drm_atomic_nonblocking_commit);
+/* just used from drm-client and atomic-helper: */
+int __drm_atomic_helper_disable_plane(struct drm_plane *plane,
+ struct drm_plane_state *plane_state)
+{
+ int ret;
+
+ ret = drm_atomic_set_crtc_for_plane(plane_state, NULL);
+ if (ret != 0)
+ return ret;
+
+ drm_atomic_set_fb_for_plane(plane_state, NULL);
+ plane_state->crtc_x = 0;
+ plane_state->crtc_y = 0;
+ plane_state->crtc_w = 0;
+ plane_state->crtc_h = 0;
+ plane_state->src_x = 0;
+ plane_state->src_y = 0;
+ plane_state->src_w = 0;
+ plane_state->src_h = 0;
+
+ return 0;
+}
+EXPORT_SYMBOL(__drm_atomic_helper_disable_plane);
+
+static int update_output_state(struct drm_atomic_state *state,
+ struct drm_mode_set *set)
+{
+ struct drm_device *dev = set->crtc->dev;
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *new_crtc_state;
+ struct drm_connector *connector;
+ struct drm_connector_state *new_conn_state;
+ int ret, i;
+
+ ret = drm_modeset_lock(>mode_config.connection_mutex,
+ state->acquire_ctx);
+ if (ret)
+ return ret;
+
+ /* First disable all connectors on the target crtc. */
+ ret = drm_atomic_add_affected_connectors(state, set->crtc);
+ if (ret)
+ return ret;
+
+ for_each_new_connector_in_state(state, connector, new_conn_state, i) {
+ if (new_conn_state->crtc == set->crtc) {
+ ret = drm_atomic_set_crtc_for_connector(new_conn_state,
+ NULL);
+ if (ret)
+ return ret;
+
+ /* Make sure legacy setCrtc always re-trains */
+ new_conn_state->link_status = DRM_LINK_STATUS_GOOD;
+ }
+ }
+
+ /* Then set all connectors from set->connectors on the target crtc */
+ for (i = 0; i < set->num_connectors; i++) {
+ new_conn_state = drm_atomic_get_connector_state(state,
+
set->connectors[i]);
+ if (IS_ERR(new_conn_state))
+ return PTR_ERR(new_conn_state);
+
+ ret = drm_atomic_set_crtc_for_connector(new_conn_state,
+ set->crtc);
+ if (ret)
+ return ret;
+ }
+
+ for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
+ /*
+* Don't update ->enable for the CRTC in the set_config request,
+* since a mismatch would indicate a bug in the upper layers.
+* The actual modeset code later on will catch any
+* inconsistencies here.
+*/
+ if (crtc == set->crtc)
+ continue;
+
+ if (!new_crtc_state->connector_mask) {
+ ret = drm_atomic_set_mode_prop_for_crtc(new_crtc_state,
+ NULL);
+ if (ret < 0)
+ return ret;
+
+ new_crtc_state->active = false;
+ }
+ }
+
+ return 0;
+}
+
+/* just used from drm-client and atomic-helper: */
+int __drm_atomic_helper_set_config(struct drm_mode_set *set,
+ struct drm_atomic_state *state)
+{
+ struct drm_crtc_state *crtc_state;
+ struct drm_plane_state *primary_state;
+ struct drm_crtc *crtc = set->crtc;
+ int hdisplay, vdisplay;
+ int ret;
+
+ crtc_state = drm_atomic_get_crtc_state(state, crtc);
+ if (IS_ERR(crtc_state))
+ return PTR_ERR(crtc_state);
+
[Intel-gfx] [PATCH v5 11/11] drm/client: Hack: Add bootsplash example
An example to showcase the client API.
TODO:
- A bootsplash client needs a way to tell drm_fb_helper to stay away,
otherwise it will chime in on setup and hotplug.
Most DRM drivers register fbdev before calling drm_dev_register() (the
generic emulation is an exception). This have to be reversed for
bootsplash to fend off fbdev.
- Probably need some way to determine which is the primary display/device
on multi DRM device systems.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/Kconfig | 5 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/drm_bootsplash.c | 358 +++
drivers/gpu/drm/drm_client.c | 7 +
drivers/gpu/drm/drm_drv.c| 4 +
include/drm/drm_client.h | 3 +
6 files changed, 378 insertions(+)
create mode 100644 drivers/gpu/drm/drm_bootsplash.c
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 2267e84d5cb4..b816ab4d7ecc 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -65,6 +65,11 @@ config DRM_DEBUG_SELFTEST
If in doubt, say "N".
+config DRM_CLIENT_BOOTSPLASH
+ bool "DRM Bootsplash"
+ help
+ DRM Bootsplash
+
config DRM_KMS_HELPER
tristate
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index ae0e8adb2d73..a4b329a831fc 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -31,6 +31,7 @@ drm-$(CONFIG_OF) += drm_of.o
drm-$(CONFIG_AGP) += drm_agpsupport.o
drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
+drm-$(CONFIG_DRM_CLIENT_BOOTSPLASH) += drm_bootsplash.o
drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_dsc.o
drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
diff --git a/drivers/gpu/drm/drm_bootsplash.c b/drivers/gpu/drm/drm_bootsplash.c
new file mode 100644
index ..f58ee19e268f
--- /dev/null
+++ b/drivers/gpu/drm/drm_bootsplash.c
@@ -0,0 +1,358 @@
+/* DRM internal client example */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+// drm_lastclose()
+#include "drm_internal.h"
+
+static bool drm_bootsplash_enabled = true;
+module_param_named(bootsplash_enabled, drm_bootsplash_enabled, bool, 0600);
+MODULE_PARM_DESC(bootsplash_enabled, "Enable bootsplash client
[default=true]");
+
+struct drm_bootsplash {
+ struct drm_client_dev client;
+ struct mutex lock;
+ struct work_struct worker;
+ struct drm_client_buffer *buffers[2];
+ bool started;
+ bool stop;
+};
+
+static bool drm_bootsplash_key_pressed;
+
+static int drm_bootsplash_keyboard_notifier_call(struct notifier_block *blk,
+unsigned long code, void
*_param)
+{
+ /* Any key is good */
+ drm_bootsplash_key_pressed = true;
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block drm_bootsplash_keyboard_notifier_block = {
+ .notifier_call = drm_bootsplash_keyboard_notifier_call,
+};
+
+static void drm_bootsplash_buffer_delete(struct drm_bootsplash *splash)
+{
+ unsigned int i;
+
+ for (i = 0; i < 2; i++) {
+ if (!IS_ERR_OR_NULL(splash->buffers[i]))
+ drm_client_framebuffer_delete(splash->buffers[i]);
+ splash->buffers[i] = NULL;
+ }
+}
+
+static int drm_bootsplash_buffer_create(struct drm_bootsplash *splash, u32
width, u32 height)
+{
+ unsigned int i;
+
+ for (i = 0; i < 2; i++) {
+ splash->buffers[i] =
drm_client_framebuffer_create(>client, width, height,
DRM_FORMAT_XRGB);
+ if (IS_ERR(splash->buffers[i])) {
+ drm_bootsplash_buffer_delete(splash);
+ return PTR_ERR(splash->buffers[i]);
+ }
+ }
+
+ return 0;
+}
+
+static int drm_bootsplash_display_probe(struct drm_bootsplash *splash)
+{
+ struct drm_client_dev *client = >client;
+ unsigned int width = 0, height = 0;
+ unsigned int num_non_tiled = 0, i;
+ unsigned int modeset_mask = 0;
+ struct drm_mode_set *modeset;
+ bool tiled = false;
+ int ret;
+
+ ret = drm_client_modeset_probe(client, 0, 0);
+ if (ret)
+ return ret;
+
+ mutex_lock(>modeset_mutex);
+
+ drm_client_for_each_modeset(modeset, client) {
+ if (!modeset->mode)
+ continue;
+
+ if (modeset->connectors[0]->has_tile)
+ tiled = true;
+ else
+ num_non_tiled++;
+ }
+
+ if (!tiled && !num_non_tiled) {
+ drm_bootsplash_buffer_delete(splash);
+ ret = -ENOENT;
+ goto out;
+ }
+
+ /* Assume only one tiled monitor is possible */
+ if
[Intel-gfx] [PATCH v5 05/11] drm/fb-helper: Remove drm_fb_helper_crtc
It now only contains the modeset so use that directly instead and attach a modeset array to drm_client_dev. drm_fb_helper will use this array. Code will later be moved to drm_client, so add code there in a new file drm_client_modeset.c with MIT license to match drm_fb_helper.c. The modeset connector array size is hardcoded for the cloned case to avoid having to pass in a value from the driver. A value of 8 is chosen to err on the safe side. This means that the max connector argument for drm_fb_helper_init() and drm_fb_helper_fbdev_setup() isn't used anymore, a todo entry for this is added. In pan_display_atomic() restore_fbdev_mode_force() is used instead of restore_fbdev_mode_atomic() because that one will later become internal to drm_client_modeset. Locking order: 1. drm_fb_helper->lock 2. drm_master_internal_acquire 3. drm_client_dev->modeset_mutex v3: - Use full drm_client_init/release for the modesets (Daniel Vetter) - drm_client_for_each_modeset: use lockdep_assert_held (Daniel Vetter) - Hook up to Documentation/gpu/drm-client.rst (Daniel Vetter) v2: - Add modesets array to drm_client (Daniel Vetter) - Use a new file for the modeset code (Daniel Vetter) - File has to be MIT licensed (Emmanuel Vadot) - Add copyrights from drm_fb_helper.c Signed-off-by: Noralf Trønnes --- Documentation/gpu/drm-client.rst | 3 + Documentation/gpu/todo.rst | 3 + drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/drm_client.c | 10 +- drivers/gpu/drm/drm_client_modeset.c | 104 + drivers/gpu/drm/drm_fb_helper.c | 301 +++ include/drm/drm_client.h | 30 +++ include/drm/drm_fb_helper.h | 8 - 8 files changed, 274 insertions(+), 187 deletions(-) create mode 100644 drivers/gpu/drm/drm_client_modeset.c diff --git a/Documentation/gpu/drm-client.rst b/Documentation/gpu/drm-client.rst index 7e672063e7eb..58b5a1d1219d 100644 --- a/Documentation/gpu/drm-client.rst +++ b/Documentation/gpu/drm-client.rst @@ -10,3 +10,6 @@ Kernel clients .. kernel-doc:: drivers/gpu/drm/drm_client.c :export: + +.. kernel-doc:: drivers/gpu/drm/drm_client_modeset.c + :export: diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 66f05f4e469f..9d4038c50013 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -289,6 +289,9 @@ drm_fb_helper tasks these igt tests need to be fixed: kms_fbcon_fbt@psr and kms_fbcon_fbt@psr-suspend. +- The max connector argument for drm_fb_helper_init() and + drm_fb_helper_fbdev_setup() isn't used anymore and can be removed. + Core refactorings = diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 72f5036d9bfa..ae0e8adb2d73 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -17,7 +17,7 @@ drm-y :=drm_auth.o drm_cache.o \ drm_plane.o drm_color_mgmt.o drm_print.o \ drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \ drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \ - drm_atomic_uapi.o + drm_client_modeset.o drm_atomic_uapi.o drm-$(CONFIG_DRM_LEGACY) += drm_legacy_misc.o drm_bufs.o drm_context.o drm_dma.o drm_scatter.o drm_lock.o drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c index f20d1dda3961..3dd08c6b264d 100644 --- a/drivers/gpu/drm/drm_client.c +++ b/drivers/gpu/drm/drm_client.c @@ -27,7 +27,6 @@ * DOC: overview * * This library provides support for clients running in the kernel like fbdev and bootsplash. - * Currently it's only partially implemented, just enough to support fbdev. * * GEM drivers which provide a GEM based dumb buffer with a virtual address are supported. */ @@ -92,14 +91,20 @@ int drm_client_init(struct drm_device *dev, struct drm_client_dev *client, client->name = name; client->funcs = funcs; - ret = drm_client_open(client); + ret = drm_client_modeset_create(client); if (ret) goto err_put_module; + ret = drm_client_open(client); + if (ret) + goto err_free; + drm_dev_get(dev); return 0; +err_free: + drm_client_modeset_free(client); err_put_module: if (funcs) module_put(funcs->owner); @@ -148,6 +153,7 @@ void drm_client_release(struct drm_client_dev *client) DRM_DEV_DEBUG_KMS(dev->dev, "%s\n", client->name); + drm_client_modeset_free(client); drm_client_close(client); drm_dev_put(dev); if (client->funcs) diff --git a/drivers/gpu/drm/drm_client_modeset.c b/drivers/gpu/drm/drm_client_modeset.c new file mode 100644 index ..66770ed3299e --- /dev/null +++ b/drivers/gpu/drm/drm_client_modeset.c @@ -0,0 +1,104 @@ +// SPDX-License-Identifier: MIT +/* + * Copyright 2018 Noralf Trønnes + * Copyright (c) 2006-2009 Red
[Intel-gfx] [PATCH v5 09/11] drm/fb-helper: Prepare to move out modeset config code
This prepares the modeset code so it can be moved out as-is in the next
patch.
v3: Remove stray newline
Signed-off-by: Noralf Trønnes
Reviewed-by: Maxime Ripard
---
drivers/gpu/drm/drm_fb_helper.c | 62 +++--
include/drm/drm_fb_helper.h | 4 ---
2 files changed, 44 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index ee0af5534f7d..802b5036f346 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -43,6 +43,10 @@
#include "drm_internal.h"
+struct drm_client_offset {
+ int x, y;
+};
+
static bool drm_fbdev_emulation = true;
module_param_named(fbdev_emulation, drm_fbdev_emulation, bool, 0600);
MODULE_PARM_DESC(fbdev_emulation,
@@ -1804,7 +1808,7 @@ static bool drm_client_target_cloned(struct drm_device
*dev,
struct drm_connector **connectors,
unsigned int connector_count,
struct drm_display_mode **modes,
-struct drm_fb_offset *offsets,
+struct drm_client_offset *offsets,
bool *enabled, int width, int height)
{
int count, i, j;
@@ -1883,7 +1887,7 @@ static bool drm_client_target_cloned(struct drm_device
*dev,
static int drm_client_get_tile_offsets(struct drm_connector **connectors,
unsigned int connector_count,
struct drm_display_mode **modes,
- struct drm_fb_offset *offsets,
+ struct drm_client_offset *offsets,
int idx,
int h_idx, int v_idx)
{
@@ -1916,7 +1920,7 @@ static int drm_client_get_tile_offsets(struct
drm_connector **connectors,
static bool drm_client_target_preferred(struct drm_connector **connectors,
unsigned int connector_count,
struct drm_display_mode **modes,
- struct drm_fb_offset *offsets,
+ struct drm_client_offset *offsets,
bool *enabled, int width, int height)
{
const u64 mask = BIT_ULL(connector_count) - 1;
@@ -2080,7 +2084,7 @@ static bool drm_client_firmware_config(struct
drm_client_dev *client,
unsigned int connector_count,
struct drm_crtc **crtcs,
struct drm_display_mode **modes,
- struct drm_fb_offset *offsets,
+ struct drm_client_offset *offsets,
bool *enabled, int width, int height)
{
unsigned int count = min_t(unsigned int, connector_count,
BITS_PER_LONG);
@@ -2250,30 +2254,47 @@ static bool drm_client_firmware_config(struct
drm_client_dev *client,
return ret;
}
-static void drm_setup_crtcs(struct drm_fb_helper *fb_helper,
- u32 width, u32 height)
+/**
+ * drm_client_modeset_probe() - Probe for displays
+ * @client: DRM client
+ * @width: Maximum display mode width (optional)
+ * @height: Maximum display mode height (optional)
+ *
+ * This function sets up display pipelines for enabled connectors and stores
the
+ * config in the client's modeset array.
+ *
+ * Returns:
+ * Zero on success or negative error code on failure.
+ */
+int drm_client_modeset_probe(struct drm_client_dev *client, unsigned int
width, unsigned int height)
{
struct drm_connector *connector, **connectors = NULL;
- struct drm_client_dev *client = _helper->client;
struct drm_connector_list_iter conn_iter;
- struct drm_device *dev = fb_helper->dev;
+ struct drm_device *dev = client->dev;
unsigned int total_modes_count = 0;
+ struct drm_client_offset *offsets;
unsigned int connector_count = 0;
struct drm_display_mode **modes;
- struct drm_fb_offset *offsets;
struct drm_crtc **crtcs;
+ int i, ret = 0;
bool *enabled;
- int i;
DRM_DEBUG_KMS("\n");
+ if (!width)
+ width = dev->mode_config.max_width;
+ if (!height)
+ height = dev->mode_config.max_height;
+
drm_connector_list_iter_begin(dev, _iter);
drm_client_for_each_connector_iter(connector, _iter) {
struct drm_connector **tmp;
tmp = krealloc(connectors, (connector_count + 1) *
sizeof(*connectors), GFP_KERNEL);
- if (!tmp)
+ if (!tmp) {
+ ret = -ENOMEM;
goto free_connectors;
+ }
[Intel-gfx] [PATCH v5 06/11] drm/fb-helper: Prepare to move out commit code
This makes the necessary changes so the commit code can be moved out to
drm_client as-is in the next patch. It's split up to ease review.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_helper.c | 122 +---
1 file changed, 81 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 6637858bf530..617e86d010fb 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -388,9 +388,20 @@ int drm_fb_helper_debug_leave(struct fb_info *info)
}
EXPORT_SYMBOL(drm_fb_helper_debug_leave);
-/* Check if the plane can hw rotate to match panel orientation */
-static bool drm_fb_helper_panel_rotation(struct drm_mode_set *modeset,
-unsigned int *rotation)
+/**
+ * drm_client_panel_rotation() - Check panel orientation
+ * @modeset: DRM modeset
+ * @rotation: Returned rotation value
+ *
+ * This function checks if the primary plane in @modeset can hw rotate to match
+ * the panel orientation on its connector.
+ *
+ * Note: Currently only 0 and 180 degrees are supported.
+ *
+ * Return:
+ * True if the plane can do the rotation, false otherwise.
+ */
+bool drm_client_panel_rotation(struct drm_mode_set *modeset, unsigned int
*rotation)
{
struct drm_connector *connector = modeset->connectors[0];
struct drm_plane *plane = modeset->crtc->primary;
@@ -431,10 +442,9 @@ static bool drm_fb_helper_panel_rotation(struct
drm_mode_set *modeset,
return true;
}
-static int restore_fbdev_mode_atomic(struct drm_fb_helper *fb_helper, bool
active)
+static int drm_client_modeset_commit_atomic(struct drm_client_dev *client,
bool active)
{
- struct drm_client_dev *client = _helper->client;
- struct drm_device *dev = fb_helper->dev;
+ struct drm_device *dev = client->dev;
struct drm_plane_state *plane_state;
struct drm_plane *plane;
struct drm_atomic_state *state;
@@ -474,7 +484,7 @@ static int restore_fbdev_mode_atomic(struct drm_fb_helper
*fb_helper, bool activ
struct drm_plane *primary = mode_set->crtc->primary;
unsigned int rotation;
- if (drm_fb_helper_panel_rotation(mode_set, )) {
+ if (drm_client_panel_rotation(mode_set, )) {
/* Cannot fail as we've already gotten the plane state
above */
plane_state = drm_atomic_get_new_plane_state(state,
primary);
plane_state->rotation = rotation;
@@ -516,15 +526,14 @@ static int restore_fbdev_mode_atomic(struct drm_fb_helper
*fb_helper, bool activ
goto retry;
}
-static int restore_fbdev_mode_legacy(struct drm_fb_helper *fb_helper)
+static int drm_client_modeset_commit_legacy(struct drm_client_dev *client)
{
- struct drm_client_dev *client = _helper->client;
- struct drm_device *dev = fb_helper->dev;
+ struct drm_device *dev = client->dev;
struct drm_mode_set *mode_set;
struct drm_plane *plane;
int ret = 0;
- drm_modeset_lock_all(fb_helper->dev);
+ drm_modeset_lock_all(dev);
drm_for_each_plane(plane, dev) {
if (plane->type != DRM_PLANE_TYPE_PRIMARY)
drm_plane_force_disable(plane);
@@ -553,35 +562,53 @@ static int restore_fbdev_mode_legacy(struct drm_fb_helper
*fb_helper)
goto out;
}
out:
- drm_modeset_unlock_all(fb_helper->dev);
+ drm_modeset_unlock_all(dev);
return ret;
}
-static int restore_fbdev_mode_force(struct drm_fb_helper *fb_helper)
+/**
+ * drm_client_modeset_commit_force() - Force commit CRTC configuration
+ * @client: DRM client
+ *
+ * Commit modeset configuration to crtcs without checking if there is a DRM
master.
+ *
+ * Returns:
+ * Zero on success or negative error code on failure.
+ */
+int drm_client_modeset_commit_force(struct drm_client_dev *client)
{
- struct drm_device *dev = fb_helper->dev;
+ struct drm_device *dev = client->dev;
int ret;
- mutex_lock(_helper->client.modeset_mutex);
+ mutex_lock(>modeset_mutex);
if (drm_drv_uses_atomic_modeset(dev))
- ret = restore_fbdev_mode_atomic(fb_helper, true);
+ ret = drm_client_modeset_commit_atomic(client, true);
else
- ret = restore_fbdev_mode_legacy(fb_helper);
- mutex_unlock(_helper->client.modeset_mutex);
+ ret = drm_client_modeset_commit_legacy(client);
+ mutex_unlock(>modeset_mutex);
return ret;
}
-static int restore_fbdev_mode(struct drm_fb_helper *fb_helper)
+/**
+ * drm_client_modeset_commit() - Commit CRTC configuration
+ * @client: DRM client
+ *
+ * Commit modeset configuration to crtcs.
+ *
+ * Returns:
+ * Zero on success or negative error code on failure.
+ */
+int drm_client_modeset_commit(struct drm_client_dev *client)
{
- struct
[Intel-gfx] [PATCH v5 03/11] drm/fb-helper: No need to cache rotation and sw_rotations
Getting rotation info is cheap so we can do it on demand.
This is done in preparation for the removal of struct drm_fb_helper_crtc.
Cc: Hans de Goede
Signed-off-by: Noralf Trønnes
Acked-by: Daniel Vetter
Reviewed-by: Maxime Ripard
---
drivers/gpu/drm/drm_fb_helper.c | 131
include/drm/drm_fb_helper.h | 8 --
2 files changed, 65 insertions(+), 74 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 6b4ce6060984..64650bb2a46b 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -388,6 +388,49 @@ int drm_fb_helper_debug_leave(struct fb_info *info)
}
EXPORT_SYMBOL(drm_fb_helper_debug_leave);
+/* Check if the plane can hw rotate to match panel orientation */
+static bool drm_fb_helper_panel_rotation(struct drm_mode_set *modeset,
+unsigned int *rotation)
+{
+ struct drm_connector *connector = modeset->connectors[0];
+ struct drm_plane *plane = modeset->crtc->primary;
+ u64 valid_mask = 0;
+ unsigned int i;
+
+ if (!modeset->num_connectors)
+ return false;
+
+ switch (connector->display_info.panel_orientation) {
+ case DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP:
+ *rotation = DRM_MODE_ROTATE_180;
+ break;
+ case DRM_MODE_PANEL_ORIENTATION_LEFT_UP:
+ *rotation = DRM_MODE_ROTATE_90;
+ break;
+ case DRM_MODE_PANEL_ORIENTATION_RIGHT_UP:
+ *rotation = DRM_MODE_ROTATE_270;
+ break;
+ default:
+ *rotation = DRM_MODE_ROTATE_0;
+ }
+
+ /*
+* TODO: support 90 / 270 degree hardware rotation,
+* depending on the hardware this may require the framebuffer
+* to be in a specific tiling format.
+*/
+ if (*rotation != DRM_MODE_ROTATE_180 || !plane->rotation_property)
+ return false;
+
+ for (i = 0; i < plane->rotation_property->num_values; i++)
+ valid_mask |= (1ULL << plane->rotation_property->values[i]);
+
+ if (!(*rotation & valid_mask))
+ return false;
+
+ return true;
+}
+
static int restore_fbdev_mode_atomic(struct drm_fb_helper *fb_helper, bool
active)
{
struct drm_device *dev = fb_helper->dev;
@@ -428,10 +471,13 @@ static int restore_fbdev_mode_atomic(struct drm_fb_helper
*fb_helper, bool activ
for (i = 0; i < fb_helper->crtc_count; i++) {
struct drm_mode_set *mode_set =
_helper->crtc_info[i].mode_set;
struct drm_plane *primary = mode_set->crtc->primary;
+ unsigned int rotation;
- /* Cannot fail as we've already gotten the plane state above */
- plane_state = drm_atomic_get_new_plane_state(state, primary);
- plane_state->rotation = fb_helper->crtc_info[i].rotation;
+ if (drm_fb_helper_panel_rotation(mode_set, )) {
+ /* Cannot fail as we've already gotten the plane state
above */
+ plane_state = drm_atomic_get_new_plane_state(state,
primary);
+ plane_state->rotation = rotation;
+ }
ret = __drm_atomic_helper_set_config(mode_set, state);
if (ret != 0)
@@ -881,7 +927,6 @@ int drm_fb_helper_init(struct drm_device *dev,
if (!fb_helper->crtc_info[i].mode_set.connectors)
goto out_free;
fb_helper->crtc_info[i].mode_set.num_connectors = 0;
- fb_helper->crtc_info[i].rotation = DRM_MODE_ROTATE_0;
}
i = 0;
@@ -2510,62 +2555,6 @@ static int drm_pick_crtcs(struct drm_fb_helper
*fb_helper,
return best_score;
}
-/*
- * This function checks if rotation is necessary because of panel orientation
- * and if it is, if it is supported.
- * If rotation is necessary and supported, it gets set in fb_crtc.rotation.
- * If rotation is necessary but not supported, a DRM_MODE_ROTATE_* flag gets
- * or-ed into fb_helper->sw_rotations. In drm_setup_crtcs_fb() we check if only
- * one bit is set and then we set fb_info.fbcon_rotate_hint to make fbcon do
- * the unsupported rotation.
- */
-static void drm_setup_crtc_rotation(struct drm_fb_helper *fb_helper,
- struct drm_fb_helper_crtc *fb_crtc,
- struct drm_connector *connector)
-{
- struct drm_plane *plane = fb_crtc->mode_set.crtc->primary;
- uint64_t valid_mask = 0;
- int i, rotation;
-
- fb_crtc->rotation = DRM_MODE_ROTATE_0;
-
- switch (connector->display_info.panel_orientation) {
- case DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP:
- rotation = DRM_MODE_ROTATE_180;
- break;
- case DRM_MODE_PANEL_ORIENTATION_LEFT_UP:
- rotation = DRM_MODE_ROTATE_90;
- break;
- case
Re: [Intel-gfx] [PATCH v6 03/10] drm: revocation check at drm subsystem
On Thu, May 02, 2019 at 06:52:56PM +0530, Ramalingam C wrote:
> On every hdcp revocation check request SRM is read from fw file
> /lib/firmware/display_hdcp_srm.bin
>
> SRM table is parsed and stored at drm_hdcp.c, with functions exported
> for the services for revocation check from drivers (which
> implements the HDCP authentication)
>
> This patch handles the HDCP1.4 and 2.2 versions of SRM table.
>
> v2:
> moved the uAPI to request_firmware_direct() [Daniel]
> v3:
> kdoc added. [Daniel]
> srm_header unified and bit field definitions are removed. [Daniel]
> locking improved. [Daniel]
> vrl length violation is fixed. [Daniel]
>
> Signed-off-by: Ramalingam C
> Suggested-by: Daniel Vetter
Found a few small details to polish, but looks good to me. With the
details addressed:
Reviewed-by: Daniel Vetter
We also still need an ack on the firmware blob approach from Matt Roper or
someone else at iotg I think.
Cheers, Daniel
> ---
> Documentation/gpu/drm-kms-helpers.rst | 6 +
> drivers/gpu/drm/Makefile | 2 +-
> drivers/gpu/drm/drm_hdcp.c| 342 ++
> drivers/gpu/drm/drm_internal.h| 4 +
> drivers/gpu/drm/drm_sysfs.c | 2 +
> include/drm/drm_hdcp.h| 24 ++
> 6 files changed, 379 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/drm_hdcp.c
>
> diff --git a/Documentation/gpu/drm-kms-helpers.rst
> b/Documentation/gpu/drm-kms-helpers.rst
> index 14102ae035dc..0fe726a6ee67 100644
> --- a/Documentation/gpu/drm-kms-helpers.rst
> +++ b/Documentation/gpu/drm-kms-helpers.rst
> @@ -181,6 +181,12 @@ Panel Helper Reference
> .. kernel-doc:: drivers/gpu/drm/drm_panel_orientation_quirks.c
> :export:
>
> +HDCP Helper Functions Reference
> +===
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_hdcp.c
> + :export:
> +
> Display Port Helper Functions Reference
> ===
>
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 72f5036d9bfa..dd02e9dec810 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -17,7 +17,7 @@ drm-y := drm_auth.o drm_cache.o \
> drm_plane.o drm_color_mgmt.o drm_print.o \
> drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
> drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
> - drm_atomic_uapi.o
> + drm_atomic_uapi.o drm_hdcp.o
>
> drm-$(CONFIG_DRM_LEGACY) += drm_legacy_misc.o drm_bufs.o drm_context.o
> drm_dma.o drm_scatter.o drm_lock.o
> drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
> diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
> new file mode 100644
> index ..dc0e13409221
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_hdcp.c
> @@ -0,0 +1,342 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2019 Intel Corporation.
> + *
> + * Authors:
> + * Ramalingam C
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +
> +struct hdcp_srm {
> + u8 *srm_buf;
Allocated, but seems to not be used.
> + size_t received_srm_sz;
Seems to be unused. Seems to both be leftovers from the sysfs interface.
> + u32 revoked_ksv_cnt;
> + u8 *revoked_ksv_list;
> +
> + /* Mutex to protect above struct member */
> + struct mutex mutex;
> +} *srm_data;
> +
> +static inline void drm_hdcp_print_ksv(const u8 *ksv)
> +{
> + DRM_DEBUG("\t%#02x, %#02x, %#02x, %#02x, %#02x\n",
> + ksv[0], ksv[1], ksv[2], ksv[3], ksv[4]);
> +}
> +
> +static u32 drm_hdcp_get_revoked_ksv_count(const u8 *buf, u32 vrls_length)
> +{
> + u32 parsed_bytes = 0, ksv_count = 0, vrl_ksv_cnt, vrl_sz;
> +
> + while (parsed_bytes < vrls_length) {
> + vrl_ksv_cnt = *buf;
> + ksv_count += vrl_ksv_cnt;
> +
> + vrl_sz = (vrl_ksv_cnt * DRM_HDCP_KSV_LEN) + 1;
> + buf += vrl_sz;
> + parsed_bytes += vrl_sz;
> + }
> +
> + /*
> + * When vrls are not valid, ksvs are not considered.
> + * Hence SRM will be discarded.
> + */
> + if (parsed_bytes != vrls_length)
> + ksv_count = 0;
> +
> + return ksv_count;
> +}
> +
> +static u32 drm_hdcp_get_revoked_ksvs(const u8 *buf, u8 *revoked_ksv_list,
> + u32 vrls_length)
> +{
> + u32 parsed_bytes = 0, ksv_count = 0;
> + u32 vrl_ksv_cnt, vrl_ksv_sz, vrl_idx = 0;
> +
> + do {
> + vrl_ksv_cnt = *buf;
> + vrl_ksv_sz = vrl_ksv_cnt * DRM_HDCP_KSV_LEN;
> +
> + buf++;
> +
> + DRM_DEBUG("vrl: %d, Revoked KSVs: %d\n", vrl_idx++,
> + vrl_ksv_cnt);
> + memcpy(revoked_ksv_list, buf, vrl_ksv_sz);
> +
> + ksv_count += vrl_ksv_cnt;
> + revoked_ksv_list += vrl_ksv_sz;
> + buf
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: add force_probe module parameter to replace alpha_support
== Series Details == Series: drm/i915: add force_probe module parameter to replace alpha_support URL : https://patchwork.freedesktop.org/series/60322/ State : success == Summary == CI Bug Log - changes from CI_DRM_6050_full -> Patchwork_12970_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12970_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@vecs0-s3: - shard-skl: [PASS][1] -> [INCOMPLETE][2] ([fdo#104108] / [fdo#107773]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6050/shard-skl2/igt@gem_ctx_isolat...@vecs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12970/shard-skl6/igt@gem_ctx_isolat...@vecs0-s3.html * igt@gem_pwrite@small-gtt-random: - shard-apl: [PASS][3] -> [INCOMPLETE][4] ([fdo#103927]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6050/shard-apl6/igt@gem_pwr...@small-gtt-random.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12970/shard-apl2/igt@gem_pwr...@small-gtt-random.html * igt@i915_pm_rpm@i2c: - shard-iclb: [PASS][5] -> [FAIL][6] ([fdo#104097]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6050/shard-iclb1/igt@i915_pm_...@i2c.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12970/shard-iclb6/igt@i915_pm_...@i2c.html * igt@i915_pm_rpm@system-suspend-execbuf: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([fdo#104108] / [fdo#107773] / [fdo#107807]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6050/shard-skl3/igt@i915_pm_...@system-suspend-execbuf.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12970/shard-skl9/igt@i915_pm_...@system-suspend-execbuf.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: - shard-hsw: [PASS][9] -> [FAIL][10] ([fdo#105767]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6050/shard-hsw2/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12970/shard-hsw6/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html * igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: - shard-glk: [PASS][11] -> [FAIL][12] ([fdo#106509] / [fdo#107409]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6050/shard-glk8/igt@kms_cursor_leg...@2x-nonblocking-modeset-vs-cursor-atomic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12970/shard-glk7/igt@kms_cursor_leg...@2x-nonblocking-modeset-vs-cursor-atomic.html * igt@kms_flip@flip-vs-suspend: - shard-skl: [PASS][13] -> [INCOMPLETE][14] ([fdo#109507]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6050/shard-skl3/igt@kms_f...@flip-vs-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12970/shard-skl8/igt@kms_f...@flip-vs-suspend.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([fdo#108566]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6050/shard-apl5/igt@kms_frontbuffer_track...@fbc-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12970/shard-apl8/igt@kms_frontbuffer_track...@fbc-suspend.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-render: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103167]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6050/shard-iclb3/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-shrfb-draw-render.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12970/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-shrfb-draw-render.html * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#108145]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6050/shard-skl4/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12970/shard-skl9/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145] / [fdo#110403]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6050/shard-skl4/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12970/shard-skl6/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_plane_scaling@pipe-a-scaler-with-clipping-clamping: - shard-glk: [PASS][23] -> [SKIP][24] ([fdo#109271] / [fdo#109278]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6050/shard-glk9/igt@kms_plane_scal...@pipe-a-scaler-with-clipping-clamping.html [24]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Kill PCH_KBP
== Series Details == Series: drm/i915: Kill PCH_KBP URL : https://patchwork.freedesktop.org/series/60327/ State : success == Summary == CI Bug Log - changes from CI_DRM_6051 -> Patchwork_12971 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12971/ Known issues Here are the changes found in Patchwork_12971 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@userptr: - fi-kbl-8809g: [PASS][1] -> [DMESG-WARN][2] ([fdo#108965]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12971/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html * igt@i915_selftest@live_evict: - fi-bsw-kefka: [PASS][3] -> [DMESG-WARN][4] ([fdo#107709]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/fi-bsw-kefka/igt@i915_selftest@live_evict.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12971/fi-bsw-kefka/igt@i915_selftest@live_evict.html Possible fixes * igt@i915_selftest@live_hangcheck: - fi-icl-y: [INCOMPLETE][5] ([fdo#107713] / [fdo#108569]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6051/fi-icl-y/igt@i915_selftest@live_hangcheck.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12971/fi-icl-y/igt@i915_selftest@live_hangcheck.html [fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 [fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965 Participating hosts (53 -> 45) -- Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_6051 -> Patchwork_12971 CI_DRM_6051: fac89f79a454771f6595bcd11d9a119d5acc42d0 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4972: f052e49a43cc9704ea5f240df15dd9d3dfed68ab @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12971: 58342517e1cf730a1e24263373fe33a2fe511247 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 58342517e1cf drm/i915: Kill PCH_KBP == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12971/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 0/5] cgroup support for GPU devices
Hello, On Wed, May 01, 2019 at 10:04:33AM -0400, Brian Welty wrote: > The patch series enables device drivers to use cgroups to control the > following resources within a GPU (or other accelerator device): > * control allocation of device memory (reuse of memcg) > and with future work, we could extend to: > * track and control share of GPU time (reuse of cpu/cpuacct) > * apply mask of allowed execution engines (reuse of cpusets) > > Instead of introducing a new cgroup subsystem for GPU devices, a new > framework is proposed to allow devices to register with existing cgroup > controllers, which creates per-device cgroup_subsys_state within the > cgroup. This gives device drivers their own private cgroup controls > (such as memory limits or other parameters) to be applied to device > resources instead of host system resources. > Device drivers (GPU or other) are then able to reuse the existing cgroup > controls, instead of inventing similar ones. I'm really skeptical about this approach. When creating resource controllers, I think what's the most important and challenging is establishing resource model - what resources are and how they can be distributed. This patchset is going the other way around - building out core infrastructure for bolierplates at a significant risk of mixing up resource models across different types of resources. IO controllers already implement per-device controls. I'd suggest following the same interface conventions and implementing a dedicated controller for the subsystem. Thanks. -- tejun ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Kill PCH_KBP
From: Ville Syrjälä
For us KBP is 100% identical to SPT. Kill the redundant enum
value. Also bspec doesn't talk about KBP either, so this might
avoid some confusion when cross checking the code against the
spec.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c| 3 ++-
drivers/gpu/drm/i915/i915_drv.h| 4 +---
drivers/gpu/drm/i915/intel_gmbus.c | 6 ++
3 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 5ed864752c7b..2c7a4318d13c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -195,7 +195,8 @@ intel_pch_type(const struct drm_i915_private *dev_priv,
unsigned short id)
DRM_DEBUG_KMS("Found Kaby Lake PCH (KBP)\n");
WARN_ON(!IS_SKYLAKE(dev_priv) && !IS_KABYLAKE(dev_priv) &&
!IS_COFFEELAKE(dev_priv));
- return PCH_KBP;
+ /* KBP is SPT compatible */
+ return PCH_SPT;
case INTEL_PCH_CNP_DEVICE_ID_TYPE:
DRM_DEBUG_KMS("Found Cannon Lake PCH (CNP)\n");
WARN_ON(!IS_CANNONLAKE(dev_priv) && !IS_COFFEELAKE(dev_priv));
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 64fa353a62bb..9321595aaf96 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -532,8 +532,7 @@ enum intel_pch {
PCH_IBX,/* Ibexpeak PCH */
PCH_CPT,/* Cougarpoint/Pantherpoint PCH */
PCH_LPT,/* Lynxpoint/Wildcatpoint PCH */
- PCH_SPT,/* Sunrisepoint PCH */
- PCH_KBP,/* Kaby Lake PCH */
+ PCH_SPT,/* Sunrisepoint/Kaby Lake PCH */
PCH_CNP,/* Cannon/Comet Lake PCH */
PCH_ICP,/* Ice Lake PCH */
};
@@ -2629,7 +2628,6 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define INTEL_PCH_ID(dev_priv) ((dev_priv)->pch_id)
#define HAS_PCH_ICP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_ICP)
#define HAS_PCH_CNP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_CNP)
-#define HAS_PCH_KBP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_KBP)
#define HAS_PCH_SPT(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_SPT)
#define HAS_PCH_LPT(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_LPT)
#define HAS_PCH_LPT_LP(dev_priv) \
diff --git a/drivers/gpu/drm/i915/intel_gmbus.c
b/drivers/gpu/drm/i915/intel_gmbus.c
index 8c36a06bda3f..969ce8b71e32 100644
--- a/drivers/gpu/drm/i915/intel_gmbus.c
+++ b/drivers/gpu/drm/i915/intel_gmbus.c
@@ -581,8 +581,7 @@ do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg
*msgs, int num,
/* Display WA #0868: skl,bxt,kbl,cfl,glk,cnl */
if (IS_GEN9_LP(dev_priv))
bxt_gmbus_clock_gating(dev_priv, false);
- else if (HAS_PCH_SPT(dev_priv) ||
-HAS_PCH_KBP(dev_priv) || HAS_PCH_CNP(dev_priv))
+ else if (HAS_PCH_SPT(dev_priv) || HAS_PCH_CNP(dev_priv))
pch_gmbus_clock_gating(dev_priv, false);
retry:
@@ -691,8 +690,7 @@ do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg
*msgs, int num,
/* Display WA #0868: skl,bxt,kbl,cfl,glk,cnl */
if (IS_GEN9_LP(dev_priv))
bxt_gmbus_clock_gating(dev_priv, true);
- else if (HAS_PCH_SPT(dev_priv) ||
-HAS_PCH_KBP(dev_priv) || HAS_PCH_CNP(dev_priv))
+ else if (HAS_PCH_SPT(dev_priv) || HAS_PCH_CNP(dev_priv))
pch_gmbus_clock_gating(dev_priv, true);
return ret;
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 0/5] cgroup support for GPU devices
On Wed, May 01, 2019 at 10:04:33AM -0400, Brian Welty wrote: > In containerized or virtualized environments, there is desire to have > controls in place for resources that can be consumed by users of a GPU > device. This RFC patch series proposes a framework for integrating > use of existing cgroup controllers into device drivers. > The i915 driver is updated in this series as our primary use case to > leverage this framework and to serve as an example for discussion. > > The patch series enables device drivers to use cgroups to control the > following resources within a GPU (or other accelerator device): > * control allocation of device memory (reuse of memcg) > and with future work, we could extend to: > * track and control share of GPU time (reuse of cpu/cpuacct) > * apply mask of allowed execution engines (reuse of cpusets) Please create a separate controller for your purposes. The memory controller is for traditional RAM. I don't see it having much in common with what you're trying to do, and it's barely reusing any of the memcg code. You can use the page_counter API directly. > Instead of introducing a new cgroup subsystem for GPU devices, a new > framework is proposed to allow devices to register with existing cgroup > controllers, which creates per-device cgroup_subsys_state within the > cgroup. This gives device drivers their own private cgroup controls > (such as memory limits or other parameters) to be applied to device > resources instead of host system resources. > Device drivers (GPU or other) are then able to reuse the existing cgroup > controls, instead of inventing similar ones. > > Per-device controls would be exposed in cgroup filesystem as: > mount//.devices// > such as (for example): > mount//memory.devices//memory.max > mount//memory.devices//memory.current > mount//cpu.devices//cpu.stat > mount//cpu.devices//cpu.weight Subdirectories for anything other than actual cgroups are a no-go. If you need a hierarchy, use dotted filenames: gpu.memory.max gpu.cycles.max etc. and look at Documentation/admin-guide/cgroup-v2.rst's 'Format' and 'Conventions', as well as how the io controller works, to see how multi-key / multi-device control files are implemented in cgroup2. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: add force_probe module parameter to replace alpha_support
== Series Details ==
Series: drm/i915: add force_probe module parameter to replace alpha_support
URL : https://patchwork.freedesktop.org/series/60322/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6050 -> Patchwork_12970
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12970/
Known issues
Here are the changes found in Patchwork_12970 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6050/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12970/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
* igt@i915_selftest@live_contexts:
- fi-bdw-gvtdvm: [PASS][3] -> [DMESG-FAIL][4] ([fdo#110235])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6050/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12970/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
* igt@i915_selftest@live_execlists:
- fi-apl-guc: [PASS][5] -> [INCOMPLETE][6] ([fdo#103927] /
[fdo#109720])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6050/fi-apl-guc/igt@i915_selftest@live_execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12970/fi-apl-guc/igt@i915_selftest@live_execlists.html
* igt@i915_selftest@live_hangcheck:
- fi-icl-y: [PASS][7] -> [INCOMPLETE][8] ([fdo#107713] /
[fdo#108569])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6050/fi-icl-y/igt@i915_selftest@live_hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12970/fi-icl-y/igt@i915_selftest@live_hangcheck.html
Possible fixes
* igt@i915_selftest@live_hangcheck:
- fi-apl-guc: [DMESG-FAIL][9] ([fdo#110620]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6050/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12970/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
Warnings
* igt@runner@aborted:
- fi-apl-guc: [FAIL][11] ([fdo#110622]) -> [FAIL][12] ([fdo#108622]
/ [fdo#109720])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6050/fi-apl-guc/igt@run...@aborted.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12970/fi-apl-guc/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
[fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720
[fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235
[fdo#110390]: https://bugs.freedesktop.org/show_bug.cgi?id=110390
[fdo#110620]: https://bugs.freedesktop.org/show_bug.cgi?id=110620
[fdo#110622]: https://bugs.freedesktop.org/show_bug.cgi?id=110622
Participating hosts (54 -> 45)
--
Missing(9): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600 fi-gdg-551 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6050 -> Patchwork_12970
CI_DRM_6050: 79f967620fe91fad840b71a0df86bbb45f9f70a3 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4972: f052e49a43cc9704ea5f240df15dd9d3dfed68ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12970: 02407cb016796a2fa1bdc850a388cfdbd22e0d17 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
02407cb01679 drm/i915: add force_probe module parameter to replace alpha_support
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12970/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v5][PATCH 01/11] drm/i915: Introduce vfunc read_luts() to create hw lut
On 06-May-19 7:11 PM, Jani Nikula wrote:
On Mon, 06 May 2019, Ville Syrjälä wrote:
On Mon, May 06, 2019 at 04:21:07PM +0300, Jani Nikula wrote:
On Sat, 04 May 2019, Swati Sharma wrote:
In this patch, a vfunc read_luts() is introduced to create a hw lut
i.e. lut having values read from gamma/degamma registers which will
later be used to compare with sw lut to validate gamma/degamma lut values.
v3: -Rebase
v4: -Renamed intel_get_color_config to intel_color_get_config [Jani]
-Wrapped get_color_config() [Jani]
v5: -Renamed intel_color_get_config() to intel_color_read_luts()
Ville, did you really want this chage? I sure didn't.
I want the low level funcs to be called something like
ilk_read_lut_10(), chv_read_cgm_gamma_lut(), etc.
The name of the vfunc is more of a meh.
And I don't care about the low level functions so much, I care about the
interface which I should emphasize the "get config" stage. :)
Sure, will do that.But my major concerns are in patch 11 :/ Please review and
guide.
Also, on CI tests are getting aborted..don't know why. Locally it's OK.
Debugging.
BR,
Jani.
BR,
Jani.
-Renamed get_color_config to read_luts
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i915/i915_drv.h| 1 +
drivers/gpu/drm/i915/intel_color.c | 8
drivers/gpu/drm/i915/intel_color.h | 1 +
3 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1cea98f..1b6d891 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -342,6 +342,7 @@ struct drm_i915_display_funcs {
* involved with the same commit.
*/
void (*load_luts)(const struct intel_crtc_state *crtc_state);
+ void (*read_luts)(struct intel_crtc_state *crtc_state);
};
#define CSR_VERSION(major, minor) ((major) << 16 | (minor))
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 962db12..0048d8a 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -879,6 +879,14 @@ int intel_color_check(struct intel_crtc_state *crtc_state)
return dev_priv->display.color_check(crtc_state);
}
+void intel_color_read_luts(struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
+
+ if (dev_priv->display.read_luts)
+ dev_priv->display.read_luts(crtc_state);
+}
+
static bool need_plane_update(struct intel_plane *plane,
const struct intel_crtc_state *crtc_state)
{
diff --git a/drivers/gpu/drm/i915/intel_color.h
b/drivers/gpu/drm/i915/intel_color.h
index b8a3ce6..fc53de9 100644
--- a/drivers/gpu/drm/i915/intel_color.h
+++ b/drivers/gpu/drm/i915/intel_color.h
@@ -13,5 +13,6 @@
int intel_color_check(struct intel_crtc_state *crtc_state);
void intel_color_commit(const struct intel_crtc_state *crtc_state);
void intel_color_load_luts(const struct intel_crtc_state *crtc_state);
+void intel_color_read_luts(struct intel_crtc_state *crtc_state);
#endif /* __INTEL_COLOR_H__ */
--
Jani Nikula, Intel Open Source Graphics Center
--
~Swati Sharma
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: add force_probe module parameter to replace alpha_support
== Series Details == Series: drm/i915: add force_probe module parameter to replace alpha_support URL : https://patchwork.freedesktop.org/series/60322/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: add force_probe module parameter to replace alpha_support + +Error in reading or end of file. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: add force_probe module parameter to replace alpha_support
== Series Details ==
Series: drm/i915: add force_probe module parameter to replace alpha_support
URL : https://patchwork.freedesktop.org/series/60322/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
02407cb01679 drm/i915: add force_probe module parameter to replace alpha_support
-:94: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#94: FILE: drivers/gpu/drm/i915/i915_params.c:91:
+i915_param_named_unsafe(force_probe, charp, 0400,
+ "Force probe the driver for specified devices. "
-:141: WARNING:EMBEDDED_FUNCTION_NAME: Prefer using '"%s...", __func__' to
using 'force_probe', this function's name, in a string
#141: FILE: drivers/gpu/drm/i915/i915_pci.c:866:
+ DRM_INFO("i915.alpha_support is deprecated, use
i915.force_probe=%04x instead\n",
total: 0 errors, 1 warnings, 1 checks, 144 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: add force_probe module parameter to replace alpha_support
The i915.alpha_support module parameter has caused some confusion along the way. Add new i915.force_probe parameter to specify PCI IDs of devices to probe, when the devices are recognized but not automatically probed by the driver. The name is intended to reflect what the parameter effectively does, avoiding any overloaded semantics of "alpha" and "support". The parameter supports "" to disable, ",[,...]" to enable force probe for one or more devices, and "*" to enable force probe for all known devices. Also add new CONFIG_DRM_I915_FORCE_PROBE config option to replace the DRM_I915_ALPHA_SUPPORT option. This defaults to "*" if DRM_I915_ALPHA_SUPPORT=y. Instead of replacing i915.alpha_support immediately, let the two coexist for a while, with a deprecation message, for a transition period. Cc: Joonas Lahtinen Cc: Rodrigo Vivi Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/Kconfig | 29 +- drivers/gpu/drm/i915/i915_drv.h | 2 - drivers/gpu/drm/i915/i915_params.c | 7 +++- drivers/gpu/drm/i915/i915_params.h | 1 + drivers/gpu/drm/i915/i915_pci.c | 51 +--- drivers/gpu/drm/i915/intel_device_info.h | 2 +- 6 files changed, 72 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index f05563..e7b617 100644 --- a/drivers/gpu/drm/i915/Kconfig +++ b/drivers/gpu/drm/i915/Kconfig @@ -45,19 +45,28 @@ config DRM_I915 config DRM_I915_ALPHA_SUPPORT bool "Enable alpha quality support for new Intel hardware by default" depends on DRM_I915 - default n help - Choose this option if you have new Intel hardware and want to enable - the alpha quality i915 driver support for the hardware in this kernel - version. You can also enable the support at runtime using the module - parameter i915.alpha_support=1; this option changes the default for - that module parameter. + This option is deprecated. Use DRM_I915_FORCE_PROBE option instead. - It is recommended to upgrade to a kernel version with proper support - as soon as it is available. Generally fixes for platforms with alpha - support are not backported to older kernels. +config DRM_I915_FORCE_PROBE + string "Force probe driver for selected new Intel hardware" + depends on DRM_I915 + default "*" if DRM_I915_ALPHA_SUPPORT + help + This is the default value for the i915.force_probe module + parameter. Using the module parameter overrides this option. - If in doubt, say "N". + Force probe the driver for new Intel graphics devices that are + recognized but not properly supported by this kernel version. It is + recommended to upgrade to a kernel version with proper support as soon + as it is available. + + Use "" to disable force probe. If in doubt, use this. + + Use "[,,...]" to force probe the driver for listed + devices. For example, "4500" or "4500,4571". + + Use "*" to force probe the driver for all known devices. config DRM_I915_CAPTURE_ERROR bool "Enable capturing GPU state following a hang" diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 64fa35..04415d 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -2435,8 +2435,6 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, #define IS_ICL_WITH_PORT_F(dev_priv) \ IS_SUBPLATFORM(dev_priv, INTEL_ICELAKE, INTEL_SUBPLATFORM_PORTF) -#define IS_ALPHA_SUPPORT(intel_info) ((intel_info)->is_alpha_support) - #define SKL_REVID_A0 0x0 #define SKL_REVID_B0 0x1 #define SKL_REVID_C0 0x2 diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c index b5be0a..5b0776 100644 --- a/drivers/gpu/drm/i915/i915_params.c +++ b/drivers/gpu/drm/i915/i915_params.c @@ -87,9 +87,12 @@ i915_param_named_unsafe(enable_psr, int, 0600, "(0=disabled, 1=enabled) " "Default: -1 (use per-chip default)"); +i915_param_named_unsafe(force_probe, charp, 0400, + "Force probe the driver for specified devices. " + "See CONFIG_DRM_I915_FORCE_PROBE for details."); + i915_param_named_unsafe(alpha_support, bool, 0400, - "Enable alpha quality driver support for latest hardware. " - "See also CONFIG_DRM_I915_ALPHA_SUPPORT."); + "Deprecated. See i915.force_probe."); i915_param_named_unsafe(disable_power_well, int, 0400, "Disable display power wells when possible " diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index 3f14e9..a2bacd0 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -64,6 +64,7 @@ struct drm_printer; param(int, reset, 2) \ param(unsigned int, inject_load_failure, 0) \ param(int, fastboot, -1) \ +
Re: [Intel-gfx] [v5][PATCH 01/11] drm/i915: Introduce vfunc read_luts() to create hw lut
On Mon, 06 May 2019, Ville Syrjälä wrote:
> On Mon, May 06, 2019 at 04:21:07PM +0300, Jani Nikula wrote:
>> On Sat, 04 May 2019, Swati Sharma wrote:
>> > In this patch, a vfunc read_luts() is introduced to create a hw lut
>> > i.e. lut having values read from gamma/degamma registers which will
>> > later be used to compare with sw lut to validate gamma/degamma lut values.
>> >
>> > v3: -Rebase
>> > v4: -Renamed intel_get_color_config to intel_color_get_config [Jani]
>> > -Wrapped get_color_config() [Jani]
>> > v5: -Renamed intel_color_get_config() to intel_color_read_luts()
>>
>> Ville, did you really want this chage? I sure didn't.
>
> I want the low level funcs to be called something like
> ilk_read_lut_10(), chv_read_cgm_gamma_lut(), etc.
> The name of the vfunc is more of a meh.
And I don't care about the low level functions so much, I care about the
interface which I should emphasize the "get config" stage. :)
BR,
Jani.
>
>>
>> BR,
>> Jani.
>>
>>
>> > -Renamed get_color_config to read_luts
>> >
>> > Signed-off-by: Swati Sharma
>> > ---
>> > drivers/gpu/drm/i915/i915_drv.h| 1 +
>> > drivers/gpu/drm/i915/intel_color.c | 8
>> > drivers/gpu/drm/i915/intel_color.h | 1 +
>> > 3 files changed, 10 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> > b/drivers/gpu/drm/i915/i915_drv.h
>> > index 1cea98f..1b6d891 100644
>> > --- a/drivers/gpu/drm/i915/i915_drv.h
>> > +++ b/drivers/gpu/drm/i915/i915_drv.h
>> > @@ -342,6 +342,7 @@ struct drm_i915_display_funcs {
>> > * involved with the same commit.
>> > */
>> >void (*load_luts)(const struct intel_crtc_state *crtc_state);
>> > + void (*read_luts)(struct intel_crtc_state *crtc_state);
>> > };
>> >
>> > #define CSR_VERSION(major, minor) ((major) << 16 | (minor))
>> > diff --git a/drivers/gpu/drm/i915/intel_color.c
>> > b/drivers/gpu/drm/i915/intel_color.c
>> > index 962db12..0048d8a 100644
>> > --- a/drivers/gpu/drm/i915/intel_color.c
>> > +++ b/drivers/gpu/drm/i915/intel_color.c
>> > @@ -879,6 +879,14 @@ int intel_color_check(struct intel_crtc_state
>> > *crtc_state)
>> >return dev_priv->display.color_check(crtc_state);
>> > }
>> >
>> > +void intel_color_read_luts(struct intel_crtc_state *crtc_state)
>> > +{
>> > + struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
>> > +
>> > + if (dev_priv->display.read_luts)
>> > + dev_priv->display.read_luts(crtc_state);
>> > +}
>> > +
>> > static bool need_plane_update(struct intel_plane *plane,
>> > const struct intel_crtc_state *crtc_state)
>> > {
>> > diff --git a/drivers/gpu/drm/i915/intel_color.h
>> > b/drivers/gpu/drm/i915/intel_color.h
>> > index b8a3ce6..fc53de9 100644
>> > --- a/drivers/gpu/drm/i915/intel_color.h
>> > +++ b/drivers/gpu/drm/i915/intel_color.h
>> > @@ -13,5 +13,6 @@
>> > int intel_color_check(struct intel_crtc_state *crtc_state);
>> > void intel_color_commit(const struct intel_crtc_state *crtc_state);
>> > void intel_color_load_luts(const struct intel_crtc_state *crtc_state);
>> > +void intel_color_read_luts(struct intel_crtc_state *crtc_state);
>> >
>> > #endif /* __INTEL_COLOR_H__ */
>>
>> --
>> Jani Nikula, Intel Open Source Graphics Center
--
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] [v5][PATCH 01/11] drm/i915: Introduce vfunc read_luts() to create hw lut
On Mon, May 06, 2019 at 04:21:07PM +0300, Jani Nikula wrote:
> On Sat, 04 May 2019, Swati Sharma wrote:
> > In this patch, a vfunc read_luts() is introduced to create a hw lut
> > i.e. lut having values read from gamma/degamma registers which will
> > later be used to compare with sw lut to validate gamma/degamma lut values.
> >
> > v3: -Rebase
> > v4: -Renamed intel_get_color_config to intel_color_get_config [Jani]
> > -Wrapped get_color_config() [Jani]
> > v5: -Renamed intel_color_get_config() to intel_color_read_luts()
>
> Ville, did you really want this chage? I sure didn't.
I want the low level funcs to be called something like
ilk_read_lut_10(), chv_read_cgm_gamma_lut(), etc.
The name of the vfunc is more of a meh.
>
> BR,
> Jani.
>
>
> > -Renamed get_color_config to read_luts
> >
> > Signed-off-by: Swati Sharma
> > ---
> > drivers/gpu/drm/i915/i915_drv.h| 1 +
> > drivers/gpu/drm/i915/intel_color.c | 8
> > drivers/gpu/drm/i915/intel_color.h | 1 +
> > 3 files changed, 10 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 1cea98f..1b6d891 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -342,6 +342,7 @@ struct drm_i915_display_funcs {
> > * involved with the same commit.
> > */
> > void (*load_luts)(const struct intel_crtc_state *crtc_state);
> > + void (*read_luts)(struct intel_crtc_state *crtc_state);
> > };
> >
> > #define CSR_VERSION(major, minor) ((major) << 16 | (minor))
> > diff --git a/drivers/gpu/drm/i915/intel_color.c
> > b/drivers/gpu/drm/i915/intel_color.c
> > index 962db12..0048d8a 100644
> > --- a/drivers/gpu/drm/i915/intel_color.c
> > +++ b/drivers/gpu/drm/i915/intel_color.c
> > @@ -879,6 +879,14 @@ int intel_color_check(struct intel_crtc_state
> > *crtc_state)
> > return dev_priv->display.color_check(crtc_state);
> > }
> >
> > +void intel_color_read_luts(struct intel_crtc_state *crtc_state)
> > +{
> > + struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
> > +
> > + if (dev_priv->display.read_luts)
> > + dev_priv->display.read_luts(crtc_state);
> > +}
> > +
> > static bool need_plane_update(struct intel_plane *plane,
> > const struct intel_crtc_state *crtc_state)
> > {
> > diff --git a/drivers/gpu/drm/i915/intel_color.h
> > b/drivers/gpu/drm/i915/intel_color.h
> > index b8a3ce6..fc53de9 100644
> > --- a/drivers/gpu/drm/i915/intel_color.h
> > +++ b/drivers/gpu/drm/i915/intel_color.h
> > @@ -13,5 +13,6 @@
> > int intel_color_check(struct intel_crtc_state *crtc_state);
> > void intel_color_commit(const struct intel_crtc_state *crtc_state);
> > void intel_color_load_luts(const struct intel_crtc_state *crtc_state);
> > +void intel_color_read_luts(struct intel_crtc_state *crtc_state);
> >
> > #endif /* __INTEL_COLOR_H__ */
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/icl: Add Multi-segmented gamma support
On Mon, May 06, 2019 at 06:44:43PM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
> On 5/6/2019 6:41 PM, Ville Syrjälä wrote:
> > On Mon, May 06, 2019 at 06:25:19PM +0530, Sharma, Shashank wrote:
> >> On 5/6/2019 5:55 PM, Ville Syrjälä wrote:
> >>> On Mon, May 06, 2019 at 04:09:33PM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
> On 5/3/2019 9:20 PM, Ville Syrjälä wrote:
> > On Tue, Apr 30, 2019 at 08:51:08PM +0530, Shashank Sharma wrote:
> >> ICL introduces a new gamma correction mode in display engine, called
> >> multi-segmented-gamma mode. This mode allows users to program the
> >> darker region of the gamma curve with sueprfine precision. An
> >> example use case for this is HDR curves (like PQ ST-2084).
> >>
> >> If we plot a gamma correction curve from value range between 0.0 to
> >> 1.0,
> >> ICL's multi-segment has 3 different sections:
> >> - superfine segment: 9 values, ranges between 0 - 1/(128 * 256)
> >> - fine segment: 257 values, ranges between 0 - 1/(128)
> >> - corase segment: 257 values, ranges between 0 - 1
> >>
> >> This patch:
> >> - Changes gamma LUTs size for ICL/GEN11 to 262144 entries (8 * 128 *
> >> 256),
> >> so that userspace can program with highest precision supported.
> >> - Changes default gamma mode (non-legacy) to multi-segmented-gamma
> >> mode.
> >> - Adds functions to program/detect multi-segment gamma.
> >>
> >> V2: Addressed review comments from Ville
> >>- separate function for superfine and fine segments.
> >>- remove enum for segments.
> >>- reuse last entry of the LUT as gc_max value.
> >>- replace if() cond with switch...case in icl_load_luts.
> >>- add an entry variable, instead of 'word'
> >>
> >> Cc: Ville Syrjälä
> >> Cc: Maarten Lankhorst
> >> Cc: Daniel Vetter
> >>
> >> Suggested-by: Ville Syrjälä
> >> Signed-off-by: Shashank Sharma
> >> Signed-off-by: Uma Shankar
> >> ---
> >> drivers/gpu/drm/i915/i915_pci.c| 3 +-
> >> drivers/gpu/drm/i915/intel_color.c | 125
> >> -
> >> 2 files changed, 123 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_pci.c
> >> b/drivers/gpu/drm/i915/i915_pci.c
> >> index ffa2ee70a03d..83698951760b 100644
> >> --- a/drivers/gpu/drm/i915/i915_pci.c
> >> +++ b/drivers/gpu/drm/i915/i915_pci.c
> >> @@ -749,7 +749,8 @@ static const struct intel_device_info
> >> intel_cannonlake_info = {
> >>GEN(11), \
> >>.ddb_size = 2048, \
> >>.has_logical_ring_elsq = 1, \
> >> - .color = { .degamma_lut_size = 33, .gamma_lut_size = 1024 }
> >> + .color = { .degamma_lut_size = 33, .gamma_lut_size = 262144 }
> > Ugh. Thats one big LUT. But looks correct.
> >
> >> +
> > Bogus newline.
> Got it.
> >>
> >> static const struct intel_device_info intel_icelake_11_info = {
> >>GEN11_FEATURES,
> >> diff --git a/drivers/gpu/drm/i915/intel_color.c
> >> b/drivers/gpu/drm/i915/intel_color.c
> >> index 6c341bea514c..49831e8d02fb 100644
> >> --- a/drivers/gpu/drm/i915/intel_color.c
> >> +++ b/drivers/gpu/drm/i915/intel_color.c
> >> @@ -41,6 +41,9 @@
> >> #define CTM_COEFF_ABS(coeff) ((coeff) &
> >> (CTM_COEFF_SIGN - 1))
> >>
> >> #define LEGACY_LUT_LENGTH 256
> >> +#define ICL_GAMMA_MULTISEG_LUT_LENGTH (256 * 128 * 8)
> >> +#define ICL_GAMMA_SUPERFINE_SEG_LENGTH9
> >> +
> >> /*
> >> * Extract the CSC coefficient from a CTM coefficient (in U32.32
> >> fixed point
> >> * format). This macro takes the coefficient we want transformed
> >> and the
> >> @@ -767,6 +770,113 @@ static void glk_load_luts(const struct
> >> intel_crtc_state *crtc_state)
> >>}
> >> }
> >>
> >> +/* ilk+ "12.4" interpolated format (high 10 bits) */
> >> +static u32 ilk_lut_12p4_ldw(const struct drm_color_lut *color)
> >> +{
> >> + return (color->red >> 6) << 20 | (color->green >> 6) << 10 |
> >> + (color->blue >> 6);
> >> +}
> >> +
> >> +/* ilk+ "12.4" interpolated format (low 6 bits) */
> >> +static u32 ilk_lut_12p4_udw(const struct drm_color_lut *color)
> >> +{
> >> + return (color->red & 0x3f) << 24 | (color->green & 0x3f) << 14 |
> >> + (color->blue & 0x3f);
> >> +}
> >> +
> >> +static void
> >> +icl_load_gcmax(const struct intel_crtc_state *crtc_state,
> >> + const struct drm_color_lut *entry)
> > Indentation looks off. Also s/entry/color/ to match the other similarish
> > funcs maybe?
> Sure.
> >> +{
>
Re: [Intel-gfx] [v5][PATCH 01/11] drm/i915: Introduce vfunc read_luts() to create hw lut
On Sat, 04 May 2019, Swati Sharma wrote:
> In this patch, a vfunc read_luts() is introduced to create a hw lut
> i.e. lut having values read from gamma/degamma registers which will
> later be used to compare with sw lut to validate gamma/degamma lut values.
>
> v3: -Rebase
> v4: -Renamed intel_get_color_config to intel_color_get_config [Jani]
> -Wrapped get_color_config() [Jani]
> v5: -Renamed intel_color_get_config() to intel_color_read_luts()
Ville, did you really want this chage? I sure didn't.
BR,
Jani.
> -Renamed get_color_config to read_luts
>
> Signed-off-by: Swati Sharma
> ---
> drivers/gpu/drm/i915/i915_drv.h| 1 +
> drivers/gpu/drm/i915/intel_color.c | 8
> drivers/gpu/drm/i915/intel_color.h | 1 +
> 3 files changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 1cea98f..1b6d891 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -342,6 +342,7 @@ struct drm_i915_display_funcs {
>* involved with the same commit.
>*/
> void (*load_luts)(const struct intel_crtc_state *crtc_state);
> + void (*read_luts)(struct intel_crtc_state *crtc_state);
> };
>
> #define CSR_VERSION(major, minor)((major) << 16 | (minor))
> diff --git a/drivers/gpu/drm/i915/intel_color.c
> b/drivers/gpu/drm/i915/intel_color.c
> index 962db12..0048d8a 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -879,6 +879,14 @@ int intel_color_check(struct intel_crtc_state
> *crtc_state)
> return dev_priv->display.color_check(crtc_state);
> }
>
> +void intel_color_read_luts(struct intel_crtc_state *crtc_state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
> +
> + if (dev_priv->display.read_luts)
> + dev_priv->display.read_luts(crtc_state);
> +}
> +
> static bool need_plane_update(struct intel_plane *plane,
> const struct intel_crtc_state *crtc_state)
> {
> diff --git a/drivers/gpu/drm/i915/intel_color.h
> b/drivers/gpu/drm/i915/intel_color.h
> index b8a3ce6..fc53de9 100644
> --- a/drivers/gpu/drm/i915/intel_color.h
> +++ b/drivers/gpu/drm/i915/intel_color.h
> @@ -13,5 +13,6 @@
> int intel_color_check(struct intel_crtc_state *crtc_state);
> void intel_color_commit(const struct intel_crtc_state *crtc_state);
> void intel_color_load_luts(const struct intel_crtc_state *crtc_state);
> +void intel_color_read_luts(struct intel_crtc_state *crtc_state);
>
> #endif /* __INTEL_COLOR_H__ */
--
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 09/10] drm/i915: Avoid taking the PPS lock for non-eDP/VLV/CHV
On Mon, May 06, 2019 at 04:12:50PM +0300, Ville Syrjälä wrote:
> On Mon, May 06, 2019 at 03:35:52PM +0300, Ville Syrjälä wrote:
> > On Fri, May 03, 2019 at 02:26:47AM +0300, Imre Deak wrote:
> > > On ICL we have to make sure that we enable the AUX power domain in a
> > > controlled way (corresponding to the port's actual TypeC mode). Since
> > > the PPS lock - which takes an AUX power ref - is only needed on
> > > eDP/VLV/CHV avoid taking it in other cases.
> > >
> > > Cc: Ville Syrjala
> > > Signed-off-by: Imre Deak
> > > ---
> > > drivers/gpu/drm/i915/intel_dp.c | 4
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index f56cbda59fb3..1ee9b7ebd801 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -6263,6 +6263,10 @@ void intel_dp_encoder_reset(struct drm_encoder
> > > *encoder)
> > >
> > > intel_dp->reset_link_params = true;
> > >
> > > + if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv) &&
> > > + !intel_dp_is_edp(intel_dp))
> > > + return;
> >
> > vlv/chv need this for all DP ports.
>
> Which is what this does. The wording in the commit message confused me.
Yep, can make it clearer like:
... only needed on eDP on all platforms and eDP/DP on VLV/CHV, ...
> >
> > > +
> > > with_pps_lock(intel_dp, wakeref) {
> > > if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> > > intel_dp->active_pipe = vlv_active_pipe(intel_dp);
> > > --
> > > 2.17.1
> >
> > --
> > Ville Syrjälä
> > Intel
>
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/icl: Add Multi-segmented gamma support
Regards
Shashank
On 5/6/2019 6:41 PM, Ville Syrjälä wrote:
On Mon, May 06, 2019 at 06:25:19PM +0530, Sharma, Shashank wrote:
On 5/6/2019 5:55 PM, Ville Syrjälä wrote:
On Mon, May 06, 2019 at 04:09:33PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 5/3/2019 9:20 PM, Ville Syrjälä wrote:
On Tue, Apr 30, 2019 at 08:51:08PM +0530, Shashank Sharma wrote:
ICL introduces a new gamma correction mode in display engine, called
multi-segmented-gamma mode. This mode allows users to program the
darker region of the gamma curve with sueprfine precision. An
example use case for this is HDR curves (like PQ ST-2084).
If we plot a gamma correction curve from value range between 0.0 to 1.0,
ICL's multi-segment has 3 different sections:
- superfine segment: 9 values, ranges between 0 - 1/(128 * 256)
- fine segment: 257 values, ranges between 0 - 1/(128)
- corase segment: 257 values, ranges between 0 - 1
This patch:
- Changes gamma LUTs size for ICL/GEN11 to 262144 entries (8 * 128 * 256),
so that userspace can program with highest precision supported.
- Changes default gamma mode (non-legacy) to multi-segmented-gamma mode.
- Adds functions to program/detect multi-segment gamma.
V2: Addressed review comments from Ville
- separate function for superfine and fine segments.
- remove enum for segments.
- reuse last entry of the LUT as gc_max value.
- replace if() cond with switch...case in icl_load_luts.
- add an entry variable, instead of 'word'
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Suggested-by: Ville Syrjälä
Signed-off-by: Shashank Sharma
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_pci.c| 3 +-
drivers/gpu/drm/i915/intel_color.c | 125 -
2 files changed, 123 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index ffa2ee70a03d..83698951760b 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -749,7 +749,8 @@ static const struct intel_device_info intel_cannonlake_info
= {
GEN(11), \
.ddb_size = 2048, \
.has_logical_ring_elsq = 1, \
- .color = { .degamma_lut_size = 33, .gamma_lut_size = 1024 }
+ .color = { .degamma_lut_size = 33, .gamma_lut_size = 262144 }
Ugh. Thats one big LUT. But looks correct.
+
Bogus newline.
Got it.
static const struct intel_device_info intel_icelake_11_info = {
GEN11_FEATURES,
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 6c341bea514c..49831e8d02fb 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -41,6 +41,9 @@
#define CTM_COEFF_ABS(coeff)((coeff) & (CTM_COEFF_SIGN - 1))
#define LEGACY_LUT_LENGTH 256
+#define ICL_GAMMA_MULTISEG_LUT_LENGTH (256 * 128 * 8)
+#define ICL_GAMMA_SUPERFINE_SEG_LENGTH 9
+
/*
* Extract the CSC coefficient from a CTM coefficient (in U32.32 fixed point
* format). This macro takes the coefficient we want transformed and the
@@ -767,6 +770,113 @@ static void glk_load_luts(const struct intel_crtc_state
*crtc_state)
}
}
+/* ilk+ "12.4" interpolated format (high 10 bits) */
+static u32 ilk_lut_12p4_ldw(const struct drm_color_lut *color)
+{
+ return (color->red >> 6) << 20 | (color->green >> 6) << 10 |
+ (color->blue >> 6);
+}
+
+/* ilk+ "12.4" interpolated format (low 6 bits) */
+static u32 ilk_lut_12p4_udw(const struct drm_color_lut *color)
+{
+ return (color->red & 0x3f) << 24 | (color->green & 0x3f) << 14 |
+ (color->blue & 0x3f);
+}
+
+static void
+icl_load_gcmax(const struct intel_crtc_state *crtc_state,
+ const struct drm_color_lut *entry)
Indentation looks off. Also s/entry/color/ to match the other similarish
funcs maybe?
Sure.
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+
+ /* Fixme: LUT entries are 16 bit only, so we can prog 0x max */
+ I915_WRITE(PREC_PAL_GC_MAX(pipe, 0), entry->red);
+ I915_WRITE(PREC_PAL_GC_MAX(pipe, 1), entry->green);
+ I915_WRITE(PREC_PAL_GC_MAX(pipe, 2), entry->blue);
+}
+
+static void
+icl_program_gamma_superfine_segment(const struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ const struct drm_property_blob *blob = crtc_state->base.gamma_lut;
+ const struct drm_color_lut *lut = blob->data;
+ enum pipe pipe = crtc->pipe;
+ u32 i;
+
+ if (!lut || drm_color_lut_size(blob) < ICL_GAMMA_SUPERFINE_SEG_LENGTH)
+ return;
These checks aren't needed. Just dead code.
Will remove this and similars.
+
+
Re: [Intel-gfx] [PATCH 09/10] drm/i915: Avoid taking the PPS lock for non-eDP/VLV/CHV
On Mon, May 06, 2019 at 03:35:52PM +0300, Ville Syrjälä wrote:
> On Fri, May 03, 2019 at 02:26:47AM +0300, Imre Deak wrote:
> > On ICL we have to make sure that we enable the AUX power domain in a
> > controlled way (corresponding to the port's actual TypeC mode). Since
> > the PPS lock - which takes an AUX power ref - is only needed on
> > eDP/VLV/CHV avoid taking it in other cases.
> >
> > Cc: Ville Syrjala
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index f56cbda59fb3..1ee9b7ebd801 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -6263,6 +6263,10 @@ void intel_dp_encoder_reset(struct drm_encoder
> > *encoder)
> >
> > intel_dp->reset_link_params = true;
> >
> > + if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv) &&
> > + !intel_dp_is_edp(intel_dp))
> > + return;
>
> vlv/chv need this for all DP ports.
Which is what this does. The wording in the commit message confused me.
>
> > +
> > with_pps_lock(intel_dp, wakeref) {
> > if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> > intel_dp->active_pipe = vlv_active_pipe(intel_dp);
> > --
> > 2.17.1
>
> --
> Ville Syrjälä
> Intel
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/icl: Add Multi-segmented gamma support
On Mon, May 06, 2019 at 06:25:19PM +0530, Sharma, Shashank wrote:
>
> On 5/6/2019 5:55 PM, Ville Syrjälä wrote:
> > On Mon, May 06, 2019 at 04:09:33PM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >> On 5/3/2019 9:20 PM, Ville Syrjälä wrote:
> >>> On Tue, Apr 30, 2019 at 08:51:08PM +0530, Shashank Sharma wrote:
> ICL introduces a new gamma correction mode in display engine, called
> multi-segmented-gamma mode. This mode allows users to program the
> darker region of the gamma curve with sueprfine precision. An
> example use case for this is HDR curves (like PQ ST-2084).
>
> If we plot a gamma correction curve from value range between 0.0 to 1.0,
> ICL's multi-segment has 3 different sections:
> - superfine segment: 9 values, ranges between 0 - 1/(128 * 256)
> - fine segment: 257 values, ranges between 0 - 1/(128)
> - corase segment: 257 values, ranges between 0 - 1
>
> This patch:
> - Changes gamma LUTs size for ICL/GEN11 to 262144 entries (8 * 128 *
> 256),
> so that userspace can program with highest precision supported.
> - Changes default gamma mode (non-legacy) to multi-segmented-gamma mode.
> - Adds functions to program/detect multi-segment gamma.
>
> V2: Addressed review comments from Ville
> - separate function for superfine and fine segments.
> - remove enum for segments.
> - reuse last entry of the LUT as gc_max value.
> - replace if() cond with switch...case in icl_load_luts.
> - add an entry variable, instead of 'word'
>
> Cc: Ville Syrjälä
> Cc: Maarten Lankhorst
> Cc: Daniel Vetter
>
> Suggested-by: Ville Syrjälä
> Signed-off-by: Shashank Sharma
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/i915_pci.c| 3 +-
> drivers/gpu/drm/i915/intel_color.c | 125 -
> 2 files changed, 123 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c
> b/drivers/gpu/drm/i915/i915_pci.c
> index ffa2ee70a03d..83698951760b 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -749,7 +749,8 @@ static const struct intel_device_info
> intel_cannonlake_info = {
> GEN(11), \
> .ddb_size = 2048, \
> .has_logical_ring_elsq = 1, \
> -.color = { .degamma_lut_size = 33, .gamma_lut_size = 1024 }
> +.color = { .degamma_lut_size = 33, .gamma_lut_size = 262144 }
> >>> Ugh. Thats one big LUT. But looks correct.
> >>>
> +
> >>> Bogus newline.
> >> Got it.
>
> static const struct intel_device_info intel_icelake_11_info = {
> GEN11_FEATURES,
> diff --git a/drivers/gpu/drm/i915/intel_color.c
> b/drivers/gpu/drm/i915/intel_color.c
> index 6c341bea514c..49831e8d02fb 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -41,6 +41,9 @@
> #define CTM_COEFF_ABS(coeff) ((coeff) & (CTM_COEFF_SIGN - 1))
>
> #define LEGACY_LUT_LENGTH 256
> +#define ICL_GAMMA_MULTISEG_LUT_LENGTH (256 * 128 * 8)
> +#define ICL_GAMMA_SUPERFINE_SEG_LENGTH 9
> +
> /*
> * Extract the CSC coefficient from a CTM coefficient (in U32.32
> fixed point
> * format). This macro takes the coefficient we want transformed and
> the
> @@ -767,6 +770,113 @@ static void glk_load_luts(const struct
> intel_crtc_state *crtc_state)
> }
> }
>
> +/* ilk+ "12.4" interpolated format (high 10 bits) */
> +static u32 ilk_lut_12p4_ldw(const struct drm_color_lut *color)
> +{
> +return (color->red >> 6) << 20 | (color->green >> 6) << 10 |
> +(color->blue >> 6);
> +}
> +
> +/* ilk+ "12.4" interpolated format (low 6 bits) */
> +static u32 ilk_lut_12p4_udw(const struct drm_color_lut *color)
> +{
> +return (color->red & 0x3f) << 24 | (color->green & 0x3f) << 14 |
> +(color->blue & 0x3f);
> +}
> +
> +static void
> +icl_load_gcmax(const struct intel_crtc_state *crtc_state,
> +const struct drm_color_lut *entry)
> >>> Indentation looks off. Also s/entry/color/ to match the other similarish
> >>> funcs maybe?
> >> Sure.
> +{
> +struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> +struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> +enum pipe pipe = crtc->pipe;
> +
> +/* Fixme: LUT entries are 16 bit only, so we can prog 0x
> max */
> +I915_WRITE(PREC_PAL_GC_MAX(pipe, 0), entry->red);
> +
Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/icl: Add Multi-segmented gamma support
On 5/6/2019 5:55 PM, Ville Syrjälä wrote:
On Mon, May 06, 2019 at 04:09:33PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 5/3/2019 9:20 PM, Ville Syrjälä wrote:
On Tue, Apr 30, 2019 at 08:51:08PM +0530, Shashank Sharma wrote:
ICL introduces a new gamma correction mode in display engine, called
multi-segmented-gamma mode. This mode allows users to program the
darker region of the gamma curve with sueprfine precision. An
example use case for this is HDR curves (like PQ ST-2084).
If we plot a gamma correction curve from value range between 0.0 to 1.0,
ICL's multi-segment has 3 different sections:
- superfine segment: 9 values, ranges between 0 - 1/(128 * 256)
- fine segment: 257 values, ranges between 0 - 1/(128)
- corase segment: 257 values, ranges between 0 - 1
This patch:
- Changes gamma LUTs size for ICL/GEN11 to 262144 entries (8 * 128 * 256),
so that userspace can program with highest precision supported.
- Changes default gamma mode (non-legacy) to multi-segmented-gamma mode.
- Adds functions to program/detect multi-segment gamma.
V2: Addressed review comments from Ville
- separate function for superfine and fine segments.
- remove enum for segments.
- reuse last entry of the LUT as gc_max value.
- replace if() cond with switch...case in icl_load_luts.
- add an entry variable, instead of 'word'
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Suggested-by: Ville Syrjälä
Signed-off-by: Shashank Sharma
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_pci.c| 3 +-
drivers/gpu/drm/i915/intel_color.c | 125 -
2 files changed, 123 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index ffa2ee70a03d..83698951760b 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -749,7 +749,8 @@ static const struct intel_device_info intel_cannonlake_info
= {
GEN(11), \
.ddb_size = 2048, \
.has_logical_ring_elsq = 1, \
- .color = { .degamma_lut_size = 33, .gamma_lut_size = 1024 }
+ .color = { .degamma_lut_size = 33, .gamma_lut_size = 262144 }
Ugh. Thats one big LUT. But looks correct.
+
Bogus newline.
Got it.
static const struct intel_device_info intel_icelake_11_info = {
GEN11_FEATURES,
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 6c341bea514c..49831e8d02fb 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -41,6 +41,9 @@
#define CTM_COEFF_ABS(coeff) ((coeff) & (CTM_COEFF_SIGN - 1))
#define LEGACY_LUT_LENGTH 256
+#define ICL_GAMMA_MULTISEG_LUT_LENGTH (256 * 128 * 8)
+#define ICL_GAMMA_SUPERFINE_SEG_LENGTH 9
+
/*
* Extract the CSC coefficient from a CTM coefficient (in U32.32 fixed point
* format). This macro takes the coefficient we want transformed and the
@@ -767,6 +770,113 @@ static void glk_load_luts(const struct intel_crtc_state
*crtc_state)
}
}
+/* ilk+ "12.4" interpolated format (high 10 bits) */
+static u32 ilk_lut_12p4_ldw(const struct drm_color_lut *color)
+{
+ return (color->red >> 6) << 20 | (color->green >> 6) << 10 |
+ (color->blue >> 6);
+}
+
+/* ilk+ "12.4" interpolated format (low 6 bits) */
+static u32 ilk_lut_12p4_udw(const struct drm_color_lut *color)
+{
+ return (color->red & 0x3f) << 24 | (color->green & 0x3f) << 14 |
+ (color->blue & 0x3f);
+}
+
+static void
+icl_load_gcmax(const struct intel_crtc_state *crtc_state,
+ const struct drm_color_lut *entry)
Indentation looks off. Also s/entry/color/ to match the other similarish
funcs maybe?
Sure.
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+
+ /* Fixme: LUT entries are 16 bit only, so we can prog 0x max */
+ I915_WRITE(PREC_PAL_GC_MAX(pipe, 0), entry->red);
+ I915_WRITE(PREC_PAL_GC_MAX(pipe, 1), entry->green);
+ I915_WRITE(PREC_PAL_GC_MAX(pipe, 2), entry->blue);
+}
+
+static void
+icl_program_gamma_superfine_segment(const struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ const struct drm_property_blob *blob = crtc_state->base.gamma_lut;
+ const struct drm_color_lut *lut = blob->data;
+ enum pipe pipe = crtc->pipe;
+ u32 i;
+
+ if (!lut || drm_color_lut_size(blob) < ICL_GAMMA_SUPERFINE_SEG_LENGTH)
+ return;
These checks aren't needed. Just dead code.
Will remove this and similars.
+
+ /*
+* Every entry in the multi-segment LUT is corresponding to a superfine
+* segment step which is 1/(8 * 128 * 256).
+*
+
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Add support for asynchronous display power disabling (rev2)
== Series Details == Series: drm/i915: Add support for asynchronous display power disabling (rev2) URL : https://patchwork.freedesktop.org/series/60242/ State : success == Summary == CI Bug Log - changes from CI_DRM_6049_full -> Patchwork_12969_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12969_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@reset-stress: - shard-skl: [PASS][1] -> [FAIL][2] ([fdo#105957]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6049/shard-skl5/igt@gem_...@reset-stress.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12969/shard-skl10/igt@gem_...@reset-stress.html * igt@gem_workarounds@suspend-resume: - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([fdo#104108] / [fdo#107773]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6049/shard-skl10/igt@gem_workarou...@suspend-resume.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12969/shard-skl2/igt@gem_workarou...@suspend-resume.html * igt@i915_pm_rpm@modeset-lpsp-stress-no-wait: - shard-skl: [PASS][5] -> [INCOMPLETE][6] ([fdo#107807]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6049/shard-skl3/igt@i915_pm_...@modeset-lpsp-stress-no-wait.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12969/shard-skl3/igt@i915_pm_...@modeset-lpsp-stress-no-wait.html * igt@kms_cursor_crc@cursor-128x128-suspend: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([fdo#104108]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6049/shard-skl5/igt@kms_cursor_...@cursor-128x128-suspend.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12969/shard-skl10/igt@kms_cursor_...@cursor-128x128-suspend.html * igt@kms_cursor_legacy@pipe-c-forked-move: - shard-hsw: [PASS][9] -> [INCOMPLETE][10] ([fdo#103540]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6049/shard-hsw8/igt@kms_cursor_leg...@pipe-c-forked-move.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12969/shard-hsw6/igt@kms_cursor_leg...@pipe-c-forked-move.html * igt@kms_frontbuffer_tracking@fbc-tilingchange: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103167]) +4 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6049/shard-iclb5/igt@kms_frontbuffer_track...@fbc-tilingchange.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12969/shard-iclb5/igt@kms_frontbuffer_track...@fbc-tilingchange.html * igt@kms_plane@pixel-format-pipe-b-planes-source-clamping: - shard-glk: [PASS][13] -> [SKIP][14] ([fdo#109271]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6049/shard-glk9/igt@kms_pl...@pixel-format-pipe-b-planes-source-clamping.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12969/shard-glk5/igt@kms_pl...@pixel-format-pipe-b-planes-source-clamping.html * igt@kms_plane_scaling@pipe-b-scaler-with-rotation: - shard-glk: [PASS][15] -> [SKIP][16] ([fdo#109271] / [fdo#109278]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6049/shard-glk9/igt@kms_plane_scal...@pipe-b-scaler-with-rotation.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12969/shard-glk7/igt@kms_plane_scal...@pipe-b-scaler-with-rotation.html * igt@kms_psr2_su@frontbuffer: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109642]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6049/shard-iclb2/igt@kms_psr2...@frontbuffer.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12969/shard-iclb1/igt@kms_psr2...@frontbuffer.html * igt@kms_psr@psr2_cursor_mmap_gtt: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6049/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_gtt.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12969/shard-iclb8/igt@kms_psr@psr2_cursor_mmap_gtt.html * igt@kms_setmode@basic: - shard-apl: [PASS][21] -> [FAIL][22] ([fdo#99912]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6049/shard-apl4/igt@kms_setm...@basic.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12969/shard-apl7/igt@kms_setm...@basic.html - shard-kbl: [PASS][23] -> [FAIL][24] ([fdo#99912]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6049/shard-kbl2/igt@kms_setm...@basic.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12969/shard-kbl4/igt@kms_setm...@basic.html * igt@kms_sysfs_edid_timing: - shard-iclb: [PASS][25] -> [FAIL][26] ([fdo#100047]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6049/shard-iclb8/igt@kms_sysfs_edid_timing.html [26]:
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Move the hsw/bdw pc8 code to intel_runtime_pm.c
On Fri, May 03, 2019 at 10:31:43PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> hsw_enable_pc8()/hsw_disable_pc8() are more less equivalent to
> the display core init/unit functions of later platforms. Relocate
> the hsw/bdw code into intel_runtime_pm.c so that it sits next to
> its cousins.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_display.c| 222 +--
> drivers/gpu/drm/i915/intel_display.h| 4 +
> drivers/gpu/drm/i915/intel_drv.h| 2 -
> drivers/gpu/drm/i915/intel_runtime_pm.c | 223
> drivers/gpu/drm/i915/intel_runtime_pm.h | 2 +
> 5 files changed, 230 insertions(+), 223 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index d81ec80e34f6..a351c8e219ba 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -8725,7 +8725,7 @@ static void lpt_enable_clkout_dp(struct
> drm_i915_private *dev_priv,
> }
>
> /* Sequence to disable CLKOUT_DP */
> -static void lpt_disable_clkout_dp(struct drm_i915_private *dev_priv)
> +void lpt_disable_clkout_dp(struct drm_i915_private *dev_priv)
> {
> u32 reg, tmp;
>
> @@ -9482,226 +9482,6 @@ static bool ironlake_get_pipe_config(struct
> intel_crtc *crtc,
>
> return ret;
> }
> -
> -static void assert_can_disable_lcpll(struct drm_i915_private *dev_priv)
> -{
> - struct drm_device *dev = _priv->drm;
> - struct intel_crtc *crtc;
> -
> - for_each_intel_crtc(dev, crtc)
> - I915_STATE_WARN(crtc->active, "CRTC for pipe %c enabled\n",
> - pipe_name(crtc->pipe));
> -
> - I915_STATE_WARN(I915_READ(HSW_PWR_WELL_CTL2),
> - "Display power well on\n");
> - I915_STATE_WARN(I915_READ(SPLL_CTL) & SPLL_PLL_ENABLE, "SPLL
> enabled\n");
> - I915_STATE_WARN(I915_READ(WRPLL_CTL(0)) & WRPLL_PLL_ENABLE, "WRPLL1
> enabled\n");
> - I915_STATE_WARN(I915_READ(WRPLL_CTL(1)) & WRPLL_PLL_ENABLE, "WRPLL2
> enabled\n");
> - I915_STATE_WARN(I915_READ(PP_STATUS(0)) & PP_ON, "Panel power on\n");
> - I915_STATE_WARN(I915_READ(BLC_PWM_CPU_CTL2) & BLM_PWM_ENABLE,
> - "CPU PWM1 enabled\n");
> - if (IS_HASWELL(dev_priv))
> - I915_STATE_WARN(I915_READ(HSW_BLC_PWM2_CTL) & BLM_PWM_ENABLE,
> - "CPU PWM2 enabled\n");
> - I915_STATE_WARN(I915_READ(BLC_PWM_PCH_CTL1) & BLM_PCH_PWM_ENABLE,
> - "PCH PWM1 enabled\n");
> - I915_STATE_WARN(I915_READ(UTIL_PIN_CTL) & UTIL_PIN_ENABLE,
> - "Utility pin enabled\n");
> - I915_STATE_WARN(I915_READ(PCH_GTC_CTL) & PCH_GTC_ENABLE, "PCH GTC
> enabled\n");
> -
> - /*
> - * In theory we can still leave IRQs enabled, as long as only the HPD
> - * interrupts remain enabled. We used to check for that, but since it's
> - * gen-specific and since we only disable LCPLL after we fully disable
> - * the interrupts, the check below should be enough.
> - */
> - I915_STATE_WARN(intel_irqs_enabled(dev_priv), "IRQs enabled\n");
> -}
> -
> -static u32 hsw_read_dcomp(struct drm_i915_private *dev_priv)
> -{
> - if (IS_HASWELL(dev_priv))
> - return I915_READ(D_COMP_HSW);
> - else
> - return I915_READ(D_COMP_BDW);
> -}
> -
> -static void hsw_write_dcomp(struct drm_i915_private *dev_priv, u32 val)
> -{
> - if (IS_HASWELL(dev_priv)) {
> - if (sandybridge_pcode_write(dev_priv, GEN6_PCODE_WRITE_D_COMP,
> - val))
> - DRM_DEBUG_KMS("Failed to write to D_COMP\n");
> - } else {
> - I915_WRITE(D_COMP_BDW, val);
> - POSTING_READ(D_COMP_BDW);
> - }
> -}
> -
> -/*
> - * This function implements pieces of two sequences from BSpec:
> - * - Sequence for display software to disable LCPLL
> - * - Sequence for display software to allow package C8+
> - * The steps implemented here are just the steps that actually touch the
> LCPLL
> - * register. Callers should take care of disabling all the display engine
> - * functions, doing the mode unset, fixing interrupts, etc.
> - */
> -static void hsw_disable_lcpll(struct drm_i915_private *dev_priv,
> - bool switch_to_fclk, bool allow_power_down)
> -{
> - u32 val;
> -
> - assert_can_disable_lcpll(dev_priv);
> -
> - val = I915_READ(LCPLL_CTL);
> -
> - if (switch_to_fclk) {
> - val |= LCPLL_CD_SOURCE_FCLK;
> - I915_WRITE(LCPLL_CTL, val);
> -
> - if (wait_for_us(I915_READ(LCPLL_CTL) &
> - LCPLL_CD_SOURCE_FCLK_DONE, 1))
> - DRM_ERROR("Switching to FCLK failed\n");
> -
> - val = I915_READ(LCPLL_CTL);
> - }
> -
> - val |= LCPLL_PLL_DISABLE;
> - I915_WRITE(LCPLL_CTL, val);
> - POSTING_READ(LCPLL_CTL);
> -
> - if
Re: [Intel-gfx] [PATCH 09/10] drm/i915: Avoid taking the PPS lock for non-eDP/VLV/CHV
On Fri, May 03, 2019 at 02:26:47AM +0300, Imre Deak wrote:
> On ICL we have to make sure that we enable the AUX power domain in a
> controlled way (corresponding to the port's actual TypeC mode). Since
> the PPS lock - which takes an AUX power ref - is only needed on
> eDP/VLV/CHV avoid taking it in other cases.
>
> Cc: Ville Syrjala
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_dp.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index f56cbda59fb3..1ee9b7ebd801 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -6263,6 +6263,10 @@ void intel_dp_encoder_reset(struct drm_encoder
> *encoder)
>
> intel_dp->reset_link_params = true;
>
> + if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv) &&
> + !intel_dp_is_edp(intel_dp))
> + return;
vlv/chv need this for all DP ports.
> +
> with_pps_lock(intel_dp, wakeref) {
> if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> intel_dp->active_pipe = vlv_active_pipe(intel_dp);
> --
> 2.17.1
--
Ville Syrjälä
Intel
___
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: Replace intel_ddi_pll_init()
On Fri, May 03, 2019 at 10:31:42PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> intel_ddi_pll_init() is an anachronism. Rename it to
> hsw_assert_cdclk() and move it to the power domain init code.
>
> Signed-off-by: Ville Syrjälä
Ok, makes sense to check this during system resume too:
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_dpll_mgr.c | 25 -
> drivers/gpu/drm/i915/intel_runtime_pm.c | 22 +-
> 2 files changed, 21 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index bb81f3506222..bf5e2541c35e 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -1881,27 +1881,6 @@ static const struct intel_shared_dpll_funcs
> bxt_ddi_pll_funcs = {
> .get_hw_state = bxt_ddi_pll_get_hw_state,
> };
>
> -static void intel_ddi_pll_init(struct drm_device *dev)
> -{
> - struct drm_i915_private *dev_priv = to_i915(dev);
> -
> - if (INTEL_GEN(dev_priv) < 9) {
> - u32 val = I915_READ(LCPLL_CTL);
> -
> - /*
> - * The LCPLL register should be turned on by the BIOS. For now
> - * let's just check its state and print errors in case
> - * something is wrong. Don't even try to turn it on.
> - */
> -
> - if (val & LCPLL_CD_SOURCE_FCLK)
> - DRM_ERROR("CDCLK source is not LCPLL\n");
> -
> - if (val & LCPLL_PLL_DISABLE)
> - DRM_ERROR("LCPLL is disabled\n");
> - }
> -}
> -
> struct intel_dpll_mgr {
> const struct dpll_info *dpll_info;
>
> @@ -3305,10 +3284,6 @@ void intel_shared_dpll_init(struct drm_device *dev)
> mutex_init(_priv->dpll_lock);
>
> BUG_ON(dev_priv->num_shared_dpll > I915_NUM_PLLS);
> -
> - /* FIXME: Move this to a more suitable place */
> - if (HAS_DDI(dev_priv))
> - intel_ddi_pll_init(dev);
> }
>
> /**
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 1b7ea6bab613..b1fd2ae99199 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -3625,6 +3625,23 @@ static void icl_mbus_init(struct drm_i915_private
> *dev_priv)
> I915_WRITE(MBUS_ABOX_CTL, val);
> }
>
> +static void hsw_assert_cdclk(struct drm_i915_private *dev_priv)
> +{
> + u32 val = I915_READ(LCPLL_CTL);
> +
> + /*
> + * The LCPLL register should be turned on by the BIOS. For now
> + * let's just check its state and print errors in case
> + * something is wrong. Don't even try to turn it on.
> + */
> +
> + if (val & LCPLL_CD_SOURCE_FCLK)
> + DRM_ERROR("CDCLK source is not LCPLL\n");
> +
> + if (val & LCPLL_PLL_DISABLE)
> + DRM_ERROR("LCPLL is disabled\n");
> +}
> +
> static void intel_pch_reset_handshake(struct drm_i915_private *dev_priv,
> bool enable)
> {
> @@ -4085,7 +4102,10 @@ void intel_power_domains_init_hw(struct
> drm_i915_private *i915, bool resume)
> mutex_unlock(_domains->lock);
> assert_ved_power_gated(i915);
> assert_isp_power_gated(i915);
> - } else if (IS_IVYBRIDGE(i915) || INTEL_GEN(i915) >= 7) {
> + } else if (IS_BROADWELL(i915) || IS_HASWELL(i915)) {
> + hsw_assert_cdclk(i915);
> + intel_pch_reset_handshake(i915, !HAS_PCH_NOP(i915));
> + } else if (IS_IVYBRIDGE(i915)) {
> intel_pch_reset_handshake(i915, !HAS_PCH_NOP(i915));
> }
>
> --
> 2.21.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/icl: Add Multi-segmented gamma support
On Mon, May 06, 2019 at 04:09:33PM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
> On 5/3/2019 9:20 PM, Ville Syrjälä wrote:
> > On Tue, Apr 30, 2019 at 08:51:08PM +0530, Shashank Sharma wrote:
> >> ICL introduces a new gamma correction mode in display engine, called
> >> multi-segmented-gamma mode. This mode allows users to program the
> >> darker region of the gamma curve with sueprfine precision. An
> >> example use case for this is HDR curves (like PQ ST-2084).
> >>
> >> If we plot a gamma correction curve from value range between 0.0 to 1.0,
> >> ICL's multi-segment has 3 different sections:
> >> - superfine segment: 9 values, ranges between 0 - 1/(128 * 256)
> >> - fine segment: 257 values, ranges between 0 - 1/(128)
> >> - corase segment: 257 values, ranges between 0 - 1
> >>
> >> This patch:
> >> - Changes gamma LUTs size for ICL/GEN11 to 262144 entries (8 * 128 * 256),
> >>so that userspace can program with highest precision supported.
> >> - Changes default gamma mode (non-legacy) to multi-segmented-gamma mode.
> >> - Adds functions to program/detect multi-segment gamma.
> >>
> >> V2: Addressed review comments from Ville
> >> - separate function for superfine and fine segments.
> >> - remove enum for segments.
> >> - reuse last entry of the LUT as gc_max value.
> >> - replace if() cond with switch...case in icl_load_luts.
> >> - add an entry variable, instead of 'word'
> >>
> >> Cc: Ville Syrjälä
> >> Cc: Maarten Lankhorst
> >> Cc: Daniel Vetter
> >>
> >> Suggested-by: Ville Syrjälä
> >> Signed-off-by: Shashank Sharma
> >> Signed-off-by: Uma Shankar
> >> ---
> >> drivers/gpu/drm/i915/i915_pci.c| 3 +-
> >> drivers/gpu/drm/i915/intel_color.c | 125 -
> >> 2 files changed, 123 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_pci.c
> >> b/drivers/gpu/drm/i915/i915_pci.c
> >> index ffa2ee70a03d..83698951760b 100644
> >> --- a/drivers/gpu/drm/i915/i915_pci.c
> >> +++ b/drivers/gpu/drm/i915/i915_pci.c
> >> @@ -749,7 +749,8 @@ static const struct intel_device_info
> >> intel_cannonlake_info = {
> >>GEN(11), \
> >>.ddb_size = 2048, \
> >>.has_logical_ring_elsq = 1, \
> >> - .color = { .degamma_lut_size = 33, .gamma_lut_size = 1024 }
> >> + .color = { .degamma_lut_size = 33, .gamma_lut_size = 262144 }
> > Ugh. Thats one big LUT. But looks correct.
> >
> >> +
> > Bogus newline.
> Got it.
> >>
> >> static const struct intel_device_info intel_icelake_11_info = {
> >>GEN11_FEATURES,
> >> diff --git a/drivers/gpu/drm/i915/intel_color.c
> >> b/drivers/gpu/drm/i915/intel_color.c
> >> index 6c341bea514c..49831e8d02fb 100644
> >> --- a/drivers/gpu/drm/i915/intel_color.c
> >> +++ b/drivers/gpu/drm/i915/intel_color.c
> >> @@ -41,6 +41,9 @@
> >> #define CTM_COEFF_ABS(coeff) ((coeff) & (CTM_COEFF_SIGN - 1))
> >>
> >> #define LEGACY_LUT_LENGTH256
> >> +#define ICL_GAMMA_MULTISEG_LUT_LENGTH (256 * 128 * 8)
> >> +#define ICL_GAMMA_SUPERFINE_SEG_LENGTH9
> >> +
> >> /*
> >>* Extract the CSC coefficient from a CTM coefficient (in U32.32 fixed
> >> point
> >>* format). This macro takes the coefficient we want transformed and the
> >> @@ -767,6 +770,113 @@ static void glk_load_luts(const struct
> >> intel_crtc_state *crtc_state)
> >>}
> >> }
> >>
> >> +/* ilk+ "12.4" interpolated format (high 10 bits) */
> >> +static u32 ilk_lut_12p4_ldw(const struct drm_color_lut *color)
> >> +{
> >> + return (color->red >> 6) << 20 | (color->green >> 6) << 10 |
> >> + (color->blue >> 6);
> >> +}
> >> +
> >> +/* ilk+ "12.4" interpolated format (low 6 bits) */
> >> +static u32 ilk_lut_12p4_udw(const struct drm_color_lut *color)
> >> +{
> >> + return (color->red & 0x3f) << 24 | (color->green & 0x3f) << 14 |
> >> + (color->blue & 0x3f);
> >> +}
> >> +
> >> +static void
> >> +icl_load_gcmax(const struct intel_crtc_state *crtc_state,
> >> + const struct drm_color_lut *entry)
> > Indentation looks off. Also s/entry/color/ to match the other similarish
> > funcs maybe?
> Sure.
> >> +{
> >> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> >> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> >> + enum pipe pipe = crtc->pipe;
> >> +
> >> + /* Fixme: LUT entries are 16 bit only, so we can prog 0x max */
> >> + I915_WRITE(PREC_PAL_GC_MAX(pipe, 0), entry->red);
> >> + I915_WRITE(PREC_PAL_GC_MAX(pipe, 1), entry->green);
> >> + I915_WRITE(PREC_PAL_GC_MAX(pipe, 2), entry->blue);
> >> +}
> >> +
> >> +static void
> >> +icl_program_gamma_superfine_segment(const struct intel_crtc_state
> >> *crtc_state)
> >> +{
> >> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> >> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> >> + const struct drm_property_blob *blob = crtc_state->base.gamma_lut;
> >> + const struct drm_color_lut *lut =
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add support for asynchronous display power disabling (rev2)
== Series Details ==
Series: drm/i915: Add support for asynchronous display power disabling (rev2)
URL : https://patchwork.freedesktop.org/series/60242/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6049 -> Patchwork_12969
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12969/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_12969:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_basic@bad-close:
- {fi-cml-u2}:[PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6049/fi-cml-u2/igt@gem_ba...@bad-close.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12969/fi-cml-u2/igt@gem_ba...@bad-close.html
Known issues
Here are the changes found in Patchwork_12969 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-skl-6600u: [PASS][3] -> [FAIL][4] ([fdo#107707])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6049/fi-skl-6600u/igt@i915_pm_...@basic-pci-d3-state.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12969/fi-skl-6600u/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_selftest@live_hangcheck:
- fi-skl-iommu: [PASS][5] -> [INCOMPLETE][6] ([fdo#108602] /
[fdo#108744])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6049/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12969/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u: [PASS][7] -> [WARN][8] ([fdo#109380])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6049/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12969/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_pipe_crc_basic@read-crc-pipe-c:
- fi-kbl-7567u: [PASS][9] -> [SKIP][10] ([fdo#109271]) +23 similar
issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6049/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12969/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
Possible fixes
* igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq: [FAIL][11] ([fdo#108511]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6049/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12969/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live_contexts:
- fi-skl-gvtdvm: [DMESG-FAIL][13] ([fdo#110235]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6049/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12969/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html
* igt@i915_selftest@live_evict:
- fi-bsw-kefka: [DMESG-WARN][15] ([fdo#107709]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6049/fi-bsw-kefka/igt@i915_selftest@live_evict.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12969/fi-bsw-kefka/igt@i915_selftest@live_evict.html
* igt@i915_selftest@live_hangcheck:
- fi-icl-y: [INCOMPLETE][17] ([fdo#107713] / [fdo#108569] /
[fdo#110581]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6049/fi-icl-y/igt@i915_selftest@live_hangcheck.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12969/fi-icl-y/igt@i915_selftest@live_hangcheck.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-blb-e6850: [INCOMPLETE][19] ([fdo#107718] / [fdo#110581]) ->
[PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6049/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12969/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
Warnings
* igt@i915_selftest@live_guc:
- fi-apl-guc: [INCOMPLETE][21] ([fdo#103927] / [fdo#110581]) ->
[INCOMPLETE][22] ([fdo#103927])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6049/fi-apl-guc/igt@i915_selftest@live_guc.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12969/fi-apl-guc/igt@i915_selftest@live_guc.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
Re: [Intel-gfx] [PATCH] RFC: console: hack up console_lock more v2
On Mon 2019-05-06 11:38:13, Daniel Vetter wrote: > On Mon, May 06, 2019 at 10:26:28AM +0200, Petr Mladek wrote: > > On Mon 2019-05-06 10:16:14, Petr Mladek wrote: > > > On Mon 2019-05-06 09:45:53, Daniel Vetter wrote: > > > > console_trylock, called from within printk, can be called from pretty > > > > much anywhere. Including try_to_wake_up. Note that this isn't common, > > > > usually the box is in pretty bad shape at that point already. But it > > > > really doesn't help when then lockdep jumps in and spams the logs, > > > > potentially obscuring the real backtrace we're really interested in. > > > > One case I've seen (slightly simplified backtrace): > > > > > > > > Call Trace: > > > > > > > > console_trylock+0xe/0x60 > > > > vprintk_emit+0xf1/0x320 > > > > printk+0x4d/0x69 > > > > __warn_printk+0x46/0x90 > > > > native_smp_send_reschedule+0x2f/0x40 > > > > check_preempt_curr+0x81/0xa0 > > > > ttwu_do_wakeup+0x14/0x220 > > > > try_to_wake_up+0x218/0x5f0 > > > > > > try_to_wake_up() takes p->pi_lock. It could deadlock because it > > > can get called recursively from printk_safe_up(). > > > > > > And there are more locks taken from try_to_wake_up(), for example, > > > __task_rq_lock() taken from ttwu_remote(). > > > > > > IMHO, the most reliable solution would be do call the entire > > > up_console_sem() from printk deferred context. We could assign > > > few bytes for this context in the per-CPU printk_deferred > > > variable. > > > > Ah, I was too fast and did the same mistake. This won't help because > > it would still call try_to_wake_up() recursively. > > Uh :-/ > > > We need to call all printk's that can be called under locks > > taken in try_to_wake_up() path in printk deferred context. > > Unfortunately it is whack a mole approach. > > Hm since it's whack-a-mole anyway, what about converting the WARN_ON into > a prinkt_deferred, like all the other scheduler related code? Feels a > notch more consistent to me than leaking the printk_context into areas it > wasn't really meant built for. Scheduler code already fully subscribed to > the whack-a-mole approach after all. I am not sure how exactly you mean the conversion. Anyway, we do not want to use printk_deferred() treewide. It reduces the chance that the messages reach consoles. Scheduler is an exception because of the possible deadlocks. A solution would be to define WARN_ON_DEFERRED() that would call normal WARN_ON() in printk deferred context and use in scheduler. Best Regards, Petr ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Add support for asynchronous display power disabling (rev2)
== Series Details ==
Series: drm/i915: Add support for asynchronous display power disabling (rev2)
URL : https://patchwork.freedesktop.org/series/60242/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5d071067866a drm/i915: Add support for tracking wakerefs w/o power-on guarantee
d71e181e7a7e drm/i915: Verify power domains state during suspend in all cases
f1694f9c835b drm/i915: Add support for asynchronous display power disabling
defe1cba7dc7 drm/i915: Disable power asynchronously during DP AUX transfers
4ca80e845053 drm/i915: WARN for eDP encoders in intel_dp_detect_dpcd()
ceea4b6eb65d drm/i915: Remove the unneeded AUX power ref from intel_dp_detect()
599e8ef0ba82 drm/i915: Remove the unneeded AUX power ref from
intel_dp_hpd_pulse()
-:12: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 1c767b339b39 ("drm/i915: take
display port power domain in DP HPD handler")'
#12:
commit 1c767b339b3938b19076ffdc9d70aa1e4235a45b
-:21: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 7d23e3c37bb3 ("drm/i915:
Cleaning up intel_dp_hpd_pulse")'
#21:
commit 7d23e3c37bb3fc6952dc84007ee60cb533fd2d5c
total: 2 errors, 0 warnings, 0 checks, 68 lines checked
0430dd3adbd0 drm/i915: Replace use of PLLS power domain with DISPLAY_CORE domain
cb2cb878cdd7 drm/i915: Avoid taking the PPS lock for non-eDP/VLV/CHV
e3d148cbe414 drm/i915: Assert that TypeC ports are not used for eDP
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 03/10] drm/i915: Add support for asynchronous display power disabling
By disabling a power domain asynchronously we can restrict holding a
reference on that power domain to the actual code sequence that
requires the power to be on for the HW access it's doing, by also
avoiding unneeded on-off-on togglings of the power domain (since the
disabling happens with a delay).
One benefit is potential power saving due to the following two reasons:
1. The fact that we will now be holding the reference only for the
necessary duration by the end of the patchset. While simply not
delaying the disabling has the same benefit, it has the problem that
frequent on-off-on power switching has its own power cost (see the 2.
point below) and the debug trace for power well on/off events will
cause a lot of dmesg spam (see details about this further below).
2. Avoiding the power cost of freuqent on-off-on power switching. This
requires us to find the optimal disabling delay based on the measured
power cost of on->off and off->on switching of each power well vs.
the power of keeping the given power well on.
In this patchset I'm not providing this optimal delay for two
reasons:
a) I don't have the means yet to perform the measurement (with high
enough signal-to-noise ratio, or with the help of an energy
counter that takes switching into account). I'm currently looking
for a way to measure this.
b) Before reducing the disabling delay we need an alternative way for
debug tracing powerwell on/off events. Simply avoiding/throttling
the debug messages is not a solution, see further below.
Note that even in the case where we can't measure any considerable
power cost of frequent on-off switching of powerwells, it still would
make sense to do the disabling asynchronously (with 0 delay) to avoid
blocking on the disabling. On VLV I measured this disabling time
overhead to be 1ms on average with a worst case of 4ms.
In the case of the AUX power domains on ICL we would also need to keep
the sequence where we hold the power reference short, the way it would
be by the end of this patchset where we hold it only for the actual AUX
transfer. Anything else would make the locking we need for ICL TypeC
ports (whenever we hold a reference on any AUX power domain) rather
problematic, adding for instance unnecessary lockdep dependencies to
the required TypeC port lock.
I chose the disabling delay to be 100msec for now to avoid the unneeded
toggling (and so not to introduce dmesg spamming) in the DP MST sideband
signaling code. We could optimize this delay later, once we have the
means to measure the switching power cost (see above).
Note that simply removing/throttling the debug tracing for power well
on/off events is not a solution. We need to know the exact spots of
these events and cannot rely only on incorrect register accesses caught
(due to not holding a wakeref at the time of access). Incorrect
powerwell enabling/disabling could lead to other problems, for instance
we need to keep certain powerwells enabled for the duration of modesets
and AUX transfers.
v2:
- Clarify the commit log parts about power cost measurement and the
problem of simply removing/throttling debug tracing. (Chris)
Cc: Chris Wilson
Cc: Ville Syrjala
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers/gpu/drm/i915/intel_runtime_pm.c | 316 +++-
drivers/gpu/drm/i915/intel_runtime_pm.h | 4 +
3 files changed, 315 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a162d57f0b58..8d18d124f496 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -835,6 +835,11 @@ struct i915_power_domains {
struct mutex lock;
int domain_use_count[POWER_DOMAIN_NUM];
+
+ struct delayed_work async_put_work;
+ intel_wakeref_t async_put_wakeref;
+ u64 async_put_domains[2];
+
struct i915_power_well *power_wells;
};
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index b4b17cdc6f26..4079b1378f2d 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -1884,6 +1884,130 @@ static void chv_pipe_power_well_disable(struct
drm_i915_private *dev_priv,
chv_set_pipe_power_well(dev_priv, power_well, false);
}
+static intel_wakeref_t
+intel_runtime_pm_get_raw(struct drm_i915_private *i915);
+static void
+intel_runtime_pm_put_raw(struct drm_i915_private *i915, intel_wakeref_t wref);
+
+static u64 __async_put_domains_mask(struct i915_power_domains *power_domains)
+{
+ return power_domains->async_put_domains[0] |
+ power_domains->async_put_domains[1];
+}
+
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
+
+static bool
+assert_async_put_domain_masks_disjoint(struct i915_power_domains
*power_domains)
+{
+ return !WARN_ON(power_domains->async_put_domains[0] &
+
Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/icl: Add Multi-segmented gamma support
Regards
Shashank
On 5/3/2019 9:20 PM, Ville Syrjälä wrote:
On Tue, Apr 30, 2019 at 08:51:08PM +0530, Shashank Sharma wrote:
ICL introduces a new gamma correction mode in display engine, called
multi-segmented-gamma mode. This mode allows users to program the
darker region of the gamma curve with sueprfine precision. An
example use case for this is HDR curves (like PQ ST-2084).
If we plot a gamma correction curve from value range between 0.0 to 1.0,
ICL's multi-segment has 3 different sections:
- superfine segment: 9 values, ranges between 0 - 1/(128 * 256)
- fine segment: 257 values, ranges between 0 - 1/(128)
- corase segment: 257 values, ranges between 0 - 1
This patch:
- Changes gamma LUTs size for ICL/GEN11 to 262144 entries (8 * 128 * 256),
so that userspace can program with highest precision supported.
- Changes default gamma mode (non-legacy) to multi-segmented-gamma mode.
- Adds functions to program/detect multi-segment gamma.
V2: Addressed review comments from Ville
- separate function for superfine and fine segments.
- remove enum for segments.
- reuse last entry of the LUT as gc_max value.
- replace if() cond with switch...case in icl_load_luts.
- add an entry variable, instead of 'word'
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Suggested-by: Ville Syrjälä
Signed-off-by: Shashank Sharma
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_pci.c| 3 +-
drivers/gpu/drm/i915/intel_color.c | 125 -
2 files changed, 123 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index ffa2ee70a03d..83698951760b 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -749,7 +749,8 @@ static const struct intel_device_info intel_cannonlake_info
= {
GEN(11), \
.ddb_size = 2048, \
.has_logical_ring_elsq = 1, \
- .color = { .degamma_lut_size = 33, .gamma_lut_size = 1024 }
+ .color = { .degamma_lut_size = 33, .gamma_lut_size = 262144 }
Ugh. Thats one big LUT. But looks correct.
+
Bogus newline.
Got it.
static const struct intel_device_info intel_icelake_11_info = {
GEN11_FEATURES,
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 6c341bea514c..49831e8d02fb 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -41,6 +41,9 @@
#define CTM_COEFF_ABS(coeff) ((coeff) & (CTM_COEFF_SIGN - 1))
#define LEGACY_LUT_LENGTH 256
+#define ICL_GAMMA_MULTISEG_LUT_LENGTH (256 * 128 * 8)
+#define ICL_GAMMA_SUPERFINE_SEG_LENGTH 9
+
/*
* Extract the CSC coefficient from a CTM coefficient (in U32.32 fixed point
* format). This macro takes the coefficient we want transformed and the
@@ -767,6 +770,113 @@ static void glk_load_luts(const struct intel_crtc_state
*crtc_state)
}
}
+/* ilk+ "12.4" interpolated format (high 10 bits) */
+static u32 ilk_lut_12p4_ldw(const struct drm_color_lut *color)
+{
+ return (color->red >> 6) << 20 | (color->green >> 6) << 10 |
+ (color->blue >> 6);
+}
+
+/* ilk+ "12.4" interpolated format (low 6 bits) */
+static u32 ilk_lut_12p4_udw(const struct drm_color_lut *color)
+{
+ return (color->red & 0x3f) << 24 | (color->green & 0x3f) << 14 |
+ (color->blue & 0x3f);
+}
+
+static void
+icl_load_gcmax(const struct intel_crtc_state *crtc_state,
+ const struct drm_color_lut *entry)
Indentation looks off. Also s/entry/color/ to match the other similarish
funcs maybe?
Sure.
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+
+ /* Fixme: LUT entries are 16 bit only, so we can prog 0x max */
+ I915_WRITE(PREC_PAL_GC_MAX(pipe, 0), entry->red);
+ I915_WRITE(PREC_PAL_GC_MAX(pipe, 1), entry->green);
+ I915_WRITE(PREC_PAL_GC_MAX(pipe, 2), entry->blue);
+}
+
+static void
+icl_program_gamma_superfine_segment(const struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ const struct drm_property_blob *blob = crtc_state->base.gamma_lut;
+ const struct drm_color_lut *lut = blob->data;
+ enum pipe pipe = crtc->pipe;
+ u32 i;
+
+ if (!lut || drm_color_lut_size(blob) < ICL_GAMMA_SUPERFINE_SEG_LENGTH)
+ return;
These checks aren't needed. Just dead code.
Will remove this and similars.
+
+ /*
+* Every entry in the multi-segment LUT is corresponding to a superfine
+* segment step which is 1/(8 * 128 * 256).
+*
+* Superfine segment has 9 entries, corresponding to values
+* 0, 1/(8 * 128 * 256), 2/(8 * 128 * 256) 8/(8 * 128 *
Re: [Intel-gfx] [PATCH v2 2/4] drm/i915/icl: Add register definitions for Multi Segmented gamma
On 5/3/2019 8:35 PM, Ville Syrjälä wrote:
On Tue, Apr 30, 2019 at 08:51:06PM +0530, Shashank Sharma wrote:
From: Uma Shankar
Add macros to define multi segmented gamma registers
V2: Addressed Ville's comments:
Add gen-lable before bit definition
Addressed Jani's comment
- Use REG_GENMASK() and REG_BIT()
Cc: Ville Syrjälä
Cc: Jani Nikula
Cc: Maarten Lankhorst
Signed-off-by: Uma Shankar
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/i915_reg.h | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6f0a0866c802..7d10b8d00d64 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7198,7 +7198,10 @@ enum {
#define GAMMA_MODE_MODE_8BIT (0 << 0)
#define GAMMA_MODE_MODE_10BIT(1 << 0)
#define GAMMA_MODE_MODE_12BIT(2 << 0)
+/* ivb-bdw */
#define GAMMA_MODE_MODE_SPLIT(3 << 0)
+/* icl + */
+#define GAMMA_MODE_MODE_12BIT_MULTI_SEGMENTED (3 << 0)
I would put the comments at the end of the line
#define ... /* ivb-bdw */
/* DMC/CSR */
#define CSR_PROGRAM(i)_MMIO(0x8 + (i) * 4)
@@ -10145,6 +10148,22 @@ enum skl_power_gate {
#define PRE_CSC_GAMC_INDEX(pipe) _MMIO_PIPE(pipe, _PRE_CSC_GAMC_INDEX_A,
_PRE_CSC_GAMC_INDEX_B)
#define PRE_CSC_GAMC_DATA(pipe) _MMIO_PIPE(pipe,
_PRE_CSC_GAMC_DATA_A, _PRE_CSC_GAMC_DATA_B)
+/* Add registers for Gen11 Multi Segmented Gamma Mode */
Weird comment. 's/Add registers for //' might make it somewhat useful.
And no point in capitalizing every word. This isn't a movie title/etc.
With those sorted this is
Reviewed-by: Ville Syrjälä
Thanks for the review, will do the changes as suggested.
- Shashank
+#define _PAL_PREC_MULTI_SEG_INDEX_A0x4A408
+#define _PAL_PREC_MULTI_SEG_INDEX_B0x4AC08
+#define PAL_PREC_MULTI_SEGMENT_AUTO_INCREMENT REG_BIT(15)
+#define PAL_PREC_MULTI_SEGMENT_INDEX_VALUE_MASK REG_GENMASK(4, 0)
+
+#define _PAL_PREC_MULTI_SEG_DATA_A 0x4A40C
+#define _PAL_PREC_MULTI_SEG_DATA_B 0x4AC0C
+
+#define PREC_PAL_MULTI_SEG_INDEX(pipe) _MMIO_PIPE(pipe, \
+ _PAL_PREC_MULTI_SEG_INDEX_A, \
+ _PAL_PREC_MULTI_SEG_INDEX_B)
+#define PREC_PAL_MULTI_SEG_DATA(pipe) _MMIO_PIPE(pipe, \
+ _PAL_PREC_MULTI_SEG_DATA_A, \
+ _PAL_PREC_MULTI_SEG_DATA_B)
+
/* pipe CSC & degamma/gamma LUTs on CHV */
#define _CGM_PIPE_A_CSC_COEFF01 (VLV_DISPLAY_BASE + 0x67900)
#define _CGM_PIPE_A_CSC_COEFF23 (VLV_DISPLAY_BASE + 0x67904)
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Add support for asynchronous display power disabling
On Fri, May 03, 2019 at 04:52:58PM +0300, Imre Deak wrote: > > > > [...] > > > > * igt@gem_persistent_relocs@forked-interruptible-thrashing: > > > > - shard-glk: [PASS][1] -> [TIMEOUT][2] > > > >[1]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6032/shard-glk6/igt@gem_persistent_rel...@forked-interruptible-thrashing.html > > > >[2]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12955/shard-glk7/igt@gem_persistent_rel...@forked-interruptible-thrashing.html > > > > > > Looks like an unrelated issue: on this GLK there are two HDMI displays > > > connected, so the change shouldn't make any diffence on it. The change > > > only affects the DP detect and hotplug paths, where we'll do now an > > > async power domain put. > > > > There's no history of glk locking up there, > > > > > The machine is still up when the problem happens, the test seems to get > > > stuck and aborted by the test runner (after ~6mins according to [1]). > > > > > > [43/82] (762s left) gem_persistent_relocs (forked-interruptible-thrashing) > > > Starting subtest: forked-interruptible-thrashing > > > Timeout. Killing the current test with SIGQUIT. > > > Timeout. Killing the current test with SIGKILL. > > > > and yet it locked up sufficiently to not respond to a signal, suggesting > > an oops (the test takes 3s normally on glk). > > No pstore logs either. I also noticed that the run [1] above resulted in > an incomplete, if that's indicative of anything. The same goes for the > previous Patchwork_12954 run. For reference what we discussed on IRC: There is also a previous Trybot run on SKL that hang in the same test in a similar way: https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_4242/shard-skl9/igt%40gem_persistent_relocs%40forked-interruptible-thrashing.html We're missing stack dumps to better isolate the problem, but based on the above it's unlikely to be caused by the changes in this patchset. Chris suggested cat /proc/*/stack on timeout and ptracing the child from the IGT runner, adding Petri for that. I'm trying to repro the problem on SKL/GLK with and without this patchset, so far I didn't hit the issue. I opened the following bug to capture the findings: https://bugs.freedesktop.org/show_bug.cgi?id=110618 and will check out Chris' patchset that may be related/fix the problem: https://patchwork.freedesktop.org/series/60257/ --Imre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] RFC: console: hack up console_lock more v2
On Mon, May 06, 2019 at 10:26:28AM +0200, Petr Mladek wrote: > On Mon 2019-05-06 10:16:14, Petr Mladek wrote: > > On Mon 2019-05-06 09:45:53, Daniel Vetter wrote: > > > console_trylock, called from within printk, can be called from pretty > > > much anywhere. Including try_to_wake_up. Note that this isn't common, > > > usually the box is in pretty bad shape at that point already. But it > > > really doesn't help when then lockdep jumps in and spams the logs, > > > potentially obscuring the real backtrace we're really interested in. > > > One case I've seen (slightly simplified backtrace): > > > > > > Call Trace: > > > > > > console_trylock+0xe/0x60 > > > vprintk_emit+0xf1/0x320 > > > printk+0x4d/0x69 > > > __warn_printk+0x46/0x90 > > > native_smp_send_reschedule+0x2f/0x40 > > > check_preempt_curr+0x81/0xa0 > > > ttwu_do_wakeup+0x14/0x220 > > > try_to_wake_up+0x218/0x5f0 > > > > try_to_wake_up() takes p->pi_lock. It could deadlock because it > > can get called recursively from printk_safe_up(). > > > > And there are more locks taken from try_to_wake_up(), for example, > > __task_rq_lock() taken from ttwu_remote(). > > > > IMHO, the most reliable solution would be do call the entire > > up_console_sem() from printk deferred context. We could assign > > few bytes for this context in the per-CPU printk_deferred > > variable. > > Ah, I was too fast and did the same mistake. This won't help because > it would still call try_to_wake_up() recursively. Uh :-/ > We need to call all printk's that can be called under locks > taken in try_to_wake_up() path in printk deferred context. > Unfortunately it is whack a mole approach. Hm since it's whack-a-mole anyway, what about converting the WARN_ON into a prinkt_deferred, like all the other scheduler related code? Feels a notch more consistent to me than leaking the printk_context into areas it wasn't really meant built for. Scheduler code already fully subscribed to the whack-a-mole approach after all. This would mean we drop the backtrace from the native_smp_send_reschedule, or maybe we need a printk_deferred_backtrace()? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] RFC: console: hack up console_trylock more
On Mon, May 6, 2019 at 9:48 AM Petr Mladek wrote: > On Mon 2019-05-06 09:11:37, Daniel Vetter wrote: > > On Fri, May 3, 2019 at 5:14 PM Petr Mladek wrote: > > > On Thu 2019-05-02 16:16:43, Daniel Vetter wrote: > > > > console_trylock, called from within printk, can be called from pretty > > > > much anywhere. Including try_to_wake_up. Note that this isn't common, > > > > usually the box is in pretty bad shape at that point already. But it > > > > really doesn't help when then lockdep jumps in and spams the logs, > > > > potentially obscuring the real backtrace we're really interested in. > > > > One case I've seen (slightly simplified backtrace): > > > > > > > > Call Trace: > > > > > > > > console_trylock+0xe/0x60 > > > > vprintk_emit+0xf1/0x320 > > > > printk+0x4d/0x69 > > > > __warn_printk+0x46/0x90 > > > > native_smp_send_reschedule+0x2f/0x40 > > > > check_preempt_curr+0x81/0xa0 > > > > ttwu_do_wakeup+0x14/0x220 > > > > try_to_wake_up+0x218/0x5f0 > > > > pollwake+0x6f/0x90 > > > > credit_entropy_bits+0x204/0x310 > > > > add_interrupt_randomness+0x18f/0x210 > > > > handle_irq+0x67/0x160 > > > > do_IRQ+0x5e/0x130 > > > > common_interrupt+0xf/0xf > > > > > > > > > > > > This alone isn't a problem, but the spinlock in the semaphore is also > > > > still held while waking up waiters (up() -> __up() -> try_to_wake_up() > > > > callchain), which then closes the runqueue vs. semaphore.lock loop, > > > > and upsets lockdep, which issues a circular locking splat to dmesg. > > > > Worse it upsets developers, since we don't want to spam dmesg with > > > > clutter when the machine is dying already. > > > > > > > > Fix this by creating a __down_trylock which only trylocks the > > > > semaphore.lock. This isn't correct in full generality, but good enough > > > > for console_lock: > > > > > > > > - there's only ever one console_lock holder, we won't fail spuriously > > > > because someone is doing a down() or up() while there's still room > > > > (unlike other semaphores with count > 1). > > > > > > > > - console_unlock() has one massive retry loop, which will catch anyone > > > > who races the trylock against the up(). This makes sure that no > > > > printk lines will get lost. Making the trylock more racy therefore > > > > has no further impact. > > > > > > To be honest, I do not see how this could solve the problem. > > > > > > The circular dependency is still there. If the new __down_trylock() > > > succeeds then console_unlock() will get called in the same context > > > and it will still need to call up() -> try_to_wake_up(). > > > > > > Note that there are many other console_lock() callers that might > > > happen in parallel and might appear in the wait queue. > > > > Hm right. It's very rare we hit this in our CI and I don't know how to > > repro otherwise, so just threw this out at the wall to see if it > > sticks. I'll try and come up with a new trick then. > > Single messages are printed from scheduler via printk_deferred(). > WARN() might be solved by introducing printk deferred context, > see the per-cpu variable printk_context. I convinced myself that I can take the wake_up_process out from under the spinlock, for the limited case of the console lock. I think that's a cleaner and more robust fix than leaking printk_context trickery into the console_unlock code. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for RFC: console: hack up console_trylock more (rev2)
== Series Details == Series: RFC: console: hack up console_trylock more (rev2) URL : https://patchwork.freedesktop.org/series/60212/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6048 -> Patchwork_12968 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_12968 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_12968, 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_12968/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_12968: ### IGT changes ### Possible regressions * igt@i915_selftest@live_hangcheck: - fi-apl-guc: [PASS][1] -> [DMESG-FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6048/fi-apl-guc/igt@i915_selftest@live_hangcheck.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12968/fi-apl-guc/igt@i915_selftest@live_hangcheck.html Warnings * igt@runner@aborted: - fi-apl-guc: [FAIL][3] ([fdo#108622] / [fdo#109720]) -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6048/fi-apl-guc/igt@run...@aborted.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12968/fi-apl-guc/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_12968 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live_workarounds: - fi-icl-y: [PASS][5] -> [INCOMPLETE][6] ([fdo#107713] / [fdo#110581]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6048/fi-icl-y/igt@i915_selftest@live_workarounds.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12968/fi-icl-y/igt@i915_selftest@live_workarounds.html Possible fixes * igt@i915_selftest@live_execlists: - fi-apl-guc: [INCOMPLETE][7] ([fdo#103927] / [fdo#109720] / [fdo#110581]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6048/fi-apl-guc/igt@i915_selftest@live_execlists.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12968/fi-apl-guc/igt@i915_selftest@live_execlists.html * igt@kms_flip@basic-flip-vs-wf_vblank: - fi-bwr-2160:[FAIL][9] ([fdo#100368]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6048/fi-bwr-2160/igt@kms_flip@basic-flip-vs-wf_vblank.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12968/fi-bwr-2160/igt@kms_flip@basic-flip-vs-wf_vblank.html [fdo#100368]: https://bugs.freedesktop.org/show_bug.cgi?id=100368 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622 [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720 [fdo#110581]: https://bugs.freedesktop.org/show_bug.cgi?id=110581 Participating hosts (52 -> 45) -- Additional (1): fi-bsw-n3050 Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_6048 -> Patchwork_12968 CI_DRM_6048: 896b156d0aa15d20a798e528ff7e5d529fbf26ae @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4972: f052e49a43cc9704ea5f240df15dd9d3dfed68ab @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12968: 679d117ff9c33340493d143534e192ce490943dc @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 679d117ff9c3 RFC: console: hack up console_lock more v2 == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12968/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] RFC: console: hack up console_lock more v2
On Mon 2019-05-06 10:16:14, Petr Mladek wrote: > On Mon 2019-05-06 09:45:53, Daniel Vetter wrote: > > console_trylock, called from within printk, can be called from pretty > > much anywhere. Including try_to_wake_up. Note that this isn't common, > > usually the box is in pretty bad shape at that point already. But it > > really doesn't help when then lockdep jumps in and spams the logs, > > potentially obscuring the real backtrace we're really interested in. > > One case I've seen (slightly simplified backtrace): > > > > Call Trace: > > > > console_trylock+0xe/0x60 > > vprintk_emit+0xf1/0x320 > > printk+0x4d/0x69 > > __warn_printk+0x46/0x90 > > native_smp_send_reschedule+0x2f/0x40 > > check_preempt_curr+0x81/0xa0 > > ttwu_do_wakeup+0x14/0x220 > > try_to_wake_up+0x218/0x5f0 > > try_to_wake_up() takes p->pi_lock. It could deadlock because it > can get called recursively from printk_safe_up(). > > And there are more locks taken from try_to_wake_up(), for example, > __task_rq_lock() taken from ttwu_remote(). > > IMHO, the most reliable solution would be do call the entire > up_console_sem() from printk deferred context. We could assign > few bytes for this context in the per-CPU printk_deferred > variable. Ah, I was too fast and did the same mistake. This won't help because it would still call try_to_wake_up() recursively. We need to call all printk's that can be called under locks taken in try_to_wake_up() path in printk deferred context. Unfortunately it is whack a mole approach. Best Regards, Petr ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] RFC: console: hack up console_lock more v2
On Mon 2019-05-06 09:45:53, Daniel Vetter wrote: > console_trylock, called from within printk, can be called from pretty > much anywhere. Including try_to_wake_up. Note that this isn't common, > usually the box is in pretty bad shape at that point already. But it > really doesn't help when then lockdep jumps in and spams the logs, > potentially obscuring the real backtrace we're really interested in. > One case I've seen (slightly simplified backtrace): > > Call Trace: > > console_trylock+0xe/0x60 > vprintk_emit+0xf1/0x320 > printk+0x4d/0x69 > __warn_printk+0x46/0x90 > native_smp_send_reschedule+0x2f/0x40 > check_preempt_curr+0x81/0xa0 > ttwu_do_wakeup+0x14/0x220 > try_to_wake_up+0x218/0x5f0 try_to_wake_up() takes p->pi_lock. It could deadlock because it can get called recursively from printk_safe_up(). And there are more locks taken from try_to_wake_up(), for example, __task_rq_lock() taken from ttwu_remote(). IMHO, the most reliable solution would be do call the entire up_console_sem() from printk deferred context. We could assign few bytes for this context in the per-CPU printk_deferred variable. Best Regards, Petr ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] RFC: console: hack up console_lock more v2
On Mon 2019-05-06 09:45:53, Daniel Vetter wrote: > console_trylock, called from within printk, can be called from pretty > much anywhere. Including try_to_wake_up. Note that this isn't common, > usually the box is in pretty bad shape at that point already. But it > really doesn't help when then lockdep jumps in and spams the logs, > potentially obscuring the real backtrace we're really interested in. > One case I've seen (slightly simplified backtrace): > > Call Trace: > > console_trylock+0xe/0x60 > vprintk_emit+0xf1/0x320 > printk+0x4d/0x69 > __warn_printk+0x46/0x90 > native_smp_send_reschedule+0x2f/0x40 > check_preempt_curr+0x81/0xa0 > ttwu_do_wakeup+0x14/0x220 > try_to_wake_up+0x218/0x5f0 try_to_wake_up() takes p->pi_lock. It could deadlock because it can get called recursively from printk_safe_up(). And there are more locks taken from try_to_wake_up(), for example, __task_rq_lock() taken from ttwu_remote(). IMHO, the most reliable solution would be do call the entire up_console_sem() from printk deferred context. We could assign few bytes for this context in the per-CPU printk_deferred variable. Best Regards, Petr ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for RFC: console: hack up console_trylock more (rev2)
== Series Details == Series: RFC: console: hack up console_trylock more (rev2) URL : https://patchwork.freedesktop.org/series/60212/ State : warning == Summary == $ dim checkpatch origin/drm-tip 679d117ff9c3 RFC: console: hack up console_lock more v2 -:74: CHECK:AVOID_EXTERNS: extern prototypes should be avoided in .h files #74: FILE: include/linux/semaphore.h:44: +extern void printk_safe_up(struct semaphore *sem); -:132: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 1 checks, 52 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 1/1] drm/fb-helper: Avoid race with DRM userspace
On Sun, May 05, 2019 at 11:16:54AM +0200, Noralf Trønnes wrote:
>
>
> Den 04.05.2019 14.34, skrev Noralf Trønnes:
> >
> >
> > Den 25.04.2019 10.31, skrev Noralf Trønnes:
> >> drm_fb_helper_is_bound() is used to check if DRM userspace is in control.
> >> This is done by looking at the fb on the primary plane. By the time
> >> fb-helper gets around to committing, it's possible that the facts have
> >> changed.
> >>
> >> Avoid this race by holding the drm_device->master_mutex lock while
> >> committing. When DRM userspace does its first open, it will now wait
> >> until fb-helper is done. The helper will stay away if there's a master.
> >>
> >> Locking rule: Always take the fb-helper lock first.
> >>
> >> v2:
> >> - Remove drm_fb_helper_is_bound() (Daniel Vetter)
> >> - No need to check fb_helper->dev->master in
> >> drm_fb_helper_single_fb_probe(), restore_fbdev_mode() has the check.
> >>
> >> Suggested-by: Daniel Vetter
> >> Signed-off-by: Noralf Trønnes
> >> Reviewed-by: Daniel Vetter
> >> ---
> >> drivers/gpu/drm/drm_auth.c | 20
> >> drivers/gpu/drm/drm_fb_helper.c | 90 -
> >> drivers/gpu/drm/drm_internal.h | 2 +
> >> 3 files changed, 67 insertions(+), 45 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
> >> index 1669c42c40ed..db199807b7dc 100644
> >> --- a/drivers/gpu/drm/drm_auth.c
> >> +++ b/drivers/gpu/drm/drm_auth.c
> >> @@ -368,3 +368,23 @@ void drm_master_put(struct drm_master **master)
> >>*master = NULL;
> >> }
> >> EXPORT_SYMBOL(drm_master_put);
> >> +
> >> +/* Used by drm_client and drm_fb_helper */
> >> +bool drm_master_internal_acquire(struct drm_device *dev)
> >> +{
> >> + mutex_lock(>master_mutex);
> >> + if (dev->master) {
> >> + mutex_unlock(>master_mutex);
> >> + return false;
> >> + }
> >> +
> >> + return true;
> >> +}
> >> +EXPORT_SYMBOL(drm_master_internal_acquire);
> >> +
> >> +/* Used by drm_client and drm_fb_helper */
> >> +void drm_master_internal_release(struct drm_device *dev)
> >> +{
> >> + mutex_unlock(>master_mutex);
> >> +}
> >> +EXPORT_SYMBOL(drm_master_internal_release);
> >> diff --git a/drivers/gpu/drm/drm_fb_helper.c
> >> b/drivers/gpu/drm/drm_fb_helper.c
> >> index 2339f0f8f5a8..578428461391 100644
> >> --- a/drivers/gpu/drm/drm_fb_helper.c
> >> +++ b/drivers/gpu/drm/drm_fb_helper.c
> >> @@ -44,6 +44,7 @@
> >>
> >> #include "drm_crtc_internal.h"
> >> #include "drm_crtc_helper_internal.h"
> >> +#include "drm_internal.h"
> >>
> >> static bool drm_fbdev_emulation = true;
> >> module_param_named(fbdev_emulation, drm_fbdev_emulation, bool, 0600);
> >> @@ -509,7 +510,7 @@ static int restore_fbdev_mode_legacy(struct
> >> drm_fb_helper *fb_helper)
> >>return ret;
> >> }
> >>
> >> -static int restore_fbdev_mode(struct drm_fb_helper *fb_helper)
> >> +static int restore_fbdev_mode_force(struct drm_fb_helper *fb_helper)
> >> {
> >>struct drm_device *dev = fb_helper->dev;
> >>
> >> @@ -519,6 +520,21 @@ static int restore_fbdev_mode(struct drm_fb_helper
> >> *fb_helper)
> >>return restore_fbdev_mode_legacy(fb_helper);
> >> }
> >>
> >> +static int restore_fbdev_mode(struct drm_fb_helper *fb_helper)
> >> +{
> >> + struct drm_device *dev = fb_helper->dev;
> >> + int ret;
> >> +
> >> + if (!drm_master_internal_acquire(dev))
> >> + return -EBUSY;
> >> +
> >> + ret = restore_fbdev_mode_force(fb_helper);
> >> +
> >> + drm_master_internal_release(dev);
> >> +
> >> + return ret;
> >> +}
> >> +
> >> /**
> >> * drm_fb_helper_restore_fbdev_mode_unlocked - restore fbdev configuration
> >> * @fb_helper: driver-allocated fbdev helper, can be NULL
> >
> > The Intel CI doesn't like this patch. AFAICT the reason is that the
> > igt@kms_fbcon_fbt@psr-suspend test expects fbcon to work while it has an
> > open fd that is master. This doesn't match the new rule of bailing out
> > if there's a master.
> >
> > Adding this debug output:
> >
> > @@ -558,6 +558,17 @@ int
> > drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper *fb_helper)
> > return 0;
> >
> > mutex_lock(_helper->lock);
> > +if (READ_ONCE(fb_helper->dev->master)) {
> > + int level = default_message_loglevel;
> > +
> > + default_message_loglevel = LOGLEVEL_DEBUG;
> > + printk("\n");
> > + printk("\n");
> > + printk("%s\n", __func__);
> > + printk("THERE IS A MASTER\n");
> > + dump_stack();
> > + default_message_loglevel = level;
> > +}
> > ret = restore_fbdev_mode_force(fb_helper);
> >
> > do_delayed = fb_helper->delayed_hotplug;
> >
> > Gives these log entries:
> >
> > <7> [1857.940072] drm_fb_helper_restore_fbdev_mode_unlocked
> > <7> [1857.940074] THERE IS A MASTER
> > <7> [1857.940079] CPU: 4 PID: 8209 Comm: kms_fbcon_fbt Tainted: G U
> > 5.1.0-rc7-CI-Trybot_4252+ #1
> > <7> [1857.940081] Hardware name: Intel Corporation Ice Lake Client
> > Platform/IceLake U DDR4
Re: [Intel-gfx] [PATCH] RFC: console: hack up console_trylock more
On Mon 2019-05-06 09:11:37, Daniel Vetter wrote: > On Fri, May 3, 2019 at 5:14 PM Petr Mladek wrote: > > On Thu 2019-05-02 16:16:43, Daniel Vetter wrote: > > > console_trylock, called from within printk, can be called from pretty > > > much anywhere. Including try_to_wake_up. Note that this isn't common, > > > usually the box is in pretty bad shape at that point already. But it > > > really doesn't help when then lockdep jumps in and spams the logs, > > > potentially obscuring the real backtrace we're really interested in. > > > One case I've seen (slightly simplified backtrace): > > > > > > Call Trace: > > > > > > console_trylock+0xe/0x60 > > > vprintk_emit+0xf1/0x320 > > > printk+0x4d/0x69 > > > __warn_printk+0x46/0x90 > > > native_smp_send_reschedule+0x2f/0x40 > > > check_preempt_curr+0x81/0xa0 > > > ttwu_do_wakeup+0x14/0x220 > > > try_to_wake_up+0x218/0x5f0 > > > pollwake+0x6f/0x90 > > > credit_entropy_bits+0x204/0x310 > > > add_interrupt_randomness+0x18f/0x210 > > > handle_irq+0x67/0x160 > > > do_IRQ+0x5e/0x130 > > > common_interrupt+0xf/0xf > > > > > > > > > This alone isn't a problem, but the spinlock in the semaphore is also > > > still held while waking up waiters (up() -> __up() -> try_to_wake_up() > > > callchain), which then closes the runqueue vs. semaphore.lock loop, > > > and upsets lockdep, which issues a circular locking splat to dmesg. > > > Worse it upsets developers, since we don't want to spam dmesg with > > > clutter when the machine is dying already. > > > > > > Fix this by creating a __down_trylock which only trylocks the > > > semaphore.lock. This isn't correct in full generality, but good enough > > > for console_lock: > > > > > > - there's only ever one console_lock holder, we won't fail spuriously > > > because someone is doing a down() or up() while there's still room > > > (unlike other semaphores with count > 1). > > > > > > - console_unlock() has one massive retry loop, which will catch anyone > > > who races the trylock against the up(). This makes sure that no > > > printk lines will get lost. Making the trylock more racy therefore > > > has no further impact. > > > > To be honest, I do not see how this could solve the problem. > > > > The circular dependency is still there. If the new __down_trylock() > > succeeds then console_unlock() will get called in the same context > > and it will still need to call up() -> try_to_wake_up(). > > > > Note that there are many other console_lock() callers that might > > happen in parallel and might appear in the wait queue. > > Hm right. It's very rare we hit this in our CI and I don't know how to > repro otherwise, so just threw this out at the wall to see if it > sticks. I'll try and come up with a new trick then. Single messages are printed from scheduler via printk_deferred(). WARN() might be solved by introducing printk deferred context, see the per-cpu variable printk_context. Best Regards, Petr ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] RFC: console: hack up console_lock more v2
console_trylock, called from within printk, can be called from pretty
much anywhere. Including try_to_wake_up. Note that this isn't common,
usually the box is in pretty bad shape at that point already. But it
really doesn't help when then lockdep jumps in and spams the logs,
potentially obscuring the real backtrace we're really interested in.
One case I've seen (slightly simplified backtrace):
Call Trace:
console_trylock+0xe/0x60
vprintk_emit+0xf1/0x320
printk+0x4d/0x69
__warn_printk+0x46/0x90
native_smp_send_reschedule+0x2f/0x40
check_preempt_curr+0x81/0xa0
ttwu_do_wakeup+0x14/0x220
try_to_wake_up+0x218/0x5f0
pollwake+0x6f/0x90
credit_entropy_bits+0x204/0x310
add_interrupt_randomness+0x18f/0x210
handle_irq+0x67/0x160
do_IRQ+0x5e/0x130
common_interrupt+0xf/0xf
This alone isn't a problem, but the spinlock in the semaphore is also
still held while waking up waiters (up() -> __up() -> try_to_wake_up()
callchain), which then closes the runqueue vs. semaphore.lock loop,
and upsets lockdep, which issues a circular locking splat to dmesg.
Worse it upsets developers, since we don't want to spam dmesg with
clutter when the machine is dying already.
Fix this by creating a prinkt_safe_up() which calls wake_up_process
outside of the spinlock. This isn't correct in full generality, but
good enough for console_lock:
- console_lock doesn't use interruptible or killable or timeout down()
calls, hence an up() is the only thing that can wake up a process.
Hence the process can't get woken and killed and reaped while we try
to wake it up too.
- semaphore.c always updates the waiter list while under the spinlock,
so there's no other races. Specifically another process that races
with a quick console_lock/unlock while we've dropped the spinlock
already won't see our own waiter.
Also cc'ing John Ogness since perhaps his printk rework fixes this all
properly.
Signed-off-by: Daniel Vetter
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Will Deacon
Cc: Petr Mladek
Cc: Sergey Senozhatsky
Cc: Steven Rostedt
Cc: Daniel Vetter
Cc: John Ogness
Cc: linux-ker...@vger.kernel.org
---
v2: My first attempt at patching down_trylock didn't work (thanks to
Petr for pointing out), now try to have a special up() that breaks the
cycle.
-Daniel
---
include/linux/semaphore.h | 1 +
kernel/locking/semaphore.c | 31 +++
kernel/printk/printk.c | 2 +-
3 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/include/linux/semaphore.h b/include/linux/semaphore.h
index 11c86fbfeb98..7e839c72809d 100644
--- a/include/linux/semaphore.h
+++ b/include/linux/semaphore.h
@@ -41,6 +41,7 @@ extern int __must_check down_interruptible(struct semaphore
*sem);
extern int __must_check down_killable(struct semaphore *sem);
extern int __must_check down_trylock(struct semaphore *sem);
extern int __must_check down_timeout(struct semaphore *sem, long jiffies);
+extern void printk_safe_up(struct semaphore *sem);
extern void up(struct semaphore *sem);
#endif /* __LINUX_SEMAPHORE_H */
diff --git a/kernel/locking/semaphore.c b/kernel/locking/semaphore.c
index 561acdd39960..84675993dc59 100644
--- a/kernel/locking/semaphore.c
+++ b/kernel/locking/semaphore.c
@@ -197,6 +197,37 @@ struct semaphore_waiter {
bool up;
};
+/**
+ * printk_safe_up - release the semaphore in console_unlock
+ * @sem: the semaphore to release
+ *
+ * Release the semaphore. Unlike mutexes, up() may be called from any
+ * context and even by tasks which have never called down().
+ *
+ * NOTE: This is a special version of up() for console_unlock only. It is only
+ * safe if there are no killable, interruptible or timing out down() calls.
+ */
+void printk_safe_up(struct semaphore *sem)
+{
+ unsigned long flags;
+ struct semaphore_waiter *waiter = NULL;
+
+ raw_spin_lock_irqsave(>lock, flags);
+ if (likely(list_empty(>wait_list))) {
+ sem->count++;
+ } else {
+ waiter = list_first_entry(>wait_list,
+ struct semaphore_waiter, list);
+ list_del(>list);
+ waiter->up = true;
+ }
+ raw_spin_unlock_irqrestore(>lock, flags);
+
+ if (waiter)
+ wake_up_process(waiter->task);
+}
+EXPORT_SYMBOL(printk_safe_up);
+
/*
* Because this function is inlined, the 'state' parameter will be
* constant, and thus optimised away by the compiler. Likewise the
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 02ca827b8fac..62303929afda 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -234,7 +234,7 @@ static void __up_console_sem(unsigned long ip)
mutex_release(_lock_dep_map, 1, ip);
printk_safe_enter_irqsave(flags);
- up(_sem);
+ printk_safe_up(_sem);
printk_safe_exit_irqrestore(flags);
}
#define up_console_sem() __up_console_sem(_RET_IP_)
--
2.20.1
Re: [Intel-gfx] [PATCH] RFC: console: hack up console_trylock more
On Fri, May 3, 2019 at 5:14 PM Petr Mladek wrote: > On Thu 2019-05-02 16:16:43, Daniel Vetter wrote: > > console_trylock, called from within printk, can be called from pretty > > much anywhere. Including try_to_wake_up. Note that this isn't common, > > usually the box is in pretty bad shape at that point already. But it > > really doesn't help when then lockdep jumps in and spams the logs, > > potentially obscuring the real backtrace we're really interested in. > > One case I've seen (slightly simplified backtrace): > > > > Call Trace: > > > > console_trylock+0xe/0x60 > > vprintk_emit+0xf1/0x320 > > printk+0x4d/0x69 > > __warn_printk+0x46/0x90 > > native_smp_send_reschedule+0x2f/0x40 > > check_preempt_curr+0x81/0xa0 > > ttwu_do_wakeup+0x14/0x220 > > try_to_wake_up+0x218/0x5f0 > > pollwake+0x6f/0x90 > > credit_entropy_bits+0x204/0x310 > > add_interrupt_randomness+0x18f/0x210 > > handle_irq+0x67/0x160 > > do_IRQ+0x5e/0x130 > > common_interrupt+0xf/0xf > > > > > > This alone isn't a problem, but the spinlock in the semaphore is also > > still held while waking up waiters (up() -> __up() -> try_to_wake_up() > > callchain), which then closes the runqueue vs. semaphore.lock loop, > > and upsets lockdep, which issues a circular locking splat to dmesg. > > Worse it upsets developers, since we don't want to spam dmesg with > > clutter when the machine is dying already. > > > > Fix this by creating a __down_trylock which only trylocks the > > semaphore.lock. This isn't correct in full generality, but good enough > > for console_lock: > > > > - there's only ever one console_lock holder, we won't fail spuriously > > because someone is doing a down() or up() while there's still room > > (unlike other semaphores with count > 1). > > > > - console_unlock() has one massive retry loop, which will catch anyone > > who races the trylock against the up(). This makes sure that no > > printk lines will get lost. Making the trylock more racy therefore > > has no further impact. > > To be honest, I do not see how this could solve the problem. > > The circular dependency is still there. If the new __down_trylock() > succeeds then console_unlock() will get called in the same context > and it will still need to call up() -> try_to_wake_up(). > > Note that there are many other console_lock() callers that might > happen in parallel and might appear in the wait queue. Hm right. It's very rare we hit this in our CI and I don't know how to repro otherwise, so just threw this out at the wall to see if it sticks. I'll try and come up with a new trick then. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/icl: Set GCP_COLOR_INDICATION only for 10/12 bit deep color (rev8)
On 5/4/19 8:55 AM, Saarinen, Jani wrote: Hi, -Original Message- From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Aditya Swarup Sent: lauantai 4. toukokuuta 2019 2.04 To: intel-gfx@lists.freedesktop.org Cc: Peres, Martin Subject: Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/icl: Set GCP_COLOR_INDICATION only for 10/12 bit deep color (rev8) On Tue, Apr 30, 2019 at 01:46:15PM +, Patchwork wrote: == Series Details == Series: drm/i915/icl: Set GCP_COLOR_INDICATION only for 10/12 bit deep color (rev8) URL : https://patchwork.freedesktop.org/series/58912/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6012_full -> Patchwork_12900_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_12900_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_12900_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_12900_full: ### IGT changes ### Possible regressions * igt@gem_caching@read-writes: - shard-skl: [PASS][1] -> [INCOMPLETE][2] +6 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6012/shard- skl9/igt@gem_cach...@read-writes.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12900/shard-skl9/ig t@gem_cach...@read-writes.html * igt@gem_mmap_gtt@forked-big-copy-odd: - shard-skl: NOTRUN -> [INCOMPLETE][3] +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12900/shard-skl2/ig t@gem_mmap_...@forked-big-copy-odd.html Hi Martin, These failures shouldn't be due to my patch. Is there a separate bug filed for gem_caching and gem_mmap_gtt failures? Yes, this still I guess due to : https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12900/shard-skl2/run25.log => Tomi, still happening: https://bugs.freedesktop.org/show_bug.cgi?id=110581 Br, Jani This was fixed around IGT_4972 / CI_DRM_6026. We're looking at results from around CI_DRM_6012, so yes, 10min timeouts were still happening. Tomi Build changes - * Linux: CI_DRM_6012 -> Patchwork_12900 Tomi -- Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
