RE: [PATCH 06/10] drm/ttm: fix busy memory to fail other user v10
Use Abaqus torturing the amdgpu driver more times will running into locking
first busy BO deadlock .Then the caller will
return EAGAIN and eventually dm_plane_helper_prepare_fb popups out pinned
failed message .For this case, the patch#7
can we add EAGAIN as ERESTARTSYS which filter out the annoying error message .
Thanks,
Prike
-Original Message-
From: Christian König
Sent: Thursday, May 23, 2019 7:04 PM
To: Zhou, David(ChunMing) ; Olsak, Marek
; Zhou, David(ChunMing) ; Liang,
Prike ; dri-devel@lists.freedesktop.org;
amd-...@lists.freedesktop.org
Subject: Re: [PATCH 06/10] drm/ttm: fix busy memory to fail other user v10
[CAUTION: External Email]
Am 23.05.19 um 12:24 schrieb zhoucm1:
>
>
> On 2019年05月22日 20:59, Christian König wrote:
>> [CAUTION: External Email]
>>
>> BOs on the LRU might be blocked during command submission and cause
>> OOM situations.
>>
>> Avoid this by blocking for the first busy BO not locked by the same
>> ticket as the BO we are searching space for.
>>
>> v10: completely start over with the patch since we didn't
>> handled a whole bunch of corner cases.
>>
>> Signed-off-by: Christian König
>> ---
>> drivers/gpu/drm/ttm/ttm_bo.c | 77 ++--
>> 1 file changed, 66 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
>> b/drivers/gpu/drm/ttm/ttm_bo.c index 4c6389d849ed..861facac33d4
>> 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>> @@ -771,32 +771,72 @@ EXPORT_SYMBOL(ttm_bo_eviction_valuable);
>>* b. Otherwise, trylock it.
>>*/
>> static bool ttm_bo_evict_swapout_allowable(struct ttm_buffer_object
>> *bo,
>> - struct ttm_operation_ctx *ctx, bool *locked)
>> + struct ttm_operation_ctx *ctx, bool *locked,
>> bool *busy)
>> {
>> bool ret = false;
>>
>> - *locked = false;
>> if (bo->resv == ctx->resv) {
>> reservation_object_assert_held(bo->resv);
>> if (ctx->flags & TTM_OPT_FLAG_ALLOW_RES_EVICT
>> || !list_empty(>ddestroy))
>> ret = true;
>> + *locked = false;
>> + if (busy)
>> + *busy = false;
>> } else {
>> - *locked = reservation_object_trylock(bo->resv);
>> - ret = *locked;
>> + ret = reservation_object_trylock(bo->resv);
>> + *locked = ret;
>> + if (busy)
>> + *busy = !ret;
>> }
>>
>> return ret;
>> }
>>
>> +/**
>> + * ttm_mem_evict_wait_busy - wait for a busy BO to become available
>> + *
>> + * @busy_bo: BO which couldn't be locked with trylock
>> + * @ctx: operation context
>> + * @ticket: acquire ticket
>> + *
>> + * Try to lock a busy buffer object to avoid failing eviction.
>> + */
>> +static int ttm_mem_evict_wait_busy(struct ttm_buffer_object *busy_bo,
>> + struct ttm_operation_ctx *ctx,
>> + struct ww_acquire_ctx *ticket) {
>> + int r;
>> +
>> + if (!busy_bo || !ticket)
>> + return -EBUSY;
>> +
>> + if (ctx->interruptible)
>> + r =
>> + reservation_object_lock_interruptible(busy_bo->resv,
>> + ticket);
>> + else
>> + r = reservation_object_lock(busy_bo->resv, ticket);
>> +
>> + /*
>> +* TODO: It would be better to keep the BO locked until
>> allocation is at
>> +* least tried one more time, but that would mean a much
>> larger rework
>> +* of TTM.
>> +*/
>> + if (!r)
>> + reservation_object_unlock(busy_bo->resv);
>> +
>> + return r == -EDEADLK ? -EAGAIN : r; }
>> +
>> static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
>> uint32_t mem_type,
>> const struct ttm_place *place,
>> - struct ttm_operation_ctx *ctx)
>> + struct ttm_operation_ctx *ctx,
>> + struct ww_acquire_ctx *ticket)
>> {
>> + struct ttm_buffer_object *bo = NULL, *busy_bo = NULL;
>> struct ttm_bo_global *glob = bdev->glob;
>> struct ttm_mem_type_manager *man = >man[mem_type];
>> - struct ttm_buffer_object *bo = NULL;
>> bool locked = false;
>> unsigned i;
>> int ret;
>> @@ -804,8 +844,15 @@ static int ttm_mem_evict_first(struct
>> ttm_bo_device *bdev,
>> spin_lock(>lru_lock);
>> for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
>> list_for_each_entry(bo, >lru[i], lru) {
>> - if (!ttm_bo_evict_swapout_allowable(bo, ctx,
>> ))
>> + bool busy;
>> +
>> + if (!ttm_bo_evict_swapout_allowable(bo, ctx,
>> ,
>> + )) {
>> + if (busy &&
Re: [PATCH 1/2] update drm.h
anyone can pick up to gitlab for libdrm?
Thanks,
-David
On 2019年05月22日 18:46, Koenig, Christian wrote:
Am 22.05.19 um 11:07 schrieb Chunming Zhou:
a) delta: only DRM_CAP_SYNCOBJ_TIMELINE
b) Generated using make headers_install.
c) Generated from origin/drm-misc-next commit
982c0500fd1a8012c31d3c9dd8de285129904656"
Signed-off-by: Chunming Zhou
Suggested-by: Michel Dänzer
Reviewed-by: Christian König
---
include/drm/drm.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index c893f3b4..438abde3 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -44,6 +44,7 @@ typedef unsigned int drm_handle_t;
#else /* One of the BSDs */
+#include
#include
#include
typedef int8_t __s8;
@@ -643,6 +644,7 @@ struct drm_gem_open {
#define DRM_CAP_PAGE_FLIP_TARGET 0x11
#define DRM_CAP_CRTC_IN_VBLANK_EVENT 0x12
#define DRM_CAP_SYNCOBJ 0x13
+#define DRM_CAP_SYNCOBJ_TIMELINE 0x14
/** DRM_IOCTL_GET_CAP ioctl argument type */
struct drm_get_cap {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
https://bugs.freedesktop.org/show_bug.cgi?id=109955 --- Comment #22 from Mauro Gaspari --- I ran more tests: 1. Installed Arch Linux, vulkan, llvm8 and ran wine games with DXVK. With same kernel parameters on grub, no freezes, no crashes. Great performance. 2. Installed Ubuntu Budgie 19.04, Oibaf ppa, updated mesa and llvm8. Same as with Arch Linux: With same kernel parameters on grub, no freezes, no crashes. Great performance. The only issue I have not being able to reproduce the issue quickly, is to clearly understand when the issue is resolved by Mesa. It takes hours for me to get the freeze sometimes. If someone has a quick way to trigger system freeze, I am happy to run more tests. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes for 5.2-rc2
Hey Linus, Nothing too unusual here for rc2. i915: - boosting fix - bump ready task fixes - GVT - reset fix, error return, TRTT handling fix amdgpu: - DMCU firmware loading fix - Polaris 10 pci id for kfd - picasso screen corruption fix - SR-IOV fixes - vega driver reload fixes - SMU locking fix - compute profile fix for kfd vmwgfx: - integer overflow fixes - dma sg fix sun4i: - HDMI phy fixes gma500: - LVDS detection fix panfrost: - devfreq selection fix drm-fixes-2019-05-24: drm i915, amdgpu, vmwgfx, sun4i, panfrost, gma500 fixes. The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9: Linux 5.2-rc1 (2019-05-19 15:47:09 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-05-24 for you to fetch changes up to e1e52981f292b4e321781794eaf6e8a087f4f300: Merge tag 'drm-intel-fixes-2019-05-23' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2019-05-24 14:01:00 +1000) drm i915, amdgpu, vmwgfx, sun4i, panfrost, gma500 fixes. Alex Deucher (2): drm/amdgpu/soc15: skip reset on init drm/amdgpu/gmc9: set vram_width properly for SR-IOV Chris Wilson (5): drm/i915: Rearrange i915_scheduler.c drm/i915: Pass i915_sched_node around internally drm/i915: Bump signaler priority on adding a waiter drm/i915: Downgrade NEWCLIENT to non-preemptive drm/i915: Truly bump ready tasks ahead of busywaits Dan Carpenter (2): drm/amd/powerplay: fix locking in smu_feature_set_supported() drm/i915/gvt: Fix an error code in ppgtt_populate_spt_by_guest_entry() Dave Airlie (4): Merge branch 'vmwgfx-fixes-5.2' of git://people.freedesktop.org/~thomash/linux into drm-fixes Merge tag 'drm-misc-fixes-2019-05-22' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Merge branch 'drm-fixes-5.2' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge tag 'drm-intel-fixes-2019-05-23' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Ezequiel Garcia (1): drm/panfrost: Select devfreq Flora Cui (1): drm/amdgpu: keep stolen memory on picasso Harish Kasiviswanathan (1): drm/amdkfd: Fix compute profile switching Harry Wentland (2): drm/amd/display: Add ASICREV_IS_PICASSO drm/amd/display: Don't load DMCU for Raven 1 Jagan Teki (1): drm/sun4i: sun6i_mipi_dsi: Fix hsync_porch overflow Jernej Skrabec (2): drm/sun4i: Fix sun8i HDMI PHY clock initialization drm/sun4i: Fix sun8i HDMI PHY configuration for > 148.5 MHz Joonas Lahtinen (1): Merge tag 'gvt-fixes-2019-05-21' of https://github.com/intel/gvt-linux into drm-intel-fixes Kent Russell (1): drm/amdkfd: Add missing Polaris10 ID Murray McAllister (2): drm/vmwgfx: NULL pointer dereference from vmw_cmd_dx_view_define() drm/vmwgfx: integer underflow in vmw_cmd_dx_set_shader() leading to an invalid read Patrik Jakobsson (1): drm/gma500/cdv: Check vbt config bits when detecting lvds panels Sean Paul (1): Merge drm-misc-next-fixes-2019-05-20 into drm-misc-fixes Thomas Hellstrom (4): drm/vmwgfx: Don't send drm sysfs hotplug events on initial master set drm/vmwgfx: Fix user space handle equal to zero drm/vmwgfx: Fix compat mode shader operation drm/vmwgfx: Use the dma scatter-gather iterator to get dma addresses Weinan (1): drm/i915/gvt: emit init breadcrumb for gvt request Yan Zhao (4): drm/i915/gvt: use cmd to restore in-context mmios to hw for gen9 platform drm/i915/gvt: Tiled Resources mmios are in-context mmios for gen9+ drm/i915/gvt: add 0x4dfc to gen9 save-restore list drm/i915/gvt: do not let TRTTE and 0x4dfc write passthrough to hardware Yintian Tao (1): drm/amdgpu: skip fw pri bo alloc for SRIOV drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c| 17 +- drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 11 +- drivers/gpu/drm/amd/amdgpu/soc15.c | 5 + drivers/gpu/drm/amd/amdkfd/kfd_device.c| 17 ++ .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 11 +- drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 7 + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 12 +- drivers/gpu/drm/amd/display/include/dal_asic_id.h | 7 +- drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 2 +- drivers/gpu/drm/gma500/cdv_intel_lvds.c| 3 + drivers/gpu/drm/gma500/intel_bios.c| 3 + drivers/gpu/drm/gma500/psb_drv.h | 1 + drivers/gpu/drm/i915/gvt/cmd_parser.c | 14 +- drivers/gpu/drm/i915/gvt/gtt.c | 4 +- drivers/gpu/drm/i915/gvt/handlers.c| 15 -- drivers/gpu/drm/i915/gvt/mmio_context.c| 23 +- drivers/gpu/drm/i915/gvt/scheduler.c | 23 +-
[PATCH] drm/komeda: Accept null writeback configurations for writeback
User may send null writeback configurations for writeback connector like:
- Only bind the writeback connector to crtc.
- set a fb_id(0) to writeback_fb_id_property
All above configurations are meaningless for writeback, but since they are
still valid configurations, accept them.
Depends on:
- https://patchwork.freedesktop.org/series/60856/
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../gpu/drm/arm/display/komeda/komeda_wb_connector.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
index 20295291572f..0d734244f662 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
@@ -13,11 +13,7 @@ komeda_wb_init_data_flow(struct komeda_layer *wb_layer,
struct komeda_crtc_state *kcrtc_st,
struct komeda_data_flow_cfg *dflow)
{
- struct drm_framebuffer *fb = conn_st->writeback_job ?
-conn_st->writeback_job->fb : NULL;
-
- if (!fb)
- return -EINVAL;
+ struct drm_framebuffer *fb = conn_st->writeback_job->fb;
memset(dflow, 0, sizeof(*dflow));
@@ -42,10 +38,15 @@ komeda_wb_encoder_atomic_check(struct drm_encoder *encoder,
struct drm_connector_state *conn_st)
{
struct komeda_crtc_state *kcrtc_st = to_kcrtc_st(crtc_st);
+ struct drm_writeback_job *writeback_job = conn_st->writeback_job;
struct komeda_layer *wb_layer;
struct komeda_data_flow_cfg dflow;
int err;
+ if (!writeback_job || !writeback_job->fb) {
+ return 0;
+ }
+
if (!crtc_st->active) {
DRM_DEBUG_ATOMIC("Cannot write the composition result out on a
inactive CRTC.\n");
return -EINVAL;
--
2.17.1
[PATCH] drm/komeda: Refine function to_d71_input_id
Since the component_state->input[i] is only valid when it is active, the
content of input[i] is undefined if it is inactive. The user must check the
state->active_inputs with input index firstly before using state->input[i].
Refine the function to_d71_input_id and directly move such check into it.
Simplify the using and avoid problem that caller forget the valid check.
Depends on:
- https://patchwork.freedesktop.org/series/60856/
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../arm/display/komeda/d71/d71_component.c| 32 ++-
1 file changed, 17 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index d101a5cc2766..fff9fc8fab15 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -156,11 +156,15 @@ static u32 to_ad_ctrl(u64 modifier)
return afbc_ctrl;
}
-static inline u32 to_d71_input_id(struct komeda_component_output *output)
+static inline u32 to_d71_input_id(struct komeda_component_state *st, int idx)
{
- struct komeda_component *comp = output->component;
+ struct komeda_component_output *input = >inputs[idx];
- return comp ? (comp->hw_id + output->output_port) : 0;
+ /* if input is not active, set hw input_id(0) to disable it */
+ if (has_bit(idx, st->active_inputs))
+ return input->component->hw_id + input->output_port;
+ else
+ return 0;
}
static void d71_layer_update_fb(struct komeda_component *c,
@@ -388,7 +392,7 @@ static void d71_wb_layer_update(struct komeda_component *c,
ctrl |= LW_TBU_EN;
malidp_write32(reg, BLK_IN_SIZE, HV_SIZE(st->hsize, st->vsize));
- malidp_write32(reg, BLK_INPUT_ID0, to_d71_input_id(>inputs[0]));
+ malidp_write32(reg, BLK_INPUT_ID0, to_d71_input_id(state, 0));
malidp_write32_mask(reg, BLK_CONTROL, mask, ctrl);
}
@@ -512,15 +516,15 @@ static void d71_compiz_update(struct komeda_component *c,
struct komeda_compiz_state *st = to_compiz_st(state);
u32 __iomem *reg = c->reg;
u32 __iomem *id_reg, *cfg_reg;
- u32 index, input_hw_id;
+ u32 index;
for_each_changed_input(state, index) {
id_reg = reg + index;
cfg_reg = reg + index * CU_PER_INPUT_REGS;
- input_hw_id = to_d71_input_id(>inputs[index]);
if (state->active_inputs & BIT(index)) {
compiz_enable_input(id_reg, cfg_reg,
- input_hw_id, >cins[index]);
+ to_d71_input_id(state, index),
+ >cins[index]);
} else {
malidp_write32(id_reg, BLK_INPUT_ID0, 0);
malidp_write32(cfg_reg, CU_INPUT0_CONTROL, 0);
@@ -696,7 +700,7 @@ static void d71_scaler_update(struct komeda_component *c,
ctrl |= SC_CTRL_LS;
malidp_write32(reg, BLK_CONTROL, ctrl);
- malidp_write32(reg, BLK_INPUT_ID0, to_d71_input_id(>inputs[0]));
+ malidp_write32(reg, BLK_INPUT_ID0, to_d71_input_id(state, 0));
}
static void d71_scaler_dump(struct komeda_component *c, struct seq_file *sf)
@@ -772,7 +776,7 @@ static void d71_merger_update(struct komeda_component *c,
for_each_changed_input(state, index)
malidp_write32(reg, MG_INPUT_ID0 + index * 4,
- to_d71_input_id(>inputs[index]));
+ to_d71_input_id(state, index));
malidp_write32(reg, MG_SIZE, HV_SIZE(st->hsize_merged,
st->vsize_merged));
@@ -839,13 +843,11 @@ static void d71_improc_update(struct komeda_component *c,
{
struct komeda_improc_state *st = to_improc_st(state);
u32 __iomem *reg = c->reg;
- u32 index, input_hw_id;
+ u32 index;
- for_each_changed_input(state, index) {
- input_hw_id = state->active_inputs & BIT(index) ?
- to_d71_input_id(>inputs[index]) : 0;
- malidp_write32(reg, BLK_INPUT_ID0 + index * 4, input_hw_id);
- }
+ for_each_changed_input(state, index)
+ malidp_write32(reg, BLK_INPUT_ID0 + index * 4,
+ to_d71_input_id(state, index));
malidp_write32(reg, BLK_SIZE, HV_SIZE(st->hsize, st->vsize));
}
--
2.17.1
[PATCH] drm/vmwgfx: fix a warning due to missing dma_parms
Booting up with DMA_API_DEBUG_SG=y generates a warning below due to the
driver forgot to set dma_parms appropriately. Set it after
vmw_dma_masks(), so it can choose a size either DMA_BIT_MASK(64) or
DMA_BIT_MASK(44).
DMA-API: vmwgfx :00:0f.0: mapping sg segment longer than device
claims to support [len=2097152] [max=65536]
WARNING: CPU: 2 PID: 261 at kernel/dma/debug.c:1232
debug_dma_map_sg+0x360/0x480
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop
Reference Platform, BIOS 6.00 04/13/2018
RIP: 0010:debug_dma_map_sg+0x360/0x480
Call Trace:
vmw_ttm_map_dma+0x3b1/0x5b0 [vmwgfx]
vmw_bo_map_dma+0x25/0x30 [vmwgfx]
vmw_otables_setup+0x2a8/0x750 [vmwgfx]
vmw_request_device_late+0x78/0xc0 [vmwgfx]
vmw_request_device+0xee/0x4e0 [vmwgfx]
vmw_driver_load.cold+0x757/0xd84 [vmwgfx]
drm_dev_register+0x1ff/0x340 [drm]
drm_get_pci_dev+0x110/0x290 [drm]
vmw_probe+0x15/0x20 [vmwgfx]
local_pci_probe+0x7a/0xc0
pci_device_probe+0x1b9/0x290
really_probe+0x1b5/0x630
driver_probe_device+0xa3/0x1a0
device_driver_attach+0x94/0xa0
__driver_attach+0xdd/0x1c0
bus_for_each_dev+0xfe/0x150
driver_attach+0x2d/0x40
bus_add_driver+0x290/0x350
driver_register+0xdc/0x1d0
__pci_register_driver+0xda/0xf0
vmwgfx_init+0x34/0x1000 [vmwgfx]
do_one_initcall+0xe5/0x40a
do_init_module+0x10f/0x3a0
load_module+0x16a5/0x1a40
__se_sys_finit_module+0x183/0x1c0
__x64_sys_finit_module+0x43/0x50
do_syscall_64+0xc8/0x606
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes: fb1d9738ca05 ("drm/vmwgfx: Add DRM driver for VMware Virtual GPU")
Signed-off-by: Qian Cai
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index bf6c3500d363..5c567b81174f 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -747,6 +747,13 @@ static int vmw_driver_load(struct drm_device *dev,
unsigned long chipset)
if (unlikely(ret != 0))
goto out_err0;
+ dev->dev->dma_parms = kzalloc(sizeof(*dev->dev->dma_parms),
+ GFP_KERNEL);
+ if (!dev->dev->dma_parms)
+ goto out_err0;
+
+ dma_set_max_seg_size(dev->dev, *dev->dev->dma_mask);
+
if (dev_priv->capabilities & SVGA_CAP_GMR2) {
DRM_INFO("Max GMR ids is %u\n",
(unsigned)dev_priv->max_gmr_ids);
@@ -772,7 +779,7 @@ static int vmw_driver_load(struct drm_device *dev, unsigned
long chipset)
if (unlikely(dev_priv->mmio_virt == NULL)) {
ret = -ENOMEM;
DRM_ERROR("Failed mapping MMIO.\n");
- goto out_err0;
+ goto out_err1;
}
/* Need mmio memory to check for fifo pitchlock cap. */
@@ -781,7 +788,7 @@ static int vmw_driver_load(struct drm_device *dev, unsigned
long chipset)
!vmw_fifo_have_pitchlock(dev_priv)) {
ret = -ENOSYS;
DRM_ERROR("Hardware has no pitchlock\n");
- goto out_err4;
+ goto out_err2;
}
dev_priv->tdev = ttm_object_device_init(_mem_glob, 12,
@@ -790,7 +797,7 @@ static int vmw_driver_load(struct drm_device *dev, unsigned
long chipset)
if (unlikely(dev_priv->tdev == NULL)) {
DRM_ERROR("Unable to initialize TTM object management.\n");
ret = -ENOMEM;
- goto out_err4;
+ goto out_err2;
}
dev->dev_private = dev_priv;
@@ -944,8 +951,11 @@ static int vmw_driver_load(struct drm_device *dev,
unsigned long chipset)
pci_release_regions(dev->pdev);
out_no_device:
ttm_object_device_release(_priv->tdev);
-out_err4:
+out_err2:
memunmap(dev_priv->mmio_virt);
+out_err1:
+ kfree(dev->dev->dma_parms);
+ dev->dev->dma_parms = NULL;
out_err0:
for (i = vmw_res_context; i < vmw_res_max; ++i)
idr_destroy(_priv->res_idr[i]);
@@ -995,6 +1005,8 @@ static void vmw_driver_unload(struct drm_device *dev)
ttm_object_device_release(_priv->tdev);
memunmap(dev_priv->mmio_virt);
+ kfree(dev->dev->dma_parms);
+ dev->dev->dma_parms = NULL;
if (dev_priv->ctx.staged_bindings)
vmw_binding_state_free(dev_priv->ctx.staged_bindings);
--
2.20.1 (Apple Git-117)
[PATCH] drm_edid-load: Fix a missing-check bug in drm_load_edid_firmware()
In drm_load_edid_firmware(), fwstr is allocated by kstrdup(). And fwstr
is dereferenced in the following codes. However, memory allocation
functions such as kstrdup() may fail and returns NULL. Dereferencing
this null pointer may cause the kernel go wrong. Thus we should check
this kstrdup() operation.
Further, if kstrdup() returns NULL, we should return ERR_PTR(-ENOMEM) to
the caller site.
Signed-off-by: Gen Zhang
Reviewed-by: Jani Nikula
---
diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
index a491509..a0e107a 100644
--- a/drivers/gpu/drm/drm_edid_load.c
+++ b/drivers/gpu/drm/drm_edid_load.c
@@ -290,6 +290,8 @@ struct edid *drm_load_edid_firmware(struct drm_connector
*connector)
* the last one found one as a fallback.
*/
fwstr = kstrdup(edid_firmware, GFP_KERNEL);
+ if (!fwstr)
+ return ERR_PTR(-ENOMEM);
edidstr = fwstr;
while ((edidname = strsep(, ","))) {
---
[Bug 110749] [Vega 11] [amdgpu retry page fault VM_L2_PROTECTION_FAULT_STATUS] System lock up during playing Steam version of Saints Row 3
https://bugs.freedesktop.org/show_bug.cgi?id=110749 --- Comment #2 from Cyrax --- Created attachment 144338 --> https://bugs.freedesktop.org/attachment.cgi?id=144338=edit Xorg log before starting the game -- 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 110749] [Vega 11] [amdgpu retry page fault VM_L2_PROTECTION_FAULT_STATUS] System lock up during playing Steam version of Saints Row 3
https://bugs.freedesktop.org/show_bug.cgi?id=110749 Cyrax changed: What|Removed |Added 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 110749] [Vega 11] [amdgpu retry page fault VM_L2_PROTECTION_FAULT_STATUS] System lock up during playing Steam version of Saints Row 3
https://bugs.freedesktop.org/show_bug.cgi?id=110749 --- Comment #1 from Cyrax --- OS : Arch Linux with linux-next-git kernel https://aur.archlinux.org/packages/linux-next-git With latest libdrm-git, mesa-git and llvm-git packages installed. local/linux-next-git 20190523.r0.gf48b97e163b3-1 The Linux-next-git kernel and modules local/linux-next-git-headers 20190523.r0.gf48b97e163b3-1 Header files and scripts for building modules for Linux-next-git kernel local/lib32-libdrm-git 2.4.98.r16.g922d9299-2 Userspace interface to kernel DRM services, git 32-bit version local/libdrm-git 2.4.98.r16.g922d9299-1 Userspace interface to kernel DRM services, master git version local/lib32-llvm-git 9.0.0_r317246.30905a375ea-1 Collection of modular and reusable compiler and toolchain technologies (32-bit, git) local/lib32-llvm-libs-git 9.0.0_r317246.30905a375ea-1 Collection of modular and reusable compiler and toolchain technologies (32-bit, git) local/llvm-git 9.0.0_r317246.30905a375ea-1 LLVM development version. includes clang and many other tools local/llvm-libs-git 9.0.0_r317246.30905a375ea-1 runtime libraries for llvm-git local/lib32-mesa-git 19.2.0_devel.92.8d386e6eef8-1 an open-source implementation of the OpenGL specification, git version local/mesa-git 19.2.0_devel.92.8d386e6eef8-1 an open-source implementation of the OpenGL specification, git version -- 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 110749] [Vega 11] [amdgpu retry page fault VM_L2_PROTECTION_FAULT_STATUS] System lock up during playing Steam version of Saints Row 3
https://bugs.freedesktop.org/show_bug.cgi?id=110749 Bug ID: 110749 Summary: [Vega 11] [amdgpu retry page fault VM_L2_PROTECTION_FAULT_STATUS] System lock up during playing Steam version of Saints Row 3 Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: blocker Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: ev...@hotmail.com Created attachment 144337 --> https://bugs.freedesktop.org/attachment.cgi?id=144337=edit contains files generated from output of dmesg, umr and "cat /sys/kernel/debug/tracing/trace" System hangs shortly (approximately few minutes) after starting playing Saints Row 3. Sound keeps playing but mouse et al doesn't work. Monitor turns itself off after few seconds. Logging in the system via SSH fails. Only magickal SysRq + REISUB command helps. -- 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 110701] GPU faults in in Unigine Valley 1.0
https://bugs.freedesktop.org/show_bug.cgi?id=110701 --- Comment #26 from Yury Zhuravlev --- (In reply to Christoph Haag from comment #25) > (In reply to Yury Zhuravlev from comment #24) > > (In reply to Marek Olšák from comment #23) > > > Fixed by d6053bf2a170a0fec6d232fda097d2f35f0e9eae. Closing. > > > > The original issue was about Vega and on Vega we saw a different problem. I > > suppose before close issue somebody should check patch on Vega. > > I will do it soon. > > Since nobody responded: On a Vega 64 I got GPU faults like the ones posted > here followed by a GPU hang immediately when restoring a firefox (nightly) > session. With mesa master this does not happen anymore. I agree, everything fine now. Vega56 -- 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] drm/mst: Fix MST sideband up-reply failure handling
On Fri, 2019-05-24 at 01:28 +0300, Imre Deak wrote:
> On Thu, May 23, 2019 at 06:09:56PM -0400, Lyude Paul wrote:
> > Patch mostly looks good to me, one comment below
> >
> > On Fri, 2019-05-24 at 00:24 +0300, Imre Deak wrote:
> > > Fix the breakage resulting in the stacktrace below, due to tx queue
> > > being full when trying to send an up-reply. txmsg->seqno is -1 in this
> > > case leading to a corruption of the mstb object by
> > >
> > > txmsg->dst->tx_slots[txmsg->seqno] = NULL;
> > >
> > > in process_single_up_tx_qlock().
> > >
> > > [ +0,005162] [drm:process_single_tx_qlock [drm_kms_helper]]
> > > set_hdr_from_dst_qlock: failed to find slot
> > > [ +0,15] [drm:drm_dp_send_up_ack_reply.constprop.19
> > > [drm_kms_helper]]
> > > failed to send msg in q -11
> > > [ +0,000939] BUG: kernel NULL pointer dereference, address:
> > > 05a0
> > > [ +0,006982] #PF: supervisor write access in kernel mode
> > > [ +0,005223] #PF: error_code(0x0002) - not-present page
> > > [ +0,005135] PGD 0 P4D 0
> > > [ +0,002581] Oops: 0002 [#1] PREEMPT SMP NOPTI
> > > [ +0,004359] CPU: 1 PID: 1200 Comm: kworker/u16:3 Tainted:
> > > G U5.2.0-rc1+ #410
> > > [ +0,008433] Hardware name: Intel Corporation Ice Lake Client
> > > Platform/IceLake U DDR4 SODIMM PD RVP, BIOS
> > > ICLSFWR1.R00.3175.A00.1904261428
> > > 04/26/2019
> > > [ +0,013323] Workqueue: i915-dp i915_digport_work_func [i915]
> > > [ +0,005676] RIP: 0010:queue_work_on+0x19/0x70
> > > [ +0,004372] Code: ff ff ff 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00
> > > 41 56
> > > 49 89 f6 41 55 41 89 fd 41 54 55 53 48 89 d3 9c 5d fa e8 e7 81 0c 00
> > > 48
> > > 0f ba 2b 00 73 31 45 31 e4 f7 c5 00 02 00 00 74 13 e8 cf 7f
> > > [ +0,018750] RSP: 0018:c97dfc50 EFLAGS: 00010006
> > > [ +0,005222] RAX: 0046 RBX: 05a0 RCX:
> > > 0001
> > > [ +0,007133] RDX: 0001b608 RSI: RDI:
> > > 82121972
> > > [ +0,007129] RBP: 0202 R08: R09:
> > > 0001
> > > [ +0,007129] R10: R11: R12:
> > > 88847bfa5096
> > > [ +0,007131] R13: 0010 R14: 88849c08f3f8 R15:
> > >
> > > [ +0,007128] FS: () GS:88849dc8()
> > > knlGS:
> > > [ +0,008083] CS: 0010 DS: ES: CR0: 80050033
> > > [ +0,005749] CR2: 05a0 CR3: 05210006 CR4:
> > > 00760ee0
> > > [ +0,007128] PKRU: 5554
> > > [ +0,002722] Call Trace:
> > > [ +0,002458] drm_dp_mst_handle_up_req+0x517/0x540 [drm_kms_helper]
> > > [ +0,006197] ? drm_dp_mst_hpd_irq+0x5b/0x9c0 [drm_kms_helper]
> > > [ +0,005764] drm_dp_mst_hpd_irq+0x5b/0x9c0 [drm_kms_helper]
> > > [ +0,005623] ? intel_dp_hpd_pulse+0x205/0x370 [i915]
> > > [ +0,005018] intel_dp_hpd_pulse+0x205/0x370 [i915]
> > > [ +0,004836] i915_digport_work_func+0xbb/0x140 [i915]
> > > [ +0,005108] process_one_work+0x245/0x610
> > > [ +0,004027] worker_thread+0x37/0x380
> > > [ +0,003684] ? process_one_work+0x610/0x610
> > > [ +0,004184] kthread+0x119/0x130
> > > [ +0,003240] ? kthread_park+0x80/0x80
> > > [ +0,003668] ret_from_fork+0x24/0x50
> > >
> > > Cc: Lyude Paul
> > > Cc: Dave Airlie
> > > Signed-off-by: Imre Deak
> > > ---
> > > drivers/gpu/drm/drm_dp_mst_topology.c | 6 +-
> > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > index da1abca1b9e9..24c325f4a616 100644
> > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > @@ -1996,7 +1996,11 @@ static void process_single_up_tx_qlock(struct
> > > drm_dp_mst_topology_mgr *mgr,
> > > if (ret != 1)
> > > DRM_DEBUG_KMS("failed to send msg in q %d\n", ret);
> > >
> > > - txmsg->dst->tx_slots[txmsg->seqno] = NULL;
> > > + if (txmsg->seqno != -1) {
> > > + WARN_ON((unsigned)txmsg->seqno >
> > > + ARRAY_SIZE(txmsg->dst->tx_slots));
> >
> > Not 100% sure on this nitpick myself but, if we know that txmsg->seqno is
> > about to go out of bounds shouldn't we also try to take action to stop it?
> > like
>
> Imo, it's worth keeping thins simple. If the WARN triggers we need to
> fix the original issue in any case (txmsg->seqno never should be set to
> anything else than -1 or a valid idx) so making the assignment here
> conditional wouldn't have a real purpose.
mm, fair enough. Then:
Reviewed-by: Lyude Paul
Thanks for the fix!
>
> > if (!WARN_ON((unsigned)txmsg->seqno > ARRAY_SIZE(txmsg->dst->tx_slots)))
> > txmsg->dst->tx_slots[txmsg->seqno] = NULL;
> >
> >
> >
> > > + txmsg->dst->tx_slots[txmsg->seqno] = NULL;
> > > + }
> > > }
> > >
> > > static void drm_dp_queue_down_tx(struct drm_dp_mst_topology_mgr *mgr,
> > --
> > Cheers,
> > Lyude Paul
> >
--
Re: [PATCH] drm/mst: Fix MST sideband up-reply failure handling
On Thu, May 23, 2019 at 06:09:56PM -0400, Lyude Paul wrote:
> Patch mostly looks good to me, one comment below
>
> On Fri, 2019-05-24 at 00:24 +0300, Imre Deak wrote:
> > Fix the breakage resulting in the stacktrace below, due to tx queue
> > being full when trying to send an up-reply. txmsg->seqno is -1 in this
> > case leading to a corruption of the mstb object by
> >
> > txmsg->dst->tx_slots[txmsg->seqno] = NULL;
> >
> > in process_single_up_tx_qlock().
> >
> > [ +0,005162] [drm:process_single_tx_qlock [drm_kms_helper]]
> > set_hdr_from_dst_qlock: failed to find slot
> > [ +0,15] [drm:drm_dp_send_up_ack_reply.constprop.19 [drm_kms_helper]]
> > failed to send msg in q -11
> > [ +0,000939] BUG: kernel NULL pointer dereference, address:
> > 05a0
> > [ +0,006982] #PF: supervisor write access in kernel mode
> > [ +0,005223] #PF: error_code(0x0002) - not-present page
> > [ +0,005135] PGD 0 P4D 0
> > [ +0,002581] Oops: 0002 [#1] PREEMPT SMP NOPTI
> > [ +0,004359] CPU: 1 PID: 1200 Comm: kworker/u16:3 Tainted:
> > G U5.2.0-rc1+ #410
> > [ +0,008433] Hardware name: Intel Corporation Ice Lake Client
> > Platform/IceLake U DDR4 SODIMM PD RVP, BIOS ICLSFWR1.R00.3175.A00.1904261428
> > 04/26/2019
> > [ +0,013323] Workqueue: i915-dp i915_digport_work_func [i915]
> > [ +0,005676] RIP: 0010:queue_work_on+0x19/0x70
> > [ +0,004372] Code: ff ff ff 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 41 56
> > 49 89 f6 41 55 41 89 fd 41 54 55 53 48 89 d3 9c 5d fa e8 e7 81 0c 00 48
> > 0f ba 2b 00 73 31 45 31 e4 f7 c5 00 02 00 00 74 13 e8 cf 7f
> > [ +0,018750] RSP: 0018:c97dfc50 EFLAGS: 00010006
> > [ +0,005222] RAX: 0046 RBX: 05a0 RCX:
> > 0001
> > [ +0,007133] RDX: 0001b608 RSI: RDI:
> > 82121972
> > [ +0,007129] RBP: 0202 R08: R09:
> > 0001
> > [ +0,007129] R10: R11: R12:
> > 88847bfa5096
> > [ +0,007131] R13: 0010 R14: 88849c08f3f8 R15:
> >
> > [ +0,007128] FS: () GS:88849dc8()
> > knlGS:
> > [ +0,008083] CS: 0010 DS: ES: CR0: 80050033
> > [ +0,005749] CR2: 05a0 CR3: 05210006 CR4:
> > 00760ee0
> > [ +0,007128] PKRU: 5554
> > [ +0,002722] Call Trace:
> > [ +0,002458] drm_dp_mst_handle_up_req+0x517/0x540 [drm_kms_helper]
> > [ +0,006197] ? drm_dp_mst_hpd_irq+0x5b/0x9c0 [drm_kms_helper]
> > [ +0,005764] drm_dp_mst_hpd_irq+0x5b/0x9c0 [drm_kms_helper]
> > [ +0,005623] ? intel_dp_hpd_pulse+0x205/0x370 [i915]
> > [ +0,005018] intel_dp_hpd_pulse+0x205/0x370 [i915]
> > [ +0,004836] i915_digport_work_func+0xbb/0x140 [i915]
> > [ +0,005108] process_one_work+0x245/0x610
> > [ +0,004027] worker_thread+0x37/0x380
> > [ +0,003684] ? process_one_work+0x610/0x610
> > [ +0,004184] kthread+0x119/0x130
> > [ +0,003240] ? kthread_park+0x80/0x80
> > [ +0,003668] ret_from_fork+0x24/0x50
> >
> > Cc: Lyude Paul
> > Cc: Dave Airlie
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/drm_dp_mst_topology.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index da1abca1b9e9..24c325f4a616 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -1996,7 +1996,11 @@ static void process_single_up_tx_qlock(struct
> > drm_dp_mst_topology_mgr *mgr,
> > if (ret != 1)
> > DRM_DEBUG_KMS("failed to send msg in q %d\n", ret);
> >
> > - txmsg->dst->tx_slots[txmsg->seqno] = NULL;
> > + if (txmsg->seqno != -1) {
> > + WARN_ON((unsigned)txmsg->seqno >
> > + ARRAY_SIZE(txmsg->dst->tx_slots));
>
> Not 100% sure on this nitpick myself but, if we know that txmsg->seqno is
> about to go out of bounds shouldn't we also try to take action to stop it?
> like
Imo, it's worth keeping thins simple. If the WARN triggers we need to
fix the original issue in any case (txmsg->seqno never should be set to
anything else than -1 or a valid idx) so making the assignment here
conditional wouldn't have a real purpose.
>
> if (!WARN_ON((unsigned)txmsg->seqno > ARRAY_SIZE(txmsg->dst->tx_slots)))
> txmsg->dst->tx_slots[txmsg->seqno] = NULL;
>
>
>
> > + txmsg->dst->tx_slots[txmsg->seqno] = NULL;
> > + }
> > }
> >
> > static void drm_dp_queue_down_tx(struct drm_dp_mst_topology_mgr *mgr,
> --
> Cheers,
> Lyude Paul
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: build failure after merge of the drm-fixes tree
Hi all,
After merging the drm-fixes tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function
'load_dmcu_fw':
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:667:7: error:
implicit declaration of function 'ASICREV_IS_PICASSO'; did you mean
'ASICREV_IS_VEGA12_P'? [-Werror=implicit-function-declaration]
if (ASICREV_IS_PICASSO(adev->external_rev_id))
^~
ASICREV_IS_VEGA12_P
Caused by commit
55143dc23ca4 ("drm/amd/display: Don't load DMCU for Raven 1")
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
pgpTyuNGOkWbE.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mst: Fix MST sideband up-reply failure handling
Patch mostly looks good to me, one comment below
On Fri, 2019-05-24 at 00:24 +0300, Imre Deak wrote:
> Fix the breakage resulting in the stacktrace below, due to tx queue
> being full when trying to send an up-reply. txmsg->seqno is -1 in this
> case leading to a corruption of the mstb object by
>
> txmsg->dst->tx_slots[txmsg->seqno] = NULL;
>
> in process_single_up_tx_qlock().
>
> [ +0,005162] [drm:process_single_tx_qlock [drm_kms_helper]]
> set_hdr_from_dst_qlock: failed to find slot
> [ +0,15] [drm:drm_dp_send_up_ack_reply.constprop.19 [drm_kms_helper]]
> failed to send msg in q -11
> [ +0,000939] BUG: kernel NULL pointer dereference, address:
> 05a0
> [ +0,006982] #PF: supervisor write access in kernel mode
> [ +0,005223] #PF: error_code(0x0002) - not-present page
> [ +0,005135] PGD 0 P4D 0
> [ +0,002581] Oops: 0002 [#1] PREEMPT SMP NOPTI
> [ +0,004359] CPU: 1 PID: 1200 Comm: kworker/u16:3 Tainted:
> G U5.2.0-rc1+ #410
> [ +0,008433] Hardware name: Intel Corporation Ice Lake Client
> Platform/IceLake U DDR4 SODIMM PD RVP, BIOS ICLSFWR1.R00.3175.A00.1904261428
> 04/26/2019
> [ +0,013323] Workqueue: i915-dp i915_digport_work_func [i915]
> [ +0,005676] RIP: 0010:queue_work_on+0x19/0x70
> [ +0,004372] Code: ff ff ff 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 41 56
> 49 89 f6 41 55 41 89 fd 41 54 55 53 48 89 d3 9c 5d fa e8 e7 81 0c 00 48
> 0f ba 2b 00 73 31 45 31 e4 f7 c5 00 02 00 00 74 13 e8 cf 7f
> [ +0,018750] RSP: 0018:c97dfc50 EFLAGS: 00010006
> [ +0,005222] RAX: 0046 RBX: 05a0 RCX:
> 0001
> [ +0,007133] RDX: 0001b608 RSI: RDI:
> 82121972
> [ +0,007129] RBP: 0202 R08: R09:
> 0001
> [ +0,007129] R10: R11: R12:
> 88847bfa5096
> [ +0,007131] R13: 0010 R14: 88849c08f3f8 R15:
>
> [ +0,007128] FS: () GS:88849dc8()
> knlGS:
> [ +0,008083] CS: 0010 DS: ES: CR0: 80050033
> [ +0,005749] CR2: 05a0 CR3: 05210006 CR4:
> 00760ee0
> [ +0,007128] PKRU: 5554
> [ +0,002722] Call Trace:
> [ +0,002458] drm_dp_mst_handle_up_req+0x517/0x540 [drm_kms_helper]
> [ +0,006197] ? drm_dp_mst_hpd_irq+0x5b/0x9c0 [drm_kms_helper]
> [ +0,005764] drm_dp_mst_hpd_irq+0x5b/0x9c0 [drm_kms_helper]
> [ +0,005623] ? intel_dp_hpd_pulse+0x205/0x370 [i915]
> [ +0,005018] intel_dp_hpd_pulse+0x205/0x370 [i915]
> [ +0,004836] i915_digport_work_func+0xbb/0x140 [i915]
> [ +0,005108] process_one_work+0x245/0x610
> [ +0,004027] worker_thread+0x37/0x380
> [ +0,003684] ? process_one_work+0x610/0x610
> [ +0,004184] kthread+0x119/0x130
> [ +0,003240] ? kthread_park+0x80/0x80
> [ +0,003668] ret_from_fork+0x24/0x50
>
> Cc: Lyude Paul
> Cc: Dave Airlie
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index da1abca1b9e9..24c325f4a616 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1996,7 +1996,11 @@ static void process_single_up_tx_qlock(struct
> drm_dp_mst_topology_mgr *mgr,
> if (ret != 1)
> DRM_DEBUG_KMS("failed to send msg in q %d\n", ret);
>
> - txmsg->dst->tx_slots[txmsg->seqno] = NULL;
> + if (txmsg->seqno != -1) {
> + WARN_ON((unsigned)txmsg->seqno >
> + ARRAY_SIZE(txmsg->dst->tx_slots));
Not 100% sure on this nitpick myself but, if we know that txmsg->seqno is
about to go out of bounds shouldn't we also try to take action to stop it?
like
if (!WARN_ON((unsigned)txmsg->seqno > ARRAY_SIZE(txmsg->dst->tx_slots)))
txmsg->dst->tx_slots[txmsg->seqno] = NULL;
> + txmsg->dst->tx_slots[txmsg->seqno] = NULL;
> + }
> }
>
> static void drm_dp_queue_down_tx(struct drm_dp_mst_topology_mgr *mgr,
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110721] graphics corruption on steam client with mesa 19.1.0 rc3 on polaris
https://bugs.freedesktop.org/show_bug.cgi?id=110721 --- Comment #16 from Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0...@gmail.com> --- I confirm that reverting "mesa: unreference current winsys buffers when unbinding winsys buffers" fixes the rendering issues in Spotify and Visual Studio Code. Thanks. -- 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 v15 00/17] arm64: untag user pointers passed to the kernel
On Thu, May 23, 2019 at 06:43:46PM +0100, Catalin Marinas wrote: > On Thu, May 23, 2019 at 09:38:19AM -0700, Kees Cook wrote: > > What on this front would you be comfortable with? Given it's a new > > feature isn't it sufficient to have a CONFIG (and/or boot option)? > > I'd rather avoid re-building kernels. A boot option would do, unless we > see value in a per-process (inherited) personality or prctl. The I think I've convinced myself that the normal<->TBI ABI control should be a boot parameter. More below... > > What about testing tools that intentionally insert high bits for syscalls > > and are _expecting_ them to fail? It seems the TBI series will break them? > > In that case, do we need to opt into TBI as well? > > If there are such tools, then we may need a per-process control. It's > basically an ABI change. syzkaller already attempts to randomly inject non-canonical and 0x addresses for user pointers in syscalls in an effort to find bugs like CVE-2017-5123 where waitid() via unchecked put_user() was able to write directly to kernel memory[1]. It seems that using TBI by default and not allowing a switch back to "normal" ABI without a reboot actually means that userspace cannot inject kernel pointers into syscalls any more, since they'll get universally stripped now. Is my understanding correct, here? i.e. exploiting CVE-2017-5123 would be impossible under TBI? If so, then I think we should commit to the TBI ABI and have a boot flag to disable it, but NOT have a process flag, as that would allow attackers to bypass the masking. The only flag should be "TBI or MTE". If so, can I get top byte masking for other architectures too? Like, just to strip high bits off userspace addresses? ;) (Oh, in looking I see this is implemented with sign-extension... why not just a mask? So it'll either be valid userspace address or forced into the non-canonical range?) [1] https://salls.github.io/Linux-Kernel-CVE-2017-5123/ > > Alright, the tl;dr appears to be: > > - you want more assurances that we can find __user stripping in the > > kernel more easily. (But this seems like a parallel problem.) > > Yes, and that we found all (most) cases now. The reason I don't see it > as a parallel problem is that, as maintainer, I promise an ABI to user > and I'd rather stick to it. I don't want, for example, ncurses to stop > working because of some ioctl() rejecting tagged pointers. But this is what I don't understand: it would need to be ncurses _using TBI_, that would stop working (having started to work before, but then regress due to a newly added one-off bug). Regular ncurses will be fine because it's not using TBI. So The Golden Rule isn't violated, and by definition, it's a specific regression caused by some bug (since TBI would have had to have worked _before_ in the situation to be considered a regression now). Which describes the normal path for kernel development... add feature, find corner cases where it doesn't work, fix them, encounter new regressions, fix those, repeat forever. > If it's just the occasional one-off bug I'm fine to deal with it. But > no-one convinced me yet that this is the case. You believe there still to be some systemic cases that haven't been found yet? And even if so -- isn't it better to work on that incrementally? > As for the generic driver code (filesystems or other subsystems), > without some clear direction for developers, together with static > checking/sparse, on how user pointers are cast to longs (one example), > it would become my responsibility to identify and fix them up with any > kernel release. This series is not providing such guidance, just adding > untagged_addr() in some places that we think matter. What about adding a nice bit of .rst documentation that describes the situation and shows how to use untagged_addr(). This is the kind of kernel-wide change that "everyone" needs to know about, and shouldn't be the arch maintainer's sole responsibility to fix. > > - we might need to opt in to TBI with a prctl() > > Yes, although still up for discussion. I think I've talked myself out of it. I say boot param only! :) So what do you say to these next steps: - change untagged_addr() to use a static branch that is controlled with a boot parameter. - add, say, Documentation/core-api/user-addresses.rst to describe proper care and handling of user space pointers with untagged_addr(), with examples based on all the cases seen so far in this series. - continue work to improve static analysis. Thanks for wading through this with me! :) -- Kees Cook ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/mst: Fix MST sideband up-reply failure handling
Fix the breakage resulting in the stacktrace below, due to tx queue
being full when trying to send an up-reply. txmsg->seqno is -1 in this
case leading to a corruption of the mstb object by
txmsg->dst->tx_slots[txmsg->seqno] = NULL;
in process_single_up_tx_qlock().
[ +0,005162] [drm:process_single_tx_qlock [drm_kms_helper]]
set_hdr_from_dst_qlock: failed to find slot
[ +0,15] [drm:drm_dp_send_up_ack_reply.constprop.19 [drm_kms_helper]]
failed to send msg in q -11
[ +0,000939] BUG: kernel NULL pointer dereference, address: 05a0
[ +0,006982] #PF: supervisor write access in kernel mode
[ +0,005223] #PF: error_code(0x0002) - not-present page
[ +0,005135] PGD 0 P4D 0
[ +0,002581] Oops: 0002 [#1] PREEMPT SMP NOPTI
[ +0,004359] CPU: 1 PID: 1200 Comm: kworker/u16:3 Tainted: G U
5.2.0-rc1+ #410
[ +0,008433] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake
U DDR4 SODIMM PD RVP, BIOS ICLSFWR1.R00.3175.A00.1904261428 04/26/2019
[ +0,013323] Workqueue: i915-dp i915_digport_work_func [i915]
[ +0,005676] RIP: 0010:queue_work_on+0x19/0x70
[ +0,004372] Code: ff ff ff 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 41 56 49
89 f6 41 55 41 89 fd 41 54 55 53 48 89 d3 9c 5d fa e8 e7 81 0c 00 48 0f ba
2b 00 73 31 45 31 e4 f7 c5 00 02 00 00 74 13 e8 cf 7f
[ +0,018750] RSP: 0018:c97dfc50 EFLAGS: 00010006
[ +0,005222] RAX: 0046 RBX: 05a0 RCX: 0001
[ +0,007133] RDX: 0001b608 RSI: RDI: 82121972
[ +0,007129] RBP: 0202 R08: R09: 0001
[ +0,007129] R10: R11: R12: 88847bfa5096
[ +0,007131] R13: 0010 R14: 88849c08f3f8 R15:
[ +0,007128] FS: () GS:88849dc8()
knlGS:
[ +0,008083] CS: 0010 DS: ES: CR0: 80050033
[ +0,005749] CR2: 05a0 CR3: 05210006 CR4: 00760ee0
[ +0,007128] PKRU: 5554
[ +0,002722] Call Trace:
[ +0,002458] drm_dp_mst_handle_up_req+0x517/0x540 [drm_kms_helper]
[ +0,006197] ? drm_dp_mst_hpd_irq+0x5b/0x9c0 [drm_kms_helper]
[ +0,005764] drm_dp_mst_hpd_irq+0x5b/0x9c0 [drm_kms_helper]
[ +0,005623] ? intel_dp_hpd_pulse+0x205/0x370 [i915]
[ +0,005018] intel_dp_hpd_pulse+0x205/0x370 [i915]
[ +0,004836] i915_digport_work_func+0xbb/0x140 [i915]
[ +0,005108] process_one_work+0x245/0x610
[ +0,004027] worker_thread+0x37/0x380
[ +0,003684] ? process_one_work+0x610/0x610
[ +0,004184] kthread+0x119/0x130
[ +0,003240] ? kthread_park+0x80/0x80
[ +0,003668] ret_from_fork+0x24/0x50
Cc: Lyude Paul
Cc: Dave Airlie
Signed-off-by: Imre Deak
---
drivers/gpu/drm/drm_dp_mst_topology.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index da1abca1b9e9..24c325f4a616 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1996,7 +1996,11 @@ static void process_single_up_tx_qlock(struct
drm_dp_mst_topology_mgr *mgr,
if (ret != 1)
DRM_DEBUG_KMS("failed to send msg in q %d\n", ret);
- txmsg->dst->tx_slots[txmsg->seqno] = NULL;
+ if (txmsg->seqno != -1) {
+ WARN_ON((unsigned)txmsg->seqno >
+ ARRAY_SIZE(txmsg->dst->tx_slots));
+ txmsg->dst->tx_slots[txmsg->seqno] = NULL;
+ }
}
static void drm_dp_queue_down_tx(struct drm_dp_mst_topology_mgr *mgr,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH] kernel.h: Add generic roundup_64() macro
On Thu, May 23, 2019 at 10:36 AM Steven Rostedt wrote:
>
> >
> > Of course, you probably want the usual "at least use 'int'" semantics,
> > in which case the "type" should be "(x)+0":
> >
> > #define round_up(x, y) size_fn((x)+0, round_up_size, x, y)
> >
> > and the 8-bit and 16-bit cases will never be used.
>
> I'm curious to what the advantage of that is?
Let's say that you have a structure with a 'unsigned char' member,
because the value range is 0-255.
What happens if you do
x = round_up(p->member, 4);
and the value is 255?
Now, if you stay in 'unsigned char' the end result is 0. If you follow
the usual C integer promotion rules ("all arithmetic promotes to at
least 'int'"), you get 256.
Most people probably expect 256, and that implies that even if you
pass an 'unsigned char' to an arithmetic function like this, you
expect any math to be done in 'int'. Doing the "(x)+0" forces that,
because the "+0" changes the type of the expression from "unsigned
char" to "int" due to C integer promotion.
Yes. The C integer type rules are subtle and sometimes surprising. One
of the things I've wanted is to have some way to limit silent
promotion (and silent truncation!), and cause warnings. 'sparse' does
some of that with some special-case types (ie __bitwise), but it's
pretty limited.
Linus
Re: [PATCH 1/1] drm/i915: remove unused IO_TLB_SEGPAGES which should be defined by swiotlb
Quoting Dongli Zhang (2019-05-21 05:40:39)
> This patch removes IO_TLB_SEGPAGES which is no longer used since
> commit 5584f1b1d73e ("drm/i915: fix i915 running as dom0 under Xen").
>
> As the define of both IO_TLB_SEGSIZE and IO_TLB_SHIFT are from swiotlb,
> IO_TLB_SEGPAGES should be defined on swiotlb side if it is required in the
> future.
>
> Signed-off-by: Dongli Zhang
Pushed, thanks for the patch.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 6/6] drm/msm/a6xx: Rename a6xx_gmu_probe to a6xx_gmu_init
On Thu, May 23, 2019 at 01:16:45PM -0400, Sean Paul wrote:
> From: Sean Paul
>
> This rename makes it more clear that everything initialized in the _init
> function must be cleaned up in a6xx_gmu_remove. This will hopefully
> dissuade people from using device managed resources (for reasons laid
> out in the previous patch).
>
> Changes in v2:
> - None
>
> Cc: Jordan Crouse
> Signed-off-by: Sean Paul
Reviewed-by: Jordan Crouse
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 2 +-
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
> drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> index e2b839b5d3bd..5ab69dcd5479 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> @@ -1259,7 +1259,7 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
> gmu->initialized = false;
> }
>
> -int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct device_node *node)
> +int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct device_node *node)
> {
> struct a6xx_gmu *gmu = _gpu->gmu;
> struct platform_device *pdev = of_find_device_by_node(node);
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index e74dce474250..1f9f4b0a9656 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -854,7 +854,7 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
> /* FIXME: How do we gracefully handle this? */
> BUG_ON(!node);
>
> - ret = a6xx_gmu_probe(a6xx_gpu, node);
> + ret = a6xx_gmu_init(a6xx_gpu, node);
> if (ret) {
> a6xx_destroy(&(a6xx_gpu->base.base));
> return ERR_PTR(ret);
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
> index b46279eb18c5..64399554f2dd 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
> @@ -53,7 +53,7 @@ bool a6xx_gmu_isidle(struct a6xx_gmu *gmu);
> int a6xx_gmu_set_oob(struct a6xx_gmu *gmu, enum a6xx_gmu_oob_state state);
> void a6xx_gmu_clear_oob(struct a6xx_gmu *gmu, enum a6xx_gmu_oob_state state);
>
> -int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct device_node *node);
> +int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct device_node *node);
> void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu);
>
> void a6xx_gmu_set_freq(struct msm_gpu *gpu, unsigned long freq);
> --
> Sean Paul, Software Engineer, Google / Chromium OS
>
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/6] drm/msm/a6xx: Drop the device reference in gmu
On Thu, May 23, 2019 at 01:16:44PM -0400, Sean Paul wrote: > From: Sean Paul > > of_find_device_by_node() grabs a dev reference, so make sure we clear it > on error and remove. > > Changes in v2: > - Added to the set (Jordan) > > Cc: Jordan Crouse > Signed-off-by: Sean Paul Reviewed-by: Jordan Crouse > --- > drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 14 +++--- > 1 file changed, 11 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > index f7240c9e11fb..e2b839b5d3bd 100644 > --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > @@ -1253,6 +1253,9 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu) > free_irq(gmu->gmu_irq, gmu); > free_irq(gmu->hfi_irq, gmu); > > + /* Drop reference taken in of_find_device_by_node */ > + put_device(gmu->dev); > + > gmu->initialized = false; > } > > @@ -1277,12 +1280,12 @@ int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct > device_node *node) > /* Get the list of clocks */ > ret = a6xx_gmu_clocks_probe(gmu); > if (ret) > - return ret; > + goto err_put_device; > > /* Set up the IOMMU context bank */ > ret = a6xx_gmu_memory_probe(gmu); > if (ret) > - return ret; > + goto err_put_device; > > /* Allocate memory for for the HFI queues */ > gmu->hfi = a6xx_gmu_memory_alloc(gmu, SZ_16K); > @@ -1334,6 +1337,11 @@ int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct > device_node *node) > > iommu_domain_free(gmu->domain); > } > + ret = -ENODEV; > > - return -ENODEV; > +err_put_device: > + /* Drop reference taken in of_find_device_by_node */ > + put_device(gmu->dev); > + > + return ret; > } > -- > Sean Paul, Software Engineer, Google / Chromium OS > -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/6] drm/msm/a6xx: Remove devm calls from gmu driver
On Thu, May 23, 2019 at 01:16:43PM -0400, Sean Paul wrote:
> From: Sean Paul
>
> The gmu driver is initialized and cleaned up with calls from the gpu driver.
> As
> such, the platform device stays valid after a6xx_gmu_remove is called and the
> device managed resources are not freed. In the case of gpu probe failures or
> unbind, these resources will remain managed.
>
> If the gpu bind is run again (eg: if there's a probe defer somewhere in msm),
> these resources will be initialized again for the same device, creating
> multiple
> references. In the case of irqs, this causes failures since the irqs are
> not shared (nor should they be).
>
> This patch removes all devm_* calls and manually cleans things up in
> gmu_remove.
>
> Changes in v2:
> - Add iounmap and free_irq to gmu_probe error paths
>
> Cc: Jordan Crouse
> Signed-off-by: Sean Paul
As we discussed in IRC, I feel like the way we are probing and dealing with
the GMU device is messing up the reference counting. I had hoped that a
put_device() would do the trick but testing showed it didn't so there is clearly
remaining fail that we should eventually find and fix.
That said; there is really no reason to be using managed resources for this
device so this is an entirely appropriate patch.
Reviewed-by: Jordan Crouse
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 33 ++-
> 1 file changed, 22 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> index 7465423e9b71..f7240c9e11fb 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> @@ -505,9 +505,9 @@ static void a6xx_gmu_rpmh_init(struct a6xx_gmu *gmu)
>
> err:
> if (!IS_ERR_OR_NULL(pdcptr))
> - devm_iounmap(gmu->dev, pdcptr);
> + iounmap(pdcptr);
> if (!IS_ERR_OR_NULL(seqptr))
> - devm_iounmap(gmu->dev, seqptr);
> + iounmap(seqptr);
> }
>
> /*
> @@ -1197,7 +1197,7 @@ static void __iomem *a6xx_gmu_get_mmio(struct
> platform_device *pdev,
> return ERR_PTR(-EINVAL);
> }
>
> - ret = devm_ioremap(>dev, res->start, resource_size(res));
> + ret = ioremap(res->start, resource_size(res));
> if (!ret) {
> DRM_DEV_ERROR(>dev, "Unable to map the %s registers\n",
> name);
> return ERR_PTR(-EINVAL);
> @@ -1213,10 +1213,10 @@ static int a6xx_gmu_get_irq(struct a6xx_gmu *gmu,
> struct platform_device *pdev,
>
> irq = platform_get_irq_byname(pdev, name);
>
> - ret = devm_request_irq(>dev, irq, handler, IRQF_TRIGGER_HIGH,
> - name, gmu);
> + ret = request_irq(irq, handler, IRQF_TRIGGER_HIGH, name, gmu);
> if (ret) {
> - DRM_DEV_ERROR(>dev, "Unable to get interrupt %s\n", name);
> + DRM_DEV_ERROR(>dev, "Unable to get interrupt %s %d\n",
> + name, ret);
> return ret;
> }
>
> @@ -1241,12 +1241,18 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
> dev_pm_domain_detach(gmu->gxpd, false);
> }
>
> + iounmap(gmu->mmio);
> + gmu->mmio = NULL;
> +
> a6xx_gmu_memory_free(gmu, gmu->hfi);
>
> iommu_detach_device(gmu->domain, gmu->dev);
>
> iommu_domain_free(gmu->domain);
>
> + free_irq(gmu->gmu_irq, gmu);
> + free_irq(gmu->hfi_irq, gmu);
> +
> gmu->initialized = false;
> }
>
> @@ -1281,24 +1287,24 @@ int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct
> device_node *node)
> /* Allocate memory for for the HFI queues */
> gmu->hfi = a6xx_gmu_memory_alloc(gmu, SZ_16K);
> if (IS_ERR(gmu->hfi))
> - goto err;
> + goto err_memory;
>
> /* Allocate memory for the GMU debug region */
> gmu->debug = a6xx_gmu_memory_alloc(gmu, SZ_16K);
> if (IS_ERR(gmu->debug))
> - goto err;
> + goto err_memory;
>
> /* Map the GMU registers */
> gmu->mmio = a6xx_gmu_get_mmio(pdev, "gmu");
> if (IS_ERR(gmu->mmio))
> - goto err;
> + goto err_memory;
>
> /* Get the HFI and GMU interrupts */
> gmu->hfi_irq = a6xx_gmu_get_irq(gmu, pdev, "hfi", a6xx_hfi_irq);
> gmu->gmu_irq = a6xx_gmu_get_irq(gmu, pdev, "gmu", a6xx_gmu_irq);
>
> if (gmu->hfi_irq < 0 || gmu->gmu_irq < 0)
> - goto err;
> + goto err_mmio;
>
> /*
>* Get a link to the GX power domain to reset the GPU in case of GMU
> @@ -1315,7 +1321,12 @@ int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct
> device_node *node)
> gmu->initialized = true;
>
> return 0;
> -err:
> +
> +err_mmio:
> + iounmap(gmu->mmio);
> + free_irq(gmu->gmu_irq, gmu);
> + free_irq(gmu->hfi_irq, gmu);
> +err_memory:
> a6xx_gmu_memory_free(gmu, gmu->hfi);
>
> if (gmu->domain) {
> --
> Sean Paul, Software Engineer, Google / Chromium
Re: [PATCH v2 3/6] drm/msm/a6xx: Check for ERR or NULL before iounmap
On Thu, May 23, 2019 at 01:16:42PM -0400, Sean Paul wrote: > From: Sean Paul > > pdcptr and seqptr aren't necessarily valid, check them before trying to > unmap them. > > Changes in v2: > - None > > Cc: Jordan Crouse > Signed-off-by: Sean Paul It has always been sad to me that iounmap() has chosen to not check for NULL. Reviewed-by: Jordan Crouse > --- > drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > index 742c8ff9a61c..7465423e9b71 100644 > --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > @@ -504,8 +504,10 @@ static void a6xx_gmu_rpmh_init(struct a6xx_gmu *gmu) > wmb(); > > err: > - devm_iounmap(gmu->dev, pdcptr); > - devm_iounmap(gmu->dev, seqptr); > + if (!IS_ERR_OR_NULL(pdcptr)) > + devm_iounmap(gmu->dev, pdcptr); > + if (!IS_ERR_OR_NULL(seqptr)) > + devm_iounmap(gmu->dev, seqptr); > } > > /* > -- > Sean Paul, Software Engineer, Google / Chromium OS > -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 04/11] drm/sun4i: tcon: Compute DCLK dividers based on format, lanes
On Mon, May 20, 2019 at 02:33:11PM +0530, Jagan Teki wrote: > pll-video => pll-mipi => tcon0 => tcon0-pixel-clock is the typical > MIPI clock topology in Allwinner DSI controller. > > TCON dotclock driver is computing the desired DCLK divider based on > panel pixel clock along with input DCLK min, max divider values from > tcon driver and that would eventually set the pll-mipi clock rate. > > The current code is passing dsi min and max divider value as 4 via > tcon driver which would ended-up triggering below vblank wait timed out > warning on "bananapi,s070wv20-ct16" panel. > > WARNING: CPU: 0 PID: 31 at drivers/gpu/drm/drm_atomic_helper.c:1429 > drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 > [CRTC:46:crtc-0] vblank wait timed out > Modules linked in: > CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted > 5.1.0-next-20190514-00025-g5186cdf10757-dirty #6 > Hardware name: Allwinner sun8i Family > Workqueue: events deferred_probe_work_func > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > [] (show_stack) from [] (dump_stack+0x84/0x98) > [] (dump_stack) from [] (__warn+0xfc/0x114) > [] (__warn) from [] (warn_slowpath_fmt+0x44/0x68) > [] (warn_slowpath_fmt) from [] > (drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) > [] (drm_atomic_helper_wait_for_vblanks.part.1) from [] > (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) > [] (drm_atomic_helper_commit_tail_rpm) from [] > (commit_tail+0x40/0x6c) > [] (commit_tail) from [] > (drm_atomic_helper_commit+0xbc/0x128) > [] (drm_atomic_helper_commit) from [] > (restore_fbdev_mode_atomic+0x1cc/0x1dc) > [] (restore_fbdev_mode_atomic) from [] > (drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa0) > [] (drm_fb_helper_restore_fbdev_mode_unlocked) from [] > (drm_fb_helper_set_par+0x30/0x54) > [] (drm_fb_helper_set_par) from [] > (fbcon_init+0x560/0x5ac) > [] (fbcon_init) from [] (visual_init+0xbc/0x104) > [] (visual_init) from [] (do_bind_con_driver+0x1b0/0x390) > [] (do_bind_con_driver) from [] > (do_take_over_console+0x13c/0x1c4) > [] (do_take_over_console) from [] > (do_fbcon_takeover+0x74/0xcc) > [] (do_fbcon_takeover) from [] > (notifier_call_chain+0x44/0x84) > [] (notifier_call_chain) from [] > (__blocking_notifier_call_chain+0x48/0x60) > [] (__blocking_notifier_call_chain) from [] > (blocking_notifier_call_chain+0x18/0x20) > [] (blocking_notifier_call_chain) from [] > (register_framebuffer+0x1e0/0x2f8) > [] (register_framebuffer) from [] > (__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c) > [] (__drm_fb_helper_initial_config_and_unlock) from [] > (drm_fbdev_client_hotplug+0xe8/0x1b8) > [] (drm_fbdev_client_hotplug) from [] > (drm_fbdev_generic_setup+0x88/0x118) > [] (drm_fbdev_generic_setup) from [] > (sun4i_drv_bind+0x128/0x160) > [] (sun4i_drv_bind) from [] > (try_to_bring_up_master+0x164/0x1a0) > [] (try_to_bring_up_master) from [] > (__component_add+0x94/0x140) > [] (__component_add) from [] > (sun6i_dsi_probe+0x144/0x234) > [] (sun6i_dsi_probe) from [] > (platform_drv_probe+0x48/0x9c) > [] (platform_drv_probe) from [] > (really_probe+0x1dc/0x2c8) > [] (really_probe) from [] > (driver_probe_device+0x60/0x160) > [] (driver_probe_device) from [] > (bus_for_each_drv+0x74/0xb8) > [] (bus_for_each_drv) from [] > (__device_attach+0xd0/0x13c) > [] (__device_attach) from [] (bus_probe_device+0x84/0x8c) > [] (bus_probe_device) from [] > (deferred_probe_work_func+0x64/0x90) > [] (deferred_probe_work_func) from [] > (process_one_work+0x204/0x420) > [] (process_one_work) from [] (worker_thread+0x274/0x5a0) > [] (worker_thread) from [] (kthread+0x11c/0x14c) > [] (kthread) from [] (ret_from_fork+0x14/0x2c) > Exception stack(0xde539fb0 to 0xde539ff8) > 9fa0: > 9fc0: > 9fe0: 0013 > ---[ end trace 4017fea4906ab391 ]--- > > But accordingly to Allwinner A33, A64 BSP codes [1] [2] this divider > is clearly using 'format/lanes' for dsi divider value, dsi_clk.clk_div > > Which would compute the pll_freq and set a clock rate for it in > [3] and [4] respectively. > > The same issue has reproduced in A33, A64 with 4-lane and 2-lane devices > and got fixed with this computation logic 'format/lanes', so this patch > using dclk min and max dividers as per BSP. > > [1] > https://github.com/BPI-SINOVOIP/BPI-M2M-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp/de/disp_lcd.c#L1106 > [2] > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/disp_al.c#L213 > [3] > https://github.com/BPI-SINOVOIP/BPI-M2M-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp/de/disp_lcd.c#L1127 > [4] > https://github.com/BPI-SINOVOIP/BPI-M2M-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp/de/disp_lcd.c#L1161 In that mail, I've pointed out that
Re: [PATCH v10 03/11] drm/sun4i: dsi: Fix video start delay computation
On Mon, May 20, 2019 at 02:33:10PM +0530, Jagan Teki wrote: > The current code is computing vertical video start delay as > > delay = mode->vtotal - (mode->vsync_end - mode->vdisplay) + start; > > On which the second parameter > > mode->vsync_end - mode->vdisplay = front porch + sync timings > > according to "DRM kernel-internal display mode structure" in > include/drm/drm_modes.h > > With adding additional sync timings, the desired video start delay > value as 510 for "bananapi,s070wv20-ct16" panel timings which indeed > trigger panel flip_done timed out as: > > WARNING: CPU: 0 PID: 31 at drivers/gpu/drm/drm_atomic_helper.c:1429 > drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 > [CRTC:46:crtc-0] vblank wait timed out > Modules linked in: > CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted > 5.1.0-next-20190514-00029-g09e5b0ed0a58 #18 > Hardware name: Allwinner sun8i Family > Workqueue: events deferred_probe_work_func > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > [] (show_stack) from [] (dump_stack+0x84/0x98) > [] (dump_stack) from [] (__warn+0xfc/0x114) > [] (__warn) from [] (warn_slowpath_fmt+0x44/0x68) > [] (warn_slowpath_fmt) from [] > (drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) > [] (drm_atomic_helper_wait_for_vblanks.part.1) from [] > (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) > [] (drm_atomic_helper_commit_tail_rpm) from [] > (commit_tail+0x40/0x6c) > [] (commit_tail) from [] > (drm_atomic_helper_commit+0xbc/0x128) > [] (drm_atomic_helper_commit) from [] > (restore_fbdev_mode_atomic+0x1cc/0x1dc) > [] (restore_fbdev_mode_atomic) from [] > (drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa0) > [] (drm_fb_helper_restore_fbdev_mode_unlocked) from [] > (drm_fb_helper_set_par+0x30/0x54) > [] (drm_fb_helper_set_par) from [] > (fbcon_init+0x560/0x5ac) > [] (fbcon_init) from [] (visual_init+0xbc/0x104) > [] (visual_init) from [] (do_bind_con_driver+0x1b0/0x390) > [] (do_bind_con_driver) from [] > (do_take_over_console+0x13c/0x1c4) > [] (do_take_over_console) from [] > (do_fbcon_takeover+0x74/0xcc) > [] (do_fbcon_takeover) from [] > (notifier_call_chain+0x44/0x84) > [] (notifier_call_chain) from [] > (__blocking_notifier_call_chain+0x48/0x60) > [] (__blocking_notifier_call_chain) from [] > (blocking_notifier_call_chain+0x18/0x20) > [] (blocking_notifier_call_chain) from [] > (register_framebuffer+0x1e0/0x2f8) > [] (register_framebuffer) from [] > (__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c) > [] (__drm_fb_helper_initial_config_and_unlock) from [] > (drm_fbdev_client_hotplug+0xe8/0x1b8) > [] (drm_fbdev_client_hotplug) from [] > (drm_fbdev_generic_setup+0x88/0x118) > [] (drm_fbdev_generic_setup) from [] > (sun4i_drv_bind+0x128/0x160) > [] (sun4i_drv_bind) from [] > (try_to_bring_up_master+0x164/0x1a0) > [] (try_to_bring_up_master) from [] > (__component_add+0x94/0x140) > [] (__component_add) from [] > (sun6i_dsi_probe+0x144/0x234) > [] (sun6i_dsi_probe) from [] > (platform_drv_probe+0x48/0x9c) > [] (platform_drv_probe) from [] > (really_probe+0x1dc/0x2c8) > [] (really_probe) from [] > (driver_probe_device+0x60/0x160) > [] (driver_probe_device) from [] > (bus_for_each_drv+0x74/0xb8) > [] (bus_for_each_drv) from [] > (__device_attach+0xd0/0x13c) > [] (__device_attach) from [] (bus_probe_device+0x84/0x8c) > [] (bus_probe_device) from [] > (deferred_probe_work_func+0x64/0x90) > [] (deferred_probe_work_func) from [] > (process_one_work+0x204/0x420) > [] (process_one_work) from [] (worker_thread+0x274/0x5a0) > [] (worker_thread) from [] (kthread+0x11c/0x14c) > [] (kthread) from [] (ret_from_fork+0x14/0x2c) > Exception stack(0xde539fb0 to 0xde539ff8) > 9fa0: > 9fc0: > 9fe0: 0013 > ---[ end trace 495200a78b24980e ]--- > random: fast init done > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:46:crtc-0] > flip_done timed out > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:48:DSI-1] > flip_done timed out > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:30:plane-0] > flip_done timed out > > But the expected video start delay value is 513 which states that > the second parameter on the computation is "front porch" value > (no sync timings included). > > This is clearly confirmed from the legacy [1] and new [2] bsp codes > that the second parameter on the video start delay is "front porch" > > Here is the detailed evidence for calculating front porch as per > bsp code. > > vfp = panel->lcd_vt - panel->lcd_y - panel->lcd_vbp > => (panel->lcd_vt) - panel->lcd_y - panel->lcd_vbp > => (tt->ver_front_porch + lcdp->panel_info.lcd_vbp > + lcdp->panel_info.lcd_y) - panel->lcd_y - panel->lcd_vbp > => tt->ver_front_porch The comment on patch 1 still applies on this
Re: [PATCH v2 2/6] drm/msm/a6xx: Remove duplicate irq disable from remove
On Thu, May 23, 2019 at 01:16:41PM -0400, Sean Paul wrote: > From: Sean Paul > > a6xx_gmu_stop() already calls this function via shutdown or force_stop, > so it's not necessary to call it twice. Previously this would have > knocked the irq refcount out of sync, but now with the irqs_enabled flag > it's just housekeeping. > > Changes in v2: > - None > > Cc: Jordan Crouse > Signed-off-by: Sean Paul Reviewed-by: Jordan Crouse > --- > drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > index aa84edb25d91..742c8ff9a61c 100644 > --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > @@ -1239,7 +1239,6 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu) > dev_pm_domain_detach(gmu->gxpd, false); > } > > - a6xx_gmu_irq_disable(gmu); > a6xx_gmu_memory_free(gmu, gmu->hfi); > > iommu_detach_device(gmu->domain, gmu->dev); > -- > Sean Paul, Software Engineer, Google / Chromium OS > -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/6] drm/msm/a6xx: Avoid freeing gmu resources multiple times
On Thu, May 23, 2019 at 01:16:40PM -0400, Sean Paul wrote:
> From: Sean Paul
>
> The driver checks for gmu->mmio as a sign that the device has been
> initialized, however there are failures in probe below the mmio init.
> If one of those is hit, mmio will be non-null but freed.
>
> In that case, a6xx_gmu_probe will return an error to a6xx_gpu_init which
> will in turn call a6xx_gmu_remove which checks gmu->mmio and tries to free
> resources for a second time. This causes a great boom.
>
> Fix this by adding an initialized member to gmu which is set on
> successful probe and cleared on removal.
>
> Changes in v2:
> - None
>
> Cc: Jordan Crouse
> Signed-off-by: Sean Paul
Reviewed-by: Jordan Crouse
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 14 +-
> drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 1 +
> 2 files changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> index 38e2cfa9cec7..aa84edb25d91 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> @@ -74,7 +74,7 @@ bool a6xx_gmu_sptprac_is_on(struct a6xx_gmu *gmu)
> u32 val;
>
> /* This can be called from gpu state code so make sure GMU is valid */
> - if (IS_ERR_OR_NULL(gmu->mmio))
> + if (!gmu->initialized)
> return false;
>
> val = gmu_read(gmu, REG_A6XX_GMU_SPTPRAC_PWR_CLK_STATUS);
> @@ -90,7 +90,7 @@ bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
> u32 val;
>
> /* This can be called from gpu state code so make sure GMU is valid */
> - if (IS_ERR_OR_NULL(gmu->mmio))
> + if (!gmu->initialized)
> return false;
>
> val = gmu_read(gmu, REG_A6XX_GMU_SPTPRAC_PWR_CLK_STATUS);
> @@ -695,7 +695,7 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
> struct a6xx_gmu *gmu = _gpu->gmu;
> int status, ret;
>
> - if (WARN(!gmu->mmio, "The GMU is not set up yet\n"))
> + if (WARN(!gmu->initialized, "The GMU is not set up yet\n"))
> return 0;
>
> gmu->hung = false;
> @@ -765,7 +765,7 @@ bool a6xx_gmu_isidle(struct a6xx_gmu *gmu)
> {
> u32 reg;
>
> - if (!gmu->mmio)
> + if (!gmu->initialized)
> return true;
>
> reg = gmu_read(gmu, REG_A6XX_GPU_GMU_AO_GPU_CX_BUSY_STATUS);
> @@ -1227,7 +1227,7 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
> {
> struct a6xx_gmu *gmu = _gpu->gmu;
>
> - if (IS_ERR_OR_NULL(gmu->mmio))
> + if (!gmu->initialized)
> return;
>
> a6xx_gmu_stop(a6xx_gpu);
> @@ -1245,6 +1245,8 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
> iommu_detach_device(gmu->domain, gmu->dev);
>
> iommu_domain_free(gmu->domain);
> +
> + gmu->initialized = false;
> }
>
> int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct device_node *node)
> @@ -1309,6 +1311,8 @@ int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct
> device_node *node)
> /* Set up the HFI queues */
> a6xx_hfi_init(gmu);
>
> + gmu->initialized = true;
> +
> return 0;
> err:
> a6xx_gmu_memory_free(gmu, gmu->hfi);
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
> b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
> index bedd8e6a63aa..39a26dd63674 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
> @@ -75,6 +75,7 @@ struct a6xx_gmu {
>
> struct a6xx_hfi_queue queues[2];
>
> + bool initialized;
> bool hung;
> };
>
> --
> Sean Paul, Software Engineer, Google / Chromium OS
>
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 02/11] drm/sun4i: dsi: Update start value in video start delay
On Mon, May 20, 2019 at 02:33:09PM +0530, Jagan Teki wrote: > start value in video start delay computation done in below commit > is as per the legacy bsp drivers/video/sunxi/legacy.. > "drm/sun4i: dsi: Change the start delay calculation" > (sha1: da676c6aa6413d59ab0a80c97bbc273025e640b2) > > This existing start delay computation gives start value of 35, > for "bananapi,s070wv20-ct16" panel timings which indeed trigger > panel flip_done timed out as: > > WARNING: CPU: 0 PID: 31 at drivers/gpu/drm/drm_atomic_helper.c:1429 > drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 > [CRTC:46:crtc-0] vblank wait timed out > Modules linked in: > CPU: 0 PID: 31 Comm: kworker/0:1 Tainted: GW > 5.1.0-next-20190514-00025-gf928bc7cc146 #15 > Hardware name: Allwinner sun8i Family > Workqueue: events deferred_probe_work_func > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > [] (show_stack) from [] (dump_stack+0x84/0x98) > [] (dump_stack) from [] (__warn+0xfc/0x114) > [] (__warn) from [] (warn_slowpath_fmt+0x44/0x68) > [] (warn_slowpath_fmt) from [] > (drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) > [] (drm_atomic_helper_wait_for_vblanks.part.1) from [] > (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) > [] (drm_atomic_helper_commit_tail_rpm) from [] > (commit_tail+0x40/0x6c) > [] (commit_tail) from [] > (drm_atomic_helper_commit+0xbc/0x128) > [] (drm_atomic_helper_commit) from [] > (restore_fbdev_mode_atomic+0x1cc/0x1dc) > [] (restore_fbdev_mode_atomic) from [] > (drm_fb_helper_pan_display+0xac/0x1d0) > [] (drm_fb_helper_pan_display) from [] > (fb_pan_display+0xcc/0x134) > [] (fb_pan_display) from [] (bit_update_start+0x14/0x30) > [] (bit_update_start) from [] (fbcon_switch+0x3d8/0x4e0) > [] (fbcon_switch) from [] (redraw_screen+0x174/0x238) > [] (redraw_screen) from [] > (fbcon_prepare_logo+0x3c4/0x400) > [] (fbcon_prepare_logo) from [] (fbcon_init+0x3c8/0x5ac) > [] (fbcon_init) from [] (visual_init+0xbc/0x104) > [] (visual_init) from [] (do_bind_con_driver+0x1b0/0x390) > [] (do_bind_con_driver) from [] > (do_take_over_console+0x13c/0x1c4) > [] (do_take_over_console) from [] > (do_fbcon_takeover+0x74/0xcc) > [] (do_fbcon_takeover) from [] > (notifier_call_chain+0x44/0x84) > [] (notifier_call_chain) from [] > (__blocking_notifier_call_chain+0x48/0x60) > [] (__blocking_notifier_call_chain) from [] > (blocking_notifier_call_chain+0x18/0x20) > [] (blocking_notifier_call_chain) from [] > (register_framebuffer+0x1e0/0x2f8) > [] (register_framebuffer) from [] > (__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c) > [] (__drm_fb_helper_initial_config_and_unlock) from [] > (drm_fbdev_client_hotplug+0xe8/0x1b8) > [] (drm_fbdev_client_hotplug) from [] > (drm_fbdev_generic_setup+0x88/0x118) > [] (drm_fbdev_generic_setup) from [] > (sun4i_drv_bind+0x128/0x160) > [] (sun4i_drv_bind) from [] > (try_to_bring_up_master+0x164/0x1a0) > [] (try_to_bring_up_master) from [] > (__component_add+0x94/0x140) > [] (__component_add) from [] > (sun6i_dsi_probe+0x144/0x234) > [] (sun6i_dsi_probe) from [] > (platform_drv_probe+0x48/0x9c) > [] (platform_drv_probe) from [] > (really_probe+0x1dc/0x2c8) > [] (really_probe) from [] > (driver_probe_device+0x60/0x160) > [] (driver_probe_device) from [] > (bus_for_each_drv+0x74/0xb8) > [] (bus_for_each_drv) from [] > (__device_attach+0xd0/0x13c) > [] (__device_attach) from [] (bus_probe_device+0x84/0x8c) > [] (bus_probe_device) from [] > (deferred_probe_work_func+0x64/0x90) > [] (deferred_probe_work_func) from [] > (process_one_work+0x204/0x420) > [] (process_one_work) from [] (worker_thread+0x274/0x5a0) > [] (worker_thread) from [] (kthread+0x11c/0x14c) > [] (kthread) from [] (ret_from_fork+0x14/0x2c) > Exception stack(0xde539fb0 to 0xde539ff8) > 9fa0: > 9fc0: > 9fe0: 0013 > ---[ end trace 755e10f62b83f396 ]--- > Console: switching to colour frame buffer device 100x30 > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:46:crtc-0] > flip_done timed out > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:48:DSI-1] > flip_done timed out > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:30:plane-0] > flip_done timed out > > But the expected start delay value is 1 which is confirmed from > new bsp [2]. If you're saying that the "legacy" link (second one) is the new BSP. > The important and unclear note on legacy and new bsp codes [1] [2] > is both use similar start computation initially but it later reassign > it to 1 in new bsp. Then start_delay is never reassigned to 1 in that link, and is clamped between 8 and 100 as the code that you are removing is doing. > Unfortunately we don't have any evidence or documentation for this > reassignment to 1 in new bsp,
Re: [PATCH v10 01/11] drm/sun4i: dsi: Fix TCON DRQ set bits
On Mon, May 20, 2019 at 02:33:08PM +0530, Jagan Teki wrote: > According to "DRM kernel-internal display mode structure" in > include/drm/drm_modes.h the current driver is trying to include > sync timings along with front porch value while checking and > computing drq set bits in non-burst mode. > > mode->hsync_end - mode->hdisplay => horizontal front porch + sync > > With adding additional sync timings, the dsi controller leads to > wrong drq set bits for "bananapi,s070wv20-ct16" panel which indeed > trigger panel flip_done timed out as: > > WARNING: CPU: 0 PID: 31 at drivers/gpu/drm/drm_atomic_helper.c:1429 > drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 > [CRTC:46:crtc-0] vblank wait timed out > Modules linked in: > CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted > 5.1.0-next-20190514-00026-g01f0c75b902d-dirty #13 > Hardware name: Allwinner sun8i Family > Workqueue: events deferred_probe_work_func > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > [] (show_stack) from [] (dump_stack+0x84/0x98) > [] (dump_stack) from [] (__warn+0xfc/0x114) > [] (__warn) from [] (warn_slowpath_fmt+0x44/0x68) > [] (warn_slowpath_fmt) from [] > (drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) > [] (drm_atomic_helper_wait_for_vblanks.part.1) from [] > (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) > [] (drm_atomic_helper_commit_tail_rpm) from [] > (commit_tail+0x40/0x6c) > [] (commit_tail) from [] > (drm_atomic_helper_commit+0xbc/0x128) > [] (drm_atomic_helper_commit) from [] > (restore_fbdev_mode_atomic+0x1cc/0x1dc) > [] (restore_fbdev_mode_atomic) from [] > (drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa0) > [] (drm_fb_helper_restore_fbdev_mode_unlocked) from [] > (drm_fb_helper_set_par+0x30/0x54) > [] (drm_fb_helper_set_par) from [] > (fbcon_init+0x560/0x5ac) > [] (fbcon_init) from [] (visual_init+0xbc/0x104) > [] (visual_init) from [] (do_bind_con_driver+0x1b0/0x390) > [] (do_bind_con_driver) from [] > (do_take_over_console+0x13c/0x1c4) > [] (do_take_over_console) from [] > (do_fbcon_takeover+0x74/0xcc) > [] (do_fbcon_takeover) from [] > (notifier_call_chain+0x44/0x84) > [] (notifier_call_chain) from [] > (__blocking_notifier_call_chain+0x48/0x60) > [] (__blocking_notifier_call_chain) from [] > (blocking_notifier_call_chain+0x18/0x20) > [] (blocking_notifier_call_chain) from [] > (register_framebuffer+0x1e0/0x2f8) > [] (register_framebuffer) from [] > (__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c) > [] (__drm_fb_helper_initial_config_and_unlock) from [] > (drm_fbdev_client_hotplug+0xe8/0x1b8) > [] (drm_fbdev_client_hotplug) from [] > (drm_fbdev_generic_setup+0x88/0x118) > [] (drm_fbdev_generic_setup) from [] > (sun4i_drv_bind+0x128/0x160) > [] (sun4i_drv_bind) from [] > (try_to_bring_up_master+0x164/0x1a0) > [] (try_to_bring_up_master) from [] > (__component_add+0x94/0x140) > [] (__component_add) from [] > (sun6i_dsi_probe+0x144/0x234) > [] (sun6i_dsi_probe) from [] > (platform_drv_probe+0x48/0x9c) > [] (platform_drv_probe) from [] > (really_probe+0x1dc/0x2c8) > [] (really_probe) from [] > (driver_probe_device+0x60/0x160) > [] (driver_probe_device) from [] > (bus_for_each_drv+0x74/0xb8) > [] (bus_for_each_drv) from [] > (__device_attach+0xd0/0x13c) > [] (__device_attach) from [] (bus_probe_device+0x84/0x8c) > [] (bus_probe_device) from [] > (deferred_probe_work_func+0x64/0x90) > [] (deferred_probe_work_func) from [] > (process_one_work+0x204/0x420) > [] (process_one_work) from [] (worker_thread+0x274/0x5a0) > [] (worker_thread) from [] (kthread+0x11c/0x14c) > [] (kthread) from [] (ret_from_fork+0x14/0x2c) > Exception stack(0xde539fb0 to 0xde539ff8) > 9fa0: > 9fc0: > 9fe0: 0013 > ---[ end trace b57eb1e5c64c6b8b ]--- > random: fast init done > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:46:crtc-0] > flip_done timed out > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:48:DSI-1] > flip_done timed out > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:30:plane-0] > flip_done timed out > > But according to Allwinner A33, A64 BSP code [1] [3] the TCON DRQ for > non-burst DSI mode can be computed based on "horizontal front porch" > value only (no sync timings included). > > Detailed evidence for drq set bits based on A33 BSP [1] [2] > > => panel->lcd_ht - panel->lcd_x - panel->lcd_hbp - 20 > => (tt->hor_front_porch + lcdp->panel_info.lcd_hbp + > lcdp->panel_info.lcd_x) - panel->lcd_x - panel->lcd_hbp - 20 > => tt->hor_front_porch - 20 The thing is, while your explanation on the DRM side is sound, Allwinner has been using the hbp field of their panel description to store what DRM calls the backporch and the sync period. And nowhere in that commit log you are describing whether
Re: [PATCHv6 1/4] drm/omap: use DRM_DEBUG_DRIVER instead of CORE
On Thu, 2019-05-23 at 22:07 +0200, Sebastian Reichel wrote:
> This macro is only used by omapdrm, which should print
> debug messages using the DRIVER category instead of the
> default CORE category.
[]
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h
> b/drivers/gpu/drm/omapdrm/omap_drv.h
[]
> @@ -37,8 +37,8 @@
> #include "omap_irq.h"
> #include "omap_plane.h"
>
> -#define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)
> -#define VERB(fmt, ...) if (0) DRM_DEBUG(fmt, ##__VA_ARGS__) /* verbose debug
> */
> +#define DBG(fmt, ...) DRM_DEBUG_DRIVER(fmt"\n", ##__VA_ARGS__)
> +#define VERB(fmt, ...) if (0) DRM_DEBUG_DRIVER(fmt, ##__VA_ARGS__) /*
> verbose debug */
Trivia:
Strictly, this should use do { if (0) etc... } while (0)
Also, none of the VERB uses have a terminating newline
so ideally, this should be:
#define VERB(fmt, ...) do { if (0) DRM_DEBUG_DRIVER(fmt "\n", ##__VA_ARGS__); }
while (0) /* verbose debug */
And VERB isn't a particularly intelligible macro name.
Maybe VDBG instead.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110712] [regression]Raven Ridge: System freeze but mouse cursor able to move when using Firefox Webrender.
https://bugs.freedesktop.org/show_bug.cgi?id=110712 --- Comment #1 from Haxk20 --- Im have not been able to get dmesg in the past few days and will not be able to get one in upcoming few days but hopefully i will be able to get one by the end of the month. If somebody could post dmesg in the mean time that would be fantastic. And if we could get somebody to look at this it would be even more awesome. -- 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
[PATCHv6 2/4] drm/omap: don't check dispc timings for DSI
While most display types only forward their VM to the DISPC, this
is not true for DSI. DSI calculates the VM for DISPC based on its
own, but it's not identical. Actually the DSI VM is not even a valid
DISPC VM making this check fail. Let's restore the old behaviour
and avoid checking the DISPC VM for DSI here.
Fixes: 7c27fa57ef31 ("drm/omap: Call dispc timings check operation directly")
Acked-by: Pavel Machek
Tested-by: Tony Lindgren
Tested-by: Pavel Machek
Signed-off-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 5a29bf01c0e8..86827a061b0b 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -395,10 +395,20 @@ static enum drm_mode_status omap_crtc_mode_valid(struct
drm_crtc *crtc,
int r;
drm_display_mode_to_videomode(mode, );
- r = priv->dispc_ops->mgr_check_timings(priv->dispc, omap_crtc->channel,
- );
- if (r)
- return r;
+
+ /*
+* DSI might not call this, since the supplied mode is not a
+* valid DISPC mode. DSI will calculate and configure the
+* proper DISPC mode later.
+*/
+ if (omap_crtc->pipe->output->next == NULL ||
+ omap_crtc->pipe->output->next->type != OMAP_DISPLAY_TYPE_DSI) {
+ r = priv->dispc_ops->mgr_check_timings(priv->dispc,
+ omap_crtc->channel,
+ );
+ if (r)
+ return r;
+ }
/* Check for bandwidth limit */
if (priv->max_bandwidth) {
--
2.20.1
[PATCHv6 4/4] drm/omap: add support for manually updated displays
This adds the required infrastructure for manually updated displays,
such as DSI command mode panels. While those panels often support
partial updates we currently always do a full refresh.
The display will be refreshed when something calls the dirty callback,
such as libdrm's drmModeDirtyFB(). This is currently being done at least
by the kernel console and Xorg (with modesetting driver) in their
default configuration. Weston does not implement this and the fbdev
backend does not work (display will not update). Weston's DRM backend
uses double buffering and the page flip will also trigger a display
refresh.
Signed-off-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 114 ++--
drivers/gpu/drm/omapdrm/omap_crtc.h | 1 +
drivers/gpu/drm/omapdrm/omap_fb.c | 19 +
3 files changed, 129 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 68697820d189..b59065365c9e 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -32,6 +32,7 @@ struct omap_crtc_state {
/* Shadow values for legacy userspace support. */
unsigned int rotation;
unsigned int zpos;
+ bool manually_updated;
};
#define to_omap_crtc(x) container_of(x, struct omap_crtc, base)
@@ -51,6 +52,7 @@ struct omap_crtc {
bool pending;
wait_queue_head_t pending_wait;
struct drm_pending_vblank_event *event;
+ struct delayed_work update_work;
void (*framedone_handler)(void *);
void *framedone_handler_data;
@@ -105,21 +107,18 @@ int omap_crtc_wait_pending(struct drm_crtc *crtc)
/*
* Manager-ops, callbacks from output when they need to configure
* the upstream part of the video pipe.
- *
- * Most of these we can ignore until we add support for command-mode
- * panels.. for video-mode the crtc-helpers already do an adequate
- * job of sequencing the setup of the video pipe in the proper order
*/
-/* we can probably ignore these until we support command-mode panels: */
static void omap_crtc_dss_start_update(struct omap_drm_private *priv,
enum omap_channel channel)
{
+ priv->dispc_ops->mgr_enable(priv->dispc, channel, true);
}
/* Called only from the encoder enable/disable and suspend/resume handlers. */
static void omap_crtc_set_enabled(struct drm_crtc *crtc, bool enable)
{
+ struct omap_crtc_state *omap_state = to_omap_crtc_state(crtc->state);
struct drm_device *dev = crtc->dev;
struct omap_drm_private *priv = dev->dev_private;
struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
@@ -131,6 +130,12 @@ static void omap_crtc_set_enabled(struct drm_crtc *crtc,
bool enable)
if (WARN_ON(omap_crtc->enabled == enable))
return;
+ if (omap_state->manually_updated) {
+ omap_irq_enable_framedone(crtc, enable);
+ omap_crtc->enabled = enable;
+ return;
+ }
+
if (omap_crtc->pipe->output->type == OMAP_DISPLAY_TYPE_HDMI) {
priv->dispc_ops->mgr_enable(priv->dispc, channel, enable);
omap_crtc->enabled = enable;
@@ -352,6 +357,51 @@ void omap_crtc_framedone_irq(struct drm_crtc *crtc,
uint32_t irqstatus)
wake_up(_crtc->pending_wait);
}
+void omap_crtc_flush(struct drm_crtc *crtc)
+{
+ struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+ struct omap_crtc_state *omap_state = to_omap_crtc_state(crtc->state);
+
+ if (!omap_state->manually_updated)
+ return;
+
+ if (!delayed_work_pending(_crtc->update_work))
+ schedule_delayed_work(_crtc->update_work, 0);
+}
+
+static void omap_crtc_manual_display_update(struct work_struct *data)
+{
+ struct omap_crtc *omap_crtc =
+ container_of(data, struct omap_crtc, update_work.work);
+ struct drm_display_mode *mode = _crtc->pipe->crtc->mode;
+ struct omap_dss_device *dssdev = omap_crtc->pipe->output->next;
+ struct drm_device *dev = omap_crtc->base.dev;
+ const struct omap_dss_driver *dssdrv;
+ int ret;
+
+ if (!dssdev) {
+ dev_err_once(dev->dev, "missing display dssdev!");
+ return;
+ }
+
+ dssdrv = dssdev->driver;
+ if (!dssdrv || !dssdrv->update) {
+ dev_err_once(dev->dev, "missing or incorrect dssdrv!");
+ return;
+ }
+
+ if (dssdrv->sync)
+ dssdrv->sync(dssdev);
+
+ ret = dssdrv->update(dssdev, 0, 0, mode->hdisplay, mode->vdisplay);
+ if (ret < 0) {
+ spin_lock_irq(>event_lock);
+ omap_crtc->pending = false;
+ spin_unlock_irq(>event_lock);
+ wake_up(_crtc->pending_wait);
+ }
+}
+
static void omap_crtc_write_crtc_properties(struct drm_crtc *crtc)
{
struct omap_drm_private *priv =
[PATCHv6 0/4] omapdrm: DSI command mode panel support
Hi, Here is another round of the DSI command mode panel patchset integrating the feedback from PATCHv5. The patches are based on v5.2-rc1 tag. It does not contain the patches required for OMAP3 support (it needs a workaround for a hardware bug) and for automatic display rotation. They should get their own series, once after everything has been moved to DRM panel API. I think DRM panel conversion should happen _after_ this series, since otherwise there is a high risk of bricking DSI support completely. I already started a WIP branch for converting DSI to the DRM panel API on top of this patchset. Tested on Droid 4: * Display blanking - automatic backlight blanking is missing (not handled by DSI) * Framebuffer Console, updated at 1Hz due to blinking cursor * Xorg 1.19 with modesetting driver * Weston 5.0 with DRM backend * kmstest (static image) * No updates send when nothing needs to be sent Known issues: * OMAP3 is untested and most likely broken due to missing workaround(s) for hardware bugs. * Weston 5.0 with fbdev backend does not work, since it uses neither page flip nor dirty ioctl. You need to use the drm backend. Changes since PATCHv5: * Rebased to v5.2-rc1 * Simplified omap_framebuffer_dirty() by using drm_for_each_crtc() Changes since PATCHv4: * Apply Acked-/Tested-by received from Tony and Pavel * Fix spelling/optimize commit messages * Use proper multi-line comments * Restructure patch 4: move the whole HDMI block into a static subfunction, that is only called when output type is HDMI. Also drop the incorrect check for DVI. Changes since PATCHv3: * Drop all Tested/Acked-by tags * Drop the rotation patches for now * Rebase to 4.20-rc1 + fixes from Laurent and Tony * Add fixes for DSI regressions introduced in 4.20-rc1 * Store info update manual update mode in omap_crtc_state * Lock modesetting in omap_framebuffer_dirty * Directly loop through CRTCs instead of connectors in dirty function * Properly refresh display during page flips and get Weston working * Add more comments about implementation details Changes since PATCHv2: * Drop omap3 quirk patch (OMAP3 should get its own mini-series) * Rebase to current linux-next * Use existing 'rotation' DT property to set DRM orientation hint * Add Tested-by from Tony Changes since PATCHv1: * Drop patches, that were queued by Tomi * Rebase to current master * Rework the omap3 workaround patch to only affect omap3 * Add orientation DRM property support -- Sebastian Sebastian Reichel (4): drm/omap: use DRM_DEBUG_DRIVER instead of CORE drm/omap: don't check dispc timings for DSI drm/omap: add framedone interrupt support drm/omap: add support for manually updated displays drivers/gpu/drm/omapdrm/omap_crtc.c | 182 ++-- drivers/gpu/drm/omapdrm/omap_crtc.h | 2 + drivers/gpu/drm/omapdrm/omap_drv.h | 4 +- drivers/gpu/drm/omapdrm/omap_fb.c | 19 +++ drivers/gpu/drm/omapdrm/omap_irq.c | 25 drivers/gpu/drm/omapdrm/omap_irq.h | 1 + 6 files changed, 222 insertions(+), 11 deletions(-) -- 2.20.1
[PATCHv6 1/4] drm/omap: use DRM_DEBUG_DRIVER instead of CORE
This macro is only used by omapdrm, which should print debug messages using the DRIVER category instead of the default CORE category. Acked-by: Pavel Machek Tested-by: Tony Lindgren Tested-by: Pavel Machek Signed-off-by: Sebastian Reichel --- drivers/gpu/drm/omapdrm/omap_drv.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h b/drivers/gpu/drm/omapdrm/omap_drv.h index 3cca45cb25f3..896aa12f09b2 100644 --- a/drivers/gpu/drm/omapdrm/omap_drv.h +++ b/drivers/gpu/drm/omapdrm/omap_drv.h @@ -37,8 +37,8 @@ #include "omap_irq.h" #include "omap_plane.h" -#define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__) -#define VERB(fmt, ...) if (0) DRM_DEBUG(fmt, ##__VA_ARGS__) /* verbose debug */ +#define DBG(fmt, ...) DRM_DEBUG_DRIVER(fmt"\n", ##__VA_ARGS__) +#define VERB(fmt, ...) if (0) DRM_DEBUG_DRIVER(fmt, ##__VA_ARGS__) /* verbose debug */ #define MODULE_NAME "omapdrm" -- 2.20.1
[PATCHv6 3/4] drm/omap: add framedone interrupt support
This prepares framedone interrupt handling for
manual display update support.
Acked-by: Pavel Machek
Tested-by: Tony Lindgren
Tested-by: Pavel Machek
Signed-off-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 50 +
drivers/gpu/drm/omapdrm/omap_crtc.h | 1 +
drivers/gpu/drm/omapdrm/omap_irq.c | 25 +++
drivers/gpu/drm/omapdrm/omap_irq.h | 1 +
4 files changed, 77 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 86827a061b0b..68697820d189 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -51,6 +51,9 @@ struct omap_crtc {
bool pending;
wait_queue_head_t pending_wait;
struct drm_pending_vblank_event *event;
+
+ void (*framedone_handler)(void *);
+ void *framedone_handler_data;
};
/*
-
@@ -230,6 +233,18 @@ static int omap_crtc_dss_register_framedone(
struct omap_drm_private *priv, enum omap_channel channel,
void (*handler)(void *), void *data)
{
+ struct drm_crtc *crtc = priv->channels[channel]->crtc;
+ struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+ struct drm_device *dev = omap_crtc->base.dev;
+
+ if (omap_crtc->framedone_handler)
+ return -EBUSY;
+
+ dev_dbg(dev->dev, "register framedone %s", omap_crtc->name);
+
+ omap_crtc->framedone_handler = handler;
+ omap_crtc->framedone_handler_data = data;
+
return 0;
}
@@ -237,6 +252,17 @@ static void omap_crtc_dss_unregister_framedone(
struct omap_drm_private *priv, enum omap_channel channel,
void (*handler)(void *), void *data)
{
+ struct drm_crtc *crtc = priv->channels[channel]->crtc;
+ struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+ struct drm_device *dev = omap_crtc->base.dev;
+
+ dev_dbg(dev->dev, "unregister framedone %s", omap_crtc->name);
+
+ WARN_ON(omap_crtc->framedone_handler != handler);
+ WARN_ON(omap_crtc->framedone_handler_data != data);
+
+ omap_crtc->framedone_handler = NULL;
+ omap_crtc->framedone_handler_data = NULL;
}
static const struct dss_mgr_ops mgr_ops = {
@@ -302,6 +328,30 @@ void omap_crtc_vblank_irq(struct drm_crtc *crtc)
DBG("%s: apply done", omap_crtc->name);
}
+void omap_crtc_framedone_irq(struct drm_crtc *crtc, uint32_t irqstatus)
+{
+ struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+
+ if (!omap_crtc->framedone_handler) {
+ dev_warn(omap_crtc->base.dev->dev, "no framedone handler?");
+ return;
+ }
+
+ omap_crtc->framedone_handler(omap_crtc->framedone_handler_data);
+
+ spin_lock(>dev->event_lock);
+ /* Send the vblank event if one has been requested. */
+ if (omap_crtc->event) {
+ drm_crtc_send_vblank_event(crtc, omap_crtc->event);
+ omap_crtc->event = NULL;
+ }
+ omap_crtc->pending = false;
+ spin_unlock(>dev->event_lock);
+
+ /* Wake up omap_atomic_complete. */
+ wake_up(_crtc->pending_wait);
+}
+
static void omap_crtc_write_crtc_properties(struct drm_crtc *crtc)
{
struct omap_drm_private *priv = crtc->dev->dev_private;
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.h
b/drivers/gpu/drm/omapdrm/omap_crtc.h
index d9de437ba9dd..d33bbb7a4f90 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.h
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.h
@@ -41,5 +41,6 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
int omap_crtc_wait_pending(struct drm_crtc *crtc);
void omap_crtc_error_irq(struct drm_crtc *crtc, u32 irqstatus);
void omap_crtc_vblank_irq(struct drm_crtc *crtc);
+void omap_crtc_framedone_irq(struct drm_crtc *crtc, uint32_t irqstatus);
#endif /* __OMAPDRM_CRTC_H__ */
diff --git a/drivers/gpu/drm/omapdrm/omap_irq.c
b/drivers/gpu/drm/omapdrm/omap_irq.c
index 329ad26d6d50..01dda84ca2ee 100644
--- a/drivers/gpu/drm/omapdrm/omap_irq.c
+++ b/drivers/gpu/drm/omapdrm/omap_irq.c
@@ -85,6 +85,28 @@ int omap_irq_wait(struct drm_device *dev, struct
omap_irq_wait *wait,
return ret == 0 ? -1 : 0;
}
+int omap_irq_enable_framedone(struct drm_crtc *crtc, bool enable)
+{
+ struct drm_device *dev = crtc->dev;
+ struct omap_drm_private *priv = dev->dev_private;
+ unsigned long flags;
+ enum omap_channel channel = omap_crtc_channel(crtc);
+ int framedone_irq =
+ priv->dispc_ops->mgr_get_framedone_irq(priv->dispc, channel);
+
+ DBG("dev=%p, crtc=%u, enable=%d", dev, channel, enable);
+
+ spin_lock_irqsave(>wait_lock, flags);
+ if (enable)
+ priv->irq_mask |= framedone_irq;
+ else
+ priv->irq_mask &= ~framedone_irq;
+ omap_irq_update(dev);
+ spin_unlock_irqrestore(>wait_lock, flags);
+
+ return 0;
+}
+
[Bug 110701] GPU faults in in Unigine Valley 1.0
https://bugs.freedesktop.org/show_bug.cgi?id=110701 --- Comment #25 from Christoph Haag --- (In reply to Yury Zhuravlev from comment #24) > (In reply to Marek Olšák from comment #23) > > Fixed by d6053bf2a170a0fec6d232fda097d2f35f0e9eae. Closing. > > The original issue was about Vega and on Vega we saw a different problem. I > suppose before close issue somebody should check patch on Vega. > I will do it soon. Since nobody responded: On a Vega 64 I got GPU faults like the ones posted here followed by a GPU hang immediately when restoring a firefox (nightly) session. With mesa master this does not happen 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
[PATCH 5.1 096/122] PCI: Reset Lenovo ThinkPad P50 nvgpu at boot if necessary
From: Lyude Paul
commit e0547c81bfcfad01cbbfa93a5e66bb98ab932f80 upstream.
On ThinkPad P50 SKUs with an Nvidia Quadro M1000M instead of the M2000M
variant, the BIOS does not always reset the secondary Nvidia GPU during
reboot if the laptop is configured in Hybrid Graphics mode. The reason is
unknown, but the following steps and possibly a good bit of patience will
reproduce the issue:
1. Boot up the laptop normally in Hybrid Graphics mode
2. Make sure nouveau is loaded and that the GPU is awake
3. Allow the Nvidia GPU to runtime suspend itself after being idle
4. Reboot the machine, the more sudden the better (e.g. sysrq-b may help)
5. If nouveau loads up properly, reboot the machine again and go back to
step 2 until you reproduce the issue
This results in some very strange behavior: the GPU will be left in exactly
the same state it was in when the previously booted kernel started the
reboot. This has all sorts of bad side effects: for starters, this
completely breaks nouveau starting with a mysterious EVO channel failure
that happens well before we've actually used the EVO channel for anything:
nouveau :01:00.0: disp: chid 0 mthd data 0400 1000 0002
This causes a timeout trying to bring up the GR ctx:
nouveau :01:00.0: timeout
WARNING: CPU: 0 PID: 12 at
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.c:1547
gf100_grctx_generate+0x7b2/0x850 [nouveau]
Hardware name: LENOVO 20EQS64N0B/20EQS64N0B, BIOS N1EET82W (1.55 ) 12/18/2018
Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper]
...
nouveau :01:00.0: gr: wait for idle timeout (en: 1, ctxsw: 0, busy: 1)
nouveau :01:00.0: gr: wait for idle timeout (en: 1, ctxsw: 0, busy: 1)
nouveau :01:00.0: fifo: fault 01 [WRITE] at 8000 engine 00
[GR] client 15 [HUB/SCC_NB] reason c4 [] on channel -1 [00 unknown]
The GPU never manages to recover. Booting without loading nouveau causes
issues as well, since the GPU starts sending spurious interrupts that cause
other device's IRQs to get disabled by the kernel:
irq 16: nobody cared (try booting with the "irqpoll" option)
...
handlers:
[<7faa9e99>] i801_isr [i2c_i801]
Disabling IRQ #16
...
serio: RMI4 PS/2 pass-through port at rmi4-00.fn03
i801_smbus :00:1f.4: Timeout waiting for interrupt!
i801_smbus :00:1f.4: Transaction timeout
rmi4_f03 rmi4-00.fn03: rmi_f03_pt_write: Failed to write to F03 TX register
(-110).
i801_smbus :00:1f.4: Timeout waiting for interrupt!
i801_smbus :00:1f.4: Transaction timeout
rmi4_physical rmi4-00: rmi_driver_set_irq_bits: Failed to change enabled
interrupts!
This causes the touchpad and sometimes other things to get disabled.
Since this happens without nouveau, we can't fix this problem from nouveau
itself.
Add a PCI quirk for the specific P50 variant of this GPU. Make sure the
GPU is advertising NoReset- so we don't reset the GPU when the machine is
in Dedicated graphics mode (where the GPU being initialized by the BIOS is
normal and expected). Map the GPU MMIO space and read the magic 0x2240c
register, which will have bit 1 set if the device was POSTed during a
previous boot. Once we've confirmed all of this, reset the GPU and
re-disable it - bringing it back to a healthy state.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=203003
Link: https://lore.kernel.org/lkml/20190212220230.1568-1-ly...@redhat.com
Signed-off-by: Lyude Paul
Signed-off-by: Bjorn Helgaas
Cc: nouv...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: Karol Herbst
Cc: Ben Skeggs
Cc: sta...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/pci/quirks.c | 58 +++
1 file changed, 58 insertions(+)
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -5124,3 +5124,61 @@ SWITCHTEC_QUIRK(0x8573); /* PFXI 48XG3
SWITCHTEC_QUIRK(0x8574); /* PFXI 64XG3 */
SWITCHTEC_QUIRK(0x8575); /* PFXI 80XG3 */
SWITCHTEC_QUIRK(0x8576); /* PFXI 96XG3 */
+
+/*
+ * On Lenovo Thinkpad P50 SKUs with a Nvidia Quadro M1000M, the BIOS does
+ * not always reset the secondary Nvidia GPU between reboots if the system
+ * is configured to use Hybrid Graphics mode. This results in the GPU
+ * being left in whatever state it was in during the *previous* boot, which
+ * causes spurious interrupts from the GPU, which in turn causes us to
+ * disable the wrong IRQ and end up breaking the touchpad. Unsurprisingly,
+ * this also completely breaks nouveau.
+ *
+ * Luckily, it seems a simple reset of the Nvidia GPU brings it back to a
+ * clean state and fixes all these issues.
+ *
+ * When the machine is configured in Dedicated display mode, the issue
+ * doesn't occur. Fortunately the GPU advertises NoReset+ when in this
+ * mode, so we can detect that and avoid resetting it.
+ */
+static void quirk_reset_lenovo_thinkpad_p50_nvgpu(struct pci_dev *pdev)
+{
+ void __iomem *map;
+ int
[Bug 110721] graphics corruption on steam client with mesa 19.1.0 rc3 on polaris
https://bugs.freedesktop.org/show_bug.cgi?id=110721 --- Comment #15 from alvarex --- > > Using master + this commit reverted: no more corruption in chromium. I reverted the commit on 19.1.0 rc3 and it works as well. -- 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 5.0 087/139] PCI: Reset Lenovo ThinkPad P50 nvgpu at boot if necessary
From: Lyude Paul
commit e0547c81bfcfad01cbbfa93a5e66bb98ab932f80 upstream.
On ThinkPad P50 SKUs with an Nvidia Quadro M1000M instead of the M2000M
variant, the BIOS does not always reset the secondary Nvidia GPU during
reboot if the laptop is configured in Hybrid Graphics mode. The reason is
unknown, but the following steps and possibly a good bit of patience will
reproduce the issue:
1. Boot up the laptop normally in Hybrid Graphics mode
2. Make sure nouveau is loaded and that the GPU is awake
3. Allow the Nvidia GPU to runtime suspend itself after being idle
4. Reboot the machine, the more sudden the better (e.g. sysrq-b may help)
5. If nouveau loads up properly, reboot the machine again and go back to
step 2 until you reproduce the issue
This results in some very strange behavior: the GPU will be left in exactly
the same state it was in when the previously booted kernel started the
reboot. This has all sorts of bad side effects: for starters, this
completely breaks nouveau starting with a mysterious EVO channel failure
that happens well before we've actually used the EVO channel for anything:
nouveau :01:00.0: disp: chid 0 mthd data 0400 1000 0002
This causes a timeout trying to bring up the GR ctx:
nouveau :01:00.0: timeout
WARNING: CPU: 0 PID: 12 at
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.c:1547
gf100_grctx_generate+0x7b2/0x850 [nouveau]
Hardware name: LENOVO 20EQS64N0B/20EQS64N0B, BIOS N1EET82W (1.55 ) 12/18/2018
Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper]
...
nouveau :01:00.0: gr: wait for idle timeout (en: 1, ctxsw: 0, busy: 1)
nouveau :01:00.0: gr: wait for idle timeout (en: 1, ctxsw: 0, busy: 1)
nouveau :01:00.0: fifo: fault 01 [WRITE] at 8000 engine 00
[GR] client 15 [HUB/SCC_NB] reason c4 [] on channel -1 [00 unknown]
The GPU never manages to recover. Booting without loading nouveau causes
issues as well, since the GPU starts sending spurious interrupts that cause
other device's IRQs to get disabled by the kernel:
irq 16: nobody cared (try booting with the "irqpoll" option)
...
handlers:
[<7faa9e99>] i801_isr [i2c_i801]
Disabling IRQ #16
...
serio: RMI4 PS/2 pass-through port at rmi4-00.fn03
i801_smbus :00:1f.4: Timeout waiting for interrupt!
i801_smbus :00:1f.4: Transaction timeout
rmi4_f03 rmi4-00.fn03: rmi_f03_pt_write: Failed to write to F03 TX register
(-110).
i801_smbus :00:1f.4: Timeout waiting for interrupt!
i801_smbus :00:1f.4: Transaction timeout
rmi4_physical rmi4-00: rmi_driver_set_irq_bits: Failed to change enabled
interrupts!
This causes the touchpad and sometimes other things to get disabled.
Since this happens without nouveau, we can't fix this problem from nouveau
itself.
Add a PCI quirk for the specific P50 variant of this GPU. Make sure the
GPU is advertising NoReset- so we don't reset the GPU when the machine is
in Dedicated graphics mode (where the GPU being initialized by the BIOS is
normal and expected). Map the GPU MMIO space and read the magic 0x2240c
register, which will have bit 1 set if the device was POSTed during a
previous boot. Once we've confirmed all of this, reset the GPU and
re-disable it - bringing it back to a healthy state.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=203003
Link: https://lore.kernel.org/lkml/20190212220230.1568-1-ly...@redhat.com
Signed-off-by: Lyude Paul
Signed-off-by: Bjorn Helgaas
Cc: nouv...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: Karol Herbst
Cc: Ben Skeggs
Cc: sta...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/pci/quirks.c | 58 +++
1 file changed, 58 insertions(+)
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -5122,3 +5122,61 @@ SWITCHTEC_QUIRK(0x8573); /* PFXI 48XG3
SWITCHTEC_QUIRK(0x8574); /* PFXI 64XG3 */
SWITCHTEC_QUIRK(0x8575); /* PFXI 80XG3 */
SWITCHTEC_QUIRK(0x8576); /* PFXI 96XG3 */
+
+/*
+ * On Lenovo Thinkpad P50 SKUs with a Nvidia Quadro M1000M, the BIOS does
+ * not always reset the secondary Nvidia GPU between reboots if the system
+ * is configured to use Hybrid Graphics mode. This results in the GPU
+ * being left in whatever state it was in during the *previous* boot, which
+ * causes spurious interrupts from the GPU, which in turn causes us to
+ * disable the wrong IRQ and end up breaking the touchpad. Unsurprisingly,
+ * this also completely breaks nouveau.
+ *
+ * Luckily, it seems a simple reset of the Nvidia GPU brings it back to a
+ * clean state and fixes all these issues.
+ *
+ * When the machine is configured in Dedicated display mode, the issue
+ * doesn't occur. Fortunately the GPU advertises NoReset+ when in this
+ * mode, so we can detect that and avoid resetting it.
+ */
+static void quirk_reset_lenovo_thinkpad_p50_nvgpu(struct pci_dev *pdev)
+{
+ void __iomem *map;
+ int
[Bug 110217] RX580: screen turns black or flickers until forced reconfiguration
https://bugs.freedesktop.org/show_bug.cgi?id=110217 --- Comment #5 from numz...@yandex.ru --- The flicker seems to be due to https://bugs.freedesktop.org/show_bug.cgi?id=102646, despite the fact Arch wiki tells that affects 120+ Hz only (my monitor runs at 75 Hz). At least fixing clocks fixes 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 110721] graphics corruption on steam client with mesa 19.1.0 rc3 on polaris
https://bugs.freedesktop.org/show_bug.cgi?id=110721 Mathieu Belanger changed: What|Removed |Added CC||0xe2.0x9a.0...@gmail.com --- Comment #14 from Mathieu Belanger --- *** Bug 110736 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 110736] Spotify rendering issues
https://bugs.freedesktop.org/show_bug.cgi?id=110736 Mathieu Belanger changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Mathieu Belanger --- *** This bug has been marked as a duplicate of bug 110721 *** -- 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 110721] graphics corruption on steam client with mesa 19.1.0 rc3 on polaris
https://bugs.freedesktop.org/show_bug.cgi?id=110721 --- Comment #13 from Mathieu Belanger --- That bug was affecting Discord, Brave and Chromium. Fixed by reverting : 811fa9a79cf -- 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 v6 2/8] drm/fb-helper: Remove drm_fb_helper_crtc
Den 23.05.2019 15.44, skrev Noralf Trønnes:
> struct drm_fb_helper_crtc is now just a wrapper around drm_mode_set so
> use that directly instead and attach it as a modeset array onto
> drm_client_dev. drm_fb_helper will use this array to store its modesets
> which means it will always initialize a drm_client, but it will not
> register the client (callbacks) unless it's the generic fbdev emulation.
>
> Code will later be moved to drm_client, so add code there in a new file
> drm_client_modeset.c with MIT license to match drm_fb_helper.c.
>
> The modeset connector array size is hardcoded for the cloned case to avoid
> having to pass in a value from the driver. A value of 8 is chosen to err
> on the safe side. This means that the max connector argument for
> drm_fb_helper_init() and drm_fb_helper_fbdev_setup() isn't used anymore,
> a todo entry for this is added.
>
> In pan_display_atomic() restore_fbdev_mode_force() is used instead of
> restore_fbdev_mode_atomic() because that one will later become internal
> to drm_client_modeset.
>
> Locking order:
> 1. drm_fb_helper->lock
> 2. drm_master_internal_acquire
> 3. drm_client_dev->modeset_mutex
>
> v6: Improve commit message (Sam Ravnborg)
>
> v3:
> - Use full drm_client_init/release for the modesets (Daniel Vetter)
> - drm_client_for_each_modeset: use lockdep_assert_held (Daniel Vetter)
> - Hook up to Documentation/gpu/drm-client.rst (Daniel Vetter)
>
> v2:
> - Add modesets array to drm_client (Daniel Vetter)
> - Use a new file for the modeset code (Daniel Vetter)
> - File has to be MIT licensed (Emmanuel Vadot)
> - Add copyrights from drm_fb_helper.c
>
> Signed-off-by: Noralf Trønnes
> Reviewed-by: Sam Ravnborg
> ---
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 4c3dc4268b65..9ead6436fb87 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -17,7 +17,7 @@ drm-y := drm_auth.o drm_cache.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_atomic_uapi.o
> + drm_client_modeset.o drm_atomic_uapi.o
The Intel CI informed me that this didn't apply on drm-tip.
There's commit 6498bf5800a3 ("drm: revocation check at drm subsystem")
coming in from drm-intel-next that conflicts. It's not in drm-next yet.
I won't be able to respin this for a week or so, so maybe by that time
it has even been backmerged into drm-misc-next.
Noralf.
>
> drm-$(CONFIG_DRM_LEGACY) += drm_legacy_misc.o drm_bufs.o drm_context.o
> drm_dma.o drm_scatter.o drm_lock.o
> drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110736] Spotify rendering issues
https://bugs.freedesktop.org/show_bug.cgi?id=110736 --- Comment #3 from Mathieu Belanger --- I would also add that the previous git version I did compile did not have the problem (Fri May 10 17:39:53 2019) -- 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 110736] Spotify rendering issues
https://bugs.freedesktop.org/show_bug.cgi?id=110736 --- Comment #2 from Mathieu Belanger --- Created attachment 144332 --> https://bugs.freedesktop.org/attachment.cgi?id=144332=edit Brave browser Here a screenshot of a Brave browser tab -- 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 110736] Spotify rendering issues
https://bugs.freedesktop.org/show_bug.cgi?id=110736 --- Comment #1 from Mathieu Belanger --- I have the same bug It started yesterday after a reboot. Between the reboot and the previous reboot I did emerge -e the whole things so I'm not totally sure it's mesa related I have the bug in: * Discord (only the rotating Discord logo when I load it, it spin like 30x on itself in the same amount of time it usually spin one time on itself.) * Brave browser (corruptopia like OP screen shot) * Chromium (partially, just the scroll bar) @Zak, is there is something else you also updated recently? Like libdrm, xorg parts, llvm? -- 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 110217] RX580: screen turns black or flickers until forced reconfiguration
https://bugs.freedesktop.org/show_bug.cgi?id=110217 --- Comment #4 from numz...@yandex.ru --- Just downgraded xf86-video-amdgpu back to 19.0.0-1. The flicker disappeared. -- 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 110217] RX580: screen turns black or flickers until forced reconfiguration
https://bugs.freedesktop.org/show_bug.cgi?id=110217 --- Comment #3 from numz...@yandex.ru --- New information: 1. Screen turns black at module insertion, be it during bootup or later. But resuming from hibernation works. 2. On the system, the converter I use is problematic itself. When I connect it to another PC, HDMI port is shown as “connected” *until* I connect a monitor to the converter. Then, everything works but HDMI port is displayed as “disconnected” in xrandr. After updating the system, flicker seems to happen in X only, despite the “TearFree” option. Virtual consoles work well, albeit use the same mode (i.e. no mode change on VT switch). Not sure was that the case earlier. Also, after last hibernation, the old trick with resetting mode didn’t help, flicker continues. New X instances flicker as well. New kernel: Linux 5.1.2-arch1-1-ARCH New X driver: xf86-video-amdgpu 19.0.1-1 -- 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: [RFC][PATCH] kernel.h: Add generic roundup_64() macro
On Thu, 23 May 2019 09:51:29 -0700
Linus Torvalds wrote:
> On Thu, May 23, 2019 at 8:27 AM Steven Rostedt wrote:
> >
> > I haven't yet tested this, but what about something like the following:
>
> So that at least handles the constant case that the normal "roundup()"
> case also handles.
>
> At the same time, in the case you are talking about, I really do
> suspect that we have a (non-constant) power of two, and that you
> should have just used "round_up()" which works fine regardless of
> size, and is always efficient.
I think you are correct in this.
act_size = roundup_64(attr->length, MLX5_SW_ICM_BLOCK_SIZE(dm_db->dev));
Where we have:
#define MLX5_SW_ICM_BLOCK_SIZE(dev) (1 << MLX5_LOG_SW_ICM_BLOCK_SIZE(dev))
Which pretty much guarantees that it is a power of two. Thus, the real
fix here is simply to s/roundup/round_up/ as you suggest.
>
> On a slight tangent.. Maybe we should have something like this:
>
> #define size_fn(x, prefix, ...) ({ \
> typeof(x) __ret;\
> switch (sizeof(x)) {\
> case 1: __ret = prefix##8(__VA_ARGS__); break; \
> case 2: __ret = prefix##16(__VA_ARGS__); break; \
> case 4: __ret = prefix##32(__VA_ARGS__); break; \
> case 8: __ret = prefix##64(__VA_ARGS__); break; \
> default: __ret = prefix##bad(__VA_ARGS__); \
> } __ret; })
>
> #define type_fn(x, prefix, ...) ({ \
> typeof(x) __ret;\
> if ((typeof(x))-1 > 1) \
> __ret = size_fn(x, prefix##_u, __VA_ARGS__);\
> else\
> __ret = size_fn(x, prefix##_s, __VA_ARGS__);\
> __ret; })
>
> which would allow typed integer functions like this. So you could do
> something like
>
> #define round_up(x, y) size_fn(x, round_up_size, x, y)
>
> and then you define functions for round_up_size8/16/32/64 (and you
You mean define functions for round_up_size_{u|s}8/16/32/64
> have toi declare - but not define - round_up_sizebad()).
>
> Of course, you probably want the usual "at least use 'int'" semantics,
> in which case the "type" should be "(x)+0":
>
> #define round_up(x, y) size_fn((x)+0, round_up_size, x, y)
>
> and the 8-bit and 16-bit cases will never be used.
I'm curious to what the advantage of that is?
>
> We have a lot of cases where we end up using "type overloading" by
> size. The most explicit case is perhaps "get_user()" and "put_user()",
> but this whole round_up thing is another example.
>
> Maybe we never really care about "char" and "short", and always want
> just the "int-vs-long-vs-longlong"? That would make the cases simpler
> (32 and 64). And maybe we never care about sign. But we could try to
> have some unified helper model like the above..
It may be simpler and perhaps more robust if we keep the char and short
cases.
I'm fine with adding something like this for round_up(), but do we want
to have a generic roundup_64() as well? I'm also thinking that we
perhaps should test for power of two on roundup():
#define roundup(x, y) ( \
{ \
typeof(y) __y = y; \
typeof(x) __x; \
\
if (__y & (__y - 1))\
__x = round_up(x, __y); \
else\
__x = (((x) + (__y - 1)) / __y) * __y; \
__x;\
})
-- Steve
[PATCH v2 1/6] drm/msm/a6xx: Avoid freeing gmu resources multiple times
From: Sean Paul
The driver checks for gmu->mmio as a sign that the device has been
initialized, however there are failures in probe below the mmio init.
If one of those is hit, mmio will be non-null but freed.
In that case, a6xx_gmu_probe will return an error to a6xx_gpu_init which
will in turn call a6xx_gmu_remove which checks gmu->mmio and tries to free
resources for a second time. This causes a great boom.
Fix this by adding an initialized member to gmu which is set on
successful probe and cleared on removal.
Changes in v2:
- None
Cc: Jordan Crouse
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 14 +-
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 1 +
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 38e2cfa9cec7..aa84edb25d91 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -74,7 +74,7 @@ bool a6xx_gmu_sptprac_is_on(struct a6xx_gmu *gmu)
u32 val;
/* This can be called from gpu state code so make sure GMU is valid */
- if (IS_ERR_OR_NULL(gmu->mmio))
+ if (!gmu->initialized)
return false;
val = gmu_read(gmu, REG_A6XX_GMU_SPTPRAC_PWR_CLK_STATUS);
@@ -90,7 +90,7 @@ bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
u32 val;
/* This can be called from gpu state code so make sure GMU is valid */
- if (IS_ERR_OR_NULL(gmu->mmio))
+ if (!gmu->initialized)
return false;
val = gmu_read(gmu, REG_A6XX_GMU_SPTPRAC_PWR_CLK_STATUS);
@@ -695,7 +695,7 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
struct a6xx_gmu *gmu = _gpu->gmu;
int status, ret;
- if (WARN(!gmu->mmio, "The GMU is not set up yet\n"))
+ if (WARN(!gmu->initialized, "The GMU is not set up yet\n"))
return 0;
gmu->hung = false;
@@ -765,7 +765,7 @@ bool a6xx_gmu_isidle(struct a6xx_gmu *gmu)
{
u32 reg;
- if (!gmu->mmio)
+ if (!gmu->initialized)
return true;
reg = gmu_read(gmu, REG_A6XX_GPU_GMU_AO_GPU_CX_BUSY_STATUS);
@@ -1227,7 +1227,7 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
{
struct a6xx_gmu *gmu = _gpu->gmu;
- if (IS_ERR_OR_NULL(gmu->mmio))
+ if (!gmu->initialized)
return;
a6xx_gmu_stop(a6xx_gpu);
@@ -1245,6 +1245,8 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
iommu_detach_device(gmu->domain, gmu->dev);
iommu_domain_free(gmu->domain);
+
+ gmu->initialized = false;
}
int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct device_node *node)
@@ -1309,6 +1311,8 @@ int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct
device_node *node)
/* Set up the HFI queues */
a6xx_hfi_init(gmu);
+ gmu->initialized = true;
+
return 0;
err:
a6xx_gmu_memory_free(gmu, gmu->hfi);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
index bedd8e6a63aa..39a26dd63674 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
@@ -75,6 +75,7 @@ struct a6xx_gmu {
struct a6xx_hfi_queue queues[2];
+ bool initialized;
bool hung;
};
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/6] drm/msm/a6xx: Rename a6xx_gmu_probe to a6xx_gmu_init
From: Sean Paul
This rename makes it more clear that everything initialized in the _init
function must be cleaned up in a6xx_gmu_remove. This will hopefully
dissuade people from using device managed resources (for reasons laid
out in the previous patch).
Changes in v2:
- None
Cc: Jordan Crouse
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 2 +-
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index e2b839b5d3bd..5ab69dcd5479 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -1259,7 +1259,7 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
gmu->initialized = false;
}
-int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct device_node *node)
+int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct device_node *node)
{
struct a6xx_gmu *gmu = _gpu->gmu;
struct platform_device *pdev = of_find_device_by_node(node);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index e74dce474250..1f9f4b0a9656 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -854,7 +854,7 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
/* FIXME: How do we gracefully handle this? */
BUG_ON(!node);
- ret = a6xx_gmu_probe(a6xx_gpu, node);
+ ret = a6xx_gmu_init(a6xx_gpu, node);
if (ret) {
a6xx_destroy(&(a6xx_gpu->base.base));
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
index b46279eb18c5..64399554f2dd 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
@@ -53,7 +53,7 @@ bool a6xx_gmu_isidle(struct a6xx_gmu *gmu);
int a6xx_gmu_set_oob(struct a6xx_gmu *gmu, enum a6xx_gmu_oob_state state);
void a6xx_gmu_clear_oob(struct a6xx_gmu *gmu, enum a6xx_gmu_oob_state state);
-int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct device_node *node);
+int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct device_node *node);
void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu);
void a6xx_gmu_set_freq(struct msm_gpu *gpu, unsigned long freq);
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/6] drm/msm/a6xx: Remove devm calls from gmu driver
From: Sean Paul
The gmu driver is initialized and cleaned up with calls from the gpu driver. As
such, the platform device stays valid after a6xx_gmu_remove is called and the
device managed resources are not freed. In the case of gpu probe failures or
unbind, these resources will remain managed.
If the gpu bind is run again (eg: if there's a probe defer somewhere in msm),
these resources will be initialized again for the same device, creating multiple
references. In the case of irqs, this causes failures since the irqs are
not shared (nor should they be).
This patch removes all devm_* calls and manually cleans things up in
gmu_remove.
Changes in v2:
- Add iounmap and free_irq to gmu_probe error paths
Cc: Jordan Crouse
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 33 ++-
1 file changed, 22 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 7465423e9b71..f7240c9e11fb 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -505,9 +505,9 @@ static void a6xx_gmu_rpmh_init(struct a6xx_gmu *gmu)
err:
if (!IS_ERR_OR_NULL(pdcptr))
- devm_iounmap(gmu->dev, pdcptr);
+ iounmap(pdcptr);
if (!IS_ERR_OR_NULL(seqptr))
- devm_iounmap(gmu->dev, seqptr);
+ iounmap(seqptr);
}
/*
@@ -1197,7 +1197,7 @@ static void __iomem *a6xx_gmu_get_mmio(struct
platform_device *pdev,
return ERR_PTR(-EINVAL);
}
- ret = devm_ioremap(>dev, res->start, resource_size(res));
+ ret = ioremap(res->start, resource_size(res));
if (!ret) {
DRM_DEV_ERROR(>dev, "Unable to map the %s registers\n",
name);
return ERR_PTR(-EINVAL);
@@ -1213,10 +1213,10 @@ static int a6xx_gmu_get_irq(struct a6xx_gmu *gmu,
struct platform_device *pdev,
irq = platform_get_irq_byname(pdev, name);
- ret = devm_request_irq(>dev, irq, handler, IRQF_TRIGGER_HIGH,
- name, gmu);
+ ret = request_irq(irq, handler, IRQF_TRIGGER_HIGH, name, gmu);
if (ret) {
- DRM_DEV_ERROR(>dev, "Unable to get interrupt %s\n", name);
+ DRM_DEV_ERROR(>dev, "Unable to get interrupt %s %d\n",
+ name, ret);
return ret;
}
@@ -1241,12 +1241,18 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
dev_pm_domain_detach(gmu->gxpd, false);
}
+ iounmap(gmu->mmio);
+ gmu->mmio = NULL;
+
a6xx_gmu_memory_free(gmu, gmu->hfi);
iommu_detach_device(gmu->domain, gmu->dev);
iommu_domain_free(gmu->domain);
+ free_irq(gmu->gmu_irq, gmu);
+ free_irq(gmu->hfi_irq, gmu);
+
gmu->initialized = false;
}
@@ -1281,24 +1287,24 @@ int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct
device_node *node)
/* Allocate memory for for the HFI queues */
gmu->hfi = a6xx_gmu_memory_alloc(gmu, SZ_16K);
if (IS_ERR(gmu->hfi))
- goto err;
+ goto err_memory;
/* Allocate memory for the GMU debug region */
gmu->debug = a6xx_gmu_memory_alloc(gmu, SZ_16K);
if (IS_ERR(gmu->debug))
- goto err;
+ goto err_memory;
/* Map the GMU registers */
gmu->mmio = a6xx_gmu_get_mmio(pdev, "gmu");
if (IS_ERR(gmu->mmio))
- goto err;
+ goto err_memory;
/* Get the HFI and GMU interrupts */
gmu->hfi_irq = a6xx_gmu_get_irq(gmu, pdev, "hfi", a6xx_hfi_irq);
gmu->gmu_irq = a6xx_gmu_get_irq(gmu, pdev, "gmu", a6xx_gmu_irq);
if (gmu->hfi_irq < 0 || gmu->gmu_irq < 0)
- goto err;
+ goto err_mmio;
/*
* Get a link to the GX power domain to reset the GPU in case of GMU
@@ -1315,7 +1321,12 @@ int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct
device_node *node)
gmu->initialized = true;
return 0;
-err:
+
+err_mmio:
+ iounmap(gmu->mmio);
+ free_irq(gmu->gmu_irq, gmu);
+ free_irq(gmu->hfi_irq, gmu);
+err_memory:
a6xx_gmu_memory_free(gmu, gmu->hfi);
if (gmu->domain) {
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/6] drm/msm/a6xx: Check for ERR or NULL before iounmap
From: Sean Paul pdcptr and seqptr aren't necessarily valid, check them before trying to unmap them. Changes in v2: - None Cc: Jordan Crouse Signed-off-by: Sean Paul --- drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c index 742c8ff9a61c..7465423e9b71 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c @@ -504,8 +504,10 @@ static void a6xx_gmu_rpmh_init(struct a6xx_gmu *gmu) wmb(); err: - devm_iounmap(gmu->dev, pdcptr); - devm_iounmap(gmu->dev, seqptr); + if (!IS_ERR_OR_NULL(pdcptr)) + devm_iounmap(gmu->dev, pdcptr); + if (!IS_ERR_OR_NULL(seqptr)) + devm_iounmap(gmu->dev, seqptr); } /* -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/6] drm/msm/a6xx: Remove duplicate irq disable from remove
From: Sean Paul a6xx_gmu_stop() already calls this function via shutdown or force_stop, so it's not necessary to call it twice. Previously this would have knocked the irq refcount out of sync, but now with the irqs_enabled flag it's just housekeeping. Changes in v2: - None Cc: Jordan Crouse Signed-off-by: Sean Paul --- drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c index aa84edb25d91..742c8ff9a61c 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c @@ -1239,7 +1239,6 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu) dev_pm_domain_detach(gmu->gxpd, false); } - a6xx_gmu_irq_disable(gmu); a6xx_gmu_memory_free(gmu, gmu->hfi); iommu_detach_device(gmu->domain, gmu->dev); -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/6] drm/msm/a6xx: Drop the device reference in gmu
From: Sean Paul of_find_device_by_node() grabs a dev reference, so make sure we clear it on error and remove. Changes in v2: - Added to the set (Jordan) Cc: Jordan Crouse Signed-off-by: Sean Paul --- drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c index f7240c9e11fb..e2b839b5d3bd 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c @@ -1253,6 +1253,9 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu) free_irq(gmu->gmu_irq, gmu); free_irq(gmu->hfi_irq, gmu); + /* Drop reference taken in of_find_device_by_node */ + put_device(gmu->dev); + gmu->initialized = false; } @@ -1277,12 +1280,12 @@ int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct device_node *node) /* Get the list of clocks */ ret = a6xx_gmu_clocks_probe(gmu); if (ret) - return ret; + goto err_put_device; /* Set up the IOMMU context bank */ ret = a6xx_gmu_memory_probe(gmu); if (ret) - return ret; + goto err_put_device; /* Allocate memory for for the HFI queues */ gmu->hfi = a6xx_gmu_memory_alloc(gmu, SZ_16K); @@ -1334,6 +1337,11 @@ int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct device_node *node) iommu_domain_free(gmu->domain); } + ret = -ENODEV; - return -ENODEV; +err_put_device: + /* Drop reference taken in of_find_device_by_node */ + put_device(gmu->dev); + + return ret; } -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mediatek: Fix warning about unhandled enum value
On Thu, May 23, 2019 at 02:13:20PM +0800, CK Hu wrote:
> Hi, Sean:
>
> On Wed, 2019-05-22 at 16:21 -0400, Sean Paul wrote:
> > From: Sean Paul
> >
> > Fixes the following build warning:
> > drivers/gpu/drm/mediatek/mtk_hdmi.c:327:2: warning: enumeration value
> > ‘HDMI_INFOFRAME_TYPE_DRM’ not handled in switch [-Wswitch]
> >
> > Introduced with the addition of HDMI_INFOFRAME_TYPE_DRM in the commit
> > below, but the code really should have been future-proofed from the
> > start.
>
> Acked-by: CK Hu
>
> >
> > Fixes: 2cdbfd66a829 ("drm: Enable HDR infoframe support")
>
> I think "drm: Enable HDR infoframe support" exist only in drm-misc tree,
> could you just merge this patch to "drm: Enable HDR infoframe support"?
Yes, I've applied it to drm-misc-next. Thanks for your Ack!
Sean
>
> Regards,
> CK
>
> > Cc: Uma Shankar
> > Cc: Shashank Sharma
> > Cc: Ville Syrjälä
> > Cc: Maarten Lankhorst
> > Cc: Maxime Ripard
> > Cc: Sean Paul
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: Bartlomiej Zolnierkiewicz
> > Cc: "Ville Syrjälä"
> > Cc: Hans Verkuil
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: linux-fb...@vger.kernel.org
> > Signed-off-by: Sean Paul
> > ---
> > drivers/gpu/drm/mediatek/mtk_hdmi.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > index e04e6c293d39..10cc9910f164 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > @@ -341,6 +341,9 @@ static void mtk_hdmi_hw_send_info_frame(struct mtk_hdmi
> > *hdmi, u8 *buffer,
> > ctrl_frame_en = VS_EN;
> > ctrl_reg = GRL_ACP_ISRC_CTRL;
> > break;
> > + default:
> > + dev_err(hdmi->dev, "Unknown infoframe type %d\n", frame_type);
> > + return;
> > }
> > mtk_hdmi_clear_bits(hdmi, ctrl_reg, ctrl_frame_en);
> > mtk_hdmi_write(hdmi, GRL_INFOFRM_TYPE, frame_type);
>
>
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/edid: Fix docbook in drm_hdmi_infoframe_set_hdr_metadata()
On Thu, May 23, 2019 at 02:38:37PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Sean Paul [mailto:s...@poorly.run]
> >Sent: Thursday, May 23, 2019 7:25 PM
> >To: dri-devel@lists.freedesktop.org
> >Cc: Sean Paul ; Shankar, Uma ;
> >Sharma, Shashank ; Ville Syrjälä
> >; Maarten Lankhorst
> >; Maxime Ripard
> >; Sean Paul ; David Airlie
> >; Daniel Vetter ; Bartlomiej
> >Zolnierkiewicz
> >; Hans Verkuil ; linux-
> >fb...@vger.kernel.org
> >Subject: [PATCH] drm/edid: Fix docbook in
> >drm_hdmi_infoframe_set_hdr_metadata()
> >
> >From: Sean Paul
> >
> >Fixes the following warnings:
> >../drivers/gpu/drm/drm_edid.c:4925: warning: Function parameter or member
> >'conn_state' not described in 'drm_hdmi_infoframe_set_hdr_metadata'
> >../drivers/gpu/drm/drm_edid.c:4925: warning: Excess function parameter
> >'hdr_metadata' description in 'drm_hdmi_infoframe_set_hdr_metadata'
>
> Thanks Sean Paul for fixing this.
> Reviewed-by: Uma Shankar
Pushed to -misc-next, thank you for the review!
Sean
>
> >Fixes: 2cdbfd66a829 ("drm: Enable HDR infoframe support")
> >Cc: Uma Shankar
> >Cc: Shashank Sharma
> >Cc: Ville Syrjälä
> >Cc: Maarten Lankhorst
> >Cc: Maxime Ripard
> >Cc: Sean Paul
> >Cc: David Airlie
> >Cc: Daniel Vetter
> >Cc: Bartlomiej Zolnierkiewicz
> >Cc: "Ville Syrjälä"
> >Cc: Hans Verkuil
> >Cc: dri-devel@lists.freedesktop.org
> >Cc: linux-fb...@vger.kernel.org
> >Signed-off-by: Sean Paul
> >---
> > drivers/gpu/drm/drm_edid.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index
> >262510c2a670..d87f574feeca 100644
> >--- a/drivers/gpu/drm/drm_edid.c
> >+++ b/drivers/gpu/drm/drm_edid.c
> >@@ -4914,7 +4914,7 @@ static inline bool is_eotf_supported(u8 output_eotf, u8
> >sink_eotf)
> > * drm_hdmi_infoframe_set_hdr_metadata() - fill an HDMI DRM infoframe with
> > * HDR metadata from userspace
> > * @frame: HDMI DRM infoframe
> >- * @hdr_metadata: hdr_source_metadata info from userspace
> >+ * @conn_state: Connector state containing HDR metadata
> > *
> > * Return: 0 on success or a negative error code on failure.
> > */
> >--
> >Sean Paul, Software Engineer, Google / Chromium OS
>
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH] kernel.h: Add generic roundup_64() macro
On Thu, May 23, 2019 at 8:27 AM Steven Rostedt wrote:
>
> I haven't yet tested this, but what about something like the following:
So that at least handles the constant case that the normal "roundup()"
case also handles.
At the same time, in the case you are talking about, I really do
suspect that we have a (non-constant) power of two, and that you
should have just used "round_up()" which works fine regardless of
size, and is always efficient.
On a slight tangent.. Maybe we should have something like this:
#define size_fn(x, prefix, ...) ({ \
typeof(x) __ret;\
switch (sizeof(x)) {\
case 1: __ret = prefix##8(__VA_ARGS__); break; \
case 2: __ret = prefix##16(__VA_ARGS__); break; \
case 4: __ret = prefix##32(__VA_ARGS__); break; \
case 8: __ret = prefix##64(__VA_ARGS__); break; \
default: __ret = prefix##bad(__VA_ARGS__); \
} __ret; })
#define type_fn(x, prefix, ...) ({ \
typeof(x) __ret;\
if ((typeof(x))-1 > 1) \
__ret = size_fn(x, prefix##_u, __VA_ARGS__);\
else\
__ret = size_fn(x, prefix##_s, __VA_ARGS__);\
__ret; })
which would allow typed integer functions like this. So you could do
something like
#define round_up(x, y) size_fn(x, round_up_size, x, y)
and then you define functions for round_up_size8/16/32/64 (and you
have toi declare - but not define - round_up_sizebad()).
Of course, you probably want the usual "at least use 'int'" semantics,
in which case the "type" should be "(x)+0":
#define round_up(x, y) size_fn((x)+0, round_up_size, x, y)
and the 8-bit and 16-bit cases will never be used.
We have a lot of cases where we end up using "type overloading" by
size. The most explicit case is perhaps "get_user()" and "put_user()",
but this whole round_up thing is another example.
Maybe we never really care about "char" and "short", and always want
just the "int-vs-long-vs-longlong"? That would make the cases simpler
(32 and 64). And maybe we never care about sign. But we could try to
have some unified helper model like the above..
Linus
Re: [PATCH v6 0/8] drm/fb-helper: Move modesetting code to drm_client
Hi Linus, Gerd. > This moves the modesetting code from drm_fb_helper to drm_client so it > can be shared by all internal clients. Could one of you take a look at this series. Daniel already ack'ed the series on irc, but an extra pair of eyes is never bad. For my part I have been through them all, but I still do not have the full picture of the DRM subsystem so my review may not suffice. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v15 00/17] arm64: untag user pointers passed to the kernel
On Thu, May 23, 2019 at 03:44:49PM +0100, Catalin Marinas wrote: > There is also the obvious requirement which I didn't mention: new user > space continues to run on new/subsequent kernel versions. That's one of > the points of contention for this series (ignoring MTE) with the > maintainers having to guarantee this without much effort. IOW, do the > 500K+ new lines in a subsequent kernel version break any user space out > there? I'm only talking about the relaxed TBI ABI. Are the usual LTP, > syskaller sufficient? Better static analysis would definitely help. We can't have perfect coverage of people actively (or accidentally) working to trick static analyzers (and the compiler) into "forgetting" about a __user annotation. We can certainly improve analysis (I see the other sub-thread on that), but I'd like that work not to block this series. What on this front would you be comfortable with? Given it's a new feature isn't it sufficient to have a CONFIG (and/or boot option)? > Or, if we ever want MTE to be turned on by default (i.e. tag checking), > even if everything is tagged with 0, we have to disallow TBI for user > and this includes hwasan. There were a small number of programs using > the TBI (I think some JavaScript compilers tried this). But now we are > bringing in the hwasan support and this can be a large user base. Shall > we add an ELF note for such binaries that use TBI/hwasan? Just to be clear, you say "disallow TBI for user" -- you mean a particular process, yes? i.e. there is no architectural limitation that says once we're using MTE nothing can switch to TBI. i.e. a process is either doing MTE or TBI (or nothing, but that's the same as TBI). > This needs solving as well. Most driver developers won't know why > untagged_addr() is needed unless we have more rigorous types or type > annotations and a tool to check them (we should probably revive the old > sparse thread). This seems like a parallel concern: we can do that separately from this series. Without landing it, is it much harder for people to test it, look for bugs, help with types/annotations, etc. > > So there needs to be some way to let the kernel know which of three > > things it should be doing: > > 1- leaving userspace addresses as-is (present) > > 2- wiping the top bits before using (this series) > > (I'd say tolerating rather than wiping since get_user still uses the tag > in the current series) > > The current series does not allow any choice between 1 and 2, the > default ABI basically becomes option 2. What about testing tools that intentionally insert high bits for syscalls and are _expecting_ them to fail? It seems the TBI series will break them? In that case, do we need to opt into TBI as well? > > 3- wiping the top bits for most things, but retaining them for MTE as > >needed (the future) > > 2 and 3 are not entirely compatible as a tagged pointer may be checked > against the memory colour by the hardware. So you can't have hwasan > binary with MTE enabled. Right: a process must be either MTE or TBI, not both. > > I expect MTE to be the "default" in the future. Once a system's libc has > > grown support for it, everything will be trying to use MTE. TBI will be > > the special case (but TBI is effectively a prerequisite). > > The kernel handling of tagged pointers is indeed a prerequisite. The ABI > distinction between the above 2 and 3 needs to be solved. Does that need solving now or when the MTE series appears? As there is no reason to distinguish between "normal" and "TBI", that doesn't seem to need solving at this point? > > AFAICT, the only difference I see between 2 and 3 will be the tag handling > > in usercopy (all other places will continue to ignore the top bits). Is > > that accurate? > > Yes, mostly (for the kernel). If MTE is enabled by default for a hwasan > binary, it will SEGFAULT (either in user space or in kernel uaccess). > How does the kernel choose between 2 and 3? Right -- that was my question as well. > > Is "1" a per-process state we want to keep? (I assume not, but rather it > > is available via no TBI/MTE CONFIG or a boot-time option, if at all?) > > Possibly, though not necessarily per process. For testing or if > something goes wrong during boot, a command line option with a static > label would do. The AT_FLAGS bit needs to be checked by user space. My > preference would be per-process. I would agree. > > To choose between "2" and "3", it seems we need a per-process flag to > > opt into TBI (and out of MTE). > > Or leave option 2 the default and get it to opt in to MTE. Given that MTE has to "start" at some point in the binary lifetime, I'm fine with opting into MTE. I do expect, though, this will feel redundant in a couple years as everything will immediately opt-in. But, okay, this is therefore an issue for the MTE series. > The current plan is that a future binary issues a prctl(), after > checking the HWCAP_MTE bit (as I replied to Elliot, the MTE
[PATCH] drm/i915: Maintain consistent documentation subsection ordering
With Sphinx 2.0 (or prior versions with the deprecation warnings fixed) the docs build fails with: Documentation/gpu/i915.rst:403: WARNING: Title level inconsistent: Global GTT Fence Handling ~ reST markup error: Documentation/gpu/i915.rst:403: (SEVERE/4) Title level inconsistent: I "fixed" it by changing the subsections in i915.rst, but that didn't seem like the correct change. It turns out that a couple of i915 files create their own subsections in kerneldoc comments using apostrophes as the heading marker: Layout '' That breaks the normal subsection marker ordering, and newer Sphinx is rather more strict about enforcing that ordering. So fix the offending comments to make Sphinx happy. (This is unfortunate, in that kerneldoc comments shouldn't need to be aware of where they might be included in the heading hierarchy, but I don't see a better way around it). Signed-off-by: Jonathan Corbet --- [If I can possibly get an ack for this, I would like to send it up soon with the other Sphinx-related fixes.] drivers/gpu/drm/i915/i915_reg.h | 6 +++--- drivers/gpu/drm/i915/intel_workarounds.c | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index b74824f0b5b1..249d35c12a75 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -35,7 +35,7 @@ * macros. Do **not** mass change existing definitions just to update the style. * * Layout - * '' + * ~~ * * Keep helper macros near the top. For example, _PIPE() and friends. * @@ -79,7 +79,7 @@ * style. Use lower case in hexadecimal values. * * Naming - * '' + * ~~ * * Try to name registers according to the specs. If the register name changes in * the specs from platform to another, stick to the original name. @@ -97,7 +97,7 @@ * suffix to the name. For example, ``_SKL`` or ``_GEN8``. * * Examples - * + * * * (Note that the values in the example are indented using spaces instead of * TABs to avoid misalignment in generated documentation. Use TABs in the diff --git a/drivers/gpu/drm/i915/intel_workarounds.c b/drivers/gpu/drm/i915/intel_workarounds.c index 9682dd575152..6decd432f4d3 100644 --- a/drivers/gpu/drm/i915/intel_workarounds.c +++ b/drivers/gpu/drm/i915/intel_workarounds.c @@ -37,7 +37,7 @@ *costly and simplifies things. We can revisit this in the future. * * Layout - * '' + * ~~ * * Keep things in this file ordered by WA type, as per the above (context, GT, * display, register whitelist, batchbuffer). Then, inside each type, keep the -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: manual merge of the drm-misc tree with Linus' tree
On Thu, May 23, 2019 at 6:54 AM Maxime Ripard wrote:
>
> On Tue, May 21, 2019 at 10:51:51AM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the drm-misc tree got a conflict in:
> >
> > Documentation/devicetree/bindings/vendor-prefixes.txt
> >
> > between commit:
> >
> > 8122de54602e ("dt-bindings: Convert vendor prefixes to json-schema")
> >
> > from Linus' tree and commits:
> >
> > b4a2c0055a4f ("dt-bindings: Add vendor prefix for VXT Ltd")
> > b1b0d36bdb15 ("dt-bindings: drm/panel: simple: Add binding for TFC
> > S9700RTWV43TR-01B")
> > fbd8b69ab616 ("dt-bindings: Add vendor prefix for Evervision Electronics")
> >
> > from the drm-misc tree.
> >
> > I fixed it up (I deleted the file and added the patch below) and can
> > carry the fix as necessary. This is now fixed as far as linux-next is
> > concerned, but any non trivial conflicts should be mentioned to your
> > upstream maintainer when your tree is submitted for merging. You may
> > also want to consider cooperating with the maintainer of the conflicting
> > tree to minimise any particularly complex conflicts.
>
> I just took your patch and pushed a temp branch there:
> https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git/commit/?h=drm-misc-next=3832f2cad5307ebcedeead13fbd8d3cf06ba5e90
>
> Rob, Stephen, are you ok with the change? If so, I'll push it.
The 'tfc' line is missing a ':' on the end. Does the file pass
dt_binding_check like that?
Rob
Re: [Intel-gfx] [PULL] drm-misc-next
On Thu, May 23, 2019 at 5:55 PM Daniel Vetter wrote: > > On Thu, May 23, 2019 at 5:53 PM Sean Paul wrote: > > > > On Thu, May 23, 2019 at 05:47:04PM +0200, Maarten Lankhorst wrote: > > > Hi Daniel and Dave, > > > > > > We keep adding support for panels at a high rate, is it still worth > > > listing them individually under cross subsystem changes? > > > > > > First pull req for v5.3 here, enjoy! > > > As I was writing this mail, I missed a fix in mtk_hdmi_hw_send_info_frame > > > for the unhandled > > > HDR case in switch, hope it's not too bad or I will send another. :) > > > > It's not, but we should wait for Maxime's fix to my botched backmerge [1] in > > order to avoid propagating the vendor prefixes file zombie to other trees. > > > > So can we backburner this until that lands? > > Yeah I want to land this until that's all settled. Also the hdr /me not English I want to _not_ land this until ... ofc. -Daniel > kerneldoc fix would be nice to land in this pull too, just for that > soothing warning-free experience :-) > -Daniel > > > > > Sean > > > > [1]- > > https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git/commit/?h=drm-misc-next=3832f2cad5307ebcedeead13fbd8d3cf06ba5e90 > > > > > > > > drm-misc-next-2019-05-23: > > > > > > drm-misc-next for v5.3: > > > > > > UAPI Changes: > > > - Add HDR source metadata property. > > > - Make drm.h compile on GNU/kFreeBSD by including stdint.h > > > - Clarify how the userspace reviewer has to review new kernel UAPI. > > > - Clarify that for using new UAPI, merging to drm-next or drm-misc-next > > > should be enough. > > > > > > Cross-subsystem Changes: > > > - video/hdmi: Add unpack function for DRM infoframes. > > > - Device tree bindings: > > > * Updating a property for Mali Midgard GPUs > > > * Updating a property for STM32 DSI panel > > > * Adding support for FriendlyELEC HD702E 800x1280 panel > > > * Adding support for Evervision VGG804821 800x480 5.0" WVGA TFT panel > > > * Adding support for the EDT ET035012DM6 3.5" 320x240 QVGA 24-bit RGB > > > TFT. > > > * Adding support for Three Five displays TFC S9700RTWV43TR-01B 800x480 > > > panel > > > with resistive touch found on TI's AM335X-EVM. > > > * Adding support for EDT ETM0430G0DH6 480x272 panel. > > > - Add OSD101T2587-53TS driver with DT bindings. > > > - Add Samsung S6E63M0 panel driver with DT bindings. > > > - Add VXT VL050-8048NT-C01 800x480 panel with DT bindings. > > > - Dma-buf: > > > - Make mmap callback actually optional. > > > - Documentation updates. > > > - Fix debugfs refcount inbalance. > > > - Remove unused sync_dump function. > > > > > > Core Changes: > > > - Add support for HDR infoframes and related EDID parsing. > > > - Remove prime sg_table caching, now done inside dma-buf. > > > - Add shiny new drm_gem_vram helpers for simple VRAM drivers; > > > with some fixes to the new API on top. > > > - Small fix to job cleanup without timeout handler. > > > - Documentation fixes to drm_fourcc. > > > - Replace lookups of drm_format with struct drm_format_info; > > > remove functions that become obsolete by this conversion. > > > - Remove double include in bridge/panel.c and some drivers. > > > - Remove drmP.h include from drm/edid and drm/dp. > > > - Fix null pointer deref in drm_fb_helper_hotplug_event(). > > > - Remove most members from drm_fb_helper_crtc, only mode_set is kept. > > > - Remove race of fb helpers with userspace; only restore mode > > > when userspace is not master. > > > - Move legacy setup from drm_file.c to drm_legacy_misc.c > > > - Rework scheduler job destruction. > > > - drm/bus was removed, remove from TODO. > > > - Add __drm_atomic_helper_crtc_reset() to subclass crtc_state, > > > and convert some drivers to use it (conversion is not complete yet). > > > - Bump vblank timeout wait to 100 ms for atomic. > > > > > > Driver Changes: > > > - sun4i: Use DRM_GEM_CMA_VMAP_DRIVER_OPS instead of definining manually. > > > - v3d: Small cleanups, adding support for compute shaders, > > >reservation/synchronization fixes and job management refactoring, > > >fixes MMU and debugfs. > > > - lima: Fix null pointer in irq handler on startup, set default timeout > > > for scheduled jobs. > > > - stm/ltdc: Assorted fixes and adding FB modifier support. > > > - amdgpu: Avoid hw reset if guilty job was already signaled. > > > - virtio: Add seqno to fences, add trace events, use correct flags for > > > fence allocation. > > > - Convert AST, bochs, mgag200, vboxvideo, hisilicon to the new > > > drm_gem_vram API. > > > - sun6i_mipi_dsi: Support DSI GENERIC_SHORT_WRITE_2 transfers. > > > - bochs: Small fix to use PTR_RET_OR_ZERO and driver unload. > > > - gma500: header fixes > > > - cirrus: Remove unused files. > > > The following changes since commit > > > a188339ca5a396acc588e5851ed7e19f66b0ebd9: > > > > > > Linux 5.2-rc1 (2019-05-19 15:47:09 -0700) > > > > > > are available in the Git repository at: > > > > > >
Re: [Intel-gfx] [PULL] drm-misc-next
On Thu, May 23, 2019 at 5:53 PM Sean Paul wrote: > > On Thu, May 23, 2019 at 05:47:04PM +0200, Maarten Lankhorst wrote: > > Hi Daniel and Dave, > > > > We keep adding support for panels at a high rate, is it still worth listing > > them individually under cross subsystem changes? > > > > First pull req for v5.3 here, enjoy! > > As I was writing this mail, I missed a fix in mtk_hdmi_hw_send_info_frame > > for the unhandled > > HDR case in switch, hope it's not too bad or I will send another. :) > > It's not, but we should wait for Maxime's fix to my botched backmerge [1] in > order to avoid propagating the vendor prefixes file zombie to other trees. > > So can we backburner this until that lands? Yeah I want to land this until that's all settled. Also the hdr kerneldoc fix would be nice to land in this pull too, just for that soothing warning-free experience :-) -Daniel > > Sean > > [1]- > https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git/commit/?h=drm-misc-next=3832f2cad5307ebcedeead13fbd8d3cf06ba5e90 > > > > > drm-misc-next-2019-05-23: > > > > drm-misc-next for v5.3: > > > > UAPI Changes: > > - Add HDR source metadata property. > > - Make drm.h compile on GNU/kFreeBSD by including stdint.h > > - Clarify how the userspace reviewer has to review new kernel UAPI. > > - Clarify that for using new UAPI, merging to drm-next or drm-misc-next > > should be enough. > > > > Cross-subsystem Changes: > > - video/hdmi: Add unpack function for DRM infoframes. > > - Device tree bindings: > > * Updating a property for Mali Midgard GPUs > > * Updating a property for STM32 DSI panel > > * Adding support for FriendlyELEC HD702E 800x1280 panel > > * Adding support for Evervision VGG804821 800x480 5.0" WVGA TFT panel > > * Adding support for the EDT ET035012DM6 3.5" 320x240 QVGA 24-bit RGB TFT. > > * Adding support for Three Five displays TFC S9700RTWV43TR-01B 800x480 > > panel > > with resistive touch found on TI's AM335X-EVM. > > * Adding support for EDT ETM0430G0DH6 480x272 panel. > > - Add OSD101T2587-53TS driver with DT bindings. > > - Add Samsung S6E63M0 panel driver with DT bindings. > > - Add VXT VL050-8048NT-C01 800x480 panel with DT bindings. > > - Dma-buf: > > - Make mmap callback actually optional. > > - Documentation updates. > > - Fix debugfs refcount inbalance. > > - Remove unused sync_dump function. > > > > Core Changes: > > - Add support for HDR infoframes and related EDID parsing. > > - Remove prime sg_table caching, now done inside dma-buf. > > - Add shiny new drm_gem_vram helpers for simple VRAM drivers; > > with some fixes to the new API on top. > > - Small fix to job cleanup without timeout handler. > > - Documentation fixes to drm_fourcc. > > - Replace lookups of drm_format with struct drm_format_info; > > remove functions that become obsolete by this conversion. > > - Remove double include in bridge/panel.c and some drivers. > > - Remove drmP.h include from drm/edid and drm/dp. > > - Fix null pointer deref in drm_fb_helper_hotplug_event(). > > - Remove most members from drm_fb_helper_crtc, only mode_set is kept. > > - Remove race of fb helpers with userspace; only restore mode > > when userspace is not master. > > - Move legacy setup from drm_file.c to drm_legacy_misc.c > > - Rework scheduler job destruction. > > - drm/bus was removed, remove from TODO. > > - Add __drm_atomic_helper_crtc_reset() to subclass crtc_state, > > and convert some drivers to use it (conversion is not complete yet). > > - Bump vblank timeout wait to 100 ms for atomic. > > > > Driver Changes: > > - sun4i: Use DRM_GEM_CMA_VMAP_DRIVER_OPS instead of definining manually. > > - v3d: Small cleanups, adding support for compute shaders, > >reservation/synchronization fixes and job management refactoring, > >fixes MMU and debugfs. > > - lima: Fix null pointer in irq handler on startup, set default timeout for > > scheduled jobs. > > - stm/ltdc: Assorted fixes and adding FB modifier support. > > - amdgpu: Avoid hw reset if guilty job was already signaled. > > - virtio: Add seqno to fences, add trace events, use correct flags for > > fence allocation. > > - Convert AST, bochs, mgag200, vboxvideo, hisilicon to the new drm_gem_vram > > API. > > - sun6i_mipi_dsi: Support DSI GENERIC_SHORT_WRITE_2 transfers. > > - bochs: Small fix to use PTR_RET_OR_ZERO and driver unload. > > - gma500: header fixes > > - cirrus: Remove unused files. > > The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9: > > > > Linux 5.2-rc1 (2019-05-19 15:47:09 -0700) > > > > are available in the Git repository at: > > > > git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2019-05-23 > > > > for you to fetch changes up to cbb56814fbe7fedd71cd6b29dc83bab2915a5b74: > > > > drm/virtio: remove irrelevant DRM_UNLOCKED flag (2019-05-23 12:16:01 > > +0200) > > > > > > We keep adding support for
Re: [PULL] drm-misc-next
On Thu, May 23, 2019 at 05:47:04PM +0200, Maarten Lankhorst wrote: > Hi Daniel and Dave, > > We keep adding support for panels at a high rate, is it still worth listing > them individually under cross subsystem changes? > > First pull req for v5.3 here, enjoy! > As I was writing this mail, I missed a fix in mtk_hdmi_hw_send_info_frame for > the unhandled > HDR case in switch, hope it's not too bad or I will send another. :) It's not, but we should wait for Maxime's fix to my botched backmerge [1] in order to avoid propagating the vendor prefixes file zombie to other trees. So can we backburner this until that lands? Sean [1]- https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git/commit/?h=drm-misc-next=3832f2cad5307ebcedeead13fbd8d3cf06ba5e90 > > drm-misc-next-2019-05-23: > > drm-misc-next for v5.3: > > UAPI Changes: > - Add HDR source metadata property. > - Make drm.h compile on GNU/kFreeBSD by including stdint.h > - Clarify how the userspace reviewer has to review new kernel UAPI. > - Clarify that for using new UAPI, merging to drm-next or drm-misc-next > should be enough. > > Cross-subsystem Changes: > - video/hdmi: Add unpack function for DRM infoframes. > - Device tree bindings: > * Updating a property for Mali Midgard GPUs > * Updating a property for STM32 DSI panel > * Adding support for FriendlyELEC HD702E 800x1280 panel > * Adding support for Evervision VGG804821 800x480 5.0" WVGA TFT panel > * Adding support for the EDT ET035012DM6 3.5" 320x240 QVGA 24-bit RGB TFT. > * Adding support for Three Five displays TFC S9700RTWV43TR-01B 800x480 panel > with resistive touch found on TI's AM335X-EVM. > * Adding support for EDT ETM0430G0DH6 480x272 panel. > - Add OSD101T2587-53TS driver with DT bindings. > - Add Samsung S6E63M0 panel driver with DT bindings. > - Add VXT VL050-8048NT-C01 800x480 panel with DT bindings. > - Dma-buf: > - Make mmap callback actually optional. > - Documentation updates. > - Fix debugfs refcount inbalance. > - Remove unused sync_dump function. > > Core Changes: > - Add support for HDR infoframes and related EDID parsing. > - Remove prime sg_table caching, now done inside dma-buf. > - Add shiny new drm_gem_vram helpers for simple VRAM drivers; > with some fixes to the new API on top. > - Small fix to job cleanup without timeout handler. > - Documentation fixes to drm_fourcc. > - Replace lookups of drm_format with struct drm_format_info; > remove functions that become obsolete by this conversion. > - Remove double include in bridge/panel.c and some drivers. > - Remove drmP.h include from drm/edid and drm/dp. > - Fix null pointer deref in drm_fb_helper_hotplug_event(). > - Remove most members from drm_fb_helper_crtc, only mode_set is kept. > - Remove race of fb helpers with userspace; only restore mode > when userspace is not master. > - Move legacy setup from drm_file.c to drm_legacy_misc.c > - Rework scheduler job destruction. > - drm/bus was removed, remove from TODO. > - Add __drm_atomic_helper_crtc_reset() to subclass crtc_state, > and convert some drivers to use it (conversion is not complete yet). > - Bump vblank timeout wait to 100 ms for atomic. > > Driver Changes: > - sun4i: Use DRM_GEM_CMA_VMAP_DRIVER_OPS instead of definining manually. > - v3d: Small cleanups, adding support for compute shaders, >reservation/synchronization fixes and job management refactoring, >fixes MMU and debugfs. > - lima: Fix null pointer in irq handler on startup, set default timeout for > scheduled jobs. > - stm/ltdc: Assorted fixes and adding FB modifier support. > - amdgpu: Avoid hw reset if guilty job was already signaled. > - virtio: Add seqno to fences, add trace events, use correct flags for fence > allocation. > - Convert AST, bochs, mgag200, vboxvideo, hisilicon to the new drm_gem_vram > API. > - sun6i_mipi_dsi: Support DSI GENERIC_SHORT_WRITE_2 transfers. > - bochs: Small fix to use PTR_RET_OR_ZERO and driver unload. > - gma500: header fixes > - cirrus: Remove unused files. > The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9: > > Linux 5.2-rc1 (2019-05-19 15:47:09 -0700) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2019-05-23 > > for you to fetch changes up to cbb56814fbe7fedd71cd6b29dc83bab2915a5b74: > > drm/virtio: remove irrelevant DRM_UNLOCKED flag (2019-05-23 12:16:01 +0200) > > > We keep adding support for panels at a high rate, is it still worth listing > them individually? > > drm-misc-next for v5.3: > > UAPI Changes: > - Add HDR source metadata property. > - Make drm.h compile on GNU/kFreeBSD by including stdint.h > - Clarify how the userspace reviewer has to review new kernel UAPI. > - Clarify that for using new UAPI, merging to drm-next or drm-misc-next > should be enough. > > Cross-subsystem Changes: > - video/hdmi: Add
[PULL] drm-misc-next
Hi Daniel and Dave, We keep adding support for panels at a high rate, is it still worth listing them individually under cross subsystem changes? First pull req for v5.3 here, enjoy! As I was writing this mail, I missed a fix in mtk_hdmi_hw_send_info_frame for the unhandled HDR case in switch, hope it's not too bad or I will send another. :) drm-misc-next-2019-05-23: drm-misc-next for v5.3: UAPI Changes: - Add HDR source metadata property. - Make drm.h compile on GNU/kFreeBSD by including stdint.h - Clarify how the userspace reviewer has to review new kernel UAPI. - Clarify that for using new UAPI, merging to drm-next or drm-misc-next should be enough. Cross-subsystem Changes: - video/hdmi: Add unpack function for DRM infoframes. - Device tree bindings: * Updating a property for Mali Midgard GPUs * Updating a property for STM32 DSI panel * Adding support for FriendlyELEC HD702E 800x1280 panel * Adding support for Evervision VGG804821 800x480 5.0" WVGA TFT panel * Adding support for the EDT ET035012DM6 3.5" 320x240 QVGA 24-bit RGB TFT. * Adding support for Three Five displays TFC S9700RTWV43TR-01B 800x480 panel with resistive touch found on TI's AM335X-EVM. * Adding support for EDT ETM0430G0DH6 480x272 panel. - Add OSD101T2587-53TS driver with DT bindings. - Add Samsung S6E63M0 panel driver with DT bindings. - Add VXT VL050-8048NT-C01 800x480 panel with DT bindings. - Dma-buf: - Make mmap callback actually optional. - Documentation updates. - Fix debugfs refcount inbalance. - Remove unused sync_dump function. Core Changes: - Add support for HDR infoframes and related EDID parsing. - Remove prime sg_table caching, now done inside dma-buf. - Add shiny new drm_gem_vram helpers for simple VRAM drivers; with some fixes to the new API on top. - Small fix to job cleanup without timeout handler. - Documentation fixes to drm_fourcc. - Replace lookups of drm_format with struct drm_format_info; remove functions that become obsolete by this conversion. - Remove double include in bridge/panel.c and some drivers. - Remove drmP.h include from drm/edid and drm/dp. - Fix null pointer deref in drm_fb_helper_hotplug_event(). - Remove most members from drm_fb_helper_crtc, only mode_set is kept. - Remove race of fb helpers with userspace; only restore mode when userspace is not master. - Move legacy setup from drm_file.c to drm_legacy_misc.c - Rework scheduler job destruction. - drm/bus was removed, remove from TODO. - Add __drm_atomic_helper_crtc_reset() to subclass crtc_state, and convert some drivers to use it (conversion is not complete yet). - Bump vblank timeout wait to 100 ms for atomic. Driver Changes: - sun4i: Use DRM_GEM_CMA_VMAP_DRIVER_OPS instead of definining manually. - v3d: Small cleanups, adding support for compute shaders, reservation/synchronization fixes and job management refactoring, fixes MMU and debugfs. - lima: Fix null pointer in irq handler on startup, set default timeout for scheduled jobs. - stm/ltdc: Assorted fixes and adding FB modifier support. - amdgpu: Avoid hw reset if guilty job was already signaled. - virtio: Add seqno to fences, add trace events, use correct flags for fence allocation. - Convert AST, bochs, mgag200, vboxvideo, hisilicon to the new drm_gem_vram API. - sun6i_mipi_dsi: Support DSI GENERIC_SHORT_WRITE_2 transfers. - bochs: Small fix to use PTR_RET_OR_ZERO and driver unload. - gma500: header fixes - cirrus: Remove unused files. The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9: Linux 5.2-rc1 (2019-05-19 15:47:09 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2019-05-23 for you to fetch changes up to cbb56814fbe7fedd71cd6b29dc83bab2915a5b74: drm/virtio: remove irrelevant DRM_UNLOCKED flag (2019-05-23 12:16:01 +0200) We keep adding support for panels at a high rate, is it still worth listing them individually? drm-misc-next for v5.3: UAPI Changes: - Add HDR source metadata property. - Make drm.h compile on GNU/kFreeBSD by including stdint.h - Clarify how the userspace reviewer has to review new kernel UAPI. - Clarify that for using new UAPI, merging to drm-next or drm-misc-next should be enough. Cross-subsystem Changes: - video/hdmi: Add unpack function for DRM infoframes. - Device tree bindings: * Updating a property for Mali Midgard GPUs * Updating a property for STM32 DSI panel * Adding support for FriendlyELEC HD702E 800x1280 panel * Adding support for Evervision VGG804821 800x480 5.0" WVGA TFT panel * Adding support for the EDT ET035012DM6 3.5" 320x240 QVGA 24-bit RGB TFT. * Adding support for Three Five displays TFC S9700RTWV43TR-01B 800x480 panel with resistive touch found on TI's AM335X-EVM. * Adding support for EDT ETM0430G0DH6 480x272 panel. - Add OSD101T2587-53TS driver with DT bindings. - Add Samsung S6E63M0 panel driver with
Re: [PATCH] drm/todo: Add bootsplash entry
Hi, On Thu, 2019-05-23 at 16:26 +0200, Noralf Trønnes wrote: > Ease entry for anyone wanting to pick up the bootsplash work by providing > a couple of pointers. > > Signed-off-by: Noralf Trønnes I think a native DRM bootsplash would be a great thing to have! Reviewed-by: Paul Kocialkowski Cheers, Paul > --- > Documentation/gpu/todo.rst | 14 ++ > 1 file changed, 14 insertions(+) > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > index ab96ba0600a9..05d610321566 100644 > --- a/Documentation/gpu/todo.rst > +++ b/Documentation/gpu/todo.rst > @@ -484,5 +484,19 @@ i915 >device_link_add to model the dependency between i915 and snd_had. See >https://dri.freedesktop.org/docs/drm/driver-api/device_link.html > > +Bootsplash > +== > + > +There is support in place now for writing internal DRM clients making it > +possible to pick up the bootsplash work that was rejected because it was > written > +for fbdev. > + > +- [v6,8/8] drm/client: Hack: Add bootsplash example > + https://patchwork.freedesktop.org/patch/306579/ > + > +- [RFC PATCH v2 00/13] Kernel based bootsplash > + https://lkml.org/lkml/2017/12/13/764 > + > + > Outside DRM > === -- Paul Kocialkowski, Bootlin Embedded Linux and kernel engineering https://bootlin.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH] kernel.h: Add generic roundup_64() macro
On Thu, 23 May 2019 08:10:44 -0700
Linus Torvalds wrote:
> On Thu, May 23, 2019 at 7:00 AM Steven Rostedt wrote:
> >
> > +# define roundup_64(x, y) (\
> > +{ \
> > + typeof(y) __y = y; \
> > + typeof(x) __x = (x) + (__y - 1);\
> > + do_div(__x, __y); \
> > + __x * __y; \
> > +} \
>
> The thing about this is that it absolutely sucks for power-of-two arguments.
>
> The regular roundup() that uses division has the compiler at least
> optimize them to shifts - at least for constant cases. But do_div() is
> meant for "we already know it's not a power of two", and the compiler
> doesn't have any understanding of the internals.
>
> And it looks to me like the use case you want this for is very much
> probably a power of two. In which case division is all kinds of just
> stupid.
>
> And we already have a power-of-two round up function that works on
> u64. It's called "round_up()".
>
> I wish we had a better visual warning about the differences between
> "round_up()" (limited to powers-of-two, but efficient, and works with
> any size) and "roundup()" (generic, potentially horribly slow, and
> doesn't work for 64-bit on 32-bit).
>
> Side note: "round_up()" has the problem that it uses "x" twice.
>
> End result: somebody should look at this, but I really don't like the
> "force division" case that is likely horribly slow and nasty.
I haven't yet tested this, but what about something like the following:
# define roundup_64(x, y) ( \
{ \
typeof(y) __y; \
typeof(x) __x; \
\
if (__builtin_constant_p(y) && \
!(y & (y >> 1))) { \
__x = round_up(x, y); \
} else {\
__y = y;\
__x = (x) + (__y - 1); \
do_div(__x, __y); \
__x = __x * __y;\
} \
__x;\
} \
)
If the compiler knows enough that y is a power of two, it will use the
shift version. Otherwise, it doesn't know enough and would divide
regardless. Or perhaps forget about the constant check, and just force
the power of two check:
# define roundup_64(x, y) ( \
{ \
typeof(y) __y = y; \
typeof(x) __x; \
\
if (!(__y & (__y >> 1))) { \
__x = round_up(x, y); \
} else {\
__x = (x) + (__y - 1); \
do_div(__x, __y); \
__x = __x * __y;\
} \
__x;\
} \
)
This way even if the compiler doesn't know that this is a power of two,
it will still do the shift if y ends up being one.
-- Steve
Re: [RFC][PATCH] kernel.h: Add generic roundup_64() macro
On Thu, May 23, 2019 at 7:00 AM Steven Rostedt wrote:
>
> +# define roundup_64(x, y) (\
> +{ \
> + typeof(y) __y = y; \
> + typeof(x) __x = (x) + (__y - 1);\
> + do_div(__x, __y); \
> + __x * __y; \
> +} \
The thing about this is that it absolutely sucks for power-of-two arguments.
The regular roundup() that uses division has the compiler at least
optimize them to shifts - at least for constant cases. But do_div() is
meant for "we already know it's not a power of two", and the compiler
doesn't have any understanding of the internals.
And it looks to me like the use case you want this for is very much
probably a power of two. In which case division is all kinds of just
stupid.
And we already have a power-of-two round up function that works on
u64. It's called "round_up()".
I wish we had a better visual warning about the differences between
"round_up()" (limited to powers-of-two, but efficient, and works with
any size) and "roundup()" (generic, potentially horribly slow, and
doesn't work for 64-bit on 32-bit).
Side note: "round_up()" has the problem that it uses "x" twice.
End result: somebody should look at this, but I really don't like the
"force division" case that is likely horribly slow and nasty.
Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/6] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
On Wed, May 22, 2019 at 11:54 PM Torsten Duwe wrote:
>
> From: Icenowy Zheng
>
> Teres-I has an anx6345 bridge connected to the RGB666 LCD output, and
> the I2C controlling signals are connected to I2C0 bus. eDP output goes
> to an Innolux N116BGE panel.
>
> Enable it in the device tree.
>
> Signed-off-by: Icenowy Zheng
> Signed-off-by: Torsten Duwe
> ---
> arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts | 65
> +--
> 1 file changed, 61 insertions(+), 4 deletions(-)
>
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> @@ -65,6 +65,21 @@
> };
> };
>
> + panel: panel {
> + compatible ="innolux,n116bge", "simple-panel";
IIRC Rob wanted it to be edp-connector, not simple-panel. Also you
need to introduce edp-connector binding.
> + status = "okay";
> + power-supply = <_dcdc1>;
> + backlight = <>;
> +
> + ports {
> + panel_in: port {
> + panel_in_edp: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> + };
> +
> reg_usb1_vbus: usb1-vbus {
> compatible = "regulator-fixed";
> regulator-name = "usb1-vbus";
> @@ -81,20 +96,48 @@
> };
> };
>
> + {
> + status = "okay";
> +};
> +
> {
> status = "okay";
> };
>
>
> -/* The ANX6345 eDP-bridge is on i2c0. There is no linux (mainline)
> - * driver for this chip at the moment, the bootloader initializes it.
> - * However it can be accessed with the i2c-dev driver from user space.
> - */
> {
> clock-frequency = <10>;
> pinctrl-names = "default";
> pinctrl-0 = <_pins>;
> status = "okay";
> +
> + anx6345: anx6345@38 {
> + compatible = "analogix,anx6345";
> + reg = <0x38>;
> + reset-gpios = < 3 24 GPIO_ACTIVE_LOW>; /* PD24 */
> + dvdd25-supply = <_dldo2>;
> + dvdd12-supply = <_dldo3>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + anx6345_in: endpoint {
> + remote-endpoint =
> <_out_anx6345>;
> + };
> + };
> + port@1 {
> + anx6345_out: endpoint {
> + remote-endpoint = <_in_edp>;
> + };
> + };
> + };
> + };
> +};
> +
> + {
> + status = "okay";
> };
>
> {
> @@ -279,6 +322,20 @@
> vcc-hdmi-supply = <_dldo1>;
> };
>
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_rgb666_pins>;
> +
> + status = "okay";
> +};
> +
> +_out {
> + tcon0_out_anx6345: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <_in>;
> + };
> +};
> +
> {
> pinctrl-names = "default";
> pinctrl-0 = <_pb_pins>;
RE: [PATCH] drm/edid: Fix docbook in drm_hdmi_infoframe_set_hdr_metadata()
>-Original Message-
>From: Sean Paul [mailto:s...@poorly.run]
>Sent: Thursday, May 23, 2019 7:25 PM
>To: dri-devel@lists.freedesktop.org
>Cc: Sean Paul ; Shankar, Uma ;
>Sharma, Shashank ; Ville Syrjälä
>; Maarten Lankhorst
>; Maxime Ripard
>; Sean Paul ; David Airlie
>; Daniel Vetter ; Bartlomiej Zolnierkiewicz
>; Hans Verkuil ; linux-
>fb...@vger.kernel.org
>Subject: [PATCH] drm/edid: Fix docbook in drm_hdmi_infoframe_set_hdr_metadata()
>
>From: Sean Paul
>
>Fixes the following warnings:
>../drivers/gpu/drm/drm_edid.c:4925: warning: Function parameter or member
>'conn_state' not described in 'drm_hdmi_infoframe_set_hdr_metadata'
>../drivers/gpu/drm/drm_edid.c:4925: warning: Excess function parameter
>'hdr_metadata' description in 'drm_hdmi_infoframe_set_hdr_metadata'
Thanks Sean Paul for fixing this.
Reviewed-by: Uma Shankar
>Fixes: 2cdbfd66a829 ("drm: Enable HDR infoframe support")
>Cc: Uma Shankar
>Cc: Shashank Sharma
>Cc: Ville Syrjälä
>Cc: Maarten Lankhorst
>Cc: Maxime Ripard
>Cc: Sean Paul
>Cc: David Airlie
>Cc: Daniel Vetter
>Cc: Bartlomiej Zolnierkiewicz
>Cc: "Ville Syrjälä"
>Cc: Hans Verkuil
>Cc: dri-devel@lists.freedesktop.org
>Cc: linux-fb...@vger.kernel.org
>Signed-off-by: Sean Paul
>---
> drivers/gpu/drm/drm_edid.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index
>262510c2a670..d87f574feeca 100644
>--- a/drivers/gpu/drm/drm_edid.c
>+++ b/drivers/gpu/drm/drm_edid.c
>@@ -4914,7 +4914,7 @@ static inline bool is_eotf_supported(u8 output_eotf, u8
>sink_eotf)
> * drm_hdmi_infoframe_set_hdr_metadata() - fill an HDMI DRM infoframe with
> * HDR metadata from userspace
> * @frame: HDMI DRM infoframe
>- * @hdr_metadata: hdr_source_metadata info from userspace
>+ * @conn_state: Connector state containing HDR metadata
> *
> * Return: 0 on success or a negative error code on failure.
> */
>--
>Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/todo: Add bootsplash entry
Ease entry for anyone wanting to pick up the bootsplash work by providing a couple of pointers. Signed-off-by: Noralf Trønnes --- Documentation/gpu/todo.rst | 14 ++ 1 file changed, 14 insertions(+) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index ab96ba0600a9..05d610321566 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -484,5 +484,19 @@ i915 device_link_add to model the dependency between i915 and snd_had. See https://dri.freedesktop.org/docs/drm/driver-api/device_link.html +Bootsplash +== + +There is support in place now for writing internal DRM clients making it +possible to pick up the bootsplash work that was rejected because it was written +for fbdev. + +- [v6,8/8] drm/client: Hack: Add bootsplash example + https://patchwork.freedesktop.org/patch/306579/ + +- [RFC PATCH v2 00/13] Kernel based bootsplash + https://lkml.org/lkml/2017/12/13/764 + + Outside DRM === -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109073] AMDGPU Radeon RX540 system freezes and/or crashes; poor performance with ac adapter plugged in
https://bugs.freedesktop.org/show_bug.cgi?id=109073 --- Comment #13 from Andre Klapper --- > its actually been more then two months since reporting it, its not fixed yet You (or anyone else) needs to volunteer to investigate and provide a patch. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: manual merge of the drm-misc tree with Linus' tree
Hi Daniel, On Thu, 23 May 2019 15:11:15 +0200 Daniel Vetter wrote: > > That commit is on top of drm-misc, and somehow the .txt version has > been resurrect in drm-misc-next (so needs to be re-deleted too). My mistake, the conflict went away (due to the back merge) so my scripts assumed the file no longer needed deleting. I didn't actually check to see if it was still there. -- Cheers, Stephen Rothwell pgpkEY83ZjdIJ.pgp Description: OpenPGP digital signature
Re: [PATCH 06/10] drm/ttm: fix busy memory to fail other user v10
Am 23.05.19 um 13:50 schrieb Zhou, David(ChunMing):
> 在 2019/5/23 19:03, Christian König 写道:
>> [CAUTION: External Email]
>>
>> Am 23.05.19 um 12:24 schrieb zhoucm1:
>>>
>>> On 2019年05月22日 20:59, Christian König wrote:
[CAUTION: External Email]
BOs on the LRU might be blocked during command submission
and cause OOM situations.
Avoid this by blocking for the first busy BO not locked by
the same ticket as the BO we are searching space for.
v10: completely start over with the patch since we didn't
handled a whole bunch of corner cases.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 77
++--
1 file changed, 66 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
b/drivers/gpu/drm/ttm/ttm_bo.c
index 4c6389d849ed..861facac33d4 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -771,32 +771,72 @@ EXPORT_SYMBOL(ttm_bo_eviction_valuable);
* b. Otherwise, trylock it.
*/
static bool ttm_bo_evict_swapout_allowable(struct ttm_buffer_object
*bo,
- struct ttm_operation_ctx *ctx, bool *locked)
+ struct ttm_operation_ctx *ctx, bool *locked,
bool *busy)
{
bool ret = false;
- *locked = false;
if (bo->resv == ctx->resv) {
reservation_object_assert_held(bo->resv);
if (ctx->flags & TTM_OPT_FLAG_ALLOW_RES_EVICT
|| !list_empty(>ddestroy))
ret = true;
+ *locked = false;
+ if (busy)
+ *busy = false;
} else {
- *locked = reservation_object_trylock(bo->resv);
- ret = *locked;
+ ret = reservation_object_trylock(bo->resv);
+ *locked = ret;
+ if (busy)
+ *busy = !ret;
}
return ret;
}
+/**
+ * ttm_mem_evict_wait_busy - wait for a busy BO to become available
+ *
+ * @busy_bo: BO which couldn't be locked with trylock
+ * @ctx: operation context
+ * @ticket: acquire ticket
+ *
+ * Try to lock a busy buffer object to avoid failing eviction.
+ */
+static int ttm_mem_evict_wait_busy(struct ttm_buffer_object *busy_bo,
+ struct ttm_operation_ctx *ctx,
+ struct ww_acquire_ctx *ticket)
+{
+ int r;
+
+ if (!busy_bo || !ticket)
+ return -EBUSY;
+
+ if (ctx->interruptible)
+ r =
reservation_object_lock_interruptible(busy_bo->resv,
+ ticket);
+ else
+ r = reservation_object_lock(busy_bo->resv, ticket);
+
+ /*
+ * TODO: It would be better to keep the BO locked until
allocation is at
+ * least tried one more time, but that would mean a much
larger rework
+ * of TTM.
+ */
+ if (!r)
+ reservation_object_unlock(busy_bo->resv);
+
+ return r == -EDEADLK ? -EAGAIN : r;
+}
+
static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
uint32_t mem_type,
const struct ttm_place *place,
- struct ttm_operation_ctx *ctx)
+ struct ttm_operation_ctx *ctx,
+ struct ww_acquire_ctx *ticket)
{
+ struct ttm_buffer_object *bo = NULL, *busy_bo = NULL;
struct ttm_bo_global *glob = bdev->glob;
struct ttm_mem_type_manager *man = >man[mem_type];
- struct ttm_buffer_object *bo = NULL;
bool locked = false;
unsigned i;
int ret;
@@ -804,8 +844,15 @@ static int ttm_mem_evict_first(struct
ttm_bo_device *bdev,
spin_lock(>lru_lock);
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
list_for_each_entry(bo, >lru[i], lru) {
- if (!ttm_bo_evict_swapout_allowable(bo, ctx,
))
+ bool busy;
+
+ if (!ttm_bo_evict_swapout_allowable(bo, ctx,
,
+ )) {
+ if (busy && !busy_bo &&
+ bo->resv->lock.ctx != ticket)
+ busy_bo = bo;
continue;
+ }
if (place &&
[Bug 109073] AMDGPU Radeon RX540 system freezes and/or crashes; poor performance with ac adapter plugged in
https://bugs.freedesktop.org/show_bug.cgi?id=109073 --- Comment #12 from Utku Helvacı (tuxutku) --- its actually been more then two months since reporting it, its not fixed yet -- 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 109073] AMDGPU Radeon RX540 system freezes and/or crashes; poor performance with ac adapter plugged in
https://bugs.freedesktop.org/show_bug.cgi?id=109073 --- Comment #11 from Utku Helvacı (tuxutku) --- I have bisected the bug, also i have reported it: https://bugzilla.kernel.org/show_bug.cgi?id=201077 its been a month since reporting it to linux kernel amd team, they acknowledged 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
[RFC][PATCH] kernel.h: Add generic roundup_64() macro
From: Steven Rostedt (VMware)
In discussing a build failure on x86_32 due to the use of roundup() on
a 64 bit number, I realized that there's no generic equivalent
roundup_64(). It is implemented in two separate places in the kernel,
but there really should be just one that all can use.
Although the other implementations are a static inline function, this
implementation is a macro to allow the use of typeof(x) to denote the
type that is being used. If the build is on a 64 bit machine, then the
roundup_64() macro will just default back to roundup(). But for 32 bit
machines, it will use the version that is will not cause issues with
dividing a 64 bit number on a 32 bit machine.
Link: http://lkml.kernel.org/r/20190522145450.25ff4...@gandalf.local.home
Signed-off-by: Steven Rostedt (VMware)
---
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 34a998012bf6..cdacfe1f732c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -143,14 +143,6 @@ nouveau_bo_del_ttm(struct ttm_buffer_object *bo)
kfree(nvbo);
}
-static inline u64
-roundup_64(u64 x, u32 y)
-{
- x += y - 1;
- do_div(x, y);
- return x * y;
-}
-
static void
nouveau_bo_fixup_align(struct nouveau_bo *nvbo, u32 flags,
int *align, u64 *size)
diff --git a/fs/xfs/xfs_linux.h b/fs/xfs/xfs_linux.h
index edbd5a210df2..13de9d49bd52 100644
--- a/fs/xfs/xfs_linux.h
+++ b/fs/xfs/xfs_linux.h
@@ -207,13 +207,6 @@ static inline xfs_dev_t linux_to_xfs_dev_t(dev_t dev)
#define xfs_sort(a,n,s,fn) sort(a,n,s,fn,NULL)
#define xfs_stack_trace() dump_stack()
-static inline uint64_t roundup_64(uint64_t x, uint32_t y)
-{
- x += y - 1;
- do_div(x, y);
- return x * y;
-}
-
static inline uint64_t howmany_64(uint64_t x, uint32_t y)
{
x += y - 1;
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 74b1ee9027f5..cd0063629357 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -115,6 +115,20 @@
(((x) + (__y - 1)) / __y) * __y;\
} \
)
+
+#if BITS_PER_LONG == 32
+# define roundup_64(x, y) (\
+{ \
+ typeof(y) __y = y; \
+ typeof(x) __x = (x) + (__y - 1);\
+ do_div(__x, __y); \
+ __x * __y; \
+} \
+)
+#else
+# define roundup_64(x, y) roundup(x, y)
+#endif
+
/**
* rounddown - round down to next specified multiple
* @x: the value to round
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/edid: Fix docbook in drm_hdmi_infoframe_set_hdr_metadata()
From: Sean Paul
Fixes the following warnings:
../drivers/gpu/drm/drm_edid.c:4925: warning: Function parameter or member
'conn_state' not described in 'drm_hdmi_infoframe_set_hdr_metadata'
../drivers/gpu/drm/drm_edid.c:4925: warning: Excess function parameter
'hdr_metadata' description in 'drm_hdmi_infoframe_set_hdr_metadata'
Fixes: 2cdbfd66a829 ("drm: Enable HDR infoframe support")
Cc: Uma Shankar
Cc: Shashank Sharma
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: "Ville Syrjälä"
Cc: Hans Verkuil
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Sean Paul
---
drivers/gpu/drm/drm_edid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 262510c2a670..d87f574feeca 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4914,7 +4914,7 @@ static inline bool is_eotf_supported(u8 output_eotf, u8
sink_eotf)
* drm_hdmi_infoframe_set_hdr_metadata() - fill an HDMI DRM infoframe with
* HDR metadata from userspace
* @frame: HDMI DRM infoframe
- * @hdr_metadata: hdr_source_metadata info from userspace
+ * @conn_state: Connector state containing HDR metadata
*
* Return: 0 on success or a negative error code on failure.
*/
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 7/8] drm/fb-helper: Move out modeset config code
No functional changes, just moving code as-is and fixing includes.
Signed-off-by: Noralf Trønnes
Reviewed-by: Maxime Ripard
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/drm_client_modeset.c | 707 ++-
drivers/gpu/drm/drm_fb_helper.c | 692 --
include/drm/drm_client.h | 5 +-
3 files changed, 702 insertions(+), 702 deletions(-)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index b2aedec65637..e8b5c54d6c05 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -13,13 +13,22 @@
#include
#include
+#include
#include
#include
#include
+#include
+#include
#include "drm_crtc_internal.h"
#include "drm_internal.h"
+#define DRM_CLIENT_MAX_CLONED_CONNECTORS 8
+
+struct drm_client_offset {
+ int x, y;
+};
+
int drm_client_modeset_create(struct drm_client_dev *client)
{
struct drm_device *dev = client->dev;
@@ -58,7 +67,7 @@ int drm_client_modeset_create(struct drm_client_dev *client)
return -ENOMEM;
}
-void drm_client_modeset_release(struct drm_client_dev *client)
+static void drm_client_modeset_release(struct drm_client_dev *client)
{
struct drm_mode_set *modeset;
unsigned int i;
@@ -75,8 +84,6 @@ void drm_client_modeset_release(struct drm_client_dev *client)
modeset->num_connectors = 0;
}
}
-/* TODO: Remove export when modeset code has been moved over */
-EXPORT_SYMBOL(drm_client_modeset_release);
void drm_client_modeset_free(struct drm_client_dev *client)
{
@@ -95,7 +102,8 @@ void drm_client_modeset_free(struct drm_client_dev *client)
kfree(client->modesets);
}
-struct drm_mode_set *drm_client_find_modeset(struct drm_client_dev *client,
struct drm_crtc *crtc)
+static struct drm_mode_set *
+drm_client_find_modeset(struct drm_client_dev *client, struct drm_crtc *crtc)
{
struct drm_mode_set *modeset;
@@ -105,8 +113,695 @@ struct drm_mode_set *drm_client_find_modeset(struct
drm_client_dev *client, stru
return NULL;
}
-/* TODO: Remove export when modeset code has been moved over */
-EXPORT_SYMBOL(drm_client_find_modeset);
+
+static struct drm_display_mode *
+drm_connector_has_preferred_mode(struct drm_connector *connector, int width,
int height)
+{
+ struct drm_display_mode *mode;
+
+ list_for_each_entry(mode, >modes, head) {
+ if (mode->hdisplay > width ||
+ mode->vdisplay > height)
+ continue;
+ if (mode->type & DRM_MODE_TYPE_PREFERRED)
+ return mode;
+ }
+ return NULL;
+}
+
+static struct drm_display_mode *
+drm_connector_pick_cmdline_mode(struct drm_connector *connector)
+{
+ struct drm_cmdline_mode *cmdline_mode;
+ struct drm_display_mode *mode;
+ bool prefer_non_interlace;
+
+ cmdline_mode = >cmdline_mode;
+ if (cmdline_mode->specified == false)
+ return NULL;
+
+ /* attempt to find a matching mode in the list of modes
+* we have gotten so far, if not add a CVT mode that conforms
+*/
+ if (cmdline_mode->rb || cmdline_mode->margins)
+ goto create_mode;
+
+ prefer_non_interlace = !cmdline_mode->interlace;
+again:
+ list_for_each_entry(mode, >modes, head) {
+ /* check width/height */
+ if (mode->hdisplay != cmdline_mode->xres ||
+ mode->vdisplay != cmdline_mode->yres)
+ continue;
+
+ if (cmdline_mode->refresh_specified) {
+ if (mode->vrefresh != cmdline_mode->refresh)
+ continue;
+ }
+
+ if (cmdline_mode->interlace) {
+ if (!(mode->flags & DRM_MODE_FLAG_INTERLACE))
+ continue;
+ } else if (prefer_non_interlace) {
+ if (mode->flags & DRM_MODE_FLAG_INTERLACE)
+ continue;
+ }
+ return mode;
+ }
+
+ if (prefer_non_interlace) {
+ prefer_non_interlace = false;
+ goto again;
+ }
+
+create_mode:
+ mode = drm_mode_create_from_cmdline_mode(connector->dev, cmdline_mode);
+ list_add(>head, >modes);
+
+ return mode;
+}
+
+static bool drm_connector_enabled(struct drm_connector *connector, bool strict)
+{
+ bool enable;
+
+ if (connector->display_info.non_desktop)
+ return false;
+
+ if (strict)
+ enable = connector->status == connector_status_connected;
+ else
+ enable = connector->status != connector_status_disconnected;
+
+ return enable;
+}
+
+static void drm_client_connectors_enabled(struct drm_connector **connectors,
+ unsigned int connector_count,
+
[PATCH v6 6/8] drm/fb-helper: Prepare to move out modeset config code
This prepares the modeset code so it can be moved out as-is in the next
patch.
v3: Remove stray newline
Signed-off-by: Noralf Trønnes
Reviewed-by: Maxime Ripard
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/drm_fb_helper.c | 62 +++--
include/drm/drm_fb_helper.h | 4 ---
2 files changed, 44 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index c2719a632e3a..4788f5a28513 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -43,6 +43,10 @@
#include "drm_internal.h"
+struct drm_client_offset {
+ int x, y;
+};
+
static bool drm_fbdev_emulation = true;
module_param_named(fbdev_emulation, drm_fbdev_emulation, bool, 0600);
MODULE_PARM_DESC(fbdev_emulation,
@@ -1804,7 +1808,7 @@ static bool drm_client_target_cloned(struct drm_device
*dev,
struct drm_connector **connectors,
unsigned int connector_count,
struct drm_display_mode **modes,
-struct drm_fb_offset *offsets,
+struct drm_client_offset *offsets,
bool *enabled, int width, int height)
{
int count, i, j;
@@ -1883,7 +1887,7 @@ static bool drm_client_target_cloned(struct drm_device
*dev,
static int drm_client_get_tile_offsets(struct drm_connector **connectors,
unsigned int connector_count,
struct drm_display_mode **modes,
- struct drm_fb_offset *offsets,
+ struct drm_client_offset *offsets,
int idx,
int h_idx, int v_idx)
{
@@ -1916,7 +1920,7 @@ static int drm_client_get_tile_offsets(struct
drm_connector **connectors,
static bool drm_client_target_preferred(struct drm_connector **connectors,
unsigned int connector_count,
struct drm_display_mode **modes,
- struct drm_fb_offset *offsets,
+ struct drm_client_offset *offsets,
bool *enabled, int width, int height)
{
const u64 mask = BIT_ULL(connector_count) - 1;
@@ -2080,7 +2084,7 @@ static bool drm_client_firmware_config(struct
drm_client_dev *client,
unsigned int connector_count,
struct drm_crtc **crtcs,
struct drm_display_mode **modes,
- struct drm_fb_offset *offsets,
+ struct drm_client_offset *offsets,
bool *enabled, int width, int height)
{
unsigned int count = min_t(unsigned int, connector_count,
BITS_PER_LONG);
@@ -2250,30 +2254,47 @@ static bool drm_client_firmware_config(struct
drm_client_dev *client,
return ret;
}
-static void drm_setup_crtcs(struct drm_fb_helper *fb_helper,
- u32 width, u32 height)
+/**
+ * drm_client_modeset_probe() - Probe for displays
+ * @client: DRM client
+ * @width: Maximum display mode width (optional)
+ * @height: Maximum display mode height (optional)
+ *
+ * This function sets up display pipelines for enabled connectors and stores
the
+ * config in the client's modeset array.
+ *
+ * Returns:
+ * Zero on success or negative error code on failure.
+ */
+int drm_client_modeset_probe(struct drm_client_dev *client, unsigned int
width, unsigned int height)
{
struct drm_connector *connector, **connectors = NULL;
- struct drm_client_dev *client = _helper->client;
struct drm_connector_list_iter conn_iter;
- struct drm_device *dev = fb_helper->dev;
+ struct drm_device *dev = client->dev;
unsigned int total_modes_count = 0;
+ struct drm_client_offset *offsets;
unsigned int connector_count = 0;
struct drm_display_mode **modes;
- struct drm_fb_offset *offsets;
struct drm_crtc **crtcs;
+ int i, ret = 0;
bool *enabled;
- int i;
DRM_DEBUG_KMS("\n");
+ if (!width)
+ width = dev->mode_config.max_width;
+ if (!height)
+ height = dev->mode_config.max_height;
+
drm_connector_list_iter_begin(dev, _iter);
drm_client_for_each_connector_iter(connector, _iter) {
struct drm_connector **tmp;
tmp = krealloc(connectors, (connector_count + 1) *
sizeof(*connectors), GFP_KERNEL);
- if (!tmp)
+ if (!tmp) {
+ ret = -ENOMEM;
goto free_connectors;
+ }
[PATCH v6 4/8] drm/fb-helper: Move out commit code
Move the modeset commit code to drm_client_modeset.
No changes except exporting API.
v2: Move to drm_client_modeset.c instead of drm_client.c
Signed-off-by: Noralf Trønnes
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/drm_client_modeset.c | 287 +++
drivers/gpu/drm/drm_fb_helper.c | 282 --
include/drm/drm_client.h | 4 +
3 files changed, 291 insertions(+), 282 deletions(-)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index 66770ed3299e..b2aedec65637 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -11,9 +11,14 @@
#include
#include
+#include
#include
#include
#include
+#include
+
+#include "drm_crtc_internal.h"
+#include "drm_internal.h"
int drm_client_modeset_create(struct drm_client_dev *client)
{
@@ -102,3 +107,285 @@ struct drm_mode_set *drm_client_find_modeset(struct
drm_client_dev *client, stru
}
/* TODO: Remove export when modeset code has been moved over */
EXPORT_SYMBOL(drm_client_find_modeset);
+
+/**
+ * drm_client_panel_rotation() - Check panel orientation
+ * @modeset: DRM modeset
+ * @rotation: Returned rotation value
+ *
+ * This function checks if the primary plane in @modeset can hw rotate to match
+ * the panel orientation on its connector.
+ *
+ * Note: Currently only 0 and 180 degrees are supported.
+ *
+ * Return:
+ * True if the plane can do the rotation, false otherwise.
+ */
+bool drm_client_panel_rotation(struct drm_mode_set *modeset, unsigned int
*rotation)
+{
+ struct drm_connector *connector = modeset->connectors[0];
+ struct drm_plane *plane = modeset->crtc->primary;
+ u64 valid_mask = 0;
+ unsigned int i;
+
+ if (!modeset->num_connectors)
+ return false;
+
+ switch (connector->display_info.panel_orientation) {
+ case DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP:
+ *rotation = DRM_MODE_ROTATE_180;
+ break;
+ case DRM_MODE_PANEL_ORIENTATION_LEFT_UP:
+ *rotation = DRM_MODE_ROTATE_90;
+ break;
+ case DRM_MODE_PANEL_ORIENTATION_RIGHT_UP:
+ *rotation = DRM_MODE_ROTATE_270;
+ break;
+ default:
+ *rotation = DRM_MODE_ROTATE_0;
+ }
+
+ /*
+* TODO: support 90 / 270 degree hardware rotation,
+* depending on the hardware this may require the framebuffer
+* to be in a specific tiling format.
+*/
+ if (*rotation != DRM_MODE_ROTATE_180 || !plane->rotation_property)
+ return false;
+
+ for (i = 0; i < plane->rotation_property->num_values; i++)
+ valid_mask |= (1ULL << plane->rotation_property->values[i]);
+
+ if (!(*rotation & valid_mask))
+ return false;
+
+ return true;
+}
+
+static int drm_client_modeset_commit_atomic(struct drm_client_dev *client,
bool active)
+{
+ struct drm_device *dev = client->dev;
+ struct drm_plane_state *plane_state;
+ struct drm_plane *plane;
+ struct drm_atomic_state *state;
+ struct drm_modeset_acquire_ctx ctx;
+ struct drm_mode_set *mode_set;
+ int ret;
+
+ drm_modeset_acquire_init(, 0);
+
+ state = drm_atomic_state_alloc(dev);
+ if (!state) {
+ ret = -ENOMEM;
+ goto out_ctx;
+ }
+
+ state->acquire_ctx =
+retry:
+ drm_for_each_plane(plane, dev) {
+ plane_state = drm_atomic_get_plane_state(state, plane);
+ if (IS_ERR(plane_state)) {
+ ret = PTR_ERR(plane_state);
+ goto out_state;
+ }
+
+ plane_state->rotation = DRM_MODE_ROTATE_0;
+
+ /* disable non-primary: */
+ if (plane->type == DRM_PLANE_TYPE_PRIMARY)
+ continue;
+
+ ret = __drm_atomic_helper_disable_plane(plane, plane_state);
+ if (ret != 0)
+ goto out_state;
+ }
+
+ drm_client_for_each_modeset(mode_set, client) {
+ struct drm_plane *primary = mode_set->crtc->primary;
+ unsigned int rotation;
+
+ if (drm_client_panel_rotation(mode_set, )) {
+ /* Cannot fail as we've already gotten the plane state
above */
+ plane_state = drm_atomic_get_new_plane_state(state,
primary);
+ plane_state->rotation = rotation;
+ }
+
+ ret = __drm_atomic_helper_set_config(mode_set, state);
+ if (ret != 0)
+ goto out_state;
+
+ /*
+* __drm_atomic_helper_set_config() sets active when a
+* mode is set, unconditionally clear it if we force DPMS off
+*/
+ if (!active) {
+ struct drm_crtc *crtc =
[PATCH v6 5/8] drm/fb-helper: Remove drm_fb_helper_connector
All drivers add all their connectors so there's no need to keep around an
array of available connectors. Instead we just put the useable (not
writeback) connectors in a temporary array using
drm_client_for_each_connector_iter() everytime we probe the outputs.
Other places where it's necessary to look at the connectors, we just
iterate over them using the same iterator function.
Rename functions which signature is changed since they will be moved to
drm_client in a later patch.
v6: Improve commit message (Sam Ravnborg)
Signed-off-by: Noralf Trønnes
Reviewed-by: Sam Ravnborg
---
Documentation/gpu/todo.rst | 4 +
drivers/gpu/drm/drm_fb_helper.c | 498 ++--
include/drm/drm_client.h| 15 +
include/drm/drm_fb_helper.h | 80 ++---
4 files changed, 193 insertions(+), 404 deletions(-)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 9d4038c50013..ab96ba0600a9 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -292,6 +292,10 @@ drm_fb_helper tasks
- The max connector argument for drm_fb_helper_init() and
drm_fb_helper_fbdev_setup() isn't used anymore and can be removed.
+- The helper doesn't keep an array of connectors anymore so these can be
+ removed: drm_fb_helper_single_add_all_connectors(),
+ drm_fb_helper_add_one_connector() and drm_fb_helper_remove_one_connector().
+
Core refactorings
=
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index e9cfccda6533..c2719a632e3a 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -90,12 +90,6 @@ static DEFINE_MUTEX(kernel_fb_helper_lock);
* Setup fbdev emulation by calling drm_fb_helper_fbdev_setup() and tear it
* down by calling drm_fb_helper_fbdev_teardown().
*
- * Drivers that need to handle connector hotplugging (e.g. dp mst) can't use
- * the setup helper and will need to do the whole four-step setup process with
- * drm_fb_helper_prepare(), drm_fb_helper_init(),
- * drm_fb_helper_single_add_all_connectors(), enable hotplugging and
- * drm_fb_helper_initial_config() to avoid a possible race window.
- *
* At runtime drivers should restore the fbdev console by using
* drm_fb_helper_lastclose() as their _driver.lastclose callback.
* They should also notify the fb helper code from updates to the output
@@ -118,8 +112,7 @@ static DEFINE_MUTEX(kernel_fb_helper_lock);
* encoders and connectors. To finish up the fbdev helper initialization, the
* drm_fb_helper_init() function is called. To probe for all attached displays
* and set up an initial configuration using the detected hardware, drivers
- * should call drm_fb_helper_single_add_all_connectors() followed by
- * drm_fb_helper_initial_config().
+ * should call drm_fb_helper_initial_config().
*
* If _framebuffer_funcs.dirty is set, the
* drm_fb_helper_{cfb,sys}_{write,fillrect,copyarea,imageblit} functions will
@@ -132,165 +125,6 @@ static DEFINE_MUTEX(kernel_fb_helper_lock);
* deferred I/O (coupled with drm_fb_helper_fbdev_teardown()).
*/
-#define drm_fb_helper_for_each_connector(fbh, i__) \
- for (({ lockdep_assert_held(&(fbh)->lock); }), \
-i__ = 0; i__ < (fbh)->connector_count; i__++)
-
-static int __drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper,
-struct drm_connector *connector)
-{
- struct drm_fb_helper_connector *fb_conn;
- struct drm_fb_helper_connector **temp;
- unsigned int count;
-
- if (!drm_fbdev_emulation)
- return 0;
-
- lockdep_assert_held(_helper->lock);
-
- count = fb_helper->connector_count + 1;
-
- if (count > fb_helper->connector_info_alloc_count) {
- size_t size = count * sizeof(fb_conn);
-
- temp = krealloc(fb_helper->connector_info, size, GFP_KERNEL);
- if (!temp)
- return -ENOMEM;
-
- fb_helper->connector_info_alloc_count = count;
- fb_helper->connector_info = temp;
- }
-
- fb_conn = kzalloc(sizeof(*fb_conn), GFP_KERNEL);
- if (!fb_conn)
- return -ENOMEM;
-
- drm_connector_get(connector);
- fb_conn->connector = connector;
- fb_helper->connector_info[fb_helper->connector_count++] = fb_conn;
-
- return 0;
-}
-
-int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper,
- struct drm_connector *connector)
-{
- int err;
-
- if (!fb_helper)
- return 0;
-
- mutex_lock(_helper->lock);
- err = __drm_fb_helper_add_one_connector(fb_helper, connector);
- mutex_unlock(_helper->lock);
-
- return err;
-}
-EXPORT_SYMBOL(drm_fb_helper_add_one_connector);
-
-/**
- * drm_fb_helper_single_add_all_connectors() - add all connectors to fbdev
- *emulation helper
- * @fb_helper:
[PATCH v6 8/8] drm/client: Hack: Add bootsplash example
An example to showcase the client API.
TODO:
- A bootsplash client needs a way to tell drm_fb_helper to stay away,
otherwise it will chime in on setup and hotplug.
Most DRM drivers register fbdev before calling drm_dev_register() (the
generic emulation is an exception). This have to be reversed for
bootsplash to fend off fbdev.
- Probably need some way to determine which is the primary display/device
on multi DRM device systems.
- Maybe do handover from early/simple DRM driver
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/Kconfig | 5 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/drm_bootsplash.c | 358 +++
drivers/gpu/drm/drm_client.c | 7 +
drivers/gpu/drm/drm_drv.c| 4 +
include/drm/drm_client.h | 3 +
6 files changed, 378 insertions(+)
create mode 100644 drivers/gpu/drm/drm_bootsplash.c
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index a461f078a0dd..aede0de0c9d9 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -65,6 +65,11 @@ config DRM_DEBUG_SELFTEST
If in doubt, say "N".
+config DRM_CLIENT_BOOTSPLASH
+ bool "DRM Bootsplash"
+ help
+ DRM Bootsplash
+
config DRM_KMS_HELPER
tristate
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 9ead6436fb87..78573ed02a4e 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -31,6 +31,7 @@ drm-$(CONFIG_OF) += drm_of.o
drm-$(CONFIG_AGP) += drm_agpsupport.o
drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
+drm-$(CONFIG_DRM_CLIENT_BOOTSPLASH) += drm_bootsplash.o
drm_vram_helper-y := drm_gem_vram_helper.o \
drm_vram_helper_common.o \
diff --git a/drivers/gpu/drm/drm_bootsplash.c b/drivers/gpu/drm/drm_bootsplash.c
new file mode 100644
index ..f58ee19e268f
--- /dev/null
+++ b/drivers/gpu/drm/drm_bootsplash.c
@@ -0,0 +1,358 @@
+/* DRM internal client example */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+// drm_lastclose()
+#include "drm_internal.h"
+
+static bool drm_bootsplash_enabled = true;
+module_param_named(bootsplash_enabled, drm_bootsplash_enabled, bool, 0600);
+MODULE_PARM_DESC(bootsplash_enabled, "Enable bootsplash client
[default=true]");
+
+struct drm_bootsplash {
+ struct drm_client_dev client;
+ struct mutex lock;
+ struct work_struct worker;
+ struct drm_client_buffer *buffers[2];
+ bool started;
+ bool stop;
+};
+
+static bool drm_bootsplash_key_pressed;
+
+static int drm_bootsplash_keyboard_notifier_call(struct notifier_block *blk,
+unsigned long code, void
*_param)
+{
+ /* Any key is good */
+ drm_bootsplash_key_pressed = true;
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block drm_bootsplash_keyboard_notifier_block = {
+ .notifier_call = drm_bootsplash_keyboard_notifier_call,
+};
+
+static void drm_bootsplash_buffer_delete(struct drm_bootsplash *splash)
+{
+ unsigned int i;
+
+ for (i = 0; i < 2; i++) {
+ if (!IS_ERR_OR_NULL(splash->buffers[i]))
+ drm_client_framebuffer_delete(splash->buffers[i]);
+ splash->buffers[i] = NULL;
+ }
+}
+
+static int drm_bootsplash_buffer_create(struct drm_bootsplash *splash, u32
width, u32 height)
+{
+ unsigned int i;
+
+ for (i = 0; i < 2; i++) {
+ splash->buffers[i] =
drm_client_framebuffer_create(>client, width, height,
DRM_FORMAT_XRGB);
+ if (IS_ERR(splash->buffers[i])) {
+ drm_bootsplash_buffer_delete(splash);
+ return PTR_ERR(splash->buffers[i]);
+ }
+ }
+
+ return 0;
+}
+
+static int drm_bootsplash_display_probe(struct drm_bootsplash *splash)
+{
+ struct drm_client_dev *client = >client;
+ unsigned int width = 0, height = 0;
+ unsigned int num_non_tiled = 0, i;
+ unsigned int modeset_mask = 0;
+ struct drm_mode_set *modeset;
+ bool tiled = false;
+ int ret;
+
+ ret = drm_client_modeset_probe(client, 0, 0);
+ if (ret)
+ return ret;
+
+ mutex_lock(>modeset_mutex);
+
+ drm_client_for_each_modeset(modeset, client) {
+ if (!modeset->mode)
+ continue;
+
+ if (modeset->connectors[0]->has_tile)
+ tiled = true;
+ else
+ num_non_tiled++;
+ }
+
+ if (!tiled && !num_non_tiled) {
+ drm_bootsplash_buffer_delete(splash);
+ ret = -ENOENT;
+ goto out;
+ }
+
+ /* Assume only one tiled monitor is possible */
+ if (tiled) {
+
[PATCH v6 0/8] drm/fb-helper: Move modesetting code to drm_client
This moves the modesetting code from drm_fb_helper to drm_client so it can be shared by all internal clients. Changes this time: - Improve commit messages All patches have been reviewed now, thanks alot for reviewing! Noralf. Noralf Trønnes (8): drm/atomic: Move __drm_atomic_helper_disable_plane/set_config() drm/fb-helper: Remove drm_fb_helper_crtc drm/fb-helper: Prepare to move out commit code drm/fb-helper: Move out commit code drm/fb-helper: Remove drm_fb_helper_connector drm/fb-helper: Prepare to move out modeset config code drm/fb-helper: Move out modeset config code drm/client: Hack: Add bootsplash example Documentation/gpu/drm-client.rst |3 + Documentation/gpu/todo.rst |7 + drivers/gpu/drm/Kconfig |5 + drivers/gpu/drm/Makefile |3 +- drivers/gpu/drm/drm_atomic.c | 168 drivers/gpu/drm/drm_atomic_helper.c | 164 drivers/gpu/drm/drm_bootsplash.c | 358 +++ drivers/gpu/drm/drm_client.c | 17 +- drivers/gpu/drm/drm_client_modeset.c | 1086 + drivers/gpu/drm/drm_crtc_internal.h |5 + drivers/gpu/drm/drm_drv.c|4 + drivers/gpu/drm/drm_fb_helper.c | 1305 ++ include/drm/drm_atomic_helper.h |4 - include/drm/drm_client.h | 49 + include/drm/drm_fb_helper.h | 92 +- 15 files changed, 1800 insertions(+), 1470 deletions(-) create mode 100644 drivers/gpu/drm/drm_bootsplash.c create mode 100644 drivers/gpu/drm/drm_client_modeset.c -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 2/8] drm/fb-helper: Remove drm_fb_helper_crtc
struct drm_fb_helper_crtc is now just a wrapper around drm_mode_set so use that directly instead and attach it as a modeset array onto drm_client_dev. drm_fb_helper will use this array to store its modesets which means it will always initialize a drm_client, but it will not register the client (callbacks) unless it's the generic fbdev emulation. Code will later be moved to drm_client, so add code there in a new file drm_client_modeset.c with MIT license to match drm_fb_helper.c. The modeset connector array size is hardcoded for the cloned case to avoid having to pass in a value from the driver. A value of 8 is chosen to err on the safe side. This means that the max connector argument for drm_fb_helper_init() and drm_fb_helper_fbdev_setup() isn't used anymore, a todo entry for this is added. In pan_display_atomic() restore_fbdev_mode_force() is used instead of restore_fbdev_mode_atomic() because that one will later become internal to drm_client_modeset. Locking order: 1. drm_fb_helper->lock 2. drm_master_internal_acquire 3. drm_client_dev->modeset_mutex v6: Improve commit message (Sam Ravnborg) v3: - Use full drm_client_init/release for the modesets (Daniel Vetter) - drm_client_for_each_modeset: use lockdep_assert_held (Daniel Vetter) - Hook up to Documentation/gpu/drm-client.rst (Daniel Vetter) v2: - Add modesets array to drm_client (Daniel Vetter) - Use a new file for the modeset code (Daniel Vetter) - File has to be MIT licensed (Emmanuel Vadot) - Add copyrights from drm_fb_helper.c Signed-off-by: Noralf Trønnes Reviewed-by: Sam Ravnborg --- Documentation/gpu/drm-client.rst | 3 + Documentation/gpu/todo.rst | 3 + drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/drm_client.c | 10 +- drivers/gpu/drm/drm_client_modeset.c | 104 + drivers/gpu/drm/drm_fb_helper.c | 301 +++ include/drm/drm_client.h | 30 +++ include/drm/drm_fb_helper.h | 8 - 8 files changed, 274 insertions(+), 187 deletions(-) create mode 100644 drivers/gpu/drm/drm_client_modeset.c diff --git a/Documentation/gpu/drm-client.rst b/Documentation/gpu/drm-client.rst index 7e672063e7eb..58b5a1d1219d 100644 --- a/Documentation/gpu/drm-client.rst +++ b/Documentation/gpu/drm-client.rst @@ -10,3 +10,6 @@ Kernel clients .. kernel-doc:: drivers/gpu/drm/drm_client.c :export: + +.. kernel-doc:: drivers/gpu/drm/drm_client_modeset.c + :export: diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 66f05f4e469f..9d4038c50013 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -289,6 +289,9 @@ drm_fb_helper tasks these igt tests need to be fixed: kms_fbcon_fbt@psr and kms_fbcon_fbt@psr-suspend. +- The max connector argument for drm_fb_helper_init() and + drm_fb_helper_fbdev_setup() isn't used anymore and can be removed. + Core refactorings = diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 4c3dc4268b65..9ead6436fb87 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -17,7 +17,7 @@ drm-y :=drm_auth.o drm_cache.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_atomic_uapi.o + drm_client_modeset.o drm_atomic_uapi.o drm-$(CONFIG_DRM_LEGACY) += drm_legacy_misc.o drm_bufs.o drm_context.o drm_dma.o drm_scatter.o drm_lock.o drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c index 5abcd83da6a6..77aa1cf09caa 100644 --- a/drivers/gpu/drm/drm_client.c +++ b/drivers/gpu/drm/drm_client.c @@ -27,7 +27,6 @@ * DOC: overview * * This library provides support for clients running in the kernel like fbdev and bootsplash. - * Currently it's only partially implemented, just enough to support fbdev. * * GEM drivers which provide a GEM based dumb buffer with a virtual address are supported. */ @@ -92,14 +91,20 @@ int drm_client_init(struct drm_device *dev, struct drm_client_dev *client, client->name = name; client->funcs = funcs; - ret = drm_client_open(client); + ret = drm_client_modeset_create(client); if (ret) goto err_put_module; + ret = drm_client_open(client); + if (ret) + goto err_free; + drm_dev_get(dev); return 0; +err_free: + drm_client_modeset_free(client); err_put_module: if (funcs) module_put(funcs->owner); @@ -148,6 +153,7 @@ void drm_client_release(struct drm_client_dev *client) DRM_DEV_DEBUG_KMS(dev->dev, "%s\n", client->name); + drm_client_modeset_free(client); drm_client_close(client); drm_dev_put(dev); if (client->funcs) diff --git
[PATCH v6 3/8] drm/fb-helper: Prepare to move out commit code
This makes the necessary changes so the commit code can be moved out to
drm_client as-is in the next patch. It's split up to ease review.
Signed-off-by: Noralf Trønnes
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/drm_fb_helper.c | 122 +---
1 file changed, 81 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index dee16d97f3da..d530fb315e52 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -388,9 +388,20 @@ int drm_fb_helper_debug_leave(struct fb_info *info)
}
EXPORT_SYMBOL(drm_fb_helper_debug_leave);
-/* Check if the plane can hw rotate to match panel orientation */
-static bool drm_fb_helper_panel_rotation(struct drm_mode_set *modeset,
-unsigned int *rotation)
+/**
+ * drm_client_panel_rotation() - Check panel orientation
+ * @modeset: DRM modeset
+ * @rotation: Returned rotation value
+ *
+ * This function checks if the primary plane in @modeset can hw rotate to match
+ * the panel orientation on its connector.
+ *
+ * Note: Currently only 0 and 180 degrees are supported.
+ *
+ * Return:
+ * True if the plane can do the rotation, false otherwise.
+ */
+bool drm_client_panel_rotation(struct drm_mode_set *modeset, unsigned int
*rotation)
{
struct drm_connector *connector = modeset->connectors[0];
struct drm_plane *plane = modeset->crtc->primary;
@@ -431,10 +442,9 @@ static bool drm_fb_helper_panel_rotation(struct
drm_mode_set *modeset,
return true;
}
-static int restore_fbdev_mode_atomic(struct drm_fb_helper *fb_helper, bool
active)
+static int drm_client_modeset_commit_atomic(struct drm_client_dev *client,
bool active)
{
- struct drm_client_dev *client = _helper->client;
- struct drm_device *dev = fb_helper->dev;
+ struct drm_device *dev = client->dev;
struct drm_plane_state *plane_state;
struct drm_plane *plane;
struct drm_atomic_state *state;
@@ -474,7 +484,7 @@ static int restore_fbdev_mode_atomic(struct drm_fb_helper
*fb_helper, bool activ
struct drm_plane *primary = mode_set->crtc->primary;
unsigned int rotation;
- if (drm_fb_helper_panel_rotation(mode_set, )) {
+ if (drm_client_panel_rotation(mode_set, )) {
/* Cannot fail as we've already gotten the plane state
above */
plane_state = drm_atomic_get_new_plane_state(state,
primary);
plane_state->rotation = rotation;
@@ -516,15 +526,14 @@ static int restore_fbdev_mode_atomic(struct drm_fb_helper
*fb_helper, bool activ
goto retry;
}
-static int restore_fbdev_mode_legacy(struct drm_fb_helper *fb_helper)
+static int drm_client_modeset_commit_legacy(struct drm_client_dev *client)
{
- struct drm_client_dev *client = _helper->client;
- struct drm_device *dev = fb_helper->dev;
+ struct drm_device *dev = client->dev;
struct drm_mode_set *mode_set;
struct drm_plane *plane;
int ret = 0;
- drm_modeset_lock_all(fb_helper->dev);
+ drm_modeset_lock_all(dev);
drm_for_each_plane(plane, dev) {
if (plane->type != DRM_PLANE_TYPE_PRIMARY)
drm_plane_force_disable(plane);
@@ -553,35 +562,53 @@ static int restore_fbdev_mode_legacy(struct drm_fb_helper
*fb_helper)
goto out;
}
out:
- drm_modeset_unlock_all(fb_helper->dev);
+ drm_modeset_unlock_all(dev);
return ret;
}
-static int restore_fbdev_mode_force(struct drm_fb_helper *fb_helper)
+/**
+ * drm_client_modeset_commit_force() - Force commit CRTC configuration
+ * @client: DRM client
+ *
+ * Commit modeset configuration to crtcs without checking if there is a DRM
master.
+ *
+ * Returns:
+ * Zero on success or negative error code on failure.
+ */
+int drm_client_modeset_commit_force(struct drm_client_dev *client)
{
- struct drm_device *dev = fb_helper->dev;
+ struct drm_device *dev = client->dev;
int ret;
- mutex_lock(_helper->client.modeset_mutex);
+ mutex_lock(>modeset_mutex);
if (drm_drv_uses_atomic_modeset(dev))
- ret = restore_fbdev_mode_atomic(fb_helper, true);
+ ret = drm_client_modeset_commit_atomic(client, true);
else
- ret = restore_fbdev_mode_legacy(fb_helper);
- mutex_unlock(_helper->client.modeset_mutex);
+ ret = drm_client_modeset_commit_legacy(client);
+ mutex_unlock(>modeset_mutex);
return ret;
}
-static int restore_fbdev_mode(struct drm_fb_helper *fb_helper)
+/**
+ * drm_client_modeset_commit() - Commit CRTC configuration
+ * @client: DRM client
+ *
+ * Commit modeset configuration to crtcs.
+ *
+ * Returns:
+ * Zero on success or negative error code on failure.
+ */
+int drm_client_modeset_commit(struct drm_client_dev
[PATCH v6 1/8] drm/atomic: Move __drm_atomic_helper_disable_plane/set_config()
Prepare for moving drm_fb_helper modesetting code to drm_client.
drm_client will be linked to drm.ko, so move
__drm_atomic_helper_disable_plane() and __drm_atomic_helper_set_config()
out of drm_kms_helper.ko.
While at it, fix two checkpatch complaints:
- WARNING: Block comments use a trailing */ on a separate line
- CHECK: Alignment should match open parenthesis
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
Reviewed-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic.c| 168
drivers/gpu/drm/drm_atomic_helper.c | 164 ---
drivers/gpu/drm/drm_crtc_internal.h | 5 +
include/drm/drm_atomic_helper.h | 4 -
4 files changed, 173 insertions(+), 168 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index f4924cb7f495..79335084a502 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1174,6 +1174,174 @@ int drm_atomic_nonblocking_commit(struct
drm_atomic_state *state)
}
EXPORT_SYMBOL(drm_atomic_nonblocking_commit);
+/* just used from drm-client and atomic-helper: */
+int __drm_atomic_helper_disable_plane(struct drm_plane *plane,
+ struct drm_plane_state *plane_state)
+{
+ int ret;
+
+ ret = drm_atomic_set_crtc_for_plane(plane_state, NULL);
+ if (ret != 0)
+ return ret;
+
+ drm_atomic_set_fb_for_plane(plane_state, NULL);
+ plane_state->crtc_x = 0;
+ plane_state->crtc_y = 0;
+ plane_state->crtc_w = 0;
+ plane_state->crtc_h = 0;
+ plane_state->src_x = 0;
+ plane_state->src_y = 0;
+ plane_state->src_w = 0;
+ plane_state->src_h = 0;
+
+ return 0;
+}
+EXPORT_SYMBOL(__drm_atomic_helper_disable_plane);
+
+static int update_output_state(struct drm_atomic_state *state,
+ struct drm_mode_set *set)
+{
+ struct drm_device *dev = set->crtc->dev;
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *new_crtc_state;
+ struct drm_connector *connector;
+ struct drm_connector_state *new_conn_state;
+ int ret, i;
+
+ ret = drm_modeset_lock(>mode_config.connection_mutex,
+ state->acquire_ctx);
+ if (ret)
+ return ret;
+
+ /* First disable all connectors on the target crtc. */
+ ret = drm_atomic_add_affected_connectors(state, set->crtc);
+ if (ret)
+ return ret;
+
+ for_each_new_connector_in_state(state, connector, new_conn_state, i) {
+ if (new_conn_state->crtc == set->crtc) {
+ ret = drm_atomic_set_crtc_for_connector(new_conn_state,
+ NULL);
+ if (ret)
+ return ret;
+
+ /* Make sure legacy setCrtc always re-trains */
+ new_conn_state->link_status = DRM_LINK_STATUS_GOOD;
+ }
+ }
+
+ /* Then set all connectors from set->connectors on the target crtc */
+ for (i = 0; i < set->num_connectors; i++) {
+ new_conn_state = drm_atomic_get_connector_state(state,
+
set->connectors[i]);
+ if (IS_ERR(new_conn_state))
+ return PTR_ERR(new_conn_state);
+
+ ret = drm_atomic_set_crtc_for_connector(new_conn_state,
+ set->crtc);
+ if (ret)
+ return ret;
+ }
+
+ for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
+ /*
+* Don't update ->enable for the CRTC in the set_config request,
+* since a mismatch would indicate a bug in the upper layers.
+* The actual modeset code later on will catch any
+* inconsistencies here.
+*/
+ if (crtc == set->crtc)
+ continue;
+
+ if (!new_crtc_state->connector_mask) {
+ ret = drm_atomic_set_mode_prop_for_crtc(new_crtc_state,
+ NULL);
+ if (ret < 0)
+ return ret;
+
+ new_crtc_state->active = false;
+ }
+ }
+
+ return 0;
+}
+
+/* just used from drm-client and atomic-helper: */
+int __drm_atomic_helper_set_config(struct drm_mode_set *set,
+ struct drm_atomic_state *state)
+{
+ struct drm_crtc_state *crtc_state;
+ struct drm_plane_state *primary_state;
+ struct drm_crtc *crtc = set->crtc;
+ int hdisplay, vdisplay;
+ int ret;
+
+ crtc_state = drm_atomic_get_crtc_state(state, crtc);
+ if (IS_ERR(crtc_state))
+ return PTR_ERR(crtc_state);
+
Re: [Intel-gfx] [PATCH 1/2] drm/syncobj: add an output syncobj parameter to find_fence
I should mentioned that this is going to make the find_fence() function
a fair bit more complex :)
On 23/05/2019 14:35, Lionel Landwerlin wrote:
Sure
-Lionel
On 23/05/2019 13:11, Zhou, David(ChunMing) wrote:
can you make the parameter optional? Otherwise looks good to me.
-David
Original Message
Subject: [PATCH 1/2] drm/syncobj: add an output syncobj parameter to
find_fence
From: Lionel Landwerlin
To: intel-...@lists.freedesktop.org
CC: Lionel Landwerlin ,"Koenig, Christian" ,"Zhou, David(ChunMing)"
,Eric Anholt ,DRI-Devel
[CAUTION: External Email]
We would like to get both the fence & the syncobj in i915 rather than
doing 2 calls to drm_syncobj_find() & drm_syncobj_find_fence().
Signed-off-by: Lionel Landwerlin
Cc: Christian Koenig
Cc: David(ChunMing) Zhou
Cc: Eric Anholt
CC: DRI-Devel
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++-
drivers/gpu/drm/drm_syncobj.c | 45 +-
drivers/gpu/drm/v3d/v3d_gem.c | 5 ++-
include/drm/drm_syncobj.h | 1 +
4 files changed, 38 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 2f6239b6be6f..09fde3c73a2c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1124,10 +1124,11 @@ static int
amdgpu_syncobj_lookup_and_add_to_sync(struct amdgpu_cs_parser *p,
uint32_t handle, u64
point,
u64 flags)
{
+ struct drm_syncobj *syncobj;
struct dma_fence *fence;
int r;
- r = drm_syncobj_find_fence(p->filp, handle, point, flags,
);
+ r = drm_syncobj_find_fence(p->filp, handle, point, flags,
, );
if (r) {
DRM_ERROR("syncobj %u failed to find fence @ %llu
(%d)!\n",
handle, point, r);
@@ -1136,6 +1137,7 @@ static int
amdgpu_syncobj_lookup_and_add_to_sync(struct amdgpu_cs_parser *p,
r = amdgpu_sync_fence(p->adev, >job->sync, fence, true);
dma_fence_put(fence);
+ drm_syncobj_put(syncobj);
return r;
}
diff --git a/drivers/gpu/drm/drm_syncobj.c
b/drivers/gpu/drm/drm_syncobj.c
index 3d400905100b..f2fd0c1fb1d3 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -222,29 +222,32 @@ static void
drm_syncobj_assign_null_handle(struct drm_syncobj *syncobj)
* @handle: sync object handle to lookup.
* @point: timeline point
* @flags: DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT or not
+ * @syncobj: out parameter for the syncobj
* @fence: out parameter for the fence
*
* This is just a convenience function that combines
drm_syncobj_find() and
* drm_syncobj_fence_get().
*
- * Returns 0 on success or a negative error value on failure. On
success @fence
- * contains a reference to the fence, which must be released by calling
- * dma_fence_put().
+ * Returns 0 on success or a negative error value on failure. On
+ * success @syncobj and @fence contains a reference respectively to
+ * the syncobj and to the fence, which must be released by calling
+ * respectively drm_syncobj_put() and dma_fence_put().
*/
int drm_syncobj_find_fence(struct drm_file *file_private,
u32 handle, u64 point, u64 flags,
+ struct drm_syncobj **syncobj,
struct dma_fence **fence)
{
- struct drm_syncobj *syncobj = drm_syncobj_find(file_private,
handle);
struct syncobj_wait_entry wait;
u64 timeout =
nsecs_to_jiffies64(DRM_SYNCOBJ_WAIT_FOR_SUBMIT_TIMEOUT);
int ret;
- if (!syncobj)
+ *syncobj = drm_syncobj_find(file_private, handle);
+
+ if (!(*syncobj))
return -ENOENT;
- *fence = drm_syncobj_fence_get(syncobj);
- drm_syncobj_put(syncobj);
+ *fence = drm_syncobj_fence_get(*syncobj);
if (*fence) {
ret = dma_fence_chain_find_seqno(fence, point);
@@ -255,13 +258,15 @@ int drm_syncobj_find_fence(struct drm_file
*file_private,
ret = -EINVAL;
}
- if (!(flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT))
+ if (!(flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT)) {
+ drm_syncobj_put(*syncobj);
return ret;
+ }
memset(, 0, sizeof(wait));
wait.task = current;
wait.point = point;
- drm_syncobj_fence_add_wait(syncobj, );
+ drm_syncobj_fence_add_wait(*syncobj, );
do {
set_current_state(TASK_INTERRUPTIBLE);
@@ -286,7 +291,10 @@ int drm_syncobj_find_fence(struct drm_file
*file_private,
*fence = wait.fence;
if (wait.node.next)
- drm_syncobj_remove_wait(syncobj, );
+ drm_syncobj_remove_wait(*syncobj, );
+
+ if (ret)
+ drm_syncobj_put(*syncobj);
return ret;
}
@@ -531,6
Re: [PATCH 1/2] drm/syncobj: add an output syncobj parameter to find_fence
Sure
-Lionel
On 23/05/2019 13:11, Zhou, David(ChunMing) wrote:
can you make the parameter optional? Otherwise looks good to me.
-David
Original Message
Subject: [PATCH 1/2] drm/syncobj: add an output syncobj parameter to
find_fence
From: Lionel Landwerlin
To: intel-...@lists.freedesktop.org
CC: Lionel Landwerlin ,"Koenig, Christian" ,"Zhou, David(ChunMing)"
,Eric Anholt ,DRI-Devel
[CAUTION: External Email]
We would like to get both the fence & the syncobj in i915 rather than
doing 2 calls to drm_syncobj_find() & drm_syncobj_find_fence().
Signed-off-by: Lionel Landwerlin
Cc: Christian Koenig
Cc: David(ChunMing) Zhou
Cc: Eric Anholt
CC: DRI-Devel
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++-
drivers/gpu/drm/drm_syncobj.c | 45 +-
drivers/gpu/drm/v3d/v3d_gem.c | 5 ++-
include/drm/drm_syncobj.h | 1 +
4 files changed, 38 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 2f6239b6be6f..09fde3c73a2c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1124,10 +1124,11 @@ static int
amdgpu_syncobj_lookup_and_add_to_sync(struct amdgpu_cs_parser *p,
uint32_t handle, u64
point,
u64 flags)
{
+ struct drm_syncobj *syncobj;
struct dma_fence *fence;
int r;
- r = drm_syncobj_find_fence(p->filp, handle, point, flags, );
+ r = drm_syncobj_find_fence(p->filp, handle, point, flags,
, );
if (r) {
DRM_ERROR("syncobj %u failed to find fence @ %llu
(%d)!\n",
handle, point, r);
@@ -1136,6 +1137,7 @@ static int
amdgpu_syncobj_lookup_and_add_to_sync(struct amdgpu_cs_parser *p,
r = amdgpu_sync_fence(p->adev, >job->sync, fence, true);
dma_fence_put(fence);
+ drm_syncobj_put(syncobj);
return r;
}
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 3d400905100b..f2fd0c1fb1d3 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -222,29 +222,32 @@ static void
drm_syncobj_assign_null_handle(struct drm_syncobj *syncobj)
* @handle: sync object handle to lookup.
* @point: timeline point
* @flags: DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT or not
+ * @syncobj: out parameter for the syncobj
* @fence: out parameter for the fence
*
* This is just a convenience function that combines
drm_syncobj_find() and
* drm_syncobj_fence_get().
*
- * Returns 0 on success or a negative error value on failure. On
success @fence
- * contains a reference to the fence, which must be released by calling
- * dma_fence_put().
+ * Returns 0 on success or a negative error value on failure. On
+ * success @syncobj and @fence contains a reference respectively to
+ * the syncobj and to the fence, which must be released by calling
+ * respectively drm_syncobj_put() and dma_fence_put().
*/
int drm_syncobj_find_fence(struct drm_file *file_private,
u32 handle, u64 point, u64 flags,
+ struct drm_syncobj **syncobj,
struct dma_fence **fence)
{
- struct drm_syncobj *syncobj = drm_syncobj_find(file_private,
handle);
struct syncobj_wait_entry wait;
u64 timeout =
nsecs_to_jiffies64(DRM_SYNCOBJ_WAIT_FOR_SUBMIT_TIMEOUT);
int ret;
- if (!syncobj)
+ *syncobj = drm_syncobj_find(file_private, handle);
+
+ if (!(*syncobj))
return -ENOENT;
- *fence = drm_syncobj_fence_get(syncobj);
- drm_syncobj_put(syncobj);
+ *fence = drm_syncobj_fence_get(*syncobj);
if (*fence) {
ret = dma_fence_chain_find_seqno(fence, point);
@@ -255,13 +258,15 @@ int drm_syncobj_find_fence(struct drm_file
*file_private,
ret = -EINVAL;
}
- if (!(flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT))
+ if (!(flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT)) {
+ drm_syncobj_put(*syncobj);
return ret;
+ }
memset(, 0, sizeof(wait));
wait.task = current;
wait.point = point;
- drm_syncobj_fence_add_wait(syncobj, );
+ drm_syncobj_fence_add_wait(*syncobj, );
do {
set_current_state(TASK_INTERRUPTIBLE);
@@ -286,7 +291,10 @@ int drm_syncobj_find_fence(struct drm_file
*file_private,
*fence = wait.fence;
if (wait.node.next)
- drm_syncobj_remove_wait(syncobj, );
+ drm_syncobj_remove_wait(*syncobj, );
+
+ if (ret)
+ drm_syncobj_put(*syncobj);
return ret;
}
@@ -531,6 +539,7 @@ static int drm_syncobj_export_sync_file(struct
drm_file *file_private,
int handle, int *p_fd)
{
Re: linux-next: manual merge of the drm-misc tree with Linus' tree
On Thu, May 23, 2019 at 3:04 PM Stephen Rothwell wrote:
>
> Hi Maxime,
>
> On Thu, 23 May 2019 13:53:55 +0200 Maxime Ripard
> wrote:
> >
> > On Tue, May 21, 2019 at 10:51:51AM +1000, Stephen Rothwell wrote:
> > >
> > > Today's linux-next merge of the drm-misc tree got a conflict in:
> > >
> > > Documentation/devicetree/bindings/vendor-prefixes.txt
> > >
> > > between commit:
> > >
> > > 8122de54602e ("dt-bindings: Convert vendor prefixes to json-schema")
> > >
> > > from Linus' tree and commits:
> > >
> > > b4a2c0055a4f ("dt-bindings: Add vendor prefix for VXT Ltd")
> > > b1b0d36bdb15 ("dt-bindings: drm/panel: simple: Add binding for TFC
> > > S9700RTWV43TR-01B")
> > > fbd8b69ab616 ("dt-bindings: Add vendor prefix for Evervision
> > > Electronics")
> > >
> > > from the drm-misc tree.
> >
> > I just took your patch and pushed a temp branch there:
> > https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git/commit/?h=drm-misc-next=3832f2cad5307ebcedeead13fbd8d3cf06ba5e90
> >
> > Rob, Stephen, are you ok with the change? If so, I'll push it.
>
> All that needs to be done is for my patch (slightly corrected) needs to
> be applied to the drm-misc tree. That tree already has the back merge
> of Linus' tree and the txt file has been removed (my patch should have
> been applied as part of the merge resolution but doing it later is fine).
That commit is on top of drm-misc, and somehow the .txt version has
been resurrect in drm-misc-next (so needs to be re-deleted too).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
Re: linux-next: manual merge of the drm-misc tree with Linus' tree
Hi Maxime,
On Thu, 23 May 2019 13:53:55 +0200 Maxime Ripard
wrote:
>
> On Tue, May 21, 2019 at 10:51:51AM +1000, Stephen Rothwell wrote:
> >
> > Today's linux-next merge of the drm-misc tree got a conflict in:
> >
> > Documentation/devicetree/bindings/vendor-prefixes.txt
> >
> > between commit:
> >
> > 8122de54602e ("dt-bindings: Convert vendor prefixes to json-schema")
> >
> > from Linus' tree and commits:
> >
> > b4a2c0055a4f ("dt-bindings: Add vendor prefix for VXT Ltd")
> > b1b0d36bdb15 ("dt-bindings: drm/panel: simple: Add binding for TFC
> > S9700RTWV43TR-01B")
> > fbd8b69ab616 ("dt-bindings: Add vendor prefix for Evervision Electronics")
> >
> > from the drm-misc tree.
>
> I just took your patch and pushed a temp branch there:
> https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git/commit/?h=drm-misc-next=3832f2cad5307ebcedeead13fbd8d3cf06ba5e90
>
> Rob, Stephen, are you ok with the change? If so, I'll push it.
All that needs to be done is for my patch (slightly corrected) needs to
be applied to the drm-misc tree. That tree already has the back merge
of Linus' tree and the txt file has been removed (my patch should have
been applied as part of the merge resolution but doing it later is fine).
--
Cheers,
Stephen Rothwell
pgpvak0h66Fo7.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/6] drm/bridge: Add Analogix anx6345 support
On Thu, May 23, 2019 at 10:50:41AM +0300, Laurent Pinchart wrote:
> Hi Torsten,
>
> Thank you for the patch.
Thank you for the thorough review!
> On Thu, May 23, 2019 at 08:53:56AM +0200, Torsten Duwe wrote:
> > +{
> > + struct anx6345 *anx6345 = connector_to_anx6345(connector);
> > + int err, num_modes = 0;
> > + bool power_off = false;
> > +
> > + mutex_lock(>lock);
> > +
> > + if (!anx6345->edid) {
>
> Could the chip be used with a hot-pluggable display, or is it guaranteed
> that EDID will never change ?
The chip itself is capable of (e)DP hot-plugging, so the signals suggest.
See the previous discussions about what to expect on the output side.
Currently, the driver does not handle hot-plugging.
> > +
> > + err = drm_of_find_panel_or_bridge(client->dev.of_node, 1, 0,
> > + >panel, NULL);
> > + if (err == -EPROBE_DEFER)
> > + return err;
> > +
> > + if (err)
> > + DRM_DEBUG("No panel found\n");
>
> Shouldn't this be fatal ?
No, basically same as above. On the output side, there can be a panel,
another bridge, or some eDP plug. If the DT didn't explicitly specify
a panel or a bridge, we can still generate video output as soon as
there is valid EDID data.
Your other points went straight onto my TODO list.
Torsten
Re: [PATCH 5/6] dt-bindings: Add ANX6345 DP/eDP transmitter binding
On Thu, May 23, 2019 at 11:05:40AM +0200, Maxime Ripard wrote: > > +Optional properties: > > + > > + - Video ports for RGB input and eDP output using the DT bindings > > + defined in [1] > > The output node can be optional, but the input one is probably going > to be needed all the time, since otherwise you won't be able to fill > the output port of the upstream device in the graph. I guess so. A sibling product brief (anx9804) https://www.analogix.com/en/ttlconvertersbridges references it as | LVTTL to DisplayPort 1.2 _transmitter_ so it will probably always be used on the output side. Torsten
Re: [PATCH v5 5/6] drm: sun4i: Add support for enabling DDC I2C bus to sun8i_dw_hdmi glue
On Tue, May 21, 2019 at 02:15:19PM +0200, Ondřej Jirman wrote:
> Hi Maxime,
>
> On Tue, May 21, 2019 at 01:46:11PM +0200, Maxime Ripard wrote:
> > Hi,
> >
> > On Tue, May 21, 2019 at 01:50:08AM +0200, meg...@megous.com wrote:
> > > From: Ondrej Jirman
> > >
> > > Orange Pi 3 board requires enabling a voltage shifting circuit via GPIO
> > > for the DDC bus to be usable.
> > >
> > > Add support for hdmi-connector node's optional ddc-en-gpios property to
> > > support this use case.
> > >
> > > Signed-off-by: Ondrej Jirman
> > > ---
> > > drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 55 +--
> > > drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 3 ++
> > > 2 files changed, 55 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> > > b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> > > index 39d8509d96a0..59b81ba02d96 100644
> > > --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> > > +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> > > @@ -98,6 +98,30 @@ static u32 sun8i_dw_hdmi_find_possible_crtcs(struct
> > > drm_device *drm,
> > > return crtcs;
> > > }
> > >
> > > +static int sun8i_dw_hdmi_find_connector_pdev(struct device *dev,
> > > + struct platform_device **pdev_out)
> > > +{
> > > + struct platform_device *pdev;
> > > + struct device_node *remote;
> > > +
> > > + remote = of_graph_get_remote_node(dev->of_node, 1, -1);
> > > + if (!remote)
> > > + return -ENODEV;
> > > +
> > > + if (!of_device_is_compatible(remote, "hdmi-connector")) {
> > > + of_node_put(remote);
> > > + return -ENODEV;
> > > + }
> > > +
> > > + pdev = of_find_device_by_node(remote);
> > > + of_node_put(remote);
> > > + if (!pdev)
> > > + return -ENODEV;
> > > +
> > > + *pdev_out = pdev;
> > > + return 0;
> > > +}
> > > +
> > > static int sun8i_dw_hdmi_bind(struct device *dev, struct device *master,
> > > void *data)
> > > {
> > > @@ -151,16 +175,29 @@ static int sun8i_dw_hdmi_bind(struct device *dev,
> > > struct device *master,
> > > return PTR_ERR(hdmi->regulator);
> > > }
> > >
> > > + ret = sun8i_dw_hdmi_find_connector_pdev(dev, >connector_pdev);
> > > + if (!ret) {
> > > + hdmi->ddc_en = gpiod_get_optional(>connector_pdev->dev,
> > > + "ddc-en", GPIOD_OUT_HIGH);
> > > + if (IS_ERR(hdmi->ddc_en)) {
> > > + platform_device_put(hdmi->connector_pdev);
> > > + dev_err(dev, "Couldn't get ddc-en gpio\n");
> > > + return PTR_ERR(hdmi->ddc_en);
> > > + }
> > > + }
> > > +
> > > ret = regulator_enable(hdmi->regulator);
> > > if (ret) {
> > > dev_err(dev, "Failed to enable regulator\n");
> > > - return ret;
> > > + goto err_unref_ddc_en;
> > > }
> > >
> > > + gpiod_set_value(hdmi->ddc_en, 1);
> > > +
> >
> > Do you really need this to be done all the time? I'm guessing you
> > would only need this when running .get_modes, right?
>
> I don't think it hurts anything. Enabled voltage shifting circuit doesn't
> draw any current, unless DDC is actually transmitting data. On most boards
> I'd imagine this circuit is always on anyway (Orange Pi 3 schematic even has
> an option to tie this signal to VCC-IO instead of GPIO).
Ok, it works for me then
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
