[git pull] drm fixes for 4.9-rc6
Hi Linus, There seems to be an uptick in the ARM drivers sending things for fixes which is good, so I've decided to dequeue a bit early, more stuff may arrive before the weekend. This contains mediatek, arcpgu, sunxi, fsl-dcu display controller fixes along with 3 amdgpu fixes, one for a fencing issue with secondary GPUs. Dave. The following changes since commit 24399f4f0b95522e01e212537d26880227787670: Merge tag 'imx-drm-fixes-2016-11-10' of git://git.pengutronix.de/git/pza/linux into drm-fixes (2016-11-11 09:09:57 +1000) are available in the git repository at: git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.9-rc6 for you to fetch changes up to 29ed197333bdb1ccda1790bd2418f3a835de86fd: Merge branch 'drm-fixes-4.9' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2016-11-17 09:45:27 +1000) fixes for amdgpu, and a bunch of arm drivers. Alex Deucher (1): drm/amdgpu/powerplay: drop a redundant NULL check Bibby Hsieh (3): drm/mediatek: fix a typo of OD_CFG to OD_RELAYMODE drm/mediatek: set vblank_disable_allowed to true drm/mediatek: clear IRQ status before enable OVL interrupt Christophe JAILLET (2): drm/sun4i: Fix error handling drm/sun4i: Propagate error to the caller Dave Airlie (5): Merge branch 'fixes-for-v4.9-rc5' of http://git.agner.ch/git/linux-drm-fsl-dcu into drm-fixes Merge branch 'topic-arcpgu-fixes' of https://github.com/foss-for-synopsys-dwc-arc-processors/linux into drm-fixes Merge tag 'sunxi-drm-fixes-for-4.9' of https://git.kernel.org/.../mripard/linux into drm-fixes Merge branch 'mediatek-drm-fixes-2016-11-11' of https://github.com/ckhu-mediatek/linux.git-tags into drm-fixes Merge branch 'drm-fixes-4.9' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Eugeniy Paltsev (1): drm/arcpgu: Accommodate adv7511 switch to DRM bridge Jonathan Liu (1): drm/sun4i: rgb: Enable panel after controller Junzhi Zhao (3): drm/mediatek: do mtk_hdmi_send_infoframe after HDMI clock enable drm/mediatek: enhance the HDMI driving current drm/mediatek: modify the factor to make the pll_rate set in the 1G-2G range Mario Kleiner (1): drm/amdgpu: Attach exclusive fence to prime exported bo's. (v5) Maxime Ripard (1): drm/sun4i: rgb: Remove the bridge enable/disable functions Monk Liu (1): drm/amdgpu:fix vpost_needed routine Stefan Agner (3): drm/fsl-dcu: do not update when modifying irq registers drm/fsl-dcu: update all registers on flush drm/fsl-dcu: disable planes before disabling CRTC drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 27 +--- drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c| 20 ++- drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 2 - drivers/gpu/drm/arc/arcpgu_hdmi.c| 159 +++ drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 13 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c| 4 - drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 5 - drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 1 + drivers/gpu/drm/mediatek/mtk_dpi.c | 9 +- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 + drivers/gpu/drm/mediatek/mtk_hdmi.c | 17 ++- drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 42 -- drivers/gpu/drm/sun4i/sun4i_drv.c| 4 +- drivers/gpu/drm/sun4i/sun4i_rgb.c| 20 ++- 17 files changed, 117 insertions(+), 212 deletions(-)
[PATCH RFC 3/7] drm/armada: move plane state to struct armada_plane
Move more of the Armada plane state (source size, and displayed size and
position) into a state structure inside struct armada_plane.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c| 29 -
drivers/gpu/drm/armada/armada_crtc.h| 8
drivers/gpu/drm/armada/armada_overlay.c | 32 ++--
3 files changed, 42 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_crtc.c
b/drivers/gpu/drm/armada/armada_crtc.c
index 9ec7e6136bcc..719873be3beb 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -543,6 +543,19 @@ static int armada_drm_crtc_mode_set(struct drm_crtc *crtc,
interlaced = !!(adj->flags & DRM_MODE_FLAG_INTERLACE);
+ val = CFG_GRA_ENA | CFG_GRA_HSMOOTH;
+ val |= CFG_GRA_FMT(drm_fb_to_armada_fb(dcrtc->crtc.primary->fb)->fmt);
+ val |= CFG_GRA_MOD(drm_fb_to_armada_fb(dcrtc->crtc.primary->fb)->mod);
+
+ if (drm_fb_to_armada_fb(dcrtc->crtc.primary->fb)->fmt > CFG_420)
+ val |= CFG_PALETTE_ENA;
+
+ drm_to_armada_plane(crtc->primary)->state.ctrl0 = val;
+ drm_to_armada_plane(crtc->primary)->state.src_hw =
+ drm_to_armada_plane(crtc->primary)->state.dst_hw =
+ adj->crtc_hdisplay << 16 | adj->crtc_vdisplay;
+ drm_to_armada_plane(crtc->primary)->state.dst_yx = 0;
+
i = armada_drm_crtc_calc_fb(dcrtc->crtc.primary->fb,
x, y, regs, interlaced);
@@ -621,8 +634,12 @@ static int armada_drm_crtc_mode_set(struct drm_crtc *crtc,
val = adj->crtc_vdisplay << 16 | adj->crtc_hdisplay;
armada_reg_queue_set(regs, i, val, LCD_SPU_V_H_ACTIVE);
- armada_reg_queue_set(regs, i, val, LCD_SPU_GRA_HPXL_VLN);
- armada_reg_queue_set(regs, i, val, LCD_SPU_GZM_HPXL_VLN);
+ armada_reg_queue_set(regs, i,
+drm_to_armada_plane(crtc->primary)->state.src_hw,
+LCD_SPU_GRA_HPXL_VLN);
+ armada_reg_queue_set(regs, i,
+drm_to_armada_plane(crtc->primary)->state.dst_hw,
+LCD_SPU_GZM_HPXL_VLN);
armada_reg_queue_set(regs, i, (lm << 16) | rm, LCD_SPU_H_PORCH);
armada_reg_queue_set(regs, i, dcrtc->v[0].spu_v_porch, LCD_SPU_V_PORCH);
armada_reg_queue_set(regs, i, dcrtc->v[0].spu_v_h_total,
@@ -634,13 +651,7 @@ static int armada_drm_crtc_mode_set(struct drm_crtc *crtc,
ADV_VSYNCOFFEN, LCD_SPU_ADV_REG);
}
- val = CFG_GRA_ENA | CFG_GRA_HSMOOTH;
- val |= CFG_GRA_FMT(drm_fb_to_armada_fb(dcrtc->crtc.primary->fb)->fmt);
- val |= CFG_GRA_MOD(drm_fb_to_armada_fb(dcrtc->crtc.primary->fb)->mod);
-
- if (drm_fb_to_armada_fb(dcrtc->crtc.primary->fb)->fmt > CFG_420)
- val |= CFG_PALETTE_ENA;
-
+ val = drm_to_armada_plane(crtc->primary)->state.ctrl0;
if (interlaced)
val |= CFG_GRA_FTOGGLE;
diff --git a/drivers/gpu/drm/armada/armada_crtc.h
b/drivers/gpu/drm/armada/armada_crtc.h
index 04fdd22d483b..5b2b2c55589c 100644
--- a/drivers/gpu/drm/armada/armada_crtc.h
+++ b/drivers/gpu/drm/armada/armada_crtc.h
@@ -41,10 +41,18 @@ struct armada_plane_work {
struct armada_plane_work *);
};
+struct armada_plane_state {
+ u32 src_hw;
+ u32 dst_hw;
+ u32 dst_yx;
+ u32 ctrl0;
+};
+
struct armada_plane {
struct drm_planebase;
wait_queue_head_t frame_wait;
struct armada_plane_work *work;
+ struct armada_plane_state state;
};
#define drm_to_armada_plane(p) container_of(p, struct armada_plane, base)
diff --git a/drivers/gpu/drm/armada/armada_overlay.c
b/drivers/gpu/drm/armada/armada_overlay.c
index 94af7c93276e..5e979bbd5d6d 100644
--- a/drivers/gpu/drm/armada/armada_overlay.c
+++ b/drivers/gpu/drm/armada/armada_overlay.c
@@ -33,10 +33,6 @@ struct armada_ovl_plane_properties {
struct armada_ovl_plane {
struct armada_plane base;
struct drm_framebuffer *old_fb;
- uint32_t src_hw;
- uint32_t dst_hw;
- uint32_t dst_yx;
- uint32_t ctrl0;
struct {
struct armada_plane_work work;
struct armada_regs regs[13];
@@ -148,22 +144,22 @@ armada_ovl_plane_update(struct drm_plane *plane, struct
drm_crtc *crtc,
/* FIXME: overlay on an interlaced display */
/* Just updating the position/size? */
- if (plane->fb == fb && dplane->ctrl0 == ctrl0) {
+ if (plane->fb == fb && dplane->base.state.ctrl0 == ctrl0) {
val = (drm_rect_height(&src) & 0x) |
drm_rect_width(&src) >> 16;
- dplane->src_hw = val;
+ dplane->base.state.src_hw = val;
writel_relaxed(val, dcrtc->base + LCD_SPU_DMA_HPXL_VLN);
val = drm_rect_height(&dest) << 1
[PATCH RFC 6/7] drm/armada: use common helper for plane base address
Use a common helper to calculate the plane base address(es) for the
framebuffer.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c| 26 ++
drivers/gpu/drm/armada/armada_crtc.h| 2 ++
drivers/gpu/drm/armada/armada_overlay.c | 26 ++
3 files changed, 34 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_crtc.c
b/drivers/gpu/drm/armada/armada_crtc.c
index 6d3b0edde8d7..ceec930696dc 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -165,19 +165,37 @@ static void armada_drm_crtc_update(struct armada_crtc
*dcrtc)
}
}
+void armada_drm_plane_calc_addrs(u32 *addrs, struct drm_framebuffer *fb,
+ int x, int y)
+{
+ u32 addr = drm_fb_obj(fb)->dev_addr;
+ u32 pixel_format = fb->pixel_format;
+ int num_planes = drm_format_num_planes(pixel_format);
+ int i;
+
+ if (num_planes > 3)
+ num_planes = 3;
+
+ for (i = 0; i < num_planes; i++)
+ addrs[i] = addr + fb->offsets[i] + y * fb->pitches[i] +
+x * drm_format_plane_cpp(pixel_format, i);
+ for (; i < 3; i++)
+ addrs[i] = 0;
+}
+
static unsigned armada_drm_crtc_calc_fb(struct drm_framebuffer *fb,
int x, int y, struct armada_regs *regs, bool interlaced)
{
- struct armada_gem_object *obj = drm_fb_obj(fb);
unsigned pitch = fb->pitches[0];
- unsigned offset = y * pitch + x * fb->bits_per_pixel / 8;
- uint32_t addr_odd, addr_even;
+ u32 addrs[3], addr_odd, addr_even;
unsigned i = 0;
DRM_DEBUG_DRIVER("pitch %u x %d y %d bpp %d\n",
pitch, x, y, fb->bits_per_pixel);
- addr_odd = addr_even = obj->dev_addr + offset;
+ armada_drm_plane_calc_addrs(addrs, fb, x, y);
+
+ addr_odd = addr_even = addrs[0];
if (interlaced) {
addr_even += pitch;
diff --git a/drivers/gpu/drm/armada/armada_crtc.h
b/drivers/gpu/drm/armada/armada_crtc.h
index 5b2b2c55589c..b08043e8cc3b 100644
--- a/drivers/gpu/drm/armada/armada_crtc.h
+++ b/drivers/gpu/drm/armada/armada_crtc.h
@@ -62,6 +62,8 @@ int armada_drm_plane_work_queue(struct armada_crtc *dcrtc,
int armada_drm_plane_work_wait(struct armada_plane *plane, long timeout);
struct armada_plane_work *armada_drm_plane_work_cancel(
struct armada_crtc *dcrtc, struct armada_plane *plane);
+void armada_drm_plane_calc_addrs(u32 *addrs, struct drm_framebuffer *fb,
+ int x, int y);
struct armada_crtc {
struct drm_crtc crtc;
diff --git a/drivers/gpu/drm/armada/armada_overlay.c
b/drivers/gpu/drm/armada/armada_overlay.c
index 5e979bbd5d6d..41fc28b1e7d1 100644
--- a/drivers/gpu/drm/armada/armada_overlay.c
+++ b/drivers/gpu/drm/armada/armada_overlay.c
@@ -169,9 +169,8 @@ armada_ovl_plane_update(struct drm_plane *plane, struct
drm_crtc *crtc,
armada_drm_plane_work_cancel(dcrtc, &dplane->base);
if (plane->fb != fb) {
- struct armada_gem_object *obj = drm_fb_obj(fb);
- uint32_t addr[3], pixel_format;
- int i, num_planes, hsub;
+ u32 addrs[3], pixel_format;
+ int num_planes, hsub;
/*
* Take a reference on the new framebuffer - we want to
@@ -185,6 +184,8 @@ armada_ovl_plane_update(struct drm_plane *plane, struct
drm_crtc *crtc,
src_y = src.y1 >> 16;
src_x = src.x1 >> 16;
+ armada_drm_plane_calc_addrs(addrs, fb, src_x, src_y);
+
pixel_format = fb->pixel_format;
hsub = drm_format_horz_chroma_subsampling(pixel_format);
num_planes = drm_format_num_planes(pixel_format);
@@ -197,24 +198,17 @@ armada_ovl_plane_update(struct drm_plane *plane, struct
drm_crtc *crtc,
if (src_x & (hsub - 1) && num_planes == 1)
ctrl0 ^= CFG_DMA_MOD(CFG_SWAPUV);
- for (i = 0; i < num_planes; i++)
- addr[i] = obj->dev_addr + fb->offsets[i] +
- src_y * fb->pitches[i] +
- src_x * drm_format_plane_cpp(pixel_format, i);
- for (; i < ARRAY_SIZE(addr); i++)
- addr[i] = 0;
-
- armada_reg_queue_set(dplane->vbl.regs, idx, addr[0],
+ armada_reg_queue_set(dplane->vbl.regs, idx, addrs[0],
LCD_SPU_DMA_START_ADDR_Y0);
- armada_reg_queue_set(dplane->vbl.regs, idx, addr[1],
+ armada_reg_queue_set(dplane->vbl.regs, idx, addrs[1],
LCD_SPU_DMA_START_ADDR_U0);
- armada_reg_queue_set(dplane->vbl.regs, idx, addr[2],
+ armada_reg_queue_set(dplane->vbl.regs, idx, addrs[2],
LCD_SPU_DMA_START_ADDR_V0);
- armad
[PATCH RFC 1/7] drm/armada: add tracing support
Add tracing support to the Armada video overlay and interrupt code.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/Makefile | 2 +-
drivers/gpu/drm/armada/armada_crtc.c| 3 ++
drivers/gpu/drm/armada/armada_overlay.c | 7
drivers/gpu/drm/armada/armada_trace.c | 4 ++
drivers/gpu/drm/armada/armada_trace.h | 66 +
5 files changed, 81 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/armada/armada_trace.c
create mode 100644 drivers/gpu/drm/armada/armada_trace.h
diff --git a/drivers/gpu/drm/armada/Makefile b/drivers/gpu/drm/armada/Makefile
index ffd673615772..a18f156c8b66 100644
--- a/drivers/gpu/drm/armada/Makefile
+++ b/drivers/gpu/drm/armada/Makefile
@@ -1,5 +1,5 @@
armada-y := armada_crtc.o armada_drv.o armada_fb.o armada_fbdev.o \
- armada_gem.o armada_overlay.o
+ armada_gem.o armada_overlay.o armada_trace.o
armada-y += armada_510.o
armada-$(CONFIG_DEBUG_FS) += armada_debugfs.o
diff --git a/drivers/gpu/drm/armada/armada_crtc.c
b/drivers/gpu/drm/armada/armada_crtc.c
index 2f58e9e2a59c..135ad844fbb8 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -18,6 +18,7 @@
#include "armada_fb.h"
#include "armada_gem.h"
#include "armada_hw.h"
+#include "armada_trace.h"
struct armada_frame_work {
struct armada_plane_work work;
@@ -464,6 +465,8 @@ static irqreturn_t armada_drm_irq(int irq, void *arg)
*/
writel_relaxed(0, dcrtc->base + LCD_SPU_IRQ_ISR);
+ trace_armada_drm_irq(&dcrtc->crtc, stat);
+
/* Mask out those interrupts we haven't enabled */
v = stat & dcrtc->irq_ena;
diff --git a/drivers/gpu/drm/armada/armada_overlay.c
b/drivers/gpu/drm/armada/armada_overlay.c
index 1ee707ef6b8d..94af7c93276e 100644
--- a/drivers/gpu/drm/armada/armada_overlay.c
+++ b/drivers/gpu/drm/armada/armada_overlay.c
@@ -15,6 +15,7 @@
#include "armada_hw.h"
#include
#include "armada_ioctlP.h"
+#include "armada_trace.h"
struct armada_ovl_plane_properties {
uint32_t colorkey_yr;
@@ -87,6 +88,8 @@ static void armada_ovl_plane_work(struct armada_crtc *dcrtc,
{
struct armada_ovl_plane *dplane = container_of(plane, struct
armada_ovl_plane, base);
+ trace_armada_ovl_plane_work(&dcrtc->crtc, &plane->base);
+
armada_drm_crtc_update_regs(dcrtc, dplane->vbl.regs);
armada_ovl_retire_fb(dplane, NULL);
}
@@ -120,6 +123,10 @@ armada_ovl_plane_update(struct drm_plane *plane, struct
drm_crtc *crtc,
bool visible;
int ret;
+ trace_armada_ovl_plane_update(plane, crtc, fb,
+crtc_x, crtc_y, crtc_w, crtc_h,
+src_x, src_y, src_w, src_h);
+
ret = drm_plane_helper_check_update(plane, crtc, fb, &src, &dest, &clip,
BIT(DRM_ROTATE_0),
0, INT_MAX, true, false, &visible);
diff --git a/drivers/gpu/drm/armada/armada_trace.c
b/drivers/gpu/drm/armada/armada_trace.c
new file mode 100644
index ..068b336ba75f
--- /dev/null
+++ b/drivers/gpu/drm/armada/armada_trace.c
@@ -0,0 +1,4 @@
+#ifndef __CHECKER__
+#define CREATE_TRACE_POINTS
+#include "armada_trace.h"
+#endif
diff --git a/drivers/gpu/drm/armada/armada_trace.h
b/drivers/gpu/drm/armada/armada_trace.h
new file mode 100644
index ..dc0cba70fd1a
--- /dev/null
+++ b/drivers/gpu/drm/armada/armada_trace.h
@@ -0,0 +1,66 @@
+#if !defined(ARMADA_TRACE_H) || defined(TRACE_HEADER_MULTI_READ)
+#define ARMADA_TRACE_H
+
+#include
+#include
+
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM armada
+#define TRACE_INCLUDE_FILE armada_trace
+
+TRACE_EVENT(armada_drm_irq,
+ TP_PROTO(struct drm_crtc *crtc, u32 stat),
+ TP_ARGS(crtc, stat),
+ TP_STRUCT__entry(
+ __field(struct drm_crtc *, crtc)
+ __field(u32, stat)
+ ),
+ TP_fast_assign(
+ __entry->crtc = crtc;
+ __entry->stat = stat;
+ ),
+ TP_printk("crtc %p stat 0x%08x",
+ __entry->crtc, __entry->stat)
+);
+
+TRACE_EVENT(armada_ovl_plane_update,
+ TP_PROTO(struct drm_plane *plane, struct drm_crtc *crtc,
+struct drm_framebuffer *fb,
+int crtc_x, int crtc_y, unsigned crtc_w, unsigned crtc_h,
+uint32_t src_x, uint32_t src_y, uint32_t src_w, uint32_t
src_h),
+ TP_ARGS(plane, crtc, fb, crtc_x, crtc_y, crtc_w, crtc_h, src_x, src_y,
src_w, src_h),
+ TP_STRUCT__entry(
+ __field(struct drm_plane *, plane)
+ __field(struct drm_crtc *, crtc)
+ __field(struct drm_framebuffer *, fb)
+ ),
+ TP_fast_assign(
+ __entry->plane = plane;
+ __entry->crtc = crtc;
+ __entry->fb = fb;
+ ),
+ TP_printk("plane %p crtc %p fb %p",
+
[PATCH RFC 2/7] drm/armada: clean up armada_drm_plane_work_run()
Make armada_drm_plane_work_run() take the drm_plane pointer rather than
our private pointer. This allows us to localise the conversion between
these two pointers inside armada_drm_plane_work_run(), rather than at
every call site.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c | 27 +++
1 file changed, 11 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_crtc.c
b/drivers/gpu/drm/armada/armada_crtc.c
index 135ad844fbb8..9ec7e6136bcc 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -193,17 +193,18 @@ static unsigned armada_drm_crtc_calc_fb(struct
drm_framebuffer *fb,
}
static void armada_drm_plane_work_run(struct armada_crtc *dcrtc,
- struct armada_plane *plane)
+ struct drm_plane *plane)
{
- struct armada_plane_work *work = xchg(&plane->work, NULL);
+ struct armada_plane *dplane = drm_to_armada_plane(plane);
+ struct armada_plane_work *work = xchg(&dplane->work, NULL);
/* Handle any pending frame work. */
if (work) {
- work->fn(dcrtc, plane, work);
+ work->fn(dcrtc, dplane, work);
drm_crtc_vblank_put(&dcrtc->crtc);
}
- wake_up(&plane->frame_wait);
+ wake_up(&dplane->frame_wait);
}
int armada_drm_plane_work_queue(struct armada_crtc *dcrtc,
@@ -308,14 +309,12 @@ static void armada_drm_crtc_finish_fb(struct armada_crtc
*dcrtc,
static void armada_drm_vblank_off(struct armada_crtc *dcrtc)
{
- struct armada_plane *plane = drm_to_armada_plane(dcrtc->crtc.primary);
-
/*
* Tell the DRM core that vblank IRQs aren't going to happen for
* a while. This cleans up any pending vblank events for us.
*/
drm_crtc_vblank_off(&dcrtc->crtc);
- armada_drm_plane_work_run(dcrtc, plane);
+ armada_drm_plane_work_run(dcrtc, dcrtc->crtc.primary);
}
void armada_drm_crtc_gamma_set(struct drm_crtc *crtc, u16 r, u16 g, u16 b,
@@ -415,10 +414,8 @@ static void armada_drm_crtc_irq(struct armada_crtc *dcrtc,
u32 stat)
spin_lock(&dcrtc->irq_lock);
ovl_plane = dcrtc->plane;
- if (ovl_plane) {
- struct armada_plane *plane = drm_to_armada_plane(ovl_plane);
- armada_drm_plane_work_run(dcrtc, plane);
- }
+ if (ovl_plane)
+ armada_drm_plane_work_run(dcrtc, ovl_plane);
if (stat & GRA_FRAME_IRQ && dcrtc->interlaced) {
int i = stat & GRA_FRAME_IRQ0 ? 0 : 1;
@@ -448,10 +445,8 @@ static void armada_drm_crtc_irq(struct armada_crtc *dcrtc,
u32 stat)
spin_unlock(&dcrtc->irq_lock);
- if (stat & GRA_FRAME_IRQ) {
- struct armada_plane *plane =
drm_to_armada_plane(dcrtc->crtc.primary);
- armada_drm_plane_work_run(dcrtc, plane);
- }
+ if (stat & GRA_FRAME_IRQ)
+ armada_drm_plane_work_run(dcrtc, dcrtc->crtc.primary);
}
static irqreturn_t armada_drm_irq(int irq, void *arg)
@@ -1039,7 +1034,7 @@ static int armada_drm_crtc_page_flip(struct drm_crtc
*crtc,
* interrupt, so complete it now.
*/
if (dpms_blanked(dcrtc->dpms))
- armada_drm_plane_work_run(dcrtc,
drm_to_armada_plane(dcrtc->crtc.primary));
+ armada_drm_plane_work_run(dcrtc, dcrtc->crtc.primary);
return 0;
}
--
2.7.4
[PATCH 0/7] Armada DRM updates for 4.10
This series is for review only - I'll be submitting a pull request to David in due course. These patches are based on the TDA998x MALI patch, removing the drm_connector_register() call, and: * Add tracing support for overlay usage, so it's possible to use tracing to monitor how well we hit the frame display times. * plane support updates which came about due to my initial investigations into converting Armada to atomic mode set. These are mostly just mechanical changes rather than anything in-depth. * de-midlayering Armada, now that TDA998x allows for this. drivers/gpu/drm/armada/Makefile | 2 +- drivers/gpu/drm/armada/armada_crtc.c| 121 ++-- drivers/gpu/drm/armada/armada_crtc.h| 10 ++ drivers/gpu/drm/armada/armada_drm.h | 1 + drivers/gpu/drm/armada/armada_drv.c | 236 +--- drivers/gpu/drm/armada/armada_overlay.c | 65 + drivers/gpu/drm/armada/armada_trace.c | 4 + drivers/gpu/drm/armada/armada_trace.h | 66 + 8 files changed, 321 insertions(+), 184 deletions(-) create mode 100644 drivers/gpu/drm/armada/armada_trace.c create mode 100644 drivers/gpu/drm/armada/armada_trace.h -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[PATCH RFC 5/7] drm/armada: move setting primary plane position to armada_drm_primary_set()
Move the setting of the primary plane position into
armada_drm_primary_set() rather than the initialisation function.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_crtc.c
b/drivers/gpu/drm/armada/armada_crtc.c
index 5fff7cada6f5..6d3b0edde8d7 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -532,13 +532,14 @@ static void armada_drm_primary_set(struct drm_crtc *crtc,
{
struct armada_plane_state *state = &drm_to_armada_plane(plane)->state;
struct armada_crtc *dcrtc = drm_to_armada_crtc(crtc);
- struct armada_regs regs[7];
+ struct armada_regs regs[8];
bool interlaced = dcrtc->interlaced;
unsigned i;
- uint32_t ctrl0;
+ u32 ctrl0;
i = armada_drm_crtc_calc_fb(plane->fb, x, y, regs, interlaced);
+ armada_reg_queue_set(regs, i, state->dst_yx, LCD_SPU_GRA_OVSA_HPXL_VLN);
armada_reg_queue_set(regs, i, state->src_hw, LCD_SPU_GRA_HPXL_VLN);
armada_reg_queue_set(regs, i, state->dst_hw, LCD_SPU_GZM_HPXL_VLN);
@@ -1191,7 +1192,6 @@ static int armada_drm_crtc_create(struct drm_device *drm,
struct device *dev,
CFG_PDWN32x32 | CFG_PDWN16x66 | CFG_PDWN32x66 |
CFG_PDWN64x66, dcrtc->base + LCD_SPU_SRAM_PARA1);
writel_relaxed(0x2032ff81, dcrtc->base + LCD_SPU_DMA_CTRL1);
- writel_relaxed(0x, dcrtc->base + LCD_SPU_GRA_OVSA_HPXL_VLN);
writel_relaxed(dcrtc->irq_ena, dcrtc->base + LCD_SPU_IRQ_ENA);
writel_relaxed(0, dcrtc->base + LCD_SPU_IRQ_ISR);
--
2.7.4
[PATCH RFC 4/7] drm/armada: split out primary plane update
Split out the primary plane update from the mode setting.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c | 52 ++--
1 file changed, 32 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_crtc.c
b/drivers/gpu/drm/armada/armada_crtc.c
index 719873be3beb..5fff7cada6f5 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -527,6 +527,34 @@ static uint32_t armada_drm_crtc_calculate_csc(struct
armada_crtc *dcrtc)
return val;
}
+static void armada_drm_primary_set(struct drm_crtc *crtc,
+ struct drm_plane *plane, int x, int y)
+{
+ struct armada_plane_state *state = &drm_to_armada_plane(plane)->state;
+ struct armada_crtc *dcrtc = drm_to_armada_crtc(crtc);
+ struct armada_regs regs[7];
+ bool interlaced = dcrtc->interlaced;
+ unsigned i;
+ uint32_t ctrl0;
+
+ i = armada_drm_crtc_calc_fb(plane->fb, x, y, regs, interlaced);
+
+ armada_reg_queue_set(regs, i, state->src_hw, LCD_SPU_GRA_HPXL_VLN);
+ armada_reg_queue_set(regs, i, state->dst_hw, LCD_SPU_GZM_HPXL_VLN);
+
+ ctrl0 = state->ctrl0;
+ if (interlaced)
+ ctrl0 |= CFG_GRA_FTOGGLE;
+
+ armada_reg_queue_mod(regs, i, ctrl0, CFG_GRAFORMAT |
+CFG_GRA_MOD(CFG_SWAPRB | CFG_SWAPUV |
+CFG_SWAPYU | CFG_YUV2RGB) |
+CFG_PALETTE_ENA | CFG_GRA_FTOGGLE,
+LCD_SPU_DMA_CTRL0);
+ armada_reg_queue_end(regs, i);
+ armada_drm_crtc_update_regs(dcrtc, regs);
+}
+
/* The mode_config.mutex will be held for this call */
static int armada_drm_crtc_mode_set(struct drm_crtc *crtc,
struct drm_display_mode *mode, struct drm_display_mode *adj,
@@ -553,12 +581,10 @@ static int armada_drm_crtc_mode_set(struct drm_crtc *crtc,
drm_to_armada_plane(crtc->primary)->state.ctrl0 = val;
drm_to_armada_plane(crtc->primary)->state.src_hw =
drm_to_armada_plane(crtc->primary)->state.dst_hw =
- adj->crtc_hdisplay << 16 | adj->crtc_vdisplay;
+ adj->crtc_vdisplay << 16 | adj->crtc_hdisplay;
drm_to_armada_plane(crtc->primary)->state.dst_yx = 0;
- i = armada_drm_crtc_calc_fb(dcrtc->crtc.primary->fb,
- x, y, regs, interlaced);
-
+ i = 0;
rm = adj->crtc_hsync_start - adj->crtc_hdisplay;
lm = adj->crtc_htotal - adj->crtc_hsync_end;
bm = adj->crtc_vsync_start - adj->crtc_vdisplay;
@@ -634,12 +660,6 @@ static int armada_drm_crtc_mode_set(struct drm_crtc *crtc,
val = adj->crtc_vdisplay << 16 | adj->crtc_hdisplay;
armada_reg_queue_set(regs, i, val, LCD_SPU_V_H_ACTIVE);
- armada_reg_queue_set(regs, i,
-drm_to_armada_plane(crtc->primary)->state.src_hw,
-LCD_SPU_GRA_HPXL_VLN);
- armada_reg_queue_set(regs, i,
-drm_to_armada_plane(crtc->primary)->state.dst_hw,
-LCD_SPU_GZM_HPXL_VLN);
armada_reg_queue_set(regs, i, (lm << 16) | rm, LCD_SPU_H_PORCH);
armada_reg_queue_set(regs, i, dcrtc->v[0].spu_v_porch, LCD_SPU_V_PORCH);
armada_reg_queue_set(regs, i, dcrtc->v[0].spu_v_h_total,
@@ -651,16 +671,6 @@ static int armada_drm_crtc_mode_set(struct drm_crtc *crtc,
ADV_VSYNCOFFEN, LCD_SPU_ADV_REG);
}
- val = drm_to_armada_plane(crtc->primary)->state.ctrl0;
- if (interlaced)
- val |= CFG_GRA_FTOGGLE;
-
- armada_reg_queue_mod(regs, i, val, CFG_GRAFORMAT |
-CFG_GRA_MOD(CFG_SWAPRB | CFG_SWAPUV |
-CFG_SWAPYU | CFG_YUV2RGB) |
-CFG_PALETTE_ENA | CFG_GRA_FTOGGLE,
-LCD_SPU_DMA_CTRL0);
-
val = adj->flags & DRM_MODE_FLAG_NVSYNC ? CFG_VSYNC_INV : 0;
armada_reg_queue_mod(regs, i, val, CFG_VSYNC_INV, LCD_SPU_DMA_CTRL1);
@@ -669,6 +679,8 @@ static int armada_drm_crtc_mode_set(struct drm_crtc *crtc,
armada_reg_queue_end(regs, i);
armada_drm_crtc_update_regs(dcrtc, regs);
+
+ armada_drm_primary_set(crtc, crtc->primary, x, y);
spin_unlock_irqrestore(&dcrtc->irq_lock, flags);
armada_drm_crtc_update(dcrtc);
--
2.7.4
[PATCH RFC 7/7] drm/armada: de-midlayer armada
Now that the drm_connector_register() is gone from tda998x, we can
remove the mid-layer from armada-drm, eliminating the load, unload,
debugfs_init, and debugfs_cleanup callbacks from armada's drm_driver
structure. No functional changes.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_drm.h | 1 +
drivers/gpu/drm/armada/armada_drv.c | 236 +++-
2 files changed, 129 insertions(+), 108 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_drm.h
b/drivers/gpu/drm/armada/armada_drm.h
index 3b2bb6128d40..77952d559a3c 100644
--- a/drivers/gpu/drm/armada/armada_drm.h
+++ b/drivers/gpu/drm/armada/armada_drm.h
@@ -53,6 +53,7 @@ struct armada_variant {
extern const struct armada_variant armada510_ops;
struct armada_private {
+ struct drm_device drm;
struct work_struct fb_unref_work;
DECLARE_KFIFO(fb_unref, struct drm_framebuffer *, 8);
struct drm_fb_helper*fbdev;
diff --git a/drivers/gpu/drm/armada/armada_drv.c
b/drivers/gpu/drm/armada/armada_drv.c
index f5ebdd681445..e79d1a7b6047 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -49,106 +49,6 @@ void armada_drm_queue_unref_work(struct drm_device *dev,
spin_unlock_irqrestore(&dev->event_lock, flags);
}
-static int armada_drm_load(struct drm_device *dev, unsigned long flags)
-{
- struct armada_private *priv;
- struct resource *mem = NULL;
- int ret, n;
-
- for (n = 0; ; n++) {
- struct resource *r = platform_get_resource(dev->platformdev,
- IORESOURCE_MEM, n);
- if (!r)
- break;
-
- /* Resources above 64K are graphics memory */
- if (resource_size(r) > SZ_64K)
- mem = r;
- else
- return -EINVAL;
- }
-
- if (!mem)
- return -ENXIO;
-
- if (!devm_request_mem_region(dev->dev, mem->start,
- resource_size(mem), "armada-drm"))
- return -EBUSY;
-
- priv = devm_kzalloc(dev->dev, sizeof(*priv), GFP_KERNEL);
- if (!priv) {
- DRM_ERROR("failed to allocate private\n");
- return -ENOMEM;
- }
-
- platform_set_drvdata(dev->platformdev, dev);
- dev->dev_private = priv;
-
- INIT_WORK(&priv->fb_unref_work, armada_drm_unref_work);
- INIT_KFIFO(priv->fb_unref);
-
- /* Mode setting support */
- drm_mode_config_init(dev);
- dev->mode_config.min_width = 320;
- dev->mode_config.min_height = 200;
-
- /*
-* With vscale enabled, the maximum width is 1920 due to the
-* 1920 by 3 lines RAM
-*/
- dev->mode_config.max_width = 1920;
- dev->mode_config.max_height = 2048;
-
- dev->mode_config.preferred_depth = 24;
- dev->mode_config.funcs = &armada_drm_mode_config_funcs;
- drm_mm_init(&priv->linear, mem->start, resource_size(mem));
- mutex_init(&priv->linear_lock);
-
- ret = component_bind_all(dev->dev, dev);
- if (ret)
- goto err_kms;
-
- ret = drm_vblank_init(dev, dev->mode_config.num_crtc);
- if (ret)
- goto err_comp;
-
- dev->irq_enabled = true;
-
- ret = armada_fbdev_init(dev);
- if (ret)
- goto err_comp;
-
- drm_kms_helper_poll_init(dev);
-
- return 0;
-
- err_comp:
- component_unbind_all(dev->dev, dev);
- err_kms:
- drm_mode_config_cleanup(dev);
- drm_mm_takedown(&priv->linear);
- flush_work(&priv->fb_unref_work);
-
- return ret;
-}
-
-static int armada_drm_unload(struct drm_device *dev)
-{
- struct armada_private *priv = dev->dev_private;
-
- drm_kms_helper_poll_fini(dev);
- armada_fbdev_fini(dev);
-
- component_unbind_all(dev->dev, dev);
-
- drm_mode_config_cleanup(dev);
- drm_mm_takedown(&priv->linear);
- flush_work(&priv->fb_unref_work);
- dev->dev_private = NULL;
-
- return 0;
-}
-
/* These are called under the vbl_lock. */
static int armada_drm_enable_vblank(struct drm_device *dev, unsigned int pipe)
{
@@ -186,16 +86,10 @@ static const struct file_operations armada_drm_fops = {
};
static struct drm_driver armada_drm_driver = {
- .load = armada_drm_load,
.lastclose = armada_drm_lastclose,
- .unload = armada_drm_unload,
.get_vblank_counter = drm_vblank_no_hw_counter,
.enable_vblank = armada_drm_enable_vblank,
.disable_vblank = armada_drm_disable_vblank,
-#ifdef CONFIG_DEBUG_FS
- .debugfs_init = armada_drm_debugfs_init,
- .debugfs_cleanup= armada_drm_debugfs_cleanup,
-#endif
.gem_free_object_unlocked = armada_gem_free_object,
.prime_handle_to_fd = drm_gem_pr
[Bug 98724] garbled output using glDrawElementsIndirect
https://bugs.freedesktop.org/show_bug.cgi?id=98724 --- Comment #3 from Aaron Paden --- Created attachment 128031 --> https://bugs.freedesktop.org/attachment.cgi?id=128031&action=edit dmesg I use mesa-git nightly builds, and I can confirm the issue is still present as of commit a456ea17fb460a68e28c13dd4b7086dc4309f410. I've also tested a 4.9+amdgpu kernel, but I get the same issue. It could very well be an SI problem. I'm attaching a dmesg log, and here's the checksums for my firmware. a76a67f56034921ca495e1cff1cf23d100e280c3 /usr/lib/firmware/radeon/oland_rlc.bin 5f732aca7ab1b205c382002aa2ae6c7b2ff484c9 /usr/lib/firmware/radeon/oland_ce.bin 3428168970dac070766cc50b06221319085214f6 /usr/lib/firmware/radeon/oland_mc.bin fae6d65d03c902657545ea90c6ea831e6d5b315d /usr/lib/firmware/radeon/oland_me.bin d54dc87ffae276aa20c7bccf38cbd9d119aaa149 /usr/lib/firmware/radeon/OLAND_pfp.bin a0b616a90df665daee7e3de32a1ca8aaa1488280 /usr/lib/firmware/radeon/OLAND_mc2.bin 9a431b9b52ce5d2d9ff8f2e834791760d7d53867 /usr/lib/firmware/radeon/oland_pfp.bin a0b616a90df665daee7e3de32a1ca8aaa1488280 /usr/lib/firmware/radeon/OLAND_mc.bin e140372cea171e36ecaa3183ecb5bad69fd73955 /usr/lib/firmware/radeon/OLAND_smc.bin 2aeae1582b8d6064a5a905f24db5baf2009de507 /usr/lib/firmware/radeon/oland_smc.bin a9ec09b0558e3542114f7a6725763ebfaa89c7e8 /usr/lib/firmware/radeon/OLAND_me.bin 9cda1adf01acdbf7de9171524828603b74edfcd6 /usr/lib/firmware/radeon/OLAND_ce.bin d8842a871808212514f300344c9f3e336282e525 /usr/lib/firmware/radeon/oland_k_smc.bin 9e85706d8fd514934f1ca1d45b2569d45dcb976e /usr/lib/firmware/radeon/OLAND_rlc.bin -- 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/20161117/5911c7bd/attachment.html>
[PATCH] dma-buf/sync_file: enable signaling even with poll(.timeout=0)
From: Gustavo Padovan
This reverts commit ecebca79f6976ddaddfd054d699272515869ea28.
Do not enable fence callback on poll() when using fence_array causes the
fence_array to not signal.
For now we will revert the change and enable signaling everytime time
poll is called with timeout=0 as well.
Cc: Chris Wilson
Signed-off-by: Gustavo Padovan
---
drivers/dma-buf/sync_file.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index 69d8ef9..6d802f2 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -308,8 +308,7 @@ static unsigned int sync_file_poll(struct file *file,
poll_table *wait)
poll_wait(file, &sync_file->wq, wait);
- if (!poll_does_not_wait(wait) &&
- !test_and_set_bit(POLL_ENABLED, &sync_file->fence->flags)) {
+ if (!test_and_set_bit(POLL_ENABLED, &sync_file->fence->flags)) {
if (dma_fence_add_callback(sync_file->fence, &sync_file->cb,
fence_check_cb_func) < 0)
wake_up_all(&sync_file->wq);
--
2.5.5
[Bug 98693] Mad Max: Long lags when VRAM full
https://bugs.freedesktop.org/show_bug.cgi?id=98693 --- Comment #2 from Jani Kärkkäinen --- Created attachment 128034 --> https://bugs.freedesktop.org/attachment.cgi?id=128034&action=edit GALLIUM_HUD enabled with requested settings GALLIUM_HUD enabled with requested statistics with VRAM and GTT etc. Shows two laggy parts, a small lag and then a big lag. -- 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/20161117/cd770015/attachment.html>
[PATCH v5] drm/mediatek: fixed the calc method of data rate per lane
Hi, Jitao: On Wed, 2016-11-16 at 11:20 +0800, Jitao Shi wrote: > Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e. > Tlpx, Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP > mode, those signals will cause h-time larger than normal and reduce FPS. > So need to multiply a coefficient to offset the extra signal's effect. > coefficient = ((htotal*bpp/lane_number)+Tlpx+Ths_prep+Ths_zero+ >Ths_trail+Ths_exit)/(htotal*bpp/lane_number) > > Signed-off-by: Jitao Shi It looks good to me. But this patch conflict with [1] which is one patch of MT2701 series. I want to apply MT2701 patches first, so please help to refine this patch based on MT2701 patches. [1] https://patchwork.kernel.org/patch/9422821/ Regards, CK > --- > Change since v4: > - tune the calc comment more clear. > - define the phy timings as constants. > > Chnage since v3: > - wrapp the commit msg. > - fix alignment of some lines. > > Change since v2: > - move phy timing back to dsi_phy_timconfig. > > Change since v1: > - phy_timing2 and phy_timing3 refer clock cycle time. > - define values of LPX HS_PRPR HS_ZERO HS_TRAIL TA_GO TA_SURE TA_GET > DA_HS_EXIT. > --- >
[Bug 98693] Mad Max: Long lags when VRAM full
https://bugs.freedesktop.org/show_bug.cgi?id=98693 --- Comment #3 from Michel Dänzer --- Assuming your card has 1GB of VRAM, the fundamental problem is that the game wants to use more VRAM than is available. Maybe you can try reducing the game's graphics settings such that the 'requested VRAM' number drops below 1GB. -- 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/20161117/819d2c18/attachment.html>
[PATCH 3/3] MAINTAINERS: Add Archit as drm bridge maintainer
On 11/16/2016 07:38 PM, Daniel Vetter wrote: > Again something that's in the drm-misc fold. Acked-by: Archit Taneja > > Cc: Archit Taneja > Signed-off-by: Daniel Vetter > --- > MAINTAINERS | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 2fd160817603..61979cf461e7 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4039,6 +4039,12 @@ M: Dave Airlie > S: Odd Fixes > F: drivers/gpu/drm/ast/ > > +DRM DRIVERS FOR BRIDGE CHIPS > +M: Archit Taneja > +S: Maintained > +T: git git://anongit.freedesktop.org/drm/drm-misc > +F: drivers/gpu/drm/bridge/ > + > DRM DRIVER FOR BOCHS VIRTUAL GPU > M: Gerd Hoffmann > S: Odd Fixes > -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH v7 1/7] drm/hisilicon/hibmc: Add hisilicon hibmc drm master driver
Hi Sean,
Thanks for reviewing.
å¨ 2016/11/16 23:42, Sean Paul åé:
> On Wed, Nov 16, 2016 at 8:43 AM, Rongrong Zou
> wrote:
>> Add DRM master driver for Hisilicon Hibmc SoC which used for
>> Out-of-band management. Blow is the general hardware connection,
>> both the Hibmc and the host CPU are on the same mother board.
>>
>> +--+ +--+
>> | | PCIe | Hibmc |
>> |host CPU( |<->| display |
>> |arm64,x86)| |subsystem |
>> +--+ +--+
>>
>> Signed-off-by: Rongrong Zou
>> ---
>
> In the future, please keep track of the differences between patch
> versions. I noticed you have a short changelog in the cover letter,
> but it really helps to add one per-patch as well, it makes reviewing
> much simpler.
>
> Reviewed-by: Sean Paul
Sorry for that, I will pay attention to it later, thanks.
Regards,
Rongrong.
>
>
>> drivers/gpu/drm/hisilicon/Kconfig| 1 +
>> drivers/gpu/drm/hisilicon/Makefile | 1 +
>> drivers/gpu/drm/hisilicon/hibmc/Kconfig | 9 +
>> drivers/gpu/drm/hisilicon/hibmc/Makefile | 4 +
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 308
>> +++
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 41 +++
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_regs.h | 196 +++
>> 7 files changed, 560 insertions(+)
>> create mode 100644 drivers/gpu/drm/hisilicon/hibmc/Kconfig
>> create mode 100644 drivers/gpu/drm/hisilicon/hibmc/Makefile
>> create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_regs.h
>>
>> diff --git a/drivers/gpu/drm/hisilicon/Kconfig
>> b/drivers/gpu/drm/hisilicon/Kconfig
>> index 558c61b..2fd2724 100644
>> --- a/drivers/gpu/drm/hisilicon/Kconfig
>> +++ b/drivers/gpu/drm/hisilicon/Kconfig
>> @@ -2,4 +2,5 @@
>> # hisilicon drm device configuration.
>> # Please keep this list sorted alphabetically
>>
>> +source "drivers/gpu/drm/hisilicon/hibmc/Kconfig"
>> source "drivers/gpu/drm/hisilicon/kirin/Kconfig"
>> diff --git a/drivers/gpu/drm/hisilicon/Makefile
>> b/drivers/gpu/drm/hisilicon/Makefile
>> index e3f6d49..c8155bf 100644
>> --- a/drivers/gpu/drm/hisilicon/Makefile
>> +++ b/drivers/gpu/drm/hisilicon/Makefile
>> @@ -2,4 +2,5 @@
>> # Makefile for hisilicon drm drivers.
>> # Please keep this list sorted alphabetically
>>
>> +obj-$(CONFIG_DRM_HISI_HIBMC) += hibmc/
>> obj-$(CONFIG_DRM_HISI_KIRIN) += kirin/
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/Kconfig
>> b/drivers/gpu/drm/hisilicon/hibmc/Kconfig
>> new file mode 100644
>> index 000..380622a
>> --- /dev/null
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/Kconfig
>> @@ -0,0 +1,9 @@
>> +config DRM_HISI_HIBMC
>> + tristate "DRM Support for Hisilicon Hibmc"
>> + depends on DRM && PCI
>> + select DRM_KMS_HELPER
>> + select DRM_TTM
>> +
>> + help
>> + Choose this option if you have a Hisilicon Hibmc soc chipset.
>> + If M is selected the module will be called hibmc-drm.
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/Makefile
>> b/drivers/gpu/drm/hisilicon/hibmc/Makefile
>> new file mode 100644
>> index 000..47962a0
>> --- /dev/null
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/Makefile
>> @@ -0,0 +1,4 @@
>> +ccflags-y := -Iinclude/drm
>> +hibmc-drm-y := hibmc_drm_drv.o
>> +
>> +obj-$(CONFIG_DRM_HISI_HIBMC) += hibmc-drm.o
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> new file mode 100644
>> index 000..6d20580
>> --- /dev/null
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> @@ -0,0 +1,308 @@
>> +/* Hisilicon Hibmc SoC drm driver
>> + *
>> + * Based on the bochs drm driver.
>> + *
>> + * Copyright (c) 2016 Huawei Limited.
>> + *
>> + * Author:
>> + * Rongrong Zou
>> + * Rongrong Zou
>> + * Jianhua Li
>> + *
>> + * 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 "hibmc_drm_drv.h"
>> +#include "hibmc_drm_regs.h"
>> +
>> +static const struct file_operations hibmc_fops = {
>> + .owner = THIS_MODULE,
>> + .open = drm_open,
>> + .release= drm_release,
>> + .unlocked_ioctl = drm_ioctl,
>> + .compat_ioctl = drm_compat_ioctl,
>> + .poll = drm_poll,
>> + .read = drm_read,
>> + .llseek = no_llseek,
>> +};
>> +
>> +static int hibmc_enable_vblank(struct drm_device *dev, unsigned int pipe)
>> +{
>> + return 0;
>> +}
>> +
>> +static void hibmc_disable_vblank(struct drm_device *dev, unsigned
[PATCH v7 0/7] Add DRM driver for Hisilicon Hibmc
å¨ 2016/11/17 0:02, Sean Paul åé: > On Wed, Nov 16, 2016 at 11:01 AM, Sean Paul wrote: >> On Wed, Nov 16, 2016 at 8:43 AM, Rongrong Zou >> wrote: >>> This patch set adds a new drm driver for Hisilicon Hibmc. Hibmc is a >>> BMC SoC with a display controller intergrated, usually it is used on >>> server for Out-of-band management purpose. In this patch set, we just >>> support basic function for Hibmc display subsystem. Hibmc display >>> subsystem is connected to host CPU by PCIe as blow: >>> >>> +--+ +--+ >>> | | PCIe | Hibmc | >>> |host CPU( |<->| display | >>> |arm64,x86)| |subsystem | >>> +--+ +--+ >>> >>> Hardware Detail for Hibmc display subsystem >>> --- >>> >>>The display subsystem of Hibmc is show as bellow: >>>++ ++ ++ ++ >>>|| || || || >>>| FB |->| DE |->|VDAC|>|external| >>>|| || || | VGA| >>>++ ++ ++ ++ >>> >>>-DE(Display Engine) is the display controller. >>>-VDAC(Video Digital-to-Analog converter) converts the RGB diaital data >>>stream from DE to VGA analog signals. >>> >> >> For the whole series/driver: >> >> Acked-by: Sean Paul >> >> > > Also, please send those fixups for the other ttm drivers ;) with pleasure :) Regards, Rongrong. > >> >>> Change History >>> >>> Changes in v7: >>>-remove hibmc_drm_power.c/hibmc_drm_power.h, move the functions to >>> hibmc_drm_drv.c. >>>-remove hibmc_drm_de.h and move the struct defined in head file to >>> hibmc_drm_de.c. >>>-plane is initialized inside crtc, not in hibmc_kms_init(). >>>-connector is initialized inside encoder, not in hibmc_kms_init(). >>>-remove plane/crtc/encoder/connector from hibmc_drm_private struct. >>>-call drm_atomic_helper_suspend/resume in hibmc_pm_suspend/resume. >>>-remove these empty stubs because caller will do NULL check. >>> hibmc_plane_atomic_disable >>> hibmc_crtc_atomic_check >>> hibmc_encoder_disable >>> hibmc_encoder_enable >>> hibmc_encoder_atomic_check >>>-clean up in all error paths of creating driver-private framebuffer. >>> >>> Changes in v6: >>>-remove the embedded framebuffer and use a pointer of hibmc_framebuffer >>> instead. >>>-remove the deprecated drm_framebuffer_unregister_private(), >>> drm_framebuffer_unreference() will be called in hibmc_fbdev_destroy(). >>>-uninstall irq in hibmc_unload(). >>> >>> Changes in v5: >>>-rebase on v4.9-rc2. >>>-replace drm_fb_helper_set_suspend with >>> drm_fb_helper_set_suspend_unlocked. >>> and remove redundant console_lock and console_unlock. >>> >>> Changes in v4: >>>-remove unused include files, and include header file when it is needed. >>>-remove unused FLAG in Kconfig: DRM_GEM_CMA_HELPER/DRM_KMS_CMA_HELPER. >>>-remove drm_helper_disable_unused_functions, since we use DRIVER_ATOMIC. >>> >>> Changes in v3: >>>-enable KMS, in v2, only fbdev is enabled. >>>-management video memory with ttm. >>>-add vblank interrupt. >>>-remove drm_connector_register_all() and drm_connector_unregister_all(). >>>-I have a basic test with igt. >>> >>> Changes in v2: >>>-Remove self-defined macros for bit operations. >>>-Remove unused register. >>>-Replace those deprecated functions with new version of them. >>>-use drm_connector_register_all() to register connector after >>> drm_dev_register(). >>> >>> The patch v2 is at >>> https://lists.freedesktop.org/archives/dri-devel/2016-May/108661.html >>> >>> Rongrong Zou (7): >>>drm/hisilicon/hibmc: Add hisilicon hibmc drm master driver >>>drm/hisilicon/hibmc: Add video memory management >>>drm/hisilicon/hibmc: Add support for frame buffer >>>drm/hisilicon/hibmc: Add support for display engine >>>drm/hisilicon/hibmc: Add support for VDAC >>>drm/hisilicon/hibmc: Add support for vblank interrupt >>>MAINTAINERS: Update HISILICON DRM entries >>> >>> MAINTAINERS | 1 + >>> drivers/gpu/drm/hisilicon/Kconfig | 1 + >>> drivers/gpu/drm/hisilicon/Makefile| 1 + >>> drivers/gpu/drm/hisilicon/hibmc/Kconfig | 9 + >>> drivers/gpu/drm/hisilicon/hibmc/Makefile | 4 + >>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c| 477 ++ >>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 456 ++ >>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 114 + >>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 267 +++ >>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_regs.h | 196 >>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 147 ++ >>> drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 558 >>> ++ >>> 12 files cha
[PATCH] drm/msm: Remove bad calls to of_node_put()
In add_components_mdp, we parse the endpoints in MDP output ports
using the helper for_each_endpoint_of_node(). Our function calls
of_node_put() on the endpoint node before we iterate over the
next one. This is already done by the helper, and results in
trying to decrement the refcount twice.
Remove the extra of_node_put calls. This fixes warnings seen when
we try to insert the driver as a module on IFC6410.
Reported-by: Ilia Mirkin
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/msm_drv.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 46568fc..5cabe1b 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -903,10 +903,8 @@ static int add_components_mdp(struct device *mdp_dev,
* remote-endpoint isn't a component that we need to add
*/
if (of_device_is_compatible(np, "qcom,mdp4") &&
- ep.port == 0) {
- of_node_put(ep_node);
+ ep.port == 0)
continue;
- }
/*
* It's okay if some of the ports don't have a remote endpoint
@@ -914,15 +912,12 @@ static int add_components_mdp(struct device *mdp_dev,
* any external interface.
*/
intf = of_graph_get_remote_port_parent(ep_node);
- if (!intf) {
- of_node_put(ep_node);
+ if (!intf)
continue;
- }
component_match_add(master_dev, matchptr, compare_of, intf);
of_node_put(intf);
- of_node_put(ep_node);
}
return 0;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
[Bug 98753] Freeze while running the mupen64plus emulator
https://bugs.freedesktop.org/show_bug.cgi?id=98753 Michel Dänzer changed: What|Removed |Added Assignee|xorg-driver-ati at lists.x.org |dri-devel at lists.freedesktop ||.org Component|Driver/Radeon |Drivers/Gallium/radeonsi QA Contact|xorg-team at lists.x.org |dri-devel at lists.freedesktop ||.org Version|7.7 (2012.06) |unspecified Product|xorg|Mesa --- Comment #1 from Michel Dänzer --- Please attach the output of glxinfo and dmesg. If you run the game with the environment variable GALLIUM_DDEBUG=pipelined set, the radeonsi driver should detect the hang and dump some information about it in a file in ~/ddebug_dumps/ . Please attach that file here. -- 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/20161117/78c8ec18/attachment.html>
[PATCH v7 0/7] Add DRM driver for Hisilicon Hibmc
Hi Rongrong, Thanks for your hard work. For this whole series patches: Reviewed-by: Xinliang Liu Thanks, -xinliang On 16 November 2016 at 21:43, Rongrong Zou wrote: > This patch set adds a new drm driver for Hisilicon Hibmc. Hibmc is a > BMC SoC with a display controller intergrated, usually it is used on > server for Out-of-band management purpose. In this patch set, we just > support basic function for Hibmc display subsystem. Hibmc display > subsystem is connected to host CPU by PCIe as blow: > > +--+ +--+ > | | PCIe | Hibmc | > |host CPU( |<->| display | > |arm64,x86)| |subsystem | > +--+ +--+ > > Hardware Detail for Hibmc display subsystem > --- > > The display subsystem of Hibmc is show as bellow: > ++ ++ ++ ++ > || || || || > | FB |->| DE |->|VDAC|>|external| > || || || | VGA| > ++ ++ ++ ++ > > -DE(Display Engine) is the display controller. > -VDAC(Video Digital-to-Analog converter) converts the RGB diaital data > stream from DE to VGA analog signals. > > Change History > > Changes in v7: > -remove hibmc_drm_power.c/hibmc_drm_power.h, move the functions to >hibmc_drm_drv.c. > -remove hibmc_drm_de.h and move the struct defined in head file to >hibmc_drm_de.c. > -plane is initialized inside crtc, not in hibmc_kms_init(). > -connector is initialized inside encoder, not in hibmc_kms_init(). > -remove plane/crtc/encoder/connector from hibmc_drm_private struct. > -call drm_atomic_helper_suspend/resume in hibmc_pm_suspend/resume. > -remove these empty stubs because caller will do NULL check. > hibmc_plane_atomic_disable > hibmc_crtc_atomic_check > hibmc_encoder_disable > hibmc_encoder_enable > hibmc_encoder_atomic_check > -clean up in all error paths of creating driver-private framebuffer. > > Changes in v6: > -remove the embedded framebuffer and use a pointer of hibmc_framebuffer >instead. > -remove the deprecated drm_framebuffer_unregister_private(), >drm_framebuffer_unreference() will be called in hibmc_fbdev_destroy(). > -uninstall irq in hibmc_unload(). > > Changes in v5: > -rebase on v4.9-rc2. > -replace drm_fb_helper_set_suspend with drm_fb_helper_set_suspend_unlocked. >and remove redundant console_lock and console_unlock. > > Changes in v4: > -remove unused include files, and include header file when it is needed. > -remove unused FLAG in Kconfig: DRM_GEM_CMA_HELPER/DRM_KMS_CMA_HELPER. > -remove drm_helper_disable_unused_functions, since we use DRIVER_ATOMIC. > > Changes in v3: > -enable KMS, in v2, only fbdev is enabled. > -management video memory with ttm. > -add vblank interrupt. > -remove drm_connector_register_all() and drm_connector_unregister_all(). > -I have a basic test with igt. > > Changes in v2: > -Remove self-defined macros for bit operations. > -Remove unused register. > -Replace those deprecated functions with new version of them. > -use drm_connector_register_all() to register connector after >drm_dev_register(). > > The patch v2 is at > https://lists.freedesktop.org/archives/dri-devel/2016-May/108661.html > > Rongrong Zou (7): > drm/hisilicon/hibmc: Add hisilicon hibmc drm master driver > drm/hisilicon/hibmc: Add video memory management > drm/hisilicon/hibmc: Add support for frame buffer > drm/hisilicon/hibmc: Add support for display engine > drm/hisilicon/hibmc: Add support for VDAC > drm/hisilicon/hibmc: Add support for vblank interrupt > MAINTAINERS: Update HISILICON DRM entries > > MAINTAINERS | 1 + > drivers/gpu/drm/hisilicon/Kconfig | 1 + > drivers/gpu/drm/hisilicon/Makefile| 1 + > drivers/gpu/drm/hisilicon/hibmc/Kconfig | 9 + > drivers/gpu/drm/hisilicon/hibmc/Makefile | 4 + > drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c| 477 ++ > drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 456 ++ > drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 114 + > drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 267 +++ > drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_regs.h | 196 > drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 147 ++ > drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 558 > ++ > 12 files changed, 2231 insertions(+) > create mode 100644 drivers/gpu/drm/hisilicon/hibmc/Kconfig > create mode 100644 drivers/gpu/drm/hisilicon/hibmc/Makefile > create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c > create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c > create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h > create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c >
[PATCH v2 2/3] drm/bridge: Add ti-tfp410 DVI transmitter driver
On 16/11/16 16:39, Jyri Sarha wrote: > On 11/16/16 15:33, Rob Herring wrote: >>> +Optional properties >>>> + - reg: I2C address. If and only if present the driver node >>>> +should be placed into the i2c controller node where the >>>> +tfp410 i2c is connected to (the current implementation does >>>> +not yet support this). >> So this chip can work without programming I guess? >> > > Yes. Just powering it up is enough for most application. Right, and not only that, but in all the TI boards I have seen TFP410's i2c pins are not even connected. The data sheet says "[TFP410] can be controlled in two ways: 1) configuration and state pins or 2) the programmable I2C serial interface". 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/20161117/598736c8/attachment.sig>
[PATCH] vgaarb: Use dev_printk() when possible
On Wed, Nov 16, 2016 at 03:45:22PM -0600, Bjorn Helgaas wrote:
> For consistency with other device-related messages, use dev_printk() when
> possible instead of pr_*() and pci_name(). This changes messages like
> this:
>
> vgaarb: setting as boot device: PCI::01:00.0
> vgaarb: device added: PCI::01:00.0,decodes=io+mem,owns=io+mem,locks=none
> vgaarb: bridge control possible :01:00.0
>
> to this:
>
> pci :01:00.0: vgaarb: setting as boot device
> pci :01:00.0: vgaarb: device added:
> decodes=io+mem,owns=io+mem,locks=none
> pci :01:00.0: vgaarb: bridge control possible
>
> No functional change intended.
>
> Signed-off-by: Bjorn Helgaas
Hm, not convinced this is better (vgaarb is kinda not a device driver),
and the code becomes a bit more unpretty imo with placing DRV all over.
I guess if you go with a
#define vgaarb_info(dev, fmt) dev_info(dev, "vgaarg: " fmt)
or so I can be convinced.
-Daniel
> ---
> drivers/gpu/vga/vgaarb.c | 27 ---
> 1 file changed, 12 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
> index 1887f19..8a3f212 100644
> --- a/drivers/gpu/vga/vgaarb.c
> +++ b/drivers/gpu/vga/vgaarb.c
> @@ -29,7 +29,8 @@
> *
> */
>
> -#define pr_fmt(fmt) "vgaarb: " fmt
> +#define DRV "vgaarb: "
> +#define pr_fmt(fmt) DRV fmt
>
> #include
> #include
> @@ -663,7 +664,7 @@ static bool vga_arbiter_add_pci_device(struct pci_dev
> *pdev)
>*/
> if (vga_default == NULL &&
> ((vgadev->owns & VGA_RSRC_LEGACY_MASK) == VGA_RSRC_LEGACY_MASK)) {
> - pr_info("setting as boot device: PCI:%s\n", pci_name(pdev));
> + dev_info(&pdev->dev, DRV "setting as boot device\n");
> vga_set_default_device(pdev);
> }
>
> @@ -672,8 +673,7 @@ static bool vga_arbiter_add_pci_device(struct pci_dev
> *pdev)
> /* Add to the list */
> list_add(&vgadev->list, &vga_list);
> vga_count++;
> - pr_info("device added: PCI:%s,decodes=%s,owns=%s,locks=%s\n",
> - pci_name(pdev),
> + dev_info(&pdev->dev, DRV "device added: decodes=%s,owns=%s,locks=%s\n",
> vga_iostate_to_str(vgadev->decodes),
> vga_iostate_to_str(vgadev->owns),
> vga_iostate_to_str(vgadev->locks));
> @@ -732,8 +732,7 @@ static inline void vga_update_device_decodes(struct
> vga_device *vgadev,
> decodes_unlocked = vgadev->locks & decodes_removed;
> vgadev->decodes = new_decodes;
>
> - pr_info("device changed decodes:
> PCI:%s,olddecodes=%s,decodes=%s:owns=%s\n",
> - pci_name(vgadev->pdev),
> + dev_info(&vgadev->pdev->dev, DRV "device changed decodes:
> olddecodes=%s,decodes=%s:owns=%s\n",
> vga_iostate_to_str(old_decodes),
> vga_iostate_to_str(vgadev->decodes),
> vga_iostate_to_str(vgadev->owns));
> @@ -1206,7 +1205,7 @@ static ssize_t vga_arb_write(struct file *file, const
> char __user *buf,
> pr_debug("vgadev %p\n", vgadev);
> if (vgadev == NULL) {
> if (pdev) {
> - pr_err("this pci device is not a vga device\n");
> + dev_err(&pdev->dev, DRV "this device is not a
> vga device\n");
> pci_dev_put(pdev);
> }
>
> @@ -1408,6 +1407,7 @@ static int __init vga_arb_device_init(void)
> int rc;
> struct pci_dev *pdev;
> struct vga_device *vgadev;
> + struct device *dev;
>
> rc = misc_register(&vga_arb_device);
> if (rc < 0)
> @@ -1440,6 +1440,7 @@ static int __init vga_arb_device_init(void)
> int i;
>
> limit = screen_info.lfb_base + screen_info.lfb_size;
> + dev = &vgadev->pdev->dev;
>
> /* Does firmware framebuffer belong to us? */
> for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
> @@ -1458,20 +1459,16 @@ static int __init vga_arb_device_init(void)
> continue;
>
> if (!vga_default_device())
> - pr_info("setting as boot device: PCI:%s\n",
> - pci_name(vgadev->pdev));
> + dev_info(dev, DRV "setting as boot device\n");
> else if (vgadev->pdev != vga_default_device())
> - pr_info("overriding boot device: PCI:%s\n",
> - pci_name(vgadev->pdev));
> + dev_info(dev, DRV "overriding boot device\n");
> vga_set_default_device(vgadev->pdev);
> }
> #endif
> if (vgadev->bridge_has_one_vga)
> - pr_info("bridge control possible %s\n",
> - pci_name(vgadev->pdev));
> + dev_info(dev, DRV "bridge control possible\n");
[PATCH] drm: document standard connector properties
There's a really big pile of additional connector properties, a lot of
them standardized. But they're all for specific outputs (panels, TV,
scaling, ...) so I left them out for now since this is enough for a
start.
I typed this to give Manasi a place to add her new link status
property documentation.
v2: forgot to git add all the bits (Manasi).
Cc: Manasi Navare
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms.rst | 6 ++
drivers/gpu/drm/drm_connector.c | 42 +
2 files changed, 48 insertions(+)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 568f3c2b6e46..f19757b1736a 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -260,6 +260,12 @@ Property Types and Blob Property Support
.. kernel-doc:: drivers/gpu/drm/drm_property.c
:export:
+Standard Connector Properties
+-
+
+.. kernel-doc:: drivers/gpu/drm/drm_connector.c
+ :doc: standard connector properties
+
Plane Composition Properties
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b5c6a8ee831e..385efbc6a9ef 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -588,6 +588,48 @@ static const struct drm_prop_enum_list
drm_tv_subconnector_enum_list[] = {
DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
drm_tv_subconnector_enum_list)
+/**
+ * DOC: standard connector properties
+ *
+ * DRM connectors have a few standardized properties:
+ *
+ * EDID:
+ * Blob property which contains the current EDID read from the sink. This
+ * is useful to parse sink identification information like vendor, model
+ * and serial. Drivers should update this property by calling
+ * drm_mode_connector_update_edid_property(), usually after having parsed
+ * the EDID using drm_add_edid_modes(). Userspace cannot change this
+ * property.
+ * DPMS:
+ * Legacy property for setting the power state of the connector. For atomic
+ * drivers this is only provided for backwards compatibility with existing
+ * drivers, it remaps to controlling the "ACTIVE" property on the CRTC the
+ * connector is linked to. Drivers should never set this property directly,
+ * it is handled by the DRM core by calling the ->dpms() callback in
+ * &drm_connector_funcs. Atomic drivers should implement this hook using
+ * drm_atomic_helper_connector_dpms(). This is the only property standard
+ * connector property that userspace can change.
+ * PATH:
+ * Connector path property to identify how this sink is physically
+ * connected. Used by DP MST. This should be set by calling
+ * drm_mode_connector_set_path_property(), in the case of DP MST with the
+ * path property the MST manager created. Userspace cannot change this
+ * property.
+ * TILE:
+ * Connector tile group property to indicate how a set of DRM connector
+ * compose together into one logical screen. This is used by both high-res
+ * external screens (often only using a single cable, but exposing multiple
+ * DP MST sinks), or high-res integrated panels (like dual-link DSI).
+ * Drivers should update this property using
+ * drm_mode_connector_set_tile_property(). Userspace cannot change this
+ * property.
+ *
+ * Connectors also have one standardized atomic property:
+ *
+ * CRTC_ID:
+ * Mode object ID of the &drm_crtc this connector should be connected to.
+ */
+
int drm_connector_create_standard_properties(struct drm_device *dev)
{
struct drm_property *prop;
--
2.10.2
[PATCH] dma-buf/sync_file: enable signaling even with poll(.timeout=0)
On Thu, Nov 17, 2016 at 11:57:30AM +0900, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> This reverts commit ecebca79f6976ddaddfd054d699272515869ea28.
When doing a revert please don't change the subject of the revert, at
least if you didn't change anything in the resulting diff. That way
reverts jump out a lot more, which I think is useful.
-Daniel
>
> Do not enable fence callback on poll() when using fence_array causes the
> fence_array to not signal.
>
> For now we will revert the change and enable signaling everytime time
> poll is called with timeout=0 as well.
>
> Cc: Chris Wilson
> Signed-off-by: Gustavo Padovan
> ---
> drivers/dma-buf/sync_file.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
> index 69d8ef9..6d802f2 100644
> --- a/drivers/dma-buf/sync_file.c
> +++ b/drivers/dma-buf/sync_file.c
> @@ -308,8 +308,7 @@ static unsigned int sync_file_poll(struct file *file,
> poll_table *wait)
>
> poll_wait(file, &sync_file->wq, wait);
>
> - if (!poll_does_not_wait(wait) &&
> - !test_and_set_bit(POLL_ENABLED, &sync_file->fence->flags)) {
> + if (!test_and_set_bit(POLL_ENABLED, &sync_file->fence->flags)) {
> if (dma_fence_add_callback(sync_file->fence, &sync_file->cb,
> fence_check_cb_func) < 0)
> wake_up_all(&sync_file->wq);
> --
> 2.5.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH] [RFC] drm: Nerf DRM_CONTROL nodes
On Fri, Oct 28, 2016 at 10:10:50AM +0200, Daniel Vetter wrote:
> Looking at the ioctl permission checks I noticed that it's impossible
> to import gem buffers into a control nodes, and fd2handle/handle2fd
> also don't work, so no joy with dma-bufs.
>
> The only way to do anything with a control node is by drawing stuff
> into a dumb buffer and displaying that. I suspect control nodes are an
> entirely unused thing, and a cursory check shows that there does not
> seem to be any callers of drmOpenControl nor of the other drmOpen
> functions using DRM_MODE_CONTROL.
>
> Since I don't like dead uabi, let's remove it. But since this would be
> a really big change I think it's better to start out small by simply
> not registering anything. We can garbage-collect the dead code later
> on, once we're sure it's really not used anywhere.
>
> Signed-off-by: Daniel Vetter
Applied with Dave's irc-ack to drm-misc.
-Daniel
> ---
> drivers/gpu/drm/drm_drv.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 6efdba4993fc..f085e28ffc6f 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -517,12 +517,6 @@ int drm_dev_init(struct drm_device *dev,
> goto err_free;
> }
>
> - if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> - ret = drm_minor_alloc(dev, DRM_MINOR_CONTROL);
> - if (ret)
> - goto err_minors;
> - }
> -
> if (drm_core_check_feature(dev, DRIVER_RENDER)) {
> ret = drm_minor_alloc(dev, DRM_MINOR_RENDER);
> if (ret)
> --
> 2.10.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH v4 1/2] drm/bridge: dumb-vga-dac: Support a VDD regulator supply
Hi,
Thanks for the patch.
On 11/16/2016 09:12 PM, Chen-Yu Tsai wrote:
> Some dumb VGA DACs are active components which require external power.
> Add support for specifying a regulator as its power supply.
>
> Signed-off-by: Chen-Yu Tsai
> Acked-by: Rob Herring
> ---
> .../bindings/display/bridge/dumb-vga-dac.txt | 2 ++
> drivers/gpu/drm/bridge/dumb-vga-dac.c | 35
> ++
> 2 files changed, 37 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
> b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
> index 003bc246a270..164cbb15f04c 100644
> --- a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
> @@ -16,6 +16,8 @@ graph bindings specified in
> Documentation/devicetree/bindings/graph.txt.
> - Video port 0 for RGB input
> - Video port 1 for VGA output
>
> +Optional properties:
> +- vdd-supply: Power supply for DAC
>
> Example
> ---
> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> index afec232185a7..15b549f94307 100644
> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> @@ -12,6 +12,7 @@
>
> #include
> #include
> +#include
>
> #include
> #include
> @@ -23,6 +24,7 @@ struct dumb_vga {
> struct drm_connectorconnector;
>
> struct i2c_adapter *ddc;
> + struct regulator*vdd;
> };
>
> static inline struct dumb_vga *
> @@ -124,8 +126,32 @@ static int dumb_vga_attach(struct drm_bridge *bridge)
> return 0;
> }
>
> +static void dumb_vga_enable(struct drm_bridge *bridge)
> +{
> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
> + int ret = 0;
> +
> + if (vga->vdd)
> + ret = regulator_enable(vga->vdd);
> +
> + if (ret) {
> + DRM_ERROR("Failed to enable vdd regulator: %d\n", ret);
> + return;
We don't need this return for now. If you're okay with it, can I fix this
and queue to misc?
Thanks,
Archit
> + }
> +}
> +
> +static void dumb_vga_disable(struct drm_bridge *bridge)
> +{
> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
> +
> + if (vga->vdd)
> + regulator_disable(vga->vdd);
> +}
> +
> static const struct drm_bridge_funcs dumb_vga_bridge_funcs = {
> .attach = dumb_vga_attach,
> + .enable = dumb_vga_enable,
> + .disable= dumb_vga_disable,
> };
>
> static struct i2c_adapter *dumb_vga_retrieve_ddc(struct device *dev)
> @@ -169,6 +195,15 @@ static int dumb_vga_probe(struct platform_device *pdev)
> return -ENOMEM;
> platform_set_drvdata(pdev, vga);
>
> + vga->vdd = devm_regulator_get_optional(&pdev->dev, "vdd");
> + if (IS_ERR(vga->vdd)) {
> + ret = PTR_ERR(vga->vdd);
> + if (ret == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + vga->vdd = NULL;
> + dev_dbg(&pdev->dev, "No vdd regulator found: %d\n", ret);
> + }
> +
> vga->ddc = dumb_vga_retrieve_ddc(&pdev->dev);
> if (IS_ERR(vga->ddc)) {
> if (PTR_ERR(vga->ddc) == -ENODEV) {
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
[PULL] drm-intel-fixes
Hi Dave, here's a small batch of i915 fixes. I was hoping to get these to -rc6 as it's getting kind of close to 4.9 release, but looks like I missed your pull to Linus. Any chance for another pull? BR, Jani. The following changes since commit 54905ab5fe7aa453610e31cec640e528aaedb2e2: drm/i915: Limit Valleyview and earlier to only using mappable scanout (2016-11-07 19:02:35 +0200) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2016-11-17 for you to fetch changes up to bc9db5ad3253c8e17969bd802c47b73e63f125ab: drm/i915: Assume non-DP++ port if dvo_port is HDMI and there's no AUX ch specified in the VBT (2016-11-16 10:06:14 +0200) Chris Wilson (1): drm/i915: Mark CPU cache as dirty when used for rendering Ville Syrjälä (3): drm/i915: Grab the rotation from the passed plane state for VLV sprites drm/i915: Refresh that status of MST capable connectors in ->detect() drm/i915: Assume non-DP++ port if dvo_port is HDMI and there's no AUX ch specified in the VBT drivers/gpu/drm/i915/i915_gem_execbuffer.c | 8 drivers/gpu/drm/i915/intel_bios.c | 30 ++ drivers/gpu/drm/i915/intel_dp.c| 10 -- drivers/gpu/drm/i915/intel_sprite.c| 2 +- drivers/gpu/drm/i915/intel_vbt_defs.h | 3 ++- 5 files changed, 33 insertions(+), 20 deletions(-) -- Jani Nikula, Intel Open Source Technology Center
[PATCH] drm: document standard connector properties
On 11/17/2016 01:08 PM, Daniel Vetter wrote:
> There's a really big pile of additional connector properties, a lot of
> them standardized. But they're all for specific outputs (panels, TV,
> scaling, ...) so I left them out for now since this is enough for a
> start.
>
> I typed this to give Manasi a place to add her new link status
> property documentation.
>
> v2: forgot to git add all the bits (Manasi).
>
> Cc: Manasi Navare
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/drm-kms.rst | 6 ++
> drivers/gpu/drm/drm_connector.c | 42
> +
> 2 files changed, 48 insertions(+)
>
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 568f3c2b6e46..f19757b1736a 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -260,6 +260,12 @@ Property Types and Blob Property Support
> .. kernel-doc:: drivers/gpu/drm/drm_property.c
> :export:
>
> +Standard Connector Properties
> +-
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_connector.c
> + :doc: standard connector properties
> +
> Plane Composition Properties
>
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index b5c6a8ee831e..385efbc6a9ef 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -588,6 +588,48 @@ static const struct drm_prop_enum_list
> drm_tv_subconnector_enum_list[] = {
> DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
>drm_tv_subconnector_enum_list)
>
> +/**
> + * DOC: standard connector properties
> + *
> + * DRM connectors have a few standardized properties:
> + *
> + * EDID:
> + * Blob property which contains the current EDID read from the sink. This
> + * is useful to parse sink identification information like vendor, model
> + * and serial. Drivers should update this property by calling
> + * drm_mode_connector_update_edid_property(), usually after having parsed
> + * the EDID using drm_add_edid_modes(). Userspace cannot change this
> + * property.
> + * DPMS:
> + * Legacy property for setting the power state of the connector. For atomic
> + * drivers this is only provided for backwards compatibility with existing
> + * drivers, it remaps to controlling the "ACTIVE" property on the CRTC the
> + * connector is linked to. Drivers should never set this property directly,
> + * it is handled by the DRM core by calling the ->dpms() callback in
> + * &drm_connector_funcs. Atomic drivers should implement this hook using
> + * drm_atomic_helper_connector_dpms(). This is the only property standard
> + * connector property that userspace can change.
> + * PATH:
> + * Connector path property to identify how this sink is physically
> + * connected. Used by DP MST. This should be set by calling
> + * drm_mode_connector_set_path_property(), in the case of DP MST with the
> + * path property the MST manager created. Userspace cannot change this
> + * property.
> + * TILE:
> + * Connector tile group property to indicate how a set of DRM connector
> + * compose together into one logical screen. This is used by both high-res
> + * external screens (often only using a single cable, but exposing multiple
> + * DP MST sinks), or high-res integrated panels (like dual-link DSI).
> + * Drivers should update this property using
> + * drm_mode_connector_set_tile_property(). Userspace cannot change this
> + * property.
This contradicts the comment on @tile_blob_ptr in drm_connector.h a bit w.r.t
high-res panels.
Maybe the comment here can say "...or high-res integrated panels which aren't
genlocked"
Archit
> + *
> + * Connectors also have one standardized atomic property:
> + *
> + * CRTC_ID:
> + * Mode object ID of the &drm_crtc this connector should be connected to.
> + */
> +
> int drm_connector_create_standard_properties(struct drm_device *dev)
> {
> struct drm_property *prop;
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH] drm: document standard connector properties
There's a really big pile of additional connector properties, a lot of
them standardized. But they're all for specific outputs (panels, TV,
scaling, ...) so I left them out for now since this is enough for a
start.
I typed this to give Manasi a place to add her new link status
property documentation.
v2: forgot to git add all the bits (Manasi).
v3: Be more epxlicit about integrated tiled panels (Archit)
Cc: Manasi Navare
Cc: Archit Taneja
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms.rst | 6 ++
drivers/gpu/drm/drm_connector.c | 44 +
2 files changed, 50 insertions(+)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 568f3c2b6e46..f19757b1736a 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -260,6 +260,12 @@ Property Types and Blob Property Support
.. kernel-doc:: drivers/gpu/drm/drm_property.c
:export:
+Standard Connector Properties
+-
+
+.. kernel-doc:: drivers/gpu/drm/drm_connector.c
+ :doc: standard connector properties
+
Plane Composition Properties
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b5c6a8ee831e..5a4526289392 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -588,6 +588,50 @@ static const struct drm_prop_enum_list
drm_tv_subconnector_enum_list[] = {
DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
drm_tv_subconnector_enum_list)
+/**
+ * DOC: standard connector properties
+ *
+ * DRM connectors have a few standardized properties:
+ *
+ * EDID:
+ * Blob property which contains the current EDID read from the sink. This
+ * is useful to parse sink identification information like vendor, model
+ * and serial. Drivers should update this property by calling
+ * drm_mode_connector_update_edid_property(), usually after having parsed
+ * the EDID using drm_add_edid_modes(). Userspace cannot change this
+ * property.
+ * DPMS:
+ * Legacy property for setting the power state of the connector. For atomic
+ * drivers this is only provided for backwards compatibility with existing
+ * drivers, it remaps to controlling the "ACTIVE" property on the CRTC the
+ * connector is linked to. Drivers should never set this property directly,
+ * it is handled by the DRM core by calling the ->dpms() callback in
+ * &drm_connector_funcs. Atomic drivers should implement this hook using
+ * drm_atomic_helper_connector_dpms(). This is the only property standard
+ * connector property that userspace can change.
+ * PATH:
+ * Connector path property to identify how this sink is physically
+ * connected. Used by DP MST. This should be set by calling
+ * drm_mode_connector_set_path_property(), in the case of DP MST with the
+ * path property the MST manager created. Userspace cannot change this
+ * property.
+ * TILE:
+ * Connector tile group property to indicate how a set of DRM connector
+ * compose together into one logical screen. This is used by both high-res
+ * external screens (often only using a single cable, but exposing multiple
+ * DP MST sinks), or high-res integrated panels (like dual-link DSI) which
+ * are not gen-locked. Note that for tiled panels which are genlocked, like
+ * dual-link LVDS or dual-link DSI, the driver should try to not expose the
+ * tiling and virtualize both &drm_crtc and &drm_plane if needed. Drivers
+ * should update this value using drm_mode_connector_set_tile_property().
+ * Userspace cannot change this property.
+ *
+ * Connectors also have one standardized atomic property:
+ *
+ * CRTC_ID:
+ * Mode object ID of the &drm_crtc this connector should be connected to.
+ */
+
int drm_connector_create_standard_properties(struct drm_device *dev)
{
struct drm_property *prop;
--
2.10.2
[PATCH 2/3] MAINTAINERS: Move dma-buf to drm-misc git
Hi Daniel, Thanks for the patch. On 16-Nov-2016 7:38 PM, "Daniel Vetter" wrote: > > Sumit still takes care about dma-buf, but we've merged the trees > together since way too much overlap. And Gustavo is also part of the > drm-misc team to be able to help out. > Of course, this is to help the current rapid development that is closely inter-related to drm changes. > Cc: Sumit Semwal > Cc: Gustavo Padovan > Signed-off-by: Daniel Vetter Acked-by: Sumit Semwal > --- > MAINTAINERS | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index f1f0a3983be8..2fd160817603 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -3911,7 +3911,7 @@ F:include/linux/dma-buf* > F: include/linux/reservation.h > F: include/linux/*fence.h > F: Documentation/dma-buf-sharing.txt > -T: git git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git > +T: git git://anongit.freedesktop.org/drm/drm-misc > > SYNC FILE FRAMEWORK > M: Sumit Semwal > @@ -3924,7 +3924,7 @@ F:drivers/dma-buf/sw_sync.c > F: include/linux/sync_file.h > F: include/uapi/linux/sync_file.h > F: Documentation/sync_file.txt > -T: git git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git > +T: git git://anongit.freedesktop.org/drm/drm-misc > > DMA GENERIC OFFLOAD ENGINE SUBSYSTEM > M: Vinod Koul > -- > 2.10.2 > Best regards, Sumit. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161117/650bbc22/attachment.html>
[PATCH v4 1/2] drm/bridge: dumb-vga-dac: Support a VDD regulator supply
On 11/17/2016 01:25 PM, Chen-Yu Tsai wrote:
> On Thu, Nov 17, 2016 at 3:48 PM, Archit Taneja
> wrote:
>> Hi,
>>
>> Thanks for the patch.
>>
>>
>> On 11/16/2016 09:12 PM, Chen-Yu Tsai wrote:
>>>
>>> Some dumb VGA DACs are active components which require external power.
>>> Add support for specifying a regulator as its power supply.
>>>
>>> Signed-off-by: Chen-Yu Tsai
>>> Acked-by: Rob Herring
>>> ---
>>> .../bindings/display/bridge/dumb-vga-dac.txt | 2 ++
>>> drivers/gpu/drm/bridge/dumb-vga-dac.c | 35
>>> ++
>>> 2 files changed, 37 insertions(+)
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>>> b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>>> index 003bc246a270..164cbb15f04c 100644
>>> --- a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>>> +++ b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>>> @@ -16,6 +16,8 @@ graph bindings specified in
>>> Documentation/devicetree/bindings/graph.txt.
>>> - Video port 0 for RGB input
>>> - Video port 1 for VGA output
>>>
>>> +Optional properties:
>>> +- vdd-supply: Power supply for DAC
>>>
>>> Example
>>> ---
>>> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>> b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>> index afec232185a7..15b549f94307 100644
>>> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>> @@ -12,6 +12,7 @@
>>>
>>> #include
>>> #include
>>> +#include
>>>
>>> #include
>>> #include
>>> @@ -23,6 +24,7 @@ struct dumb_vga {
>>> struct drm_connectorconnector;
>>>
>>> struct i2c_adapter *ddc;
>>> + struct regulator*vdd;
>>> };
>>>
>>> static inline struct dumb_vga *
>>> @@ -124,8 +126,32 @@ static int dumb_vga_attach(struct drm_bridge *bridge)
>>> return 0;
>>> }
>>>
>>> +static void dumb_vga_enable(struct drm_bridge *bridge)
>>> +{
>>> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>>> + int ret = 0;
>>> +
>>> + if (vga->vdd)
>>> + ret = regulator_enable(vga->vdd);
>>> +
>>> + if (ret) {
>>> + DRM_ERROR("Failed to enable vdd regulator: %d\n", ret);
>>> + return;
>>
>>
>> We don't need this return for now. If you're okay with it, can I fix this
>> and queue to misc?
>
> Yes, please!
pushed to drm-misc.
Thanks,
Archit
>
> Thanks
> ChenYu
>
>>
>> Thanks,
>> Archit
>>
>>
>>> + }
>>> +}
>>> +
>>> +static void dumb_vga_disable(struct drm_bridge *bridge)
>>> +{
>>> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>>> +
>>> + if (vga->vdd)
>>> + regulator_disable(vga->vdd);
>>> +}
>>> +
>>> static const struct drm_bridge_funcs dumb_vga_bridge_funcs = {
>>> .attach = dumb_vga_attach,
>>> + .enable = dumb_vga_enable,
>>> + .disable= dumb_vga_disable,
>>> };
>>>
>>> static struct i2c_adapter *dumb_vga_retrieve_ddc(struct device *dev)
>>> @@ -169,6 +195,15 @@ static int dumb_vga_probe(struct platform_device
>>> *pdev)
>>> return -ENOMEM;
>>> platform_set_drvdata(pdev, vga);
>>>
>>> + vga->vdd = devm_regulator_get_optional(&pdev->dev, "vdd");
>>> + if (IS_ERR(vga->vdd)) {
>>> + ret = PTR_ERR(vga->vdd);
>>> + if (ret == -EPROBE_DEFER)
>>> + return -EPROBE_DEFER;
>>> + vga->vdd = NULL;
>>> + dev_dbg(&pdev->dev, "No vdd regulator found: %d\n", ret);
>>> + }
>>> +
>>> vga->ddc = dumb_vga_retrieve_ddc(&pdev->dev);
>>> if (IS_ERR(vga->ddc)) {
>>> if (PTR_ERR(vga->ddc) == -ENODEV) {
>>>
>>
>> --
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>> a Linux Foundation Collaborative Project
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH] drm: document standard connector properties
On 11/17/2016 02:26 PM, Daniel Vetter wrote:
> There's a really big pile of additional connector properties, a lot of
> them standardized. But they're all for specific outputs (panels, TV,
> scaling, ...) so I left them out for now since this is enough for a
> start.
>
> I typed this to give Manasi a place to add her new link status
> property documentation.
Reviewed-by: Archit Taneja
>
> v2: forgot to git add all the bits (Manasi).
>
> v3: Be more epxlicit about integrated tiled panels (Archit)
>
> Cc: Manasi Navare
> Cc: Archit Taneja
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/drm-kms.rst | 6 ++
> drivers/gpu/drm/drm_connector.c | 44
> +
> 2 files changed, 50 insertions(+)
>
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 568f3c2b6e46..f19757b1736a 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -260,6 +260,12 @@ Property Types and Blob Property Support
> .. kernel-doc:: drivers/gpu/drm/drm_property.c
> :export:
>
> +Standard Connector Properties
> +-
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_connector.c
> + :doc: standard connector properties
> +
> Plane Composition Properties
>
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index b5c6a8ee831e..5a4526289392 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -588,6 +588,50 @@ static const struct drm_prop_enum_list
> drm_tv_subconnector_enum_list[] = {
> DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
>drm_tv_subconnector_enum_list)
>
> +/**
> + * DOC: standard connector properties
> + *
> + * DRM connectors have a few standardized properties:
> + *
> + * EDID:
> + * Blob property which contains the current EDID read from the sink. This
> + * is useful to parse sink identification information like vendor, model
> + * and serial. Drivers should update this property by calling
> + * drm_mode_connector_update_edid_property(), usually after having parsed
> + * the EDID using drm_add_edid_modes(). Userspace cannot change this
> + * property.
> + * DPMS:
> + * Legacy property for setting the power state of the connector. For atomic
> + * drivers this is only provided for backwards compatibility with existing
> + * drivers, it remaps to controlling the "ACTIVE" property on the CRTC the
> + * connector is linked to. Drivers should never set this property directly,
> + * it is handled by the DRM core by calling the ->dpms() callback in
> + * &drm_connector_funcs. Atomic drivers should implement this hook using
> + * drm_atomic_helper_connector_dpms(). This is the only property standard
> + * connector property that userspace can change.
> + * PATH:
> + * Connector path property to identify how this sink is physically
> + * connected. Used by DP MST. This should be set by calling
> + * drm_mode_connector_set_path_property(), in the case of DP MST with the
> + * path property the MST manager created. Userspace cannot change this
> + * property.
> + * TILE:
> + * Connector tile group property to indicate how a set of DRM connector
> + * compose together into one logical screen. This is used by both high-res
> + * external screens (often only using a single cable, but exposing multiple
> + * DP MST sinks), or high-res integrated panels (like dual-link DSI) which
> + * are not gen-locked. Note that for tiled panels which are genlocked, like
> + * dual-link LVDS or dual-link DSI, the driver should try to not expose the
> + * tiling and virtualize both &drm_crtc and &drm_plane if needed. Drivers
> + * should update this value using drm_mode_connector_set_tile_property().
> + * Userspace cannot change this property.
> + *
> + * Connectors also have one standardized atomic property:
> + *
> + * CRTC_ID:
> + * Mode object ID of the &drm_crtc this connector should be connected to.
> + */
> +
> int drm_connector_create_standard_properties(struct drm_device *dev)
> {
> struct drm_property *prop;
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v12 0/4] New debugfs API for capturing CRC of frames
Hi, here are the patches that remain to be merged in this series. They have been rebased and I have also addressed two smaller comments: - Move locking into drm_crtc_add_crc_entry (Daniel Vetter). - Define intel_crtc_set_crc_source as NULL if !CONFIG_DEBUG_FS (Jani Nikula). Thanks, Tomeu Tomeu Vizoso (4): drm/i915/debugfs: Move out pipe CRC code drm: Move locking into drm_debugfs_crtc_crc_add drm/i915: Use new CRC debugfs API drm/i915: Put "cooked" vlank counters in frame CRC lines drivers/gpu/drm/drm_debugfs_crc.c |9 +- drivers/gpu/drm/i915/Makefile |2 +- drivers/gpu/drm/i915/i915_debugfs.c | 882 +--- drivers/gpu/drm/i915/i915_drv.h |1 + drivers/gpu/drm/i915/i915_irq.c | 81 ++- drivers/gpu/drm/i915/intel_display.c |1 + drivers/gpu/drm/i915/intel_drv.h | 11 + drivers/gpu/drm/i915/intel_pipe_crc.c | 1009 + 8 files changed, 1089 insertions(+), 907 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_pipe_crc.c -- 2.7.4
[PATCH v12 1/4] drm/i915/debugfs: Move out pipe CRC code
In preparation to using a generic API in the DRM core for continuous CRC
generation, move the related code out of i915_debugfs.c into a new file.
Eventually, only the Intel-specific code will remain in this new file.
v2: Rebased.
v6: Rebased.
v7: Fix whitespace issue.
v9: Have intel_display_crc_init accept a drm_i915_private instead.
v12: Rebased.
Signed-off-by: Tomeu Vizoso
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/i915/Makefile | 2 +-
drivers/gpu/drm/i915/i915_debugfs.c | 882 +--
drivers/gpu/drm/i915/intel_drv.h | 5 +
drivers/gpu/drm/i915/intel_pipe_crc.c | 939 ++
4 files changed, 949 insertions(+), 879 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_pipe_crc.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 3dea46af9fe6..0e4c15b93f04 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -24,7 +24,7 @@ i915-y := i915_drv.o \
intel_runtime_pm.o
i915-$(CONFIG_COMPAT) += i915_ioc32.o
-i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o
+i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o intel_pipe_crc.o
# GEM code
i915-y += i915_cmd_parser.o \
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1cc971cb6cb1..7863d2080b19 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -26,19 +26,9 @@
*
*/
-#include
-#include
-#include
#include
-#include
-#include
#include
-#include
-#include
#include "intel_drv.h"
-#include "intel_ringbuffer.h"
-#include
-#include "i915_drv.h"
static inline struct drm_i915_private *node_to_i915(struct drm_info_node *node)
{
@@ -3548,12 +3538,6 @@ static int i915_drrs_status(struct seq_file *m, void
*unused)
return 0;
}
-struct pipe_crc_info {
- const char *name;
- struct drm_i915_private *dev_priv;
- enum pipe pipe;
-};
-
static int i915_dp_mst_info(struct seq_file *m, void *unused)
{
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -3583,844 +3567,6 @@ static int i915_dp_mst_info(struct seq_file *m, void
*unused)
return 0;
}
-static int i915_pipe_crc_open(struct inode *inode, struct file *filep)
-{
- struct pipe_crc_info *info = inode->i_private;
- struct drm_i915_private *dev_priv = info->dev_priv;
- struct intel_pipe_crc *pipe_crc = &dev_priv->pipe_crc[info->pipe];
-
- if (info->pipe >= INTEL_INFO(dev_priv)->num_pipes)
- return -ENODEV;
-
- spin_lock_irq(&pipe_crc->lock);
-
- if (pipe_crc->opened) {
- spin_unlock_irq(&pipe_crc->lock);
- return -EBUSY; /* already open */
- }
-
- pipe_crc->opened = true;
- filep->private_data = inode->i_private;
-
- spin_unlock_irq(&pipe_crc->lock);
-
- return 0;
-}
-
-static int i915_pipe_crc_release(struct inode *inode, struct file *filep)
-{
- struct pipe_crc_info *info = inode->i_private;
- struct drm_i915_private *dev_priv = info->dev_priv;
- struct intel_pipe_crc *pipe_crc = &dev_priv->pipe_crc[info->pipe];
-
- spin_lock_irq(&pipe_crc->lock);
- pipe_crc->opened = false;
- spin_unlock_irq(&pipe_crc->lock);
-
- return 0;
-}
-
-/* (6 fields, 8 chars each, space separated (5) + '\n') */
-#define PIPE_CRC_LINE_LEN (6 * 8 + 5 + 1)
-/* account for \'0' */
-#define PIPE_CRC_BUFFER_LEN(PIPE_CRC_LINE_LEN + 1)
-
-static int pipe_crc_data_count(struct intel_pipe_crc *pipe_crc)
-{
- assert_spin_locked(&pipe_crc->lock);
- return CIRC_CNT(pipe_crc->head, pipe_crc->tail,
- INTEL_PIPE_CRC_ENTRIES_NR);
-}
-
-static ssize_t
-i915_pipe_crc_read(struct file *filep, char __user *user_buf, size_t count,
- loff_t *pos)
-{
- struct pipe_crc_info *info = filep->private_data;
- struct drm_i915_private *dev_priv = info->dev_priv;
- struct intel_pipe_crc *pipe_crc = &dev_priv->pipe_crc[info->pipe];
- char buf[PIPE_CRC_BUFFER_LEN];
- int n_entries;
- ssize_t bytes_read;
-
- /*
-* Don't allow user space to provide buffers not big enough to hold
-* a line of data.
-*/
- if (count < PIPE_CRC_LINE_LEN)
- return -EINVAL;
-
- if (pipe_crc->source == INTEL_PIPE_CRC_SOURCE_NONE)
- return 0;
-
- /* nothing to read */
- spin_lock_irq(&pipe_crc->lock);
- while (pipe_crc_data_count(pipe_crc) == 0) {
- int ret;
-
- if (filep->f_flags & O_NONBLOCK) {
- spin_unlock_irq(&pipe_crc->lock);
- return -EAGAIN;
- }
-
- ret = wait_event_interruptible_lock_irq(pipe_crc->wq,
- pipe_crc_data_count(pipe_crc), pipe_crc->lock);
- if (ret) {
- spin_unlock_irq(&pipe_crc->lock);
-
[PATCH v12 2/4] drm: Move locking into drm_debugfs_crtc_crc_add
There's no reason any more for callers of this function to take the lock
themselves, so just move the lock to the function to avoid confusion and
bugs when more callers are contributed.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/drm_debugfs_crc.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
b/drivers/gpu/drm/drm_debugfs_crc.c
index 00e771fb7df2..68b171af237b 100644
--- a/drivers/gpu/drm/drm_debugfs_crc.c
+++ b/drivers/gpu/drm/drm_debugfs_crc.c
@@ -325,16 +325,19 @@ int drm_crtc_add_crc_entry(struct drm_crtc *crtc, bool
has_frame,
struct drm_crtc_crc_entry *entry;
int head, tail;
- assert_spin_locked(&crc->lock);
+ spin_lock(&crc->lock);
/* Caller may not have noticed yet that userspace has stopped reading */
- if (!crc->opened)
+ if (!crc->opened) {
+ spin_unlock(&crc->lock);
return -EINVAL;
+ }
head = crc->head;
tail = crc->tail;
if (CIRC_SPACE(head, tail, DRM_CRC_ENTRIES_NR) < 1) {
+ spin_unlock(&crc->lock);
DRM_ERROR("Overflow of CRC buffer, userspace reads too
slow.\n");
return -ENOBUFS;
}
@@ -347,6 +350,8 @@ int drm_crtc_add_crc_entry(struct drm_crtc *crtc, bool
has_frame,
head = (head + 1) & (DRM_CRC_ENTRIES_NR - 1);
crc->head = head;
+ spin_unlock(&crc->lock);
+
return 0;
}
EXPORT_SYMBOL_GPL(drm_crtc_add_crc_entry);
--
2.7.4
[PATCH v12 4/4] drm/i915: Put "cooked" vlank counters in frame CRC lines
Use drm_accurate_vblank_count so we have the full 32 bit to represent
the frame counter and userspace has a simpler way of knowing when the
counter wraps around.
Signed-off-by: Tomeu Vizoso
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/i915/i915_irq.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 7870a86d7209..c522a8b611b8 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1557,7 +1557,6 @@ static void display_pipe_crc_irq_handler(struct
drm_i915_private *dev_priv,
struct drm_driver *driver = dev_priv->drm.driver;
uint32_t crcs[5];
int head, tail, ret;
- u32 frame;
spin_lock(&pipe_crc->lock);
if (pipe_crc->source) {
@@ -1612,8 +1611,9 @@ static void display_pipe_crc_irq_handler(struct
drm_i915_private *dev_priv,
crcs[2] = crc2;
crcs[3] = crc3;
crcs[4] = crc4;
- frame = driver->get_vblank_counter(&dev_priv->drm, pipe);
- ret = drm_crtc_add_crc_entry(&crtc->base, true, frame, crcs);
+ ret = drm_crtc_add_crc_entry(&crtc->base, true,
+
drm_accurate_vblank_count(&crtc->base),
+crcs);
if (!ret)
wake_up_interruptible(&crtc->base.crc.wq);
}
--
2.7.4
[PATCH v12 3/4] drm/i915: Use new CRC debugfs API
The core provides now an ABI to userspace for generation of frame CRCs,
so implement the ->set_crc_source() callback and reuse as much code as
possible with the previous ABI implementation.
When handling the pageflip interrupt, we skip 1 or 2 frames depending on
the HW because they contain wrong values. For the legacy ABI for
generating frame CRCs, this was done in userspace but now that we have a
generic ABI it's better if it's not exposed by the kernel.
v2:
- Leave the legacy implementation in place as the ABI implementation
in the core is incompatible with it.
v3:
- Use the "cooked" vblank counter so we have a whole 32 bits.
- Make sure we don't mess with the state of the legacy CRC capture
ABI implementation.
v4:
- Keep use of get_vblank_counter as in the legacy code, will be
changed in a followup commit.
v5:
- Skip first frame or two as it's known that they contain wrong
data.
- A few fixes suggested by Emil Velikov.
v6:
- Rework programming of the HW registers to preserve previous
behavior.
v7:
- Address whitespace issue.
- Added a comment on why in the implementation of the new ABI we
skip the 1st or 2nd frames.
v9:
- Add stub for intel_crtc_set_crc_source.
v12:
- Rebased.
- Remove stub for intel_crtc_set_crc_source and instead set the
callback to NULL (Jani Nikula).
Signed-off-by: Tomeu Vizoso
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_irq.c | 81 --
drivers/gpu/drm/i915/intel_display.c | 1 +
drivers/gpu/drm/i915/intel_drv.h | 6 +++
drivers/gpu/drm/i915/intel_pipe_crc.c | 94 ++-
5 files changed, 145 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 006914ca36fe..86d63c446ca6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1733,6 +1733,7 @@ struct intel_pipe_crc {
enum intel_pipe_crc_source source;
int head, tail;
wait_queue_head_t wq;
+ int skipped;
};
struct i915_frontbuffer_tracking {
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index cb8a75f6ca16..7870a86d7209 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1553,41 +1553,70 @@ static void display_pipe_crc_irq_handler(struct
drm_i915_private *dev_priv,
{
struct intel_pipe_crc *pipe_crc = &dev_priv->pipe_crc[pipe];
struct intel_pipe_crc_entry *entry;
- int head, tail;
+ struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
+ struct drm_driver *driver = dev_priv->drm.driver;
+ uint32_t crcs[5];
+ int head, tail, ret;
+ u32 frame;
spin_lock(&pipe_crc->lock);
+ if (pipe_crc->source) {
+ if (!pipe_crc->entries) {
+ spin_unlock(&pipe_crc->lock);
+ DRM_DEBUG_KMS("spurious interrupt\n");
+ return;
+ }
- if (!pipe_crc->entries) {
- spin_unlock(&pipe_crc->lock);
- DRM_DEBUG_KMS("spurious interrupt\n");
- return;
- }
-
- head = pipe_crc->head;
- tail = pipe_crc->tail;
+ head = pipe_crc->head;
+ tail = pipe_crc->tail;
- if (CIRC_SPACE(head, tail, INTEL_PIPE_CRC_ENTRIES_NR) < 1) {
- spin_unlock(&pipe_crc->lock);
- DRM_ERROR("CRC buffer overflowing\n");
- return;
- }
+ if (CIRC_SPACE(head, tail, INTEL_PIPE_CRC_ENTRIES_NR) < 1) {
+ spin_unlock(&pipe_crc->lock);
+ DRM_ERROR("CRC buffer overflowing\n");
+ return;
+ }
- entry = &pipe_crc->entries[head];
+ entry = &pipe_crc->entries[head];
- entry->frame = dev_priv->drm.driver->get_vblank_counter(&dev_priv->drm,
-pipe);
- entry->crc[0] = crc0;
- entry->crc[1] = crc1;
- entry->crc[2] = crc2;
- entry->crc[3] = crc3;
- entry->crc[4] = crc4;
+ entry->frame = driver->get_vblank_counter(&dev_priv->drm, pipe);
+ entry->crc[0] = crc0;
+ entry->crc[1] = crc1;
+ entry->crc[2] = crc2;
+ entry->crc[3] = crc3;
+ entry->crc[4] = crc4;
- head = (head + 1) & (INTEL_PIPE_CRC_ENTRIES_NR - 1);
- pipe_crc->head = head;
+ head = (head + 1) & (INTEL_PIPE_CRC_ENTRIES_NR - 1);
+ pipe_crc->head = head;
- spin_unlock(&pipe_crc->lock);
+ spin_unlock(&pipe_crc->lock);
- wake_up_interruptible(&pipe_crc->wq);
+ wake_up_interruptible(&pipe_crc->wq);
+ } else {
+ /*
+* For s
[PATCH v2 2/3] drm/bridge: Add ti-tfp410 DVI transmitter driver
Hi Jyri, On Wednesday 16 Nov 2016 16:39:28 Jyri Sarha wrote: > On 11/16/16 15:33, Rob Herring wrote: > >> +Optional properties > >> > >>> + - reg: I2C address. If and only if present the driver node I assume you meant device node, not driver node ? > >>> + should be placed into the i2c controller node where the > >>> + tfp410 i2c is connected to (the current implementation does > >>> + not yet support this). > > > > So this chip can work without programming I guess? > > Yes. Just powering it up is enough for most application. > > > reg should only be not present if I2C is not connected in the design. It > > can't be a function of what the driver supports. In otherwords, you > > can't be moving this node around based on when you add I2C control. > > Ok, I'll try to implement a dummy i2c driver at the same time too. I can > not test anything related to it because I do not have a piece of HW with > tfp410 i2c wires connected, but it should not matter as long as I am > able to probe it as a i2c client. I think that Rob's point was that whether the current implementation supports this or not is irrelevant from a DT bindings point of view. It should not be mentioned in the bindings document. -- Regards, Laurent Pinchart
[Bug 98753] Freeze while running the mupen64plus emulator
https://bugs.freedesktop.org/show_bug.cgi?id=98753 --- Comment #2 from Vincent B. --- Created attachment 128039 --> https://bugs.freedesktop.org/attachment.cgi?id=128039&action=edit dmesg output -- 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/20161117/f1d1fbd6/attachment-0001.html>
[Bug 98753] Freeze while running the mupen64plus emulator
https://bugs.freedesktop.org/show_bug.cgi?id=98753 --- Comment #3 from Vincent B. --- Created attachment 128040 --> https://bugs.freedesktop.org/attachment.cgi?id=128040&action=edit glxinfo output -- 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/20161117/8e4bc797/attachment.html>
[Bug 98693] Mad Max: Long lags when VRAM full
https://bugs.freedesktop.org/show_bug.cgi?id=98693 --- Comment #4 from Jani Kärkkäinen --- (In reply to Michel Dänzer from comment #3) > Assuming your card has 1GB of VRAM, the fundamental problem is that the game > wants to use more VRAM than is available. Maybe you can try reducing the > game's graphics settings such that the 'requested VRAM' number drops below > 1GB. Indeed. The game's settings are at the minimum, and the resolution is @ 720p. I hoped the lowest setting would alleviate the lags, but unfortunately it didn't. However, just by reading the links from the article I linked in my original message, I thought that it should be possible to play with less VRAM than what is needed, as per: "The game I'm testing needs 3.4 GB of VRAM. Setups: Tonga - 2 GB: It's nearly unplayable, because freezes occur too often. Fiji - 4 GB: There is one freeze at the beginning (which is annoying too), after that it's smooth. So even 4 GB is not enough." Also the descriptions of the problem seem to match mine. A problem in memory handling? Thanks for the suggestion though, anything that could remove or at least reduce the lags would make the game from mostly playable to very playable (for me at least). -- 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/20161117/25081518/attachment.html>
[PATCH] drm: also move DSI panels to the front of the connector list
We've overlooked adding DSI panels to the front of the connector
list. This seems to be the right thing to do, and I suspect this might
fix some issues, although I currently have no evidence to support this.
Cc: Daniel Vetter
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_modeset_helper.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_modeset_helper.c
b/drivers/gpu/drm/drm_modeset_helper.c
index 2f452b3dd40e..440d65882fc6 100644
--- a/drivers/gpu/drm/drm_modeset_helper.c
+++ b/drivers/gpu/drm/drm_modeset_helper.c
@@ -51,7 +51,8 @@ void drm_helper_move_panel_connectors_to_head(struct
drm_device *dev)
list_for_each_entry_safe(connector, tmp,
&dev->mode_config.connector_list, head) {
if (connector->connector_type == DRM_MODE_CONNECTOR_LVDS ||
- connector->connector_type == DRM_MODE_CONNECTOR_eDP)
+ connector->connector_type == DRM_MODE_CONNECTOR_eDP ||
+ connector->connector_type == DRM_MODE_CONNECTOR_DSI)
list_move_tail(&connector->head, &panel_list);
}
--
2.1.4
[PATCH v2] drm: also move DSI panels to the front of the connector list
We've overlooked adding DSI panels to the front of the connector
list. This seems to be the right thing to do, and I suspect this might
fix some issues, although I currently have no evidence to support this.
v2: also git add the comment change
Cc: Daniel Vetter
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_modeset_helper.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_modeset_helper.c
b/drivers/gpu/drm/drm_modeset_helper.c
index 2f452b3dd40e..eba1c6c72acd 100644
--- a/drivers/gpu/drm/drm_modeset_helper.c
+++ b/drivers/gpu/drm/drm_modeset_helper.c
@@ -38,7 +38,7 @@
* Some userspace presumes that the first connected connector is the main
* display, where it's supposed to display e.g. the login screen. For
* laptops, this should be the main panel. Use this function to sort all
- * (eDP/LVDS) panels to the front of the connector list, instead of
+ * (eDP/LVDS/DSI) panels to the front of the connector list, instead of
* painstakingly trying to initialize them in the right order.
*/
void drm_helper_move_panel_connectors_to_head(struct drm_device *dev)
@@ -51,7 +51,8 @@ void drm_helper_move_panel_connectors_to_head(struct
drm_device *dev)
list_for_each_entry_safe(connector, tmp,
&dev->mode_config.connector_list, head) {
if (connector->connector_type == DRM_MODE_CONNECTOR_LVDS ||
- connector->connector_type == DRM_MODE_CONNECTOR_eDP)
+ connector->connector_type == DRM_MODE_CONNECTOR_eDP ||
+ connector->connector_type == DRM_MODE_CONNECTOR_DSI)
list_move_tail(&connector->head, &panel_list);
}
--
2.1.4
DRM: urgent v4.9-rc6 build regression: master build: 2 failures 1 warnings (v4.9-rc5-213-g961b708)
On Thursday, November 17, 2016 4:14:44 AM CET Build bot for Mark Brown wrote:
> arm64-allmodconfig
> ../drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c:126:36: error: 'OD_CFG'
> undeclared (first use in this function)
> ../drivers/gpu/drm/mediatek/mtk_drm_drv.c:220:5: error: 'struct drm_device'
> has no member named 'vblank_disable_allowed'
>
> arm-allmodconfig
> ../drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c:126:36: error: 'OD_CFG'
> undeclared (first use in this function)
> ../drivers/gpu/drm/mediatek/mtk_drm_drv.c:220:5: error: 'struct drm_device'
> has no member named 'vblank_disable_allowed'
These two patches need to be reverted or fixed:
f752fff ("drm/mediatek: set vblank_disable_allowed to true")
83ba62b ("drm/mediatek: fix a typo of OD_CFG to OD_RELAYMODE")
Both of them seem to work fine on linux-next, but were accidentally sent
to Linus yesterday through:
Merge tag 'drm-fixes-for-v4.9-rc6' of
git://people.freedesktop.org/~airlied/linux
Merge branch 'mediatek-drm-fixes-2016-11-11' of
https://github.com/ckhu-mediatek/linux.git-tags into drm-fixes
Clearly that branch has never been build-tested by itself. Unfortunately
the dependency on "HAVE_ARM_SMCCC" caused the driver to not be no longer
included in x86 allmodconfig builds despite the COMPILE_TEST check,
so neither David Airlie nor Linus Torvalds caught it before it got merged.
Arnd
DRM: urgent v4.9-rc6 build regression: master build: 2 failures 1 warnings (v4.9-rc5-213-g961b708)
On 17 Nov. 2016 8:41 pm, "Arnd Bergmann" wrote:
>
> On Thursday, November 17, 2016 4:14:44 AM CET Build bot for Mark Brown
wrote:
> > arm64-allmodconfig
> > ../drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c:126:36: error: 'OD_CFG'
undeclared (first use in this function)
> > ../drivers/gpu/drm/mediatek/mtk_drm_drv.c:220:5: error: 'struct
drm_device' has no member named 'vblank_disable_allowed'
> >
> > arm-allmodconfig
> > ../drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c:126:36: error: 'OD_CFG'
undeclared (first use in this function)
> > ../drivers/gpu/drm/mediatek/mtk_drm_drv.c:220:5: error: 'struct
drm_device' has no member named 'vblank_disable_allowed'
>
> These two patches need to be reverted or fixed:
>
> f752fff ("drm/mediatek: set vblank_disable_allowed to true")
> 83ba62b ("drm/mediatek: fix a typo of OD_CFG to OD_RELAYMODE")
>
> Both of them seem to work fine on linux-next, but were accidentally sent
> to Linus yesterday through:
>
> Merge tag 'drm-fixes-for-v4.9-rc6' of git://
people.freedesktop.org/~airlied/linux
> Merge branch 'mediatek-drm-fixes-2016-11-11' of
https://github.com/ckhu-mediatek/linux.git-tags into drm-fixes
>
> Clearly that branch has never been build-tested by itself. Unfortunately
> the dependency on "HAVE_ARM_SMCCC" caused the driver to not be no longer
> included in x86 allmodconfig builds despite the COMPILE_TEST check,
> so neither David Airlie nor Linus Torvalds caught it before it got merged.
oops bad dependency, I normally have a cross compile on -next, but -fixes I
don't always do it, since who would send broken -fixes,
Arnd could you send a git pull with the two reverts, with my Acked-by on
it? I won't be in a place to do it for 8-9hrs.
Dave.
>
> Arnd
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161117/10429d4e/attachment.html>
[RFC][PATCH] drm: Nuke modifier[1-3]
On Wed, Nov 16, 2016 at 01:33:16PM +0200, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> It has been suggested that having per-plane modifiers is making life
> more difficult for userspace, so let's just retire modifier[1-3] and
> use modifier[0] to apply to the entire framebuffer.
>
> Obviosuly this means that if individual planes need different tiling
> layouts and whatnot we will need a new modifier for each combination
> of planes with different tiling layouts.
>
> For a bit of extra backwards compatilbilty the kernel will allow
> non-zero modifier[1+] but it require that they will match modifier[0].
> This in case there's existing userspace out there that sets
> modifier[1+] to something non-zero with planar formats.
>
> Mostly a cocci job, with a bit of manual stuff mixed in.
>
> @@
> struct drm_framebuffer *fb;
> expression E;
> @@
> - fb->modifier[E]
> + fb->modifier
>
> @@
> struct drm_framebuffer fb;
> expression E;
> @@
> - fb.modifier[E]
> + fb.modifier
>
> Cc: Kristian Høgsberg
> Cc: Ben Widawsky
> Cc: Rob Clark
> Cc: Daniel Vetter
> Cc: Tomeu Vizoso
> Cc: dczaplejewicz at collabora.co.uk
> Suggested-by: Kristian Høgsberg
> Signed-off-by: Ville Syrjälä
Applied to drm-misc, thx.
-Daniel
> ---
> drivers/gpu/drm/drm_atomic.c | 2 +-
> drivers/gpu/drm/drm_framebuffer.c | 7 +++
> drivers/gpu/drm/drm_modeset_helper.c | 2 +-
> drivers/gpu/drm/i915/i915_debugfs.c | 4 +-
> drivers/gpu/drm/i915/intel_atomic_plane.c | 4 +-
> drivers/gpu/drm/i915/intel_display.c | 72
> +++
> drivers/gpu/drm/i915/intel_fbdev.c| 2 +-
> drivers/gpu/drm/i915/intel_pm.c | 22 +-
> drivers/gpu/drm/i915/intel_sprite.c | 14 +++---
> drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 2 +-
> include/drm/drm_framebuffer.h | 4 +-
> include/uapi/drm/drm_mode.h | 13 +++---
> 12 files changed, 79 insertions(+), 69 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 57e0a6e96f6d..bfaa6e4a9989 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -922,12 +922,12 @@ static void drm_atomic_plane_print_state(struct
> drm_printer *p,
>
> drm_printf(p, "\t\tformat=%s\n",
> drm_get_format_name(fb->pixel_format,
> &format_name));
> + drm_printf(p, "\t\t\tmodifier=0x%llx\n", fb->modifier);
> drm_printf(p, "\t\tsize=%dx%d\n", fb->width, fb->height);
> drm_printf(p, "\t\tlayers:\n");
> for (i = 0; i < n; i++) {
> drm_printf(p, "\t\t\tpitch[%d]=%u\n", i,
> fb->pitches[i]);
> drm_printf(p, "\t\t\toffset[%d]=%u\n", i,
> fb->offsets[i]);
> - drm_printf(p, "\t\t\tmodifier[%d]=0x%llx\n", i,
> fb->modifier[i]);
> }
> }
> drm_printf(p, "\tcrtc-pos=" DRM_RECT_FMT "\n", DRM_RECT_ARG(&dest));
> diff --git a/drivers/gpu/drm/drm_framebuffer.c
> b/drivers/gpu/drm/drm_framebuffer.c
> index 06ad3d1350c4..cbf0c893f426 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -177,6 +177,13 @@ static int framebuffer_check(const struct
> drm_mode_fb_cmd2 *r)
> return -EINVAL;
> }
>
> + if (r->flags & DRM_MODE_FB_MODIFIERS &&
> + r->modifier[i] != r->modifier[0]) {
> + DRM_DEBUG_KMS("bad fb modifier %llu for plane %d\n",
> + r->modifier[i], i);
> + return -EINVAL;
> + }
> +
> /* modifier specific checks: */
> switch (r->modifier[i]) {
> case DRM_FORMAT_MOD_SAMSUNG_64_32_TILE:
> diff --git a/drivers/gpu/drm/drm_modeset_helper.c
> b/drivers/gpu/drm/drm_modeset_helper.c
> index 2f452b3dd40e..633355e02398 100644
> --- a/drivers/gpu/drm/drm_modeset_helper.c
> +++ b/drivers/gpu/drm/drm_modeset_helper.c
> @@ -93,8 +93,8 @@ void drm_helper_mode_fill_fb_struct(struct drm_framebuffer
> *fb,
> for (i = 0; i < 4; i++) {
> fb->pitches[i] = mode_cmd->pitches[i];
> fb->offsets[i] = mode_cmd->offsets[i];
> - fb->modifier[i] = mode_cmd->modifier[i];
> }
> + fb->modifier = mode_cmd->modifier[0];
> fb->pixel_format = mode_cmd->pixel_format;
> fb->flags = mode_cmd->flags;
> }
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 1cc971cb6cb1..ae136af4aa37 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1897,7 +1897,7 @@ static int i915_gem_framebuffer_info(struct seq_file
> *m, void *data)
> fbdev_fb->base.height,
> fbdev_fb->base.depth,
> fbdev_fb->base.bits_per_pixel,
> -
[PATCH v2] drm: also move DSI panels to the front of the connector list
On Thu, Nov 17, 2016 at 12:29:08PM +0200, Jani Nikula wrote:
> We've overlooked adding DSI panels to the front of the connector
> list. This seems to be the right thing to do, and I suspect this might
> fix some issues, although I currently have no evidence to support this.
>
> v2: also git add the comment change
>
> Cc: Daniel Vetter
> Signed-off-by: Jani Nikula
Applied to drm-misc, thx.
-Daniel
> ---
> drivers/gpu/drm/drm_modeset_helper.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_modeset_helper.c
> b/drivers/gpu/drm/drm_modeset_helper.c
> index 2f452b3dd40e..eba1c6c72acd 100644
> --- a/drivers/gpu/drm/drm_modeset_helper.c
> +++ b/drivers/gpu/drm/drm_modeset_helper.c
> @@ -38,7 +38,7 @@
> * Some userspace presumes that the first connected connector is the main
> * display, where it's supposed to display e.g. the login screen. For
> * laptops, this should be the main panel. Use this function to sort all
> - * (eDP/LVDS) panels to the front of the connector list, instead of
> + * (eDP/LVDS/DSI) panels to the front of the connector list, instead of
> * painstakingly trying to initialize them in the right order.
> */
> void drm_helper_move_panel_connectors_to_head(struct drm_device *dev)
> @@ -51,7 +51,8 @@ void drm_helper_move_panel_connectors_to_head(struct
> drm_device *dev)
> list_for_each_entry_safe(connector, tmp,
>&dev->mode_config.connector_list, head) {
> if (connector->connector_type == DRM_MODE_CONNECTOR_LVDS ||
> - connector->connector_type == DRM_MODE_CONNECTOR_eDP)
> + connector->connector_type == DRM_MODE_CONNECTOR_eDP ||
> + connector->connector_type == DRM_MODE_CONNECTOR_DSI)
> list_move_tail(&connector->head, &panel_list);
> }
>
> --
> 2.1.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH v2 0/7] drm/tilcdc: LCDC Revision 1 related fixes
2016-11-16 19:00 GMT+01:00 Jyri Sarha : > On 11/16/16 17:18, Bartosz Golaszewski wrote: >> 2016-11-16 13:40 GMT+01:00 Jyri Sarha : >>> Changes since first version of the series: >>> >>> - Move tilcdc_regs.h changes from "drm/tilcdc: Enable palette loading >>> for revision 2 LCDC too" to "drm/tilcdc: Add tilcdc_write_mask() to >>> tilcdc_regs.h" >>> >>> These patches are inspired by this series form Bartosz Golaszewski: >>> https://www.spinics.net/lists/arm-kernel/msg539629.html >>> >>> The patches are based on drm-next plus the earlier patches that I plan >>> to send in a pull request for 4.10. The base + these patches are >>> pushed here: >>> >>> https://github.com/jsarha/linux drm-next-tilcdc-for-4.10-wip >>> >>> Bartosz, please test if this branch works for rev1 LCDC, with your dts >>> file! >>> >> >> Hi Jyri, >> >> with your changes I'm getting the following warning on initialization: >> >> [drm] Initialized >> [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). >> [drm] No driver support for vblank timestamp query. >> [ cut here ] >> WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_atomic_helper.c:1141 >> drm_atomic_helper_wait_for_vblanks+0x23c/0x24c >> [CRTC:24] vblank wait timed out >> Modules linked in: >> CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.0-rc4-00939-ge79af2c #60 >> Hardware name: Generic DA850/OMAP-L138/AM18x >> Backtrace: >> [snip] >> >> and the same when running simple modetest (no vsynced page flipping). >> > > Weird. I have never seen that warning. Are you receiving > LCDC_END_OF_FRAME0 interrupts at all? > I'm only getting three right after drm initialization and then, something seems to be disabling them (maybe as the result of vblank timeout?). > Am I missing some interrupt enable bit for rev 1 LCDC? > Rather the interrupt is disabled after being enabled first. > AFAIK the drm_crtc_send_vblank_event() should get called for the drm > atomic state even when the LCDC_END_OF_FRAME0 interrupt is received and > the (mandatory) framebuffer is on the screen. > I'll investigate that, thanks for the hint. >> The default resolution still works and I can start a graphical environment. >> > > Was this with the panel hack or using dumb-vga-dac bridge? > Yes, still the panel hack. I'll test the vga-dac after I can sort out this issue. Thanks, Bartosz
[PATCH] drm/atomic: cleanup debugfs entries on un-registering the driver.
Cleanup the debugfs entries created by commit 6559c901cb48 when
the driver's minor gets un-registered. Without it, DRM drivers
compiled as modules cannot be rmmod-ed and modprobed again.
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/drm_atomic.c | 7 +++
drivers/gpu/drm/drm_debugfs.c | 9 +
include/drm/drm_atomic.h | 1 +
3 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 6773b35..dddf37a 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1681,6 +1681,13 @@ int drm_atomic_debugfs_init(struct drm_minor *minor)
ARRAY_SIZE(drm_atomic_debugfs_list),
minor->debugfs_root, minor);
}
+
+int drm_atomic_debugfs_cleanup(struct drm_minor *minor)
+{
+ return drm_debugfs_remove_files(drm_atomic_debugfs_list,
+ ARRAY_SIZE(drm_atomic_debugfs_list),
+ minor);
+}
#endif
/*
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 206a4fe..2e3e46a 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -228,6 +228,7 @@ EXPORT_SYMBOL(drm_debugfs_remove_files);
int drm_debugfs_cleanup(struct drm_minor *minor)
{
struct drm_device *dev = minor->dev;
+ int ret;
if (!minor->debugfs_root)
return 0;
@@ -235,6 +236,14 @@ int drm_debugfs_cleanup(struct drm_minor *minor)
if (dev->driver->debugfs_cleanup)
dev->driver->debugfs_cleanup(minor);
+ if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
+ ret = drm_atomic_debugfs_cleanup(minor);
+ if (ret) {
+ DRM_ERROR("DRM: Failed to remove atomic debugfs
entries\n");
+ return ret;
+ }
+ }
+
drm_debugfs_remove_files(drm_debugfs_list, DRM_DEBUGFS_ENTRIES, minor);
debugfs_remove(minor->debugfs_root);
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index 2409144..6400df0 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -374,6 +374,7 @@ void drm_state_dump(struct drm_device *dev, struct
drm_printer *p);
#ifdef CONFIG_DEBUG_FS
struct drm_minor;
int drm_atomic_debugfs_init(struct drm_minor *minor);
+int drm_atomic_debugfs_cleanup(struct drm_minor *minor);
#endif
#define for_each_connector_in_state(__state, connector, connector_state, __i) \
--
2.10.0
[PATCH] drm/atomic: cleanup debugfs entries on un-registering the driver.
On Thu, Nov 17, 2016 at 11:41:29AM +, Liviu Dudau wrote:
> Cleanup the debugfs entries created by commit 6559c901cb48 when
> the driver's minor gets un-registered. Without it, DRM drivers
> compiled as modules cannot be rmmod-ed and modprobed again.
Bah, naughty of me: should've put the commit message too:
commit 6559c901cb48: drm/atomic: add debugfs file to dump out atomic state
Also, cc-ing Sean Paul who pulled this first into drm-misc.
Best regards,
Liviu
>
> Signed-off-by: Liviu Dudau
> ---
> drivers/gpu/drm/drm_atomic.c | 7 +++
> drivers/gpu/drm/drm_debugfs.c | 9 +
> include/drm/drm_atomic.h | 1 +
> 3 files changed, 17 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 6773b35..dddf37a 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1681,6 +1681,13 @@ int drm_atomic_debugfs_init(struct drm_minor *minor)
> ARRAY_SIZE(drm_atomic_debugfs_list),
> minor->debugfs_root, minor);
> }
> +
> +int drm_atomic_debugfs_cleanup(struct drm_minor *minor)
> +{
> + return drm_debugfs_remove_files(drm_atomic_debugfs_list,
> + ARRAY_SIZE(drm_atomic_debugfs_list),
> + minor);
> +}
> #endif
>
> /*
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index 206a4fe..2e3e46a 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -228,6 +228,7 @@ EXPORT_SYMBOL(drm_debugfs_remove_files);
> int drm_debugfs_cleanup(struct drm_minor *minor)
> {
> struct drm_device *dev = minor->dev;
> + int ret;
>
> if (!minor->debugfs_root)
> return 0;
> @@ -235,6 +236,14 @@ int drm_debugfs_cleanup(struct drm_minor *minor)
> if (dev->driver->debugfs_cleanup)
> dev->driver->debugfs_cleanup(minor);
>
> + if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
> + ret = drm_atomic_debugfs_cleanup(minor);
> + if (ret) {
> + DRM_ERROR("DRM: Failed to remove atomic debugfs
> entries\n");
> + return ret;
> + }
> + }
> +
> drm_debugfs_remove_files(drm_debugfs_list, DRM_DEBUGFS_ENTRIES, minor);
>
> debugfs_remove(minor->debugfs_root);
> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> index 2409144..6400df0 100644
> --- a/include/drm/drm_atomic.h
> +++ b/include/drm/drm_atomic.h
> @@ -374,6 +374,7 @@ void drm_state_dump(struct drm_device *dev, struct
> drm_printer *p);
> #ifdef CONFIG_DEBUG_FS
> struct drm_minor;
> int drm_atomic_debugfs_init(struct drm_minor *minor);
> +int drm_atomic_debugfs_cleanup(struct drm_minor *minor);
> #endif
>
> #define for_each_connector_in_state(__state, connector, connector_state,
> __i) \
> --
> 2.10.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ã)_/¯
[PATCH v2 2/4] drm/atomic: Add accessor macros for the current state.
Op 16-11-16 om 17:32 schreef Ville Syrjälä:
> On Wed, Nov 16, 2016 at 05:11:56PM +0100, Maarten Lankhorst wrote:
>> Op 16-11-16 om 16:04 schreef Daniel Vetter:
>>> On Wed, Nov 16, 2016 at 04:35:45PM +0200, Ville Syrjälä wrote:
On Wed, Nov 16, 2016 at 02:58:06PM +0100, Maarten Lankhorst wrote:
> With checks! This will allow safe access to the current state,
> while ensuring that the correct locks are held.
>
> Signed-off-by: Maarten Lankhorst
> ---
> include/drm/drm_atomic.h | 66
> ++
> include/drm/drm_modeset_lock.h | 21 ++
> 2 files changed, 87 insertions(+)
>
> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> index e527684dd394..462408a2d1b8 100644
> --- a/include/drm/drm_atomic.h
> +++ b/include/drm/drm_atomic.h
> @@ -334,6 +334,72 @@ __drm_atomic_get_current_plane_state(struct
> drm_atomic_state *state,
> return plane->state;
> }
>
> +
> +/**
> + * drm_atomic_get_current_plane_state - get current plane state
> + * @plane: plane to grab
> + *
> + * This function returns the current plane state for the given plane,
> + * with extra locking checks to make sure that the plane state can be
> + * retrieved safely.
> + *
> + * Returns:
> + *
> + * Pointer to the current plane state.
> + */
> +static inline struct drm_plane_state *
> +drm_atomic_get_current_plane_state(struct drm_plane *plane)
> +{
> + struct drm_plane_state *plane_state = plane->state;
> + struct drm_crtc *crtc = plane_state ? plane_state->crtc : NULL;
> +
> + if (crtc)
> + drm_modeset_lock_assert_one_held(&plane->mutex, &crtc->mutex);
> + else
> + drm_modeset_lock_assert_held(&plane->mutex);
Hmm. Daniel recently smashed me on the head with a big clue bat to point
out that accessing object->state isn't safe unless you hold the object
lock.
So this thing seems suspicious. What's the use case for this?
I guess in this case it might be safe since a parallel update would lock
the crtc as well. But it does feel like promoting potentially dangerous
behaviour. Also there are no barriers so I'm not sure this would be
guaranteed to give us the correct answer anyway.
As far as all of these functions go, should they return const*? Presumably
you wouldn't want to allow changes to the current state.
>>> Yep, need at least a lockdep check for the plane->mutex. And imo also a
>>> check that we're indeed in atomic_check per the idea I dropped on the
>>> cover letter.
>>>
>>> And +1 on const * for these, that seems like a very important check.
>> Well I allowed for crtc lock held because the __ function uses crtc->mutex
>> as safety lock.
> What is this so called __ function exactly?
__drm_atomic_get_current_plane_state, which is only used by
drm_atomic_crtc_state_for_each_plane_state.
It iterates over crtc_state->plane_mask and then gets new_plane_state if
available, or plane->state if the plane is not part of the state.
This is mostly used for watermark calculations.
>> I thought of const, but some code like i915_page_flip manipulates the
>> current state with the right locks held.
>> Perhaps we should disallow that. :)
>>
>> ~Maarten
[PATCH v2 1/4] drm: Define drm_mm_for_each_node_in_range()
Some clients would like to iterate over every node within a certain
range. Make a nice little macro for them to hide the mixing of the
rbtree search and linear walk.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_mm.c | 11 ++-
include/drm/drm_mm.h | 8 +---
2 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 632473beb40c..f8eebbde376e 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -174,19 +174,12 @@ INTERVAL_TREE_DEFINE(struct drm_mm_node, rb,
START, LAST, static inline, drm_mm_interval_tree)
struct drm_mm_node *
-drm_mm_interval_first(struct drm_mm *mm, u64 start, u64 last)
+__drm_mm_interval_first(struct drm_mm *mm, u64 start, u64 last)
{
return drm_mm_interval_tree_iter_first(&mm->interval_tree,
start, last);
}
-EXPORT_SYMBOL(drm_mm_interval_first);
-
-struct drm_mm_node *
-drm_mm_interval_next(struct drm_mm_node *node, u64 start, u64 last)
-{
- return drm_mm_interval_tree_iter_next(node, start, last);
-}
-EXPORT_SYMBOL(drm_mm_interval_next);
+EXPORT_SYMBOL(__drm_mm_interval_first);
static void drm_mm_interval_tree_add_node(struct drm_mm_node *hole_node,
struct drm_mm_node *node)
diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
index 41ddafe92b2f..fca5f313cf18 100644
--- a/include/drm/drm_mm.h
+++ b/include/drm/drm_mm.h
@@ -308,10 +308,12 @@ void drm_mm_takedown(struct drm_mm *mm);
bool drm_mm_clean(struct drm_mm *mm);
struct drm_mm_node *
-drm_mm_interval_first(struct drm_mm *mm, u64 start, u64 last);
+__drm_mm_interval_first(struct drm_mm *mm, u64 start, u64 last);
-struct drm_mm_node *
-drm_mm_interval_next(struct drm_mm_node *node, u64 start, u64 last);
+#define drm_mm_for_each_node_in_range(node, mm, start, end)\
+ for (node = __drm_mm_interval_first((mm), (start), (end)-1);\
+node && node->start < (end); \
+node = list_next_entry(node, node_list)) \
void drm_mm_init_scan(struct drm_mm *mm,
u64 size,
--
2.10.2
[PATCH v2] drm: also move DSI panels to the front of the connector list
On 17.11.2016 11:29, Jani Nikula wrote:
> We've overlooked adding DSI panels to the front of the connector
> list. This seems to be the right thing to do, and I suspect this might
> fix some issues, although I currently have no evidence to support this.
>
> v2: also git add the comment change
>
> Cc: Daniel Vetter
> Signed-off-by: Jani Nikula
Reviewed-by: Andrzej Hajda
Out of curiosity, why driver (i915) do not create connectors
just in proper order instead of sorting them later.
--
Regards
Andrzej
> ---
> drivers/gpu/drm/drm_modeset_helper.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_modeset_helper.c
> b/drivers/gpu/drm/drm_modeset_helper.c
> index 2f452b3dd40e..eba1c6c72acd 100644
> --- a/drivers/gpu/drm/drm_modeset_helper.c
> +++ b/drivers/gpu/drm/drm_modeset_helper.c
> @@ -38,7 +38,7 @@
> * Some userspace presumes that the first connected connector is the main
> * display, where it's supposed to display e.g. the login screen. For
> * laptops, this should be the main panel. Use this function to sort all
> - * (eDP/LVDS) panels to the front of the connector list, instead of
> + * (eDP/LVDS/DSI) panels to the front of the connector list, instead of
> * painstakingly trying to initialize them in the right order.
> */
> void drm_helper_move_panel_connectors_to_head(struct drm_device *dev)
> @@ -51,7 +51,8 @@ void drm_helper_move_panel_connectors_to_head(struct
> drm_device *dev)
> list_for_each_entry_safe(connector, tmp,
>&dev->mode_config.connector_list, head) {
> if (connector->connector_type == DRM_MODE_CONNECTOR_LVDS ||
> - connector->connector_type == DRM_MODE_CONNECTOR_eDP)
> + connector->connector_type == DRM_MODE_CONNECTOR_eDP ||
> + connector->connector_type == DRM_MODE_CONNECTOR_DSI)
> list_move_tail(&connector->head, &panel_list);
> }
>
[Intel-gfx] [PATCH v2] drm: also move DSI panels to the front of the connector list
On Thu, 17 Nov 2016, Andrzej Hajda wrote:
> On 17.11.2016 11:29, Jani Nikula wrote:
>> We've overlooked adding DSI panels to the front of the connector
>> list. This seems to be the right thing to do, and I suspect this might
>> fix some issues, although I currently have no evidence to support this.
>>
>> v2: also git add the comment change
>>
>> Cc: Daniel Vetter
>> Signed-off-by: Jani Nikula
>
> Reviewed-by: Andrzej Hajda
>
> Out of curiosity, why driver (i915) do not create connectors
> just in proper order instead of sorting them later.
commit 270b30420c5e0d5f779aa76882367f9265c5aa7d
Author: Daniel Vetter
Date: Sat Oct 27 15:52:05 2012 +0200
drm/i915: move panel connectors to the front
This essentially reverts
commit cb0953d734348e8862d6d7edc666cfb3bf6d8fae
Author: Adam Jackson
Date: Fri Jul 16 14:46:29 2010 -0400
drm/i915: Initialize LVDS and eDP outputs before anything else
simply because it doesn't scale: It misses SDVO and DVO panels,
and now with DDI encoders on haswell this is becoming unmanageable.
Instead we simply sort the connector list after everything is
set up.
Reviewed-by: Adam Jackson
Acked-by: Chris Wilson
Signed-off-by: Daniel Vetter
>
>
> --
> Regards
> Andrzej
>
>> ---
>> drivers/gpu/drm/drm_modeset_helper.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_modeset_helper.c
>> b/drivers/gpu/drm/drm_modeset_helper.c
>> index 2f452b3dd40e..eba1c6c72acd 100644
>> --- a/drivers/gpu/drm/drm_modeset_helper.c
>> +++ b/drivers/gpu/drm/drm_modeset_helper.c
>> @@ -38,7 +38,7 @@
>> * Some userspace presumes that the first connected connector is the main
>> * display, where it's supposed to display e.g. the login screen. For
>> * laptops, this should be the main panel. Use this function to sort all
>> - * (eDP/LVDS) panels to the front of the connector list, instead of
>> + * (eDP/LVDS/DSI) panels to the front of the connector list, instead of
>> * painstakingly trying to initialize them in the right order.
>> */
>> void drm_helper_move_panel_connectors_to_head(struct drm_device *dev)
>> @@ -51,7 +51,8 @@ void drm_helper_move_panel_connectors_to_head(struct
>> drm_device *dev)
>> list_for_each_entry_safe(connector, tmp,
>> &dev->mode_config.connector_list, head) {
>> if (connector->connector_type == DRM_MODE_CONNECTOR_LVDS ||
>> -connector->connector_type == DRM_MODE_CONNECTOR_eDP)
>> +connector->connector_type == DRM_MODE_CONNECTOR_eDP ||
>> +connector->connector_type == DRM_MODE_CONNECTOR_DSI)
>> list_move_tail(&connector->head, &panel_list);
>> }
>>
>
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
[PATCH 1/2] drm/i2c: tda998x: allow interrupt to be shared
Hi Russell,
On Wed, Nov 16, 2016 at 10:48:52AM +, Russell King wrote:
>The TDA998x contains two different I2C devices - there is the HDMI
>encoder, and the TDA9950 CEC engine. These two share the same interrupt
>signal.
>
>In order to allow a driver for the CEC engine to work, we need to be
>able to share the interrupt with the CEC driver, so convert the handler
>and registration to allow this to happen.
>
>Signed-off-by: Russell King
>---
>This patch follows on from:
> "drm/i2c: tda998x: power down pre-filter and color conversion"
>which is now part of my drm-tda998x-devel branch, a branch which will
>shortly be part of linux-next. This patch and the following patch are
>not part of that branch yet.
>
>I don't believe I received any testing for the power-down patch above
>either, so if I can have some tested-bys/reviewed-bys for it and these
>two patches, that'd be great. Thanks.
I tested these two and the power-down one on mali-dp and hdlcd. The
output, hotplugging and EDID continued to work; so you can have my
tested-by and reviewed-by for all 3.
Cheers,
Brian
>
>As my Juno has now been fixed, I've been able to test these two patches
>on the HDLCD on Juno and Dove Cubox.
>
> drivers/gpu/drm/i2c/tda998x_drv.c | 52 ---
> 1 file changed, 27 insertions(+), 25 deletions(-)
>
>diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
>b/drivers/gpu/drm/i2c/tda998x_drv.c
>index bf5eec0c1b4f..74fb59a35269 100644
>--- a/drivers/gpu/drm/i2c/tda998x_drv.c
>+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
>@@ -634,28 +634,30 @@ static irqreturn_t tda998x_irq_thread(int irq, void
>*data)
> bool handled = false;
>
> sta = cec_read(priv, REG_CEC_INTSTATUS);
>- cec = cec_read(priv, REG_CEC_RXSHPDINT);
>- lvl = cec_read(priv, REG_CEC_RXSHPDLEV);
>- flag0 = reg_read(priv, REG_INT_FLAGS_0);
>- flag1 = reg_read(priv, REG_INT_FLAGS_1);
>- flag2 = reg_read(priv, REG_INT_FLAGS_2);
>- DRM_DEBUG_DRIVER(
>- "tda irq sta %02x cec %02x lvl %02x f0 %02x f1 %02x f2 %02x\n",
>- sta, cec, lvl, flag0, flag1, flag2);
>-
>- if (cec & CEC_RXSHPDINT_HPD) {
>- if (lvl & CEC_RXSHPDLEV_HPD)
>- tda998x_edid_delay_start(priv);
>- else
>- schedule_work(&priv->detect_work);
>-
>- handled = true;
>- }
>+ if (sta & CEC_INTSTATUS_HDMI) {
>+ cec = cec_read(priv, REG_CEC_RXSHPDINT);
>+ lvl = cec_read(priv, REG_CEC_RXSHPDLEV);
>+ flag0 = reg_read(priv, REG_INT_FLAGS_0);
>+ flag1 = reg_read(priv, REG_INT_FLAGS_1);
>+ flag2 = reg_read(priv, REG_INT_FLAGS_2);
>+ DRM_DEBUG_DRIVER(
>+ "tda irq sta %02x cec %02x lvl %02x f0 %02x f1 %02x f2
>%02x\n",
>+ sta, cec, lvl, flag0, flag1, flag2);
>+
>+ if (cec & CEC_RXSHPDINT_HPD) {
>+ if (lvl & CEC_RXSHPDLEV_HPD)
>+ tda998x_edid_delay_start(priv);
>+ else
>+ schedule_work(&priv->detect_work);
>+
>+ handled = true;
>+ }
>
>- if ((flag2 & INT_FLAGS_2_EDID_BLK_RD) && priv->wq_edid_wait) {
>- priv->wq_edid_wait = 0;
>- wake_up(&priv->wq_edid);
>- handled = true;
>+ if ((flag2 & INT_FLAGS_2_EDID_BLK_RD) && priv->wq_edid_wait) {
>+ priv->wq_edid_wait = 0;
>+ wake_up(&priv->wq_edid);
>+ handled = true;
>+ }
> }
>
> return IRQ_RETVAL(handled);
>@@ -1542,7 +1544,7 @@ static int tda998x_create(struct i2c_client *client,
>struct tda998x_priv *priv)
>
> /* initialize the optional IRQ */
> if (client->irq) {
>- int irqf_trigger;
>+ unsigned long irq_flags;
>
> /* init read EDID waitqueue and HDP work */
> init_waitqueue_head(&priv->wq_edid);
>@@ -1552,11 +1554,11 @@ static int tda998x_create(struct i2c_client *client,
>struct tda998x_priv *priv)
> reg_read(priv, REG_INT_FLAGS_1);
> reg_read(priv, REG_INT_FLAGS_2);
>
>- irqf_trigger =
>+ irq_flags =
> irqd_get_trigger_type(irq_get_irq_data(client->irq));
>+ irq_flags |= IRQF_SHARED | IRQF_ONESHOT;
> ret = request_threaded_irq(client->irq, NULL,
>- tda998x_irq_thread,
>- irqf_trigger | IRQF_ONESHOT,
>+ tda998x_irq_thread, irq_flags,
> "tda998x", priv);
> if (ret) {
> dev_err(&client->dev,
>--
>2.7.4
>
[PATCH] drm/atomic: cleanup debugfs entries on un-registering the driver.
On Thu, Nov 17, 2016 at 11:41:29AM +, Liviu Dudau wrote:
>Cleanup the debugfs entries created by commit 6559c901cb48 when
>the driver's minor gets un-registered. Without it, DRM drivers
>compiled as modules cannot be rmmod-ed and modprobed again.
>
>Signed-off-by: Liviu Dudau
Works for me,
Tested-by: Brian Starkey
>---
> drivers/gpu/drm/drm_atomic.c | 7 +++
> drivers/gpu/drm/drm_debugfs.c | 9 +
> include/drm/drm_atomic.h | 1 +
> 3 files changed, 17 insertions(+)
>
>diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>index 6773b35..dddf37a 100644
>--- a/drivers/gpu/drm/drm_atomic.c
>+++ b/drivers/gpu/drm/drm_atomic.c
>@@ -1681,6 +1681,13 @@ int drm_atomic_debugfs_init(struct drm_minor *minor)
> ARRAY_SIZE(drm_atomic_debugfs_list),
> minor->debugfs_root, minor);
> }
>+
>+int drm_atomic_debugfs_cleanup(struct drm_minor *minor)
>+{
>+ return drm_debugfs_remove_files(drm_atomic_debugfs_list,
>+ ARRAY_SIZE(drm_atomic_debugfs_list),
>+ minor);
>+}
> #endif
>
> /*
>diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
>index 206a4fe..2e3e46a 100644
>--- a/drivers/gpu/drm/drm_debugfs.c
>+++ b/drivers/gpu/drm/drm_debugfs.c
>@@ -228,6 +228,7 @@ EXPORT_SYMBOL(drm_debugfs_remove_files);
> int drm_debugfs_cleanup(struct drm_minor *minor)
> {
> struct drm_device *dev = minor->dev;
>+ int ret;
>
> if (!minor->debugfs_root)
> return 0;
>@@ -235,6 +236,14 @@ int drm_debugfs_cleanup(struct drm_minor *minor)
> if (dev->driver->debugfs_cleanup)
> dev->driver->debugfs_cleanup(minor);
>
>+ if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
>+ ret = drm_atomic_debugfs_cleanup(minor);
>+ if (ret) {
>+ DRM_ERROR("DRM: Failed to remove atomic debugfs
>entries\n");
>+ return ret;
>+ }
>+ }
>+
> drm_debugfs_remove_files(drm_debugfs_list, DRM_DEBUGFS_ENTRIES, minor);
>
> debugfs_remove(minor->debugfs_root);
>diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
>index 2409144..6400df0 100644
>--- a/include/drm/drm_atomic.h
>+++ b/include/drm/drm_atomic.h
>@@ -374,6 +374,7 @@ void drm_state_dump(struct drm_device *dev, struct
>drm_printer *p);
> #ifdef CONFIG_DEBUG_FS
> struct drm_minor;
> int drm_atomic_debugfs_init(struct drm_minor *minor);
>+int drm_atomic_debugfs_cleanup(struct drm_minor *minor);
> #endif
>
> #define for_each_connector_in_state(__state, connector, connector_state, __i)
> \
>--
>2.10.0
>
[PATCH v2 2/4] drm/atomic: Add accessor macros for the current state.
On Thu, Nov 17, 2016 at 12:58:00PM +0100, Maarten Lankhorst wrote:
> Op 16-11-16 om 17:32 schreef Ville Syrjälä:
> > On Wed, Nov 16, 2016 at 05:11:56PM +0100, Maarten Lankhorst wrote:
> >> Op 16-11-16 om 16:04 schreef Daniel Vetter:
> >>> On Wed, Nov 16, 2016 at 04:35:45PM +0200, Ville Syrjälä wrote:
> On Wed, Nov 16, 2016 at 02:58:06PM +0100, Maarten Lankhorst wrote:
> > With checks! This will allow safe access to the current state,
> > while ensuring that the correct locks are held.
> >
> > Signed-off-by: Maarten Lankhorst
> > ---
> > include/drm/drm_atomic.h | 66
> > ++
> > include/drm/drm_modeset_lock.h | 21 ++
> > 2 files changed, 87 insertions(+)
> >
> > diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> > index e527684dd394..462408a2d1b8 100644
> > --- a/include/drm/drm_atomic.h
> > +++ b/include/drm/drm_atomic.h
> > @@ -334,6 +334,72 @@ __drm_atomic_get_current_plane_state(struct
> > drm_atomic_state *state,
> > return plane->state;
> > }
> >
> > +
> > +/**
> > + * drm_atomic_get_current_plane_state - get current plane state
> > + * @plane: plane to grab
> > + *
> > + * This function returns the current plane state for the given plane,
> > + * with extra locking checks to make sure that the plane state can be
> > + * retrieved safely.
> > + *
> > + * Returns:
> > + *
> > + * Pointer to the current plane state.
> > + */
> > +static inline struct drm_plane_state *
> > +drm_atomic_get_current_plane_state(struct drm_plane *plane)
> > +{
> > + struct drm_plane_state *plane_state = plane->state;
> > + struct drm_crtc *crtc = plane_state ? plane_state->crtc : NULL;
> > +
> > + if (crtc)
> > + drm_modeset_lock_assert_one_held(&plane->mutex,
> > &crtc->mutex);
> > + else
> > + drm_modeset_lock_assert_held(&plane->mutex);
> Hmm. Daniel recently smashed me on the head with a big clue bat to point
> out that accessing object->state isn't safe unless you hold the object
> lock.
> So this thing seems suspicious. What's the use case for this?
>
> I guess in this case it might be safe since a parallel update would lock
> the crtc as well. But it does feel like promoting potentially dangerous
> behaviour. Also there are no barriers so I'm not sure this would be
> guaranteed to give us the correct answer anyway.
>
> As far as all of these functions go, should they return const*?
> Presumably
> you wouldn't want to allow changes to the current state.
> >>> Yep, need at least a lockdep check for the plane->mutex. And imo also a
> >>> check that we're indeed in atomic_check per the idea I dropped on the
> >>> cover letter.
> >>>
> >>> And +1 on const * for these, that seems like a very important check.
> >> Well I allowed for crtc lock held because the __ function uses crtc->mutex
> >> as safety lock.
> > What is this so called __ function exactly?
> __drm_atomic_get_current_plane_state, which is only used by
> drm_atomic_crtc_state_for_each_plane_state.
>
> It iterates over crtc_state->plane_mask and then gets new_plane_state if
> available, or plane->state if the plane is not part of the state.
> This is mostly used for watermark calculations.
Sounds like we should kill that sucker and make things clearer by
enforcing the "want to access foo->state? then grab foo->lock first"
rule.
> >> I thought of const, but some code like i915_page_flip manipulates the
> >> current state with the right locks held.
> >> Perhaps we should disallow that. :)
> >>
> >> ~Maarten
>
--
Ville Syrjälä
Intel OTC
[Intel-gfx] [PATCH 0/5] Handle link training failure during modeset
On Tue, 15 Nov 2016, Manasi Navare wrote: > Submitting new series that adds proper commit messages/cover letter > and kernel documentation. It also moved the set_link_status function > to drm core so other kernel drivers can make use of it. > > The idea presented in these patches is to address link training failure > in a way that: > a) changes the current happy day scenario as little as possible, to avoid > regressions, b) can be implemented the same way by all drm drivers, c) > is still opt-in for the drivers and userspace, and opting out doesn't > regress the user experience, d) doesn't prevent drivers from > implementing better or alternate approaches, possibly without userspace > involvement. And, of course, handles all the issues presented. > > The solution is to add a "link status" connector property. In the usual > happy day scenario, this is always "good". If something fails during or > after a mode set, the kernel driver can set the link status to "bad", > prune the mode list based on new information as necessary, and send a > hotplug uevent for userspace to have it re-check the valid modes through > getconnector, and try again. If the theoretical capabilities of the link > can't be reached, the mode list is trimmed based on that. > > If the userspace is not aware of the property, the user experience is > the same as it currently is. If the userspace is aware of the property, > it has a chance to improve user experience. If a drm driver does not > modify the property (it stays "good"), the user experience is the same > as it currently is. A drm driver can also choose to try to handle more > of the failures in kernel, hardware not limiting, or it can choose to > involve userspace more. Up to the drivers. > > The reason for adding the property is to handle link training failures, > but it is not limited to DP or link training. For example, if we > implement asynchronous setcrtc, we can use this to report any failures > in that. > > Finally, while DP CTS compliance is advertized (which is great, and > could be made to work similarly for all drm drivers), this can be used > for the more important goal of improving user experience on link > training failures, by avoiding black screens. Since I went through the trouble of writing this, you might as well add it to patch 1/5 commit message so it benefits the posterity. > Acked-by: Tony Cheng > Acked-by: Harry Wentland These must go to patch 1/5 commit message. BR, Jani. > > Manasi Navare (5): > drm: Add a new connector property for link status > drm: Set DRM connector link status property > drm/i915: Update CRTC state if connector link status property changed > drm/i915: Find fallback link rate/lane count > drm/i915: Implement Link Rate fallback on Link training failure > > drivers/gpu/drm/drm_atomic_helper.c | 7 ++ > drivers/gpu/drm/drm_connector.c | 55 ++ > drivers/gpu/drm/i915/intel_ddi.c | 21 +++- > drivers/gpu/drm/i915/intel_dp.c | 144 > +- > drivers/gpu/drm/i915/intel_dp_link_training.c | 12 ++- > drivers/gpu/drm/i915/intel_drv.h | 10 +- > include/drm/drm_connector.h | 9 +- > include/drm/drm_crtc.h| 5 + > include/uapi/drm/drm_mode.h | 4 + > 9 files changed, 257 insertions(+), 10 deletions(-) -- Jani Nikula, Intel Open Source Technology Center
[PATCH v2 2/4] drm/atomic: Add accessor macros for the current state.
Op 17-11-16 om 13:26 schreef Ville Syrjälä:
> On Thu, Nov 17, 2016 at 12:58:00PM +0100, Maarten Lankhorst wrote:
>> Op 16-11-16 om 17:32 schreef Ville Syrjälä:
>>> On Wed, Nov 16, 2016 at 05:11:56PM +0100, Maarten Lankhorst wrote:
Op 16-11-16 om 16:04 schreef Daniel Vetter:
> On Wed, Nov 16, 2016 at 04:35:45PM +0200, Ville Syrjälä wrote:
>> On Wed, Nov 16, 2016 at 02:58:06PM +0100, Maarten Lankhorst wrote:
>>> With checks! This will allow safe access to the current state,
>>> while ensuring that the correct locks are held.
>>>
>>> Signed-off-by: Maarten Lankhorst
>>> ---
>>> include/drm/drm_atomic.h | 66
>>> ++
>>> include/drm/drm_modeset_lock.h | 21 ++
>>> 2 files changed, 87 insertions(+)
>>>
>>> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
>>> index e527684dd394..462408a2d1b8 100644
>>> --- a/include/drm/drm_atomic.h
>>> +++ b/include/drm/drm_atomic.h
>>> @@ -334,6 +334,72 @@ __drm_atomic_get_current_plane_state(struct
>>> drm_atomic_state *state,
>>> return plane->state;
>>> }
>>>
>>> +
>>> +/**
>>> + * drm_atomic_get_current_plane_state - get current plane state
>>> + * @plane: plane to grab
>>> + *
>>> + * This function returns the current plane state for the given plane,
>>> + * with extra locking checks to make sure that the plane state can be
>>> + * retrieved safely.
>>> + *
>>> + * Returns:
>>> + *
>>> + * Pointer to the current plane state.
>>> + */
>>> +static inline struct drm_plane_state *
>>> +drm_atomic_get_current_plane_state(struct drm_plane *plane)
>>> +{
>>> + struct drm_plane_state *plane_state = plane->state;
>>> + struct drm_crtc *crtc = plane_state ? plane_state->crtc : NULL;
>>> +
>>> + if (crtc)
>>> + drm_modeset_lock_assert_one_held(&plane->mutex,
>>> &crtc->mutex);
>>> + else
>>> + drm_modeset_lock_assert_held(&plane->mutex);
>> Hmm. Daniel recently smashed me on the head with a big clue bat to point
>> out that accessing object->state isn't safe unless you hold the object
>> lock.
>> So this thing seems suspicious. What's the use case for this?
>>
>> I guess in this case it might be safe since a parallel update would lock
>> the crtc as well. But it does feel like promoting potentially dangerous
>> behaviour. Also there are no barriers so I'm not sure this would be
>> guaranteed to give us the correct answer anyway.
>>
>> As far as all of these functions go, should they return const*?
>> Presumably
>> you wouldn't want to allow changes to the current state.
> Yep, need at least a lockdep check for the plane->mutex. And imo also a
> check that we're indeed in atomic_check per the idea I dropped on the
> cover letter.
>
> And +1 on const * for these, that seems like a very important check.
Well I allowed for crtc lock held because the __ function uses crtc->mutex
as safety lock.
>>> What is this so called __ function exactly?
>> __drm_atomic_get_current_plane_state, which is only used by
>> drm_atomic_crtc_state_for_each_plane_state.
>>
>> It iterates over crtc_state->plane_mask and then gets new_plane_state if
>> available, or plane->state if the plane is not part of the state.
>> This is mostly used for watermark calculations.
> Sounds like we should kill that sucker and make things clearer by
> enforcing the "want to access foo->state? then grab foo->lock first"
> rule.
Except adding all planes to cursor updates would result in unintended behavior.
And there are already patches to use the sprite plane instead of the cursor
plane for skylake, so it's not just theoretical. :)
Testcases:
flip-vs-cursor-busy-crc-legacy
flip-vs-cursor-busy-crc-atomic
~Maarten
[PATCH 5/5] drm/i915: Implement Link Rate fallback on Link training failure
On Tue, 15 Nov 2016, Manasi Navare wrote:
> If link training at a link rate optimal for a particular
> mode fails during modeset's atomic commit phase, then we
> let the modeset complete and then retry. We save the link rate
> value at which link training failed, update the link status property
> to "BAD" and use a lower link rate to prune the modes. It will redo
> the modeset on the current mode at lower link rate or if the current
> mode gets pruned due to lower link constraints then, it will send a
> hotplug uevent for userspace to handle it.
>
> This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
> 4.3.1.6.
>
> v5:
> * Move set link status to drm core (Daniel Vetter, Jani Nikula)
> v4:
> * Add fallback support for non DDI platforms too
> * Set connector->link status inside set_link_status function
> (Jani Nikula)
> v3:
> * Set link status property to BAd unconditionally (Jani Nikula)
> * Dont use two separate variables link_train_failed and link_status
> to indicate same thing (Jani Nikula)
> v2:
> * Squashed a few patches (Jani Nikula)
>
> Acked-by: Tony Cheng
> Acked-by: Harry Wentland
> Cc: Jani Nikula
> Cc: Daniel Vetter
> Cc: Ville Syrjala
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 21 +-
> drivers/gpu/drm/i915/intel_dp.c | 102
> +-
> drivers/gpu/drm/i915/intel_dp_link_training.c | 12 ++-
> drivers/gpu/drm/i915/intel_drv.h | 6 +-
> 4 files changed, 131 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 0ad4e16..57b7ee9 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1684,6 +1684,8 @@ static void intel_ddi_pre_enable_dp(struct
> intel_encoder *encoder,
> struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> enum port port = intel_ddi_get_encoder_port(encoder);
> + struct intel_connector *intel_connector = intel_dp->attached_connector;
> + struct drm_connector *connector = &intel_connector->base;
>
> intel_dp_set_link_params(intel_dp, link_rate, lane_count,
>link_mst);
> @@ -1694,7 +1696,24 @@ static void intel_ddi_pre_enable_dp(struct
> intel_encoder *encoder,
> intel_prepare_dp_ddi_buffers(encoder);
> intel_ddi_init_dp_buf_reg(encoder);
> intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> - intel_dp_start_link_train(intel_dp);
> + if (!intel_dp_start_link_train(intel_dp)) {
> + DRM_DEBUG_KMS("Link Training failed at link rate = %d, lane
> count = %d",
> + link_rate, lane_count);
> + if (!intel_dp_get_link_train_fallback_values(intel_dp,
> + link_rate,
> + lane_count))
> + /* Schedule a Hotplug Uevent to userspace to start
> modeset */
> + schedule_work(&intel_connector->modeset_retry_work);
> + } else {
> + DRM_DEBUG_KMS("Link Training Passed at Link Rate = %d, Lane
> count = %d",
> + link_rate, lane_count);
> + intel_dp->fallback_link_rate_index = -1;
> + intel_dp->fallback_link_rate = 0;
> + intel_dp->fallback_lane_count = 0;
> + drm_mode_connector_set_link_status_property(connector,
> +
> DRM_MODE_LINK_STATUS_GOOD);
> + }
Code block with intel_dp_start_link_train() failure handling. Okay.
> +
> if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
> intel_dp_stop_link_train(intel_dp);
> }
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index e87b451..af2f8b2 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -353,8 +353,14 @@ int intel_dp_get_link_train_fallback_values(struct
> intel_dp *intel_dp,
> target_clock = fixed_mode->clock;
> }
>
> - max_link_clock = intel_dp_max_link_rate(intel_dp);
> - max_lanes = intel_dp_max_lane_count(intel_dp);
> + /* Prune the modes using the fallback link rate/lane count */
> + if (connector->link_status == DRM_MODE_LINK_STATUS_BAD) {
> + max_link_clock = intel_dp->fallback_link_rate;
> + max_lanes = intel_dp->fallback_lane_count;
> + } else {
> + max_link_clock = intel_dp_max_link_rate(intel_dp);
> + max_lanes = intel_dp_max_lane_count(intel_dp);
> + }
>
> max_rate = intel_dp_max_data_rate(max_link_clock, max_lanes);
> mode_rate = intel_dp_link_required(target_clock, 18);
> @@ -1591,6 +1597,7 @@ static int intel_dp_compute_bpp(struct intel_dp
> *intel_dp,
> enum port port = dp_to_dig_port(intel_dp
[PATCH v2 2/4] drm/atomic: Add accessor macros for the current state.
On Thu, Nov 17, 2016 at 01:42:13PM +0100, Maarten Lankhorst wrote:
> Op 17-11-16 om 13:26 schreef Ville Syrjälä:
> > On Thu, Nov 17, 2016 at 12:58:00PM +0100, Maarten Lankhorst wrote:
> >> Op 16-11-16 om 17:32 schreef Ville Syrjälä:
> >>> On Wed, Nov 16, 2016 at 05:11:56PM +0100, Maarten Lankhorst wrote:
> Op 16-11-16 om 16:04 schreef Daniel Vetter:
> > On Wed, Nov 16, 2016 at 04:35:45PM +0200, Ville Syrjälä wrote:
> >> On Wed, Nov 16, 2016 at 02:58:06PM +0100, Maarten Lankhorst wrote:
> >>> With checks! This will allow safe access to the current state,
> >>> while ensuring that the correct locks are held.
> >>>
> >>> Signed-off-by: Maarten Lankhorst >>> linux.intel.com>
> >>> ---
> >>> include/drm/drm_atomic.h | 66
> >>> ++
> >>> include/drm/drm_modeset_lock.h | 21 ++
> >>> 2 files changed, 87 insertions(+)
> >>>
> >>> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> >>> index e527684dd394..462408a2d1b8 100644
> >>> --- a/include/drm/drm_atomic.h
> >>> +++ b/include/drm/drm_atomic.h
> >>> @@ -334,6 +334,72 @@ __drm_atomic_get_current_plane_state(struct
> >>> drm_atomic_state *state,
> >>> return plane->state;
> >>> }
> >>>
> >>> +
> >>> +/**
> >>> + * drm_atomic_get_current_plane_state - get current plane state
> >>> + * @plane: plane to grab
> >>> + *
> >>> + * This function returns the current plane state for the given plane,
> >>> + * with extra locking checks to make sure that the plane state can be
> >>> + * retrieved safely.
> >>> + *
> >>> + * Returns:
> >>> + *
> >>> + * Pointer to the current plane state.
> >>> + */
> >>> +static inline struct drm_plane_state *
> >>> +drm_atomic_get_current_plane_state(struct drm_plane *plane)
> >>> +{
> >>> + struct drm_plane_state *plane_state = plane->state;
> >>> + struct drm_crtc *crtc = plane_state ? plane_state->crtc : NULL;
> >>> +
> >>> + if (crtc)
> >>> + drm_modeset_lock_assert_one_held(&plane->mutex,
> >>> &crtc->mutex);
> >>> + else
> >>> + drm_modeset_lock_assert_held(&plane->mutex);
> >> Hmm. Daniel recently smashed me on the head with a big clue bat to
> >> point
> >> out that accessing object->state isn't safe unless you hold the object
> >> lock.
> >> So this thing seems suspicious. What's the use case for this?
> >>
> >> I guess in this case it might be safe since a parallel update would
> >> lock
> >> the crtc as well. But it does feel like promoting potentially dangerous
> >> behaviour. Also there are no barriers so I'm not sure this would be
> >> guaranteed to give us the correct answer anyway.
> >>
> >> As far as all of these functions go, should they return const*?
> >> Presumably
> >> you wouldn't want to allow changes to the current state.
> > Yep, need at least a lockdep check for the plane->mutex. And imo also a
> > check that we're indeed in atomic_check per the idea I dropped on the
> > cover letter.
> >
> > And +1 on const * for these, that seems like a very important check.
> Well I allowed for crtc lock held because the __ function uses
> crtc->mutex as safety lock.
> >>> What is this so called __ function exactly?
> >> __drm_atomic_get_current_plane_state, which is only used by
> >> drm_atomic_crtc_state_for_each_plane_state.
> >>
> >> It iterates over crtc_state->plane_mask and then gets new_plane_state if
> >> available, or plane->state if the plane is not part of the state.
> >> This is mostly used for watermark calculations.
> > Sounds like we should kill that sucker and make things clearer by
> > enforcing the "want to access foo->state? then grab foo->lock first"
> > rule.
> Except adding all planes to cursor updates would result in unintended
> behavior.
That wasn't my suggestion.
> And there are already patches to use the sprite plane instead of the cursor
> plane for skylake, so it's not just theoretical. :)
>
> Testcases:
> flip-vs-cursor-busy-crc-legacy
> flip-vs-cursor-busy-crc-atomic
>
> ~Maarten
--
Ville Syrjälä
Intel OTC
[PATCH 4/5] drm/i915: Find fallback link rate/lane count
On Tue, 15 Nov 2016, Manasi Navare wrote:
> If link training fails, then we need to fallback to lower
> link rate first and if link training fails at RBR, then
> fallback to lower lane count.
> This function finds the next lower link rate/lane count
> value after link training failure.
>
> v2:
> Squash the patch that returns the link rate index (Jani Nikula)
>
> Acked-by: Tony Cheng
> Acked-by: Harry Wentland
> Cc: Ville Syrjala
> Cc: Jani Nikula
> Cc: Daniel Vetter
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/i915/intel_dp.c | 42
>
> drivers/gpu/drm/i915/intel_drv.h | 6 ++
> 2 files changed, 48 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index a1b0181..e87b451 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -288,6 +288,48 @@ static int intel_dp_common_rates(struct intel_dp
> *intel_dp,
> common_rates);
> }
>
> +static int intel_dp_link_rate_index(struct intel_dp *intel_dp,
> + int *common_rates, int link_rate)
> +{
> + int common_len;
> + int index;
> +
> + common_len = intel_dp_common_rates(intel_dp, common_rates);
> + for (index = 0; index < common_len; index++) {
> + if (link_rate == common_rates[common_len - index - 1])
> + return common_len - index - 1;
> + }
> +
> + return -1;
> +}
> +
> +int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
> + int link_rate, uint8_t lane_count)
> +{
> + int common_rates[DP_MAX_SUPPORTED_RATES] = {};
> + int common_len;
> + int link_rate_index = -1;
> +
> + common_len = intel_dp_common_rates(intel_dp, common_rates);
> + link_rate_index = intel_dp_link_rate_index(intel_dp,
> +common_rates,
> +link_rate);
> + if (link_rate_index > 0) {
> + intel_dp->fallback_link_rate_index = link_rate_index - 1;
> + intel_dp->fallback_link_rate =
> common_rates[intel_dp->fallback_link_rate_index];
fallback_link_rate_index and fallback_link_rate are two ways to express
the same thing, and you can derive one from the other. When you have
two, you run the risk of having them out of sync. I thought I'd
mentioned this in earlier review.
Please do not store fallback_link_rate_index in intel_dp. Only store
fallback_link_rate. You can use your intel_dp_link_rate_index() function
when you need to convert rate to index.
Moreover, resetting the state becomes more clear when all can be set to
0.
BR,
Jani.
> + intel_dp->fallback_lane_count =
> intel_dp_max_lane_count(intel_dp);
> + } else if (lane_count > 1) {
> + intel_dp->fallback_link_rate_index = common_len - 1;
> + intel_dp->fallback_link_rate =
> common_rates[intel_dp->fallback_link_rate_index];
> + intel_dp->fallback_lane_count = lane_count >> 1;
> + } else {
> + DRM_ERROR("Link Training Unsuccessful\n");
> + return -1;
> + }
> +
> + return 0;
> +}
> +
> static enum drm_mode_status
> intel_dp_mode_valid(struct drm_connector *connector,
> struct drm_display_mode *mode)
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 75252ec..55ceb44 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -887,6 +887,10 @@ struct intel_dp {
> uint32_t DP;
> int link_rate;
> uint8_t lane_count;
> + int fallback_link_rate;
> + uint8_t fallback_lane_count;
> + int fallback_link_rate_index;
> + bool link_train_failed;
> uint8_t sink_count;
> bool link_mst;
> bool has_audio;
> @@ -1383,6 +1387,8 @@ bool intel_dp_init_connector(struct intel_digital_port
> *intel_dig_port,
> void intel_dp_set_link_params(struct intel_dp *intel_dp,
> int link_rate, uint8_t lane_count,
> bool link_mst);
> +int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
> + int link_rate, uint8_t lane_count);
> void intel_dp_start_link_train(struct intel_dp *intel_dp);
> void intel_dp_stop_link_train(struct intel_dp *intel_dp);
> void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);
--
Jani Nikula, Intel Open Source Technology Center
[PATCH libdrm] intel: Add a getter for the intel_context ctx_id
I forgot that my recently sent out i915-perf i-g-t tests depend on this utility
api (not just my Mesa / GL_INTEL_performance_query patches).
Not all tests in i-g-t use libdrm to create contexts, but the i915-perf tests
use render_copy (drm_intel_context based) while testing single context
filtering and so want to pluck out the u32 ctx_id for passing to i915-perf.
I made a last moment tweak to the utility to return an error value separate
from a uint32_t output ctx_id pointer, so there will need to be a corresponding
tweak of the perf.c tests I sent out.
Regards,
- Robert
--- >8 ---
Exposing the u32 context ID makes it possible to define new drm kernel
interfaces based on the same IDs that e.g. execbuf uses to identify a
gem context, that aren't themselves abstracted by libdrm but need to be
used by libdrm/drm_intel_context based clients such as (parts of) i-g-t
or Mesa.
For example this can be used to configure an i915-perf stream to collect
metrics for a specific context.
Signed-off: Robert Bragg
---
intel/intel_bufmgr.h | 2 ++
intel/intel_bufmgr_gem.c | 11 +++
2 files changed, 13 insertions(+)
diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
index ce4e70d..7530fa5 100644
--- a/intel/intel_bufmgr.h
+++ b/intel/intel_bufmgr.h
@@ -212,6 +212,8 @@ int drm_intel_bufmgr_gem_get_devid(drm_intel_bufmgr
*bufmgr);
int drm_intel_gem_bo_wait(drm_intel_bo *bo, int64_t timeout_ns);
drm_intel_context *drm_intel_gem_context_create(drm_intel_bufmgr *bufmgr);
+int drm_intel_gem_context_get_context_id(drm_intel_context *ctx,
+uint32_t *ctx_id);
void drm_intel_gem_context_destroy(drm_intel_context *ctx);
int drm_intel_gem_bo_context_exec(drm_intel_bo *bo, drm_intel_context *ctx,
int used, unsigned int flags);
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 15c79b3..cefe4a7 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -3184,6 +3184,17 @@ drm_intel_gem_context_create(drm_intel_bufmgr *bufmgr)
return context;
}
+int
+drm_intel_gem_context_get_context_id(drm_intel_context *ctx, uint32_t *ctx_id)
+{
+ if (ctx == NULL)
+ return -EINVAL;
+
+ *ctx_id = ctx->ctx_id;
+
+ return 0;
+}
+
void
drm_intel_gem_context_destroy(drm_intel_context *ctx)
{
--
2.10.1
[PATCH v2.1 2/4] drm/atomic: Add accessor macros for the current state, v2.
With checks! This will allow safe access to the current state,
while ensuring that the correct locks are held.
Changes since v1:
- Constify returned states.
- Require plane lock to return plane state, don't allow crtc_lock to
be sufficient.
Signed-off-by: Maarten Lankhorst
---
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index e527684dd394..9af5aba8c27c 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -334,6 +334,66 @@ __drm_atomic_get_current_plane_state(struct
drm_atomic_state *state,
return plane->state;
}
+
+/**
+ * drm_atomic_get_current_plane_state - get current plane state
+ * @plane: plane to grab
+ *
+ * This function returns the current plane state for the given plane,
+ * with extra locking checks to make sure that the plane state can be
+ * retrieved safely.
+ *
+ * Returns:
+ *
+ * Pointer to the current plane state.
+ */
+static inline const struct drm_plane_state *
+drm_atomic_get_current_plane_state(struct drm_plane *plane)
+{
+ drm_modeset_lock_assert_held(&plane->mutex);
+
+ return plane->state;
+}
+
+/**
+ * drm_atomic_get_current_crtc_state - get current crtc state
+ * @crtc: crtc to grab
+ *
+ * This function returns the current crtc state for the given crtc,
+ * with extra locking checks to make sure that the crtc state can be
+ * retrieved safely.
+ *
+ * Returns:
+ *
+ * Pointer to the current crtc state.
+ */
+static inline const struct drm_crtc_state *
+drm_atomic_get_current_crtc_state(struct drm_crtc *crtc)
+{
+ drm_modeset_lock_assert_held(&crtc->mutex);
+
+ return crtc->state;
+}
+
+/**
+ * drm_atomic_get_current_connector_state - get current connector state
+ * @connector: connector to grab
+ *
+ * This function returns the current connector state for the given connector,
+ * with extra locking checks to make sure that the connector state can be
+ * retrieved safely.
+ *
+ * Returns:
+ *
+ * Pointer to the current connector state.
+ */
+#define drm_atomic_get_current_connector_state(connector) \
+({ /* Implemented as macro to avoid including drmP for struct drm_device */ \
+ struct drm_connector *con__ = (connector); \
+
drm_modeset_lock_assert_held(&con__->dev->mode_config.connection_mutex); \
+ (const struct drm_connector_state *)con__->state; \
+})
+
int __must_check
drm_atomic_set_mode_for_crtc(struct drm_crtc_state *state,
struct drm_display_mode *mode);
diff --git a/include/drm/drm_modeset_lock.h b/include/drm/drm_modeset_lock.h
index d918ce45ec2c..3ca4ee838b07 100644
--- a/include/drm/drm_modeset_lock.h
+++ b/include/drm/drm_modeset_lock.h
@@ -109,6 +109,15 @@ static inline bool drm_modeset_is_locked(struct
drm_modeset_lock *lock)
return ww_mutex_is_locked(&lock->mutex);
}
+static inline void drm_modeset_lock_assert_held(struct drm_modeset_lock *lock)
+{
+#ifdef CONFIG_LOCKDEP
+ lockdep_assert_held(&lock->mutex.base);
+#else
+ WARN_ON(!drm_modeset_is_locked(lock));
+#endif
+}
+
int drm_modeset_lock(struct drm_modeset_lock *lock,
struct drm_modeset_acquire_ctx *ctx);
int drm_modeset_lock_interruptible(struct drm_modeset_lock *lock,
[PATCH v3] PCI: create revision file in sysfs
On Wed, Nov 16, 2016 at 3:58 PM, Bjorn Helgaas wrote: > [+cc Sinan, Lukas] > > Hi Daniel, > > On Mon, Nov 14, 2016 at 07:40:03PM +0100, Daniel Vetter wrote: >> On Fri, Nov 11, 2016 at 02:37:23PM +, Emil Velikov wrote: >> > From: Emil Velikov >> > >> > Currently the revision isn't available via sysfs/libudev thus if one >> > wants to know the value they need to read through the config file. >> > >> > This in itself wakes/powers up the device, causing unwanted delay >> > since it can be quite costly. >> > >> > There are at least two userspace components which could make use the new >> > file libpciaccess and libdrm. The former [used in various places] wakes >> > up _every_ PCI device, which can be observed via glxinfo [when using >> > Mesa 10.0+ drivers]. While the latter [in association with Mesa 13.0] >> > can lead to 2-3 second delays while starting firefox, thunderbird or >> > chromium. >> > >> > Expose the revision as a separate file, just like we do for the device, >> > vendor, their subsystem version and class. >> > >> > Cc: Bjorn Helgaas >> > Cc: linux-pci at vger.kernel.org >> > Cc: Greg KH >> > Link: https://bugs.freedesktop.org/show_bug.cgi?id=98502 >> > Tested-by: Mauro Santos >> > Reviewed-by: Alex Deucher >> > Signed-off-by: Emil Velikov >> >> Given that waking a gpu can take somewhere between ages and forever, and >> that we read the pci revisions everytime we launch a new gl app I think >> this is the correct approach. Of course we could just patch libdrm and >> everyone to not look at the pci revision, but that just leads to every >> pci-based driver having a driver-private ioctl/getparam thing to expose >> it. Which also doesn't make much sense. > > This re-asserts what has already been said, but doesn't address any of > my questions in the v2 discussion, so I'm still looking to continue > that thread. > > I am curious about this long wakeup issue, though. Are we talking > about a D3cold -> D0 transition? I assume so, since config space is > generally accessible in all power states except D3cold. From the > device's point of view this is basically like a power-on. I think the > gist of PCIe r3.0, sec 6.6.1 is that we need to wait 100ms, e.g., > PCI_PM_D3COLD_WAIT, before doing config accesses. > > We do support Configuration Request Retry Status Software Visibility > (pci_enable_crs()), so a device *can* take longer than 100ms after > power-up to respond to a config read, but I think that only applies to > reads of the Vendor ID. I cc'd Sinan because we do have some issues > with our CRS support, and maybe he can shed some light on this. > > I'm not surprised if a GPU takes longer than 100ms to do device- > specific, driver-managed, non-PCI things like detect and wake up > monitors. But I *am* surprised if generic PCI bus-level things like > config reads take longer than that. I also cc'd Lukas because he > knows a lot more about PCI PM than I do. FWIW, If you run lspci on a GPU that is in the powered off state (either D3 cold if supported or the older vendor specific power controls that pre-dated D3 cold), any fields that were not previously cached return all 1s. So for example the pci revision would be 0xff rather than whatever it's supposed to be. Alex
[PATCH v3 0/3] drm/tilcdc: Add bridge support and sync-lost flood recovery
Changes since v2: - "drm/tilcdc: Recover from sync lost error flood by resetting the LCDC" - no change - "drm/bridge: Add ti-tfp410 DVI transmitter driver" - Fix deveice-tree document - "driver node" -> "device node" - remove "(the current implementation does not yet support this)" - Add dummy i2c support. The driver probe works also if placed under i2c controller node, but there is no actual i2c probing. - "drm/tilcdc: Add drm bridge support for attaching drm bridge drivers" - no change Changes since first version of the series: - "drm/tilcdc: Recover from sync lost error flood by resetting the LCDC" - no change - "drm/bridge: Add ti-tfp410 DVI transmitter driver" - HDMI -> DVI - DT Binding document - Prepare for tfp410 connected trough i2c by optional reg property - Require two port nodes - Implementation - Implement connector node functionality with in tfp410 bridge drive, but follow generic connector binding by pulling the ddc-i2c-bus property from the connector node. - "drm/tilcdc: Add drm bridge support for attaching drm bridge drivers" - Remove earlier change in TD binding document. There is no need to mention DRM implementation details, like bridge support, in DT binding. The first patch is an independent on and I've been testing it for quite a while now. The tfp410 bridge driver and the tilcdc bridge support are tested with BeagleBone DVI-D Cape Rev A3. The tfp410 bridge driver is missing a lot of features, because the DVI-D cape does not have too many wires connected. The missing features can be added later when they are needed. Jyri Sarha (3): drm/tilcdc: Recover from sync lost error flood by resetting the LCDC drm/bridge: Add ti-tfp410 DVI transmitter driver drm/tilcdc: Add drm bridge support for attaching drm bridge drivers .../bindings/display/bridge/ti,tfp410.txt | 40 +++ drivers/gpu/drm/bridge/Kconfig | 7 + drivers/gpu/drm/bridge/Makefile| 1 + drivers/gpu/drm/bridge/ti-tfp410.c | 287 + drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 26 +- drivers/gpu/drm/tilcdc/tilcdc_drv.c| 7 +- drivers/gpu/drm/tilcdc/tilcdc_drv.h| 2 + drivers/gpu/drm/tilcdc/tilcdc_external.c | 140 -- drivers/gpu/drm/tilcdc/tilcdc_external.h | 1 + 9 files changed, 491 insertions(+), 20 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt create mode 100644 drivers/gpu/drm/bridge/ti-tfp410.c -- 1.9.1
[PATCH v3 3/3] drm/tilcdc: Add drm bridge support for attaching drm bridge drivers
Adds drm bride support for attaching drm bridge drivers to tilcdc. The
decision whether a video port leads to an external encoder or bridge
is made simply based on remote device's compatible string. The code
has been tested with BeagleBone-Black with and without BeagleBone
DVI-D Cape Rev A3 using ti-tfp410 driver.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 7 +-
drivers/gpu/drm/tilcdc/tilcdc_drv.h | 2 +
drivers/gpu/drm/tilcdc/tilcdc_external.c | 140 +++
drivers/gpu/drm/tilcdc/tilcdc_external.h | 1 +
4 files changed, 131 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 3d2cea0..af959df 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -384,9 +384,14 @@ static int tilcdc_init(struct drm_driver *ddrv, struct
device *dev)
ret = tilcdc_add_external_encoders(ddev);
if (ret < 0)
goto init_failed;
+ } else {
+ ret = tilcdc_attach_remote_device(ddev);
+ if (ret)
+ goto init_failed;
}
- if ((priv->num_encoders == 0) || (priv->num_connectors == 0)) {
+ if (!priv->remote_encoder &&
+ ((priv->num_encoders == 0) || (priv->num_connectors == 0))) {
dev_err(dev, "no encoders/connectors found\n");
ret = -ENXIO;
goto init_failed;
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
index d31fe5d..283ff28 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
@@ -90,6 +90,8 @@ struct tilcdc_drm_private {
struct drm_connector *connectors[8];
const struct drm_connector_helper_funcs *connector_funcs[8];
+ struct drm_encoder *remote_encoder;
+
bool is_registered;
bool is_componentized;
};
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c
b/drivers/gpu/drm/tilcdc/tilcdc_external.c
index 06a4c58..e1576ba 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_external.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_external.c
@@ -28,6 +28,18 @@
.raster_order = 0,
};
+static const struct tilcdc_panel_info panel_info_default = {
+ .ac_bias= 255,
+ .ac_bias_intrpt = 0,
+ .dma_burst_sz = 16,
+ .bpp= 16,
+ .fdd= 0x80,
+ .tft_alt_mode = 0,
+ .sync_edge = 0,
+ .sync_ctrl = 1,
+ .raster_order = 0,
+};
+
static int tilcdc_external_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
{
@@ -130,6 +142,101 @@ void tilcdc_remove_external_encoders(struct drm_device
*dev)
priv->connector_funcs[i]);
}
+static const struct drm_encoder_funcs tilcdc_remote_encoder_funcs = {
+ .destroy= drm_encoder_cleanup,
+};
+
+static
+int tilcdc_attach_bridge(struct drm_device *ddev, struct drm_bridge *bridge)
+{
+ struct tilcdc_drm_private *priv = ddev->dev_private;
+ int ret;
+
+ priv->remote_encoder->possible_crtcs = BIT(0);
+ priv->remote_encoder->bridge = bridge;
+ bridge->encoder = priv->remote_encoder;
+
+ ret = drm_bridge_attach(ddev, bridge);
+ if (ret) {
+ dev_err(ddev->dev, "drm_bridge_attach() failed %d\n", ret);
+ return ret;
+ }
+
+ tilcdc_crtc_set_panel_info(priv->crtc, &panel_info_default);
+
+ return 0;
+}
+
+static int tilcdc_node_has_port(struct device_node *dev_node)
+{
+ struct device_node *node;
+
+ node = of_get_child_by_name(dev_node, "ports");
+ if (!node)
+ node = of_get_child_by_name(dev_node, "port");
+ if (!node)
+ return 0;
+ of_node_put(node);
+
+ return 1;
+}
+
+static
+struct device_node *tilcdc_get_remote_node(struct device_node *node)
+{
+ struct device_node *ep;
+ struct device_node *parent;
+
+ if (!tilcdc_node_has_port(node))
+ return NULL;
+
+ ep = of_graph_get_next_endpoint(node, NULL);
+ if (!ep)
+ return NULL;
+
+ parent = of_graph_get_remote_port_parent(ep);
+ of_node_put(ep);
+
+ return parent;
+}
+
+int tilcdc_attach_remote_device(struct drm_device *ddev)
+{
+ struct tilcdc_drm_private *priv = ddev->dev_private;
+ struct device_node *remote_node;
+ struct drm_bridge *bridge;
+ int ret;
+
+ remote_node = tilcdc_get_remote_node(ddev->dev->of_node);
+ if (!remote_node)
+ return 0;
+
+ bridge = of_drm_find_bridge(remote_node);
+ of_node_put(remote_node);
+ if (!bridge
[PATCH v3 1/3] drm/tilcdc: Recover from sync lost error flood by resetting the LCDC
Recover from sync lost error flood by resetting the LCDC instead of
turning off the SYNC_LOST error IRQ. When LCDC starves on limited
memory bandwidth it may sometimes result an error situation when the
picture may have shifted couple of pixels to right and SYNC_LOST
interrupt is generated on every frame. LCDC main reset recovers from
this situation and causes a brief blanking on the screen.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 0d09acc..c787349 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -55,6 +55,7 @@ struct tilcdc_crtc {
int sync_lost_count;
bool frame_intact;
+ struct work_struct recover_work;
};
#define to_tilcdc_crtc(x) container_of(x, struct tilcdc_crtc, base)
@@ -252,6 +253,25 @@ static bool tilcdc_crtc_is_on(struct drm_crtc *crtc)
return crtc->state && crtc->state->enable && crtc->state->active;
}
+static void tilcdc_crtc_recover_work(struct work_struct *work)
+{
+ struct tilcdc_crtc *tilcdc_crtc =
+ container_of(work, struct tilcdc_crtc, recover_work);
+ struct drm_crtc *crtc = &tilcdc_crtc->base;
+
+ dev_info(crtc->dev->dev, "%s: Reset CRTC", __func__);
+
+ drm_modeset_lock_crtc(crtc, NULL);
+
+ if (!tilcdc_crtc_is_on(crtc))
+ goto out;
+
+ tilcdc_crtc_disable(crtc);
+ tilcdc_crtc_enable(crtc);
+out:
+ drm_modeset_unlock_crtc(crtc);
+}
+
static void tilcdc_crtc_destroy(struct drm_crtc *crtc)
{
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
@@ -838,9 +858,12 @@ irqreturn_t tilcdc_crtc_irq(struct drm_crtc *crtc)
tilcdc_crtc->frame_intact = false;
if (tilcdc_crtc->sync_lost_count++ >
SYNC_LOST_COUNT_LIMIT) {
- dev_err(dev->dev, "%s(0x%08x): Sync lost flood
detected, disabling the interrupt", __func__, stat);
+ dev_err(dev->dev, "%s(0x%08x): Sync lost flood
detected, recovering", __func__, stat);
+ queue_work(system_wq,
+ &tilcdc_crtc->recover_work);
tilcdc_write(dev, LCDC_INT_ENABLE_CLR_REG,
LCDC_SYNC_LOST);
+ tilcdc_crtc->sync_lost_count = 0;
}
}
@@ -880,6 +903,7 @@ struct drm_crtc *tilcdc_crtc_create(struct drm_device *dev)
"unref", unref_worker);
spin_lock_init(&tilcdc_crtc->irq_lock);
+ INIT_WORK(&tilcdc_crtc->recover_work, tilcdc_crtc_recover_work);
ret = drm_crtc_init_with_planes(dev, crtc,
&tilcdc_crtc->primary,
--
1.9.1
[PATCH v3 2/3] drm/bridge: Add ti-tfp410 DVI transmitter driver
Add very basic ti-ftp410 DVI transmitter driver. The only feature
separating this from a completely dummy bridge is the EDID read
support trough DDC I2C. Even that functionality should be in a
separate generic connector driver. However, because of missing DRM
infrastructure support the connector is implemented within the bridge
driver. Some tfp410 HW specific features may be added later if needed,
because there is a set of registers behind i2c if it is connected.
This implementation is tested against my new tilcdc bridge support
and it works with BeagleBone DVI-D Cape Rev A3. A DT binding document
is also added.
Signed-off-by: Jyri Sarha
---
.../bindings/display/bridge/ti,tfp410.txt | 40 +++
drivers/gpu/drm/bridge/Kconfig | 7 +
drivers/gpu/drm/bridge/Makefile| 1 +
drivers/gpu/drm/bridge/ti-tfp410.c | 287 +
4 files changed, 335 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
create mode 100644 drivers/gpu/drm/bridge/ti-tfp410.c
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
new file mode 100644
index 000..6174b18
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
@@ -0,0 +1,40 @@
+TFP410 DVI bridge bindings
+
+Required properties:
+ - compatible: "ti,tfp410"
+
+Optional properties
+ - reg: I2C address. If and only if present the device node
+ should be placed into the i2c controller node where the
+ tfp410 i2c is connected to.
+
+Required subnodes:
+ - port at 0: Video input port node to connect the bridge to a
+ display controller output [1].
+ - port at 1: Video output port node to connect the bridge to a
+ connector input [1].
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+ hdmi-bridge {
+ compatible = "ti,tfp410";
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ bridge_in: endpoint {
+ remote-endpoint = <&dc_out>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ bridge_out: endpoint {
+ remote-endpoint = <&hdmi_in>;
+ };
+ };
+ };
+ };
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index bd6acc8..a424e03 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -81,6 +81,13 @@ config DRM_TOSHIBA_TC358767
---help---
Toshiba TC358767 eDP bridge chip driver.
+config DRM_TI_TFP410
+ tristate "TI TFP410 DVI/HDMI bridge"
+ depends on OF
+ select DRM_KMS_HELPER
+ ---help---
+ Texas Instruments TFP410 DVI/HDMI Transmitter driver
+
source "drivers/gpu/drm/bridge/analogix/Kconfig"
source "drivers/gpu/drm/bridge/adv7511/Kconfig"
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 97ed1a5..8b065d9 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_DRM_SII902X) += sii902x.o
obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
+obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
b/drivers/gpu/drm/bridge/ti-tfp410.c
new file mode 100644
index 000..64f54e4
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ti-tfp410.c
@@ -0,0 +1,287 @@
+/*
+ * Copyright (C) 2016 Texas Instruments
+ * Author: Jyri Sarha
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+struct tfp410 {
+ struct drm_bridge bridge;
+ struct drm_connectorconnector;
+
+ struct i2c_adapter *ddc;
+
+ struct device *dev;
+};
+
+static inline struct tfp410 *
+drm_bridge_to_tfp410(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct tfp410, bridge);
+}
+
+static inline struct tfp410 *
+drm_connector_to_tfp410(struct drm_connector *connector)
+{
+ return container_of(connector, struct tfp410, connector);
+}
+
+static int tfp410_get_modes(struct drm_connector *connector)
+{
+ struct tfp410 *dvi = drm_connector_to_tfp410(connector);
+ struct edid *edid;
+ int ret;
+
+ if (!dvi->ddc)
+
[Bug 98693] Mad Max: Long lags when VRAM full
https://bugs.freedesktop.org/show_bug.cgi?id=98693 --- Comment #5 from Alex Deucher --- (In reply to Jani Kärkkäinen from comment #4) > "The game I'm testing needs 3.4 GB of VRAM. > > Setups: > Tonga - 2 GB: It's nearly unplayable, because freezes occur too often. > Fiji - 4 GB: There is one freeze at the beginning (which is annoying > too), after that it's smooth. > > So even 4 GB is not enough." > > Also the descriptions of the problem seem to match mine. A problem in memory > handling? The freeze at the beginning is most likely shader compilation. Mesa does not have a shader cache yet. -- 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/20161117/f56f4e05/attachment.html>
[PATCH v3 2/3] drm/bridge: Add ti-tfp410 DVI transmitter driver
On 11/17/16 15:28, Jyri Sarha wrote:
> Add very basic ti-ftp410 DVI transmitter driver. The only feature
> separating this from a completely dummy bridge is the EDID read
> support trough DDC I2C. Even that functionality should be in a
> separate generic connector driver. However, because of missing DRM
> infrastructure support the connector is implemented within the bridge
> driver. Some tfp410 HW specific features may be added later if needed,
> because there is a set of registers behind i2c if it is connected.
>
> This implementation is tested against my new tilcdc bridge support
> and it works with BeagleBone DVI-D Cape Rev A3. A DT binding document
> is also added.
>
> Signed-off-by: Jyri Sarha
> ---
> .../bindings/display/bridge/ti,tfp410.txt | 40 +++
> drivers/gpu/drm/bridge/Kconfig | 7 +
> drivers/gpu/drm/bridge/Makefile| 1 +
> drivers/gpu/drm/bridge/ti-tfp410.c | 287
> +
> 4 files changed, 335 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
> create mode 100644 drivers/gpu/drm/bridge/ti-tfp410.c
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
> b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
> new file mode 100644
> index 000..6174b18
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
> @@ -0,0 +1,40 @@
> +TFP410 DVI bridge bindings
> +
> +Required properties:
> + - compatible: "ti,tfp410"
> +
> +Optional properties
> + - reg: I2C address. If and only if present the device node
> + should be placed into the i2c controller node where the
> + tfp410 i2c is connected to.
> +
> +Required subnodes:
> + - port at 0: Video input port node to connect the bridge to a
> + display controller output [1].
> + - port at 1: Video output port node to connect the bridge to a
> + connector input [1].
> +
> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example:
> + hdmi-bridge {
> + compatible = "ti,tfp410";
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + bridge_in: endpoint {
> + remote-endpoint = <&dc_out>;
> + };
> + };
> +
> + port at 1 {
> + reg = <1>;
> + bridge_out: endpoint {
> + remote-endpoint = <&hdmi_in>;
> + };
> + };
> + };
> + };
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index bd6acc8..a424e03 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -81,6 +81,13 @@ config DRM_TOSHIBA_TC358767
> ---help---
> Toshiba TC358767 eDP bridge chip driver.
>
> +config DRM_TI_TFP410
> + tristate "TI TFP410 DVI/HDMI bridge"
> + depends on OF
> + select DRM_KMS_HELPER
> + ---help---
> + Texas Instruments TFP410 DVI/HDMI Transmitter driver
> +
> source "drivers/gpu/drm/bridge/analogix/Kconfig"
>
> source "drivers/gpu/drm/bridge/adv7511/Kconfig"
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 97ed1a5..8b065d9 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -11,3 +11,4 @@ obj-$(CONFIG_DRM_SII902X) += sii902x.o
> obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
> obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> +obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
> diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
> b/drivers/gpu/drm/bridge/ti-tfp410.c
> new file mode 100644
> index 000..64f54e4
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
> @@ -0,0 +1,287 @@
> +/*
> + * Copyright (C) 2016 Texas Instruments
> + * Author: Jyri Sarha
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published
> by
> + * the Free Software Foundation.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +
> +struct tfp410 {
> + struct drm_bridge bridge;
> + struct drm_connectorconnector;
> +
> + struct i2c_adapter *ddc;
> +
> + struct device *dev;
> +};
> +
> +static inline struct tfp410 *
> +drm_bridge_to_tfp410(struct drm_bridge *bridge)
> +{
> + return container_of(bridge, struct tfp410, bridge);
> +}
> +
> +static inline struct tfp410 *
> +drm_connector_to_tfp410(struct drm_connector *connector)
> +{
> + return container
[Intel-gfx] [PATCH v2 1/4] drm: Define drm_mm_for_each_node_in_range()
On to, 2016-11-17 at 12:08 +, Chris Wilson wrote:
> Some clients would like to iterate over every node within a certain
> range. Make a nice little macro for them to hide the mixing of the
> rbtree search and linear walk.
>
> Signed-off-by: Chris Wilson
> Cc: Daniel Vetter
> Cc: dri-devel at lists.freedesktop.org
>
>
> @@ -174,19 +174,12 @@ INTERVAL_TREE_DEFINE(struct drm_mm_node, rb,
> Â Â Â Â Â Â START, LAST, static inline, drm_mm_interval_tree)
> Â
> Â struct drm_mm_node *
> -drm_mm_interval_first(struct drm_mm *mm, u64 start, u64 last)
> +__drm_mm_interval_first(struct drm_mm *mm, u64 start, u64 last)
> Â {
> Â return drm_mm_interval_tree_iter_first(&mm->interval_tree,
> Â Â Â Â Â Â Â Â start, last);
> Â }
> -EXPORT_SYMBOL(drm_mm_interval_first);
> -
> -struct drm_mm_node *
> -drm_mm_interval_next(struct drm_mm_node *node, u64 start, u64 last)
> -{
> - return drm_mm_interval_tree_iter_next(node, start, last);
> -}
> -EXPORT_SYMBOL(drm_mm_interval_next);
These were introduced by you so I guess the reason for them ceased to
exist, so the removal should not hurt anybody.
> +EXPORT_SYMBOL(__drm_mm_interval_first);
> Â
> Â static void drm_mm_interval_tree_add_node(struct drm_mm_node *hole_node,
> Â Â Â struct drm_mm_node *node)
> diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
> index 41ddafe92b2f..fca5f313cf18 100644
> --- a/include/drm/drm_mm.h
> +++ b/include/drm/drm_mm.h
> @@ -308,10 +308,12 @@ void drm_mm_takedown(struct drm_mm *mm);
> Â bool drm_mm_clean(struct drm_mm *mm);
> Â
> Â struct drm_mm_node *
> -drm_mm_interval_first(struct drm_mm *mm, u64 start, u64 last);
> +__drm_mm_interval_first(struct drm_mm *mm, u64 start, u64 last);
> Â
> -struct drm_mm_node *
> -drm_mm_interval_next(struct drm_mm_node *node, u64 start, u64 last);
> +#define drm_mm_for_each_node_in_range(node, mm, start, end) \
> + for (node = __drm_mm_interval_first((mm), (start), (end)-1);\
> + Â Â Â Â Â node && node->start < (end); \
> + Â Â Â Â Â node = list_next_entry(node, node_list))
> \
Drop a quick kerneldoc for this. It's almost ready in the commit message.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
[PATCH v3] PCI: create revision file in sysfs
On Thu, Nov 17, 2016 at 9:35 AM, Bjorn Helgaas wrote: > On Thu, Nov 17, 2016 at 08:28:50AM -0500, Alex Deucher wrote: >> On Wed, Nov 16, 2016 at 3:58 PM, Bjorn Helgaas wrote: >> > On Mon, Nov 14, 2016 at 07:40:03PM +0100, Daniel Vetter wrote: >> >> Given that waking a gpu can take somewhere between ages and forever, and >> >> that we read the pci revisions everytime we launch a new gl app I think >> >> this is the correct approach. Of course we could just patch libdrm and >> >> everyone to not look at the pci revision, but that just leads to every >> >> pci-based driver having a driver-private ioctl/getparam thing to expose >> >> it. Which also doesn't make much sense. >> > >> > I am curious about this long wakeup issue, though. Are we talking >> > about a D3cold -> D0 transition? I assume so, since config space is >> > generally accessible in all power states except D3cold. From the >> > device's point of view this is basically like a power-on. I think the >> > gist of PCIe r3.0, sec 6.6.1 is that we need to wait 100ms, e.g., >> > PCI_PM_D3COLD_WAIT, before doing config accesses. >> > >> > We do support Configuration Request Retry Status Software Visibility >> > (pci_enable_crs()), so a device *can* take longer than 100ms after >> > power-up to respond to a config read, but I think that only applies to >> > reads of the Vendor ID. I cc'd Sinan because we do have some issues >> > with our CRS support, and maybe he can shed some light on this. >> > >> > I'm not surprised if a GPU takes longer than 100ms to do device- >> > specific, driver-managed, non-PCI things like detect and wake up >> > monitors. But I *am* surprised if generic PCI bus-level things like >> > config reads take longer than that. I also cc'd Lukas because he >> > knows a lot more about PCI PM than I do. >> >> FWIW, If you run lspci on a GPU that is in the powered off state >> (either D3 cold if supported or the older vendor specific power >> controls that pre-dated D3 cold), any fields that were not previously >> cached return all 1s. So for example the pci revision would be 0xff >> rather than whatever it's supposed to be. > > That doesn't feel like the right behavior to me -- I would have > expected lspci to either wake up the device and show valid data or > maybe complain "this device is powered off" (this seems hard to do > without races). Showing a mix of cached valid data and all 1s data > seems like a strange user experience to me. > > Caching the revision would fix that particular piece, of course, but > not the overall experience. Am I expecting too much? Maybe my > expectations are out of line. I agree with you, I'm just saying that that is the current behavior. The GPU power is controlled by runtimepm, perhaps there is a corner case we are missing when pci config space is accessed on a powered off device? Alex > > I think in this particular case (reading config space of a powered-off > device), CRS doesn't apply because the device is powered off, and > there's probably no delay: the read would probably complete > immediately because the link to the device is down, and the Root Port > or Downstream Port would probably generate an Unsupported Request > completion, which the Root Complex might handle by fabricating all 1s > data for the CPU. > > Bjorn
[PATCH] drm: Define drm_mm_for_each_node_in_range()
Some clients would like to iterate over every node within a certain
range. Make a nice little macro for them to hide the mixing of the
rbtree search and linear walk.
v2: Blurb
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_mm.c | 11 ++-
include/drm/drm_mm.h | 22 +++---
2 files changed, 21 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 632473beb40c..f8eebbde376e 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -174,19 +174,12 @@ INTERVAL_TREE_DEFINE(struct drm_mm_node, rb,
START, LAST, static inline, drm_mm_interval_tree)
struct drm_mm_node *
-drm_mm_interval_first(struct drm_mm *mm, u64 start, u64 last)
+__drm_mm_interval_first(struct drm_mm *mm, u64 start, u64 last)
{
return drm_mm_interval_tree_iter_first(&mm->interval_tree,
start, last);
}
-EXPORT_SYMBOL(drm_mm_interval_first);
-
-struct drm_mm_node *
-drm_mm_interval_next(struct drm_mm_node *node, u64 start, u64 last)
-{
- return drm_mm_interval_tree_iter_next(node, start, last);
-}
-EXPORT_SYMBOL(drm_mm_interval_next);
+EXPORT_SYMBOL(__drm_mm_interval_first);
static void drm_mm_interval_tree_add_node(struct drm_mm_node *hole_node,
struct drm_mm_node *node)
diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
index 41ddafe92b2f..6aab836c5338 100644
--- a/include/drm/drm_mm.h
+++ b/include/drm/drm_mm.h
@@ -308,10 +308,26 @@ void drm_mm_takedown(struct drm_mm *mm);
bool drm_mm_clean(struct drm_mm *mm);
struct drm_mm_node *
-drm_mm_interval_first(struct drm_mm *mm, u64 start, u64 last);
+__drm_mm_interval_first(struct drm_mm *mm, u64 start, u64 last);
-struct drm_mm_node *
-drm_mm_interval_next(struct drm_mm_node *node, u64 start, u64 last);
+/**
+ * drm_mm_for_each_node_in_range - iterator to walk over a range of
+ * allocated nodes
+ * @node: drm_mm_node structure to assign to in each iteration step
+ * @mm: drm_mm allocator to walk
+ * @start: starting offset, the first node will overlap this
+ * @end: ending offset, the last node will start before this (but may overlap)
+ *
+ * This iterator walks over all nodes in the range allocator that start
+ * between @start and @end. It is implemented similar to list_for_each(),
+ * but using the internal interval tree to accelerate the search for the
+ * starting node, and so not safe against removal of elements. It assumes
+ * that @end is within (or is the upper limit of) the drm_mm allocator.
+ */
+#define drm_mm_for_each_node_in_range(node, mm, start, end)\
+ for (node = __drm_mm_interval_first((mm), (start), (end)-1);\
+node && node->start < (end); \
+node = list_next_entry(node, node_list)) \
void drm_mm_init_scan(struct drm_mm *mm,
u64 size,
--
2.10.2
[PATCH v3] PCI: create revision file in sysfs
On Wed, Nov 16, 2016 at 02:58:11PM -0600, Bjorn Helgaas wrote: > On Mon, Nov 14, 2016 at 07:40:03PM +0100, Daniel Vetter wrote: > > On Fri, Nov 11, 2016 at 02:37:23PM +, Emil Velikov wrote: > > > From: Emil Velikov > > > > > > Currently the revision isn't available via sysfs/libudev thus if one > > > wants to know the value they need to read through the config file. > > > > > > This in itself wakes/powers up the device, causing unwanted delay > > > since it can be quite costly. > > > > > > There are at least two userspace components which could make use the new > > > file libpciaccess and libdrm. The former [used in various places] wakes > > > up _every_ PCI device, which can be observed via glxinfo [when using > > > Mesa 10.0+ drivers]. While the latter [in association with Mesa 13.0] > > > can lead to 2-3 second delays while starting firefox, thunderbird or > > > chromium. > > > > > > Expose the revision as a separate file, just like we do for the device, > > > vendor, their subsystem version and class. > > > > > > Cc: Bjorn Helgaas > > > Cc: linux-pci at vger.kernel.org > > > Cc: Greg KH > > > Link: https://bugs.freedesktop.org/show_bug.cgi?id=98502 > > > Tested-by: Mauro Santos > > > Reviewed-by: Alex Deucher > > > Signed-off-by: Emil Velikov > > > > Given that waking a gpu can take somewhere between ages and forever, and > > that we read the pci revisions everytime we launch a new gl app I think > > this is the correct approach. Of course we could just patch libdrm and > > everyone to not look at the pci revision, but that just leads to every > > pci-based driver having a driver-private ioctl/getparam thing to expose > > it. Which also doesn't make much sense. > > This re-asserts what has already been said, but doesn't address any of > my questions in the v2 discussion, so I'm still looking to continue > that thread. > > I am curious about this long wakeup issue, though. Are we talking > about a D3cold -> D0 transition? Yes, this is about a D3cold -> D0 transition, the bugzilla entry Emil linked talks about a dual GPU notebook. E.g. the Nvidia Kepler GPU in my MacBook Pro has 5 different power rails which must be brought up in a specific sequence (3.3V, 1.8V, 5V for the GPU, 1.35V for the video RAM and 1.05V for PCIe), something on the order of half a second to one second is reasonable for that. And the DRM driver needs a lot of time as well, half a second in the case of nouveau: [ 1500.780052] nouveau :01:00.0: DRM: resuming kernel object tree... [ 1501.176616] nouveau :01:00.0: DRM: resuming client object trees... [ 1501.176672] nouveau :01:00.0: DRM: resuming display... [ 1501.298985] nouveau :01:00.0: DRM: resuming console... There are no special PCIe things happening here. And since Sinan asked, these discrete GPUs usually aren't located behind a bridge, just a regular root port. Thanks, Lukas
[PATCH v5 1/7] drm: sunxi: Add a basic DRM driver for Allwinner DE2
On Wed, 16 Nov 2016 22:33:06 +0100
Maxime Ripard wrote:
> > > > The Device Engine just handles the planes of the LCDs, but, indeed,
> > > > the LCDs must know about the DE and the DE must know about the LCDs.
> > > > There are 2 ways to realize this knowledge in the DT:
> > > > 1) either the DE has one or two phandle's to the LCDs,
> > > > 2) or the LCDs have a phandle to the DE.
> > > >
> > > > I chose the 1st way, the DE ports pointing to the endpoint of the LCDs
> > > > which is part of the video link (OF-graph LCD <-> connector).
> > > > It would be possible to have phandles to the LCDs themselves, but this
> > > > asks for more code.
> > > >
> > > > The second way is also possible, but it also complexifies a bit the
> > > > exchanges DE <-> LCD.
> > >
> > > I'm still not sure how it would complexify anything, and why you can't
> > > use the display graph to model the relation between the display engine
> > > and the TCON (and why you want to use a generic property that refers
> > > to the of-graph while it really isn't).
> >
> > Complexification:
> > 1- my solution:
> > At startup time, the DE device is the DRM device.
>
> How do you deal with SoCs with multiple display engines then?
In the H3, A83T and A64, there is only one DE.
If many DEs in a SoC, there may be either one DRM device per DE or one
DRM device for the whole system. In this last case, the (global) DE
would have many resources (many I/O memory maps / IRQs..) and the
physical DE of each endpoint would be indicated by the position of its
phandle in the 'ports' array (DT documentation).
> > It has to know the devices entering in the video chains.
> > The CRTCs (LCD/TCON) are found by
> > ports[i] -> parent
> > The connectors are found by
> > ports[i] -> endpoint -> remote_endpoint -> parent
> > 2- with ports pointing to the LCDs:
> > The CRTCs (LCD/TCON) are simply
> > ports[i]
> > The connectors are found by
> > loop on all ports of ports[i]
> > ports[i][j] -> endpoint -> remote_endpoint -> parent
> > 3- with a phandle to the DE in the LCDs:
>
> What do you mean with LCD? Panels? Why would panels have a phandle to
> the display engine?
LCD is the same as CRTC. I don't think people will connect old CRT's to
their new ARM boards. LCD's may be panels, modern TV sets, or any
digital display. The word LCD seems clearer to me in this context, even
if there may a DAC as an ancoder.
> > The DE cannot be the DRM device because there is no information about
> > the video devices in the DT. Then, the DRM devices are the LCDs.
> > These LCDs must give their indices to the DE. So, the DE must implement
> > some callback function to accept a LCD definition, and there must be
> > a list of DEs in the driver to make the association DE <-> LCD[i]
> > Some more problem may be raised if a user wants to have the same frame
> > buffer on the 2 LCDs of a DE.
>
> I have no idea what you're talking about, sorry.
Here is the DT (I am using back 'CRTC'):
de: display-controller at xxx {
...
};
crtc0: crt-controller at xxx{
...
display-controller = <&de>;
ports {
... /* to the crtc0 connectors */
}
};
crtc1: crt-controller at xxx{
...
display-controller = <&de>;
ports {
... /* to the crtc1 connectors */
};
};
There are 2 DRM devices: one on crtc0, the other one on crtc1.
The DE device is isolated. But, to treat the planes, it must receive
information about the CRTCs. How?
> > Anyway, my solution is already used in the IMX Soc.
> > See 'display-subsystem' in arch/arm/boot/dts/imx6q.dtsi for an example.
>
> Pointing out random example in the tree doesn't make a compelling
> argument.
This is not a random example. There was a thread about the 'ports'
phandle in the DT definition of the IMX video subsystem, and what kind
of OF function should be used (see one of my previous mails). In the DRI
list, nobody objected about the phandle by itself.
> > > > > > > Panel functions? In the CRTC driver?
> > > > > >
> > > > > > Yes, dumb panel.
> > > > >
> > > > > What do you mean by that? Using a Parallel/RGB interface?
> > > >
> > > > Sorry, I though this was a well-known name. The 'dump panel' was used
> > > > in the documentation of my previous ARM machine as the video frame sent
> > > > to the HDMI controller. 'video_frame' is OK for you?
> > >
> > > If it's the frame sent to the encoder, then it would be the CRTC by
> > > DRM's nomenclature.
> >
> > The CRTC is a software entity. The frame buffer is a hardware entity.
>
> Why are you about framebuffer now, this is nowhere in that
> discussion. Any way, the framebuffer is also what is put in a plane,
> so there's a name collision here, and you'll probably want to change
> it.
>
> Judging by
[PATCH 1/2] Revert "drm/mediatek: fix a typo of OD_CFG to OD_RELAYMODE"
This reverts commit 83ba62bc700ba ("drm/mediatek: fix a typo of OD_CFG
to OD_RELAYMODE"), which causes a build failure:
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c:126:36: error: 'OD_CFG' undeclared
(first use in this function)
It currently applies on neither v4.9-rc nor today's linux-next
as the OD_CFG macro is not defined anywhere.
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index aa5f20f..df33b3c 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -123,7 +123,7 @@ static void mtk_od_config(struct mtk_ddp_comp *comp,
unsigned int w,
unsigned int bpc)
{
writel(w << 16 | h, comp->regs + DISP_OD_SIZE);
- writel(OD_RELAYMODE, comp->regs + OD_CFG);
+ writel(OD_RELAYMODE, comp->regs + OD_RELAYMODE);
mtk_dither_set(comp, bpc, DISP_OD_CFG);
}
--
2.9.0
[PATCH 2/2] Revert "drm/mediatek: set vblank_disable_allowed to true"
This reverts commit f752fff611b ("drm/mediatek: set vblank_disable_allowed
to true"), which no longer applies to mainline kernels and instead results
in a build failure:
drivers/gpu/drm/mediatek/mtk_drm_drv.c:220:5: error: 'struct drm_device' has
no member named 'vblank_disable_allowed'
The 'vblank_disable_allowed' member was removed in commit ee59065e58
("drm: Nuke ->vblank_disable_allowed") for v4.7.
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 0b2ae47..cf83f65 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -217,7 +217,6 @@ static int mtk_drm_kms_init(struct drm_device *drm)
if (ret < 0)
goto err_component_unbind;
- drm->vblank_disable_allowed = true;
drm_kms_helper_poll_init(drm);
drm_mode_config_reset(drm);
--
2.9.0
[Bug 98505] [radeon, amdgpu] Regression introduced in 4.8-rc3
https://bugs.freedesktop.org/show_bug.cgi?id=98505 --- Comment #30 from Nayan Deshmukh --- Created attachment 128042 --> https://bugs.freedesktop.org/attachment.cgi?id=128042&action=edit dmesg_with_debug_options Sorry for the delay, I compiled my kernel with CONFIG_DEBUG_ACPI=y followed the steps that you mentioned. -- 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/20161117/dbc40acb/attachment.html>
DRM: urgent v4.9-rc6 build regression: master build: 2 failures 1 warnings (v4.9-rc5-213-g961b708)
On Thursday, November 17, 2016 8:50:05 PM CET Dave Airlie wrote: > > Arnd could you send a git pull with the two reverts, with my Acked-by on > it? I won't be in a place to do it for 8-9hrs. I don't think it's that urgent, as long as we make sure it's fixed in the next -rc. I've sent out the reverts as patches with a little more information in the changelog: it turns out that they are actually broken on linux-next too, they had just not made it in there, and one of the two actually did build on older kernels. I think what happened here is that the fixes were tested on a v4.4 kernel and blindly forward-ported. It probably makes sense to look at the entire series again in case another one of them is broken. Philipp, Hu, Bibby, could one of you have another look? Arnd
[Bug 178421] [regression] Radeon Oops on shutdown
https://bugzilla.kernel.org/show_bug.cgi?id=178421 Jouni Mettälä changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX --- Comment #11 from Jouni Mettälä --- This bug is fixed between 4.9-rc4 and 4.9-rc5. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 98664] Fragment shader while loop causes geometry corruption
https://bugs.freedesktop.org/show_bug.cgi?id=98664 Nicolai Hähnle changed: What|Removed |Added Resolution|--- |NOTOURBUG Status|NEW |RESOLVED --- Comment #10 from Nicolai Hähnle --- The geometry shader is incorrect. I guess it works on i965 because the NIR path skips some optimizations that are allowed by the GLSL spec, which has this to say about EmitVertex(): "Emits the current values of output variables to the current output primitive. On return from this call, the values of output variables are undefined." In other words, you need to store outMinEdge / outMaxEdge in temporary variables. -- 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/20161117/c1e8a955/attachment.html>
[drm-intel:drm-intel-next-queued 2/2] drivers/gpu/drm/i915/i915_gem_stolen.c:516:20: warning: unused variable 'ggtt'
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: 95a2e2be952c3c3a643b8e0504f2ceef15294d4d
commit: 95a2e2be952c3c3a643b8e0504f2ceef15294d4d [2/2] drm/i915: Remove stolen
object spam
config: i386-defconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 95a2e2be952c3c3a643b8e0504f2ceef15294d4d
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
drivers/gpu/drm/i915/i915_gem_stolen.c: In function
'i915_pages_create_for_stolen':
>> drivers/gpu/drm/i915/i915_gem_stolen.c:516:20: warning: unused variable
>> 'ggtt' [-Wunused-variable]
struct i915_ggtt *ggtt = &dev_priv->ggtt;
^~~~
vim +/ggtt +516 drivers/gpu/drm/i915/i915_gem_stolen.c
1ca36d4cb Paulo Zanoni2015-09-23 500* on the first page. So we
don't reserve this page for now because of
1ca36d4cb Paulo Zanoni2015-09-23 501* that. Our current solution
is to just prevent new nodes from being
1ca36d4cb Paulo Zanoni2015-09-23 502* inserted on the first page -
see the check we have at
1ca36d4cb Paulo Zanoni2015-09-23 503*
i915_gem_stolen_insert_node_in_range(). We may want to fix the fbcon
1ca36d4cb Paulo Zanoni2015-09-23 504* problem later.
1ca36d4cb Paulo Zanoni2015-09-23 505*/
72e96d645 Joonas Lahtinen 2016-03-30 506
drm_mm_init(&dev_priv->mm.stolen, 0, ggtt->stolen_usable_size);
9797fbfbc Chris Wilson2012-04-24 507
9797fbfbc Chris Wilson2012-04-24 508 return 0;
9797fbfbc Chris Wilson2012-04-24 509 }
0104fdbb8 Chris Wilson2012-11-15 510
0104fdbb8 Chris Wilson2012-11-15 511 static struct sg_table *
0104fdbb8 Chris Wilson2012-11-15 512 i915_pages_create_for_stolen(struct
drm_device *dev,
0104fdbb8 Chris Wilson2012-11-15 513u32
offset, u32 size)
0104fdbb8 Chris Wilson2012-11-15 514 {
72e96d645 Joonas Lahtinen 2016-03-30 515 struct drm_i915_private
*dev_priv = to_i915(dev);
72e96d645 Joonas Lahtinen 2016-03-30 @516 struct i915_ggtt *ggtt =
&dev_priv->ggtt;
0104fdbb8 Chris Wilson2012-11-15 517 struct sg_table *st;
0104fdbb8 Chris Wilson2012-11-15 518 struct scatterlist *sg;
0104fdbb8 Chris Wilson2012-11-15 519
95a2e2be9 Chris Wilson2016-11-16 520 GEM_BUG_ON(offset >
ggtt->stolen_size - size);
0104fdbb8 Chris Wilson2012-11-15 521
0104fdbb8 Chris Wilson2012-11-15 522 /* We hide that we have no
struct page backing our stolen object
0104fdbb8 Chris Wilson2012-11-15 523* by wrapping the contiguous
physical allocation with a fake
0104fdbb8 Chris Wilson2012-11-15 524* dma mapping in a single
scatterlist.
:: The code at line 516 was first introduced by commit
:: 72e96d6450c067f58b65224bb5e73914e2cc43ab drm/i915: Refer to GGTT {,VM}
consistently
:: TO: Joonas Lahtinen
:: CC: Joonas Lahtinen
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 25157 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161117/6f938c34/attachment-0001.gz>
[Bug 98664] Fragment shader while loop causes geometry corruption
https://bugs.freedesktop.org/show_bug.cgi?id=98664 --- Comment #11 from Nicolai Hähnle --- Actually, I suspect we do have a related bug here in the Mesa state tracker, but you definitely need to fix that geometry shader. -- 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/20161117/313aac27/attachment.html>
[PATCH 00/32] drm: Deduplicate fb format information
From: Ville Syrjälä
This series aims to remove the duplicated format information stored under
drm_framebuffer (depth,bits_per_pixel,pixel_format), and instead we just
use the drm_format_info structure. And we store a pointer to the approriate
drm_format_info under drm_framebuffer so that we don't have to do expensive
linear searches through the big array.
Quite of bit of this was cocci magic, and I've tried to keep the cocci
patches pure of manual tinkering in case someone needs to rerun them.
I had some issues with cocci behaving like an idiot, so I've included
a bunch of hand rolled patches up front to make life easier for it.
I've smoke tested this on i915, and compile tested on everything else
(I hope).
Entire series available here:
git://github.com/vsyrjala/linux.git fb_format_dedup
Cc: Alex Deucher
Cc: Alexey Brodkin
Cc: Ben Skeggs
Cc: Brian Starkey
Cc: "Christian König"
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: intel-gfx at lists.freedesktop.org
Cc: linux-graphics-maintainer at vmware.com
Cc: Liviu Dudau
Cc: Mali DP Maintainers
Cc: Patrik Jakobsson
Cc: Paulo Zanoni
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
Ville Syrjälä (32):
drm/i915: Add local 'fb' variables
drm/radeon: Add local 'fb' variables
drm/radeon: Use DIV_ROUND_UP()
drm/mgag200: Add local 'fb' variable
drm/ast: Add local 'fb' variables
drm/gma500: Add some local 'fb' variables
drm/cirrus: Add some local 'fb' variables
drm/arcpgu: Add local 'fb' variables
drm/arm: Add local 'fb' variables
drm/nouveau: Fix crtc->primary->fb vs. drm_fb fail
drm/nouveau: Add local 'fb' variables
drm/vmwgfx: Populate fb->dev before drm_framebuffer_init()
drm: Pass 'dev' to drm_helper_mode_fill_fb_struct()
drm/vmwgfx: Populate fb->pixel_format
drm/qxl: Call drm_helper_mode_fill_fb_struct() before
drm_framebuffer_init()
drm/virtio: Call drm_helper_mode_fill_fb_struct() before
drm_framebuffer_init()
drm/i915: Set fb->dev early on for inherited fbs
drm: Populate fb->dev from drm_helper_mode_fill_fb_struct()
drm: Store a pointer to drm_format_info under drm_framebuffer
drm/vmwgfx: Populate fb->format correctly
drm/i915: Populate fb->format early for inherited fbs
drm/atomic: Replace drm_format_num_planes() with
fb->format->num_planes
drm/fb_cma_helper: Replace drm_format_info() with fb->format
drm/nouveau: Use fb->format rather than drm_format_info()
drm/i915: Store a pointer to the pixel format info for fbc
drm/i915: Replace drm_format_plane_cpp() with fb->format->cpp[]
drm/i915: Replace drm_format_num_planes() with fb->format->num_planes
drm: Add drm_framebuffer_plane_{width,height}()
drm/i915: Use drm_framebuffer_plane_{width,height}() where possible
drm: Nuke fb->depth
drm: Nuke fb->bits_per_pixel
drm: Nuke fb->pixel_format
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 4 +-
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 6 +-
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 6 +-
drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 6 +-
drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 6 +-
drivers/gpu/drm/arc/arcpgu_crtc.c | 3 +-
drivers/gpu/drm/arm/hdlcd_crtc.c| 18 +++---
drivers/gpu/drm/arm/malidp_planes.c | 10 ++--
drivers/gpu/drm/armada/armada_crtc.c| 6 +-
drivers/gpu/drm/armada/armada_fb.c | 2 +-
drivers/gpu/drm/armada/armada_fbdev.c | 5 +-
drivers/gpu/drm/armada/armada_overlay.c | 2 +-
drivers/gpu/drm/ast/ast_fb.c| 4 +-
drivers/gpu/drm/ast/ast_main.c | 2 +-
drivers/gpu/drm/ast/ast_mode.c | 16 +++--
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c | 2 +-
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 22 +++
drivers/gpu/drm/bochs/bochs_fbdev.c | 2 +-
drivers/gpu/drm/bochs/bochs_mm.c| 2 +-
drivers/gpu/drm/cirrus/cirrus_fbdev.c | 6 +-
drivers/gpu/drm/cirrus/cirrus_main.c| 2 +-
drivers/gpu/drm/cirrus/cirrus_mode.c| 9 +--
drivers/gpu/drm/drm_atomic.c| 8 +--
drivers/gpu/drm/drm_crtc.c | 4 +-
drivers/gpu/drm/drm_crtc_helper.c | 4 +-
drivers/gpu/drm/drm_fb_cma_helper.c | 11 ++--
drivers/gpu/drm/drm_fb_helper.c | 10 ++--
drivers/gpu/drm/drm_framebuffer.c | 53 -
drivers/gpu/drm/drm_modeset_helper.c| 11 ++--
drivers/gpu/drm/drm_plane.c | 6 +-
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 6 +-
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 8 +--
drivers/gpu/drm/exynos/exynos_drm_fb.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 6 +-
drivers/gpu/drm/exynos/exynos_drm_fimd.c| 4 +-
drivers/gpu/drm/exynos/exynos_mixer.c | 12 ++--
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_p
[PATCH 01/32] drm/i915: Add local 'fb' variables
From: Ville Syrjälä
Add a local 'fb' variable to a few places to get rid of the
'crtc->primary->fb' stuff. Looks neater and helps me with my poor
coccinelle skills later.
While at it switch over to using the pixel format rather than
depth+bpp.
Cc: intel-gfx at lists.freedesktop.org
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_overlay.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_overlay.c
b/drivers/gpu/drm/i915/intel_overlay.c
index fd0e4dac7cc1..ce3667c18e18 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -658,6 +658,8 @@ static bool update_scaling_factors(struct intel_overlay
*overlay,
static void update_colorkey(struct intel_overlay *overlay,
struct overlay_registers __iomem *regs)
{
+ const struct drm_framebuffer *fb =
+ overlay->crtc->base.primary->fb;
u32 key = overlay->color_key;
u32 flags;
@@ -665,24 +667,20 @@ static void update_colorkey(struct intel_overlay *overlay,
if (overlay->color_key_enabled)
flags |= DST_KEY_ENABLE;
- switch (overlay->crtc->base.primary->fb->bits_per_pixel) {
- case 8:
+ switch (fb->pixel_format) {
+ case DRM_FORMAT_C8:
key = 0;
flags |= CLK_RGB8I_MASK;
break;
-
- case 16:
- if (overlay->crtc->base.primary->fb->depth == 15) {
- key = RGB15_TO_COLORKEY(key);
- flags |= CLK_RGB15_MASK;
- } else {
- key = RGB16_TO_COLORKEY(key);
- flags |= CLK_RGB16_MASK;
- }
+ case DRM_FORMAT_XRGB1555:
+ key = RGB15_TO_COLORKEY(key);
+ flags |= CLK_RGB15_MASK;
break;
-
- case 24:
- case 32:
+ case DRM_FORMAT_RGB565:
+ key = RGB16_TO_COLORKEY(key);
+ flags |= CLK_RGB16_MASK;
+ break;
+ default:
flags |= CLK_RGB24_MASK;
break;
}
--
2.7.4
[PATCH 03/32] drm/radeon: Use DIV_ROUND_UP()
From: Ville Syrjälä Use DIV_ROUND_UP() instead of hand rolling it. Just a drive-by change. Cc: Alex Deucher Cc: "Christian König" Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c index bb5346812de4..31c03e32a6b5 100644 --- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c +++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c @@ -477,9 +477,8 @@ int radeon_crtc_do_set_base(struct drm_crtc *crtc, crtc_offset_cntl = 0; pitch_pixels = target_fb->pitches[0] / (target_fb->bits_per_pixel / 8); - crtc_pitch = (((pitch_pixels * target_fb->bits_per_pixel) + - ((target_fb->bits_per_pixel * 8) - 1)) / - (target_fb->bits_per_pixel * 8)); + crtc_pitch = DIV_ROUND_UP(pitch_pixels * target_fb->bits_per_pixel, + target_fb->bits_per_pixel * 8); crtc_pitch |= crtc_pitch << 16; crtc_offset_cntl |= RADEON_CRTC_GUI_TRIG_OFFSET_LEFT_EN; -- 2.7.4
[PATCH 02/32] drm/radeon: Add local 'fb' variables
From: Ville Syrjälä
Add a local 'fb' variable to a few places to get rid of the
'crtc->primary->fb' stuff. Looks neater and helps me with my poor
coccinelle skills later.
Cc: Alex Deucher
Cc: "Christian König"
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/radeon/r100.c | 10 --
drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 3 ++-
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index f5e84f4b58e6..984b35f43554 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -3225,13 +3225,19 @@ void r100_bandwidth_update(struct radeon_device *rdev)
radeon_update_display_priority(rdev);
if (rdev->mode_info.crtcs[0]->base.enabled) {
+ const struct drm_framebuffer *fb =
+ rdev->mode_info.crtcs[0]->base.primary->fb;
+
mode1 = &rdev->mode_info.crtcs[0]->base.mode;
- pixel_bytes1 =
rdev->mode_info.crtcs[0]->base.primary->fb->bits_per_pixel / 8;
+ pixel_bytes1 = fb->bits_per_pixel / 8;
}
if (!(rdev->flags & RADEON_SINGLE_CRTC)) {
if (rdev->mode_info.crtcs[1]->base.enabled) {
+ const struct drm_framebuffer *fb =
+ rdev->mode_info.crtcs[1]->base.primary->fb;
+
mode2 = &rdev->mode_info.crtcs[1]->base.mode;
- pixel_bytes2 =
rdev->mode_info.crtcs[1]->base.primary->fb->bits_per_pixel / 8;
+ pixel_bytes2 = fb->bits_per_pixel / 8;
}
}
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
index d0de4022fff9..bb5346812de4 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
@@ -579,6 +579,7 @@ static bool radeon_set_crtc_timing(struct drm_crtc *crtc,
struct drm_display_mod
struct drm_device *dev = crtc->dev;
struct radeon_device *rdev = dev->dev_private;
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
+ const struct drm_framebuffer *fb = crtc->primary->fb;
struct drm_encoder *encoder;
int format;
int hsync_start;
@@ -602,7 +603,7 @@ static bool radeon_set_crtc_timing(struct drm_crtc *crtc,
struct drm_display_mod
}
}
- switch (crtc->primary->fb->bits_per_pixel) {
+ switch (fb->bits_per_pixel) {
case 8:
format = 2;
break;
--
2.7.4
[PATCH 05/32] drm/ast: Add local 'fb' variables
From: Ville Syrjälä
Add a local 'fb' variable to a few places to get rid of the
'crtc->primary->fb' stuff. Looks neater and helps me with my poor
coccinelle skills later.
Cc: Dave Airlie
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/ast/ast_mode.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 5957c3e659fe..deb3684ccaf8 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -79,12 +79,13 @@ static bool ast_get_vbios_mode_info(struct drm_crtc *crtc,
struct drm_display_mo
struct ast_vbios_mode_info *vbios_mode)
{
struct ast_private *ast = crtc->dev->dev_private;
+ const struct drm_framebuffer *fb = crtc->primary->fb;
u32 refresh_rate_index = 0, mode_id, color_index, refresh_rate;
u32 hborder, vborder;
bool check_sync;
struct ast_vbios_enhtable *best = NULL;
- switch (crtc->primary->fb->bits_per_pixel) {
+ switch (fb->bits_per_pixel) {
case 8:
vbios_mode->std_table = &vbios_stdtable[VGAModeIndex];
color_index = VGAModeIndex - 1;
@@ -207,7 +208,7 @@ static bool ast_get_vbios_mode_info(struct drm_crtc *crtc,
struct drm_display_mo
ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0x91, 0x00);
if (vbios_mode->enh_table->flags & NewModeInfo) {
ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0x91, 0xa8);
- ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0x92,
crtc->primary->fb->bits_per_pixel);
+ ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0x92,
fb->bits_per_pixel);
ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0x93,
adjusted_mode->clock / 1000);
ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0x94,
adjusted_mode->crtc_hdisplay);
ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0x95,
adjusted_mode->crtc_hdisplay >> 8);
@@ -369,10 +370,11 @@ static void ast_set_crtc_reg(struct drm_crtc *crtc,
struct drm_display_mode *mod
static void ast_set_offset_reg(struct drm_crtc *crtc)
{
struct ast_private *ast = crtc->dev->dev_private;
+ const struct drm_framebuffer *fb = crtc->primary->fb;
u16 offset;
- offset = crtc->primary->fb->pitches[0] >> 3;
+ offset = fb->pitches[0] >> 3;
ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0x13, (offset & 0xff));
ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xb0, (offset >> 8) & 0x3f);
}
@@ -395,9 +397,10 @@ static void ast_set_ext_reg(struct drm_crtc *crtc, struct
drm_display_mode *mode
struct ast_vbios_mode_info *vbios_mode)
{
struct ast_private *ast = crtc->dev->dev_private;
+ const struct drm_framebuffer *fb = crtc->primary->fb;
u8 jregA0 = 0, jregA3 = 0, jregA8 = 0;
- switch (crtc->primary->fb->bits_per_pixel) {
+ switch (fb->bits_per_pixel) {
case 8:
jregA0 = 0x70;
jregA3 = 0x01;
@@ -452,7 +455,9 @@ static void ast_set_sync_reg(struct drm_device *dev, struct
drm_display_mode *mo
static bool ast_set_dac_reg(struct drm_crtc *crtc, struct drm_display_mode
*mode,
struct ast_vbios_mode_info *vbios_mode)
{
- switch (crtc->primary->fb->bits_per_pixel) {
+ const struct drm_framebuffer *fb = crtc->primary->fb;
+
+ switch (fb->bits_per_pixel) {
case 8:
break;
default:
--
2.7.4
[PATCH 07/32] drm/cirrus: Add some local 'fb' variables
From: Ville Syrjälä
Add a local 'fb' variable to a few places to get rid of the
'crtc->primary->fb' stuff. Looks neater and helps me with my poor
coccinelle skills later.
Cc: Dave Airlie
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/cirrus/cirrus_mode.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c
b/drivers/gpu/drm/cirrus/cirrus_mode.c
index 17c915d9a03e..f2297acae235 100644
--- a/drivers/gpu/drm/cirrus/cirrus_mode.c
+++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
@@ -185,6 +185,7 @@ static int cirrus_crtc_mode_set(struct drm_crtc *crtc,
{
struct drm_device *dev = crtc->dev;
struct cirrus_device *cdev = dev->dev_private;
+ const struct drm_framebuffer *fb = crtc->primary->fb;
int hsyncstart, hsyncend, htotal, hdispend;
int vtotal, vdispend;
int tmp;
@@ -257,7 +258,7 @@ static int cirrus_crtc_mode_set(struct drm_crtc *crtc,
sr07 = RREG8(SEQ_DATA);
sr07 &= 0xe0;
hdr = 0;
- switch (crtc->primary->fb->bits_per_pixel) {
+ switch (fb->bits_per_pixel) {
case 8:
sr07 |= 0x11;
break;
@@ -280,13 +281,13 @@ static int cirrus_crtc_mode_set(struct drm_crtc *crtc,
WREG_SEQ(0x7, sr07);
/* Program the pitch */
- tmp = crtc->primary->fb->pitches[0] / 8;
+ tmp = fb->pitches[0] / 8;
WREG_CRT(VGA_CRTC_OFFSET, tmp);
/* Enable extended blanking and pitch bits, and enable full memory */
tmp = 0x22;
- tmp |= (crtc->primary->fb->pitches[0] >> 7) & 0x10;
- tmp |= (crtc->primary->fb->pitches[0] >> 6) & 0x40;
+ tmp |= (fb->pitches[0] >> 7) & 0x10;
+ tmp |= (fb->pitches[0] >> 6) & 0x40;
WREG_CRT(0x1b, tmp);
/* Enable high-colour modes */
--
2.7.4
[PATCH 06/32] drm/gma500: Add some local 'fb' variables
From: Ville Syrjälä
Add a local 'fb' variable to a few places to get rid of the
'crtc->primary->fb' stuff. Looks neater and helps me with my poor
coccinelle skills later.
Cc: Patrik Jakobsson
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/gma500/gma_display.c | 13 +++--
drivers/gpu/drm/gma500/mdfld_intel_display.c | 15 ---
drivers/gpu/drm/gma500/oaktrail_crtc.c | 13 +++--
3 files changed, 22 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/gma500/gma_display.c
b/drivers/gpu/drm/gma500/gma_display.c
index 1a1cf7a3b5ef..05b9a4ceb58d 100644
--- a/drivers/gpu/drm/gma500/gma_display.c
+++ b/drivers/gpu/drm/gma500/gma_display.c
@@ -59,7 +59,8 @@ int gma_pipe_set_base(struct drm_crtc *crtc, int x, int y,
struct drm_device *dev = crtc->dev;
struct drm_psb_private *dev_priv = dev->dev_private;
struct gma_crtc *gma_crtc = to_gma_crtc(crtc);
- struct psb_framebuffer *psbfb = to_psb_fb(crtc->primary->fb);
+ struct drm_framebuffer *fb = crtc->primary->fb;
+ struct psb_framebuffer *psbfb = to_psb_fb(fb);
int pipe = gma_crtc->pipe;
const struct psb_offset *map = &dev_priv->regmap[pipe];
unsigned long start, offset;
@@ -70,7 +71,7 @@ int gma_pipe_set_base(struct drm_crtc *crtc, int x, int y,
return 0;
/* no fb bound */
- if (!crtc->primary->fb) {
+ if (!fb) {
dev_err(dev->dev, "No FB bound\n");
goto gma_pipe_cleaner;
}
@@ -81,19 +82,19 @@ int gma_pipe_set_base(struct drm_crtc *crtc, int x, int y,
if (ret < 0)
goto gma_pipe_set_base_exit;
start = psbfb->gtt->offset;
- offset = y * crtc->primary->fb->pitches[0] + x *
(crtc->primary->fb->bits_per_pixel / 8);
+ offset = y * fb->pitches[0] + x * (fb->bits_per_pixel / 8);
- REG_WRITE(map->stride, crtc->primary->fb->pitches[0]);
+ REG_WRITE(map->stride, fb->pitches[0]);
dspcntr = REG_READ(map->cntr);
dspcntr &= ~DISPPLANE_PIXFORMAT_MASK;
- switch (crtc->primary->fb->bits_per_pixel) {
+ switch (fb->bits_per_pixel) {
case 8:
dspcntr |= DISPPLANE_8BPP;
break;
case 16:
- if (crtc->primary->fb->depth == 15)
+ if (fb->depth == 15)
dspcntr |= DISPPLANE_15_16BPP;
else
dspcntr |= DISPPLANE_16BPP;
diff --git a/drivers/gpu/drm/gma500/mdfld_intel_display.c
b/drivers/gpu/drm/gma500/mdfld_intel_display.c
index 92e3f93ee682..e80895285e94 100644
--- a/drivers/gpu/drm/gma500/mdfld_intel_display.c
+++ b/drivers/gpu/drm/gma500/mdfld_intel_display.c
@@ -165,8 +165,9 @@ static int mdfld__intel_pipe_set_base(struct drm_crtc
*crtc, int x, int y,
{
struct drm_device *dev = crtc->dev;
struct drm_psb_private *dev_priv = dev->dev_private;
+ struct drm_framebuffer *fb = crtc->primary->fb;
struct gma_crtc *gma_crtc = to_gma_crtc(crtc);
- struct psb_framebuffer *psbfb = to_psb_fb(crtc->primary->fb);
+ struct psb_framebuffer *psbfb = to_psb_fb(fb);
int pipe = gma_crtc->pipe;
const struct psb_offset *map = &dev_priv->regmap[pipe];
unsigned long start, offset;
@@ -178,12 +179,12 @@ static int mdfld__intel_pipe_set_base(struct drm_crtc
*crtc, int x, int y,
dev_dbg(dev->dev, "pipe = 0x%x.\n", pipe);
/* no fb bound */
- if (!crtc->primary->fb) {
+ if (!fb) {
dev_dbg(dev->dev, "No FB bound\n");
return 0;
}
- ret = check_fb(crtc->primary->fb);
+ ret = check_fb(fb);
if (ret)
return ret;
@@ -196,18 +197,18 @@ static int mdfld__intel_pipe_set_base(struct drm_crtc
*crtc, int x, int y,
return 0;
start = psbfb->gtt->offset;
- offset = y * crtc->primary->fb->pitches[0] + x *
(crtc->primary->fb->bits_per_pixel / 8);
+ offset = y * fb->pitches[0] + x * (fb->bits_per_pixel / 8);
- REG_WRITE(map->stride, crtc->primary->fb->pitches[0]);
+ REG_WRITE(map->stride, fb->pitches[0]);
dspcntr = REG_READ(map->cntr);
dspcntr &= ~DISPPLANE_PIXFORMAT_MASK;
- switch (crtc->primary->fb->bits_per_pixel) {
+ switch (fb->bits_per_pixel) {
case 8:
dspcntr |= DISPPLANE_8BPP;
break;
case 16:
- if (crtc->primary->fb->depth == 15)
+ if (fb->depth == 15)
dspcntr |= DISPPLANE_15_16BPP;
else
dspcntr |= DISPPLANE_16BPP;
diff --git a/drivers/gpu/drm/gma500/oaktrail_crtc.c
b/drivers/gpu/drm/gma500/oaktrail_crtc.c
index da9fd34b9550..a51896544d91 100644
--- a/drivers/gpu/drm/gma500/oaktrail_crtc.c
+++ b/drivers/gpu/drm/gma500/oaktrail_crtc.c
@@ -599,7 +599,8 @@ static int oaktrail_pipe_set_base(struct drm_crtc *crtc,
struct
[PATCH 04/32] drm/mgag200: Add local 'fb' variable
From: Ville Syrjälä
Add a local 'fb' variable to a few places to get rid of the
'crtc->primary->fb' stuff. Looks neater and helps me with my poor
coccinelle skills later.
Cc: Dave Airlie
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 6b21cb27e1cc..bdac288ab16d 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -880,6 +880,7 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
{
struct drm_device *dev = crtc->dev;
struct mga_device *mdev = dev->dev_private;
+ const struct drm_framebuffer *fb = crtc->primary->fb;
int hdisplay, hsyncstart, hsyncend, htotal;
int vdisplay, vsyncstart, vsyncend, vtotal;
int pitch;
@@ -902,7 +903,7 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
/* 0x48: */0,0,0,0,0,0,0,0
};
- bppshift = mdev->bpp_shifts[(crtc->primary->fb->bits_per_pixel >> 3) -
1];
+ bppshift = mdev->bpp_shifts[(fb->bits_per_pixel >> 3) - 1];
switch (mdev->type) {
case G200_SE_A:
@@ -941,12 +942,12 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
break;
}
- switch (crtc->primary->fb->bits_per_pixel) {
+ switch (fb->bits_per_pixel) {
case 8:
dacvalue[MGA1064_MUL_CTL] = MGA1064_MUL_CTL_8bits;
break;
case 16:
- if (crtc->primary->fb->depth == 15)
+ if (fb->depth == 15)
dacvalue[MGA1064_MUL_CTL] = MGA1064_MUL_CTL_15bits;
else
dacvalue[MGA1064_MUL_CTL] = MGA1064_MUL_CTL_16bits;
@@ -997,8 +998,8 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
WREG_SEQ(3, 0);
WREG_SEQ(4, 0xe);
- pitch = crtc->primary->fb->pitches[0] /
(crtc->primary->fb->bits_per_pixel / 8);
- if (crtc->primary->fb->bits_per_pixel == 24)
+ pitch = fb->pitches[0] / (fb->bits_per_pixel / 8);
+ if (fb->bits_per_pixel == 24)
pitch = (pitch * 3) >> (4 - bppshift);
else
pitch = pitch >> (4 - bppshift);
@@ -1075,7 +1076,7 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
((vdisplay & 0xc00) >> 7) |
((vsyncstart & 0xc00) >> 5) |
((vdisplay & 0x400) >> 3);
- if (crtc->primary->fb->bits_per_pixel == 24)
+ if (fb->bits_per_pixel == 24)
ext_vga[3] = (((1 << bppshift) * 3) - 1) | 0x80;
else
ext_vga[3] = ((1 << bppshift) - 1) | 0x80;
@@ -1138,9 +1139,9 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
u32 bpp;
u32 mb;
- if (crtc->primary->fb->bits_per_pixel > 16)
+ if (fb->bits_per_pixel > 16)
bpp = 32;
- else if (crtc->primary->fb->bits_per_pixel > 8)
+ else if (fb->bits_per_pixel > 8)
bpp = 16;
else
bpp = 8;
--
2.7.4
[PATCH 10/32] drm/nouveau: Fix crtc->primary->fb vs. drm_fb fail
From: Ville Syrjälä So it looks like the code is trying to pick between the passed in fb and crtc->primary->fb based on that funky 'bool atomic'. But later it will mix uses of both drm_fb (which was picked by the aforementioned logic) and crtc->primary->fb. So looks like a bug to me. Let's make it use drm_fb only. Cc: Ben Skeggs Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/nouveau/dispnv04/crtc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c b/drivers/gpu/drm/nouveau/dispnv04/crtc.c index 59d1d1c5de5f..7c6c66f177df 100644 --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c @@ -854,9 +854,9 @@ nv04_crtc_do_mode_set_base(struct drm_crtc *crtc, /* Update the framebuffer format. */ regp->CRTC[NV_CIO_CRE_PIXEL_INDEX] &= ~3; - regp->CRTC[NV_CIO_CRE_PIXEL_INDEX] |= (crtc->primary->fb->depth + 1) / 8; + regp->CRTC[NV_CIO_CRE_PIXEL_INDEX] |= (drm_fb->depth + 1) / 8; regp->ramdac_gen_ctrl &= ~NV_PRAMDAC_GENERAL_CONTROL_ALT_MODE_SEL; - if (crtc->primary->fb->depth == 16) + if (drm_fb->depth == 16) regp->ramdac_gen_ctrl |= NV_PRAMDAC_GENERAL_CONTROL_ALT_MODE_SEL; crtc_wr_cio_state(crtc, regp, NV_CIO_CRE_PIXEL_INDEX); NVWriteRAMDAC(dev, nv_crtc->index, NV_PRAMDAC_GENERAL_CONTROL, -- 2.7.4
[PATCH 11/32] drm/nouveau: Add local 'fb' variables
From: Ville Syrjälä
Add a local 'fb' variable to a few places to get rid of the
'crtc->primary->fb' stuff. Looks neater and helps me with my poor
coccinelle skills later.
Cc: Ben Skeggs
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 5 +++--
drivers/gpu/drm/nouveau/dispnv04/dfp.c | 3 ++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
index 7c6c66f177df..8286b8ffe109 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
@@ -460,6 +460,7 @@ nv_crtc_mode_set_regs(struct drm_crtc *crtc, struct
drm_display_mode * mode)
struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
struct nv04_crtc_reg *regp =
&nv04_display(dev)->mode_reg.crtc_reg[nv_crtc->index];
struct nv04_crtc_reg *savep =
&nv04_display(dev)->saved_reg.crtc_reg[nv_crtc->index];
+ const struct drm_framebuffer *fb = crtc->primary->fb;
struct drm_encoder *encoder;
bool lvds_output = false, tmds_output = false, tv_output = false,
off_chip_digital = false;
@@ -569,7 +570,7 @@ nv_crtc_mode_set_regs(struct drm_crtc *crtc, struct
drm_display_mode * mode)
regp->CRTC[NV_CIO_CRE_86] = 0x1;
}
- regp->CRTC[NV_CIO_CRE_PIXEL_INDEX] = (crtc->primary->fb->depth + 1) / 8;
+ regp->CRTC[NV_CIO_CRE_PIXEL_INDEX] = (fb->depth + 1) / 8;
/* Enable slaved mode (called MODE_TV in nv4ref.h) */
if (lvds_output || tmds_output || tv_output)
regp->CRTC[NV_CIO_CRE_PIXEL_INDEX] |= (1 << 7);
@@ -583,7 +584,7 @@ nv_crtc_mode_set_regs(struct drm_crtc *crtc, struct
drm_display_mode * mode)
regp->ramdac_gen_ctrl = NV_PRAMDAC_GENERAL_CONTROL_BPC_8BITS |
NV_PRAMDAC_GENERAL_CONTROL_VGA_STATE_SEL |
NV_PRAMDAC_GENERAL_CONTROL_PIXMIX_ON;
- if (crtc->primary->fb->depth == 16)
+ if (fb->depth == 16)
regp->ramdac_gen_ctrl |=
NV_PRAMDAC_GENERAL_CONTROL_ALT_MODE_SEL;
if (drm->device.info.chipset >= 0x11)
regp->ramdac_gen_ctrl |= NV_PRAMDAC_GENERAL_CONTROL_PIPE_LONG;
diff --git a/drivers/gpu/drm/nouveau/dispnv04/dfp.c
b/drivers/gpu/drm/nouveau/dispnv04/dfp.c
index c2947ef7d4fc..945607b3cd41 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/dfp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/dfp.c
@@ -290,6 +290,7 @@ static void nv04_dfp_mode_set(struct drm_encoder *encoder,
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
struct drm_display_mode *output_mode = &nv_encoder->mode;
struct drm_connector *connector = &nv_connector->base;
+ const struct drm_framebuffer *fb = encoder->crtc->primary->fb;
uint32_t mode_ratio, panel_ratio;
NV_DEBUG(drm, "Output mode on CRTC %d:\n", nv_crtc->index);
@@ -415,7 +416,7 @@ static void nv04_dfp_mode_set(struct drm_encoder *encoder,
/* Output property. */
if ((nv_connector->dithering_mode == DITHERING_MODE_ON) ||
(nv_connector->dithering_mode == DITHERING_MODE_AUTO &&
-encoder->crtc->primary->fb->depth > connector->display_info.bpc *
3)) {
+fb->depth > connector->display_info.bpc * 3)) {
if (drm->device.info.chipset == 0x11)
regp->dither = savep->dither | 0x0001;
else {
--
2.7.4
[PATCH 09/32] drm/arm: Add local 'fb' variables
From: Ville Syrjälä
Add a local 'fb' variable to a few places to get rid of the
'crtc->primary->fb' stuff. Looks neater and helps me with my ppor
coccinelle skills later.
In some places the local variable was already there, just not used
consistently.
Cc: Liviu Dudau
Cc: Brian Starkey
Cc: Mali DP Maintainers
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/arm/hdlcd_crtc.c| 18 ++
drivers/gpu/drm/arm/malidp_planes.c | 6 +++---
2 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index bbaa55add2d2..8a0fee03aa39 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -60,11 +60,12 @@ static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc)
{
unsigned int btpp;
struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
+ const struct drm_framebuffer *fb = crtc->primary->state->fb;
uint32_t pixel_format;
struct simplefb_format *format = NULL;
int i;
- pixel_format = crtc->primary->state->fb->pixel_format;
+ pixel_format = fb->pixel_format;
for (i = 0; i < ARRAY_SIZE(supported_formats); i++) {
if (supported_formats[i].fourcc == pixel_format)
@@ -221,27 +222,28 @@ static int hdlcd_plane_atomic_check(struct drm_plane
*plane,
static void hdlcd_plane_atomic_update(struct drm_plane *plane,
struct drm_plane_state *state)
{
+ struct drm_framebuffer *fb = plane->state->fb;
struct hdlcd_drm_private *hdlcd;
struct drm_gem_cma_object *gem;
u32 src_w, src_h, dest_w, dest_h;
dma_addr_t scanout_start;
- if (!plane->state->fb)
+ if (!fb)
return;
src_w = plane->state->src_w >> 16;
src_h = plane->state->src_h >> 16;
dest_w = plane->state->crtc_w;
dest_h = plane->state->crtc_h;
- gem = drm_fb_cma_get_gem_obj(plane->state->fb, 0);
- scanout_start = gem->paddr + plane->state->fb->offsets[0] +
- plane->state->crtc_y * plane->state->fb->pitches[0] +
+ gem = drm_fb_cma_get_gem_obj(fb, 0);
+ scanout_start = gem->paddr + fb->offsets[0] +
+ plane->state->crtc_y * fb->pitches[0] +
plane->state->crtc_x *
- drm_format_plane_cpp(plane->state->fb->pixel_format, 0);
+ drm_format_plane_cpp(fb->pixel_format, 0);
hdlcd = plane->dev->dev_private;
- hdlcd_write(hdlcd, HDLCD_REG_FB_LINE_LENGTH,
plane->state->fb->pitches[0]);
- hdlcd_write(hdlcd, HDLCD_REG_FB_LINE_PITCH,
plane->state->fb->pitches[0]);
+ hdlcd_write(hdlcd, HDLCD_REG_FB_LINE_LENGTH, fb->pitches[0]);
+ hdlcd_write(hdlcd, HDLCD_REG_FB_LINE_PITCH, fb->pitches[0]);
hdlcd_write(hdlcd, HDLCD_REG_FB_LINE_COUNT, dest_h - 1);
hdlcd_write(hdlcd, HDLCD_REG_FB_BASE, scanout_start);
}
diff --git a/drivers/gpu/drm/arm/malidp_planes.c
b/drivers/gpu/drm/arm/malidp_planes.c
index 63eec8f37cfc..ee7f7663a307 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -137,8 +137,8 @@ static int malidp_de_plane_check(struct drm_plane *plane,
/* packed RGB888 / BGR888 can't be rotated or flipped */
if (state->rotation != DRM_ROTATE_0 &&
- (state->fb->pixel_format == DRM_FORMAT_RGB888 ||
-state->fb->pixel_format == DRM_FORMAT_BGR888))
+ (fb->pixel_format == DRM_FORMAT_RGB888 ||
+fb->pixel_format == DRM_FORMAT_BGR888))
return -EINVAL;
ms->rotmem_size = 0;
@@ -147,7 +147,7 @@ static int malidp_de_plane_check(struct drm_plane *plane,
val = mp->hwdev->rotmem_required(mp->hwdev, state->crtc_h,
state->crtc_w,
-state->fb->pixel_format);
+fb->pixel_format);
if (val < 0)
return val;
--
2.7.4
[PATCH 12/32] drm/vmwgfx: Populate fb->dev before drm_framebuffer_init()
From: Ville Syrjälä drm_framebuffer_init() will start to check that fb->dev is already populated, so let's to that manually since vmwgfx isn't using drm_helper_mode_fill_fb_struct(). Cc: linux-graphics-maintainer at vmware.com Cc: Sinclair Yeh Cc: Thomas Hellstrom Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c index e3f68cc9bb4b..7d92ab56961b 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c @@ -581,6 +581,7 @@ static int vmw_kms_new_framebuffer_surface(struct vmw_private *dev_priv, goto out_err1; } + vfbs->base.base.dev = dev; /* XXX get the first 3 from the surface info */ vfbs->base.base.bits_per_pixel = mode_cmd->bpp; vfbs->base.base.pitches[0] = mode_cmd->pitch; @@ -875,6 +876,7 @@ static int vmw_kms_new_framebuffer_dmabuf(struct vmw_private *dev_priv, goto out_err1; } + vfbd->base.base.dev = dev; vfbd->base.base.bits_per_pixel = mode_cmd->bpp; vfbd->base.base.pitches[0] = mode_cmd->pitch; vfbd->base.base.depth = mode_cmd->depth; -- 2.7.4
[PATCH 13/32] drm: Pass 'dev' to drm_helper_mode_fill_fb_struct()
From: Ville Syrjälä
Pass the drm_device to drm_helper_mode_fill_fb_struct() so that we can
populate fb->dev early. Will make it easier to use the fb before we
register it.
@@
identifier fb, mode_cmd;
@@
void drm_helper_mode_fill_fb_struct(
+struct drm_device *dev,
struct drm_framebuffer *fb,
const struct drm_mode_fb_cmd2 *mode_cmd
);
@@
identifier fb, mode_cmd;
@@
void drm_helper_mode_fill_fb_struct(
+struct drm_device *dev,
struct drm_framebuffer *fb,
const struct drm_mode_fb_cmd2 *mode_cmd
)
{ ... }
@@
function func;
identifier dev;
expression E1, E2;
@@
func(struct drm_device *dev, ...)
{
...
drm_helper_mode_fill_fb_struct(
+ dev,
E1, E2);
...
}
@@
expression E1, E2;
@@
drm_helper_mode_fill_fb_struct(
+ dev,
E1, E2);
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 +-
drivers/gpu/drm/armada/armada_fb.c | 2 +-
drivers/gpu/drm/ast/ast_main.c | 2 +-
drivers/gpu/drm/bochs/bochs_mm.c| 2 +-
drivers/gpu/drm/cirrus/cirrus_main.c| 2 +-
drivers/gpu/drm/drm_fb_cma_helper.c | 2 +-
drivers/gpu/drm/drm_modeset_helper.c| 3 ++-
drivers/gpu/drm/exynos/exynos_drm_fb.c | 2 +-
drivers/gpu/drm/gma500/framebuffer.c| 2 +-
drivers/gpu/drm/i915/intel_display.c| 2 +-
drivers/gpu/drm/mediatek/mtk_drm_fb.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_main.c | 2 +-
drivers/gpu/drm/msm/msm_fb.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
drivers/gpu/drm/omapdrm/omap_fb.c | 2 +-
drivers/gpu/drm/qxl/qxl_display.c | 2 +-
drivers/gpu/drm/radeon/radeon_display.c | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 2 +-
drivers/gpu/drm/tegra/fb.c | 2 +-
drivers/gpu/drm/udl/udl_fb.c| 2 +-
drivers/gpu/drm/virtio/virtgpu_display.c| 2 +-
include/drm/drm_modeset_helper.h| 3 ++-
22 files changed, 24 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 741144fcc7bc..d492cf84ddc1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -508,7 +508,7 @@ amdgpu_framebuffer_init(struct drm_device *dev,
{
int ret;
rfb->obj = obj;
- drm_helper_mode_fill_fb_struct(&rfb->base, mode_cmd);
+ drm_helper_mode_fill_fb_struct(dev, &rfb->base, mode_cmd);
ret = drm_framebuffer_init(dev, &rfb->base, &amdgpu_fb_funcs);
if (ret) {
rfb->obj = NULL;
diff --git a/drivers/gpu/drm/armada/armada_fb.c
b/drivers/gpu/drm/armada/armada_fb.c
index f03c212b754d..2a7eb6817c36 100644
--- a/drivers/gpu/drm/armada/armada_fb.c
+++ b/drivers/gpu/drm/armada/armada_fb.c
@@ -81,7 +81,7 @@ struct armada_framebuffer *armada_framebuffer_create(struct
drm_device *dev,
dfb->mod = config;
dfb->obj = obj;
- drm_helper_mode_fill_fb_struct(&dfb->fb, mode);
+ drm_helper_mode_fill_fb_struct(dev, &dfb->fb, mode);
ret = drm_framebuffer_init(dev, &dfb->fb, &armada_fb_funcs);
if (ret) {
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index 904beaa932d0..d85af0ff2653 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -313,7 +313,7 @@ int ast_framebuffer_init(struct drm_device *dev,
{
int ret;
- drm_helper_mode_fill_fb_struct(&ast_fb->base, mode_cmd);
+ drm_helper_mode_fill_fb_struct(dev, &ast_fb->base, mode_cmd);
ast_fb->obj = obj;
ret = drm_framebuffer_init(dev, &ast_fb->base, &ast_fb_funcs);
if (ret) {
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index 099a3c688c26..ceb1fecf02dd 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -484,7 +484,7 @@ int bochs_framebuffer_init(struct drm_device *dev,
{
int ret;
- drm_helper_mode_fill_fb_struct(&gfb->base, mode_cmd);
+ drm_helper_mode_fill_fb_struct(dev, &gfb->base, mode_cmd);
gfb->obj = obj;
ret = drm_framebuffer_init(dev, &gfb->base, &bochs_fb_funcs);
if (ret) {
diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c
b/drivers/gpu/drm/cirrus/cirrus_main.c
index 2c3c0d4072ce..52d901fa8687 100644
--- a/drivers/gpu/drm/cirrus/cirrus_main.c
+++ b/drivers/gpu/drm/cirrus/cirrus_main.c
@@ -34,7 +34,7 @@ int cirrus_framebuffer_init(struct drm_device *dev,
{
int ret;
- drm_helper_mode_fill_fb_struct(&gfb->base, mode_c
[PATCH 14/32] drm/vmwgfx: Populate fb->pixel_format
From: Ville Syrjälä
Stuff something semi-reasonable into fb->pixel_format. I had to guess
as to which formats we should pick. Did I guess correctly?
We can't quite use drm_mode_legacy_fb_format() due to the ARGB1555
vs. XRGB155 mess. However use of 'A' formats should imply per-pixel
alpha blending as far as KMS is concerned so I'm not at all sure we
want to have any 'A' formats exposed as opposed to just 'X' formats.
OTOH vmvgfx doesn't do planes, and so the core won't enforce that
these formats match any list of supported formats, so the choice
shouldn't be super important at this point.
Cc: linux-graphics-maintainer at vmware.com
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 7d92ab56961b..5788913ca8f9 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -524,6 +524,7 @@ static int vmw_kms_new_framebuffer_surface(struct
vmw_private *dev_priv,
struct drm_device *dev = dev_priv->dev;
struct vmw_framebuffer_surface *vfbs;
enum SVGA3dSurfaceFormat format;
+ u32 pixel_format;
int ret;
/* 3D is only supported on HWv8 and newer hosts */
@@ -548,17 +549,22 @@ static int vmw_kms_new_framebuffer_surface(struct
vmw_private *dev_priv,
return -EINVAL;
}
+ /* FIXME 'A' format implies per-pixel alpha blending for KMS */
switch (mode_cmd->depth) {
case 32:
+ pixel_format = DRM_FORMAT_ARGB;
format = SVGA3D_A8R8G8B8;
break;
case 24:
+ pixel_format = DRM_FORMAT_XRGB;
format = SVGA3D_X8R8G8B8;
break;
case 16:
+ pixel_format = DRM_FORMAT_RGB565;
format = SVGA3D_R5G6B5;
break;
case 15:
+ pixel_format = DRM_FORMAT_ARGB1555;
format = SVGA3D_A1R5G5B5;
break;
default:
@@ -582,7 +588,8 @@ static int vmw_kms_new_framebuffer_surface(struct
vmw_private *dev_priv,
}
vfbs->base.base.dev = dev;
- /* XXX get the first 3 from the surface info */
+ /* XXX get the first 4 from the surface info */
+ vfbs->base.base.pixel_format = pixel_format;
vfbs->base.base.bits_per_pixel = mode_cmd->bpp;
vfbs->base.base.pitches[0] = mode_cmd->pitch;
vfbs->base.base.depth = mode_cmd->depth;
@@ -834,6 +841,7 @@ static int vmw_kms_new_framebuffer_dmabuf(struct
vmw_private *dev_priv,
struct drm_device *dev = dev_priv->dev;
struct vmw_framebuffer_dmabuf *vfbd;
unsigned int requested_size;
+ u32 pixel_format;
int ret;
requested_size = mode_cmd->height * mode_cmd->pitch;
@@ -852,6 +860,12 @@ static int vmw_kms_new_framebuffer_dmabuf(struct
vmw_private *dev_priv,
if (mode_cmd->bpp == 32)
break;
+ /* FIXME 'A' format implies per-pixel alpha blending
for KMS */
+ if (mode_cmd->depth == 32)
+ pixel_format = DRM_FORMAT_ARGB;
+ else
+ pixel_format = DRM_FORMAT_XRGB;
+
DRM_ERROR("Invalid color depth/bbp: %d %d\n",
mode_cmd->depth, mode_cmd->bpp);
return -EINVAL;
@@ -861,6 +875,12 @@ static int vmw_kms_new_framebuffer_dmabuf(struct
vmw_private *dev_priv,
if (mode_cmd->bpp == 16)
break;
+ /* FIXME 'A' format implies per-pixel alpha blending
for KMS */
+ if (mode_cmd->depth == 16)
+ pixel_format = DRM_FORMAT_RGB565;
+ else
+ pixel_format = DRM_FORMAT_ARGB1555;
+
DRM_ERROR("Invalid color depth/bbp: %d %d\n",
mode_cmd->depth, mode_cmd->bpp);
return -EINVAL;
@@ -877,6 +897,7 @@ static int vmw_kms_new_framebuffer_dmabuf(struct
vmw_private *dev_priv,
}
vfbd->base.base.dev = dev;
+ vfbd->base.base.pixel_format = pixel_format;
vfbd->base.base.bits_per_pixel = mode_cmd->bpp;
vfbd->base.base.pitches[0] = mode_cmd->pitch;
vfbd->base.base.depth = mode_cmd->depth;
--
2.7.4
[PATCH 08/32] drm/arcpgu: Add local 'fb' variables
From: Ville Syrjälä
Add a local 'fb' variable to a few places to get rid of the
'crtc->primary->fb' stuff. Looks neater and helps me with my ppor
coccinelle skills later.
Cc: Alexey Brodkin
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/arc/arcpgu_crtc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index 7130b044b004..5c26c5f126a3 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -35,7 +35,8 @@ static struct simplefb_format supported_formats[] = {
static void arc_pgu_set_pxl_fmt(struct drm_crtc *crtc)
{
struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
- uint32_t pixel_format = crtc->primary->state->fb->pixel_format;
+ const struct drm_framebuffer *fb = crtc->primary->state->fb;
+ uint32_t pixel_format = fb->pixel_format;
struct simplefb_format *format = NULL;
int i;
--
2.7.4
[PATCH 15/32] drm/qxl: Call drm_helper_mode_fill_fb_struct() before drm_framebuffer_init()
From: Ville Syrjälä
We want framebuffers to be mostly useable already before
drm_framebuffer_init() is called, and so we will start demanding that
all the interesting format/size/etc. information be filled in before
drm_framebuffer_init(). drm_helper_mode_fill_fb_struct() will do that
for us, so let's make sure it gets called before drm_framebuffer_init().
Cc: Dave Airlie
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/qxl/qxl_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index bcbad877ce4f..9e2c92b9d12e 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -579,12 +579,12 @@ qxl_framebuffer_init(struct drm_device *dev,
int ret;
qfb->obj = obj;
+ drm_helper_mode_fill_fb_struct(dev, &qfb->base, mode_cmd);
ret = drm_framebuffer_init(dev, &qfb->base, funcs);
if (ret) {
qfb->obj = NULL;
return ret;
}
- drm_helper_mode_fill_fb_struct(dev, &qfb->base, mode_cmd);
return 0;
}
--
2.7.4
