Re: [PATCH v15 13/17] IB, arm64: untag user pointers in ib_uverbs_(re)reg_mr()
On Mon, May 06, 2019 at 04:50:20PM -0300, Jason Gunthorpe wrote: > On Mon, May 06, 2019 at 06:30:59PM +0200, Andrey Konovalov wrote: > > This patch is a part of a series that extends arm64 kernel ABI to allow to > > pass tagged user pointers (with the top byte set to something else other > > than 0x00) as syscall arguments. > > > > ib_uverbs_(re)reg_mr() use provided user pointers for vma lookups (through > > e.g. mlx4_get_umem_mr()), which can only by done with untagged pointers. > > > > Untag user pointers in these functions. > > > > Signed-off-by: Andrey Konovalov > > --- > > drivers/infiniband/core/uverbs_cmd.c | 4 > > 1 file changed, 4 insertions(+) > > I think this is OK.. We should really get it tested though.. Leon? It can be done after v5.2-rc1. Thanks > > Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109649] [bisected][raven] gfx ring timeout when running clover apps
https://bugs.freedesktop.org/show_bug.cgi?id=109649 --- Comment #7 from Jan Vesely --- The workaround is still necessary in kernel 5.1.0. The failure mode is a bit different, it hangs just the application, not entire machine. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 3.18 10/10] gpu: ipu-v3: dp: fix CSC handling
From: Lucas Stach
[ Upstream commit d4fad0a426c6e26f48c9a7cdd21a7fe9c198d645 ]
Initialize the flow input colorspaces to unknown and reset to that value
when the channel gets disabled. This avoids the state getting mixed up
with a previous mode.
Also keep the CSC settings for the background flow intact when disabling
the foreground flow.
Root-caused-by: Jonathan Marek
Signed-off-by: Lucas Stach
Signed-off-by: Philipp Zabel
Signed-off-by: Sasha Levin
---
drivers/gpu/ipu-v3/ipu-dp.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-dp.c b/drivers/gpu/ipu-v3/ipu-dp.c
index 98686edbcdbb..33de3a1bac49 100644
--- a/drivers/gpu/ipu-v3/ipu-dp.c
+++ b/drivers/gpu/ipu-v3/ipu-dp.c
@@ -195,7 +195,8 @@ int ipu_dp_setup_channel(struct ipu_dp *dp,
ipu_dp_csc_init(flow, flow->foreground.in_cs, flow->out_cs,
DP_COM_CONF_CSC_DEF_BOTH);
} else {
- if (flow->foreground.in_cs == flow->out_cs)
+ if (flow->foreground.in_cs == IPUV3_COLORSPACE_UNKNOWN ||
+ flow->foreground.in_cs == flow->out_cs)
/*
* foreground identical to output, apply color
* conversion on background
@@ -261,6 +262,8 @@ void ipu_dp_disable_channel(struct ipu_dp *dp)
struct ipu_dp_priv *priv = flow->priv;
u32 reg, csc;
+ dp->in_cs = IPUV3_COLORSPACE_UNKNOWN;
+
if (!dp->foreground)
return;
@@ -268,8 +271,9 @@ void ipu_dp_disable_channel(struct ipu_dp *dp)
reg = readl(flow->base + DP_COM_CONF);
csc = reg & DP_COM_CONF_CSC_DEF_MASK;
- if (csc == DP_COM_CONF_CSC_DEF_FG)
- reg &= ~DP_COM_CONF_CSC_DEF_MASK;
+ reg &= ~DP_COM_CONF_CSC_DEF_MASK;
+ if (csc == DP_COM_CONF_CSC_DEF_BOTH || csc == DP_COM_CONF_CSC_DEF_BG)
+ reg |= DP_COM_CONF_CSC_DEF_BG;
reg &= ~DP_COM_CONF_FG_EN;
writel(reg, flow->base + DP_COM_CONF);
@@ -350,6 +354,8 @@ int ipu_dp_init(struct ipu_soc *ipu, struct device *dev,
unsigned long base)
mutex_init(&priv->mutex);
for (i = 0; i < IPUV3_NUM_FLOWS; i++) {
+ priv->flow[i].background.in_cs = IPUV3_COLORSPACE_UNKNOWN;
+ priv->flow[i].foreground.in_cs = IPUV3_COLORSPACE_UNKNOWN;
priv->flow[i].foreground.foreground = true;
priv->flow[i].base = priv->base + ipu_dp_flow_base[i];
priv->flow[i].priv = priv;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.4 14/14] gpu: ipu-v3: dp: fix CSC handling
From: Lucas Stach
[ Upstream commit d4fad0a426c6e26f48c9a7cdd21a7fe9c198d645 ]
Initialize the flow input colorspaces to unknown and reset to that value
when the channel gets disabled. This avoids the state getting mixed up
with a previous mode.
Also keep the CSC settings for the background flow intact when disabling
the foreground flow.
Root-caused-by: Jonathan Marek
Signed-off-by: Lucas Stach
Signed-off-by: Philipp Zabel
Signed-off-by: Sasha Levin
---
drivers/gpu/ipu-v3/ipu-dp.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-dp.c b/drivers/gpu/ipu-v3/ipu-dp.c
index 98686edbcdbb..33de3a1bac49 100644
--- a/drivers/gpu/ipu-v3/ipu-dp.c
+++ b/drivers/gpu/ipu-v3/ipu-dp.c
@@ -195,7 +195,8 @@ int ipu_dp_setup_channel(struct ipu_dp *dp,
ipu_dp_csc_init(flow, flow->foreground.in_cs, flow->out_cs,
DP_COM_CONF_CSC_DEF_BOTH);
} else {
- if (flow->foreground.in_cs == flow->out_cs)
+ if (flow->foreground.in_cs == IPUV3_COLORSPACE_UNKNOWN ||
+ flow->foreground.in_cs == flow->out_cs)
/*
* foreground identical to output, apply color
* conversion on background
@@ -261,6 +262,8 @@ void ipu_dp_disable_channel(struct ipu_dp *dp)
struct ipu_dp_priv *priv = flow->priv;
u32 reg, csc;
+ dp->in_cs = IPUV3_COLORSPACE_UNKNOWN;
+
if (!dp->foreground)
return;
@@ -268,8 +271,9 @@ void ipu_dp_disable_channel(struct ipu_dp *dp)
reg = readl(flow->base + DP_COM_CONF);
csc = reg & DP_COM_CONF_CSC_DEF_MASK;
- if (csc == DP_COM_CONF_CSC_DEF_FG)
- reg &= ~DP_COM_CONF_CSC_DEF_MASK;
+ reg &= ~DP_COM_CONF_CSC_DEF_MASK;
+ if (csc == DP_COM_CONF_CSC_DEF_BOTH || csc == DP_COM_CONF_CSC_DEF_BG)
+ reg |= DP_COM_CONF_CSC_DEF_BG;
reg &= ~DP_COM_CONF_FG_EN;
writel(reg, flow->base + DP_COM_CONF);
@@ -350,6 +354,8 @@ int ipu_dp_init(struct ipu_soc *ipu, struct device *dev,
unsigned long base)
mutex_init(&priv->mutex);
for (i = 0; i < IPUV3_NUM_FLOWS; i++) {
+ priv->flow[i].background.in_cs = IPUV3_COLORSPACE_UNKNOWN;
+ priv->flow[i].foreground.in_cs = IPUV3_COLORSPACE_UNKNOWN;
priv->flow[i].foreground.foreground = true;
priv->flow[i].base = priv->base + ipu_dp_flow_base[i];
priv->flow[i].priv = priv;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 22/25] gpu: ipu-v3: dp: fix CSC handling
From: Lucas Stach
[ Upstream commit d4fad0a426c6e26f48c9a7cdd21a7fe9c198d645 ]
Initialize the flow input colorspaces to unknown and reset to that value
when the channel gets disabled. This avoids the state getting mixed up
with a previous mode.
Also keep the CSC settings for the background flow intact when disabling
the foreground flow.
Root-caused-by: Jonathan Marek
Signed-off-by: Lucas Stach
Signed-off-by: Philipp Zabel
Signed-off-by: Sasha Levin
---
drivers/gpu/ipu-v3/ipu-dp.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-dp.c b/drivers/gpu/ipu-v3/ipu-dp.c
index 98686edbcdbb..33de3a1bac49 100644
--- a/drivers/gpu/ipu-v3/ipu-dp.c
+++ b/drivers/gpu/ipu-v3/ipu-dp.c
@@ -195,7 +195,8 @@ int ipu_dp_setup_channel(struct ipu_dp *dp,
ipu_dp_csc_init(flow, flow->foreground.in_cs, flow->out_cs,
DP_COM_CONF_CSC_DEF_BOTH);
} else {
- if (flow->foreground.in_cs == flow->out_cs)
+ if (flow->foreground.in_cs == IPUV3_COLORSPACE_UNKNOWN ||
+ flow->foreground.in_cs == flow->out_cs)
/*
* foreground identical to output, apply color
* conversion on background
@@ -261,6 +262,8 @@ void ipu_dp_disable_channel(struct ipu_dp *dp)
struct ipu_dp_priv *priv = flow->priv;
u32 reg, csc;
+ dp->in_cs = IPUV3_COLORSPACE_UNKNOWN;
+
if (!dp->foreground)
return;
@@ -268,8 +271,9 @@ void ipu_dp_disable_channel(struct ipu_dp *dp)
reg = readl(flow->base + DP_COM_CONF);
csc = reg & DP_COM_CONF_CSC_DEF_MASK;
- if (csc == DP_COM_CONF_CSC_DEF_FG)
- reg &= ~DP_COM_CONF_CSC_DEF_MASK;
+ reg &= ~DP_COM_CONF_CSC_DEF_MASK;
+ if (csc == DP_COM_CONF_CSC_DEF_BOTH || csc == DP_COM_CONF_CSC_DEF_BG)
+ reg |= DP_COM_CONF_CSC_DEF_BG;
reg &= ~DP_COM_CONF_FG_EN;
writel(reg, flow->base + DP_COM_CONF);
@@ -350,6 +354,8 @@ int ipu_dp_init(struct ipu_soc *ipu, struct device *dev,
unsigned long base)
mutex_init(&priv->mutex);
for (i = 0; i < IPUV3_NUM_FLOWS; i++) {
+ priv->flow[i].background.in_cs = IPUV3_COLORSPACE_UNKNOWN;
+ priv->flow[i].foreground.in_cs = IPUV3_COLORSPACE_UNKNOWN;
priv->flow[i].foreground.foreground = true;
priv->flow[i].base = priv->base + ipu_dp_flow_base[i];
priv->flow[i].priv = priv;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 20/25] drm/sun4i: Set device driver data at bind time for use in unbind
From: Paul Kocialkowski
[ Upstream commit 02b92adbe33e6dbd15dc6e32540b22f47c4ff0a2 ]
Our sun4i_drv_unbind gets the drm device using dev_get_drvdata.
However, that driver data is never set in sun4i_drv_bind.
Set it there to avoid getting a NULL pointer at unbind time.
Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
Signed-off-by: Paul Kocialkowski
Signed-off-by: Maxime Ripard
Link:
https://patchwork.freedesktop.org/patch/msgid/20190418132727.5128-3-paul.kocialkow...@bootlin.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 97828faf2a1f..d58991b06a47 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -137,6 +137,8 @@ static int sun4i_drv_bind(struct device *dev)
ret = -ENOMEM;
goto free_drm;
}
+
+ dev_set_drvdata(dev, drm);
drm->dev_private = drv;
drm_vblank_init(drm, 1);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 82/95] drm/rockchip: fix for mailbox read validation.
From: Damian Kos
[ Upstream commit e4056bbb6719fe713bfc4030ac78e8e97ddf7574 ]
This is basically the same fix as in
commit fa68d4f8476b ("drm/rockchip: fix for mailbox read size")
but for cdn_dp_mailbox_validate_receive function.
See patchwork.kernel.org/patch/10671981/ for details.
Signed-off-by: Damian Kos
Signed-off-by: Heiko Stuebner
Link:
https://patchwork.freedesktop.org/patch/msgid/1542640463-18332-1-git-send-email-d...@cadence.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/rockchip/cdn-dp-reg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
index 0ed7e91471f6..4df201d21f27 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
@@ -113,7 +113,7 @@ static int cdp_dp_mailbox_write(struct cdn_dp_device *dp,
u8 val)
static int cdn_dp_mailbox_validate_receive(struct cdn_dp_device *dp,
u8 module_id, u8 opcode,
- u8 req_size)
+ u16 req_size)
{
u32 mbox_size, i;
u8 header[4];
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 67/95] drm/rockchip: psr: do not dereference encoder before it is null checked.
From: Enric Balletbo i Serra
[ Upstream commit 4eda776c3cefcb1f01b2d85bd8753f67606282b5 ]
'encoder' is dereferenced before it is null sanity checked, hence we
potentially have a null pointer dereference bug. Instead, initialise
drm_drv from encoder->dev->dev_private after we are sure 'encoder' is
not null.
Fixes: 5182c1a556d7f ("drm/rockchip: add an common abstracted PSR driver")
Cc: sta...@vger.kernel.org
Signed-off-by: Enric Balletbo i Serra
Signed-off-by: Heiko Stuebner
Link:
https://patchwork.freedesktop.org/patch/msgid/20181013105654.11827-1-enric.balle...@collabora.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
index a553e182ff53..32e7dba2bf5e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
@@ -221,13 +221,15 @@ EXPORT_SYMBOL(rockchip_drm_psr_flush_all);
int rockchip_drm_psr_register(struct drm_encoder *encoder,
void (*psr_set)(struct drm_encoder *, bool enable))
{
- struct rockchip_drm_private *drm_drv = encoder->dev->dev_private;
+ struct rockchip_drm_private *drm_drv;
struct psr_drv *psr;
unsigned long flags;
if (!encoder || !psr_set)
return -EINVAL;
+ drm_drv = encoder->dev->dev_private;
+
psr = kzalloc(sizeof(struct psr_drv), GFP_KERNEL);
if (!psr)
return -ENOMEM;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[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 skl_setup_wm_l
[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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 28/95] drm/sun4i: Set device driver data at bind time for use in unbind
From: Paul Kocialkowski
[ Upstream commit 02b92adbe33e6dbd15dc6e32540b22f47c4ff0a2 ]
Our sun4i_drv_unbind gets the drm device using dev_get_drvdata.
However, that driver data is never set in sun4i_drv_bind.
Set it there to avoid getting a NULL pointer at unbind time.
Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
Signed-off-by: Paul Kocialkowski
Signed-off-by: Maxime Ripard
Link:
https://patchwork.freedesktop.org/patch/msgid/20190418132727.5128-3-paul.kocialkow...@bootlin.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 8d3c8070ed86..e09161cf312f 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -96,6 +96,8 @@ static int sun4i_drv_bind(struct device *dev)
ret = -ENOMEM;
goto free_drm;
}
+
+ dev_set_drvdata(dev, drm);
drm->dev_private = drv;
INIT_LIST_HEAD(&drv->engine_list);
INIT_LIST_HEAD(&drv->tcon_list);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 30/95] gpu: ipu-v3: dp: fix CSC handling
From: Lucas Stach
[ Upstream commit d4fad0a426c6e26f48c9a7cdd21a7fe9c198d645 ]
Initialize the flow input colorspaces to unknown and reset to that value
when the channel gets disabled. This avoids the state getting mixed up
with a previous mode.
Also keep the CSC settings for the background flow intact when disabling
the foreground flow.
Root-caused-by: Jonathan Marek
Signed-off-by: Lucas Stach
Signed-off-by: Philipp Zabel
Signed-off-by: Sasha Levin
---
drivers/gpu/ipu-v3/ipu-dp.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-dp.c b/drivers/gpu/ipu-v3/ipu-dp.c
index 9b2b3fa479c4..5e44ff1f2085 100644
--- a/drivers/gpu/ipu-v3/ipu-dp.c
+++ b/drivers/gpu/ipu-v3/ipu-dp.c
@@ -195,7 +195,8 @@ int ipu_dp_setup_channel(struct ipu_dp *dp,
ipu_dp_csc_init(flow, flow->foreground.in_cs, flow->out_cs,
DP_COM_CONF_CSC_DEF_BOTH);
} else {
- if (flow->foreground.in_cs == flow->out_cs)
+ if (flow->foreground.in_cs == IPUV3_COLORSPACE_UNKNOWN ||
+ flow->foreground.in_cs == flow->out_cs)
/*
* foreground identical to output, apply color
* conversion on background
@@ -261,6 +262,8 @@ void ipu_dp_disable_channel(struct ipu_dp *dp, bool sync)
struct ipu_dp_priv *priv = flow->priv;
u32 reg, csc;
+ dp->in_cs = IPUV3_COLORSPACE_UNKNOWN;
+
if (!dp->foreground)
return;
@@ -268,8 +271,9 @@ void ipu_dp_disable_channel(struct ipu_dp *dp, bool sync)
reg = readl(flow->base + DP_COM_CONF);
csc = reg & DP_COM_CONF_CSC_DEF_MASK;
- if (csc == DP_COM_CONF_CSC_DEF_FG)
- reg &= ~DP_COM_CONF_CSC_DEF_MASK;
+ reg &= ~DP_COM_CONF_CSC_DEF_MASK;
+ if (csc == DP_COM_CONF_CSC_DEF_BOTH || csc == DP_COM_CONF_CSC_DEF_BG)
+ reg |= DP_COM_CONF_CSC_DEF_BG;
reg &= ~DP_COM_CONF_FG_EN;
writel(reg, flow->base + DP_COM_CONF);
@@ -347,6 +351,8 @@ int ipu_dp_init(struct ipu_soc *ipu, struct device *dev,
unsigned long base)
mutex_init(&priv->mutex);
for (i = 0; i < IPUV3_NUM_FLOWS; i++) {
+ priv->flow[i].background.in_cs = IPUV3_COLORSPACE_UNKNOWN;
+ priv->flow[i].foreground.in_cs = IPUV3_COLORSPACE_UNKNOWN;
priv->flow[i].foreground.foreground = true;
priv->flow[i].base = priv->base + ipu_dp_flow_base[i];
priv->flow[i].priv = priv;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 31/95] drm/imx: don't skip DP channel disable for background plane
From: Lucas Stach [ Upstream commit 7bcde275eb1d0ac8793c77c7e666a886eb16633d ] In order to make sure that the plane color space gets reset correctly. Signed-off-by: Lucas Stach Signed-off-by: Philipp Zabel Signed-off-by: Sasha Levin --- drivers/gpu/drm/imx/ipuv3-crtc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c index d976391dfa31..957fbf8c55eb 100644 --- a/drivers/gpu/drm/imx/ipuv3-crtc.c +++ b/drivers/gpu/drm/imx/ipuv3-crtc.c @@ -79,7 +79,7 @@ static void ipu_crtc_disable_planes(struct ipu_crtc *ipu_crtc, if (disable_partial) ipu_plane_disable(ipu_crtc->plane[1], true); if (disable_full) - ipu_plane_disable(ipu_crtc->plane[0], false); + ipu_plane_disable(ipu_crtc->plane[0], true); } static void ipu_crtc_atomic_disable(struct drm_crtc *crtc, -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 49/81] drm/sun4i: Set device driver data at bind time for use in unbind
From: Paul Kocialkowski
[ Upstream commit 02b92adbe33e6dbd15dc6e32540b22f47c4ff0a2 ]
Our sun4i_drv_unbind gets the drm device using dev_get_drvdata.
However, that driver data is never set in sun4i_drv_bind.
Set it there to avoid getting a NULL pointer at unbind time.
Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
Signed-off-by: Paul Kocialkowski
Signed-off-by: Maxime Ripard
Link:
https://patchwork.freedesktop.org/patch/msgid/20190418132727.5128-3-paul.kocialkow...@bootlin.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 8b0cd08034e0..7cac01c72c02 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -92,6 +92,8 @@ static int sun4i_drv_bind(struct device *dev)
ret = -ENOMEM;
goto free_drm;
}
+
+ dev_set_drvdata(dev, drm);
drm->dev_private = drv;
INIT_LIST_HEAD(&drv->frontend_list);
INIT_LIST_HEAD(&drv->engine_list);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 54/81] drm/imx: don't skip DP channel disable for background plane
From: Lucas Stach [ Upstream commit 7bcde275eb1d0ac8793c77c7e666a886eb16633d ] In order to make sure that the plane color space gets reset correctly. Signed-off-by: Lucas Stach Signed-off-by: Philipp Zabel Signed-off-by: Sasha Levin --- drivers/gpu/drm/imx/ipuv3-crtc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c index 7d4b710b837a..11e2dcdd6b18 100644 --- a/drivers/gpu/drm/imx/ipuv3-crtc.c +++ b/drivers/gpu/drm/imx/ipuv3-crtc.c @@ -78,7 +78,7 @@ static void ipu_crtc_disable_planes(struct ipu_crtc *ipu_crtc, if (disable_partial) ipu_plane_disable(ipu_crtc->plane[1], true); if (disable_full) - ipu_plane_disable(ipu_crtc->plane[0], false); + ipu_plane_disable(ipu_crtc->plane[0], true); } static void ipu_crtc_atomic_disable(struct drm_crtc *crtc, -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 50/81] drm/sun4i: Fix component unbinding and component master deletion
From: Paul Kocialkowski
[ Upstream commit f5a9ed867c83875546c9aadd4ed8e785e9adcc3c ]
For our component-backed driver to be properly removed, we need to
delete the component master in sun4i_drv_remove and make sure to call
component_unbind_all in the master's unbind so that all components are
unbound when the master is.
Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
Signed-off-by: Paul Kocialkowski
Signed-off-by: Maxime Ripard
Link:
https://patchwork.freedesktop.org/patch/msgid/20190418132727.5128-4-paul.kocialkow...@bootlin.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 7cac01c72c02..62703630090a 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -160,6 +160,8 @@ static void sun4i_drv_unbind(struct device *dev)
drm_mode_config_cleanup(drm);
of_reserved_mem_device_release(dev);
drm_dev_put(drm);
+
+ component_unbind_all(dev, NULL);
}
static const struct component_master_ops sun4i_drv_master_ops = {
@@ -407,6 +409,8 @@ static int sun4i_drv_probe(struct platform_device *pdev)
static int sun4i_drv_remove(struct platform_device *pdev)
{
+ component_master_del(&pdev->dev, &sun4i_drv_master_ops);
+
return 0;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 53/81] gpu: ipu-v3: dp: fix CSC handling
From: Lucas Stach
[ Upstream commit d4fad0a426c6e26f48c9a7cdd21a7fe9c198d645 ]
Initialize the flow input colorspaces to unknown and reset to that value
when the channel gets disabled. This avoids the state getting mixed up
with a previous mode.
Also keep the CSC settings for the background flow intact when disabling
the foreground flow.
Root-caused-by: Jonathan Marek
Signed-off-by: Lucas Stach
Signed-off-by: Philipp Zabel
Signed-off-by: Sasha Levin
---
drivers/gpu/ipu-v3/ipu-dp.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-dp.c b/drivers/gpu/ipu-v3/ipu-dp.c
index 9b2b3fa479c4..5e44ff1f2085 100644
--- a/drivers/gpu/ipu-v3/ipu-dp.c
+++ b/drivers/gpu/ipu-v3/ipu-dp.c
@@ -195,7 +195,8 @@ int ipu_dp_setup_channel(struct ipu_dp *dp,
ipu_dp_csc_init(flow, flow->foreground.in_cs, flow->out_cs,
DP_COM_CONF_CSC_DEF_BOTH);
} else {
- if (flow->foreground.in_cs == flow->out_cs)
+ if (flow->foreground.in_cs == IPUV3_COLORSPACE_UNKNOWN ||
+ flow->foreground.in_cs == flow->out_cs)
/*
* foreground identical to output, apply color
* conversion on background
@@ -261,6 +262,8 @@ void ipu_dp_disable_channel(struct ipu_dp *dp, bool sync)
struct ipu_dp_priv *priv = flow->priv;
u32 reg, csc;
+ dp->in_cs = IPUV3_COLORSPACE_UNKNOWN;
+
if (!dp->foreground)
return;
@@ -268,8 +271,9 @@ void ipu_dp_disable_channel(struct ipu_dp *dp, bool sync)
reg = readl(flow->base + DP_COM_CONF);
csc = reg & DP_COM_CONF_CSC_DEF_MASK;
- if (csc == DP_COM_CONF_CSC_DEF_FG)
- reg &= ~DP_COM_CONF_CSC_DEF_MASK;
+ reg &= ~DP_COM_CONF_CSC_DEF_MASK;
+ if (csc == DP_COM_CONF_CSC_DEF_BOTH || csc == DP_COM_CONF_CSC_DEF_BG)
+ reg |= DP_COM_CONF_CSC_DEF_BG;
reg &= ~DP_COM_CONF_FG_EN;
writel(reg, flow->base + DP_COM_CONF);
@@ -347,6 +351,8 @@ int ipu_dp_init(struct ipu_soc *ipu, struct device *dev,
unsigned long base)
mutex_init(&priv->mutex);
for (i = 0; i < IPUV3_NUM_FLOWS; i++) {
+ priv->flow[i].background.in_cs = IPUV3_COLORSPACE_UNKNOWN;
+ priv->flow[i].foreground.in_cs = IPUV3_COLORSPACE_UNKNOWN;
priv->flow[i].foreground.foreground = true;
priv->flow[i].base = priv->base + ipu_dp_flow_base[i];
priv->flow[i].priv = priv;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 59/81] drm/sun4i: Unbind components before releasing DRM and memory
From: Paul Kocialkowski
[ Upstream commit e02bc29b2cfa7806830d6da8b2322cddd67e8dfe ]
Our components may still be using the DRM device driver (if only to
access our driver's private data), so make sure to unbind them before
the final drm_dev_put.
Also release our reserved memory after component unbind instead of
before to match reverse creation order.
Fixes: f5a9ed867c83 ("drm/sun4i: Fix component unbinding and component master
deletion")
Signed-off-by: Paul Kocialkowski
Reviewed-by: Chen-Yu Tsai
Link:
https://patchwork.freedesktop.org/patch/msgid/20190424090413.6918-1-paul.kocialkow...@bootlin.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 62703630090a..57f61ec4bc6b 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -158,10 +158,11 @@ static void sun4i_drv_unbind(struct device *dev)
drm_kms_helper_poll_fini(drm);
sun4i_framebuffer_free(drm);
drm_mode_config_cleanup(drm);
- of_reserved_mem_device_release(dev);
- drm_dev_put(drm);
component_unbind_all(dev, NULL);
+ of_reserved_mem_device_release(dev);
+
+ drm_dev_put(drm);
}
static const struct component_master_ops sun4i_drv_master_ops = {
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 28/81] drm/amd/display: If one stream full updates, full update all planes
From: David Francis
[ Upstream commit c238bfe0be9ef7420f7669a69e27c8c8f4d8a568 ]
[Why]
On some compositors, with two monitors attached, VT terminal
switch can cause a graphical issue by the following means:
There are two streams, one for each monitor. Each stream has one
plane
current state:
M1:S1->P1
M2:S2->P2
The user calls for a terminal switch and a commit is made to
change both planes to linear swizzle mode. In atomic check,
a new dc_state is constructed with new planes on each stream
new state:
M1:S1->P3
M2:S2->P4
In commit tail, each stream is committed, one at a time. The first
stream (S1) updates properly, triggerring a full update and replacing
the state
current state:
M1:S1->P3
M2:S2->P4
The update for S2 comes in, but dc detects that there is no difference
between the stream and plane in the new and current states, and so
triggers a fast update. The fast update does not program swizzle,
so the second monitor is corrupted
[How]
Add a flag to dc_plane_state that forces full updates
When a stream undergoes a full update, set this flag on all changed
planes, then clear it on the current stream
Subsequent streams will get full updates as a result
Signed-off-by: David Francis
Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Roman Li
Acked-by: Bhawanpreet Lakha
Acked-by: Nicholas Kazlauskas
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 19 +++
drivers/gpu/drm/amd/display/dc/dc.h | 3 +++
2 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index bb0cda727605..e3f5e5d6f0c1 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -1213,6 +1213,11 @@ static enum surface_update_type det_surface_update(const
struct dc *dc,
return UPDATE_TYPE_FULL;
}
+ if (u->surface->force_full_update) {
+ update_flags->bits.full_update = 1;
+ return UPDATE_TYPE_FULL;
+ }
+
type = get_plane_info_update_type(u);
elevate_update_type(&overall_type, type);
@@ -1467,6 +1472,14 @@ void dc_commit_updates_for_stream(struct dc *dc,
}
dc_resource_state_copy_construct(state, context);
+
+ for (i = 0; i < dc->res_pool->pipe_count; i++) {
+ struct pipe_ctx *new_pipe =
&context->res_ctx.pipe_ctx[i];
+ struct pipe_ctx *old_pipe =
&dc->current_state->res_ctx.pipe_ctx[i];
+
+ if (new_pipe->plane_state && new_pipe->plane_state !=
old_pipe->plane_state)
+ new_pipe->plane_state->force_full_update = true;
+ }
}
@@ -1510,6 +1523,12 @@ void dc_commit_updates_for_stream(struct dc *dc,
dc->current_state = context;
dc_release_state(old);
+ for (i = 0; i < dc->res_pool->pipe_count; i++) {
+ struct pipe_ctx *pipe_ctx =
&context->res_ctx.pipe_ctx[i];
+
+ if (pipe_ctx->plane_state && pipe_ctx->stream == stream)
+ pipe_ctx->plane_state->force_full_update =
false;
+ }
}
/*let's use current_state to update watermark etc*/
if (update_type >= UPDATE_TYPE_FULL)
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h
b/drivers/gpu/drm/amd/display/dc/dc.h
index 6c9990bef267..4094b4f50111 100644
--- a/drivers/gpu/drm/amd/display/dc/dc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc.h
@@ -505,6 +505,9 @@ struct dc_plane_state {
struct dc_plane_status status;
struct dc_context *ctx;
+ /* HACK: Workaround for forcing full reprogramming under some
conditions */
+ bool force_full_update;
+
/* private to dc_surface.c */
enum dc_irq_source irq_source;
struct kref refcount;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 20/81] drm/amd/display: extending AUX SW Timeout
From: Martin Leung
[ Upstream commit f4bbebf8e7eb4d294b040ab2d2ba71e70e69b930 ]
[Why]
AUX takes longer to reply when using active DP-DVI dongle on some asics
resulting in up to 2000+ us edid read (timeout).
[How]
1. Adjust AUX poll to match spec
2. Extend the SW timeout. This does not affect normal
operation since we exit the loop as soon as AUX acks.
Signed-off-by: Martin Leung
Reviewed-by: Jun Lei
Acked-by: Joshua Aberback
Acked-by: Leo Li
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dce/dce_aux.c | 9 ++---
drivers/gpu/drm/amd/display/dc/dce/dce_aux.h | 6 +++---
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
index 3f5b2e6f7553..df936edac5c7 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
@@ -189,6 +189,12 @@ static void submit_channel_request(
1,
0);
}
+
+ REG_UPDATE(AUX_INTERRUPT_CONTROL, AUX_SW_DONE_ACK, 1);
+
+ REG_WAIT(AUX_SW_STATUS, AUX_SW_DONE, 0,
+ 10, aux110->timeout_period/10);
+
/* set the delay and the number of bytes to write */
/* The length include
@@ -241,9 +247,6 @@ static void submit_channel_request(
}
}
- REG_UPDATE(AUX_INTERRUPT_CONTROL, AUX_SW_DONE_ACK, 1);
- REG_WAIT(AUX_SW_STATUS, AUX_SW_DONE, 0,
- 10, aux110->timeout_period/10);
REG_UPDATE(AUX_SW_CONTROL, AUX_SW_GO, 1);
}
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.h
b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.h
index f7caab85dc80..2c6f50b4245a 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.h
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.h
@@ -69,11 +69,11 @@ enum { /* This is the timeout as defined in DP 1.2a,
* at most within ~240usec. That means,
* increasing this timeout will not affect normal operation,
* and we'll timeout after
-* SW_AUX_TIMEOUT_PERIOD_MULTIPLIER * AUX_TIMEOUT_PERIOD = 1600usec.
+* SW_AUX_TIMEOUT_PERIOD_MULTIPLIER * AUX_TIMEOUT_PERIOD = 2400usec.
* This timeout is especially important for
-* resume from S3 and CTS.
+* converters, resume from S3, and CTS.
*/
- SW_AUX_TIMEOUT_PERIOD_MULTIPLIER = 4
+ SW_AUX_TIMEOUT_PERIOD_MULTIPLIER = 6
};
struct aux_engine_dce110 {
struct aux_engine base;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.0 99/99] drm/rockchip: fix for mailbox read validation.
From: Damian Kos
[ Upstream commit e4056bbb6719fe713bfc4030ac78e8e97ddf7574 ]
This is basically the same fix as in
commit fa68d4f8476b ("drm/rockchip: fix for mailbox read size")
but for cdn_dp_mailbox_validate_receive function.
See patchwork.kernel.org/patch/10671981/ for details.
Signed-off-by: Damian Kos
Signed-off-by: Heiko Stuebner
Link:
https://patchwork.freedesktop.org/patch/msgid/1542640463-18332-1-git-send-email-d...@cadence.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/rockchip/cdn-dp-reg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
index 5a485489a1e2..6c8b14fb1d2f 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
@@ -113,7 +113,7 @@ static int cdp_dp_mailbox_write(struct cdn_dp_device *dp,
u8 val)
static int cdn_dp_mailbox_validate_receive(struct cdn_dp_device *dp,
u8 module_id, u8 opcode,
- u8 req_size)
+ u16 req_size)
{
u32 mbox_size, i;
u8 header[4];
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.0 79/99] drm/imx: don't skip DP channel disable for background plane
From: Lucas Stach [ Upstream commit 7bcde275eb1d0ac8793c77c7e666a886eb16633d ] In order to make sure that the plane color space gets reset correctly. Signed-off-by: Lucas Stach Signed-off-by: Philipp Zabel Signed-off-by: Sasha Levin --- drivers/gpu/drm/imx/ipuv3-crtc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c index 058b53c0aa7e..1bb3e598cb84 100644 --- a/drivers/gpu/drm/imx/ipuv3-crtc.c +++ b/drivers/gpu/drm/imx/ipuv3-crtc.c @@ -70,7 +70,7 @@ static void ipu_crtc_disable_planes(struct ipu_crtc *ipu_crtc, if (disable_partial) ipu_plane_disable(ipu_crtc->plane[1], true); if (disable_full) - ipu_plane_disable(ipu_crtc->plane[0], false); + ipu_plane_disable(ipu_crtc->plane[0], true); } static void ipu_crtc_atomic_disable(struct drm_crtc *crtc, -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.0 87/99] drm/sun4i: Unbind components before releasing DRM and memory
From: Paul Kocialkowski
[ Upstream commit e02bc29b2cfa7806830d6da8b2322cddd67e8dfe ]
Our components may still be using the DRM device driver (if only to
access our driver's private data), so make sure to unbind them before
the final drm_dev_put.
Also release our reserved memory after component unbind instead of
before to match reverse creation order.
Fixes: f5a9ed867c83 ("drm/sun4i: Fix component unbinding and component master
deletion")
Signed-off-by: Paul Kocialkowski
Reviewed-by: Chen-Yu Tsai
Link:
https://patchwork.freedesktop.org/patch/msgid/20190424090413.6918-1-paul.kocialkow...@bootlin.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 9a5713fa03b2..f8bf5bbec2df 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -146,10 +146,11 @@ static void sun4i_drv_unbind(struct device *dev)
drm_dev_unregister(drm);
drm_kms_helper_poll_fini(drm);
drm_mode_config_cleanup(drm);
- of_reserved_mem_device_release(dev);
- drm_dev_put(drm);
component_unbind_all(dev, NULL);
+ of_reserved_mem_device_release(dev);
+
+ drm_dev_put(drm);
}
static const struct component_master_ops sun4i_drv_master_ops = {
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.0 70/99] drm/sun4i: Fix component unbinding and component master deletion
From: Paul Kocialkowski
[ Upstream commit f5a9ed867c83875546c9aadd4ed8e785e9adcc3c ]
For our component-backed driver to be properly removed, we need to
delete the component master in sun4i_drv_remove and make sure to call
component_unbind_all in the master's unbind so that all components are
unbound when the master is.
Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
Signed-off-by: Paul Kocialkowski
Signed-off-by: Maxime Ripard
Link:
https://patchwork.freedesktop.org/patch/msgid/20190418132727.5128-4-paul.kocialkow...@bootlin.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index c6b65a969979..9a5713fa03b2 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -148,6 +148,8 @@ static void sun4i_drv_unbind(struct device *dev)
drm_mode_config_cleanup(drm);
of_reserved_mem_device_release(dev);
drm_dev_put(drm);
+
+ component_unbind_all(dev, NULL);
}
static const struct component_master_ops sun4i_drv_master_ops = {
@@ -395,6 +397,8 @@ static int sun4i_drv_probe(struct platform_device *pdev)
static int sun4i_drv_remove(struct platform_device *pdev)
{
+ component_master_del(&pdev->dev, &sun4i_drv_master_ops);
+
return 0;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.0 69/99] drm/sun4i: Set device driver data at bind time for use in unbind
From: Paul Kocialkowski
[ Upstream commit 02b92adbe33e6dbd15dc6e32540b22f47c4ff0a2 ]
Our sun4i_drv_unbind gets the drm device using dev_get_drvdata.
However, that driver data is never set in sun4i_drv_bind.
Set it there to avoid getting a NULL pointer at unbind time.
Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
Signed-off-by: Paul Kocialkowski
Signed-off-by: Maxime Ripard
Link:
https://patchwork.freedesktop.org/patch/msgid/20190418132727.5128-3-paul.kocialkow...@bootlin.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 9e4c375ccc96..c6b65a969979 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -85,6 +85,8 @@ static int sun4i_drv_bind(struct device *dev)
ret = -ENOMEM;
goto free_drm;
}
+
+ dev_set_drvdata(dev, drm);
drm->dev_private = drv;
INIT_LIST_HEAD(&drv->frontend_list);
INIT_LIST_HEAD(&drv->engine_list);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.0 85/99] Revert "drm/virtio: drop prime import/export callbacks"
From: Dave Airlie
[ Upstream commit a0cecc23cfcbf2626497a8c8770856dd56b67917 ]
This patch does more harm than good, as it breaks both Xwayland and
gnome-shell with X11.
Xwayland requires DRI3 & DRI3 requires PRIME.
X11 crash for obscure double-free reason which are hard to debug
(starting X11 by hand doesn't trigger the crash).
I don't see an apparent problem implementing those stub prime
functions, they may return an error at run-time, and it seems to be
handled fine by GNOME at least.
This reverts commit b318e3ff7ca065d6b107e424c85a63d7a6798a69.
[airlied:
This broke userspace for virtio-gpus, and regressed things from DRI3 to DRI2.
This brings back the original problem, but it's better than regressions.]
Fixes: b318e3ff7ca065d6b107e424c85a63d7a6798a ("drm/virtio: drop prime
import/export callbacks")
Signed-off-by: Marc-André Lureau
Signed-off-by: Dave Airlie
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 4
drivers/gpu/drm/virtio/virtgpu_drv.h | 4
drivers/gpu/drm/virtio/virtgpu_prime.c | 12
3 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c
b/drivers/gpu/drm/virtio/virtgpu_drv.c
index 2d1aaca49105..f7f32a885af7 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
@@ -127,10 +127,14 @@ static struct drm_driver driver = {
#if defined(CONFIG_DEBUG_FS)
.debugfs_init = virtio_gpu_debugfs_init,
#endif
+ .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
+ .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_export = drm_gem_prime_export,
.gem_prime_import = drm_gem_prime_import,
.gem_prime_pin = virtgpu_gem_prime_pin,
.gem_prime_unpin = virtgpu_gem_prime_unpin,
+ .gem_prime_get_sg_table = virtgpu_gem_prime_get_sg_table,
+ .gem_prime_import_sg_table = virtgpu_gem_prime_import_sg_table,
.gem_prime_vmap = virtgpu_gem_prime_vmap,
.gem_prime_vunmap = virtgpu_gem_prime_vunmap,
.gem_prime_mmap = virtgpu_gem_prime_mmap,
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 0c15000f926e..1deb41d42ea4 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -372,6 +372,10 @@ int virtio_gpu_object_wait(struct virtio_gpu_object *bo,
bool no_wait);
/* virtgpu_prime.c */
int virtgpu_gem_prime_pin(struct drm_gem_object *obj);
void virtgpu_gem_prime_unpin(struct drm_gem_object *obj);
+struct sg_table *virtgpu_gem_prime_get_sg_table(struct drm_gem_object *obj);
+struct drm_gem_object *virtgpu_gem_prime_import_sg_table(
+ struct drm_device *dev, struct dma_buf_attachment *attach,
+ struct sg_table *sgt);
void *virtgpu_gem_prime_vmap(struct drm_gem_object *obj);
void virtgpu_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
int virtgpu_gem_prime_mmap(struct drm_gem_object *obj,
diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c
b/drivers/gpu/drm/virtio/virtgpu_prime.c
index c59ec34c80a5..eb51a78e1199 100644
--- a/drivers/gpu/drm/virtio/virtgpu_prime.c
+++ b/drivers/gpu/drm/virtio/virtgpu_prime.c
@@ -39,6 +39,18 @@ void virtgpu_gem_prime_unpin(struct drm_gem_object *obj)
WARN_ONCE(1, "not implemented");
}
+struct sg_table *virtgpu_gem_prime_get_sg_table(struct drm_gem_object *obj)
+{
+ return ERR_PTR(-ENODEV);
+}
+
+struct drm_gem_object *virtgpu_gem_prime_import_sg_table(
+ struct drm_device *dev, struct dma_buf_attachment *attach,
+ struct sg_table *table)
+{
+ return ERR_PTR(-ENODEV);
+}
+
void *virtgpu_gem_prime_vmap(struct drm_gem_object *obj)
{
struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.0 60/99] drm: bridge: dw-hdmi: Fix overflow workaround for Rockchip SoCs
From: Jonas Karlman
[ Upstream commit d15d9fd02575ecfada92d42f655940c4f10af842 ]
The Rockchip RK3288 SoC (v2.00a) and RK3328/RK3399 SoCs (v2.11a) have
also been identified as needing this workaround with a single iteration.
Fixes: be41fc55f1aa ("drm: bridge: dw-hdmi: Handle overflow workaround based on
device version")
Signed-off-by: Jonas Karlman
Tested-by: Heiko Stueber
Signed-off-by: Andrzej Hajda
Link:
https://patchwork.freedesktop.org/patch/msgid/am3pr03mb0966818faaae6192ff4ed11aac...@am3pr03mb0966.eurprd03.prod.outlook.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 64c3cf027518..14223c0ee784 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1655,6 +1655,8 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
* iteration for others.
* The Amlogic Meson GX SoCs (v2.01a) have been identified as needing
* the workaround with a single iteration.
+* The Rockchip RK3288 SoC (v2.00a) and RK3328/RK3399 SoCs (v2.11a) have
+* been identified as needing the workaround with a single iteration.
*/
switch (hdmi->version) {
@@ -1663,7 +1665,9 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
break;
case 0x131a:
case 0x132a:
+ case 0x200a:
case 0x201a:
+ case 0x211a:
case 0x212a:
count = 1;
break;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.0 78/99] gpu: ipu-v3: dp: fix CSC handling
From: Lucas Stach
[ Upstream commit d4fad0a426c6e26f48c9a7cdd21a7fe9c198d645 ]
Initialize the flow input colorspaces to unknown and reset to that value
when the channel gets disabled. This avoids the state getting mixed up
with a previous mode.
Also keep the CSC settings for the background flow intact when disabling
the foreground flow.
Root-caused-by: Jonathan Marek
Signed-off-by: Lucas Stach
Signed-off-by: Philipp Zabel
Signed-off-by: Sasha Levin
---
drivers/gpu/ipu-v3/ipu-dp.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-dp.c b/drivers/gpu/ipu-v3/ipu-dp.c
index 9b2b3fa479c4..5e44ff1f2085 100644
--- a/drivers/gpu/ipu-v3/ipu-dp.c
+++ b/drivers/gpu/ipu-v3/ipu-dp.c
@@ -195,7 +195,8 @@ int ipu_dp_setup_channel(struct ipu_dp *dp,
ipu_dp_csc_init(flow, flow->foreground.in_cs, flow->out_cs,
DP_COM_CONF_CSC_DEF_BOTH);
} else {
- if (flow->foreground.in_cs == flow->out_cs)
+ if (flow->foreground.in_cs == IPUV3_COLORSPACE_UNKNOWN ||
+ flow->foreground.in_cs == flow->out_cs)
/*
* foreground identical to output, apply color
* conversion on background
@@ -261,6 +262,8 @@ void ipu_dp_disable_channel(struct ipu_dp *dp, bool sync)
struct ipu_dp_priv *priv = flow->priv;
u32 reg, csc;
+ dp->in_cs = IPUV3_COLORSPACE_UNKNOWN;
+
if (!dp->foreground)
return;
@@ -268,8 +271,9 @@ void ipu_dp_disable_channel(struct ipu_dp *dp, bool sync)
reg = readl(flow->base + DP_COM_CONF);
csc = reg & DP_COM_CONF_CSC_DEF_MASK;
- if (csc == DP_COM_CONF_CSC_DEF_FG)
- reg &= ~DP_COM_CONF_CSC_DEF_MASK;
+ reg &= ~DP_COM_CONF_CSC_DEF_MASK;
+ if (csc == DP_COM_CONF_CSC_DEF_BOTH || csc == DP_COM_CONF_CSC_DEF_BG)
+ reg |= DP_COM_CONF_CSC_DEF_BG;
reg &= ~DP_COM_CONF_FG_EN;
writel(reg, flow->base + DP_COM_CONF);
@@ -347,6 +351,8 @@ int ipu_dp_init(struct ipu_soc *ipu, struct device *dev,
unsigned long base)
mutex_init(&priv->mutex);
for (i = 0; i < IPUV3_NUM_FLOWS; i++) {
+ priv->flow[i].background.in_cs = IPUV3_COLORSPACE_UNKNOWN;
+ priv->flow[i].foreground.in_cs = IPUV3_COLORSPACE_UNKNOWN;
priv->flow[i].foreground.foreground = true;
priv->flow[i].base = priv->base + ipu_dp_flow_base[i];
priv->flow[i].priv = priv;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.0 27/99] drm/amdgpu: shadow in shadow_list without tbo.mem.start cause page fault in sriov TDR
From: wentalou [ Upstream commit b575f10dbd6f84c2c8744ff1f486bfae1e4f6f38 ] shadow was added into shadow_list by amdgpu_bo_create_shadow. meanwhile, shadow->tbo.mem was not fully configured. tbo.mem would be fully configured by amdgpu_vm_sdma_map_table until calling amdgpu_vm_clear_bo. If sriov TDR occurred between amdgpu_bo_create_shadow and amdgpu_vm_sdma_map_table, amdgpu_device_recover_vram would deal with shadow without tbo.mem.start. Signed-off-by: Wentao Lou Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index 7ff3a28fc903..5336b2c9b615 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -3150,6 +3150,7 @@ static int amdgpu_device_recover_vram(struct amdgpu_device *adev) /* No need to recover an evicted BO */ if (shadow->tbo.mem.mem_type != TTM_PL_TT || + shadow->tbo.mem.start == AMDGPU_BO_INVALID_OFFSET || shadow->parent->tbo.mem.mem_type != TTM_PL_VRAM) continue; -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.0 38/99] drm/amd/display: If one stream full updates, full update all planes
From: David Francis
[ Upstream commit c238bfe0be9ef7420f7669a69e27c8c8f4d8a568 ]
[Why]
On some compositors, with two monitors attached, VT terminal
switch can cause a graphical issue by the following means:
There are two streams, one for each monitor. Each stream has one
plane
current state:
M1:S1->P1
M2:S2->P2
The user calls for a terminal switch and a commit is made to
change both planes to linear swizzle mode. In atomic check,
a new dc_state is constructed with new planes on each stream
new state:
M1:S1->P3
M2:S2->P4
In commit tail, each stream is committed, one at a time. The first
stream (S1) updates properly, triggerring a full update and replacing
the state
current state:
M1:S1->P3
M2:S2->P4
The update for S2 comes in, but dc detects that there is no difference
between the stream and plane in the new and current states, and so
triggers a fast update. The fast update does not program swizzle,
so the second monitor is corrupted
[How]
Add a flag to dc_plane_state that forces full updates
When a stream undergoes a full update, set this flag on all changed
planes, then clear it on the current stream
Subsequent streams will get full updates as a result
Signed-off-by: David Francis
Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Roman Li
Acked-by: Bhawanpreet Lakha
Acked-by: Nicholas Kazlauskas
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 19 +++
drivers/gpu/drm/amd/display/dc/dc.h | 3 +++
2 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 1f92e7e8e3d3..5af2ea1f201d 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -1308,6 +1308,11 @@ static enum surface_update_type det_surface_update(const
struct dc *dc,
return UPDATE_TYPE_FULL;
}
+ if (u->surface->force_full_update) {
+ update_flags->bits.full_update = 1;
+ return UPDATE_TYPE_FULL;
+ }
+
type = get_plane_info_update_type(u);
elevate_update_type(&overall_type, type);
@@ -1637,6 +1642,14 @@ void dc_commit_updates_for_stream(struct dc *dc,
}
dc_resource_state_copy_construct(state, context);
+
+ for (i = 0; i < dc->res_pool->pipe_count; i++) {
+ struct pipe_ctx *new_pipe =
&context->res_ctx.pipe_ctx[i];
+ struct pipe_ctx *old_pipe =
&dc->current_state->res_ctx.pipe_ctx[i];
+
+ if (new_pipe->plane_state && new_pipe->plane_state !=
old_pipe->plane_state)
+ new_pipe->plane_state->force_full_update = true;
+ }
}
@@ -1680,6 +1693,12 @@ void dc_commit_updates_for_stream(struct dc *dc,
dc->current_state = context;
dc_release_state(old);
+ for (i = 0; i < dc->res_pool->pipe_count; i++) {
+ struct pipe_ctx *pipe_ctx =
&context->res_ctx.pipe_ctx[i];
+
+ if (pipe_ctx->plane_state && pipe_ctx->stream == stream)
+ pipe_ctx->plane_state->force_full_update =
false;
+ }
}
/*let's use current_state to update watermark etc*/
if (update_type >= UPDATE_TYPE_FULL)
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h
b/drivers/gpu/drm/amd/display/dc/dc.h
index 4b5bbb13ce7f..7d5656d7e460 100644
--- a/drivers/gpu/drm/amd/display/dc/dc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc.h
@@ -496,6 +496,9 @@ struct dc_plane_state {
struct dc_plane_status status;
struct dc_context *ctx;
+ /* HACK: Workaround for forcing full reprogramming under some
conditions */
+ bool force_full_update;
+
/* private to dc_surface.c */
enum dc_irq_source irq_source;
struct kref refcount;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.0 23/99] drm/amd/display: extending AUX SW Timeout
From: Martin Leung
[ Upstream commit f4bbebf8e7eb4d294b040ab2d2ba71e70e69b930 ]
[Why]
AUX takes longer to reply when using active DP-DVI dongle on some asics
resulting in up to 2000+ us edid read (timeout).
[How]
1. Adjust AUX poll to match spec
2. Extend the SW timeout. This does not affect normal
operation since we exit the loop as soon as AUX acks.
Signed-off-by: Martin Leung
Reviewed-by: Jun Lei
Acked-by: Joshua Aberback
Acked-by: Leo Li
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dce/dce_aux.c | 9 ++---
drivers/gpu/drm/amd/display/dc/dce/dce_aux.h | 6 +++---
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
index aaeb7faac0c4..e0fff5744b5f 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
@@ -189,6 +189,12 @@ static void submit_channel_request(
1,
0);
}
+
+ REG_UPDATE(AUX_INTERRUPT_CONTROL, AUX_SW_DONE_ACK, 1);
+
+ REG_WAIT(AUX_SW_STATUS, AUX_SW_DONE, 0,
+ 10, aux110->timeout_period/10);
+
/* set the delay and the number of bytes to write */
/* The length include
@@ -241,9 +247,6 @@ static void submit_channel_request(
}
}
- REG_UPDATE(AUX_INTERRUPT_CONTROL, AUX_SW_DONE_ACK, 1);
- REG_WAIT(AUX_SW_STATUS, AUX_SW_DONE, 0,
- 10, aux110->timeout_period/10);
REG_UPDATE(AUX_SW_CONTROL, AUX_SW_GO, 1);
}
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.h
b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.h
index f7caab85dc80..2c6f50b4245a 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.h
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.h
@@ -69,11 +69,11 @@ enum { /* This is the timeout as defined in DP 1.2a,
* at most within ~240usec. That means,
* increasing this timeout will not affect normal operation,
* and we'll timeout after
-* SW_AUX_TIMEOUT_PERIOD_MULTIPLIER * AUX_TIMEOUT_PERIOD = 1600usec.
+* SW_AUX_TIMEOUT_PERIOD_MULTIPLIER * AUX_TIMEOUT_PERIOD = 2400usec.
* This timeout is especially important for
-* resume from S3 and CTS.
+* converters, resume from S3, and CTS.
*/
- SW_AUX_TIMEOUT_PERIOD_MULTIPLIER = 4
+ SW_AUX_TIMEOUT_PERIOD_MULTIPLIER = 6
};
struct aux_engine_dce110 {
struct aux_engine base;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.0 22/99] drm/ttm: fix dma_fence refcount imbalance on error path
From: Lin Yi
[ Upstream commit 543c364d8eeeb42c0edfaac9764f4e9f3d777ec1 ]
the ttm_bo_add_move_fence takes a reference to the struct dma_fence, but
failed to release it on the error path, leading to a memory leak.
add dma_fence_put before return when error occur.
Signed-off-by: Lin Yi
Reviewed-by: Christian König
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/ttm/ttm_bo.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 996cadd83f24..d8e1b3f12904 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -881,8 +881,10 @@ static int ttm_bo_add_move_fence(struct ttm_buffer_object
*bo,
reservation_object_add_shared_fence(bo->resv, fence);
ret = reservation_object_reserve_shared(bo->resv, 1);
- if (unlikely(ret))
+ if (unlikely(ret)) {
+ dma_fence_put(fence);
return ret;
+ }
dma_fence_put(bo->moving);
bo->moving = fence;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 88275] [865G] Intel OpenGL rendering isn't starting
https://bugs.freedesktop.org/show_bug.cgi?id=88275 Timothy Arceri changed: What|Removed |Added Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org Component|Mesa core |Drivers/DRI/i915 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix timestamp docs for variable refresh properties.
Nag nag: The below documentation patch, acked-by Daniel and r-b'd by
Nicholas seems to not have made it into drm-next yet?
thanks,
-mario
On Thu, Apr 18, 2019 at 2:45 PM Kazlauskas, Nicholas
wrote:
>
> On 4/18/19 2:01 AM, Mario Kleiner wrote:
> > As discussed with Nicholas and Daniel Vetter (patchwork
> > link to discussion below), the VRR timestamping behaviour
> > produced utterly useless and bogus vblank/pageflip
> > timestamps. We have found a way to fix this and provide
> > sane behaviour.
> >
> > As of Linux 5.2, the amdgpu driver will be able to
> > provide exactly the same vblank / pageflip timestamp
> > semantic in variable refresh rate mode as in standard
> > fixed refresh rate mode. This is achieved by deferring
> > core vblank handling (drm_crtc_handle_vblank()) until
> > the end of front porch, and also defer the sending of
> > pageflip completion events until end of front porch,
> > when we can safely compute correct pageflip/vblank
> > timestamps.
> >
> > The same approach will be possible for other VRR
> > capable kms drivers, so we can actually have sane
> > and useful timestamps in VRR mode.
> >
> > This patch removes the section of the docs that
> > describes the broken timestamp behaviour present
> > in Linux 5.0/5.1.
> >
> > Fixes: ab7a664f7a2d ("drm: Document variable refresh properties")
> > Link: https://patchwork.freedesktop.org/patch/285333/
> > Signed-off-by: Mario Kleiner
>
> Reviewed-by: Nicholas Kazlauskas
>
> Someone else can feel free to push this as I don't have commit rights
> for DRM.
>
> Thanks!
>
> Nicholas Kazlauskas
>
> > ---
> > drivers/gpu/drm/drm_connector.c | 6 --
> > 1 file changed, 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_connector.c
> > b/drivers/gpu/drm/drm_connector.c
> > index 2355124849db..b34c3d38bf15 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -1416,12 +1416,6 @@ EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
> >*
> >* The driver may place further restrictions within these minimum
> >* and maximum bounds.
> > - *
> > - * The semantics for the vertical blank timestamp differ when
> > - * variable refresh rate is active. The vertical blank timestamp
> > - * is defined to be an estimate using the current mode's fixed
> > - * refresh rate timings. The semantics for the page-flip event
> > - * timestamp remain the same.
> >*/
> >
> > /**
> >
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37274] Crash in draw_llvm_shader23 (r300g, rs690, in warzone2100)
https://bugs.freedesktop.org/show_bug.cgi?id=37274 Timothy Arceri changed: What|Removed |Added Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org Component|Mesa core |Drivers/Gallium/r300 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 44344] [i915g] state_tracker/st_glsl_to_tgsi.cpp:3082:simplify_cmp: Assertion `inst->dst.index < 4096' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=44344 Timothy Arceri changed: What|Removed |Added Component|Mesa core |Drivers/Gallium/i915g Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108893] Slow redrawing of menu in Gothic 2 under wine
https://bugs.freedesktop.org/show_bug.cgi?id=108893 --- Comment #19 from Timothy Arceri --- I installed the game via Proton. Seems it is still very buggy in wine. I had to follow the instructions here [1] to get it to load without crashing or constantly changing the screen between windowed and fullscreen. Once I got it working the menu was working fine, no lag. I'm suspecting you are either experiencing a wine bug or you have some bad settings somewhere rather than a Mesa bug. [1] https://www.protondb.com/app/39510 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101769] 2X performance regression on Mesa 17.1 vs 17.0
https://bugs.freedesktop.org/show_bug.cgi?id=101769 Timothy Arceri changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #3 from Timothy Arceri --- Has this performance regression been fixed for you in recent Mesa releases? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] 2nd pull for malidp-next
On Fri, 3 May 2019 at 22:17, Daniel Vetter wrote:
>
> On Fri, May 03, 2019 at 10:29:48AM +0100, Liviu Dudau wrote:
> > On Fri, May 03, 2019 at 11:15:23AM +0200, Daniel Vetter wrote:
> > > On Fri, May 3, 2019 at 11:11 AM Liviu Dudau wrote:
> > > >
> > > > On Fri, May 03, 2019 at 09:54:35AM +1000, Dave Airlie wrote:
> > > > > On Thu, 2 May 2019 at 20:45, Liviu Dudau wrote:
> > > > > >
> > > > > > Hi DRM maintainers,
> > > > > >
> > > > > > This is the 2nd pull request for the malidp-next. The new patches
> > > > > > add
> > > > > > additional support for Arm Mali D71 so that it can now be enabled
> > > > > > correctly and brought up on any SoC that contains the IP. From now
> > > > > > on
> > > > > > we will start focusing on adding writeback, scaling and other useful
> > > > > > features to bring the driver to the same level of maturity as
> > > > > > mali-dp.
> > > > > >
> > > > > > Please pull,
> > > > > > Liviu
> > > > > >
> > > > > >
> > > > > >
> > > > > > The following changes since commit
> > > > > > 7c13e5cc2391950541f41fc9ab0336aae77c7f63:
> > > > > >
> > > > > > Merge tag 'drm-intel-next-fixes-2019-04-25' of
> > > > > > git://anongit.freedesktop.org/drm/drm-intel into drm-next
> > > > > > (2019-04-26 11:35:59 +1000)
> > > > > >
> > > > > > are available in the Git repository at:
> > > > > >
> > > > > > git://linux-arm.org/linux-ld.git for-upstream/mali-dp
So I get commits now, but I also get:
Pulling git://linux-arm.org/linux-ld.git for-upstream/mali-dp ...
From git://linux-arm.org/linux-ld
* branch for-upstream/mali-dp -> FETCH_HEAD
dim: 09918bb1ff8c ("drm/komeda: Use memset to initialize config_id"):
SHA1 in fixes line not found:
dim: 4cc734cb79a8 ("drm/komeda: Add sysfs attribute: core_id and config_id")
dim: d9fcab4a131d ("drm/komeda: Mark the local functions as static"):
author Signed-off-by missing.
dim: ERROR: issues in commits detected, aborting
Please fix the fixes tag, though since that is all in the one pull
request you should probably squash the fix into the offending commit.
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100239] Incorrect rendering in CS:GO
https://bugs.freedesktop.org/show_bug.cgi?id=100239 Timothy Arceri changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #22 from Timothy Arceri --- Should be fixed by: commit 49025292fbbf285d4473d2c20a83b6c533a79d45 Author: Timothy Arceri Date: Mon May 6 14:39:44 2019 +1000 radeonsi: add config entry for Counter-Strike Global Offensive This fixes rendering issues with gun scopes which is rather important. Cc: "19.0" "19.1" Acked-by: Bas Nieuwenhuizen Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100239 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix drm.h uapi header for GNU/kFreeBSD
On 6 May 2019, at 09:16, Daniel Vetter wrote: > On Sat, May 04, 2019 at 09:43:14PM +0100, James Clarke wrote: >> On 15 Jan 2019, at 18:41, Eric Anholt wrote: >>> >>> Daniel Vetter writes: >>> On Tue, Jan 15, 2019 at 03:04:18PM +, James Clarke wrote: > Like GNU/Linux, GNU/kFreeBSD's sys/types.h does not define the uintX_t > types, which differs from the BSDs' headers. Thus we should include > stdint.h to ensure we have all the required integer types. > > Signed-off-by: James Clarke Would be good to get an ack from some other *bsd that this is still all fine. lgtm otherwise. -Daniel >>> >>> I think there was some need for inttypes.h instead of stdint like a >>> decade ago when I was working on BSDs, but that was already almost >>> irrelevant then. >> >> Hi, just following up on this; is there still the need for an ACK? > > Yeah and ack without a "decades ago" qualifier would be nice. > -Daniel I have the following from Brooks Davis, FreeBSD contributor and core team member: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline With respect to the thread: https://lists.freedesktop.org/archives/dri-devel/2019-May/216784.html I can't see any reason why you'd want to include inttypes.h instead of stdint.h unless you want the intmax_t using types/functions it defines. Your patch is certainly safe on FreeBSD. At a glance it looks like the same is true (with somewhat different implementation) on OpenBSD. - -- Brooks -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJc0LwmAAoJEKzQXbSebgfArrIIAItDHcDG5d9QcMnbQibk+d6w EW1OnvijeVZ6PCNcbEEldZEHXsRFOe7zE8sYKSPegDnYve1y8jVyh2YyJtDI7eWL hD2dSY3DGOKatEfd3CxoG2vpN8zv3giDS35hXIqMRF1iD0/jYixTYLcfZgQ7U6Ml 34gxe3q6v30ZoWK5SHCDCac4z0OYjfKTpwZnyNkag/DW5CqqOTQOao6AJOLcosqJ orIUZVl0nvk0dIGzK09ef+BWOyVA5h6f+V3F3x/cK3E2qiTRxVLhhLVaEgdBDp5C hPXH33q/GK54m5jWVaZ5BtpKSA1Et6HjF48+wyJCADQh//DxIWGEAa1fmvKryQw= =oJBq -END PGP SIGNATURE- Hopefully the signature survives; I converted it from PGP/MIME and it seems to verify locally. Regards, James ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 203525] brightness with function buttons Acer Aspire A315-41 notebook with AMD Ryzen 5 2500U
https://bugzilla.kernel.org/show_bug.cgi?id=203525 --- Comment #5 from Erik (erikjohans...@flashbox.5july.org) --- By adding commit b59dfdaef173677b0b7e10f375226c0a1114fd20 i was able to boot 4.19.36. I tried 4.19.36 but it was broken. 4.19.36 broken and 4.19.37 fixed. I then ran a bisect but i wasn't able to to find the commit that fixed it. I don't know why the bisect went thru all steps without finding the fix. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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 parsed_byt
Re: [PATCH v2 12/17] kunit: tool: add Python wrappers for running KUnit tests
> On Sun, May 5, 2019 at 5:19 PM Frank Rowand wrote: > > You can see the full version 14 document in the submitter's repo: > > > > $ git clone https://github.com/isaacs/testanything.github.io.git > > $ cd testanything.github.io > > $ git checkout tap14 > > $ ls tap-version-14-specification.md > > > > My understanding is the the version 14 specification is not trying to > > add new features, but instead capture what is already implemented in > > the wild. > > Oh! I didn't know about the work on TAP 14. I'll go read through this. > > > > ## Here is what I propose for this patchset: > > > > > > - Print out test number range at the beginning of each test suite. > > > - Print out log lines as soon as they happen as diagnostics. > > > - Print out the lines that state whether a test passes or fails as a > > > ok/not ok line. > > > > > > This would be technically conforming with TAP13 and is consistent with > > > what some kselftests have done. > > This is what I fixed kselftest to actually do (it wasn't doing correct > TAP13), and Shuah is testing the series now: > https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git/log/?h=ksft-tap-refactor Oh, cool! I guess this is an okay approach then. Thanks! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 12/17] kunit: tool: add Python wrappers for running KUnit tests
> On 5/3/19 4:14 PM, Brendan Higgins wrote: > >> On 5/2/19 10:36 PM, Brendan Higgins wrote: > >>> On Thu, May 2, 2019 at 6:45 PM Frank Rowand > >>> wrote: > > On 5/2/19 4:45 PM, Brendan Higgins wrote: > > On Thu, May 2, 2019 at 2:16 PM Frank Rowand > > wrote: > >> > >> On 5/2/19 11:07 AM, Brendan Higgins wrote: > >>> On Thu, May 2, 2019 at 4:02 AM Greg KH > >>> wrote: > > On Wed, May 01, 2019 at 04:01:21PM -0700, Brendan Higgins wrote: > > From: Felix Guo > > > > The ultimate goal is to create minimal isolated test binaries; in > > the > > meantime we are using UML to provide the infrastructure to run > > tests, so > > define an abstract way to configure and run tests that allow us to > > change the context in which tests are built without affecting the > > user. > > This also makes pretty and dynamic error reporting, and a lot of > > other > > nice features easier. > > > > kunit_config.py: > > - parse .config and Kconfig files. > > > > kunit_kernel.py: provides helper functions to: > > - configure the kernel using kunitconfig. > > - build the kernel with the appropriate configuration. > > - provide function to invoke the kernel and stream the output > > back. > > > > Signed-off-by: Felix Guo > > Signed-off-by: Brendan Higgins > > Ah, here's probably my answer to my previous logging format question, > right? What's the chance that these wrappers output stuff in a > standard > format that test-framework-tools can already parse? :) > > > > To be clear, the test-framework-tools format we are talking about is > > TAP13[1], correct? > > I'm not sure what the test community prefers for a format. I'll let them > jump in and debate that question. > > > > > > My understanding is that is what kselftest is being converted to use. > > > >>> > >>> It should be pretty easy to do. I had some patches that pack up the > >>> results into a serialized format for a presubmit service; it should be > >>> pretty straightforward to take the same logic and just change the > >>> output format. > >> > >> When examining and trying out the previous versions of the patch I > >> found > >> the wrappers useful to provide information about how to control and use > >> the tests, but I had no interest in using the scripts as they do not > >> fit in with my personal environment and workflow. > >> > >> In the previous versions of the patch, these helper scripts are > >> optional, > >> which is good for my use case. If the helper scripts are required to > > > > They are still optional. > > > >> get the data into the proper format then the scripts are not quite so > >> optional, they become the expected environment. I think the proper > >> format should exist without the helper scripts. > > > > That's a good point. A couple things, > > > > First off, supporting TAP13, either in the kernel or the wrapper > > script is not hard, but I don't think that is the real issue that you > > raise. > > > > If your only concern is that you will always be able to have human > > readable KUnit results printed to the kernel log, that is a guarantee > > I feel comfortable making. Beyond that, I think it is going to take a > > long while before I would feel comfortable guaranteeing anything about > > how will KUnit work, what kind of data it will want to expose, and how > > it will be organized. I think the wrapper script provides a nice > > facade that I can maintain, can mediate between the implementation > > details and the user, and can mediate between the implementation > > details and other pieces of software that might want to consume > > results. > > > > [1] https://testanything.org/tap-version-13-specification.html > > My concern is based on a focus on my little part of the world > (which in _previous_ versions of the patch series was the devicetree > unittest.c tests being converted to use the kunit infrastructure). > If I step back and think of the entire kernel globally I may end > up with a different conclusion - but I'm going to remain myopic > for this email. > > I want the test results to be usable by me and my fellow > developers. I prefer that the test results be easily accessible > (current printk() implementation means that kunit messages are > just as accessible as the current unittest.c printk() output). > If the printk() output needs to be filtered through a script > to generate the actual test results then that is sub-optimal > to me. It is one
[Bug 110630] Random Horizontal green lines after screen resize
https://bugs.freedesktop.org/show_bug.cgi?id=110630 --- Comment #4 from Axel Davy --- Created attachment 144181 --> https://bugs.freedesktop.org/attachment.cgi?id=144181&action=edit dmesg (after capturing the issue) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110630] Random Horizontal green lines after screen resize
https://bugs.freedesktop.org/show_bug.cgi?id=110630 --- Comment #3 from Axel Davy --- Yes sure, Here is a video: http://dev.ipol.im/~adavy/green_lines.mp4 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110630] Random Horizontal green lines after screen resize
https://bugs.freedesktop.org/show_bug.cgi?id=110630 --- Comment #5 from Axel Davy --- Created attachment 144182 --> https://bugs.freedesktop.org/attachment.cgi?id=144182&action=edit Xorg log (after having the issue) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110630] Random Horizontal green lines after screen resize
https://bugs.freedesktop.org/show_bug.cgi?id=110630 --- Comment #2 from Alex Deucher --- Can you get a picture or video of the lines? Please attach your dmesg output and xorg log (if using X). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110630] Random Horizontal green lines after screen resize
https://bugs.freedesktop.org/show_bug.cgi?id=110630 Axel Davy changed: What|Removed |Added Summary|Horizontal green lines |Random Horizontal green ||lines after screen resize --- Comment #1 from Axel Davy --- Hi there, AMD Radeon RX 480. Linux 5.0.13 Full HD screen with hdmi Archlinux KDE Xorg It's a problem I had noticed for some time, but couldn't figure out what was triggering it. Sometimes after screen mode change there is random green lines appearing on the screen (random location, but about one third of the bottom of the screen). It seems i can replicate it on my system by changing the resolution in the system settings from 1920x1080 to 1280x1024. When going back to full hd, the green lines sometimes remain. Shutting down the screen and resuming it helps (but if still at 1280x1024, the lines remain). The random line disappear when the screen doesn't refresh (cursor not moving, nothing drawing on the background). No particular message appear in the dmesg after changing resolution. I assume this is not enough, please indicate me what would help. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110614] [Regression] Freeze at desktop manager startup
https://bugs.freedesktop.org/show_bug.cgi?id=110614 --- Comment #5 from raffa...@zoho.com --- Maybe I should have stated so explicitely, ec6c2297634eba77248a929048cf4201887a5f0a is the first commit to crash. It looks like it crashes even before calling si_texture_get_handle as there's nothing logged on bad builds. Possibly there is something wrong with my setup? I'm only compiling mesa from git, all other libs are from repos. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110614] [Regression] Freeze at desktop manager startup
https://bugs.freedesktop.org/show_bug.cgi?id=110614 --- Comment #6 from Julien Isorce --- This one https://cgit.freedesktop.org/mesa/mesa/commit/?id=ec6c2297634eba77248a929048cf4201887a5f0a ? or https://cgit.freedesktop.org/mesa/mesa/commit/?id=a3c202de0a963c0562796cf75e3a9b3eedf1afad ? Any chance you can install the debug symbols ? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110629] Intel i915 graphics driver issues with external monitor when laptop in docking station (opensuse bug 1132926)
https://bugs.freedesktop.org/show_bug.cgi?id=110629 otrebor changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |intel-gfx-bugs@lists.freede |.org|sktop.org Product|Mesa|DRI QA Contact|dri-devel@lists.freedesktop |intel-gfx-bugs@lists.freede |.org|sktop.org CC||intel-gfx-bugs@lists.freede ||sktop.org Component|Drivers/DRI/i915|DRM/Intel -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 95298] Can't "connect" to external display attached to docking station via DP on laptop with Intel/AMD dual
https://bugs.freedesktop.org/show_bug.cgi?id=95298 otrebor changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=110629 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110629] Intel i915 graphics driver issues with external monitor when laptop in docking station (opensuse bug 1132926)
https://bugs.freedesktop.org/show_bug.cgi?id=110629 Bug ID: 110629 Summary: Intel i915 graphics driver issues with external monitor when laptop in docking station (opensuse bug 1132926) Product: Mesa Version: unspecified Hardware: x86-64 (AMD64) URL: https://bugzilla.opensuse.org/show_bug.cgi?id=1132926 OS: Linux (All) Status: NEW Keywords: regression Severity: normal Priority: medium Component: Drivers/DRI/i915 Assignee: dri-devel@lists.freedesktop.org Reporter: otre...@swissonline.ch QA Contact: dri-devel@lists.freedesktop.org CC: ti...@suse.de I have a HP EliteBook 840 G2 running openSUSE Leap 15.0 with all patches applied. The laptop runs fine when it is in normal portable mode (off dock), also with an external monitor. When I dock it into its docking station at home, I experience weird graphic device behaviour. It is a matter of luck if it is able to initialize and configure the attached external monitor the way it is expected. Sometimes it hangs in an endless config loop when trying to initialize the monitor. The external monitor is a SAMSUNG U28D590D connected via display port to port #1 to the docking station. However, if I undock the laptop and plug the very same display cable to the onboard display port then the display and the laptop run as expected. It really is an issue I can only experience when putting the device into the docking station. For comparison: I had the chance to try another device, a HP EliteBook 840 G3 with the very same docking station and monitor. It was running Windows 7 and I did not see any strange behaviour. Additionally, I was earlier running openSUSE 42.3 on the very same device configuration and did not have any issues. The odd behaviour only started after upgrading to Leap 15.0 and got worse with each patch cycle, to reach total unusability as of today. Hence, thats why I am writing this bug report. One thing I occasionally see is this error message in the logs: kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe C FIFO underrun I attaching output from dmesg, journalctl, and xrandr in different configurations. Let me know if you need more. Thanks for the support. Please also refer to opensuse bug #1132926 here for more details: https://bugzilla.opensuse.org/show_bug.cgi?id=1132926 Somehow might relate to this bug here: https://bugs.freedesktop.org/show_bug.cgi?id=95298 However, my enviroenment refers to the Intel i915 graphics driver as I have no Radeon hardware. Please also see the opensuse bug first. Let me know If you need more info. Thanks for the support. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[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 =
&fb_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, &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 = 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;
-
[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(&dev->master_mutex);
+ if (dev->master) {
+ mutex_unlock(&dev->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(&dev->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(&fb_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
[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(&dev->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
[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 Ha
[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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[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, &connector->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 = &connector->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, &connector->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(&mode->head, &connector->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
[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 &drm_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 &drm_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(&fb_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(&fb_helper->lock);
- err = __drm_fb_helper_add_one_connector(fb_helper, connector);
- mutex_unlock(&fb_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.
-
[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 = &fb_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, &rotation)) {
+ if (drm_client_panel_rotation(mode_set, &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 = 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 = &fb_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(&fb_helper->client.modeset_mutex);
+ mutex_lock(&client->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(&fb_helper->client.modeset_mutex);
+ ret = drm_client_modeset_commit_legacy(client);
+ mutex_unlock(&client->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
[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(&ctx, 0);
+
+ state = drm_atomic_state_alloc(dev);
+ if (!state) {
+ ret = -ENOMEM;
+ goto out_ctx;
+ }
+
+ state->acquire_ctx = &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, &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 = 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;
+
[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 = &fb_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, &conn_iter);
drm_client_for_each_connector_iter(connector, &conn_iter) {
struct drm_connector **tmp;
tmp = krealloc(connectors, (connector_count + 1) *
sizeof(*connectors), GFP_KERNEL);
- if (!tmp)
+ if (!tmp) {
+ ret = -ENOMEM;
goto free_connectors;
+ }
[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(&splash->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 = &splash->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(&client->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 pos
[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 = &fb_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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 203525] brightness with function buttons Acer Aspire A315-41 notebook with AMD Ryzen 5 2500U
https://bugzilla.kernel.org/show_bug.cgi?id=203525 --- Comment #4 from Erik (erikjohans...@flashbox.5july.org) --- Created attachment 282653 --> https://bugzilla.kernel.org/attachment.cgi?id=282653&action=edit dmesg fixed 4.19.37 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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 +
Re: [PATCH 1/1] MAINTAINERS: update amdkfd maintainer
On Fri, May 3, 2019 at 4:04 AM Oded Gabbay wrote: > > amdkfd is now being upstreamed together with the amdgpu driver. Therefore, > update the maintainer entry for the driver with the name of the amdgpu > driver maintainer. > We use one tree, but Felix is the maintainer. Should probably put him rather than me. Alex > Signed-off-by: Oded Gabbay > --- > MAINTAINERS | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 5c38f21aee78..3798247d02c6 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -798,9 +798,9 @@ F: drivers/iommu/amd_iommu*.[ch] > F: include/linux/amd-iommu.h > > AMD KFD > -M: Oded Gabbay > +M: Alex Deucher > L: dri-devel@lists.freedesktop.org > -T: git git://people.freedesktop.org/~gabbayo/linux.git > +T: git git://people.freedesktop.org/~agd5f/linux > S: Supported > F: drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c > F: drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h > -- > 2.17.1 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 203525] brightness with function buttons Acer Aspire A315-41 notebook with AMD Ryzen 5 2500U
https://bugzilla.kernel.org/show_bug.cgi?id=203525 --- Comment #3 from Erik (erikjohans...@flashbox.5july.org) --- Created attachment 282649 --> https://bugzilla.kernel.org/attachment.cgi?id=282649&action=edit dmesg broken 4.19.35 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 203525] brightness with function buttons Acer Aspire A315-41 notebook with AMD Ryzen 5 2500U
https://bugzilla.kernel.org/show_bug.cgi?id=203525 --- Comment #2 from Erik (erikjohans...@flashbox.5july.org) --- Created attachment 282647 --> https://bugzilla.kernel.org/attachment.cgi?id=282647&action=edit dmesg fixed 4.19.39 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/doc: Improve docs for conn_state->best_encoder
On Mon, May 06, 2019 at 05:57:53PM +0300, Laurent Pinchart wrote:
> Hi Daniel,
>
> Thank you for the patch.
>
> On Mon, May 06, 2019 at 04:46:29PM +0200, Daniel Vetter wrote:
> > It's mandatory and considered core state since ioctls rely on this
> > working.
> >
> > Thanks to Laurent for pointing out this gap.
> >
> > v2: Clarify to "atomic drivers" only.
> >
> > Cc: Laurent Pinchart
> > Cc: Sean Paul
> > Signed-off-by: Daniel Vetter
> > ---
> > include/drm/drm_connector.h | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > index 02a131202add..f43f40d5888a 100644
> > --- a/include/drm/drm_connector.h
> > +++ b/include/drm/drm_connector.h
> > @@ -517,6 +517,10 @@ struct drm_connector_state {
> > * Used by the atomic helpers to select the encoder, through the
> > * &drm_connector_helper_funcs.atomic_best_encoder or
> > * &drm_connector_helper_funcs.best_encoder callbacks.
>
> How about updating this part as well ?
>
> "Used by both the DRM core and the atomic helpers to select the encoder
> (through the &drm_connector_helper_funcs.atomic_best_encoder), access it
> and report it to userspace (through the GETCONNECTOR and GETENCODER
> ioctls). This field shall be set by all atomic drivers, either directly
> or through atomic helpers."
It's kinda two things, I think best to describe in two paragraphs. But I
can move the core usage up, since arguable more important. Otoh most
drivers won't care since helpers handle this, and they care more about how
@best_encoder is used.
E.g. core never calls the helper callbacks
@atomic_best_endoer/best_encoder, which isn't clear anymore with your
wording. And I have a sticker for core/helper splits :-)
-Daniel
>
> > +*
> > +* NOTE: Atomic drivers must fill this out (either themselves or through
> > +* helpers), for otherwise the GETCONNECTOR and GETENCODER IOCTLs will
> > +* not return correct data to userspace.
> > */
> > struct drm_encoder *best_encoder;
> >
>
> --
> Regards,
>
> Laurent Pinchart
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 00/19] Share TTM code among DRM framebuffer drivers
On Mon, May 06, 2019 at 04:20:34PM +0200, Gerd Hoffmann wrote: > On Mon, May 06, 2019 at 03:09:20PM +0200, Thomas Zimmermann wrote: > > Hi > > > > Am 06.05.19 um 14:22 schrieb Gerd Hoffmann: > > >> GEM VRAM could implement PRIME helpers, which would allow for using > > >> the generic fbcon. > > > > > > bochs_gem_prime_*() functions with this series applied look like you can > > > just rename them & move over to vram helpers. > > > > > > It's not a full prime implementation, specifically actual export/import > > > isn't there. But pin+vmap (needed by generic fbcon) is implemented. > > > > I did have a patch to do this, but then I read that prime requires DMA > > for buffer sharing and bochs works only because it's emulated. > > For actual buffer sharing with other drivers yes because dma-bufs > typically are a bunch of pages (struct page**) and live in RAM. > > Not sure whenever it is possible or useful to place the vram in > ZONE_DEVICE to get page structs for it, then export buffers located > in vram that way without copying them over to main memory. I suspect > most importers would fail to properly setup PCI-PCI dma in that case. Christian König is working on p2p dma-buf sharing. Not sure that's worth it for virtual devices, but could be fun to wire up I guess. -Daniel > > > If bochs' implementation is complete enough to be useful for other > > drivers, I'll add it to the patch set. > > It's good enough for generic fbcon. > > cheers, > Gerd > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110614] [Regression] Freeze at desktop manager startup
https://bugs.freedesktop.org/show_bug.cgi?id=110614 --- Comment #4 from Julien Isorce --- So somehow the factoring is incorrect https://cgit.freedesktop.org/mesa/mesa/commit/?id=1cec049d4db1c4dcd121bad17df4a77273dd9bb1 If you can log the values for offset and stride before and after this patch it might help to understand the issue. Thx -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110614] [Regression] Freeze at desktop manager startup
https://bugs.freedesktop.org/show_bug.cgi?id=110614 --- Comment #3 from raffa...@zoho.com --- Tested both master and 8cd71f399e73c5d87e9162cc74da76e317a9f41f specifically, but it still hangs and the stacktrace looks the same. Any way I can help debug this? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/panel: simple: Add FriendlyELEC HD702E 800x1280 LCD panel
On Mon, May 6, 2019 at 4:56 AM Jagan Teki wrote: > > Hi Sam, > > On Thu, May 2, 2019 at 1:04 AM Sam Ravnborg wrote: > > > > Hi Jagan > > > > On Wed, May 01, 2019 at 05:44:47PM +0530, Jagan Teki wrote: > > > HD702E lcd is FriendlyELEC developed eDP LCD panel with 800x1280 > > > resolution. It has built in Goodix, GT9271 captive touchscreen > > > with backlight adjustable via PWM. > > > > > > Add support for it. > > > > > > Cc: Thierry Reding > > > Cc: Sam Ravnborg > > > Cc: David Airlie > > > Cc: Daniel Vetter > > > Cc: dri-devel@lists.freedesktop.org > > > Signed-off-by: Jagan Teki > > > > Please submit the binding in a separate patch as per > > Documentation/devicetree/bindings/submitting-patches.txt > > Hmm.. prepared like this initially but few of my patches were combined > earlier even-though I sent it separately. anyway let me separate it > again. For what subsystem? All the maintainers that I was aware of doing that have stopped. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/12] drm/amdgpu: add independent DMA-buf export v3
On Mon, May 06, 2019 at 10:05:07AM +, Koenig, Christian wrote: > Am 06.05.19 um 10:04 schrieb Daniel Vetter: > > [SNIP] > + /* pin buffer into GTT */ > + return amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT); > >>> This is kinda what I mean with "shouldn't we pin the attachment" - afaiui > >>> this can fail is someone already pinned the buffer into vram. And that > >>> kind of checking is supposed to happen in the buffer attachment. > >> Why is that supposed to happen on the attachment? I mean it could be nice > >> to > >> have for debugging, but I still don't see any practical reason for this. > > dma_buf_attach is supposed to make sure the buffer won't land somewhere > > where you can't get at it anymore. Wrt pin that means the exporter needs > > to make sure it can't get pinned into a wrong place, and also isn't pinned > > into a wrong place anymore. That's why I think pinning ties in with > > dma_buf_attach and not the overall buffer. > > > > In a way there's two pieces of a pin: > > - Do not move the buffer anymore. > > - Make sure I can still get at it. > > > > Internally the 2nd part is encoded in the domain parameter you pass to > > amdgpu_bo_pin. When going through dma-buf that information is derived > > from the attachment (e.g. if it's a p2p one, then you can put it wherever > > you feel like, if it's a normal one it must be in system ram). The dma-buf > > alone doesn't tell you _where_ to pin something. > > Ok, that finally makes some sense. So the attachment describes where the > buffer needs to be for the attaching device/use case to be able to > access it. > > Going to change it to use an attachment instead. btw one thing we've discussed, and much easier to implement on most socs is telling apart the render vs display attachment. Most socs have different devices for that, and different pin requirements. We could do something similarly-ish on pci too, where you attach to some sub-device representing scanout. Or maybe a flag on the attachment. Either way, that would indicate an attachment where the pin indicates "must be in vram". Might be useful for SLI rendered scanout (in case that ever happens). > >> Well completely amdgpu internal handling here. Key point is we have both > >> preferred_domains as well as allowed_domains. > >> > >> During command submission we always try to move a BO to the > >> preferred_domains again. > >> > >> Now what could happen if we don't have this check is the following: > >> > >> 1. BO is allocate in VRAM. And preferred_domains says only VRAM please, but > >> allowed_domains says VRAM or GTT. > >> > >> 2. DMA-buf Importer comes along and moves the BO to GTT, which is perfectly > >> valid because of the allowed_domains. > >> > >> 3. Command submission is made and moves the BO to VRAM again. > >> > >> 4. Importer comes along and moves the BO to GTT. > >> > >> > >> E.g. a nice ping/pong situation which just eats up memory bandwidth. > > Hm yeah the ping/pong is bad, but I figure you have to already handle that > > (with some bias or whatever). Outright disabling invalidate/dynamic > > dma-buf seems like overkill. > > > > What about upgradging preferred_domains to include GTT here? Defacto what > > you do is forcing GTT, so just adding GTT as a possible domain seems like > > the better choice. Bonus points for undoing that when the last importer > > disappears. > > Well that's exactly what we want to avoid here. > > The preferred_domains is where userspace likes the buffer to be and > should never be changed by the kernel. > > The allowed_domains is where the buffer should be based on the hardware > restrictions and is usually updated by the kernel driver. > > > In general I think dynamic dma-buf needs to be able to handle this > > somehow, or it won't really work. Simplest is probably to just stop moving > > buffers around so much for buffers that are dynamically exported (so maybe > > could also change that in the CS ioctl to not move exported buffers > > anymore, would achieve the same). > > Yeah, that's the obvious alternative. But I didn't wanted to add even > more complexity to the patch right now. > > Cleaning this up is pure amdgpu internally, e.g. we need to make sure to > not move buffers around so much on command submission. Ok if the comment is clear enough for you folks that's all fine. Maybe add a FIXME about how this is a bit pessimistic and what could/should be done instead. I agree that it's probably not a use-case you really care about, since the big piles of dynamic shared buffers will be p2p. Dynamic, but not p2p is a bit an edge case really. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/doc: Improve docs for conn_state->best_encoder
Hi Daniel,
Thank you for the patch.
On Mon, May 06, 2019 at 04:46:29PM +0200, Daniel Vetter wrote:
> It's mandatory and considered core state since ioctls rely on this
> working.
>
> Thanks to Laurent for pointing out this gap.
>
> v2: Clarify to "atomic drivers" only.
>
> Cc: Laurent Pinchart
> Cc: Sean Paul
> Signed-off-by: Daniel Vetter
> ---
> include/drm/drm_connector.h | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 02a131202add..f43f40d5888a 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -517,6 +517,10 @@ struct drm_connector_state {
>* Used by the atomic helpers to select the encoder, through the
>* &drm_connector_helper_funcs.atomic_best_encoder or
>* &drm_connector_helper_funcs.best_encoder callbacks.
How about updating this part as well ?
"Used by both the DRM core and the atomic helpers to select the encoder
(through the &drm_connector_helper_funcs.atomic_best_encoder), access it
and report it to userspace (through the GETCONNECTOR and GETENCODER
ioctls). This field shall be set by all atomic drivers, either directly
or through atomic helpers."
> + *
> + * NOTE: Atomic drivers must fill this out (either themselves or through
> + * helpers), for otherwise the GETCONNECTOR and GETENCODER IOCTLs will
> + * not return correct data to userspace.
>*/
> struct drm_encoder *best_encoder;
>
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/doc: Improve docs for conn_state->best_encoder
It's mandatory and considered core state since ioctls rely on this
working.
Thanks to Laurent for pointing out this gap.
v2: Clarify to "atomic drivers" only.
Cc: Laurent Pinchart
Cc: Sean Paul
Signed-off-by: Daniel Vetter
---
include/drm/drm_connector.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 02a131202add..f43f40d5888a 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -517,6 +517,10 @@ struct drm_connector_state {
* Used by the atomic helpers to select the encoder, through the
* &drm_connector_helper_funcs.atomic_best_encoder or
* &drm_connector_helper_funcs.best_encoder callbacks.
+*
+* NOTE: Atomic drivers must fill this out (either themselves or through
+* helpers), for otherwise the GETCONNECTOR and GETENCODER IOCTLs will
+* not return correct data to userspace.
*/
struct drm_encoder *best_encoder;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu/drm: Remove duplicate headers
On Fri, May 03, 2019 at 11:28:13PM +0530, jagdsh.li...@gmail.com wrote:
> From: Jagadeesh Pagadala
>
> Remove duplicate headers which are included twice.
>
> Signed-off-by: Jagadeesh Pagadala
I collected some acks for the msm and nouveau parts and pushed this. For
next time around would be great if you split these up along driver/module
boundaries, so that each maintainer can pick this up directly.
Thanks for your patch.
-Daniel
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 1 -
> drivers/gpu/drm/nouveau/nvkm/subdev/bus/nv04.c| 2 --
> drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c | 1 -
> 3 files changed, 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
> index 018df2c..45a5bc6 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
> @@ -15,7 +15,6 @@
> #include "dpu_hwio.h"
> #include "dpu_hw_lm.h"
> #include "dpu_hw_mdss.h"
> -#include "dpu_kms.h"
>
> #define LM_OP_MODE0x00
> #define LM_OUT_SIZE 0x04
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bus/nv04.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/bus/nv04.c
> index c80b967..2b44ba5 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/bus/nv04.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bus/nv04.c
> @@ -26,8 +26,6 @@
>
> #include
>
> -#include
> -
> static void
> nv04_bus_intr(struct nvkm_bus *bus)
> {
> diff --git a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
> b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
> index 2c9c972..cacf2e0 100644
> --- a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
> +++ b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
> @@ -53,7 +53,6 @@
> #include
> #include
>
> -#include
> #include
> #include
> #include
> --
> 1.8.3.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110614] [Regression] Freeze at desktop manager startup
https://bugs.freedesktop.org/show_bug.cgi?id=110614 --- Comment #2 from Julien Isorce --- Can you try with latest master ? Should be fixed with: https://cgit.freedesktop.org/mesa/mesa/commit/?id=8cd71f399e73c5d87e9162cc74da76e317a9f41f Sorry for the inconvenience -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 00/19] Share TTM code among DRM framebuffer drivers
On Mon, May 06, 2019 at 03:09:20PM +0200, Thomas Zimmermann wrote: > Hi > > Am 06.05.19 um 14:22 schrieb Gerd Hoffmann: > >> GEM VRAM could implement PRIME helpers, which would allow for using > >> the generic fbcon. > > > > bochs_gem_prime_*() functions with this series applied look like you can > > just rename them & move over to vram helpers. > > > > It's not a full prime implementation, specifically actual export/import > > isn't there. But pin+vmap (needed by generic fbcon) is implemented. > > I did have a patch to do this, but then I read that prime requires DMA > for buffer sharing and bochs works only because it's emulated. For actual buffer sharing with other drivers yes because dma-bufs typically are a bunch of pages (struct page**) and live in RAM. Not sure whenever it is possible or useful to place the vram in ZONE_DEVICE to get page structs for it, then export buffers located in vram that way without copying them over to main memory. I suspect most importers would fail to properly setup PCI-PCI dma in that case. > If bochs' implementation is complete enough to be useful for other > drivers, I'll add it to the patch set. It's good enough for generic fbcon. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108514] heavy screen flickering with Mobility Radeon X1600 and kernel version 3.15rc2 onward
https://bugs.freedesktop.org/show_bug.cgi?id=108514 Werner Lueckel changed: What|Removed |Added Version|unspecified |DRI git -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108514] heavy screen flickering with Mobility Radeon X1600 and kernel version 3.15rc2 onward
https://bugs.freedesktop.org/show_bug.cgi?id=108514 --- Comment #34 from Werner Lueckel --- Is there any chance to get the patch implemented into 18.04 LTS? The flickering screen is really annoying ... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110621] inbox is going to blank page
https://bugs.freedesktop.org/show_bug.cgi?id=110621 Andre Klapper changed: What|Removed |Added Resolution|FIXED |INVALID Product|DRI |Spam Component|DRM/AMDgpu |Two Group||spam Status|CLOSED |RESOLVED --- Comment #1 from Andre Klapper --- Go away and test somewhere else. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 203525] brightness with function buttons Acer Aspire A315-41 notebook with AMD Ryzen 5 2500U
https://bugzilla.kernel.org/show_bug.cgi?id=203525 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) --- Can you attach your dmesg outputs for both the working kernels and non-working kernels? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 203525] New: brightness with function buttons Acer Aspire A315-41 notebook with AMD Ryzen 5 2500U
https://bugzilla.kernel.org/show_bug.cgi?id=203525 Bug ID: 203525 Summary: brightness with function buttons Acer Aspire A315-41 notebook with AMD Ryzen 5 2500U Product: Drivers Version: 2.5 Kernel Version: 4.19.37 5.0.11 5.1 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: erikjohans...@flashbox.5july.org Regression: No I got an Acer Aspire A315-41 notebook with AMD Ryzen 5 2500U and i have had problems with brightness not working out of the box (OTB) if i used function buttons. The thing is that i found that it started to work with linux-4.19.37 (fixed) but it didn't work with linux-4.19.35 (broken). It works from 4.19.37 but it doesn't work in later kernel series such as linux-5.0.11 or linux-5.1 and i think the fix should also be in newer kernels. I started to bisect but linux-4.19.36 doesn't boot with my hardware and after many bisect skip and compiling i gave up. Do anyone know what commit that could have fixed it? Or why 4.19.36 won't boot on my hardware (if there was some known regression) so i can perform an bisect. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 01/19] drm: Add |struct drm_gem_vram_object| and helpers
Hi
Am 06.05.19 um 15:17 schrieb Gerd Hoffmann:
> Hi,
>
>> This misses the call to drm_gem_vram_placement(), where
>> drm_gem_vram_push_to_system() enforces placement in system memory.
>
> Ah, missed that detail.
>
>> We
>> could build a common implementation out of both interfaces, but that
>> would obfuscate the code IMHO. I'd just leave it as it is.
>
> Ok.
>
+struct drm_gem_vram_object {
+ /* Supported placements are %TTM_PL_VRAM and %TTM_PL_SYSTEM */
+ struct ttm_placement placement;
+ struct ttm_place placements[3];
>>>
>>> placements[2] should be enough I guess?
>>
>> TTM_PL_VRAM has index 2 and TTM_PL_SYSTEM has index 0. There's TTM_PL_TT
>> at index 1. We don't use all three array entries here, but I'm not sure
>> if something in TTM does. I took the line from the drivers and didn't
>> change it for that reason.
>
> TTM_PL_* isn't an index into that array. See drm_gem_vram_placement()
> which fills that array. It'll use one or two entries of that array.
The field 'placements' is assigned to 'placement.placements' and
'placement.busy_placement'. The placement field is later given to
ttm_bo_validate() for internal use by TTM. From reading ttm_bo.c, that's
apparently not a problem. I'm just being defensive here, but let's
remove the additional entry if it's just overhead.
Best regards
Thomas
> cheers,
> Gerd
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH next 25/25] video: fbdev: Use dev_get_drvdata()
On 04/23/2019 09:50 AM, Kefeng Wang wrote: > Using dev_get_drvdata directly. > > Cc: Wan ZongShun > Cc: Kukjin Kim > Cc: Bartlomiej Zolnierkiewicz > Cc: Krzysztof Kozlowski > Cc: Michal Januszewski > Cc: dri-devel@lists.freedesktop.org > Cc: linux-fb...@vger.kernel.org > Signed-off-by: Kefeng Wang Patch queued for v5.2, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 45/79] docs: console.txt: convert docs to ReST and rename to *.rst
On 04/22/2019 03:27 PM, Mauro Carvalho Chehab wrote: > Convert this small file to ReST in preparation for adding it to > the driver-api book. > > While this is not part of the driver-api book, mark it as > :orphan:, in order to avoid build warnings. > > Signed-off-by: Mauro Carvalho Chehab Acked-by: Bartlomiej Zolnierkiewicz Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 13/79] docs: fb: convert docs to ReST and rename to *.rst
On 04/22/2019 03:27 PM, Mauro Carvalho Chehab wrote: > The conversion is actually: > - add blank lines and identation in order to identify paragraphs; > - fix tables markups; > - add some lists markups; > - mark literal blocks; > - adjust title markups. > > At its new index.rst, let's add a :orphan: while this is not linked to > the main index.rst file, in order to avoid build warnings. > > Signed-off-by: Mauro Carvalho Chehab Acked-by: Bartlomiej Zolnierkiewicz Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/virtio: Remove redundant return type
On Mon, May 06, 2019 at 11:10:34AM +0200, Robert Foss wrote: > virtio_gpu_fence_emit() always returns 0, since it > has no error paths. > > Consequently no calls for virtio_gpu_fence_emit() > use the return value, and it can be removed. > > Signed-off-by: Robert Foss > Suggested-by: Emil Velikov > Reviewed-by: Chia-I Wu Pushed to drm-misc-next. thanks, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 14/26] compat_ioctl: move ATYFB_CLK handling to atyfb driver
On 04/16/2019 10:25 PM, Arnd Bergmann wrote: > These are two obscure ioctl commands, in a driver that only > has compatible commands, so just let the driver handle this > itself. > > Signed-off-by: Arnd Bergmann Acked-by: Bartlomiej Zolnierkiewicz Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/57] docs: fb: convert documentation to ReST format
On 04/16/2019 04:55 AM, Mauro Carvalho Chehab wrote: > Convert all documents here from plain txt to ReST format, in > order to allow parsing them with the documentation build > system. > > Signed-off-by: Mauro Carvalho Chehab Acked-by: Bartlomiej Zolnierkiewicz Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbcon: Don't reset logo_shown when logo is currently shown
On 04/02/2019 08:09 PM, Andreas Schwab wrote:
> When the logo is currently drawn on a virtual console, and the console
> loglevel is reduced to quiet, logo_shown must be left alone, so that it
> the scrolling region on that virtual console is properly reset.
>
> Fixes: 10993504d647 ("fbcon: Silence fbcon logo on 'quiet' boots")
> Signed-off-by: Andreas Schwab
Patch queued for v5.2, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 18/20] lib: image-formats: Add v4l2 formats support
Hi Hans On Thu, May 02, 2019 at 10:24:00AM +0200, Hans Verkuil wrote: > On 4/17/19 9:54 AM, Maxime Ripard wrote: > > V4L2 uses different fourcc's than DRM, and has a different set of formats. > > For now, let's add the v4l2 fourcc's for the already existing formats. > > For this lib to be more useful for V4L2, would it be a good idea to add > Bayer formats as well? This can be done in a separate patch. > > Those formats are V4L specific, but are very common. Yeah, this was mostly to support the formats that are already supported as of today, but eventually more are going to be supported, and the bayer formats seems like a natural choice :) Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 01/19] drm: Add |struct drm_gem_vram_object| and helpers
Hi,
> This misses the call to drm_gem_vram_placement(), where
> drm_gem_vram_push_to_system() enforces placement in system memory.
Ah, missed that detail.
> We
> could build a common implementation out of both interfaces, but that
> would obfuscate the code IMHO. I'd just leave it as it is.
Ok.
> >> +struct drm_gem_vram_object {
> >> + /* Supported placements are %TTM_PL_VRAM and %TTM_PL_SYSTEM */
> >> + struct ttm_placement placement;
> >> + struct ttm_place placements[3];
> >
> > placements[2] should be enough I guess?
>
> TTM_PL_VRAM has index 2 and TTM_PL_SYSTEM has index 0. There's TTM_PL_TT
> at index 1. We don't use all three array entries here, but I'm not sure
> if something in TTM does. I took the line from the drivers and didn't
> change it for that reason.
TTM_PL_* isn't an index into that array. See drm_gem_vram_placement()
which fills that array. It'll use one or two entries of that array.
cheers,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 12/19] drm/bochs: Convert bochs driver to VRAM MM
Hi
Am 06.05.19 um 14:40 schrieb Gerd Hoffmann:
> Hi,
>
>> static const struct file_operations bochs_fops = {
>> .owner = THIS_MODULE,
>> -.open = drm_open,
>> -.release= drm_release,
>> -.unlocked_ioctl = drm_ioctl,
>> -.compat_ioctl = drm_compat_ioctl,
>> -.poll = drm_poll,
>> -.read = drm_read,
>> .llseek = no_llseek,
>> -.mmap = bochs_mmap,
>> +DRM_VRAM_MM_FILE_OPERATIONS
>> };
>
> What about llseek? I think it should either be deleted (if not needed)
> or added to DRM_VRAM_MM_FILE_OPERATIONS (if needed).
Some drivers set no_llseek, some leave the .llseek field to NULL. So I
don't set the field from DRM_VRAM_MM_FILE_OPERATIONS.
But now that you asked, I found that DRM actually requires no_llseek.
I'll add it to the default operations in the next iteration of the patch
set.
Best regards
Thomas
> cheers,
> Gerd
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
