Re: [Intel-gfx] [PATCH v2] Return only active connectors for get_resources ioctl
On Wed, 2018-11-28 at 22:21 +0100, Daniel Vetter wrote:
> On Wed, Nov 28, 2018 at 09:51:13PM +0100, Daniel Vetter wrote:
> > On Wed, Nov 28, 2018 at 03:55:58PM +0200, Stanislav Lisovskiy
> > wrote:
> > > Currently kernel might allocate different connector ids
> > > for the same outputs in case of DP MST, which seems to
> > > confuse userspace. There are can be different connector
> > > ids in the list, which could be assigned to the same
> > > output, while being in different states.
> > > This results in issues, like external displays staying
> > > blank after quick unplugging and plugging back(bug #106250).
> > > Returning only active DP connectors fixes the issue.
> > >
> > > v2: Removed caps from the title
> > >
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106250
> > > Signed-off-by: Stanislav Lisovskiy > > >
> > > ---
> > > drivers/gpu/drm/drm_mode_config.c | 16 +++-
> > > 1 file changed, 11 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_mode_config.c
> > > b/drivers/gpu/drm/drm_mode_config.c
> > > index ee80788f2c40..ec5b2b08a45e 100644
> > > --- a/drivers/gpu/drm/drm_mode_config.c
> > > +++ b/drivers/gpu/drm/drm_mode_config.c
> > > @@ -143,6 +143,7 @@ int drm_mode_getresources(struct drm_device
> > > *dev, void *data,
> > > drm_connector_list_iter_begin(dev, _iter);
> > > count = 0;
> > > connector_id = u64_to_user_ptr(card_res-
> > > >connector_id_ptr);
> > > + DRM_DEBUG_KMS("GetResources: writing connectors start");
> > > drm_for_each_connector_iter(connector, _iter) {
> > > /* only expose writeback connectors if userspace
> > > understands them */
> > > if (!file_priv->writeback_connectors &&
> > > @@ -150,15 +151,20 @@ int drm_mode_getresources(struct drm_device
> > > *dev, void *data,
> > > continue;
> > >
> > > if (drm_lease_held(file_priv, connector-
> > > >base.id)) {
> > > - if (count < card_res->count_connectors
> > > &&
> > > - put_user(connector->base.id,
> > > connector_id + count)) {
> > > - drm_connector_list_iter_end(
> > > n_iter);
> > > - return -EFAULT;
> > > + if (connector->connector_type !=
> > > DRM_MODE_CONNECTOR_DisplayPort ||
> > > + connector->status !=
> > > connector_status_disconnected) {
> > > + if (count < card_res-
> > > >count_connectors &&
> > > + put_user(connector->base.id,
> > > connector_id + count)) {
> > > + drm_connector_list_iter_
> > > end(_iter);
> > > + return -EFAULT;
> > > + }
> > > + DRM_DEBUG_KMS("GetResources:
> > > connector %s", connector->name);
> > > + count++;
> >
> > I tried to read the bug and I have no idea what's going on here.
> > Userspace
> > is supposed to shut off outputs that are disconnected, whether
> > that's DP,
> > DP MST or something else shouldn't matter. New connectors can
> > come as
> > they see fit. Also not really something special.
> >
> > Why do we need to dynamically hide an output here? Note that this
> > also
> > affects normal DP ports, which I have no idea is actually what you
> > want to
> > do or not.
This bug is real and easily reproducible with recent drm-tip.
Unplugging and then quickly plugging back periodically leaves both my
external displays connected to the docking station blank, there are
also many duplicate bugs for this, which I simply didn't track. This
patch at least fixes that annoying thing.
The userspace seems to get confused when we are returning two different
connector ids, one in disconnected state and another in connected state
for the same output. This results in userspace believing that nothing
had changed and drm_mode_setcrtc call is not required( I have done
traces confirming that theory).
This could be also fixed in userspace by checking connectors more
carefully - that fix I've also implemented for Intel DDX and attached
to the bug, however seems that this happens also for Wayland.
>
> For entertainment and other reasons, testing the below diff would be
> interesting.
>
>
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 4de247ddf05f..e1b66396c83b 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -499,6 +499,8 @@ static void
> intel_dp_register_mst_connector(struct drm_connector *connector)
> drm_fb_helper_add_one_connector(_priv->fbdev-
> >helper,
> connector);
>
> + list_move(>head, >dev-
> >mode_config.connector_list);
> +
> drm_connector_register(connector);
> }
>
--
Best Regards,
Lisovskiy Stanislav
___
dri-devel mailing list
[Bug 108892] kernel BUG at kernel/time/timer.c:1137 in drm_sched_job_finish [gpu_sched]
https://bugs.freedesktop.org/show_bug.cgi?id=108892 --- Comment #1 from Christian König --- What kernel version is this? Please also try with the latest. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-staging-drm-next 429/451] htmldocs: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:195: warning: Function parameter or member 'atomic_obj' not described in 'amdgpu_display_manager'
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next head: 2e41bee6b61f2f0a460a8fb71b795d756a38bc85 commit: e64abff2f1330b536b2973719b74ba92950ff254 [429/451] drm/amd/display: Use private obj helpers for dm_atomic_state reproduce: make htmldocs All warnings (new ones prefixed by >>): include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' include/net/mac80211.h:477: warning: cannot understand function prototype: 'struct ieee80211_ftm_responder_params ' net/mac80211/sta_info.h:588: warning: Function parameter or member 'rx_stats_avg' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'rx_stats_avg.signal' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'rx_stats_avg.chain_signal' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.filtered' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.retry_failed' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.retry_count' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.lost_packets' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.last_tdls_pkt_time' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.msdu_retries' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.msdu_failed' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.last_ack' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.last_ack_signal' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.ack_signal_filled' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'status_stats.avg_ack_signal' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'tx_stats.packets' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'tx_stats.bytes' not described in 'sta_info' net/mac80211/sta_info.h:588: warning: Function parameter or member 'tx_stats.last_rate' not described in 'sta_info' net/mac80211/sta_info.h:588: warning:
[Bug 108892] kernel BUG at kernel/time/timer.c:1137 in drm_sched_job_finish [gpu_sched]
https://bugs.freedesktop.org/show_bug.cgi?id=108892 Bug ID: 108892 Summary: kernel BUG at kernel/time/timer.c:1137 in drm_sched_job_finish [gpu_sched] Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: viclu...@gmail.com Created attachment 142656 --> https://bugs.freedesktop.org/attachment.cgi?id=142656=edit kernel dmesg Sometimes my AMD-2500U with amd.dc=1 crashes with the above messages in dmesg. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm: Add optional PIXEL_NORMALIZE_RANGE property to drm_plane
Add an optional property to allow applications to indicate what range their
floating point pixel data is normalized to. Drivers are free to choose what
ranges they want to support and can attach this property to each plane that
actually supports floating point formats
Signed-off-by: Kevin Strasser
Cc: Uma Shankar
Cc: Shashank Sharma
Cc: Ville Syrjälä
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/drm_atomic.c| 2 ++
drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
drivers/gpu/drm/drm_color_mgmt.c| 68 +
drivers/gpu/drm/drm_crtc_internal.h | 1 +
include/drm/drm_color_mgmt.h| 9 +
include/drm/drm_plane.h | 14
6 files changed, 98 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 1706ed1..1f520ef 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -624,6 +624,8 @@ static void drm_atomic_plane_print_state(struct drm_printer
*p,
drm_get_color_encoding_name(state->color_encoding));
drm_printf(p, "\tcolor-range=%s\n",
drm_get_color_range_name(state->color_range));
+ drm_printf(p, "\tpixel-normalize-range=%s\n",
+
drm_get_pixel_normalize_range_name(state->pixel_normalize_range));
if (plane->funcs->atomic_print_state)
plane->funcs->atomic_print_state(p, state);
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 86ac339..e79a23cd 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -566,6 +566,8 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
state->color_encoding = val;
} else if (property == plane->color_range_property) {
state->color_range = val;
+ } else if (property == plane->pixel_normalize_range_property) {
+ state->pixel_normalize_range = val;
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -621,6 +623,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state->color_encoding;
} else if (property == plane->color_range_property) {
*val = state->color_range;
+ } else if (property == plane->pixel_normalize_range_property) {
+ *val = state->pixel_normalize_range;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state,
property, val);
} else {
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 581cc37..b1e2a0a 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -472,3 +472,71 @@ int drm_plane_create_color_properties(struct drm_plane
*plane,
return 0;
}
EXPORT_SYMBOL(drm_plane_create_color_properties);
+
+static const char * const pixel_normalize_range_name[] = {
+ [DRM_PIXEL_NORMALIZE_RANGE_0_1] = "0.0 - 1.0",
+ [DRM_PIXEL_NORMALIZE_RANGE_0_255] = "0.0 - 255.0",
+};
+
+/**
+ * drm_get_pixel_normalize_range_name - return a string for pixel normalize
+ * range
+ * @range: pixel normalize range to compute name of
+ *
+ * In contrast to the other drm_get_*_name functions this one here returns a
+ * const pointer and hence is threadsafe.
+ */
+const char *drm_get_pixel_normalize_range_name(enum drm_pixel_normalize_range
range)
+{
+ if (WARN_ON(range >= ARRAY_SIZE(pixel_normalize_range_name)))
+ return "unknown";
+
+ return pixel_normalize_range_name[range];
+}
+
+/**
+ * drm_plane_create_pixel_normalize_range_property - pixel normalize range
+ * property
+ * @plane: plane object
+ * @supported_ranges: bitfield indicating supported normalize ranges
+ * @default_range: default normalize range
+ *
+ * Create and attach plane specific PIXEL_NORMALIZE_RANGE property to @plane.
+ * The supported ranges should be provided in supported_ranges bitmask. Eeach
+ * bit set in the bitmask indicates that its number as enum value is supported.
+ */
+int drm_plane_create_pixel_normalize_range_property(struct drm_plane *plane,
+ u32 supported_ranges, enum drm_pixel_normalize_range default_range)
+{
+ struct drm_property *prop;
+ struct drm_prop_enum_list enum_list[DRM_PIXEL_NORMALIZE_RANGE_MAX];
+ int i, len = 0;
+
+ if (WARN_ON(supported_ranges == 0 ||
+ (supported_ranges & -BIT(DRM_PIXEL_NORMALIZE_RANGE_MAX)) !=
0 ||
+ (supported_ranges & BIT(default_range)) == 0))
+ return -EINVAL;
+
+ for (i = 0; i < DRM_PIXEL_NORMALIZE_RANGE_MAX; i++) {
+ if ((supported_ranges & BIT(i)) == 0)
+ continue;
+
+ enum_list[len].type = i;
+
[PATCH 0/3] Support 64 bpp half float formats
This series defines new formats and adds a plane property to be used for floating point framebuffer content. Implementation is then added to i915. I have shared an IGT branch which adds test coverage for the new formats: https://github.com/strassek/xorg-intel-gpu-tools/tree/fp16 Kevin Strasser (3): drm/fourcc: Add 64 bpp half float formats drm: Add optional PIXEL_NORMALIZE_RANGE property to drm_plane drm/i915: Implement half float formats and pixel normalize property drivers/gpu/drm/drm_atomic.c | 2 + drivers/gpu/drm/drm_atomic_uapi.c| 4 ++ drivers/gpu/drm/drm_color_mgmt.c | 67 +++ drivers/gpu/drm/drm_crtc_internal.h | 1 + drivers/gpu/drm/drm_fourcc.c | 4 ++ drivers/gpu/drm/i915/i915_reg.h | 15 - drivers/gpu/drm/i915/intel_display.c | 47 drivers/gpu/drm/i915/intel_drv.h | 5 ++ drivers/gpu/drm/i915/intel_sprite.c | 82 ++-- include/drm/drm_color_mgmt.h | 9 +++ include/drm/drm_fourcc.h | 3 + include/drm/drm_plane.h | 14 + include/uapi/drm/drm_fourcc.h| 6 ++ 13 files changed, 252 insertions(+), 7 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/fourcc: Add 64 bpp half float formats
Add 64 bpp 16:16:16:16 half float pixel formats. Each 16 bit component is
formatted in IEEE-754 half-precision float (binary16) 1:5:10
MSb-sign:exponent:fraction form.
An 'is_fp' attribute is added to drm_format_info so that drivers can easily
distinguish these formats from those that might contain uint pixel data.
This patch attempts to address the feedback provided when 2 of these
formats were previosly proposed:
https://patchwork.kernel.org/patch/10072545/
Signed-off-by: Kevin Strasser
Cc: Tina Zhang
Cc: Uma Shankar
Cc: Shashank Sharma
Cc: Ville Syrjälä
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/drm_fourcc.c | 4
include/drm/drm_fourcc.h | 3 +++
include/uapi/drm/drm_fourcc.h | 6 ++
3 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index f523948..a7b969a 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -198,6 +198,10 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_ABGR,.depth = 32,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
{ .format = DRM_FORMAT_RGBA,.depth = 32,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
{ .format = DRM_FORMAT_BGRA,.depth = 32,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
+ { .format = DRM_FORMAT_XRGB16161616H, .depth = 48,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_fp = true },
+ { .format = DRM_FORMAT_XBGR16161616H, .depth = 48,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_fp = true },
+ { .format = DRM_FORMAT_ARGB16161616H, .depth = 64,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
.is_fp = true },
+ { .format = DRM_FORMAT_ABGR16161616H, .depth = 64,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
.is_fp = true },
{ .format = DRM_FORMAT_RGB888_A8, .depth = 32,
.num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
{ .format = DRM_FORMAT_BGR888_A8, .depth = 32,
.num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
{ .format = DRM_FORMAT_XRGB_A8, .depth = 32,
.num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index bcb389f..2c5aa19 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -133,6 +133,9 @@ struct drm_format_info {
/** @is_yuv: Is it a YUV format? */
bool is_yuv;
+
+ /** @is_fp: Is it a floating point format? */
+ bool is_fp;
};
/**
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index e7e48f1f..530bce4 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -144,6 +144,12 @@ extern "C" {
#define DRM_FORMAT_RGBA1010102 fourcc_code('R', 'A', '3', '0') /* [31:0]
R:G:B:A 10:10:10:2 little endian */
#define DRM_FORMAT_BGRA1010102 fourcc_code('B', 'A', '3', '0') /* [31:0]
B:G:R:A 10:10:10:2 little endian */
+/* 64 bpp RGB IEEE-754 half-precision float (binary16) */
+#define DRM_FORMAT_XBGR16161616H fourcc_code('X', 'B', '4', 'H') /* [63:0]
x:B:G:R 16:16:16:16 little endian */
+#define DRM_FORMAT_ABGR16161616H fourcc_code('A', 'B', '4', 'H') /* [63:0]
A:B:G:R 16:16:16:16 little endian */
+#define DRM_FORMAT_XRGB16161616H fourcc_code('X', 'R', '4', 'H') /* [63:0]
x:R:G:B 16:16:16:16 little endian */
+#define DRM_FORMAT_ARGB16161616H fourcc_code('A', 'R', '4', 'H') /* [63:0]
A:R:G:B 16:16:16:16 little endian */
+
/* packed YCbCr */
#define DRM_FORMAT_YUYVfourcc_code('Y', 'U', 'Y', 'V') /*
[31:0] Cr0:Y1:Cb0:Y0 8:8:8:8 little endian */
#define DRM_FORMAT_YVYUfourcc_code('Y', 'V', 'Y', 'U') /*
[31:0] Cb0:Y1:Cr0:Y0 8:8:8:8 little endian */
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/i915: Implement half float formats and pixel normalize property
64 bpp half float formats are supported on hdr planes only and are subject
to the following restrictions:
* 90/270 rotation not supported
* Yf Tiling not supported
* Frame Buffer Compression not supported
* Color Keying not supported
The behavior of pixel normalize with non-float formats is currently
undefined. As such, the pixel normalize register is enabled iff the
framebuffer contains floating point pixel data.
Signed-off-by: Kevin Strasser
Cc: Uma Shankar
Cc: Shashank Sharma
Cc: Ville Syrjälä
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/i915/i915_reg.h | 15 ++-
drivers/gpu/drm/i915/intel_display.c | 48 +
drivers/gpu/drm/i915/intel_drv.h | 5 +++
drivers/gpu/drm/i915/intel_sprite.c | 82 +---
4 files changed, 143 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 47baf2fe..871d293 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6563,6 +6563,10 @@ enum {
#define _PLANE_KEYMAX_1_A 0x701a0
#define _PLANE_KEYMAX_2_A 0x702a0
#define PLANE_KEYMAX_ALPHA(a) ((a) << 24)
+#define _PLANE_PIXEL_NORMALIZE_1_A 0x701a8
+#define _PLANE_PIXEL_NORMALIZE_2_A 0x702a8
+#define PLANE_PIXEL_NORMALIZE_ENABLE (1 << 31)
+#define PLANE_PIXEL_NORMALIZE_FACTOR_MASK0x
#define _PLANE_AUX_DIST_1_A0x701c0
#define _PLANE_AUX_DIST_2_A0x702c0
#define _PLANE_AUX_OFFSET_1_A 0x701c4
@@ -6786,7 +6790,16 @@ enum {
#define PLANE_COLOR_CTL(pipe, plane) \
_MMIO_PLANE(plane, _PLANE_COLOR_CTL_1(pipe), _PLANE_COLOR_CTL_2(pipe))
-#/* SKL new cursor registers */
+#define _PLANE_PIXEL_NORMALIZE_1_B 0x711a8
+#define _PLANE_PIXEL_NORMALIZE_2_B 0x712a8
+#define _PLANE_PIXEL_NORMALIZE_1(pipe) \
+ _PIPE(pipe, _PLANE_PIXEL_NORMALIZE_1_A, _PLANE_PIXEL_NORMALIZE_1_B)
+#define _PLANE_PIXEL_NORMALIZE_2(pipe) \
+ _PIPE(pipe, _PLANE_PIXEL_NORMALIZE_2_A, _PLANE_PIXEL_NORMALIZE_2_B)
+#define PLANE_PIXEL_NORMALIZE(pipe, plane) \
+ _MMIO_PLANE(plane, _PLANE_PIXEL_NORMALIZE_1(pipe),
_PLANE_PIXEL_NORMALIZE_2(pipe))
+
+/* SKL new cursor registers */
#define _CUR_BUF_CFG_A 0x7017c
#define _CUR_BUF_CFG_B 0x7117c
#define CUR_BUF_CFG(pipe) _MMIO_PIPE(pipe, _CUR_BUF_CFG_A, _CUR_BUF_CFG_B)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e9f4e22..cbacb4b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2618,6 +2618,18 @@ int skl_format_to_fourcc(int format, bool rgb_order,
bool alpha)
return DRM_FORMAT_RGB565;
case PLANE_CTL_FORMAT_NV12:
return DRM_FORMAT_NV12;
+ case PLANE_CTL_FORMAT_XRGB_16161616F:
+ if (rgb_order) {
+ if (alpha)
+ return DRM_FORMAT_ABGR16161616H;
+ else
+ return DRM_FORMAT_XBGR16161616H;
+ } else {
+ if (alpha)
+ return DRM_FORMAT_ARGB16161616H;
+ else
+ return DRM_FORMAT_XRGB16161616H;
+ }
default:
case PLANE_CTL_FORMAT_XRGB_:
if (rgb_order) {
@@ -3505,6 +3517,12 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_VYUY;
case DRM_FORMAT_NV12:
return PLANE_CTL_FORMAT_NV12;
+ case DRM_FORMAT_XBGR16161616H:
+ case DRM_FORMAT_ABGR16161616H:
+ return PLANE_CTL_FORMAT_XRGB_16161616F | PLANE_CTL_ORDER_RGBX;
+ case DRM_FORMAT_XRGB16161616H:
+ case DRM_FORMAT_ARGB16161616H:
+ return PLANE_CTL_FORMAT_XRGB_16161616F;
default:
MISSING_CASE(pixel_format);
}
@@ -3680,6 +3698,32 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state
*crtc_state,
return plane_color_ctl;
}
+u32 icl_plane_pixel_normalize(uint32_t pixel_format,
+ enum drm_pixel_normalize_range range)
+{
+ /* 1.0 in half float */
+ u16 half_float_1 = 0x3c00;
+ /* 3.92E-3 in half float */
+ u16 half_float_255 = 0x1c04;
+
+ switch (pixel_format) {
+ case DRM_FORMAT_XRGB16161616H:
+ case DRM_FORMAT_XBGR16161616H:
+ case DRM_FORMAT_ARGB16161616H:
+ case DRM_FORMAT_ABGR16161616H:
+ switch (range) {
+ case DRM_PIXEL_NORMALIZE_RANGE_0_1:
+ return PLANE_PIXEL_NORMALIZE_ENABLE | half_float_1;
+ case DRM_PIXEL_NORMALIZE_RANGE_0_255:
+ return
[PATCH AUTOSEL 4.19 28/68] drm/amd/display: Support amdgpu "max bpc" connector property (v2)
From: Nicholas Kazlauskas
[ Upstream commit 07e3a1cfb0568b6d8d7862077029af96af6690ea ]
[Why]
Many panels support more than 8bpc but some modes are unavailable while
running at greater than 8bpc due to DP/HDMI bandwidth constraints.
Support for more than 8bpc was added recently in the driver but it
defaults to the maximum supported bpc - locking out these modes.
This should be a user configurable option such that the user can select
what bpc configuration they would like.
[How]
This patch adds support for getting and setting the amdgpu driver
specific "max bpc" property on the connector.
It also adds support for limiting the output bpc based on the property
value. The default limitation is the lowest value in the range, 8bpc.
This was the old value before the range was uncapped.
This patch should be updated/replaced later once common drm support
for max bpc lands.
Bugzilla: https://bugs.freedesktop.org/108542
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201585
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200645
Fixes: e03fd3f300f6 ("drm/amd/display: Do not limit color depth to 8bpc")
v2: rebase on upstream (Alex)
Signed-off-by: Nicholas Kazlauskas
Acked-by: Alex Deucher
Reviewed-by: Harry Wentland
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c| 16
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h| 1 +
2 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index ef5c6af4d964..299def84e69c 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2213,8 +2213,15 @@ static void update_stream_scaling_settings(const struct
drm_display_mode *mode,
static enum dc_color_depth
convert_color_depth_from_display_info(const struct drm_connector *connector)
{
+ struct dm_connector_state *dm_conn_state =
+ to_dm_connector_state(connector->state);
uint32_t bpc = connector->display_info.bpc;
+ /* TODO: Remove this when there's support for max_bpc in drm */
+ if (dm_conn_state && bpc > dm_conn_state->max_bpc)
+ /* Round down to nearest even number. */
+ bpc = dm_conn_state->max_bpc - (dm_conn_state->max_bpc & 1);
+
switch (bpc) {
case 0:
/* Temporary Work around, DRM don't parse color depth for
@@ -2796,6 +2803,9 @@ int amdgpu_dm_connector_atomic_set_property(struct
drm_connector *connector,
} else if (property == adev->mode_info.underscan_property) {
dm_new_state->underscan_enable = val;
ret = 0;
+ } else if (property == adev->mode_info.max_bpc_property) {
+ dm_new_state->max_bpc = val;
+ ret = 0;
}
return ret;
@@ -2838,6 +2848,9 @@ int amdgpu_dm_connector_atomic_get_property(struct
drm_connector *connector,
} else if (property == adev->mode_info.underscan_property) {
*val = dm_state->underscan_enable;
ret = 0;
+ } else if (property == adev->mode_info.max_bpc_property) {
+ *val = dm_state->max_bpc;
+ ret = 0;
}
return ret;
}
@@ -3658,6 +3671,9 @@ void amdgpu_dm_connector_init_helper(struct
amdgpu_display_manager *dm,
drm_object_attach_property(>base.base,
adev->mode_info.underscan_vborder_property,
0);
+ drm_object_attach_property(>base.base,
+ adev->mode_info.max_bpc_property,
+ 0);
}
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index aba2c5c1d2f8..74aedcffc4bb 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -213,6 +213,7 @@ struct dm_connector_state {
enum amdgpu_rmx_type scaling;
uint8_t underscan_vborder;
uint8_t underscan_hborder;
+ uint8_t max_bpc;
bool underscan_enable;
struct mod_freesync_user_enable user_enable;
bool freesync_capable;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 27/68] drm/amdgpu: Add amdgpu "max bpc" connector property (v2)
From: Nicholas Kazlauskas
[ Upstream commit 69756c6ff0de478c10100481f16c966dde3b5339 ]
[Why]
Many panels support more than 8bpc but some modes are unavailable while
running at greater than 8bpc due to DP/HDMI bandwidth constraints.
Support for more than 8bpc was added recently in the driver but it
defaults to the maximum supported bpc - locking out these modes.
This should be a user configurable option such that the user can select
what bpc configuration they would like.
[How]
This patch introduces the "max bpc" amdgpu driver specific connector
property so the user can limit the maximum bpc. It ranges from 8 to 16.
This doesn't directly set the preferred bpc for the panel since it
follows Intel's existing driver conventions.
This proprety should be removed once common drm support for max bpc
lands.
v2: rebase on upstream (Alex)
Signed-off-by: Nicholas Kazlauskas
Acked-by: Alex Deucher
Reviewed-by: Harry Wentland
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 7 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h| 2 ++
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 6748cd7fc129..686a26de50f9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -626,6 +626,13 @@ int amdgpu_display_modeset_create_props(struct
amdgpu_device *adev)
"dither",
amdgpu_dither_enum_list, sz);
+ if (amdgpu_device_has_dc_support(adev)) {
+ adev->mode_info.max_bpc_property =
+ drm_property_create_range(adev->ddev, 0, "max bpc", 8,
16);
+ if (!adev->mode_info.max_bpc_property)
+ return -ENOMEM;
+ }
+
return 0;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
index b9e9e8b02fb7..d1b4d9b6aae0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
@@ -339,6 +339,8 @@ struct amdgpu_mode_info {
struct drm_property *audio_property;
/* FMT dithering */
struct drm_property *dither_property;
+ /* maximum number of bits per channel for monitor color */
+ struct drm_property *max_bpc_property;
/* hardcoded DFP edid from BIOS */
struct edid *bios_hardcoded_edid;
int bios_hardcoded_edid_size;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105725] WARNING: CPU: 0 PID: 487 at drivers/gpu/drm/amd/amdgpu/../display /dc/gpio/gpio_base.c:64 dal_gpio_open_ex+0xc/0x30 [amdgpu]
https://bugs.freedesktop.org/show_bug.cgi?id=105725 --- Comment #15 from Petr Cvek --- (In reply to hjpriester from comment #14) > I am now running 4.19.4 and did not get the messages anymore. > The messages where there from 4.5.11 to 4.18.16 I've got the warnings with vanilla 4.20-rc2 (-next-20181113) on RX460 card. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108317] [GCN3] Black Textures only on GCN3 in Cemu Zelda Breath of the Wild (OpenGL 4.5)
https://bugs.freedesktop.org/show_bug.cgi?id=108317 --- Comment #19 from John --- This is a problem with mesa master, I've never used mild myself and still have the issue. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106287] 18.0.1 introduced glitches in Dying Light
https://bugs.freedesktop.org/show_bug.cgi?id=106287 Timothy Arceri changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #13 from Timothy Arceri --- *** This bug has been marked as a duplicate of bug 107990 *** -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107990] Got Dying Light working in Arch by changing Mesa's compile steps, how to get it working Out Of the Box?
https://bugs.freedesktop.org/show_bug.cgi?id=107990 Timothy Arceri changed: What|Removed |Added CC||henrik.hol...@gmail.com --- Comment #6 from Timothy Arceri --- *** Bug 106287 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108317] [GCN3] Black Textures only on GCN3 in Cemu Zelda Breath of the Wild (OpenGL 4.5)
https://bugs.freedesktop.org/show_bug.cgi?id=108317 Timothy Arceri changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #18 from Timothy Arceri --- (In reply to John Galt from comment #12) > llvm 5.0.2 + mesa mild + http://sprunge.us/oPqhzd + polaris, still not past > the regression: https://i.imgur.com/RAOwPtM.png I had to do a google search to find out what "mesa mild" is. Please do not use this, it seems that was a hack to workaround the fact that radeonsi did not have compatibility profile support. The dev version of Mesa in git has had 4.5 support for a number of months now. As will the stable 18.3 release due out very soon. Can you check if this is still a problem in Mesa from git? There is no need to use "mesa mild" it's just forked version on Mesa from June. It seems the original author deleted the project when we got compat support in master and somebody has revived the repo. I really wish they had not done so. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 3/7] mm, devm_memremap_pages: Fix shutdown handling
On Tue, Nov 27, 2018 at 1:44 PM Logan Gunthorpe wrote:
>
> Hey Dan,
>
> On 2018-11-20 4:13 p.m., Dan Williams wrote:
> > The last step before devm_memremap_pages() returns success is to
> > allocate a release action, devm_memremap_pages_release(), to tear the
> > entire setup down. However, the result from devm_add_action() is not
> > checked.
> >
> > Checking the error from devm_add_action() is not enough. The api
> > currently relies on the fact that the percpu_ref it is using is killed
> > by the time the devm_memremap_pages_release() is run. Rather than
> > continue this awkward situation, offload the responsibility of killing
> > the percpu_ref to devm_memremap_pages_release() directly. This allows
> > devm_memremap_pages() to do the right thing relative to init failures
> > and shutdown.
> >
> > Without this change we could fail to register the teardown of
> > devm_memremap_pages(). The likelihood of hitting this failure is tiny as
> > small memory allocations almost always succeed. However, the impact of
> > the failure is large given any future reconfiguration, or
> > disable/enable, of an nvdimm namespace will fail forever as subsequent
> > calls to devm_memremap_pages() will fail to setup the pgmap_radix since
> > there will be stale entries for the physical address range.
> >
> > An argument could be made to require that the ->kill() operation be set
> > in the @pgmap arg rather than passed in separately. However, it helps
> > code readability, tracking the lifetime of a given instance, to be able
> > to grep the kill routine directly at the devm_memremap_pages() call
> > site.
> >
> > Cc:
> > Fixes: e8d513483300 ("memremap: change devm_memremap_pages interface...")
> > Reviewed-by: "Jérôme Glisse"
> > Reported-by: Logan Gunthorpe
> > Reviewed-by: Logan Gunthorpe
> > Reviewed-by: Christoph Hellwig
> > Signed-off-by: Dan Williams
>
> I recently realized this patch, which was recently added to the mm tree,
> will break p2pdma. This is largely because the patch was written and
> reviewed before p2pdma was merged (in 4.20). Originally, I think we both
> expected this patch would be merged before p2pdma but that's not what
> happened.
Indeed, sorry I missed this.
>
> Also, while testing this, I found the teardown is still not quite
> correct. In p2pdma, the struct pages will be removed before all of the
> percpu references have released and if the device is unbound while pages
> are in use, there will be a kernel panic. This is because we wait on the
> completion that indicates all references have been free'd after
> devm_memremap_pages_release() is called and the pages are removed. This
> is fairly easily fixed by waiting for the completion in the kill
> function and moving the call after the last put_page(). I suspect device
> DAX also has this problem but I'm not entirely certain if something else
> might be preventing us from hitting this bug.
>
> Ideally, as part of this patch we need to update the p2pdma call site
> for devm_memremap_pages() and fix the completion issue. The diff for all
> this is below, but if you'd like I can send a proper patch.
Yes, please send a proper patch. Although, I'm still not sure I see
the problem with the order of the percpu-ref kill. It's likely more
efficient to put the kill after the put_page() loop because the
percpu-ref will still be in "fast" per-cpu mode, but the kernel panic
should not be possible as long as their is a wait_for_completion()
before the exit, unless something else is wrong.
Certainly you can't move the wait_for_completion() into your ->kill()
callback without switching the ordering, but I'm not on board with
that change until I understand a bit more about why you think
device-dax might be broken?
I took a look at the p2pdma shutdown path and the:
if (percpu_ref_is_dying(ref))
return;
...looks fishy. If multiple agents can overlap their requests for the
same range why not track that simply as additional refs? Could it be
the crash that you are seeing is a result of mis-accounting when it is
safe to assume the page allocation can be freed?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows
https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #72 from Brandon Wright --- (In reply to bmilreu from comment #71) > @Nicholas Kazlauskas > any reason not to push this fix to staging or next? I agree. This will reduce stuttering for everyone, especially those who think the problem is caused elsewhere and just discount it as bad software or graphics card performance like I did. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/i915: change i915_sw_fence license to MIT
Change the license of the i915_sw_fence files to MIT matching most of the other i915 files. This makes it possible to use them in a new port of i915 to OpenBSD. Besides some mechanical tree wide changes Chris Wilson is the sole author of these files with Intel holding the copyright. Intel's legal team have given permission to change the license according to Joonas Lahtinen. v2: expand commit message and note permission from Intel legal Signed-off-by: Jonathan Gray Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Reviewed-by: Chris Wilson --- drivers/gpu/drm/i915/i915_sw_fence.c | 7 ++- drivers/gpu/drm/i915/i915_sw_fence.h | 5 ++--- 2 files changed, 4 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c b/drivers/gpu/drm/i915/i915_sw_fence.c index 6dbeed079ae5..fc2eeab823b7 100644 --- a/drivers/gpu/drm/i915/i915_sw_fence.c +++ b/drivers/gpu/drm/i915/i915_sw_fence.c @@ -1,10 +1,7 @@ /* - * (C) Copyright 2016 Intel Corporation + * SPDX-License-Identifier: MIT * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License - * as published by the Free Software Foundation; version 2 - * of the License. + * (C) Copyright 2016 Intel Corporation */ #include diff --git a/drivers/gpu/drm/i915/i915_sw_fence.h b/drivers/gpu/drm/i915/i915_sw_fence.h index fe2ef4dadfc6..0e055ea0179f 100644 --- a/drivers/gpu/drm/i915/i915_sw_fence.h +++ b/drivers/gpu/drm/i915/i915_sw_fence.h @@ -1,10 +1,9 @@ /* + * SPDX-License-Identifier: MIT + * * i915_sw_fence.h - library routines for N:M synchronisation points * * Copyright (C) 2016 Intel Corporation - * - * This file is released under the GPLv2. - * */ #ifndef _I915_SW_FENCE_H_ -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] 4.20.0-rc3 nouveau/Quadro P2000 Mobile: runpm causing ACPI errors, lockups
On Thu, Nov 29, 2018 at 12:21:31AM +0100, Karol Herbst wrote: > this was already debugged and there is no point in searching inside > the Firmware. It's not a firmware bug or anything. > > The proper fix is to do something inside Nouveau so that we don't > upset the device and being able to runtime resume it again. > > The initial thing we do inside Nouveau to cause those issues is to run > that so called "DEVINIT" script inside the vbios to initialize the > GPU, problem is, it changes something on the PCIe configuration so > that the GPU isn't able to runtime resume anymore. I am in contact > with Nvidia about that issue and hopefully we get the proper answers. > When I was digging into that myself I was able to make the situation > more stable by setting the PCIE link speed to the boot defaults, but > that was still pretty unstable. > > Anyway, because the binary driver fails here as well (through > bumblebee and so on) there isn't much of reverse engineering we can do > besides guessing and trying it on literally every hardware until it > works. > > We also have an upstream bug for this issue: > https://bugzilla.kernel.org/show_bug.cgi?id=156341 If you like I can probably dump the pcie registers on card and/or the pcie port under windows. The card works there :) Let me know. -- MST ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 3/6] drm/dp_mst: Start tracking per-port VCPI allocations
On Wed, 2018-11-28 at 09:17 +0100, Daniel Vetter wrote: > On Tue, Nov 27, 2018 at 08:44:14PM -0500, Lyude Paul wrote: > > On Tue, 2018-11-27 at 20:44 +0100, Daniel Vetter wrote: > > > > We could do this the other way around so it looks like this maybe > > > > struct kref; /* manages kfree() */ > > struct topology_kref; /* corresonds to lifetime in topology */ > > > > Then only expose functions for the normal kref to drivers, so that any > > possible confusion is still limited to drm_dp_mst_topology.c > > I like this bikeshed a lot. Since we need a bunch of the plain > kref_get/put internally, probably still good to have a wrapper. For that > the port_malloc_get/put() still sounds good to me - port_kfree_get/put > sounds confusing, since it's not the kfree we're refcounting, but the > memory allocation. > > Another option would be to add _topology to the public get/put functions, > but that makes for a fairly long function name :-/ bleh. Looked at not using a malloc() prefix in the naming but it's definitely still more confusing without one. I really do question if we really want the canonical naming prefix for the MST helpers to be drm_dp_mst_topology. It would be very nice to have this freed so we could do something like this: drm_dp_mst_topology_get_mstb() /* _kref */ drm_dp_mst_topology_put_mstb() /* _kref */ drm_dp_mst_get_mstb_malloc() /* */ drm_dp_mst_put_mstb_malloc() /* */ drm_dp_mst_topology_get_port() /* _kref */ drm_dp_mst_topology_put_port() /* _kref */ drm_dp_mst_get_port_malloc() /* */ drm_dp_mst_put_port_malloc() /* */ Additionally, I had an epiphany and figured out a seriously dead-simple rule that answers "what ref to use where" in the MST helper code: Let's start with a topology like this: |- mst_primary |- port #1 |- port #2 |- port #3 |- mstb #1 |- port #4 |- mstb #2 |- port #5 |- port #6 |- mstb #3 |- port #7 |- mstb #4 |- port #8 |- port #9 If mstb #1 was removed from the topology, ports 4-9 and mstbs 2-4 must lose their topology references. Simply put: each port holds a topology reference to it's mstb (if there is one), and each mstb holds a topology reference to it's ports. Now, let's allocate some payloads on the topology: |- mst_primary |- port #1 |- port #2 |- port #3 |- mstb #1 |- port #4 |- mstb #2 (has payload) |- port #5 |- port #6 |- mstb #3 |- port #7 |- mstb #4 (has payload) |- port #8 |- port #9 So, now if we remove mstb #1 any payloads under it need to be freed. Since mstb #4's and #2's parents no longer exist in the topology however, we must go back up the tree to find our last living relative. So: mstb #4 → port #7 → mstb #3 → port #6 → mstb #1 → port #3 for payload 1 mstb #4 → port #4 → mstb #1 → port #3 for payload 2 Going off this we can come up with the rule for malloc refs: each port holds a malloc ref to it's parent mstb, and each mstb holds a malloc ref to it's parent port (if there is one). So, it's just the reverse of the topology ref rule. Now just add refs for payloads and other stuff, and we're good. Hooray! Now I can also use this in any docs I write too :) > -Daniel > > > > > > -Daniel > > > > > > > > > > > Piles of comments below. > > > > > > > > > > > > Cheers, Daniel > > > > > > > > > > > > > - Use the small changes to drm_dp_put_port() to add even more > > > > > > > error > > > > > > >checking to make misusage of the helpers more obvious. I > > > > > > > added > > > > > > > this > > > > > > >after having to chase down various use-after-free conditions > > > > > > > that > > > > > > >started popping up from the new helpers so no one else has to > > > > > > >troubleshoot that. > > > > > > > - Move some accidental DRM_DEBUG_KMS() calls to > > > > > > > DRM_DEBUG_ATOMIC() > > > > > > > - Update documentation again, note that find/release() should > > > > > > > both > > > > > > > not > > > > > > > be > > > > > > >called on the same port in a single atomic check phase (but > > > > > > > multiple > > > > > > >calls to one or the other is OK) > > > > > > > > > > > > > > Changes since v4: > > > > > > > - Don't skip the atomic checks for VCPI allocations if no new > > > > > > > VCPI > > > > > > >allocations happen in a state. This makes the next change I'm > > > > > > > about > > > > > > >to list here a lot easier to implement. > > > > > > > - Don't ignore VCPI allocations on destroyed ports, instead > > > > > > > ensure > > > > > > > that > > > > > > >when ports are destroyed and still have VCPI allocations in > > > > > > > the > > > > > > >topology state, the only state changes allowed are releasing > > > > > > > said > > > > > > >ports'
[Bug 108572] Could not start gimp (probably due to opencl)
https://bugs.freedesktop.org/show_bug.cgi?id=108572 --- Comment #3 from Timothy Arceri --- If you build radeonsi with debug sysmbols i.e. use --enable-debug you should be able to run gimp in gdb and see exactly were the segfault is. Could be as simple as a NULL check missing somewhere. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH v3] arm64: dts: qcom: sdm845: Add dpu to sdm845 dts file
Hi,
On Wed, Nov 28, 2018 at 3:44 PM Jordan Crouse wrote:
>
> On Thu, Nov 01, 2018 at 07:25:23PM -0700, Jeykumar Sankaran wrote:
> > DPU is short for the Display Processing Unit. It is the display
> > controller on Qualcomm SDM845 chips.
> >
> > This change adds MDSS and DSI nodes to enable display on the
> > target device.
> >
> > Changes in v2:
> >- Beefed up commit message
> >- Use SoC specific compatibles for mdss and dpu (Rob H)
> >- Use assigned-clocks to set initial clock frequency(Rob H)
> > Changes in v3:
> >- added IOMMU node
> >- Fix device naming (remove _phys)
> >- Use correct IRQ_TYPE in interrupt specifiers
> >
> > Signed-off-by: Jeykumar Sankaran
> > Signed-off-by: Sean Paul
> > ---
> > arch/arm64/boot/dts/qcom/sdm845.dtsi | 191
> > +++
> > 1 file changed, 191 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > index 0c9a2aa..dd612ac 100644
> > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > @@ -978,6 +978,197 @@
> > #thermal-sensor-cells = <1>;
> > };
> >
> > + mdss: mdss@ae0 {
> > + compatible = "qcom,sdm845-mdss";
> > + reg = <0xae0 0x1000>;
> > + reg-names = "mdss";
> > +
> > + power-domains = < 0>;
>
> Would the powers-that-be in the power domain prefer this to have a symbolic
> value? I see MDSS_GDSC in the bindings header.
You're one patch version behind. Can you look at:
https://patchwork.kernel.org/patch/10666253/ AKA
https://lkml.kernel.org/r/1541197576-19730-2-git-send-email-jsa...@codeaurora.org
...that addresses the _clk issues and I commented about the #define too.
> > + phys = <_phy>;
> > + phy-names = "dsi-phy";
>
> This too, I reckon.
I didn't notice this one, so it's still "dsi-phy" in v4.
> > + dsi0_phy: dsi-phy@ae94400 {
> > + compatible = "qcom,dsi-phy-10nm";
> > + reg = <0xae94400 0x200>,
> > + <0xae94a00 0x1e0>,
> > + <0xae94600 0x280>;
>
> I think it would be better if these were in numerical order.
Still broken in v4.
Also Bjorn's thought about adding a 'status = "disabled"' also makes sense.
So I guess it's time for a v5 Jeykumar.
-Doug
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH v3] arm64: dts: qcom: sdm845: Add dpu to sdm845 dts file
On Thu, Nov 01, 2018 at 07:25:23PM -0700, Jeykumar Sankaran wrote:
> DPU is short for the Display Processing Unit. It is the display
> controller on Qualcomm SDM845 chips.
>
> This change adds MDSS and DSI nodes to enable display on the
> target device.
>
> Changes in v2:
>- Beefed up commit message
>- Use SoC specific compatibles for mdss and dpu (Rob H)
>- Use assigned-clocks to set initial clock frequency(Rob H)
> Changes in v3:
>- added IOMMU node
>- Fix device naming (remove _phys)
>- Use correct IRQ_TYPE in interrupt specifiers
>
> Signed-off-by: Jeykumar Sankaran
> Signed-off-by: Sean Paul
> ---
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 191
> +++
> 1 file changed, 191 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index 0c9a2aa..dd612ac 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -978,6 +978,197 @@
> #thermal-sensor-cells = <1>;
> };
>
> + mdss: mdss@ae0 {
> + compatible = "qcom,sdm845-mdss";
> + reg = <0xae0 0x1000>;
> + reg-names = "mdss";
> +
> + power-domains = < 0>;
Would the powers-that-be in the power domain prefer this to have a symbolic
value? I see MDSS_GDSC in the bindings header.
> +
> + clocks = < GCC_DISP_AHB_CLK>,
> + < GCC_DISP_AXI_CLK>,
> + < DISP_CC_MDSS_MDP_CLK>;
> + clock-names = "iface", "bus", "core";
> +
> + assigned-clocks = < DISP_CC_MDSS_MDP_CLK>;
> + assigned-clock-rates = <3>;
> +
> + interrupts = ;
> + interrupt-controller;
> + #interrupt-cells = <1>;
> +
> + iommus = <_smmu 0x880 0x8>,
> + <_smmu 0xc80 0x8>;
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + mdss_mdp: mdp@ae01000 {
> + compatible = "qcom,sdm845-dpu";
> + reg = <0x0ae01000 0x8f000>,
> + <0x0aeb 0x2008>;
> + reg-names = "mdp", "vbif";
> +
> + clocks = < DISP_CC_MDSS_AHB_CLK>,
> + < DISP_CC_MDSS_AXI_CLK>,
> + < DISP_CC_MDSS_MDP_CLK>,
> + < DISP_CC_MDSS_VSYNC_CLK>;
> + clock-names = "iface", "bus", "core", "vsync";
> +
> + assigned-clocks = <
> DISP_CC_MDSS_MDP_CLK>,
> + <
> DISP_CC_MDSS_VSYNC_CLK>;
> + assigned-clock-rates = <3>,
> +<1920>;
> +
> + interrupt-parent = <>;
> + interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + dpu_intf1_out: endpoint {
> + remote-endpoint =
> <_in>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + dpu_intf2_out: endpoint {
> + remote-endpoint =
> <_in>;
> + };
> + };
> + };
> + };
> +
> + dsi0: dsi@ae94000 {
> + compatible = "qcom,mdss-dsi-ctrl";
> + reg = <0xae94000 0x400>;
> + reg-names = "dsi_ctrl";
> +
> + interrupt-parent = <>;
> + interrupts = <4 IRQ_TYPE_LEVEL_HIGH>;
> +
> + clocks = < DISP_CC_MDSS_BYTE0_CLK>,
> + < DISP_CC_MDSS_BYTE0_INTF_CLK>,
> + < DISP_CC_MDSS_PCLK0_CLK>,
> + < DISP_CC_MDSS_ESC0_CLK>,
> + < DISP_CC_MDSS_AHB_CLK>,
> + < DISP_CC_MDSS_AXI_CLK>;
> +
Re: [PATCH 2/2] drm/ast: Fix connector leak during driver unload
On Mon, 5 Nov 2018 at 15:59, Sam Bobroff wrote:
>
> When unloading the ast driver, a warning message is printed by
> drm_mode_config_cleanup() because a reference is still held to one of
> the drm_connector structs.
>
> Correct this by calling drm_framebuffer_remove() in
> ast_fbdev_destroy().
>
> Signed-off-by: Sam Bobroff
> ---
> drivers/gpu/drm/ast/ast_fb.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
> index 0cd827e11fa2..655372ea81e9 100644
> --- a/drivers/gpu/drm/ast/ast_fb.c
> +++ b/drivers/gpu/drm/ast/ast_fb.c
> @@ -263,6 +263,10 @@ static void ast_fbdev_destroy(struct drm_device *dev,
> {
> struct ast_framebuffer *afb = >afb;
>
> + /* drm_framebuffer_remove() expects us to hold a ref, which it
> +* will drop, so take one: */
> + drm_framebuffer_get(>base);
> + drm_framebuffer_remove(>base);
This doesn't seem corret, no other driver does this pattern, and I
can't believe ast is special here.
The get just doesn't make sense.
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] 4.20.0-rc3 nouveau/Quadro P2000 Mobile: runpm causing ACPI errors, lockups
this was already debugged and there is no point in searching inside
the Firmware. It's not a firmware bug or anything.
The proper fix is to do something inside Nouveau so that we don't
upset the device and being able to runtime resume it again.
The initial thing we do inside Nouveau to cause those issues is to run
that so called "DEVINIT" script inside the vbios to initialize the
GPU, problem is, it changes something on the PCIe configuration so
that the GPU isn't able to runtime resume anymore. I am in contact
with Nvidia about that issue and hopefully we get the proper answers.
When I was digging into that myself I was able to make the situation
more stable by setting the PCIE link speed to the boot defaults, but
that was still pretty unstable.
Anyway, because the binary driver fails here as well (through
bumblebee and so on) there isn't much of reverse engineering we can do
besides guessing and trying it on literally every hardware until it
works.
We also have an upstream bug for this issue:
https://bugzilla.kernel.org/show_bug.cgi?id=156341
On Wed, Nov 28, 2018 at 9:30 PM Michael S. Tsirkin wrote:
>
> On Wed, Nov 28, 2018 at 05:55:44PM +0200, Mika Westerberg wrote:
> > On Wed, Nov 28, 2018 at 10:09:22AM -0500, Michael S. Tsirkin wrote:
> > > Yea all this is weird, in particular I wonder why does everyone
> > > using dsm insists on saying Arg4
> > > when they actually mean Arg3. ACPI numbers arguments from 0.
> > >
> > > So it's a bit ugly, and maybe worth fixing but unlikely to be
> > > an actual issue simply because we end up not using DSM in the end.
> >
> > I agree.
> >
> > > Poking at the probing code in nouveau_pr3_present, I started to wonder:
> > > should I try to hack it to disable d3cold and pr3 and see what
> > > happens?
> >
> > I guess it is worth a try. You can do it from sysfs for the graphics
> > PCI device there is an attribute d3cold_allowed that controls this.
> >
> > [snip]
>
> But probably too late by time nouveau is up at boot?
>
> > > > > 00:14.3 Network controller: Intel Corporation Wireless-AC 9560
> > > > > [Jefferson Peak] (rev 10)
> > > > >
> > > > > so really shouldn't be affected, but go figure. If driver really is
> > > > > getting
> > > > > all-ones from the device, it just might try to poke at a wrong b:d.f
> > > > > by mistake
> > > > > maybe ...
> > > >
> > > > Or it the power resource is shared by wifi as well.
> > >
> > > Is there a way to find out through e.g. sysfs?
> >
> > It is not shared, I checked from the acpidump you provided. Possibly the
> > infinite loop in AML when executing NVPO method have some effect on
> > this.
> >
> > [snip]
> >
> > > > No need to send, I can read it from the bugzilla just fine. Can you
> > > > attach
> > > > acpidump there as well?
> > >
> > > Done. lspci -x too just in case.
> >
> > Looking at the dmesg:
> >
> > [ 52.917009] No Local Variables are initialized for Method [NVPO]
> > [ 52.917011] No Arguments are initialized for method [NVPO]
> > [ 52.917012] ACPI Error: Method parse/execution failed
> > \_SB.PCI0.PEG0.PEGP.NVPO, AE_AML_LOOP_TIMEOUT (20181003/psparse-516)
> > [ 52.917063] ACPI Error: Method parse/execution failed \_SB.PCI0.PGON,
> > AE_AML_LOOP_TIMEOUT (20181003/psparse-516)
> > [ 52.917084] ACPI Error: Method parse/execution failed
> > \_SB.PCI0.PEG0.PG00._ON, AE_AML_LOOP_TIMEOUT (20181003/psparse-516)
> >
> > So what happens here is that Linux turns off power resource
> > \_SB.PCI0.PEG0.PG00 by calling its _OFF method (happens when the root
> > port is runtime suspended). This ends up calling \_SB.PCI0.PGON which
> > calls \_SB.PCI0.PEG0.PEGP.NVPO.
> >
> > The last method looks like this:
> >
> >Method (NVPO, 0, NotSerialized)
> > {
> > While ((\_SB.PCI0.P0LS < 0x03))
> > {
> > Sleep (One)
> > }
> >
> > So basically it polls P0LS register infinitely if the returned value is
> > less than 3. I suspect this is the issue and it then makes the other
> > like wifi to fail to execute its methods.
> >
> > P0LS comes from this operation region:
> >
> > OperationRegion (OPG0, SystemMemory, (XBAS + 0x8000), 0x1000)
> > Field (OPG0, AnyAcc, NoLock, Preserve)
> > {
> > ...
> > Offset (0x216),
> > P0LS, 4,
> >
> > This is some host bridge register but not sure which because XBAS value
> > cannot be determined from the acpidump.
>
> Oh I think XBAS is in SSDT4:
>
> OperationRegion (SANV, SystemMemory, 0x4FBF7018, 0x01F4)
> Field (SANV, AnyAcc, Lock, Preserve)
> {
> ASLB, 32,
> IMON, 8,
> IGDS, 8,
> IBTT, 8,
> IPAT, 8,
> IPSC, 8,
> IBIA, 8,
> ISSC, 8,
> IDMS, 8,
> IF1E, 8,
> HVCO, 8,
> GSMI, 8,
> PAVP, 8,
> CADL, 8,
> CSTE, 16,
> NSTE, 16,
> NDID, 8,
> DID1, 32,
> DID2, 32,
>
[Bug 108311] Query buffer object support is broken on r600.
https://bugs.freedesktop.org/show_bug.cgi?id=108311 Dave Airlie changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Dave Airlie --- I pushed my patch for simplicity sakes, I don't think we'd notice the difference in perf or mem usage. Thanks for pointing out the problem and the first patch! -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/v3d: Fix prime imports of buffers from other drivers.
v3d_bo_get_pages() checks this to decide to map the imported buffer
instead of the backing shmem file. The caller was about to set this
value anyway, and there's no error path in between. Ideally we
wouldn't even allocate the shmem file for our imports, but that's a
more invasive fix.
Signed-off-by: Eric Anholt
Fixes: 57692c94dcbe ("drm/v3d: Introduce a new DRM driver for Broadcom V3D
V3.x+")
Cc: Dave Emett
---
I've been sitting on this one because I don't like it and was hoping
the shmem library would pan out. This is a useful patch for now,
though.
drivers/gpu/drm/v3d/v3d_bo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/v3d/v3d_bo.c b/drivers/gpu/drm/v3d/v3d_bo.c
index 54d96518a131..a08766d39eab 100644
--- a/drivers/gpu/drm/v3d/v3d_bo.c
+++ b/drivers/gpu/drm/v3d/v3d_bo.c
@@ -293,6 +293,7 @@ v3d_prime_import_sg_table(struct drm_device *dev,
bo->resv = attach->dmabuf->resv;
bo->sgt = sgt;
+ obj->import_attach = attach;
v3d_bo_get_pages(bo);
v3d_mmu_insert_ptes(bo);
--
2.20.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108825] Regression Raven Ridge: Banding on eDP display
https://bugs.freedesktop.org/show_bug.cgi?id=108825 --- Comment #12 from Samantha McVey --- Nicholas, Your last patch but with `new_state->max_bpc = state->max_bpc;` instead of `new_state->max_bpc = cur->max_bpc;` resolves the issue. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/v3d: Add support for submitting jobs to the TFU.
The TFU can copy from raster, UIF, and SAND input images to UIF output
images, with optional mipmap generation. This will certainly be
useful for media EGL image input, but is also useful immediately for
mipmap generation without bogging the V3D core down.
For now we only run the queue 1 job deep, and don't have any hang
recovery (though I don't think we should need it, with TFU). Queuing
multiple jobs in the HW will require synchronizing the YUV coefficient
regs updates since they don't get FIFOed with the job.
v2: Change the ioctl to IOW instead of IOWR, always set COEF0, explain
why TFU is AUTH, clarify the syncing docs, drop the unused TFU
interrupt regs (you're expected to use the hub's), don't take
>base for NULL bos.
Signed-off-by: Eric Anholt
Cc: Dave Emett
---
drivers/gpu/drm/v3d/v3d_drv.c | 15 ++-
drivers/gpu/drm/v3d/v3d_drv.h | 32 +-
drivers/gpu/drm/v3d/v3d_gem.c | 178
drivers/gpu/drm/v3d/v3d_irq.c | 12 ++-
drivers/gpu/drm/v3d/v3d_regs.h | 49 +
drivers/gpu/drm/v3d/v3d_sched.c | 147 ++
drivers/gpu/drm/v3d/v3d_trace.h | 20
include/uapi/drm/v3d_drm.h | 25 +
8 files changed, 426 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c
index 4857c0a63131..0c59a7e16275 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.c
+++ b/drivers/gpu/drm/v3d/v3d_drv.c
@@ -184,10 +184,15 @@ static int v3d_get_param_ioctl(struct drm_device *dev,
void *data,
return 0;
}
- /* Any params that aren't just register reads would go here. */
- DRM_DEBUG("Unknown parameter %d\n", args->param);
- return -EINVAL;
+ switch (args->param) {
+ case DRM_V3D_PARAM_SUPPORTS_TFU:
+ args->value = 1;
+ return 0;
+ default:
+ DRM_DEBUG("Unknown parameter %d\n", args->param);
+ return -EINVAL;
+ }
}
static int
@@ -242,7 +247,8 @@ static const struct file_operations v3d_drm_fops = {
/* DRM_AUTH is required on SUBMIT_CL for now, while we don't have GMP
* protection between clients. Note that render nodes would be be
* able to submit CLs that could access BOs from clients authenticated
- * with the master node.
+ * with the master node. The TFU doesn't use the GMP, so it would
+ * need to stay DRM_AUTH until we do buffer size/offset validation.
*/
static const struct drm_ioctl_desc v3d_drm_ioctls[] = {
DRM_IOCTL_DEF_DRV(V3D_SUBMIT_CL, v3d_submit_cl_ioctl, DRM_RENDER_ALLOW
| DRM_AUTH),
@@ -251,6 +257,7 @@ static const struct drm_ioctl_desc v3d_drm_ioctls[] = {
DRM_IOCTL_DEF_DRV(V3D_MMAP_BO, v3d_mmap_bo_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(V3D_GET_PARAM, v3d_get_param_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(V3D_GET_BO_OFFSET, v3d_get_bo_offset_ioctl,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(V3D_SUBMIT_TFU, v3d_submit_tfu_ioctl,
DRM_RENDER_ALLOW | DRM_AUTH),
};
static const struct vm_operations_struct v3d_vm_ops = {
diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index 83c55ab6e1c0..e0624ea72942 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -8,19 +8,18 @@
#include
#include
#include
+#include "uapi/drm/v3d_drm.h"
#define GMP_GRANULARITY (128 * 1024)
-/* Enum for each of the V3D queues. We maintain various queue
- * tracking as an array because at some point we'll want to support
- * the TFU (texture formatting unit) as another queue.
- */
+/* Enum for each of the V3D queues. */
enum v3d_queue {
V3D_BIN,
V3D_RENDER,
+ V3D_TFU,
};
-#define V3D_MAX_QUEUES (V3D_RENDER + 1)
+#define V3D_MAX_QUEUES (V3D_TFU + 1)
struct v3d_queue_state {
struct drm_gpu_scheduler sched;
@@ -74,6 +73,7 @@ struct v3d_dev {
struct v3d_exec_info *bin_job;
struct v3d_exec_info *render_job;
+ struct v3d_tfu_job *tfu_job;
struct v3d_queue_state queue[V3D_MAX_QUEUES];
@@ -224,6 +224,25 @@ struct v3d_exec_info {
u32 qma, qms, qts;
};
+struct v3d_tfu_job {
+ struct drm_sched_job base;
+
+ struct drm_v3d_submit_tfu args;
+
+ /* An optional fence userspace can pass in for the job to depend on. */
+ struct dma_fence *in_fence;
+
+ /* v3d fence to be signaled by IRQ handler when the job is complete. */
+ struct dma_fence *done_fence;
+
+ struct v3d_dev *v3d;
+
+ struct kref refcount;
+
+ /* This is the array of BOs that were looked up at the start of exec. */
+ struct v3d_bo *bo[4];
+};
+
/**
* _wait_for - magic (register) wait macro
*
@@ -287,9 +306,12 @@ int v3d_gem_init(struct drm_device *dev);
void v3d_gem_destroy(struct drm_device *dev);
int v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
+int v3d_submit_tfu_ioctl(struct drm_device *dev,
[PATCH 2/3] drm/v3d: Drop the "dev" argument to lock/unlock of BO reservations.
They were unused, as Dave Emett noticed in TFU review.
Signed-off-by: Eric Anholt
Cc: Dave Emett
---
drivers/gpu/drm/v3d/v3d_gem.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index 41cbe2cdad50..778657d9b6e7 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -219,8 +219,7 @@ v3d_attach_object_fences(struct v3d_bo **bos, int bo_count,
}
static void
-v3d_unlock_bo_reservations(struct drm_device *dev,
- struct v3d_bo **bos,
+v3d_unlock_bo_reservations(struct v3d_bo **bos,
int bo_count,
struct ww_acquire_ctx *acquire_ctx)
{
@@ -240,8 +239,7 @@ v3d_unlock_bo_reservations(struct drm_device *dev,
* to v3d, so we don't attach dma-buf fences to them.
*/
static int
-v3d_lock_bo_reservations(struct drm_device *dev,
-struct v3d_bo **bos,
+v3d_lock_bo_reservations(struct v3d_bo **bos,
int bo_count,
struct ww_acquire_ctx *acquire_ctx)
{
@@ -298,7 +296,7 @@ v3d_lock_bo_reservations(struct drm_device *dev,
for (i = 0; i < bo_count; i++) {
ret = reservation_object_reserve_shared(bos[i]->resv, 1);
if (ret) {
- v3d_unlock_bo_reservations(dev, bos, bo_count,
+ v3d_unlock_bo_reservations(bos, bo_count,
acquire_ctx);
return ret;
}
@@ -566,7 +564,7 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
if (ret)
goto fail;
- ret = v3d_lock_bo_reservations(dev, exec->bo, exec->bo_count,
+ ret = v3d_lock_bo_reservations(exec->bo, exec->bo_count,
_ctx);
if (ret)
goto fail;
@@ -604,7 +602,7 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
v3d_attach_object_fences(exec->bo, exec->bo_count,
exec->render_done_fence);
- v3d_unlock_bo_reservations(dev, exec->bo, exec->bo_count, _ctx);
+ v3d_unlock_bo_reservations(exec->bo, exec->bo_count, _ctx);
/* Update the return sync object for the */
sync_out = drm_syncobj_find(file_priv, args->out_sync);
@@ -620,7 +618,7 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
fail_unreserve:
mutex_unlock(>sched_lock);
- v3d_unlock_bo_reservations(dev, exec->bo, exec->bo_count, _ctx);
+ v3d_unlock_bo_reservations(exec->bo, exec->bo_count, _ctx);
fail:
v3d_exec_put(exec);
@@ -691,7 +689,7 @@ v3d_submit_tfu_ioctl(struct drm_device *dev, void *data,
}
spin_unlock(_priv->table_lock);
- ret = v3d_lock_bo_reservations(dev, job->bo, bo_count, _ctx);
+ ret = v3d_lock_bo_reservations(job->bo, bo_count, _ctx);
if (ret)
goto fail;
@@ -710,7 +708,7 @@ v3d_submit_tfu_ioctl(struct drm_device *dev, void *data,
v3d_attach_object_fences(job->bo, bo_count, sched_done_fence);
- v3d_unlock_bo_reservations(dev, job->bo, bo_count, _ctx);
+ v3d_unlock_bo_reservations(job->bo, bo_count, _ctx);
/* Update the return sync object */
sync_out = drm_syncobj_find(file_priv, args->out_sync);
@@ -726,7 +724,7 @@ v3d_submit_tfu_ioctl(struct drm_device *dev, void *data,
fail_unreserve:
mutex_unlock(>sched_lock);
- v3d_unlock_bo_reservations(dev, job->bo, bo_count, _ctx);
+ v3d_unlock_bo_reservations(job->bo, bo_count, _ctx);
fail:
v3d_tfu_job_put(job);
--
2.20.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm: Add DRM_MODESET_LOCK_BEGIN/END helpers
On Wed, Nov 28, 2018 at 09:31:11AM -0500, Sean Paul wrote: > On Wed, Nov 28, 2018 at 10:01:07AM +0100, Daniel Vetter wrote: > > On Tue, Nov 27, 2018 at 05:46:40PM -0500, Sean Paul wrote: > > > diff --git a/include/drm/drm_modeset_lock.h > > > b/include/drm/drm_modeset_lock.h > > > index a685d1bb21f26..6213a11445633 100644 > > > --- a/include/drm/drm_modeset_lock.h > > > +++ b/include/drm/drm_modeset_lock.h > > > @@ -130,4 +130,58 @@ void drm_warn_on_modeset_not_all_locked(struct > > > drm_device *dev); > > > int drm_modeset_lock_all_ctx(struct drm_device *dev, > > >struct drm_modeset_acquire_ctx *ctx); > > > > > > +/** > > > + * DRM_MODESET_LOCK_ALL_BEGIN - Helper to acquire modeset locks > > > + * @dev: drm device > > > + * @ret: local ret/err/etc variable to track error status > > > + * @ctx: local modeset acquire context, will be dereferenced > > > + * @flags: DRM_MODESET_ACQUIRE_* flags to pass to acquire_init() > > > > Full function name for the nice hyperlink. Needs a continuation line, > > which just needs to be indentend. > > > > And a bikeshed: I'd put ret last in both macros, I think that's where > > usually the cursors/output variables are. > > For _BEGIN is effectively a void, since it can't return with anything but > ret==0. I agonized a little over doing this for _END, but figured since it was > setting the value of ret, it might be misleading to put it at the end since > folks might not realize that if they ignore it ret can still change (if that > makes sense). In other words, I don't want people to think that: > > ret = DRM_MODESET_LOCAL_ALL_END(ret, ctx); > > behaves differently than > > DRM_MODESET_LOCAL_ALL_END(ret, ctx); > > By not allowing the assignment, it might poke people to think more about ret > on > END. > > I'm happy to have my mind changed on this, but figured context would be > useful. > > All other bikesheds LGTM. I think I wasn't clear enough: I meant to put ret last in the parameter list of each. Especially the (ret, ctx) ordering looks very strange to me. Definitely agreed that these macros shouldn't have some kind of contrived return value. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm: Add DRM_MODESET_LOCK_BEGIN/END helpers
On Wed, Nov 28, 2018 at 11:59:48AM -0500, Sean Paul wrote: > On Wed, Nov 28, 2018 at 10:01:07AM +0100, Daniel Vetter wrote: > > On Tue, Nov 27, 2018 at 05:46:40PM -0500, Sean Paul wrote: > > } > > > diff --git a/include/drm/drm_modeset_lock.h > > > b/include/drm/drm_modeset_lock.h > > > index a685d1bb21f26..6213a11445633 100644 > > > --- a/include/drm/drm_modeset_lock.h > > > +++ b/include/drm/drm_modeset_lock.h > > > @@ -130,4 +130,58 @@ void drm_warn_on_modeset_not_all_locked(struct > > > drm_device *dev); > > > int drm_modeset_lock_all_ctx(struct drm_device *dev, > > >struct drm_modeset_acquire_ctx *ctx); > > > > > > +/** > > > + * DRM_MODESET_LOCK_ALL_BEGIN - Helper to acquire modeset locks > > > + * @dev: drm device > > > + * @ret: local ret/err/etc variable to track error status > > > + * @ctx: local modeset acquire context, will be dereferenced > > > + * @flags: DRM_MODESET_ACQUIRE_* flags to pass to acquire_init() > > > > Full function name for the nice hyperlink. Needs a continuation line, > > which just needs to be indentend. > > This isn't a function, but a series of flags prefixed with > DRM_MODESET_ACQUIRE_ > (currently only one there, but perhaps more could come). I meant you should spell out drm_modeset_acquire_init() in full. For the hyperlink. Wrt DRM_MODESET_LOCAL_ALL_END() just being a #define: I think kerneldoc treats that as a function too, and you can link to it like a normal function. Good to double-check with $ make htmldocs Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108572] Could not start gimp (probably due to opencl)
https://bugs.freedesktop.org/show_bug.cgi?id=108572 Marco changed: What|Removed |Added Component|Gallium/StateTracker/Clover |Drivers/Gallium/radeonsi Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org QA Contact|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108891] Test enumeration becomes funky on some tests due to fd FILE* stream change
https://bugs.freedesktop.org/show_bug.cgi?id=108891
--- Comment #3 from Chris Wilson ---
diff --git a/lib/igt_core.c b/lib/igt_core.c
index e0989f53..bd600762 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -1116,30 +1116,28 @@ void igt_fail(int exitcode)
if (in_atexit_handler)
_exit(IGT_EXIT_FAILURE);
- if (!failed_one)
- igt_exitcode = exitcode;
-
- failed_one = true;
-
/* Silent exit, parent will do the yelling. */
if (test_child)
exit(exitcode);
+ if (in_fixture) {
+ skip_subtests_henceforth = FAIL;
+ __igt_fixture_end();
+ }
+
_igt_log_buffer_dump();
+ if (!failed_one) {
+ igt_exitcode = exitcode;
+ failed_one = true;
+ }
+
if (in_subtest) {
if (exitcode == IGT_EXIT_TIMEOUT)
exit_subtest("TIMEOUT");
else
exit_subtest("FAIL");
} else {
- assert(igt_can_fail());
-
- if (in_fixture) {
- skip_subtests_henceforth = FAIL;
- __igt_fixture_end();
- }
-
igt_exit();
}
}
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108891] Test enumeration becomes funky on some tests due to fd FILE* stream change
https://bugs.freedesktop.org/show_bug.cgi?id=108891 Chris Wilson changed: What|Removed |Added Resolution|NOTABUG |--- Status|RESOLVED|REOPENED --- Comment #4 from Chris Wilson --- Just a very misleading bisect. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/dp-mst-helper: Remove hotplug callback
When everyone implements it exactly the same way, among all 4
implementations, there's not really a need to overwrite this at all.
Aside: drm_kms_helper_hotplug_event is pretty much core functionality
at this point. Probably should move it there.
Signed-off-by: Daniel Vetter
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 9 -
drivers/gpu/drm/drm_dp_mst_topology.c | 7 ---
drivers/gpu/drm/i915/intel_dp_mst.c| 10 --
drivers/gpu/drm/nouveau/dispnv50/disp.c| 8
drivers/gpu/drm/radeon/radeon_dp_mst.c | 9 -
include/drm/drm_dp_mst_helper.h| 2 --
6 files changed, 4 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index d02c32a1039c..9fdeca096407 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -396,14 +396,6 @@ static void dm_dp_destroy_mst_connector(struct
drm_dp_mst_topology_mgr *mgr,
drm_connector_put(connector);
}
-static void dm_dp_mst_hotplug(struct drm_dp_mst_topology_mgr *mgr)
-{
- struct amdgpu_dm_connector *master = container_of(mgr, struct
amdgpu_dm_connector, mst_mgr);
- struct drm_device *dev = master->base.dev;
-
- drm_kms_helper_hotplug_event(dev);
-}
-
static void dm_dp_mst_register_connector(struct drm_connector *connector)
{
struct drm_device *dev = connector->dev;
@@ -420,7 +412,6 @@ static void dm_dp_mst_register_connector(struct
drm_connector *connector)
static const struct drm_dp_mst_topology_cbs dm_mst_cbs = {
.add_connector = dm_dp_add_mst_connector,
.destroy_connector = dm_dp_destroy_mst_connector,
- .hotplug = dm_dp_mst_hotplug,
.register_connector = dm_dp_mst_register_connector
};
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 08978ad72f33..639552918b44 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
/**
* DOC: dp mst helper
@@ -1650,7 +1651,7 @@ static void drm_dp_send_link_address(struct
drm_dp_mst_topology_mgr *mgr,
for (i = 0; i < txmsg->reply.u.link_addr.nports; i++) {
drm_dp_add_port(mstb, mgr->dev,
>reply.u.link_addr.ports[i]);
}
- (*mgr->cbs->hotplug)(mgr);
+ drm_kms_helper_hotplug_event(mgr->dev);
}
} else {
mstb->link_address_sent = false;
@@ -2423,7 +2424,7 @@ static int drm_dp_mst_handle_up_req(struct
drm_dp_mst_topology_mgr *mgr)
drm_dp_update_port(mstb, _stat);
DRM_DEBUG_KMS("Got CSN: pn: %d ldps:%d ddps: %d mcs: %d
ip: %d pdt: %d\n", msg.u.conn_stat.port_number,
msg.u.conn_stat.legacy_device_plug_status,
msg.u.conn_stat.displayport_device_plug_status,
msg.u.conn_stat.message_capability_status, msg.u.conn_stat.input_port,
msg.u.conn_stat.peer_device_type);
- (*mgr->cbs->hotplug)(mgr);
+ drm_kms_helper_hotplug_event(mgr->dev);
} else if (msg.req_type == DP_RESOURCE_STATUS_NOTIFY) {
drm_dp_send_up_ack_reply(mgr, mgr->mst_primary,
msg.req_type, seqno, false);
@@ -3120,7 +3121,7 @@ static void drm_dp_destroy_connector_work(struct
work_struct *work)
send_hotplug = true;
}
if (send_hotplug)
- (*mgr->cbs->hotplug)(mgr);
+ drm_kms_helper_hotplug_event(mgr->dev);
}
static struct drm_private_state *
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 4de247ddf05f..f05427b74e34 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -517,20 +517,10 @@ static void intel_dp_destroy_mst_connector(struct
drm_dp_mst_topology_mgr *mgr,
drm_connector_put(connector);
}
-static void intel_dp_mst_hotplug(struct drm_dp_mst_topology_mgr *mgr)
-{
- struct intel_dp *intel_dp = container_of(mgr, struct intel_dp, mst_mgr);
- struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
- struct drm_device *dev = intel_dig_port->base.base.dev;
-
- drm_kms_helper_hotplug_event(dev);
-}
-
static const struct drm_dp_mst_topology_cbs mst_cbs = {
.add_connector = intel_dp_add_mst_connector,
.register_connector = intel_dp_register_mst_connector,
.destroy_connector = intel_dp_destroy_mst_connector,
- .hotplug = intel_dp_mst_hotplug,
};
static struct intel_dp_mst_encoder *
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index
[Bug 108825] Regression Raven Ridge: Banding on eDP display
https://bugs.freedesktop.org/show_bug.cgi?id=108825 --- Comment #11 from Samantha McVey --- new_state->max_bpc = cur->max_bpc; cur doesn't exist here (fails to compile with v2 patch). Did you mean state->max_bpc? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108891] Test enumeration becomes funky on some tests due to fd FILE* stream change
https://bugs.freedesktop.org/show_bug.cgi?id=108891 Chris Wilson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG --- Comment #2 from Chris Wilson --- Different subgroup, not affecting basic-busy-default, but rightfully preventing you from running any of the hang tests. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v5 4/5] drm: Add library for shmem backed GEM objects
Daniel Vetter writes:
> On Tue, Nov 27, 2018 at 12:38:44PM -0800, Eric Anholt wrote:
>> Daniel Vetter writes:
>>
>> > On Mon, Nov 26, 2018 at 04:36:21PM -0800, Eric Anholt wrote:
>> >> Noralf Trønnes writes:
>> >> > +static void drm_gem_shmem_vm_close(struct vm_area_struct *vma)
>> >> > +{
>> >> > + struct drm_gem_object *obj = vma->vm_private_data;
>> >> > + struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
>> >> > +
>> >> > + drm_gem_shmem_put_pages(shmem);
>> >> > + drm_gem_vm_close(vma);
>> >> > +}
>> >> > +
>> >> > +const struct vm_operations_struct drm_gem_shmem_vm_ops = {
>> >> > + .fault = drm_gem_shmem_fault,
>> >> > + .open = drm_gem_vm_open,
>> >> > + .close = drm_gem_shmem_vm_close,
>> >> > +};
>> >> > +EXPORT_SYMBOL_GPL(drm_gem_shmem_vm_ops);
>> >>
>> >> I just saw a warning from drm_gem_shmem_put_pages() for
>> >> !shmem->pages_use_count -- I think drm_gem_vm_open() needs to
>> >> drm_gem_shmem_get_pages().
>> >
>> > Yeah we need a drm_gem_shmem_vm_open here.
>>
>> Adding one of those fixed my refcounting issues, so I've sent out a v6
>> with it.
>
> Just realized that I've reviewed this patch already, spotted that vma
> management issue there too. Plus a pile of other things. From reading that
> other thread discussion with Noralf concluded with "not yet ready for
> prime time" unfortunately :-/
I saw stuff about how it wasn't usable for SPI because SPI does weird
things with DMA mapping. Was there something else?
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: Fix plane duplicate_state
Daniel Vetter writes: > We need to handle allocation failures and bail out. While at it, tune > the allocation failures down to debug level. > > syzbot injected an allocation failure and then hit this WARN_ON. r-b. I also often don't add kmalloc failure messages, since it's rare and spits a warning anyway. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108825] Regression Raven Ridge: Banding on eDP display
https://bugs.freedesktop.org/show_bug.cgi?id=108825 Nicholas Kazlauskas changed: What|Removed |Added Attachment #142652|0 |1 is obsolete|| --- Comment #10 from Nicholas Kazlauskas --- Created attachment 142653 --> https://bugs.freedesktop.org/attachment.cgi?id=142653=edit v2-0001-drm-amd-display-Fix-unintialized-max_bpc-state-va.patch I meant to copy the property for the dm connector state, sorry. Try this patch instead. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108825] Regression Raven Ridge: Banding on eDP display
https://bugs.freedesktop.org/show_bug.cgi?id=108825 --- Comment #9 from Samantha McVey --- It doesn't compile with that patch: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function ‘dm_crtc_duplicate_state’: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:2991:7: error: ‘struct dm_crtc_state’ has no member named ‘max_bpc’ state->max_bpc = cur->max_bpc; ^~ drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:2991:22: error: ‘struct dm_crtc_state’ has no member named ‘max_bpc’ state->max_bpc = cur->max_bpc; ^~ -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL v2] drm-misc-fixes
Hi Dave, Here's the updated PR with the mst destroy patch reverted. drm-misc-fixes-2018-11-28-1: - mst: Don't try to validate ports while destroying them (Lyude) - Revert: Don't try to validate ports while destroying them (Lyude) - core: Don't set device to master unless set_master succeeds (Sergio) - meson: Do vblank_on/off on enable/disable (Neil) - meson: Use fast_io regmap option to avoid sleeping in irq ctx (Lyude) - meson: Don't walk off the end of the OSD EOTF LUTs (Lyude) Cc: Lyude Paul Cc: Sergio Correia Cc: Neil Armstrong Cheers, Sean For completeness, here's my summary from the v1: --- Hi Dave, Happy meson week! A bunch of stellar fixes coming in this week from Lyude, and a couple others plugging holes in meson and core. drm-misc-fixes-2018-11-28: - mst: Don't try to validate ports while destroying them (Lyude) - core: Don't set device to master unless set_master succeeds (Sergio) - meson: Do vblank_on/off on enable/disable (Neil) - meson: Use fast_io regmap option to avoid sleeping in irq ctx (Lyude) - meson: Don't walk off the end of the OSD EOTF LUTs (Lyude) Cc: Lyude Paul Cc: Sergio Correia Cc: Neil Armstrong Cheers, Sean --- The following changes since commit 2e6e902d185027f8e3cb8b7305238f7e35d6a436: Linux 4.20-rc4 (2018-11-25 14:19:31 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-11-28-1 for you to fetch changes up to 9765635b30756eb74e05e260ac812659c296cd28: Revert "drm/dp_mst: Skip validating ports during destruction, just ref" (2018-11-28 16:22:17 -0500) - mst: Don't try to validate ports while destroying them (Lyude) - Revert: Don't try to validate ports while destroying them (Lyude) - core: Don't set device to master unless set_master succeeds (Sergio) - meson: Do vblank_on/off on enable/disable (Neil) - meson: Use fast_io regmap option to avoid sleeping in irq ctx (Lyude) - meson: Don't walk off the end of the OSD EOTF LUTs (Lyude) Cc: Lyude Paul Cc: Sergio Correia Cc: Neil Armstrong Christian Hewitt (1): drm/meson: add support for 1080p25 mode Lyude Paul (4): drm/dp_mst: Skip validating ports during destruction, just ref drm/meson: Enable fast_io in meson_dw_hdmi_regmap_config drm/meson: Fix OOB memory accesses in meson_viu_set_osd_lut() Revert "drm/dp_mst: Skip validating ports during destruction, just ref" Neil Armstrong (1): drm/meson: Fixes for drm_crtc_vblank_on/off support Sergio Correia (1): drm: set is_master to 0 upon drm_new_set_master() failure drivers/gpu/drm/drm_auth.c| 2 ++ drivers/gpu/drm/meson/meson_crtc.c| 27 +-- drivers/gpu/drm/meson/meson_dw_hdmi.c | 1 + drivers/gpu/drm/meson/meson_venc.c| 4 drivers/gpu/drm/meson/meson_viu.c | 12 ++-- 5 files changed, 38 insertions(+), 8 deletions(-) -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/5] drm/rcar-du: Use drm_fbdev_generic_setup()
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by the emulation code. Additionally fbdev unregister happens
automatically on drm_dev_unregister().
The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
driver. This is done to highlight the fact that fbdev emulation is an
internal client that makes use of the driver, it is not part of the
driver as such. If fbdev setup fails, an error is printed, but the driver
succeeds probing.
drm_fbdev_generic_setup() handles mode_config.num_connector being zero.
In that case it retries fbdev setup on the next .output_poll_changed.
Cc: Laurent Pinchart
Signed-off-by: Noralf Trønnes
Acked-by: Sam Ravnborg
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 14 +++---
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 --
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 21 -
3 files changed, 3 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index c6770043dcdc..c24aabe3e3e9 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include "rcar_du_drv.h"
@@ -363,19 +364,11 @@ MODULE_DEVICE_TABLE(of, rcar_du_of_table);
* DRM operations
*/
-static void rcar_du_lastclose(struct drm_device *dev)
-{
- struct rcar_du_device *rcdu = dev->dev_private;
-
- drm_fbdev_cma_restore_mode(rcdu->fbdev);
-}
-
DEFINE_DRM_GEM_CMA_FOPS(rcar_du_fops);
static struct drm_driver rcar_du_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME
| DRIVER_ATOMIC,
- .lastclose = rcar_du_lastclose,
.gem_free_object_unlocked = drm_gem_cma_free_object,
.gem_vm_ops = _gem_cma_vm_ops,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
@@ -431,9 +424,6 @@ static int rcar_du_remove(struct platform_device *pdev)
drm_dev_unregister(ddev);
- if (rcdu->fbdev)
- drm_fbdev_cma_fini(rcdu->fbdev);
-
drm_kms_helper_poll_fini(ddev);
drm_mode_config_cleanup(ddev);
@@ -493,6 +483,8 @@ static int rcar_du_probe(struct platform_device *pdev)
DRM_INFO("Device %s probed\n", dev_name(>dev));
+ drm_fbdev_generic_setup(ddev, 32);
+
return 0;
error:
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index 9f5563296c5a..a68da79b424e 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -20,7 +20,6 @@
struct clk;
struct device;
struct drm_device;
-struct drm_fbdev_cma;
struct rcar_du_device;
#define RCAR_DU_FEATURE_CRTC_IRQ_CLOCK BIT(0) /* Per-CRTC IRQ and clock */
@@ -78,7 +77,6 @@ struct rcar_du_device {
void __iomem *mmio;
struct drm_device *ddev;
- struct drm_fbdev_cma *fbdev;
struct rcar_du_crtc crtcs[RCAR_DU_MAX_CRTCS];
unsigned int num_crtcs;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 4ebd61ecbee1..6562871aa706 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -255,13 +255,6 @@ rcar_du_fb_create(struct drm_device *dev, struct drm_file
*file_priv,
return drm_gem_fb_create(dev, file_priv, mode_cmd);
}
-static void rcar_du_output_poll_changed(struct drm_device *dev)
-{
- struct rcar_du_device *rcdu = dev->dev_private;
-
- drm_fbdev_cma_hotplug_event(rcdu->fbdev);
-}
-
/*
-
* Atomic Check and Update
*/
@@ -308,7 +301,6 @@ static const struct drm_mode_config_helper_funcs
rcar_du_mode_config_helper = {
static const struct drm_mode_config_funcs rcar_du_mode_config_funcs = {
.fb_create = rcar_du_fb_create,
- .output_poll_changed = rcar_du_output_poll_changed,
.atomic_check = rcar_du_atomic_check,
.atomic_commit = drm_atomic_helper_commit,
};
@@ -543,7 +535,6 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
struct drm_device *dev = rcdu->ddev;
struct drm_encoder *encoder;
- struct drm_fbdev_cma *fbdev;
unsigned int dpad0_sources;
unsigned int num_encoders;
unsigned int num_groups;
@@ -682,17 +673,5 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
drm_kms_helper_poll_init(dev);
- if (dev->mode_config.num_connector) {
- fbdev = drm_fbdev_cma_init(dev, 32,
- dev->mode_config.num_connector);
- if
[PATCH v3 0/5] drm/cma-helper drivers: Use drm_fbdev_generic_setup()
This patchset moves the drivers using the CMA helper fully over to the generic fbdev emulation. Changes this time is to remove a stray include from the rcar patch and some more include cleanup in the cma-helper which required a change to drm_framebuffer.h. I'm still hoping to get driver maintainer ack's for the hisilicon and mxsfb patches. For context, here's part 1 of the generic fbdev emulation: drm: Add generic fbdev emulation https://patchwork.freedesktop.org/series/45848/ Noralf. Cc: Xinliang Liu Cc: Rongrong Zou Cc: Xinwei Kong Cc: Chen Feng Cc: Marek Vasut Cc: Laurent Pinchart Noralf Trønnes (5): drm/hisilicon/kirin: Use drm_fbdev_generic_setup() drm/mxsfb: Use drm_fbdev_generic_setup() drm/rcar-du: Use drm_fbdev_generic_setup() drm/framebuffer: Include linux/sched.h in header file drm/cma-helper: Remove unused fbdev code drivers/gpu/drm/Kconfig | 4 - drivers/gpu/drm/drm_fb_cma_helper.c | 137 +--- drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 38 +-- drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 4 - drivers/gpu/drm/mxsfb/mxsfb_drv.c | 26 + drivers/gpu/drm/mxsfb/mxsfb_drv.h | 1 - drivers/gpu/drm/rcar-du/rcar_du_drv.c | 14 +-- drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 - drivers/gpu/drm/rcar-du/rcar_du_kms.c | 21 include/drm/drm_fb_cma_helper.h | 22 include/drm/drm_framebuffer.h | 1 + 11 files changed, 11 insertions(+), 259 deletions(-) -- 2.15.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/5] drm/framebuffer: Include linux/sched.h in header file
A cleanup of the includes in drm_fb_cma_helper resulted in: CC [M] drivers/gpu/drm/drm_fb_cma_helper.o In file included from drivers/gpu/drm/drm_fb_cma_helper.c:21:0: include/drm/drm_framebuffer.h:128:12: error: ‘TASK_COMM_LEN’ undeclared here (not in a function) char comm[TASK_COMM_LEN]; Fix it by including linux/sched.h. Signed-off-by: Noralf Trønnes --- include/drm/drm_framebuffer.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/drm/drm_framebuffer.h b/include/drm/drm_framebuffer.h index c94acedfb08e..d4ce58568fa6 100644 --- a/include/drm/drm_framebuffer.h +++ b/include/drm/drm_framebuffer.h @@ -25,6 +25,7 @@ #include #include +#include #include struct drm_framebuffer; -- 2.15.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows
https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #71 from bmil...@gmail.com --- @Nicholas Kazlauskas any reason not to push this fix to staging or next? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/5] drm/mxsfb: Use drm_fbdev_generic_setup()
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by the emulation code. Additionally fbdev unregister happens
automatically on drm_dev_unregister().
The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
driver. This is done to highlight the fact that fbdev emulation is an
internal client that makes use of the driver, it is not part of the
driver as such. If fbdev setup fails, an error is printed, but the driver
succeeds probing.
Cc: Marek Vasut
Signed-off-by: Noralf Trønnes
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 26 ++
drivers/gpu/drm/mxsfb/mxsfb_drv.h | 1 -
2 files changed, 2 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 88ba003979e6..13e778825098 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -263,23 +263,12 @@ static int mxsfb_load(struct drm_device *drm, unsigned
long flags)
drm_kms_helper_poll_init(drm);
- mxsfb->fbdev = drm_fbdev_cma_init(drm, 32,
- drm->mode_config.num_connector);
- if (IS_ERR(mxsfb->fbdev)) {
- ret = PTR_ERR(mxsfb->fbdev);
- mxsfb->fbdev = NULL;
- dev_err(drm->dev, "Failed to init FB CMA area\n");
- goto err_cma;
- }
-
platform_set_drvdata(pdev, drm);
drm_helper_hpd_irq_event(drm);
return 0;
-err_cma:
- drm_irq_uninstall(drm);
err_irq:
drm_panel_detach(mxsfb->panel);
err_vblank:
@@ -290,11 +279,6 @@ static int mxsfb_load(struct drm_device *drm, unsigned
long flags)
static void mxsfb_unload(struct drm_device *drm)
{
- struct mxsfb_drm_private *mxsfb = drm->dev_private;
-
- if (mxsfb->fbdev)
- drm_fbdev_cma_fini(mxsfb->fbdev);
-
drm_kms_helper_poll_fini(drm);
drm_mode_config_cleanup(drm);
@@ -307,13 +291,6 @@ static void mxsfb_unload(struct drm_device *drm)
pm_runtime_disable(drm->dev);
}
-static void mxsfb_lastclose(struct drm_device *drm)
-{
- struct mxsfb_drm_private *mxsfb = drm->dev_private;
-
- drm_fbdev_cma_restore_mode(mxsfb->fbdev);
-}
-
static void mxsfb_irq_preinstall(struct drm_device *drm)
{
struct mxsfb_drm_private *mxsfb = drm->dev_private;
@@ -347,7 +324,6 @@ static struct drm_driver mxsfb_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET |
DRIVER_PRIME | DRIVER_ATOMIC |
DRIVER_HAVE_IRQ,
- .lastclose = mxsfb_lastclose,
.irq_handler= mxsfb_irq_handler,
.irq_preinstall = mxsfb_irq_preinstall,
.irq_uninstall = mxsfb_irq_preinstall,
@@ -412,6 +388,8 @@ static int mxsfb_probe(struct platform_device *pdev)
if (ret)
goto err_unload;
+ drm_fbdev_generic_setup(drm, 32);
+
return 0;
err_unload:
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.h
b/drivers/gpu/drm/mxsfb/mxsfb_drv.h
index 5d0883fc805b..bedd6801edca 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.h
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.h
@@ -37,7 +37,6 @@ struct mxsfb_drm_private {
struct drm_simple_display_pipe pipe;
struct drm_connectorconnector;
struct drm_panel*panel;
- struct drm_fbdev_cma*fbdev;
};
int mxsfb_setup_crtc(struct drm_device *dev);
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 5/5] drm/cma-helper: Remove unused fbdev code
CMA helper drivers have been converted to drm_fbdev_generic_setup()
so the fbdev code can be removed.
v2: Clean up the includes some more (Laurent)
Cc: Laurent Pinchart
Signed-off-by: Noralf Trønnes
Acked-by: Sam Ravnborg
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/Kconfig | 4 --
drivers/gpu/drm/drm_fb_cma_helper.c | 137 +---
include/drm/drm_fb_cma_helper.h | 22 --
3 files changed, 2 insertions(+), 161 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 4385f00e1d05..bd943a71756c 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -170,10 +170,6 @@ config DRM_KMS_CMA_HELPER
bool
depends on DRM
select DRM_GEM_CMA_HELPER
- select DRM_KMS_FB_HELPER
- select FB_SYS_FILLRECT
- select FB_SYS_COPYAREA
- select FB_SYS_IMAGEBLIT
help
Choose this if you need the KMS CMA helper functions
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 5b516615881a..5f8074ffe7d9 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -17,20 +17,13 @@
* GNU General Public License for more details.
*/
-#include
-#include
-#include
+#include
#include
#include
#include
-#include
-#include
+#include
#include
-struct drm_fbdev_cma {
- struct drm_fb_helperfb_helper;
-};
-
/**
* DOC: framebuffer cma helper functions
*
@@ -39,16 +32,8 @@ struct drm_fbdev_cma {
*
* drm_gem_fb_create() is used in the _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_fb_cma_fbdev_init(). drm_fb_cma_fbdev_fini() tears it down.
*/
-static inline struct drm_fbdev_cma *to_fbdev_cma(struct drm_fb_helper *helper)
-{
- return container_of(helper, struct drm_fbdev_cma, fb_helper);
-}
-
/**
* drm_fb_cma_get_gem_obj() - Get CMA GEM object for framebuffer
* @fb: The framebuffer
@@ -119,121 +104,3 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
*fb,
return paddr;
}
EXPORT_SYMBOL_GPL(drm_fb_cma_get_gem_addr);
-
-/**
- * drm_fb_cma_fbdev_init() - Allocate and initialize fbdev emulation
- * @dev: DRM device
- * @preferred_bpp: Preferred bits per pixel for the device.
- * @dev->mode_config.preferred_depth is used if this is zero.
- * @max_conn_count: Maximum number of connectors.
- * @dev->mode_config.num_connector is used if this is zero.
- *
- * Returns:
- * Zero on success or negative error code on failure.
- */
-int drm_fb_cma_fbdev_init(struct drm_device *dev, unsigned int preferred_bpp,
- unsigned int max_conn_count)
-{
- struct drm_fbdev_cma *fbdev_cma;
-
- /* dev->fb_helper will indirectly point to fbdev_cma after this call */
- fbdev_cma = drm_fbdev_cma_init(dev, preferred_bpp, max_conn_count);
- return PTR_ERR_OR_ZERO(fbdev_cma);
-}
-EXPORT_SYMBOL_GPL(drm_fb_cma_fbdev_init);
-
-/**
- * drm_fb_cma_fbdev_fini() - Teardown fbdev emulation
- * @dev: DRM device
- */
-void drm_fb_cma_fbdev_fini(struct drm_device *dev)
-{
- if (dev->fb_helper)
- drm_fbdev_cma_fini(to_fbdev_cma(dev->fb_helper));
-}
-EXPORT_SYMBOL_GPL(drm_fb_cma_fbdev_fini);
-
-static const struct drm_fb_helper_funcs drm_fb_cma_helper_funcs = {
- .fb_probe = drm_fb_helper_generic_probe,
-};
-
-/**
- * drm_fbdev_cma_init() - Allocate and initializes a drm_fbdev_cma struct
- * @dev: DRM device
- * @preferred_bpp: Preferred bits per pixel for the device
- * @max_conn_count: Maximum number of connectors
- *
- * Returns a newly allocated drm_fbdev_cma struct or a ERR_PTR.
- */
-struct drm_fbdev_cma *drm_fbdev_cma_init(struct drm_device *dev,
- unsigned int preferred_bpp, unsigned int max_conn_count)
-{
- struct drm_fbdev_cma *fbdev_cma;
- struct drm_fb_helper *fb_helper;
- int ret;
-
- fbdev_cma = kzalloc(sizeof(*fbdev_cma), GFP_KERNEL);
- if (!fbdev_cma)
- return ERR_PTR(-ENOMEM);
-
- fb_helper = _cma->fb_helper;
-
- ret = drm_client_init(dev, _helper->client, "fbdev", NULL);
- if (ret)
- goto err_free;
-
- ret = drm_fb_helper_fbdev_setup(dev, fb_helper,
_fb_cma_helper_funcs,
- preferred_bpp, max_conn_count);
- if (ret)
- goto err_client_put;
-
- drm_client_add(_helper->client);
-
- return fbdev_cma;
-
-err_client_put:
- drm_client_release(_helper->client);
-err_free:
- kfree(fbdev_cma);
-
- return ERR_PTR(ret);
-}
-EXPORT_SYMBOL_GPL(drm_fbdev_cma_init);
-
-/**
- * drm_fbdev_cma_fini() - Free drm_fbdev_cma struct
- * @fbdev_cma: The drm_fbdev_cma struct
- */
-void drm_fbdev_cma_fini(struct drm_fbdev_cma *fbdev_cma)
-{
- drm_fb_helper_unregister_fbi(_cma->fb_helper);
-
[PATCH v3 1/5] drm/hisilicon/kirin: Use drm_fbdev_generic_setup()
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by the emulation code. Additionally fbdev unregister happens
automatically on drm_dev_unregister().
The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
driver. This is done to highlight the fact that fbdev emulation is an
internal client that makes use of the driver, it is not part of the
driver as such. If fbdev setup fails, an error is printed, but the driver
succeeds probing.
struct kirin_drm_private can be removed now that driver doesn't have to
store the fbdev pointer.
Cc: Xinliang Liu
Cc: Rongrong Zou
Cc: Xinwei Kong
Cc: Chen Feng
Signed-off-by: Noralf Trønnes
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 38 ++---
drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 4 ---
2 files changed, 3 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index e6a62d5a00a3..15e32e5d9101 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -33,32 +34,15 @@ static struct kirin_dc_ops *dc_ops;
static int kirin_drm_kms_cleanup(struct drm_device *dev)
{
- struct kirin_drm_private *priv = dev->dev_private;
-
- if (priv->fbdev) {
- drm_fbdev_cma_fini(priv->fbdev);
- priv->fbdev = NULL;
- }
-
drm_kms_helper_poll_fini(dev);
dc_ops->cleanup(to_platform_device(dev->dev));
drm_mode_config_cleanup(dev);
- devm_kfree(dev->dev, priv);
- dev->dev_private = NULL;
return 0;
}
-static void kirin_fbdev_output_poll_changed(struct drm_device *dev)
-{
- struct kirin_drm_private *priv = dev->dev_private;
-
- drm_fbdev_cma_hotplug_event(priv->fbdev);
-}
-
static const struct drm_mode_config_funcs kirin_drm_mode_config_funcs = {
.fb_create = drm_gem_fb_create,
- .output_poll_changed = kirin_fbdev_output_poll_changed,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
};
@@ -76,14 +60,8 @@ static void kirin_drm_mode_config_init(struct drm_device
*dev)
static int kirin_drm_kms_init(struct drm_device *dev)
{
- struct kirin_drm_private *priv;
int ret;
- priv = devm_kzalloc(dev->dev, sizeof(*priv), GFP_KERNEL);
- if (!priv)
- return -ENOMEM;
-
- dev->dev_private = priv;
dev_set_drvdata(dev->dev, dev);
/* dev->mode_config initialization */
@@ -117,26 +95,14 @@ static int kirin_drm_kms_init(struct drm_device *dev)
/* init kms poll for handling hpd */
drm_kms_helper_poll_init(dev);
- priv->fbdev = drm_fbdev_cma_init(dev, 32,
-dev->mode_config.num_connector);
-
- if (IS_ERR(priv->fbdev)) {
- DRM_ERROR("failed to initialize fbdev.\n");
- ret = PTR_ERR(priv->fbdev);
- goto err_cleanup_poll;
- }
return 0;
-err_cleanup_poll:
- drm_kms_helper_poll_fini(dev);
err_unbind_all:
component_unbind_all(dev->dev, dev);
err_dc_cleanup:
dc_ops->cleanup(to_platform_device(dev->dev));
err_mode_config_cleanup:
drm_mode_config_cleanup(dev);
- devm_kfree(dev->dev, priv);
- dev->dev_private = NULL;
return ret;
}
@@ -199,6 +165,8 @@ static int kirin_drm_bind(struct device *dev)
if (ret)
goto err_kms_cleanup;
+ drm_fbdev_generic_setup(drm_dev, 32);
+
return 0;
err_kms_cleanup:
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
index 56cb62df065c..ad027d1cc826 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
@@ -19,10 +19,6 @@ struct kirin_dc_ops {
void (*cleanup)(struct platform_device *pdev);
};
-struct kirin_drm_private {
- struct drm_fbdev_cma *fbdev;
-};
-
extern const struct kirin_dc_ops ade_dc_ops;
#endif /* __KIRIN_DRM_DRV_H__ */
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v3 06/19] arch: um: enable running kunit from User Mode Linux
On Wed, Nov 28, 2018 at 1:37 PM Brendan Higgins wrote: > > Make minimum number of changes outside of the KUnit directories for > KUnit to build and run using UML. There's nothing in this patch limiting this to UML. Only patch 1 does that and I would remove that depends. I'd guess most folks will want to run under something other than UML. DRM for instance (though the virtual KMS stuff may work in UML?). Plus you want to make sure this all builds with allmodconfig for x86 (or ARM) because those get the most (and quickest) compile coverage. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108825] Regression Raven Ridge: Banding on eDP display
https://bugs.freedesktop.org/show_bug.cgi?id=108825 --- Comment #8 from Nicholas Kazlauskas --- Created attachment 142652 --> https://bugs.freedesktop.org/attachment.cgi?id=142652=edit 0001-drm-amd-display-Fix-unintialized-max_bpc-state-value.patch Does this help fix the issue? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v2] Return only active connectors for get_resources ioctl
On Wed, Nov 28, 2018 at 10:21:33PM +0100, Daniel Vetter wrote:
> On Wed, Nov 28, 2018 at 09:51:13PM +0100, Daniel Vetter wrote:
> > On Wed, Nov 28, 2018 at 03:55:58PM +0200, Stanislav Lisovskiy wrote:
> > > Currently kernel might allocate different connector ids
> > > for the same outputs in case of DP MST, which seems to
> > > confuse userspace. There are can be different connector
> > > ids in the list, which could be assigned to the same
> > > output, while being in different states.
> > > This results in issues, like external displays staying
> > > blank after quick unplugging and plugging back(bug #106250).
> > > Returning only active DP connectors fixes the issue.
> > >
> > > v2: Removed caps from the title
> > >
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106250
> > > Signed-off-by: Stanislav Lisovskiy
> > > ---
> > > drivers/gpu/drm/drm_mode_config.c | 16 +++-
> > > 1 file changed, 11 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_mode_config.c
> > > b/drivers/gpu/drm/drm_mode_config.c
> > > index ee80788f2c40..ec5b2b08a45e 100644
> > > --- a/drivers/gpu/drm/drm_mode_config.c
> > > +++ b/drivers/gpu/drm/drm_mode_config.c
> > > @@ -143,6 +143,7 @@ int drm_mode_getresources(struct drm_device *dev,
> > > void *data,
> > > drm_connector_list_iter_begin(dev, _iter);
> > > count = 0;
> > > connector_id = u64_to_user_ptr(card_res->connector_id_ptr);
> > > + DRM_DEBUG_KMS("GetResources: writing connectors start");
> > > drm_for_each_connector_iter(connector, _iter) {
> > > /* only expose writeback connectors if userspace understands
> > > them */
> > > if (!file_priv->writeback_connectors &&
> > > @@ -150,15 +151,20 @@ int drm_mode_getresources(struct drm_device *dev,
> > > void *data,
> > > continue;
> > >
> > > if (drm_lease_held(file_priv, connector->base.id)) {
> > > - if (count < card_res->count_connectors &&
> > > - put_user(connector->base.id, connector_id + count))
> > > {
> > > - drm_connector_list_iter_end(_iter);
> > > - return -EFAULT;
> > > + if (connector->connector_type !=
> > > DRM_MODE_CONNECTOR_DisplayPort ||
> > > + connector->status !=
> > > connector_status_disconnected) {
> > > + if (count < card_res->count_connectors &&
> > > + put_user(connector->base.id, connector_id +
> > > count)) {
> > > + drm_connector_list_iter_end(_iter);
> > > + return -EFAULT;
> > > + }
> > > + DRM_DEBUG_KMS("GetResources: connector %s",
> > > connector->name);
> > > + count++;
> >
> > I tried to read the bug and I have no idea what's going on here. Userspace
> > is supposed to shut off outputs that are disconnected, whether that's DP,
> > DP MST or something else shouldn't matter. New connectors can come as
> > they see fit. Also not really something special.
> >
> > Why do we need to dynamically hide an output here? Note that this also
> > affects normal DP ports, which I have no idea is actually what you want to
> > do or not.
>
> For entertainment and other reasons, testing the below diff would be
> interesting.
Now also with real locking:
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 4de247ddf05f..1b83567aa922 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -494,11 +494,16 @@ static struct drm_connector
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
static void intel_dp_register_mst_connector(struct drm_connector *connector)
{
struct drm_i915_private *dev_priv = to_i915(connector->dev);
+ struct drm_mode_config *config = >dev->mode_config;
if (dev_priv->fbdev)
drm_fb_helper_add_one_connector(_priv->fbdev->helper,
connector);
+ spin_lock_irq(>connector_list_lock);
+ list_move(>head, >connector_list);
+ spin_unlock_irq(>connector_list_lock);
+
drm_connector_register(connector);
}
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v2] Return only active connectors for get_resources ioctl
On Wed, Nov 28, 2018 at 09:51:13PM +0100, Daniel Vetter wrote:
> On Wed, Nov 28, 2018 at 03:55:58PM +0200, Stanislav Lisovskiy wrote:
> > Currently kernel might allocate different connector ids
> > for the same outputs in case of DP MST, which seems to
> > confuse userspace. There are can be different connector
> > ids in the list, which could be assigned to the same
> > output, while being in different states.
> > This results in issues, like external displays staying
> > blank after quick unplugging and plugging back(bug #106250).
> > Returning only active DP connectors fixes the issue.
> >
> > v2: Removed caps from the title
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106250
> > Signed-off-by: Stanislav Lisovskiy
> > ---
> > drivers/gpu/drm/drm_mode_config.c | 16 +++-
> > 1 file changed, 11 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_mode_config.c
> > b/drivers/gpu/drm/drm_mode_config.c
> > index ee80788f2c40..ec5b2b08a45e 100644
> > --- a/drivers/gpu/drm/drm_mode_config.c
> > +++ b/drivers/gpu/drm/drm_mode_config.c
> > @@ -143,6 +143,7 @@ int drm_mode_getresources(struct drm_device *dev, void
> > *data,
> > drm_connector_list_iter_begin(dev, _iter);
> > count = 0;
> > connector_id = u64_to_user_ptr(card_res->connector_id_ptr);
> > + DRM_DEBUG_KMS("GetResources: writing connectors start");
> > drm_for_each_connector_iter(connector, _iter) {
> > /* only expose writeback connectors if userspace understands
> > them */
> > if (!file_priv->writeback_connectors &&
> > @@ -150,15 +151,20 @@ int drm_mode_getresources(struct drm_device *dev,
> > void *data,
> > continue;
> >
> > if (drm_lease_held(file_priv, connector->base.id)) {
> > - if (count < card_res->count_connectors &&
> > - put_user(connector->base.id, connector_id + count))
> > {
> > - drm_connector_list_iter_end(_iter);
> > - return -EFAULT;
> > + if (connector->connector_type !=
> > DRM_MODE_CONNECTOR_DisplayPort ||
> > + connector->status !=
> > connector_status_disconnected) {
> > + if (count < card_res->count_connectors &&
> > + put_user(connector->base.id, connector_id +
> > count)) {
> > + drm_connector_list_iter_end(_iter);
> > + return -EFAULT;
> > + }
> > + DRM_DEBUG_KMS("GetResources: connector %s",
> > connector->name);
> > + count++;
>
> I tried to read the bug and I have no idea what's going on here. Userspace
> is supposed to shut off outputs that are disconnected, whether that's DP,
> DP MST or something else shouldn't matter. New connectors can come as
> they see fit. Also not really something special.
>
> Why do we need to dynamically hide an output here? Note that this also
> affects normal DP ports, which I have no idea is actually what you want to
> do or not.
For entertainment and other reasons, testing the below diff would be
interesting.
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 4de247ddf05f..e1b66396c83b 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -499,6 +499,8 @@ static void intel_dp_register_mst_connector(struct
drm_connector *connector)
drm_fb_helper_add_one_connector(_priv->fbdev->helper,
connector);
+ list_move(>head,
>dev->mode_config.connector_list);
+
drm_connector_register(connector);
}
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v3 16/19] arch: um: make UML unflatten device tree when testing
On Wed, Nov 28, 2018 at 1:38 PM Brendan Higgins wrote: > > Make UML unflatten any present device trees when running KUnit tests. > > Signed-off-by: Brendan Higgins > --- > arch/um/kernel/um_arch.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/arch/um/kernel/um_arch.c b/arch/um/kernel/um_arch.c > index a818ccef30ca2..bd58ae3bf4148 100644 > --- a/arch/um/kernel/um_arch.c > +++ b/arch/um/kernel/um_arch.c > @@ -13,6 +13,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -347,6 +348,9 @@ void __init setup_arch(char **cmdline_p) > read_initrd(); > > paging_init(); > +#if IS_ENABLED(CONFIG_OF_UNITTEST) > + unflatten_device_tree(); > +#endif Kind of strange to have this in the arch code. I'd rather have this in the unittest code if possible. Can we have an initcall conditional on CONFIG_UM in the unittest do this? Side note, use a C if with IS_ENABLED() whenever possible instead of pre-processor #if. I'll take a fix separately as it was on my todo to fix. I've got the unit tests running in a gitlab CI job now[1]. Rob [1] https://gitlab.com/robherring/linux-dt-unittest/pipelines ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108891] Test enumeration becomes funky on some tests due to fd FILE* stream change
https://bugs.freedesktop.org/show_bug.cgi?id=108891 --- Comment #1 from Casey Bowman --- Note that the invalid argument error is most likely an unrelated error, but most likely attributed to this bug being found. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108891] Test enumeration becomes funky on some tests due to fd FILE* stream change
https://bugs.freedesktop.org/show_bug.cgi?id=108891 Bug ID: 108891 Summary: Test enumeration becomes funky on some tests due to fd FILE* stream change Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: IGT Assignee: dri-devel@lists.freedesktop.org Reporter: casey.g.bow...@intel.com Testing on ChromeOS KBL device with a 4.4 kernel IGT SHA used was: dbe1fc1e13c4e4eebaa9e1bbc5d188b5109c09d3 Running the igt@gem_busy@basic-busy-default test resulted in the following failure: (gem_busy:13397) igt-gt-CRITICAL: Test assertion failure function igt_allow_hang, file ../../intel-gpu-tools-/lib/igt_gt.c:174: (gem_busy:13397) igt-gt-CRITICAL: Failed assertion: igt_sysfs_set_parameter (fd, "reset", "%d", INT_MAX ) (gem_busy:13397) igt-gt-CRITICAL: Last errno: 22, Invalid argument Test gem_busy failed. DEBUG (gem_busy:13397) DEBUG: Test requirement passed: gem_has_ring(fd, e->exec_id | e->flags) (gem_busy:13397) igt-debugfs-DEBUG: Opening debugfs directory '/sys/kernel/debug/dri/0' (gem_busy:13397) drmtest-DEBUG: Test requirement passed: is_i915_device(fd) && has_known_intel_chipset(fd) (gem_busy:13397) igt-debugfs-DEBUG: Opening debugfs directory '/sys/kernel/debug/dri/0' (gem_busy:13397) ioctl-wrappers-DEBUG: Test requirement passed: dir >= 0 (gem_busy:13397) ioctl-wrappers-DEBUG: Test requirement passed: err == 0 (gem_busy:13397) ioctl-wrappers-DEBUG: Test requirement passed: gem_has_ring(fd, ring) (gem_busy:13397) igt-dummyload-DEBUG: Test requirement passed: nengine (gem_busy:13397) igt-core-INFO: Subtest basic-busy-default: SUCCESS (0.013s) (gem_busy:13397) drmtest-DEBUG: Test requirement passed: is_i915_device(fd) && has_known_intel_chipset(fd) (gem_busy:13397) igt-debugfs-DEBUG: Opening debugfs directory '/sys/kernel/debug/dri/0' (gem_busy:13397) ioctl-wrappers-DEBUG: Test requirement passed: dir >= 0 (gem_busy:13397) ioctl-wrappers-DEBUG: Test requirement passed: err == 0 (gem_busy:13397) ioctl-wrappers-DEBUG: Test requirement passed: gem_has_ring(fd, ring) (gem_busy:13397) igt-dummyload-DEBUG: Test requirement passed: nengine (gem_busy:13397) DEBUG: Test requirement passed: has_extended_busy_ioctl(fd) (gem_busy:13397) drmtest-DEBUG: Test requirement passed: is_i915_device(fd) && has_known_intel_chipset(fd) (gem_busy:13397) igt-debugfs-DEBUG: Opening debugfs directory '/sys/kernel/debug/dri/0' (gem_busy:13397) ioctl-wrappers-DEBUG: Test requirement passed: dir >= 0 (gem_busy:13397) ioctl-wrappers-DEBUG: Test requirement passed: err == 0 (gem_busy:13397) ioctl-wrappers-DEBUG: Test requirement passed: gem_has_ring(fd, ring) (gem_busy:13397) igt-dummyload-DEBUG: Test requirement passed: nengine (gem_busy:13397) DEBUG: Test requirement passed: has_extended_busy_ioctl(fd) (gem_busy:13397) drmtest-DEBUG: Test requirement passed: is_i915_device(fd) && has_known_intel_chipset(fd) (gem_busy:13397) igt-debugfs-DEBUG: Opening debugfs directory '/sys/kernel/debug/dri/0' (gem_busy:13397) ioctl-wrappers-DEBUG: Test requirement passed: dir >= 0 (gem_busy:13397) ioctl-wrappers-DEBUG: Test requirement passed: err == 0 (gem_busy:13397) igt-gt-CRITICAL: Test assertion failure function igt_allow_hang, file ../../intel-gpu-tools-/lib/igt_gt.c:174: (gem_busy:13397) igt-gt-CRITICAL: Failed assertion: igt_sysfs_set_parameter (fd, "reset", "%d", INT_MAX ) (gem_busy:13397) igt-gt-CRITICAL: Last errno: 22, Invalid argument (gem_busy:13397) igt-core-INFO: Stack trace: END The Stderr output clearly shows that the test passed with: (gem_busy:13397) igt-core-INFO: Subtest basic-busy-default: SUCCESS (0.013s) But the test continues on. Doing a bisect resulted in the offending commit: commit 3f89d7b02dcf662e994c7135b13d52bc8e09a4ea Author: Chris Wilson Date: Thu Aug 30 09:38:55 2018 +0100 lib/sysfs: Avoid using FILE* temporary for igt_sysfs_[v]printf Currently we wrap our fd inside a FILE* stream to make use of vfprintf, but the man page leaves the question of errno and signal handling in doubt. It is documented as returning a negative value and setting ferror(), but we have been interpreting errno to handle signal restarting. As that is in doubt, reduce it to a sprintf and reuse our common interrupt handling write() that already returns -errno. Signed-off-by: Chris Wilson Cc: Katarzyna Dec Reviewed-by: Katarzyna Dec Reverting the commit fixed the behavior and 30+ subtests on the fast-feedback.testlist changed back to passing. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Revert "drm/dp_mst: Skip validating ports during destruction, just ref"
On Wed, Nov 28, 2018 at 04:00:05PM -0500, Lyude Paul wrote:
> This reverts commit:
>
> c54c7374ff44 ("drm/dp_mst: Skip validating ports during destruction, just
> ref")
>
> ugh.
>
> In drm_dp_destroy_connector_work(), we have a pretty good chance of
> freeing the actual struct drm_dp_mst_port. However, after destroying
> things we send a hotplug through (*mgr->cbs->hotplug)(mgr) which is
> where the problems start.
>
> For i915, this calls all the way down to the fbcon probing helpers,
> which start trying to access the port in a modeset.
>
> [ 45.062001]
> ==
> [ 45.062112] BUG: KASAN: use-after-free in ex_handler_refcount+0x146/0x180
> [ 45.062196] Write of size 4 at addr 8882b4b70968 by task kworker/3:1/53
>
> [ 45.062325] CPU: 3 PID: 53 Comm: kworker/3:1 Kdump: loaded Tainted: G
> O 4.20.0-rc4Lyude-Test+ #3
> [ 45.062442] Hardware name: LENOVO 20BWS1KY00/20BWS1KY00, BIOS JBET71WW
> (1.35 ) 09/14/2018
> [ 45.062554] Workqueue: events drm_dp_destroy_connector_work
> [drm_kms_helper]
> [ 45.062641] Call Trace:
> [ 45.062685] dump_stack+0xbd/0x15a
> [ 45.062735] ? dump_stack_print_info.cold.0+0x1b/0x1b
> [ 45.062801] ? printk+0x9f/0xc5
> [ 45.062847] ? kmsg_dump_rewind_nolock+0xe4/0xe4
> [ 45.062909] ? ex_handler_refcount+0x146/0x180
> [ 45.062970] print_address_description+0x71/0x239
> [ 45.063036] ? ex_handler_refcount+0x146/0x180
> [ 45.063095] kasan_report.cold.5+0x242/0x30b
> [ 45.063155] __asan_report_store4_noabort+0x1c/0x20
> [ 45.063313] ex_handler_refcount+0x146/0x180
> [ 45.063371] ? ex_handler_clear_fs+0xb0/0xb0
> [ 45.063428] fixup_exception+0x98/0xd7
> [ 45.063484] ? raw_notifier_call_chain+0x20/0x20
> [ 45.063548] do_trap+0x6d/0x210
> [ 45.063605] ?
> _GLOBAL__sub_I_65535_1_drm_dp_aux_unregister_devnode+0x2f/0x1c6
> [drm_kms_helper]
> [ 45.063732] do_error_trap+0xc0/0x170
> [ 45.063802] ?
> _GLOBAL__sub_I_65535_1_drm_dp_aux_unregister_devnode+0x2f/0x1c6
> [drm_kms_helper]
> [ 45.063929] do_invalid_op+0x3b/0x50
> [ 45.063997] ?
> _GLOBAL__sub_I_65535_1_drm_dp_aux_unregister_devnode+0x2f/0x1c6
> [drm_kms_helper]
> [ 45.064103] invalid_op+0x14/0x20
> [ 45.064162] RIP:
> 0010:_GLOBAL__sub_I_65535_1_drm_dp_aux_unregister_devnode+0x2f/0x1c6
> [drm_kms_helper]
> [ 45.064274] Code: 00 48 c7 c7 80 fe 53 a0 48 89 e5 e8 5b 6f 26 e1 5d c3 48
> 8d 0e 0f 0b 48 8d 0b 0f 0b 48 8d 0f 0f 0b 48 8d 0f 0f 0b 49 8d 4d 00 <0f> 0b
> 49 8d 0e 0f 0b 48 8d 08 0f 0b 49 8d 4d 00 0f 0b 48 8d 0b 0f
> [ 45.064569] RSP: 0018:8882b789ee10 EFLAGS: 00010282
> [ 45.064637] RAX: 8882af47ae70 RBX: 8882af47aa60 RCX:
> 8882b4b70968
> [ 45.064723] RDX: 8882af47ae70 RSI: 0008 RDI:
> 8882b788bdb8
> [ 45.064808] RBP: 8882b789ee28 R08: ed1056f13db4 R09:
> ed1056f13db3
> [ 45.064894] R10: ed1056f13db3 R11: 8882b789ed9f R12:
> 8882af47ad28
> [ 45.064980] R13: 8882b4b70968 R14: 8882acd86728 R15:
> 8882b4b75dc8
> [ 45.065084] drm_dp_mst_reset_vcpi_slots+0x12/0x80 [drm_kms_helper]
> [ 45.065225] intel_mst_disable_dp+0xda/0x180 [i915]
> [ 45.065361] intel_encoders_disable.isra.107+0x197/0x310 [i915]
> [ 45.065498] haswell_crtc_disable+0xbe/0x400 [i915]
> [ 45.065622] ? i9xx_disable_plane+0x1c0/0x3e0 [i915]
> [ 45.065750] intel_atomic_commit_tail+0x74e/0x3e60 [i915]
> [ 45.065884] ? intel_pre_plane_update+0xbc0/0xbc0 [i915]
> [ 45.065968] ? drm_atomic_helper_swap_state+0x88b/0x1d90 [drm_kms_helper]
> [ 45.066054] ? kasan_check_write+0x14/0x20
> [ 45.066165] ? i915_gem_track_fb+0x13a/0x330 [i915]
> [ 45.066277] ? i915_sw_fence_complete+0xe9/0x140 [i915]
> [ 45.066406] ? __i915_sw_fence_complete+0xc50/0xc50 [i915]
> [ 45.066540] intel_atomic_commit+0x72e/0xef0 [i915]
> [ 45.066635] ? drm_dev_dbg+0x200/0x200 [drm]
> [ 45.066764] ? intel_atomic_commit_tail+0x3e60/0x3e60 [i915]
> [ 45.066898] ? intel_atomic_commit_tail+0x3e60/0x3e60 [i915]
> [ 45.067001] drm_atomic_commit+0xc4/0xf0 [drm]
> [ 45.067074] restore_fbdev_mode_atomic+0x562/0x780 [drm_kms_helper]
> [ 45.067166] ? drm_fb_helper_debug_leave+0x690/0x690 [drm_kms_helper]
> [ 45.067249] ? kasan_check_read+0x11/0x20
> [ 45.067324] restore_fbdev_mode+0x127/0x4b0 [drm_kms_helper]
> [ 45.067364] ? kasan_check_read+0x11/0x20
> [ 45.067406] drm_fb_helper_restore_fbdev_mode_unlocked+0x164/0x200
> [drm_kms_helper]
> [ 45.067462] ? drm_fb_helper_hotplug_event+0x30/0x30 [drm_kms_helper]
> [ 45.067508] ? kasan_check_write+0x14/0x20
> [ 45.070360] ? mutex_unlock+0x22/0x40
> [ 45.073748] drm_fb_helper_set_par+0xb2/0xf0 [drm_kms_helper]
> [ 45.075846] drm_fb_helper_hotplug_event.part.33+0x1cd/0x290
> [drm_kms_helper]
> [ 45.078088] drm_fb_helper_hotplug_event+0x1c/0x30 [drm_kms_helper]
> [ 45.082614] intel_fbdev_output_poll_changed+0x9f/0x140 [i915]
[PATCH] Revert "drm/dp_mst: Skip validating ports during destruction, just ref"
This reverts commit:
c54c7374ff44 ("drm/dp_mst: Skip validating ports during destruction, just ref")
ugh.
In drm_dp_destroy_connector_work(), we have a pretty good chance of
freeing the actual struct drm_dp_mst_port. However, after destroying
things we send a hotplug through (*mgr->cbs->hotplug)(mgr) which is
where the problems start.
For i915, this calls all the way down to the fbcon probing helpers,
which start trying to access the port in a modeset.
[ 45.062001]
==
[ 45.062112] BUG: KASAN: use-after-free in ex_handler_refcount+0x146/0x180
[ 45.062196] Write of size 4 at addr 8882b4b70968 by task kworker/3:1/53
[ 45.062325] CPU: 3 PID: 53 Comm: kworker/3:1 Kdump: loaded Tainted: G
O 4.20.0-rc4Lyude-Test+ #3
[ 45.062442] Hardware name: LENOVO 20BWS1KY00/20BWS1KY00, BIOS JBET71WW (1.35
) 09/14/2018
[ 45.062554] Workqueue: events drm_dp_destroy_connector_work [drm_kms_helper]
[ 45.062641] Call Trace:
[ 45.062685] dump_stack+0xbd/0x15a
[ 45.062735] ? dump_stack_print_info.cold.0+0x1b/0x1b
[ 45.062801] ? printk+0x9f/0xc5
[ 45.062847] ? kmsg_dump_rewind_nolock+0xe4/0xe4
[ 45.062909] ? ex_handler_refcount+0x146/0x180
[ 45.062970] print_address_description+0x71/0x239
[ 45.063036] ? ex_handler_refcount+0x146/0x180
[ 45.063095] kasan_report.cold.5+0x242/0x30b
[ 45.063155] __asan_report_store4_noabort+0x1c/0x20
[ 45.063313] ex_handler_refcount+0x146/0x180
[ 45.063371] ? ex_handler_clear_fs+0xb0/0xb0
[ 45.063428] fixup_exception+0x98/0xd7
[ 45.063484] ? raw_notifier_call_chain+0x20/0x20
[ 45.063548] do_trap+0x6d/0x210
[ 45.063605] ?
_GLOBAL__sub_I_65535_1_drm_dp_aux_unregister_devnode+0x2f/0x1c6 [drm_kms_helper]
[ 45.063732] do_error_trap+0xc0/0x170
[ 45.063802] ?
_GLOBAL__sub_I_65535_1_drm_dp_aux_unregister_devnode+0x2f/0x1c6 [drm_kms_helper]
[ 45.063929] do_invalid_op+0x3b/0x50
[ 45.063997] ?
_GLOBAL__sub_I_65535_1_drm_dp_aux_unregister_devnode+0x2f/0x1c6 [drm_kms_helper]
[ 45.064103] invalid_op+0x14/0x20
[ 45.064162] RIP:
0010:_GLOBAL__sub_I_65535_1_drm_dp_aux_unregister_devnode+0x2f/0x1c6
[drm_kms_helper]
[ 45.064274] Code: 00 48 c7 c7 80 fe 53 a0 48 89 e5 e8 5b 6f 26 e1 5d c3 48
8d 0e 0f 0b 48 8d 0b 0f 0b 48 8d 0f 0f 0b 48 8d 0f 0f 0b 49 8d 4d 00 <0f> 0b 49
8d 0e 0f 0b 48 8d 08 0f 0b 49 8d 4d 00 0f 0b 48 8d 0b 0f
[ 45.064569] RSP: 0018:8882b789ee10 EFLAGS: 00010282
[ 45.064637] RAX: 8882af47ae70 RBX: 8882af47aa60 RCX: 8882b4b70968
[ 45.064723] RDX: 8882af47ae70 RSI: 0008 RDI: 8882b788bdb8
[ 45.064808] RBP: 8882b789ee28 R08: ed1056f13db4 R09: ed1056f13db3
[ 45.064894] R10: ed1056f13db3 R11: 8882b789ed9f R12: 8882af47ad28
[ 45.064980] R13: 8882b4b70968 R14: 8882acd86728 R15: 8882b4b75dc8
[ 45.065084] drm_dp_mst_reset_vcpi_slots+0x12/0x80 [drm_kms_helper]
[ 45.065225] intel_mst_disable_dp+0xda/0x180 [i915]
[ 45.065361] intel_encoders_disable.isra.107+0x197/0x310 [i915]
[ 45.065498] haswell_crtc_disable+0xbe/0x400 [i915]
[ 45.065622] ? i9xx_disable_plane+0x1c0/0x3e0 [i915]
[ 45.065750] intel_atomic_commit_tail+0x74e/0x3e60 [i915]
[ 45.065884] ? intel_pre_plane_update+0xbc0/0xbc0 [i915]
[ 45.065968] ? drm_atomic_helper_swap_state+0x88b/0x1d90 [drm_kms_helper]
[ 45.066054] ? kasan_check_write+0x14/0x20
[ 45.066165] ? i915_gem_track_fb+0x13a/0x330 [i915]
[ 45.066277] ? i915_sw_fence_complete+0xe9/0x140 [i915]
[ 45.066406] ? __i915_sw_fence_complete+0xc50/0xc50 [i915]
[ 45.066540] intel_atomic_commit+0x72e/0xef0 [i915]
[ 45.066635] ? drm_dev_dbg+0x200/0x200 [drm]
[ 45.066764] ? intel_atomic_commit_tail+0x3e60/0x3e60 [i915]
[ 45.066898] ? intel_atomic_commit_tail+0x3e60/0x3e60 [i915]
[ 45.067001] drm_atomic_commit+0xc4/0xf0 [drm]
[ 45.067074] restore_fbdev_mode_atomic+0x562/0x780 [drm_kms_helper]
[ 45.067166] ? drm_fb_helper_debug_leave+0x690/0x690 [drm_kms_helper]
[ 45.067249] ? kasan_check_read+0x11/0x20
[ 45.067324] restore_fbdev_mode+0x127/0x4b0 [drm_kms_helper]
[ 45.067364] ? kasan_check_read+0x11/0x20
[ 45.067406] drm_fb_helper_restore_fbdev_mode_unlocked+0x164/0x200
[drm_kms_helper]
[ 45.067462] ? drm_fb_helper_hotplug_event+0x30/0x30 [drm_kms_helper]
[ 45.067508] ? kasan_check_write+0x14/0x20
[ 45.070360] ? mutex_unlock+0x22/0x40
[ 45.073748] drm_fb_helper_set_par+0xb2/0xf0 [drm_kms_helper]
[ 45.075846] drm_fb_helper_hotplug_event.part.33+0x1cd/0x290 [drm_kms_helper]
[ 45.078088] drm_fb_helper_hotplug_event+0x1c/0x30 [drm_kms_helper]
[ 45.082614] intel_fbdev_output_poll_changed+0x9f/0x140 [i915]
[ 45.087069] drm_kms_helper_hotplug_event+0x67/0x90 [drm_kms_helper]
[ 45.089319] intel_dp_mst_hotplug+0x37/0x50 [i915]
[ 45.091496] drm_dp_destroy_connector_work+0x510/0x6f0 [drm_kms_helper]
[ 45.093675] ? drm_dp_update_payload_part1+0x1220/0x1220
Re: [RFC v3 17/19] of: unittest: migrate tests to run on KUnit
On Wed, Nov 28, 2018 at 1:38 PM Brendan Higgins
wrote:
>
> Migrate tests without any cleanup, or modifying test logic in anyway to
> run under KUnit using the KUnit expectation and assertion API.
Nice! You beat me to it. This is probably going to conflict with what
is in the DT tree for 4.21. Also, please Cc the DT list for
drivers/of/ changes.
Looks good to me, but a few mostly formatting comments below.
>
> Signed-off-by: Brendan Higgins
> ---
> drivers/of/Kconfig|1 +
> drivers/of/unittest.c | 1405 ++---
> 2 files changed, 752 insertions(+), 654 deletions(-)
>
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index ad3fcad4d75b8..f309399deac20 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -15,6 +15,7 @@ if OF
> config OF_UNITTEST
> bool "Device Tree runtime unit tests"
> depends on !SPARC
> + depends on KUNIT
Unless KUNIT has depends, better to be a select here.
> select IRQ_DOMAIN
> select OF_EARLY_FLATTREE
> select OF_RESOLVE
> diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
> index 41b49716ac75f..a5ef44730ffdb 100644
> --- a/drivers/of/unittest.c
> +++ b/drivers/of/unittest.c
> @@ -26,186 +26,187 @@
>
> #include
>
> +#include
> +
> #include "of_private.h"
>
> -static struct unittest_results {
> - int passed;
> - int failed;
> -} unittest_results;
> -
> -#define unittest(result, fmt, ...) ({ \
> - bool failed = !(result); \
> - if (failed) { \
> - unittest_results.failed++; \
> - pr_err("FAIL %s():%i " fmt, __func__, __LINE__,
> ##__VA_ARGS__); \
> - } else { \
> - unittest_results.passed++; \
> - pr_debug("pass %s():%i\n", __func__, __LINE__); \
> - } \
> - failed; \
> -})
> -
> -static void __init of_unittest_find_node_by_name(void)
> +static void of_unittest_find_node_by_name(struct kunit *test)
Why do we have to drop __init everywhere? The tests run later?
> {
> struct device_node *np;
> const char *options, *name;
>
> np = of_find_node_by_path("/testcase-data");
> name = kasprintf(GFP_KERNEL, "%pOF", np);
> - unittest(np && !strcmp("/testcase-data", name),
> - "find /testcase-data failed\n");
> + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, np);
> + KUNIT_EXPECT_STREQ_MSG(test, "/testcase-data", name,
> + "find /testcase-data failed\n");
> of_node_put(np);
> kfree(name);
>
> /* Test if trailing '/' works */
> - np = of_find_node_by_path("/testcase-data/");
> - unittest(!np, "trailing '/' on /testcase-data/ should fail\n");
> + KUNIT_EXPECT_EQ_MSG(test, of_find_node_by_path("/testcase-data/"),
> NULL,
> + "trailing '/' on /testcase-data/ should fail\n");
>
> np = of_find_node_by_path("/testcase-data/phandle-tests/consumer-a");
> + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, np);
> name = kasprintf(GFP_KERNEL, "%pOF", np);
> - unittest(np && !strcmp("/testcase-data/phandle-tests/consumer-a",
> name),
> - "find /testcase-data/phandle-tests/consumer-a failed\n");
> + KUNIT_EXPECT_STREQ_MSG(test,
> + "/testcase-data/phandle-tests/consumer-a",
> name,
> + "find /testcase-data/phandle-tests/consumer-a
> failed\n");
> of_node_put(np);
> kfree(name);
>
> np = of_find_node_by_path("testcase-alias");
> + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, np);
> name = kasprintf(GFP_KERNEL, "%pOF", np);
> - unittest(np && !strcmp("/testcase-data", name),
> - "find testcase-alias failed\n");
> + KUNIT_EXPECT_STREQ_MSG(test, "/testcase-data", name,
> + "find testcase-alias failed\n");
> of_node_put(np);
> kfree(name);
>
> /* Test if trailing '/' works on aliases */
> - np = of_find_node_by_path("testcase-alias/");
> - unittest(!np, "trailing '/' on testcase-alias/ should fail\n");
> + KUNIT_EXPECT_EQ_MSG(test, of_find_node_by_path("testcase-alias/"),
> NULL,
> + "trailing '/' on testcase-alias/ should fail\n");
>
> np = of_find_node_by_path("testcase-alias/phandle-tests/consumer-a");
> + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, np);
> name = kasprintf(GFP_KERNEL, "%pOF", np);
> - unittest(np && !strcmp("/testcase-data/phandle-tests/consumer-a",
> name),
> - "find testcase-alias/phandle-tests/consumer-a failed\n");
> + KUNIT_EXPECT_STREQ_MSG(test,
> + "/testcase-data/phandle-tests/consumer-a",
> name,
> + "find testcase-alias/phandle-tests/consumer-a
> failed\n");
> of_node_put(np);
> kfree(name);
>
> - np =
Re: [Intel-gfx] [PATCH v2] Return only active connectors for get_resources ioctl
On Wed, Nov 28, 2018 at 03:55:58PM +0200, Stanislav Lisovskiy wrote:
> Currently kernel might allocate different connector ids
> for the same outputs in case of DP MST, which seems to
> confuse userspace. There are can be different connector
> ids in the list, which could be assigned to the same
> output, while being in different states.
> This results in issues, like external displays staying
> blank after quick unplugging and plugging back(bug #106250).
> Returning only active DP connectors fixes the issue.
>
> v2: Removed caps from the title
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106250
> Signed-off-by: Stanislav Lisovskiy
> ---
> drivers/gpu/drm/drm_mode_config.c | 16 +++-
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_mode_config.c
> b/drivers/gpu/drm/drm_mode_config.c
> index ee80788f2c40..ec5b2b08a45e 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -143,6 +143,7 @@ int drm_mode_getresources(struct drm_device *dev, void
> *data,
> drm_connector_list_iter_begin(dev, _iter);
> count = 0;
> connector_id = u64_to_user_ptr(card_res->connector_id_ptr);
> + DRM_DEBUG_KMS("GetResources: writing connectors start");
> drm_for_each_connector_iter(connector, _iter) {
> /* only expose writeback connectors if userspace understands
> them */
> if (!file_priv->writeback_connectors &&
> @@ -150,15 +151,20 @@ int drm_mode_getresources(struct drm_device *dev, void
> *data,
> continue;
>
> if (drm_lease_held(file_priv, connector->base.id)) {
> - if (count < card_res->count_connectors &&
> - put_user(connector->base.id, connector_id + count))
> {
> - drm_connector_list_iter_end(_iter);
> - return -EFAULT;
> + if (connector->connector_type !=
> DRM_MODE_CONNECTOR_DisplayPort ||
> + connector->status !=
> connector_status_disconnected) {
> + if (count < card_res->count_connectors &&
> + put_user(connector->base.id, connector_id +
> count)) {
> + drm_connector_list_iter_end(_iter);
> + return -EFAULT;
> + }
> + DRM_DEBUG_KMS("GetResources: connector %s",
> connector->name);
> + count++;
I tried to read the bug and I have no idea what's going on here. Userspace
is supposed to shut off outputs that are disconnected, whether that's DP,
DP MST or something else shouldn't matter. New connectors can come as
they see fit. Also not really something special.
Why do we need to dynamically hide an output here? Note that this also
affects normal DP ports, which I have no idea is actually what you want to
do or not.
-Daniel
> }
> - count++;
> }
> }
> card_res->count_connectors = count;
> + DRM_DEBUG_KMS("GetResources: writing connectors end - count %d", count);
> drm_connector_list_iter_end(_iter);
>
> return ret;
> --
> 2.17.1
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 00/14] kunit: introduce KUnit, the Linux kernel unit testing framework
On 11/28/18 12:54 PM, Knut Omang wrote: On Mon, 2018-11-26 at 17:41 -0800, Brendan Higgins wrote: On Fri, Nov 23, 2018 at 9:15 PM Knut Omang wrote: On Tue, 2018-10-23 at 16:57 -0700, Brendan Higgins wrote: Brendan, I regret you weren't at this year's testing and fuzzing workshop at LPC last week so we could have continued our discussions from last year there! Likewise! Unfortunately, I could not make it. So it goes. I hope we can work on this for a while longer before anything gets merged. Maybe it can be topic for a longer session in a future test related workshop? I don't see why we cannot just discuss it here as we are already doing. Yes, as long as we are not wasting all the Cc:'ed people's valuable time. Besides, you are mostly interested in out of tree testing, right? I don't see how this precludes anything that you are trying to do with KTF. Both approaches provide assertion macros for running tests inside the kernel, I doubt the kernel community would like to see yet two such sets of macros, with differing syntax merged. One of the good reasons to have a *framework* is that it is widely used and understood, so that people coming from one part of the kernel can easily run, understand and relate to selected tests from another part. The goal with KTF is to allow this for any kernel, old or new, not just kernels built specifically for testing purposes. We felt that providing it as a separate git module (still open source, for anyone to contribute to) is a more efficient approach until we have more examples and experience with using it in different parts of the kernel. We can definitely post the kernel side of KTF as a patch series fairly soon if the community wants us to. Except for hybrid tests, the ktf.ko module works fine independently of any user side support, just using the debugfs interface to run and examine tests. Having test framework in the kernel sources tree has benefits. It allows us (kernel developers) to do co-development of kernel features and tests for these features. It encourages developers to write regression tests. More importantly, kernel features and tests for these features are included in the same release in most cases and/or allows us freedom to do so if test framework and tests are part of the kernel sources. We have seen this with our experience with kselftest. It would not have see the same level of attention and growth if it stayed outside the kernel sources. Most kernel developers would not want to include a externally maintained module for testing. As a general rule, it has to be easy to run tests. I think there are good uses cases for having the ability to maintain a single source for tests that can be run against multiple kernels, also distro kernels that the test framework cannot expect to be able to modify, except from using the module interfaces. Same reasons as above. Having the tests included in the kernel sources makes it easier for distros to run those tests and include running them during their qualification. And there are good arguments for having (at least parts of) the test framework easily available within the kernel under test. When Kernel unit, functional, and regressions tests reside in the kernel sources, they evolve quicker as kernel developers contribute tests as part of their kernel work-flow. Maintaining tests and framework separately will make it harder to maintain them and keep them updated for us the kernel community. thanks, -- Shuah ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v4 3/3] drm/i915: Attach colorspace property and enable modeset
Hi Uma,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20181128]
[cannot apply to v4.20-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Uma-Shankar/Add-Colorspace-connector-property-interface/20181128-083317
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/i915/intel_hdmi.c:493:51: warning: mixing different enum
>> types
drivers/gpu/drm/i915/intel_hdmi.c:493:51: unsigned int enum
absolute_colorimetry_list versus
drivers/gpu/drm/i915/intel_hdmi.c:493:51: unsigned int enum
hdmi_colorimetry
include/linux/slab.h:332:43: warning: dubious: x & !y
include/linux/slab.h:332:43: warning: dubious: x & !y
vim +493 drivers/gpu/drm/i915/intel_hdmi.c
460
461 static void intel_hdmi_set_avi_infoframe(struct intel_encoder *encoder,
462 const struct intel_crtc_state
*crtc_state,
463 const struct
drm_connector_state *conn_state)
464 {
465 struct intel_hdmi *intel_hdmi =
enc_to_intel_hdmi(>base);
466 const struct drm_display_mode *adjusted_mode =
467 _state->base.adjusted_mode;
468 struct drm_connector *connector =
_hdmi->attached_connector->base;
469 bool is_hdmi2_sink =
connector->display_info.hdmi.scdc.supported ||
470 connector->display_info.color_formats &
DRM_COLOR_FORMAT_YCRCB420;
471 union hdmi_infoframe frame;
472 int ret;
473
474 ret = drm_hdmi_avi_infoframe_from_display_mode(,
475 adjusted_mode,
476 is_hdmi2_sink);
477 if (ret < 0) {
478 DRM_ERROR("couldn't fill AVI infoframe\n");
479 return;
480 }
481
482 if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
483 frame.avi.colorspace = HDMI_COLORSPACE_YUV420;
484 else if (crtc_state->output_format ==
INTEL_OUTPUT_FORMAT_YCBCR444)
485 frame.avi.colorspace = HDMI_COLORSPACE_YUV444;
486 else
487 frame.avi.colorspace = HDMI_COLORSPACE_RGB;
488
489 if (conn_state->colorspace == COLORIMETRY_DEFAULT) {
490 /* Set ITU 709 as default for HDMI */
491 frame.avi.colorimetry = COLORIMETRY_ITU_709;
492 } else if (conn_state->colorspace < COLORIMETRY_XV_YCC_601) {
> 493 frame.avi.colorimetry = conn_state->colorspace;
494 } else {
495 frame.avi.colorimetry = HDMI_COLORIMETRY_EXTENDED;
496 /*
497 * Starting from extended list where
COLORIMETRY_XV_YCC_601
498 * is the first extended mode and its value is 0 as per
HDMI
499 * specification.
500 */
501 frame.avi.extended_colorimetry = conn_state->colorspace
-
502
COLORIMETRY_XV_YCC_601;
503 }
504
505 drm_hdmi_avi_infoframe_quant_range(, adjusted_mode,
506
crtc_state->limited_color_range ?
507
HDMI_QUANTIZATION_RANGE_LIMITED :
508 HDMI_QUANTIZATION_RANGE_FULL,
509
intel_hdmi->rgb_quant_range_selectable,
510 is_hdmi2_sink);
511
512 drm_hdmi_avi_infoframe_content_type(,
513 conn_state);
514
515 /* TODO: handle pixel repetition for YCBCR420 outputs */
516 intel_write_infoframe(encoder, crtc_state,
517);
518 }
519
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/edid: Add display_info.rgb_quant_range_selectable
On Wed, Nov 28, 2018 at 12:19 PM Eric Anholt wrote: > > Ville Syrjala writes: > > > From: Ville Syrjälä > > > > Move the CEA-861 QS bit handling entirely into the edid code. No > > need to bother the drivers with this. > > > > Cc: Alex Deucher > > Cc: "Christian König" > > Cc: "David (ChunMing) Zhou" > > Cc: amd-...@lists.freedesktop.org > > Cc: Eric Anholt (supporter:DRM DRIVERS FOR VC4) > > Signed-off-by: Ville Syrjälä > > For vc4, > Acked-by: Eric Anholt > > Looks like a nice cleanup! for radeon: Acked-by: Alex Deucher ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] drm-misc-fixes
On Wed, Nov 28, 2018 at 3:04 PM Sean Paul wrote: > > > Hi Dave, > Happy meson week! A bunch of stellar fixes coming in this week from Lyude, > and a > couple others plugging holes in meson and core. > > > drm-misc-fixes-2018-11-28: > - mst: Don't try to validate ports while destroying them (Lyude) ICYMIRC, Lyude noticed a new issue with this patch, so we're going to revert and re-send. Please drop for now, Sean > - core: Don't set device to master unless set_master succeeds (Sergio) > - meson: Do vblank_on/off on enable/disable (Neil) > - meson: Use fast_io regmap option to avoid sleeping in irq ctx (Lyude) > - meson: Don't walk off the end of the OSD EOTF LUTs (Lyude) > > Cc: Lyude Paul > Cc: Sergio Correia > Cc: Neil Armstrong > > Cheers, Sean > > > The following changes since commit 2e6e902d185027f8e3cb8b7305238f7e35d6a436: > > Linux 4.20-rc4 (2018-11-25 14:19:31 -0800) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-11-28 > > for you to fetch changes up to 31e1ab494559fb46de304cc6c2aed1528f94b298: > > drm/meson: add support for 1080p25 mode (2018-11-26 16:14:28 -0500) > > > - mst: Don't try to validate ports while destroying them (Lyude) > - core: Don't set device to master unless set_master succeeds (Sergio) > - meson: Do vblank_on/off on enable/disable (Neil) > - meson: Use fast_io regmap option to avoid sleeping in irq ctx (Lyude) > - meson: Don't walk off the end of the OSD EOTF LUTs (Lyude) > > Cc: Lyude Paul > Cc: Sergio Correia > Cc: Neil Armstrong > > > Christian Hewitt (1): > drm/meson: add support for 1080p25 mode > > Lyude Paul (3): > drm/dp_mst: Skip validating ports during destruction, just ref > drm/meson: Enable fast_io in meson_dw_hdmi_regmap_config > drm/meson: Fix OOB memory accesses in meson_viu_set_osd_lut() > > Neil Armstrong (1): > drm/meson: Fixes for drm_crtc_vblank_on/off support > > Sergio Correia (1): > drm: set is_master to 0 upon drm_new_set_master() failure > > drivers/gpu/drm/drm_auth.c| 2 ++ > drivers/gpu/drm/drm_dp_mst_topology.c | 15 +-- > drivers/gpu/drm/meson/meson_crtc.c| 27 +-- > drivers/gpu/drm/meson/meson_dw_hdmi.c | 1 + > drivers/gpu/drm/meson/meson_venc.c| 4 > drivers/gpu/drm/meson/meson_viu.c | 12 ++-- > 6 files changed, 51 insertions(+), 10 deletions(-) > > -- > Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: radeon: fix overflow on 32bit systems
On Wed, Nov 28, 2018 at 3:14 AM Christian König
wrote:
>
> Am 27.11.18 um 12:50 schrieb Yang Xiao:
> > From: Young Xiao
> >
> > the type mem->start is unsigned long, so this can overflow on
> > 32bit system, since the type addr is uint64_t.
> >
> > Signed-off-by: Young Xiao
>
> Reviewed-by: Christian König
>
Applied. thanks!
Alex
> > ---
> > drivers/gpu/drm/radeon/radeon_vm.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/radeon_vm.c
> > b/drivers/gpu/drm/radeon/radeon_vm.c
> > index 7f1a9c7..51559d8 100644
> > --- a/drivers/gpu/drm/radeon/radeon_vm.c
> > +++ b/drivers/gpu/drm/radeon/radeon_vm.c
> > @@ -946,7 +946,7 @@ int radeon_vm_bo_update(struct radeon_device *rdev,
> > bo_va->flags &= ~RADEON_VM_PAGE_WRITEABLE;
> >
> > if (mem) {
> > - addr = mem->start << PAGE_SHIFT;
> > + addr = (u64)mem->start << PAGE_SHIFT;
> > if (mem->mem_type != TTM_PL_SYSTEM) {
> > bo_va->flags |= RADEON_VM_PAGE_VALID;
> > }
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 4.20.0-rc3 nouveau/Quadro P2000 Mobile: runpm causing ACPI errors, lockups
On Wed, Nov 28, 2018 at 05:55:44PM +0200, Mika Westerberg wrote:
> On Wed, Nov 28, 2018 at 10:09:22AM -0500, Michael S. Tsirkin wrote:
> > Yea all this is weird, in particular I wonder why does everyone
> > using dsm insists on saying Arg4
> > when they actually mean Arg3. ACPI numbers arguments from 0.
> >
> > So it's a bit ugly, and maybe worth fixing but unlikely to be
> > an actual issue simply because we end up not using DSM in the end.
>
> I agree.
>
> > Poking at the probing code in nouveau_pr3_present, I started to wonder:
> > should I try to hack it to disable d3cold and pr3 and see what
> > happens?
>
> I guess it is worth a try. You can do it from sysfs for the graphics
> PCI device there is an attribute d3cold_allowed that controls this.
>
> [snip]
But probably too late by time nouveau is up at boot?
> > > > 00:14.3 Network controller: Intel Corporation Wireless-AC 9560
> > > > [Jefferson Peak] (rev 10)
> > > >
> > > > so really shouldn't be affected, but go figure. If driver really is
> > > > getting
> > > > all-ones from the device, it just might try to poke at a wrong b:d.f by
> > > > mistake
> > > > maybe ...
> > >
> > > Or it the power resource is shared by wifi as well.
> >
> > Is there a way to find out through e.g. sysfs?
>
> It is not shared, I checked from the acpidump you provided. Possibly the
> infinite loop in AML when executing NVPO method have some effect on
> this.
>
> [snip]
>
> > > No need to send, I can read it from the bugzilla just fine. Can you attach
> > > acpidump there as well?
> >
> > Done. lspci -x too just in case.
>
> Looking at the dmesg:
>
> [ 52.917009] No Local Variables are initialized for Method [NVPO]
> [ 52.917011] No Arguments are initialized for method [NVPO]
> [ 52.917012] ACPI Error: Method parse/execution failed
> \_SB.PCI0.PEG0.PEGP.NVPO, AE_AML_LOOP_TIMEOUT (20181003/psparse-516)
> [ 52.917063] ACPI Error: Method parse/execution failed \_SB.PCI0.PGON,
> AE_AML_LOOP_TIMEOUT (20181003/psparse-516)
> [ 52.917084] ACPI Error: Method parse/execution failed
> \_SB.PCI0.PEG0.PG00._ON, AE_AML_LOOP_TIMEOUT (20181003/psparse-516)
>
> So what happens here is that Linux turns off power resource
> \_SB.PCI0.PEG0.PG00 by calling its _OFF method (happens when the root
> port is runtime suspended). This ends up calling \_SB.PCI0.PGON which
> calls \_SB.PCI0.PEG0.PEGP.NVPO.
>
> The last method looks like this:
>
>Method (NVPO, 0, NotSerialized)
> {
> While ((\_SB.PCI0.P0LS < 0x03))
> {
> Sleep (One)
> }
>
> So basically it polls P0LS register infinitely if the returned value is
> less than 3. I suspect this is the issue and it then makes the other
> like wifi to fail to execute its methods.
>
> P0LS comes from this operation region:
>
> OperationRegion (OPG0, SystemMemory, (XBAS + 0x8000), 0x1000)
> Field (OPG0, AnyAcc, NoLock, Preserve)
> {
> ...
> Offset (0x216),
> P0LS, 4,
>
> This is some host bridge register but not sure which because XBAS value
> cannot be determined from the acpidump.
Oh I think XBAS is in SSDT4:
OperationRegion (SANV, SystemMemory, 0x4FBF7018, 0x01F4)
Field (SANV, AnyAcc, Lock, Preserve)
{
ASLB, 32,
IMON, 8,
IGDS, 8,
IBTT, 8,
IPAT, 8,
IPSC, 8,
IBIA, 8,
ISSC, 8,
IDMS, 8,
IF1E, 8,
HVCO, 8,
GSMI, 8,
PAVP, 8,
CADL, 8,
CSTE, 16,
NSTE, 16,
NDID, 8,
DID1, 32,
DID2, 32,
DID3, 32,
DID4, 32,
DID5, 32,
DID6, 32,
DID7, 32,
DID8, 32,
DID9, 32,
DIDA, 32,
DIDB, 32,
DIDC, 32,
DIDD, 32,
DIDE, 32,
DIDF, 32,
DIDX, 32,
NXD1, 32,
NXD2, 32,
NXD3, 32,
NXD4, 32,
NXD5, 32,
NXD6, 32,
NXD7, 32,
NXD8, 32,
NXDX, 32,
LIDS, 8,
KSV0, 32,
KSV1, 8,
BRTL, 8,
ALSE, 8,
ALAF, 8,
LLOW, 8,
LHIH, 8,
ALFP, 8,
IPTP, 8,
EDPV, 8,
SGMD, 8,
SGFL, 8,
SGGP, 8,
HRE0, 8,
HRG0, 32,
HRA0, 8,
PWE0, 8,
PWG0, 32,
PWA0, 8,
P1GP, 8,
HRE1, 8,
HRG1, 32,
HRA1, 8,
PWE1, 8,
PWG1, 32,
PWA1, 8,
P2GP, 8,
HRE2, 8,
HRG2, 32,
HRA2, 8,
PWE2, 8,
PWG2, 32,
PWA2, 8,
DLPW, 16,
DLHR, 16,
EECP, 8,
XBAS, 32,
GBAS, 16,
NVGA, 32,
NVHA, 32,
Re: [PATCH] drm/amd/pp: fix spelling mistake "dependancy" -> "dependency"
On Tue, Nov 27, 2018 at 9:19 AM Colin King wrote: > > From: Colin Ian King > > There are spelling mistakes in PP_ASSERT_WITH_CODE messages, fix these. > > Signed-off-by: Colin Ian King Applied. thanks! Alex > --- > drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c > b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c > index 88f6b35ea6fe..5dcd21d29dbf 100644 > --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c > +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c > @@ -269,7 +269,7 @@ static int smu7_construct_voltage_tables(struct pp_hwmgr > *hwmgr) > > hwmgr->dyn_state.mvdd_dependency_on_mclk); > > PP_ASSERT_WITH_CODE((0 == result), > - "Failed to retrieve SVI2 MVDD table from > dependancy table.", > + "Failed to retrieve SVI2 MVDD table from > dependency table.", > return result;); > } > > @@ -288,7 +288,7 @@ static int smu7_construct_voltage_tables(struct pp_hwmgr > *hwmgr) > result = > phm_get_svi2_voltage_table_v0(&(data->vddci_voltage_table), > > hwmgr->dyn_state.vddci_dependency_on_mclk); > PP_ASSERT_WITH_CODE((0 == result), > - "Failed to retrieve SVI2 VDDCI table from > dependancy table.", > + "Failed to retrieve SVI2 VDDCI table from > dependency table.", > return result); > } > > @@ -317,7 +317,7 @@ static int smu7_construct_voltage_tables(struct pp_hwmgr > *hwmgr) > table_info->vddc_lookup_table); > > PP_ASSERT_WITH_CODE((0 == result), > - "Failed to retrieve SVI2 VDDC table from dependancy > table.", return result;); > + "Failed to retrieve SVI2 VDDC table from dependency > table.", return result;); > } > > tmp = smum_get_mac_definition(hwmgr, SMU_MAX_LEVELS_VDDC); > -- > 2.19.1 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/9] drm/i915/psr: Don't tell sink that main link will be active while is active PSR2
On Wed, 2018-11-28 at 11:02 -0800, Rodrigo Vivi wrote:
> On Mon, Nov 26, 2018 at 04:37:03PM -0800, José Roberto de Souza
> wrote:
> > For PSR2 there is no register to tell HW to keep main link enabled
> > while PSR2 is active, so don't configure sink DPCD with a
> > misleading value.
> >
> > Cc: Dhinakaran Pandiyan
> > Cc: Rodrigo Vivi
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/intel_psr.c | 10 ++
> > 1 file changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index f5d27a02eb28..888e348cc1b4 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -391,12 +391,14 @@ static void intel_psr_enable_sink(struct
> > intel_dp *intel_dp)
> > drm_dp_dpcd_writeb(_dp->aux,
> > DP_RECEIVER_ALPM_CONFIG,
> >DP_ALPM_ENABLE);
> > dpcd_val |= DP_PSR_ENABLE_PSR2;
> > + } else {
> > + if (dev_priv->psr.link_standby)
> > + dpcd_val |= DP_PSR_MAIN_LINK_ACTIVE;
> > +
> > + if (INTEL_GEN(dev_priv) >= 8)
> > + dpcd_val |= DP_PSR_CRC_VERIFICATION;
>
> commit message only mention the link stand-by...
> could you please do this in a separated patch?
We were already doing it for PSR1, I just grouped all the PSR1 checks
inside of this else block, so there is no functional change in CRC
verification but I can move it to a separated patch if you want.
>
> > }
> >
> > - if (dev_priv->psr.link_standby)
> > - dpcd_val |= DP_PSR_MAIN_LINK_ACTIVE;
> > - if (!dev_priv->psr.psr2_enabled && INTEL_GEN(dev_priv) >= 8)
> > - dpcd_val |= DP_PSR_CRC_VERIFICATION;
> > drm_dp_dpcd_writeb(_dp->aux, DP_PSR_EN_CFG, dpcd_val);
> >
> > drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER,
> > DP_SET_POWER_D0);
> > --
> > 2.19.2
> >
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH 3/3] drm/msm: Use Hardware counters for perf profiling
On Fri, Oct 26, 2018 at 9:46 AM Sharat Masetty wrote:
>
> Added Rob to this thread.
>
> On 10/17/2018 8:05 PM, Jordan Crouse wrote:
> > On Wed, Oct 17, 2018 at 06:34:01PM +0530, Sharat Masetty wrote:
> >> This patch attempts to make use of the hardware counters for GPU busy %
> >> estimation when possible and skip using the software counters as it also
> >> accounts for software side delays. This should help give more accurate
> >> representation of the GPU workload.
> >
> > I would leave this more to Rob as this particular file makes more sense for
> > freedreno than it does for us but I think in general if you want to do this
> > then we should do use the hardware for all targets and get rid of the
> > mix of the old and the new.
> Thanks for the comments Jordan. Yes, I prefer the same too, but the only
> limiting factor for me is that I don't have a way to test changes for
> targets such as a3xx and a4xx, and I also do not know if there is anyone
> actually using this currently.
>
> Hi Rob,
> Can you please share your comments on this? Is it okay to remove
> software counters functionality?
In principle yes.. although one side-comment is that there are
patches floating around for a2xx, which is from long enough ago that I
don't remember what the perf-ctr situation is there.
I guess if we can be reasonably confident to implement it w/ hw
counters for all the generations, then I don't see a big need to keep
the sw counter functionality.
I should, in theory, be able to test a3xx/a4xx/a5xx.. a4xx might be a
bit harder to get a recent upstream kernel running on
BR,
-R
>
> Sharat
> >
> >> Signed-off-by: Sharat Masetty
> >> ---
> >> drivers/gpu/drm/msm/msm_gpu.c | 30 ++
> >> drivers/gpu/drm/msm/msm_gpu.h | 5 +++--
> >> drivers/gpu/drm/msm/msm_perf.c | 10 +-
> >> 3 files changed, 34 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> >> index e9b5426..a896541 100644
> >> --- a/drivers/gpu/drm/msm/msm_gpu.c
> >> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> >> @@ -592,6 +592,9 @@ static void update_sw_cntrs(struct msm_gpu *gpu)
> >> uint32_t elapsed;
> >> unsigned long flags;
> >>
> >> +if (gpu->funcs->gpu_busy)
> >> +return;
> >
> > Like here - there isn't any reason to not have a gpu_busy for each target
> > so then this code could mostly go away.
> >
> >> spin_lock_irqsave(>perf_lock, flags);
> >> if (!gpu->perfcntr_active)
> >> goto out;
> >> @@ -620,6 +623,7 @@ void msm_gpu_perfcntr_start(struct msm_gpu *gpu)
> >> /* we could dynamically enable/disable perfcntr registers too.. */
> >> gpu->last_sample.active = msm_gpu_active(gpu);
> >> gpu->last_sample.time = ktime_get();
> >> +gpu->last_sample.busy_cycles = 0;
> >> gpu->activetime = gpu->totaltime = 0;
> >> gpu->perfcntr_active = true;
> >> update_hw_cntrs(gpu, 0, NULL);
> >> @@ -632,9 +636,22 @@ void msm_gpu_perfcntr_stop(struct msm_gpu *gpu)
> >> pm_runtime_put_sync(>pdev->dev);
> >> }
> >>
> >> +static void msm_gpu_hw_sample(struct msm_gpu *gpu, uint64_t *activetime,
> >> +uint64_t *totaltime)
> >> +{
> >> +ktime_t time;
> >> +
> >> +*activetime = gpu->funcs->gpu_busy(gpu,
> >> +>last_sample.busy_cycles);
> >> +
> >> +time = ktime_get();
> >> +*totaltime = ktime_us_delta(time, gpu->last_sample.time);
> >> +gpu->last_sample.time = time;
> >> +}
> >
> > This can all be done inline in the sample function below.
> >
> >> /* returns -errno or # of cntrs sampled */
> >> -int msm_gpu_perfcntr_sample(struct msm_gpu *gpu, uint32_t *activetime,
> >> -uint32_t *totaltime, uint32_t ncntrs, uint32_t *cntrs)
> >> +int msm_gpu_perfcntr_sample(struct msm_gpu *gpu, uint64_t *activetime,
> >> +uint64_t *totaltime, uint32_t ncntrs, uint32_t *cntrs)
> >
> > This might be an good change (though if our activetime or totaltime ever
> > goes over 32 bits we've got ourselves a problem) - but it should be in a
> > separate patch.
> >
> >> {
> >> unsigned long flags;
> >> int ret;
> >> @@ -646,13 +663,18 @@ int msm_gpu_perfcntr_sample(struct msm_gpu *gpu,
> >> uint32_t *activetime,
> >> goto out;
> >> }
> >>
> >> +ret = update_hw_cntrs(gpu, ncntrs, cntrs);
> >> +
> >> +if (gpu->funcs->gpu_busy) {
> >> +msm_gpu_hw_sample(gpu, activetime, totaltime);
> >> +goto out;
> >> +}
> >> +
> >> *activetime = gpu->activetime;
> >> *totaltime = gpu->totaltime;
> >>
> >> gpu->activetime = gpu->totaltime = 0;
> >>
> >> -ret = update_hw_cntrs(gpu, ncntrs, cntrs);
> >> -
> >> out:
> >> spin_unlock_irqrestore(>perf_lock, flags);
> >>
> >> diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
> >> index 0ff23ca..7dc775f 100644
> >> --- a/drivers/gpu/drm/msm/msm_gpu.h
> >> +++ b/drivers/gpu/drm/msm/msm_gpu.h
>
[PULL] drm-misc-fixes
Hi Dave, Happy meson week! A bunch of stellar fixes coming in this week from Lyude, and a couple others plugging holes in meson and core. drm-misc-fixes-2018-11-28: - mst: Don't try to validate ports while destroying them (Lyude) - core: Don't set device to master unless set_master succeeds (Sergio) - meson: Do vblank_on/off on enable/disable (Neil) - meson: Use fast_io regmap option to avoid sleeping in irq ctx (Lyude) - meson: Don't walk off the end of the OSD EOTF LUTs (Lyude) Cc: Lyude Paul Cc: Sergio Correia Cc: Neil Armstrong Cheers, Sean The following changes since commit 2e6e902d185027f8e3cb8b7305238f7e35d6a436: Linux 4.20-rc4 (2018-11-25 14:19:31 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-11-28 for you to fetch changes up to 31e1ab494559fb46de304cc6c2aed1528f94b298: drm/meson: add support for 1080p25 mode (2018-11-26 16:14:28 -0500) - mst: Don't try to validate ports while destroying them (Lyude) - core: Don't set device to master unless set_master succeeds (Sergio) - meson: Do vblank_on/off on enable/disable (Neil) - meson: Use fast_io regmap option to avoid sleeping in irq ctx (Lyude) - meson: Don't walk off the end of the OSD EOTF LUTs (Lyude) Cc: Lyude Paul Cc: Sergio Correia Cc: Neil Armstrong Christian Hewitt (1): drm/meson: add support for 1080p25 mode Lyude Paul (3): drm/dp_mst: Skip validating ports during destruction, just ref drm/meson: Enable fast_io in meson_dw_hdmi_regmap_config drm/meson: Fix OOB memory accesses in meson_viu_set_osd_lut() Neil Armstrong (1): drm/meson: Fixes for drm_crtc_vblank_on/off support Sergio Correia (1): drm: set is_master to 0 upon drm_new_set_master() failure drivers/gpu/drm/drm_auth.c| 2 ++ drivers/gpu/drm/drm_dp_mst_topology.c | 15 +-- drivers/gpu/drm/meson/meson_crtc.c| 27 +-- drivers/gpu/drm/meson/meson_dw_hdmi.c | 1 + drivers/gpu/drm/meson/meson_venc.c| 4 drivers/gpu/drm/meson/meson_viu.c | 12 ++-- 6 files changed, 51 insertions(+), 10 deletions(-) -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108825] Regression Raven Ridge: Banding on eDP display
https://bugs.freedesktop.org/show_bug.cgi?id=108825 --- Comment #7 from Samantha McVey --- Nicholas, Reverting that commit (307638884f721b02b6a54ee8b351c5b4434bd4a6) on the top of amd-staging-drm-next resolves the banding issues. So it is that commit that is causing the problem. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu drm-fixes-4.20
Hi Dave, Fixes for 4.20. Nothing major. - DC DP MST fix - GPUVM fix for huge page mapping - RLC fix for vega20 The following changes since commit a5d0f4565996e5595a10cb57b3d1e3d74379c502: drm/amdgpu: Enable HDP memory light sleep (2018-11-20 14:40:15 -0500) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-4.20 for you to fetch changes up to ad97d9de45835b6a0f71983b0ae0cffd7306730a: drm/amdgpu: Add delay after enable RLC ucode (2018-11-28 14:52:44 -0500) Felix Kuehling (2): drm/amdgpu: Cast to uint64_t before left shift drm/amdgpu: Avoid endless loop in GPUVM fragment processing Lyude Paul (2): drm/amd/dm: Don't forget to attach MST encoders drm/amd/dm: Understand why attaching path/tile properties are needed shaoyunl (1): drm/amdgpu: Add delay after enable RLC ucode drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 14 -- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 7 --- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 5 ++--- 3 files changed, 14 insertions(+), 12 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH RFC 2/5] cgroup: Add mechanism to register vendor specific DRM devices
On Wed, Nov 28, 2018 at 4:14 AM Joonas Lahtinen wrote: > So we can only choose the lowest common denominator, right? > > Any core count out of total core count should translate nicely into a > fraction, so what would be the problem with percentage amounts? I don't think having an abstracted resource necessarily equate 'lowest'. The issue with percentage is the lack of precision. If you look at cpuset cgroup, you can see the specification can be very precise: # /bin/echo 1-4,6 > cpuset.cpus -> set cpus list to cpus 1,2,3,4,6 (https://www.kernel.org/doc/Documentation/cgroup-v1/cpusets.txt) The driver can translate something like this to core count and then to percentage and handle accordingly while the reverse is not possible. (You can't tell which set of CUs/EUs a user want from a percentage request.) It's also not clear to me, from user/application/admin/resource management perspective, how the base core counts of a GPU is relevant to the workload (since percentage is a 'relative' quantity.) For example, let say a workload wants to use 256 'cores', does it matter if that workload is put on a GPU with 1024 cores or a GPU with 4096 cores total? I am not dismissing the possible need for percentage. I just think there should be a way to accommodate more than just the 'lowest'. Regards, Kennny > > > That combined with the "GPU memory usable" property should be a good > > > starting point to start subdividing the GPU resources for multiple > > > users. > > > > > > Regards, Joonas > > > > > > > > > > > Your feedback is highly appreciated. > > > > > > > > Best Regards, > > > > Harish > > > > > > > > > > > > > > > > From: amd-gfx on behalf of > > > > Tejun Heo > > > > Sent: Tuesday, November 20, 2018 5:30 PM > > > > To: Ho, Kenny > > > > Cc: cgro...@vger.kernel.org; intel-...@lists.freedesktop.org; > > > > y2ke...@gmail.com; amd-...@lists.freedesktop.org; > > > > dri-devel@lists.freedesktop.org > > > > Subject: Re: [PATCH RFC 2/5] cgroup: Add mechanism to register vendor > > > > specific DRM devices > > > > > > > > > > > > Hello, > > > > > > > > On Tue, Nov 20, 2018 at 10:21:14PM +, Ho, Kenny wrote: > > > > > By this reply, are you suggesting that vendor specific resources > > > > > will never be acceptable to be managed under cgroup? Let say a user > > > > > > > > I wouldn't say never but whatever which gets included as a cgroup > > > > controller should have clearly defined resource abstractions and the > > > > control schemes around them including support for delegation. AFAICS, > > > > gpu side still seems to have a long way to go (and it's not clear > > > > whether that's somewhere it will or needs to end up). > > > > > > > > > want to have similar functionality as what cgroup is offering but to > > > > > manage vendor specific resources, what would you suggest as a > > > > > solution? When you say keeping vendor specific resource regulation > > > > > inside drm or specific drivers, do you mean we should replicate the > > > > > cgroup infrastructure there or do you mean either drm or specific > > > > > driver should query existing hierarchy (such as device or perhaps > > > > > cpu) for the process organization information? > > > > > > > > > > To put the questions in more concrete terms, let say a user wants to > > > > > expose certain part of a gpu to a particular cgroup similar to the > > > > > way selective cpu cores are exposed to a cgroup via cpuset, how > > > > > should we go about enabling such functionality? > > > > > > > > Do what the intel driver or bpf is doing? It's not difficult to hook > > > > into cgroup for identification purposes. > > > > > > > > Thanks. > > > > > > > > -- > > > > tejun > > > > ___ > > > > amd-gfx mailing list > > > > amd-...@lists.freedesktop.org > > > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx > > > > > > > > > > > > amd-gfx Info Page - freedesktop.org > > > > lists.freedesktop.org > > > > To see the collection of prior postings to the list, visit the amd-gfx > > > > Archives.. Using amd-gfx: To post a message to all the list members, > > > > send email to amd-...@lists.freedesktop.org. You can subscribe to the > > > > list, or change your existing subscription, in the sections below. > > > > > > > > ___ > > > > Intel-gfx mailing list > > > > intel-...@lists.freedesktop.org > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 9/9] drm/cma-helper: Remove unused fbdev code
Hi Noralf,
Thank you for the patch.
On Thursday, 25 October 2018 23:13:40 EET Noralf Trønnes wrote:
> CMA helper drivers have been converted to drm_fbdev_generic_setup()
> so the fbdev code can be removed.
>
> Cc: Laurent Pinchart
> Signed-off-by: Noralf Trønnes
> Acked-by: Sam Ravnborg
> ---
>
> Changes since version 1:
> - Rebased
>
> drivers/gpu/drm/Kconfig | 4 --
> drivers/gpu/drm/drm_fb_cma_helper.c | 130 -
> include/drm/drm_fb_cma_helper.h | 22 --
> 3 files changed, 156 deletions(-)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 4385f00e1d05..bd943a71756c 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -170,10 +170,6 @@ config DRM_KMS_CMA_HELPER
> bool
> depends on DRM
> select DRM_GEM_CMA_HELPER
> - select DRM_KMS_FB_HELPER
> - select FB_SYS_FILLRECT
> - select FB_SYS_COPYAREA
> - select FB_SYS_IMAGEBLIT
> help
> Choose this if you need the KMS CMA helper functions
>
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> b/drivers/gpu/drm/drm_fb_cma_helper.c index fc2b42dd3dc6..0ddf9c65e5ab
> 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -18,8 +18,6 @@
> */
>
> #include
> -#include
> -#include
> #include
> #include
> #include
> @@ -27,10 +25,6 @@
> #include
As far as I can tell, you can also drop drm/drm_fb_cma_helper.h and drm/
drm_print.h. If you include drm/drm_fourcc.h and drm/drm_plane.h, you can also
drop drm/drmP.h.
Apart from that,
Reviewed-by: Laurent Pinchart
> #include
>
> -struct drm_fbdev_cma {
> - struct drm_fb_helperfb_helper;
> -};
> -
> /**
> * DOC: framebuffer cma helper functions
> *
> @@ -39,16 +33,8 @@ struct drm_fbdev_cma {
> *
> * drm_gem_fb_create() is used in the _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_fb_cma_fbdev_init(). drm_fb_cma_fbdev_fini() tears it down.
> */
>
> -static inline struct drm_fbdev_cma *to_fbdev_cma(struct drm_fb_helper
> *helper) -{
> - return container_of(helper, struct drm_fbdev_cma, fb_helper);
> -}
> -
> /**
> * drm_fb_cma_get_gem_obj() - Get CMA GEM object for framebuffer
> * @fb: The framebuffer
> @@ -105,119 +91,3 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct
> drm_framebuffer *fb, return paddr;
> }
> EXPORT_SYMBOL_GPL(drm_fb_cma_get_gem_addr);
> -
> -/**
> - * drm_fb_cma_fbdev_init() - Allocate and initialize fbdev emulation
> - * @dev: DRM device
> - * @preferred_bpp: Preferred bits per pixel for the device.
> - * @dev->mode_config.preferred_depth is used if this is
> zero. - * @max_conn_count: Maximum number of connectors.
> - * @dev->mode_config.num_connector is used if this is
> zero. - *
> - * Returns:
> - * Zero on success or negative error code on failure.
> - */
> -int drm_fb_cma_fbdev_init(struct drm_device *dev, unsigned int
> preferred_bpp, -unsigned int max_conn_count)
> -{
> - struct drm_fbdev_cma *fbdev_cma;
> -
> - /* dev->fb_helper will indirectly point to fbdev_cma after this call */
> - fbdev_cma = drm_fbdev_cma_init(dev, preferred_bpp, max_conn_count);
> - return PTR_ERR_OR_ZERO(fbdev_cma);
> -}
> -EXPORT_SYMBOL_GPL(drm_fb_cma_fbdev_init);
> -
> -/**
> - * drm_fb_cma_fbdev_fini() - Teardown fbdev emulation
> - * @dev: DRM device
> - */
> -void drm_fb_cma_fbdev_fini(struct drm_device *dev)
> -{
> - if (dev->fb_helper)
> - drm_fbdev_cma_fini(to_fbdev_cma(dev->fb_helper));
> -}
> -EXPORT_SYMBOL_GPL(drm_fb_cma_fbdev_fini);
> -
> -static const struct drm_fb_helper_funcs drm_fb_cma_helper_funcs = {
> - .fb_probe = drm_fb_helper_generic_probe,
> -};
> -
> -/**
> - * drm_fbdev_cma_init() - Allocate and initializes a drm_fbdev_cma struct
> - * @dev: DRM device
> - * @preferred_bpp: Preferred bits per pixel for the device
> - * @max_conn_count: Maximum number of connectors
> - *
> - * Returns a newly allocated drm_fbdev_cma struct or a ERR_PTR.
> - */
> -struct drm_fbdev_cma *drm_fbdev_cma_init(struct drm_device *dev,
> - unsigned int preferred_bpp, unsigned int max_conn_count)
> -{
> - struct drm_fbdev_cma *fbdev_cma;
> - struct drm_fb_helper *fb_helper;
> - int ret;
> -
> - fbdev_cma = kzalloc(sizeof(*fbdev_cma), GFP_KERNEL);
> - if (!fbdev_cma)
> - return ERR_PTR(-ENOMEM);
> -
> - fb_helper = _cma->fb_helper;
> -
> - ret = drm_client_new(dev, _helper->client, "fbdev", NULL);
> - if (ret)
> - goto err_free;
> -
> - ret = drm_fb_helper_fbdev_setup(dev, fb_helper,
> _fb_cma_helper_funcs,
> - preferred_bpp, max_conn_count);
> - if (ret)
> - goto err_client_put;
> -
> - return fbdev_cma;
> -
> -err_client_put:
> -
[Bug 201795] [Regression] Wrong 4k resolution detected with DisplayPort to HDMI adapter on amdgpu
https://bugzilla.kernel.org/show_bug.cgi?id=201795 --- Comment #6 from thomas.lassdiesonner...@gmx.de --- Created attachment 279721 --> https://bugzilla.kernel.org/attachment.cgi?id=279721=edit xorg log of kernel 4.14 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201795] [Regression] Wrong 4k resolution detected with DisplayPort to HDMI adapter on amdgpu
https://bugzilla.kernel.org/show_bug.cgi?id=201795 --- Comment #7 from thomas.lassdiesonner...@gmx.de --- Created attachment 279723 --> https://bugzilla.kernel.org/attachment.cgi?id=279723=edit xorg log of kernel 4.19 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201795] [Regression] Wrong 4k resolution detected with DisplayPort to HDMI adapter on amdgpu
https://bugzilla.kernel.org/show_bug.cgi?id=201795 --- Comment #5 from thomas.lassdiesonner...@gmx.de --- Created attachment 279719 --> https://bugzilla.kernel.org/attachment.cgi?id=279719=edit dmesg of kernel 4.19 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201795] [Regression] Wrong 4k resolution detected with DisplayPort to HDMI adapter on amdgpu
https://bugzilla.kernel.org/show_bug.cgi?id=201795 --- Comment #4 from thomas.lassdiesonner...@gmx.de --- Created attachment 279717 --> https://bugzilla.kernel.org/attachment.cgi?id=279717=edit dmesg of kernel 4.14 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH 1/1] drm/msm/a6xx: Add support for an interconnect path
On Wed, Nov 28, 2018 at 1:29 PM Jordan Crouse wrote:
>
> Try to get the interconnect path for the GPU and vote for the maximum
> bandwidth to support all frequencies. This is needed for performance.
> Later we will want to scale the bandwidth based on the frequency to
> also optimize for power but that will require some device tree
> infrastructure that does not yet exist.
>
> Signed-off-by: Jordan Crouse
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 20
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 9 +
> drivers/gpu/drm/msm/msm_gpu.h | 3 +++
> 3 files changed, 32 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> index 546599a7ab05..b96ae2ab04bb 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> @@ -3,6 +3,7 @@
>
> #include
> #include
> +#include
> #include
>
> #include "a6xx_gpu.h"
> @@ -63,6 +64,9 @@ static bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
>
> static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
> {
> + struct a6xx_gpu *a6xx_gpu = container_of(gmu, struct a6xx_gpu, gmu);
> + struct adreno_gpu *adreno_gpu = _gpu->base;
> + struct msm_gpu *gpu = _gpu->base;
> int ret;
>
> gmu_write(gmu, REG_A6XX_GMU_DCVS_ACK_OPTION, 0);
> @@ -85,6 +89,12 @@ static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int
> index)
> dev_err(gmu->dev, "GMU set GPU frequency error: %d\n", ret);
>
> gmu->freq = gmu->gpu_freqs[index];
> +
> + /*
> +* Eventually we will want to scale the path vote with the frequency
> but
> +* for now leave it t at max so that the performance is nominal.
> +*/
> + icc_set(gpu->icc_path, 0, 721600);
Should we get these hard-coded rates from 'struct adreno_info'? I
guess they are not constant across all the variants of a given
generation?
I assume at least the port label would be the same for all?
BR,
-R
> }
>
> void a6xx_gmu_set_freq(struct msm_gpu *gpu, unsigned long freq)
> @@ -680,6 +690,8 @@ int a6xx_gmu_reset(struct a6xx_gpu *a6xx_gpu)
>
> int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
> {
> + struct adreno_gpu *adreno_gpu = _gpu->base;
> + struct msm_gpu *gpu = _gpu->base;
> struct a6xx_gmu *gmu = _gpu->gmu;
> int status, ret;
>
> @@ -695,6 +707,9 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
> if (ret)
> goto out;
>
> + /* Set the bus quota to a reasonable value for boot */
> + icc_set(gpu->icc_path, 0, 307200);
> +
> a6xx_gmu_irq_enable(gmu);
>
> /* Check to see if we are doing a cold or warm boot */
> @@ -735,6 +750,8 @@ bool a6xx_gmu_isidle(struct a6xx_gmu *gmu)
>
> int a6xx_gmu_stop(struct a6xx_gpu *a6xx_gpu)
> {
> + struct adreno_gpu *adreno_gpu = _gpu->base;
> + struct msm_gpu *gpu = _gpu->base;
> struct a6xx_gmu *gmu = _gpu->gmu;
> u32 val;
>
> @@ -781,6 +798,9 @@ int a6xx_gmu_stop(struct a6xx_gpu *a6xx_gpu)
> /* Tell RPMh to power off the GPU */
> a6xx_rpmh_stop(gmu);
>
> + /* Remove the bus vote */
> + icc_set(gpu->icc_path, 0, 0);
> +
> clk_bulk_disable_unprepare(gmu->nr_clocks, gmu->clocks);
>
> pm_runtime_put_sync(gmu->dev);
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 93d70f4a2154..9bab491912cf 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -21,6 +21,7 @@
> #include
> #include
> #include
> +#include
> #include "adreno_gpu.h"
> #include "msm_gem.h"
> #include "msm_mmu.h"
> @@ -695,6 +696,11 @@ static int adreno_get_pwrlevels(struct device *dev,
>
> DBG("fast_rate=%u, slow_rate=2700", gpu->fast_rate);
>
> + /* Check for an interconnect path for the bus */
> + gpu->icc_path = of_icc_get(dev, "port0");
> + if (IS_ERR(gpu->icc_path))
> + gpu->icc_path = NULL;
> +
> return 0;
> }
>
> @@ -733,10 +739,13 @@ int adreno_gpu_init(struct drm_device *drm, struct
> platform_device *pdev,
>
> void adreno_gpu_cleanup(struct adreno_gpu *adreno_gpu)
> {
> + struct msm_gpu *gpu = _gpu->base;
> unsigned int i;
>
> for (i = 0; i < ARRAY_SIZE(adreno_gpu->info->fw); i++)
> release_firmware(adreno_gpu->fw[i]);
>
> + icc_put(gpu->icc_path);
> +
> msm_gpu_cleanup(_gpu->base);
> }
> diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
> index f82bac08..7b04d166 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.h
> +++ b/drivers/gpu/drm/msm/msm_gpu.h
> @@ -20,6 +20,7 @@
>
> #include
> #include
> +#include
>
> #include "msm_drv.h"
> #include "msm_fence.h"
> @@ -119,6 +120,8 @@ struct msm_gpu {
> struct clk *ebi1_clk, *core_clk, *rbbmtimer_clk;
> uint32_t fast_rate;
>
>
Re: [PATCH 2/9] drm/i915/psr: Don't tell sink that main link will be active while is active PSR2
On Mon, Nov 26, 2018 at 04:37:03PM -0800, José Roberto de Souza wrote:
> For PSR2 there is no register to tell HW to keep main link enabled
> while PSR2 is active, so don't configure sink DPCD with a
> misleading value.
>
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/intel_psr.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index f5d27a02eb28..888e348cc1b4 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -391,12 +391,14 @@ static void intel_psr_enable_sink(struct intel_dp
> *intel_dp)
> drm_dp_dpcd_writeb(_dp->aux, DP_RECEIVER_ALPM_CONFIG,
> DP_ALPM_ENABLE);
> dpcd_val |= DP_PSR_ENABLE_PSR2;
> + } else {
> + if (dev_priv->psr.link_standby)
> + dpcd_val |= DP_PSR_MAIN_LINK_ACTIVE;
> +
> + if (INTEL_GEN(dev_priv) >= 8)
> + dpcd_val |= DP_PSR_CRC_VERIFICATION;
commit message only mention the link stand-by...
could you please do this in a separated patch?
> }
>
> - if (dev_priv->psr.link_standby)
> - dpcd_val |= DP_PSR_MAIN_LINK_ACTIVE;
> - if (!dev_priv->psr.psr2_enabled && INTEL_GEN(dev_priv) >= 8)
> - dpcd_val |= DP_PSR_CRC_VERIFICATION;
> drm_dp_dpcd_writeb(_dp->aux, DP_PSR_EN_CFG, dpcd_val);
>
> drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER, DP_SET_POWER_D0);
> --
> 2.19.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/9] drm/rcar-du: Use drm_fbdev_generic_setup()
Hi Noralf,
Thank you for the patch.
On Wednesday, 28 November 2018 19:03:39 EET Noralf Trønnes wrote:
> Den 25.10.2018 22.13, skrev Noralf Trønnes:
> > The CMA helper is already using the drm_fb_helper_generic_probe part of
> > the generic fbdev emulation. This patch makes full use of the generic
> > fbdev emulation by using its drm_client callbacks. This means that
> > drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
> > now handled by the emulation code. Additionally fbdev unregister happens
> > automatically on drm_dev_unregister().
> >
> > The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
> > driver. This is done to highlight the fact that fbdev emulation is an
> > internal client that makes use of the driver, it is not part of the
> > driver as such. If fbdev setup fails, an error is printed, but the driver
> > succeeds probing.
> >
> > drm_fbdev_generic_setup() handles mode_config.num_connector being zero.
> > In that case it retries fbdev setup on the next .output_poll_changed.
> >
> > Cc: Laurent Pinchart
> > Signed-off-by: Noralf Trønnes
> > Acked-by: Sam Ravnborg
> > Reviewed-by: Laurent Pinchart
> > ---
> >
> > Changes since version 1:
> > - Rebased on: drm/rcar-du: Convert drm_atomic_helper_suspend/resume()
> >
> > Laurent, do you want to take this through your tree, or do you want me to
> > apply it to drm-misc-next?
> >
> > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 15 ---
> > drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 --
> > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 21 -
> > 3 files changed, 4 insertions(+), 34 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_drv.c index 7015974c247a..27bfccd5b136
> > 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > @@ -21,7 +21,9 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > +#include
>
> I see that I forgot to remove this include when rebasing.
>
> Will send a new version together with the other remaining patches.
Looks good to me, you can keep my Reviewed-by line. I'm fine with the patch
being merged through the drm-misc tree.
> > #include "rcar_du_drv.h"
> > #include "rcar_du_kms.h"
> >
> > @@ -363,19 +365,11 @@ MODULE_DEVICE_TABLE(of, rcar_du_of_table);
> >* DRM operations
> >*/
> >
> > -static void rcar_du_lastclose(struct drm_device *dev)
> > -{
> > - struct rcar_du_device *rcdu = dev->dev_private;
> > -
> > - drm_fbdev_cma_restore_mode(rcdu->fbdev);
> > -}
> > -
> > DEFINE_DRM_GEM_CMA_FOPS(rcar_du_fops);
> >
> > static struct drm_driver rcar_du_driver = {
> > .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME
> > | DRIVER_ATOMIC,
> > - .lastclose = rcar_du_lastclose,
> > .gem_free_object_unlocked = drm_gem_cma_free_object,
> > .gem_vm_ops = _gem_cma_vm_ops,
> > .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> > @@ -431,9 +425,6 @@ static int rcar_du_remove(struct platform_device
> > *pdev)
> >
> > drm_dev_unregister(ddev);
> >
> > - if (rcdu->fbdev)
> > - drm_fbdev_cma_fini(rcdu->fbdev);
> > -
> > drm_kms_helper_poll_fini(ddev);
> > drm_mode_config_cleanup(ddev);
> >
> > @@ -493,6 +484,8 @@ static int rcar_du_probe(struct platform_device *pdev)
> >
> > DRM_INFO("Device %s probed\n", dev_name(>dev));
> >
> > + drm_fbdev_generic_setup(ddev, 32);
> > +
> > return 0;
> >
> > error:
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> > b/drivers/gpu/drm/rcar-du/rcar_du_drv.h index 9f5563296c5a..a68da79b424e
> > 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> > @@ -20,7 +20,6 @@
> > struct clk;
> > struct device;
> > struct drm_device;
> > -struct drm_fbdev_cma;
> > struct rcar_du_device;
> >
> > #define RCAR_DU_FEATURE_CRTC_IRQ_CLOCKBIT(0) /* Per-CRTC IRQ and
> > clock
> > */
> > @@ -78,7 +77,6 @@ struct rcar_du_device {
> > void __iomem *mmio;
> >
> > struct drm_device *ddev;
> > - struct drm_fbdev_cma *fbdev;
> > struct rcar_du_crtc crtcs[RCAR_DU_MAX_CRTCS];
> > unsigned int num_crtcs;
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index 4ebd61ecbee1..6562871aa706
> > 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > @@ -255,13 +255,6 @@ rcar_du_fb_create(struct drm_device *dev, struct
> > drm_file *file_priv,
> > return drm_gem_fb_create(dev, file_priv, mode_cmd);
> > }
> >
> > -static void rcar_du_output_poll_changed(struct drm_device *dev)
> > -{
> > - struct rcar_du_device *rcdu = dev->dev_private;
> > -
> > - drm_fbdev_cma_hotplug_event(rcdu->fbdev);
> > -}
> > -
> > /*
Re: [PATCH v6 3/6] drm/dp_mst: Start tracking per-port VCPI allocations
On Wed, 2018-11-28 at 09:17 +0100, Daniel Vetter wrote: > On Tue, Nov 27, 2018 at 08:44:14PM -0500, Lyude Paul wrote: > > On Tue, 2018-11-27 at 20:44 +0100, Daniel Vetter wrote: > > > On Tue, Nov 27, 2018 at 12:48:59PM -0500, Lyude Paul wrote: > > > > On Mon, 2018-11-26 at 22:22 +0100, Daniel Vetter wrote: > > > > > On Mon, Nov 26, 2018 at 10:04:21PM +0100, Daniel Vetter wrote: > > > > > > On Thu, Nov 15, 2018 at 07:50:05PM -0500, Lyude Paul wrote: > > > > > > > There has been a TODO waiting for quite a long time in > > > > > > > drm_dp_mst_topology.c: > > > > > > > > > > > > > > /* We cannot rely on port->vcpi.num_slots to update > > > > > > >* topology_state->avail_slots as the port may not exist if > > > > > > > the parent > > > > > > >* branch device was unplugged. This should be fixed by > > > > > > > tracking > > > > > > >* per-port slot allocation in drm_dp_mst_topology_state > > > > > > > instead of > > > > > > >* depending on the caller to tell us how many slots to > > > > > > > release. > > > > > > >*/ > > > > > > > > > > > > > > That's not the only reason we should fix this: forcing the > > > > > > > driver to > > > > > > > track the VCPI allocations throughout a state's atomic check is > > > > > > > error prone, because it means that extra care has to be taken > > > > > > > with > > > > > > > the > > > > > > > order that drm_dp_atomic_find_vcpi_slots() and > > > > > > > drm_dp_atomic_release_vcpi_slots() are called in in order to > > > > > > > ensure > > > > > > > idempotency. Currently the only driver actually using these > > > > > > > helpers, > > > > > > > i915, doesn't even do this correctly: multiple ->best_encoder() > > > > > > > checks > > > > > > > with i915's current implementation would not be idempotent and > > > > > > > would > > > > > > > over-allocate VCPI slots, something I learned trying to > > > > > > > implement > > > > > > > fallback retraining in MST. > > > > > > > > > > > > > > So: simplify this whole mess, and teach > > > > > > > drm_dp_atomic_find_vcpi_slots() > > > > > > > and drm_dp_atomic_release_vcpi_slots() to track the VCPI > > > > > > > allocations > > > > > > > for > > > > > > > each port. This allows us to ensure idempotency without having > > > > > > > to > > > > > > > rely > > > > > > > on the driver as much. Additionally: the driver doesn't need to > > > > > > > do > > > > > > > any > > > > > > > kind of VCPI slot tracking anymore if it doesn't need it for > > > > > > > it's > > > > > > > own > > > > > > > internal state. > > > > > > > > > > > > > > Additionally; this adds a new drm_dp_mst_atomic_check() helper > > > > > > > which > > > > > > > must be used by atomic drivers to perform validity checks for > > > > > > > the > > > > > > > new > > > > > > > VCPI allocations incurred by a state. > > > > > > > > > > > > > > Also: update the documentation and make it more obvious that > > > > > > > these > > > > > > > /must/ be called by /all/ atomic drivers supporting MST. > > > > > > > > > > > > > > Changes since v6: > > > > > > > - Keep a kref to all of the ports we have allocations on. This > > > > > > > required > > > > > > >a good bit of changing to when we call > > > > > > > drm_dp_find_vcpi_slots(), > > > > > > >mainly that we need to ensure that we only redo VCPI > > > > > > > allocations > > > > > > > on > > > > > > >actual mode or CRTC changes, not crtc_state->active changes. > > > > > > >Additionally, we no longer take the registration of the DRM > > > > > > > connector > > > > > > >for each port into account because so long as we have a kref > > > > > > > to > > > > > > > the > > > > > > >port in the new or previous atomic state, the connector will > > > > > > > stay > > > > > > >registered. > > > > > > > > > > > > I write an entire pile of small nitpits (still included most of > > > > > > them > > > > > > below), until I realized this here wont work. Delaying the call to > > > > > > destroy > > > > > > the connector (well, unregister it really) wreaks the design we've > > > > > > come up > > > > > > with thus far, resulting in most of my comments here. > > > > > > > > > > > > Instead, all we need to do is delay the kfree(port) at the bottom > > > > > > of > > > > > > drm_dp_destroy_port(). The vcpi allocation structure _only_ needs > > > > > > the > > > > > > pointer value to stay valid, as a lookup key. It doesn't care at > > > > > > all > > > > > > about > > > > > > anything actually stored in there. So the only thing we need to > > > > > > delay > > > > > > is > > > > > > the kfree. I think the simplest way to achieve this is to add a > > > > > > 2nd > > > > > > kref > > > > > > (port->kfree_ref or something like that), with on reference held > > > > > > by > > > > > > the > > > > > > port itself (released in drm_dp_destroy_port), and the other one > > > > > > held > > > > > > as-needed by the vcpi allocation lists. > > > > > > > > > > > > I think if we go with this design instead of
[PATCH 0/1] drm/msm/a6xx: Add interconnect support
I heard at LPC that there was some confusion that the OPP bindings [1] were needed to land interconnect support. They aren't. There is a two step process for the SDM845 GPU. First we need a vote (any vote) because the default bus settings are way too bad for any reasonable performance. The next step after that would be to scale the bus request based on the frequency in order to save power. For that we *do* need a solution but that can be calmly discussed separately. This patch accommodates the first step. It cranks the bus to max for GPU activity and turns it off when the GPU goes to sleep. Hopefully this can alleviate the confusion and help interconnect land that much quicker. After that, we can calmly re-introduce the OPP discussion. This patch depends on interconnect support [2]. [1] https://patchwork.kernel.org/patch/10577303/ [2] https://patchwork.kernel.org/patch/10701287/ Jordan Crouse (1): drm/msm/a6xx: Add support for an interconnect path drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 20 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 9 + drivers/gpu/drm/msm/msm_gpu.h | 3 +++ 3 files changed, 32 insertions(+) -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/1] drm/msm/a6xx: Add support for an interconnect path
Try to get the interconnect path for the GPU and vote for the maximum
bandwidth to support all frequencies. This is needed for performance.
Later we will want to scale the bandwidth based on the frequency to
also optimize for power but that will require some device tree
infrastructure that does not yet exist.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 20
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 9 +
drivers/gpu/drm/msm/msm_gpu.h | 3 +++
3 files changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 546599a7ab05..b96ae2ab04bb 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -3,6 +3,7 @@
#include
#include
+#include
#include
#include "a6xx_gpu.h"
@@ -63,6 +64,9 @@ static bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
{
+ struct a6xx_gpu *a6xx_gpu = container_of(gmu, struct a6xx_gpu, gmu);
+ struct adreno_gpu *adreno_gpu = _gpu->base;
+ struct msm_gpu *gpu = _gpu->base;
int ret;
gmu_write(gmu, REG_A6XX_GMU_DCVS_ACK_OPTION, 0);
@@ -85,6 +89,12 @@ static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int
index)
dev_err(gmu->dev, "GMU set GPU frequency error: %d\n", ret);
gmu->freq = gmu->gpu_freqs[index];
+
+ /*
+* Eventually we will want to scale the path vote with the frequency but
+* for now leave it t at max so that the performance is nominal.
+*/
+ icc_set(gpu->icc_path, 0, 721600);
}
void a6xx_gmu_set_freq(struct msm_gpu *gpu, unsigned long freq)
@@ -680,6 +690,8 @@ int a6xx_gmu_reset(struct a6xx_gpu *a6xx_gpu)
int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
{
+ struct adreno_gpu *adreno_gpu = _gpu->base;
+ struct msm_gpu *gpu = _gpu->base;
struct a6xx_gmu *gmu = _gpu->gmu;
int status, ret;
@@ -695,6 +707,9 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
if (ret)
goto out;
+ /* Set the bus quota to a reasonable value for boot */
+ icc_set(gpu->icc_path, 0, 307200);
+
a6xx_gmu_irq_enable(gmu);
/* Check to see if we are doing a cold or warm boot */
@@ -735,6 +750,8 @@ bool a6xx_gmu_isidle(struct a6xx_gmu *gmu)
int a6xx_gmu_stop(struct a6xx_gpu *a6xx_gpu)
{
+ struct adreno_gpu *adreno_gpu = _gpu->base;
+ struct msm_gpu *gpu = _gpu->base;
struct a6xx_gmu *gmu = _gpu->gmu;
u32 val;
@@ -781,6 +798,9 @@ int a6xx_gmu_stop(struct a6xx_gpu *a6xx_gpu)
/* Tell RPMh to power off the GPU */
a6xx_rpmh_stop(gmu);
+ /* Remove the bus vote */
+ icc_set(gpu->icc_path, 0, 0);
+
clk_bulk_disable_unprepare(gmu->nr_clocks, gmu->clocks);
pm_runtime_put_sync(gmu->dev);
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 93d70f4a2154..9bab491912cf 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include "adreno_gpu.h"
#include "msm_gem.h"
#include "msm_mmu.h"
@@ -695,6 +696,11 @@ static int adreno_get_pwrlevels(struct device *dev,
DBG("fast_rate=%u, slow_rate=2700", gpu->fast_rate);
+ /* Check for an interconnect path for the bus */
+ gpu->icc_path = of_icc_get(dev, "port0");
+ if (IS_ERR(gpu->icc_path))
+ gpu->icc_path = NULL;
+
return 0;
}
@@ -733,10 +739,13 @@ int adreno_gpu_init(struct drm_device *drm, struct
platform_device *pdev,
void adreno_gpu_cleanup(struct adreno_gpu *adreno_gpu)
{
+ struct msm_gpu *gpu = _gpu->base;
unsigned int i;
for (i = 0; i < ARRAY_SIZE(adreno_gpu->info->fw); i++)
release_firmware(adreno_gpu->fw[i]);
+ icc_put(gpu->icc_path);
+
msm_gpu_cleanup(_gpu->base);
}
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index f82bac08..7b04d166 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -20,6 +20,7 @@
#include
#include
+#include
#include "msm_drv.h"
#include "msm_fence.h"
@@ -119,6 +120,8 @@ struct msm_gpu {
struct clk *ebi1_clk, *core_clk, *rbbmtimer_clk;
uint32_t fast_rate;
+ struct icc_path *icc_path;
+
/* Hang and Inactivity Detection:
*/
#define DRM_MSM_INACTIVE_PERIOD 66 /* in ms (roughly four frames) */
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-fixes
Hi Dave, Been a steady week, and no fixes apart from GVT, so quoting Zhenyu: "One to correct MOCS registers load on engine list, one for rpm lock warning fix, and another for use-after-free fix for partial ggtt list destroy. " Next week, Thursday is a national holiday in Finland, so I'll send the PR by Wed if there is something urgent surfacing, but doesn't look like that for now. Regards, Joonas *** drm-intel-fixes-2018-11-28: Just gvt-fixes-2018-11-26 The following changes since commit 2e6e902d185027f8e3cb8b7305238f7e35d6a436: Linux 4.20-rc4 (2018-11-25 14:19:31 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2018-11-28 for you to fetch changes up to 2455facbb700e3c3ca26b9255956d6ed45cb6217: Merge tag 'gvt-fixes-2018-11-26' of https://github.com/intel/gvt-linux into drm-intel-fixes (2018-11-26 11:19:48 +0200) Just gvt-fixes-2018-11-26 Chris Wilson (1): drm/i915/gvt: Avoid use-after-free iterating the gtt list Hang Yuan (1): drm/i915/gvt: ensure gpu is powered before do i915_gem_gtt_insert Joonas Lahtinen (1): Merge tag 'gvt-fixes-2018-11-26' of https://github.com/intel/gvt-linux into drm-intel-fixes Xinyun Liu (1): drm/i915/gvt: not to touch undefined MOCS registers drivers/gpu/drm/i915/gvt/aperture_gm.c | 2 ++ drivers/gpu/drm/i915/gvt/gtt.c | 7 --- drivers/gpu/drm/i915/gvt/mmio_context.c | 2 ++ 3 files changed, 8 insertions(+), 3 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] drm/virtio: fence cleanups
Hey Gerd, I was looking at making these changes too, thanks for submitting this. This series has been: Reviewed-by: Robert Foss Rob. On 2018-11-28 16:10, Gerd Hoffmann wrote: Gerd Hoffmann (2): drm/virtio: fence: pass plain pointer drm/virtio: virtio_gpu_cmd_resource_create_3d: drop unused fence arg drivers/gpu/drm/virtio/virtgpu_drv.h | 15 +++ drivers/gpu/drm/virtio/virtgpu_fence.c | 10 +- drivers/gpu/drm/virtio/virtgpu_ioctl.c | 10 +- drivers/gpu/drm/virtio/virtgpu_plane.c | 2 +- drivers/gpu/drm/virtio/virtgpu_vq.c| 23 +++ 5 files changed, 29 insertions(+), 31 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: change i915_sw_fence license to MIT
Quoting Jonathan Gray (2018-11-23 16:53:46) > On Fri, Nov 23, 2018 at 03:01:06PM +0200, Joonas Lahtinen wrote: > > Quoting Jonathan Gray (2018-11-23 14:28:37) > > > On Fri, Nov 23, 2018 at 12:14:00PM +0200, Joonas Lahtinen wrote: > > > > Quoting Jonathan Gray (2018-11-20 00:31:22) > > > > > On Mon, Nov 19, 2018 at 10:09:33AM -0800, Rodrigo Vivi wrote: > > > > > > On Sun, Nov 18, 2018 at 08:44:30PM +1100, Jonathan Gray wrote: > > > > > > > On Wed, Oct 31, 2018 at 08:43:03AM +, Chris Wilson wrote: > > > > > > > > Quoting Jonathan Gray (2018-10-31 00:56:12) > > > > > > > > > Chris Wilson said Intel is willing to change the license of > > > > > > > > > these files > > > > > > > > > to MIT. > > > > > > > > > > > > > > > > > > Signed-off-by: Jonathan Gray > > > > > > > > Reviewed-by: Chris Wilson > > > > > > > > -Chris > > > > > > > > > > > > > > Still looking to get this merged/reviewed by one of the i915 > > > > > > > maintainers. > > > > > > > > > > > > I believe this patch should have a better commit message. > > > > > > > > > > It isn't clear what should be changed, what do you have in mind? > > > > > > > > It would make sense to state why you want to change the license to begin > > > > with. > > > > > > > > Anyway, I'll double check with our legal team and reply shortly. > > > > > > > > Regards, Joonas > > > > > > I am porting the i915 code to OpenBSD again. These files are the last > > > remaining GPL parts in my development tree. If they can't have the same > > > license as the rest of the i915 code I will have to reimplement them. > > > > Yes, that's a reasonable reason, which should be recorded in the commit > > message. It's maybe also worthy mentioning that the files are only > > touched by tree-wide changes in addition to Chris, so he's the sole > > author of the file. Documenting these two saves somebody a lot of > > digging when they come across the commit. > > > > Pretty much everybody seems to be on their Thanksgiving holidays, so > > I'll expect a reply early next week from our legal. > > > > Regards, Joonas > > Thanks, I can send a v2 with that context if you like assuming they agree. Hi, Please do send a v2, we got a permission to change the license. Regards, Joonas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/pl111: add of_node_put()
Yangtao Li writes: > of_find_node_by_path() acquires a reference to the node > returned by it and that reference needs to be dropped by its caller. > bl_idle_init() doesn't do that, so fix it. The "bl_idle_init" appeared to be copy-and-paste from some other commit message, so I droppped that bit and pushed. Thanks! signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/edid: Add display_info.rgb_quant_range_selectable
Ville Syrjala writes: > From: Ville Syrjälä > > Move the CEA-861 QS bit handling entirely into the edid code. No > need to bother the drivers with this. > > Cc: Alex Deucher > Cc: "Christian König" > Cc: "David (ChunMing) Zhou" > Cc: amd-...@lists.freedesktop.org > Cc: Eric Anholt (supporter:DRM DRIVERS FOR VC4) > Signed-off-by: Ville Syrjälä For vc4, Acked-by: Eric Anholt Looks like a nice cleanup! signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/3] drm/connector: Add generic underscan properties
Brian Starkey writes: > Hi Boris, > > Just because I happened to read the docs in here, one typo below: > > On Thu, Nov 22, 2018 at 12:23:29PM +0100, Boris Brezillon wrote: >>diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c >>index c555e17ab8d7..170317248da6 100644 >>--- a/drivers/gpu/drm/drm_connector.c >>+++ b/drivers/gpu/drm/drm_connector.c >>@@ -971,6 +971,38 @@ DRM_ENUM_NAME_FN(drm_get_content_protection_name, >>drm_cp_enum_list) >> * can also expose this property to external outputs, in which case they >> * must support "None", which should be the default (since external screens >> * have a built-in scaler). >>+ * >>+ * Connectors for non-analog outputs may also have standardized underscan >>+ * properties (drivers can set this up by calling >>+ * drm_connector_attach_content_protection_property() on initialization): > > Should be drm_connector_attach_underscan_properties() Other than this typo, this series is: Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/9] drm/rcar-du: Use drm_fbdev_generic_setup()
Den 25.10.2018 22.13, skrev Noralf Trønnes:
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by the emulation code. Additionally fbdev unregister happens
automatically on drm_dev_unregister().
The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
driver. This is done to highlight the fact that fbdev emulation is an
internal client that makes use of the driver, it is not part of the
driver as such. If fbdev setup fails, an error is printed, but the driver
succeeds probing.
drm_fbdev_generic_setup() handles mode_config.num_connector being zero.
In that case it retries fbdev setup on the next .output_poll_changed.
Cc: Laurent Pinchart
Signed-off-by: Noralf Trønnes
Acked-by: Sam Ravnborg
Reviewed-by: Laurent Pinchart
---
Changes since version 1:
- Rebased on: drm/rcar-du: Convert drm_atomic_helper_suspend/resume()
Laurent, do you want to take this through your tree, or do you want me to
apply it to drm-misc-next?
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 15 ---
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 --
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 21 -
3 files changed, 4 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 7015974c247a..27bfccd5b136 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -21,7 +21,9 @@
#include
#include
#include
+#include
#include
+#include
I see that I forgot to remove this include when rebasing.
Will send a new version together with the other remaining patches.
Noralf.
#include "rcar_du_drv.h"
#include "rcar_du_kms.h"
@@ -363,19 +365,11 @@ MODULE_DEVICE_TABLE(of, rcar_du_of_table);
* DRM operations
*/
-static void rcar_du_lastclose(struct drm_device *dev)
-{
- struct rcar_du_device *rcdu = dev->dev_private;
-
- drm_fbdev_cma_restore_mode(rcdu->fbdev);
-}
-
DEFINE_DRM_GEM_CMA_FOPS(rcar_du_fops);
static struct drm_driver rcar_du_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME
| DRIVER_ATOMIC,
- .lastclose = rcar_du_lastclose,
.gem_free_object_unlocked = drm_gem_cma_free_object,
.gem_vm_ops = _gem_cma_vm_ops,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
@@ -431,9 +425,6 @@ static int rcar_du_remove(struct platform_device *pdev)
drm_dev_unregister(ddev);
- if (rcdu->fbdev)
- drm_fbdev_cma_fini(rcdu->fbdev);
-
drm_kms_helper_poll_fini(ddev);
drm_mode_config_cleanup(ddev);
@@ -493,6 +484,8 @@ static int rcar_du_probe(struct platform_device *pdev)
DRM_INFO("Device %s probed\n", dev_name(>dev));
+ drm_fbdev_generic_setup(ddev, 32);
+
return 0;
error:
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index 9f5563296c5a..a68da79b424e 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -20,7 +20,6 @@
struct clk;
struct device;
struct drm_device;
-struct drm_fbdev_cma;
struct rcar_du_device;
#define RCAR_DU_FEATURE_CRTC_IRQ_CLOCK BIT(0) /* Per-CRTC IRQ and clock */
@@ -78,7 +77,6 @@ struct rcar_du_device {
void __iomem *mmio;
struct drm_device *ddev;
- struct drm_fbdev_cma *fbdev;
struct rcar_du_crtc crtcs[RCAR_DU_MAX_CRTCS];
unsigned int num_crtcs;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 4ebd61ecbee1..6562871aa706 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -255,13 +255,6 @@ rcar_du_fb_create(struct drm_device *dev, struct drm_file
*file_priv,
return drm_gem_fb_create(dev, file_priv, mode_cmd);
}
-static void rcar_du_output_poll_changed(struct drm_device *dev)
-{
- struct rcar_du_device *rcdu = dev->dev_private;
-
- drm_fbdev_cma_hotplug_event(rcdu->fbdev);
-}
-
/*
-
* Atomic Check and Update
*/
@@ -308,7 +301,6 @@ static const struct drm_mode_config_helper_funcs
rcar_du_mode_config_helper = {
static const struct drm_mode_config_funcs rcar_du_mode_config_funcs = {
.fb_create = rcar_du_fb_create,
- .output_poll_changed = rcar_du_output_poll_changed,
.atomic_check = rcar_du_atomic_check,
.atomic_commit = drm_atomic_helper_commit,
};
@@ -543,7 +535,6 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
struct drm_device *dev = rcdu->ddev;
struct drm_encoder *encoder;
- struct
Re: [PATCH 3/3] drm: Add DRM_MODESET_LOCK_BEGIN/END helpers
On Wed, Nov 28, 2018 at 10:01:07AM +0100, Daniel Vetter wrote:
> On Tue, Nov 27, 2018 at 05:46:40PM -0500, Sean Paul wrote:
> > From: Sean Paul
> >
> > This patch adds a couple of helpers to remove the boilerplate involved
> > in grabbing all of the modeset locks.
> >
> > I've also converted the obvious cases in drm core to use the helpers.
> >
> > The only remaining instance of drm_modeset_lock_all_ctx() is in
> > drm_framebuffer. It's complicated by the state clear that occurs on
> > deadlock. ATM, there's no way to inject code in the deadlock path with
> > the helpers, so it's unfit for conversion.
> >
> > Cc: Daniel Vetter
> > Signed-off-by: Sean Paul
> > ---
> > drivers/gpu/drm/drm_atomic_helper.c | 52 ++-
> > drivers/gpu/drm/drm_color_mgmt.c| 14 ++--
> > drivers/gpu/drm/drm_crtc.c | 15 ++--
> > drivers/gpu/drm/drm_plane.c | 16 ++---
> > include/drm/drm_modeset_lock.h | 54 +
> > 5 files changed, 72 insertions(+), 79 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 15a75b9f185fa..997735eea9abc 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -3124,23 +3124,13 @@ void drm_atomic_helper_shutdown(struct drm_device
> > *dev)
> > struct drm_modeset_acquire_ctx ctx;
> > int ret;
> >
> > - drm_modeset_acquire_init(, 0);
> > - while (1) {
> > - ret = drm_modeset_lock_all_ctx(dev, );
> > - if (!ret)
> > - ret = __drm_atomic_helper_disable_all(dev, , true);
> > -
> > - if (ret != -EDEADLK)
> > - break;
> > -
> > - drm_modeset_backoff();
> > - }
> > + DRM_MODESET_LOCK_ALL_BEGIN(dev, ret, ctx, 0);
> >
> > + ret = __drm_atomic_helper_disable_all(dev, , true);
> > if (ret)
> > DRM_ERROR("Disabling all crtc's during unload failed with
> > %i\n", ret);
> >
> > - drm_modeset_drop_locks();
> > - drm_modeset_acquire_fini();
> > + DRM_MODESET_LOCK_ALL_END(ret, ctx);
> > }
> > EXPORT_SYMBOL(drm_atomic_helper_shutdown);
> >
> > @@ -3175,14 +3165,7 @@ struct drm_atomic_state
> > *drm_atomic_helper_suspend(struct drm_device *dev)
> > struct drm_atomic_state *state;
> > int err;
> >
> > - drm_modeset_acquire_init(, 0);
> > -
> > -retry:
> > - err = drm_modeset_lock_all_ctx(dev, );
> > - if (err < 0) {
> > - state = ERR_PTR(err);
> > - goto unlock;
> > - }
> > + DRM_MODESET_LOCK_ALL_BEGIN(dev, err, ctx, 0);
> >
> > state = drm_atomic_helper_duplicate_state(dev, );
> > if (IS_ERR(state))
> > @@ -3191,18 +3174,14 @@ struct drm_atomic_state
> > *drm_atomic_helper_suspend(struct drm_device *dev)
> > err = drm_atomic_helper_disable_all(dev, );
> > if (err < 0) {
> > drm_atomic_state_put(state);
> > - state = ERR_PTR(err);
> > goto unlock;
> > }
> >
> > unlock:
> > - if (PTR_ERR(state) == -EDEADLK) {
> > - drm_modeset_backoff();
> > - goto retry;
> > - }
> > + DRM_MODESET_LOCK_ALL_END(err, ctx);
> > + if (err)
> > + return ERR_PTR(err);
> >
> > - drm_modeset_drop_locks();
> > - drm_modeset_acquire_fini();
> > return state;
> > }
> > EXPORT_SYMBOL(drm_atomic_helper_suspend);
> > @@ -3272,23 +3251,12 @@ int drm_atomic_helper_resume(struct drm_device *dev,
> >
> > drm_mode_config_reset(dev);
> >
> > - drm_modeset_acquire_init(, 0);
> > - while (1) {
> > - err = drm_modeset_lock_all_ctx(dev, );
> > - if (err)
> > - goto out;
> > + DRM_MODESET_LOCK_ALL_BEGIN(dev, err, ctx, 0);
> >
> > - err = drm_atomic_helper_commit_duplicated_state(state, );
> > -out:
> > - if (err != -EDEADLK)
> > - break;
> > -
> > - drm_modeset_backoff();
> > - }
> > + err = drm_atomic_helper_commit_duplicated_state(state, );
> >
> > state->acquire_ctx = NULL;
> > - drm_modeset_drop_locks();
> > - drm_modeset_acquire_fini();
> > + DRM_MODESET_LOCK_ALL_END(err, ctx);
> > drm_atomic_state_put(state);
> >
> > return err;
> > diff --git a/drivers/gpu/drm/drm_color_mgmt.c
> > b/drivers/gpu/drm/drm_color_mgmt.c
> > index 581cc37882230..9c6827171d795 100644
> > --- a/drivers/gpu/drm/drm_color_mgmt.c
> > +++ b/drivers/gpu/drm/drm_color_mgmt.c
> > @@ -255,11 +255,7 @@ int drm_mode_gamma_set_ioctl(struct drm_device *dev,
> > if (crtc_lut->gamma_size != crtc->gamma_size)
> > return -EINVAL;
> >
> > - drm_modeset_acquire_init(, 0);
> > -retry:
> > - ret = drm_modeset_lock_all_ctx(dev, );
> > - if (ret)
> > - goto out;
> > + DRM_MODESET_LOCK_ALL_BEGIN(dev, ret, ctx, 0);
> >
> > size = crtc_lut->gamma_size * (sizeof(uint16_t));
> > r_base = crtc->gamma_store;
> > @@ -284,13 +280,7 @@ int
[PATCH 1/2] drm/tegra: hub: Enable all required clocks
From: Thierry Reding
The display architecture on Tegra186 and Tegra194 requires that there be
some valid clock on all domains before accessing any display register. A
further requirement is that in addition to the host1x, hub, disp and dsc
clocks, all the head clocks (pclk0-2 on Tegra186 or pclk0-3 on Tegra194)
must also be enabled.
Implement this logic within the display hub driver to ensure the clocks
are always enabled at the right time.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/hub.c | 47 +++--
drivers/gpu/drm/tegra/hub.h | 3 +++
2 files changed, 48 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tegra/hub.c b/drivers/gpu/drm/tegra/hub.c
index 6112d9042979..7e7742877b90 100644
--- a/drivers/gpu/drm/tegra/hub.c
+++ b/drivers/gpu/drm/tegra/hub.c
@@ -742,7 +742,9 @@ static const struct host1x_client_ops tegra_display_hub_ops
= {
static int tegra_display_hub_probe(struct platform_device *pdev)
{
+ struct device_node *child = NULL;
struct tegra_display_hub *hub;
+ struct clk *clk;
unsigned int i;
int err;
@@ -801,6 +803,33 @@ static int tegra_display_hub_probe(struct platform_device
*pdev)
return err;
}
+ hub->num_heads = of_get_child_count(pdev->dev.of_node);
+
+ hub->clk_heads = devm_kcalloc(>dev, hub->num_heads, sizeof(clk),
+ GFP_KERNEL);
+ if (!hub->clk_heads)
+ return -ENOMEM;
+
+ for (i = 0; i < hub->num_heads; i++) {
+ child = of_get_next_child(pdev->dev.of_node, child);
+ if (!child) {
+ dev_err(>dev, "failed to find node for head %u\n",
+ i);
+ return -ENODEV;
+ }
+
+ clk = devm_get_clk_from_child(>dev, child, "dc");
+ if (IS_ERR(clk)) {
+ dev_err(>dev, "failed to get clock for head %u\n",
+ i);
+ return PTR_ERR(clk);
+ }
+
+ hub->clk_heads[i] = clk;
+ }
+
+ of_node_put(child);
+
/* XXX: enable clock across reset? */
err = reset_control_assert(hub->rst);
if (err < 0)
@@ -840,12 +869,16 @@ static int tegra_display_hub_remove(struct
platform_device *pdev)
static int __maybe_unused tegra_display_hub_suspend(struct device *dev)
{
struct tegra_display_hub *hub = dev_get_drvdata(dev);
+ unsigned int i;
int err;
err = reset_control_assert(hub->rst);
if (err < 0)
return err;
+ for (i = 0; i < hub->num_heads; i++)
+ clk_disable_unprepare(hub->clk_heads[i]);
+
clk_disable_unprepare(hub->clk_hub);
clk_disable_unprepare(hub->clk_dsc);
clk_disable_unprepare(hub->clk_disp);
@@ -856,6 +889,7 @@ static int __maybe_unused tegra_display_hub_suspend(struct
device *dev)
static int __maybe_unused tegra_display_hub_resume(struct device *dev)
{
struct tegra_display_hub *hub = dev_get_drvdata(dev);
+ unsigned int i;
int err;
err = clk_prepare_enable(hub->clk_disp);
@@ -870,13 +904,22 @@ static int __maybe_unused tegra_display_hub_resume(struct
device *dev)
if (err < 0)
goto disable_dsc;
+ for (i = 0; i < hub->num_heads; i++) {
+ err = clk_prepare_enable(hub->clk_heads[i]);
+ if (err < 0)
+ goto disable_heads;
+ }
+
err = reset_control_deassert(hub->rst);
if (err < 0)
- goto disable_hub;
+ goto disable_heads;
return 0;
-disable_hub:
+disable_heads:
+ while (i--)
+ clk_disable_unprepare(hub->clk_heads[i]);
+
clk_disable_unprepare(hub->clk_hub);
disable_dsc:
clk_disable_unprepare(hub->clk_dsc);
diff --git a/drivers/gpu/drm/tegra/hub.h b/drivers/gpu/drm/tegra/hub.h
index 6696a85fc1f2..479087c0705a 100644
--- a/drivers/gpu/drm/tegra/hub.h
+++ b/drivers/gpu/drm/tegra/hub.h
@@ -49,6 +49,9 @@ struct tegra_display_hub {
struct clk *clk_hub;
struct reset_control *rst;
+ unsigned int num_heads;
+ struct clk **clk_heads;
+
const struct tegra_display_hub_soc *soc;
struct tegra_windowgroup *wgrps;
};
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/tegra: dc: Don't clean up unused display controller
From: Thierry Reding
Display controllers that don't own any windows and which therefore
aren't currently being assigned a primary plane are not registered
as a CRTC with the DRM framework. They request neither a syncpoint
nor an interrupt because they don't use them, so avoid cleaning up
those resources.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dc.c | 38 ++
1 file changed, 22 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index f80e82e16475..607a6ea17ecc 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -1978,6 +1978,23 @@ static irqreturn_t tegra_dc_irq(int irq, void *data)
return IRQ_HANDLED;
}
+static bool tegra_dc_has_window_groups(struct tegra_dc *dc)
+{
+ unsigned int i;
+
+ if (!dc->soc->wgrps)
+ return true;
+
+ for (i = 0; i < dc->soc->num_wgrps; i++) {
+ const struct tegra_windowgroup_soc *wgrp = >soc->wgrps[i];
+
+ if (wgrp->dc == dc->pipe && wgrp->num_windows > 0)
+ return true;
+ }
+
+ return false;
+}
+
static int tegra_dc_init(struct host1x_client *client)
{
struct drm_device *drm = dev_get_drvdata(client->parent);
@@ -1993,22 +2010,8 @@ static int tegra_dc_init(struct host1x_client *client)
* assign a primary plane to them, which in turn will cause KMS to
* crash.
*/
- if (dc->soc->wgrps) {
- bool has_wgrps = false;
- unsigned int i;
-
- for (i = 0; i < dc->soc->num_wgrps; i++) {
- const struct tegra_windowgroup_soc *wgrp =
>soc->wgrps[i];
-
- if (wgrp->dc == dc->pipe && wgrp->num_windows > 0) {
- has_wgrps = true;
- break;
- }
- }
-
- if (!has_wgrps)
- return 0;
- }
+ if (!tegra_dc_has_window_groups(dc))
+ return 0;
dc->syncpt = host1x_syncpt_request(client, flags);
if (!dc->syncpt)
@@ -2094,6 +2097,9 @@ static int tegra_dc_exit(struct host1x_client *client)
struct tegra_dc *dc = host1x_client_to_dc(client);
int err;
+ if (!tegra_dc_has_window_groups(dc))
+ return 0;
+
devm_free_irq(dc->dev, dc->irq, dc);
err = tegra_dc_rgb_exit(dc);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v4 2/3] drm: Add DP colorspace property
Regards
Shashank
On 11/27/2018 10:10 PM, Uma Shankar wrote:
This patch adds a DP colorspace property, enabling
userspace to switch to various supported colorspaces.
This will help enable BT2020 along with other colorspaces.
v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
colorspaces. Also, added a default option for colorspace.
v3: Split the changes to have separate colorspace property for
DP and HDMI.
v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_connector.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 57d36e4..30e2e6f 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -850,6 +850,29 @@ int drm_display_info_set_bus_formats(struct
drm_display_info *info,
{ COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
};
+static const struct drm_prop_enum_list dp_colorspace[] = {
+ /* For Default case, driver will set the colorspace */
+ { COLORIMETRY_DEFAULT, "Default" },
+ /* Standard Definition Colorimetry based on CEA 861 */
+ { COLORIMETRY_ITU_601, "ITU_601" },
+ { COLORIMETRY_ITU_709, "ITU_709" },
+ /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+ { COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
+ /* High Definition Colorimetry based on IEC 61966-2-4 */
+ { COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
+ /* Colorimetry based on IEC 61966-2-5 */
+ { COLORIMETRY_OPRGB, "opRGB" },
+ /* DP MSA Colorimetry */
+ { DP_COLORIMETRY_Y_CBCR_ITU_601, "YCBCR_ITU_601" },
+ { DP_COLORIMETRY_Y_CBCR_ITU_709, "YCBCR_ITU_709" },
+ { DP_COLORIMETRY_SRGB, "sRGB" },
+ { DP_COLORIMETRY_RGB_WIDE_GAMUT, "RGB Wide Gamut" },
+ { DP_COLORIMETRY_SCRGB, "scRGB" },
+ { DP_COLORIMETRY_DCI_P3, "DCI-P3" },
+ { DP_COLORIMETRY_CUSTOM_COLOR_PROFILE, "Custom Profile" },
+};
+
+
The same comments as previous patch, possibility of the platform specfic
enum values being passed from the core driver. and DRM layer blindly
registers it.
- Shashank
/**
* DOC: standard connector properties
*
@@ -1454,6 +1477,14 @@ int drm_mode_create_colorspace_property(struct
drm_connector *connector)
ARRAY_SIZE(hdmi_colorspace));
if (!prop)
return -ENOMEM;
+ } else if (connector->connector_type == DRM_MODE_CONNECTOR_eDP ||
+ connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) {
+
+ prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM,
+ "Colorspace", dp_colorspace,
+ ARRAY_SIZE(dp_colorspace));
+ if (!prop)
+ return -ENOMEM;
}
connector->colorspace_property = prop;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v4 1/3] drm: Add HDMI colorspace property
Regards
Shashank
On 11/27/2018 10:10 PM, Uma Shankar wrote:
This patch adds a HDMI colorspace property, enabling
userspace to switch to various supported colorspaces.
This will help enable BT2020 along with other colorspaces.
v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
colorspaces. Also, added a default option for colorspace.
v3: Removed Adobe references from enum definitions as per
Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
Default to an unset state where driver will assign the colorspace
is not chosen by user, suggested by Ville and Maarten. Addressed
other misc review comments from Maarten. Split the changes to
have separate colorspace property for DP and HDMI.
v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
drivers/gpu/drm/drm_connector.c | 61 +++
include/drm/drm_connector.h | 14 +
include/uapi/drm/drm_mode.h | 33 +
4 files changed, 112 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 86ac339..9df7520 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -729,6 +729,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
return -EINVAL;
}
state->content_protection = val;
+ } else if (property == connector->colorspace_property) {
+ state->colorspace = val;
} else if (property == config->writeback_fb_id_property) {
struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL,
val);
int ret = drm_atomic_set_writeback_fb_for_connector(state, fb);
@@ -797,6 +799,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
*val = state->picture_aspect_ratio;
} else if (property == config->content_type_property) {
*val = state->content_type;
+ } else if (property == connector->colorspace_property) {
+ *val = state->colorspace;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
} else if (property == connector->content_protection_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index fa9baac..57d36e4 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -826,6 +826,30 @@ int drm_display_info_set_bus_formats(struct
drm_display_info *info,
};
DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
+static const struct drm_prop_enum_list hdmi_colorspace[] = {
+ /* For Default case, driver will set the colorspace */
+ { COLORIMETRY_DEFAULT, "Default" },
+ /* Standard Definition Colorimetry based on CEA 861 */
+ { COLORIMETRY_ITU_601, "ITU_601" },
+ { COLORIMETRY_ITU_709, "ITU_709" },
+ /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+ { COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
+ /* High Definition Colorimetry based on IEC 61966-2-4 */
+ { COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
+ /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
+ { COLORIMETRY_S_YCC_601, "S_YCC_601" },
+ /* Colorimetry based on IEC 61966-2-5 [33] */
+ { COLORIMETRY_OPYCC_601, "opYCC_601" },
+ /* Colorimetry based on IEC 61966-2-5 */
+ { COLORIMETRY_OPRGB, "opRGB" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
This still doesn't help us with the platform specific colorspace
support, like:
Even for HDMI, Until GEN10, we don't want to add BT2020 colorspace enum
values for Intel driver, which would be difficult to know for a user.
How about we modify the design a drm helper bit like this:
1. Keep the absolute_colorimetry_list as the full range of colorimetry
enum values supported by DRM for HDMI display
2. Make the DRM helper accept a series/subset of these enum values,
which will be passed from the core driver (like I915), and the DRM
functions creates property with these passed values.
3. Call the DRM helper function from functions core driver function
(like intel_ddi_init()) from where we already know:
- Which display to select enum values from (HDMI/DP)
- Which enum values to pick based on current platform (Like if GEN
< GEN9, add dont add REC_2020 etc)
- Shashank
+};
+
/**
* DOC:
Re: [PATCH] drm/fbdev: Make skip_vt_switch the default
Reviewed-by: Samuel Li On 2018-11-28 3:20 a.m., Daniel Vetter wrote: > On Wed, Nov 28, 2018 at 08:17:04AM +0100, Maarten Lankhorst wrote: >> Op 27-11-18 om 18:34 schreef Daniel Vetter: >>> KMS drivers really should all be able to restore their display state >>> on resume without fbcon helping out. So make this the default. >>> >>> Since I'm not entirely foolish, make it only a default, which drivers >>> can still override. That way when the inevitable regression report >>> happens I can fix things up with a one-liner plus FIXME comment that >>> someone should fix up the suspend/resume code in that driver. >>> >>> But at least all new drivers won't be broken by accident as soon as >>> you turn off fbcon because "suspend/resume worked when I tested it". >>> >>> v2: Keep this for radeon because of >>> >>> commit 18c437caa5b18a235dd65cec224eab54bebcee65 >>> Author: Alex Deucher >>> Date: Tue Nov 14 17:19:29 2017 -0500 >>> >>> Revert "drm/radeon: dont switch vt on suspend" >>> >>> Thanks to Michel Dänzer for pointing this one out. >> >> Maybe just reload the gamma lut on resume for radeon, instead of relying on >> fbcon? > > It also caused random sound issues and other fun. Also, afaiui radeon does > load the lut. Except because of timing or bad luck, it doesn't work > reliably, and the vt switch doing it a 2nd time helps out. > -Daniel > >> Otherwise patch looks sane, would be nice if radeon was fixed instead of >> worked around. >> >> Reviewed-by: Maarten Lankhorst ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] fbdev: uvesafb: fix spelling mistake "memoery" -> "memory"
From: Colin Ian King There is a spelling mistake in the module parameter description, fix it. Signed-off-by: Colin Ian King --- drivers/video/fbdev/uvesafb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/uvesafb.c b/drivers/video/fbdev/uvesafb.c index 440a6636d8f0..34dc8e53a1e9 100644 --- a/drivers/video/fbdev/uvesafb.c +++ b/drivers/video/fbdev/uvesafb.c @@ -1979,7 +1979,7 @@ MODULE_PARM_DESC(noedid, module_param(vram_remap, uint, 0); MODULE_PARM_DESC(vram_remap, "Set amount of video memory to be used [MiB]"); module_param(vram_total, uint, 0); -MODULE_PARM_DESC(vram_total, "Set total amount of video memoery [MiB]"); +MODULE_PARM_DESC(vram_total, "Set total amount of video memory [MiB]"); module_param(maxclk, ushort, 0); MODULE_PARM_DESC(maxclk, "Maximum pixelclock [MHz], overrides EDID data"); module_param(maxhf, ushort, 0); -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108890] VLC Segmentation fault (core dumped)
https://bugs.freedesktop.org/show_bug.cgi?id=108890
Bug ID: 108890
Summary: VLC Segmentation fault (core dumped)
Product: DRI
Version: unspecified
Hardware: Other
OS: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: DRM/AMDgpu-pro
Assignee: dri-devel@lists.freedesktop.org
Reporter: snur...@gmail.com
Created attachment 142649
--> https://bugs.freedesktop.org/attachment.cgi?id=142649=edit
Pertinent system logs
Upgraded Ubuntu 16.04 to 18.04.1. VLC worked correctly prior to the upgrade;
no hardware changes were made.
VLC plays music files correctly.
Any video files cause "Segmentation fault (core dumped)"
Happens if 2x-clicking a video file, or if dropping a video file onto a running
VLC window, or if selecting a video from Media -> Open File.
Specific file format does not matter - I have confirmed with mp4, mkv, webm,
avi, mov
Turning hardware acceleration off does not correct the issue.
Full output:
VLC media player 3.0.4 Vetinari (revision 3.0.4-0-gf615db6332)
[557badb0d570] main libvlc: Running vlc with the default interface. Use
'cvlc' to use vlc without interface.
[557badb114e0] main playlist: playlist is empty
Gtk-Message: 10:02:40.800: GtkDialog mapped without a transient parent. This is
discouraged.
Segmentation fault (core dumped)
Videos play correctly with xine.
Possibly related symptoms:
Videos viewed on Chrome exhibit tearing (with hw accel on or off) but not in
Firefox.
After the initial upgrade, the system would freeze at every boot - screen would
flicker and attempt to launch the GUI, but would drop back to the terminal.
Safe Mode from the recovery console would flicker the screen and return to the
recovery console. ***This behavior was the same when booting to a live Ubuntu
18.04.1 disc.*** Ultimately required amdgpu-uninstall from recovery console
CLI to get to a login/desktop.
Currently running the latest AMDGPU driver, and have removed and re-installed
it multiple times. ("amdgpu-pro-18.40-676022-ubuntu-18.04.tar.xz")
No other graphics issues are apparent with the system; Geeks3d GPUtest runs
very smoothly and gives very impressive results.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
