[PATCH 4/5] drm/amdgpu: Wait for end of last waited-for vblank before programming flip
On 06/13/16 23:06, Daniel Vetter wrote: > On Mon, Jun 13, 2016 at 05:58:29PM +0900, Michel Dänzer wrote: >> On 06/13/16 17:06, Daniel Vetter wrote: >>> On Mon, Jun 13, 2016 at 10:54:37AM +0900, Michel Dänzer wrote: On 10.06.2016 23:43, Daniel Vetter wrote: > On Fri, Jun 10, 2016 at 05:57:12PM +0900, Michel Dänzer wrote: >> From: Michel Dänzer >> >> If userspace wants a page flip to take effect during vblank sequence n, >> it has to wait for vblank seqno n-1 before calling the >> DRM_IOCTL_MODE_PAGE_FLIP ioctl. >> >> This change makes sure that we do not program the flip to the hardware >> before the end of vblank seqno n-1 in this case, to prevent the flip >> from taking effect too early. >> >> On the other hand, if the DRM_IOCTL_MODE_PAGE_FLIP ioctl is called >> during vblank, but userspace didn't wait for the current vblank seqno >> before, this change would still allow the flip to be programmed during >> the current vblank seqno. > > This just sounds like you're sending vblank events out a bit too early. > And watching vblank waits that userspace does works, but it's fragile, > add-hoc and I don't really jump in joy about adding that to the vblank > core. Is there no way you can adjust sending out the vblank events > similarly, to make sure userspace can never sneak in a pageflip too early? What you call "too early" is actually "during the vertical blank period waited for". IMHO only notifying userspace of a vertical blank period when it's already over would defeat the purpose. >>> >>> Afaiui the rules are: >>> - The timestamp for vblank event needs to agree with whatever oml_sync >>> requries. >>> - The event delivery itself needs to be consistent with what page_flip >>> takes, i.e. if userspace sees an event and immediately issues a >>> page_flip then it should not be able to hit the same vblank with that >>> pageflip. >>> - The event needs to be after the old buffers are not longer used and can >>> be reused for rendering. >> >> That's only relevant for DRM_IOCTL_MODE_PAGE_FLIP, not >> DRM_IOCTL_WAIT_VBLANK. > > Yup, mixed that up. > >>> - There's no requirement at all that the event gets delivered at a >>> specific point in the vblank, hardware is too different for that to work >> >> As the name implies, the purpose of DRM_IOCTL_WAIT_VBLANK is to wait for >> a vertical blank period. If that doesn't work as intended with some >> hardware, that's tough luck but not really my problem. :) >> >>> - that kind of precision is why we have a separate timestamp. >> >> I'm afraid this last item gives away that you're relatively new to this >> code. ;) The timestamp was originally literally just the current >> gettimeofday when the wait finished (the original DRM_IOCTL_WAIT_VBLANK >> ioctl didn't have any asynchronous notification functionality). It was >> relatively recently that Mario changed the timestamp to correspond to >> the end of the vertical blank period / start of scanout of the next >> frame, presumably due to your first rule above. > > Most hw just seems to give you a vblank interrupt somewhere in the vblank > are, or sometimes even slightly before that. Our hardware tends to trigger the vblank interrupt early, but it's still useful in that drawing operations submitted after it cannot affect the previously scanned out frame. > Also there's scheduling jitter. Sure, but there's a big difference between "no guarantee that we're still in vblank" vs "guarantee that we're no longer in vblank". >>> I assume you're goal is to not delay page_flips unecessarily, without >>> breaking requirement 2 here. Imo a simpler fix would be to delay the >>> vblank handling to end of vblank. Fixes everything without hacks, [...] >> >> Except it breaks the original purpose of the wait for vblank >> functionality, which is to wait for the beginning of a vertical blank >> period. [0] You're focusing too much on page flips and suggesting to >> throw out the vblank baby with the bathwater. I really don't see the big >> issue which would justify that. >> >> >> [0] As an analogy, how useful would e.g. calendar notifications be if >> they arrived at the end of the events they're about? "Hey, that meeting >> you were supposed to attend? It just finished!" > > Ok, what exactly is the use-case for waiting for vblanks _without_ > scheduling a flip afterwards? At least in drm the rule is that ABI is what > userspace observes and actually cares about. E.g.: In cases where page flipping cannot be used, Xorg / the DDX driver waits for the target vertical blank period before emitting the drawing commands for a buffer swap operation. If the vblank notification only arrives when the vertical blank period is already over, this is very likely to result in tearing. Some X compositors and AFAIK even applications such as media players can use DRM_IOCTL_WAIT_VBLANK similarly. Obviously it's not intended to be
linux-next: manual merge of the drm tree with the drm-intel-fixes tree
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/intel_display.c
between commit:
a5aac5ab876a ("drm/i915: Check VBT for port presence in addition to the strap
on VLV/CHV")
from the drm-intel-fixes tree and commit:
457c52d87e5d ("drm/i915: Only ignore eDP ports that are connected")
(which is also in the drm-intel-fixes tree)
from the drm tree.
I fixed it up (I used the version form the drm-intel-fixes tree) and
can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
[PATCH 1/2] drm/amdgpu: stop trying to schedule() with a spin held
On 06/13/16 23:12, Christian König wrote: > From: Christian König > > Drop the lock before calling cancel_delayed_work_sync(). > > Signed-off-by: Christian König > Tested-by: Nicolai Hähnle Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96445 -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[Bug 119631] RadeonSI get a huge performance dip with used with the nine state tracker
https://bugzilla.kernel.org/show_bug.cgi?id=119631 --- Comment #6 from Michel Dänzer --- Does the problem also occur with xserver 1.18.3 or newer? -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 1/2] drm/mediatek: Add gamma correction
Apply gamma function to correct brightness values.
It applies arbitrary mapping curve to compensate the
incorrect transfer function of the panel.
Signed-off-by: Bibby Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 12 ++
drivers/gpu/drm/mediatek/mtk_drm_crtc.h |1 +
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 56 ++-
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |9 +
4 files changed, 77 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 24aa3ba..1b38406 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -127,6 +127,16 @@ static void mtk_drm_crtc_reset(struct drm_crtc *crtc)
state->base.crtc = crtc;
}
+static void mtk_crtc_gamma_set(struct drm_crtc *crtc, u16 *r,
+ u16 *g, u16 *b, uint32_t start, uint32_t size)
+{
+ struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
+ unsigned int i;
+
+ for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)
+ mtk_ddp_gamma_set(mtk_crtc->ddp_comp[i], r, g, b, start, size);
+}
+
static struct drm_crtc_state *mtk_drm_crtc_duplicate_state(struct drm_crtc
*crtc)
{
struct mtk_crtc_state *state;
@@ -418,6 +428,7 @@ static const struct drm_crtc_funcs mtk_crtc_funcs = {
.reset = mtk_drm_crtc_reset,
.atomic_duplicate_state = mtk_drm_crtc_duplicate_state,
.atomic_destroy_state = mtk_drm_crtc_destroy_state,
+ .gamma_set = mtk_crtc_gamma_set,
};
static const struct drm_crtc_helper_funcs mtk_crtc_helper_funcs = {
@@ -569,6 +580,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
if (ret < 0)
goto unprepare;
+ drm_mode_crtc_set_gamma_size(&mtk_crtc->base, MTK_LUT_SIZE);
priv->crtc[pipe] = &mtk_crtc->base;
priv->num_pipes++;
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
index 81e5566..d332564 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
@@ -19,6 +19,7 @@
#include "mtk_drm_plane.h"
#define OVL_LAYER_NR 4
+#define MTK_LUT_SIZE 512
int mtk_drm_crtc_enable_vblank(struct drm_device *drm, unsigned int pipe);
void mtk_drm_crtc_disable_vblank(struct drm_device *drm, unsigned int pipe);
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 3970fcf..3fd5141 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -24,6 +24,7 @@
#include "mtk_drm_drv.h"
#include "mtk_drm_plane.h"
#include "mtk_drm_ddp_comp.h"
+#include "mtk_drm_crtc.h"
#define DISP_OD_EN 0x
#define DISP_OD_INTEN 0x0008
@@ -38,6 +39,18 @@
#define DISP_COLOR_WIDTH 0x0c50
#define DISP_COLOR_HEIGHT 0x0c54
+#define DISP_AAL_EN0x000
+#define DISP_AAL_SIZE 0x030
+
+#define DISP_GAMMA_CFG 0x020
+#define DISP_GAMMA_LUT 0x700
+
+#define LUT_10BIT_MASK 0x3ff
+
+#define AAL_EN BIT(0)
+
+#define GAMMA_LUT_EN BIT(1)
+
#defineOD_RELAY_MODE BIT(0)
#defineUFO_BYPASS BIT(2)
@@ -76,6 +89,40 @@ static void mtk_ufoe_start(struct mtk_ddp_comp *comp)
writel(UFO_BYPASS, comp->regs + DISP_REG_UFO_START);
}
+static void mtk_aal_config(struct mtk_ddp_comp *comp, unsigned int w,
+ unsigned int h, unsigned int vrefresh)
+{
+ writel(h << 16 | w, comp->regs + DISP_AAL_SIZE);
+}
+
+static void mtk_aal_start(struct mtk_ddp_comp *comp)
+{
+ writel(AAL_EN, comp->regs + DISP_AAL_EN);
+}
+
+static void mtk_aal_stop(struct mtk_ddp_comp *comp)
+{
+ writel_relaxed(0x0, comp->regs + DISP_AAL_EN);
+}
+
+static void mtk_gamma_set(struct mtk_ddp_comp *comp, u16 *r, u16 *g,
+ u16 *b, uint32_t start, uint32_t size)
+{
+ int i;
+ unsigned int lut;
+ int end = (start + size > MTK_LUT_SIZE) ? MTK_LUT_SIZE : start + size;
+ void __iomem *lut_base;
+
+ writel(GAMMA_LUT_EN, comp->regs + DISP_GAMMA_CFG);
+ lut_base = comp->regs + DISP_GAMMA_LUT;
+ for (i = start; i < end; i++) {
+ lut = (((r[i] >> 6) & LUT_10BIT_MASK) << 20) +
+ (((g[i] >> 6) & LUT_10BIT_MASK) << 10) +
+ ((b[i] >> 6) & LUT_10BIT_MASK);
+ writel(lut, (lut_base + i * 4));
+ }
+}
+
static const struct mtk_ddp_comp_funcs ddp_color = {
.config = mtk_color_config,
.start = mtk_color_start,
@@ -90,6 +137,13 @@ static const struct mtk_ddp_comp_funcs ddp_ufoe = {
.start = mtk_ufoe_start,
};
+static const struct mtk_
[PATCH 2/2] drm/mediatek: set mt8173 dithering function
Some panels only accept bpc (bit per color) 6-bit.
But, the default bpc in mt8173 display data path is 8-bit.
If we didn't enable dithering function to convert bpc,
display cannot show the smooth grayscale image.
In mt8173, the dithering function in OD (OverDrive) and
GAMMA module, we have to config them with
connector->display_mode.bpc when CRTC initial.
1. Clear the default value at *_DITHER_5 and *_DITHER_7 register.
2. Calculate the LSB_ERR_SHIFT bits and ADD_LSHIFT bits two values.
i.e. Input bpc of OD is 10 bits, we assume the bpc of panel is 6-bit,
so, we need to set 4-bit to LSB_ERR_SHIFT and ADD_LSHIFT bits respectively.
3. Then, set the OD or GAMMA to dithering mode depends on path-1 or path-2.
Signed-off-by: Bibby Hsieh
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c |3 +-
drivers/gpu/drm/mediatek/mtk_disp_rdma.c|3 +-
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 18 +--
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 44 +--
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |6 ++--
5 files changed, 64 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 8f62671f..019b7ca 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -103,7 +103,8 @@ static void mtk_ovl_stop(struct mtk_ddp_comp *comp)
}
static void mtk_ovl_config(struct mtk_ddp_comp *comp, unsigned int w,
- unsigned int h, unsigned int vrefresh)
+ unsigned int h, unsigned int vrefresh,
+ unsigned int bpc)
{
if (w != 0 && h != 0)
writel_relaxed(h << 16 | w, comp->regs + DISP_REG_OVL_ROI_SIZE);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 5fb80cb..0df05f9 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -106,7 +106,8 @@ static void mtk_rdma_stop(struct mtk_ddp_comp *comp)
}
static void mtk_rdma_config(struct mtk_ddp_comp *comp, unsigned int width,
- unsigned int height, unsigned int vrefresh)
+ unsigned int height, unsigned int vrefresh,
+ unsigned int bpc)
{
unsigned int threshold;
unsigned int reg;
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 1b38406..96c1b31 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -52,6 +52,7 @@ struct mtk_drm_crtc {
struct mtk_disp_mutex *mutex;
unsigned intddp_comp_nr;
struct mtk_ddp_comp **ddp_comp;
+ unsigned intbpc;
};
struct mtk_crtc_state {
@@ -232,6 +233,8 @@ static void mtk_crtc_ddp_clk_disable(struct mtk_drm_crtc
*mtk_crtc)
static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc *mtk_crtc)
{
struct drm_crtc *crtc = &mtk_crtc->base;
+ struct drm_connector *connector;
+ struct drm_encoder *encoder;
unsigned int width, height, vrefresh;
int ret;
int i;
@@ -243,6 +246,15 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc
*mtk_crtc)
width = crtc->state->adjusted_mode.hdisplay;
height = crtc->state->adjusted_mode.vdisplay;
vrefresh = crtc->state->adjusted_mode.vrefresh;
+ drm_for_each_encoder(encoder, crtc->dev) {
+ if (encoder->crtc != crtc)
+ continue;
+ drm_for_each_connector(connector, crtc->dev) {
+ if (connector->encoder != encoder)
+ continue;
+ mtk_crtc->bpc = connector->display_info.bpc;
+ }
+ }
ret = pm_runtime_get_sync(crtc->dev->dev);
if (ret < 0) {
@@ -276,7 +288,8 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc
*mtk_crtc)
for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[i];
- mtk_ddp_comp_config(comp, width, height, vrefresh);
+ mtk_ddp_comp_config(comp, width, height, vrefresh,
+ mtk_crtc->bpc);
mtk_ddp_comp_start(comp);
}
@@ -475,7 +488,8 @@ void mtk_crtc_ddp_irq(struct drm_crtc *crtc, struct
mtk_ddp_comp *ovl)
if (state->pending_config) {
mtk_ddp_comp_config(ovl, state->pending_width,
state->pending_height,
- state->pending_vrefresh);
+ state->pending_vrefresh,
+ mtk_crtc->bpc);
state->pending_config = false;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 3fd5
[Bug 119631] RadeonSI get a huge performance dip with used with the nine state tracker
https://bugzilla.kernel.org/show_bug.cgi?id=119631 --- Comment #7 from Mathieu Belanger --- Yes, I just updated xserver to 1.18.3, bug still present. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 1/2] drm/mediatek: Add gamma correction
On Tue, Jun 14, 2016 at 10:55:52AM +0800, Bibby Hsieh wrote:
> Apply gamma function to correct brightness values.
> It applies arbitrary mapping curve to compensate the
> incorrect transfer function of the panel.
>
> Signed-off-by: Bibby Hsieh
I think it would be much better to use the new atomic color management
support, which includes gamma. See drm_crtc_enable_color_mgmt.
-Daniel
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 12 ++
> drivers/gpu/drm/mediatek/mtk_drm_crtc.h |1 +
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 56
> ++-
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |9 +
> 4 files changed, 77 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 24aa3ba..1b38406 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -127,6 +127,16 @@ static void mtk_drm_crtc_reset(struct drm_crtc *crtc)
> state->base.crtc = crtc;
> }
>
> +static void mtk_crtc_gamma_set(struct drm_crtc *crtc, u16 *r,
> +u16 *g, u16 *b, uint32_t start, uint32_t size)
> +{
> + struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> + unsigned int i;
> +
> + for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)
> + mtk_ddp_gamma_set(mtk_crtc->ddp_comp[i], r, g, b, start, size);
> +}
> +
> static struct drm_crtc_state *mtk_drm_crtc_duplicate_state(struct drm_crtc
> *crtc)
> {
> struct mtk_crtc_state *state;
> @@ -418,6 +428,7 @@ static const struct drm_crtc_funcs mtk_crtc_funcs = {
> .reset = mtk_drm_crtc_reset,
> .atomic_duplicate_state = mtk_drm_crtc_duplicate_state,
> .atomic_destroy_state = mtk_drm_crtc_destroy_state,
> + .gamma_set = mtk_crtc_gamma_set,
> };
>
> static const struct drm_crtc_helper_funcs mtk_crtc_helper_funcs = {
> @@ -569,6 +580,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
> if (ret < 0)
> goto unprepare;
>
> + drm_mode_crtc_set_gamma_size(&mtk_crtc->base, MTK_LUT_SIZE);
> priv->crtc[pipe] = &mtk_crtc->base;
> priv->num_pipes++;
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> index 81e5566..d332564 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> @@ -19,6 +19,7 @@
> #include "mtk_drm_plane.h"
>
> #define OVL_LAYER_NR 4
> +#define MTK_LUT_SIZE 512
>
> int mtk_drm_crtc_enable_vblank(struct drm_device *drm, unsigned int pipe);
> void mtk_drm_crtc_disable_vblank(struct drm_device *drm, unsigned int pipe);
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index 3970fcf..3fd5141 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -24,6 +24,7 @@
> #include "mtk_drm_drv.h"
> #include "mtk_drm_plane.h"
> #include "mtk_drm_ddp_comp.h"
> +#include "mtk_drm_crtc.h"
>
> #define DISP_OD_EN 0x
> #define DISP_OD_INTEN0x0008
> @@ -38,6 +39,18 @@
> #define DISP_COLOR_WIDTH 0x0c50
> #define DISP_COLOR_HEIGHT0x0c54
>
> +#define DISP_AAL_EN 0x000
> +#define DISP_AAL_SIZE0x030
> +
> +#define DISP_GAMMA_CFG 0x020
> +#define DISP_GAMMA_LUT 0x700
> +
> +#define LUT_10BIT_MASK 0x3ff
> +
> +#define AAL_EN BIT(0)
> +
> +#define GAMMA_LUT_EN BIT(1)
> +
> #define OD_RELAY_MODE BIT(0)
>
> #define UFO_BYPASS BIT(2)
> @@ -76,6 +89,40 @@ static void mtk_ufoe_start(struct mtk_ddp_comp *comp)
> writel(UFO_BYPASS, comp->regs + DISP_REG_UFO_START);
> }
>
> +static void mtk_aal_config(struct mtk_ddp_comp *comp, unsigned int w,
> +unsigned int h, unsigned int vrefresh)
> +{
> + writel(h << 16 | w, comp->regs + DISP_AAL_SIZE);
> +}
> +
> +static void mtk_aal_start(struct mtk_ddp_comp *comp)
> +{
> + writel(AAL_EN, comp->regs + DISP_AAL_EN);
> +}
> +
> +static void mtk_aal_stop(struct mtk_ddp_comp *comp)
> +{
> + writel_relaxed(0x0, comp->regs + DISP_AAL_EN);
> +}
> +
> +static void mtk_gamma_set(struct mtk_ddp_comp *comp, u16 *r, u16 *g,
> + u16 *b, uint32_t start, uint32_t size)
> +{
> + int i;
> + unsigned int lut;
> + int end = (start + size > MTK_LUT_SIZE) ? MTK_LUT_SIZE : start + size;
> + void __iomem *lut_base;
> +
> + writel(GAMMA_LUT_EN, comp->regs + DISP_GAMMA_CFG);
> + lut_base = comp->regs + DISP_GAMMA_LUT;
> + for (i = start; i < end; i++) {
> + lut = (((r[i] >> 6) & LUT_10BIT_MASK) << 20) +
> +
[PATCH 4/5] drm/amdgpu: Wait for end of last waited-for vblank before programming flip
On Tue, Jun 14, 2016 at 11:09:10AM +0900, Michel Dänzer wrote: > On 06/13/16 23:06, Daniel Vetter wrote: > > On Mon, Jun 13, 2016 at 05:58:29PM +0900, Michel Dänzer wrote: > >> On 06/13/16 17:06, Daniel Vetter wrote: > >>> On Mon, Jun 13, 2016 at 10:54:37AM +0900, Michel Dänzer wrote: > On 10.06.2016 23:43, Daniel Vetter wrote: > > On Fri, Jun 10, 2016 at 05:57:12PM +0900, Michel Dänzer wrote: > >> From: Michel Dänzer > >> > >> If userspace wants a page flip to take effect during vblank sequence n, > >> it has to wait for vblank seqno n-1 before calling the > >> DRM_IOCTL_MODE_PAGE_FLIP ioctl. > >> > >> This change makes sure that we do not program the flip to the hardware > >> before the end of vblank seqno n-1 in this case, to prevent the flip > >> from taking effect too early. > >> > >> On the other hand, if the DRM_IOCTL_MODE_PAGE_FLIP ioctl is called > >> during vblank, but userspace didn't wait for the current vblank seqno > >> before, this change would still allow the flip to be programmed during > >> the current vblank seqno. > > > > This just sounds like you're sending vblank events out a bit too early. > > And watching vblank waits that userspace does works, but it's fragile, > > add-hoc and I don't really jump in joy about adding that to the vblank > > core. Is there no way you can adjust sending out the vblank events > > similarly, to make sure userspace can never sneak in a pageflip too > > early? > > What you call "too early" is actually "during the vertical blank period > waited for". IMHO only notifying userspace of a vertical blank period > when it's already over would defeat the purpose. > >>> > >>> Afaiui the rules are: > >>> - The timestamp for vblank event needs to agree with whatever oml_sync > >>> requries. > >>> - The event delivery itself needs to be consistent with what page_flip > >>> takes, i.e. if userspace sees an event and immediately issues a > >>> page_flip then it should not be able to hit the same vblank with that > >>> pageflip. > >>> - The event needs to be after the old buffers are not longer used and can > >>> be reused for rendering. > >> > >> That's only relevant for DRM_IOCTL_MODE_PAGE_FLIP, not > >> DRM_IOCTL_WAIT_VBLANK. > > > > Yup, mixed that up. > > > >>> - There's no requirement at all that the event gets delivered at a > >>> specific point in the vblank, hardware is too different for that to work > >> > >> As the name implies, the purpose of DRM_IOCTL_WAIT_VBLANK is to wait for > >> a vertical blank period. If that doesn't work as intended with some > >> hardware, that's tough luck but not really my problem. :) > >> > >>> - that kind of precision is why we have a separate timestamp. > >> > >> I'm afraid this last item gives away that you're relatively new to this > >> code. ;) The timestamp was originally literally just the current > >> gettimeofday when the wait finished (the original DRM_IOCTL_WAIT_VBLANK > >> ioctl didn't have any asynchronous notification functionality). It was > >> relatively recently that Mario changed the timestamp to correspond to > >> the end of the vertical blank period / start of scanout of the next > >> frame, presumably due to your first rule above. > > > > Most hw just seems to give you a vblank interrupt somewhere in the vblank > > are, or sometimes even slightly before that. > > Our hardware tends to trigger the vblank interrupt early, but it's still > useful in that drawing operations submitted after it cannot affect the > previously scanned out frame. > > > Also there's scheduling jitter. > > Sure, but there's a big difference between "no guarantee that we're > still in vblank" vs "guarantee that we're no longer in vblank". > > > >>> I assume you're goal is to not delay page_flips unecessarily, without > >>> breaking requirement 2 here. Imo a simpler fix would be to delay the > >>> vblank handling to end of vblank. Fixes everything without hacks, [...] > >> > >> Except it breaks the original purpose of the wait for vblank > >> functionality, which is to wait for the beginning of a vertical blank > >> period. [0] You're focusing too much on page flips and suggesting to > >> throw out the vblank baby with the bathwater. I really don't see the big > >> issue which would justify that. > >> > >> > >> [0] As an analogy, how useful would e.g. calendar notifications be if > >> they arrived at the end of the events they're about? "Hey, that meeting > >> you were supposed to attend? It just finished!" > > > > Ok, what exactly is the use-case for waiting for vblanks _without_ > > scheduling a flip afterwards? At least in drm the rule is that ABI is what > > userspace observes and actually cares about. > > E.g.: In cases where page flipping cannot be used, Xorg / the DDX driver > waits for the target vertical blank period before emitting the drawing > commands for a buffer swap operation. If th
[Bug 90481] Radeonsi driver, X crash while playing "Spec ops: the line"
https://bugs.freedesktop.org/show_bug.cgi?id=90481 --- Comment #12 from Nicolai Hähnle --- Based on the reported GRBM_STATUS registers, the hang is probably somewhere in the pixel pipe, since VGT_BUSY and PA_BUSY = 0. But it's difficult to say more. Framerate sensitivity is definitely possible. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160614/e2fae2a4/attachment.html>
[Intel-gfx] [PATCH] drm/i915: Fix missing unlock on error in i915_ppgtt_info()
On Mon, Jun 13, 2016 at 11:42:00PM +, weiyj_lk at 163.com wrote:
> From: Wei Yongjun
>
> Add the missing unlock before return from function i915_ppgtt_info()
> in the error handling case.
>
> Fixes: 1d2ac403ae3b(drm: Protect dev->filelist with its own mutex)
> Signed-off-by: Wei Yongjun
Applied to drm-misc, thanks.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 3269033..1035468 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2365,16 +2365,16 @@ static int i915_ppgtt_info(struct seq_file *m, void
> *data)
> task = get_pid_task(file->pid, PIDTYPE_PID);
> if (!task) {
> ret = -ESRCH;
> - goto out_put;
> + goto out_unlock;
> }
> seq_printf(m, "\nproc: %s\n", task->comm);
> put_task_struct(task);
> idr_for_each(&file_priv->context_idr, per_file_ctx,
>(void *)(unsigned long)m);
> }
> +out_unlock:
> mutex_unlock(&dev->filelist_mutex);
>
> -out_put:
> intel_runtime_pm_put(dev_priv);
> mutex_unlock(&dev->struct_mutex);
>
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 4/5] drm/amdgpu: Wait for end of last waited-for vblank before programming flip
On 14.06.2016 14:53, Daniel Vetter wrote: > On Tue, Jun 14, 2016 at 11:09:10AM +0900, Michel Dänzer wrote: >> On 06/13/16 23:06, Daniel Vetter wrote: >>> On Mon, Jun 13, 2016 at 05:58:29PM +0900, Michel Dänzer wrote: On 06/13/16 17:06, Daniel Vetter wrote: > On Mon, Jun 13, 2016 at 10:54:37AM +0900, Michel Dänzer wrote: >> On 10.06.2016 23:43, Daniel Vetter wrote: >>> On Fri, Jun 10, 2016 at 05:57:12PM +0900, Michel Dänzer wrote: From: Michel Dänzer If userspace wants a page flip to take effect during vblank sequence n, it has to wait for vblank seqno n-1 before calling the DRM_IOCTL_MODE_PAGE_FLIP ioctl. This change makes sure that we do not program the flip to the hardware before the end of vblank seqno n-1 in this case, to prevent the flip from taking effect too early. On the other hand, if the DRM_IOCTL_MODE_PAGE_FLIP ioctl is called during vblank, but userspace didn't wait for the current vblank seqno before, this change would still allow the flip to be programmed during the current vblank seqno. >>> >>> This just sounds like you're sending vblank events out a bit too early. >>> And watching vblank waits that userspace does works, but it's fragile, >>> add-hoc and I don't really jump in joy about adding that to the vblank >>> core. Is there no way you can adjust sending out the vblank events >>> similarly, to make sure userspace can never sneak in a pageflip too >>> early? >> >> What you call "too early" is actually "during the vertical blank period >> waited for". IMHO only notifying userspace of a vertical blank period >> when it's already over would defeat the purpose. > > Afaiui the rules are: > - The timestamp for vblank event needs to agree with whatever oml_sync > requries. > - The event delivery itself needs to be consistent with what page_flip > takes, i.e. if userspace sees an event and immediately issues a > page_flip then it should not be able to hit the same vblank with that > pageflip. > - The event needs to be after the old buffers are not longer used and can > be reused for rendering. That's only relevant for DRM_IOCTL_MODE_PAGE_FLIP, not DRM_IOCTL_WAIT_VBLANK. >>> >>> Yup, mixed that up. >>> > - There's no requirement at all that the event gets delivered at a > specific point in the vblank, hardware is too different for that to work As the name implies, the purpose of DRM_IOCTL_WAIT_VBLANK is to wait for a vertical blank period. If that doesn't work as intended with some hardware, that's tough luck but not really my problem. :) > - that kind of precision is why we have a separate timestamp. I'm afraid this last item gives away that you're relatively new to this code. ;) The timestamp was originally literally just the current gettimeofday when the wait finished (the original DRM_IOCTL_WAIT_VBLANK ioctl didn't have any asynchronous notification functionality). It was relatively recently that Mario changed the timestamp to correspond to the end of the vertical blank period / start of scanout of the next frame, presumably due to your first rule above. >>> >>> Most hw just seems to give you a vblank interrupt somewhere in the vblank >>> are, or sometimes even slightly before that. >> >> Our hardware tends to trigger the vblank interrupt early, but it's still >> useful in that drawing operations submitted after it cannot affect the >> previously scanned out frame. >> >>> Also there's scheduling jitter. >> >> Sure, but there's a big difference between "no guarantee that we're >> still in vblank" vs "guarantee that we're no longer in vblank". >> >> > I assume you're goal is to not delay page_flips unecessarily, without > breaking requirement 2 here. Imo a simpler fix would be to delay the > vblank handling to end of vblank. Fixes everything without hacks, [...] Except it breaks the original purpose of the wait for vblank functionality, which is to wait for the beginning of a vertical blank period. [0] You're focusing too much on page flips and suggesting to throw out the vblank baby with the bathwater. I really don't see the big issue which would justify that. [0] As an analogy, how useful would e.g. calendar notifications be if they arrived at the end of the events they're about? "Hey, that meeting you were supposed to attend? It just finished!" >>> >>> Ok, what exactly is the use-case for waiting for vblanks _without_ >>> scheduling a flip afterwards? At least in drm the rule is that ABI is what >>> userspace observes and actually cares about. >> >> E.g.: In cases where page flipping cannot be used, Xorg / the DDX driver >> waits for the target vertical blank period before emitting the drawi
[PATCH v8 2/2] drm/bridge: Add sii902x DT bindings doc
Add Sii9022 DT bindings description.
Signed-off-by: Boris Brezillon
Acked-by: Rob Herring
---
Changes since v6:
- make 'reset-gpios' optional
Changes since v1:
- rename doc file
- s/sil902/sii902/
---
.../devicetree/bindings/display/bridge/sii902x.txt | 35 ++
1 file changed, 35 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/bridge/sii902x.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/sii902x.txt
b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
new file mode 100644
index 000..56a3e68
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
@@ -0,0 +1,35 @@
+sii902x HDMI bridge bindings
+
+Required properties:
+ - compatible: "sil,sii9022"
+ - reg: i2c address of the bridge
+
+Optional properties:
+ - interrupts-extended or interrupt-parent + interrupts: describe
+ the interrupt line used to inform the host about hotplug events.
+ - reset-gpios: OF device-tree gpio specification for RST_N pin.
+
+Optional subnodes:
+ - video input: this subnode can contain a video input port node
+ to connect the bridge to a display controller output (See this
+ documentation [1]).
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+ hdmi-bridge at 39 {
+ compatible = "sil,sii9022";
+ reg = <0x39>;
+ reset-gpios = <&pioA 1 0>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ bridge_in: endpoint {
+ remote-endpoint = <&dc_out>;
+ };
+ };
+ };
+ };
--
2.7.4
[PATCH v8 1/2] drm/bridge: Add sii902x driver
Add basic support for the sii902x RGB -> HDMI bridge. This driver does not support audio output yet. Signed-off-by: Boris Brezillon Tested-by: Nicolas Ferre --- Changes in v8: - remove useless headers inclusion - fix macro names (s/SIL/SII) - drop unneeded hotplug_work field from struct sii902x - drop drm_connector_unregister() call in the ->destroy() method - add a timeout when polling a register value Changes in v6: - use HDMI_INFOFRAME_SIZE(AVI) - fix reset_gpio initialization - reduce the reset time based on Ming feedback Changes in v5: - drop the best_encoder() implementation Changes in v4: - make reset GPIO optional - only support attaching to DRM devices supporting atomic updates Changes in v3: - fix get_modes() implementation to avoid turning the screen in power save mode - rename the driver (sil902x -> sii902x) Changes in v2: - fix errors reported by the kbuild robot fixup! drm: bridge: Add sii902x driver --- drivers/gpu/drm/bridge/Kconfig | 8 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/sii902x.c | 467 +++ 3 files changed, 476 insertions(+) create mode 100644 drivers/gpu/drm/bridge/sii902x.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 8f7423f..a1419214 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -50,6 +50,14 @@ config DRM_PARADE_PS8622 ---help--- Parade eDP-LVDS bridge chip driver. +config DRM_SII902X + tristate "Silicon Image sii902x RGB/HDMI bridge" + depends on OF + select DRM_KMS_HELPER + select REGMAP_I2C + ---help--- + Silicon Image sii902x bridge chip driver. + source "drivers/gpu/drm/bridge/analogix/Kconfig" endmenu diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index 96b13b3..bfec9f8 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -5,4 +5,5 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o +obj-$(CONFIG_DRM_SII902X) += sii902x.o obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/ diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c new file mode 100644 index 000..9126d03 --- /dev/null +++ b/drivers/gpu/drm/bridge/sii902x.c @@ -0,0 +1,467 @@ +/* + * Copyright (C) 2016 Atmel + * Bo Shen + * + * Authors: Bo Shen + * Boris Brezillon + * Wu, Songjun + * + * + * Copyright (C) 2010-2011 Freescale Semiconductor, Inc. All Rights Reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include +#include +#include +#include + +#include +#include +#include +#include + +#define SII902X_TPI_VIDEO_DATA 0x0 + +#define SII902X_TPI_PIXEL_REPETITION 0x8 +#define SII902X_TPI_AVI_PIXEL_REP_BUS_24BIT BIT(5) +#define SII902X_TPI_AVI_PIXEL_REP_RISING_EDGE BIT(4) +#define SII902X_TPI_AVI_PIXEL_REP_4X 3 +#define SII902X_TPI_AVI_PIXEL_REP_2X 1 +#define SII902X_TPI_AVI_PIXEL_REP_NONE 0 +#define SII902X_TPI_CLK_RATIO_HALF (0 << 6) +#define SII902X_TPI_CLK_RATIO_1X (1 << 6) +#define SII902X_TPI_CLK_RATIO_2X (2 << 6) +#define SII902X_TPI_CLK_RATIO_4X (3 << 6) + +#define SII902X_TPI_AVI_IN_FORMAT 0x9 +#define SII902X_TPI_AVI_INPUT_BITMODE_12BITBIT(7) +#define SII902X_TPI_AVI_INPUT_DITHER BIT(6) +#define SII902X_TPI_AVI_INPUT_RANGE_LIMITED(2 << 2) +#define SII902X_TPI_AVI_INPUT_RANGE_FULL (1 << 2) +#define SII902X_TPI_AVI_INPUT_RANGE_AUTO (0 << 2) +#define SII902X_TPI_AVI_INPUT_COLORSPACE_BLACK (3 << 0) +#define SII902X_TPI_AVI_INPUT_COLORSPACE_YUV422(2 << 0) +#define SII902X_TPI_AVI_INPUT_COLORSPACE_YUV444(1 << 0) +#define SII902X_TPI_AVI_INPUT_COLORSPACE_RGB (0 << 0) + +#define SII902X_TPI_AVI_INFOFRAME 0x0c + +#define SII902X_SYS_CTRL_DATA 0x1a +#define SII902X_SYS_CTRL_PWR_DWN BIT(4) +#define SII902X_SYS_CTRL_AV_MUTE BIT(3) +#define SII902X_SYS_CTRL_DDC_BUS_REQ BIT(2) +#define SII902X_SYS_CTRL_DDC_BUS_GRTD BIT(1) +#define SII902X_SYS_CTRL_OUTPUT_MODE BIT(0) +#define SII902X_SYS_CTRL_OUTPUT_HDMI 1 +#define SII902X_SYS_CTRL_OUTPUT_DVI0 + +#defin
[Bug 119631] RadeonSI get a huge performance dip with used with the nine state tracker
https://bugzilla.kernel.org/show_bug.cgi?id=119631 --- Comment #8 from Michel Dänzer --- Does setting the environment variable thread_submit=true for the EVE-Online process avoid the problem? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 87682] Horizontal lines in radeon driver on kernel 3.15 and upwards
https://bugs.freedesktop.org/show_bug.cgi?id=87682 Thom changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #19 from Thom --- Patch submitted by Christian König https://lists.freedesktop.org/archives/dri-devel/2016-June/110724.html This solved the bug. Thanks everyone for all the help. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160614/deaf09e5/attachment.html>
[PATCH 4/5] drm/amdgpu: Wait for end of last waited-for vblank before programming flip
On Tue, Jun 14, 2016 at 04:25:28PM +0900, Michel Dänzer wrote: > On 14.06.2016 14:53, Daniel Vetter wrote: > > On Tue, Jun 14, 2016 at 11:09:10AM +0900, Michel Dänzer wrote: > >> On 06/13/16 23:06, Daniel Vetter wrote: > >>> On Mon, Jun 13, 2016 at 05:58:29PM +0900, Michel Dänzer wrote: > On 06/13/16 17:06, Daniel Vetter wrote: > > On Mon, Jun 13, 2016 at 10:54:37AM +0900, Michel Dänzer wrote: > >> On 10.06.2016 23:43, Daniel Vetter wrote: > >>> On Fri, Jun 10, 2016 at 05:57:12PM +0900, Michel Dänzer wrote: > From: Michel Dänzer > > If userspace wants a page flip to take effect during vblank sequence > n, > it has to wait for vblank seqno n-1 before calling the > DRM_IOCTL_MODE_PAGE_FLIP ioctl. > > This change makes sure that we do not program the flip to the > hardware > before the end of vblank seqno n-1 in this case, to prevent the flip > from taking effect too early. > > On the other hand, if the DRM_IOCTL_MODE_PAGE_FLIP ioctl is called > during vblank, but userspace didn't wait for the current vblank seqno > before, this change would still allow the flip to be programmed > during > the current vblank seqno. > >>> > >>> This just sounds like you're sending vblank events out a bit too > >>> early. > >>> And watching vblank waits that userspace does works, but it's fragile, > >>> add-hoc and I don't really jump in joy about adding that to the vblank > >>> core. Is there no way you can adjust sending out the vblank events > >>> similarly, to make sure userspace can never sneak in a pageflip too > >>> early? > >> > >> What you call "too early" is actually "during the vertical blank period > >> waited for". IMHO only notifying userspace of a vertical blank period > >> when it's already over would defeat the purpose. > > > > Afaiui the rules are: > > - The timestamp for vblank event needs to agree with whatever oml_sync > > requries. > > - The event delivery itself needs to be consistent with what page_flip > > takes, i.e. if userspace sees an event and immediately issues a > > page_flip then it should not be able to hit the same vblank with that > > pageflip. > > - The event needs to be after the old buffers are not longer used and > > can > > be reused for rendering. > > That's only relevant for DRM_IOCTL_MODE_PAGE_FLIP, not > DRM_IOCTL_WAIT_VBLANK. > >>> > >>> Yup, mixed that up. > >>> > > - There's no requirement at all that the event gets delivered at a > > specific point in the vblank, hardware is too different for that to > > work > > As the name implies, the purpose of DRM_IOCTL_WAIT_VBLANK is to wait for > a vertical blank period. If that doesn't work as intended with some > hardware, that's tough luck but not really my problem. :) > > > - that kind of precision is why we have a separate timestamp. > > I'm afraid this last item gives away that you're relatively new to this > code. ;) The timestamp was originally literally just the current > gettimeofday when the wait finished (the original DRM_IOCTL_WAIT_VBLANK > ioctl didn't have any asynchronous notification functionality). It was > relatively recently that Mario changed the timestamp to correspond to > the end of the vertical blank period / start of scanout of the next > frame, presumably due to your first rule above. > >>> > >>> Most hw just seems to give you a vblank interrupt somewhere in the vblank > >>> are, or sometimes even slightly before that. > >> > >> Our hardware tends to trigger the vblank interrupt early, but it's still > >> useful in that drawing operations submitted after it cannot affect the > >> previously scanned out frame. > >> > >>> Also there's scheduling jitter. > >> > >> Sure, but there's a big difference between "no guarantee that we're > >> still in vblank" vs "guarantee that we're no longer in vblank". > >> > >> > > I assume you're goal is to not delay page_flips unecessarily, without > > breaking requirement 2 here. Imo a simpler fix would be to delay the > > vblank handling to end of vblank. Fixes everything without hacks, [...] > > Except it breaks the original purpose of the wait for vblank > functionality, which is to wait for the beginning of a vertical blank > period. [0] You're focusing too much on page flips and suggesting to > throw out the vblank baby with the bathwater. I really don't see the big > issue which would justify that. > > > [0] As an analogy, how useful would e.g. calendar notifications be if > they arrived at the end of the events they're about? "Hey, that meeting > you were supposed to attend? It just finished!" > >>> > >>> Ok, what exactly is the us
[Bug 96445] [amdgpu][tonga] display freezes soon after X start
https://bugs.freedesktop.org/show_bug.cgi?id=96445 Christian König changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160614/539b244a/attachment.html>
[PATCH 4/5] drm/amdgpu: Wait for end of last waited-for vblank before programming flip
On Tue, Jun 14, 2016 at 07:53:41AM +0200, Daniel Vetter wrote: > On Tue, Jun 14, 2016 at 11:09:10AM +0900, Michel Dänzer wrote: > > E.g.: In cases where page flipping cannot be used, Xorg / the DDX driver > > waits for the target vertical blank period before emitting the drawing > > commands for a buffer swap operation. If the vblank notification only > > arrives when the vertical blank period is already over, this is very > > likely to result in tearing. > > > > Some X compositors and AFAIK even applications such as media players can > > use DRM_IOCTL_WAIT_VBLANK similarly. Obviously it's not intended to be > > used directly like that, but nonetheless it is. > > Is there really anything using it like that outside of -ati? I didn't know > that we pass vblank waits to X clients. No, because EGL doesn't offer an equivalent to OML_sync_control applications like kodi have implemented their own vblank scheduling via DRM_IOCTL_WAIT_VBLANK directly. > Either way annoying, since it > means you need to keep things working like this for amd drivers forever. > Afaik others don't use it like that, at least not on intel. Weston has > some hacks to use vblank waits for plane flips, but that's all disabled > code because it just doesn't work - you need full atomic. Inside Xorg/Present, as Michel said, the vblank notification is used to drive onscreen copies *within* the vblank period (i.e. to try and avoid visible tearing). -Chris -- Chris Wilson, Intel Open Source Technology Centre
Looking for pointers on diagnosing ring test failure in amdgpu
Hi Matthew,
see inline below.
Am 14.06.2016 um 00:03 schrieb Matthew Macy:
> On Mon, 13 Jun 2016 01:35:34 -0700 Christian König at amd.com> wrote
> > Hi Matthew,
> >
> > sounds like the UVD block doesn't want to initialize. No idea off hand
> > why, could be anything. I would need the hardware here for a closer
> > inspection.
> >
> > For a workaround you can try to disable the UVD blokc using the
> > ip_block_mask module parameter (it's a bitmask of enabled blocks e.g.
> > 0x means all blocks enabled, UVD is bit 7 on Carrizo IIRC).
>
>
> When I clear bit 7 I get the following now:
>
> Jun 14 07:58:18 trainwreck kernel: drmn0: fence driver on ring 10 use gpu
> addr 0x40b0, cpu addr 0x0xf800bd4320b0
> Jun 14 07:58:18 trainwreck kernel: drmn0: fence driver on ring 11 use gpu
> addr 0x40c0, cpu addr 0x0xf800bd4320c0
> Jun 14 07:58:19 trainwreck kernel: drmn0: SMU check loaded firmware failed,
> expecting 0x17f, getting 0x0[drm:0x826d4dc4s] *ERROR* amdgpu: smc
> start failed
> Jun 14 07:58:19 trainwreck kernel: [drm:0x8269fc40s] *ERROR* hw_init
> 3 failed -22
> Jun 14 07:58:19 trainwreck kernel: drmn0: amdgpu_init failed
UVD is optional (as long as you don't want to do hardware video
decoding) but the SMU isn't. Alex, Rex any idea what's going wrong here?
> Which is hard to correlate without spending a lot more quality time with the
> driver than I've had time for yet.
Yeah, I don't see why some blocks should fail while others seem to
initialize just fine. Especially since you reported it seems to work on
other hardware.
> One thing that occurs to me is that Linux is usually compiled with gcc6 - has
> amdgpu ever been tested as compiled with clang?
Not as far as I know. We had some problems in the past even with some
gcc versions because of some odd things in the BIOS headers (e.g. zero
sized arrays). But those issues should be fixed by now.
> Below is a list of the warnings I have to disable in order to get amdgpu to
> compile without disabling Werror altogether. The -Wno-format is an artifact
> of clang or FreeBSD treating long long and uint64_t as distinct types and the
> -Wno-pointer-arith is to accept the linux convention of doing pointer
> arithmetic on void pointers. All the others are arguably oversights in the
> code (similar silencing has to be done in i915, but I've had better luck with
> it to date). I haven't fixed the warnings because I try to treat it as vendor
> code and minimize any local changes. Will you accept quasi-cosmetic patches
> from other operating systems / compilers?
Yeah, sure feel free to provide patches. As long as it is only cleanup
and not structural changes it should be trivial to get them merged.
Especially "-Wno-missing-prototypes" and "-Wno-unused-variable" sound
like something which should be trivial to fix.
Regards,
Christian.
>
> Thanks.
>
> -M
>
>
> CWARNFLAGS+=-Wno-pointer-arith
> CWARNFLAGS+=-Wno-pointer-sign ${CWARNFLAGS.${.IMPSRC:T}}
>
> CWARNFLAGS.amdgpu_acpi.c= -Wno-int-conversion -Wno-missing-prototypes
> -Wno-unused-variable
> CWARNFLAGS.amdgpu_amdkfd.c= -Wno-missing-prototypes
> CWARNFLAGS.amdgpu_bo_list.c=-Wno-missing-prototypes
> CWARNFLAGS.amdgpu_cs.c= -Wno-missing-prototypes
> CWARNFLAGS.amdgpu_device.c= -Wno-format -Wno-cast-qual
> CWARNFLAGS.amdgpu_fence.c= -Wno-format
> CWARNFLAGS.amdgpu_gfx.c=-Wno-missing-prototypes
> CWARNFLAGS.amdgpu_amdkfd_gfx_v7.c= -Wno-cast-qual
> CWARNFLAGS.amdgpu_amdkfd_gfx_v8.c= -Wno-cast-qual
> CWARNFLAGS.amdgpu_atpx_handler.c= -Wno-missing-prototypes
> CWARNFLAGS.amdgpu_ih.c= -Wno-cast-qual
> CWARNFLAGS.amdgpu_ioc32.c= -Wno-missing-prototypes
> CWARNFLAGS.amdgpu_object.c= -Wno-format
> CWARNFLAGS.amdgpu_mn.c= -Wno-unused-variable
> CWARNFLAGS.amdgpu_pll.c=-Wno-missing-prototypes
> CWARNFLAGS.amdgpu_pm.c= -Wno-missing-prototypes -Wno-enum-conversion
> CWARNFLAGS.amdgpu_ring.c= -Wno-cast-qual
> CWARNFLAGS.amdgpu_ttm.c=-Wno-missing-prototypes
> CWARNFLAGS.amdgpu_ucode.c=
> -Wno-incompatible-pointer-types-discards-qualifiers -Wno-cast-qual
> CWARNFLAGS.amdgpu_uvd.c=-Wno-format
> CWARNFLAGS.amdgpu_vce.c=-Wno-format
> CWARNFLAGS.amdgpu_vce.c=-Wno-format
> CWARNFLAGS.amdgpu_vm.c= -Wno-format
> CWARNFLAGS.amdgpu_test.c= -Wno-format
> CWARNFLAGS.amdgpu_vm.c= -Wno-format
> CWARNFLAGS.atombios_crtc.c= -Wno-missing-prototypes
> CWARNFLAGS.atombios_dp.c= -Wno-format
> CWARNFLAGS.atombios_i2c.c= -Wno-missing-prototypes
> CWARNFLAGS.ci_dpm.c=-Wno-unused-const-variable
> CWARNFLAGS.cz_smc.c=-Wno-missing-prototypes
> CWARNFLAGS.fiji_smc.c= -Wno-cast-qual
> CWARNFLAGS.gfx_v7_0.c= -Wno-missing-prototypes -Wno-cast-qual
> CWARNFLAGS.gfx_v8_0.c= -Wno-missing-prototypes
> CWARNFLAGS.iceland_smc.c= -Wno-missing-prototypes
> CWARNFLAGS.kv_dpm.c=
[Bug 119631] RadeonSI get a huge performance dip with used with the nine state tracker
https://bugzilla.kernel.org/show_bug.cgi?id=119631 --- Comment #9 from Mathieu Belanger --- No,thread_submit=true just remove more fps. Big drop if I run EVE without DRM_MODE_PAGE_FLIP_ASYNC Small drop if I run EVE with DRM_MODE_PAGE_FLIP_ASYNC -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 76130] Radeon HD 4570 set dpm state fails after suspend
https://bugs.freedesktop.org/show_bug.cgi?id=76130 --- Comment #22 from Thaddaeus Tintenfisch --- I was able to resolve the FPS drop by running the following two commands: echo battery > /sys/class/drm/card0/device/power_dpm_state echo balanced > /sys/class/drm/card0/device/power_dpm_state -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160614/9fe571e2/attachment.html>
[PATCH v3 4/6] drm/panel: simple: Add support for Samsung LSN122DL01-C01 2560x1600 panel
On Mon, Jun 13, 2016 at 10:00:45AM -0700, Doug Anderson wrote:
> Yakir,
>
> On Sat, Jun 11, 2016 at 7:56 PM, Yakir Yang wrote:
> > The Samsung LSN122DL01-C01 is an 12.2" 2560x1600 (WQXGA) TFT-LCD panel
> > connected using eDP interfaces.
> >
> > Signed-off-by: Yakir Yang
> > ---
> > Changes in v3:
> > - Correct the size of panel_desc to active area 262mmx164mm (Emil,
> > Stéphane)
> >
> > Changes in v2: None
> >
> > drivers/gpu/drm/panel/panel-simple.c | 25 +
> > 1 file changed, 25 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > b/drivers/gpu/drm/panel/panel-simple.c
> > index 2d40a21..17cc973 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -1246,6 +1246,28 @@ static const struct panel_desc qd43003c0_40 = {
> > .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
> > };
> >
> > +static const struct drm_display_mode samsung_lsn122dl01_c01_mode = {
> > + .clock = 271560,
> > + .hdisplay = 2560,
> > + .hsync_start = 2560 + 48,
> > + .hsync_end = 2560 + 48 + 32,
> > + .htotal = 2560 + 48 + 32 + 80,
> > + .vdisplay = 1600,
> > + .vsync_start = 1600 + 2,
> > + .vsync_end = 1600 + 2 + 5,
> > + .vtotal = 1600 + 2 + 5 + 57,
> > + .vrefresh = 60,
> > +};
> > +
> > +static const struct panel_desc samsung_lsn122dl01_c01 = {
> > + .modes = &samsung_lsn122dl01_c01_mode,
> > + .num_modes = 1,
> > + .size = {
> > + .width = 262,
> > + .height = 164,
>
> Earlier you said that the active area of this panel was:
>
> > Display area 262.656(H) X 164.16(V) (12.2âdiagonal)
>
> In other panels I looked at the EDID tended to round numbers, not
> truncate them. For instance the Starry panel that I sent the patch
> for says in the manual "262.7712 (H) x 164.232 (V)" but then the EDID
> says "263 x 164".
>
> That would mean your width should be 263 mm, not 262 mm.
Yes, rounding is what I've also applied to all panels that I added.
While it isn't documented I hope that other panels did round, rather
than truncate, as well.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160614/4761a5ca/attachment-0001.sig>
[PATCH 1/3] RFC: drm: Restrict vblank ioctl to master
Somehow this escaped us, this is a KMS ioctl which should only be used
by the master (which is the thing that's also in control of kms
resources). Everything else is bound to result in fail.
Clients shouldn't have a trouble coping with this, since a pile of
drivers don't support vblank waits (or just randomly fall over when
using them). Note that the big motivation for abusing this like mad
seems to be that EGL doesn't have OML_sync, but somehow it didn't
cross anyone's mind that adding OML_sync to EGL would be useful. This
patch is meant to essentially start kicking that can from the back
end.
Cc: fritsch at kodi.tv
Cc: fernetmenta at kodi.tv
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_ioctl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 0510675eec5d..6cc78d648393 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -529,9 +529,9 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_SG_ALLOC, drm_legacy_sg_alloc,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF(DRM_IOCTL_SG_FREE, drm_legacy_sg_free,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
- DRM_IOCTL_DEF(DRM_IOCTL_WAIT_VBLANK, drm_wait_vblank, DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_WAIT_VBLANK, drm_wait_vblank,
DRM_MASTER|DRM_UNLOCKED),
- DRM_IOCTL_DEF(DRM_IOCTL_MODESET_CTL, drm_modeset_ctl, 0),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODESET_CTL, drm_modeset_ctl, DRM_MASTER),
DRM_IOCTL_DEF(DRM_IOCTL_UPDATE_DRAW, drm_noop,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
--
2.8.1
[PATCH 3/3] drm: Mark set/drop master ioctl as unlocked.
Again this is neatly protected by the dev->master_mutex now. There is
a driver callback both for set and drop, but it's only used by vmwgfx.
And vmwgfx has it's own solid locking for shared resources (besides
dev->master_mutex), hence is all safe. Let's drop another place where
the drm legacy bkl is used.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_ioctl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 288b047b2de5..08c75630f1dc 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -487,8 +487,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_SET_SAREA_CTX, drm_legacy_setsareactx,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF(DRM_IOCTL_GET_SAREA_CTX, drm_legacy_getsareactx,
DRM_AUTH),
- DRM_IOCTL_DEF(DRM_IOCTL_SET_MASTER, drm_setmaster_ioctl, DRM_ROOT_ONLY),
- DRM_IOCTL_DEF(DRM_IOCTL_DROP_MASTER, drm_dropmaster_ioctl,
DRM_ROOT_ONLY),
+ DRM_IOCTL_DEF(DRM_IOCTL_SET_MASTER, drm_setmaster_ioctl,
DRM_UNLOCKED|DRM_ROOT_ONLY),
+ DRM_IOCTL_DEF(DRM_IOCTL_DROP_MASTER, drm_dropmaster_ioctl,
DRM_UNLOCKED|DRM_ROOT_ONLY),
DRM_IOCTL_DEF(DRM_IOCTL_ADD_CTX, drm_legacy_addctx,
DRM_AUTH|DRM_ROOT_ONLY),
DRM_IOCTL_DEF(DRM_IOCTL_RM_CTX, drm_legacy_rmctx,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
--
2.8.1
[PATCH 2/3] drm: Mark authmagic ioctls as unlocked
All protected by dev->master_mutex. And there's no driver callbacks,
which means no need to sync with old dri1 horror show drivers at all.
Hence safe to drop the drm legacy BKL from these paths.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_ioctl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 6cc78d648393..288b047b2de5 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -467,7 +467,7 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_VERSION, drm_version,
DRM_UNLOCKED|DRM_RENDER_ALLOW|DRM_CONTROL_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_GET_UNIQUE, drm_getunique, 0),
- DRM_IOCTL_DEF(DRM_IOCTL_GET_MAGIC, drm_getmagic, 0),
+ DRM_IOCTL_DEF(DRM_IOCTL_GET_MAGIC, drm_getmagic, DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_IRQ_BUSID, drm_irq_by_busid,
DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF(DRM_IOCTL_GET_MAP, drm_legacy_getmap_ioctl, DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_GET_CLIENT, drm_getclient, DRM_UNLOCKED),
@@ -479,7 +479,7 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_SET_UNIQUE, drm_invalid_op,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF(DRM_IOCTL_BLOCK, drm_noop,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF(DRM_IOCTL_UNBLOCK, drm_noop,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
- DRM_IOCTL_DEF(DRM_IOCTL_AUTH_MAGIC, drm_authmagic, DRM_AUTH|DRM_MASTER),
+ DRM_IOCTL_DEF(DRM_IOCTL_AUTH_MAGIC, drm_authmagic,
DRM_AUTH|DRM_UNLOCKED|DRM_MASTER),
DRM_IOCTL_DEF(DRM_IOCTL_ADD_MAP, drm_legacy_addmap_ioctl,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF(DRM_IOCTL_RM_MAP, drm_legacy_rmmap_ioctl, DRM_AUTH),
--
2.8.1
[PATCH 1/3] RFC: drm: Restrict vblank ioctl to master
On 14.06.2016 18:03, Daniel Vetter wrote: > Somehow this escaped us, this is a KMS ioctl which should only be used > by the master (which is the thing that's also in control of kms > resources). Everything else is bound to result in fail. > > Clients shouldn't have a trouble coping with this, since a pile of > drivers don't support vblank waits (or just randomly fall over when > using them). Note that the big motivation for abusing this like mad > seems to be that EGL doesn't have OML_sync, but somehow it didn't > cross anyone's mind that adding OML_sync to EGL would be useful. That may be one motivation, but it's certainly not the only one. DRM_IOCTL_WAIT_VBLANK is used by apps which don't use EGL or any similar API at all. Seems like you really want to throw out a baby with the bathwater. :( > - DRM_IOCTL_DEF(DRM_IOCTL_MODESET_CTL, drm_modeset_ctl, 0), > + DRM_IOCTL_DEF(DRM_IOCTL_MODESET_CTL, drm_modeset_ctl, DRM_MASTER), If the DRM_IOCTL_MODESET_CTL change is intended, it should be documented in the commit log. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[PATCH 1/3] RFC: drm: Restrict vblank ioctl to master
On Tue, Jun 14, 2016 at 11:09 AM, Michel Dänzer wrote: > On 14.06.2016 18:03, Daniel Vetter wrote: >> Somehow this escaped us, this is a KMS ioctl which should only be used >> by the master (which is the thing that's also in control of kms >> resources). Everything else is bound to result in fail. >> >> Clients shouldn't have a trouble coping with this, since a pile of >> drivers don't support vblank waits (or just randomly fall over when >> using them). Note that the big motivation for abusing this like mad >> seems to be that EGL doesn't have OML_sync, but somehow it didn't >> cross anyone's mind that adding OML_sync to EGL would be useful. > > That may be one motivation, but it's certainly not the only one. > DRM_IOCTL_WAIT_VBLANK is used by apps which don't use EGL or any similar > API at all. Hm, what else? Quick irc discussion turned up a lot of users of this, but they sem to all have cargo-culted this from the same source, and all because OML_sync doesn't exist on EGL. Kodi for example uses a 2nd hidden window and glx oml_sync as a fallback when the vblank ioctl isn't there. So at least from that pov the reason really seems to be lack of oml_sync on egl, and not anything more fundamental. At least on X, where DRI2/Present already fully support everything you need for oml_sync, and it's just a question of typing the egl variant of that extension and implementing it in mesa. Note that I _only_ mean clients here, anything doing bare kms+egl is of course perfectly fine to use all the kms apis we have directly. > Seems like you really want to throw out a baby with the bathwater. :( This is another baby and bathtub ;-) I didn't realize at all that clients of compositors where doing this. Which is an entirely new can of worms, since they don't really know on which screen they are, when the compositor is going to turn it of or do something else. Note that I only try to restrict it here to DRM_MASTER. And I guess on the master file there's indeed a pile more use-cases besides just timing page_flip. >> - DRM_IOCTL_DEF(DRM_IOCTL_MODESET_CTL, drm_modeset_ctl, 0), >> + DRM_IOCTL_DEF(DRM_IOCTL_MODESET_CTL, drm_modeset_ctl, DRM_MASTER), > > If the DRM_IOCTL_MODESET_CTL change is intended, it should be documented > in the commit log. Yeah that's an accident, I forgot to take out this hunk. MODESET_CTL is an ums-only ioctl, so really doesn't matter what we do with it. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v2 1/2] drm/fsl-dcu: Add HDMI driver for freescale DCU
This patch creates another Encoder for HDMI port, and linking the Encoder
to appropriate DRM bridge. And this Encoder using same CRTC with RGB-LCD.
For RGB-LCD and HDMI using the same hardware connection to DCU, RGB-LCD
panel should be unplugged when using the HDMI connection.
Signed-off-by: Alison Wang
Signed-off-by: Xiubo Li
Signed-off-by: Jianwei Wang
Signed-off-by: Meng Yi
---
Changes in V2:
-remove unused headers inclusion
-remove module declarations
-fix error handling coding style
-drop moulde parameters and auto detect HDMI connection relying on deviece tree
-modified comment lines
---
drivers/gpu/drm/fsl-dcu/Makefile | 1 +
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_hdmi.c | 189 +++
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c| 16 +++
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h | 4 +
4 files changed, 210 insertions(+)
create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_hdmi.c
diff --git a/drivers/gpu/drm/fsl-dcu/Makefile b/drivers/gpu/drm/fsl-dcu/Makefile
index b35a292..12e2245 100644
--- a/drivers/gpu/drm/fsl-dcu/Makefile
+++ b/drivers/gpu/drm/fsl-dcu/Makefile
@@ -1,6 +1,7 @@
fsl-dcu-drm-y := fsl_dcu_drm_drv.o \
fsl_dcu_drm_kms.o \
fsl_dcu_drm_rgb.o \
+fsl_dcu_drm_hdmi.o \
fsl_dcu_drm_plane.o \
fsl_dcu_drm_crtc.o \
fsl_dcu_drm_fbdev.o \
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_hdmi.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_hdmi.c
new file mode 100644
index 000..f567534
--- /dev/null
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_hdmi.c
@@ -0,0 +1,189 @@
+/*
+ * Copyright 2016 NXP Semiconductor, Inc.
+ *
+ * NXP DCU drm device driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+
+#include "fsl_dcu_drm_drv.h"
+#include "fsl_dcu_drm_output.h"
+#include "fsl_tcon.h"
+
+static void
+fsl_dcu_drm_hdmienc_mode_set(struct drm_encoder *encoder,
+struct drm_display_mode *mode,
+struct drm_display_mode *adjusted_mode)
+{
+ /*TODO*/
+}
+
+static int
+fsl_dcu_drm_hdmienc_atomic_check(struct drm_encoder *encoder,
+struct drm_crtc_state *crtc_state,
+struct drm_connector_state *conn_state)
+{
+ return 0;
+}
+
+static void
+fsl_dcu_drm_hdmienc_disable(struct drm_encoder *encoder)
+{
+ struct drm_device *dev = encoder->dev;
+ struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
+
+ if (fsl_dev->tcon)
+ fsl_tcon_bypass_disable(fsl_dev->tcon);
+}
+
+static void
+fsl_dcu_drm_hdmienc_enable(struct drm_encoder *encoder)
+{
+ struct drm_device *dev = encoder->dev;
+ struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
+
+ if (fsl_dev->tcon)
+ fsl_tcon_bypass_enable(fsl_dev->tcon);
+}
+
+static const struct
+drm_encoder_helper_funcs encoder_helper_funcs = {
+ .atomic_check = fsl_dcu_drm_hdmienc_atomic_check,
+ .disable = fsl_dcu_drm_hdmienc_disable,
+ .enable = fsl_dcu_drm_hdmienc_enable,
+ .mode_set = fsl_dcu_drm_hdmienc_mode_set,
+};
+
+static void
+fsl_dcu_drm_hdmienc_destroy(struct drm_encoder *encoder)
+{
+ drm_encoder_cleanup(encoder);
+}
+
+static const struct
+drm_encoder_funcs encoder_funcs = {
+ .destroy = fsl_dcu_drm_hdmienc_destroy,
+};
+
+int fsl_dcu_drm_hdmienc_create(struct fsl_dcu_drm_device *fsl_dev,
+ struct drm_crtc *crtc)
+{
+ struct drm_encoder *encoder;
+ int ret;
+
+ encoder = devm_kzalloc(fsl_dev->dev,
+ sizeof(struct drm_encoder), GFP_KERNEL);
+ if (!encoder)
+ return -ENOMEM;
+
+ encoder->possible_crtcs = 1;
+ ret = drm_encoder_init(fsl_dev->drm, encoder, &encoder_funcs,
+ DRM_MODE_ENCODER_TMDS, NULL);
+ if (ret)
+ goto fail_encoder;
+
+ drm_encoder_helper_add(encoder, &encoder_helper_funcs);
+ encoder->crtc = crtc;
+
+ return 0;
+
+fail_encoder:
+ devm_kfree(fsl_dev->dev, encoder);
+ return ret;
+}
+
+static struct
+drm_encoder *fsl_dcu_drm_hdmi_find_encoder(struct drm_device *dev)
+{
+ struct drm_encoder *encoder;
+
+ list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
+ if (encoder->encoder_type == DRM_MODE_ENCODER_TMDS)
+ return encoder;
+ }
+
+ return NULL;
+}
+
+static struct
+device_node *detect_hdmi_connection(struct fsl_dcu_drm_device *fsl_dev)
+{
+ struct device_node *remote_port;
+ struct of_endpoint *ep;
+ struct device_node *ep_node;
[PATCH 2/2 v16] drm/bridge: Add I2C based driver for ps8640 bridge
Hi Jitao,
On Thu, Jun 2, 2016 at 5:57 PM, Jitao Shi wrote:
>
> This patch adds drm_bridge driver for parade DSI to eDP bridge chip.
>
> Signed-off-by: Jitao Shi
> Reviewed-by: Daniel Kurtz
> ---
> Changes since v15:
> - Drop drm_connector_(un)register calls from parade ps8640.
>The main DRM driver mtk_drm_drv now calls
>drm_connector_register_all() after drm_dev_register() in the
>mtk_drm_bind() function. That function should iterate over all
>connectors and call drm_connector_register() for each of them.
>So, remove drm_connector_(un)register calls from parade ps8640.
[snip...]
> +static void ps8640_pre_enable(struct drm_bridge *bridge)
> +{
> + struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> + struct i2c_client *client = ps_bridge->page[2];
> + int err;
> + u8 set_vdo_done;
> + ktime_t timeout;
> +
> + if (ps_bridge->in_fw_update)
> + return;
> +
> + if (ps_bridge->enabled)
> + return;
> +
> + err = drm_panel_prepare(ps_bridge->panel);
> + if (err < 0) {
> + DRM_ERROR("failed to prepare panel: %d\n", err);
> + return;
> + }
> +
(1) For patch v10, Philipp Zabel commented that gpio_slp_n &
gpio_rst_n are both active low, and that the device tree should
contain a reset-gpios property with the GPIO_ACTIVE_LOW flag set.
(2) However, you did change the the reset logic from v10 -> v11, but
it isn't clear why (nor mentioned in the patch notes).
v10 (https://patchwork.kernel.org/patch/8357851/) had:
+ gpiod_set_value(ps_bridge->gpio_slp_n, 1);
+ gpiod_set_value(ps_bridge->gpio_rst_n, 0);
+
+ err = regulator_bulk_enable(ARRAY_SIZE(ps_bridge->supplies),
+ps_bridge->supplies);
+ if (err < 0) {
+ DRM_ERROR("cannot enable regulators %d\n", err);
+ goto err_panel_unprepare;
+ }
+
+ usleep_range(500, 700);
+ gpiod_set_value(ps_bridge->gpio_rst_n, 1);
In other words:
(a) de-assert power down
(b) assert reset
(c) enable 1.2 & 3.3 regulators
(d) (aka regulator-ramp-delay in device-tree)
(e) wait an additional 2 ms (as requested by Parade for ps8640 to stabilize?)
(f) de-assert reset
(g) wait 200 ms (for ps8640 FW to load?)
This mostly made sense to me, except for step (a)... I'm not sure why
you de-assert power down before enabling the regulators. It seems
like you'd want to do that later, maybe after reset (can you ask
Paradetech?).
Now (as of v11) it has changed to:
> + err = regulator_bulk_enable(ARRAY_SIZE(ps_bridge->supplies),
> + ps_bridge->supplies);
> + if (err < 0) {
> + DRM_ERROR("cannot enable regulators %d\n", err);
> + goto err_panel_unprepare;
> + }
> +
> + gpiod_set_value(ps_bridge->gpio_slp_n, 1);
> + gpiod_set_value(ps_bridge->gpio_rst_n, 0);
> + usleep_range(2000, 2500);
> + gpiod_set_value(ps_bridge->gpio_rst_n, 1);
Two additional comments:
(3) if you correctly configure these gpios as GPIO_ACTIVE_LOW, you can
drop the "_n" suffix, which will make the driver code easier to
understand.
(4) "gpio_slp_n" is called "PD#" by the PS8640 datasheet, so a better
name might be: "gpio_power_down".
Thanks,
-Dan
[PATCH v2 1/2] drm/fsl-dcu: Add HDMI driver for freescale DCU
On Tuesday 14 June 2016 17:20:36, Meng Yi wrote:
> This patch creates another Encoder for HDMI port, and linking the Encoder
> to appropriate DRM bridge. And this Encoder using same CRTC with RGB-LCD.
> For RGB-LCD and HDMI using the same hardware connection to DCU, RGB-LCD
> panel should be unplugged when using the HDMI connection.
>
> Signed-off-by: Alison Wang
> Signed-off-by: Xiubo Li
> Signed-off-by: Jianwei Wang
> Signed-off-by: Meng Yi
> ---
> Changes in V2:
> -remove unused headers inclusion
> -remove module declarations
> -fix error handling coding style
> -drop moulde parameters and auto detect HDMI connection relying on deviece
> tree -modified comment lines
> ---
> drivers/gpu/drm/fsl-dcu/Makefile | 1 +
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_hdmi.c | 189
> +++ drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c|
> 16 +++
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h | 4 +
> 4 files changed, 210 insertions(+)
> create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_hdmi.c
> [...]
> +static struct
> +device_node *detect_hdmi_connection(struct fsl_dcu_drm_device *fsl_dev)
> +{
> + struct device_node *remote_port;
> + struct of_endpoint *ep;
> + struct device_node *ep_node;
> + int ret;
> + struct device_node *parent = fsl_dev->dev->of_node;
> +
> + ep = devm_kzalloc(fsl_dev->dev,
> + sizeof(struct of_endpoint), GFP_KERNEL);
> + if (!ep)
> + return NULL;
> +
> + ep_node = devm_kzalloc(fsl_dev->dev,
> + sizeof(struct device_node), GFP_KERNEL);
> + if (!ep_node)
> + return NULL;
> +
> + ep_node = of_graph_get_next_endpoint(parent, NULL);
^^^
You overwrite the pointer to previously allocated memory.
> + if (!ep_node)
> + goto error;
> +
> + ret = of_graph_parse_endpoint(ep_node, ep);
> + if (ret) {
> + of_node_put(ep_node);
> + goto error;
> + }
> +
> + remote_port = of_graph_get_remote_port_parent(ep->local_node);
> + if (!remote_port)
> + goto error;
> +
> + return remote_port;
> +error:
> + devm_kfree(ep);
> + devm_kfree(ep_node);
> + return NULL;
> +}
So, unless you hit the error label the memory allocated using devm_kzalloc
stays around until the device is removed. I don't know DRM internals much, but
can load (within drm_driver) be called multiple times during device lifetime?
This would allocate memory each time it is called. Why not allocate 'ep' on
stack while ep_node don't need allocation at all, no?
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c index c564ec6..658bc92 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c
> @@ -17,10 +17,18 @@
> #include "fsl_dcu_drm_crtc.h"
> #include "fsl_dcu_drm_drv.h"
>
> +static void fsl_dcu_drm_output_poll_changed(struct drm_device *dev)
> +{
> + struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
> +
> + drm_fbdev_cma_hotplug_event(fsl_dev->fbdev);
> +}
> +
> static const struct drm_mode_config_funcs fsl_dcu_drm_mode_config_funcs = {
> .atomic_check = drm_atomic_helper_check,
> .atomic_commit = drm_atomic_helper_commit,
> .fb_create = drm_fb_cma_create,
> + .output_poll_changed = fsl_dcu_drm_output_poll_changed,
> };
>
> int fsl_dcu_drm_modeset_init(struct fsl_dcu_drm_device *fsl_dev)
> @@ -47,6 +55,14 @@ int fsl_dcu_drm_modeset_init(struct fsl_dcu_drm_device
> *fsl_dev) if (ret)
> goto fail_connector;
>
> + ret = fsl_dcu_drm_hdmienc_create(fsl_dev, &fsl_dev->crtc);
> + if (ret)
> + DRM_ERROR("Failed to create HDMI encoder\n");
> +
> + ret = fsl_dcu_drm_hdmienc_attach_bridge(fsl_dev);
> + if (ret)
> + DRM_ERROR("Failed to attach HDMI bridge\n");
> +
Are those really errors? What about setups without any HDMI bridge at all? I
would conside it an error if a bridge is given in device-tree but detecting or
whatsoever fails for some reason.
Best regards,
Alexander
[PATCH] virtio-gpu: use src not crtc
Hi
On Tue, May 31, 2016 at 2:52 PM, Gerd Hoffmann wrote:
> Pick up the correct source rectangle from framebuffer.
> Without this multihead setups are not working correctly.
>
> Signed-off-by: Gerd Hoffmann
Reviewed-by: Marc-André Lureau
Additionally, I had to modify the page_flip() function to take the
plane source coordinates for virgl/3d multihead to work. Feel free to
squash.
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -68,11 +68,16 @@ static int virtio_gpu_page_flip(struct drm_crtc *crtc,
0, 0, NULL);
}
virtio_gpu_cmd_set_scanout(vgdev, output->index, handle,
- crtc->mode.hdisplay,
- crtc->mode.vdisplay, 0, 0);
- virtio_gpu_cmd_resource_flush(vgdev, handle, 0, 0,
- crtc->mode.hdisplay,
- crtc->mode.vdisplay);
+ plane->state->src_w >> 16,
+ plane->state->src_h >> 16,
+ plane->state->src_x >> 16,
+ plane->state->src_y >> 16);
+
+ virtio_gpu_cmd_resource_flush(vgdev, handle,
+ plane->state->src_x >> 16,
+ plane->state->src_y >> 16,
+ plane->state->src_w >> 16,
+ plane->state->src_h);
> ---
> drivers/gpu/drm/virtio/virtgpu_plane.c | 31 ++-
> 1 file changed, 18 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
> b/drivers/gpu/drm/virtio/virtgpu_plane.c
> index b7778a7..925ca25 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_plane.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
> @@ -85,27 +85,32 @@ static void virtio_gpu_primary_plane_update(struct
> drm_plane *plane,
> if (bo->dumb) {
> virtio_gpu_cmd_transfer_to_host_2d
> (vgdev, handle, 0,
> -cpu_to_le32(plane->state->crtc_w),
> -cpu_to_le32(plane->state->crtc_h),
> -plane->state->crtc_x, plane->state->crtc_y,
> NULL);
> +cpu_to_le32(plane->state->src_w >> 16),
> +cpu_to_le32(plane->state->src_h >> 16),
> +plane->state->src_x >> 16,
> +plane->state->src_y >> 16, NULL);
> }
> } else {
> handle = 0;
> }
>
> - DRM_DEBUG("handle 0x%x, crtc %dx%d+%d+%d\n", handle,
> + DRM_DEBUG("handle 0x%x, crtc %dx%d+%d+%d, src %dx%d+%d+%d\n", handle,
> plane->state->crtc_w, plane->state->crtc_h,
> - plane->state->crtc_x, plane->state->crtc_y);
> + plane->state->crtc_x, plane->state->crtc_y,
> + plane->state->src_w >> 16,
> + plane->state->src_h >> 16,
> + plane->state->src_x >> 16,
> + plane->state->src_y >> 16);
> virtio_gpu_cmd_set_scanout(vgdev, output->index, handle,
> - plane->state->crtc_w,
> - plane->state->crtc_h,
> - plane->state->crtc_x,
> - plane->state->crtc_y);
> + plane->state->src_w >> 16,
> + plane->state->src_h >> 16,
> + plane->state->src_x >> 16,
> + plane->state->src_y >> 16);
> virtio_gpu_cmd_resource_flush(vgdev, handle,
> - plane->state->crtc_x,
> - plane->state->crtc_y,
> - plane->state->crtc_w,
> - plane->state->crtc_h);
> + plane->state->src_x >> 16,
> + plane->state->src_y >> 16,
> + plane->state->src_w >> 16,
> + plane->state->src_h >> 16);
> }
>
> static void virtio_gpu_cursor_plane_update(struct drm_plane *plane,
> --
> 1.8.3.1
>
--
Marc-André Lureau
[PATCH 2/2] drm/edid: Add 6 bpc quirk for display AEO model 0.
On Thu, May 26, 2016 at 04:39:04PM +0200, Mario Kleiner wrote:
> Bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=105331
> reports that the "AEO model 0" display is driven with 8 bpc
> without dithering by default, which looks bad because that
> panel is apparently a 6 bpc DP panel with faulty EDID.
>
> A fix for this was made by commit 013dd9e03872
> ("drm/i915/dp: fall back to 18 bpp when sink capability is unknown").
>
> That commit triggers new regressions in precision for DP->DVI and
> DP->VGA displays. A patch is out to revert that commit, but it will
> revert video output for the AEO model 0 panel to 8 bpc without
> dithering.
>
> The EDID 1.3 of that panel, as decoded from the xrandr output
> attached to that bugzilla bug report, is somewhat faulty, and beyond
> other problems also sets the "DFP 1.x compliant TMDS" bit, which
> according to DFP spec means to drive the panel with 8 bpc and
> no dithering in absence of other colorimetry information.
>
> Try to make the original bug reporter happy despite the
> faulty EDID by adding a quirk to mark that panel as 6 bpc,
> so 6 bpc output with dithering creates a nice picture.
>
> Tested by injecting the edid from the fdo bug into a DP connector
> via drm_kms_helper.edid_firmware and verifying the 6 bpc + dithering
> is selected.
>
> This patch should be backported to stable.
>
> Signed-off-by: Mario Kleiner
> Cc: stable at vger.kernel.org
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
Now I'm confused. I thought we didn't need any quirks?
> ---
> drivers/gpu/drm/drm_edid.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 7df26d4..2cb472b 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -74,6 +74,8 @@
> #define EDID_QUIRK_FORCE_8BPC(1 << 8)
> /* Force 12bpc */
> #define EDID_QUIRK_FORCE_12BPC (1 << 9)
> +/* Force 6bpc */
> +#define EDID_QUIRK_FORCE_6BPC(1 << 10)
>
> struct detailed_mode_closure {
> struct drm_connector *connector;
> @@ -100,6 +102,9 @@ static struct edid_quirk {
> /* Unknown Acer */
> { "ACR", 2423, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
>
> + /* AEO model 0 reports 8 bpc, but is a 6 bpc panel */
> + { "AEO", 0, EDID_QUIRK_FORCE_6BPC },
> +
> /* Belinea 10 15 55 */
> { "MAX", 1516, EDID_QUIRK_PREFER_LARGE_60 },
> { "MAX", 0x77e, EDID_QUIRK_PREFER_LARGE_60 },
> @@ -4082,6 +4087,9 @@ int drm_add_edid_modes(struct drm_connector *connector,
> struct edid *edid)
>
> drm_add_display_info(edid, &connector->display_info, connector);
>
> + if (quirks & EDID_QUIRK_FORCE_6BPC)
> + connector->display_info.bpc = 6;
> +
> if (quirks & EDID_QUIRK_FORCE_8BPC)
> connector->display_info.bpc = 8;
>
> --
> 2.7.0
--
Ville Syrjälä
Intel OTC
[PATCH 1/2] drm/i915/dp: Revert "drm/i915/dp: fall back to 18 bpp when sink capability is unknown"
On Thu, May 26, 2016 at 4:39 PM, Mario Kleiner
wrote:
> This reverts commit 013dd9e03872
> ("drm/i915/dp: fall back to 18 bpp when sink capability is unknown")
>
> This commit introduced a regression into stable kernels,
> as it reduces output color depth to 6 bpc for any video
> sink connected to a Displayport connector if that sink
> doesn't report a specific color depth via EDID, or if
> our EDID parser doesn't actually recognize the proper
> bpc from EDID.
>
> Affected are active DisplayPort->VGA converters and
> active DisplayPort->DVI converters. Both should be
> able to handle 8 bpc, but are degraded to 6 bpc with
> this patch.
>
> The reverted commit was meant to fix
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105331
>
> A followup patch implements a fix for that specific bug,
> which is caused by a faulty EDID of the affected DP panel
> by adding a new EDID quirk for that panel.
>
> DP 18 bpp fallback handling and other improvements to
> DP sink bpc detection will be handled for future
> kernels in a separate series of patches.
>
> Please backport to stable.
>
> Signed-off-by: Mario Kleiner
> Acked-by: Jani Nikula
> Cc: stable at vger.kernel.org
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
I wonder whether we shouldn't just move this into the DP code, and
instead of looking at the edid (which is just pass-through for dp->vga
dongles) we should only look at dpcd values? Or maybe only look at the
edid value if the sink is native DP, and not when it's a dongle.
That would probably also avoid the quirk, and that quirk seems a bit fishy.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v4 2/2] drm/panel: Add JDI LT070ME05000 WUXGA DSI Panel
On Tue, Jun 14, 2016 at 04:27:53PM +0530, Vinay Simha wrote:
[...]
> On Mon, Jun 13, 2016 at 6:05 PM, Thierry Reding
> wrote:
> > On Mon, Jun 13, 2016 at 03:55:28PM +0530, Vinay Simha BN wrote:
[...]
> >> +const char *regs[] = {
> >> + "vddp",
> >> + "dcdc_en",
> >> + "vcc"
> >> +};
> >
> > This should be static. Also use a more sensible name, such as
> > regulator_names, please.
> it kept as regs, to keep constant names as used in
> the dsi_cfg file
> drivers/gpu/drm/msm/dsi/dsi_cfg.c
That's a completely different driver, no need to be consistent.
> >> +static int jdi_panel_init(struct jdi_panel *jdi)
> >> +{
> > [...]
> >> + struct mipi_dsi_device *dsi = jdi->dsi;
> >> + int ret;
> >> +
> >> + dsi->mode_flags |= MIPI_DSI_MODE_LPM;
> >> +
> >> + ret = mipi_dsi_dcs_soft_reset(dsi);
> >> + if (ret < 0)
> >> + return ret;
> >> +
> >> + usleep_range(1, 2);
> >> +
> >> + ret = mipi_dsi_dcs_set_pixel_format(dsi, 0x70);
> >> + if (ret < 0)
> >> + return ret;
> >
> > Please use the existing symbolic constants for this.
> i am not clear on the symbolic constants for pixel_format ?
See include/video/mipi_display.h
> >> +
> >> + ret = mipi_dsi_dcs_write(dsi, MIPI_DCS_WRITE_CONTROL_DISPLAY,
> >> + (u8[]){ 0x24 }, 1);
> >> + if (ret < 0)
> >> + return ret;
> brightness control setting, to enable pwm/backlight
> >> +
> >> + ret = mipi_dsi_dcs_write(dsi, MIPI_DCS_WRITE_POWER_SAVE,
> >> + (u8[]){ 0x00 }, 1);
> >> + if (ret < 0)
> >> + return ret;
> >
> this is to set cabc off/on
Can you point me to the specification of these? I'd like to investigate
whether or not we can turn these into more sensible commands. As-is, it
is completely obfuscated and I'd like to avoid that where possible.
> >> + ret = mipi_dsi_generic_write(dsi, (u8[]){0xB0, 0x00}, 2);
> >> + if (ret < 0)
> >> + return ret;
> >> + mdelay(10);
> >
> > Same here. This also needs at least a comment, though ideally you'd use
> > symbolic names for those magic numbers.
> i do not have the datasheet to give more description.
> this is for interface setting, either command mode/video mode
Okay, please add a comment on what this is supposed to do, then.
> >> +
> >> + jdi->mode = &default_mode;
> >> +
> >> + for (i = 0; i < num; i++)
> >> + s[i].supply = regs[i];
> >> +
> >> + ret = devm_regulator_bulk_get(dev, num, s);
> >> + if (ret < 0) {
> >> + dev_err(dev, "%s: failed to init regulator, ret=%d\n",
> >> + __func__, ret);
> >> + return ret;
> >> + }
> >> +
> >> + jdi->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
> >> + if (IS_ERR(jdi->reset_gpio)) {
> >> + dev_err(dev, "cannot get reset-gpios %ld\n",
> >> + PTR_ERR(jdi->reset_gpio));
> >
> > This is a third variant of error reporting. Please stick to one.
> for PTR_ERR(jdi->reset_gpio) returns unsigned long, so this error reporting
> cannot be changed to ret,
> others error reporting incorporated consistently.
PTR_ERR() returns signed long, not unsigned.
You can still use the same format for the message and substitute the
%ld printk specifier to match the type.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160614/ed1d7e6d/attachment.sig>
[PATCH v3 0/10]
RK3399 and RK3288 shared the same eDP IP controller, only some light difference with VOP configure and GRF configure. Also same misc fix to analogix_dp driver: - Hotplug invalid which report by Dan Carpenter - Make panel detect to an optional action - correct the register bit define error in ANALOGIX_DP_PLL_REG_1 Changes in v3: - Correct the misspell of "marcos" in commit message (Dominik, reviewed at Google Gerrit) [https://chromium-review.googlesource.com/#/c/346312/9//COMMIT_MSG at 9] - Add reviewed flag from Stéphane. [https://chromium-review.googlesource.com/#/c/346312/16] - Add tested flag from Javier. - Write a kerneldoc-style comment explaining the chips data fields (Tomasz, reviewed at Google Gerrit) [https://chromium-review.googlesource.com/#/c/346313/10/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c at 39] - Drop the '.lcdcsel_mask' number in chips data field (Tomasz, reviewed at Google Gerrit) [https://chromium-review.googlesource.com/#/c/346313/10/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c at 382] - Add acked flag from Mark. - Add reviewed flag from Tomasz. [https://chromium-review.googlesource.com/#/c/346315/15] - Add tested flag from Javier - Make this hack code more clear (Tomasz, reviewed at Google Gerrit) reg = ~reg & REF_CLK_MASK; ---> reg ^= REF_CLK_MASK; [https://chromium-review.googlesource.com/#/c/346852/7/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c at 80] - Add tested flag from Javier - Give the "rk3399-edp" a separate line for clarity in document (Tomasz, reviewed at Google Gerrit) [https://chromium-review.googlesource.com/#/c/346314/10/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt at 5] - Move 'output_type' setting before the return statement (Tomasz, reviewed at Google Gerrit) [https://chromium-review.googlesource.com/#/c/346314/10/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c at 154] - Add the acked flag from Mark. - Add the acked flag from Mark. - Avoid to change any internal driver state in .mode_valid interface. (Tomasz, reviewed at Google Gerrit) [https://chromium-review.googlesource.com/#/c/346318/10/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c at 113] - Hook the connector's color_formats in .get_modes directly. (Tomasz, reviewed at Google Gerrit) [https://chromium-review.googlesource.com/#/c/346317/15] - Add the acked flag from Mark. - Add the reviewed flag from Tomasz. [https://chromium-review.googlesource.com/#/c/346853/12] - Add the acked flag from Mark. - Add reviewed flag from Stéphane. [https://chromium-review.googlesource.com/#/c/346319/15] - Add tested flag from Javier Changes in v2: - new patch in v2 - rebase with drm-next, fix some conflicts - new patch in v2 Yakir Yang (10): drm/bridge: analogix_dp: rename RK3288_DP to ROCKCHIP_DP drm/rockchip: analogix_dp: split the lcdc select setting into device data drm/bridge: analogix_dp: correct the register bit define error in ANALOGIX_DP_PLL_REG_1 drm/bridge: analogix_dp: some rockchip chips need to flip REF_CLK bit setting drm/rockchip: analogix_dp: add rk3399 eDP support drm/rockchip: analogix_dp: make panel detect to an optional action drm/bridge: analogix_dp: passing the connector as an argument in .get_modes() drm/rockchip: analogix_dp: correct the connector display color format and bpc drm/rockchip: analogix_dp: update the comments about why need to hardcode VOP output mode drm/bridge: analogix_dp: fix no drm hpd event when panel plug in .../bindings/display/bridge/analogix_dp.txt| 1 + .../display/rockchip/analogix_dp-rockchip.txt | 3 +- drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 6 +- drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 8 +- drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 12 +- drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h | 5 +- drivers/gpu/drm/exynos/exynos_dp.c | 4 +- drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 158 ++--- include/drm/bridge/analogix_dp.h | 9 +- 9 files changed, 141 insertions(+), 65 deletions(-) -- 1.9.1
[PATCH 1/5] drm/tilcdc: Restore old dmps state in pm_resume()
Restore old dpms state in pm_resume(). The dpms is turned off in
pm_suspend() and it should be restored to its original state in
pm_resume().
Fixes commit 614b3cfeb8d2 ("drm/tilcdc: disable the lcd controller/dma
engine when suspend invoked")
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 7 +++
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 3 +++
drivers/gpu/drm/tilcdc/tilcdc_drv.h | 2 ++
3 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 79027b1..4d8f9a5 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -246,6 +246,13 @@ void tilcdc_crtc_dpms(struct drm_crtc *crtc, int mode)
}
}
+int tilcdc_crtc_current_dpms_state(struct drm_crtc *crtc)
+{
+ struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
+
+ return tilcdc_crtc->dpms;
+}
+
static bool tilcdc_crtc_mode_fixup(struct drm_crtc *crtc,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 308e197..148b1ed 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -598,6 +598,7 @@ static int tilcdc_pm_suspend(struct device *dev)
}
/* Disable the LCDC controller, to avoid locking up the PRCM */
+ priv->saved_dpms_state = tilcdc_crtc_current_dpms_state(priv->crtc);
tilcdc_crtc_dpms(priv->crtc, DRM_MODE_DPMS_OFF);
/* Save register state: */
@@ -628,6 +629,8 @@ static int tilcdc_pm_resume(struct device *dev)
priv->saved_register[n++]);
}
+ tilcdc_crtc_dpms(priv->crtc, priv->saved_dpms_state);
+
drm_kms_helper_poll_enable(ddev);
return 0;
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
index c1de18b..3b52ce8 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
@@ -67,6 +67,7 @@ struct tilcdc_drm_private {
/* register contents saved across suspend/resume: */
u32 *saved_register;
+ int saved_dpms_state;
bool ctx_valid;
#ifdef CONFIG_CPU_FREQ
@@ -172,5 +173,6 @@ void tilcdc_crtc_set_simulate_vesa_sync(struct drm_crtc
*crtc,
int tilcdc_crtc_mode_valid(struct drm_crtc *crtc, struct drm_display_mode
*mode);
int tilcdc_crtc_max_width(struct drm_crtc *crtc);
void tilcdc_crtc_dpms(struct drm_crtc *crtc, int mode);
+int tilcdc_crtc_current_dpms_state(struct drm_crtc *crtc);
#endif /* __TILCDC_DRV_H__ */
--
1.9.1
[PATCH 4/5] drm/tilcdc: Refer to panel.txt and tfp410.txt bindings in tilcdc.txt
The legacy panel.txt and tfp410.txt bindings are still the only supported
way to connect lcd panel and tfp410 DVI encoder to tilcdc.
Signed-off-by: Jyri Sarha
---
Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
index 2136ee8..6efa4c5 100644
--- a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
+++ b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
@@ -24,6 +24,10 @@ Optional nodes:
binding follows Documentation/devicetree/bindings/graph.txt and
suppors a single port with a single endpoint.
+ - See also Documentation/devicetree/bindings/display/tilcdc/panel.txt and
+ Documentation/devicetree/bindings/display/tilcdc/tfp410.txt for connecting
+ tfp410 DVI encoder or lcd panel to lcdc
+
Example:
fb: fb at 4830e000 {
--
1.9.1
[PATCH 0/5] drm/tilcdc Fixes and cleanups
Some fixes and cleanups that should get merged to tilcdc even if my atomic changes are still a work in progress. Jyri Sarha (5): drm/tilcdc: Restore old dmps state in pm_resume() drm/tilcdc: Write to LCDC_END_OF_INT_IND_REG at the end of IRQ function drm/tilcdc: Move waiting of LCDC_FRAME_DONE IRQ into stop() drm/tilcdc: Refer to panel.txt and tfp410.txt bindings in tilcdc.txt drm/tilcdc: Avoid error print by of_graph_get_next_endpoint() .../devicetree/bindings/display/tilcdc/tilcdc.txt | 4 ++ drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 62 +- drivers/gpu/drm/tilcdc/tilcdc_drv.c| 3 ++ drivers/gpu/drm/tilcdc/tilcdc_drv.h| 2 + drivers/gpu/drm/tilcdc/tilcdc_external.c | 11 5 files changed, 58 insertions(+), 24 deletions(-) -- 1.9.1
[PATCH 2/5] drm/tilcdc: Write to LCDC_END_OF_INT_IND_REG at the end of IRQ function
Reorder the IRQ function so that the write to LCDC_END_OF_INT_IND_REG
is done last. The write to LCDC_END_OF_INT_IND_REG indicates to LCDC
that the interrupt service routine has completed (see section
13.3.6.1.6 in AM335x TRM). This is needed if LCDC's ipgvmodirq module
is configured for pulse interrupts.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 4d8f9a5..1343717 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -725,14 +725,19 @@ irqreturn_t tilcdc_crtc_irq(struct drm_crtc *crtc)
tilcdc_crtc->frame_intact = true;
}
- if (priv->rev == 2) {
- if (stat & LCDC_FRAME_DONE) {
- tilcdc_crtc->frame_done = true;
- wake_up(&tilcdc_crtc->frame_done_wq);
- }
- tilcdc_write(dev, LCDC_END_OF_INT_IND_REG, 0);
+ if (priv->rev == 1)
+ return IRQ_HANDLED;
+ /* The rest is for revision 2 only */
+
+ if (stat & LCDC_FRAME_DONE) {
+ tilcdc_crtc->frame_done = true;
+ wake_up(&tilcdc_crtc->frame_done_wq);
}
+ if (stat & LCDC_FIFO_UNDERFLOW)
+ dev_err_ratelimited(dev->dev, "%s(0x%08x): FIFO underfow",
+ __func__, stat);
+
if (stat & LCDC_SYNC_LOST) {
dev_err_ratelimited(dev->dev, "%s(0x%08x): Sync lost",
__func__, stat);
@@ -746,9 +751,10 @@ irqreturn_t tilcdc_crtc_irq(struct drm_crtc *crtc)
}
}
- if (stat & LCDC_FIFO_UNDERFLOW)
- dev_err_ratelimited(dev->dev, "%s(0x%08x): FIFO underfow",
- __func__, stat);
+ /* Indicate to LCDC that the interrupt service routine has
+* completed, see 13.3.6.1.6 in AM335x TRM.
+*/
+ tilcdc_write(dev, LCDC_END_OF_INT_IND_REG, 0);
return IRQ_HANDLED;
}
--
1.9.1
[PATCH 3/5] drm/tilcdc: Move waiting of LCDC_FRAME_DONE IRQ into stop()
Move wait queue waiting of LCDC_FRAME_DONE IRQ from tilcdc_crtc_dpms()
into stop() function.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 31 ---
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 1343717..cfa1a4e 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -113,9 +113,25 @@ static void start(struct drm_crtc *crtc)
static void stop(struct drm_crtc *crtc)
{
+ struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
struct drm_device *dev = crtc->dev;
+ struct tilcdc_drm_private *priv = dev->dev_private;
+ tilcdc_crtc->frame_done = false;
tilcdc_clear(dev, LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
+
+ /*
+* if necessary wait for framedone irq which will still come
+* before putting things to sleep..
+*/
+ if (priv->rev == 2) {
+ int ret = wait_event_timeout(tilcdc_crtc->frame_done_wq,
+tilcdc_crtc->frame_done,
+msecs_to_jiffies(50));
+ if (ret == 0)
+ dev_err(dev->dev, "%s: timeout waiting for framedone\n",
+ __func__);
+ }
}
static void tilcdc_crtc_destroy(struct drm_crtc *crtc)
@@ -212,22 +228,7 @@ void tilcdc_crtc_dpms(struct drm_crtc *crtc, int mode)
pm_runtime_get_sync(dev->dev);
start(crtc);
} else {
- tilcdc_crtc->frame_done = false;
stop(crtc);
-
- /*
-* if necessary wait for framedone irq which will still come
-* before putting things to sleep..
-*/
- if (priv->rev == 2) {
- int ret = wait_event_timeout(
- tilcdc_crtc->frame_done_wq,
- tilcdc_crtc->frame_done,
- msecs_to_jiffies(50));
- if (ret == 0)
- dev_err(dev->dev, "timeout waiting for
framedone\n");
- }
-
pm_runtime_put_sync(dev->dev);
if (tilcdc_crtc->next_fb) {
--
1.9.1
[PATCH 5/5] drm/tilcdc: Avoid error print by of_graph_get_next_endpoint()
Avoid error print by of_graph_get_next_endpoint() if there is no ports
present.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_external.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c
b/drivers/gpu/drm/tilcdc/tilcdc_external.c
index 03acb4f..51811e3 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_external.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_external.c
@@ -138,9 +138,20 @@ static int dev_match_of(struct device *dev, void *data)
int tilcdc_get_external_components(struct device *dev,
struct component_match **match)
{
+ struct device_node *node;
struct device_node *ep = NULL;
int count = 0;
+ /* Avoid error print by of_graph_get_next_endpoint() if there
+* is no ports present.
+*/
+ node = of_get_child_by_name(dev->of_node, "ports");
+ if (!node)
+ node = of_get_child_by_name(dev->of_node, "port");
+ if (!node)
+ return 0;
+ of_node_put(node);
+
while ((ep = of_graph_get_next_endpoint(dev->of_node, ep))) {
struct device_node *node;
--
1.9.1
[PATCH v3 02/10] drm/rockchip: analogix_dp: split the lcdc select setting into device data
eDP controller need to declare which vop provide the video source,
and it's defined in GRF registers.
But different chips have different GRF register address, so we need to
create a device data to declare the GRF messages for each chips.
Signed-off-by: Yakir Yang
Acked-by: Mark Yao
---
Changes in v3:
- Write a kerneldoc-style comment explaining the chips data fields (Tomasz,
reviewed at Google Gerrit)
[https://chromium-review.googlesource.com/#/c/346313/10/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
at 39]
- Drop the '.lcdcsel_mask' number in chips data field (Tomasz, reviewed at
Google Gerrit)
[https://chromium-review.googlesource.com/#/c/346313/10/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
at 382]
- Add acked flag from Mark.
Changes in v2: None
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 39 +++--
1 file changed, 30 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 2bc8a7e..3855f46 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -14,6 +14,7 @@
#include
#include
+#include
#include
#include
#include
@@ -35,11 +36,17 @@
#define to_dp(nm) container_of(nm, struct rockchip_dp_device, nm)
-/* dp grf register offset */
-#define GRF_SOC_CON60x025c
-#define GRF_EDP_LCD_SEL_MASKBIT(5)
-#define GRF_EDP_SEL_VOP_LIT BIT(5)
-#define GRF_EDP_SEL_VOP_BIG 0
+/**
+ * struct rockchip_dp_chip_data - splite the grf setting of kind of chips
+ * @lcdsel_grf_reg: grf register offset of lcdc select
+ * @lcdsel_big: reg value of selecting vop big for eDP
+ * @lcdsel_lit: reg value of selecting vop little for eDP
+ */
+struct rockchip_dp_chip_data {
+ u32 lcdsel_grf_reg;
+ u32 lcdsel_big;
+ u32 lcdsel_lit;
+};
struct rockchip_dp_device {
struct drm_device*drm_dev;
@@ -51,6 +58,8 @@ struct rockchip_dp_device {
struct regmap*grf;
struct reset_control *rst;
+ const struct rockchip_dp_chip_data *data;
+
struct analogix_dp_plat_data plat_data;
};
@@ -119,13 +128,13 @@ static void rockchip_dp_drm_encoder_enable(struct
drm_encoder *encoder)
return;
if (ret)
- val = GRF_EDP_SEL_VOP_LIT | (GRF_EDP_LCD_SEL_MASK << 16);
+ val = dp->data->lcdsel_lit;
else
- val = GRF_EDP_SEL_VOP_BIG | (GRF_EDP_LCD_SEL_MASK << 16);
+ val = dp->data->lcdsel_big;
dev_dbg(dp->dev, "vop %s output to dp\n", (ret) ? "LIT" : "BIG");
- ret = regmap_write(dp->grf, GRF_SOC_CON6, val);
+ ret = regmap_write(dp->grf, dp->data->lcdsel_grf_reg, val);
if (ret != 0) {
dev_err(dp->dev, "Could not write to GRF: %d\n", ret);
return;
@@ -246,6 +255,7 @@ static int rockchip_dp_bind(struct device *dev, struct
device *master,
void *data)
{
struct rockchip_dp_device *dp = dev_get_drvdata(dev);
+ const struct rockchip_dp_chip_data *dp_data;
struct drm_device *drm_dev = data;
int ret;
@@ -256,10 +266,15 @@ static int rockchip_dp_bind(struct device *dev, struct
device *master,
*/
dev_set_drvdata(dev, NULL);
+ dp_data = of_device_get_match_data(dev);
+ if (!dp_data)
+ return -ENODEV;
+
ret = rockchip_dp_init(dp);
if (ret < 0)
return ret;
+ dp->data = dp_data;
dp->drm_dev = drm_dev;
ret = rockchip_dp_drm_create_encoder(dp);
@@ -365,8 +380,14 @@ static const struct dev_pm_ops rockchip_dp_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(rockchip_dp_suspend, rockchip_dp_resume)
};
+static const struct rockchip_dp_chip_data rk3288_dp = {
+ .lcdsel_grf_reg = 0x025c,
+ .lcdsel_big = 0 | BIT(21),
+ .lcdsel_lit = BIT(5) | BIT(21),
+};
+
static const struct of_device_id rockchip_dp_dt_ids[] = {
- {.compatible = "rockchip,rk3288-dp",},
+ {.compatible = "rockchip,rk3288-dp", .data = &rk3288_dp },
{}
};
MODULE_DEVICE_TABLE(of, rockchip_dp_dt_ids);
--
1.9.1
[PATCH v3 03/10] drm/bridge: analogix_dp: correct the register bit define error in ANALOGIX_DP_PLL_REG_1
There're an register define error in ANALOGIX_DP_PLL_REG_1 which introduced
by commit bcec20fd5ad6 ("drm: bridge: analogix/dp: add some rk3288 special
registers setting").
The PHY PLL input clock source is selected by ANALOGIX_DP_PLL_REG_1
BIT 0, not BIT 1.
Signed-off-by: Yakir Yang
Reviewed-by: Tomasz Figa
Tested-by: Javier Martinez Canillas
---
Changes in v3:
- Add reviewed flag from Tomasz.
[https://chromium-review.googlesource.com/#/c/346315/15]
- Add tested flag from Javier
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
index 337912b..88d56ad 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
@@ -163,8 +163,8 @@
#define HSYNC_POLARITY_CFG (0x1 << 0)
/* ANALOGIX_DP_PLL_REG_1 */
-#define REF_CLK_24M(0x1 << 1)
-#define REF_CLK_27M(0x0 << 1)
+#define REF_CLK_24M(0x1 << 0)
+#define REF_CLK_27M(0x0 << 0)
/* ANALOGIX_DP_LANE_MAP */
#define LANE3_MAP_LOGIC_LANE_0 (0x0 << 6)
--
1.9.1
[PATCH v3 04/10] drm/bridge: analogix_dp: some rockchip chips need to flip REF_CLK bit setting
As vendor document indicate, when REF_CLK bit set 0, then DP
phy's REF_CLK should switch to 24M source clock.
But due to IC PHY layout mistaken, some chips need to flip this
bit(like RK3288), and unfortunately they didn't indicate in the
DP version register. That's why we have to make this little hack.
Signed-off-by: Yakir Yang
Tested-by: Javier Martinez Canillas
---
Changes in v3:
- Make this hack code more clear (Tomasz, reviewed at Google Gerrit)
reg = ~reg & REF_CLK_MASK; ---> reg ^= REF_CLK_MASK;
[https://chromium-review.googlesource.com/#/c/346852/7/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
at 80]
- Add tested flag from Javier
Changes in v2:
- new patch in v2
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 6 +-
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h | 1 +
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 3 +++
include/drm/bridge/analogix_dp.h | 5 +
4 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 931a76c..97ced6b 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -75,7 +75,11 @@ void analogix_dp_init_analog_param(struct analogix_dp_device
*dp)
writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_2);
if (dp->plat_data && (dp->plat_data->dev_type == ROCKCHIP_DP)) {
- writel(REF_CLK_24M, dp->reg_base + ANALOGIX_DP_PLL_REG_1);
+ reg = REF_CLK_24M;
+ if (dp->plat_data->subdev_type == RK3288_DP)
+ reg ^= REF_CLK_MASK;
+
+ writel(reg, dp->reg_base + ANALOGIX_DP_PLL_REG_1);
writel(0x95, dp->reg_base + ANALOGIX_DP_PLL_REG_2);
writel(0x40, dp->reg_base + ANALOGIX_DP_PLL_REG_3);
writel(0x58, dp->reg_base + ANALOGIX_DP_PLL_REG_4);
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
index 88d56ad..cdcc6c5 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
@@ -165,6 +165,7 @@
/* ANALOGIX_DP_PLL_REG_1 */
#define REF_CLK_24M(0x1 << 0)
#define REF_CLK_27M(0x0 << 0)
+#define REF_CLK_MASK (0x1 << 0)
/* ANALOGIX_DP_LANE_MAP */
#define LANE3_MAP_LOGIC_LANE_0 (0x0 << 6)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 3855f46..315ebba 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -46,6 +46,7 @@ struct rockchip_dp_chip_data {
u32 lcdsel_grf_reg;
u32 lcdsel_big;
u32 lcdsel_lit;
+ u32 chip_type;
};
struct rockchip_dp_device {
@@ -286,6 +287,7 @@ static int rockchip_dp_bind(struct device *dev, struct
device *master,
dp->plat_data.encoder = &dp->encoder;
dp->plat_data.dev_type = ROCKCHIP_DP;
+ dp->plat_data.subdev_type = dp_data->chip_type;
dp->plat_data.power_on = rockchip_dp_poweron;
dp->plat_data.power_off = rockchip_dp_powerdown;
@@ -384,6 +386,7 @@ static const struct rockchip_dp_chip_data rk3288_dp = {
.lcdsel_grf_reg = 0x025c,
.lcdsel_big = 0 | BIT(21),
.lcdsel_lit = BIT(5) | BIT(21),
+ .chip_type = RK3288_DP,
};
static const struct of_device_id rockchip_dp_dt_ids[] = {
diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index 9e5d013..06c0250 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -18,8 +18,13 @@ enum analogix_dp_devtype {
ROCKCHIP_DP,
};
+enum analogix_dp_sub_devtype {
+ RK3288_DP,
+};
+
struct analogix_dp_plat_data {
enum analogix_dp_devtype dev_type;
+ enum analogix_dp_sub_devtype subdev_type;
struct drm_panel *panel;
struct drm_encoder *encoder;
struct drm_connector *connector;
--
1.9.1
[PATCH v3 07/10] drm/bridge: analogix_dp: passing the connector as an argument in .get_modes()
It's better to pass the connector to platform driver in .get_modes()
callback, just like what the .get_modes() helper function designed.
Signed-off-by: Yakir Yang
---
Changes in v3:
- Avoid to change any internal driver state in .mode_valid interface. (Tomasz,
reviewed at Google Gerrit)
[https://chromium-review.googlesource.com/#/c/346318/10/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
at 113]
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 +-
drivers/gpu/drm/exynos/exynos_dp.c | 4 ++--
include/drm/bridge/analogix_dp.h | 3 ++-
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 4a1b3b8..1a890fa 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -938,7 +938,7 @@ int analogix_dp_get_modes(struct drm_connector *connector)
num_modes += drm_panel_get_modes(dp->plat_data->panel);
if (dp->plat_data->get_modes)
- num_modes += dp->plat_data->get_modes(dp->plat_data);
+ num_modes += dp->plat_data->get_modes(dp->plat_data, connector);
return num_modes;
}
diff --git a/drivers/gpu/drm/exynos/exynos_dp.c
b/drivers/gpu/drm/exynos/exynos_dp.c
index 468498e..8a555ed 100644
--- a/drivers/gpu/drm/exynos/exynos_dp.c
+++ b/drivers/gpu/drm/exynos/exynos_dp.c
@@ -67,10 +67,10 @@ static int exynos_dp_poweroff(struct analogix_dp_plat_data
*plat_data)
return exynos_dp_crtc_clock_enable(plat_data, false);
}
-static int exynos_dp_get_modes(struct analogix_dp_plat_data *plat_data)
+static int exynos_dp_get_modes(struct analogix_dp_plat_data *plat_data,
+ struct drm_connector *connector)
{
struct exynos_dp_device *dp = to_dp(plat_data);
- struct drm_connector *connector = &dp->connector;
struct drm_display_mode *mode;
int num_modes = 0;
diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index 82b8135..181db09 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -34,7 +34,8 @@ struct analogix_dp_plat_data {
int (*power_off)(struct analogix_dp_plat_data *);
int (*attach)(struct analogix_dp_plat_data *, struct drm_bridge *,
struct drm_connector *);
- int (*get_modes)(struct analogix_dp_plat_data *);
+ int (*get_modes)(struct analogix_dp_plat_data *,
+struct drm_connector *);
};
int analogix_dp_resume(struct device *dev);
--
1.9.1
[PATCH v3 08/10] drm/rockchip: analogix_dp: correct the connector display color format and bpc
Rockchip VOP couldn't output YUV video format for eDP controller, so
when driver detect connector support YUV video format, we need to hack
it down to RGB888.
Signed-off-by: Yakir Yang
Acked-by: Mark Yao
---
Changes in v3:
- Hook the connector's color_formats in .get_modes directly. (Tomasz, reviewed
at Google Gerrit)
[https://chromium-review.googlesource.com/#/c/346317/15]
- Add the acked flag from Mark.
Changes in v2: None
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index da2e844..95a6f60 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -102,6 +102,22 @@ static int rockchip_dp_powerdown(struct
analogix_dp_plat_data *plat_data)
return 0;
}
+static int rockchip_dp_get_modes(struct analogix_dp_plat_data *plat_data,
+struct drm_connector *connector)
+{
+ struct drm_display_info *di = &connector->display_info;
+
+ if (di->color_formats & DRM_COLOR_FORMAT_YCRCB444 ||
+ di->color_formats & DRM_COLOR_FORMAT_YCRCB422) {
+ di->color_formats &= ~(DRM_COLOR_FORMAT_YCRCB422 |
+ DRM_COLOR_FORMAT_YCRCB444);
+ di->color_formats |= DRM_COLOR_FORMAT_RGB444;
+ di->bpc = 8;
+ }
+
+ return 0;
+}
+
static bool
rockchip_dp_drm_encoder_mode_fixup(struct drm_encoder *encoder,
const struct drm_display_mode *mode,
@@ -313,6 +329,7 @@ static int rockchip_dp_bind(struct device *dev, struct
device *master,
dp->plat_data.subdev_type = dp_data->chip_type;
dp->plat_data.power_on = rockchip_dp_poweron;
dp->plat_data.power_off = rockchip_dp_powerdown;
+ dp->plat_data.get_modes = rockchip_dp_get_modes;
return analogix_dp_bind(dev, dp->drm_dev, &dp->plat_data);
}
--
1.9.1
[PATCH v3 01/10] drm/bridge: analogix_dp: rename RK3288_DP to ROCKCHIP_DP
Rename RK3288_DP macros to ROCKCHIP_DP, prepare to add eDP
support for more Rockchip chips.
Signed-off-by: Yakir Yang
Reviewed-by: Stéphane Marchesin
Tested-by: Javier Martinez Canillas
---
Changes in v3:
- Correct the misspell of "marcos" in commit message (Dominik, reviewed at
Google Gerrit)
[https://chromium-review.googlesource.com/#/c/346312/9//COMMIT_MSG at 9]
- Add reviewed flag from Stéphane.
[https://chromium-review.googlesource.com/#/c/346312/16]
- Add tested flag from Javier.
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 4 ++--
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 6 +++---
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 2 +-
include/drm/bridge/analogix_dp.h | 2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 7699597..4a1b3b8 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1207,9 +1207,9 @@ static int analogix_dp_dt_parse_pdata(struct
analogix_dp_device *dp)
struct video_info *video_info = &dp->video_info;
switch (dp->plat_data->dev_type) {
- case RK3288_DP:
+ case ROCKCHIP_DP:
/*
-* Like Rk3288 DisplayPort TRM indicate that "Main link
+* Like Rockchip DisplayPort TRM indicate that "Main link
* containing 4 physical lanes of 2.7/1.62 Gbps/lane".
*/
video_info->max_link_rate = 0x0A;
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 49205ef..931a76c 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -74,7 +74,7 @@ void analogix_dp_init_analog_param(struct analogix_dp_device
*dp)
reg = SEL_24M | TX_DVDD_BIT_1_0625V;
writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_2);
- if (dp->plat_data && (dp->plat_data->dev_type == RK3288_DP)) {
+ if (dp->plat_data && (dp->plat_data->dev_type == ROCKCHIP_DP)) {
writel(REF_CLK_24M, dp->reg_base + ANALOGIX_DP_PLL_REG_1);
writel(0x95, dp->reg_base + ANALOGIX_DP_PLL_REG_2);
writel(0x40, dp->reg_base + ANALOGIX_DP_PLL_REG_3);
@@ -244,7 +244,7 @@ void analogix_dp_set_analog_power_down(struct
analogix_dp_device *dp,
u32 reg;
u32 phy_pd_addr = ANALOGIX_DP_PHY_PD;
- if (dp->plat_data && (dp->plat_data->dev_type == RK3288_DP))
+ if (dp->plat_data && (dp->plat_data->dev_type == ROCKCHIP_DP))
phy_pd_addr = ANALOGIX_DP_PD;
switch (block) {
@@ -448,7 +448,7 @@ void analogix_dp_init_aux(struct analogix_dp_device *dp)
analogix_dp_reset_aux(dp);
/* Disable AUX transaction H/W retry */
- if (dp->plat_data && (dp->plat_data->dev_type == RK3288_DP))
+ if (dp->plat_data && (dp->plat_data->dev_type == ROCKCHIP_DP))
reg = AUX_BIT_PERIOD_EXPECTED_DELAY(0) |
AUX_HW_RETRY_COUNT_SEL(3) |
AUX_HW_RETRY_INTERVAL_600_MICROSECONDS;
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 7f6a55c..2bc8a7e 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -270,7 +270,7 @@ static int rockchip_dp_bind(struct device *dev, struct
device *master,
dp->plat_data.encoder = &dp->encoder;
- dp->plat_data.dev_type = RK3288_DP;
+ dp->plat_data.dev_type = ROCKCHIP_DP;
dp->plat_data.power_on = rockchip_dp_poweron;
dp->plat_data.power_off = rockchip_dp_powerdown;
diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index 25afb31..9e5d013 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -15,7 +15,7 @@
enum analogix_dp_devtype {
EXYNOS_DP,
- RK3288_DP,
+ ROCKCHIP_DP,
};
struct analogix_dp_plat_data {
--
1.9.1
[PATCH v3 05/10] drm/rockchip: analogix_dp: add rk3399 eDP support
RK3399 and RK3288 shared the same eDP IP controller, only some light
difference with VOP configure and GRF configure.
Signed-off-by: Yakir Yang
Acked-by: Mark Yao
---
Changes in v3:
- Give the "rk3399-edp" a separate line for clarity in document (Tomasz,
reviewed at Google Gerrit)
[https://chromium-review.googlesource.com/#/c/346314/10/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
at 5]
- Move 'output_type' setting before the return statement (Tomasz, reviewed at
Google Gerrit)
[https://chromium-review.googlesource.com/#/c/346314/10/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
at 154]
- Add the acked flag from Mark.
Changes in v2:
- rebase with drm-next, fix some conflicts
.../bindings/display/bridge/analogix_dp.txt| 1 +
.../display/rockchip/analogix_dp-rockchip.txt | 3 +-
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 33 +-
include/drm/bridge/analogix_dp.h | 1 +
4 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
index 4f2ba8c..4a0f4f7 100644
--- a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
+++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
@@ -5,6 +5,7 @@ Required properties for dp-controller:
platform specific such as:
* "samsung,exynos5-dp"
* "rockchip,rk3288-dp"
+* "rockchip,rk3399-edp"
-reg:
physical base address of the controller and length
of memory mapped region.
diff --git
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
index e832ff9..726c945 100644
---
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
+++
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
@@ -2,7 +2,8 @@ Rockchip RK3288 specific extensions to the Analogix Display Port
Required properties:
-- compatible: "rockchip,rk3288-edp";
+- compatible: "rockchip,rk3288-edp",
+ "rockchip,rk3399-edp";
- reg: physical base address of the controller and length
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 315ebba..bcd9ecc 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -153,6 +153,8 @@ rockchip_dp_drm_encoder_atomic_check(struct drm_encoder
*encoder,
struct drm_connector_state *conn_state)
{
struct rockchip_crtc_state *s = to_rockchip_crtc_state(crtc_state);
+ struct rockchip_dp_device *dp = to_dp(encoder);
+ int ret;
/*
* FIXME(Yakir): driver should configure the CRTC output video
@@ -167,7 +169,28 @@ rockchip_dp_drm_encoder_atomic_check(struct drm_encoder
*encoder,
* But if I configure CTRC to RGBaaa, and eDP driver still keep
* RGB666 input video mode, then screen would works prefect.
*/
- s->output_mode = ROCKCHIP_OUT_MODE_;
+
+ ret = drm_of_encoder_active_endpoint_id(dp->dev->of_node, encoder);
+ if (ret < 0)
+ return 0;
+
+ switch (dp->data->chip_type) {
+ case RK3399_EDP:
+ /*
+* For RK3399, VOP Lit must code the out mode to RGB888,
+* VOP Big must code the out mode to RGB10.
+*/
+ if (ret)
+ s->output_mode = ROCKCHIP_OUT_MODE_P888;
+ else
+ s->output_mode = ROCKCHIP_OUT_MODE_;
+ break;
+
+ default:
+ s->output_mode = ROCKCHIP_OUT_MODE_;
+ break;
+ }
+
s->output_type = DRM_MODE_CONNECTOR_eDP;
return 0;
@@ -382,6 +405,13 @@ static const struct dev_pm_ops rockchip_dp_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(rockchip_dp_suspend, rockchip_dp_resume)
};
+static const struct rockchip_dp_chip_data rk3399_edp = {
+ .lcdsel_grf_reg = 0x6250,
+ .lcdsel_big = 0 | BIT(21),
+ .lcdsel_lit = BIT(5) | BIT(21),
+ .chip_type = RK3399_EDP,
+};
+
static const struct rockchip_dp_chip_data rk3288_dp = {
.lcdsel_grf_reg = 0x025c,
.lcdsel_big = 0 | BIT(21),
@@ -391,6 +421,7 @@ static const struct rockchip_dp_chip_data rk3288_dp = {
static const struct of_device_id rockchip_dp_dt_ids[] = {
{.compatible = "rockchip,rk3288-dp", .data = &rk3288_dp },
+ {.compatible = "rockchip,rk3399-edp", .data = &rk3399_edp },
{}
};
MODULE_DEVICE_TABLE(of, rockchip_dp_dt_ids);
diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index 06c0250..82b8135 100644
--- a/inc
[PATCH v3 06/10] drm/rockchip: analogix_dp: make panel detect to an optional action
Some boards don't need to declare a panel device node, like the
display interface is DP monitors, so it's necessary to make the
panel detect to an optional action.
Signed-off-by: Yakir Yang
Acked-by: Mark Yao
---
Changes in v3:
- Add the acked flag from Mark.
Changes in v2: None
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 48 -
1 file changed, 22 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index bcd9ecc..da2e844 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -332,38 +332,34 @@ static int rockchip_dp_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct device_node *panel_node, *port, *endpoint;
+ struct drm_panel *panel = NULL;
struct rockchip_dp_device *dp;
- struct drm_panel *panel;
port = of_graph_get_port_by_id(dev->of_node, 1);
- if (!port) {
- dev_err(dev, "can't find output port\n");
- return -EINVAL;
- }
-
- endpoint = of_get_child_by_name(port, "endpoint");
- of_node_put(port);
- if (!endpoint) {
- dev_err(dev, "no output endpoint found\n");
- return -EINVAL;
- }
-
- panel_node = of_graph_get_remote_port_parent(endpoint);
- of_node_put(endpoint);
- if (!panel_node) {
- dev_err(dev, "no output node found\n");
- return -EINVAL;
- }
-
- panel = of_drm_find_panel(panel_node);
- if (!panel) {
- DRM_ERROR("failed to find panel\n");
+ if (port) {
+ endpoint = of_get_child_by_name(port, "endpoint");
+ of_node_put(port);
+ if (!endpoint) {
+ dev_err(dev, "no output endpoint found\n");
+ return -EINVAL;
+ }
+
+ panel_node = of_graph_get_remote_port_parent(endpoint);
+ of_node_put(endpoint);
+ if (!panel_node) {
+ dev_err(dev, "no output node found\n");
+ return -EINVAL;
+ }
+
+ panel = of_drm_find_panel(panel_node);
+ if (!panel) {
+ DRM_ERROR("failed to find panel\n");
+ of_node_put(panel_node);
+ return -EPROBE_DEFER;
+ }
of_node_put(panel_node);
- return -EPROBE_DEFER;
}
- of_node_put(panel_node);
-
dp = devm_kzalloc(dev, sizeof(*dp), GFP_KERNEL);
if (!dp)
return -ENOMEM;
--
1.9.1
[PATCH v3 09/10] drm/rockchip: analogix_dp: update the comments about why need to hardcode VOP output mode
The hardware IC designed that VOP must output the RGB10 video format to eDP contoller, and if eDP panel only support RGB8, then eDP contoller should cut down the video data, not via VOP contoller, that's why we need to hardcode the VOP output mode to RGA10 here. Signed-off-by: Yakir Yang Acked-by: Mark Yao Reviewed-by: Tomasz Figa --- Changes in v3: - Add the reviewed flag from Tomasz. [https://chromium-review.googlesource.com/#/c/346853/12] - Add the acked flag from Mark. Changes in v2: - new patch in v2 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 16 +--- 1 file changed, 5 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c index 95a6f60..2ceb3f9 100644 --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c @@ -173,17 +173,11 @@ rockchip_dp_drm_encoder_atomic_check(struct drm_encoder *encoder, int ret; /* -* FIXME(Yakir): driver should configure the CRTC output video -* mode with the display information which indicated the monitor -* support colorimetry. -* -* But don't know why the CRTC driver seems could only output the -* RGBaaa rightly. For example, if connect the "innolux,n116bge" -* eDP screen, EDID would indicated that screen only accepted the -* 6bpc mode. But if I configure CRTC to RGB666 output, then eDP -* screen would show a blue picture (RGB888 show a green picture). -* But if I configure CTRC to RGBaaa, and eDP driver still keep -* RGB666 input video mode, then screen would works prefect. +* The hardware IC designed that VOP must output the RGB10 video +* format to eDP contoller, and if eDP panel only support RGB8, +* then eDP contoller should cut down the video data, not via VOP +* contoller, that's why we need to hardcode the VOP output mode +* to RGA10 here. */ ret = drm_of_encoder_active_endpoint_id(dp->dev->of_node, encoder); -- 1.9.1
[PATCH v3 10/10] drm/bridge: analogix_dp: fix no drm hpd event when panel plug in
The enum value of DP_IRQ_TYPE_HP_CABLE_IN is zero, but driver only
send drm hp event when the irq_type and the enum value is true.
if (irq_type & DP_IRQ_TYPE_HP_CABLE_IN || ...)
drm_helper_hpd_irq_event(dp->drm_dev);
So there would no drm hpd event when cable plug in, to fix that
just need to assign all hotplug enum with no-zero values.
Reported-by: Dan Carpenter
Signed-off-by: Yakir Yang
Reviewed-by: Stéphane Marchesin
Tested-by: Javier Martinez Canillas
---
Changes in v3:
- Add reviewed flag from Stéphane.
[https://chromium-review.googlesource.com/#/c/346319/15]
- Add tested flag from Javier
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index f09275d..b456380 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -127,10 +127,10 @@ enum analog_power_block {
};
enum dp_irq_type {
- DP_IRQ_TYPE_HP_CABLE_IN,
- DP_IRQ_TYPE_HP_CABLE_OUT,
- DP_IRQ_TYPE_HP_CHANGE,
- DP_IRQ_TYPE_UNKNOWN,
+ DP_IRQ_TYPE_HP_CABLE_IN = BIT(0),
+ DP_IRQ_TYPE_HP_CABLE_OUT = BIT(1),
+ DP_IRQ_TYPE_HP_CHANGE= BIT(2),
+ DP_IRQ_TYPE_UNKNOWN = BIT(3),
};
struct video_info {
--
1.9.1
[PATCH 1/5] drm/tilcdc: Restore old dmps state in pm_resume()
On 14/06/16 14:45, Jyri Sarha wrote:
> Restore old dpms state in pm_resume(). The dpms is turned off in
> pm_suspend() and it should be restored to its original state in
> pm_resume().
>
> Fixes commit 614b3cfeb8d2 ("drm/tilcdc: disable the lcd controller/dma
> engine when suspend invoked")
"dmps" in the subject.
It would be good to mention what the problem seen is, what does this fix.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160614/4bdd350f/attachment-0001.sig>
[PATCH 5/5] drm/tilcdc: Avoid error print by of_graph_get_next_endpoint()
On 06/14/16 14:45, Jyri Sarha wrote:
> Avoid error print by of_graph_get_next_endpoint() if there is no ports
> present.
>
> Signed-off-by: Jyri Sarha
> ---
> drivers/gpu/drm/tilcdc/tilcdc_external.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c
> b/drivers/gpu/drm/tilcdc/tilcdc_external.c
> index 03acb4f..51811e3 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_external.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_external.c
> @@ -138,9 +138,20 @@ static int dev_match_of(struct device *dev, void *data)
> int tilcdc_get_external_components(struct device *dev,
> struct component_match **match)
> {
> + struct device_node *node;
> struct device_node *ep = NULL;
> int count = 0;
>
> + /* Avoid error print by of_graph_get_next_endpoint() if there
> + * is no ports present.
> + */
> + node = of_get_child_by_name(dev->of_node, "ports");
> + if (!node)
> + node = of_get_child_by_name(dev->of_node, "port");
> + if (!node)
> + return 0;
> + of_node_put(node);
> +
> while ((ep = of_graph_get_next_endpoint(dev->of_node, ep))) {
> struct device_node *node;
Argh.. This now redundant local variable should have been removed. It is
now done in my local branch and will be in the v2 series, if there is
need for one.
BR,
Jyri
[PATCH v2 1/2] drm/crtc: fix connector reference counting mismatch in drm_crtc_helper_set_config
Am Montag, den 13.06.2016, 20:18 +0200 schrieb Daniel Vetter:
[...]
> > > > Only the reference count of connectors that weren't previously bound to
> > > > an encoder should be incremented after a call to
> > > > drm_crtc_helper_set_config.
> > > > And only the reference count of connectors that were previously bound to
> > > > an encoder and are unbound afterwards should ever be decremented.
> > > > The reference counts of the temporary copies in the save_connectors
> > > > should not be touched at all.
> > > >
> > > > This patch fixes the above error by only incrementing the reference
> > > > count
> > > > of those connectors in the set that are initially not bound to any
> > > > encoder,
> > > > and also by restoring the reference count of only those connectors in
> > > > the
> > > > set in the failure case.
> > > >
> > > > Fixes: 0955c1250e96 ("drm/crtc: take references to connectors used in a
> > > > modeset. (v2)")
> > > > Signed-off-by: Philipp Zabel
> > >
> > > I'd like to analyze this bug first a bit more (since it seems to be imx
> > > specific) before review/merging, per our ongoing discussion. The current
> > > code is definitely wrong, but looking at it I more expected a leak (since
> > > we decrement saved structures, not the real ones), not an explosion.
> > > -Daniel
> > >
> > There is a regression bug open against nouveau, which shows the same
> > symptoms and is fixed by these patches.
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=119861
> >
> > It is not specific to imx-drm, but doesn't explode on desktop system
> > right away, probably due to the FB emulation holding a reference to all
> > connectors.
>
> Sensible theory. Can you confirm that enabling fbdev emulation on imx
> works around this?
Yes, we are unable to reproduce the issue if fbdev emulation is enabled.
Regards,
Lucas
[PATCH v2 08/10] dt-bindings: msm/dsi: Modify port and PHY bindings
On Fri, Jun 10, 2016 at 04:16:38PM +0530, Archit Taneja wrote: > The DSI node now has two ports that describe the connection between the > MDP interface output and the DSI input, and the connection between the DSI > output and the connected panel/bridge. Update the properties and the > example. > > Also, use generic PHY bindings instead of the custom one. > > Signed-off-by: Archit Taneja > --- > v2: > - Use hyphen for dsi phy name > > .../devicetree/bindings/display/msm/dsi.txt| 45 > -- > 1 file changed, 34 insertions(+), 11 deletions(-) Acked-by: Rob Herring
[PATCH 1/2] drm: vc4: set permissions for ioctls
On 10 June 2016 at 21:08, Eric Anholt wrote: > Emil Velikov writes: > >> On 10 June 2016 at 00:42, Eric Anholt wrote: >>> Rob Herring writes: >>> Ioctls generally have DRM_AUTH and DRM_RENDER_ALLOW set to restrict them to authorized clients and render nodes. Without this, access from render nodes fails. >>> >>> We've already got a fix to add RENDER_ALLOW submitted in the latest >>> drm-vc4-fixes. There's no reason to require auth on this >>> implementation, though. >>> >> Not 100% sure but I think you do. At least every other driver does... >> >> Why: I'm thinking that without DRM_AUTH one will be able to open the >> card# node and issue the said IOCTLs even if the client is not >> authenticated. Which, obviously isn't a huge deal, but doesn't sound >> right. >> >> Then again, my knowledge of vc4 is virtually non-existent, so there >> might be something special happening here ? > > Let's flip this around: What is the problem you see with calling any of > the ioctls without having gone through the auth dance? I don't believe > there's any reason to require auth, since you only have access to the > buffers you create or import. > > Basically, auth was created a stopgap solution for "but if anyone had > access to the DRM device, they could scrape the X frontbuffer!" Personally I don't see any serious issues* with keeping DRM_AUTH out of these. Although one could argue that the lack of it up-to recently one was using non-auth access to the card node. The latter of which lead to the DRM_RENDER_ALLOW going unnoticed. That aside, I would urge that we have consistency on the topic. Whether adding DRM_AUTH to the said VC4 ioctls, dropping DRM_AUTH everywhere (if DRM_RENDER_ALLOW is present on the said ioclt) or something else. I believe Daniel V was wondering about the second at some stage. Regards, Emil * Barring buggy user-space tailored for this behaviour.
[PATCH v2 10/10] dt-bindings: msm/dsi: Some binding doc cleanups
On Fri, Jun 10, 2016 at 04:16:40PM +0530, Archit Taneja wrote: > Some cleanups: > > - Use simpler names for DT nodes in the example > - Use references instead of dumping Document links everywhere > > Signed-off-by: Archit Taneja > --- > .../devicetree/bindings/display/msm/dsi.txt| 45 > +++--- > 1 file changed, 22 insertions(+), 23 deletions(-) Acked-by: Rob Herring
[PATCH] virtio-gpu: use src not crtc
On Di, 2016-06-14 at 12:13 +0200, Marc-André Lureau wrote: > Hi > > On Tue, May 31, 2016 at 2:52 PM, Gerd Hoffmann wrote: > > Pick up the correct source rectangle from framebuffer. > > Without this multihead setups are not working correctly. > > > > Signed-off-by: Gerd Hoffmann > > Reviewed-by: Marc-André Lureau > > Additionally, I had to modify the page_flip() function to take the > plane source coordinates for virgl/3d multihead to work. Feel free to > squash. This is in progress of being sorted, by dropping the virtio_gpu_page_flip function altogether in favor of atomic helpers, which will use the (already fixed) plane callbacks instead. See nonblocking commit support patches by Daniel Vetter on this list. cheers, Gerd
Looking for pointers on diagnosing ring test failure in amdgpu
On Tue, Jun 14, 2016 at 4:10 AM, Christian König
wrote:
> Hi Matthew,
>
> see inline below.
>
> Am 14.06.2016 um 00:03 schrieb Matthew Macy:
>>
>> On Mon, 13 Jun 2016 01:35:34 -0700 Christian König
>> wrote
>> > Hi Matthew,
>> >
>> > sounds like the UVD block doesn't want to initialize. No idea off hand
>> > why, could be anything. I would need the hardware here for a closer
>> > inspection.
>> >
>> > For a workaround you can try to disable the UVD blokc using the
>> > ip_block_mask module parameter (it's a bitmask of enabled blocks e.g.
>> > 0x means all blocks enabled, UVD is bit 7 on Carrizo IIRC).
>>
>>
>> When I clear bit 7 I get the following now:
>>
>> Jun 14 07:58:18 trainwreck kernel: drmn0: fence driver on ring 10 use gpu
>> addr 0x40b0, cpu addr 0x0xf800bd4320b0
>> Jun 14 07:58:18 trainwreck kernel: drmn0: fence driver on ring 11 use gpu
>> addr 0x40c0, cpu addr 0x0xf800bd4320c0
>> Jun 14 07:58:19 trainwreck kernel: drmn0: SMU check loaded firmware
>> failed, expecting 0x17f, getting 0x0[drm:0x826d4dc4s] *ERROR*
>> amdgpu: smc start failed
>> Jun 14 07:58:19 trainwreck kernel: [drm:0x8269fc40s] *ERROR*
>> hw_init 3 failed -22
>> Jun 14 07:58:19 trainwreck kernel: drmn0: amdgpu_init failed
>
>
> UVD is optional (as long as you don't want to do hardware video decoding)
> but the SMU isn't. Alex, Rex any idea what's going wrong here?
>
Seems like maybe the two issues are related. Maybe some general MMIO
issue on that particular system or a issue with the MC or gart setup?
The firmware that the SMU loads is stored in gart and all of the
engine rings are in gart. Maybe a problem with the IOMMU setup on the
CPU?
Alex
>> Which is hard to correlate without spending a lot more quality time with
>> the driver than I've had time for yet.
>
>
> Yeah, I don't see why some blocks should fail while others seem to
> initialize just fine. Especially since you reported it seems to work on
> other hardware.
>
>> One thing that occurs to me is that Linux is usually compiled with gcc6 -
>> has amdgpu ever been tested as compiled with clang?
>
>
> Not as far as I know. We had some problems in the past even with some gcc
> versions because of some odd things in the BIOS headers (e.g. zero sized
> arrays). But those issues should be fixed by now.
>
>> Below is a list of the warnings I have to disable in order to get amdgpu
>> to compile without disabling Werror altogether. The -Wno-format is an
>> artifact of clang or FreeBSD treating long long and uint64_t as distinct
>> types and the -Wno-pointer-arith is to accept the linux convention of doing
>> pointer arithmetic on void pointers. All the others are arguably oversights
>> in the code (similar silencing has to be done in i915, but I've had better
>> luck with it to date). I haven't fixed the warnings because I try to treat
>> it as vendor code and minimize any local changes. Will you accept
>> quasi-cosmetic patches from other operating systems / compilers?
>
>
> Yeah, sure feel free to provide patches. As long as it is only cleanup and
> not structural changes it should be trivial to get them merged.
>
> Especially "-Wno-missing-prototypes" and "-Wno-unused-variable" sound like
> something which should be trivial to fix.
>
> Regards,
> Christian.
>
>
>>
>> Thanks.
>>
>> -M
>>
>>
>> CWARNFLAGS+=-Wno-pointer-arith
>> CWARNFLAGS+=-Wno-pointer-sign ${CWARNFLAGS.${.IMPSRC:T}}
>>
>> CWARNFLAGS.amdgpu_acpi.c= -Wno-int-conversion
>> -Wno-missing-prototypes -Wno-unused-variable
>> CWARNFLAGS.amdgpu_amdkfd.c= -Wno-missing-prototypes
>> CWARNFLAGS.amdgpu_bo_list.c=-Wno-missing-prototypes
>> CWARNFLAGS.amdgpu_cs.c= -Wno-missing-prototypes
>> CWARNFLAGS.amdgpu_device.c= -Wno-format -Wno-cast-qual
>> CWARNFLAGS.amdgpu_fence.c= -Wno-format
>> CWARNFLAGS.amdgpu_gfx.c=-Wno-missing-prototypes
>> CWARNFLAGS.amdgpu_amdkfd_gfx_v7.c= -Wno-cast-qual
>> CWARNFLAGS.amdgpu_amdkfd_gfx_v8.c= -Wno-cast-qual
>> CWARNFLAGS.amdgpu_atpx_handler.c= -Wno-missing-prototypes
>> CWARNFLAGS.amdgpu_ih.c= -Wno-cast-qual
>> CWARNFLAGS.amdgpu_ioc32.c= -Wno-missing-prototypes
>> CWARNFLAGS.amdgpu_object.c= -Wno-format
>> CWARNFLAGS.amdgpu_mn.c= -Wno-unused-variable
>> CWARNFLAGS.amdgpu_pll.c=-Wno-missing-prototypes
>> CWARNFLAGS.amdgpu_pm.c= -Wno-missing-prototypes
>> -Wno-enum-conversion
>> CWARNFLAGS.amdgpu_ring.c= -Wno-cast-qual
>> CWARNFLAGS.amdgpu_ttm.c=-Wno-missing-prototypes
>> CWARNFLAGS.amdgpu_ucode.c=
>> -Wno-incompatible-pointer-types-discards-qualifiers -Wno-cast-qual
>> CWARNFLAGS.amdgpu_uvd.c=-Wno-format
>> CWARNFLAGS.amdgpu_vce.c=-Wno-format
>> CWARNFLAGS.amdgpu_vce.c=-Wno-format
>> CWARNFLAGS.amdgpu_vm.c= -Wno-format
>> CWARNFLAGS.amdgpu_test.c= -Wno-format
>> CWARNFLAGS.amdgpu_vm.c= -Wno-format
>> CWARNFLAGS.atombios_crtc.c= -Wno-missing-prototype
[PATCH 2/2] drm/edid: Add 6 bpc quirk for display AEO model 0.
On 06/14/2016 12:44 PM, Ville Syrjälä wrote:
> On Thu, May 26, 2016 at 04:39:04PM +0200, Mario Kleiner wrote:
>> Bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=105331
>> reports that the "AEO model 0" display is driven with 8 bpc
>> without dithering by default, which looks bad because that
>> panel is apparently a 6 bpc DP panel with faulty EDID.
>>
>> A fix for this was made by commit 013dd9e03872
>> ("drm/i915/dp: fall back to 18 bpp when sink capability is unknown").
>>
>> That commit triggers new regressions in precision for DP->DVI and
>> DP->VGA displays. A patch is out to revert that commit, but it will
>> revert video output for the AEO model 0 panel to 8 bpc without
>> dithering.
>>
>> The EDID 1.3 of that panel, as decoded from the xrandr output
>> attached to that bugzilla bug report, is somewhat faulty, and beyond
>> other problems also sets the "DFP 1.x compliant TMDS" bit, which
>> according to DFP spec means to drive the panel with 8 bpc and
>> no dithering in absence of other colorimetry information.
>>
>> Try to make the original bug reporter happy despite the
>> faulty EDID by adding a quirk to mark that panel as 6 bpc,
>> so 6 bpc output with dithering creates a nice picture.
>>
>> Tested by injecting the edid from the fdo bug into a DP connector
>> via drm_kms_helper.edid_firmware and verifying the 6 bpc + dithering
>> is selected.
>>
>> This patch should be backported to stable.
>>
>> Signed-off-by: Mario Kleiner
>> Cc: stable at vger.kernel.org
>> Cc: Jani Nikula
>> Cc: Ville Syrjälä
>> Cc: Daniel Vetter
>
> Now I'm confused. I thought we didn't need any quirks?
>
We don't need a quirk for this, once the DP sink bpc helper i wrote is
cleaned up, merged and hooked up.
But as Jani advised me as well, that code might be a bit too much for
backporting to stable kernels, and i really also need a fix for stable
kernels.
So plan is:
1. Get patch 1/2 into drm-next or drm-fixes, which is a revert of Jani's
patch and thereby fixes the regression i care about. Easily
back-portable to stable.
2. Because that would cause mishandling of that panel again, get this
patch 2/2 in as well, backport to stable, so owners of that panel stay
happy on LTS kernels. I personally don't care much about patch 2/2,
because that doesn't fix a kernel bug, but a bug in that panels edid.
Given how easy it is to fix with an edid quirk, it would still be nice
to apply, so stable kernels can deal better with that panel.
3. On top of 1 i'll then resubmit a cleaned up version of a new DP
helper for Linux 4.8 to fix this properly.
I tested this patch against the edid from the fdo bug to make sure it
does the right thing. But i don't really care if we keep or drop it. The
important one is 1/2 for fixing the stable regression.
thanks,
-mario
>> ---
>> drivers/gpu/drm/drm_edid.c | 8
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 7df26d4..2cb472b 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -74,6 +74,8 @@
>> #define EDID_QUIRK_FORCE_8BPC (1 << 8)
>> /* Force 12bpc */
>> #define EDID_QUIRK_FORCE_12BPC (1 << 9)
>> +/* Force 6bpc */
>> +#define EDID_QUIRK_FORCE_6BPC (1 << 10)
>>
>> struct detailed_mode_closure {
>> struct drm_connector *connector;
>> @@ -100,6 +102,9 @@ static struct edid_quirk {
>> /* Unknown Acer */
>> { "ACR", 2423, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
>>
>> +/* AEO model 0 reports 8 bpc, but is a 6 bpc panel */
>> +{ "AEO", 0, EDID_QUIRK_FORCE_6BPC },
>> +
>> /* Belinea 10 15 55 */
>> { "MAX", 1516, EDID_QUIRK_PREFER_LARGE_60 },
>> { "MAX", 0x77e, EDID_QUIRK_PREFER_LARGE_60 },
>> @@ -4082,6 +4087,9 @@ int drm_add_edid_modes(struct drm_connector
>> *connector, struct edid *edid)
>>
>> drm_add_display_info(edid, &connector->display_info, connector);
>>
>> +if (quirks & EDID_QUIRK_FORCE_6BPC)
>> +connector->display_info.bpc = 6;
>> +
>> if (quirks & EDID_QUIRK_FORCE_8BPC)
>> connector->display_info.bpc = 8;
>>
>> --
>> 2.7.0
>
[PATCH 1/2] drm/i915/dp: Revert "drm/i915/dp: fall back to 18 bpp when sink capability is unknown"
On 06/14/2016 01:05 PM, Daniel Vetter wrote:
> On Thu, May 26, 2016 at 4:39 PM, Mario Kleiner
> wrote:
>> This reverts commit 013dd9e03872
>> ("drm/i915/dp: fall back to 18 bpp when sink capability is unknown")
>>
>> This commit introduced a regression into stable kernels,
>> as it reduces output color depth to 6 bpc for any video
>> sink connected to a Displayport connector if that sink
>> doesn't report a specific color depth via EDID, or if
>> our EDID parser doesn't actually recognize the proper
>> bpc from EDID.
>>
>> Affected are active DisplayPort->VGA converters and
>> active DisplayPort->DVI converters. Both should be
>> able to handle 8 bpc, but are degraded to 6 bpc with
>> this patch.
>>
>> The reverted commit was meant to fix
>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105331
>>
>> A followup patch implements a fix for that specific bug,
>> which is caused by a faulty EDID of the affected DP panel
>> by adding a new EDID quirk for that panel.
>>
>> DP 18 bpp fallback handling and other improvements to
>> DP sink bpc detection will be handled for future
>> kernels in a separate series of patches.
>>
>> Please backport to stable.
>>
>> Signed-off-by: Mario Kleiner
>> Acked-by: Jani Nikula
>> Cc: stable at vger.kernel.org
>> Cc: Ville Syrjälä
>> Cc: Daniel Vetter
>
> I wonder whether we shouldn't just move this into the DP code, and
> instead of looking at the edid (which is just pass-through for dp->vga
> dongles) we should only look at dpcd values? Or maybe only look at the
> edid value if the sink is native DP, and not when it's a dongle.
>
> That would probably also avoid the quirk, and that quirk seems a bit fishy.
> -Daniel
>
This patch is just a simple fix for the color depth regression which
affects stable kernels. It can be back-ported easily to affected stable
kernels, as Jani advised me.
I wanted to clean up and resubmit that DP helper function which looks at
dpcd values and might be a bit too much for stable, once this fix is in.
-mario
[PATCH] drm/virtio: Don't reinvent a flipping wheel
> >> Gerd, can you pls retest? I think due to your change in the above > >> referenced commit to switch to active_only=true in commit_planes() this is > >> now broken. > > > > Yes, probably it'll break things. > > > > Any branch I can test? Your "stuff" branch seems to not yet have the > > commit above. > > > > I guess virtio-gpu should switch over to override .atomic_commit_tail > > instead of .atomic_commit? > > See v2 that I've sent out - it contains these changes already. Patch > applies on top of topic/drm-misc, but I'll be pushing out a new > version of stuff asap. Tested refreshed "stuff" branch now, seems to work just fine. Anything specific to look out for? cheers Gerd
[PATCH] drm/virtio: Don't reinvent a flipping wheel
On Tue, Jun 14, 2016 at 04:25:45PM +0200, Gerd Hoffmann wrote: > > >> Gerd, can you pls retest? I think due to your change in the above > > >> referenced commit to switch to active_only=true in commit_planes() this > > >> is > > >> now broken. > > > > > > Yes, probably it'll break things. > > > > > > Any branch I can test? Your "stuff" branch seems to not yet have the > > > commit above. > > > > > > I guess virtio-gpu should switch over to override .atomic_commit_tail > > > instead of .atomic_commit? > > > > See v2 that I've sent out - it contains these changes already. Patch > > applies on top of topic/drm-misc, but I'll be pushing out a new > > version of stuff asap. > > Tested refreshed "stuff" branch now, seems to work just fine. > Anything specific to look out for? If no noise in dmesg and not stalls and no issues, then it should be all fine. I've removed the (v1) disclaimer and applied the patch to drm-misc, thanks a lot for testing and reviewing. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Bug 96512] Portal Stories Mel: Player's hands appear black at high shader quality
https://bugs.freedesktop.org/show_bug.cgi?id=96512 --- Comment #1 from Nicolai Hähnle --- Hi Robin, thanks for the report. Could you provide an apitrace where the issue appears? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160614/2958bf10/attachment.html>
[PATCH v2 1/2] drm/crtc: fix connector reference counting mismatch in drm_crtc_helper_set_config
Am Dienstag, den 14.06.2016, 13:57 +0200 schrieb Lucas Stach:
> Am Montag, den 13.06.2016, 20:18 +0200 schrieb Daniel Vetter:
> [...]
> > > > > Only the reference count of connectors that weren't previously bound
> > > > > to
> > > > > an encoder should be incremented after a call to
> > > > > drm_crtc_helper_set_config.
> > > > > And only the reference count of connectors that were previously bound
> > > > > to
> > > > > an encoder and are unbound afterwards should ever be decremented.
> > > > > The reference counts of the temporary copies in the save_connectors
> > > > > should not be touched at all.
> > > > >
> > > > > This patch fixes the above error by only incrementing the reference
> > > > > count
> > > > > of those connectors in the set that are initially not bound to any
> > > > > encoder,
> > > > > and also by restoring the reference count of only those connectors in
> > > > > the
> > > > > set in the failure case.
> > > > >
> > > > > Fixes: 0955c1250e96 ("drm/crtc: take references to connectors used in
> > > > > a modeset. (v2)")
> > > > > Signed-off-by: Philipp Zabel
> > > >
> > > > I'd like to analyze this bug first a bit more (since it seems to be imx
> > > > specific) before review/merging, per our ongoing discussion. The current
> > > > code is definitely wrong, but looking at it I more expected a leak
> > > > (since
> > > > we decrement saved structures, not the real ones), not an explosion.
> > > > -Daniel
> > > >
> > > There is a regression bug open against nouveau, which shows the same
> > > symptoms and is fixed by these patches.
> > >
> > > https://bugzilla.kernel.org/show_bug.cgi?id=119861
> > >
> > > It is not specific to imx-drm, but doesn't explode on desktop system
> > > right away, probably due to the FB emulation holding a reference to all
> > > connectors.
> >
> > Sensible theory. Can you confirm that enabling fbdev emulation on imx
> > works around this?
>
> Yes, we are unable to reproduce the issue if fbdev emulation is enabled.
And contrary to what I expected, the connector reference counts don't
decrease, but increase over time with fbdev emulation enabled.
-->8--
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index bceb31c..62c9299 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -364,6 +364,7 @@ static struct drm_mode_object *_object_find(struct
drm_device *dev,
obj = NULL;
if (obj && obj->free_cb) {
+ DRM_DEBUG("OBJ ID: %d (%d)\n", obj->id,
atomic_read(&obj->refcount.refcount));
if (!kref_get_unless_zero(&obj->refcount))
obj = NULL;
}
--8<--
Initially:
[1.697118] [drm:drm_minor_register]
[1.697136] [drm:drm_minor_register]
[1.698860] [drm:drm_minor_register] new minor registered 128
[1.698878] [drm:drm_minor_register]
[1.700011] [drm:drm_minor_register] new minor registered 0
[1.949582] [drm:drm_platform_init]
[1.949601] [drm:drm_get_platform_dev]
[1.949775] [drm:drm_minor_register]
[1.950938] [drm:drm_minor_register] new minor registered 64
[1.950956] [drm:drm_minor_register]
[1.950972] [drm:drm_minor_register]
[1.951896] [drm:drm_minor_register] new minor registered 1
[2.030970] [drm:drm_sysfs_connector_add] adding "HDMI-A-1" to sysfs
[2.030991] [drm:drm_sysfs_hotplug_event] generating hotplug event
[2.031581] [drm:drm_sysfs_connector_add] adding "LVDS-1" to sysfs
[2.031601] [drm:drm_sysfs_hotplug_event] generating hotplug event
[2.031850] [drm:drm_mode_object_reference] OBJ ID: 34 (1)
[2.031875] [drm:drm_mode_object_reference] OBJ ID: 36 (1)
[2.031901] [drm:drm_helper_probe_single_connector_modes]
[CONNECTOR:34:HDMI-A-1]
[2.079442] [drm:drm_detect_monitor_audio] Monitor has basic audio support
[2.080453] [drm:drm_assign_hdmi_deep_color_info] HDMI-A-1: No deep color
support on this HDMI sink.
[2.080477] [drm:drm_edid_to_eld] ELD monitor SyncMaster
[2.080517] [drm:drm_edid_to_eld] ELD size 36, SAD count 1
[2.080787] [drm:drm_helper_probe_single_connector_modes]
[CONNECTOR:34:HDMI-A-1] probed modes :
[2.080813] [drm:drm_mode_debug_printmodeline] Modeline 38:"1920x1200" 60
154000 1920 1968 2000 2080 1200 1203 1209 1235 0x48 0x9
[2.080837] [drm:drm_mode_debug_printmodeline] Modeline 39:"1920x1080" 60
148500 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5
[...]
[2.081478] [drm:drm_helper_probe_single_connector_modes]
[CONNECTOR:36:LVDS-1]
[2.081497] [drm:drm_helper_probe_single_connector_modes]
[CONNECTOR:36:LVDS-1] status updated from unknown to connected
[2.081535] [drm:drm_helper_probe_single_connector_modes]
[CONNECTOR:36:LVDS-1] probed modes :
[2.081559] [drm:drm_mode_debug_printmodeline] Modeline 63:"1280x800" 60
71100 1280 1281 1439 1440 800 801 822 823 0x40 0x0
[2.081576] [drm:drm_setup_crtcs]
[2.081601] [drm:drm_enable_connectors] c
[PATCH v5] drm/i915/ilk: Don't disable SSC source if it's in use
Thanks to Ville Syrjälä for pointing me towards the cause of this issue.
Unfortunately one of the sideaffects of having the refclk for a DPLL set
to SSC is that as long as it's set to SSC, the GPU will prevent us from
powering down any of the pipes or transcoders using it. A couple of
BIOSes enable SSC in both PCH_DREF_CONTROL and in the DPLL
configurations. This causes issues on the first modeset, since we don't
expect SSC to be left on and as a result, can't successfully power down
the pipes or the transcoders using it. Here's an example from this Dell
OptiPlex 990:
[drm:intel_modeset_init] SSC enabled by BIOS, overriding VBT which says disabled
[drm:intel_modeset_init] 2 display pipes available.
[drm:intel_update_cdclk] Current CD clock rate: 40 kHz
[drm:intel_update_max_cdclk] Max CD clock rate: 40 kHz
[drm:intel_update_max_cdclk] Max dotclock rate: 36 kHz
vgaarb: device changed decodes:
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[drm:intel_crt_reset] crt adpa set to 0xf4
[drm:intel_dp_init_connector] Adding DP connector on port C
[drm:intel_dp_aux_init] registering DPDDC-C bus for card0-DP-1
[drm:ironlake_init_pch_refclk] has_panel 0 has_lvds 0 has_ck505 0
[drm:ironlake_init_pch_refclk] Disabling SSC entirely
⦠later we try committing the first modeset â¦
[drm:intel_dump_pipe_config] [CRTC:26][modeset] config 88041b02e800 for
pipe A
[drm:intel_dump_pipe_config] cpu_transcoder: A
â¦
[drm:intel_dump_pipe_config] dpll_hw_state: dpll: 0xc4016001, dpll_md: 0x0,
fp0: 0x20e08, fp1: 0x30d07
[drm:intel_dump_pipe_config] planes on this crtc
[drm:intel_dump_pipe_config] STANDARD PLANE:23 plane: 0.0 idx: 0 enabled
[drm:intel_dump_pipe_config] FB:42, fb = 800x600 format = 0x34325258
[drm:intel_dump_pipe_config] scaler:0 src (0, 0) 800x600 dst (0, 0) 800x600
[drm:intel_dump_pipe_config] CURSOR PLANE:25 plane: 0.1 idx: 1 disabled,
scaler_id = 0
[drm:intel_dump_pipe_config] STANDARD PLANE:27 plane: 0.1 idx: 2 disabled,
scaler_id = 0
[drm:intel_get_shared_dpll] CRTC:26 allocated PCH DPLL A
[drm:intel_get_shared_dpll] using PCH DPLL A for pipe A
[drm:ilk_audio_codec_disable] Disable audio codec on port C, pipe A
[drm:intel_disable_pipe] disabling pipe A
[ cut here ]
WARNING: CPU: 1 PID: 130 at drivers/gpu/drm/i915/intel_display.c:1146
intel_disable_pipe+0x297/0x2d0 [i915]
pipe_off wait timed out
â¦
---[ end trace 94fc8aa03ae139e8 ]---
[drm:intel_dp_link_down]
[drm:ironlake_crtc_disable [i915]] *ERROR* failed to disable transcoder A
Later modesets succeed since they reset the DPLL's configuration anyway,
but this is enough to get stuck with a big fat warning in dmesg.
A better solution would be to add refcounts for the SSC source, but for
now leaving the source clock on should suffice.
Changes since v4:
- Fix calculation of final for systems with LVDS panels (fixes BUG() on
CI test suite)
Changes since v3:
- Move temp variable into loop
- Move checks for using_ssc_source to after we've figured out has_ck505
- Add using_ssc_source to debug output
Changes since v2:
- Fix debug output for when we disable the CPU source
Changes since v1:
- Leave the SSC source clock on instead of just shutting it off on all
of the DPLL configurations.
Cc: stable at vger.kernel.org
Reviewed-by: Ville Syrjälä
Signed-off-by: Lyude
---
drivers/gpu/drm/i915/intel_display.c | 48 +---
1 file changed, 34 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5c2dbf8..2d7f457 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8228,12 +8228,14 @@ static void ironlake_init_pch_refclk(struct drm_device
*dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_encoder *encoder;
+ int i;
u32 val, final;
bool has_lvds = false;
bool has_cpu_edp = false;
bool has_panel = false;
bool has_ck505 = false;
bool can_ssc = false;
+ bool using_ssc_source = false;
/* We need to take the global config into account */
for_each_intel_encoder(dev, encoder) {
@@ -8260,8 +8262,22 @@ static void ironlake_init_pch_refclk(struct drm_device
*dev)
can_ssc = true;
}
- DRM_DEBUG_KMS("has_panel %d has_lvds %d has_ck505 %d\n",
- has_panel, has_lvds, has_ck505);
+ /* Check if any DPLLs are using the SSC source */
+ for (i = 0; i < dev_priv->num_shared_dpll; i++) {
+ u32 temp = I915_READ(PCH_DPLL(i));
+
+ if (!(temp & DPLL_VCO_ENABLE))
+ continue;
+
+ if ((temp & PLL_REF_INPUT_MASK) ==
+ PLLB_REF_INPUT_SPREADSPECTRUMIN) {
+ using_ssc_source = true;
+ break;
+ }
+ }
+
+ DRM_DEBUG_KMS("has_panel %d has_lvds
[PATCH v3 05/10] drm/rockchip: analogix_dp: add rk3399 eDP support
Yakir, On Tue, Jun 14, 2016 at 4:46 AM, Yakir Yang wrote: > RK3399 and RK3288 shared the same eDP IP controller, only some light > difference with VOP configure and GRF configure. > > Signed-off-by: Yakir Yang > Acked-by: Mark Yao > --- > Changes in v3: > - Give the "rk3399-edp" a separate line for clarity in document (Tomasz, > reviewed at Google Gerrit) > > [https://chromium-review.googlesource.com/#/c/346314/10/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt > at 5] > - Move 'output_type' setting before the return statement (Tomasz, reviewed at > Google Gerrit) > > [https://chromium-review.googlesource.com/#/c/346314/10/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c > at 154] > - Add the acked flag from Mark. > > Changes in v2: > - rebase with drm-next, fix some conflicts > > .../bindings/display/bridge/analogix_dp.txt| 1 + > .../display/rockchip/analogix_dp-rockchip.txt | 3 +- > drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 33 > +- > include/drm/bridge/analogix_dp.h | 1 + > 4 files changed, 36 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt > b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt > index 4f2ba8c..4a0f4f7 100644 > --- a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt > +++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt > @@ -5,6 +5,7 @@ Required properties for dp-controller: > platform specific such as: > * "samsung,exynos5-dp" > * "rockchip,rk3288-dp" > +* "rockchip,rk3399-edp" > -reg: > physical base address of the controller and length > of memory mapped region. > diff --git > a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt > b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt > index e832ff9..726c945 100644 > --- > a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt > +++ > b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt > @@ -2,7 +2,8 @@ Rockchip RK3288 specific extensions to the Analogix Display > Port > > > Required properties: > -- compatible: "rockchip,rk3288-edp"; > +- compatible: "rockchip,rk3288-edp", > + "rockchip,rk3399-edp"; As commented by Tomasz on gerrit, there is a pre-existing typo here. Specifically "rockchip,rk3288-edp" should be "rockchip,rk3288-dp". The typo is pre-existing so I'm not sure you would need to spin this series to fix it, but if you were spinning it anyway it wouldn't hurt to fix. Could also just send out a followon patch to fix this after the series lands... -Doug
[PATCH 1/2] drm: vc4: set permissions for ioctls
Emil Velikov writes: > On 10 June 2016 at 21:08, Eric Anholt wrote: >> Emil Velikov writes: >> >>> On 10 June 2016 at 00:42, Eric Anholt wrote: >>>> Rob Herring writes: >>>> >>>>> Ioctls generally have DRM_AUTH and DRM_RENDER_ALLOW set to restrict them >>>>> to authorized clients and render nodes. Without this, access from render >>>>> nodes fails. >>>> >>>> We've already got a fix to add RENDER_ALLOW submitted in the latest >>>> drm-vc4-fixes. There's no reason to require auth on this >>>> implementation, though. >>>> >>> Not 100% sure but I think you do. At least every other driver does... >>> >>> Why: I'm thinking that without DRM_AUTH one will be able to open the >>> card# node and issue the said IOCTLs even if the client is not >>> authenticated. Which, obviously isn't a huge deal, but doesn't sound >>> right. >>> >>> Then again, my knowledge of vc4 is virtually non-existent, so there >>> might be something special happening here ? >> >> Let's flip this around: What is the problem you see with calling any of >> the ioctls without having gone through the auth dance? I don't believe >> there's any reason to require auth, since you only have access to the >> buffers you create or import. >> >> Basically, auth was created a stopgap solution for "but if anyone had >> access to the DRM device, they could scrape the X frontbuffer!" > > Personally I don't see any serious issues* with keeping DRM_AUTH out > of these. Although one could argue that the lack of it up-to recently > one was using non-auth access to the card node. The latter of which > lead to the DRM_RENDER_ALLOW going unnoticed. > > That aside, I would urge that we have consistency on the topic. > Whether adding DRM_AUTH to the said VC4 ioctls, dropping DRM_AUTH > everywhere (if DRM_RENDER_ALLOW is present on the said ioclt) or > something else. DRM_AUTH is not safe to remove from other drivers, unless they enforce access control to their buffers. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160614/771165da/attachment.sig>
[PATCH v2 1/2] drm/crtc: fix connector reference counting mismatch in drm_crtc_helper_set_config
On Tue, Jun 14, 2016 at 04:51:27PM +0200, Philipp Zabel wrote:
> Am Dienstag, den 14.06.2016, 13:57 +0200 schrieb Lucas Stach:
> > Am Montag, den 13.06.2016, 20:18 +0200 schrieb Daniel Vetter:
> > [...]
> > > > > > Only the reference count of connectors that weren't previously
> > > > > > bound to
> > > > > > an encoder should be incremented after a call to
> > > > > > drm_crtc_helper_set_config.
> > > > > > And only the reference count of connectors that were previously
> > > > > > bound to
> > > > > > an encoder and are unbound afterwards should ever be decremented.
> > > > > > The reference counts of the temporary copies in the save_connectors
> > > > > > should not be touched at all.
> > > > > >
> > > > > > This patch fixes the above error by only incrementing the reference
> > > > > > count
> > > > > > of those connectors in the set that are initially not bound to any
> > > > > > encoder,
> > > > > > and also by restoring the reference count of only those connectors
> > > > > > in the
> > > > > > set in the failure case.
> > > > > >
> > > > > > Fixes: 0955c1250e96 ("drm/crtc: take references to connectors used
> > > > > > in a modeset. (v2)")
> > > > > > Signed-off-by: Philipp Zabel
> > > > >
> > > > > I'd like to analyze this bug first a bit more (since it seems to be
> > > > > imx
> > > > > specific) before review/merging, per our ongoing discussion. The
> > > > > current
> > > > > code is definitely wrong, but looking at it I more expected a leak
> > > > > (since
> > > > > we decrement saved structures, not the real ones), not an explosion.
> > > > > -Daniel
> > > > >
> > > > There is a regression bug open against nouveau, which shows the same
> > > > symptoms and is fixed by these patches.
> > > >
> > > > https://bugzilla.kernel.org/show_bug.cgi?id=119861
> > > >
> > > > It is not specific to imx-drm, but doesn't explode on desktop system
> > > > right away, probably due to the FB emulation holding a reference to all
> > > > connectors.
> > >
> > > Sensible theory. Can you confirm that enabling fbdev emulation on imx
> > > works around this?
> >
> > Yes, we are unable to reproduce the issue if fbdev emulation is enabled.
>
> And contrary to what I expected, the connector reference counts don't
> decrease, but increase over time with fbdev emulation enabled.
That's actually entirely expected, since we only ever decrement it on the
copy, which then gets kfreed. It all makes sense now. Will review the
patches onces more and then Dave can pick them up tomorrow.
-Daniel
>
> -->8--
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index bceb31c..62c9299 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -364,6 +364,7 @@ static struct drm_mode_object *_object_find(struct
> drm_device *dev,
> obj = NULL;
>
> if (obj && obj->free_cb) {
> + DRM_DEBUG("OBJ ID: %d (%d)\n", obj->id,
> atomic_read(&obj->refcount.refcount));
> if (!kref_get_unless_zero(&obj->refcount))
> obj = NULL;
> }
> --8<--
>
> Initially:
>
> [1.697118] [drm:drm_minor_register]
> [1.697136] [drm:drm_minor_register]
> [1.698860] [drm:drm_minor_register] new minor registered 128
> [1.698878] [drm:drm_minor_register]
> [1.700011] [drm:drm_minor_register] new minor registered 0
> [1.949582] [drm:drm_platform_init]
> [1.949601] [drm:drm_get_platform_dev]
> [1.949775] [drm:drm_minor_register]
> [1.950938] [drm:drm_minor_register] new minor registered 64
> [1.950956] [drm:drm_minor_register]
> [1.950972] [drm:drm_minor_register]
> [1.951896] [drm:drm_minor_register] new minor registered 1
> [2.030970] [drm:drm_sysfs_connector_add] adding "HDMI-A-1" to sysfs
> [2.030991] [drm:drm_sysfs_hotplug_event] generating hotplug event
> [2.031581] [drm:drm_sysfs_connector_add] adding "LVDS-1" to sysfs
> [2.031601] [drm:drm_sysfs_hotplug_event] generating hotplug event
> [2.031850] [drm:drm_mode_object_reference] OBJ ID: 34 (1)
> [2.031875] [drm:drm_mode_object_reference] OBJ ID: 36 (1)
> [2.031901] [drm:drm_helper_probe_single_connector_modes]
> [CONNECTOR:34:HDMI-A-1]
> [2.079442] [drm:drm_detect_monitor_audio] Monitor has basic audio support
> [2.080453] [drm:drm_assign_hdmi_deep_color_info] HDMI-A-1: No deep color
> support on this HDMI sink.
> [2.080477] [drm:drm_edid_to_eld] ELD monitor SyncMaster
> [2.080517] [drm:drm_edid_to_eld] ELD size 36, SAD count 1
> [2.080787] [drm:drm_helper_probe_single_connector_modes]
> [CONNECTOR:34:HDMI-A-1] probed modes :
> [2.080813] [drm:drm_mode_debug_printmodeline] Modeline 38:"1920x1200" 60
> 154000 1920 1968 2000 2080 1200 1203 1209 1235 0x48 0x9
> [2.080837] [drm:drm_mode_debug_printmodeline] Modeline 39:"1920x1080" 60
> 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5
> [...]
> [2.081478] [
[PATCH v2 1/2] drm/crtc: fix connector reference counting mismatch in drm_crtc_helper_set_config
On Thu, Jun 02, 2016 at 07:27:51PM +0200, Philipp Zabel wrote:
> Since commit 0955c1250e96 ("drm/crtc: take references to connectors used
> in a modeset. (v2)"), the reference counts of all connectors in the
> drm_mode_set given to drm_crtc_helper_set_config are incremented, and then
> the reference counts of all connectors are decremented on success, but in a
> temporary copy of the connector structure. This leads to the following
> error after the first modeset on imx-drm:
>
> Unable to handle kernel NULL pointer dereference at virtual address
> 0004
> pgd = ad8c4000
> [0004] *pgd=3d9c5831, *pte=, *ppte=
> Internal error: Oops: 817 [#1] PREEMPT SMP ARM
> Modules linked in:
> CPU: 1 PID: 190 Comm: kmsfb-manage Not tainted 4.7.0-rc1+ #657
> Hardware name: Freescale i.MX6 Quad/DualLit: [<80506098>]lr :
> [<80252e94>]psr: 200c0013
> sp : adca7ca8 ip : adca7b90 fp : adca7cd4
> r10: r9 : 0100 r8 : 0200
> r7 : af3c9800 r6 : aded7848 r5 : aded7800 r4 :
> r3 : af3ca058 r2 : 0200 r1 : af3ca058 r0 :
> Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> Control: 10c5387d Table: 3d8c404a DAC: 0051
> Process kmsfb-manage (pid: 190, stack limit = 0xadca6210)
> Stack: (0xadca7ca8 to 0xadca8000)
> 7ca0: 805190e0 aded7800 aded7820 80501a88 8155a290
> af3c9c6c
> 7cc0: adca7ddc 000f adca7cec adca7cd8 80519104 80506044 805190e0
> aded7800
> 7ce0: adca7d04 adca7cf0 80501ac0 805190ec aded7820 aded7814 adca7d24
> adca7d08
> 7d00: 804fdb80 80501a94 aded7800 af3ca010 aded7afc af3c9c60 adca7d94
> adca7d28
> 7d20: 804e3518 804fdb20 af3c9b1c adca7d50 81506f44
> 8093c500
> 7d40: af3c9c6c ae4f2ca8 ae4f2c18 ae637f00
> aded7800
> 7d60: 0001 af3c9800 af23c300 ae77fcc0 ae4f2c18 0001 af3c9800
> 8155a290
> 7d80: af1af700 adca6000 adca7db4 adca7d98 804fea6c 804e2de4 adca7e50
> adb3d940
> 7da0: 0001 af3c9800 adca7e24 adca7db8 8050440c 804fea0c ae77fcc0
> 0003
> 7dc0: adca7e24 adb3d940 af1af700 ae77fcc0 ae77fccc ae4f2c18 8083d44c
> ae77fcc0
> 7de0: ae4002 80d03040 adca7e64 adca7e40 adca7e50 80503f08
> 7e40: 7ebd5630 adca7e50 0068 c06864a2 7ebd5be8 0001
> 0018
> 7e60: 0026 0001 000115bc 05010500
> 05a0059f
> 7e80: 0320 03360321 0337 003c 0040 30383231
> 30303878
> 7ea0: 80173058
> 80172e30
> 7ec0: 80d77d32 4000 adf7d900 0003 7ebd5630 af342bb0
> adfe3b80
> 7ee0: 80272f50 0003 adca6000 adca7f7c adca7f00 802725ec
> 804f52cc
> 7f00: 802809cc 80178450 80280880 80145904 adb3d8c0
> adf7d990
> 7f20: 0003 4000 01614c10 c06864a2 0003 adca6000
>
> 7f40: adca7f6c adca7f50 80280b04 8028088c 000115bc adfe3b81 7ebd5630
> adfe3b80
> 7f60: c06864a2 0003 adca6000 adca7fa4 adca7f80 80272f50
> 80272548
> 7f80: 000115bc 00017050 0001 01614c10 0036 801089e4
> adca7fa8
> 7fa0: 80108840 80272f18 00017050 0001 0003 c06864a2 7ebd5630
> 000115bc
> 7fc0: 00017050 0001 01614c10 0036 0003 0026
> 0018
> 7fe0: 00016f38 7ebd562c b5e9 76ef31e6 400c0030 0003 ff5f37db
> bfe7dd4d
> Backtrace:
> [<80506038>] (drm_connector_cleanup) from [<80519104>]
> (dw_hdmi_connector_destroy+0x24/0x28)
> r10:000f r9:adca7ddc r8:af3c9c6c r7:8155a290 r6:80501a88 r5:aded7820
> r4:aded7800 r3:805190e0
> [<805190e0>] (dw_hdmi_connector_destroy) from [<80501ac0>]
> (drm_connector_free+0x38/0x3c)
> r4:aded7800 nreference) from [<804e3518>]
> (drm_crtc_helper_set_config+0x740/0xbf4)
> r6:af3c9c60 r5:aded7afc r4:af3ca010 r3:aded7800
> [<804e2dd8>] (drm_crtc_helper_set_config) from [<804fea6c>]
> (drm_mode_set_config_internal+0x6c/0xf4)
> r10:adca6000 r9:af1af700 r8:8155a290 r7:af3c9800 r6:0001 r5:ae4f2c18
> r4:ae77fcc0
> [<804fea00>] (drm_mode_set_config_internal) from [<8050440c>]
> (drm_mode_setcrtc+0x504/0x57c)
> r7:af3c9800 r6:0001 r5:adb3d940 r4:adca7e50
> [<80503f08>] (drm_mode_setcrtc) from [<804f5404>] (drm_ioctl+0x144/0x4dc)
> r10:ada2e000 r9:00a2 r8:af3c9800 r7:8155a290 r6:809320b4 r5:0051
> r4:adca7e50
> [<804f52c0>] (drm_ioctl) from [<802725ec>] (do_vfs_ioctl+0xb0/0x9d0)
> r10: r9:adca6000 r8:0003 r7:80272f50 r6:adfe3b80 r5:af342bb0
> r4:7ebd5630
> [<8027253c>] (do_vfs_ioctl) from [<80272f50>] (SyS_ioctl+0x44/0x6c)
> r10: r9:adca6000 r8:0003 r7:c06864a2 r6:adfe3b80 r5:7ebd5630
> r4:adfe3b81
> [<80272f0c>] (SyS_ioctl) from [<80108840>] (ret_fast_syscall+0x0/0x1c)
> r8:801089e4 r7:0036 r6:0
[PATCH 3/3] drm: Mark set/drop master ioctl as unlocked.
On Tue, Jun 14, 2016 at 11:03:34AM +0200, Daniel Vetter wrote:
> Again this is neatly protected by the dev->master_mutex now. There is
> a driver callback both for set and drop, but it's only used by vmwgfx.
> And vmwgfx has it's own solid locking for shared resources (besides
> dev->master_mutex), hence is all safe. Let's drop another place where
> the drm legacy bkl is used.
>
> Signed-off-by: Daniel Vetter
Note that patches 2&3 here require my patches to first switch over to
master_mutex, and I haven't sent them out yet. Oops. Will integrate into
that series.
-Daniel
> ---
> drivers/gpu/drm/drm_ioctl.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 288b047b2de5..08c75630f1dc 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -487,8 +487,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
> DRM_IOCTL_DEF(DRM_IOCTL_SET_SAREA_CTX, drm_legacy_setsareactx,
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
> DRM_IOCTL_DEF(DRM_IOCTL_GET_SAREA_CTX, drm_legacy_getsareactx,
> DRM_AUTH),
>
> - DRM_IOCTL_DEF(DRM_IOCTL_SET_MASTER, drm_setmaster_ioctl, DRM_ROOT_ONLY),
> - DRM_IOCTL_DEF(DRM_IOCTL_DROP_MASTER, drm_dropmaster_ioctl,
> DRM_ROOT_ONLY),
> + DRM_IOCTL_DEF(DRM_IOCTL_SET_MASTER, drm_setmaster_ioctl,
> DRM_UNLOCKED|DRM_ROOT_ONLY),
> + DRM_IOCTL_DEF(DRM_IOCTL_DROP_MASTER, drm_dropmaster_ioctl,
> DRM_UNLOCKED|DRM_ROOT_ONLY),
>
> DRM_IOCTL_DEF(DRM_IOCTL_ADD_CTX, drm_legacy_addctx,
> DRM_AUTH|DRM_ROOT_ONLY),
> DRM_IOCTL_DEF(DRM_IOCTL_RM_CTX, drm_legacy_rmctx,
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
> --
> 2.8.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 1/5] drm/tilcdc: Restore old dmps state in pm_resume()
On Tue, Jun 14, 2016 at 02:48:44PM +0300, Tomi Valkeinen wrote:
> On 14/06/16 14:45, Jyri Sarha wrote:
> > Restore old dpms state in pm_resume(). The dpms is turned off in
> > pm_suspend() and it should be restored to its original state in
> > pm_resume().
> >
> > Fixes commit 614b3cfeb8d2 ("drm/tilcdc: disable the lcd controller/dma
> > engine when suspend invoked")
>
> "dmps" in the subject.
>
> It would be good to mention what the problem seen is, what does this fix.
With atomic you get this all for free, using
drm_atomic_helper_suspend/resume ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 3/5] drm/tilcdc: Move waiting of LCDC_FRAME_DONE IRQ into stop()
On Tue, Jun 14, 2016 at 02:45:04PM +0300, Jyri Sarha wrote:
> Move wait queue waiting of LCDC_FRAME_DONE IRQ from tilcdc_crtc_dpms()
> into stop() function.
>
> Signed-off-by: Jyri Sarha
You should also call drm_crtc_vblank_on/off, to make sure any vblank waits
and anything else gets properly cleaned up.
-Daniel
> ---
> drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 31 ---
> 1 file changed, 16 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> index 1343717..cfa1a4e 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> @@ -113,9 +113,25 @@ static void start(struct drm_crtc *crtc)
>
> static void stop(struct drm_crtc *crtc)
> {
> + struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
> struct drm_device *dev = crtc->dev;
> + struct tilcdc_drm_private *priv = dev->dev_private;
>
> + tilcdc_crtc->frame_done = false;
> tilcdc_clear(dev, LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
> +
> + /*
> + * if necessary wait for framedone irq which will still come
> + * before putting things to sleep..
> + */
> + if (priv->rev == 2) {
> + int ret = wait_event_timeout(tilcdc_crtc->frame_done_wq,
> + tilcdc_crtc->frame_done,
> + msecs_to_jiffies(50));
> + if (ret == 0)
> + dev_err(dev->dev, "%s: timeout waiting for framedone\n",
> + __func__);
> + }
> }
>
> static void tilcdc_crtc_destroy(struct drm_crtc *crtc)
> @@ -212,22 +228,7 @@ void tilcdc_crtc_dpms(struct drm_crtc *crtc, int mode)
> pm_runtime_get_sync(dev->dev);
> start(crtc);
> } else {
> - tilcdc_crtc->frame_done = false;
> stop(crtc);
> -
> - /*
> - * if necessary wait for framedone irq which will still come
> - * before putting things to sleep..
> - */
> - if (priv->rev == 2) {
> - int ret = wait_event_timeout(
> - tilcdc_crtc->frame_done_wq,
> - tilcdc_crtc->frame_done,
> - msecs_to_jiffies(50));
> - if (ret == 0)
> - dev_err(dev->dev, "timeout waiting for
> framedone\n");
> - }
> -
> pm_runtime_put_sync(dev->dev);
>
> if (tilcdc_crtc->next_fb) {
> --
> 1.9.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH v3 07/10] drm/bridge: analogix_dp: passing the connector as an argument in .get_modes()
On Tue, Jun 14, 2016 at 07:46:29PM +0800, Yakir Yang wrote:
> It's better to pass the connector to platform driver in .get_modes()
> callback, just like what the .get_modes() helper function designed.
>
> Signed-off-by: Yakir Yang
> ---
> Changes in v3:
> - Avoid to change any internal driver state in .mode_valid interface.
> (Tomasz, reviewed at Google Gerrit)
>
> [https://chromium-review.googlesource.com/#/c/346318/10/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> at 113]
>
> Changes in v2: None
Needs cc: Archit Tajena as drm_bridge maintainer (or at least inofficial
one), plus ack imo.
-Daniel
>
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 +-
> drivers/gpu/drm/exynos/exynos_dp.c | 4 ++--
> include/drm/bridge/analogix_dp.h | 3 ++-
> 3 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 4a1b3b8..1a890fa 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -938,7 +938,7 @@ int analogix_dp_get_modes(struct drm_connector *connector)
> num_modes += drm_panel_get_modes(dp->plat_data->panel);
>
> if (dp->plat_data->get_modes)
> - num_modes += dp->plat_data->get_modes(dp->plat_data);
> + num_modes += dp->plat_data->get_modes(dp->plat_data, connector);
>
> return num_modes;
> }
> diff --git a/drivers/gpu/drm/exynos/exynos_dp.c
> b/drivers/gpu/drm/exynos/exynos_dp.c
> index 468498e..8a555ed 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp.c
> @@ -67,10 +67,10 @@ static int exynos_dp_poweroff(struct
> analogix_dp_plat_data *plat_data)
> return exynos_dp_crtc_clock_enable(plat_data, false);
> }
>
> -static int exynos_dp_get_modes(struct analogix_dp_plat_data *plat_data)
> +static int exynos_dp_get_modes(struct analogix_dp_plat_data *plat_data,
> +struct drm_connector *connector)
> {
> struct exynos_dp_device *dp = to_dp(plat_data);
> - struct drm_connector *connector = &dp->connector;
> struct drm_display_mode *mode;
> int num_modes = 0;
>
> diff --git a/include/drm/bridge/analogix_dp.h
> b/include/drm/bridge/analogix_dp.h
> index 82b8135..181db09 100644
> --- a/include/drm/bridge/analogix_dp.h
> +++ b/include/drm/bridge/analogix_dp.h
> @@ -34,7 +34,8 @@ struct analogix_dp_plat_data {
> int (*power_off)(struct analogix_dp_plat_data *);
> int (*attach)(struct analogix_dp_plat_data *, struct drm_bridge *,
> struct drm_connector *);
> - int (*get_modes)(struct analogix_dp_plat_data *);
> + int (*get_modes)(struct analogix_dp_plat_data *,
> + struct drm_connector *);
> };
>
> int analogix_dp_resume(struct device *dev);
> --
> 1.9.1
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH v3 07/10] drm/bridge: analogix_dp: passing the connector as an argument in .get_modes()
On Tue, Jun 14, 2016 at 07:46:29PM +0800, Yakir Yang wrote:
> It's better to pass the connector to platform driver in .get_modes()
> callback, just like what the .get_modes() helper function designed.
>
> Signed-off-by: Yakir Yang
Also please drop the analogix prefix from the subject, this is for all
drm_bridge drivers.
-Daniel
> ---
> Changes in v3:
> - Avoid to change any internal driver state in .mode_valid interface.
> (Tomasz, reviewed at Google Gerrit)
>
> [https://chromium-review.googlesource.com/#/c/346318/10/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> at 113]
>
> Changes in v2: None
>
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 +-
> drivers/gpu/drm/exynos/exynos_dp.c | 4 ++--
> include/drm/bridge/analogix_dp.h | 3 ++-
> 3 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 4a1b3b8..1a890fa 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -938,7 +938,7 @@ int analogix_dp_get_modes(struct drm_connector *connector)
> num_modes += drm_panel_get_modes(dp->plat_data->panel);
>
> if (dp->plat_data->get_modes)
> - num_modes += dp->plat_data->get_modes(dp->plat_data);
> + num_modes += dp->plat_data->get_modes(dp->plat_data, connector);
>
> return num_modes;
> }
> diff --git a/drivers/gpu/drm/exynos/exynos_dp.c
> b/drivers/gpu/drm/exynos/exynos_dp.c
> index 468498e..8a555ed 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp.c
> @@ -67,10 +67,10 @@ static int exynos_dp_poweroff(struct
> analogix_dp_plat_data *plat_data)
> return exynos_dp_crtc_clock_enable(plat_data, false);
> }
>
> -static int exynos_dp_get_modes(struct analogix_dp_plat_data *plat_data)
> +static int exynos_dp_get_modes(struct analogix_dp_plat_data *plat_data,
> +struct drm_connector *connector)
> {
> struct exynos_dp_device *dp = to_dp(plat_data);
> - struct drm_connector *connector = &dp->connector;
> struct drm_display_mode *mode;
> int num_modes = 0;
>
> diff --git a/include/drm/bridge/analogix_dp.h
> b/include/drm/bridge/analogix_dp.h
> index 82b8135..181db09 100644
> --- a/include/drm/bridge/analogix_dp.h
> +++ b/include/drm/bridge/analogix_dp.h
> @@ -34,7 +34,8 @@ struct analogix_dp_plat_data {
> int (*power_off)(struct analogix_dp_plat_data *);
> int (*attach)(struct analogix_dp_plat_data *, struct drm_bridge *,
> struct drm_connector *);
> - int (*get_modes)(struct analogix_dp_plat_data *);
> + int (*get_modes)(struct analogix_dp_plat_data *,
> + struct drm_connector *);
> };
>
> int analogix_dp_resume(struct device *dev);
> --
> 1.9.1
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH v3 07/10] drm/bridge: analogix_dp: passing the connector as an argument in .get_modes()
On Tue, Jun 14, 2016 at 06:26:56PM +0200, Daniel Vetter wrote:
> On Tue, Jun 14, 2016 at 07:46:29PM +0800, Yakir Yang wrote:
> > It's better to pass the connector to platform driver in .get_modes()
> > callback, just like what the .get_modes() helper function designed.
> >
> > Signed-off-by: Yakir Yang
>
> Also please drop the analogix prefix from the subject, this is for all
> drm_bridge drivers.
Ok, strike all my comments, I was blind and didn't realize that this was a
private interface for only rockchip/exynos.
-Daniel
> -Daniel
>
> > ---
> > Changes in v3:
> > - Avoid to change any internal driver state in .mode_valid interface.
> > (Tomasz, reviewed at Google Gerrit)
> >
> > [https://chromium-review.googlesource.com/#/c/346318/10/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> > at 113]
> >
> > Changes in v2: None
> >
> > drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 +-
> > drivers/gpu/drm/exynos/exynos_dp.c | 4 ++--
> > include/drm/bridge/analogix_dp.h | 3 ++-
> > 3 files changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > index 4a1b3b8..1a890fa 100644
> > --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > @@ -938,7 +938,7 @@ int analogix_dp_get_modes(struct drm_connector
> > *connector)
> > num_modes += drm_panel_get_modes(dp->plat_data->panel);
> >
> > if (dp->plat_data->get_modes)
> > - num_modes += dp->plat_data->get_modes(dp->plat_data);
> > + num_modes += dp->plat_data->get_modes(dp->plat_data, connector);
> >
> > return num_modes;
> > }
> > diff --git a/drivers/gpu/drm/exynos/exynos_dp.c
> > b/drivers/gpu/drm/exynos/exynos_dp.c
> > index 468498e..8a555ed 100644
> > --- a/drivers/gpu/drm/exynos/exynos_dp.c
> > +++ b/drivers/gpu/drm/exynos/exynos_dp.c
> > @@ -67,10 +67,10 @@ static int exynos_dp_poweroff(struct
> > analogix_dp_plat_data *plat_data)
> > return exynos_dp_crtc_clock_enable(plat_data, false);
> > }
> >
> > -static int exynos_dp_get_modes(struct analogix_dp_plat_data *plat_data)
> > +static int exynos_dp_get_modes(struct analogix_dp_plat_data *plat_data,
> > + struct drm_connector *connector)
> > {
> > struct exynos_dp_device *dp = to_dp(plat_data);
> > - struct drm_connector *connector = &dp->connector;
> > struct drm_display_mode *mode;
> > int num_modes = 0;
> >
> > diff --git a/include/drm/bridge/analogix_dp.h
> > b/include/drm/bridge/analogix_dp.h
> > index 82b8135..181db09 100644
> > --- a/include/drm/bridge/analogix_dp.h
> > +++ b/include/drm/bridge/analogix_dp.h
> > @@ -34,7 +34,8 @@ struct analogix_dp_plat_data {
> > int (*power_off)(struct analogix_dp_plat_data *);
> > int (*attach)(struct analogix_dp_plat_data *, struct drm_bridge *,
> > struct drm_connector *);
> > - int (*get_modes)(struct analogix_dp_plat_data *);
> > + int (*get_modes)(struct analogix_dp_plat_data *,
> > +struct drm_connector *);
> > };
> >
> > int analogix_dp_resume(struct device *dev);
> > --
> > 1.9.1
> >
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH v2 1/2] drm/crtc: fix connector reference counting mismatch in drm_crtc_helper_set_config
On Tue, Jun 14, 2016 at 06:08:35PM +0200, Daniel Vetter wrote:
> On Thu, Jun 02, 2016 at 07:27:51PM +0200, Philipp Zabel wrote:
> > Since commit 0955c1250e96 ("drm/crtc: take references to connectors used
> > in a modeset. (v2)"), the reference counts of all connectors in the
> > drm_mode_set given to drm_crtc_helper_set_config are incremented, and then
> > the reference counts of all connectors are decremented on success, but in a
> > temporary copy of the connector structure. This leads to the following
> > error after the first modeset on imx-drm:
> >
> > Unable to handle kernel NULL pointer dereference at virtual address
> > 0004
> > pgd = ad8c4000
> > [0004] *pgd=3d9c5831, *pte=, *ppte=
> > Internal error: Oops: 817 [#1] PREEMPT SMP ARM
> > Modules linked in:
> > CPU: 1 PID: 190 Comm: kmsfb-manage Not tainted 4.7.0-rc1+ #657
> > Hardware name: Freescale i.MX6 Quad/DualLit: [<80506098>]lr :
> > [<80252e94>]psr: 200c0013
> > sp : adca7ca8 ip : adca7b90 fp : adca7cd4
> > r10: r9 : 0100 r8 : 0200
> > r7 : af3c9800 r6 : aded7848 r5 : aded7800 r4 :
> > r3 : af3ca058 r2 : 0200 r1 : af3ca058 r0 :
> > Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> > Control: 10c5387d Table: 3d8c404a DAC: 0051
> > Process kmsfb-manage (pid: 190, stack limit = 0xadca6210)
> > Stack: (0xadca7ca8 to 0xadca8000)
> > 7ca0: 805190e0 aded7800 aded7820 80501a88 8155a290
> > af3c9c6c
> > 7cc0: adca7ddc 000f adca7cec adca7cd8 80519104 80506044 805190e0
> > aded7800
> > 7ce0: adca7d04 adca7cf0 80501ac0 805190ec aded7820 aded7814 adca7d24
> > adca7d08
> > 7d00: 804fdb80 80501a94 aded7800 af3ca010 aded7afc af3c9c60 adca7d94
> > adca7d28
> > 7d20: 804e3518 804fdb20 af3c9b1c adca7d50 81506f44
> > 8093c500
> > 7d40: af3c9c6c ae4f2ca8 ae4f2c18 ae637f00
> > aded7800
> > 7d60: 0001 af3c9800 af23c300 ae77fcc0 ae4f2c18 0001 af3c9800
> > 8155a290
> > 7d80: af1af700 adca6000 adca7db4 adca7d98 804fea6c 804e2de4 adca7e50
> > adb3d940
> > 7da0: 0001 af3c9800 adca7e24 adca7db8 8050440c 804fea0c ae77fcc0
> > 0003
> > 7dc0: adca7e24 adb3d940 af1af700 ae77fcc0 ae77fccc ae4f2c18 8083d44c
> > ae77fcc0
> > 7de0: ae4002 80d03040 adca7e64 adca7e40 adca7e50 80503f08
> > 7e40: 7ebd5630 adca7e50 0068 c06864a2 7ebd5be8 0001
> > 0018
> > 7e60: 0026 0001 000115bc 05010500
> > 05a0059f
> > 7e80: 0320 03360321 0337 003c 0040 30383231
> > 30303878
> > 7ea0: 80173058
> > 80172e30
> > 7ec0: 80d77d32 4000 adf7d900 0003 7ebd5630 af342bb0
> > adfe3b80
> > 7ee0: 80272f50 0003 adca6000 adca7f7c adca7f00 802725ec
> > 804f52cc
> > 7f00: 802809cc 80178450 80280880 80145904 adb3d8c0
> > adf7d990
> > 7f20: 0003 4000 01614c10 c06864a2 0003 adca6000
> >
> > 7f40: adca7f6c adca7f50 80280b04 8028088c 000115bc adfe3b81 7ebd5630
> > adfe3b80
> > 7f60: c06864a2 0003 adca6000 adca7fa4 adca7f80 80272f50
> > 80272548
> > 7f80: 000115bc 00017050 0001 01614c10 0036 801089e4
> > adca7fa8
> > 7fa0: 80108840 80272f18 00017050 0001 0003 c06864a2 7ebd5630
> > 000115bc
> > 7fc0: 00017050 0001 01614c10 0036 0003 0026
> > 0018
> > 7fe0: 00016f38 7ebd562c b5e9 76ef31e6 400c0030 0003 ff5f37db
> > bfe7dd4d
> > Backtrace:
> > [<80506038>] (drm_connector_cleanup) from [<80519104>]
> > (dw_hdmi_connector_destroy+0x24/0x28)
> > r10:000f r9:adca7ddc r8:af3c9c6c r7:8155a290 r6:80501a88
> > r5:aded7820
> > r4:aded7800 r3:805190e0
> > [<805190e0>] (dw_hdmi_connector_destroy) from [<80501ac0>]
> > (drm_connector_free+0x38/0x3c)
> > r4:aded7800 nreference) from [<804e3518>]
> > (drm_crtc_helper_set_config+0x740/0xbf4)
> > r6:af3c9c60 r5:aded7afc r4:af3ca010 r3:aded7800
> > [<804e2dd8>] (drm_crtc_helper_set_config) from [<804fea6c>]
> > (drm_mode_set_config_internal+0x6c/0xf4)
> > r10:adca6000 r9:af1af700 r8:8155a290 r7:af3c9800 r6:0001
> > r5:ae4f2c18
> > r4:ae77fcc0
> > [<804fea00>] (drm_mode_set_config_internal) from [<8050440c>]
> > (drm_mode_setcrtc+0x504/0x57c)
> > r7:af3c9800 r6:0001 r5:adb3d940 r4:adca7e50
> > [<80503f08>] (drm_mode_setcrtc) from [<804f5404>]
> > (drm_ioctl+0x144/0x4dc)
> > r10:ada2e000 r9:00a2 r8:af3c9800 r7:8155a290 r6:809320b4
> > r5:0051
> > r4:adca7e50
> > [<804f52c0>] (drm_ioctl) from [<802725ec>] (do_vfs_ioctl+0xb0/0x9d0)
> > r10: r9:adca6000 r8:0003 r7:80272f50 r6:adfe3b80
> > r5:af342bb0
> > r4:7ebd5630
> >
[PATCH] drm/atomic-helpers: Stall on the right commit
stall_checks carefully picked out the right commit to stall on, then
promptly used the wrong variable. Due to the break in the next loop
iteration this could be the 3rd commit, or if the list only has 2
entries commit would now point into the struct drm_crtc itself, at
some offset. Hilarity eventually ensues.
For added safety, also break right away instead of iterating once
more, but the real fix is waiting on stall_commit instead of commit.
Reported-and-tested-by: Liviu Dudau
Cc: Liviu Dudau
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 6a13df8691d4..716aa535eb98 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1324,8 +1324,8 @@ static int stall_checks(struct drm_crtc *crtc, bool
nonblock)
} else if (i == 1) {
stall_commit = commit;
drm_crtc_commit_get(stall_commit);
- } else
break;
+ }
i++;
}
@@ -1337,7 +1337,7 @@ static int stall_checks(struct drm_crtc *crtc, bool
nonblock)
/* We don't want to let commits get ahead of cleanup work too much,
* stalling on 2nd previous commit means triple-buffer won't ever stall.
*/
- ret = wait_for_completion_interruptible_timeout(&commit->cleanup_done,
+ ret =
wait_for_completion_interruptible_timeout(&stall_commit->cleanup_done,
10*HZ);
if (ret == 0)
DRM_ERROR("[CRTC:%d:%s] cleanup_done timed out\n",
--
2.8.1
[PATCH 00/14] Cruft removal around drm_master
Hi all, These are the final bits of my dev->struct_mutex crusade, taking care of a few things related to drm_master. Since I just couldnt' grok this dense web of legacy dungeons, also includes some cleanups. On top of that also patches to mark auth and master ioctls as DRM_UNLOCKED, which means the other drm subsystem BKL is also much reduced (and only still needed to paper over the midlayer fail for drivers that use the ->load callback). Feedbacks, review and testing highly welcome. Cheers, Daniel Daniel Vetter (14): drm: Nuke legacy maps debugfs files drm: Hide hw.lock cleanup in filp->release better drm: Link directly from drm_master to drm_device drm: Move master functions into drm_auth.c drm: Extract drm_master_open drm: Extract drm_master_relase drm: Only do the hw.lock cleanup in master_relase for !MODESET drm: Move authmagic cleanup into drm_master_release drm: Protect authmagic with master_mutex drm: Mark authmagic ioctls as unlocked drm: Mark set/drop master ioctl as unlocked. drm: Move master pointer from drm_minor to drm_device drm: Clean up drm_crtc.h drm: Use dev->name as fallback for dev->unique drivers/gpu/drm/drm_auth.c | 231 +- drivers/gpu/drm/drm_bufs.c | 8 +- drivers/gpu/drm/drm_crtc.c | 7 ++ drivers/gpu/drm/drm_crtc_internal.h | 86 - drivers/gpu/drm/drm_debugfs.c | 3 - drivers/gpu/drm/drm_drv.c | 119 +- drivers/gpu/drm/drm_fb_helper.c | 2 +- drivers/gpu/drm/drm_fops.c | 125 ++- drivers/gpu/drm/drm_info.c | 97 ++- drivers/gpu/drm/drm_internal.h | 18 +-- drivers/gpu/drm/drm_ioctl.c | 16 +-- drivers/gpu/drm/drm_legacy.h| 8 +- drivers/gpu/drm/drm_lock.c | 238 ++-- drivers/gpu/drm/drm_vm.c| 54 drivers/gpu/drm/sis/sis_mm.c| 2 +- drivers/gpu/drm/via/via_mm.c| 2 +- include/drm/drmP.h | 17 +-- include/drm/drm_crtc.h | 188 +--- 18 files changed, 547 insertions(+), 674 deletions(-) -- 2.8.1
[PATCH 01/14] drm: Nuke legacy maps debugfs files
GEM stopped using those a while ago, and no one should ever
need to use them again to debug legacy horror show drivers.
Nuke it all. Aside: It would kinda be nice if we'd have some
generic debugfs dumps for at least kms ...
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_debugfs.c | 3 --
drivers/gpu/drm/drm_info.c | 89 --
drivers/gpu/drm/drm_internal.h | 5 ---
drivers/gpu/drm/drm_vm.c | 54 -
4 files changed, 151 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 3bcf8e6a85b3..fa10cef2ba37 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -46,11 +46,8 @@
static const struct drm_info_list drm_debugfs_list[] = {
{"name", drm_name_info, 0},
- {"vm", drm_vm_info, 0},
{"clients", drm_clients_info, 0},
- {"bufs", drm_bufs_info, 0},
{"gem_names", drm_gem_name_info, DRIVER_GEM},
- {"vma", drm_vma_info, 0},
};
#define DRM_DEBUGFS_ENTRIES ARRAY_SIZE(drm_debugfs_list)
diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm/drm_info.c
index 5d469b2f26f4..0090d5987801 100644
--- a/drivers/gpu/drm/drm_info.c
+++ b/drivers/gpu/drm/drm_info.c
@@ -66,94 +66,6 @@ int drm_name_info(struct seq_file *m, void *data)
}
/**
- * Called when "/proc/dri/.../vm" is read.
- *
- * Prints information about all mappings in drm_device::maplist.
- */
-int drm_vm_info(struct seq_file *m, void *data)
-{
- struct drm_info_node *node = (struct drm_info_node *) m->private;
- struct drm_device *dev = node->minor->dev;
- struct drm_local_map *map;
- struct drm_map_list *r_list;
-
- /* Hardcoded from _DRM_FRAME_BUFFER,
- _DRM_REGISTERS, _DRM_SHM, _DRM_AGP, and
- _DRM_SCATTER_GATHER and _DRM_CONSISTENT */
- const char *types[] = { "FB", "REG", "SHM", "AGP", "SG", "PCI" };
- const char *type;
- int i;
-
- mutex_lock(&dev->struct_mutex);
- seq_printf(m, "slot offset size type flagsaddress
mtrr\n\n");
- i = 0;
- list_for_each_entry(r_list, &dev->maplist, head) {
- map = r_list->map;
- if (!map)
- continue;
- if (map->type < 0 || map->type > 5)
- type = "??";
- else
- type = types[map->type];
-
- seq_printf(m, "%4d 0x%016llx 0x%08lx %4.4s 0x%02x 0x%08lx ",
- i,
- (unsigned long long)map->offset,
- map->size, type, map->flags,
- (unsigned long) r_list->user_token);
- if (map->mtrr < 0)
- seq_printf(m, "none\n");
- else
- seq_printf(m, "%4d\n", map->mtrr);
- i++;
- }
- mutex_unlock(&dev->struct_mutex);
- return 0;
-}
-
-/**
- * Called when "/proc/dri/.../bufs" is read.
- */
-int drm_bufs_info(struct seq_file *m, void *data)
-{
- struct drm_info_node *node = (struct drm_info_node *) m->private;
- struct drm_device *dev = node->minor->dev;
- struct drm_device_dma *dma;
- int i, seg_pages;
-
- mutex_lock(&dev->struct_mutex);
- dma = dev->dma;
- if (!dma) {
- mutex_unlock(&dev->struct_mutex);
- return 0;
- }
-
- seq_printf(m, " o size count free segs pageskB\n\n");
- for (i = 0; i <= DRM_MAX_ORDER; i++) {
- if (dma->bufs[i].buf_count) {
- seg_pages = dma->bufs[i].seg_count * (1 <<
dma->bufs[i].page_order);
- seq_printf(m, "%2d %8d %5d %5d %5d %5d %5ld\n",
- i,
- dma->bufs[i].buf_size,
- dma->bufs[i].buf_count,
- 0,
- dma->bufs[i].seg_count,
- seg_pages,
- seg_pages * PAGE_SIZE / 1024);
- }
- }
- seq_printf(m, "\n");
- for (i = 0; i < dma->buf_count; i++) {
- if (i && !(i % 32))
- seq_printf(m, "\n");
- seq_printf(m, " %d", dma->buflist[i]->list);
- }
- seq_printf(m, "\n");
- mutex_unlock(&dev->struct_mutex);
- return 0;
-}
-
-/**
* Called when "/proc/dri/.../clients" is read.
*
*/
@@ -194,7 +106,6 @@ int drm_clients_info(struct seq_file *m, void *data)
return 0;
}
-
static int drm_gem_one_name_info(int id, void *ptr, void *data)
{
struct drm_gem_object *obj = ptr;
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 902cf6a15212..56a9b1cf99d7 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -35,9 +35,6 @@ int drm_pci_set_unique(stru
[PATCH 02/14] drm: Hide hw.lock cleanup in filp->release better
A few things:
- Rename the cleanup function from drm_master_release to
drm_legacy_lock_release. It doesn't relase any master stuff, but
just the legacy hw lock.
- Hide it in drm_lock.c, which allows us to make a few more functions
static in there. To avoid forward decl we need to shuffle the code a
bit though.
- Push the check for ->master into the function itself.
- Only call this for !DRIVER_MODESET.
End result: Another place that takes struct_mutex gone for good for
modern drivers.
v2: Remove leftover comment.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fops.c | 17 +---
drivers/gpu/drm/drm_legacy.h | 8 +-
drivers/gpu/drm/drm_lock.c | 238 ++-
3 files changed, 126 insertions(+), 137 deletions(-)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index a27bc7cda975..2fd4f42b907a 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -338,18 +338,6 @@ out_prime_destroy:
return ret;
}
-static void drm_master_release(struct drm_device *dev, struct file *filp)
-{
- struct drm_file *file_priv = filp->private_data;
-
- if (drm_legacy_i_have_hw_lock(dev, file_priv)) {
- DRM_DEBUG("File %p released, freeing lock for context %d\n",
- filp,
_DRM_LOCKING_CONTEXT(file_priv->master->lock.hw_lock->lock));
- drm_legacy_lock_free(&file_priv->master->lock,
-
_DRM_LOCKING_CONTEXT(file_priv->master->lock.hw_lock->lock));
- }
-}
-
static void drm_events_release(struct drm_file *file_priv)
{
struct drm_device *dev = file_priv->minor->dev;
@@ -468,9 +456,8 @@ int drm_release(struct inode *inode, struct file *filp)
(long)old_encode_dev(file_priv->minor->kdev->devt),
dev->open_count);
- /* if the master has gone away we can't do anything with the lock */
- if (file_priv->minor->master)
- drm_master_release(dev, filp);
+ if (!drm_core_check_feature(dev, DRIVER_MODESET))
+ drm_legacy_lock_release(dev, filp);
if (drm_core_check_feature(dev, DRIVER_HAVE_DMA))
drm_legacy_reclaim_buffers(dev, file_priv);
diff --git a/drivers/gpu/drm/drm_legacy.h b/drivers/gpu/drm/drm_legacy.h
index d3b6ee357a2b..c6f422e879dd 100644
--- a/drivers/gpu/drm/drm_legacy.h
+++ b/drivers/gpu/drm/drm_legacy.h
@@ -88,14 +88,10 @@ struct drm_agp_mem {
struct list_head head;
};
-/*
- * Generic Userspace Locking-API
- */
-
-int drm_legacy_i_have_hw_lock(struct drm_device *d, struct drm_file *f);
+/* drm_lock.c */
int drm_legacy_lock(struct drm_device *d, void *v, struct drm_file *f);
int drm_legacy_unlock(struct drm_device *d, void *v, struct drm_file *f);
-int drm_legacy_lock_free(struct drm_lock_data *lock, unsigned int ctx);
+void drm_legacy_lock_release(struct drm_device *dev, struct file *filp);
/* DMA support */
int drm_legacy_dma_setup(struct drm_device *dev);
diff --git a/drivers/gpu/drm/drm_lock.c b/drivers/gpu/drm/drm_lock.c
index daa2ff12101b..0fb8f9e73486 100644
--- a/drivers/gpu/drm/drm_lock.c
+++ b/drivers/gpu/drm/drm_lock.c
@@ -41,6 +41,110 @@
static int drm_lock_take(struct drm_lock_data *lock_data, unsigned int
context);
/**
+ * Take the heavyweight lock.
+ *
+ * \param lock lock pointer.
+ * \param context locking context.
+ * \return one if the lock is held, or zero otherwise.
+ *
+ * Attempt to mark the lock as held by the given context, via the \p cmpxchg
instruction.
+ */
+static
+int drm_lock_take(struct drm_lock_data *lock_data,
+ unsigned int context)
+{
+ unsigned int old, new, prev;
+ volatile unsigned int *lock = &lock_data->hw_lock->lock;
+
+ spin_lock_bh(&lock_data->spinlock);
+ do {
+ old = *lock;
+ if (old & _DRM_LOCK_HELD)
+ new = old | _DRM_LOCK_CONT;
+ else {
+ new = context | _DRM_LOCK_HELD |
+ ((lock_data->user_waiters +
lock_data->kernel_waiters > 1) ?
+_DRM_LOCK_CONT : 0);
+ }
+ prev = cmpxchg(lock, old, new);
+ } while (prev != old);
+ spin_unlock_bh(&lock_data->spinlock);
+
+ if (_DRM_LOCKING_CONTEXT(old) == context) {
+ if (old & _DRM_LOCK_HELD) {
+ if (context != DRM_KERNEL_CONTEXT) {
+ DRM_ERROR("%d holds heavyweight lock\n",
+ context);
+ }
+ return 0;
+ }
+ }
+
+ if ((_DRM_LOCKING_CONTEXT(new)) == context && (new & _DRM_LOCK_HELD)) {
+ /* Have lock */
+ return 1;
+ }
+ return 0;
+}
+
+/**
+ * This takes a lock forcibly and hands it to context. Should ONLY be used
+ * inside *_unlock to give lock to kernel before calli
[PATCH 03/14] drm: Link directly from drm_master to drm_device
Master-based auth only exists for the legacy/primary drm_minor, hence
there can only be one per device. The goal here is to untangle the
epic dereference games of minor->master and master->minor which is
just massively confusing.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 6 +++---
drivers/gpu/drm/drm_fops.c | 2 +-
drivers/gpu/drm/drm_internal.h | 2 +-
include/drm/drmP.h | 7 +--
4 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 8b2582aeaab6..3c01a16bbb77 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -93,7 +93,7 @@ void drm_ut_debug_printk(const char *function_name, const
char *format, ...)
}
EXPORT_SYMBOL(drm_ut_debug_printk);
-struct drm_master *drm_master_create(struct drm_minor *minor)
+struct drm_master *drm_master_create(struct drm_device *dev)
{
struct drm_master *master;
@@ -105,7 +105,7 @@ struct drm_master *drm_master_create(struct drm_minor
*minor)
spin_lock_init(&master->lock.spinlock);
init_waitqueue_head(&master->lock.lock_queue);
idr_init(&master->magic_map);
- master->minor = minor;
+ master->dev = dev;
return master;
}
@@ -120,7 +120,7 @@ EXPORT_SYMBOL(drm_master_get);
static void drm_master_destroy(struct kref *kref)
{
struct drm_master *master = container_of(kref, struct drm_master,
refcount);
- struct drm_device *dev = master->minor->dev;
+ struct drm_device *dev = master->dev;
if (dev->driver->master_destroy)
dev->driver->master_destroy(dev, master);
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 2fd4f42b907a..bfbf1381f55d 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -185,7 +185,7 @@ int drm_new_set_master(struct drm_device *dev, struct
drm_file *fpriv)
lockdep_assert_held_once(&dev->master_mutex);
/* create a new master */
- fpriv->minor->master = drm_master_create(fpriv->minor);
+ fpriv->minor->master = drm_master_create(fpriv->minor->dev);
if (!fpriv->minor->master)
return -ENOMEM;
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 56a9b1cf99d7..f5c1d17fa51f 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -92,7 +92,7 @@ int drm_setmaster_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
int drm_dropmaster_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
-struct drm_master *drm_master_create(struct drm_minor *minor);
+struct drm_master *drm_master_create(struct drm_device *dev);
/* drm_debugfs.c */
#if defined(CONFIG_DEBUG_FS)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index cd3995d82477..17dcbea4f259 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -379,16 +379,19 @@ struct drm_lock_data {
* struct drm_master - drm master structure
*
* @refcount: Refcount for this master object.
- * @minor: Link back to minor char device we are master for. Immutable.
+ * @dev: Link back to the DRM device
* @unique: Unique identifier: e.g. busid. Protected by drm_global_mutex.
* @unique_len: Length of unique field. Protected by drm_global_mutex.
* @magic_map: Map of used authentication tokens. Protected by struct_mutex.
* @lock: DRI lock information.
* @driver_priv: Pointer to driver-private information.
+ *
+ * Note that master structures are only relevant for the legacy/primary device
+ * nodes, hence there can only be one per device, not one per drm_minor.
*/
struct drm_master {
struct kref refcount;
- struct drm_minor *minor;
+ struct drm_device *dev;
char *unique;
int unique_len;
struct idr magic_map;
--
2.8.1
[PATCH 04/14] drm: Move master functions into drm_auth.c
For modern drivers pretty much the only thing drm_master does is
handling authentication for the primary/legacy drm_minor node. Instead
of having it all over drm files, move it all together into drm_auth.c.
This patch just does code-motion, follow up patches will also extract
the master logic from file open&release paths.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_auth.c | 163 +
drivers/gpu/drm/drm_drv.c | 108 ---
drivers/gpu/drm/drm_fops.c | 54 --
drivers/gpu/drm/drm_internal.h | 12 ++-
include/drm/drmP.h | 1 -
5 files changed, 168 insertions(+), 170 deletions(-)
diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index 50d0baa06db0..1d314ae13560 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -30,6 +30,7 @@
#include
#include "drm_internal.h"
+#include "drm_legacy.h"
/**
* drm_getmagic - Get unique magic of a client
@@ -91,3 +92,165 @@ int drm_authmagic(struct drm_device *dev, void *data,
return file ? 0 : -EINVAL;
}
+
+static struct drm_master *drm_master_create(struct drm_device *dev)
+{
+ struct drm_master *master;
+
+ master = kzalloc(sizeof(*master), GFP_KERNEL);
+ if (!master)
+ return NULL;
+
+ kref_init(&master->refcount);
+ spin_lock_init(&master->lock.spinlock);
+ init_waitqueue_head(&master->lock.lock_queue);
+ idr_init(&master->magic_map);
+ master->dev = dev;
+
+ return master;
+}
+
+/*
+ * drm_new_set_master - Allocate a new master object and become master for the
+ * associated master realm.
+ *
+ * @dev: The associated device.
+ * @fpriv: File private identifying the client.
+ *
+ * This function must be called with dev::struct_mutex held.
+ * Returns negative error code on failure. Zero on success.
+ */
+int drm_new_set_master(struct drm_device *dev, struct drm_file *fpriv)
+{
+ struct drm_master *old_master;
+ int ret;
+
+ lockdep_assert_held_once(&dev->master_mutex);
+
+ /* create a new master */
+ fpriv->minor->master = drm_master_create(fpriv->minor->dev);
+ if (!fpriv->minor->master)
+ return -ENOMEM;
+
+ /* take another reference for the copy in the local file priv */
+ old_master = fpriv->master;
+ fpriv->master = drm_master_get(fpriv->minor->master);
+
+ if (dev->driver->master_create) {
+ ret = dev->driver->master_create(dev, fpriv->master);
+ if (ret)
+ goto out_err;
+ }
+ if (dev->driver->master_set) {
+ ret = dev->driver->master_set(dev, fpriv, true);
+ if (ret)
+ goto out_err;
+ }
+
+ fpriv->is_master = 1;
+ fpriv->allowed_master = 1;
+ fpriv->authenticated = 1;
+ if (old_master)
+ drm_master_put(&old_master);
+
+ return 0;
+
+out_err:
+ /* drop both references and restore old master on failure */
+ drm_master_put(&fpriv->minor->master);
+ drm_master_put(&fpriv->master);
+ fpriv->master = old_master;
+
+ return ret;
+}
+
+int drm_setmaster_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+ int ret = 0;
+
+ mutex_lock(&dev->master_mutex);
+ if (file_priv->is_master)
+ goto out_unlock;
+
+ if (file_priv->minor->master) {
+ ret = -EINVAL;
+ goto out_unlock;
+ }
+
+ if (!file_priv->master) {
+ ret = -EINVAL;
+ goto out_unlock;
+ }
+
+ if (!file_priv->allowed_master) {
+ ret = drm_new_set_master(dev, file_priv);
+ goto out_unlock;
+ }
+
+ file_priv->minor->master = drm_master_get(file_priv->master);
+ file_priv->is_master = 1;
+ if (dev->driver->master_set) {
+ ret = dev->driver->master_set(dev, file_priv, false);
+ if (unlikely(ret != 0)) {
+ file_priv->is_master = 0;
+ drm_master_put(&file_priv->minor->master);
+ }
+ }
+
+out_unlock:
+ mutex_unlock(&dev->master_mutex);
+ return ret;
+}
+
+int drm_dropmaster_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file_priv)
+{
+ int ret = -EINVAL;
+
+ mutex_lock(&dev->master_mutex);
+ if (!file_priv->is_master)
+ goto out_unlock;
+
+ if (!file_priv->minor->master)
+ goto out_unlock;
+
+ ret = 0;
+ if (dev->driver->master_drop)
+ dev->driver->master_drop(dev, file_priv, false);
+ drm_master_put(&file_priv->minor->master);
+ file_priv->is_master = 0;
+
+out_unlock:
+ mutex_unlock(&dev->master_mutex);
+ return ret;
+}
+
+struct drm_master *drm_master_get(struct drm_master *mast
[PATCH 06/14] drm: Extract drm_master_relase
Like with drm_master_open protect it with a check for primary_client
to make it clear that this can't happen on render/control nodes.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_auth.c | 37 +
drivers/gpu/drm/drm_fops.c | 35 ++-
drivers/gpu/drm/drm_internal.h | 1 +
3 files changed, 40 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index 9c1e2081cd58..e015a7edb154 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -243,6 +243,43 @@ int drm_master_open(struct drm_file *file_priv)
return ret;
}
+void drm_master_release(struct drm_file *file_priv)
+{
+ struct drm_device *dev = file_priv->minor->dev;
+
+ mutex_lock(&dev->master_mutex);
+ if (file_priv->is_master) {
+ struct drm_master *master = file_priv->master;
+
+ /*
+* Since the master is disappearing, so is the
+* possibility to lock.
+*/
+ mutex_lock(&dev->struct_mutex);
+ if (master->lock.hw_lock) {
+ if (dev->sigdata.lock == master->lock.hw_lock)
+ dev->sigdata.lock = NULL;
+ master->lock.hw_lock = NULL;
+ master->lock.file_priv = NULL;
+ wake_up_interruptible_all(&master->lock.lock_queue);
+ }
+ mutex_unlock(&dev->struct_mutex);
+
+ if (file_priv->minor->master == file_priv->master) {
+ /* drop the reference held my the minor */
+ if (dev->driver->master_drop)
+ dev->driver->master_drop(dev, file_priv, true);
+ drm_master_put(&file_priv->minor->master);
+ }
+ }
+
+ /* drop the master reference held by the file priv */
+ if (file_priv->master)
+ drm_master_put(&file_priv->master);
+ file_priv->is_master = 0;
+ mutex_unlock(&dev->master_mutex);
+}
+
struct drm_master *drm_master_get(struct drm_master *master)
{
kref_get(&master->refcount);
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index e2522672719a..f3b2677de882 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -411,43 +411,12 @@ int drm_release(struct inode *inode, struct file *filp)
drm_legacy_ctxbitmap_flush(dev, file_priv);
- mutex_lock(&dev->master_mutex);
-
- if (file_priv->is_master) {
- struct drm_master *master = file_priv->master;
-
- /*
-* Since the master is disappearing, so is the
-* possibility to lock.
-*/
- mutex_lock(&dev->struct_mutex);
- if (master->lock.hw_lock) {
- if (dev->sigdata.lock == master->lock.hw_lock)
- dev->sigdata.lock = NULL;
- master->lock.hw_lock = NULL;
- master->lock.file_priv = NULL;
- wake_up_interruptible_all(&master->lock.lock_queue);
- }
- mutex_unlock(&dev->struct_mutex);
-
- if (file_priv->minor->master == file_priv->master) {
- /* drop the reference held my the minor */
- if (dev->driver->master_drop)
- dev->driver->master_drop(dev, file_priv, true);
- drm_master_put(&file_priv->minor->master);
- }
- }
-
- /* drop the master reference held by the file priv */
- if (file_priv->master)
- drm_master_put(&file_priv->master);
- file_priv->is_master = 0;
- mutex_unlock(&dev->master_mutex);
+ if (drm_is_primary_client(file_priv))
+ drm_master_release(file_priv);
if (dev->driver->postclose)
dev->driver->postclose(dev, file_priv);
-
if (drm_core_check_feature(dev, DRIVER_PRIME))
drm_prime_destroy_file_private(&file_priv->prime);
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 2b9a94f679ed..38401d406532 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -67,6 +67,7 @@ int drm_setmaster_ioctl(struct drm_device *dev, void *data,
int drm_dropmaster_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
int drm_master_open(struct drm_file *file_priv);
+void drm_master_release(struct drm_file *file_priv);
/* drm_sysfs.c */
extern struct class *drm_class;
--
2.8.1
[PATCH 05/14] drm: Extract drm_master_open
And pull out the primary_client check to make it really obvious that
this can't happen on control/render nodes. Bonus that we can avoid the
master lock in this case.
v2: Don't leak locks on error path (and simplify control flow while
at it), reported by Julia.
Cc: Julia Lawall
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_auth.c | 19 ++-
drivers/gpu/drm/drm_fops.c | 13 ++---
drivers/gpu/drm/drm_internal.h | 2 +-
3 files changed, 21 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index 1d314ae13560..9c1e2081cd58 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -120,7 +120,7 @@ static struct drm_master *drm_master_create(struct
drm_device *dev)
* This function must be called with dev::struct_mutex held.
* Returns negative error code on failure. Zero on success.
*/
-int drm_new_set_master(struct drm_device *dev, struct drm_file *fpriv)
+static int drm_new_set_master(struct drm_device *dev, struct drm_file *fpriv)
{
struct drm_master *old_master;
int ret;
@@ -226,6 +226,23 @@ out_unlock:
return ret;
}
+int drm_master_open(struct drm_file *file_priv)
+{
+ struct drm_device *dev = file_priv->minor->dev;
+ int ret = 0;
+
+ /* if there is no current master make this fd it, but do not create
+* any master object for render clients */
+ mutex_lock(&dev->master_mutex);
+ if (!file_priv->minor->master)
+ ret = drm_new_set_master(dev, file_priv);
+ else
+ file_priv->master = drm_master_get(file_priv->minor->master);
+ mutex_unlock(&dev->master_mutex);
+
+ return ret;
+}
+
struct drm_master *drm_master_get(struct drm_master *master)
{
kref_get(&master->refcount);
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 50b3de990aee..e2522672719a 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -229,19 +229,11 @@ static int drm_open_helper(struct file *filp, struct
drm_minor *minor)
goto out_prime_destroy;
}
- /* if there is no current master make this fd it, but do not create
-* any master object for render clients */
- mutex_lock(&dev->master_mutex);
- if (drm_is_primary_client(priv) && !priv->minor->master) {
- /* create a new master */
- ret = drm_new_set_master(dev, priv);
+ if (drm_is_primary_client(priv)) {
+ ret = drm_master_open(priv);
if (ret)
goto out_close;
- } else if (drm_is_primary_client(priv)) {
- /* get a reference to the master */
- priv->master = drm_master_get(priv->minor->master);
}
- mutex_unlock(&dev->master_mutex);
mutex_lock(&dev->filelist_mutex);
list_add(&priv->lhead, &dev->filelist);
@@ -270,7 +262,6 @@ static int drm_open_helper(struct file *filp, struct
drm_minor *minor)
return 0;
out_close:
- mutex_unlock(&dev->master_mutex);
if (dev->driver->postclose)
dev->driver->postclose(dev, priv);
out_prime_destroy:
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index d29d426f633f..2b9a94f679ed 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -66,7 +66,7 @@ int drm_setmaster_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
int drm_dropmaster_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
-int drm_new_set_master(struct drm_device *dev, struct drm_file *fpriv);
+int drm_master_open(struct drm_file *file_priv);
/* drm_sysfs.c */
extern struct class *drm_class;
--
2.8.1
[PATCH 07/14] drm: Only do the hw.lock cleanup in master_relase for !MODESET
Another place gone where modern drivers could have hit
dev->struct_mutex.
To avoid too deeply nesting control flow rework it a bit.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_auth.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index e015a7edb154..a58b2eb0d004 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -246,11 +246,14 @@ int drm_master_open(struct drm_file *file_priv)
void drm_master_release(struct drm_file *file_priv)
{
struct drm_device *dev = file_priv->minor->dev;
+ struct drm_master *master = file_priv->master;
+
mutex_lock(&dev->master_mutex);
- if (file_priv->is_master) {
- struct drm_master *master = file_priv->master;
+ if (!file_priv->is_master)
+ goto out_unlock;
+ if (!drm_core_check_feature(dev, DRIVER_MODESET)) {
/*
* Since the master is disappearing, so is the
* possibility to lock.
@@ -264,19 +267,20 @@ void drm_master_release(struct drm_file *file_priv)
wake_up_interruptible_all(&master->lock.lock_queue);
}
mutex_unlock(&dev->struct_mutex);
+ }
- if (file_priv->minor->master == file_priv->master) {
- /* drop the reference held my the minor */
- if (dev->driver->master_drop)
- dev->driver->master_drop(dev, file_priv, true);
- drm_master_put(&file_priv->minor->master);
- }
+ if (file_priv->minor->master == file_priv->master) {
+ /* drop the reference held my the minor */
+ if (dev->driver->master_drop)
+ dev->driver->master_drop(dev, file_priv, true);
+ drm_master_put(&file_priv->minor->master);
}
/* drop the master reference held by the file priv */
if (file_priv->master)
drm_master_put(&file_priv->master);
file_priv->is_master = 0;
+out_unlock:
mutex_unlock(&dev->master_mutex);
}
--
2.8.1
[PATCH 08/14] drm: Move authmagic cleanup into drm_master_release
It's related, and soon authmagic will also use the master_mutex. There is an ever-so-slightly semantic change here: - authmagic will only be cleaned up for primary_client drm_minors. But it's impossible to create authmagic on render/control nodes, so this is fine. - The cleanup is moved down a bit in the release processing. Doesn't matter at all since authmagic is purely internal logic used by the core ioctl access checks, and when we're in a file's release callback no one can do ioctls any more. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_auth.c | 4 drivers/gpu/drm/drm_fops.c | 5 - 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c index a58b2eb0d004..e37d657dbf5f 100644 --- a/drivers/gpu/drm/drm_auth.c +++ b/drivers/gpu/drm/drm_auth.c @@ -248,6 +248,10 @@ void drm_master_release(struct drm_file *file_priv) struct drm_device *dev = file_priv->minor->dev; struct drm_master *master = file_priv->master; + mutex_lock(&dev->struct_mutex); + if (file_priv->magic) + idr_remove(&file_priv->master->magic_map, file_priv->magic); + mutex_unlock(&dev->struct_mutex); mutex_lock(&dev->master_mutex); if (!file_priv->is_master) diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c index f3b2677de882..f6dfdfcd018b 100644 --- a/drivers/gpu/drm/drm_fops.c +++ b/drivers/gpu/drm/drm_fops.c @@ -376,11 +376,6 @@ int drm_release(struct inode *inode, struct file *filp) list_del(&file_priv->lhead); mutex_unlock(&dev->filelist_mutex); - mutex_lock(&dev->struct_mutex); - if (file_priv->magic) - idr_remove(&file_priv->master->magic_map, file_priv->magic); - mutex_unlock(&dev->struct_mutex); - if (dev->driver->preclose) dev->driver->preclose(dev, file_priv); -- 2.8.1
[PATCH 09/14] drm: Protect authmagic with master_mutex
Simplifies cleanup, and there's no reason drivers should ever care
about authmagic at all - it's all handled in the core.
And with that, Ladies and Gentlemen, it's time to pop the champagen
and celebrate: dev->struct_mutex is now officially gone from modern
drivers, and if a driver is using gem_free_object_unlocked and doesn't
do anything else silly it's positively impossible to ever touch
dev->struct_mutex at runtime, anywhere.
Well except for the mutex_init on driver load ;-)
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_auth.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index e37d657dbf5f..94761e4bd1e5 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -49,7 +49,7 @@ int drm_getmagic(struct drm_device *dev, void *data, struct
drm_file *file_priv)
struct drm_auth *auth = data;
int ret = 0;
- mutex_lock(&dev->struct_mutex);
+ mutex_lock(&dev->master_mutex);
if (!file_priv->magic) {
ret = idr_alloc(&file_priv->master->magic_map, file_priv,
1, 0, GFP_KERNEL);
@@ -57,7 +57,7 @@ int drm_getmagic(struct drm_device *dev, void *data, struct
drm_file *file_priv)
file_priv->magic = ret;
}
auth->magic = file_priv->magic;
- mutex_unlock(&dev->struct_mutex);
+ mutex_unlock(&dev->master_mutex);
DRM_DEBUG("%u\n", auth->magic);
@@ -82,13 +82,13 @@ int drm_authmagic(struct drm_device *dev, void *data,
DRM_DEBUG("%u\n", auth->magic);
- mutex_lock(&dev->struct_mutex);
+ mutex_lock(&dev->master_mutex);
file = idr_find(&file_priv->master->magic_map, auth->magic);
if (file) {
file->authenticated = 1;
idr_replace(&file_priv->master->magic_map, NULL, auth->magic);
}
- mutex_unlock(&dev->struct_mutex);
+ mutex_unlock(&dev->master_mutex);
return file ? 0 : -EINVAL;
}
@@ -117,7 +117,7 @@ static struct drm_master *drm_master_create(struct
drm_device *dev)
* @dev: The associated device.
* @fpriv: File private identifying the client.
*
- * This function must be called with dev::struct_mutex held.
+ * This function must be called with dev::master_mutex held.
* Returns negative error code on failure. Zero on success.
*/
static int drm_new_set_master(struct drm_device *dev, struct drm_file *fpriv)
@@ -248,12 +248,10 @@ void drm_master_release(struct drm_file *file_priv)
struct drm_device *dev = file_priv->minor->dev;
struct drm_master *master = file_priv->master;
- mutex_lock(&dev->struct_mutex);
+ mutex_lock(&dev->master_mutex);
if (file_priv->magic)
idr_remove(&file_priv->master->magic_map, file_priv->magic);
- mutex_unlock(&dev->struct_mutex);
- mutex_lock(&dev->master_mutex);
if (!file_priv->is_master)
goto out_unlock;
--
2.8.1
[PATCH 10/14] drm: Mark authmagic ioctls as unlocked
All protected by dev->master_mutex. And there's no driver callbacks,
which means no need to sync with old dri1 horror show drivers at all.
Hence safe to drop the drm legacy BKL from these paths.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_ioctl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index b7a39771c152..e4ccb5c3fdea 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -504,7 +504,7 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_VERSION, drm_version,
DRM_UNLOCKED|DRM_RENDER_ALLOW|DRM_CONTROL_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_GET_UNIQUE, drm_getunique, 0),
- DRM_IOCTL_DEF(DRM_IOCTL_GET_MAGIC, drm_getmagic, 0),
+ DRM_IOCTL_DEF(DRM_IOCTL_GET_MAGIC, drm_getmagic, DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_IRQ_BUSID, drm_irq_by_busid,
DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF(DRM_IOCTL_GET_MAP, drm_legacy_getmap_ioctl, DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_GET_CLIENT, drm_getclient, DRM_UNLOCKED),
@@ -516,7 +516,7 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_SET_UNIQUE, drm_setunique,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF(DRM_IOCTL_BLOCK, drm_noop,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF(DRM_IOCTL_UNBLOCK, drm_noop,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
- DRM_IOCTL_DEF(DRM_IOCTL_AUTH_MAGIC, drm_authmagic, DRM_AUTH|DRM_MASTER),
+ DRM_IOCTL_DEF(DRM_IOCTL_AUTH_MAGIC, drm_authmagic,
DRM_AUTH|DRM_UNLOCKED|DRM_MASTER),
DRM_IOCTL_DEF(DRM_IOCTL_ADD_MAP, drm_legacy_addmap_ioctl,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF(DRM_IOCTL_RM_MAP, drm_legacy_rmmap_ioctl, DRM_AUTH),
--
2.8.1
[PATCH 11/14] drm: Mark set/drop master ioctl as unlocked.
Again this is neatly protected by the dev->master_mutex now. There is
a driver callback both for set and drop, but it's only used by vmwgfx.
And vmwgfx has it's own solid locking for shared resources (besides
dev->master_mutex), hence is all safe. Let's drop another place where
the drm legacy bkl is used.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_ioctl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index e4ccb5c3fdea..11eda9050215 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -524,8 +524,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_SET_SAREA_CTX, drm_legacy_setsareactx,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF(DRM_IOCTL_GET_SAREA_CTX, drm_legacy_getsareactx,
DRM_AUTH),
- DRM_IOCTL_DEF(DRM_IOCTL_SET_MASTER, drm_setmaster_ioctl, DRM_ROOT_ONLY),
- DRM_IOCTL_DEF(DRM_IOCTL_DROP_MASTER, drm_dropmaster_ioctl,
DRM_ROOT_ONLY),
+ DRM_IOCTL_DEF(DRM_IOCTL_SET_MASTER, drm_setmaster_ioctl,
DRM_UNLOCKED|DRM_ROOT_ONLY),
+ DRM_IOCTL_DEF(DRM_IOCTL_DROP_MASTER, drm_dropmaster_ioctl,
DRM_UNLOCKED|DRM_ROOT_ONLY),
DRM_IOCTL_DEF(DRM_IOCTL_ADD_CTX, drm_legacy_addctx,
DRM_AUTH|DRM_ROOT_ONLY),
DRM_IOCTL_DEF(DRM_IOCTL_RM_CTX, drm_legacy_rmctx,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
--
2.8.1
[PATCH 12/14] drm: Move master pointer from drm_minor to drm_device
There can only be one current master, and it's for the overall device.
Render/control minors don't support master-based auth at all.
This simplifies the master logic a lot, at least in my eyes: All these
additional pointer chases are just confusing.
While doing the conversion I spotted some locking fail:
- drm_lock/drm_auth check dev->master without holding the
master_mutex. This is fallout from
commit c996fd0b956450563454e7ccc97a82ca31f9d043
Author: Thomas Hellstrom
Date: Tue Feb 25 19:57:44 2014 +0100
drm: Protect the master management with a drm_device::master_mutex v3
but I honestly don't care one bit about those old legacy drivers
using this.
- debugfs name info should just grab master_mutex.
- And the fbdev helper looked at it to figure out whether someone is
using KMS. We just need a consistent value, so READ_ONCE. Aside: We
should probably check if anyone has opened a control node too, but I
guess current userspace doesn't really do that yet.
v2: Balance locking, reported by Julia.
Cc: Julia Lawall
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_auth.c | 26 +-
drivers/gpu/drm/drm_bufs.c | 8
drivers/gpu/drm/drm_fb_helper.c | 2 +-
drivers/gpu/drm/drm_info.c | 10 --
drivers/gpu/drm/drm_lock.c | 2 +-
drivers/gpu/drm/sis/sis_mm.c| 2 +-
drivers/gpu/drm/via/via_mm.c| 2 +-
include/drm/drmP.h | 9 +
8 files changed, 34 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index 94761e4bd1e5..fcadd8e1de28 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -128,13 +128,13 @@ static int drm_new_set_master(struct drm_device *dev,
struct drm_file *fpriv)
lockdep_assert_held_once(&dev->master_mutex);
/* create a new master */
- fpriv->minor->master = drm_master_create(fpriv->minor->dev);
- if (!fpriv->minor->master)
+ dev->master = drm_master_create(dev);
+ if (!dev->master)
return -ENOMEM;
/* take another reference for the copy in the local file priv */
old_master = fpriv->master;
- fpriv->master = drm_master_get(fpriv->minor->master);
+ fpriv->master = drm_master_get(dev->master);
if (dev->driver->master_create) {
ret = dev->driver->master_create(dev, fpriv->master);
@@ -157,7 +157,7 @@ static int drm_new_set_master(struct drm_device *dev,
struct drm_file *fpriv)
out_err:
/* drop both references and restore old master on failure */
- drm_master_put(&fpriv->minor->master);
+ drm_master_put(&dev->master);
drm_master_put(&fpriv->master);
fpriv->master = old_master;
@@ -173,7 +173,7 @@ int drm_setmaster_ioctl(struct drm_device *dev, void *data,
if (file_priv->is_master)
goto out_unlock;
- if (file_priv->minor->master) {
+ if (dev->master) {
ret = -EINVAL;
goto out_unlock;
}
@@ -188,13 +188,13 @@ int drm_setmaster_ioctl(struct drm_device *dev, void
*data,
goto out_unlock;
}
- file_priv->minor->master = drm_master_get(file_priv->master);
+ dev->master = drm_master_get(file_priv->master);
file_priv->is_master = 1;
if (dev->driver->master_set) {
ret = dev->driver->master_set(dev, file_priv, false);
if (unlikely(ret != 0)) {
file_priv->is_master = 0;
- drm_master_put(&file_priv->minor->master);
+ drm_master_put(&dev->master);
}
}
@@ -212,13 +212,13 @@ int drm_dropmaster_ioctl(struct drm_device *dev, void
*data,
if (!file_priv->is_master)
goto out_unlock;
- if (!file_priv->minor->master)
+ if (!dev->master)
goto out_unlock;
ret = 0;
if (dev->driver->master_drop)
dev->driver->master_drop(dev, file_priv, false);
- drm_master_put(&file_priv->minor->master);
+ drm_master_put(&dev->master);
file_priv->is_master = 0;
out_unlock:
@@ -234,10 +234,10 @@ int drm_master_open(struct drm_file *file_priv)
/* if there is no current master make this fd it, but do not create
* any master object for render clients */
mutex_lock(&dev->master_mutex);
- if (!file_priv->minor->master)
+ if (!dev->master)
ret = drm_new_set_master(dev, file_priv);
else
- file_priv->master = drm_master_get(file_priv->minor->master);
+ file_priv->master = drm_master_get(dev->master);
mutex_unlock(&dev->master_mutex);
return ret;
@@ -271,11 +271,11 @@ void drm_master_release(struct drm_file *file_priv)
mutex_unlock(&dev->struct_mutex);
}
- if (file_priv->minor->master == file_priv->master) {
+ if (dev-
[PATCH 13/14] drm: Clean up drm_crtc.h
- Group declarations for separate files (drm_bridge.c, drm_edid.c)
- Move declarations only used within drm.ko to drm_crtc_internal.h
- drm_property_type_valid to drm_crtc.c, its only callsite
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 7 ++
drivers/gpu/drm/drm_crtc_internal.h | 86 -
drivers/gpu/drm/drm_drv.c | 1 +
drivers/gpu/drm/drm_fops.c | 1 +
include/drm/drm_crtc.h | 188 +++-
5 files changed, 150 insertions(+), 133 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 4ec35f9e6de5..4ff818ad34d7 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3656,6 +3656,13 @@ void drm_fb_release(struct drm_file *priv)
}
}
+static bool drm_property_type_valid(struct drm_property *property)
+{
+ if (property->flags & DRM_MODE_PROP_EXTENDED_TYPE)
+ return !(property->flags & DRM_MODE_PROP_LEGACY_TYPE);
+ return !!(property->flags & DRM_MODE_PROP_LEGACY_TYPE);
+}
+
/**
* drm_property_create - create a new property type
* @dev: drm device
diff --git a/drivers/gpu/drm/drm_crtc_internal.h
b/drivers/gpu/drm/drm_crtc_internal.h
index a78c138282ea..8186c0e05c42 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -31,14 +31,98 @@
* and are not exported to drivers.
*/
+
+/* drm_crtc.c */
+void drm_connector_ida_init(void);
+void drm_connector_ida_destroy(void);
int drm_mode_object_get(struct drm_device *dev,
struct drm_mode_object *obj, uint32_t obj_type);
void drm_mode_object_unregister(struct drm_device *dev,
struct drm_mode_object *object);
+bool drm_property_change_valid_get(struct drm_property *property,
+ uint64_t value,
+ struct drm_mode_object **ref);
+void drm_property_change_valid_put(struct drm_property *property,
+ struct drm_mode_object *ref);
+
+int drm_plane_check_pixel_format(const struct drm_plane *plane,
+u32 format);
+int drm_crtc_check_viewport(const struct drm_crtc *crtc,
+ int x, int y,
+ const struct drm_display_mode *mode,
+ const struct drm_framebuffer *fb);
+
+void drm_fb_release(struct drm_file *file_priv);
+void drm_property_destroy_user_blobs(struct drm_device *dev,
+struct drm_file *file_priv);
+
+/* dumb buffer support IOCTLs */
+int drm_mode_create_dumb_ioctl(struct drm_device *dev,
+ void *data, struct drm_file *file_priv);
+int drm_mode_mmap_dumb_ioctl(struct drm_device *dev,
+void *data, struct drm_file *file_priv);
+int drm_mode_destroy_dumb_ioctl(struct drm_device *dev,
+ void *data, struct drm_file *file_priv);
+
+/* framebuffer IOCTLs */
+extern int drm_mode_addfb(struct drm_device *dev,
+ void *data, struct drm_file *file_priv);
+extern int drm_mode_addfb2(struct drm_device *dev,
+ void *data, struct drm_file *file_priv);
+int drm_mode_rmfb(struct drm_device *dev,
+void *data, struct drm_file *file_priv);
+int drm_mode_getfb(struct drm_device *dev,
+ void *data, struct drm_file *file_priv);
+int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
+ void *data, struct drm_file *file_priv);
+
+/* IOCTLs */
+int drm_mode_obj_get_properties_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_priv);
+int drm_mode_obj_set_property_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_priv);
+
+int drm_mode_getresources(struct drm_device *dev,
+ void *data, struct drm_file *file_priv);
+int drm_mode_getplane_res(struct drm_device *dev, void *data,
+ struct drm_file *file_priv);
+int drm_mode_getcrtc(struct drm_device *dev,
+void *data, struct drm_file *file_priv);
+int drm_mode_getconnector(struct drm_device *dev,
+ void *data, struct drm_file *file_priv);
+int drm_mode_setcrtc(struct drm_device *dev,
+void *data, struct drm_file *file_priv);
+int drm_mode_getplane(struct drm_device *dev,
+ void *data, struct drm_file *file_priv);
+int drm_mode_setplane(struct drm_device *dev,
+ void *data, struct drm_file *file_priv);
+int drm_mode_cursor_ioctl(struct drm_device *dev,
+ void *data, struct drm_file *file_priv);
+int drm_mode_cursor2_ioctl(struct drm_device *dev,
+ void *data, struct drm_file *file_priv);
+int drm_mode_getproperty_ioctl(struct dr
[PATCH 14/14] drm: Use dev->name as fallback for dev->unique
Lots of arm drivers get this wrong and for most arm boards this is the
right thing actually. And anyway with most loaders you want to chase
sysfs links anyway to figure out which dri device you want.
This will fix dmesg noise for rockchip and sti.
Also add a fallback to driver->name for entirely virtual drivers like
vgem.
v2: Rebase on top of
commit e112e593b215c394c0303dbf0534db0928e87967
Author: Nicolas Iooss
Date: Fri Dec 11 11:20:28 2015 +0100
drm: use dev_name as default unique name in drm_dev_alloc()
and simplify a bit. Plus add a comment.
Cc: Ilia Mirkin
Reported-by: Ilia Mirkin
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 10 +-
drivers/gpu/drm/drm_ioctl.c | 8 +---
2 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 10afa2539181..ecba2511ef5a 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -523,11 +523,11 @@ struct drm_device *drm_dev_alloc(struct drm_driver
*driver,
}
}
- if (parent) {
- ret = drm_dev_set_unique(dev, dev_name(parent));
- if (ret)
- goto err_setunique;
- }
+ /* Use the parent device name as DRM device unique identifier, but fall
+* back to the driver name for virtual devices like vgem. */
+ ret = drm_dev_set_unique(dev, parent ? dev_name(parent) : driver->name);
+ if (ret)
+ goto err_setunique;
return dev;
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 11eda9050215..83892b6b1e0d 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -134,13 +134,7 @@ static int drm_set_busid(struct drm_device *dev, struct
drm_file *file_priv)
drm_unset_busid(dev, master);
return ret;
}
- } else {
- if (WARN(dev->unique == NULL,
-"No drm_driver.set_busid() implementation provided by "
-"%ps. Use drm_dev_set_unique() to set the unique "
-"name explicitly.", dev->driver))
- return -EINVAL;
-
+ } else if (dev->unique) {
master->unique = kstrdup(dev->unique, GFP_KERNEL);
if (master->unique)
master->unique_len = strlen(dev->unique);
--
2.8.1
[Bug 119631] RadeonSI get a huge performance dip with used with the nine state tracker
https://bugzilla.kernel.org/show_bug.cgi?id=119631 Axel Davy changed: What|Removed |Added CC||vebveb at hotmail.fr --- Comment #10 from Axel Davy --- Hi, It looks like to be a bug in gallium nine, wine side. (Though I don't get why thread_submit=true didn't help) Please try with the following diff: https://paste.fedoraproject.org/379178/93261014/ -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v2 1/2] dt-bindings: add Starry KR122EA0SRA panel binding
On Fri, Jun 10, 2016 at 10:02:06AM -0700, Douglas Anderson wrote: > The Starry KR122EA0SRA is a 12.2", 1920x1200 TFT-LCD panel connected > using eDP interfaces. > > Signed-off-by: Douglas Anderson > --- > Changes in v2: > - Proper title (sorry!) > > .../devicetree/bindings/display/panel/starry,kr122ea0sra.txt | 7 > +++ > 1 file changed, 7 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/starry,kr122ea0sra.txt Acked-by: Rob Herring
Looking for pointers on diagnosing ring test failure in amdgpu
On Tue, 14 Jun 2016 06:02:09 -0700 Alex Deucher wrote
>On Tue, Jun 14, 2016 at 4:10 AM, Christian König
> wrote:
>> Hi Matthew,
>>
>> see inline below.
>>
>> Am 14.06.2016 um 00:03 schrieb Matthew Macy:
>>>
>>> On Mon, 13 Jun 2016 01:35:34 -0700 Christian König
>>> wrote
>>> > Hi Matthew,
>>> >
>>> > sounds like the UVD block doesn't want to initialize. No idea off hand
>>> > why, could be anything. I would need the hardware here for a closer
>>> > inspection.
>>> >
>>> > For a workaround you can try to disable the UVD blokc using the
>>> > ip_block_mask module parameter (it's a bitmask of enabled blocks e.g.
>>> > 0x means all blocks enabled, UVD is bit 7 on Carrizo IIRC).
>>>
>>>
>>> When I clear bit 7 I get the following now:
>>>
>>> Jun 14 07:58:18 trainwreck kernel: drmn0: fence driver on ring 10 use gpu
>>> addr 0x40b0, cpu addr 0x0xf800bd4320b0
>>> Jun 14 07:58:18 trainwreck kernel: drmn0: fence driver on ring 11 use gpu
>>> addr 0x40c0, cpu addr 0x0xf800bd4320c0
>>> Jun 14 07:58:19 trainwreck kernel: drmn0: SMU check loaded firmware
>>> failed, expecting 0x17f, getting 0x0[drm:0x826d4dc4s] *ERROR*
>>> amdgpu: smc start failed
>>> Jun 14 07:58:19 trainwreck kernel: [drm:0x8269fc40s] *ERROR*
>>> hw_init 3 failed -22
>>> Jun 14 07:58:19 trainwreck kernel: drmn0: amdgpu_init failed
>>
>>
>> UVD is optional (as long as you don't want to do hardware video decoding)
>> but the SMU isn't. Alex, Rex any idea what's going wrong here?
>>
>
>Seems like maybe the two issues are related. Maybe some general MMIO
>issue on that particular system or a issue with the MC or gart setup?
>The firmware that the SMU loads is stored in gart and all of the
>engine rings are in gart. Maybe a problem with the IOMMU setup on the
>CPU?
The two issues are definitely related. They both go through a bounded delay
loop waiting for some operation to complete.
By default FreeBSD doesn't use the IOMMU on x86 so that's not an issue.
One thing that is different between the Elitebook (A12) and the the Thinkpad
(A10) is that the Thinkpad has both integrated and discrete GPUs. 0x6660
matches Hainan in drm_pciids.h which I guess is GCN 1.0? Could that possibly be
an issue? I know amdgpu doesn't support pre GCN 1.1 currently, so I would
assume it would just be ignored. Nonetheless, I thought I should bring it up
just in case.
vgapci0 at pci0:0:1:0: class=0x03 card=0x511617aa chip=0x98741002 rev=0xc5
hdr=0x00
vendor = 'Advanced Micro Devices, Inc. [AMD/ATI]'
device = 'Carrizo'
class = display
subclass = VGA
<...>
vgapci1 at pci0:5:0:0: class=0x038000 card=0x511617aa chip=0x66601002 rev=0x83
hdr=0x00
vendor = 'Advanced Micro Devices, Inc. [AMD/ATI]'
device = 'Sun XT [Radeon HD 8670A/8670M/8690M / R5 M330]'
class = display
Thanks.
-M
>
>Alex
>
>>> Which is hard to correlate without spending a lot more quality time with
>>> the driver than I've had time for yet.
>>
>>
>> Yeah, I don't see why some blocks should fail while others seem to
>> initialize just fine. Especially since you reported it seems to work on
>> other hardware.
>>
>>> One thing that occurs to me is that Linux is usually compiled with gcc6 -
>>> has amdgpu ever been tested as compiled with clang?
>>
>>
>> Not as far as I know. We had some problems in the past even with some gcc
>> versions because of some odd things in the BIOS headers (e.g. zero sized
>> arrays). But those issues should be fixed by now.
>>
>>> Below is a list of the warnings I have to disable in order to get amdgpu
>>> to compile without disabling Werror altogether. The -Wno-format is an
>>> artifact of clang or FreeBSD treating long long and uint64_t as distinct
>>> types and the -Wno-pointer-arith is to accept the linux convention of doing
>>> pointer arithmetic on void pointers. All the others are arguably oversights
>>> in the code (similar silencing has to be done in i915, but I've had better
>>> luck with it to date). I haven't fixed the warnings because I try to treat
>>> it as vendor code and minimize any local changes. Will you accept
>>> quasi-cosmetic patches from other operating systems / compilers?
>>
>>
>> Yeah, sure feel free to provide patches. As long as it is only cleanup and
>> not structural changes it should be trivial to get them merged.
>>
>> Especially "-Wno-missing-prototypes" and "-Wno-unused-variable" sound like
>> something which should be trivial to fix.
>>
>> Regards,
>> Christian.
>>
>>
>>>
>>> Thanks.
>>>
>>> -M
>>>
>>>
>>> CWARNFLAGS+= -Wno-pointer-arith
>>> CWARNFLAGS+= -Wno-pointer-sign ${CWARNFLAGS.${.IMPSRC:T}}
>>>
>>> CWARNFLAGS.amdgpu_acpi.c= -Wno-int-conversion
>>> -Wno-missing-prototypes -Wno-unused-variable
>>> CWARNFLAGS.amdgpu_amdkfd.c= -Wno-missing-prototypes
>>> CWARNFLAGS.amdgpu_bo_list.c= -Wno-missing-prototype
Looking for pointers on diagnosing ring test failure in amdgpu
>
> The two issues are definitely related. They both go through a bounded delay
> loop waiting for some operation to complete.
>
I realized that sounded really dumb after I sent it. But what makes me think
it's all related is that timing perturbations / random seemingly unrelated code
changes can cause it to fail in about 3 or 4 distinct ways. Some times failing
as early ring 0, other times ring 1, other times ring 11, and in this case on
SMU firmware check. Whereas no matter what I do it gets to the point of
switching from the efifb to the fb based on the set up by amdgpu on my friend's
elitebook. So it looks like I just hit really unfortunate choice for a bring up
device.
-M
> By default FreeBSD doesn't use the IOMMU on x86 so that's not an issue.
>
> One thing that is different between the Elitebook (A12) and the the Thinkpad
> (A10) is that the Thinkpad has both integrated and discrete GPUs. 0x6660
> matches Hainan in drm_pciids.h which I guess is GCN 1.0? Could that possibly
> be an issue? I know amdgpu doesn't support pre GCN 1.1 currently, so I would
> assume it would just be ignored. Nonetheless, I thought I should bring it up
> just in case.
>
>
> vgapci0 at pci0:0:1:0:class=0x03 card=0x511617aa chip=0x98741002
> rev=0xc5 hdr=0x00
> vendor = 'Advanced Micro Devices, Inc. [AMD/ATI]'
> device = 'Carrizo'
> class = display
> subclass = VGA
> <...>
> vgapci1 at pci0:5:0:0:class=0x038000 card=0x511617aa chip=0x66601002
> rev=0x83 hdr=0x00
> vendor = 'Advanced Micro Devices, Inc. [AMD/ATI]'
> device = 'Sun XT [Radeon HD 8670A/8670M/8690M / R5 M330]'
> class = display
>
> Thanks.
> -M
>
>
> >
> >Alex
> >
> >>> Which is hard to correlate without spending a lot more quality time with
> >>> the driver than I've had time for yet.
> >>
> >>
> >> Yeah, I don't see why some blocks should fail while others seem to
> >> initialize just fine. Especially since you reported it seems to work on
> >> other hardware.
> >>
> >>> One thing that occurs to me is that Linux is usually compiled with gcc6
> >>> -
> >>> has amdgpu ever been tested as compiled with clang?
> >>
> >>
> >> Not as far as I know. We had some problems in the past even with some gcc
> >> versions because of some odd things in the BIOS headers (e.g. zero sized
> >> arrays). But those issues should be fixed by now.
> >>
> >>> Below is a list of the warnings I have to disable in order to get amdgpu
> >>> to compile without disabling Werror altogether. The -Wno-format is an
> >>> artifact of clang or FreeBSD treating long long and uint64_t as distinct
> >>> types and the -Wno-pointer-arith is to accept the linux convention of
> >>> doing
> >>> pointer arithmetic on void pointers. All the others are arguably
> >>> oversights
> >>> in the code (similar silencing has to be done in i915, but I've had
> >>> better
> >>> luck with it to date). I haven't fixed the warnings because I try to
> >>> treat
> >>> it as vendor code and minimize any local changes. Will you accept
> >>> quasi-cosmetic patches from other operating systems / compilers?
> >>
> >>
> >> Yeah, sure feel free to provide patches. As long as it is only cleanup
> >> and
> >> not structural changes it should be trivial to get them merged.
> >>
> >> Especially "-Wno-missing-prototypes" and "-Wno-unused-variable" sound
> >> like
> >> something which should be trivial to fix.
> >>
> >> Regards,
> >> Christian.
> >>
> >>
> >>>
> >>> Thanks.
> >>>
> >>> -M
> >>>
> >>>
> >>> CWARNFLAGS+= -Wno-pointer-arith
> >>> CWARNFLAGS+= -Wno-pointer-sign ${CWARNFLAGS.${.IMPSRC:T}}
> >>>
> >>> CWARNFLAGS.amdgpu_acpi.c= -Wno-int-conversion
> >>> -Wno-missing-prototypes -Wno-unused-variable
> >>> CWARNFLAGS.amdgpu_amdkfd.c= -Wno-missing-prototypes
> >>> CWARNFLAGS.amdgpu_bo_list.c= -Wno-missing-prototypes
> >>> CWARNFLAGS.amdgpu_cs.c= -Wno-missing-prototypes
> >>> CWARNFLAGS.amdgpu_device.c= -Wno-format -Wno-cast-qual
> >>> CWARNFLAGS.amdgpu_fence.c= -Wno-format
> >>> CWARNFLAGS.amdgpu_gfx.c= -Wno-missing-prototypes
> >>> CWARNFLAGS.amdgpu_amdkfd_gfx_v7.c= -Wno-cast-qual
> >>> CWARNFLAGS.amdgpu_amdkfd_gfx_v8.c= -Wno-cast-qual
> >>> CWARNFLAGS.amdgpu_atpx_handler.c= -Wno-missing-prototypes
> >>> CWARNFLAGS.amdgpu_ih.c= -Wno-cast-qual
> >>> CWARNFLAGS.amdgpu_ioc32.c= -Wno-missing-prototypes
> >>> CWARNFLAGS.amdgpu_object.c= -Wno-format
> >>> CWARNFLAGS.amdgpu_mn.c= -Wno-unused-variable
> >>> CWARNFLAGS.amdgpu_pll.c= -Wno-missing-prototypes
> >>> CWARNFLAGS.amdgpu_pm.c= -Wno-missing-prototypes
> >>> -Wno-enum-conversion
> >>> CWARNFLAGS.amdgpu_ring.c= -Wno-cast-qual
> >>> CWARNFLAGS.amdgpu_ttm.c= -Wno-missing-prototypes
> >>> CWARNFLAGS.amdgpu_ucode.c=
> >>> -Wno-incompatible-pointer-types-discards-qualifiers -Wno-cast-qual
> >>> CWARNFLAGS.am
Looking for pointers on diagnosing ring test failure in amdgpu
> -Original Message- > From: Matthew Macy [mailto:mmacy at nextbsd.org] > Sent: Tuesday, June 14, 2016 4:03 PM > To: Alex Deucher > Cc: Koenig, Christian; Deucher, Alexander; Zhu, Rex; dri- > devel at lists.freedesktop.org > Subject: Re: Re: Looking for pointers on diagnosing ring test failure in > amdgpu > > > > On Tue, 14 Jun 2016 06:02:09 -0700 Alex Deucher wrote > >On Tue, Jun 14, 2016 at 4:10 AM, Christian König > > wrote: > >> Hi Matthew, > >> > >> see inline below. > >> > >> Am 14.06.2016 um 00:03 schrieb Matthew Macy: > >>> > >>> On Mon, 13 Jun 2016 01:35:34 -0700 Christian König > >>> wrote > >>> > Hi Matthew, > >>> > > >>> > sounds like the UVD block doesn't want to initialize. No idea off hand > >>> > why, could be anything. I would need the hardware here for a closer > >>> > inspection. > >>> > > >>> > For a workaround you can try to disable the UVD blokc using the > >>> > ip_block_mask module parameter (it's a bitmask of enabled blocks e.g. > >>> > 0x means all blocks enabled, UVD is bit 7 on Carrizo IIRC). > >>> > >>> > >>> When I clear bit 7 I get the following now: > >>> > >>> Jun 14 07:58:18 trainwreck kernel: drmn0: fence driver on ring 10 use gpu > >>> addr 0x40b0, cpu addr 0x0xf800bd4320b0 > >>> Jun 14 07:58:18 trainwreck kernel: drmn0: fence driver on ring 11 use gpu > >>> addr 0x40c0, cpu addr 0x0xf800bd4320c0 > >>> Jun 14 07:58:19 trainwreck kernel: drmn0: SMU check loaded firmware > >>> failed, expecting 0x17f, getting 0x0[drm:0x826d4dc4s] *ERROR* > >>> amdgpu: smc start failed > >>> Jun 14 07:58:19 trainwreck kernel: [drm:0x8269fc40s] *ERROR* > >>> hw_init 3 failed -22 > >>> Jun 14 07:58:19 trainwreck kernel: drmn0: amdgpu_init failed > >> > >> > >> UVD is optional (as long as you don't want to do hardware video > decoding) > >> but the SMU isn't. Alex, Rex any idea what's going wrong here? > >> > > > >Seems like maybe the two issues are related. Maybe some general MMIO > >issue on that particular system or a issue with the MC or gart setup? > >The firmware that the SMU loads is stored in gart and all of the > >engine rings are in gart. Maybe a problem with the IOMMU setup on the > >CPU? > > > The two issues are definitely related. They both go through a bounded delay > loop waiting for some operation to complete. > > By default FreeBSD doesn't use the IOMMU on x86 so that's not an issue. > > One thing that is different between the Elitebook (A12) and the the Thinkpad > (A10) is that the Thinkpad has both integrated and discrete GPUs. 0x6660 > matches Hainan in drm_pciids.h which I guess is GCN 1.0? Could that possibly > be an issue? I know amdgpu doesn't support pre GCN 1.1 currently, so I > would assume it would just be ignored. Nonetheless, I thought I should bring > it up just in case. amdgpu won't try and bind to it, but radeon will. If you've ported radeon to freebsd, you might want to blacklist that driver while you are testing. Some bioses also have an option to disable the dGPU, if yours does, you could try that. It shouldn't cause an issue if nothing is trying to load on it. Alex > > > vgapci0 at pci0:0:1:0:class=0x03 card=0x511617aa chip=0x98741002 > rev=0xc5 hdr=0x00 > vendor = 'Advanced Micro Devices, Inc. [AMD/ATI]' > device = 'Carrizo' > class = display > subclass = VGA > <...> > vgapci1 at pci0:5:0:0:class=0x038000 card=0x511617aa chip=0x66601002 > rev=0x83 hdr=0x00 > vendor = 'Advanced Micro Devices, Inc. [AMD/ATI]' > device = 'Sun XT [Radeon HD 8670A/8670M/8690M / R5 M330]' > class = display > > Thanks. > -M > > > > > >Alex > > > >>> Which is hard to correlate without spending a lot more quality time with > >>> the driver than I've had time for yet. > >> > >> > >> Yeah, I don't see why some blocks should fail while others seem to > >> initialize just fine. Especially since you reported it seems to work on > >> other hardware. > >> > >>> One thing that occurs to me is that Linux is usually compiled with gcc6 - > >>> has amdgpu ever been tested as compiled with clang? > >> > >> > >> Not as far as I know. We had some problems in the past even with some > gcc > >> versions because of some odd things in the BIOS headers (e.g. zero sized > >> arrays). But those issues should be fixed by now. > >> > >>> Below is a list of the warnings I have to disable in order to get amdgpu > >>> to compile without disabling Werror altogether. The -Wno-format is an > >>> artifact of clang or FreeBSD treating long long and uint64_t as distinct > >>> types and the -Wno-pointer-arith is to accept the linux convention of > doing > >>> pointer arithmetic on void pointers. All the others are arguably > oversights > >>> in the code (similar silencing has to be done in i915, but I've had better > >>> luck with it to date). I haven't fixed the warnings because I try to treat > >>> it as vendor code and minimize any
[PATCH v2 00/15] Runtime pm ref leak bonanza
On Thu, Jun 9, 2016 at 2:50 AM, Daniel Vetter wrote: > On Wed, Jun 08, 2016 at 06:47:27PM +0200, Lukas Wunner wrote: >> Second iteration of my endeavour to rid nouveau, radeon and amdgpu of >> runtime pm ref leaks. >> >> Patches 1 to 8 are identical to v1. >> >> Patch 9 of v1 modified the DRM core to turn off all CRTCs on driver >> unload. Based on feedback by Daniel Vetter, I've replaced this with >> a helper to turn off all CRTCs, which is called by nouveau, radeon >> and amdgpu on unload. In other words, this is now opt-in. >> So patch 9 of v1 is replaced with new patches 9 to 12. >> >> A by-product of patch 9 is a helper which turns off a *single* CRTC. >> This is open coded in three other places in the DRM tree and patches >> 13 to 15 refactor those to use the new helper. > > Yeah I think this makes much more sense. Please poke amd/nouveau folks for > reviews/acks, then I can merge. The amdgpu, radeon, and drm patches are: Acked-by: Alex Deucher > -Daniel > >> >> To ease reviewing, I've pushed this series to GitHub: >> https://github.com/l1k/linux/commits/drm_runpm_fixes_v2 >> >> The discussion on v1 is archived here: >> https://lists.freedesktop.org/archives/dri-devel/2016-May/thread.html#108278 >> >> Thanks, >> >> Lukas >> >> Lukas Wunner (15): >> drm/nouveau: Don't leak runtime pm ref on driver unload >> drm/nouveau: Forbid runtime pm on driver unload >> drm/radeon: Don't leak runtime pm ref on driver unload >> drm/radeon: Don't leak runtime pm ref on driver load >> drm/radeon: Forbid runtime pm on driver unload >> drm/amdgpu: Don't leak runtime pm ref on driver unload >> drm/amdgpu: Don't leak runtime pm ref on driver load >> drm/amdgpu: Forbid runtime pm on driver unload >> drm: Add helpers to turn off CRTCs >> drm/nouveau: Turn off CRTCs on driver unload >> drm/radeon: Turn off CRTCs on driver unload >> drm/amdgpu: Turn off CRTCs on driver unload >> drm: Use helper to turn off CRTC >> drm/i2c/ch7006: Use helper to turn off CRTC >> drm/nouveau/dispnv04: Use helper to turn off CRTC >> >> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 + >> drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 12 +-- >> drivers/gpu/drm/drm_crtc.c | 53 >> ++ >> drivers/gpu/drm/i2c/ch7006_drv.c | 9 ++--- >> drivers/gpu/drm/nouveau/dispnv04/disp.c| 10 -- >> drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 9 ++--- >> drivers/gpu/drm/nouveau/nouveau_display.c | 1 + >> drivers/gpu/drm/nouveau/nouveau_drm.c | 6 +++- >> drivers/gpu/drm/radeon/radeon_device.c | 4 +++ >> drivers/gpu/drm/radeon/radeon_display.c| 1 + >> drivers/gpu/drm/radeon/radeon_kms.c| 5 ++- >> include/drm/drm_crtc.h | 2 ++ >> 12 files changed, 77 insertions(+), 36 deletions(-) >> >> -- >> 2.8.1 >> > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
