[PATCH v2] drm: zte: add overlay plane support
Hi Sean,
On Thu, Dec 22, 2016 at 09:56:01AM -0500, Sean Paul wrote:
> On Tue, Dec 20, 2016 at 7:09 AM, Shawn Guo wrote:
> > diff --git a/drivers/gpu/drm/zte/zx_vou.c b/drivers/gpu/drm/zte/zx_vou.c
> > index 73fe15c17c32..8ca9c4bdeeaf 100644
> > --- a/drivers/gpu/drm/zte/zx_vou.c
> > +++ b/drivers/gpu/drm/zte/zx_vou.c
> > @@ -93,10 +93,38 @@ struct zx_crtc {
> > const struct zx_crtc_bits *bits;
> > enum vou_chn_type chn_type;
> > struct clk *pixclk;
> > + u32 overlay_bitmap;
> > };
> >
> > #define to_zx_crtc(x) container_of(x, struct zx_crtc, crtc)
> >
> > +struct zx_vl_bits {
> > + u32 enable;
> > + u32 chnsel;
> > + u32 clksel;
> > +};
> > +
> > +static const struct zx_vl_bits zx_vl_bits[VL_NUM] = {
> > + {
> > + .enable = OSD_CTRL0_VL0_EN,
> > + .chnsel = OSD_CTRL0_VL0_SEL,
> > + .clksel = VOU_CLK_VL0_SEL,
> > + }, {
> > + .enable = OSD_CTRL0_VL1_EN,
> > + .chnsel = OSD_CTRL0_VL1_SEL,
> > + .clksel = VOU_CLK_VL1_SEL,
> > + }, {
> > + .enable = OSD_CTRL0_VL2_EN,
> > + .chnsel = OSD_CTRL0_VL2_SEL,
> > + .clksel = VOU_CLK_VL2_SEL,
> > + },
> > +};
> > +
> > +struct zx_overlay {
> > + struct drm_plane *plane;
>
> If you subclass plane instead of storing the pointer, you don't need
> to keep an array of overlays in vou_hw or the find_vl_idx function.
Thanks for the comment, which I found is quite useful. It reminds me
something in the existing code which could be optimized.
We already have a subclass of drm_plane. That's struct zx_plane in
zx_plane.c. Initially, I thought it might be good to keep the structure
local in zx_plane driver. It should make the most sense for the ideal
case, like all the data we have to encode in the structure will only be
accessed inside zx_plane driver. Unfortunately, I found it's not quite
true. There are a few layer specific hardware bits we need to configure
do not sit inside layer block itself, but in some VOU hardware glue
blocks like OSD_CTRL and VOU_CTRL. These glue blocks are only available
in zx_vou driver. If we can access struct zx_plane from zx_vou driver,
things will become much easier and functions like find_vl_idx can be
saved completely.
I have worked out v3 with your comment addressed. There are a couple
of new patches added, which moves struct zx_plane from zx_plane.c to
zx_plane.h and adds support of disabling layer. I will post it shortly.
Please take another look at your convenient time. Thanks for your time.
Shawn
[PATCH v3 0/3] Add overlay plane support for ZTE drm driver
From: Shawn Guo Changes for v3: - Let zx_plane be accessible from zx_vou driver, and so we can easily access all the data encoded in zx_plane with a drm_plane pointer. Thus, function zx_overlay_find_vl_idx() can be saved completely. - Refine the existing zx_plane driver a bit to support disable graphic layer, and make the support of overlay plane a bit easier, by sharing VOU layer setup and teardown functions between graphic and video layers. Changes for v2: - Use clipped coordinates for overlay position calculation Shawn Guo (3): drm: zte: make zx_plane accessible from zx_vou driver drm: zte: add .atomic_disable hook to disable graphic layer drm: zte: add overlay plane support drivers/gpu/drm/zte/zx_plane.c | 338 drivers/gpu/drm/zte/zx_plane.h | 12 +- drivers/gpu/drm/zte/zx_plane_regs.h | 51 ++ drivers/gpu/drm/zte/zx_vou.c| 181 ++- drivers/gpu/drm/zte/zx_vou.h| 3 + drivers/gpu/drm/zte/zx_vou_regs.h | 18 ++ 6 files changed, 521 insertions(+), 82 deletions(-) -- 1.9.1
[PATCH v3 1/3] drm: zte: make zx_plane accessible from zx_vou driver
From: Shawn Guo
Move struct zx_plane from zx_plane.c to zx_plane.h, so that it can be
accessed from zx_vou driver, and we can save the use of struct
zx_layer_data completely. More importantly, those additional data used
by VOU controller to enable/disable graphic and video layers can later
be added and accessed much more easily from zx_vou driver.
While at it, we make two changes to zx_plane_init() interface:
- Encode struct device pointer in zx_plane, so that we do not need to
pass it as a parameter.
- Change return of zx_plane_init() from struct drm_plane pointer to
error code, since we can get the pointer from zx_plane in zx_vou
driver now.
Signed-off-by: Shawn Guo
---
drivers/gpu/drm/zte/zx_plane.c | 36 +++-
drivers/gpu/drm/zte/zx_plane.h | 11 +++
drivers/gpu/drm/zte/zx_vou.c | 31 +++
3 files changed, 33 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/zte/zx_plane.c b/drivers/gpu/drm/zte/zx_plane.c
index 546eb92a94e8..78d29b1db91c 100644
--- a/drivers/gpu/drm/zte/zx_plane.c
+++ b/drivers/gpu/drm/zte/zx_plane.c
@@ -21,16 +21,6 @@
#include "zx_plane_regs.h"
#include "zx_vou.h"
-struct zx_plane {
- struct drm_plane plane;
- void __iomem *layer;
- void __iomem *csc;
- void __iomem *hbsc;
- void __iomem *rsz;
-};
-
-#define to_zx_plane(plane) container_of(plane, struct zx_plane, plane)
-
static const uint32_t gl_formats[] = {
DRM_FORMAT_ARGB,
DRM_FORMAT_XRGB,
@@ -248,28 +238,16 @@ static void zx_plane_hbsc_init(struct zx_plane *zplane)
zx_writel(hbsc + HBSC_THRESHOLD_COL3, (0x3c0 << 16) | 0x40);
}
-struct drm_plane *zx_plane_init(struct drm_device *drm, struct device *dev,
- struct zx_layer_data *data,
- enum drm_plane_type type)
+int zx_plane_init(struct drm_device *drm, struct zx_plane *zplane,
+ enum drm_plane_type type)
{
const struct drm_plane_helper_funcs *helper;
- struct zx_plane *zplane;
- struct drm_plane *plane;
+ struct drm_plane *plane = &zplane->plane;
+ struct device *dev = zplane->dev;
const uint32_t *formats;
unsigned int format_count;
int ret;
- zplane = devm_kzalloc(dev, sizeof(*zplane), GFP_KERNEL);
- if (!zplane)
- return ERR_PTR(-ENOMEM);
-
- plane = &zplane->plane;
-
- zplane->layer = data->layer;
- zplane->hbsc = data->hbsc;
- zplane->csc = data->csc;
- zplane->rsz = data->rsz;
-
zx_plane_hbsc_init(zplane);
switch (type) {
@@ -282,7 +260,7 @@ struct drm_plane *zx_plane_init(struct drm_device *drm,
struct device *dev,
/* TODO: add video layer (vl) support */
break;
default:
- return ERR_PTR(-ENODEV);
+ return -ENODEV;
}
ret = drm_universal_plane_init(drm, plane, VOU_CRTC_MASK,
@@ -290,10 +268,10 @@ struct drm_plane *zx_plane_init(struct drm_device *drm,
struct device *dev,
type, NULL);
if (ret) {
DRM_DEV_ERROR(dev, "failed to init universal plane: %d\n", ret);
- return ERR_PTR(ret);
+ return ret;
}
drm_plane_helper_add(plane, helper);
- return plane;
+ return 0;
}
diff --git a/drivers/gpu/drm/zte/zx_plane.h b/drivers/gpu/drm/zte/zx_plane.h
index 2b82cd558d9d..264a92e0b532 100644
--- a/drivers/gpu/drm/zte/zx_plane.h
+++ b/drivers/gpu/drm/zte/zx_plane.h
@@ -11,16 +11,19 @@
#ifndef __ZX_PLANE_H__
#define __ZX_PLANE_H__
-struct zx_layer_data {
+struct zx_plane {
+ struct drm_plane plane;
+ struct device *dev;
void __iomem *layer;
void __iomem *csc;
void __iomem *hbsc;
void __iomem *rsz;
};
-struct drm_plane *zx_plane_init(struct drm_device *drm, struct device *dev,
- struct zx_layer_data *data,
- enum drm_plane_type type);
+#define to_zx_plane(plane) container_of(plane, struct zx_plane, plane)
+
+int zx_plane_init(struct drm_device *drm, struct zx_plane *zplane,
+ enum drm_plane_type type);
void zx_plane_set_update(struct drm_plane *plane);
#endif /* __ZX_PLANE_H__ */
diff --git a/drivers/gpu/drm/zte/zx_vou.c b/drivers/gpu/drm/zte/zx_vou.c
index 73fe15c17c32..d5c801f6f97b 100644
--- a/drivers/gpu/drm/zte/zx_vou.c
+++ b/drivers/gpu/drm/zte/zx_vou.c
@@ -294,7 +294,7 @@ static int zx_crtc_init(struct drm_device *drm, struct
zx_vou_hw *vou,
enum vou_chn_type chn_type)
{
struct device *dev = vou->dev;
- struct zx_layer_data data;
+ struct zx_plane *zplane;
struct zx_crtc *zcrtc;
int ret;
@@ -305,19 +305,25 @@ static int zx_crtc_init(struct drm_device *drm, struct
zx_vou_hw *vou,
zcrtc->vou = vou;
zcrtc->chn_
[PATCH v3 3/3] drm: zte: add overlay plane support
From: Shawn Guo
It enables VOU VL (Video Layer) to support overlay plane with scaling
function. VL0 has some quirks on scaling support. We choose to skip it
and only adds VL1 and VL2 into DRM core for now.
Function zx_plane_atomic_disable() gets moved around with no changes to
save a forward declaration.
Signed-off-by: Shawn Guo
---
drivers/gpu/drm/zte/zx_plane.c | 311 +---
drivers/gpu/drm/zte/zx_plane_regs.h | 51 ++
drivers/gpu/drm/zte/zx_vou.c| 80 +-
drivers/gpu/drm/zte/zx_vou_regs.h | 18 +++
4 files changed, 431 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/zte/zx_plane.c b/drivers/gpu/drm/zte/zx_plane.c
index 5445eebf830f..c5ac42647735 100644
--- a/drivers/gpu/drm/zte/zx_plane.c
+++ b/drivers/gpu/drm/zte/zx_plane.c
@@ -30,6 +30,275 @@
DRM_FORMAT_ARGB,
};
+static const uint32_t vl_formats[] = {
+ DRM_FORMAT_NV12,/* Semi-planar YUV420 */
+ DRM_FORMAT_YUV420, /* Planar YUV420 */
+ DRM_FORMAT_YUYV,/* Packed YUV422 */
+ DRM_FORMAT_YVYU,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_VYUY,
+ DRM_FORMAT_YUV444, /* YUV444 8bit */
+ /*
+* TODO: add formats below that HW supports:
+* - YUV420 P010
+* - YUV420 Hantro
+* - YUV444 10bit
+*/
+};
+
+#define FRAC_16_16(mult, div)(((mult) << 16) / (div))
+
+static int zx_vl_plane_atomic_check(struct drm_plane *plane,
+ struct drm_plane_state *plane_state)
+{
+ struct drm_framebuffer *fb = plane_state->fb;
+ struct drm_crtc *crtc = plane_state->crtc;
+ struct drm_crtc_state *crtc_state;
+ struct drm_rect clip;
+ int min_scale = FRAC_16_16(1, 8);
+ int max_scale = FRAC_16_16(8, 1);
+
+ if (!crtc || !fb)
+ return 0;
+
+ crtc_state = drm_atomic_get_existing_crtc_state(plane_state->state,
+ crtc);
+ if (WARN_ON(!crtc_state))
+ return -EINVAL;
+
+ /* nothing to check when disabling or disabled */
+ if (!crtc_state->enable)
+ return 0;
+
+ /* plane must be enabled */
+ if (!plane_state->crtc)
+ return -EINVAL;
+
+ clip.x1 = 0;
+ clip.y1 = 0;
+ clip.x2 = crtc_state->adjusted_mode.hdisplay;
+ clip.y2 = crtc_state->adjusted_mode.vdisplay;
+
+ return drm_plane_helper_check_state(plane_state, &clip,
+ min_scale, max_scale,
+ true, true);
+}
+
+static u32 zx_vl_get_fmt(uint32_t format)
+{
+ u32 val = 0;
+
+ switch (format) {
+ case DRM_FORMAT_NV12:
+ val = VL_FMT_YUV420;
+ break;
+ case DRM_FORMAT_YUV420:
+ val = VL_YUV420_PLANAR | VL_FMT_YUV420;
+ break;
+ case DRM_FORMAT_YUYV:
+ val = VL_YUV422_YUYV | VL_FMT_YUV422;
+ break;
+ case DRM_FORMAT_YVYU:
+ val = VL_YUV422_YVYU | VL_FMT_YUV422;
+ break;
+ case DRM_FORMAT_UYVY:
+ val = VL_YUV422_UYVY | VL_FMT_YUV422;
+ break;
+ case DRM_FORMAT_VYUY:
+ val = VL_YUV422_VYUY | VL_FMT_YUV422;
+ break;
+ case DRM_FORMAT_YUV444:
+ val = VL_FMT_YUV444_8BIT;
+ break;
+ default:
+ WARN_ONCE(1, "invalid pixel format %d\n", format);
+ }
+
+ return val;
+}
+
+static inline void zx_vl_set_update(struct zx_plane *zplane)
+{
+ void __iomem *layer = zplane->layer;
+
+ zx_writel_mask(layer + VL_CTRL0, VL_UPDATE, VL_UPDATE);
+}
+
+static inline void zx_vl_rsz_set_update(struct zx_plane *zplane)
+{
+ zx_writel(zplane->rsz + RSZ_VL_ENABLE_CFG, 1);
+}
+
+static u32 zx_vl_rsz_get_fmt(uint32_t format)
+{
+ u32 val = 0;
+
+ switch (format) {
+ case DRM_FORMAT_NV12:
+ case DRM_FORMAT_YUV420:
+ val = RSZ_VL_FMT_YCBCR420;
+ break;
+ case DRM_FORMAT_YUYV:
+ case DRM_FORMAT_YVYU:
+ case DRM_FORMAT_UYVY:
+ case DRM_FORMAT_VYUY:
+ val = RSZ_VL_FMT_YCBCR422;
+ break;
+ case DRM_FORMAT_YUV444:
+ val = RSZ_VL_FMT_YCBCR444;
+ break;
+ default:
+ WARN_ONCE(1, "invalid pixel format %d\n", format);
+ }
+
+ return val;
+}
+
+static inline u32 rsz_step_value(u32 src, u32 dst)
+{
+ u32 val = 0;
+
+ if (src == dst)
+ val = 0;
+ else if (src < dst)
+ val = RSZ_PARA_STEP((src << 16) / dst);
+ else if (src > dst)
+ val = RSZ_DATA_STEP(src / dst) |
+ RSZ_PARA_STEP(((src << 16) / dst) & 0x);
+
+ return val;
+}
+
+static void zx_vl_rsz_setup(struct zx_plane *zplane, uint32_t format,
+
[PATCH v3 2/3] drm: zte: add .atomic_disable hook to disable graphic layer
From: Shawn Guo
There are a few hardware bits for each graphic layer to control main/aux
channel and clock selection, as well as the layer enabling. These bits
sit outside the layer block itself, but in VOU control glue block. We
currently set these bits up at CRTC initialization for once, and do not
support disabling the layer.
This patch creates a pair of functions zx_vou_layer_enable[disable] to
be invoked from plane hooks .atomic_update and .atomic_disable to set up
and tear down the layer. This is generic for both graphic and video
layers, so it will make the overlay plane support to be added later much
easier.
Signed-off-by: Shawn Guo
---
drivers/gpu/drm/zte/zx_plane.c | 15 +
drivers/gpu/drm/zte/zx_plane.h | 1 +
drivers/gpu/drm/zte/zx_vou.c | 70 ++
drivers/gpu/drm/zte/zx_vou.h | 3 ++
4 files changed, 69 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/zte/zx_plane.c b/drivers/gpu/drm/zte/zx_plane.c
index 78d29b1db91c..5445eebf830f 100644
--- a/drivers/gpu/drm/zte/zx_plane.c
+++ b/drivers/gpu/drm/zte/zx_plane.c
@@ -197,12 +197,27 @@ static void zx_gl_plane_atomic_update(struct drm_plane
*plane,
/* Enable HBSC block */
zx_writel_mask(hbsc + HBSC_CTRL0, HBSC_CTRL_EN, HBSC_CTRL_EN);
+ zx_vou_layer_enable(plane);
+
zx_gl_set_update(zplane);
}
+static void zx_plane_atomic_disable(struct drm_plane *plane,
+ struct drm_plane_state *old_state)
+{
+ struct zx_plane *zplane = to_zx_plane(plane);
+ void __iomem *hbsc = zplane->hbsc;
+
+ zx_vou_layer_disable(plane);
+
+ /* Disable HBSC block */
+ zx_writel_mask(hbsc + HBSC_CTRL0, HBSC_CTRL_EN, 0);
+}
+
static const struct drm_plane_helper_funcs zx_gl_plane_helper_funcs = {
.atomic_check = zx_gl_plane_atomic_check,
.atomic_update = zx_gl_plane_atomic_update,
+ .atomic_disable = zx_plane_atomic_disable,
};
static void zx_plane_destroy(struct drm_plane *plane)
diff --git a/drivers/gpu/drm/zte/zx_plane.h b/drivers/gpu/drm/zte/zx_plane.h
index 264a92e0b532..933611ddffd0 100644
--- a/drivers/gpu/drm/zte/zx_plane.h
+++ b/drivers/gpu/drm/zte/zx_plane.h
@@ -18,6 +18,7 @@ struct zx_plane {
void __iomem *csc;
void __iomem *hbsc;
void __iomem *rsz;
+ const struct vou_layer_bits *bits;
};
#define to_zx_plane(plane) container_of(plane, struct zx_plane, plane)
diff --git a/drivers/gpu/drm/zte/zx_vou.c b/drivers/gpu/drm/zte/zx_vou.c
index d5c801f6f97b..3fb4fc04e693 100644
--- a/drivers/gpu/drm/zte/zx_vou.c
+++ b/drivers/gpu/drm/zte/zx_vou.c
@@ -65,7 +65,6 @@ struct zx_crtc_bits {
u32 polarity_shift;
u32 int_frame_mask;
u32 tc_enable;
- u32 gl_enable;
};
static const struct zx_crtc_bits main_crtc_bits = {
@@ -73,7 +72,6 @@ struct zx_crtc_bits {
.polarity_shift = MAIN_POL_SHIFT,
.int_frame_mask = TIMING_INT_MAIN_FRAME,
.tc_enable = MAIN_TC_EN,
- .gl_enable = OSD_CTRL0_GL0_EN,
};
static const struct zx_crtc_bits aux_crtc_bits = {
@@ -81,7 +79,6 @@ struct zx_crtc_bits {
.polarity_shift = AUX_POL_SHIFT,
.int_frame_mask = TIMING_INT_AUX_FRAME,
.tc_enable = AUX_TC_EN,
- .gl_enable = OSD_CTRL0_GL1_EN,
};
struct zx_crtc {
@@ -97,6 +94,24 @@ struct zx_crtc {
#define to_zx_crtc(x) container_of(x, struct zx_crtc, crtc)
+struct vou_layer_bits {
+ u32 enable;
+ u32 chnsel;
+ u32 clksel;
+};
+
+static const struct vou_layer_bits zx_gl_bits[GL_NUM] = {
+ {
+ .enable = OSD_CTRL0_GL0_EN,
+ .chnsel = OSD_CTRL0_GL0_SEL,
+ .clksel = VOU_CLK_GL0_SEL,
+ }, {
+ .enable = OSD_CTRL0_GL1_EN,
+ .chnsel = OSD_CTRL0_GL1_SEL,
+ .clksel = VOU_CLK_GL1_SEL,
+ },
+};
+
struct zx_vou_hw {
struct device *dev;
void __iomem *osd;
@@ -220,10 +235,6 @@ static void zx_crtc_enable(struct drm_crtc *crtc)
/* Enable channel */
zx_writel_mask(zcrtc->chnreg + CHN_CTRL0, CHN_ENABLE, CHN_ENABLE);
- /* Enable Graphic Layer */
- zx_writel_mask(vou->osd + OSD_CTRL0, bits->gl_enable,
- bits->gl_enable);
-
drm_crtc_vblank_on(crtc);
ret = clk_set_rate(zcrtc->pixclk, mode->clock * 1000);
@@ -247,9 +258,6 @@ static void zx_crtc_disable(struct drm_crtc *crtc)
drm_crtc_vblank_off(crtc);
- /* Disable Graphic Layer */
- zx_writel_mask(vou->osd + OSD_CTRL0, bits->gl_enable, 0);
-
/* Disable channel */
zx_writel_mask(zcrtc->chnreg + CHN_CTRL0, CHN_ENABLE, 0);
@@ -316,6 +324,7 @@ static int zx_crtc_init(struct drm_device *drm, struct
zx_vou_hw *vou,
zplane->csc = vou->osd + MAIN_CSC_OFFSET;
zplane->hbsc = vou->osd + MAIN_HBSC_OFFSET;
zplane->rsz = vou->otfppu + MAIN_RSZ_OFFSET;
+ zplane->bits = &zx_gl_bits[0];
[Bug 96488] [r600g]OpenCL driver causes segfault in ImageMagick's Histogram kernel
https://bugs.freedesktop.org/show_bug.cgi?id=96488 --- Comment #9 from nixscripter at gmail.com --- I have downloaded LLVM r290690 which contains your first diff, manually applied your 2nd diff, and compiled it. The resulting library seems to resolve the issue. Once that patch is reviewed and applied to the mainline, I will do one final verification and (hopefully) close this bug. Thanks for all your efforts on this! -- 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/20161229/d4d268f8/attachment.html>
[Intel-gfx] [PATCH v3 3/3] drm: clean cached display info
Regards
Shashank
On 12/27/2016 3:07 PM, Daniel Vetter wrote:
> On Thu, Dec 22, 2016 at 10:21:25AM +, Jose Abreu wrote:
>> Hi Shashank,
>>
>>
>> On 21-12-2016 15:29, Shashank Sharma wrote:
>>> This patch adds a small helper function, which clears the cached
>>> information about a hot-pluggable display, from connector. On event
>>> This will run on event of a hot-unplug, keeping the connector's display
>>> info up-to-date, avoiding any errors due to invalid cached data.
>>>
>>> Cc: Jose Abreu
>>>
>>> Suggested-by: Jose Abreu
>>> Signed-off-by: Shashank Sharma
>>> ---
>>> drivers/gpu/drm/drm_probe_helper.c | 20
>>> 1 file changed, 20 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_probe_helper.c
>>> b/drivers/gpu/drm/drm_probe_helper.c
>>> index 7cff91e..9e97b45 100644
>>> --- a/drivers/gpu/drm/drm_probe_helper.c
>>> +++ b/drivers/gpu/drm/drm_probe_helper.c
>>> @@ -164,6 +164,18 @@ void drm_kms_helper_poll_enable_locked(struct
>>> drm_device *dev)
>>> }
>>>
>>> /**
>>> + * drm_helper_clear_display_info - clean cached display information for
>>> + * hot pluggable displays, on event of hot-unplug
>>> + * @connector: connector under event
>>> + */
>>> +void drm_helper_clear_display_info(struct drm_connector *connector)
>>> +{
>>> + struct drm_display_info *info = &connector->display_info;
>>> +
>>> + memset(info, 0, sizeof(*info));
>>> +}
>>> +
>>> +/**
>>>* drm_helper_probe_single_connector_modes - get complete set of display
>>> modes
>>>* @connector: connector to probe
>>>* @maxX: max width for modes
>>> @@ -288,6 +300,14 @@ int drm_helper_probe_single_connector_modes(struct
>>> drm_connector *connector,
>>> DRM_DEBUG_KMS("[CONNECTOR:%d:%s] disconnected\n",
>>> connector->base.id, connector->name);
>>> drm_mode_connector_update_edid_property(connector, NULL);
>>> +
>>> + /*
>>> +* Connector status change to disconnected, time to clean
>>> +* cached display information
>>> +*/
>>> + if (connector->status == connector_status_disconnected)
>>> + drm_helper_clear_display_info(connector);
>>> +
>> I don't know if this is the right place to do this because it is
>> a helper and I don't know if it is used by all the drivers. We
>> may need something more general that is always called when
>> probing modes, or force drivers that don't use the helper to use
>> the drm_helper_clear_display_info function. As I told you before,
>> I'm new to dri-devel so we need more comments.
> Seems reasonable to me, since afaik all drivers do use the probe helpers.
> -Daniel
This was my understanding too. Jose, you think there would be any
drivers who dont use this probe ?
- Shashank
>> Best regards,
>> Jose Miguel Abreu
>>
>>> verbose_prune = false;
>>> goto prune;
>>> }
>> ___
>> Intel-gfx mailing list
>> Intel-gfx at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[PATCH 2/2] drm/fsl-dcu: check for clk_prepare_enable() error
On 2016-12-28 19:53, Gabriel Krisman Bertazi wrote: > Fabio Estevam writes: > >> On Wed, Dec 28, 2016 at 4:38 PM, Gabriel Krisman Bertazi >> wrote: >> >>> This leaks tcon if clk_prepare_enable fails. >> >> No, it does not as tcon is allocated via devm_kzalloc(). > > Agreed. But I think devm_kzalloc() only drops the memory once the > device is removed, which is not the case here, since failing > fsl_tcon_init is not fatal and the initialization continues in this > case. That is probably true, but does it matter? I guess it is anyway an unlikely case, so why bother? -- Stefan
[PATCH 0/2] Enable R8A7794 DU VSPD compositor
Hi Sergei, On Thursday 29 Dec 2016 00:18:40 Sergei Shtylyov wrote: > Hello. > >Here's the set of 2 patches against the 'drm-next' branch of David > Airlie's 'linux.git' repo. We're switching to the DU compositor for the DU > driver on the Renesas R8A7794 SoC. > > [1/2] drm: rcar-du: support less VSPs than CRTCs > [2/2] drm: rcar-du: enable VSPD on R8A7794 Nack for the same reasons as your previous related patches. If you want to get this feature merged we'll need to configure whether the VSPD is used standalone or for DU operation at runtime. The DRM live sources were an attempt at implementing that, feel free to revive the idea and brush up the patches. -- Regards, Laurent Pinchart
[BUG] radeon DisplayPort hotplug - dmesg warning, monitor not waking
Resending because it got caught in moderation last time.
What I'm using:
- R9 290
- Kernel 4.9.0
- ASUS PB278Q monitor, connected with DisplayPort
- OpenGL core profile version string: 4.5 (Core Profile) Mesa 13.1.0-devel
(git-d9fef84)
- radeon DDX 7.8.99 (Git)
For as long as I remember I've had a couple of issues with DisplayPort on the
above setup.
First is the kernel WARN that happens when I turn the monitor on from an off
state. It looks like this:
[102004.855043] [ cut here ]
[102004.855046] WARNING: CPU: 7 PID: 14012 at ./include/drm/drm_crtc.h:1403
drm_helper_choose_crtc_dpms+0x93/0xa0 [drm_kms_helper]
[102004.855046] Modules linked in: vhost_net vhost macvtap macvlan xt_CHECKSUM
iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4
nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT
nf_reject_ipv4 xt_tcpudp bridge stp llc ebtable_filter ebtables ip6table_filter
ip6_tables iptable_filter ip_tables x_tables binfmt_misc nls_iso8859_1 mxm_wmi
intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul
crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul
glue_helper ablk_helper cryptd snd_usb_audio snd_usbmidi_lib input_leds joydev
serio_raw snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi
snd_hda_intel snd_soc_rt5640 snd_hda_codec snd_soc_ssm4567 snd_soc_rl6231
snd_hda_core snd_soc_core snd_hwdep mei_me lpc_ich
[102004.855058] mei snd_compress shpchp snd_pcm snd_seq_midi
snd_seq_midi_event snd_rawmidi snd_seq snd_timer snd_seq_device snd wmi
elan_i2c soundcore dw_dmac video snd_soc_sst_acpi i2c_designware_platform
snd_soc_sst_match i2c_designware_core 8250_dw mac_hid spi_pxa2xx_platform
acpi_pad tpm_infineon kvm_intel kvm irqbypass sunrpc parport_pc ppdev lp
parport autofs4 btrfs xor raid6_pq dm_mirror dm_region_hash dm_log hid_generic
usbhid amdkfd amd_iommu_v2 radeon(OE) i2c_algo_bit drm_kms_helper syscopyarea
sysfillrect sysimgblt fb_sys_fops ttm e1000e crc32c_intel drm psmouse ahci ptp
libahci pps_core sdhci_acpi sdhci i2c_hid hid fjes
[102004.855070] CPU: 7 PID: 14012 Comm: kworker/7:1 Tainted: GW OE
4.9.0 #13
[102004.855070] Hardware name: Gigabyte Technology Co., Ltd.
Z97X-UD3H-BK/Z97X-UD3H-BK-CF, BIOS F6 06/17/2014
[102004.855078] Workqueue: events radeon_dp_work_func [radeon]
[102004.855079] a82d4c277d20 aa432693
[102004.855080] a82d4c277d60 aa082bbb 057b401c8000
8c7641aa1800
[102004.855081] 8c764008a000 8c764008a000 0003
[102004.855082] Call Trace:
[102004.855083] [] dump_stack+0x63/0x90
[102004.855083] [] __warn+0xcb/0xf0
[102004.855084] [] warn_slowpath_null+0x1d/0x20
[102004.855087] [] drm_helper_choose_crtc_dpms+0x93/0xa0
[drm_kms_helper]
[102004.855089] [] drm_helper_connector_dpms+0x77/0x100
[drm_kms_helper]
[102004.855096] [] ? atombios_blank_crtc+0x150/0x150 [radeon]
[102004.855103] [] radeon_connector_hotplug+0xf6/0x120
[radeon]
[102004.855111] [] radeon_dp_work_func+0x3f/0x60 [radeon]
[102004.855112] [] process_one_work+0x16b/0x480
[102004.855113] [] worker_thread+0x4b/0x500
[102004.855114] [] ? process_one_work+0x480/0x480
[102004.855115] [] ? process_one_work+0x480/0x480
[102004.855116] [] kthread+0xd9/0xf0
[102004.855117] [] ? kthread_park+0x60/0x60
[102004.855118] [] ret_from_fork+0x25/0x30
[102004.855118] ---[ end trace cbb9abffe6127dc8 ]---
After some investigation I found that this will solve that warning:
diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c
b/drivers/gpu/drm/radeon/radeon_irq_kms.c
index c084cad..c8504b1 100644
--- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c
@@ -102,11 +102,12 @@ static void radeon_dp_work_func(struct work_struct *work)
struct drm_mode_config *mode_config = &dev->mode_config;
struct drm_connector *connector;
- /* this should take a mutex */
+ mutex_lock(&mode_config->mutex);
if (mode_config->num_connector) {
list_for_each_entry(connector, &mode_config->connector_list,
head)
radeon_connector_hotplug(connector);
}
+ mutex_unlock(&mode_config->mutex);
}
/**
* radeon_driver_irq_preinstall_kms - drm irq preinstall callback
However, it does not solve my other problem, which is that sometimes, when
turning the monitor on, the display will not wake; it will just display "No
Signal". To make it wake up one has to turn the monitor off and on again a few
times, unplug the cable, or (more recently; I'm not sure what changed), turn
off the monitor, go to a TTY, and turn the monitor back on.
When the monitor turns off or on, I get a seemingly random smattering of errors
in dmesg:
[72940.457950] [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link
status failed
[72940.457961] [drm:radeon_dp_link_train [radeon]] *ERROR* clock
[Bug 99219] The Stanley Parable GPU hang when starting a new game
https://bugs.freedesktop.org/show_bug.cgi?id=99219 Bug ID: 99219 Summary: The Stanley Parable GPU hang when starting a new game Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: haagch at frickel.club QA Contact: dri-devel at lists.freedesktop.org RX 480 with llvm 4.0.0svn_r290670, mesa git Tested with linux 4.9 and 4.10-rc1, happens on both. Tested with ingame settings medium and highest, happens with both. This apitrace hangs my GPU: https://haagch.frickel.club/files/stanley_linux.trace.xz Dez 29 11:21:58 c-l kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, last signaled seq=6391, last emitted seq=6394 Dez 29 11:21:58 c-l kernel: [drm] IP block:gfx_v8_0 is hung! -- 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/20161229/6021e116/attachment.html>
[PATCH] drm/mm: Some doc polish
On Wed, Dec 28, 2016 at 05:37:26PM +, Chris Wilson wrote: > On Wed, Dec 28, 2016 at 05:57:40PM +0100, Daniel Vetter wrote: > > @@ -230,23 +272,23 @@ static inline u64 drm_mm_hole_node_end(const struct > > drm_mm_node *hole_node) > > > > /** > > * drm_mm_for_each_node - iterator to walk over all allocated nodes > > - * @entry: drm_mm_node structure to assign to in each iteration step > > - * @mm: drm_mm allocator to walk > > + * @entry: &drm_mm_node structure to assign to in each iteration step > > If we have the &struct link, do we need to say "structure"? > We use a mix of "&struct structure" and plain "&struct". Choose a style > and make it consistent. (Bonus points for an easy to find style guide.) There's also "struct &struct_name" and "&struct struct_name". Anything goes really, and I just semi-randomly pick what reads reasonably well. The issue with macros is that they don't have the types in the declaration (compared to functions), that's why I added the &. And I think indicating the text that it's a structure makes some sense, since the link could also be to an enum. Anyway if you insist I can do some ocd for drm_mm, but for all of the drm docs is a bit much. Oh and the style guides we have: https://dri.freedesktop.org/docs/drm/doc-guide/sphinx.html#writing-documentation https://dri.freedesktop.org/docs/drm/gpu/introduction.html#style-guidelines Reminds me, should add a link from the drm guidelines to the overall ones. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH] drm/doc: link style-guide to doc-guide
Our style guide should only be the delta compared to the overall one. Cc: Chris Wilson Signed-off-by: Daniel Vetter --- Documentation/gpu/introduction.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/gpu/introduction.rst b/Documentation/gpu/introduction.rst index 1903595b5310..6960e31f71e1 100644 --- a/Documentation/gpu/introduction.rst +++ b/Documentation/gpu/introduction.rst @@ -49,3 +49,5 @@ section name should be all upper-case or not, and whether it should end in a colon or not. Go with the file-local style. Other common section names are "Notes" with information for dangerous or tricky corner cases, and "FIXME" where the interface could be cleaned up. + +Also read the :ref:`guidelines for the kernel documentation at large `. -- 2.7.4
[Intel-gfx] [PATCH v3 3/3] drm: clean cached display info
Regards
Shashank
On 12/29/2016 3:35 PM, Jose Abreu wrote:
> Hi Shashank,
>
>
> On 29-12-2016 05:53, Sharma, Shashank wrote:
>> Regards
>>
>> Shashank
>>
>>
>> On 12/27/2016 3:07 PM, Daniel Vetter wrote:
>>> On Thu, Dec 22, 2016 at 10:21:25AM +, Jose Abreu wrote:
Hi Shashank,
On 21-12-2016 15:29, Shashank Sharma wrote:
> This patch adds a small helper function, which clears the
> cached
> information about a hot-pluggable display, from connector.
> On event
> This will run on event of a hot-unplug, keeping the
> connector's display
> info up-to-date, avoiding any errors due to invalid cached
> data.
>
> Cc: Jose Abreu
>
> Suggested-by: Jose Abreu
> Signed-off-by: Shashank Sharma
> ---
>drivers/gpu/drm/drm_probe_helper.c | 20
>1 file changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index 7cff91e..9e97b45 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -164,6 +164,18 @@ void
> drm_kms_helper_poll_enable_locked(struct drm_device *dev)
>}
> /**
> + * drm_helper_clear_display_info - clean cached display
> information for
> + * hot pluggable displays, on event of hot-unplug
> + * @connector: connector under event
> + */
> +void drm_helper_clear_display_info(struct drm_connector
> *connector)
> +{
> +struct drm_display_info *info = &connector->display_info;
> +
> +memset(info, 0, sizeof(*info));
> +}
> +
> +/**
> * drm_helper_probe_single_connector_modes - get complete
> set of display modes
> * @connector: connector to probe
> * @maxX: max width for modes
> @@ -288,6 +300,14 @@ int
> drm_helper_probe_single_connector_modes(struct drm_connector
> *connector,
>DRM_DEBUG_KMS("[CONNECTOR:%d:%s] disconnected\n",
>connector->base.id, connector->name);
>drm_mode_connector_update_edid_property(connector,
> NULL);
> +
> +/*
> + * Connector status change to disconnected, time to
> clean
> + * cached display information
> + */
> +if (connector->status ==
> connector_status_disconnected)
> +drm_helper_clear_display_info(connector);
> +
I don't know if this is the right place to do this because it is
a helper and I don't know if it is used by all the drivers. We
may need something more general that is always called when
probing modes, or force drivers that don't use the helper to use
the drm_helper_clear_display_info function. As I told you
before,
I'm new to dri-devel so we need more comments.
>>> Seems reasonable to me, since afaik all drivers do use the
>>> probe helpers.
>>> -Daniel
>> This was my understanding too. Jose, you think there would be
>> any drivers who dont use this probe ?
>> - Shashank
> I found only one driver that don't use this helper: vmwgfx. But,
> this driver does not seem to use EDID fields, it has a list of
> preferred video modes and manually adds these modes.
>
> So, I think it is safe to add this in the helper as long as
> future drivers that use EDID use this helper also. Maybe a small
> comment about this should be added in the helper declaration.
>
> Best regards,
> Jose Miguel Abreu
Sure, I will add a comment and publish a new patchset.
Shashank
Best regards,
Jose Miguel Abreu
>verbose_prune = false;
>goto prune;
>}
___
Intel-gfx mailing list
Intel-gfx at lists.freedesktop.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_intel-2Dgfx&d=DgIC-g&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=1G5dnBp7Y6VEifpEnDT2wKFoDRBXnxGXAnA-4883H74&s=y1M2ce128zpR_lBDPSgS_JGm-HoPIJjneK2s3tkrvyo&e=
[PATCH] drm/mm: Some doc polish
On Thu, Dec 29, 2016 at 11:35:48AM +0100, Daniel Vetter wrote: > On Wed, Dec 28, 2016 at 05:37:26PM +, Chris Wilson wrote: > > On Wed, Dec 28, 2016 at 05:57:40PM +0100, Daniel Vetter wrote: > > > @@ -230,23 +272,23 @@ static inline u64 drm_mm_hole_node_end(const struct > > > drm_mm_node *hole_node) > > > > > > /** > > > * drm_mm_for_each_node - iterator to walk over all allocated nodes > > > - * @entry: drm_mm_node structure to assign to in each iteration step > > > - * @mm: drm_mm allocator to walk > > > + * @entry: &drm_mm_node structure to assign to in each iteration step > > > > If we have the &struct link, do we need to say "structure"? > > We use a mix of "&struct structure" and plain "&struct". Choose a style > > and make it consistent. (Bonus points for an easy to find style guide.) > > There's also "struct &struct_name" and "&struct struct_name". Anything > goes really, and I just semi-randomly pick what reads reasonably well. The > issue with macros is that they don't have the types in the declaration > (compared to functions), that's why I added the &. > > And I think indicating the text that it's a structure makes some sense, > since the link could also be to an enum. Does "&struct struct_name" render well in the html? I think that's the easiest style for us to remember since it matches C (and so also reads well for someone versed in C). > Anyway if you insist I can do some ocd for drm_mm, but for all of the drm > docs is a bit much. I don't insist, I just think having a recommended way of writing the stanzas not only reduce the cognitive burden of writing them but also reading them. > Oh and the style guides we have: > https://dri.freedesktop.org/docs/drm/doc-guide/sphinx.html#writing-documentation > https://dri.freedesktop.org/docs/drm/gpu/introduction.html#style-guidelines I said easy to find! :) Something like Documentation/WritingStyle -Chris -- Chris Wilson, Intel Open Source Technology Centre
[Bug 99158] vdpau segfaults and gpu locks with kodi on R9285
https://bugs.freedesktop.org/show_bug.cgi?id=99158 --- Comment #4 from Andy Furniss --- (In reply to Andy Furniss from comment #3) > Couldn't get it to crash with valgrind. > > Bisect not 100% sure as it seemed to get harder to provoke going back in > time, but it does seem to need temporal deint and I got - > > first bad commit: [d0d5f7600c2e8ab8d0c153787185f7a534753edd] > Revert "st/vdpau: use linear layout for output surfaces > > The revert reverts from current head, so I will test for a while like that. I've been running OK with the revert reverted for some time now, testing with a script that repeatedly starts kodi, so it does seem to be this commit that causes some timing issue with vdpau temporal deint. -- 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/20161229/b8683109/attachment-0001.html>
[PATCH] drm/mm: Some doc polish
On Thu, 29 Dec 2016, Chris Wilson wrote: > On Thu, Dec 29, 2016 at 11:35:48AM +0100, Daniel Vetter wrote: >> On Wed, Dec 28, 2016 at 05:37:26PM +, Chris Wilson wrote: >> > On Wed, Dec 28, 2016 at 05:57:40PM +0100, Daniel Vetter wrote: >> > > @@ -230,23 +272,23 @@ static inline u64 drm_mm_hole_node_end(const >> > > struct drm_mm_node *hole_node) >> > > >> > > /** >> > > * drm_mm_for_each_node - iterator to walk over all allocated nodes >> > > - * @entry: drm_mm_node structure to assign to in each iteration step >> > > - * @mm: drm_mm allocator to walk >> > > + * @entry: &drm_mm_node structure to assign to in each iteration step >> > >> > If we have the &struct link, do we need to say "structure"? >> > We use a mix of "&struct structure" and plain "&struct". Choose a style >> > and make it consistent. (Bonus points for an easy to find style guide.) >> >> There's also "struct &struct_name" and "&struct struct_name". Anything >> goes really, and I just semi-randomly pick what reads reasonably well. The >> issue with macros is that they don't have the types in the declaration >> (compared to functions), that's why I added the &. >> >> And I think indicating the text that it's a structure makes some sense, >> since the link could also be to an enum. > > Does "&struct struct_name" render well in the html? I think that's the > easiest style for us to remember since it matches C (and so also reads > well for someone versed in C). "&struct foo" turns the whole thing into a link while "struct &foo" only makes foo a link and struct remains in normal body text style. I think the former is more aesthetically pleasing. The main downside is that "&struct foo" must not have a line break in between (the parser is just a dumb line based regexp mess). BR, Jani. > >> Anyway if you insist I can do some ocd for drm_mm, but for all of the drm >> docs is a bit much. > > I don't insist, I just think having a recommended way of writing the > stanzas not only reduce the cognitive burden of writing them but also > reading them. > >> Oh and the style guides we have: >> https://dri.freedesktop.org/docs/drm/doc-guide/sphinx.html#writing-documentation >> https://dri.freedesktop.org/docs/drm/gpu/introduction.html#style-guidelines > > I said easy to find! :) Something like Documentation/WritingStyle > -Chris -- Jani Nikula, Intel Open Source Technology Center
[PATCH] drm/mm: Some doc polish
On Thu, Dec 29, 2016 at 10:54:29AM +, Chris Wilson wrote: > On Thu, Dec 29, 2016 at 11:35:48AM +0100, Daniel Vetter wrote: > > On Wed, Dec 28, 2016 at 05:37:26PM +, Chris Wilson wrote: > > > On Wed, Dec 28, 2016 at 05:57:40PM +0100, Daniel Vetter wrote: > > > > @@ -230,23 +272,23 @@ static inline u64 drm_mm_hole_node_end(const > > > > struct drm_mm_node *hole_node) > > > > > > > > /** > > > > * drm_mm_for_each_node - iterator to walk over all allocated nodes > > > > - * @entry: drm_mm_node structure to assign to in each iteration step > > > > - * @mm: drm_mm allocator to walk > > > > + * @entry: &drm_mm_node structure to assign to in each iteration step > > > > > > If we have the &struct link, do we need to say "structure"? > > > We use a mix of "&struct structure" and plain "&struct". Choose a style > > > and make it consistent. (Bonus points for an easy to find style guide.) > > > > There's also "struct &struct_name" and "&struct struct_name". Anything > > goes really, and I just semi-randomly pick what reads reasonably well. The > > issue with macros is that they don't have the types in the declaration > > (compared to functions), that's why I added the &. > > > > And I think indicating the text that it's a structure makes some sense, > > since the link could also be to an enum. > > Does "&struct struct_name" render well in the html? I think that's the > easiest style for us to remember since it matches C (and so also reads > well for someone versed in C). > > > Anyway if you insist I can do some ocd for drm_mm, but for all of the drm > > docs is a bit much. > > I don't insist, I just think having a recommended way of writing the > stanzas not only reduce the cognitive burden of writing them but also > reading them. Hm ok, quick counting shows that &struct foo seems to win. I'll make a patch as the canonical thing. > > Oh and the style guides we have: > > https://dri.freedesktop.org/docs/drm/doc-guide/sphinx.html#writing-documentation > > https://dri.freedesktop.org/docs/drm/gpu/introduction.html#style-guidelines > > I said easy to find! :) Something like Documentation/WritingStyle Documentation/doc-guide as a directory to find it all. And there's links to it at a growing set of places ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH] drm/mm: Convert to drm_printer
Including all drivers. I thought about keeping small compat functions
to avoid having to change all drivers. But I really like the
drm_printer idea, so figured spreading it more widely is a good thing.
v2: Review from Chris:
- Natural argument order and better name for drm_mm_print.
- show_mm() macro in the selftest.
Cc: Rob Clark
Cc: Russell King
Cc: Alex Deucher
Cc: Christian König
Cc: Lucas Stach
Cc: Tomi Valkeinen
Cc: Thierry Reding
Cc: Jyri Sarha
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 3 +-
drivers/gpu/drm/armada/armada_debugfs.c | 6 +--
drivers/gpu/drm/drm_mm.c | 67 +---
drivers/gpu/drm/drm_print.c | 2 +-
drivers/gpu/drm/etnaviv/etnaviv_drv.c| 10 +++--
drivers/gpu/drm/msm/msm_debugfs.c| 6 ++-
drivers/gpu/drm/omapdrm/omap_debugfs.c | 6 ++-
drivers/gpu/drm/qxl/qxl_ttm.c| 6 +--
drivers/gpu/drm/radeon/radeon_ttm.c | 6 +--
drivers/gpu/drm/selftests/test-drm_mm.c | 12 +++--
drivers/gpu/drm/tegra/drm.c | 5 ++-
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 4 +-
drivers/gpu/drm/ttm/ttm_bo_manager.c | 3 +-
include/drm/drm_mm.h | 9 +---
16 files changed, 63 insertions(+), 91 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 00f46b0e076d..c6c125d31161 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -235,9 +235,10 @@ static void amdgpu_gtt_mgr_debug(struct
ttm_mem_type_manager *man,
const char *prefix)
{
struct amdgpu_gtt_mgr *mgr = man->priv;
+ struct drm_printer p = drm_debug_printer(prefix);
spin_lock(&mgr->lock);
- drm_mm_debug_table(&mgr->mm, prefix);
+ drm_mm_print(&mgr->mm, &p);
spin_unlock(&mgr->lock);
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 8e35c1ff59e3..c695b6c55361 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1482,18 +1482,18 @@ static int amdgpu_mm_dump_table(struct seq_file *m,
void *data)
struct drm_device *dev = node->minor->dev;
struct amdgpu_device *adev = dev->dev_private;
struct drm_mm *mm = (struct drm_mm *)adev->mman.bdev.man[ttm_pl].priv;
- int ret;
struct ttm_bo_global *glob = adev->mman.bdev.glob;
+ struct drm_printer p = drm_seq_file_printer(m);
spin_lock(&glob->lru_lock);
- ret = drm_mm_dump_table(m, mm);
+ drm_mm_print(mm, &p);
spin_unlock(&glob->lru_lock);
if (ttm_pl == TTM_PL_VRAM)
seq_printf(m, "man size:%llu pages, ram usage:%lluMB, vis
usage:%lluMB\n",
adev->mman.bdev.man[ttm_pl].size,
(u64)atomic64_read(&adev->vram_usage) >> 20,
(u64)atomic64_read(&adev->vram_vis_usage) >> 20);
- return ret;
+ return 0;
}
static int ttm_pl_vram = TTM_PL_VRAM;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index d710226a0fff..ac9007986c11 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -207,9 +207,10 @@ static void amdgpu_vram_mgr_debug(struct
ttm_mem_type_manager *man,
const char *prefix)
{
struct amdgpu_vram_mgr *mgr = man->priv;
+ struct drm_printer p = drm_debug_printer(prefix);
spin_lock(&mgr->lock);
- drm_mm_debug_table(&mgr->mm, prefix);
+ drm_mm_print(&mgr->mm, &p);
spin_unlock(&mgr->lock);
}
diff --git a/drivers/gpu/drm/armada/armada_debugfs.c
b/drivers/gpu/drm/armada/armada_debugfs.c
index 90222e60d2d6..0c7b915be082 100644
--- a/drivers/gpu/drm/armada/armada_debugfs.c
+++ b/drivers/gpu/drm/armada/armada_debugfs.c
@@ -19,13 +19,13 @@ static int armada_debugfs_gem_linear_show(struct seq_file
*m, void *data)
struct drm_info_node *node = m->private;
struct drm_device *dev = node->minor->dev;
struct armada_private *priv = dev->dev_private;
- int ret;
+ struct drm_printer p = drm_seq_file_printer(m);
mutex_lock(&priv->linear_lock);
- ret = drm_mm_dump_table(m, &priv->linear);
+ drm_mm_dump_table(&p, &priv->linear);
mutex_unlock(&priv->linear_lock);
- return ret;
+ return 0;
}
static int armada_debugfs_reg_show(struct seq_file *m, void *data)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 1a5b4eba2386..e54aa3fa538f 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -832,8 +832,7 @@ void drm_mm_
[PATCH] drm: zte: support hdmi audio through spdif
On Thu, Dec 22, 2016 at 10:18:00AM -0500, Sean Paul wrote:
> On Thu, Dec 22, 2016 at 8:11 AM, Shawn Guo wrote:
> > +static int zx_hdmi_audio_get_n(unsigned int fs)
> > +{
> > + unsigned int n;
> > +
> > + switch (fs) {
> > + case 32000:
> > + n = 4096;
> > + break;
> > + case 44100:
> > + n = 6272;
> > + break;
> > + case 48000:
> > + n = 6144;
> > + break;
> > + case 88200:
> > + n = 6272 * 2;
> > + break;
> > + case 96000:
> > + n = 6144 * 2;
> > + break;
> > + case 176400:
> > + n = 6272 * 4;
> > + break;
> > + case 192000:
> > + n = 6144 * 4;
> > + break;
> > + default:
> > + n = fs * 128 / 1000;
>
> It seems like this could be distilled down to:
>
> if (fs && (fs % 44100) == 0)
> n = 6272 * (fs / 44100);
> else
> n = fs * 128 / 1000;
Nice! Thanks for the suggestion.
>
> > + }
> > +
> > + return n;
> > +}
> > +
> > +static int zx_hdmi_audio_hw_params(struct device *dev,
> > + void *data,
> > + struct hdmi_codec_daifmt *daifmt,
> > + struct hdmi_codec_params *params)
> > +{
> > + struct zx_hdmi *hdmi = dev_get_drvdata(dev);
> > + struct hdmi_audio_infoframe *cea = ¶ms->cea;
> > + union hdmi_infoframe frame;
> > + int n;
> > +
> > + /* We only support spdif for now */
> > + if (daifmt->fmt != HDMI_SPDIF) {
> > + DRM_DEV_ERROR(hdmi->dev, "invalid daifmt %d\n",
> > daifmt->fmt);
> > + return -EINVAL;
> > + }
> > +
> > + switch (params->sample_width) {
> > + case 16:
> > + hdmi_writeb_mask(hdmi, TPI_AUD_CONFIG,
> > SPDIF_SAMPLE_SIZE_MASK,
> > +SPDIF_SAMPLE_SIZE_16BIT);
> > + break;
> > + case 20:
> > + hdmi_writeb_mask(hdmi, TPI_AUD_CONFIG,
> > SPDIF_SAMPLE_SIZE_MASK,
> > +SPDIF_SAMPLE_SIZE_20BIT);
> > + break;
> > + case 24:
> > + hdmi_writeb_mask(hdmi, TPI_AUD_CONFIG,
> > SPDIF_SAMPLE_SIZE_MASK,
> > +SPDIF_SAMPLE_SIZE_24BIT);
> > + break;
> > + default:
> > + DRM_DEV_ERROR(hdmi->dev, "invalid sample width %d\n",
> > + params->sample_width);
> > + return -EINVAL;
> > + }
> > +
> > + /* CTS is calculated by hardware, and we only need to take care of
> > N */
> > + n = zx_hdmi_audio_get_n(params->sample_rate);
> > + hdmi_writeb(hdmi, N_SVAL1, n & 0xff);
> > + hdmi_writeb(hdmi, N_SVAL2, (n >> 8) && 0xff);
>
> s/&&/&/ ?
Oops! Thanks for catching it.
Shawn
>
> > + hdmi_writeb(hdmi, N_SVAL3, (n >> 16) & 0xf);
> > +
> > + /* Enable spdif mode */
> > + hdmi_writeb_mask(hdmi, AUD_MODE, SPDIF_EN, SPDIF_EN);
> > +
> > + /* Enable audio input */
> > + hdmi_writeb_mask(hdmi, AUD_EN, AUD_IN_EN, AUD_IN_EN);
> > +
> > + memcpy(&frame.audio, cea, sizeof(*cea));
> > +
> > + return zx_hdmi_infoframe_trans(hdmi, &frame, FSEL_AUDIO);
> > +}
[PATCH v2] drm: zte: support hdmi audio through spdif
From: Shawn Guo
It enables HDMI audio support through SPDIF interface based on generic
hdmi-audio-codec driver. The HDMI hardware supports more audio
interfaces than SPDIF, like I2S, which may be added later.
Signed-off-by: Shawn Guo
---
Changes for v2:
- Distll the function zx_hdmi_audio_get_n() per Sean's suggestion and
make it inline.
- Fix the operator typo on N_SVAL2 register write.
drivers/gpu/drm/zte/Kconfig| 1 +
drivers/gpu/drm/zte/zx_hdmi.c | 148 +
drivers/gpu/drm/zte/zx_hdmi_regs.h | 14
drivers/gpu/drm/zte/zx_vou.c | 9 +++
drivers/gpu/drm/zte/zx_vou.h | 10 +++
drivers/gpu/drm/zte/zx_vou_regs.h | 2 +
6 files changed, 184 insertions(+)
diff --git a/drivers/gpu/drm/zte/Kconfig b/drivers/gpu/drm/zte/Kconfig
index 4065b2840f1c..ed6de4b10c74 100644
--- a/drivers/gpu/drm/zte/Kconfig
+++ b/drivers/gpu/drm/zte/Kconfig
@@ -4,5 +4,6 @@ config DRM_ZTE
select DRM_KMS_CMA_HELPER
select DRM_KMS_FB_HELPER
select DRM_KMS_HELPER
+ select SND_SOC_HDMI_CODEC if SND_SOC
help
Choose this option to enable DRM on ZTE ZX SoCs.
diff --git a/drivers/gpu/drm/zte/zx_hdmi.c b/drivers/gpu/drm/zte/zx_hdmi.c
index 6bf6c364811e..c20121846073 100644
--- a/drivers/gpu/drm/zte/zx_hdmi.c
+++ b/drivers/gpu/drm/zte/zx_hdmi.c
@@ -25,6 +25,8 @@
#include
#include
+#include
+
#include "zx_hdmi_regs.h"
#include "zx_vou.h"
@@ -49,6 +51,7 @@ struct zx_hdmi {
bool sink_is_hdmi;
bool sink_has_audio;
const struct vou_inf *inf;
+ struct platform_device *audio_pdev;
};
#define to_zx_hdmi(x) container_of(x, struct zx_hdmi, x)
@@ -366,6 +369,142 @@ static irqreturn_t zx_hdmi_irq_handler(int irq, void
*dev_id)
return IRQ_NONE;
}
+static int zx_hdmi_audio_startup(struct device *dev, void *data)
+{
+ struct zx_hdmi *hdmi = dev_get_drvdata(dev);
+ struct drm_encoder *encoder = &hdmi->encoder;
+
+ vou_inf_hdmi_audio_sel(encoder->crtc, VOU_HDMI_AUD_SPDIF);
+
+ return 0;
+}
+
+static void zx_hdmi_audio_shutdown(struct device *dev, void *data)
+{
+ struct zx_hdmi *hdmi = dev_get_drvdata(dev);
+
+ /* Disable audio input */
+ hdmi_writeb_mask(hdmi, AUD_EN, AUD_IN_EN, 0);
+}
+
+static inline int zx_hdmi_audio_get_n(unsigned int fs)
+{
+ unsigned int n;
+
+ if (fs && (fs % 44100) == 0)
+ n = 6272 * (fs / 44100);
+ else
+ n = fs * 128 / 1000;
+
+ return n;
+}
+
+static int zx_hdmi_audio_hw_params(struct device *dev,
+ void *data,
+ struct hdmi_codec_daifmt *daifmt,
+ struct hdmi_codec_params *params)
+{
+ struct zx_hdmi *hdmi = dev_get_drvdata(dev);
+ struct hdmi_audio_infoframe *cea = ¶ms->cea;
+ union hdmi_infoframe frame;
+ int n;
+
+ /* We only support spdif for now */
+ if (daifmt->fmt != HDMI_SPDIF) {
+ DRM_DEV_ERROR(hdmi->dev, "invalid daifmt %d\n", daifmt->fmt);
+ return -EINVAL;
+ }
+
+ switch (params->sample_width) {
+ case 16:
+ hdmi_writeb_mask(hdmi, TPI_AUD_CONFIG, SPDIF_SAMPLE_SIZE_MASK,
+SPDIF_SAMPLE_SIZE_16BIT);
+ break;
+ case 20:
+ hdmi_writeb_mask(hdmi, TPI_AUD_CONFIG, SPDIF_SAMPLE_SIZE_MASK,
+SPDIF_SAMPLE_SIZE_20BIT);
+ break;
+ case 24:
+ hdmi_writeb_mask(hdmi, TPI_AUD_CONFIG, SPDIF_SAMPLE_SIZE_MASK,
+SPDIF_SAMPLE_SIZE_24BIT);
+ break;
+ default:
+ DRM_DEV_ERROR(hdmi->dev, "invalid sample width %d\n",
+ params->sample_width);
+ return -EINVAL;
+ }
+
+ /* CTS is calculated by hardware, and we only need to take care of N */
+ n = zx_hdmi_audio_get_n(params->sample_rate);
+ hdmi_writeb(hdmi, N_SVAL1, n & 0xff);
+ hdmi_writeb(hdmi, N_SVAL2, (n >> 8) & 0xff);
+ hdmi_writeb(hdmi, N_SVAL3, (n >> 16) & 0xf);
+
+ /* Enable spdif mode */
+ hdmi_writeb_mask(hdmi, AUD_MODE, SPDIF_EN, SPDIF_EN);
+
+ /* Enable audio input */
+ hdmi_writeb_mask(hdmi, AUD_EN, AUD_IN_EN, AUD_IN_EN);
+
+ memcpy(&frame.audio, cea, sizeof(*cea));
+
+ return zx_hdmi_infoframe_trans(hdmi, &frame, FSEL_AUDIO);
+}
+
+static int zx_hdmi_audio_digital_mute(struct device *dev, void *data,
+ bool enable)
+{
+ struct zx_hdmi *hdmi = dev_get_drvdata(dev);
+
+ if (enable)
+ hdmi_writeb_mask(hdmi, TPI_AUD_CONFIG, TPI_AUD_MUTE,
+TPI_AUD_MUTE);
+ else
+ hdmi_writeb_mask(hdmi, TPI_AUD_CONFIG, TPI_AUD_MUTE, 0);
+
+ return 0;
+}
+
+static int zx_hdmi_audio_get_eld(struct device *dev, void *data,
[Bug 99163] Radeon HDMI audio lost after resuming from suspend on kernel >4.2
https://bugs.freedesktop.org/show_bug.cgi?id=99163 --- Comment #9 from Felix Schwarz --- Maybe a different bug but since I switched to Wayland (F25) I noticed that HDMI audio (Radeon HD6450) is also gone for me after suspend/resume. Never noticed that with X though. Switching VTs does not change anything for me but that might be due to using Wayland. -- 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/20161229/7fccf55b/attachment.html>
[Intel-gfx] [PATCH] drm/mm: Convert to drm_printer
On Thu, Dec 29, 2016 at 12:09:24PM +0100, Daniel Vetter wrote: > Including all drivers. I thought about keeping small compat functions > to avoid having to change all drivers. But I really like the > drm_printer idea, so figured spreading it more widely is a good thing. > > v2: Review from Chris: > - Natural argument order and better name for drm_mm_print. > - show_mm() macro in the selftest. > > Cc: Rob Clark > Cc: Russell King > Cc: Alex Deucher > Cc: Christian König > Cc: Lucas Stach > Cc: Tomi Valkeinen > Cc: Thierry Reding > Cc: Jyri Sarha > Signed-off-by: Daniel Vetter Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH] drm: clean cached display info
This patch adds a small helper function, which clears the cached
information about a hot-pluggable display, from connector. On event
This will run on event of a hot-unplug, keeping the connector's display
info up-to-date, avoiding any errors due to invalid cached data.
Forking this patch out from the 3 patch series:
https://patchwork.freedesktop.org/patch/128961/
(still under review) and sending as individual patch.
Cc: Jose Abreu
Cc: Daniel Vetter
Suggested-by: Jose Abreu
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/drm_probe_helper.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 7cff91e..65a6a1f 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -164,6 +164,18 @@ void drm_kms_helper_poll_enable_locked(struct drm_device
*dev)
}
/**
+ * drm_helper_clear_display_info - clean cached display information for
+ * hot pluggable displays, on event of hot-unplug
+ * @connector: connector under event
+ */
+void drm_helper_clear_display_info(struct drm_connector *connector)
+{
+ struct drm_display_info *info = &connector->display_info;
+
+ memset(info, 0, sizeof(*info));
+}
+
+/**
* drm_helper_probe_single_connector_modes - get complete set of display modes
* @connector: connector to probe
* @maxX: max width for modes
@@ -288,6 +300,16 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
DRM_DEBUG_KMS("[CONNECTOR:%d:%s] disconnected\n",
connector->base.id, connector->name);
drm_mode_connector_update_edid_property(connector, NULL);
+
+ /*
+* Connector status change to disconnected, time to clean
+* cached display information.
+* Any driver which doesn't use this probe_helper function
+* should implement update of EDID property and display_info
+* on its own.
+*/
+ drm_helper_clear_display_info(connector);
+
verbose_prune = false;
goto prune;
}
--
1.9.1
[PATCH] drm/doc: link style-guide to doc-guide
On Thu, Dec 29, 2016 at 11:44:35AM +0100, Daniel Vetter wrote: > Our style guide should only be the delta compared to the overall one. The link looks correct, but I still haven't found a good guide on the style of prose to use; certainly one doesn't stand out from the instructions on how to write the markup. > Cc: Chris Wilson > Signed-off-by: Daniel Vetter Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre
[Intel-gfx] [PATCH] drm/mm: Convert to drm_printer
On Thu, Dec 29, 2016 at 11:31:45AM +, Chris Wilson wrote: > On Thu, Dec 29, 2016 at 12:09:24PM +0100, Daniel Vetter wrote: > > Including all drivers. I thought about keeping small compat functions > > to avoid having to change all drivers. But I really like the > > drm_printer idea, so figured spreading it more widely is a good thing. > > > > v2: Review from Chris: > > - Natural argument order and better name for drm_mm_print. > > - show_mm() macro in the selftest. > > > > Cc: Rob Clark > > Cc: Russell King > > Cc: Alex Deucher > > Cc: Christian König > > Cc: Lucas Stach > > Cc: Tomi Valkeinen > > Cc: Thierry Reding > > Cc: Jyri Sarha > > Signed-off-by: Daniel Vetter > > Reviewed-by: Chris Wilson r-b on both patches? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH 1/3] drm: add crtc helper drm_crtc_from_index()
From: Shawn Guo
It adds a crtc helper drm_crtc_from_index() to find the registered CRTC
with a given index, just like drm_plane_from_index().
Signed-off-by: Shawn Guo
---
drivers/gpu/drm/drm_crtc.c | 20
include/drm/drm_crtc.h | 1 +
2 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e75f62cd8a65..5c1bb1f34697 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -47,6 +47,26 @@
#include "drm_internal.h"
/**
+ * drm_crtc_from_index - find the registered CRTC at an index
+ * @dev: DRM device
+ * @idx: index of registered CRTC to find for
+ *
+ * Given a CRTC index, return the registered CRTC from DRM device's
+ * list of CRTCs with matching index.
+ */
+struct drm_crtc *drm_crtc_from_index(struct drm_device *dev, int idx)
+{
+ struct drm_crtc *crtc;
+
+ drm_for_each_crtc(crtc, dev)
+ if (idx == crtc->index)
+ return crtc;
+
+ return NULL;
+}
+EXPORT_SYMBOL(drm_crtc_from_index);
+
+/**
* drm_crtc_force_disable - Forcibly turn off a CRTC
* @crtc: CRTC to turn off
*
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 946672f97e1e..a5627eb8621f 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -830,6 +830,7 @@ void drm_crtc_get_hv_timing(const struct drm_display_mode
*mode,
int drm_crtc_force_disable_all(struct drm_device *dev);
int drm_mode_set_config_internal(struct drm_mode_set *set);
+struct drm_crtc *drm_crtc_from_index(struct drm_device *dev, int idx);
/* Helpers */
static inline struct drm_crtc *drm_crtc_find(struct drm_device *dev,
--
1.9.1
[PATCH 2/3] drm: zte: use crtc helper drm_crtc_from_index()
From: Shawn Guo
Function zx_find_crtc() does the exactly same thing as what crtc helper
drm_crtc_from_index() provides. Use the helper to save some code.
Signed-off-by: Shawn Guo
---
drivers/gpu/drm/zte/zx_vou.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/zte/zx_vou.c b/drivers/gpu/drm/zte/zx_vou.c
index 73fe15c17c32..a86e3a5852a2 100644
--- a/drivers/gpu/drm/zte/zx_vou.c
+++ b/drivers/gpu/drm/zte/zx_vou.c
@@ -355,17 +355,6 @@ static int zx_crtc_init(struct drm_device *drm, struct
zx_vou_hw *vou,
return 0;
}
-static inline struct drm_crtc *zx_find_crtc(struct drm_device *drm, int pipe)
-{
- struct drm_crtc *crtc;
-
- list_for_each_entry(crtc, &drm->mode_config.crtc_list, head)
- if (crtc->index == pipe)
- return crtc;
-
- return NULL;
-}
-
int zx_vou_enable_vblank(struct drm_device *drm, unsigned int pipe)
{
struct drm_crtc *crtc;
@@ -373,7 +362,7 @@ int zx_vou_enable_vblank(struct drm_device *drm, unsigned
int pipe)
struct zx_vou_hw *vou;
u32 int_frame_mask;
- crtc = zx_find_crtc(drm, pipe);
+ crtc = drm_crtc_from_index(drm, pipe);
if (!crtc)
return 0;
@@ -393,7 +382,7 @@ void zx_vou_disable_vblank(struct drm_device *drm, unsigned
int pipe)
struct zx_crtc *zcrtc;
struct zx_vou_hw *vou;
- crtc = zx_find_crtc(drm, pipe);
+ crtc = drm_crtc_from_index(drm, pipe);
if (!crtc)
return;
--
1.9.1
[PATCH 0/3] Add CRTC helper drm_crtc_from_index()
From: Shawn Guo This is a suggestion from Sean Paul. ZTE and Rockchip DRM drivers have the similar code to find registered CRTC by given index. The series create a CRTC helper drm_crtc_from_index() to do the job, just like drm_plane_from_index() to search plane, and change ZTE, Rockchip driver to use the helper. Shawn Guo (3): drm: add crtc helper drm_crtc_from_index() drm: zte: use crtc helper drm_crtc_from_index() drm: rockchip: use crtc helper drm_crtc_from_index() drivers/gpu/drm/drm_crtc.c | 20 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 17 ++--- drivers/gpu/drm/zte/zx_vou.c| 15 ++- include/drm/drm_crtc.h | 1 + 4 files changed, 25 insertions(+), 28 deletions(-) -- 1.9.1
[PATCH 3/3] drm: rockchip: use crtc helper drm_crtc_from_index()
From: Shawn Guo
Function rockchip_crtc_from_pipe() does the exactly same thing as what
crtc helper drm_crtc_from_index() provides. Use the helper to save
some code.
Signed-off-by: Shawn Guo
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 17 ++---
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 2390c8577617..c30d649cb147 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -99,24 +99,11 @@ void rockchip_unregister_crtc_funcs(struct drm_crtc *crtc)
priv->crtc_funcs[pipe] = NULL;
}
-static struct drm_crtc *rockchip_crtc_from_pipe(struct drm_device *drm,
- int pipe)
-{
- struct drm_crtc *crtc;
- int i = 0;
-
- list_for_each_entry(crtc, &drm->mode_config.crtc_list, head)
- if (i++ == pipe)
- return crtc;
-
- return NULL;
-}
-
static int rockchip_drm_crtc_enable_vblank(struct drm_device *dev,
unsigned int pipe)
{
struct rockchip_drm_private *priv = dev->dev_private;
- struct drm_crtc *crtc = rockchip_crtc_from_pipe(dev, pipe);
+ struct drm_crtc *crtc = drm_crtc_from_index(dev, pipe);
if (crtc && priv->crtc_funcs[pipe] &&
priv->crtc_funcs[pipe]->enable_vblank)
@@ -129,7 +116,7 @@ static void rockchip_drm_crtc_disable_vblank(struct
drm_device *dev,
unsigned int pipe)
{
struct rockchip_drm_private *priv = dev->dev_private;
- struct drm_crtc *crtc = rockchip_crtc_from_pipe(dev, pipe);
+ struct drm_crtc *crtc = drm_crtc_from_index(dev, pipe);
if (crtc && priv->crtc_funcs[pipe] &&
priv->crtc_funcs[pipe]->enable_vblank)
--
1.9.1
[PATCH 1/2] drm/printer: add debug printer
On Wed, Dec 28, 2016 at 05:42:09PM +0100, Daniel Vetter wrote:
> Useful for dumping lots of data into dmesg, e.g. drm_mm.
>
> Cc: Rob Clark
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_print.c | 6 ++
> include/drm/drm_print.h | 20 ++--
> 2 files changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
> index ad3caaa1f48b..a8300cd2d3b3 100644
> --- a/drivers/gpu/drm/drm_print.c
> +++ b/drivers/gpu/drm/drm_print.c
> @@ -40,6 +40,12 @@ void __drm_printfn_info(struct drm_printer *p, struct
> va_format *vaf)
> }
> EXPORT_SYMBOL(__drm_printfn_info);
>
> +void __drm_printfn_debug(struct drm_printer *p, struct va_format *vaf)
> +{
> + pr_debug("%s %pV", p->prefix, vaf);
> +}
> +EXPORT_SYMBOL(__drm_printfn_info);
Ahem.
> +
> /**
> * drm_printf - print to a &drm_printer stream
> * @p: the &drm_printer
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index 1adf84aea622..e9d0ba20089c 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -60,19 +60,20 @@
>
> /**
> * struct drm_printer - drm output "stream"
> - * @printfn: actual output fxn
> - * @arg: output fxn specific data
> *
> * Do not use struct members directly. Use drm_printer_seq_file(),
> * drm_printer_info(), etc to initialize. And drm_printf() for output.
> */
> struct drm_printer {
> + /* private: */
> void (*printfn)(struct drm_printer *p, struct va_format *vaf);
> void *arg;
> + const char *prefix;
> };
>
> void __drm_printfn_seq_file(struct drm_printer *p, struct va_format *vaf);
> void __drm_printfn_info(struct drm_printer *p, struct va_format *vaf);
> +void __drm_printfn_debug(struct drm_printer *p, struct va_format *vaf);
>
> void drm_printf(struct drm_printer *p, const char *f, ...);
>
> @@ -109,4 +110,19 @@ static inline struct drm_printer drm_info_printer(struct
> device *dev)
> return p;
> }
>
> +/**
> + * drm_debug_printer - construct a &drm_printer that outputs to pr_debug()
> + * @prefix: debug output prefix
> + *
> + * RETURNS:
> + * The &drm_printer object
> + */
> +static inline struct drm_printer drm_debug_printer(const char *prefix)
> +{
> + struct drm_printer p = {
> + .printfn = __drm_printfn_debug,
> + .prefix = prefix
> + };
> + return p;
> +}
\n
> #endif /* DRM_PRINT_H_ */
I was looking at a single __drm_printfn callback with a
drm_printer.level, but we lose the dynamic debug goodness.
With the EXPORT_SYMBOL fixed,
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
[PATCH] drm: Reduce verbosity level for drm_core_init() debug message
Currently at the end of drm_core_init() we print
[0.735185] [drm] Initialized
which does not provide any user information and is only a breadcrumb for
developers, so reduce it from info to debug.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 2b75ce65d586..25783b99b651 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -929,7 +929,7 @@ static int __init drm_core_init(void)
if (ret < 0)
goto error;
- DRM_INFO("Initialized\n");
+ DRM_DEBUG("Initialized\n");
return 0;
error:
--
2.11.0
[Bug 93809] playing Just Cause causes system crash
https://bugs.freedesktop.org/show_bug.cgi?id=93809 --- Comment #1 from almos --- I tried this again with current sw stack (kernel 4.8.13, libdrm 2.74, mesa 13.1-dev, wine 2.0rc2), and the game ran for 1 hour without crashing the machine, so I guess this is fixed. The performance feels much worse now (around 2-5fps), but with nine the game is playable (but it doesn't draw shadows, and crashes very often). -- 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/20161229/1a3593d8/attachment.html>
[PATCH 0/4] video/exynos/cec: add HDMI state notifier & use in s5p-cec
Hi Hans,
On 2016-12-13 16:08, Hans Verkuil wrote:
> From: Hans Verkuil
>
> This patch series adds the HDMI notifier code, based on Russell's code:
>
> https://patchwork.kernel.org/patch/9277043/
>
> It adds support for it to the exynos_hdmi drm driver, adds support for
> it to the CEC framework and finally adds support to the s5p-cec driver,
> which now can be moved out of staging.
>
> Tested with my Odroid U3 exynos4 devboard.
>
> Comments are welcome. I'd like to get this in for the 4.11 kernel as
> this is a missing piece needed to integrate CEC drivers.
>
> Benjamin, can you look at doing the same notifier integration for your
> st-cec driver as is done for s5p-cec? It would be good to be able to
> move st-cec out of staging at the same time.
Thanks for working on this and taking it from by TODO list! :)
Please add:
Tested-by: Marek Szyprowski
If you plan to send an updated version, please send it also to
linux-samsung-soc at vger.kernel.org, Krzysztof and Inki to get their acks
for the bindings, dtsi and drm parts.
This HDMI notifier framework will probably be also useful for integrating
HDMI audio support for Samsung ASoC driver.
> Regards,
>
> Hans
>
> Hans Verkuil (4):
>video: add HDMI state notifier support
>exynos_hdmi: add HDMI notifier support
>cec: integrate HDMI notifier support
>s5p-cec: add hdmi-notifier support, move out of staging
>
> .../devicetree/bindings/media/s5p-cec.txt | 2 +
> arch/arm/boot/dts/exynos4.dtsi | 1 +
> drivers/gpu/drm/exynos/Kconfig | 1 +
> drivers/gpu/drm/exynos/exynos_hdmi.c | 24 +++-
> drivers/media/cec/cec-core.c | 50
> drivers/media/platform/Kconfig | 18 +++
> drivers/media/platform/Makefile| 1 +
> .../media => media/platform}/s5p-cec/Makefile | 0
> .../platform}/s5p-cec/exynos_hdmi_cec.h| 0
> .../platform}/s5p-cec/exynos_hdmi_cecctrl.c| 0
> .../media => media/platform}/s5p-cec/regs-cec.h| 0
> .../media => media/platform}/s5p-cec/s5p_cec.c | 35 +-
> .../media => media/platform}/s5p-cec/s5p_cec.h | 3 +
> drivers/staging/media/Kconfig | 2 -
> drivers/staging/media/Makefile | 1 -
> drivers/staging/media/s5p-cec/Kconfig | 9 --
> drivers/staging/media/s5p-cec/TODO | 7 --
> drivers/video/Kconfig | 3 +
> drivers/video/Makefile | 1 +
> drivers/video/hdmi-notifier.c | 134
> +
> include/linux/hdmi-notifier.h | 109 +
> include/media/cec.h| 15 +++
> 22 files changed, 389 insertions(+), 27 deletions(-)
> rename drivers/{staging/media => media/platform}/s5p-cec/Makefile (100%)
> rename drivers/{staging/media => media/platform}/s5p-cec/exynos_hdmi_cec.h
> (100%)
> rename drivers/{staging/media =>
> media/platform}/s5p-cec/exynos_hdmi_cecctrl.c (100%)
> rename drivers/{staging/media => media/platform}/s5p-cec/regs-cec.h (100%)
> rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.c (89%)
> rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.h (97%)
> delete mode 100644 drivers/staging/media/s5p-cec/Kconfig
> delete mode 100644 drivers/staging/media/s5p-cec/TODO
> create mode 100644 drivers/video/hdmi-notifier.c
> create mode 100644 include/linux/hdmi-notifier.h
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
[PATCH] drm/amd/amdgpu: fix spelling mistake: "comleted" -> "completed"
From: Colin Ian King
trivial fix to spelling mistake in WARN message
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 60bd4af..9ca3167 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2335,7 +2335,7 @@ int amdgpu_gpu_reset(struct amdgpu_device *adev)
if (fence) {
r = dma_fence_wait(fence, false);
if (r) {
- WARN(r, "recovery from shadow
isn't comleted\n");
+ WARN(r, "recovery from shadow
isn't completed\n");
break;
}
}
@@ -2347,7 +2347,7 @@ int amdgpu_gpu_reset(struct amdgpu_device *adev)
if (fence) {
r = dma_fence_wait(fence, false);
if (r)
- WARN(r, "recovery from shadow isn't
comleted\n");
+ WARN(r, "recovery from shadow isn't
completed\n");
}
dma_fence_put(fence);
}
--
2.10.2
[PATCH] drm/nouveau/bios: fix spelling mistake: "INIT_GENERIC_CONDITON" -> "INIT_GENERIC_CONDITION"
From: Colin Ian King
trivial fix to spelling mistake in warn message
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
index 38ed09f..1068e6a 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
@@ -828,7 +828,7 @@ init_generic_condition(struct nvbios_init *init)
init_exec_set(init, false);
break;
default:
- warn("INIT_GENERIC_CONDITON: unknown 0x%02x\n", cond);
+ warn("INIT_GENERIC_CONDITION: unknown 0x%02x\n", cond);
init->offset += size;
break;
}
--
2.10.2
[PATCH] drm: clean cached display info
Thanks for the review, Jose.
Regards
Shashank
-Original Message-
From: Jose Abreu [mailto:jose.ab...@synopsys.com]
Sent: Thursday, December 29, 2016 11:05 PM
To: Sharma, Shashank ; dri-devel at
lists.freedesktop.org; intel-gfx at lists.freedesktop.org
Cc: Jose Abreu ; Daniel Vetter
Subject: Re: [PATCH] drm: clean cached display info
Hi Shashank,
On 29-12-2016 12:28, Shashank Sharma wrote:
> This patch adds a small helper function, which clears the cached
> information about a hot-pluggable display, from connector. On event
> This will run on event of a hot-unplug, keeping the connector's
> display info up-to-date, avoiding any errors due to invalid cached data.
>
> Forking this patch out from the 3 patch series:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.freedes
> ktop.org_patch_128961_&d=DgIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=yaVFU4TjGY0
> gVF8El1uKcisy6TPsyCl9uN7Wsis-qhY&m=wGqvHYK00VvbUVGun4-ZhK6KZ4Ht_lHwPGf
> C6ajlzxE&s=7YpJD-fwUixHNz9SNn2B1ijuL5mEVeEUmolbf3NqWcs&e=
> (still under review) and sending as individual patch.
>
> Cc: Jose Abreu
> Cc: Daniel Vetter
>
> Suggested-by: Jose Abreu
> Signed-off-by: Shashank Sharma
> ---
Reviewed-by: Jose Abreu
Best regards,
Jose Miguel Abreu
> drivers/gpu/drm/drm_probe_helper.c | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index 7cff91e..65a6a1f 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -164,6 +164,18 @@ void drm_kms_helper_poll_enable_locked(struct
> drm_device *dev) }
>
> /**
> + * drm_helper_clear_display_info - clean cached display information
> +for
> + * hot pluggable displays, on event of hot-unplug
> + * @connector: connector under event
> + */
> +void drm_helper_clear_display_info(struct drm_connector *connector) {
> + struct drm_display_info *info = &connector->display_info;
> +
> + memset(info, 0, sizeof(*info));
> +}
> +
> +/**
> * drm_helper_probe_single_connector_modes - get complete set of display
> modes
> * @connector: connector to probe
> * @maxX: max width for modes
> @@ -288,6 +300,16 @@ int drm_helper_probe_single_connector_modes(struct
> drm_connector *connector,
> DRM_DEBUG_KMS("[CONNECTOR:%d:%s] disconnected\n",
> connector->base.id, connector->name);
> drm_mode_connector_update_edid_property(connector, NULL);
> +
> + /*
> + * Connector status change to disconnected, time to clean
> + * cached display information.
> + * Any driver which doesn't use this probe_helper function
> + * should implement update of EDID property and display_info
> + * on its own.
> + */
> + drm_helper_clear_display_info(connector);
> +
> verbose_prune = false;
> goto prune;
> }
[Bug 99219] The Stanley Parable GPU hang when starting a new game
https://bugs.freedesktop.org/show_bug.cgi?id=99219 --- Comment #1 from Christoph Haag --- Created attachment 128688 --> https://bugs.freedesktop.org/attachment.cgi?id=128688&action=edit full dmesg Apparently this didn't attach correctly when I created the bug. -- 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/20161229/46765e60/attachment-0001.html>
[PATCH 01/17] drm/docs: Small cleanup in drm-uapi.rst
- Remove the outdated hunk about driver documentation which somehow got misplaced here in the split-up. - Collect all the testing&validation stuff together and give the CRC section a heading for prettier output. Cc: Tomeu Vizoso Cc: Jani Nikula Signed-off-by: Daniel Vetter --- Documentation/gpu/drm-uapi.rst | 25 +++-- 1 file changed, 11 insertions(+), 14 deletions(-) diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index de3ac9f90f8f..fcc228ef5bc4 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -156,8 +156,12 @@ other hand, a driver requires shared state between clients which is visible to user-space and accessible beyond open-file boundaries, they cannot support render nodes. + +Testing and validation +== + Validating changes with IGT -=== +--- There's a collection of tests that aims to cover the whole functionality of DRM drivers and that can be used to check that changes to DRM drivers or the @@ -193,6 +197,12 @@ run-tests.sh is a wrapper around piglit that will execute the tests matching the -t options. A report in HTML format will be available in ./results/html/index.html. Results can be compared with piglit. +Display CRC Support +--- + +.. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c + :doc: CRC ABI + VBlank event handling = @@ -209,16 +219,3 @@ DRM_IOCTL_MODESET_CTL mode setting, since on many devices the vertical blank counter is reset to 0 at some point during modeset. Modern drivers should not call this any more since with kernel mode setting it is a no-op. - -This second part of the GPU Driver Developer's Guide documents driver -code, implementation details and also all the driver-specific userspace -interfaces. Especially since all hardware-acceleration interfaces to -userspace are driver specific for efficiency and other reasons these -interfaces can be rather substantial. Hence every driver has its own -chapter. - -Testing and validation -== - -.. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c - :doc: CRC ABI -- 2.7.4
[PATCH 09/17] drm/rect: Fix formatting of example code
Drive-by polish. Cc: Ville Syrjälä Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_rect.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c index e6057d8cdcd5..bc5575960ebc 100644 --- a/drivers/gpu/drm/drm_rect.c +++ b/drivers/gpu/drm/drm_rect.c @@ -371,10 +371,10 @@ EXPORT_SYMBOL(drm_rect_rotate); * to the vertical axis of the original untransformed * coordinate space, so that you never have to flip * them when doing a rotatation and its inverse. - * That is, if you do: + * That is, if you do :: * - * drm_rotate(&r, width, height, rotation); - * drm_rotate_inv(&r, width, height, rotation); + * drm_rotate(&r, width, height, rotation); + * drm_rotate_inv(&r, width, height, rotation); * * you will always get back the original rectangle. */ -- 2.7.4
[PATCH 04/17] dma-buf: use preferred struct reference in kernel-doc
sed -e 's/\( \* .*\)struct &\([_a-z]*\)/\1\&struct \2/' -i
Originally I wasnt a friend of this style because I thought a
line-break between the "&struct" and "foo" part would break it. But a
quick test shows that " * &struct \n * foo\n" works pefectly well with
current kernel-doc. So time to mass-apply these changes!
Cc: Sumit Semwal
Cc: Jani Nikula
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/dma-buf/dma-buf.c | 6 +++---
include/linux/dma-buf.h | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 91aff74ed092..ab814aff0a5b 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -128,7 +128,7 @@ static loff_t dma_buf_llseek(struct file *file, loff_t
offset, int whence)
* DOC: fence polling
*
* To support cross-device and cross-driver synchronization of buffer access
- * implicit fences (represented internally in the kernel with struct &fence)
can
+ * implicit fences (represented internally in the kernel with &struct fence)
can
* be attached to a &dma_buf. The glue for that and a few related things are
* provided in the &reservation_object structure.
*
@@ -373,7 +373,7 @@ static inline int is_dma_buf_file(struct file *file)
* Additionally, provide a name string for exporter; useful in debugging.
*
* @exp_info: [in]holds all the export related information provided
- * by the exporter. see struct &dma_buf_export_info
+ * by the exporter. see &struct dma_buf_export_info
* for further details.
*
* Returns, on success, a newly created dma_buf object, which wraps the
@@ -517,7 +517,7 @@ EXPORT_SYMBOL_GPL(dma_buf_get);
*
* If, as a result of this call, the refcount becomes 0, the 'release' file
* operation related to this fd is called. It calls the release operation of
- * struct &dma_buf_ops in turn, and frees the memory allocated for dmabuf when
+ * &struct dma_buf_ops in turn, and frees the memory allocated for dmabuf when
* exported.
*/
void dma_buf_put(struct dma_buf *dmabuf)
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 57828154e440..4d61fc55278b 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -278,7 +278,7 @@ struct dma_buf_ops {
* Shared dma buffers are reference counted using dma_buf_put() and
* get_dma_buf().
*
- * Device DMA access is handled by the separate struct &dma_buf_attachment.
+ * Device DMA access is handled by the separate &struct dma_buf_attachment.
*/
struct dma_buf {
size_t size;
@@ -355,7 +355,7 @@ struct dma_buf_export_info {
* DEFINE_DMA_BUF_EXPORT_INFO - helper macro for exporters
* @name: export-info name
*
- * DEFINE_DMA_BUF_EXPORT_INFO macro defines the struct &dma_buf_export_info,
+ * DEFINE_DMA_BUF_EXPORT_INFO macro defines the &struct dma_buf_export_info,
* zeroes it out and pre-populates exp_name in it.
*/
#define DEFINE_DMA_BUF_EXPORT_INFO(name) \
--
2.7.4
[PATCH 02/17] drm/doc: link style-guide to doc-guide
Our style guide should only be the delta compared to the overall one. Cc: Chris Wilson Signed-off-by: Daniel Vetter --- Documentation/gpu/introduction.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/gpu/introduction.rst b/Documentation/gpu/introduction.rst index 1903595b5310..6960e31f71e1 100644 --- a/Documentation/gpu/introduction.rst +++ b/Documentation/gpu/introduction.rst @@ -49,3 +49,5 @@ section name should be all upper-case or not, and whether it should end in a colon or not. Go with the file-local style. Other common section names are "Notes" with information for dangerous or tricky corner cases, and "FIXME" where the interface could be cleaned up. + +Also read the :ref:`guidelines for the kernel documentation at large `. -- 2.7.4
[PATCH 15/17] drm/kms-core: Use recommened kerneldoc for struct member refs
I just learned that &struct_name.member_name works and looks pretty even. It doesn't (yet) link to the member directly though, which would be really good for big structures or vfunc tables (where the per-member kerneldoc tends to be long). Also some minor drive-by polish where it makes sense, I read a lot of docs ... Cc: Jani Nikula Cc: Chris Wilson Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_atomic.c| 71 ++--- drivers/gpu/drm/drm_blend.c | 11 +++--- drivers/gpu/drm/drm_connector.c | 12 +++ drivers/gpu/drm/drm_crtc.c | 7 ++-- drivers/gpu/drm/drm_dumb_buffers.c | 4 +-- drivers/gpu/drm/drm_encoder.c | 2 +- drivers/gpu/drm/drm_encoder_slave.c | 2 +- drivers/gpu/drm/drm_framebuffer.c | 10 +++--- drivers/gpu/drm/drm_modeset_lock.c | 10 +++--- drivers/gpu/drm/drm_plane.c | 2 +- drivers/gpu/drm/drm_property.c | 2 +- include/drm/drm_atomic.h| 6 ++-- include/drm/drm_color_mgmt.h| 2 +- include/drm/drm_connector.h | 40 ++--- include/drm/drm_crtc.h | 29 +++ include/drm/drm_framebuffer.h | 15 include/drm/drm_mode_config.h | 12 +++ include/drm/drm_mode_object.h | 13 --- include/drm/drm_modeset_lock.h | 2 +- include/drm/drm_plane.h | 18 +- include/drm/drm_property.h | 8 ++--- 21 files changed, 141 insertions(+), 137 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 681d5f97639d..eea7e15bb1cf 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -200,8 +200,8 @@ EXPORT_SYMBOL(drm_atomic_state_default_clear); * all locks. So someone else could sneak in and change the current modeset * configuration. Which means that all the state assembled in @state is no * longer an atomic update to the current state, but to some arbitrary earlier - * state. Which could break assumptions the driver's ->atomic_check likely - * relies on. + * state. Which could break assumptions the driver's + * &drm_mode_config_funcs.atomic_check likely relies on. * * Hence we must clear all cached state and completely start over, using this * function. @@ -461,11 +461,10 @@ drm_atomic_replace_property_blob_from_id(struct drm_crtc *crtc, * @property: the property to set * @val: the new property value * - * Use this instead of calling crtc->atomic_set_property directly. - * This function handles generic/core properties and calls out to - * driver's ->atomic_set_property() for driver properties. To ensure - * consistent behavior you must call this function rather than the - * driver hook directly. + * This function handles generic/core properties and calls out to driver's + * &drm_crtc_funcs.atomic_set_property for driver properties. To ensure + * consistent behavior you must call this function rather than the driver hook + * directly. * * RETURNS: * Zero on success, error code on failure @@ -537,10 +536,10 @@ EXPORT_SYMBOL(drm_atomic_crtc_set_property); * @property: the property to set * @val: return location for the property value * - * This function handles generic/core properties and calls out to - * driver's ->atomic_get_property() for driver properties. To ensure - * consistent behavior you must call this function rather than the - * driver hook directly. + * This function handles generic/core properties and calls out to driver's + * &drm_crtc_funcs.atomic_get_property for driver properties. To ensure + * consistent behavior you must call this function rather than the driver hook + * directly. * * RETURNS: * Zero on success, error code on failure @@ -721,11 +720,10 @@ EXPORT_SYMBOL(drm_atomic_get_plane_state); * @property: the property to set * @val: the new property value * - * Use this instead of calling plane->atomic_set_property directly. - * This function handles generic/core properties and calls out to - * driver's ->atomic_set_property() for driver properties. To ensure - * consistent behavior you must call this function rather than the - * driver hook directly. + * This function handles generic/core properties and calls out to driver's + * &drm_plane_funcs.atomic_set_property for driver properties. To ensure + * consistent behavior you must call this function rather than the driver hook + * directly. * * RETURNS: * Zero on success, error code on failure @@ -796,10 +794,10 @@ EXPORT_SYMBOL(drm_atomic_plane_set_property); * @property: the property to set * @val: return location for the property value * - * This function handles generic/core properties and calls out to - * driver's ->atomic_get_property() for driver properties. To ensure - * consistent behavior you must call this function rather than the - * driver hook directly. + * This function handles generic/core properties and calls out to driver's + * &drm_plane_funcs.atomic_get_property for drive
[PATCH 14/17] drm/cma-helpers: Use recommened kerneldoc for struct member refs
I just learned that &struct_name.member_name works and looks pretty
even. It doesn't (yet) link to the member directly though, which would
be really good for big structures or vfunc tables (where the
per-member kerneldoc tends to be long).
Also some minor drive-by polish where it makes sense, I read a lot
of docs ...
Cc: Laurent Pinchart
Cc: Jani Nikula
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_cma_helper.c | 24
drivers/gpu/drm/drm_gem_cma_helper.c | 16
2 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index ec081727cd5a..0a0ac77b464b 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -48,14 +48,14 @@ struct drm_fbdev_cma {
* Provides helper functions for creating a cma (contiguous memory allocator)
* backed framebuffer.
*
- * drm_fb_cma_create() is used in the &drm_mode_config_funcs ->fb_create
+ * drm_fb_cma_create() is used in the &drm_mode_config_funcs.fb_create
* callback function to create a cma backed framebuffer.
*
* An fbdev framebuffer backed by cma is also available by calling
* drm_fbdev_cma_init(). drm_fbdev_cma_fini() tears it down.
- * If the &drm_framebuffer_funcs ->dirty callback is set, fb_deferred_io
- * will be set up automatically. dirty() is called by
- * drm_fb_helper_deferred_io() in process context (struct delayed_work).
+ * If the &drm_framebuffer_funcs.dirty callback is set, fb_deferred_io will be
+ * set up automatically. &drm_framebuffer_funcs.dirty is called by
+ * drm_fb_helper_deferred_io() in process context (&struct delayed_work).
*
* Example fbdev deferred io code::
*
@@ -155,16 +155,16 @@ static struct drm_fb_cma *drm_fb_cma_alloc(struct
drm_device *dev,
/**
* drm_fb_cma_create_with_funcs() - helper function for the
- * &drm_mode_config_funcs ->fb_create
- * callback function
+ * &drm_mode_config_funcs.fb_create
+ * callback
* @dev: DRM device
* @file_priv: drm file for the ioctl call
* @mode_cmd: metadata from the userspace fb creation request
* @funcs: vtable to be used for the new framebuffer object
*
* This can be used to set &drm_framebuffer_funcs for drivers that need the
- * dirty() callback. Use drm_fb_cma_create() if you don't need to change
- * &drm_framebuffer_funcs.
+ * &drm_framebuffer_funcs.dirty callback. Use drm_fb_cma_create() if you don't
+ * need to change &drm_framebuffer_funcs.
*/
struct drm_framebuffer *drm_fb_cma_create_with_funcs(struct drm_device *dev,
struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd,
@@ -221,14 +221,14 @@ struct drm_framebuffer
*drm_fb_cma_create_with_funcs(struct drm_device *dev,
EXPORT_SYMBOL_GPL(drm_fb_cma_create_with_funcs);
/**
- * drm_fb_cma_create() - &drm_mode_config_funcs ->fb_create callback function
+ * drm_fb_cma_create() - &drm_mode_config_funcs.fb_create callback function
* @dev: DRM device
* @file_priv: drm file for the ioctl call
* @mode_cmd: metadata from the userspace fb creation request
*
* If your hardware has special alignment or pitch requirements these should be
* checked before calling this function. Use drm_fb_cma_create_with_funcs() if
- * you need to set &drm_framebuffer_funcs ->dirty.
+ * you need to set &drm_framebuffer_funcs.dirty.
*/
struct drm_framebuffer *drm_fb_cma_create(struct drm_device *dev,
struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd)
@@ -264,7 +264,7 @@ EXPORT_SYMBOL_GPL(drm_fb_cma_get_gem_obj);
* @plane: Which plane
* @state: Plane state attach fence to
*
- * This should be put into prepare_fb hook of &struct drm_plane_helper_funcs .
+ * This should be set as the &struct drm_plane_helper_funcs.prepare_fb hook.
*
* This function checks if the plane FB has an dma-buf attached, extracts
* the exclusive fence and attaches it to plane state for the atomic helper
@@ -491,7 +491,7 @@ static const struct drm_fb_helper_funcs
drm_fb_cma_helper_funcs = {
* @preferred_bpp: Preferred bits per pixel for the device
* @num_crtc: Number of CRTCs
* @max_conn_count: Maximum number of connectors
- * @funcs: fb helper functions, in particular fb_probe()
+ * @funcs: fb helper functions, in particular a custom dirty() callback
*
* Returns a newly allocated drm_fbdev_cma struct or a ERR_PTR.
*/
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 1d6c335584ec..6ec2d8096b2c 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -177,7 +177,7 @@ drm_gem_cma_create_with_handle(struct drm_file *file_priv,
* This function frees the backing memory of the CMA GEM object, cleans up the
* GEM object state and frees the memory used to store the object it
[PATCH 06/17] drm/doc: use preferred struct reference in kernel-doc
sed -e 's/\( \* .*\)struct &\([_a-z]*\)/\1\&struct \2/' -i Originally I wasnt a friend of this style because I thought a line-break between the "&struct" and "foo" part would break it. But a quick test shows that " * &struct \n * foo\n" works pefectly well with current kernel-doc. So time to mass-apply these changes! Cc: Jani Nikula Cc: Chris Wilson Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_atomic.c | 6 +++--- drivers/gpu/drm/drm_atomic_helper.c | 8 drivers/gpu/drm/drm_auth.c | 8 drivers/gpu/drm/drm_bridge.c | 4 ++-- drivers/gpu/drm/drm_color_mgmt.c | 4 ++-- drivers/gpu/drm/drm_connector.c | 2 +- drivers/gpu/drm/drm_crtc_helper.c| 14 +++--- drivers/gpu/drm/drm_drv.c| 10 +- drivers/gpu/drm/drm_dumb_buffers.c | 2 +- drivers/gpu/drm/drm_encoder.c| 4 ++-- drivers/gpu/drm/drm_fb_cma_helper.c | 2 +- drivers/gpu/drm/drm_framebuffer.c| 6 +++--- drivers/gpu/drm/drm_irq.c| 2 +- drivers/gpu/drm/drm_plane.c | 2 +- drivers/gpu/drm/drm_plane_helper.c | 2 +- drivers/gpu/drm/drm_probe_helper.c | 2 +- drivers/gpu/drm/drm_property.c | 2 +- drivers/gpu/drm/drm_simple_kms_helper.c | 2 +- include/drm/drm_atomic.h | 2 +- include/drm/drm_auth.h | 2 +- include/drm/drm_bridge.h | 8 include/drm/drm_connector.h | 10 +- include/drm/drm_crtc.h | 8 include/drm/drm_fb_helper.h | 2 +- include/drm/drm_framebuffer.h| 6 +++--- include/drm/drm_irq.h| 4 ++-- include/drm/drm_mode_config.h| 10 +- include/drm/drm_modeset_helper_vtables.h | 2 +- include/drm/drm_plane.h | 4 ++-- include/drm/drm_print.h | 4 ++-- include/drm/drm_simple_kms_helper.h | 8 31 files changed, 76 insertions(+), 76 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index b1b54011a92c..681d5f97639d 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -1882,7 +1882,7 @@ EXPORT_SYMBOL(drm_atomic_clean_old_fb); * As a contrast, with implicit fencing the kernel keeps track of any * ongoing rendering, and automatically ensures that the atomic update waits * for any pending rendering to complete. For shared buffers represented with - * a struct &dma_buf this is tracked in &reservation_object structures. + * a &struct dma_buf this is tracked in &reservation_object structures. * Implicit syncing is how Linux traditionally worked (e.g. DRI2/3 on X.org), * whereas explicit fencing is what Android wants. * @@ -1898,7 +1898,7 @@ EXPORT_SYMBOL(drm_atomic_clean_old_fb); * it will only check if the Sync File is a valid one. * * On the driver side the fence is stored on the @fence parameter of - * struct &drm_plane_state. Drivers which also support implicit fencing + * &struct drm_plane_state. Drivers which also support implicit fencing * should set the implicit fence using drm_atomic_set_fence_for_plane(), * to make sure there's consistent behaviour between drivers in precedence * of implicit vs. explicit fencing. @@ -1917,7 +1917,7 @@ EXPORT_SYMBOL(drm_atomic_clean_old_fb); * DRM_MODE_ATOMIC_TEST_ONLY flag the out fence will also be set to -1. * * Note that out-fences don't have a special interface to drivers and are - * internally represented by a struct &drm_pending_vblank_event in struct + * internally represented by a &struct drm_pending_vblank_event in struct * &drm_crtc_state, which is also used by the nonblocking atomic commit * helpers and for the DRM event handling for existing userspace. */ diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 799c1564a4f8..8eab8944c736 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -56,9 +56,9 @@ * implement these functions themselves but must use the provided helpers. * * The atomic helper uses the same function table structures as all other - * modesetting helpers. See the documentation for struct &drm_crtc_helper_funcs, - * struct &drm_encoder_helper_funcs and struct &drm_connector_helper_funcs. It - * also shares the struct &drm_plane_helper_funcs function table with the plane + * modesetting helpers. See the documentation for &struct drm_crtc_helper_funcs, + * struct &drm_encoder_helper_funcs and &struct drm_connector_helper_funcs. It + * also shares the &struct drm_plane_helper_funcs function table with the plane * helpers. */ static void @@ -1369,7 +1369,7 @@ static int stall_checks(struct drm_crtc *crtc, bool nonblock) * actually committing the hardware state, and for nonblocking commits this call
[PATCH 05/17] dma-buf: Use recommended structure member reference
I just learned that &struct_name.member_name works and looks pretty
even. It doesn't (yet) link to the member directly though, which would
be really good for big structures or vfunc tables (where the
per-member kerneldoc tends to be long).
Cc: Sumit Semwal
Cc: Jani Nikula
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/dma-buf/dma-buf.c | 5 ++---
include/linux/dma-buf.h | 6 +++---
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index ab814aff0a5b..718f832a5c71 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -516,9 +516,8 @@ EXPORT_SYMBOL_GPL(dma_buf_get);
* Uses file's refcounting done implicitly by fput().
*
* If, as a result of this call, the refcount becomes 0, the 'release' file
- * operation related to this fd is called. It calls the release operation of
- * &struct dma_buf_ops in turn, and frees the memory allocated for dmabuf when
- * exported.
+ * operation related to this fd is called. It calls &dma_buf_ops.release vfunc
+ * in turn, and frees the memory allocated for dmabuf when exported.
*/
void dma_buf_put(struct dma_buf *dmabuf)
{
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 4d61fc55278b..bfb3704fc6fc 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -66,8 +66,8 @@ struct dma_buf_ops {
* is not the case, and the allocation cannot be moved, it should also
* fail the attach operation.
*
-* Any exporter-private housekeeping data can be stored in the priv
-* pointer of &dma_buf_attachment structure.
+* Any exporter-private housekeeping data can be stored in the
+* &dma_buf_attachment.priv pointer.
*
* This callback is optional.
*
@@ -106,7 +106,7 @@ struct dma_buf_ops {
*
* Note that any specific buffer attributes required for this function
* should get added to device_dma_parameters accessible via
-* device->dma_params from the &dma_buf_attachment. The @attach callback
+* &device.dma_params from the &dma_buf_attachment. The @attach callback
* should also check these constraints.
*
* If this is being called for the first time, the exporter can now
--
2.7.4
[PATCH 10/17] drm/atomic-helpers: Remove outdated comment
We forgot to clean this up when adding connector refcounting.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 8eab8944c736..5e5224460042 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3286,11 +3286,6 @@ EXPORT_SYMBOL(drm_atomic_helper_duplicate_state);
void
__drm_atomic_helper_connector_destroy_state(struct drm_connector_state *state)
{
- /*
-* This is currently a placeholder so that drivers that subclass the
-* state will automatically do the right thing if code is ever added
-* to this function.
-*/
if (state->crtc)
drm_connector_unreference(state->connector);
}
--
2.7.4
[PATCH 17/17] drm/core: Use recommened kerneldoc for struct member refs
I just learned that &struct_name.member_name works and looks pretty even. It doesn't (yet) link to the member directly though, which would be really good for big structures or vfunc tables (where the per-member kerneldoc tends to be long). Also some minor drive-by polish where it makes sense, I read a lot of docs ... Cc: Jani Nikula Cc: Chris Wilson Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_auth.c | 4 ++-- drivers/gpu/drm/drm_drv.c | 8 drivers/gpu/drm/drm_fops.c | 11 ++- drivers/gpu/drm/drm_irq.c | 10 +- drivers/gpu/drm/drm_pci.c | 2 +- drivers/gpu/drm/drm_platform.c | 2 +- drivers/gpu/drm/drm_sysfs.c| 2 +- include/drm/drm_auth.h | 12 ++-- include/drm/drm_drv.h | 2 +- include/drm/drm_irq.h | 4 ++-- 10 files changed, 29 insertions(+), 28 deletions(-) diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c index 860cfe124c2a..7ff697389d74 100644 --- a/drivers/gpu/drm/drm_auth.c +++ b/drivers/gpu/drm/drm_auth.c @@ -40,8 +40,8 @@ * least once successfully became the device master (either through the * SET_MASTER IOCTL, or implicitly through opening the primary device node when * no one else is the current master that time) there exists one &drm_master. - * This is noted in the is_master member of &drm_file. All other clients have - * just a pointer to the &drm_master they are associated with. + * This is noted in &drm_file.is_master. All other clients have just a pointer + * to the &drm_master they are associated with. * * In addition only one &drm_master can be the current master for a &drm_device. * It can be switched through the DROP_MASTER and SET_MASTER IOCTL, or diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index f8de5804c37c..720427aad1d4 100644 --- a/drivers/gpu/drm/drm_drv.c +++ b/drivers/gpu/drm/drm_drv.c @@ -309,7 +309,7 @@ void drm_minor_release(struct drm_minor *minor) * userspace the device instance can be published using drm_dev_register(). * * There is also deprecated support for initalizing device instances using - * bus-specific helpers and the ->load() callback. But due to + * bus-specific helpers and the &drm_driver.load callback. But due to * backwards-compatibility needs the device instance have to be published too * early, which requires unpretty global locking to make safe and is therefore * only support for existing drivers not yet converted to the new scheme. @@ -718,9 +718,9 @@ static void remove_compat_control_link(struct drm_device *dev) * Never call this twice on any device! * * NOTE: To ensure backward compatibility with existing drivers method this - * function calls the ->load() method after registering the device nodes, - * creating race conditions. Usage of the ->load() methods is therefore - * deprecated, drivers must perform all initialization before calling + * function calls the &drm_driver.load method after registering the device + * nodes, creating race conditions. Usage of the &drm_driver.load methods is + * therefore deprecated, drivers must perform all initialization before calling * drm_dev_register(). * * RETURNS: diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c index 48e106557c92..c9383ff36b61 100644 --- a/drivers/gpu/drm/drm_fops.c +++ b/drivers/gpu/drm/drm_fops.c @@ -580,7 +580,7 @@ EXPORT_SYMBOL(drm_poll); * kmalloc and @p must be the first member element. * * This is the locked version of drm_event_reserve_init() for callers which - * already hold dev->event_lock. + * already hold &drm_device.event_lock. * * RETURNS: * @@ -621,7 +621,7 @@ EXPORT_SYMBOL(drm_event_reserve_init_locked); * If callers embedded @p into a larger structure it must be allocated with * kmalloc and @p must be the first member element. * - * Callers which already hold dev->event_lock should use + * Callers which already hold &drm_device.event_lock should use * drm_event_reserve_init_locked() instead. * * RETURNS: @@ -677,7 +677,7 @@ EXPORT_SYMBOL(drm_event_cancel_free); * * This function sends the event @e, initialized with drm_event_reserve_init(), * to its associated userspace DRM file. Callers must already hold - * dev->event_lock, see drm_send_event() for the unlocked version. + * &drm_device.event_lock, see drm_send_event() for the unlocked version. * * Note that the core will take care of unlinking and disarming events when the * corresponding DRM file is closed. Drivers need not worry about whether the @@ -717,8 +717,9 @@ EXPORT_SYMBOL(drm_send_event_locked); * @e: DRM event to deliver * * This function sends the event @e, initialized with drm_event_reserve_init(), - * to its associated userspace DRM file. This function acquires dev->event_lock, - * see drm_send_event_locked() for callers which already hold this lock. + * to its associated userspace DRM file. This function acquires + * &drm_device.event_lock, see drm_send_event_lo
[PATCH 13/17] drm/bridge: Use recommened kerneldoc for struct member refs
I just learned that &struct_name.member_name works and looks pretty
even. It doesn't (yet) link to the member directly though, which would
be really good for big structures or vfunc tables (where the
per-member kerneldoc tends to be long).
Also some minor drive-by polish where it makes sense, I read a lot
of docs ...
Cc: Archit Taneja
Cc: Jani Nikula
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_bridge.c | 27 +++--
include/drm/drm_bridge.h | 48 +---
2 files changed, 39 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index ae5e57ad718c..86a7637ba344 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -55,7 +55,7 @@
* just provide additional hooks to get the desired output at the end of the
* encoder chain.
*
- * Bridges can also be chained up using the next pointer in &struct drm_bridge.
+ * Bridges can also be chained up using the &drm_bridge.next pointer.
*
* Both legacy CRTC helpers and the new atomic modeset helpers support bridges.
*/
@@ -179,7 +179,7 @@ void drm_bridge_detach(struct drm_bridge *bridge)
* @mode: desired mode to be set for the bridge
* @adjusted_mode: updated mode that works for this bridge
*
- * Calls ->mode_fixup() &drm_bridge_funcs op for all the bridges in the
+ * Calls &drm_bridge_funcs.mode_fixup for all the bridges in the
* encoder chain, starting from the first bridge to the last.
*
* Note: the bridge passed should be the one closest to the encoder
@@ -206,11 +206,10 @@ bool drm_bridge_mode_fixup(struct drm_bridge *bridge,
EXPORT_SYMBOL(drm_bridge_mode_fixup);
/**
- * drm_bridge_disable - calls ->disable() &drm_bridge_funcs op for all
- * bridges in the encoder chain.
+ * drm_bridge_disable - disables all bridges in the encoder chain
* @bridge: bridge control structure
*
- * Calls ->disable() &drm_bridge_funcs op for all the bridges in the encoder
+ * Calls &drm_bridge_funcs.disable op for all the bridges in the encoder
* chain, starting from the last bridge to the first. These are called before
* calling the encoder's prepare op.
*
@@ -229,11 +228,10 @@ void drm_bridge_disable(struct drm_bridge *bridge)
EXPORT_SYMBOL(drm_bridge_disable);
/**
- * drm_bridge_post_disable - calls ->post_disable() &drm_bridge_funcs op for
- * all bridges in the encoder chain.
+ * drm_bridge_post_disable - cleans up after disabling all bridges in the
encoder chain
* @bridge: bridge control structure
*
- * Calls ->post_disable() &drm_bridge_funcs op for all the bridges in the
+ * Calls &drm_bridge_funcs.post_disable op for all the bridges in the
* encoder chain, starting from the first bridge to the last. These are called
* after completing the encoder's prepare op.
*
@@ -258,7 +256,7 @@ EXPORT_SYMBOL(drm_bridge_post_disable);
* @mode: desired mode to be set for the bridge
* @adjusted_mode: updated mode that works for this bridge
*
- * Calls ->mode_set() &drm_bridge_funcs op for all the bridges in the
+ * Calls &drm_bridge_funcs.mode_set op for all the bridges in the
* encoder chain, starting from the first bridge to the last.
*
* Note: the bridge passed should be the one closest to the encoder
@@ -278,11 +276,11 @@ void drm_bridge_mode_set(struct drm_bridge *bridge,
EXPORT_SYMBOL(drm_bridge_mode_set);
/**
- * drm_bridge_pre_enable - calls ->pre_enable() &drm_bridge_funcs op for all
- *bridges in the encoder chain.
+ * drm_bridge_pre_enable - prepares for enabling all
+ *bridges in the encoder chain
* @bridge: bridge control structure
*
- * Calls ->pre_enable() &drm_bridge_funcs op for all the bridges in the encoder
+ * Calls &drm_bridge_funcs.pre_enable op for all the bridges in the encoder
* chain, starting from the last bridge to the first. These are called
* before calling the encoder's commit op.
*
@@ -301,11 +299,10 @@ void drm_bridge_pre_enable(struct drm_bridge *bridge)
EXPORT_SYMBOL(drm_bridge_pre_enable);
/**
- * drm_bridge_enable - calls ->enable() &drm_bridge_funcs op for all bridges
- *in the encoder chain.
+ * drm_bridge_enable - enables all bridges in the encoder chain
* @bridge: bridge control structure
*
- * Calls ->enable() &drm_bridge_funcs op for all the bridges in the encoder
+ * Calls &drm_bridge_funcs.enable op for all the bridges in the encoder
* chain, starting from the first bridge to the last. These are called
* after completing the encoder's commit op.
*
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index d3ca16f4da8f..1595a57dfbf2 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -87,18 +87,19 @@ struct drm_bridge_funcs {
* True if an acceptable configuration is possible, false if the modeset
* operation should be rejected.
*/
-
[PATCH 07/17] drm: Nuke connector_list locking assert
I've forgotten to remove this when revamping the
connector_list locking.
Cc: seanpaul at chromium.org
Signed-off-by: Daniel Vetter
---
include/drm/drm_connector.h | 6 +-
include/drm/drm_crtc.h | 14 --
2 files changed, 1 insertion(+), 19 deletions(-)
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index acb4241bff7d..d489cc003b7e 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -875,11 +875,7 @@ void drm_mode_put_tile_group(struct drm_device *dev,
* deprecated. Use drm_for_each_connector_iter() instead.
*/
#define drm_for_each_connector(connector, dev) \
- for (assert_drm_connector_list_read_locked(&(dev)->mode_config),
\
-connector = list_first_entry(&(dev)->mode_config.connector_list,
\
- struct drm_connector, head);
\
-&connector->head != (&(dev)->mode_config.connector_list);
\
-connector = list_next_entry(connector, head))
+ list_for_each_entry(connector, &(dev)->mode_config.connector_list, head)
/**
* struct drm_connector_list_iter - connector_list iterator
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 0b9ec7245c7e..c0817fa205d4 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -835,18 +835,4 @@ static inline struct drm_crtc *drm_crtc_find(struct
drm_device *dev,
#define drm_for_each_crtc(crtc, dev) \
list_for_each_entry(crtc, &(dev)->mode_config.crtc_list, head)
-static inline void
-assert_drm_connector_list_read_locked(struct drm_mode_config *mode_config)
-{
- /*
-* The connector hotadd/remove code currently grabs both locks when
-* updating lists. Hence readers need only hold either of them to be
-* safe and the check amounts to
-*
-* WARN_ON(not_holding(A) && not_holding(B)).
-*/
- WARN_ON(!mutex_is_locked(&mode_config->mutex) &&
- !drm_modeset_is_locked(&mode_config->connection_mutex));
-}
-
#endif /* __DRM_CRTC_H__ */
--
2.7.4
[PATCH 16/17] drm/gem|prime|mm: Use recommened kerneldoc for struct member refs
I just learned that &struct_name.member_name works and looks pretty even. It doesn't (yet) link to the member directly though, which would be really good for big structures or vfunc tables (where the per-member kerneldoc tends to be long). Also some minor drive-by polish where it makes sense, I read a lot of docs ... Cc: Jani Nikula Cc: Chris Wilson Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_gem.c | 24 drivers/gpu/drm/drm_mm.c| 4 ++-- drivers/gpu/drm/drm_prime.c | 2 +- include/drm/drm_gem.h | 16 4 files changed, 23 insertions(+), 23 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 465bacd0a630..bc93de308673 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -316,8 +316,8 @@ EXPORT_SYMBOL(drm_gem_handle_delete); * @dev: corresponding drm_device * @handle: the dumb handle to remove * - * This implements the ->dumb_destroy kms driver callback for drivers which use - * gem to manage their backing storage. + * This implements the &drm_driver.dumb_destroy kms driver callback for drivers + * which use gem to manage their backing storage. */ int drm_gem_dumb_destroy(struct drm_file *file, struct drm_device *dev, @@ -333,9 +333,9 @@ EXPORT_SYMBOL(drm_gem_dumb_destroy); * @obj: object to register * @handlep: pointer to return the created handle to the caller * - * This expects the dev->object_name_lock to be held already and will drop it - * before returning. Used to avoid races in establishing new handles when - * importing an object from either an flink name or a dma-buf. + * This expects the &drm_device.object_name_lock to be held already and will + * drop it before returning. Used to avoid races in establishing new handles + * when importing an object from either an flink name or a dma-buf. * * Handles must be release again through drm_gem_handle_delete(). This is done * when userspace closes @file_priv for all attached handles, or through the @@ -447,8 +447,8 @@ EXPORT_SYMBOL(drm_gem_free_mmap_offset); * structures. * * This routine allocates and attaches a fake offset for @obj, in cases where - * the virtual size differs from the physical size (ie. obj->size). Otherwise - * just use drm_gem_create_mmap_offset(). + * the virtual size differs from the physical size (ie. &drm_gem_object.size). + * Otherwise just use drm_gem_create_mmap_offset(). * * This function is idempotent and handles an already allocated mmap offset * transparently. Drivers do not need to check for this case. @@ -787,7 +787,7 @@ EXPORT_SYMBOL(drm_gem_object_release); * @kref: kref of the object to free * * Called after the last reference to the object has been lost. - * Must be called holding &drm_device->struct_mutex. + * Must be called holding &drm_device.struct_mutex. * * Frees the object */ @@ -813,7 +813,7 @@ EXPORT_SYMBOL(drm_gem_object_free); * @obj: GEM buffer object * * This releases a reference to @obj. Callers must not hold the - * dev->struct_mutex lock when calling this function. + * &drm_device.struct_mutex lock when calling this function. * * See also __drm_gem_object_unreference(). */ @@ -840,9 +840,9 @@ EXPORT_SYMBOL(drm_gem_object_unreference_unlocked); * drm_gem_object_unreference - release a GEM BO reference * @obj: GEM buffer object * - * This releases a reference to @obj. Callers must hold the dev->struct_mutex - * lock when calling this function, even when the driver doesn't use - * dev->struct_mutex for anything. + * This releases a reference to @obj. Callers must hold the + * &drm_device.struct_mutex lock when calling this function, even when the + * driver doesn't use &drm_device.struct_mutex for anything. * * For drivers not encumbered with legacy locking use * drm_gem_object_unreference_unlocked() instead. diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c index 229b3f525dee..e51876e588d6 100644 --- a/drivers/gpu/drm/drm_mm.c +++ b/drivers/gpu/drm/drm_mm.c @@ -552,8 +552,8 @@ EXPORT_SYMBOL(drm_mm_replace_node); * objects to the roster, probably by walking an LRU list, but this can be * freely implemented. Eviction candiates are added using * drm_mm_scan_add_block() until a suitable hole is found or there are no - * further evictable objects. Eviction roster metadata is tracked in struct - * &drm_mm_scan. + * further evictable objects. Eviction roster metadata is tracked in &struct + * drm_mm_scan. * * The driver must walk through all objects again in exactly the reverse * order to restore the allocator state. Note that while the allocator is used diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 8d77b2462594..485e558d6661 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -291,7 +291,7 @@ static void drm_gem_unmap_dma_buf(struct dma_buf_attachment *attach, * This wraps dma_buf_export() for use by generi
[PATCH 08/17] drm/doc: Update styleguide
The new cool is &struct foo (kernel-doc now copes with linebreaks), and structure members should be referenced using &foo.bar. Cc: Jani Nikula Cc: Chris Wilson Signed-off-by: Daniel Vetter --- Documentation/gpu/introduction.rst | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/Documentation/gpu/introduction.rst b/Documentation/gpu/introduction.rst index 6960e31f71e1..eb284eb748ba 100644 --- a/Documentation/gpu/introduction.rst +++ b/Documentation/gpu/introduction.rst @@ -23,13 +23,12 @@ For consistency this documentation uses American English. Abbreviations are written as all-uppercase, for example: DRM, KMS, IOCTL, CRTC, and so on. To aid in reading, documentations make full use of the markup characters kerneldoc provides: @parameter for function parameters, - at member for structure members, &structure to reference structures and -function() for functions. These all get automatically hyperlinked if -kerneldoc for the referenced objects exists. When referencing entries in -function vtables please use ->vfunc(). Note that kerneldoc does not -support referencing struct members directly, so please add a reference -to the vtable struct somewhere in the same paragraph or at least -section. + at member for structure members (within the same structure), &struct structure to +reference structures and function() for functions. These all get automatically +hyperlinked if kerneldoc for the referenced objects exists. When referencing +entries in function vtables (and structure members in general) please use +&vtable_name.vfunc. Unfortunately this does not yet yield a direct link to the +member, only the structure. Except in special situations (to separate locked from unlocked variants) locking requirements for functions aren't documented in the kerneldoc. -- 2.7.4
[PATCH 03/17] drm/mm: Some doc polish
Added some boilerplate for the structs, documented members where they are relevant and plenty of markup for hyperlinks all over. And a few small wording polish. Note that the intro needs some more love after the DRM_MM_INSERT_* patch from Chris has landed. v2: Spelling fixes (Chris). v3: Use &struct foo instead of &foo structure (Chris). Cc: Chris Wilson Cc: Joonas Lahtinen Signed-off-by: Daniel Vetter --- Documentation/gpu/drm-mm.rst | 2 +- drivers/gpu/drm/drm_mm.c | 41 +++-- include/drm/drm_mm.h | 84 ++-- 3 files changed, 89 insertions(+), 38 deletions(-) diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index cb5daffcd6be..5355e5ad51a7 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -442,7 +442,7 @@ LRU Scan/Eviction Support - .. kernel-doc:: drivers/gpu/drm/drm_mm.c - :doc: lru scan roaster + :doc: lru scan roster DRM MM Range Allocator Function References -- diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c index e54aa3fa538f..229b3f525dee 100644 --- a/drivers/gpu/drm/drm_mm.c +++ b/drivers/gpu/drm/drm_mm.c @@ -59,8 +59,8 @@ * * The main data struct is &drm_mm, allocations are tracked in &drm_mm_node. * Drivers are free to embed either of them into their own suitable - * datastructures. drm_mm itself will not do any allocations of its own, so if - * drivers choose not to embed nodes they need to still allocate them + * datastructures. drm_mm itself will not do any memory allocations of its own, + * so if drivers choose not to embed nodes they need to still allocate them * themselves. * * The range allocator also supports reservation of preallocated blocks. This is @@ -78,7 +78,7 @@ * steep cliff not a real concern. Removing a node again is O(1). * * drm_mm supports a few features: Alignment and range restrictions can be - * supplied. Further more every &drm_mm_node has a color value (which is just an + * supplied. Furthermore every &drm_mm_node has a color value (which is just an * opaque unsigned long) which in conjunction with a driver callback can be used * to implement sophisticated placement restrictions. The i915 DRM driver uses * this to implement guard pages between incompatible caching domains in the @@ -296,11 +296,11 @@ static void drm_mm_insert_helper(struct drm_mm_node *hole_node, * @mm: drm_mm allocator to insert @node into * @node: drm_mm_node to insert * - * This functions inserts an already set-up drm_mm_node into the allocator, - * meaning that start, size and color must be set by the caller. This is useful - * to initialize the allocator with preallocated objects which must be set-up - * before the range allocator can be set-up, e.g. when taking over a firmware - * framebuffer. + * This functions inserts an already set-up &drm_mm_node into the allocator, + * meaning that start, size and color must be set by the caller. All other + * fields must be cleared to 0. This is useful to initialize the allocator with + * preallocated objects which must be set-up before the range allocator can be + * set-up, e.g. when taking over a firmware framebuffer. * * Returns: * 0 on success, -ENOSPC if there's no hole where @node is. @@ -375,7 +375,7 @@ EXPORT_SYMBOL(drm_mm_reserve_node); * @sflags: flags to fine-tune the allocation search * @aflags: flags to fine-tune the allocation behavior * - * The preallocated node must be cleared to 0. + * The preallocated @node must be cleared to 0. * * Returns: * 0 on success, -ENOSPC if there's no suitable hole. @@ -537,7 +537,7 @@ void drm_mm_replace_node(struct drm_mm_node *old, struct drm_mm_node *new) EXPORT_SYMBOL(drm_mm_replace_node); /** - * DOC: lru scan roaster + * DOC: lru scan roster * * Very often GPUs need to have continuous allocations for a given object. When * evicting objects to make space for a new one it is therefore not most @@ -549,9 +549,11 @@ EXPORT_SYMBOL(drm_mm_replace_node); * The DRM range allocator supports this use-case through the scanning * interfaces. First a scan operation needs to be initialized with * drm_mm_scan_init() or drm_mm_scan_init_with_range(). The driver adds - * objects to the roster (probably by walking an LRU list, but this can be - * freely implemented) (using drm_mm_scan_add_block()) until a suitable hole - * is found or there are no further evictable objects. + * objects to the roster, probably by walking an LRU list, but this can be + * freely implemented. Eviction candiates are added using + * drm_mm_scan_add_block() until a suitable hole is found or there are no + * further evictable objects. Eviction roster metadata is tracked in struct + * &drm_mm_scan. * * The driver must walk through all objects again in exactly the reverse * order to restore the allocator state. Note that while the allocator is used @@ -559,7
[PATCH 11/17] drm/cma-helper: simplify setup for drivers with ->dirty callbacks
If we store the fb funcs pointer, we can remove a bit of boilerplate.
Also remove the _fbdev_ in the example code, since the fb_funcs->dirty
callback has nothing to do with fbdev. It's a KMS feature, only
used by the fbdev deferred_io support to implement flushing/upload.
Cc: Noralf Trønnes
Cc: Laurent Pinchart
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_cma_helper.c | 58 +
include/drm/drm_fb_cma_helper.h | 5 +---
2 files changed, 21 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 76cb1aa1b089..ec081727cd5a 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -39,6 +39,7 @@ struct drm_fb_cma {
struct drm_fbdev_cma {
struct drm_fb_helperfb_helper;
struct drm_fb_cma *fb;
+ const struct drm_framebuffer_funcs *fb_funcs;
};
/**
@@ -58,39 +59,29 @@ struct drm_fbdev_cma {
*
* Example fbdev deferred io code::
*
- * static int driver_fbdev_fb_dirty(struct drm_framebuffer *fb,
- * struct drm_file *file_priv,
- * unsigned flags, unsigned color,
- * struct drm_clip_rect *clips,
- * unsigned num_clips)
+ * static int driver_fb_dirty(struct drm_framebuffer *fb,
+ *struct drm_file *file_priv,
+ *unsigned flags, unsigned color,
+ *struct drm_clip_rect *clips,
+ *unsigned num_clips)
* {
* struct drm_gem_cma_object *cma = drm_fb_cma_get_gem_obj(fb, 0);
* ... push changes ...
* return 0;
* }
*
- * static struct drm_framebuffer_funcs driver_fbdev_fb_funcs = {
+ * static struct drm_framebuffer_funcs driver_fb_funcs = {
* .destroy = drm_fb_cma_destroy,
* .create_handle = drm_fb_cma_create_handle,
- * .dirty = driver_fbdev_fb_dirty,
+ * .dirty = driver_fb_dirty,
* };
*
- * static int driver_fbdev_create(struct drm_fb_helper *helper,
- * struct drm_fb_helper_surface_size *sizes)
- * {
- * return drm_fbdev_cma_create_with_funcs(helper, sizes,
- *&driver_fbdev_fb_funcs);
- * }
- *
- * static const struct drm_fb_helper_funcs driver_fb_helper_funcs = {
- * .fb_probe = driver_fbdev_create,
- * };
+ * Initialize::
*
- * Initialize:
* fbdev = drm_fbdev_cma_init_with_funcs(dev, 16,
* dev->mode_config.num_crtc,
* dev->mode_config.num_connector,
- * &driver_fb_helper_funcs);
+ * &driver_fb_funcs);
*
*/
@@ -408,13 +399,9 @@ static void drm_fbdev_cma_defio_fini(struct fb_info *fbi)
kfree(fbi->fbops);
}
-/*
- * For use in a (struct drm_fb_helper_funcs *)->fb_probe callback function that
- * needs custom struct drm_framebuffer_funcs, like dirty() for deferred_io use.
- */
-int drm_fbdev_cma_create_with_funcs(struct drm_fb_helper *helper,
- struct drm_fb_helper_surface_size *sizes,
- const struct drm_framebuffer_funcs *funcs)
+static int
+drm_fbdev_cma_create(struct drm_fb_helper *helper,
+ struct drm_fb_helper_surface_size *sizes)
{
struct drm_fbdev_cma *fbdev_cma = to_fbdev_cma(helper);
struct drm_mode_fb_cmd2 mode_cmd = { 0 };
@@ -450,7 +437,8 @@ int drm_fbdev_cma_create_with_funcs(struct drm_fb_helper
*helper,
goto err_gem_free_object;
}
- fbdev_cma->fb = drm_fb_cma_alloc(dev, &mode_cmd, &obj, 1, funcs);
+ fbdev_cma->fb = drm_fb_cma_alloc(dev, &mode_cmd, &obj, 1,
+fbdev_cma->fb_funcs);
if (IS_ERR(fbdev_cma->fb)) {
dev_err(dev->dev, "Failed to allocate DRM framebuffer.\n");
ret = PTR_ERR(fbdev_cma->fb);
@@ -476,7 +464,7 @@ int drm_fbdev_cma_create_with_funcs(struct drm_fb_helper
*helper,
fbi->screen_size = size;
fbi->fix.smem_len = size;
- if (funcs->dirty) {
+ if (fbdev_cma->fb_funcs->dirty) {
ret = drm_fbdev_cma_defio_init(fbi, obj);
if (ret)
goto err_cma_destroy;
@@ -492,13 +480,6 @@ int drm_fbdev_cma_create_with_funcs(struct drm_fb_helper
*helper,
drm_gem_object_unreference_unlocked(&obj->base);
return ret;
}
-EXPORT_SYMBOL(drm_fbdev_cma_create_with_funcs);
-
-static int drm_fbdev_cma_create(struct drm_fb_helper *helper,
- struct drm_fb_helper_surface_size *sizes)
-{
- return drm_fbdev_cma_create_with_funcs(helper, sizes,
&drm_fb_cma_funcs);
-}
static const struct drm_f
[PATCH 12/17] drm/kms-helpers: Use recommened kerneldoc for struct member refs
I just learned that &struct_name.member_name works and looks pretty even. It doesn't (yet) link to the member directly though, which would be really good for big structures or vfunc tables (where the per-member kerneldoc tends to be long). Also some minor drive-by polish where it makes sense, I read a lot of docs ... Cc: Jani Nikula Cc: Chris Wilson Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_atomic_helper.c | 97 ++-- drivers/gpu/drm/drm_crtc_helper.c| 28 +++--- drivers/gpu/drm/drm_dp_helper.c | 2 +- drivers/gpu/drm/drm_fb_helper.c | 48 +- drivers/gpu/drm/drm_plane_helper.c | 9 +- drivers/gpu/drm/drm_probe_helper.c | 14 +-- include/drm/drm_atomic_helper.h | 13 +-- include/drm/drm_dp_mst_helper.h | 7 +- include/drm/drm_flip_work.h | 2 +- include/drm/drm_modeset_helper_vtables.h | 146 --- include/drm/drm_simple_kms_helper.h | 12 +-- 11 files changed, 197 insertions(+), 181 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 5e5224460042..8ef1f5923468 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -458,22 +458,25 @@ mode_fixup(struct drm_atomic_state *state) * Check the state object to see if the requested state is physically possible. * This does all the crtc and connector related computations for an atomic * update and adds any additional connectors needed for full modesets and calls - * down into ->mode_fixup functions of the driver backend. - * - * crtc_state->mode_changed is set when the input mode is changed. - * crtc_state->connectors_changed is set when a connector is added or - * removed from the crtc. - * crtc_state->active_changed is set when crtc_state->active changes, - * which is used for dpms. + * down into &drm_crtc_helper_funcs.mode_fixup and + * &drm_encoder_helper_funcs.mode_fixup or + * &drm_encoder_helper_funcs.atomic_check functions of the driver backend. + * + * &drm_crtc_state.mode_changed is set when the input mode is changed. + * &drm_crtc_state.connectors_changed is set when a connector is added or + * removed from the crtc. &drm_crtc_state.active_changed is set when + * &drm_crtc_state.active changes, which is used for DPMS. * See also: drm_atomic_crtc_needs_modeset() * * IMPORTANT: * - * Drivers which set ->mode_changed (e.g. in their ->atomic_check hooks if a - * plane update can't be done without a full modeset) _must_ call this function - * afterwards after that change. It is permitted to call this function multiple - * times for the same update, e.g. when the ->atomic_check functions depend upon - * the adjusted dotclock for fifo space allocation and watermark computation. + * Drivers which set &drm_crtc_state.mode_changed (e.g. in their + * &drm_plane_helper_funcs.atomic_check hooks if a plane update can't be done + * without a full modeset) _must_ call this function afterwards after that + * change. It is permitted to call this function multiple times for the same + * update, e.g. when the &drm_crtc_helper_funcs.atomic_check functions depend + * upon the adjusted dotclock for fifo space allocation and watermark + * computation. * * RETURNS: * Zero for success or -errno @@ -584,9 +587,10 @@ EXPORT_SYMBOL(drm_atomic_helper_check_modeset); * * Check the state object to see if the requested state is physically possible. * This does all the plane update related checks using by calling into the - * ->atomic_check hooks provided by the driver. + * &drm_crtc_helper_funcs.atomic_check and &drm_plane_helper_funcs.atomic_check + * hooks provided by the driver. * - * It also sets crtc_state->planes_changed to indicate that a crtc has + * It also sets &drm_crtc_state.planes_changed to indicate that a crtc has * updated planes. * * RETURNS: @@ -648,14 +652,15 @@ EXPORT_SYMBOL(drm_atomic_helper_check_planes); * Check the state object to see if the requested state is physically possible. * Only crtcs and planes have check callbacks, so for any additional (global) * checking that a driver needs it can simply wrap that around this function. - * Drivers without such needs can directly use this as their ->atomic_check() - * callback. + * Drivers without such needs can directly use this as their + * &drm_mode_config_funcs.atomic_check callback. * * This just wraps the two parts of the state checking for planes and modeset * state in the default order: First it calls drm_atomic_helper_check_modeset() * and then drm_atomic_helper_check_planes(). The assumption is that the - * ->atomic_check functions depend upon an updated adjusted_mode.clock to - * e.g. properly compute watermarks. + * @drm_plane_helper_funcs.atomic_check and @drm_crtc_helper_funcs.atomic_check + * functions depend upon an updated adjusted_mode.clock to e.g. properly compute + * watermarks. * * RETURNS: *
[PATCH 07/17] drm: Nuke connector_list locking assert
On Thu, Dec 29, 2016 at 3:48 PM, Daniel Vetter
wrote:
> I've forgotten to remove this when revamping the
> connector_list locking.
>
> Cc: seanpaul at chromium.org
Reviewed-by: Sean Paul
> Signed-off-by: Daniel Vetter
> ---
> include/drm/drm_connector.h | 6 +-
> include/drm/drm_crtc.h | 14 --
> 2 files changed, 1 insertion(+), 19 deletions(-)
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index acb4241bff7d..d489cc003b7e 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -875,11 +875,7 @@ void drm_mode_put_tile_group(struct drm_device *dev,
> * deprecated. Use drm_for_each_connector_iter() instead.
> */
> #define drm_for_each_connector(connector, dev) \
> - for (assert_drm_connector_list_read_locked(&(dev)->mode_config),
> \
> -connector = list_first_entry(&(dev)->mode_config.connector_list,
> \
> - struct drm_connector, head);
> \
> -&connector->head != (&(dev)->mode_config.connector_list);
> \
> -connector = list_next_entry(connector, head))
> + list_for_each_entry(connector, &(dev)->mode_config.connector_list,
> head)
>
> /**
> * struct drm_connector_list_iter - connector_list iterator
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 0b9ec7245c7e..c0817fa205d4 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -835,18 +835,4 @@ static inline struct drm_crtc *drm_crtc_find(struct
> drm_device *dev,
> #define drm_for_each_crtc(crtc, dev) \
> list_for_each_entry(crtc, &(dev)->mode_config.crtc_list, head)
>
> -static inline void
> -assert_drm_connector_list_read_locked(struct drm_mode_config *mode_config)
> -{
> - /*
> -* The connector hotadd/remove code currently grabs both locks when
> -* updating lists. Hence readers need only hold either of them to be
> -* safe and the check amounts to
> -*
> -* WARN_ON(not_holding(A) && not_holding(B)).
> -*/
> - WARN_ON(!mutex_is_locked(&mode_config->mutex) &&
> - !drm_modeset_is_locked(&mode_config->connection_mutex));
> -}
> -
> #endif /* __DRM_CRTC_H__ */
> --
> 2.7.4
>
--
Sean Paul, Software Engineer, Google / Chromium OS
[PATCH] gpu: drm: vmwgfx: Use kmemdup instead of kmalloc and memcpy
Thanks, applied.
Reviewed-by: Sinclair Yeh
On Sat, Dec 24, 2016 at 01:21:10AM +0530, Shyam Saini wrote:
> When some other buffer is immediately copied into allocated region.
> Replace calls to kmalloc followed by a memcpy with a direct
> call to kmemdup.
>
> Signed-off-by: Shyam Saini
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_mob.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
> index b6126a5..941bcfd 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
> @@ -319,18 +319,17 @@ int vmw_otables_setup(struct vmw_private *dev_priv)
> int ret;
>
> if (dev_priv->has_dx) {
> - *otables = kmalloc(sizeof(dx_tables), GFP_KERNEL);
> + *otables = kmemdup(dx_tables, sizeof(dx_tables), GFP_KERNEL);
> if (*otables == NULL)
> return -ENOMEM;
>
> - memcpy(*otables, dx_tables, sizeof(dx_tables));
> dev_priv->otable_batch.num_otables = ARRAY_SIZE(dx_tables);
> } else {
> - *otables = kmalloc(sizeof(pre_dx_tables), GFP_KERNEL);
> + *otables = kmemdup(pre_dx_tables, sizeof(pre_dx_tables),
> +GFP_KERNEL);
> if (*otables == NULL)
> return -ENOMEM;
>
> - memcpy(*otables, pre_dx_tables, sizeof(pre_dx_tables));
> dev_priv->otable_batch.num_otables = ARRAY_SIZE(pre_dx_tables);
> }
>
> --
> 2.7.4
>
[PATCH 0/2] Enable R8A7794 DU VSPD compositor
Hello. Here's the set of 2 patches against the 'drm-next' branch of David Airlie's 'linux.git' repo. We're switching to the DU compositor for the DU driver on the Renesas R8A7794 SoC. [1/2] drm: rcar-du: support less VSPs than CRTCs [2/2] drm: rcar-du: enable VSPD on R8A7794 MBR, Sergei
[PATCH] drm: clean cached display info
Hi Shashank,
On 29-12-2016 12:28, Shashank Sharma wrote:
> This patch adds a small helper function, which clears the cached
> information about a hot-pluggable display, from connector. On event
> This will run on event of a hot-unplug, keeping the connector's display
> info up-to-date, avoiding any errors due to invalid cached data.
>
> Forking this patch out from the 3 patch series:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.freedesktop.org_patch_128961_&d=DgIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=yaVFU4TjGY0gVF8El1uKcisy6TPsyCl9uN7Wsis-qhY&m=wGqvHYK00VvbUVGun4-ZhK6KZ4Ht_lHwPGfC6ajlzxE&s=7YpJD-fwUixHNz9SNn2B1ijuL5mEVeEUmolbf3NqWcs&e=
>
> (still under review) and sending as individual patch.
>
> Cc: Jose Abreu
> Cc: Daniel Vetter
>
> Suggested-by: Jose Abreu
> Signed-off-by: Shashank Sharma
> ---
Reviewed-by: Jose Abreu
Best regards,
Jose Miguel Abreu
> drivers/gpu/drm/drm_probe_helper.c | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index 7cff91e..65a6a1f 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -164,6 +164,18 @@ void drm_kms_helper_poll_enable_locked(struct drm_device
> *dev)
> }
>
> /**
> + * drm_helper_clear_display_info - clean cached display information for
> + * hot pluggable displays, on event of hot-unplug
> + * @connector: connector under event
> + */
> +void drm_helper_clear_display_info(struct drm_connector *connector)
> +{
> + struct drm_display_info *info = &connector->display_info;
> +
> + memset(info, 0, sizeof(*info));
> +}
> +
> +/**
> * drm_helper_probe_single_connector_modes - get complete set of display
> modes
> * @connector: connector to probe
> * @maxX: max width for modes
> @@ -288,6 +300,16 @@ int drm_helper_probe_single_connector_modes(struct
> drm_connector *connector,
> DRM_DEBUG_KMS("[CONNECTOR:%d:%s] disconnected\n",
> connector->base.id, connector->name);
> drm_mode_connector_update_edid_property(connector, NULL);
> +
> + /*
> + * Connector status change to disconnected, time to clean
> + * cached display information.
> + * Any driver which doesn't use this probe_helper function
> + * should implement update of EDID property and display_info
> + * on its own.
> + */
> + drm_helper_clear_display_info(connector);
> +
> verbose_prune = false;
> goto prune;
> }
[PATCH 2/2] drm: rcar-du: enable VSPD on R8A7794
We're going to use R8A7794 VSPD to control DU, so set the corresponding flag
and the newly added field, 'num_vspds'...
Signed-off-by: Sergei Shtylyov
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: linux/drivers/gpu/drm/rcar-du/rcar_du_drv.c
===
--- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ linux/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -136,7 +136,8 @@ static const struct rcar_du_device_info
static const struct rcar_du_device_info rcar_du_r8a7794_info = {
.gen = 2,
.features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
- | RCAR_DU_FEATURE_EXT_CTRL_REGS,
+ | RCAR_DU_FEATURE_EXT_CTRL_REGS
+ | RCAR_DU_FEATURE_VSP1_SOURCE,
.num_crtcs = 2,
.routes = {
/* R8A7794 has two RGB outputs and one (currently unsupported)
@@ -154,6 +155,7 @@ static const struct rcar_du_device_info
},
},
.num_lvds = 0,
+ .num_vspds = 1,
};
static const struct rcar_du_device_info rcar_du_r8a7795_info = {
[PATCH 1/2] drm: rcar-du: support less VSPs than CRTCs
Renesas R-Car E2 (R8A7791) SoC only has 1 VSPD but still 2 DU ports.
Since we are going to use the R-Car gen2 VSPDs as the DU compositors,
we'll have to also support this case. Now that the number of VSPDs can be
less than the number of the DU ports, 'struct rcar_du_device_info' needs
a new field which we'll have to set for the SoCs where we've already used
the VSPD compositor...
Signed-off-by: Sergei Shtylyov
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 17 ++-
drivers/gpu/drm/rcar-du/rcar_du_drv.c |2
drivers/gpu/drm/rcar-du/rcar_du_drv.h |2
drivers/gpu/drm/rcar-du/rcar_du_kms.c |2
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 76 ++---
drivers/gpu/drm/rcar-du/rcar_du_vsp.h |2
6 files changed, 75 insertions(+), 26 deletions(-)
Index: linux/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
===
--- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ linux/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -255,8 +255,21 @@ static void rcar_du_crtc_update_planes(s
/* If VSP+DU integration is enabled the plane assignment is fixed. */
if (rcar_du_has(rcdu, RCAR_DU_FEATURE_VSP1_SOURCE)) {
if (rcdu->info->gen < 3) {
- dspr = (rcrtc->index % 2) + 1;
- hwplanes = 1 << (rcrtc->index % 2);
+ if (rcrtc->vsp->vsp) {
+ dspr = (rcrtc->index % 2) + 1;
+ hwplanes = 1 << (rcrtc->index % 2);
+ } else {
+ for (i = 0; i < rcrtc->vsp->num_planes; ++i) {
+ struct rcar_du_vsp_plane *plane =
+ &rcrtc->vsp->planes[i];
+
+ if (plane->plane.state->crtc !=
+ &rcrtc->crtc)
+ continue;
+ dspr |= (plane->index + 5) << 4 * i;
+ hwplanes |= 1 << (plane->index + 4);
+ }
+ }
} else {
dspr = (rcrtc->index % 2) ? 3 : 1;
hwplanes = 1 << ((rcrtc->index % 2) ? 2 : 0);
Index: linux/drivers/gpu/drm/rcar-du/rcar_du_drv.c
===
--- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ linux/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -109,6 +109,7 @@ static const struct rcar_du_device_info
},
},
.num_lvds = 1,
+ .num_vspds = 2,
};
static const struct rcar_du_device_info rcar_du_r8a7792_info = {
@@ -201,6 +202,7 @@ static const struct rcar_du_device_info
},
},
.num_lvds = 1,
+ .num_vspds = 4,
};
static const struct of_device_id rcar_du_of_table[] = {
Index: linux/drivers/gpu/drm/rcar-du/rcar_du_drv.h
===
--- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ linux/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -59,6 +59,7 @@ struct rcar_du_output_routing {
* @num_crtcs: total number of CRTCs
* @routes: array of CRTC to output routes, indexed by output
(RCAR_DU_OUTPUT_*)
* @num_lvds: number of internal LVDS encoders
+ * @num_vspds: number of VSPDs
*/
struct rcar_du_device_info {
unsigned int gen;
@@ -67,6 +68,7 @@ struct rcar_du_device_info {
unsigned int num_crtcs;
struct rcar_du_output_routing routes[RCAR_DU_OUTPUT_MAX];
unsigned int num_lvds;
+ unsigned int num_vspds;
};
#define RCAR_DU_MAX_CRTCS 4
Index: linux/drivers/gpu/drm/rcar-du/rcar_du_kms.c
===
--- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ linux/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -611,6 +611,8 @@ int rcar_du_modeset_init(struct rcar_du_
vsp->index = i;
vsp->dev = rcdu;
+ vsp->group = &rcdu->groups[i / 2];
+
rcdu->crtcs[i].vsp = vsp;
ret = rcar_du_vsp_init(vsp);
Index: linux/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
===
--- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ linux/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -51,6 +51,9 @@ void rcar_du_vsp_enable(struct rcar_du_c
.colorkey = 0,
};
+ if (!crtc->vsp->vsp)
+ return;
+
if (rcdu->info->gen >= 3)
state.hwindex = (crtc->index % 2) ? 2 : 0;
else
@@ -71,17 +74,20 @@ void rcar_du_vsp_enable(struct rcar_du_c
void rcar_du_vsp_disable(struct rcar_du_crtc *crtc)
{
- vsp1_du_setup_lif(crtc->vsp->vsp, 0, 0);
+ if (crtc->vsp
[Intel-gfx] [PATCH v3 3/3] drm: clean cached display info
Hi Shashank,
On 29-12-2016 05:53, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 12/27/2016 3:07 PM, Daniel Vetter wrote:
>> On Thu, Dec 22, 2016 at 10:21:25AM +, Jose Abreu wrote:
>>> Hi Shashank,
>>>
>>>
>>> On 21-12-2016 15:29, Shashank Sharma wrote:
This patch adds a small helper function, which clears the
cached
information about a hot-pluggable display, from connector.
On event
This will run on event of a hot-unplug, keeping the
connector's display
info up-to-date, avoiding any errors due to invalid cached
data.
Cc: Jose Abreu
Suggested-by: Jose Abreu
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/drm_probe_helper.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 7cff91e..9e97b45 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -164,6 +164,18 @@ void
drm_kms_helper_poll_enable_locked(struct drm_device *dev)
}
/**
+ * drm_helper_clear_display_info - clean cached display
information for
+ * hot pluggable displays, on event of hot-unplug
+ * @connector: connector under event
+ */
+void drm_helper_clear_display_info(struct drm_connector
*connector)
+{
+struct drm_display_info *info = &connector->display_info;
+
+memset(info, 0, sizeof(*info));
+}
+
+/**
* drm_helper_probe_single_connector_modes - get complete
set of display modes
* @connector: connector to probe
* @maxX: max width for modes
@@ -288,6 +300,14 @@ int
drm_helper_probe_single_connector_modes(struct drm_connector
*connector,
DRM_DEBUG_KMS("[CONNECTOR:%d:%s] disconnected\n",
connector->base.id, connector->name);
drm_mode_connector_update_edid_property(connector,
NULL);
+
+/*
+ * Connector status change to disconnected, time to
clean
+ * cached display information
+ */
+if (connector->status ==
connector_status_disconnected)
+drm_helper_clear_display_info(connector);
+
>>> I don't know if this is the right place to do this because it is
>>> a helper and I don't know if it is used by all the drivers. We
>>> may need something more general that is always called when
>>> probing modes, or force drivers that don't use the helper to use
>>> the drm_helper_clear_display_info function. As I told you
>>> before,
>>> I'm new to dri-devel so we need more comments.
>> Seems reasonable to me, since afaik all drivers do use the
>> probe helpers.
>> -Daniel
> This was my understanding too. Jose, you think there would be
> any drivers who dont use this probe ?
> - Shashank
I found only one driver that don't use this helper: vmwgfx. But,
this driver does not seem to use EDID fields, it has a list of
preferred video modes and manually adds these modes.
So, I think it is safe to add this in the helper as long as
future drivers that use EDID use this helper also. Maybe a small
comment about this should be added in the helper declaration.
Best regards,
Jose Miguel Abreu
>>> Best regards,
>>> Jose Miguel Abreu
>>>
verbose_prune = false;
goto prune;
}
>>> ___
>>> Intel-gfx mailing list
>>> Intel-gfx at lists.freedesktop.org
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_intel-2Dgfx&d=DgIC-g&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=1G5dnBp7Y6VEifpEnDT2wKFoDRBXnxGXAnA-4883H74&s=y1M2ce128zpR_lBDPSgS_JGm-HoPIJjneK2s3tkrvyo&e=
>>
>
