Re: [PATCH 5/5] [RFC]drm: add syncobj timeline support v3
On 2018年09月03日 19:19, Christian König wrote:
Am 03.09.2018 um 12:07 schrieb Chunming Zhou:
在 2018/9/3 16:50, Christian König 写道:
Am 03.09.2018 um 06:13 schrieb Chunming Zhou:
在 2018/8/30 19:32, Christian König 写道:
[SNIP]
+
+struct drm_syncobj_wait_pt {
+ struct drm_syncobj_stub_fence base;
+ u64 value;
+ struct rb_node node;
+};
+struct drm_syncobj_signal_pt {
+ struct drm_syncobj_stub_fence base;
+ struct dma_fence *signal_fence;
+ struct dma_fence *pre_pt_base;
+ struct dma_fence_cb signal_cb;
+ struct dma_fence_cb pre_pt_cb;
+ struct drm_syncobj *syncobj;
+ u64 value;
+ struct list_head list;
+};
What are those two structures good for
They are used to record wait ops points and signal ops points.
For timeline, they are connected by timeline value, works like:
a. signal pt increase timeline value to signal_pt value
when signal_pt is signaled. signal_pt is depending on previous
pt fence and itself signal fence from signal ops.
b. wait pt tree checks if timeline value over itself value.
For normal, works like:
a. signal pt increase 1 for syncobj_timeline->signal_point
every time when signal ops is performed.
b. when wait ops is comming, wait pt will fetch above last
signal pt value as its wait point. wait pt will be only
signaled by equal point value signal_pt.
and why is the stub fence their base?
Good question, I tried to kzalloc for them as well when I debug
them, I encountered a problem:
I lookup/find wait_pt or signal_pt successfully, but when I
tried to use them, they are freed sometimes, and results in
NULL point.
and generally, when lookup them, we often need their stub fence
as well, and in the meantime, their lifecycle are same.
Above reason, I make stub fence as their base.
That sounds like you only did this because you messed up the
lifecycle.
Additional to that I don't think you correctly considered the
lifecycle of the waits and the sync object itself. E.g. blocking
in drm_syncobj_timeline_fini() until all waits are done is not a
good idea.
What you should do instead is to create a fence_array object
with all the fence we need to wait for when a wait point is
requested.
Yeah, this is our initial discussion result, but when I tried to
do that, I found that cannot meet the advance signal requirement:
a. We need to consider the wait and signal pt value are not
one-to-one match, it's difficult to find dependent point, at
least, there is some overhead.
As far as I can see that is independent of using a fence array
here. See you can either use a ring buffer or an rb-tree, but when
you want to wait for a specific point we need to condense the not
yet signaled fences into an array.
again, need to find the range of where the specific point in, we
should close to timeline semantics, I also refered the sw_sync.c
timeline, usally wait_pt is signalled by timeline point. And I
agree we can implement it with several methods, but I don't think
there are basical differences.
The problem is that with your current approach you need the sync_obj
alive for the synchronization to work. That is most likely not a
good idea.
Indeed, I will fix that. How abount only creating fence array for
every wait pt when syncobj release? when syncobj release, wait pt
must have waited the signal opertation, then we can easily condense
fences for every wait pt. And meantime, we can take timeline based
wait pt advantage.
That could work, but I don't see how you want to replace the already
issued fence with a fence_array when the sync object is destroyed.
Additional to that I would rather prefer a consistent handling, e.g.
without extra rarely used code paths.
Ah, I find a easy way, we just need to make syncobj_timeline structure
as a reference. This way syncobj itself can be released first,
wait_pt/signal_pt don't need syncobj at all.
every wait_pt/signal_pt keep a reference of syncobj_timeline.
Additional to that you enable signaling without a need from the
waiting side. That is rather bad for implementations which need that
optimization.
Do you mean increasing timeline based on signal fence is not better?
only update timeline value when requested by a wait pt?
Yes, exactly.
This way, we will not update timeline value immidiately and cannot
free signal pt immidiately, and we also need to consider it to CPU
query and wait.
That is actually the better coding style. We usually try to avoid
doing things in interrupt handlers as much as possible.
OK, I see your concern, how about to delay handling to a workqueue? this
way, we only increase timeline value and wake up workqueue in fence cb,
is that acceptable?
How about this idea:
1. Each signaling point is a fence implementation with an rb node.
2. Each node keeps a reference to the last previously inserted node.
3. Each node is referenced by the sync object itself.
4. Before each signal/wait operation we do a garbage
[RFC] drm/amdgpu: Add macros and documentation for format modifiers.
This is an initial proposal for format modifiers for AMD hardware.
It uses 48 bits including a chip generation, leaving 8 bits for
a format version number.
On gfx6-gfx8 we have all the fields influencing sample locations
in memory.
Tile split bytes are optional for single sample buffers as no
hardware reaches the split size with 1 sample and hence the actual
size does not matter.
The macrotile fields are duplicated for images with multiple planes.
If the planes have different bitdepth they need different macro
tile fields and different tile split bytes if multisample.
I could not fit multiple copies in for tile split bytes, but
multisample & multiplane images are very rare. Overall, I think
we should punt on multisample for a later format version since
they are generally not shared on any modifier aware windowing
system, and we have more issues like fmask & cmask.
We need these copies because the drm modifier of all planes in an
image needs to be equal, so we need to fit these together.
This adds fields for compression support, using metadata that is
compatible with AMDVLK and for which radv and radeonsi can
reasonably be extended.
The big open question for compression is between which generations
the format changed to see if we can share more.
This explicitly does not try to solve the linear stride alignment
issue, thoguh we could internally just use the tiling modes for
the linear modes to indicate linear images with the stride for the
given chip.
Signed-off-by: Bas Nieuwenhuizen
CC: Chad Versace
CC: Dave Airlie
CC: Marek Olšák
CC: Nicolai Hähnle
CC: Alex Deucher
CC: Daniel Vetter
---
include/uapi/drm/amdgpu_drm.h | 130 ++
1 file changed, 130 insertions(+)
diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h
index 9eeba55b..4e1452161dbf 100644
--- a/include/uapi/drm/amdgpu_drm.h
+++ b/include/uapi/drm/amdgpu_drm.h
@@ -990,6 +990,136 @@ struct drm_amdgpu_info_vce_clock_table {
#define AMDGPU_FAMILY_AI 141 /* Vega10 */
#define AMDGPU_FAMILY_RV 142 /* Raven */
+#define AMDGPU_CHIP_TAHITI 0
+#define AMDGPU_CHIP_PITCAIRN 1
+#define AMDGPU_CHIP_VERDE 2
+#define AMDGPU_CHIP_OLAND 3
+#define AMDGPU_CHIP_HAINAN 4
+#define AMDGPU_CHIP_BONAIRE5
+#define AMDGPU_CHIP_KAVERI 6
+#define AMDGPU_CHIP_KABINI 7
+#define AMDGPU_CHIP_HAWAII 8
+#define AMDGPU_CHIP_MULLINS9
+#define AMDGPU_CHIP_TOPAZ 10
+#define AMDGPU_CHIP_TONGA 11
+#define AMDGPU_CHIP_FIJI 12
+#define AMDGPU_CHIP_CARRIZO13
+#define AMDGPU_CHIP_STONEY 14
+#define AMDGPU_CHIP_POLARIS10 15
+#define AMDGPU_CHIP_POLARIS11 16
+#define AMDGPU_CHIP_POLARIS12 17
+#define AMDGPU_CHIP_VEGAM 18
+#define AMDGPU_CHIP_VEGA10 19
+#define AMDGPU_CHIP_VEGA12 20
+#define AMDGPU_CHIP_VEGA20 21
+#define AMDGPU_CHIP_RAVEN 22
+
+/* Format for GFX6-GFX8 DRM format modifiers. These are intentionally the same
+ * as AMDGPU_TILING_*. However, the the rules as to when to set them are
+ * different.
+ *
+ * Do not use linear ARRAY_MODEs or SWIZZLE_MODEs. Use DRM_FORMAT_MOD_LINEAR
+ * instead.
+ *
+ * If ARRAY_MODE is 1D, only the micro tile mode and the pipe config should be
+ * set.
+ *
+ * For other ARRAY_MODEs:
+ * - Only set TILE_SPLIT if the image is multisample.
+ *
+ * We have 1 extra bit for the micro tile mode, as GFX6 and GFX7+ have 1
+ * different value there. The values are
+ * - depth : 0
+ * - displayable : 1
+ * - thin: 2
+ * - thick (GFX6): 3
+ * - rotated (GFX7+) : 4
+ *
+ * TODO: What to do with multisample multi plane images? More tile split
+ * fields don't fit if we want to keep a few bits for a format version.
+ */
+#define AMDGPU_MODIFIER_GFX8_ARRAY_MODE_SHIFT 0
+#define AMDGPU_MODIFIER_GFX8_ARRAY_MODE_MASK 0xf
+#define AMDGPU_MODIFIER_GFX8_PIPE_CONFIG_SHIFT 4
+#define AMDGPU_MODIFIER_GFX8_PIPE_CONFIG_MASK 0x1f
+#define AMDGPU_MODIFIER_GFX8_TILE_SPLIT_SHIFT 9
+#define AMDGPU_MODIFIER_GFX8_TILE_SPLIT_MASK 0x7
+#define AMDGPU_MODIFIER_GFX8_MICRO_TILE_MODE_SHIFT 12
+#define AMDGPU_MODIFIER_GFX8_MICRO_TILE_MODE_MASK 0x7
+#define AMDGPU_MODIFIER_GFX8_BANK_WIDTH_SHIFT 15
+#define AMDGPU_MODIFIER_GFX8_BANK_WIDTH_MASK 0x3
+#define AMDGPU_MODIFIER_GFX8_BANK_HEIGHT_SHIFT 17
+#define AMDGPU_MODIFIER_GFX8_BANK_HEIGHT_MASK 0x3
+#define AMDGPU_MODIFIER_GFX8_MACRO_TILE_ASPECT_SHIFT 19
+#define AMDGPU_MODIFIER_GFX8_MACRO_TILE_ASPECT_MASK0x3
+#define AMDGPU_MODIFIER_GFX8_NUM_BANKS_SHIFT 21
+#define AMDGPU_MODIFIER_GFX8_NUM_BANKS_MASK0x3
+
+/* Macrotile parameters for a second plane if existing */
+#define AMDGPU_MODIFIER_GFX8_BANK_WIDTH_1_SHIFT23
+#define AMDGPU_MODIFIER_GFX8_BANK_WIDTH_1_MASK 0x3
+#define AMDGPU_MODIFIER_GFX8_BANK_HEIGHT_1_SHIFT 25
+#define
[PATCH 2/5] drm/nouveau/disp/gm200-: add scdc parameter setter
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nvkm/engine/disp/Kbuild| 1 +
.../gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c | 34 ++
drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h | 2 ++
.../gpu/drm/nouveau/nvkm/engine/disp/sorgm200.c| 1 +
.../gpu/drm/nouveau/nvkm/engine/disp/sorgv100.c| 1 +
5 files changed, 39 insertions(+)
create mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/Kbuild
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/Kbuild
index 3d485dbf310a..8089ac9a12e2 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/Kbuild
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/Kbuild
@@ -50,6 +50,7 @@ nvkm-y += nvkm/engine/disp/hdmig84.o
nvkm-y += nvkm/engine/disp/hdmigt215.o
nvkm-y += nvkm/engine/disp/hdmigf119.o
nvkm-y += nvkm/engine/disp/hdmigk104.o
+nvkm-y += nvkm/engine/disp/hdmigm200.o
nvkm-y += nvkm/engine/disp/hdmigv100.o
nvkm-y += nvkm/engine/disp/conn.o
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c
new file mode 100644
index ..ad5f658c3f6d
--- /dev/null
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c
@@ -0,0 +1,34 @@
+/*
+ * Copyright 2018 Ilia Mirkin
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors: Ilia Mirkin
+ */
+#include "hdmi.h"
+
+void
+gm200_hdmi_scdc(struct nvkm_ior *ior, int head, u8 scdc)
+{
+ struct nvkm_device *device = ior->disp->engine.subdev.device;
+ const u32 hoff = head * 0x800;
+ const u32 ctrl = scdc & 0x3;
+
+ nvkm_mask(device, 0x61c5bc + hoff, 0x0003, ctrl);
+}
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h
index 57ffadc6a38e..cf640141ad23 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h
@@ -144,6 +144,8 @@ void gf119_hdmi_ctrl(struct nvkm_ior *, int, bool, u8, u8,
u8 *, u8 , u8 *, u8);
void gk104_hdmi_ctrl(struct nvkm_ior *, int, bool, u8, u8, u8 *, u8 , u8 *,
u8);
void gv100_hdmi_ctrl(struct nvkm_ior *, int, bool, u8, u8, u8 *, u8 , u8 *,
u8);
+void gm200_hdmi_scdc(struct nvkm_ior *, int, u8);
+
void gt215_hda_hpd(struct nvkm_ior *, int, bool);
void gt215_hda_eld(struct nvkm_ior *, u8 *, u8);
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgm200.c
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgm200.c
index d892bdf04034..384f82652bec 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgm200.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgm200.c
@@ -99,6 +99,7 @@ gm200_sor = {
.clock = gf119_sor_clock,
.hdmi = {
.ctrl = gk104_hdmi_ctrl,
+ .scdc = gm200_hdmi_scdc,
},
.dp = {
.lanes = { 0, 1, 2, 3 },
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgv100.c
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgv100.c
index 040db8a338de..8ba881a729ee 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgv100.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgv100.c
@@ -88,6 +88,7 @@ gv100_sor = {
.clock = gf119_sor_clock,
.hdmi = {
.ctrl = gv100_hdmi_ctrl,
+ .scdc = gm200_hdmi_scdc,
},
.dp = {
.lanes = { 0, 1, 2, 3 },
--
2.16.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/nouveau/disp: add support for setting scdc parameters for high modes
When SCDC is supported, make sure that we configure the GPU and monitor
to the same parameters.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 40 -
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 9bae4db84cfb..77cf5878896e 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include
#include
@@ -506,6 +507,7 @@ nv50_hdmi_disable(struct drm_encoder *encoder, struct
nouveau_crtc *nv_crtc)
static void
nv50_hdmi_enable(struct drm_encoder *encoder, struct drm_display_mode *mode)
{
+ struct nouveau_drm *drm = nouveau_drm(encoder->dev);
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
struct nouveau_crtc *nv_crtc = nouveau_crtc(encoder->crtc);
struct nv50_disp *disp = nv50_disp(encoder->dev);
@@ -523,9 +525,12 @@ nv50_hdmi_enable(struct drm_encoder *encoder, struct
drm_display_mode *mode)
.pwr.rekey = 56, /* binary driver, and tegra, constant */
};
struct nouveau_connector *nv_connector;
+ struct drm_hdmi_info *hdmi;
u32 max_ac_packet;
union hdmi_infoframe avi_frame;
union hdmi_infoframe vendor_frame;
+ bool scdc_supported, high_tmds_clock_ratio = false, scrambling = false;
+ u8 config;
int ret;
int size;
@@ -533,8 +538,11 @@ nv50_hdmi_enable(struct drm_encoder *encoder, struct
drm_display_mode *mode)
if (!drm_detect_hdmi_monitor(nv_connector->edid))
return;
+ hdmi = _connector->base.display_info.hdmi;
+ scdc_supported = hdmi->scdc.supported;
+
ret = drm_hdmi_avi_infoframe_from_display_mode(_frame.avi, mode,
- false);
+ scdc_supported);
if (!ret) {
/* We have an AVI InfoFrame, populate it to the display */
args.pwr.avi_infoframe_length
@@ -557,12 +565,42 @@ nv50_hdmi_enable(struct drm_encoder *encoder, struct
drm_display_mode *mode)
max_ac_packet -= 18; /* constant from tegra */
args.pwr.max_ac_packet = max_ac_packet / 32;
+ if (hdmi->scdc.scrambling.supported) {
+ high_tmds_clock_ratio = mode->clock > 34;
+ scrambling = high_tmds_clock_ratio ||
+ hdmi->scdc.scrambling.low_rates;
+ }
+
+ args.pwr.scdc =
+ NV50_DISP_SOR_HDMI_PWR_V0_SCDC_SCRAMBLE * scrambling |
+ NV50_DISP_SOR_HDMI_PWR_V0_SCDC_DIV_BY_4 * high_tmds_clock_ratio;
+
size = sizeof(args.base)
+ sizeof(args.pwr)
+ args.pwr.avi_infoframe_length
+ args.pwr.vendor_infoframe_length;
nvif_mthd(>disp->object, 0, , size);
+
nv50_audio_enable(encoder, mode);
+
+ /* If SCDC is supported by the downstream monitor, update
+* divider / scrambling settings to what we programmed above.
+*/
+ if (!hdmi->scdc.scrambling.supported)
+ return;
+
+ ret = drm_scdc_readb(nv_encoder->i2c, SCDC_TMDS_CONFIG, );
+ if (ret < 0) {
+ NV_ERROR(drm, "Failure to read SCDC_TMDS_CONFIG: %d\n", ret);
+ return;
+ }
+ config &= ~(SCDC_TMDS_BIT_CLOCK_RATIO_BY_40 | SCDC_SCRAMBLING_ENABLE);
+ config |= SCDC_TMDS_BIT_CLOCK_RATIO_BY_40 * high_tmds_clock_ratio;
+ config |= SCDC_SCRAMBLING_ENABLE * scrambling;
+ ret = drm_scdc_writeb(nv_encoder->i2c, SCDC_TMDS_CONFIG, config);
+ if (ret < 0)
+ NV_ERROR(drm, "Failure to write SCDC_TMDS_CONFIG = 0x%02x:
%d\n",
+config, ret);
}
/**
--
2.16.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] drm/nouveau: add basic HDMI 2.0 support
This is the beginnings of HDMI 2.0 support. All of the "extra" features are left out, such as 12/16bpc, YUV420, etc. I've verified that with this code, a GP108 (GT1030) can switch between 4k@60 and 1920x1080@60 on a LG 4K TV. Further, I've verified via i2c tools, that the SCDC writes really do happen. I suspect that the patch for keeping track of the high-speed TMDS setting is somehow off, esp if one were to switch between HDMI and DVI on the same port, or DP and HDMI. I'm quite confused about OR's vs HEAD's, and how to tell whether a register is indexed by one or the other. But at least it works a little bit! Note that I have limited testing equipment, but I did verify that a GM204 trace referred to the same register for controlling scrambling. I may get access to a GM206 later in the week to verify there. Ilia Mirkin (5): drm/nouveau/disp: add a way to configure scrambling/tmds for hdmi 2.0 drm/nouveau/disp/gm200-: add scdc parameter setter drm/nouveau/disp: keep track of high-speed state, program into clock drm/nouveau/disp: add support for setting scdc parameters for high modes drm/nouveau/disp: take sink support into account for exposing 594mhz drivers/gpu/drm/nouveau/dispnv50/disp.c| 40 +- drivers/gpu/drm/nouveau/include/nvif/cl5070.h | 5 ++- drivers/gpu/drm/nouveau/nouveau_connector.c| 34 +++--- drivers/gpu/drm/nouveau/nvkm/engine/disp/Kbuild| 1 + .../gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c | 36 +++ drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h | 8 + .../gpu/drm/nouveau/nvkm/engine/disp/rootnv50.c| 10 -- .../gpu/drm/nouveau/nvkm/engine/disp/sorgf119.c| 11 +++--- .../gpu/drm/nouveau/nvkm/engine/disp/sorgm200.c| 1 + .../gpu/drm/nouveau/nvkm/engine/disp/sorgv100.c| 1 + 10 files changed, 127 insertions(+), 20 deletions(-) create mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c -- 2.16.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/nouveau/disp: take sink support into account for exposing 594mhz
Scrambling is required for supporting any mode over 340MHz. If it's not
supported, reject any modes that would require it.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 34 +++--
1 file changed, 22 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index af68eae4c626..64228cc1412c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -977,18 +977,33 @@ nouveau_connector_get_modes(struct drm_connector
*connector)
}
static unsigned
-get_tmds_link_bandwidth(struct drm_connector *connector, bool hdmi)
+get_tmds_link_bandwidth(struct drm_connector *connector)
{
struct nouveau_connector *nv_connector = nouveau_connector(connector);
+ struct nouveau_encoder *nv_encoder = nv_connector->detected_encoder;
struct nouveau_drm *drm = nouveau_drm(connector->dev);
struct dcb_output *dcb = nv_connector->detected_encoder->dcb;
+ struct drm_display_info *info = NULL;
+ const unsigned duallink_scale =
+ nouveau_duallink && nv_encoder->dcb->duallink_possible ? 2 : 1;
+
+ if (drm_detect_hdmi_monitor(nv_connector->edid))
+ info = _connector->base.display_info;
- if (hdmi) {
+ if (info) {
if (nouveau_hdmimhz > 0)
return nouveau_hdmimhz * 1000;
/* Note: these limits are conservative, some Fermi's
* can do 297 MHz. Unclear how this can be determined.
*/
+ if (drm->client.device.info.chipset >= 0x120) {
+ const int max_tmds_clock =
+ info->hdmi.scdc.scrambling.supported ?
+ 594000 : 34;
+ return info->max_tmds_clock ?
+ min(info->max_tmds_clock, max_tmds_clock) :
+ max_tmds_clock;
+ }
if (drm->client.device.info.family >= NV_DEVICE_INFO_V0_KEPLER)
return 297000;
if (drm->client.device.info.family >= NV_DEVICE_INFO_V0_FERMI)
@@ -996,13 +1011,13 @@ get_tmds_link_bandwidth(struct drm_connector *connector,
bool hdmi)
}
if (dcb->location != DCB_LOC_ON_CHIP ||
drm->client.device.info.chipset >= 0x46)
- return 165000;
+ return 165000 * duallink_scale;
else if (drm->client.device.info.chipset >= 0x40)
- return 155000;
+ return 155000 * duallink_scale;
else if (drm->client.device.info.chipset >= 0x18)
- return 135000;
+ return 135000 * duallink_scale;
else
- return 112000;
+ return 112000 * duallink_scale;
}
static enum drm_mode_status
@@ -1014,7 +1029,6 @@ nouveau_connector_mode_valid(struct drm_connector
*connector,
struct drm_encoder *encoder = to_drm_encoder(nv_encoder);
unsigned min_clock = 25000, max_clock = min_clock;
unsigned clock = mode->clock;
- bool hdmi;
switch (nv_encoder->dcb->type) {
case DCB_OUTPUT_LVDS:
@@ -1027,11 +1041,7 @@ nouveau_connector_mode_valid(struct drm_connector
*connector,
max_clock = 40;
break;
case DCB_OUTPUT_TMDS:
- hdmi = drm_detect_hdmi_monitor(nv_connector->edid);
- max_clock = get_tmds_link_bandwidth(connector, hdmi);
- if (!hdmi && nouveau_duallink &&
- nv_encoder->dcb->duallink_possible)
- max_clock *= 2;
+ max_clock = get_tmds_link_bandwidth(connector);
break;
case DCB_OUTPUT_ANALOG:
max_clock = nv_encoder->dcb->crtconf.maxfreq;
--
2.16.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/nouveau/disp: keep track of high-speed state, program into clock
The register programmed by the clock method needs to contain a different
setting for the link speed as well as special divider settings.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c | 2 ++
drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h | 5 +
drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgf119.c | 11 +++
3 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c
index ad5f658c3f6d..9b16a08eb4d9 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c
@@ -31,4 +31,6 @@ gm200_hdmi_scdc(struct nvkm_ior *ior, int head, u8 scdc)
const u32 ctrl = scdc & 0x3;
nvkm_mask(device, 0x61c5bc + hoff, 0x0003, ctrl);
+
+ ior->tmds.high_speed = !!(scdc & 0x2);
}
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h
index cf640141ad23..e2e0515a178c 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h
@@ -40,6 +40,11 @@ struct nvkm_ior {
u8 nr;
u8 bw;
} dp;
+
+ /* Armed TMDS state. */
+ struct {
+ bool high_speed;
+ } tmds;
};
struct nvkm_ior_func {
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgf119.c
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgf119.c
index e6e6dfbb1283..456a5a143522 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgf119.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgf119.c
@@ -120,13 +120,16 @@ void
gf119_sor_clock(struct nvkm_ior *sor)
{
struct nvkm_device *device = sor->disp->engine.subdev.device;
- const int div = sor->asy.link == 3;
const u32 soff = nv50_ior_base(sor);
+ u32 div1 = sor->asy.link == 3;
+ u32 div2 = sor->asy.link == 3;
if (sor->asy.proto == TMDS) {
- /* NFI why, but this sets DP_LINK_BW_2_7 when using TMDS. */
- nvkm_mask(device, 0x612300 + soff, 0x007c, 0x0a << 18);
+ const u32 speed = sor->tmds.high_speed ? 0x14 : 0x0a;
+ nvkm_mask(device, 0x612300 + soff, 0x007c, speed << 18);
+ if (sor->tmds.high_speed)
+ div2 = 1;
}
- nvkm_mask(device, 0x612300 + soff, 0x0707, (div << 8) | div);
+ nvkm_mask(device, 0x612300 + soff, 0x0707, (div2 << 8) | div1);
}
void
--
2.16.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] drm/nouveau/disp: add a way to configure scrambling/tmds for hdmi 2.0
High pixel clocks are required to use a 40 TMDS divider instead of 10,
and even low ones may optionally use scrambling depending on device
support.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/include/nvif/cl5070.h | 5 -
drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h | 1 +
drivers/gpu/drm/nouveau/nvkm/engine/disp/rootnv50.c | 10 --
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/include/nvif/cl5070.h
b/drivers/gpu/drm/nouveau/include/nvif/cl5070.h
index 7cdf53615d7b..bced81987269 100644
--- a/drivers/gpu/drm/nouveau/include/nvif/cl5070.h
+++ b/drivers/gpu/drm/nouveau/include/nvif/cl5070.h
@@ -69,7 +69,10 @@ struct nv50_disp_sor_hdmi_pwr_v0 {
__u8 rekey;
__u8 avi_infoframe_length;
__u8 vendor_infoframe_length;
- __u8 pad06[2];
+#define NV50_DISP_SOR_HDMI_PWR_V0_SCDC_SCRAMBLE (1 << 0)
+#define NV50_DISP_SOR_HDMI_PWR_V0_SCDC_DIV_BY_4 (1 << 1)
+ __u8 scdc;
+ __u8 pad07[1];
};
struct nv50_disp_sor_lvds_script_v0 {
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h
index e0b4e0c5704e..57ffadc6a38e 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h
@@ -60,6 +60,7 @@ struct nvkm_ior_func {
void (*ctrl)(struct nvkm_ior *, int head, bool enable,
u8 max_ac_packet, u8 rekey, u8 *avi, u8 avi_size,
u8 *vendor, u8 vendor_size);
+ void (*scdc)(struct nvkm_ior *, int head, u8 scdc);
} hdmi;
struct {
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/rootnv50.c
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/rootnv50.c
index 3aa5a2879239..5f758948d6e1 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/rootnv50.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/rootnv50.c
@@ -176,9 +176,10 @@ nv50_disp_root_mthd_(struct nvkm_object *object, u32 mthd,
void *data, u32 size)
nvif_ioctl(object, "disp sor hdmi ctrl size %d\n", size);
if (!(ret = nvif_unpack(ret, , , args->v0, 0, 0,
true))) {
nvif_ioctl(object, "disp sor hdmi ctrl vers %d state %d
"
- "max_ac_packet %d rekey %d\n",
+ "max_ac_packet %d rekey %d scdc
%d\n",
args->v0.version, args->v0.state,
- args->v0.max_ac_packet, args->v0.rekey);
+ args->v0.max_ac_packet, args->v0.rekey,
+ args->v0.scdc);
if (args->v0.max_ac_packet > 0x1f || args->v0.rekey >
0x7f)
return -EINVAL;
if ((args->v0.avi_infoframe_length
@@ -202,6 +203,11 @@ nv50_disp_root_mthd_(struct nvkm_object *object, u32 mthd,
void *data, u32 size)
args->v0.max_ac_packet,
args->v0.rekey, avi, avi_size,
vendor, vendor_size);
+
+ if (outp->ior->func->hdmi.scdc)
+ outp->ior->func->hdmi.scdc(
+ outp->ior, hidx, args->v0.scdc);
+
return 0;
}
break;
--
2.16.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [virtio-dev] [PATCH 2/2] drm/virtio: add iommu support.
For the series,
Reviewed-by: Dave Airlie
On Wed, 29 Aug 2018 at 22:20, Gerd Hoffmann wrote:
>
> Use the dma mapping api and properly add iommu mappings for
> objects, unless virtio is in iommu quirk mode.
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
> drivers/gpu/drm/virtio/virtgpu_vq.c | 46
> +---
> 2 files changed, 38 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
> b/drivers/gpu/drm/virtio/virtgpu_drv.h
> index cbbff01077..ec9a38f995 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> @@ -57,6 +57,7 @@ struct virtio_gpu_object {
> uint32_t hw_res_handle;
>
> struct sg_table *pages;
> + uint32_t mapped;
> void *vmap;
> bool dumb;
> struct ttm_placeplacement_code;
> diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
> b/drivers/gpu/drm/virtio/virtgpu_vq.c
> index af24e91267..bf631d32d4 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_vq.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
> @@ -424,7 +424,8 @@ void virtio_gpu_cmd_unref_resource(struct
> virtio_gpu_device *vgdev,
> }
>
> static void virtio_gpu_cmd_resource_inval_backing(struct virtio_gpu_device
> *vgdev,
> - uint32_t resource_id)
> + uint32_t resource_id,
> + struct virtio_gpu_fence
> **fence)
> {
> struct virtio_gpu_resource_detach_backing *cmd_p;
> struct virtio_gpu_vbuffer *vbuf;
> @@ -435,7 +436,7 @@ static void virtio_gpu_cmd_resource_inval_backing(struct
> virtio_gpu_device *vgde
> cmd_p->hdr.type = cpu_to_le32(VIRTIO_GPU_CMD_RESOURCE_DETACH_BACKING);
> cmd_p->resource_id = cpu_to_le32(resource_id);
>
> - virtio_gpu_queue_ctrl_buffer(vgdev, vbuf);
> + virtio_gpu_queue_fenced_ctrl_buffer(vgdev, vbuf, _p->hdr, fence);
> }
>
> void virtio_gpu_cmd_set_scanout(struct virtio_gpu_device *vgdev,
> @@ -848,9 +849,10 @@ int virtio_gpu_object_attach(struct virtio_gpu_device
> *vgdev,
> uint32_t resource_id,
> struct virtio_gpu_fence **fence)
> {
> + bool use_dma_api = !virtio_has_iommu_quirk(vgdev->vdev);
> struct virtio_gpu_mem_entry *ents;
> struct scatterlist *sg;
> - int si;
> + int si, nents;
>
> if (!obj->pages) {
> int ret;
> @@ -860,23 +862,33 @@ int virtio_gpu_object_attach(struct virtio_gpu_device
> *vgdev,
> return ret;
> }
>
> + if (use_dma_api) {
> + obj->mapped = dma_map_sg(vgdev->vdev->dev.parent,
> +obj->pages->sgl, obj->pages->nents,
> +DMA_TO_DEVICE);
> + nents = obj->mapped;
> + } else {
> + nents = obj->pages->nents;
> + }
> +
> /* gets freed when the ring has consumed it */
> - ents = kmalloc_array(obj->pages->nents,
> -sizeof(struct virtio_gpu_mem_entry),
> + ents = kmalloc_array(nents, sizeof(struct virtio_gpu_mem_entry),
> GFP_KERNEL);
> if (!ents) {
> DRM_ERROR("failed to allocate ent list\n");
> return -ENOMEM;
> }
>
> - for_each_sg(obj->pages->sgl, sg, obj->pages->nents, si) {
> - ents[si].addr = cpu_to_le64(sg_phys(sg));
> + for_each_sg(obj->pages->sgl, sg, nents, si) {
> + ents[si].addr = cpu_to_le64(use_dma_api
> + ? sg_dma_address(sg)
> + : sg_phys(sg));
> ents[si].length = cpu_to_le32(sg->length);
> ents[si].padding = 0;
> }
>
> virtio_gpu_cmd_resource_attach_backing(vgdev, resource_id,
> - ents, obj->pages->nents,
> + ents, nents,
>fence);
> obj->hw_res_handle = resource_id;
> return 0;
> @@ -885,7 +897,23 @@ int virtio_gpu_object_attach(struct virtio_gpu_device
> *vgdev,
> void virtio_gpu_object_detach(struct virtio_gpu_device *vgdev,
> struct virtio_gpu_object *obj)
> {
> - virtio_gpu_cmd_resource_inval_backing(vgdev, obj->hw_res_handle);
> + bool use_dma_api = !virtio_has_iommu_quirk(vgdev->vdev);
> + struct virtio_gpu_fence *fence;
> +
> + if (use_dma_api && obj->mapped) {
> + /* detach backing and wait for the host process it ... */
> + virtio_gpu_cmd_resource_inval_backing(vgdev,
> obj->hw_res_handle, );
> + dma_fence_wait(>f, true);
> + dma_fence_put(>f);
> +
Re: [PATCH] drm/virtio: track virtual output state
On Tue, 14 Aug 2018 at 01:30, Gerd Hoffmann wrote:
>
> Track whenever an virtual output (crtc) is enabled or disabled.
>
> On atomic updates check for both framebuffer being present and crtc
> being enabled to figure whenever the output is active or not.
>
> Signed-off-by: Gerd Hoffmann
Reviewed-by: Dave Airlie
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
> drivers/gpu/drm/virtio/virtgpu_display.c | 4
> drivers/gpu/drm/virtio/virtgpu_plane.c | 2 +-
> 3 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
> b/drivers/gpu/drm/virtio/virtgpu_drv.h
> index 65605e207b..d46f10e656 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> @@ -114,6 +114,7 @@ struct virtio_gpu_output {
> struct virtio_gpu_update_cursor cursor;
> int cur_x;
> int cur_y;
> + bool enabled;
> };
> #define drm_crtc_to_virtio_gpu_output(x) \
> container_of(x, struct virtio_gpu_output, crtc)
> diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
> b/drivers/gpu/drm/virtio/virtgpu_display.c
> index 25503b9335..9f1e0a669d 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_display.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_display.c
> @@ -109,6 +109,9 @@ static void virtio_gpu_crtc_mode_set_nofb(struct drm_crtc
> *crtc)
> static void virtio_gpu_crtc_atomic_enable(struct drm_crtc *crtc,
> struct drm_crtc_state *old_state)
> {
> + struct virtio_gpu_output *output =
> drm_crtc_to_virtio_gpu_output(crtc);
> +
> + output->enabled = true;
> }
>
> static void virtio_gpu_crtc_atomic_disable(struct drm_crtc *crtc,
> @@ -119,6 +122,7 @@ static void virtio_gpu_crtc_atomic_disable(struct
> drm_crtc *crtc,
> struct virtio_gpu_output *output =
> drm_crtc_to_virtio_gpu_output(crtc);
>
> virtio_gpu_cmd_set_scanout(vgdev, output->index, 0, 0, 0, 0, 0);
> + output->enabled = false;
> }
>
> static int virtio_gpu_crtc_atomic_check(struct drm_crtc *crtc,
> diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
> b/drivers/gpu/drm/virtio/virtgpu_plane.c
> index dc5b5b2b7a..88f2fb8c61 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_plane.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
> @@ -152,7 +152,7 @@ static void virtio_gpu_primary_plane_update(struct
> drm_plane *plane,
> if (WARN_ON(!output))
> return;
>
> - if (plane->state->fb) {
> + if (plane->state->fb && output->enabled) {
> vgfb = to_virtio_gpu_framebuffer(plane->state->fb);
> bo = gem_to_virtio_gpu_obj(vgfb->base.obj[0]);
> handle = bo->hw_res_handle;
> --
> 2.9.3
>
> ___
> 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: [git pull] drm udl fixes
> > I've seen that you dropped this patch: > https://patchwork.kernel.org/patch/10445393/ > > Is that patch correct or incorrect? In case it is incorrect, do you have > an idea how should fbdefio be used properly on KMS drivers? I suppose I was wondering what use fbdefio really has, modern code should be using KMS interface and the KMS dirty handling should be able to cover those cases. I don't really like the maintainability decrease moving to in-driver page handling causes vs using shmem. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107690] Blackscreen after installing AMD driver 18.30 for Vega 64 on Ubuntu 18.04.1
https://bugs.freedesktop.org/show_bug.cgi?id=107690 Gleb Zasyadko changed: What|Removed |Added Product|xorg|DRI Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop ||.org QA Contact|xorg-t...@lists.x.org | Component|Driver/AMDgpu-pro |DRM/AMDgpu -- 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: [git pull] drm udl fixes
On Tue, 31 Jul 2018, Dave Airlie wrote: > Pull request to myself just so it's logged and linked in right place, > but this is a set of Mikulas's udl kms patches I've looked over and am > happy with. > > Dave. I've seen that you dropped this patch: https://patchwork.kernel.org/patch/10445393/ Is that patch correct or incorrect? In case it is incorrect, do you have an idea how should fbdefio be used properly on KMS drivers? Mikulas > The following changes since commit acb1872577b346bd15ab3a3f8dff780d6cca4b70: > > Linux 4.18-rc7 (2018-07-29 14:44:52 -0700) > > are available in the Git repository at: > > git://people.freedesktop.org/~airlied/linux drm-udl-next > > for you to fetch changes up to 90991209837ab619555a46a97a88dead7a960d2d: > > udl-kms: dont spam the syslog with debug messages (2018-07-31 08:11:12 > +1000) > > > Mikulas Patocka (7): > udl-kms: change down_interruptible to down > udl-kms: handle allocation failure > udl-kms: fix crash due to uninitialized memory > udl-kms: avoid division > udl-kms: avoid prefetch > udl-kms: use spin_lock_irq instead of spin_lock_irqsave > udl-kms: dont spam the syslog with debug messages > > drivers/gpu/drm/udl/udl_drv.h | 2 +- > drivers/gpu/drm/udl/udl_fb.c | 23 ++- > drivers/gpu/drm/udl/udl_main.c | 45 +++-- > drivers/gpu/drm/udl/udl_modeset.c | 7 +++--- > drivers/gpu/drm/udl/udl_transfer.c | 46 > +- > 5 files changed, 60 insertions(+), 63 deletions(-) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND v6 1/2] drm/panel: Add support for Truly NT35597 panel driver
On Mon, Sep 3, 2018 at 9:50 PM Bjorn Andersson
wrote:
> On Tue 28 Aug 15:39 PDT 2018, Abhinav Kumar wrote:
> > From: "abhin...@codeaurora.org"
> >
> > Add support for Truly NT35597 panel driver used
> > in MSM reference platforms.
> >
> > This panel driver supports both single DSI and dual DSI
> > modes.
> >
> > However, this patch series adds support only for
> > dual DSI mode.
> >
> > Changes in v6:
> > - Introduce panel config to store panel specific
> > details
> > - Bring back the size member for the panel command
> > structure to make the design more scalable
> > - Move the display mode from the DT to driver
> > - Change the compatible string to indicate which
> > which board and panel it will be used for
> > - Rename the functions to match the panel driver
> > - Have a data member for each compatible string
> > - Remove the panel commands split as its not
> > required for the panel init functionality
> >
> > Signed-off-by: Archit Taneja
> > Signed-off-by: Abhinav Kumar
> [..]
> > diff --git a/drivers/gpu/drm/panel/panel-truly-nt35597.c
> > b/drivers/gpu/drm/panel/panel-truly-nt35597.c
> [..]
> > + { .compatible = "qcom,sdm845-mtp-2K-display",
>
> I do not agree with Linus here.
>
> If I understand correctly the variability in the video timing comes from
> the fact that the LCD Driver IC (NT35597) can be paired with different
> LCD panels. As such I strongly believe that the compatible should
> describe this combo, not which phone/devkit you mounted a panel using
> this Driver IC on.
I agree with that.
I just saw "it's some qualcomm string, not just the name of the LCD
driver so OK".
The inability to parse the "qcom,*" string is just my ignorance, sorry
for that.
Yours,
Linus Walleij
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107781] amdgpu hangs on resume on Lenovo A475
https://bugs.freedesktop.org/show_bug.cgi?id=107781 --- Comment #6 from Alex Findler --- I was afraid you'd ask that. Last time I built a kernel myself I was on Slackware 8. But I cloned the linux git repo yesterday in anticipation. I'll give it a try. https://fedoraproject.org/wiki/Building_a_custom_kernel I'll use these instructions. Which remote and baseline should I choose? -- 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 107261] [drm:generic_reg_wait [amdgpu]] *ERROR* REG_WAIT timeout 1us * 10 tries - optc1_lock line:628
https://bugs.freedesktop.org/show_bug.cgi?id=107261 --- Comment #4 from Elie B --- I am also getting a similar error only when using Wayland. When switching to Xorg I no longer get it. So is an issue related to Wayland or is it just because Wayland may use a mechanism that Xorg don't? -- 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 107572] Unrecoverable GPU hang with IP block:gfx_v8_0 is hung
https://bugs.freedesktop.org/show_bug.cgi?id=107572 --- Comment #20 from Paju --- I ran some Unigine tests with different kernels. No crashes with 4.13.12 and older kernels. Maybe somebody could try to run these tests too and confirm this? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107819] DRM radeon GPU fault detected (gem object lookup failed)
https://bugs.freedesktop.org/show_bug.cgi?id=107819 Bug ID: 107819 Summary: DRM radeon GPU fault detected (gem object lookup failed) Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/Radeon Assignee: dri-devel@lists.freedesktop.org Reporter: egdf...@opensuse.org After plug two monitor i see this errors in dmesg (first monitor connected in HDMI, second in DisplayPort): kernel: [drm:radeon_cs_parser_relocs [radeon]] *ERROR* gem object lookup failed 0xa kernel: [drm:radeon_cs_ioctl [radeon]] *ERROR* Failed to parse relocation -2! kernel: radeon :01:00.0: GPU fault detected: 146 0x0ec35014 kernel: radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00105B76 kernel: radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x03050014 kernel: VM fault (0x04, vmid 1) at page 1071990, write from CB (80) kernel: radeon :01:00.0: GPU fault detected: 146 0x0e835014 kernel: radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00105B57 kernel: radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x03010014 kernel: VM fault (0x04, vmid 1) at page 1071959, write from CB (16) kernel: radeon :01:00.0: GPU fault detected: 146 0x0ee36014 kernel: radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00105C3E kernel: radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x03020014 kernel: VM fault (0x04, vmid 1) at page 1072190, write from CB (32) kernel: radeon :01:00.0: GPU fault detected: 146 0x0ec36014 kernel: radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00105CC0 kernel: radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x03010014 kernel: VM fault (0x04, vmid 1) at page 1072320, write from CB (16) kernel: radeon :01:00.0: GPU fault detected: 146 0x0ee35014 kernel: radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00105D36 kernel: radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x03060014 kernel: VM fault (0x04, vmid 1) at page 1072438, write from CB (96) kernel: radeon :01:00.0: GPU fault detected: 146 0x0e836014 kernel: radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00105D9C kernel: radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x03050014 kernel: VM fault (0x04, vmid 1) at page 1072540, write from CB (80) kernel: radeon :01:00.0: GPU fault detected: 146 0x0ea35014 kernel: radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00105E12 kernel: radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x03010014 kernel: VM fault (0x04, vmid 1) at page 1072658, write from CB (16) kernel: radeon :01:00.0: GPU fault detected: 146 0x07435014 kernel: radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00105B38 kernel: radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x03010014 kernel: VM fault (0x04, vmid 1) at page 1071928, write from CB (16) kernel: radeon :01:00.0: GPU fault detected: 146 0x07035014 kernel: radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00105BA3 kernel: radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x03010014 kernel: VM fault (0x04, vmid 1) at page 1072035, write from CB (16) kernel: radeon :01:00.0: GPU fault detected: 146 0x07035014 kernel: radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00105C26 kernel: radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x03060014 kernel: VM fault (0x04, vmid 1) at page 1072166, write from CB (96) kernel: radeon :01:00.0: GPU fault detected: 146 0x07236014 kernel: radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00105C23 kernel: radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x03020014 installed: kernel-default-4.18.5-1.6.x86_64 libdrm_radeon1-32bit-2.4.93-1.1.x86_64 libdrm_amdgpu1-2.4.93-1.1.x86_64 libdrm_nouveau2-2.4.93-1.1.x86_64 libva-drm2-2.2.0-1.1.x86_64 libdrm_nouveau2-32bit-2.4.93-1.1.x86_64 libdrm2-2.4.93-1.1.x86_64 libdrm_intel1-32bit-2.4.93-1.1.x86_64 libdrm_intel1-2.4.93-1.1.x86_64 libdrm_radeon1-2.4.93-1.1.x86_64 libdrm2-32bit-2.4.93-1.1.x86_64 libdrm_amdgpu1-32bit-2.4.93-1.1.x86_64 libdrm-devel-2.4.93-1.1.x86_64 Mesa-libGLESv2-2-18.1.6-207.1.x86_64 Mesa-dri-32bit-18.1.6-205.1.x86_64 libOSMesa8-18.1.6-207.1.x86_64 Mesa-libva-18.1.6-207.1.x86_64 Mesa-libEGL1-18.1.6-207.1.x86_64 Mesa-gallium-18.1.6-207.1.x86_64 Mesa-libEGL-devel-18.1.6-207.1.x86_64 Mesa-libEGL1-32bit-18.1.6-207.1.x86_64 Mesa-gallium-32bit-18.1.6-205.1.x86_64 Mesa-libGL1-18.1.6-207.1.x86_64 Mesa-libglapi0-18.1.6-207.1.x86_64 Mesa-libd3d-32bit-18.1.6-205.1.x86_64 Mesa-dri-18.1.6-207.1.x86_64 Mesa-libglapi0-32bit-18.1.6-207.1.x86_64 Mesa-libGL-devel-18.1.6-207.1.x86_64 Mesa-demo-x-8.4.0-1.3.x86_64 Mesa-libd3d-18.1.6-207.1.x86_64 Mesa-32bit-18.1.6-207.1.x86_64 libOSMesa8-32bit-18.1.6-207.1.x86_64
Re: [Intel-gfx] [PATCH 09/14] drm: Update todo.rst
On 3 September 2018 at 17:54, Daniel Vetter wrote: > -Hide legacy cruft better > - > - > -Way back DRM supported only drivers which shadow-attached to PCI devices with > -userspace or fbdev drivers setting up outputs. Modern DRM drivers take charge > -of the entire device, you can spot them with the DRIVER_MODESET flag. > - > -Unfortunately there's still large piles of legacy code around which needs to > -be hidden so that driver writers don't accidentally end up using it. And to > -prevent security issues in those legacy IOCTLs from being exploited on modern > -drivers. This has multiple possible subtasks: > - > -* Extract support code for legacy features into a ``drm-legacy.ko`` kernel > - module and compile it only when one of the legacy drivers is enabled. > - This isn't done, > -This is mostly done, the only thing left is to split up ``drm_irq.c`` into > -legacy cruft and the parts needed by modern KMS drivers. > - ... while this one is. HTH -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/14] drm: Update todo.rst
Hi Daniel. > -Note that this is well in progress, but ``drmP.h`` is still huge. The updated > -plan is to switch to per-file driver API headers, which will also structure > -the kerneldoc better. This should also allow more fine-grained ``#include`` > -directives. > +The DRM subsystem originally had only one huge globale header, ``drmP.h``. > This globale => global > +is not split up, but many source files still include it. The remainig part of remainig => remaining Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm: fix drm_mode_addfb() on big endian machines.
On Mon, Sep 3, 2018 at 12:45 PM, Daniel Vetter wrote: > On Mon, Sep 03, 2018 at 12:57:54PM +0200, Gerd Hoffmann wrote: >> Userspace on big endian machhines typically expects the ADDFB ioctl >> returns a big endian framebuffer. drm_mode_addfb() will call >> drm_mode_addfb2() unconditionally with little endian DRM_FORMAT_* >> values though, which is wrong. This patch fixes that. >> >> Drivers (both kernel and xorg) have quirks in place to deal with the >> broken drm_mode_addfb() behavior. Because of this we can't just change >> drm_mode_addfb() behavior for everybody without breaking things. So add >> a new driver feature flag DRIVER_PREFER_HOST_BYTE_ORDER, so drivers can >> opt-in. >> >> Signed-off-by: Gerd Hoffmann >> --- >> include/drm/drm_drv.h | 1 + >> drivers/gpu/drm/drm_framebuffer.c | 11 +++ >> 2 files changed, 12 insertions(+) >> >> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h >> index 46a8009784..9cf12596cd 100644 >> --- a/include/drm/drm_drv.h >> +++ b/include/drm/drm_drv.h >> @@ -57,6 +57,7 @@ struct drm_printer; >> #define DRIVER_KMS_LEGACY_CONTEXT0x2 >> #define DRIVER_SYNCOBJ 0x4 >> #define DRIVER_PREFER_XBGR_30BPP0x8 >> +#define DRIVER_PREFER_HOST_BYTE_ORDER 0x10 > > Hm, not a huge fan of using driver_flags for random little quirks. I think > a boolean in sturct drm_mode_config would be much better. Bonus if you > also move the 30bpp hack over to that. Something like > mode_config.quirk_addfb_host_byte_order and > mode_config.quirk_addfb_prefer_xbgr_30bpp or whatever. That has the upside > of giving us a really nice place to put a huge comment about what this is > supposed to do. > > I think otherwise this looks overall rather reasonable. I think the only > other driver that ever cared about big endian was radeon/amdgpu. Would be > good to get at least an ack from amd folks, or a "meh, stopped caring". and nouveau. I do believe that ADDFB should be made to always prefer host byte order -- this is how all of the existing implementations work in practice. However e.g. nouveau wants DRM_FORMAT_XRGB. But it still treats it as host byte order. This will become more important in a world where ADDFB2 is more common. So, I think that this change should be applied, drivers (I suspect just nouveau and radeon) fixed up to consume the "new" formats, and then made to be the one-and-only way for ADDFB to function. That way we'll no longer be lying about the DRM_FORMAT being used. Cheers, -ilia ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm: fix drm_mode_addfb() on big endian machines.
On 2018-09-03 6:45 p.m., Daniel Vetter wrote: > On Mon, Sep 03, 2018 at 12:57:54PM +0200, Gerd Hoffmann wrote: >> Userspace on big endian machhines typically expects the ADDFB ioctl >> returns a big endian framebuffer. drm_mode_addfb() will call >> drm_mode_addfb2() unconditionally with little endian DRM_FORMAT_* >> values though, which is wrong. This patch fixes that. >> >> Drivers (both kernel and xorg) have quirks in place to deal with the >> broken drm_mode_addfb() behavior. Because of this we can't just change >> drm_mode_addfb() behavior for everybody without breaking things. So add >> a new driver feature flag DRIVER_PREFER_HOST_BYTE_ORDER, so drivers can >> opt-in. Since the changes are opt-in now, they shouldn't affect drivers which don't opt in; they should work as well (or as badly :) after these changes as they did before. So no concerns from my side anymore. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux
On 09/03/2018 06:33 PM, Daniel Vetter wrote: On Mon, Sep 03, 2018 at 11:16:29AM +0200, Thomas Hellstrom wrote: On 08/31/2018 05:30 PM, Thomas Hellstrom wrote: On 08/31/2018 05:27 PM, Emil Velikov wrote: On 31 August 2018 at 15:38, Michel Dänzer wrote: [ Adding the amd-gfx list ] On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote: On 08/31/2018 02:30 PM, Emil Velikov wrote: On 31 August 2018 at 12:54, Thomas Hellstrom wrote: To determine whether a device node is a drm device node or not, the code currently compares the node's major number to the static drm major device number. This breaks the standalone vmwgfx driver on XWayland dri clients, Any particular reason why the code doesn't use a fixed node there? It will make the diff vs the in-kernel driver a bit smaller. Because then it won't be able to interoperate with other in-tree drivers, like virtual drm drivers or passthrough usb drm drivers. There is no clean way to share the minor number allocation with in-tree drm, so standalone vmwgfx is using dynamic major allocation. I wonder why I haven't heard of any of these issues with the standalone version of amdgpu shipped in packaged AMD releases. Does that also use a different major number? If yes, maybe it's just that nobody has tried Xwayland clients with that driver. If no, how does it avoid the other issues described above? AFAICT, the difference is that the standalone vmwgfx uses an internal copy of drm core. It doesn't reuse the in-kernel drm, hence it cannot know which minor it can use. -Emil Actually, standalone vmwgfx could perhaps also try to allocate minors from 63 and downwards. That might work, but needs some verification. So unfortuntately this doesn't work since the in-tree drm's file operations are registered with the DRM_MAJOR. So I still think the patch is the way to go. If people are concerned that also fbdev file descriptors are allowed, perhaps there are other sysfs traits we can look at? Somewhat out of curiosity, but why do you have to overwrite all of drm? amdgpu seems to be able to pull their stunt off without ... -Daniel At the time we launched the standalone vmwgfx, the DRM <-> driver interface was moving considerably more rapidly than the DRM <-> kernel interface. I think that's still the case. Hence less work for us. Also meant we can install the full driver stack with latest features on fairly old VMs without backported DRM functionality. /Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/14] drm: Extract drm_atomic_state_helper.[hc]
We already have a separate overview doc for this, makes sense to
untangle it from the overall atomic helpers.
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms-helpers.rst | 19 +-
drivers/gpu/drm/Makefile | 3 +-
drivers/gpu/drm/drm_atomic_helper.c | 568
drivers/gpu/drm/drm_atomic_state_helper.c | 603 ++
include/drm/drm_atomic_helper.h | 44 +-
include/drm/drm_atomic_state_helper.h | 80 +++
6 files changed, 700 insertions(+), 617 deletions(-)
create mode 100644 drivers/gpu/drm/drm_atomic_state_helper.c
create mode 100644 include/drm/drm_atomic_state_helper.h
diff --git a/Documentation/gpu/drm-kms-helpers.rst
b/Documentation/gpu/drm-kms-helpers.rst
index f9cfcdcdf024..4b4dc236ef6f 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -59,19 +59,28 @@ Implementing Asynchronous Atomic Commit
.. kernel-doc:: drivers/gpu/drm/drm_atomic_helper.c
:doc: implementing nonblocking commit
+Helper Functions Reference
+--
+
+.. kernel-doc:: include/drm/drm_atomic_helper.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_atomic_helper.c
+ :export:
+
Atomic State Reset and Initialization
-
-.. kernel-doc:: drivers/gpu/drm/drm_atomic_helper.c
+.. kernel-doc:: drivers/gpu/drm/drm_atomic_state_helper.c
:doc: atomic state reset and initialization
-Helper Functions Reference
---
+Atomic State Helper Reference
+-
-.. kernel-doc:: include/drm/drm_atomic_helper.h
+.. kernel-doc:: include/drm/drm_atomic_state_helper.h
:internal:
-.. kernel-doc:: drivers/gpu/drm/drm_atomic_helper.c
+.. kernel-doc:: drivers/gpu/drm/drm_atomic_state_helper.c
:export:
Simple KMS Helper Reference
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index bc6a16a3c36e..576ba985e138 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -36,7 +36,8 @@ drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o
drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
drm_simple_kms_helper.o drm_modeset_helper.o \
- drm_scdc_helper.o drm_gem_framebuffer_helper.o
+ drm_scdc_helper.o drm_gem_framebuffer_helper.o \
+ drm_atomic_state_helper.o
drm_kms_helper-$(CONFIG_DRM_PANEL_BRIDGE) += bridge/panel.o
drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 334b121bd4d9..a5edc8757056 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3382,571 +3382,3 @@ int drm_atomic_helper_page_flip_target(struct drm_crtc
*crtc,
return ret;
}
EXPORT_SYMBOL(drm_atomic_helper_page_flip_target);
-
-/**
- * DOC: atomic state reset and initialization
- *
- * Both the drm core and the atomic helpers assume that there is always the
full
- * and correct atomic software state for all connectors, CRTCs and planes
- * available. Which is a bit a problem on driver load and also after system
- * suspend. One way to solve this is to have a hardware state read-out
- * infrastructure which reconstructs the full software state (e.g. the i915
- * driver).
- *
- * The simpler solution is to just reset the software state to everything off,
- * which is easiest to do by calling drm_mode_config_reset(). To facilitate
this
- * the atomic helpers provide default reset implementations for all hooks.
- *
- * On the upside the precise state tracking of atomic simplifies system suspend
- * and resume a lot. For drivers using drm_mode_config_reset() a complete
recipe
- * is implemented in drm_atomic_helper_suspend() and
drm_atomic_helper_resume().
- * For other drivers the building blocks are split out, see the documentation
- * for these functions.
- */
-
-/**
- * drm_atomic_helper_crtc_reset - default _crtc_funcs.reset hook for CRTCs
- * @crtc: drm CRTC
- *
- * Resets the atomic state for @crtc by freeing the state pointer (which might
- * be NULL, e.g. at driver load time) and allocating a new empty state object.
- */
-void drm_atomic_helper_crtc_reset(struct drm_crtc *crtc)
-{
- if (crtc->state)
- __drm_atomic_helper_crtc_destroy_state(crtc->state);
-
- kfree(crtc->state);
- crtc->state = kzalloc(sizeof(*crtc->state), GFP_KERNEL);
-
- if (crtc->state)
- crtc->state->crtc = crtc;
-}
-EXPORT_SYMBOL(drm_atomic_helper_crtc_reset);
-
-/**
- * __drm_atomic_helper_crtc_duplicate_state - copy atomic CRTC state
- * @crtc: CRTC object
- * @state: atomic CRTC state
- *
- * Copies atomic state from a CRTC's current state and resets inferred values.
- * This is useful for drivers that subclass the CRTC state.
-
[PATCH 13/14] drm/atomic: Improve docs for drm_atomic_state->allow_modeset
Motivated by vmwgfx digging around in core uapi bits it shouldn't dig
around in.
Signed-off-by: Daniel Vetter
---
include/drm/drm_atomic.h | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index 4aff40886acb..91d896ec9c10 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -254,7 +254,6 @@ struct __drm_private_objs_state {
* struct drm_atomic_state - the global state object for atomic updates
* @ref: count of all references to this state (will not be freed until zero)
* @dev: parent DRM device
- * @allow_modeset: allow full modeset
* @legacy_cursor_update: hint to enforce legacy cursor IOCTL semantics
* @async_update: hint for asynchronous plane update
* @planes: pointer to array of structures with per-plane data
@@ -273,6 +272,15 @@ struct drm_atomic_state {
struct kref ref;
struct drm_device *dev;
+
+ /**
+* @allow_modeset:
+*
+* Allow full modeset. This is used by the ATOMIC IOCTL handler to
+* implement the DRM_MODE_ATOMIC_ALLOW_MODESET flag. Drivers should
+* never consult this flag, instead looking at the output of
+* drm_atomic_crtc_needs_modeset().
+*/
bool allow_modeset : 1;
bool legacy_cursor_update : 1;
bool async_update : 1;
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 12/14] drm/vmwgfx: Don't look at state->allow_modeset
That's purely for the uapi layer to implement the ALLOW_MODESET flag.
Drivers should instead look at the state, e.g. through
drm_atomic_crtc_needs_modeset(), which vmwgfx already does. Also remove
the confusing comment, since checking allow_modeset is at best a micro
optimization.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 0f7e116a59f0..71b7460d140f 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1683,14 +1683,6 @@ vmw_kms_atomic_check_modeset(struct drm_device *dev,
if (ret)
return ret;
- if (!state->allow_modeset)
- return ret;
-
- /*
-* Legacy path do not set allow_modeset properly like
-* @drm_atomic_helper_update_plane, This will result in unnecessary call
-* to vmw_kms_check_topology. So extra set of check.
-*/
for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
if (drm_atomic_crtc_needs_modeset(crtc_state))
need_modeset = true;
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 14/14] drm/vmwgfx: Add FIXME comments for customer page_flip handlers
The idea behind allowing drivers to override legacy ioctls (instead of using the generic implementations unconditionally) is to handle bugs in old driver-specific userspace. Like e.g. vmw_kms_set_config does, to work around some vmwgfx userspace not clearing its ioctl structs properly. But you can't use it to augment semantics and put in additional checks, since from a correctly working userspace's pov there should not be any difference in behaviour between the legacy and the atomic paths. vmwgfx seems to be doing some strange things in its page_flip handlers. Since I'm not an expert of this codebase just wrap some FIXME comments around the potentially problematic code. Signed-off-by: Daniel Vetter Cc: VMware Graphics Cc: Sinclair Yeh Cc: Thomas Hellstrom --- drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 2 ++ drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 1 + 2 files changed, 3 insertions(+) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c index 4c68ad6f3605..8e692334c3b9 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c @@ -326,6 +326,7 @@ static int vmw_sou_crtc_page_flip(struct drm_crtc *crtc, struct vmw_private *dev_priv = vmw_priv(crtc->dev); int ret; + /* FIMXE: This check needs to be moved into ->atomic_check code. */ if (!vmw_kms_crtc_flippable(dev_priv, crtc)) return -EINVAL; @@ -335,6 +336,7 @@ static int vmw_sou_crtc_page_flip(struct drm_crtc *crtc, return ret; } + /* FIMXE: This code needs to be moved into ->atomic_commit callbacks. */ if (vmw_crtc_to_du(crtc)->is_implicit) vmw_kms_update_implicit_fb(dev_priv, crtc); diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c index f5b2fe8a7793..1913e086d015 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c @@ -501,6 +501,7 @@ static int vmw_stdu_crtc_page_flip(struct drm_crtc *crtc, struct vmw_screen_target_display_unit *stdu = vmw_crtc_to_stdu(crtc); int ret; + /* FIMXE: This check needs to be moved into ->atomic_check code. */ if (!stdu->defined || !vmw_kms_crtc_flippable(dev_priv, crtc)) return -EINVAL; -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/14] drm/amdgpu: Remove default best_encoder hook from DC
For atomic driver this is the default, no need to reimplement it. We
still need to keep the copypasta for not-atomic drivers though, since
no one polished the legacy crtc helpers as much as the atomic ones.
Signed-off-by: Daniel Vetter
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Andrey Grodzovsky
Cc: Tony Cheng
Cc: "Leo (Sunpeng) Li"
Cc: Shirish S
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 23 ---
1 file changed, 23 deletions(-)
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 af6adffba788..333f9904f135 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2794,28 +2794,6 @@ static const struct drm_connector_funcs
amdgpu_dm_connector_funcs = {
.atomic_get_property = amdgpu_dm_connector_atomic_get_property
};
-static struct drm_encoder *best_encoder(struct drm_connector *connector)
-{
- int enc_id = connector->encoder_ids[0];
- struct drm_mode_object *obj;
- struct drm_encoder *encoder;
-
- DRM_DEBUG_DRIVER("Finding the best encoder\n");
-
- /* pick the encoder ids */
- if (enc_id) {
- obj = drm_mode_object_find(connector->dev, NULL, enc_id,
DRM_MODE_OBJECT_ENCODER);
- if (!obj) {
- DRM_ERROR("Couldn't find a matching encoder for our
connector\n");
- return NULL;
- }
- encoder = obj_to_encoder(obj);
- return encoder;
- }
- DRM_ERROR("No encoder id\n");
- return NULL;
-}
-
static int get_modes(struct drm_connector *connector)
{
return amdgpu_dm_connector_get_modes(connector);
@@ -2934,7 +2912,6 @@ amdgpu_dm_connector_helper_funcs = {
*/
.get_modes = get_modes,
.mode_valid = amdgpu_dm_connector_mode_valid,
- .best_encoder = best_encoder
};
static void dm_crtc_helper_disable(struct drm_crtc *crtc)
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/14] drm/vmwgfx: Remove confused comment from vmw_du_connector_atomic_set_property
The core _does_ the call to drm_atomic_commit for you. That's pretty
much the entire point of having the fancy new atomic_set/get_prop
callbacks.
Signed-off-by: Daniel Vetter
Cc: VMware Graphics
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 0c25bb8faf80..0f7e116a59f0 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -2309,12 +2309,6 @@ vmw_du_connector_atomic_set_property(struct
drm_connector *connector,
if (property == dev_priv->implicit_placement_property) {
vcs->is_implicit = val;
-
- /*
-* We should really be doing a drm_atomic_commit() to
-* commit the new state, but since this doesn't cause
-* an immedate state change, this is probably ok
-*/
du->is_implicit = vcs->is_implicit;
} else {
return -EINVAL;
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/14] drm: extract drm_atomic_uapi.c
This leaves all the commit/check and state handling in drm_atomic.c,
while pulling all the uapi glue and the huge ioctl itself into a
seprate file.
This seems to almost perfectly split the rather big drm_atomic.c file
into 2 equal sizes.
Also adjust the kerneldoc and type a very terse overview text.
v2: Rebase.
v3: Fix tiny typo.
Signed-off-by: Daniel Vetter
Cc: David Airlie
Cc: Gustavo Padovan
Cc: Maarten Lankhorst
Cc: Sean Paul
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Rob Clark
Cc: Eric Anholt
Cc: intel-...@lists.freedesktop.org
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
---
Documentation/gpu/drm-kms.rst| 11 +-
drivers/gpu/drm/Makefile |3 +-
drivers/gpu/drm/drm_atomic.c | 1359 +
drivers/gpu/drm/drm_atomic_helper.c |1 +
drivers/gpu/drm/drm_atomic_uapi.c| 1393 ++
drivers/gpu/drm/drm_crtc_helper.c|1 +
drivers/gpu/drm/drm_crtc_internal.h |5 +
drivers/gpu/drm/drm_framebuffer.c|1 +
drivers/gpu/drm/drm_gem_framebuffer_helper.c |1 +
drivers/gpu/drm/drm_plane_helper.c |1 +
drivers/gpu/drm/i915/intel_display.c |1 +
drivers/gpu/drm/msm/msm_atomic.c |2 +
drivers/gpu/drm/vc4/vc4_crtc.c |1 +
drivers/gpu/drm/vc4/vc4_plane.c |1 +
include/drm/drm_atomic.h | 16 -
include/drm/drm_atomic_uapi.h| 58 +
16 files changed, 1480 insertions(+), 1375 deletions(-)
create mode 100644 drivers/gpu/drm/drm_atomic_uapi.c
create mode 100644 include/drm/drm_atomic_uapi.h
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 3a9dd68b97c9..4b1501b4835b 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -287,6 +287,15 @@ Atomic Mode Setting Function Reference
.. kernel-doc:: drivers/gpu/drm/drm_atomic.c
:export:
+Atomic Mode Setting IOCTL and UAPI Functions
+
+
+.. kernel-doc:: drivers/gpu/drm/drm_atomic_uapi.c
+ :doc: overview
+
+.. kernel-doc:: drivers/gpu/drm/drm_atomic_uapi.c
+ :export:
+
CRTC Abstraction
@@ -563,7 +572,7 @@ Tile Group Property
Explicit Fencing Properties
---
-.. kernel-doc:: drivers/gpu/drm/drm_atomic.c
+.. kernel-doc:: drivers/gpu/drm/drm_atomic_uapi.c
:doc: explicit fencing properties
Existing KMS Properties
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index a6771cef85e2..bc6a16a3c36e 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -18,7 +18,8 @@ drm-y :=drm_auth.o drm_bufs.o drm_cache.o \
drm_encoder.o drm_mode_object.o drm_property.o \
drm_plane.o drm_color_mgmt.o drm_print.o \
drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
- drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o
+ drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
+ drm_atomic_uapi.o
drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
drm-$(CONFIG_DRM_VM) += drm_vm.o
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 29a4e6959358..19634e03b78e 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -28,6 +28,7 @@
#include
#include
+#include
#include
#include
#include
@@ -309,285 +310,6 @@ drm_atomic_get_crtc_state(struct drm_atomic_state *state,
}
EXPORT_SYMBOL(drm_atomic_get_crtc_state);
-static void set_out_fence_for_crtc(struct drm_atomic_state *state,
- struct drm_crtc *crtc, s32 __user *fence_ptr)
-{
- state->crtcs[drm_crtc_index(crtc)].out_fence_ptr = fence_ptr;
-}
-
-static s32 __user *get_out_fence_for_crtc(struct drm_atomic_state *state,
- struct drm_crtc *crtc)
-{
- s32 __user *fence_ptr;
-
- fence_ptr = state->crtcs[drm_crtc_index(crtc)].out_fence_ptr;
- state->crtcs[drm_crtc_index(crtc)].out_fence_ptr = NULL;
-
- return fence_ptr;
-}
-
-static int set_out_fence_for_connector(struct drm_atomic_state *state,
- struct drm_connector *connector,
- s32 __user *fence_ptr)
-{
- unsigned int index = drm_connector_index(connector);
-
- if (!fence_ptr)
- return 0;
-
- if (put_user(-1, fence_ptr))
- return -EFAULT;
-
- state->connectors[index].out_fence_ptr = fence_ptr;
-
- return 0;
-}
-
-static s32 __user *get_out_fence_for_connector(struct drm_atomic_state *state,
- struct drm_connector *connector)
-{
- unsigned int index = drm_connector_index(connector);
- s32 __user *fence_ptr;
-
- fence_ptr =
[PATCH 07/14] drm/atomic-helper: Unexport drm_atomic_helper_best_encoder
It's the default. The exported version was kinda a transition state,
before we made this the default.
To stop new atomic drivers from using it (instead of just relying on
the default) let's unexport it.
Signed-off-by: Daniel Vetter
Cc: Gustavo Padovan
Cc: Maarten Lankhorst
Cc: Sean Paul
Cc: David Airlie
Cc: VMware Graphics
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
Cc: Archit Taneja
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Hans Verkuil
Cc: Daniel Vetter
Cc: Russell King
Cc: Jernej Skrabec
Cc: Jani Nikula
Cc: Pierre-Hugues Husson
Cc: Fabio Estevam
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 1 -
drivers/gpu/drm/drm_atomic_helper.c | 24 +++
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 1 -
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 1 -
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 1 -
include/drm/drm_atomic_helper.h | 2 --
6 files changed, 7 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 5971976284bf..0aed51799526 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1957,7 +1957,6 @@ static const struct drm_connector_funcs
dw_hdmi_connector_funcs = {
static const struct drm_connector_helper_funcs dw_hdmi_connector_helper_funcs
= {
.get_modes = dw_hdmi_connector_get_modes,
- .best_encoder = drm_atomic_helper_best_encoder,
};
static int dw_hdmi_bridge_attach(struct drm_bridge *bridge)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 8469a7e9afe3..334b121bd4d9 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -92,6 +92,13 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state
*state,
}
}
+static struct drm_encoder *
+drm_atomic_helper_best_encoder(struct drm_connector *connector)
+{
+ WARN_ON(connector->encoder_ids[1]);
+ return drm_encoder_find(connector->dev, NULL,
connector->encoder_ids[0]);
+}
+
static int handle_conflicting_encoders(struct drm_atomic_state *state,
bool disable_conflicting_encoders)
{
@@ -3376,23 +3383,6 @@ int drm_atomic_helper_page_flip_target(struct drm_crtc
*crtc,
}
EXPORT_SYMBOL(drm_atomic_helper_page_flip_target);
-/**
- * drm_atomic_helper_best_encoder - Helper for
- * _connector_helper_funcs.best_encoder callback
- * @connector: Connector control structure
- *
- * This is a _connector_helper_funcs.best_encoder callback helper for
- * connectors that support exactly 1 encoder, statically determined at driver
- * init time.
- */
-struct drm_encoder *
-drm_atomic_helper_best_encoder(struct drm_connector *connector)
-{
- WARN_ON(connector->encoder_ids[1]);
- return drm_encoder_find(connector->dev, NULL,
connector->encoder_ids[0]);
-}
-EXPORT_SYMBOL(drm_atomic_helper_best_encoder);
-
/**
* DOC: atomic state reset and initialization
*
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
index 723578117191..4b5378495eea 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
@@ -274,7 +274,6 @@ static const struct drm_connector_funcs
vmw_legacy_connector_funcs = {
static const struct
drm_connector_helper_funcs vmw_ldu_connector_helper_funcs = {
- .best_encoder = drm_atomic_helper_best_encoder,
};
/*
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index ad0de7f0cd60..4c68ad6f3605 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -389,7 +389,6 @@ static const struct drm_connector_funcs
vmw_sou_connector_funcs = {
static const struct
drm_connector_helper_funcs vmw_sou_connector_helper_funcs = {
- .best_encoder = drm_atomic_helper_best_encoder,
};
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
index 93f6b96ca7bb..f5b2fe8a7793 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
@@ -1037,7 +1037,6 @@ static const struct drm_connector_funcs
vmw_stdu_connector_funcs = {
static const struct
drm_connector_helper_funcs vmw_stdu_connector_helper_funcs = {
- .best_encoder = drm_atomic_helper_best_encoder,
};
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index 63e736eeb516..27aef91ca1c3 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -144,8 +144,6 @@ int drm_atomic_helper_page_flip_target(
uint32_t flags,
uint32_t target,
struct drm_modeset_acquire_ctx *ctx);
-struct drm_encoder *
-drm_atomic_helper_best_encoder(struct drm_connector *connector);
/* default implementations for state handling */
void drm_atomic_helper_crtc_reset(struct
[PATCH 09/14] drm: Update todo.rst
- drmP.h is now fully split up. - vkms is happening (and will gain its own todo and docs under a new vkms.rst file real soon) - legacy cruft is completely hidden now, drm_vblank.c is split out from drm_irq.c now. - best_encoder atomic cleanup is done (it's now the default, not even exported anymore) - bunch of smaller things Signed-off-by: Daniel Vetter Cc: Gustavo Padovan Cc: Maarten Lankhorst Cc: Sean Paul Cc: David Airlie --- Documentation/gpu/todo.rst | 68 ++ 1 file changed, 10 insertions(+), 58 deletions(-) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index a7c150d6b63f..96bfdbc9ebff 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -127,7 +127,8 @@ interfaces to fix these issues: the acquire context explicitly on stack and then also pass it down into drivers explicitly so that the legacy-on-atomic functions can use them. - Except for some driver code this is done. + Except for some driver code this is done. This task should be finished by + adding WARN_ON(!drm_drv_uses_atomic_modeset) in drm_modeset_lock_all(). * A bunch of the vtable hooks are now in the wrong place: DRM has a split between core vfunc tables (named ``drm_foo_funcs``), which are used to @@ -137,13 +138,6 @@ interfaces to fix these issues: ``_helper_funcs`` since they are not part of the core ABI. There's a ``FIXME`` comment in the kerneldoc for each such case in ``drm_crtc.h``. -* There's a new helper ``drm_atomic_helper_best_encoder()`` which could be - used by all atomic drivers which don't select the encoder for a given - connector at runtime. That's almost all of them, and would allow us to get - rid of a lot of ``best_encoder`` boilerplate in drivers. - - This was almost done, but new drivers added a few more cases again. - Contact: Daniel Vetter Get rid of dev->struct_mutex from GEM drivers @@ -164,9 +158,8 @@ private lock. The tricky part is the BO free functions, since those can't reliably take that lock any more. Instead state needs to be protected with suitable subordinate locks or some cleanup work pushed to a worker thread. For performance-critical drivers it might also be better to go with a more -fine-grained per-buffer object and per-context lockings scheme. Currently the -following drivers still use ``struct_mutex``: ``msm``, ``omapdrm`` and -``udl``. +fine-grained per-buffer object and per-context lockings scheme. Currently only the +``msm`` driver still use ``struct_mutex``. Contact: Daniel Vetter, respective driver maintainers @@ -190,7 +183,8 @@ Convert drivers to use simple modeset suspend/resume Most drivers (except i915 and nouveau) that use drm_atomic_helper_suspend/resume() can probably be converted to use -drm_mode_config_helper_suspend/resume(). +drm_mode_config_helper_suspend/resume(). Also there's still open-coded version +of the atomic suspend/resume code in older atomic modeset drivers. Contact: Maintainer of the driver you plan to convert @@ -246,20 +240,10 @@ Core refactorings Clean up the DRM header mess -Currently the DRM subsystem has only one global header, ``drmP.h``. This is -used both for functions exported to helper libraries and drivers and functions -only used internally in the ``drm.ko`` module. The goal would be to move all -header declarations not needed outside of ``drm.ko`` into -``drivers/gpu/drm/drm_*_internal.h`` header files. ``EXPORT_SYMBOL`` also -needs to be dropped for these functions. - -This would nicely tie in with the below task to create kerneldoc after the API -is cleaned up. Or with the "hide legacy cruft better" task. - -Note that this is well in progress, but ``drmP.h`` is still huge. The updated -plan is to switch to per-file driver API headers, which will also structure -the kerneldoc better. This should also allow more fine-grained ``#include`` -directives. +The DRM subsystem originally had only one huge globale header, ``drmP.h``. This +is not split up, but many source files still include it. The remainig part of +the cleanup work here is to replace any ``#include `` by only the +headers needed (and fixing up any missing pre-declarations in the headers). In the end no .c file should need to include ``drmP.h`` anymore. @@ -278,26 +262,6 @@ See https://dri.freedesktop.org/docs/drm/ for what's there already. Contact: Daniel Vetter -Hide legacy cruft better - - -Way back DRM supported only drivers which shadow-attached to PCI devices with -userspace or fbdev drivers setting up outputs. Modern DRM drivers take charge -of the entire device, you can spot them with the DRIVER_MODESET flag. - -Unfortunately there's still large piles of legacy code around which needs to -be hidden so that driver writers don't accidentally end up using it. And to -prevent security issues in those legacy IOCTLs from being exploited on modern -drivers. This has multiple
[PATCH 03/14] drm: drop drmP.h include from drm_plane.c
Just a bit of missing includes and pre declarations. v2: Compiles now, with drm/kernel.h extracted. Reviewed-by: Sean Paul Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_crtc_internal.h | 8 drivers/gpu/drm/drm_plane.c | 11 ++- include/drm/drm_color_mgmt.h| 1 + include/drm/drm_plane.h | 2 ++ include/drm/drm_property.h | 2 ++ 5 files changed, 23 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_crtc_internal.h b/drivers/gpu/drm/drm_crtc_internal.h index b61322763394..ff5e0d521c21 100644 --- a/drivers/gpu/drm/drm_crtc_internal.h +++ b/drivers/gpu/drm/drm_crtc_internal.h @@ -31,6 +31,14 @@ * and are not exported to drivers. */ +enum drm_mode_status; +enum drm_connector_force; + +struct drm_display_mode; +struct work_struct; +struct drm_connector; +struct drm_bridge; +struct edid; /* drm_crtc.c */ int drm_mode_crtc_set_obj_prop(struct drm_mode_object *obj, diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c index 6153cbda239f..36bf3fe9ad21 100644 --- a/drivers/gpu/drm/drm_plane.c +++ b/drivers/gpu/drm/drm_plane.c @@ -20,8 +20,17 @@ * OF THIS SOFTWARE. */ -#include +#include +#include + #include +#include +#include +#include +#include +#include +#include +#include #include "drm_crtc_internal.h" diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h index 44f04233e3db..90ef9996d9a4 100644 --- a/include/drm/drm_color_mgmt.h +++ b/include/drm/drm_color_mgmt.h @@ -24,6 +24,7 @@ #define __DRM_COLOR_MGMT_H__ #include +#include struct drm_crtc; struct drm_plane; diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h index 2af3f0a7d2e7..fe6c4aee2d08 100644 --- a/include/drm/drm_plane.h +++ b/include/drm/drm_plane.h @@ -27,6 +27,8 @@ #include #include #include +#include +#include #include struct drm_crtc; diff --git a/include/drm/drm_property.h b/include/drm/drm_property.h index c030f6ccab99..5b9efff35d6d 100644 --- a/include/drm/drm_property.h +++ b/include/drm/drm_property.h @@ -27,6 +27,8 @@ #include #include +#include + /** * struct drm_property_enum - symbolic values for enumerations * @value: numeric property value for this enum entry -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/14] drm: Add drm/kernel.h header file
We have a bunch of neat little macros all over the place which should
move to kernel.h. But some of them died in bikesheds on lkml, and we
need a decent home for them.
Start out by moving the for_each_if macro there.
Cc: Sean Paul
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_display.h| 2 ++
drivers/gpu/drm/i915/intel_ringbuffer.h | 2 ++
drivers/gpu/drm/nouveau/nouveau_connector.h | 2 ++
include/drm/drmP.h | 3 --
include/drm/drm_atomic.h| 1 +
include/drm/drm_atomic_helper.h | 1 +
include/drm/drm_connector.h | 1 +
include/drm/drm_encoder.h | 1 +
include/drm/drm_plane.h | 1 +
include/drm/kernel.h| 32 +
11 files changed, 44 insertions(+), 3 deletions(-)
create mode 100644 include/drm/kernel.h
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 14e562887307..63cd53067cc3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -52,6 +52,7 @@
#include
#include
#include
+#include
#include "i915_params.h"
#include "i915_reg.h"
diff --git a/drivers/gpu/drm/i915/intel_display.h
b/drivers/gpu/drm/i915/intel_display.h
index e20e6a36a748..bb6e8d949ebb 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -25,6 +25,8 @@
#ifndef _INTEL_DISPLAY_H_
#define _INTEL_DISPLAY_H_
+#include
+
enum i915_gpio {
GPIOA,
GPIOB,
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 3f6920dd7880..c06ec8078313 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -2,6 +2,8 @@
#ifndef _INTEL_RINGBUFFER_H_
#define _INTEL_RINGBUFFER_H_
+#include
+
#include
#include
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.h
b/drivers/gpu/drm/nouveau/nouveau_connector.h
index dc7454e7f19a..fff89cb4a792 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.h
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.h
@@ -32,6 +32,8 @@
#include
#include
#include
+#include
+
#include "nouveau_crtc.h"
#include "nouveau_encoder.h"
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index f7a19c2a7a80..05350424a4d3 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -110,7 +110,4 @@ static inline bool drm_can_sleep(void)
return true;
}
-/* helper for handling conditionals in various for_each macros */
-#define for_each_if(condition) if (!(condition)) {} else
-
#endif
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index da9d95a19580..07b4cb1c9603 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -29,6 +29,7 @@
#define DRM_ATOMIC_H_
#include
+#include
/**
* struct drm_crtc_commit - track modeset commits on a CRTC
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index f4c7ed876c97..63e736eeb516 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
struct drm_atomic_state;
struct drm_private_obj;
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 97ea41dc678f..95be147ee4db 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h
index 4f597c0730b4..9cb01c764fac 100644
--- a/include/drm/drm_encoder.h
+++ b/include/drm/drm_encoder.h
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
struct drm_encoder;
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 16f5b66684ca..2af3f0a7d2e7 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
struct drm_crtc;
struct drm_printer;
diff --git a/include/drm/kernel.h b/include/drm/kernel.h
new file mode 100644
index ..6ea220c0c132
--- /dev/null
+++ b/include/drm/kernel.h
@@ -0,0 +1,32 @@
+/*
+ * Internal Header for the Direct Rendering Manager
+ *
+ * Copyright 2018 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE
[PATCH 04/14] drm: drop drmP.h include from drm_crtc.c
This is starting to become easy! v2: Compiles now, with drm/kernel.h extracted. Reviewed-by: Sean Paul Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_crtc.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index bae43938c8f6..2f6c877299e4 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -34,7 +34,7 @@ #include #include #include -#include +#include #include #include #include @@ -42,6 +42,9 @@ #include #include #include +#include +#include +#include #include "drm_crtc_internal.h" #include "drm_internal.h" -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/14] drm/atomic: trim driver interface/docs
Remove the kerneldoc and EXPORT_SYMBOL which aren't used and really
shouldn't ever be used by drivers directly.
Unfortunately this means we need to move the set_writeback_fb function
around to avoid a forward decl.
Signed-off-by: Daniel Vetter
Cc: David Airlie
Cc: Gustavo Padovan
Cc: Maarten Lankhorst
Cc: Sean Paul
---
Documentation/gpu/drm-kms.rst | 3 -
drivers/gpu/drm/drm_atomic.c | 219 ++
include/drm/drm_atomic.h | 6 -
3 files changed, 34 insertions(+), 194 deletions(-)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index f8f5bf11a6ca..3a9dd68b97c9 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -287,9 +287,6 @@ Atomic Mode Setting Function Reference
.. kernel-doc:: drivers/gpu/drm/drm_atomic.c
:export:
-.. kernel-doc:: drivers/gpu/drm/drm_atomic.c
- :internal:
-
CRTC Abstraction
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 151dd7162b3a..29a4e6959358 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -464,30 +464,6 @@ int drm_atomic_set_mode_prop_for_crtc(struct
drm_crtc_state *state,
}
EXPORT_SYMBOL(drm_atomic_set_mode_prop_for_crtc);
-/**
- * drm_atomic_replace_property_blob_from_id - lookup the new blob and replace
the old one with it
- * @dev: DRM device
- * @blob: a pointer to the member blob to be replaced
- * @blob_id: ID of the new blob
- * @expected_size: total expected size of the blob data (in bytes)
- * @expected_elem_size: expected element size of the blob data (in bytes)
- * @replaced: did the blob get replaced?
- *
- * Replace @blob with another blob with the ID @blob_id. If @blob_id is zero
- * @blob becomes NULL.
- *
- * If @expected_size is positive the new blob length is expected to be equal
- * to @expected_size bytes. If @expected_elem_size is positive the new blob
- * length is expected to be a multiple of @expected_elem_size bytes. Otherwise
- * an error is returned.
- *
- * @replaced will indicate to the caller whether the blob was replaced or not.
- * If the old and new blobs were in fact the same blob @replaced will be false
- * otherwise it will be true.
- *
- * RETURNS:
- * Zero on success, error code on failure.
- */
static int
drm_atomic_replace_property_blob_from_id(struct drm_device *dev,
struct drm_property_blob **blob,
@@ -521,22 +497,7 @@ drm_atomic_replace_property_blob_from_id(struct drm_device
*dev,
return 0;
}
-/**
- * drm_atomic_crtc_set_property - set property on CRTC
- * @crtc: the drm CRTC to set a property on
- * @state: the state object to update with the new property value
- * @property: the property to set
- * @val: the new property value
- *
- * This function handles generic/core properties and calls out to driver's
- * _crtc_funcs.atomic_set_property for driver properties. To ensure
- * consistent behavior you must call this function rather than the driver hook
- * directly.
- *
- * RETURNS:
- * Zero on success, error code on failure
- */
-int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
+static int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
struct drm_crtc_state *state, struct drm_property *property,
uint64_t val)
{
@@ -598,23 +559,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
return 0;
}
-EXPORT_SYMBOL(drm_atomic_crtc_set_property);
-/**
- * drm_atomic_crtc_get_property - get property value from CRTC state
- * @crtc: the drm CRTC to set a property on
- * @state: the state object to get the property value from
- * @property: the property to set
- * @val: return location for the property value
- *
- * This function handles generic/core properties and calls out to driver's
- * _crtc_funcs.atomic_get_property for driver properties. To ensure
- * consistent behavior you must call this function rather than the driver hook
- * directly.
- *
- * RETURNS:
- * Zero on success, error code on failure
- */
static int
drm_atomic_crtc_get_property(struct drm_crtc *crtc,
const struct drm_crtc_state *state,
@@ -643,16 +588,6 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
return 0;
}
-/**
- * drm_atomic_crtc_check - check crtc state
- * @crtc: crtc to check
- * @state: crtc state to check
- *
- * Provides core sanity checks for crtc state.
- *
- * RETURNS:
- * Zero on success, error code on failure
- */
static int drm_atomic_crtc_check(struct drm_crtc *crtc,
struct drm_crtc_state *state)
{
@@ -728,16 +663,6 @@ static void drm_atomic_crtc_print_state(struct drm_printer
*p,
crtc->funcs->atomic_print_state(p, state);
}
-/**
- * drm_atomic_connector_check - check connector state
- * @connector: connector to check
- * @state: connector state to check
- *
- * Provides core sanity checks for connector state.
- *
- * RETURNS:
- * Zero on success, error code on
[PATCH 02/14] drm: Drop drmP.h from drm_connector.c
Only needed minimal changes in drm_internal.h (for the drm_ioctl_t type and a few forward declarations), plus a few missing includes in drm_connector.c. Yay, the last stage of the drm header cleanup can finally commence! v2: Compiles now, with drm/kernel.h extracted. Reviewed-by: Sean Paul Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_connector.c | 6 +- drivers/gpu/drm/drm_internal.h | 5 + 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index 6011d769d50b..526619f963e5 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -20,11 +20,15 @@ * OF THIS SOFTWARE. */ -#include #include #include #include #include +#include +#include +#include + +#include #include "drm_crtc_internal.h" #include "drm_internal.h" diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h index 40179c5fc6b8..0c4eb4a9ab31 100644 --- a/drivers/gpu/drm/drm_internal.h +++ b/drivers/gpu/drm/drm_internal.h @@ -21,9 +21,14 @@ * OTHER DEALINGS IN THE SOFTWARE. */ +#include + #define DRM_IF_MAJOR 1 #define DRM_IF_MINOR 4 +struct drm_prime_file_private; +struct dma_buf; + /* drm_file.c */ extern struct mutex drm_global_mutex; struct drm_file *drm_file_alloc(struct drm_minor *minor); -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] fbdev: Add FBINFO_HIDE_SMEM_START flag
On Wed, Aug 22, 2018 at 10:54:04AM +0200, Daniel Vetter wrote:
> DRM drivers really, really, really don't want random userspace to
> share buffer behind it's back, bypassing the dma-buf buffer sharing
> machanism. For that reason we've ruthlessly rejected any IOCTL
> exposing the physical address of any graphics buffer.
>
> Unfortunately fbdev comes with that built-in. We could just set
> smem_start to 0, but that means we'd have to hand-roll our own fb_mmap
> implementation. For good reasons many drivers do that, but
> smem_start/length is still super convenient.
>
> Hence instead just stop the leak in the ioctl, to keep fb mmap working
> as-is. A second patch will set this flag for all drm drivers.
>
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Kees Cook
> Cc: Daniel Vetter
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: Daniel Vetter
Any comments from the fbdev side on this?
-Daniel
> ---
> drivers/video/fbdev/core/fbmem.c | 4
> include/linux/fb.h | 7 +++
> 2 files changed, 11 insertions(+)
>
> diff --git a/drivers/video/fbdev/core/fbmem.c
> b/drivers/video/fbdev/core/fbmem.c
> index 609438d2465b..549d0f86fcf3 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1116,6 +1116,8 @@ static long do_fb_ioctl(struct fb_info *info, unsigned
> int cmd,
> if (!lock_fb_info(info))
> return -ENODEV;
> fix = info->fix;
> + if (info->flags & FBINFO_HIDE_SMEM_START)
> + fix.smem_start = 0;
> unlock_fb_info(info);
>
> ret = copy_to_user(argp, , sizeof(fix)) ? -EFAULT : 0;
> @@ -1326,6 +1328,8 @@ static int fb_get_fscreeninfo(struct fb_info *info,
> unsigned int cmd,
> if (!lock_fb_info(info))
> return -ENODEV;
> fix = info->fix;
> + if (info->flags & FBINFO_HIDE_SMEM_START)
> + fix.smem_start = 0;
> unlock_fb_info(info);
> return do_fscreeninfo_to_user(, compat_ptr(arg));
> }
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index fa8c6f9c9c3a..f42b09ca71f8 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -456,6 +456,13 @@ struct fb_tile_ops {
> * and host endianness. Drivers should not use this flag.
> */
> #define FBINFO_BE_MATH 0x10
> +/*
> + * Hide smem_start in the FBIOGET_FSCREENINFO IOCTL. This is used by modern
> DRM
> + * drivers to stop userspace from trying to share buffers behind the kernel's
> + * back. Instead dma-buf based buffer sharing should be used.
> + */
> +#define FBINFO_HIDE_SMEM_START 0x20
> +
>
> struct fb_info {
> atomic_t count;
> --
> 2.18.0
>
--
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/5] drm: fix drm_mode_addfb() on big endian machines.
On Mon, Sep 03, 2018 at 12:57:54PM +0200, Gerd Hoffmann wrote:
> Userspace on big endian machhines typically expects the ADDFB ioctl
> returns a big endian framebuffer. drm_mode_addfb() will call
> drm_mode_addfb2() unconditionally with little endian DRM_FORMAT_*
> values though, which is wrong. This patch fixes that.
>
> Drivers (both kernel and xorg) have quirks in place to deal with the
> broken drm_mode_addfb() behavior. Because of this we can't just change
> drm_mode_addfb() behavior for everybody without breaking things. So add
> a new driver feature flag DRIVER_PREFER_HOST_BYTE_ORDER, so drivers can
> opt-in.
>
> Signed-off-by: Gerd Hoffmann
> ---
> include/drm/drm_drv.h | 1 +
> drivers/gpu/drm/drm_framebuffer.c | 11 +++
> 2 files changed, 12 insertions(+)
>
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index 46a8009784..9cf12596cd 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -57,6 +57,7 @@ struct drm_printer;
> #define DRIVER_KMS_LEGACY_CONTEXT0x2
> #define DRIVER_SYNCOBJ 0x4
> #define DRIVER_PREFER_XBGR_30BPP0x8
> +#define DRIVER_PREFER_HOST_BYTE_ORDER 0x10
Hm, not a huge fan of using driver_flags for random little quirks. I think
a boolean in sturct drm_mode_config would be much better. Bonus if you
also move the 30bpp hack over to that. Something like
mode_config.quirk_addfb_host_byte_order and
mode_config.quirk_addfb_prefer_xbgr_30bpp or whatever. That has the upside
of giving us a really nice place to put a huge comment about what this is
supposed to do.
I think otherwise this looks overall rather reasonable. I think the only
other driver that ever cared about big endian was radeon/amdgpu. Would be
good to get at least an ack from amd folks, or a "meh, stopped caring".
-Daniel
>
> /**
> * struct drm_driver - DRM driver structure
> diff --git a/drivers/gpu/drm/drm_framebuffer.c
> b/drivers/gpu/drm/drm_framebuffer.c
> index 88758096d5..ccbda8a2e9 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -124,6 +124,17 @@ int drm_mode_addfb(struct drm_device *dev, struct
> drm_mode_fb_cmd *or,
> dev->driver->driver_features & DRIVER_PREFER_XBGR_30BPP)
> r.pixel_format = DRM_FORMAT_XBGR2101010;
>
> + if (dev->driver->driver_features & DRIVER_PREFER_HOST_BYTE_ORDER) {
> + if (r.pixel_format == DRM_FORMAT_XRGB)
> + r.pixel_format = DRM_FORMAT_HOST_XRGB;
> + if (r.pixel_format == DRM_FORMAT_ARGB)
> + r.pixel_format = DRM_FORMAT_HOST_ARGB;
> + if (r.pixel_format == DRM_FORMAT_RGB565)
> + r.pixel_format = DRM_FORMAT_HOST_RGB565;
> + if (r.pixel_format == DRM_FORMAT_XRGB1555)
> + r.pixel_format = DRM_FORMAT_HOST_XRGB1555;
> + }
> +
> ret = drm_mode_addfb2(dev, , file_priv);
> if (ret)
> return ret;
> --
> 2.9.3
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Remove "protection" around drm_vma_offset_manager_destroy()
On Mon, Sep 03, 2018 at 10:31:55AM +0100, Chris Wilson wrote:
> Using a spinlock to serialize the destroy function, within the destroy
> function itself does not prevent the buggy driver from shooting
> themselves in the foot - either way they still have a use-after-free
> issue.
>
> Reported-by: Jia-Ju Bai
> Signed-off-by: Chris Wilson
> Cc: Davidlohr Bueso
> Cc: Liviu Dudau
> Cc: Daniel Vetter
Ah, now I understand a bit more ...
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_vma_manager.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_vma_manager.c
> b/drivers/gpu/drm/drm_vma_manager.c
> index a6b2fe36b025..c5d0d2358301 100644
> --- a/drivers/gpu/drm/drm_vma_manager.c
> +++ b/drivers/gpu/drm/drm_vma_manager.c
> @@ -103,10 +103,7 @@ EXPORT_SYMBOL(drm_vma_offset_manager_init);
> */
> void drm_vma_offset_manager_destroy(struct drm_vma_offset_manager *mgr)
> {
> - /* take the lock to protect against buggy drivers */
> - write_lock(>vm_lock);
> drm_mm_takedown(>vm_addr_space_mm);
> - write_unlock(>vm_lock);
> }
> EXPORT_SYMBOL(drm_vma_offset_manager_destroy);
>
> --
> 2.19.0.rc1
>
--
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 libdrm] libdrm: Allow dynamic drm majors on linux
On Mon, Sep 03, 2018 at 11:16:29AM +0200, Thomas Hellstrom wrote: > On 08/31/2018 05:30 PM, Thomas Hellstrom wrote: > > On 08/31/2018 05:27 PM, Emil Velikov wrote: > > > On 31 August 2018 at 15:38, Michel Dänzer wrote: > > > > [ Adding the amd-gfx list ] > > > > > > > > On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote: > > > > > On 08/31/2018 02:30 PM, Emil Velikov wrote: > > > > > > On 31 August 2018 at 12:54, Thomas Hellstrom > > > > > > wrote: > > > > > > > To determine whether a device node is a drm device > > > > > > > node or not, the code > > > > > > > currently compares the node's major number to the static drm major > > > > > > > device > > > > > > > number. > > > > > > > > > > > > > > This breaks the standalone vmwgfx driver on XWayland dri clients, > > > > > > > > > > > > > Any particular reason why the code doesn't use a fixed node there? > > > > > > It will make the diff vs the in-kernel driver a bit smaller. > > > > > Because then it won't be able to interoperate with other in-tree > > > > > drivers, like virtual drm drivers or passthrough usb drm drivers. > > > > > There is no clean way to share the minor number allocation > > > > > with in-tree > > > > > drm, so standalone vmwgfx is using dynamic major allocation. > > > > I wonder why I haven't heard of any of these issues with the standalone > > > > version of amdgpu shipped in packaged AMD releases. Does that > > > > also use a > > > > different major number? If yes, maybe it's just that nobody has tried > > > > Xwayland clients with that driver. If no, how does it avoid the other > > > > issues described above? > > > > > > > AFAICT, the difference is that the standalone vmwgfx uses an internal > > > copy of drm core. > > > It doesn't reuse the in-kernel drm, hence it cannot know which minor > > > it can use. > > > > > > -Emil > > > > Actually, standalone vmwgfx could perhaps also try to allocate minors > > from 63 and downwards. That might work, but needs some verification. > > > > So unfortuntately this doesn't work since the in-tree drm's file operations > are registered with the DRM_MAJOR. > So I still think the patch is the way to go. If people are concerned that > also fbdev file descriptors are allowed, perhaps there are other sysfs > traits we can look at? Somewhat out of curiosity, but why do you have to overwrite all of drm? amdgpu seems to be able to pull their stunt off without ... -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 v3 00/13] remove_conflicting_framebuffers() cleanup
On Mon, Sep 03, 2018 at 01:31:34PM +0200, Bartlomiej Zolnierkiewicz wrote: > On Monday, September 03, 2018 09:43:15 AM Daniel Vetter wrote: > > On Sat, Sep 01, 2018 at 04:08:41PM +0200, Michał Mirosław wrote: > > > This series cleans up duplicated code for replacing firmware FB > > > driver with proper DRI driver and adds handover support to > > > Tegra driver. > > > > > > This is a sligtly updated version of a series sent on 24 Nov 2017. > > > > > > --- > > > v2: > > > - rebased on current drm-next > > > - dropped staging/sm750fb changes > > > - added kernel docs for DRM helpers > > > v3: > > > - move kerneldoc to fbdev, where functions are implemented > > > - split kerneldoc for remove_conflicting_framebuffers() > > > > Ah, that's not quite what I had in mind. I think having the docs (also) in > > the drm helpers would be good, since that's where drm people will look, > > and that's the function they'll call. I just wanted you to split the fbdev > > and drm parts into 2 patches (since those are two different maintainers). > > > > Anyway, this is ok too, so imo ready for merging. If you can resurrect the > > drm docs (with a patch title of "drm/fb-helper: document fbdev remove > > functions" or similar) that would be great. > > > > Only thing we need for merging now is the ack from Bartlomiej. > > For the whole patchset: > > Acked-by: Bartlomiej Zolnierkiewicz Thanks, entire patch set applied to drm-misc-next for 4.20. -Daniel > > > -Daniel > > > > > - propagate return value in remove_conflicting_pci_framebuffers() > > > > > > --- > > > Michał Mirosław (13): > > > fbdev: show fbdev number for debugging > > > fbdev: allow apertures == NULL in remove_conflicting_framebuffers() > > > fbdev: add kerneldoc do remove_conflicting_framebuffers() > > > fbdev: add remove_conflicting_pci_framebuffers() > > > drm/amdgpu: use simpler remove_conflicting_pci_framebuffers() > > > drm/bochs: use simpler remove_conflicting_pci_framebuffers() > > > drm/cirrus: use simpler remove_conflicting_pci_framebuffers() > > > drm/mgag200: use simpler remove_conflicting_pci_framebuffers() > > > drm/radeon: use simpler remove_conflicting_pci_framebuffers() > > > drm/virtio: use simpler remove_conflicting_pci_framebuffers() > > > drm/vc4: use simpler remove_conflicting_framebuffers(NULL) > > > drm/sun4i: use simpler remove_conflicting_framebuffers(NULL) > > > drm/tegra: kick out simplefb > > > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 24 + > > > drivers/gpu/drm/bochs/bochs_drv.c| 18 +-- > > > drivers/gpu/drm/cirrus/cirrus_drv.c | 23 + > > > drivers/gpu/drm/mgag200/mgag200_drv.c| 21 +--- > > > drivers/gpu/drm/mgag200/mgag200_main.c | 9 > > > drivers/gpu/drm/radeon/radeon_drv.c | 23 + > > > drivers/gpu/drm/sun4i/sun4i_drv.c| 18 +-- > > > drivers/gpu/drm/tegra/drm.c | 4 ++ > > > drivers/gpu/drm/vc4/vc4_drv.c| 20 +--- > > > drivers/gpu/drm/virtio/virtgpu_drm_bus.c | 24 ++--- > > > drivers/video/fbdev/core/fbmem.c | 63 +++- > > > include/drm/drm_fb_helper.h | 12 + > > > include/linux/fb.h | 2 + > > > 13 files changed, 89 insertions(+), 172 deletions(-) > > Best regards, > -- > Bartlomiej Zolnierkiewicz > Samsung R Institute Poland > Samsung Electronics > -- 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 v3 04/13] fbdev: add remove_conflicting_pci_framebuffers()
On Sat, Sep 01, 2018 at 04:08:45PM +0200, Michał Mirosław wrote:
> Almost all PCI drivers using remove_conflicting_framebuffers() wrap it
> with the same code.
>
> ---
This cuts away the sob. Just fyi.
-Daniel
> v2: add kerneldoc for DRM helper
> v3: propagate remove_conflicting_framebuffers() return value
> + move kerneldoc to where function is implemented
>
> Signed-off-by: Michał Mirosław
> ---
> drivers/video/fbdev/core/fbmem.c | 35
> include/drm/drm_fb_helper.h | 12 +++
> include/linux/fb.h | 2 ++
> 3 files changed, 49 insertions(+)
>
> diff --git a/drivers/video/fbdev/core/fbmem.c
> b/drivers/video/fbdev/core/fbmem.c
> index 2de93b5014e3..cd96b1c62bbe 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -34,6 +34,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -1812,6 +1813,40 @@ int remove_conflicting_framebuffers(struct
> apertures_struct *a,
> }
> EXPORT_SYMBOL(remove_conflicting_framebuffers);
>
> +/**
> + * remove_conflicting_pci_framebuffers - remove firmware-configured
> framebuffers for PCI devices
> + * @pdev: PCI device
> + * @resource_id: index of PCI BAR configuring framebuffer memory
> + * @name: requesting driver name
> + *
> + * This function removes framebuffer devices (eg. initialized by firmware)
> + * using memory range configured for @pdev's BAR @resource_id.
> + *
> + * The function assumes that PCI device with shadowed ROM drives a primary
> + * display and so kicks out vga16fb.
> + */
> +int remove_conflicting_pci_framebuffers(struct pci_dev *pdev, int res_id,
> const char *name)
> +{
> + struct apertures_struct *ap;
> + bool primary = false;
> + int err;
> +
> + ap = alloc_apertures(1);
> + if (!ap)
> + return -ENOMEM;
> +
> + ap->ranges[0].base = pci_resource_start(pdev, res_id);
> + ap->ranges[0].size = pci_resource_len(pdev, res_id);
> +#ifdef CONFIG_X86
> + primary = pdev->resource[PCI_ROM_RESOURCE].flags &
> + IORESOURCE_ROM_SHADOW;
> +#endif
> + err = remove_conflicting_framebuffers(ap, name, primary);
> + kfree(ap);
> + return err;
> +}
> +EXPORT_SYMBOL(remove_conflicting_pci_framebuffers);
> +
> /**
> * register_framebuffer - registers a frame buffer device
> * @fb_info: frame buffer info structure
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index b069433e7fc1..20ea856db900 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -577,4 +577,16 @@ drm_fb_helper_remove_conflicting_framebuffers(struct
> apertures_struct *a,
> #endif
> }
>
> +static inline int
> +drm_fb_helper_remove_conflicting_pci_framebuffers(struct pci_dev *pdev,
> + int resource_id,
> + const char *name)
> +{
> +#if IS_REACHABLE(CONFIG_FB)
> + return remove_conflicting_pci_framebuffers(pdev, resource_id, name);
> +#else
> + return 0;
> +#endif
> +}
> +
> #endif
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index aa74a228bb92..abeffd55b66a 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -632,6 +632,8 @@ extern ssize_t fb_sys_write(struct fb_info *info, const
> char __user *buf,
> extern int register_framebuffer(struct fb_info *fb_info);
> extern int unregister_framebuffer(struct fb_info *fb_info);
> extern int unlink_framebuffer(struct fb_info *fb_info);
> +extern int remove_conflicting_pci_framebuffers(struct pci_dev *pdev, int
> res_id,
> +const char *name);
> extern int remove_conflicting_framebuffers(struct apertures_struct *a,
> const char *name, bool primary);
> extern int fb_prepare_logo(struct fb_info *fb_info, int rotate);
> --
> 2.18.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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 107781] amdgpu hangs on resume on Lenovo A475
https://bugs.freedesktop.org/show_bug.cgi?id=107781 --- Comment #5 from Michel Dänzer --- Any chance you can try if the problem also occurs with an upstream 4.17 or 4.18 kernel? -- 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: [REGRESSION] boot-screen override by "34db50e55656 efifb: Copy the ACPI BGRT"
Hey
On Mon, Sep 3, 2018 at 4:47 PM Hans de Goede wrote:
>
> Hi,
>
> On 03-09-18 16:16, Bartlomiej Zolnierkiewicz wrote:
> >
> > Hi,
> >
> > On Monday, September 03, 2018 03:23:38 PM David Herrmann wrote:
> >> Hey
> >>
> >> Since this commit:
> >>
> >> 34db50e55656 efifb: Copy the ACPI BGRT
> >>
> >> the kernel will override boot-splashs unasked. This breaks the
> >> graphical boot-process on our setups. In particular, we have a setup
> >> where an efi-boot-entry draws the early boot-splash on-screen, then
> >> hands-over to the linux-kernel + initrd. The boot-splash daemon in the
> >> initrd then takes over control of possible animations.
> >>
> >> With the mentioned commit compiled in, the kernel will redraw the
> >> firmware logo on screen at a random time without any way to intervene.
> >
> > You have CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER=y (the deferred
> > console takeover support introduced in v4,19-rc1). I assume that this
> > is intended?
> >
> >> What is the intention of this commit? Why is the kernel re-drawing the
> >> firmware logo unasked? If someone during the boot-process draws
> >> content on the screen, I would prefer if the kernel does not clear
> >> that on driver load.
> >
> > +/*
> > + * If fbcon deffered console takeover is configured, the intent is for the
> > + * framebuffer to show the boot graphics (e.g. vendor logo) until there is
> > some
> > + * (error) message to display. But the boot graphics may have been
> > destroyed by
> > + * e.g. option ROM output, detect this and restore the boot graphics.
> > + */
> > +#if defined CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER && \
> > +defined CONFIG_ACPI_BGRT
> > ...
> > +static void efifb_show_boot_graphics(struct fb_info *info)
> > ...
> > +#else
> > +static inline void efifb_show_boot_graphics(struct fb_info *info) {}
> > +#endif
> >
> >> Can we either provide an option to disable this feature, or revert the
> >> commit?
> >
> > Hans?
>
> We use the ACPI bgrt extension to get the logo to draw and then
> draw it since some devices rely on the OS to draw it and otherwise we
> just end up with a blackscreen when doing silent / flickerfree boot.
>
> Ideally you would be able to get your vendor to put the logo in firmware
> in the ACPI bgrt extension, then you also do not need to play any tricks
> with an EFI binary drawing your own logo. But I can understand if you don't
> have control over this, so you need to do this with the EFI binary trick.
>
> I can also understand that you want to use deferred console takeover
> in a setup like yours to avoid fbcon messing up what is on the display
> during boot, that is exactly what it is for. So I think a reasonable
> approach here is to add a kernel commandline option, say:
>
> video=efifb:nobgrt
>
> David, would that work for you?
That would be perfect!
Thanks
David
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107784] [AMD tahiti XT] displayport broken
https://bugs.freedesktop.org/show_bug.cgi?id=107784 --- Comment #4 from Sylvain BERTRAND --- I did a manual bisection and got lucky: faulty commit: 019cddc88f9e4ae0de2c76802f7137210c2101aa on amd-staging-drm-next this commit is i2c related, right before the commit 5e8704ac1cfa9fceef94fcc457e18613b1589b34 which is the drm-next commit. -- 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: [REGRESSION] boot-screen override by "34db50e55656 efifb: Copy the ACPI BGRT"
Hi,
On 03-09-18 16:16, Bartlomiej Zolnierkiewicz wrote:
Hi,
On Monday, September 03, 2018 03:23:38 PM David Herrmann wrote:
Hey
Since this commit:
34db50e55656 efifb: Copy the ACPI BGRT
the kernel will override boot-splashs unasked. This breaks the
graphical boot-process on our setups. In particular, we have a setup
where an efi-boot-entry draws the early boot-splash on-screen, then
hands-over to the linux-kernel + initrd. The boot-splash daemon in the
initrd then takes over control of possible animations.
With the mentioned commit compiled in, the kernel will redraw the
firmware logo on screen at a random time without any way to intervene.
You have CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER=y (the deferred
console takeover support introduced in v4,19-rc1). I assume that this
is intended?
What is the intention of this commit? Why is the kernel re-drawing the
firmware logo unasked? If someone during the boot-process draws
content on the screen, I would prefer if the kernel does not clear
that on driver load.
+/*
+ * If fbcon deffered console takeover is configured, the intent is for the
+ * framebuffer to show the boot graphics (e.g. vendor logo) until there is some
+ * (error) message to display. But the boot graphics may have been destroyed by
+ * e.g. option ROM output, detect this and restore the boot graphics.
+ */
+#if defined CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER && \
+defined CONFIG_ACPI_BGRT
...
+static void efifb_show_boot_graphics(struct fb_info *info)
...
+#else
+static inline void efifb_show_boot_graphics(struct fb_info *info) {}
+#endif
Can we either provide an option to disable this feature, or revert the commit?
Hans?
We use the ACPI bgrt extension to get the logo to draw and then
draw it since some devices rely on the OS to draw it and otherwise we
just end up with a blackscreen when doing silent / flickerfree boot.
Ideally you would be able to get your vendor to put the logo in firmware
in the ACPI bgrt extension, then you also do not need to play any tricks
with an EFI binary drawing your own logo. But I can understand if you don't
have control over this, so you need to do this with the EFI binary trick.
I can also understand that you want to use deferred console takeover
in a setup like yours to avoid fbcon messing up what is on the display
during boot, that is exactly what it is for. So I think a reasonable
approach here is to add a kernel commandline option, say:
video=efifb:nobgrt
David, would that work for you?
Regards,
Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] drm: Add library for shmem backed GEM objects
Den 02.09.2018 22.56, skrev Sam Ravnborg:
Hi Noralf.
Only nitpicks, I have not the background
to review the actual implmentation.
So no tags from me to put on the commit.
Sam
+/**
+ * drm_gem_shmem_create - Allocate an object with the given size
+ * @dev: DRM device
+ * @size: Size of the object to allocate
+ *
+ * This function creates a shmem GEM object. The default cache mode is
+ * DRM_GEM_SHMEM_BO_CACHED. The _driver->gem_create_object callback can be
+ * used override this.
used to override this.
^^
+ *
+ * Returns:
+ * A struct drm_gem_shmem_object * on success or an ERR_PTR()-encoded negative
+ * error code on failure.
+ */
+struct drm_gem_shmem_object *drm_gem_shmem_create(struct drm_device *dev,
size_t size)
+{
+ struct drm_gem_shmem_object *shmem;
+ struct drm_gem_object *obj;
+ int ret;
+
+ size = PAGE_ALIGN(size);
+
+ if (dev->driver->gem_create_object)
+ obj = dev->driver->gem_create_object(dev, size);
+ else
+ obj = kzalloc(sizeof(*shmem), GFP_KERNEL);
+ if (!obj)
+ return ERR_PTR(-ENOMEM);
+
+ shmem = to_drm_gem_shmem_obj(obj);
+
+ if (!dev->driver->gem_create_object)
+ shmem->cache_mode = DRM_GEM_SHMEM_BO_CACHED;
+
+ ret = drm_gem_object_init(dev, obj, size);
+ if (ret)
+ goto err_free;
Some users of drm_gem_object_init() calls drm_gem_object_put_unlocked(obj)
when there is an error. Others call kfree() liek in this case.
I could also have done that if I initialized the mutexes earlier to match
up with the destroy in *_free_object. But it doesn't buy me anything,
so I prefer to stay with how the majority does it.
I really like to use Elixir when tracking down how drivers use the
various DRM functions:
https://elixir.bootlin.com/linux/latest/ident/drm_gem_object_init
+
+ ret = drm_gem_create_mmap_offset(obj);
+ if (ret)
+ goto err_release;
+
+ mutex_init(>pages_lock);
+ mutex_init(>vmap_lock);
+
+ return shmem;
+
+err_release:
+ drm_gem_object_release(obj);
+err_free:
+ kfree(shmem);
+
+ return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(drm_gem_shmem_create);
+
+
+static int drm_gem_shmem_get_pages_locked(struct drm_gem_shmem_object *shmem)
+{
+ struct drm_gem_object *obj = >base;
+ struct page **pages;
+
+ if (shmem->pages_use_count++ > 0)
+ return 0;
+
+ pages = drm_gem_get_pages(obj);
+ if (IS_ERR(pages)) {
+ DRM_DEBUG_KMS("Failed to get pages (%ld)\n", PTR_ERR(pages));
+ shmem->pages_use_count = 0;
+ return PTR_ERR(pages);
+ }
+
+ shmem->pages = pages;
+
+ return 0;
+}
+
+/*
+ * drm_gem_shmem_get_pages - Allocate backing pages for a shmem GEM object
+ * @shmem: shmem GEM object
+ *
+ * This function makes sure that backing pages exists for the shmem GEM object
+ * and increases the use count.
+ *
+ * Returns:
+ * 0 on success or a negative error code on failure.
+ */
+int drm_gem_shmem_get_pages(struct drm_gem_shmem_object *shmem)
+{
+ int ret;
+
+ ret = mutex_lock_interruptible(>pages_lock);
+ if (ret)
+ return ret;
+ ret = drm_gem_shmem_get_pages_locked(shmem);
+ mutex_unlock(>pages_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL(drm_gem_shmem_get_pages);
+
The functions is named *_unlocked, but called with a lock held.
Inconsistent?
Indeed it is.
Thanks,
Noralf
+static void drm_gem_shmem_put_pages_unlocked(struct drm_gem_shmem_object
*shmem)
+{
+ struct drm_gem_object *obj = >base;
+
+ if (WARN_ON_ONCE(!shmem->pages_use_count))
+ return;
+
+ if (--shmem->pages_use_count > 0)
+ return;
+
+ drm_gem_put_pages(obj, shmem->pages,
+ shmem->pages_mark_dirty_on_put,
+ shmem->pages_mark_accessed_on_put);
+ shmem->pages = NULL;
+}
+
+/*
+ * drm_gem_shmem_put_pages - Decrease use count on the backing pages for a
shmem GEM object
+ * @shmem: shmem GEM object
+ *
+ * This function decreases the use count and puts the backing pages when use
drops to zero.
+ */
+void drm_gem_shmem_put_pages(struct drm_gem_shmem_object *shmem)
+{
+ mutex_lock(>pages_lock);
+ drm_gem_shmem_put_pages_unlocked(shmem);
+ mutex_unlock(>pages_lock);
+}
+EXPORT_SYMBOL(drm_gem_shmem_put_pages);
+
+static int drm_gem_shmem_vmap_locked(struct drm_gem_shmem_object *shmem)
+{
+ struct drm_gem_object *obj = >base;
+ int ret;
+
+ if (shmem->vmap_use_count++ > 0)
+ return 0;
+
+ ret = drm_gem_shmem_get_pages(shmem);
+ if (ret)
+ goto err_zero_use;
+
+ if (obj->import_attach) {
+ shmem->vaddr = dma_buf_vmap(obj->import_attach->dmabuf);
+ } else {
+ pgprot_t prot;
+
+ switch (shmem->cache_mode) {
+ case
Re: [REGRESSION] boot-screen override by "34db50e55656 efifb: Copy the ACPI BGRT"
Hi,
On Monday, September 03, 2018 03:23:38 PM David Herrmann wrote:
> Hey
>
> Since this commit:
>
> 34db50e55656 efifb: Copy the ACPI BGRT
>
> the kernel will override boot-splashs unasked. This breaks the
> graphical boot-process on our setups. In particular, we have a setup
> where an efi-boot-entry draws the early boot-splash on-screen, then
> hands-over to the linux-kernel + initrd. The boot-splash daemon in the
> initrd then takes over control of possible animations.
>
> With the mentioned commit compiled in, the kernel will redraw the
> firmware logo on screen at a random time without any way to intervene.
You have CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER=y (the deferred
console takeover support introduced in v4,19-rc1). I assume that this
is intended?
> What is the intention of this commit? Why is the kernel re-drawing the
> firmware logo unasked? If someone during the boot-process draws
> content on the screen, I would prefer if the kernel does not clear
> that on driver load.
+/*
+ * If fbcon deffered console takeover is configured, the intent is for the
+ * framebuffer to show the boot graphics (e.g. vendor logo) until there is some
+ * (error) message to display. But the boot graphics may have been destroyed by
+ * e.g. option ROM output, detect this and restore the boot graphics.
+ */
+#if defined CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER && \
+defined CONFIG_ACPI_BGRT
...
+static void efifb_show_boot_graphics(struct fb_info *info)
...
+#else
+static inline void efifb_show_boot_graphics(struct fb_info *info) {}
+#endif
> Can we either provide an option to disable this feature, or revert the commit?
Hans?
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200621] Freezing with amdgpu driver
https://bugzilla.kernel.org/show_bug.cgi?id=200621 --- Comment #10 from Jon (jon...@gmail.com) --- Upgraded to 4.18.5 and have been running that since 8/29. I've had the same amount of freezing, but no more errors in the journal. This morning it was a complete freeze while using Firefox. Nothing of interest in the logs that I could find. The last message prior to freeze this time was dnf-automatic attempting to update the cache, so I went ahead and disabled that to test. I checked the log during previous freezes and this wasn't present, so I doubt it will be the culprit. Not sure how to troubleshoot further. I've run memtest and stress-ng and cannot replicate the problem. No freezing or errors reported by memtest. CPU temperatures seem good (Tdie is 28C idle and 42C under load). This time it froze completely, mouse wouldn't move, numlock light stuck on, audio was playing and started producing garbled output until I pressed the reset switch on the pc. -- 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
[PATCH] locking: Fix mutex debug call and ww_mutex doc
Commit 08295b3b5bee ("Implement an algorithm choice for Wound-Wait
mutexes") introduced a reference in the documentation to a function
that was removed in an earlier commit.
It also forgot to remove a call to debug_mutex_add_waiter() which is now
unconditionally called by __mutex_add_waiter().
Fix those issues.
Fixes: 08295b3b5bee ("Implement an algorithm choice for Wound-Wait mutexes")
Signed-off-by: Thomas Hellstrom
---
kernel/locking/mutex.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index 1a81a1257b3f..3f8a35104285 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -389,7 +389,7 @@ static bool __ww_mutex_wound(struct mutex *lock,
/*
* wake_up_process() paired with set_current_state()
* inserts sufficient barriers to make sure @owner either sees
-* it's wounded in __ww_mutex_lock_check_stamp() or has a
+* it's wounded in __ww_mutex_check_kill() or has a
* wakeup pending to re-read the wounded state.
*/
if (owner != current)
@@ -946,7 +946,6 @@ __mutex_lock_common(struct mutex *lock, long state,
unsigned int subclass,
}
debug_mutex_lock_common(lock, );
- debug_mutex_add_waiter(lock, , current);
lock_contended(>dep_map, ip);
--
2.18.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: stm: implement get_scanout_position function
Hardware allow to read the position in scanout buffer so
we can use this information to make wait of vblank more accurate.
Active area bounds (start, end, total height) have already been
computed and written in ltdc registers, read them and get the
current line position to compute vpos value.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/stm/drv.c | 2 ++
drivers/gpu/drm/stm/ltdc.c | 45 +
drivers/gpu/drm/stm/ltdc.h | 5 +
3 files changed, 52 insertions(+)
diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
index 8698e08313e1..ac53383350e3 100644
--- a/drivers/gpu/drm/stm/drv.c
+++ b/drivers/gpu/drm/stm/drv.c
@@ -72,6 +72,8 @@ static struct drm_driver drv_driver = {
.gem_prime_vmap = drm_gem_cma_prime_vmap,
.gem_prime_vunmap = drm_gem_cma_prime_vunmap,
.gem_prime_mmap = drm_gem_cma_prime_mmap,
+ .get_scanout_position = ltdc_crtc_scanoutpos,
+ .get_vblank_timestamp = drm_calc_vbltimestamp_from_scanoutpos,
};
static int drv_load(struct drm_device *ddev)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index d997a6014d6c..05b714673042 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -148,6 +148,8 @@
#define IER_TERRIE BIT(2) /* Transfer ERRor Interrupt Enable */
#define IER_RRIE BIT(3) /* Register Reload Interrupt enable */
+#define CPSR_CYPOS GENMASK(15, 0) /* Current Y position */
+
#define ISR_LIFBIT(0) /* Line Interrupt Flag */
#define ISR_FUIF BIT(1) /* Fifo Underrun Interrupt Flag */
#define ISR_TERRIF BIT(2) /* Transfer ERRor Interrupt Flag */
@@ -622,6 +624,49 @@ static void ltdc_crtc_disable_vblank(struct drm_crtc *crtc)
reg_clear(ldev->regs, LTDC_IER, IER_LIE);
}
+bool ltdc_crtc_scanoutpos(struct drm_device *ddev, unsigned int pipe,
+ bool in_vblank_irq, int *vpos, int *hpos,
+ ktime_t *stime, ktime_t *etime,
+ const struct drm_display_mode *mode)
+{
+ struct ltdc_device *ldev = ddev->dev_private;
+ int line, vactive_start, vactive_end, vtotal;
+
+ if (stime)
+ *stime = ktime_get();
+
+ /* The active area starts after vsync + front porch and ends
+* at vsync + front porc + display size.
+* The total height also include back porch.
+* We have 3 possible cases to handle:
+* - line < vactive_start: vpos = line - vactive_start and will be
+* negative
+* - vactive_start < line < vactive_end: vpos = line - vactive_start
+* and will be positive
+* - line > vactive_end: vpos = line - vtotal - vactive_start
+* and will negative
+*
+* Computation for the two first cases are identical so we can
+* simplify the code and only test if line > vactive_end
+*/
+ line = reg_read(ldev->regs, LTDC_CPSR) & CPSR_CYPOS;
+ vactive_start = reg_read(ldev->regs, LTDC_BPCR) & BPCR_AVBP;
+ vactive_end = reg_read(ldev->regs, LTDC_AWCR) & AWCR_AAH;
+ vtotal = reg_read(ldev->regs, LTDC_TWCR) & TWCR_TOTALH;
+
+ if (line > vactive_end)
+ *vpos = line - vtotal - vactive_start;
+ else
+ *vpos = line - vactive_start;
+
+ *hpos = 0;
+
+ if (etime)
+ *etime = ktime_get();
+
+ return true;
+}
+
static const struct drm_crtc_funcs ltdc_crtc_funcs = {
.destroy = drm_crtc_cleanup,
.set_config = drm_atomic_helper_set_config,
diff --git a/drivers/gpu/drm/stm/ltdc.h b/drivers/gpu/drm/stm/ltdc.h
index 1e16d6afb0d2..b8c5cc41e17a 100644
--- a/drivers/gpu/drm/stm/ltdc.h
+++ b/drivers/gpu/drm/stm/ltdc.h
@@ -37,6 +37,11 @@ struct ltdc_device {
struct fps_info plane_fpsi[LTDC_MAX_LAYER];
};
+bool ltdc_crtc_scanoutpos(struct drm_device *dev, unsigned int pipe,
+ bool in_vblank_irq, int *vpos, int *hpos,
+ ktime_t *stime, ktime_t *etime,
+ const struct drm_display_mode *mode);
+
int ltdc_load(struct drm_device *ddev);
void ltdc_unload(struct drm_device *ddev);
--
2.15.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] omapdrm changes for v4.20
Hi Dave, Please pull omapdrm changes for v4.20. I'm sending these early to get as much linux-next time as possible. We may get some more patches later in the -rc cycle, but this pull request should be the bulk of the changes. Tomi The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git tags/omapdrm-4.20 for you to fetch changes up to 6ea48430952323091194100d48c5610b9cd286b4: drm/omap: Don't call .set_timings() operation recursively (2018-09-03 16:13:30 +0300) omapdrm changes for v4.20 Big amount of changes from Laurent, reworking the driver towards the model used by the other DRM drivers by reverting the direction of many of the operations on the display pipeline. The aim of this work is to allow omapdrm to use the common DRM panels and bridges. Not all of the operations are dealt in these patches, so more work needs to be done. The only change visible to the user should be the change in module dependencies: e.g. earlier a panel module depended on an encoder module, but now the encoder module depends on the panel module, which affects the order in which to unload the modules. Jyri Sarha (1): drm/omap: dss: Move platform_device_register from core.c to dss.c probe Laurent Pinchart (100): drm/omap: dss: Gather OMAP DSS components at probe time drm/omap: dss: Handle DPI and SDI port initialization failures drm/omap: dss: Remove omapdss_atv_ops get_wss and set_wss operations drm/omap: dss: Remove DSS encoders get_timings operation drm/omap: dss: Remove unused omapdss_default_get_timings() drm/omap: dss: Constify omap_dss_driver operations structure drm/omap: displays: Remove videomode from omap_dss_device structure drm/omap: dss: Remove omap_dss_device panel fields drm/omap: dss: Rename omap_dss_device list field to output_list drm/omap: dss: Create global list of all omap_dss_device instances drm/omap: dss: Create and use omapdss_device_is_registered() drm/omap: dss: Rework output lookup by port node drm/omap: dss: Allow looking up any device by port drm/omap: dss: Move common device operations to common structure drm/omap: dss: Add functions to connect and disconnect devices drm/omap: dss: Move debug message and checks to connection handlers drm/omap: displays: Don't call disconnect handlers directly drm/omap: dss: Move src and dst check and set to connection handlers drm/omap: displays: Remove input omap_dss_device from panel data drm/omap: dsi: Simplify debugfs implementation drm/omap: Move DSI debugfs clocks dump to dsi%u_clks files drm/omap: dss: Remove output devices list drm/omap: dss: Rename for_each_dss_dev macro to for_each_dss_display drm/omap: dss: Make omap_dss_get_next_device() more generic drm/omap: dss: Split omapdss_register_display() drm/omap: dss: Remove panel devices list drm/omap: dss: Move and rename omap_dss_(get|put)_device() drm/omap: dss: Store dss_device pointer in omap_dss_device drm/omap: dss: Move DSS mgr ops and private data to dss_device drm/omap: dss: Modify omapdss_find_output_from_display() to return channel drm/omap: dss: Replace omap_dss_device port number with bitmask drm/omap: dss: Extend omapdss_of_find_source_for_first_ep() to sinks drm/omap: displays: Don't cast dssdev to panel data unnecessarily drm/omap: dss: Cleanup error paths in output init functions drm/omap: dss: dsi: Move initialization code from bind to probe drm/omap: dss: hdmi4: Move initialization code from bind to probe drm/omap: dss: hdmi5: Move initialization code from bind to probe drm/omap: dss: venc: Move initialization code from bind to probe drm/omap: dss: Acquire next dssdev at probe time drm/omap: dss: Add for_each_dss_output() macro drm/omap: dss: Add function to retrieve display for an output drm/omap: dss: Remove duplicated parameter to dss_mgr_(dis)connect() drm/omap: dss: Get regulators at probe time drm/omap: Remove unneeded variable assignments in omap_modeset_init drm/omap: Create all planes before CRTCs drm/omap: Group CRTC, encoder, connector and dssdev in a structure drm/omap: Reverse direction of DSS device (dis)connect operations drm/omap: dss: Move connection checks to omapdss_device_(dis)connect drm/omap: dss: Move display type validation to initialization time drm/omap: dss: Merge two disconnection helpers drm/omap: Pass pipe pointer to omap_crtc_init() drm/omap: Store CRTC lookup by channel table in omap_drm_private drm/omap: Remove
[Bug 105379] The Witcher: Enhanced Edition under Wine fails to launch
https://bugs.freedesktop.org/show_bug.cgi?id=105379 --- Comment #7 from Andrew Sheldon --- Scratch that; looks like a manual git build works, but not mesa- in the Gentoo repository. I've tested with minimal cflags too and the problem remains, so I'm not sure what the difference is. -- 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 105251] [Vega10] GPU lockup on boot: VMC page fault
https://bugs.freedesktop.org/show_bug.cgi?id=105251 --- Comment #48 from CheatCodesOfLife --- Created attachment 141425 --> https://bugs.freedesktop.org/attachment.cgi?id=141425=edit logs and trace Hi, I have applied the patch, ran through the process and attached the logs. The file doesn't appear to be truncated anymore. -- 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
[REGRESSION] boot-screen override by "34db50e55656 efifb: Copy the ACPI BGRT"
Hey Since this commit: 34db50e55656 efifb: Copy the ACPI BGRT the kernel will override boot-splashs unasked. This breaks the graphical boot-process on our setups. In particular, we have a setup where an efi-boot-entry draws the early boot-splash on-screen, then hands-over to the linux-kernel + initrd. The boot-splash daemon in the initrd then takes over control of possible animations. With the mentioned commit compiled in, the kernel will redraw the firmware logo on screen at a random time without any way to intervene. What is the intention of this commit? Why is the kernel re-drawing the firmware logo unasked? If someone during the boot-process draws content on the screen, I would prefer if the kernel does not clear that on driver load. Can we either provide an option to disable this feature, or revert the commit? Thanks David ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105379] The Witcher: Enhanced Edition under Wine fails to launch
https://bugs.freedesktop.org/show_bug.cgi?id=105379 --- Comment #6 from Andrew Sheldon --- It's still broken for me actually, and reverting the commit original commit works around the issue. Maybe there is something that is specific to my system 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
[Bug 106747] [CI] igt@* - crash - An internal exception that should have been handled was not: UnicodeDecodeError
https://bugs.freedesktop.org/show_bug.cgi?id=106747 Petri Latvala changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG --- Comment #5 from Petri Latvala --- Marking notourbug, we should be able to create a proper bug report of the test printing ickyness with igt_runner when that's deployed. -- 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 107800] [CI][BAT] An internal exception that should have been handled was not: UnicodeDecodeError.
https://bugs.freedesktop.org/show_bug.cgi?id=107800 Martin Peres changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #4 from Martin Peres --- Sorry for the noise :s -- 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 107800] [CI][BAT] An internal exception that should have been handled was not: UnicodeDecodeError.
https://bugs.freedesktop.org/show_bug.cgi?id=107800 Petri Latvala changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Petri Latvala --- *** This bug has been marked as a duplicate of bug 106747 *** -- 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 106747] [CI] igt@* - crash - An internal exception that should have been handled was not: UnicodeDecodeError
https://bugs.freedesktop.org/show_bug.cgi?id=106747 --- Comment #4 from Petri Latvala --- *** Bug 107800 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 107800] [CI][BAT] An internal exception that should have been handled was not: UnicodeDecodeError.
https://bugs.freedesktop.org/show_bug.cgi?id=107800 --- Comment #2 from Chris Wilson --- Want to just poke bug 106747? -- 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 107800] [CI][BAT] An internal exception that should have been handled was not: UnicodeDecodeError.
https://bugs.freedesktop.org/show_bug.cgi?id=107800 Martin Peres changed: What|Removed |Added Whiteboard||ReadyForDev Priority|medium |highest --- Comment #1 from Martin Peres --- This is a BAT bug, raising priority. -- 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 107800] [CI][BAT] An internal exception that should have been handled was not: UnicodeDecodeError.
https://bugs.freedesktop.org/show_bug.cgi?id=107800 Bug ID: 107800 Summary: [CI][BAT] An internal exception that should have been handled was not: UnicodeDecodeError. Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: IGT Assignee: dri-devel@lists.freedesktop.org Reporter: martin.pe...@free.fr https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_4756/fi-byt-n2820/igt@gem_exec_paral...@basic.html An internal exception that should have been handled was not: UnicodeDecodeError. -- 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 10/27] drm/sun4i: Add compatible for H6 display engine
hi,
On Sun, Sep 02, 2018 at 09:26:26AM +0200, Jernej Skrabec wrote:
> H6 is first Allwinner SoC which supports 10 bit colors, HDR and AFBC.
>
> Signed-off-by: Jernej Skrabec
> ---
> drivers/gpu/drm/sun4i/sun4i_drv.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
> b/drivers/gpu/drm/sun4i/sun4i_drv.c
> index dd19d674055c..e5731d092e1a 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> @@ -410,6 +410,7 @@ static int sun4i_drv_remove(struct platform_device *pdev)
>
> static const struct of_device_id sun4i_drv_of_table[] = {
> { .compatible = "allwinner,sun4i-a10-display-engine" },
> + { .compatible = "allwinner,sun50i-h6-display-engine" },
> { .compatible = "allwinner,sun5i-a10s-display-engine" },
> { .compatible = "allwinner,sun5i-a13-display-engine" },
> { .compatible = "allwinner,sun6i-a31-display-engine" },
While it makes sens from an alphabetical point of view, we usually
follow the number order here (so after sun9i).
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107798] [CI][BAT] igt@pm_rpm@module-reload - fail - Failed assertion: is_i915_device(fd)
https://bugs.freedesktop.org/show_bug.cgi?id=107798
Chris Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #1 from Chris Wilson ---
commit 125eee6e981eac0a004aeb4f327439a132ceac5c (upstream/master,
origin/master, origin/HEAD)
Author: Chris Wilson
Date: Mon Sep 3 10:44:31 2018 +0100
lib: Fix strcmp() direction for bsearch.
I fluked out as vgem was the initial mid value, hiding the worst of the
errors as i915 matched with DRIVER_ANY.
Fixes: 20087bf22698 ("lib: Use a bsearch to find the module name")
Reported-by: Petri Latvala
Signed-off-by: Chris Wilson
Cc: Petri Latvala
Reviewed-by: Petri Latvala
--
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] gpu: drm: drm_mm: Fix a sleep-in-atomic-context bug in show_leaks()
Am 03.09.2018 um 09:52 schrieb Daniel Vetter: On Sat, Sep 01, 2018 at 01:32:54PM +0100, Chris Wilson wrote: Quoting Jia-Ju Bai (2018-09-01 13:20:41) The driver may sleep with holding a spinlock. The function call paths (from bottom to top) in Linux-4.16 are: [FUNC] kmalloc(GFP_KERNEL) drivers/gpu/drm/drm_mm.c, 130: kmalloc in show_leaks drivers/gpu/drm/drm_mm.c, 913: show_leaks in drm_mm_takedown drivers/gpu/drm/drm_vma_manager.c, 107: drm_mm_takedown in drm_vma_offset_manager_destroy drivers/gpu/drm/drm_vma_manager.c, 106: _raw_write_lock in drm_vma_offset_manager_destroy [FUNC] kmalloc(GFP_KERNEL) drivers/gpu/drm/drm_mm.c, 130: kmalloc in show_leaks drivers/gpu/drm/drm_mm.c, 913: show_leaks in drm_mm_takedown drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c, 71: drm_mm_takedown in amdgpu_vram_mgr_fini drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c, 70: spin_lock in amdgpu_vram_mgr_fini [FUNC] kmalloc(GFP_KERNEL) drivers/gpu/drm/drm_mm.c, 130: kmalloc in show_leaks drivers/gpu/drm/drm_mm.c, 913: show_leaks in drm_mm_takedown drivers/gpu/drm/ttm/ttm_bo_manager.c, 128: drm_mm_takedown in ttm_bo_man_takedown drivers/gpu/drm/ttm/ttm_bo_manager.c, 126: spin_lock in ttm_bo_man_takedown To fix this bug, GFP_KERNEL is replaced with GFP_ATOMIC. The bug are above, since those spinlocks do not protect the data and imply use-after-free. Adding amdgpu, since that's where the bug seems to be. When we have use after free we might have concurrent uses as well. I think taking the lock here is probably a good idea if you don't want to accidentally access freed memory in show_leaks. So Chris change sounds valid to me. Christian. -Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107798] [CI][BAT] igt@pm_rpm@module-reload - fail - Failed assertion: is_i915_device(fd)
https://bugs.freedesktop.org/show_bug.cgi?id=107798 Martin Peres changed: What|Removed |Added Whiteboard||ReadyForDev Priority|medium |highest -- 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 107798] [CI][BAT] igt@pm_rpm@module-reload - fail - Failed assertion: is_i915_device(fd)
https://bugs.freedesktop.org/show_bug.cgi?id=107798 Bug ID: 107798 Summary: [CI][BAT] igt@pm_rpm@module-reload - fail - Failed assertion: is_i915_device(fd) Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: IGT Assignee: dri-devel@lists.freedesktop.org Reporter: martin.pe...@free.fr https://intel-gfx-ci.01.org/tree/drm-tip/IGT_4620/fi-kbl-8809g/igt@pm_...@module-reload.html https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_4754/fi-kbl-8809g/igt@pm_...@module-reload.html (pm_rpm:4358) intel_chipset-CRITICAL: Test assertion failure function intel_get_drm_devid, file ../lib/intel_chipset.c:132: (pm_rpm:4358) intel_chipset-CRITICAL: Failed assertion: is_i915_device(fd) (pm_rpm:4358) intel_chipset-CRITICAL: Last errno: 2, No such file or directory Test pm_rpm failed. -- 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 v3 00/13] remove_conflicting_framebuffers() cleanup
On Monday, September 03, 2018 09:43:15 AM Daniel Vetter wrote: > On Sat, Sep 01, 2018 at 04:08:41PM +0200, Michał Mirosław wrote: > > This series cleans up duplicated code for replacing firmware FB > > driver with proper DRI driver and adds handover support to > > Tegra driver. > > > > This is a sligtly updated version of a series sent on 24 Nov 2017. > > > > --- > > v2: > > - rebased on current drm-next > > - dropped staging/sm750fb changes > > - added kernel docs for DRM helpers > > v3: > > - move kerneldoc to fbdev, where functions are implemented > > - split kerneldoc for remove_conflicting_framebuffers() > > Ah, that's not quite what I had in mind. I think having the docs (also) in > the drm helpers would be good, since that's where drm people will look, > and that's the function they'll call. I just wanted you to split the fbdev > and drm parts into 2 patches (since those are two different maintainers). > > Anyway, this is ok too, so imo ready for merging. If you can resurrect the > drm docs (with a patch title of "drm/fb-helper: document fbdev remove > functions" or similar) that would be great. > > Only thing we need for merging now is the ack from Bartlomiej. For the whole patchset: Acked-by: Bartlomiej Zolnierkiewicz > -Daniel > > > - propagate return value in remove_conflicting_pci_framebuffers() > > > > --- > > Michał Mirosław (13): > > fbdev: show fbdev number for debugging > > fbdev: allow apertures == NULL in remove_conflicting_framebuffers() > > fbdev: add kerneldoc do remove_conflicting_framebuffers() > > fbdev: add remove_conflicting_pci_framebuffers() > > drm/amdgpu: use simpler remove_conflicting_pci_framebuffers() > > drm/bochs: use simpler remove_conflicting_pci_framebuffers() > > drm/cirrus: use simpler remove_conflicting_pci_framebuffers() > > drm/mgag200: use simpler remove_conflicting_pci_framebuffers() > > drm/radeon: use simpler remove_conflicting_pci_framebuffers() > > drm/virtio: use simpler remove_conflicting_pci_framebuffers() > > drm/vc4: use simpler remove_conflicting_framebuffers(NULL) > > drm/sun4i: use simpler remove_conflicting_framebuffers(NULL) > > drm/tegra: kick out simplefb > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 24 + > > drivers/gpu/drm/bochs/bochs_drv.c| 18 +-- > > drivers/gpu/drm/cirrus/cirrus_drv.c | 23 + > > drivers/gpu/drm/mgag200/mgag200_drv.c| 21 +--- > > drivers/gpu/drm/mgag200/mgag200_main.c | 9 > > drivers/gpu/drm/radeon/radeon_drv.c | 23 + > > drivers/gpu/drm/sun4i/sun4i_drv.c| 18 +-- > > drivers/gpu/drm/tegra/drm.c | 4 ++ > > drivers/gpu/drm/vc4/vc4_drv.c| 20 +--- > > drivers/gpu/drm/virtio/virtgpu_drm_bus.c | 24 ++--- > > drivers/video/fbdev/core/fbmem.c | 63 +++- > > include/drm/drm_fb_helper.h | 12 + > > include/linux/fb.h | 2 + > > 13 files changed, 89 insertions(+), 172 deletions(-) Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] [RFC]drm: add syncobj timeline support v3
Am 03.09.2018 um 12:07 schrieb Chunming Zhou:
在 2018/9/3 16:50, Christian König 写道:
Am 03.09.2018 um 06:13 schrieb Chunming Zhou:
在 2018/8/30 19:32, Christian König 写道:
[SNIP]
+
+struct drm_syncobj_wait_pt {
+ struct drm_syncobj_stub_fence base;
+ u64 value;
+ struct rb_node node;
+};
+struct drm_syncobj_signal_pt {
+ struct drm_syncobj_stub_fence base;
+ struct dma_fence *signal_fence;
+ struct dma_fence *pre_pt_base;
+ struct dma_fence_cb signal_cb;
+ struct dma_fence_cb pre_pt_cb;
+ struct drm_syncobj *syncobj;
+ u64 value;
+ struct list_head list;
+};
What are those two structures good for
They are used to record wait ops points and signal ops points.
For timeline, they are connected by timeline value, works like:
a. signal pt increase timeline value to signal_pt value when
signal_pt is signaled. signal_pt is depending on previous pt
fence and itself signal fence from signal ops.
b. wait pt tree checks if timeline value over itself value.
For normal, works like:
a. signal pt increase 1 for syncobj_timeline->signal_point
every time when signal ops is performed.
b. when wait ops is comming, wait pt will fetch above last
signal pt value as its wait point. wait pt will be only signaled
by equal point value signal_pt.
and why is the stub fence their base?
Good question, I tried to kzalloc for them as well when I debug
them, I encountered a problem:
I lookup/find wait_pt or signal_pt successfully, but when I
tried to use them, they are freed sometimes, and results in NULL
point.
and generally, when lookup them, we often need their stub fence
as well, and in the meantime, their lifecycle are same.
Above reason, I make stub fence as their base.
That sounds like you only did this because you messed up the
lifecycle.
Additional to that I don't think you correctly considered the
lifecycle of the waits and the sync object itself. E.g. blocking
in drm_syncobj_timeline_fini() until all waits are done is not a
good idea.
What you should do instead is to create a fence_array object with
all the fence we need to wait for when a wait point is requested.
Yeah, this is our initial discussion result, but when I tried to
do that, I found that cannot meet the advance signal requirement:
a. We need to consider the wait and signal pt value are not
one-to-one match, it's difficult to find dependent point, at
least, there is some overhead.
As far as I can see that is independent of using a fence array
here. See you can either use a ring buffer or an rb-tree, but when
you want to wait for a specific point we need to condense the not
yet signaled fences into an array.
again, need to find the range of where the specific point in, we
should close to timeline semantics, I also refered the sw_sync.c
timeline, usally wait_pt is signalled by timeline point. And I agree
we can implement it with several methods, but I don't think there
are basical differences.
The problem is that with your current approach you need the sync_obj
alive for the synchronization to work. That is most likely not a good
idea.
Indeed, I will fix that. How abount only creating fence array for
every wait pt when syncobj release? when syncobj release, wait pt must
have waited the signal opertation, then we can easily condense fences
for every wait pt. And meantime, we can take timeline based wait pt
advantage.
That could work, but I don't see how you want to replace the already
issued fence with a fence_array when the sync object is destroyed.
Additional to that I would rather prefer a consistent handling, e.g.
without extra rarely used code paths.
Additional to that you enable signaling without a need from the
waiting side. That is rather bad for implementations which need that
optimization.
Do you mean increasing timeline based on signal fence is not better?
only update timeline value when requested by a wait pt?
Yes, exactly.
This way, we will not update timeline value immidiately and cannot
free signal pt immidiately, and we also need to consider it to CPU
query and wait.
That is actually the better coding style. We usually try to avoid doing
things in interrupt handlers as much as possible.
How about this idea:
1. Each signaling point is a fence implementation with an rb node.
2. Each node keeps a reference to the last previously inserted node.
3. Each node is referenced by the sync object itself.
4. Before each signal/wait operation we do a garbage collection and
remove the first node from the tree as long as it is signaled.
5. When enable_signaling is requested for a node we cascade that to the
left using rb_prev.
This ensures that signaling is enabled for the current fence as
well as all previous fences.
6. A wait just looks into the tree for the signal point lower or equal
of the requested sequence number.
7. When the sync object is released we use
rbtree_postorder_for_each_entry_safe() and drop
[PATCH 5/5] drm/virtio: fix DRM_FORMAT_* handling
Use DRM_FORMAT_HOST_XRGB, so we are using the correct format code
on bigendian machines. Also add DRIVER_PREFER_HOST_BYTE_ORDER driver
feature flag so drm_mode_addfb() asks for the correct format code.
Both DRM_FORMAT_* and VIRTIO_GPU_FORMAT_* are defined to be little
endian, so using a different mapping on bigendian machines is wrong.
It's there because of broken drm_mode_addfb() behavior. So with
drm_mode_addfb() being fixed we can fix this too.
While wading through the code I've noticed we have a little issue in
virtio: We attach a format to the bo when it is created
(DRM_IOCTL_MODE_CREATE_DUMB), not when we map it as framebuffer
(DRM_IOCTL_MODE_ADDFB). Easy way out: Support a single format only.
Pick DRM_FORMAT_HOST_XRGB, it is the only one actually used in
practice. Drop unused mappings in virtio_gpu_translate_format().
With this patch applied both ADDFB and ADDFB2 ioctls work correctly in
the virtio-gpu.ko driver on big endian machines. Without the patch only
ADDFB (which still seems to be used by the majority of userspace) works
correctly.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_display.c | 4 +++
drivers/gpu/drm/virtio/virtgpu_drv.c | 4 ++-
drivers/gpu/drm/virtio/virtgpu_fb.c | 2 +-
drivers/gpu/drm/virtio/virtgpu_gem.c | 7 +++--
drivers/gpu/drm/virtio/virtgpu_plane.c | 54 ++--
5 files changed, 15 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
b/drivers/gpu/drm/virtio/virtgpu_display.c
index 25503b9335..f6c4af1db4 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -306,6 +306,10 @@ virtio_gpu_user_framebuffer_create(struct drm_device *dev,
struct virtio_gpu_framebuffer *virtio_gpu_fb;
int ret;
+ if (mode_cmd->pixel_format != DRM_FORMAT_HOST_XRGB &&
+ mode_cmd->pixel_format != DRM_FORMAT_HOST_ARGB)
+ return ERR_PTR(-ENOENT);
+
/* lookup object associated with res handle */
obj = drm_gem_object_lookup(file_priv, mode_cmd->handles[0]);
if (!obj)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c
b/drivers/gpu/drm/virtio/virtgpu_drv.c
index d9287c144f..4b28f41ac1 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
@@ -114,7 +114,9 @@ static const struct file_operations virtio_gpu_driver_fops
= {
};
static struct drm_driver driver = {
- .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME |
DRIVER_RENDER | DRIVER_ATOMIC,
+ .driver_features = (DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME |
+ DRIVER_RENDER | DRIVER_ATOMIC |
+ DRIVER_PREFER_HOST_BYTE_ORDER),
.load = virtio_gpu_driver_load,
.unload = virtio_gpu_driver_unload,
.open = virtio_gpu_driver_open,
diff --git a/drivers/gpu/drm/virtio/virtgpu_fb.c
b/drivers/gpu/drm/virtio/virtgpu_fb.c
index a121b1c795..9d87ebd645 100644
--- a/drivers/gpu/drm/virtio/virtgpu_fb.c
+++ b/drivers/gpu/drm/virtio/virtgpu_fb.c
@@ -233,7 +233,7 @@ static int virtio_gpufb_create(struct drm_fb_helper *helper,
mode_cmd.width = sizes->surface_width;
mode_cmd.height = sizes->surface_height;
mode_cmd.pitches[0] = mode_cmd.width * 4;
- mode_cmd.pixel_format = drm_mode_legacy_fb_format(32, 24);
+ mode_cmd.pixel_format = DRM_FORMAT_HOST_XRGB;
format = virtio_gpu_translate_format(mode_cmd.pixel_format);
if (format == 0)
diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c
b/drivers/gpu/drm/virtio/virtgpu_gem.c
index 0f2768eaca..82c817f37c 100644
--- a/drivers/gpu/drm/virtio/virtgpu_gem.c
+++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
@@ -90,7 +90,10 @@ int virtio_gpu_mode_dumb_create(struct drm_file *file_priv,
uint32_t resid;
uint32_t format;
- pitch = args->width * ((args->bpp + 1) / 8);
+ if (args->bpp != 32)
+ return -EINVAL;
+
+ pitch = args->width * 4;
args->size = pitch * args->height;
args->size = ALIGN(args->size, PAGE_SIZE);
@@ -99,7 +102,7 @@ int virtio_gpu_mode_dumb_create(struct drm_file *file_priv,
if (ret)
goto fail;
- format = virtio_gpu_translate_format(DRM_FORMAT_XRGB);
+ format = virtio_gpu_translate_format(DRM_FORMAT_HOST_XRGB);
virtio_gpu_resource_id_get(vgdev, );
virtio_gpu_cmd_create_resource(vgdev, resid, format,
args->width, args->height);
diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
b/drivers/gpu/drm/virtio/virtgpu_plane.c
index dc5b5b2b7a..3221d50b9a 100644
--- a/drivers/gpu/drm/virtio/virtgpu_plane.c
+++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
@@ -28,22 +28,11 @@
#include
static const uint32_t virtio_gpu_formats[] = {
- DRM_FORMAT_XRGB,
- DRM_FORMAT_ARGB,
- DRM_FORMAT_BGRX,
-
[PATCH 0/5] drm: byteorder fixes
After a lng break, here is the next version of the patch series. It adds some convinience #defines for host byteoder drm formats. It fixes drm_mode_addfb() behavior on bigendian machines. For bug compatibility reasons a driver feature flag activates the fix. bochs and virtio-gpu drivers are updated to use the new #defines, set the new driver feature flag and fix some issues. Gerd Hoffmann (5): drm: byteorder: add DRM_FORMAT_HOST_* drm: do not mask out DRM_FORMAT_BIG_ENDIAN drm: fix drm_mode_addfb() on big endian machines. drm/bochs: fix DRM_FORMAT_* handling for big endian machines. drm/virtio: fix DRM_FORMAT_* handling include/drm/drm_drv.h| 1 + include/drm/drm_fourcc.h | 22 + drivers/gpu/drm/bochs/bochs_drv.c| 3 +- drivers/gpu/drm/bochs/bochs_fbdev.c | 5 ++- drivers/gpu/drm/bochs/bochs_kms.c| 33 ++- drivers/gpu/drm/bochs/bochs_mm.c | 2 +- drivers/gpu/drm/drm_framebuffer.c| 13 +++- drivers/gpu/drm/virtio/virtgpu_display.c | 4 +++ drivers/gpu/drm/virtio/virtgpu_drv.c | 4 ++- drivers/gpu/drm/virtio/virtgpu_fb.c | 2 +- drivers/gpu/drm/virtio/virtgpu_gem.c | 7 +++-- drivers/gpu/drm/virtio/virtgpu_plane.c | 54 ++-- 12 files changed, 87 insertions(+), 63 deletions(-) -- 2.9.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/bochs: fix DRM_FORMAT_* handling for big endian machines.
Use DRM_FORMAT_HOST_XRGB, so we are using the correct format code
on bigendian machines. Also add DRIVER_PREFER_HOST_BYTE_ORDER driver
feature flag so drm_mode_addfb() asks for the correct format code.
Create our own plane and use drm_crtc_init_with_planes() instead of
depending on the default created by drm_crtc_init(). That way the plane
format list is correct on bigendian machines.
With this patch applied both ADDFB and ADDFB2 ioctls work correctly in
the bochs-drm.ko driver on big endian machines. Without the patch only
ADDFB (which still seems to be used by the majority of userspace) works
correctly.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/bochs/bochs_drv.c | 3 ++-
drivers/gpu/drm/bochs/bochs_fbdev.c | 5 ++---
drivers/gpu/drm/bochs/bochs_kms.c | 33 -
drivers/gpu/drm/bochs/bochs_mm.c| 2 +-
4 files changed, 37 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs_drv.c
b/drivers/gpu/drm/bochs/bochs_drv.c
index 7b20318483..fa84a3c841 100644
--- a/drivers/gpu/drm/bochs/bochs_drv.c
+++ b/drivers/gpu/drm/bochs/bochs_drv.c
@@ -81,7 +81,8 @@ static const struct file_operations bochs_fops = {
};
static struct drm_driver bochs_driver = {
- .driver_features= DRIVER_GEM | DRIVER_MODESET,
+ .driver_features= (DRIVER_GEM | DRIVER_MODESET |
+ DRIVER_PREFER_HOST_BYTE_ORDER),
.load = bochs_load,
.unload = bochs_unload,
.fops = _fops,
diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c
b/drivers/gpu/drm/bochs/bochs_fbdev.c
index 14eb8d0d5a..bf728790fa 100644
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
@@ -64,9 +64,8 @@ static int bochsfb_create(struct drm_fb_helper *helper,
mode_cmd.width = sizes->surface_width;
mode_cmd.height = sizes->surface_height;
- mode_cmd.pitches[0] = mode_cmd.width * ((sizes->surface_bpp + 7) / 8);
- mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp,
- sizes->surface_depth);
+ mode_cmd.pitches[0] = sizes->surface_width * 4;
+ mode_cmd.pixel_format = DRM_FORMAT_HOST_XRGB;
size = mode_cmd.pitches[0] * mode_cmd.height;
/* alloc, pin & map bo */
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
b/drivers/gpu/drm/bochs/bochs_kms.c
index ca5a9afdd5..2662cdcf2d 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -129,12 +129,43 @@ static const struct drm_crtc_helper_funcs
bochs_helper_funcs = {
.commit = bochs_crtc_commit,
};
+static const uint32_t bochs_formats[] = {
+ DRM_FORMAT_HOST_XRGB,
+};
+
+static struct drm_plane *bochs_primary_plane(struct drm_device *dev)
+{
+ struct drm_plane *primary;
+ int ret;
+
+ primary = kzalloc(sizeof(*primary), GFP_KERNEL);
+ if (primary == NULL) {
+ DRM_DEBUG_KMS("Failed to allocate primary plane\n");
+ return NULL;
+ }
+
+ ret = drm_universal_plane_init(dev, primary, 0,
+ _primary_helper_funcs,
+ bochs_formats,
+ ARRAY_SIZE(bochs_formats),
+ NULL,
+ DRM_PLANE_TYPE_PRIMARY, NULL);
+ if (ret) {
+ kfree(primary);
+ primary = NULL;
+ }
+
+ return primary;
+}
+
static void bochs_crtc_init(struct drm_device *dev)
{
struct bochs_device *bochs = dev->dev_private;
struct drm_crtc *crtc = >crtc;
+ struct drm_plane *primary = bochs_primary_plane(dev);
- drm_crtc_init(dev, crtc, _crtc_funcs);
+ drm_crtc_init_with_planes(dev, crtc, primary, NULL,
+ _crtc_funcs, NULL);
drm_crtc_helper_add(crtc, _helper_funcs);
}
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index c9c7097030..fdf151fbdb 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -506,7 +506,7 @@ bochs_user_framebuffer_create(struct drm_device *dev,
(mode_cmd->pixel_format >> 16) & 0xff,
(mode_cmd->pixel_format >> 24) & 0xff);
- if (mode_cmd->pixel_format != DRM_FORMAT_XRGB)
+ if (mode_cmd->pixel_format != DRM_FORMAT_HOST_XRGB)
return ERR_PTR(-ENOENT);
obj = drm_gem_object_lookup(filp, mode_cmd->handles[0]);
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm: do not mask out DRM_FORMAT_BIG_ENDIAN
framebuffer_check() expects that drm_get_format_info() will not fail if
the __drm_format_info() call was successful. That'll work only in case
both are called with the same pixel_format value, so masking out the
DRM_FORMAT_BIG_ENDIAN flag isn't a good idea.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/drm_framebuffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/drivers/gpu/drm/drm_framebuffer.c
index 781af1d42d..88758096d5 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -164,7 +164,7 @@ static int framebuffer_check(struct drm_device *dev,
int i;
/* check if the format is supported at all */
- info = __drm_format_info(r->pixel_format & ~DRM_FORMAT_BIG_ENDIAN);
+ info = __drm_format_info(r->pixel_format);
if (!info) {
struct drm_format_name_buf format_name;
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm: fix drm_mode_addfb() on big endian machines.
Userspace on big endian machhines typically expects the ADDFB ioctl
returns a big endian framebuffer. drm_mode_addfb() will call
drm_mode_addfb2() unconditionally with little endian DRM_FORMAT_*
values though, which is wrong. This patch fixes that.
Drivers (both kernel and xorg) have quirks in place to deal with the
broken drm_mode_addfb() behavior. Because of this we can't just change
drm_mode_addfb() behavior for everybody without breaking things. So add
a new driver feature flag DRIVER_PREFER_HOST_BYTE_ORDER, so drivers can
opt-in.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_drv.h | 1 +
drivers/gpu/drm/drm_framebuffer.c | 11 +++
2 files changed, 12 insertions(+)
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 46a8009784..9cf12596cd 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -57,6 +57,7 @@ struct drm_printer;
#define DRIVER_KMS_LEGACY_CONTEXT 0x2
#define DRIVER_SYNCOBJ 0x4
#define DRIVER_PREFER_XBGR_30BPP0x8
+#define DRIVER_PREFER_HOST_BYTE_ORDER 0x10
/**
* struct drm_driver - DRM driver structure
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/drivers/gpu/drm/drm_framebuffer.c
index 88758096d5..ccbda8a2e9 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -124,6 +124,17 @@ int drm_mode_addfb(struct drm_device *dev, struct
drm_mode_fb_cmd *or,
dev->driver->driver_features & DRIVER_PREFER_XBGR_30BPP)
r.pixel_format = DRM_FORMAT_XBGR2101010;
+ if (dev->driver->driver_features & DRIVER_PREFER_HOST_BYTE_ORDER) {
+ if (r.pixel_format == DRM_FORMAT_XRGB)
+ r.pixel_format = DRM_FORMAT_HOST_XRGB;
+ if (r.pixel_format == DRM_FORMAT_ARGB)
+ r.pixel_format = DRM_FORMAT_HOST_ARGB;
+ if (r.pixel_format == DRM_FORMAT_RGB565)
+ r.pixel_format = DRM_FORMAT_HOST_RGB565;
+ if (r.pixel_format == DRM_FORMAT_XRGB1555)
+ r.pixel_format = DRM_FORMAT_HOST_XRGB1555;
+ }
+
ret = drm_mode_addfb2(dev, , file_priv);
if (ret)
return ret;
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] drm: byteorder: add DRM_FORMAT_HOST_*
Add fourcc variants in host byte order. With these at hand we don't need #ifdefs in drivers which support framebuffers in cpu endianess. Signed-off-by: Gerd Hoffmann --- include/drm/drm_fourcc.h | 22 ++ 1 file changed, 22 insertions(+) diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h index f9c15845f4..fac831c401 100644 --- a/include/drm/drm_fourcc.h +++ b/include/drm/drm_fourcc.h @@ -25,6 +25,28 @@ #include #include +/* + * DRM formats are little endian. Define host endian variants for the + * most common formats here, to reduce the #ifdefs needed in drivers. + * + * Note that the DRM_FORMAT_BIG_ENDIAN flag should only be used in + * case the format can't be specified otherwise, so we don't end up + * with two values describing the same format. + */ +#ifdef __BIG_ENDIAN +# define DRM_FORMAT_HOST_XRGB1555 (DRM_FORMAT_XRGB1555 | \ + DRM_FORMAT_BIG_ENDIAN) +# define DRM_FORMAT_HOST_RGB565 (DRM_FORMAT_RGB565 | \ + DRM_FORMAT_BIG_ENDIAN) +# define DRM_FORMAT_HOST_XRGB DRM_FORMAT_BGRX +# define DRM_FORMAT_HOST_ARGB DRM_FORMAT_BGRA +#else +# define DRM_FORMAT_HOST_XRGB1555 DRM_FORMAT_XRGB1555 +# define DRM_FORMAT_HOST_RGB565 DRM_FORMAT_RGB565 +# define DRM_FORMAT_HOST_XRGB DRM_FORMAT_XRGB +# define DRM_FORMAT_HOST_ARGB DRM_FORMAT_ARGB +#endif + struct drm_device; struct drm_mode_fb_cmd2; -- 2.9.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Describe pixel_blend_mode in drm_plane_state
Hi Sean,
On Fri, Aug 31, 2018 at 11:09:25AM -0400, Sean Paul wrote:
> From: Sean Paul
>
> Adds docs for pixel_blend_mode in drm_plane_state. Fixes the warning
> found by kbuild test robot:
>
> htmldocs: include/drm/drm_plane.h:189: warning: Function parameter or member
> 'pixel_blend_mode' not described in 'drm_plane_state'
>
> Cc: Daniel Vetter
> Cc: Lowry Li
> Signed-off-by: Sean Paul
Reviewed-by: Alexandru Gheorghe
> ---
> include/drm/drm_plane.h | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index 35ef64a9398b..16f5b66684ca 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -117,6 +117,13 @@ struct drm_plane_state {
>* details.
>*/
> u16 alpha;
> +
> + /**
> + * @pixel_blend_mode:
> + * The alpha blending equation selection, describing how the pixels from
> + * the current plane are composited with the background. Value can be
> + * one of DRM_MODE_BLEND_*
> + */
> uint16_t pixel_blend_mode;
>
> /**
> --
> Sean Paul, Software Engineer, Google / Chromium OS
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107781] amdgpu hangs on resume on Lenovo A475
https://bugs.freedesktop.org/show_bug.cgi?id=107781 --- Comment #4 from Alex Findler --- I've tried with all kernels that Fedora offered during the last two months, including 4.16 varieties. These are the kernel options I tried: radeon.cik_support=0 amdgpu.cik_support=1 scsi_mod.scan=sync amdgpu.gpu_recovery=1 amdgpu.dc=1 I have now added the option iommu=soft, and it seems to solve the problem! I have tried suspend via script (echo mem > /sys/power/state), via hardware button, and via plasmashell option, and all come back, including wake-up by lid signal. I'll test this for a couple of days now and see if it works persistently, then report back. Thanks for your quick reaction, it is much appreciated. -- 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 107784] [AMD tahiti XT] displayport broken
https://bugs.freedesktop.org/show_bug.cgi?id=107784 --- Comment #3 from Sylvain BERTRAND --- On Mon, Sep 03, 2018 at 09:17:30AM +, bugzilla-dae...@freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=107784 > > --- Comment #2 from Michel Dänzer --- > Can you bisect? I don't think it is reasonable because something bad happens between the 4.18 to 4.19 jump, then I would have to bisect on thousands of commits. Additionnaly, I had to remove my git repo of 4.18 and clone again 4.19 because git was unable to perform the pull, even with reset and force (I probably don't know some git magic here): lost the last working 4.18 commit. I would need to know what drm/amdgpu related commits where added from 4.18->4.19, the person who did this has this knowledge. I'll try to fool around with git to see if I can manage something in the mean time (with dates and targetting drm/amdgpu directories). > P.S. Please enable CONFIG_UNWINDER_ORC in your kernel build, to make the > backtraces in dmesg more useful. ORC breaks linux build. Only guess compile (actually kbuild and kconfig are quite broken in this 4.19), but it's an optimized build without symbols. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106639] System display has noise when amdgpu module is being loaded
https://bugs.freedesktop.org/show_bug.cgi?id=106639 --- Comment #11 from Daniel Drake --- Also confirmed working after applying these commits from amd-staging-drm-next Applying: drm/amdgpu/gmc9: rework stolen vga memory handling Applying: drm/amdgpu/gmc9: don't keep stolen memory on Raven Applying: drm/amdgpu/gmc9: don't keep stolen memory on vega12 Applying: drm/amdgpu/gmc9: don't keep stolen memory on vega20 -- 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 5/5] [RFC]drm: add syncobj timeline support v3
在 2018/9/3 16:50, Christian König 写道:
Am 03.09.2018 um 06:13 schrieb Chunming Zhou:
在 2018/8/30 19:32, Christian König 写道:
[SNIP]
+
+struct drm_syncobj_wait_pt {
+ struct drm_syncobj_stub_fence base;
+ u64 value;
+ struct rb_node node;
+};
+struct drm_syncobj_signal_pt {
+ struct drm_syncobj_stub_fence base;
+ struct dma_fence *signal_fence;
+ struct dma_fence *pre_pt_base;
+ struct dma_fence_cb signal_cb;
+ struct dma_fence_cb pre_pt_cb;
+ struct drm_syncobj *syncobj;
+ u64 value;
+ struct list_head list;
+};
What are those two structures good for
They are used to record wait ops points and signal ops points.
For timeline, they are connected by timeline value, works like:
a. signal pt increase timeline value to signal_pt value when
signal_pt is signaled. signal_pt is depending on previous pt
fence and itself signal fence from signal ops.
b. wait pt tree checks if timeline value over itself value.
For normal, works like:
a. signal pt increase 1 for syncobj_timeline->signal_point
every time when signal ops is performed.
b. when wait ops is comming, wait pt will fetch above last
signal pt value as its wait point. wait pt will be only signaled
by equal point value signal_pt.
and why is the stub fence their base?
Good question, I tried to kzalloc for them as well when I debug
them, I encountered a problem:
I lookup/find wait_pt or signal_pt successfully, but when I tried
to use them, they are freed sometimes, and results in NULL point.
and generally, when lookup them, we often need their stub fence
as well, and in the meantime, their lifecycle are same.
Above reason, I make stub fence as their base.
That sounds like you only did this because you messed up the
lifecycle.
Additional to that I don't think you correctly considered the
lifecycle of the waits and the sync object itself. E.g. blocking
in drm_syncobj_timeline_fini() until all waits are done is not a
good idea.
What you should do instead is to create a fence_array object with
all the fence we need to wait for when a wait point is requested.
Yeah, this is our initial discussion result, but when I tried to do
that, I found that cannot meet the advance signal requirement:
a. We need to consider the wait and signal pt value are not
one-to-one match, it's difficult to find dependent point, at least,
there is some overhead.
As far as I can see that is independent of using a fence array here.
See you can either use a ring buffer or an rb-tree, but when you
want to wait for a specific point we need to condense the not yet
signaled fences into an array.
again, need to find the range of where the specific point in, we
should close to timeline semantics, I also refered the sw_sync.c
timeline, usally wait_pt is signalled by timeline point. And I agree
we can implement it with several methods, but I don't think there are
basical differences.
The problem is that with your current approach you need the sync_obj
alive for the synchronization to work. That is most likely not a good
idea.
Indeed, I will fix that. How abount only creating fence array for every
wait pt when syncobj release? when syncobj release, wait pt must have
waited the signal opertation, then we can easily condense fences for
every wait pt. And meantime, we can take timeline based wait pt advantage.
Additional to that you enable signaling without a need from the
waiting side. That is rather bad for implementations which need that
optimization.
Do you mean increasing timeline based on signal fence is not better?
only update timeline value when requested by a wait pt? This way, we
will not update timeline value immidiately and cannot free signal pt
immidiately, and we also need to consider it to CPU query and wait.
Thanks,
David Zhou
I suggest to either condense all the fences you need to wait for in an
array during the wait operation, or reference count the sync_obj and
only enable the signaling on the fences when requested by a wait.
b. because we allowed "wait-before-signal", if
"wait-before-signal" happens, there isn't signal fence which can be
used to create fence array.
Well, again we DON'T support wait-before-signal here. I will
certainly NAK any implementation which tries to do this until we
haven't figured out all the resource management constraints and I
still don't see how we can do this.
yes, we don't support real wait-before-signal in patch now, just a
fake wait-before-signal, which still wait on CS submission until
signal operation coming through wait_event, which is the conclusion
we disscussed before.
Well in this case we should call it wait-for-signal and not
wait-before-signal :)
So timeline value is good to resolve that.
Otherwise somebody can easily construct a situation where timeline
sync obj A waits on B and B waits on A.
Same situation also can happens with fence-array, we only can see
this is a programming
[Bug 107516] Firefox for WebGL fallbacks to swrast_dri.so, not using radeon_si.so
https://bugs.freedesktop.org/show_bug.cgi?id=107516 --- Comment #8 from Gian-Carlo Pascutto --- To clarify the underlying cause of this: >Earlier commit reworked our sysfs handling to use realpath. >Sadly that backfired since the Firefox sandboxing mechanism rejects >that. Despite the files/folders being in the allowed list, of the >sandboxing mechanism. The problem is that the underlying implementation of realpath() in libc will issue lstat calls on each of the path components. In Mesa's case, this will cause it to try to stat /sys, which is not on the list of allowed paths. This in turn causes the realpath() call to fail. If this failure isn't handled things broke. Firefox 62 and later will now specifically allow the stat call (only). >Oddly enough, the Chromium sandboxing doesn't complain about any of >this. I'm not sure how much of Chromium's GPU sandbox is enabled by default (on non-Chromebooks), but they literally just did the same fix as we did a few days ago: https://chromium.googlesource.com/chromium/src/+/8655d49f657d3878c937f1387b3d31fa66c8e76a%5E%21/content/gpu/gpu_sandbox_hook_linux.cc -- 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: Remove "protection" around drm_vma_offset_manager_destroy()
Using a spinlock to serialize the destroy function, within the destroy
function itself does not prevent the buggy driver from shooting
themselves in the foot - either way they still have a use-after-free
issue.
Reported-by: Jia-Ju Bai
Signed-off-by: Chris Wilson
Cc: Davidlohr Bueso
Cc: Liviu Dudau
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_vma_manager.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_vma_manager.c
b/drivers/gpu/drm/drm_vma_manager.c
index a6b2fe36b025..c5d0d2358301 100644
--- a/drivers/gpu/drm/drm_vma_manager.c
+++ b/drivers/gpu/drm/drm_vma_manager.c
@@ -103,10 +103,7 @@ EXPORT_SYMBOL(drm_vma_offset_manager_init);
*/
void drm_vma_offset_manager_destroy(struct drm_vma_offset_manager *mgr)
{
- /* take the lock to protect against buggy drivers */
- write_lock(>vm_lock);
drm_mm_takedown(>vm_addr_space_mm);
- write_unlock(>vm_lock);
}
EXPORT_SYMBOL(drm_vma_offset_manager_destroy);
--
2.19.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107781] amdgpu hangs on resume on Lenovo A475
https://bugs.freedesktop.org/show_bug.cgi?id=107781 Michel Dänzer changed: What|Removed |Added Component|Driver/AMDgpu |DRM/AMDgpu QA Contact|xorg-t...@lists.x.org | Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop ||.org Product|xorg|DRI --- Comment #3 from Michel Dänzer --- Did it work with older kernels? Does iommu=soft on the kernel command line avoid 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
[Bug 107784] [AMD tahiti XT] displayport broken
https://bugs.freedesktop.org/show_bug.cgi?id=107784 --- Comment #2 from Michel Dänzer --- Can you bisect? P.S. Please enable CONFIG_UNWINDER_ORC in your kernel build, to make the backtraces in dmesg more useful. -- 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 libdrm] libdrm: Allow dynamic drm majors on linux
On 08/31/2018 05:30 PM, Thomas Hellstrom wrote: On 08/31/2018 05:27 PM, Emil Velikov wrote: On 31 August 2018 at 15:38, Michel Dänzer wrote: [ Adding the amd-gfx list ] On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote: On 08/31/2018 02:30 PM, Emil Velikov wrote: On 31 August 2018 at 12:54, Thomas Hellstrom wrote: To determine whether a device node is a drm device node or not, the code currently compares the node's major number to the static drm major device number. This breaks the standalone vmwgfx driver on XWayland dri clients, Any particular reason why the code doesn't use a fixed node there? It will make the diff vs the in-kernel driver a bit smaller. Because then it won't be able to interoperate with other in-tree drivers, like virtual drm drivers or passthrough usb drm drivers. There is no clean way to share the minor number allocation with in-tree drm, so standalone vmwgfx is using dynamic major allocation. I wonder why I haven't heard of any of these issues with the standalone version of amdgpu shipped in packaged AMD releases. Does that also use a different major number? If yes, maybe it's just that nobody has tried Xwayland clients with that driver. If no, how does it avoid the other issues described above? AFAICT, the difference is that the standalone vmwgfx uses an internal copy of drm core. It doesn't reuse the in-kernel drm, hence it cannot know which minor it can use. -Emil Actually, standalone vmwgfx could perhaps also try to allocate minors from 63 and downwards. That might work, but needs some verification. So unfortuntately this doesn't work since the in-tree drm's file operations are registered with the DRM_MAJOR. So I still think the patch is the way to go. If people are concerned that also fbdev file descriptors are allowed, perhaps there are other sysfs traits we can look at? /Thomas /Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] add gitlab-ci builds of libdrm
On Monday, 2018-09-03 10:43:36 +0200, Daniel Vetter wrote: > On Mon, Sep 03, 2018 at 09:07:10AM +0100, Eric Engestrom wrote: > > On Monday, 2018-09-03 09:50:06 +0200, Daniel Vetter wrote: > > > On Fri, Aug 31, 2018 at 05:13:25PM +0100, Eric Engestrom wrote: > > > > On Friday, 2018-08-31 16:03:44 +0100, Daniel Stone wrote: > > > > > Hi Eric, > > > > > > > > > > On Fri, 31 Aug 2018 at 15:22, Eric Engestrom > > > > > wrote: > > > > > > +- LIBPCIACCESS_VERSION=libpciaccess-0.10 && > > > > > > + wget --no-check-certificate > > > > > > https://xorg.freedesktop.org/releases/individual/lib/$LIBPCIACCESS_VERSION.tar.bz2 > > > > > > && > > > > > > > > > > Why are you using --no-check-certificate?! > > > > > > > > Right, forgot to add a comment for this, sorry. > > > > > > > > fd.o uses LetsEncrypt, which is not present in the ca-certificate on > > > > debian:stable. I had to choose between ignoring the certificate error or > > > > use a custom CA, which just didn't seem worth it. > > > > > > Slightly more modern distro then? On the kernel side we're going with > > > fedora:latest, that also tends to have all the latest bells we > > > need for compiling some of our things. > > > > I have two distros in this pipeline: arch to test the up-to-date stuff > > and debian to test the ancient stuff. > > Should I drop debian and just keep arch to only have the up-to-date test? > > Ah, I missed that. Makes sense (if you add a comment to explain this). > > > FYI, I'm planning on adding freebsd too (later this week hopefully). > > I think cross-compiling to arm/arm64, and making sure x86 (the 32bit > stuff) keeps working would be great too. If you go to the trouble of > testing all these things :-) Good points, I forgot about testing archs; I'll add those too, thanks :) > -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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] add gitlab-ci builds of libdrm
Hi, On Mon, 3 Sep 2018 at 09:45, Daniel Vetter wrote: > On Fri, Aug 31, 2018 at 03:18:56PM +0100, Eric Engestrom wrote: > > It currently does 4 builds: 2 using Meson and 2 using Autotools, 2 using > > the latest dependencies on ArchLinux and 2 using very old dependencies > > on Debian (including manually building libpciaccess to have the oldest > > version supported, to make sure it keeps being supported). > > > > All the build options are turned on for both Meson and Autotools. > > > > Signed-off-by: Eric Engestrom > > --- > > See it in action on my fork: > > https://gitlab.freedesktop.org/eric/libdrm/pipelines/3885 > > With the --no-check-certificate things explained: > > Reviewed-by: Daniel Vetter Indeed, and also: Reviewed-by: Daniel Stone Thanks for doing this! Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] [RFC]drm: add syncobj timeline support v3
Am 03.09.2018 um 06:13 schrieb Chunming Zhou:
在 2018/8/30 19:32, Christian König 写道:
[SNIP]
+
+struct drm_syncobj_wait_pt {
+ struct drm_syncobj_stub_fence base;
+ u64 value;
+ struct rb_node node;
+};
+struct drm_syncobj_signal_pt {
+ struct drm_syncobj_stub_fence base;
+ struct dma_fence *signal_fence;
+ struct dma_fence *pre_pt_base;
+ struct dma_fence_cb signal_cb;
+ struct dma_fence_cb pre_pt_cb;
+ struct drm_syncobj *syncobj;
+ u64 value;
+ struct list_head list;
+};
What are those two structures good for
They are used to record wait ops points and signal ops points.
For timeline, they are connected by timeline value, works like:
a. signal pt increase timeline value to signal_pt value when
signal_pt is signaled. signal_pt is depending on previous pt fence
and itself signal fence from signal ops.
b. wait pt tree checks if timeline value over itself value.
For normal, works like:
a. signal pt increase 1 for syncobj_timeline->signal_point
every time when signal ops is performed.
b. when wait ops is comming, wait pt will fetch above last
signal pt value as its wait point. wait pt will be only signaled
by equal point value signal_pt.
and why is the stub fence their base?
Good question, I tried to kzalloc for them as well when I debug
them, I encountered a problem:
I lookup/find wait_pt or signal_pt successfully, but when I tried
to use them, they are freed sometimes, and results in NULL point.
and generally, when lookup them, we often need their stub fence as
well, and in the meantime, their lifecycle are same.
Above reason, I make stub fence as their base.
That sounds like you only did this because you messed up the
lifecycle.
Additional to that I don't think you correctly considered the
lifecycle of the waits and the sync object itself. E.g. blocking in
drm_syncobj_timeline_fini() until all waits are done is not a good
idea.
What you should do instead is to create a fence_array object with
all the fence we need to wait for when a wait point is requested.
Yeah, this is our initial discussion result, but when I tried to do
that, I found that cannot meet the advance signal requirement:
a. We need to consider the wait and signal pt value are not
one-to-one match, it's difficult to find dependent point, at least,
there is some overhead.
As far as I can see that is independent of using a fence array here.
See you can either use a ring buffer or an rb-tree, but when you want
to wait for a specific point we need to condense the not yet signaled
fences into an array.
again, need to find the range of where the specific point in, we
should close to timeline semantics, I also refered the sw_sync.c
timeline, usally wait_pt is signalled by timeline point. And I agree
we can implement it with several methods, but I don't think there are
basical differences.
The problem is that with your current approach you need the sync_obj
alive for the synchronization to work. That is most likely not a good idea.
Additional to that you enable signaling without a need from the waiting
side. That is rather bad for implementations which need that optimization.
I suggest to either condense all the fences you need to wait for in an
array during the wait operation, or reference count the sync_obj and
only enable the signaling on the fences when requested by a wait.
b. because we allowed "wait-before-signal", if
"wait-before-signal" happens, there isn't signal fence which can be
used to create fence array.
Well, again we DON'T support wait-before-signal here. I will
certainly NAK any implementation which tries to do this until we
haven't figured out all the resource management constraints and I
still don't see how we can do this.
yes, we don't support real wait-before-signal in patch now, just a
fake wait-before-signal, which still wait on CS submission until
signal operation coming through wait_event, which is the conclusion we
disscussed before.
Well in this case we should call it wait-for-signal and not
wait-before-signal :)
So timeline value is good to resolve that.
Otherwise somebody can easily construct a situation where timeline
sync obj A waits on B and B waits on A.
Same situation also can happens with fence-array, we only can see
this is a programming bug with incorrect use.
No, fence-array is initialized only once with a static list of
fences. This way it is impossible to add the fence-array to itself
for example.
E.g. you can't build circle dependencies with that.
we already wait for signal operation event, so never build circle
dependencies with that. The theory is same.
Yeah, ok that is certainly true.
Regards,
Christian.
Better use rbtree_postorder_for_each_entry_safe() for this.
From the comments, seems we cannot use it here, we need erase node
here.
Comments:
* Note, however, that it cannot handle other modifications that
re-order the
* rbtree it
[PATCH libdrm] Add basic CONTRIBUTING file
I picked up a bunch of the pieces from wayland's version:
https://gitlab.freedesktop.org/wayland/wayland/blob/master/CONTRIBUTING.md
The weston one is fairly similar. Then I rather massively trimmed it
down since in reality libdrm is a bit a dumping ground with very few
real rules. The commit rights and CoC sections I've copied verbatim
from igt respectively drm-misc. Weston/Wayland only differ in their
pick of how many patches you need (10 instead of 5). I think for
libdrm this is supremely relevant, since most everyone will get their
commit rights by contributing already to the kernel or mesa and having
commit rights there already.
Anyway, I figured this is good to get the rules documented, even if
there's mostly not many rules.
Note: This references maintainers in a MAINTAINERS file, which needs
to be created first.
Note: With the gitlab migration the entire commit rights process is
still a bit up in the air. But gitlab commit rights and roles are
hierarchical, so we can do libdrm-only maintainer/commiter roles
("Owner" and "Developer" in gitlab-speak). This should avoid
conflating libdrm roles with mesa roles, useful for those pushing to
libdrm as primarily kernel contributors.
v2: Comments from Emil:
- Recommend subject prefix.
- Fix copypaste fumbles, this isn't igt/wayland ...
v3: Comments from Marek:
- libdrm moved to mesa, update the document. Atm the entire account
request situation is entirely not clear for gitlab and mesa
projects, so that's a bit up in the air. Also, should probably send
an announcement to dri-devel@, which didn't happen.
- amd folks don't submit their patches to dri-devel, document that.
Probably applies to other drivers too.
v4: Comments from Rob:
- Also include kernel/userspace in the commit counts criteria, due to
libdrm's special role as a glue library.
v5: Summarize the irc discussion on gitlab roles in the commit message
a bit.
v6: Some grammer stuff from Eric E.
v7: Use --local in git config (Eric E.)
Cc: Dave Airlie
Cc: Michel Dänzer
Cc: Emil Velikov
Cc: Marek Olšák
Cc: Rob Clark
Cc: Eric Engestrom
Reviewed-by: Rob Clark (v4)
Reviewed-by: Eric Engestrom (v6)
Acked-by: Emil Velikov (v6)
Acked-by: Marek Olšák (v5)
References:
https://gitlab.freedesktop.org/wayland/weston/blob/master/CONTRIBUTING.md
References:
https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html#commit-rights
References: https://cgit.freedesktop.org/drm/igt-gpu-tools/tree/CONTRIBUTING#n54
Signed-off-by: Daniel Vetter
---
CONTRIBUTING | 105 +++
1 file changed, 105 insertions(+)
create mode 100644 CONTRIBUTING
diff --git a/CONTRIBUTING b/CONTRIBUTING
new file mode 100644
index ..96f1e4fb0108
--- /dev/null
+++ b/CONTRIBUTING
@@ -0,0 +1,105 @@
+Contributing to libdrm
+==
+
+Submitting Patches
+--
+
+Patches should be sent to dri-devel@lists.freedesktop.org, using git
+send-email. For patches only touching driver specific code one of the driver
+mailing lists (like amd-...@lists.freedesktop.org) is also appropriate. See git
+documentation for help:
+
+http://git-scm.com/documentation
+
+Since dri-devel is a very busy mailing list please use --subject-prefix="PATCH
+libdrm" to make it easier to find libdrm patches. This is best done by running
+
+git config --local format.subjectprefix "PATCH libdrm"
+
+The first line of a commit message should contain a prefix indicating what part
+is affected by the patch followed by one sentence that describes the change.
For
+examples:
+
+amdgpu: Use uint32_t i in amdgpu_find_bo_by_cpu_mapping
+
+The body of the commit message should describe what the patch changes and why,
+and also note any particular side effects. For a recommended reading on
+writing commit messages, see:
+
+http://who-t.blogspot.de/2009/12/on-commit-messages.html
+
+Your patches should also include a Signed-off-by line with your name and email
+address. If you're not the patch's original author, you should also gather
+S-o-b's by them (and/or whomever gave the patch to you.) The significance of
+this is that it certifies that you created the patch, that it was created under
+an appropriate open source license, or provided to you under those terms. This
+lets us indicate a chain of responsibility for the copyright status of the
code.
+For more details:
+
+https://developercertificate.org/
+
+We won't reject patches that lack S-o-b, but it is strongly recommended.
+
+Review and Merging
+--
+
+Patches should have at least one positive review (Reviewed-by: tag) or
+indication of approval (Acked-by: tag) before merging. For any code shared
+between drivers this is mandatory.
+
+Please note that kernel/userspace API header files have special rules, see
+include/drm/README.
+
+Coding style in the project loosely follows the CodingStyle of the linux
kernel:
+
[Bug 105733] Amdgpu randomly hangs and only ssh works. Mouse cursor moves sometimes but does nothing. Keyboard stops working.
https://bugs.freedesktop.org/show_bug.cgi?id=105733 --- Comment #36 from markusr...@gmail.com --- (In reply to markusraat from comment #35) > It might be that kernel option apci=ht ( also apci=off ) solve the problem. > It is taking more time to waiting the possible problem appearance. At least > it worth of testing. But this is not maybe the final solution for this bug? > > [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.18.5-041805-generic > root=UUID=c3df607f-ac6e-11e8-9f6b-3497f638e103 ro acpi=ht > [0.00] Malformed early option 'acpi' Okay, the "acpi=off" or "acpi=ht" was the miss shot. But changing from motherboard bios GPU PCIe speed auto > gen3 is giving very promissing results! I also rose logging level from grub settings to "loglevel=8" but I haven't got regenerated the crash. I will reply if this fails again. -- 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 libdrm] add gitlab-ci builds of libdrm
On Fri, Aug 31, 2018 at 03:18:56PM +0100, Eric Engestrom wrote: > It currently does 4 builds: 2 using Meson and 2 using Autotools, 2 using > the latest dependencies on ArchLinux and 2 using very old dependencies > on Debian (including manually building libpciaccess to have the oldest > version supported, to make sure it keeps being supported). > > All the build options are turned on for both Meson and Autotools. > > Signed-off-by: Eric Engestrom > --- > See it in action on my fork: > https://gitlab.freedesktop.org/eric/libdrm/pipelines/3885 With the --no-check-certificate things explained: Reviewed-by: Daniel Vetter > --- > .gitlab-ci.yml | 173 + > 1 file changed, 173 insertions(+) > create mode 100644 .gitlab-ci.yml > > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml > new file mode 100644 > index ..a0f3ecb9d7f7f95443a7 > --- /dev/null > +++ b/.gitlab-ci.yml > @@ -0,0 +1,173 @@ > +latest-meson: > + stage: build > + image: base/archlinux:latest > + before_script: > +- pacman -Syu --noconfirm --needed > +base-devel > +meson > +libpciaccess > +libxslt docbook-xsl > +valgrind > +libatomic_ops > +cairo cunit > + script: > +- meson _build > +-D amdgpu=true > +-D cairo-tests=true > +-D etnaviv=true > +-D exynos=true > +-D freedreno=true > +-D freedreno-kgsl=true > +-D intel=true > +-D libkms=true > +-D man-pages=true > +-D nouveau=true > +-D omap=true > +-D radeon=true > +-D tegra=true > +-D udev=true > +-D valgrind=true > +-D vc4=true > +-D vmwgfx=true > +- ninja -C _build > +- ninja -C _build test > + > +latest-autotools: > + stage: build > + image: base/archlinux:latest > + before_script: > +- pacman -Syu --noconfirm --needed > +base-devel > +libpciaccess > +libxslt docbook-xsl > +valgrind > +libatomic_ops > +cairo cunit > +xorg-util-macros > +git # autogen.sh depends on git > + script: > +- mkdir _build > +- cd _build > +- ../autogen.sh > +--enable-udev > +--enable-libkms > +--enable-intel > +--enable-radeon > +--enable-admgpu > +--enable-nouveau > +--enable-vmwfgx > +--enable-omap-experimental-api > +--enable-exynos-experimental-api > +--enable-freedreno > +--enable-freedreno-kgsl > +--enable-tegra-experimental-api > +--enable-vc4 > +--enable-etnaviv-experimental-api > +- make > +- make check > + > +oldest-meson: > + stage: build > + image: debian:stable > + before_script: > +- printf > /etc/dpkg/dpkg.cfg.d/99-exclude-cruft "%s\n" > +'path-exclude=/usr/share/doc/*' > +'path-exclude=/usr/share/man/*' > +- printf > /usr/sbin/policy-rc.d "%s\n" > +'#!/bin/sh' > +'exit 101' > +- chmod +x /usr/sbin/policy-rc.d > +- apt-get update > +- apt-get -y --no-install-recommends install > +build-essential > +pkg-config > +xsltproc > +libxslt1-dev docbook-xsl > +valgrind > +libatomic-ops-dev > +libcairo2-dev libcunit1-dev > +ninja-build > +python3 python3-pip > +wget > +- LIBPCIACCESS_VERSION=libpciaccess-0.10 && > + wget --no-check-certificate > https://xorg.freedesktop.org/releases/individual/lib/$LIBPCIACCESS_VERSION.tar.bz2 > && > + tar -jxvf $LIBPCIACCESS_VERSION.tar.bz2 && > + (cd $LIBPCIACCESS_VERSION && ./configure --prefix=$HOME/prefix && make > install) > +- pip3 install wheel setuptools > +- pip3 install meson==0.43 > + script: > +- export > PKG_CONFIG_PATH=$HOME/prefix/lib/pkgconfig:$HOME/prefix/share/pkgconfig > +- export LD_LIBRARY_PATH="$HOME/prefix/lib:$LD_LIBRARY_PATH" > +- meson _build > +-D amdgpu=true > +-D cairo-tests=true > +-D etnaviv=true > +-D exynos=true > +-D freedreno=true > +-D freedreno-kgsl=true > +-D intel=true > +-D libkms=true > +-D man-pages=true > +-D nouveau=true > +-D omap=true > +-D radeon=true > +-D tegra=true > +-D udev=true > +-D valgrind=true > +-D vc4=true > +-D vmwgfx=true > +- ninja -C _build > +- ninja -C _build test > + > +oldest-autotools: > + stage: build > + image: debian:stable > + before_script: > +- printf > /etc/dpkg/dpkg.cfg.d/99-exclude-cruft "%s\n" > +'path-exclude=/usr/share/doc/*' > +'path-exclude=/usr/share/man/*' > +- printf > /usr/sbin/policy-rc.d "%s\n" > +'#!/bin/sh' > +'exit 101' > +- chmod +x /usr/sbin/policy-rc.d > +- apt-get update > +- apt-get -y --no-install-recommends install > +
Re: [PATCH libdrm] add gitlab-ci builds of libdrm
On Mon, Sep 03, 2018 at 09:07:10AM +0100, Eric Engestrom wrote: > On Monday, 2018-09-03 09:50:06 +0200, Daniel Vetter wrote: > > On Fri, Aug 31, 2018 at 05:13:25PM +0100, Eric Engestrom wrote: > > > On Friday, 2018-08-31 16:03:44 +0100, Daniel Stone wrote: > > > > Hi Eric, > > > > > > > > On Fri, 31 Aug 2018 at 15:22, Eric Engestrom > > > > wrote: > > > > > +- LIBPCIACCESS_VERSION=libpciaccess-0.10 && > > > > > + wget --no-check-certificate > > > > > https://xorg.freedesktop.org/releases/individual/lib/$LIBPCIACCESS_VERSION.tar.bz2 > > > > > && > > > > > > > > Why are you using --no-check-certificate?! > > > > > > Right, forgot to add a comment for this, sorry. > > > > > > fd.o uses LetsEncrypt, which is not present in the ca-certificate on > > > debian:stable. I had to choose between ignoring the certificate error or > > > use a custom CA, which just didn't seem worth it. > > > > Slightly more modern distro then? On the kernel side we're going with > > fedora:latest, that also tends to have all the latest bells we > > need for compiling some of our things. > > I have two distros in this pipeline: arch to test the up-to-date stuff > and debian to test the ancient stuff. > Should I drop debian and just keep arch to only have the up-to-date test? Ah, I missed that. Makes sense (if you add a comment to explain this). > FYI, I'm planning on adding freebsd too (later this week hopefully). I think cross-compiling to arm/arm64, and making sure x86 (the 32bit stuff) keeps working would be great too. If you go to the trouble of testing all these things :-) -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 107793] Black screen on boot for Fedora 28 with 4.17 kernel (i.e. with amdgpu.dc defaulted)
https://bugs.freedesktop.org/show_bug.cgi?id=107793 --- Comment #2 from Simon Geard --- Created attachment 141424 --> https://bugs.freedesktop.org/attachment.cgi?id=141424=edit Output of dmesg on successful boot -- 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 107793] Black screen on boot for Fedora 28 with 4.17 kernel (i.e. with amdgpu.dc defaulted)
https://bugs.freedesktop.org/show_bug.cgi?id=107793 --- Comment #1 from Simon Geard --- Created attachment 141423 --> https://bugs.freedesktop.org/attachment.cgi?id=141423=edit Output of lspci on successful boot -- 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 107793] Black screen on boot for Fedora 28 with 4.17 kernel (i.e. with amdgpu.dc defaulted)
https://bugs.freedesktop.org/show_bug.cgi?id=107793 Bug ID: 107793 Summary: Black screen on boot for Fedora 28 with 4.17 kernel (i.e. with amdgpu.dc defaulted) Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: simon.ge...@gmail.com Created attachment 141422 --> https://bugs.freedesktop.org/attachment.cgi?id=141422=edit Contents of /proc/cpuinfo on successful boot My Fedora 28 desktop stopped booting up cleanly after switching to the 4.17 kernel where amdgpu.dc became the default... the system seems to be working (e.g when installing updates, it automatically reboots once done), but the screen goes black immediately after grub loads the kernel, and it remains that way indefinitely. Passing "amdgpu.dc=0" on the kernel command line resolves the problem. The active graphics card is an AMD RX-470, the CPU is an AMD A10-7850k (with unused onboard graphics). This was logged on the RedHat bugzilla, but after receiving no response in over a month, I've opted to log it here instead. Here's the link to the downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=1601812 I've re-attached the same files provided there – the output of lspci, dmesg, and /proc/cpuinfo for a successful boot – but if you need anything else to track this down, let me know. -- 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 v2 4/5] drm: Add support for handling linear tile formats
On Mon, Sep 03, 2018 at 09:26:24AM +0200, Daniel Vetter wrote:
> On Fri, Aug 31, 2018 at 05:26:37PM +0100, Alexandru-Cosmin Gheorghe wrote:
> > Hi,
> >
> > On Fri, Aug 31, 2018 at 05:12:24PM +0200, Daniel Vetter wrote:
> > > On Fri, Aug 31, 2018 at 02:20:31PM +0300, Ville Syrjälä wrote:
> > > > On Fri, Aug 31, 2018 at 10:14:14AM +0200, Daniel Vetter wrote:
> > > > > On Thu, Aug 23, 2018 at 06:43:40PM +0100, Alexandru-Cosmin Gheorghe
> > > > > wrote:
> > > > > > On Wed, Aug 22, 2018 at 10:18:51PM +0200, Daniel Vetter wrote:
> > > > > > > On Tue, Aug 21, 2018 at 07:30:03PM +0100, Alexandru Gheorghe
> > > > > > > wrote:
> > > > > > > > The previous patch added tile_w and tile_h, which represent the
> > > > > > > > horizontal and vertical sizes of a tile.
> > > > > > > >
> > > > > > > > This one uses that to plumb through drm core in order to be
> > > > > > > > able to
> > > > > > > > handle linear tile formats without the need for drivers to roll
> > > > > > > > up
> > > > > > > > their own implementation.
> > > > > > > >
> > > > > > > > This patch had been written with Mali-dp X0L2 and X0L0 in mind
> > > > > > > > which
> > > > > > > > is a 1 plane YCbCr 420 format with a 2x2 tile, that uses in
> > > > > > > > average 2
> > > > > > > > bytes per pixel and where tiles are laid out in a linear manner.
> > > > > > > >
> > > > > > > > Now what are the restrictions:
> > > > > > > >
> > > > > > > > 1. Pitch in bytes is expected to cover at least tile_h * width
> > > > > > > > in
> > > > > > > > pixels. Due to this the places where the pitch is checked/used
> > > > > > > > need to
> > > > > > > > be updated to take into consideration the tile_w, tile_h and
> > > > > > > > tile_size.
> > > > > > > > tile_size = cpp * tile_w * tile_h
> > > > > > > >
> > > > > > > > 2. When doing source cropping plane_src_x/y need to be a
> > > > > > > > multiple of
> > > > > > > > tile_w/tile_h and we need to take into consideration the
> > > > > > > > tile_w/tile_h
> > > > > > > > when computing the start address.
> > > > > > > >
> > > > > > > > For all non-tiled formats the tile_w and tile_h will be 1, so
> > > > > > > > if I
> > > > > > > > didn't miss anything nothing should change.
> > > > > > > >
> > > > > > > > Regarding multi-planar linear tile formats, I'm not sure how
> > > > > > > > those
> > > > > > > > should be handle I kind of assumed that tile_h/tile_w will have
> > > > > > > > to be
> > > > > > > > divided by horizontal/subsampling. Anyway, I think it's best to
> > > > > > > > just
> > > > > > > > put an warning in there and handle it when someone tries to add
> > > > > > > > support for them.
> > > > > > > >
> > > > > > > > Signed-off-by: Alexandru Gheorghe
> > > > > > > >
> > > > > > > > ---
> > > > > > > > drivers/gpu/drm/drm_atomic.c | 8 +++
> > > > > > > > drivers/gpu/drm/drm_fb_cma_helper.c | 11 -
> > > > > > > > drivers/gpu/drm/drm_fourcc.c | 52
> > > > > > > >
> > > > > > > > drivers/gpu/drm/drm_framebuffer.c| 19 +--
> > > > > > > > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 10 ++--
> > > > > > > > include/drm/drm_fourcc.h | 2 +
> > > > > > > > 6 files changed, 94 insertions(+), 8 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/drivers/gpu/drm/drm_atomic.c
> > > > > > > > b/drivers/gpu/drm/drm_atomic.c
> > > > > > > > index 3eb061e11e2e..7a3e893a4cd1 100644
> > > > > > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > > > > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > > > > > > @@ -1087,6 +1087,14 @@ static int drm_atomic_plane_check(struct
> > > > > > > > drm_plane *plane,
> > > > > > > > return -ENOSPC;
> > > > > > > > }
> > > > > > > >
> > > > > > > > + /* Make sure source coordinates are a multiple of tile
> > > > > > > > sizes */
> > > > > > > > + if ((state->src_x >> 16) % state->fb->format->tile_w ||
> > > > > > > > + (state->src_y >> 16) % state->fb->format->tile_h) {
> > > > > > > > + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] Source
> > > > > > > > coordinates do not meet tile restrictions",
> > > > > > > > +plane->base.id, plane->name);
> > > > > > > > + return -EINVAL;
> > > > > > > > + }
> > > > > > > > +
> > > > > > > > if (plane_switching_crtc(state->state, plane, state)) {
> > > > > > > > DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC
> > > > > > > > directly\n",
> > > > > > > > plane->base.id, plane->name);
> > > > > > > > diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> > > > > > > > b/drivers/gpu/drm/drm_fb_cma_helper.c
> > > > > > > > index 47e0e2f6642d..4d8052adce67 100644
> > > > > > > > --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> > > > > > > > +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> > > > > > > > @@ -87,6 +87,8 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct
> > > > > >
Re: [PATCH libdrm] add gitlab-ci builds of libdrm
On Monday, 2018-09-03 09:50:06 +0200, Daniel Vetter wrote: > On Fri, Aug 31, 2018 at 05:13:25PM +0100, Eric Engestrom wrote: > > On Friday, 2018-08-31 16:03:44 +0100, Daniel Stone wrote: > > > Hi Eric, > > > > > > On Fri, 31 Aug 2018 at 15:22, Eric Engestrom > > > wrote: > > > > +- LIBPCIACCESS_VERSION=libpciaccess-0.10 && > > > > + wget --no-check-certificate > > > > https://xorg.freedesktop.org/releases/individual/lib/$LIBPCIACCESS_VERSION.tar.bz2 > > > > && > > > > > > Why are you using --no-check-certificate?! > > > > Right, forgot to add a comment for this, sorry. > > > > fd.o uses LetsEncrypt, which is not present in the ca-certificate on > > debian:stable. I had to choose between ignoring the certificate error or > > use a custom CA, which just didn't seem worth it. > > Slightly more modern distro then? On the kernel side we're going with > fedora:latest, that also tends to have all the latest bells we > need for compiling some of our things. I have two distros in this pipeline: arch to test the up-to-date stuff and debian to test the ancient stuff. Should I drop debian and just keep arch to only have the up-to-date test? FYI, I'm planning on adding freebsd too (later this week hopefully). > -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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: drm: drm_mm: Fix a sleep-in-atomic-context bug in show_leaks()
On Sat, Sep 01, 2018 at 01:32:54PM +0100, Chris Wilson wrote: > Quoting Jia-Ju Bai (2018-09-01 13:20:41) > > The driver may sleep with holding a spinlock. > > > > The function call paths (from bottom to top) in Linux-4.16 are: > > > > [FUNC] kmalloc(GFP_KERNEL) > > drivers/gpu/drm/drm_mm.c, 130: > > kmalloc in show_leaks > > drivers/gpu/drm/drm_mm.c, 913: > > show_leaks in drm_mm_takedown > > drivers/gpu/drm/drm_vma_manager.c, 107: > > drm_mm_takedown in drm_vma_offset_manager_destroy > > drivers/gpu/drm/drm_vma_manager.c, 106: > > _raw_write_lock in drm_vma_offset_manager_destroy > > > > [FUNC] kmalloc(GFP_KERNEL) > > drivers/gpu/drm/drm_mm.c, 130: > > kmalloc in show_leaks > > drivers/gpu/drm/drm_mm.c, 913: > > show_leaks in drm_mm_takedown > > drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c, 71: > > drm_mm_takedown in amdgpu_vram_mgr_fini > > drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c, 70: > > spin_lock in amdgpu_vram_mgr_fini > > > > [FUNC] kmalloc(GFP_KERNEL) > > drivers/gpu/drm/drm_mm.c, 130: > > kmalloc in show_leaks > > drivers/gpu/drm/drm_mm.c, 913: > > show_leaks in drm_mm_takedown > > drivers/gpu/drm/ttm/ttm_bo_manager.c, 128: > > drm_mm_takedown in ttm_bo_man_takedown > > drivers/gpu/drm/ttm/ttm_bo_manager.c, 126: > > spin_lock in ttm_bo_man_takedown > > > > To fix this bug, GFP_KERNEL is replaced with GFP_ATOMIC. > > The bug are above, since those spinlocks do not protect the data and > imply use-after-free. Adding amdgpu, since that's where the bug seems to be. -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
