Re: [PATCH RFC v2 0/6] ARM: qcom: initial Nexus 5 display support
On Wed, May 29, 2019 at 3:17 AM Brian Masney wrote: > It's in low speed mode but its usable. How low speed is that? > I assume that it's related to the > vblank events not working properly? They are only waiting for 50 ms before timing out, I raised it to 100ms in the -next kernel. I'm still suspicious about this even though I think you said this was not the problem. For a command mode panel in LP mode it will nevertheless be more than 100ms for sure, the update is visible to the naked eye. Raise it to 1 ms or something and see what happens. drivers/gpu/drm/drm_atomic_helper.c: msecs_to_jiffies(50) Yours, Linus Walleij
Re: [RESEND PATCH v2 2/2] drm/panfrost: Expose perf counters through debugfs
On Tue, 28 May 2019 16:01:15 +0200
Boris Brezillon wrote:
> On Tue, 28 May 2019 15:53:48 +0200
> Boris Brezillon wrote:
>
> > Hi Steve,
> >
> > On Thu, 16 May 2019 17:21:39 +0100
> > Steven Price wrote:
> >
> >
> > > >> +static void panfrost_perfcnt_setup(struct panfrost_device *pfdev)
> > > >> +{
> > > >> + u32 cfg;
> > > >> +
> > > >> + /*
> > > >> +* Always use address space 0 for now.
> > > >> +* FIXME: this needs to be updated when we start using
> > > >> different
> > > >> +* address space.
> > > >> +*/
> > > >> + cfg = GPU_PERFCNT_CFG_AS(0);
> > > >> + if (panfrost_model_cmp(pfdev, 0x1000) >= 0)
> > > >
> > > > You've got a couple of these. Perhaps we should add either a
> > > > model_is_bifrost() helper or an is_bifrost variable to use.
> > > >
> > > >> + cfg |= GPU_PERFCNT_CFG_SETSEL(1);
> > >
> > > mali_kbase only sets this if CONFIG_MALI_PRFCNT_SET_SECONDARY is defined
> > > - i.e. this selects a different selection of counters. At at the very
> > > least this should be an optional flag that can be set, but I suspect the
> > > primary set are the ones you are interested in.
> >
> > I'll add a param to pass the set of counters to monitor.
> >
> > >
> > > >> +
> > > >> + gpu_write(pfdev, GPU_PERFCNT_CFG,
> > > >> + cfg |
> > > >> GPU_PERFCNT_CFG_MODE(GPU_PERFCNT_CFG_MODE_OFF));
> > > >> +
> > > >> + if (!pfdev->perfcnt->enabled)
> > > >> + return;
> > > >> +
> > > >> + gpu_write(pfdev, GPU_PRFCNT_JM_EN, 0x);
> > > >> + gpu_write(pfdev, GPU_PRFCNT_SHADER_EN, 0x);
> > > >> + gpu_write(pfdev, GPU_PRFCNT_MMU_L2_EN, 0x);
> > > >> +
> > > >> + /*
> > > >> +* Due to PRLAM-8186 we need to disable the Tiler before we
> > > >> enable HW
> > > >> +* counters.
> > > >
> > > > Seems like you could just always apply the work-around? It doesn't
> > > > look like it would be much different.
> > >
> > > Technically the workaround causes the driver to perform the operation in
> > > the wrong order below (write TILER_EN when the mode is MANUAL) - this is
> > > a workaround for the hardware issue (and therefore works on that
> > > hardware). But I wouldn't like to say it works on other hardware which
> > > doesn't have the issue.
> >
> > Okay, I'll keep the workaround only for HW that are impacted by the bug.
> >
> > >
> > > >> +*/
> > > >> + if (panfrost_has_hw_issue(pfdev, HW_ISSUE_8186))
> > > >> + gpu_write(pfdev, GPU_PRFCNT_TILER_EN, 0);
> > > >> + else
> > > >> + gpu_write(pfdev, GPU_PRFCNT_TILER_EN, 0x);
> > > >> +
> > > >> + gpu_write(pfdev, GPU_PERFCNT_CFG,
> > > >> + cfg |
> > > >> GPU_PERFCNT_CFG_MODE(GPU_PERFCNT_CFG_MODE_MANUAL));
> > > >> +
> > > >> + if (panfrost_has_hw_issue(pfdev, HW_ISSUE_8186))
> > > >> + gpu_write(pfdev, GPU_PRFCNT_TILER_EN, 0x);
> > > >> +}
> >
> > [...]
> >
> > > >> +int panfrost_perfcnt_init(struct panfrost_device *pfdev)
> > > >> +{
> > > >> + struct panfrost_perfcnt *perfcnt;
> > > >> + struct drm_gem_shmem_object *bo;
> > > >> + size_t size;
> > > >> + u32 status;
> > > >> + int ret;
> > > >> +
> > > >> + if (panfrost_has_hw_feature(pfdev, HW_FEATURE_V4)) {
> > > >> + unsigned int ncoregroups;
> > > >> +
> > > >> + ncoregroups = hweight64(pfdev->features.l2_present);
> > > >> + size = ncoregroups * BLOCKS_PER_COREGROUP *
> > > >> + COUNTERS_PER_BLOCK * BYTES_PER_COUNTER;
> > > >> + } else {
> > > >> + unsigned int nl2c, ncores;
> > > >> +
> > > >> + /*
> > > >> +* TODO: define a macro to extract the number of l2
> > > >> caches from
> > > >> +* mem_features.
> > > >> +*/
> > > >> + nl2c = ((pfdev->features.mem_features >> 8) &
> > > >> GENMASK(3, 0)) + 1;
> > > >> +
> > > >> + /*
> > > >> +* The ARM driver is grouping cores per core group and
> > > >> then
> > > >> +* only using the number of cores in group 0 to
> > > >> calculate the
> > > >> +* size. Not sure why this is done like that, but I
> > > >> guess
> > > >> +* shader_present will only show cores in the first
> > > >> group
> > > >> +* anyway.
> > > >> +*/
> > >
> > > I'm not sure I understand this comment. I'm not sure which version of
> > > the driver you are looking at, but shader_present should contain all the
> > > cores (in every core group).
> > >
> > > The kbase driver (in panfrost's git tree[1]), contains:
> > >
> > > base_gpu_props *props = >gpu_props.props;
> > > u32 nr_l2 = props->l2_props.num_l2_slices;
> > > u64 core_mask =
Re: [PATCH] drm/gem_shmem: Use a writecombine mapping for ->vaddr
On Wed, May 29, 2019 at 08:51:21AM +0200, Boris Brezillon wrote:
> Right now, the BO is mapped as a cached region when ->vmap() is called
> and the underlying object is not a dmabuf.
> Doing that makes cache management a bit more complicated (you'd need
> to call dma_map/unmap_sg() on the ->sgt field everytime the BO is about
> to be passed to the GPU/CPU), so let's map the BO with writecombine
> attributes instead (as done in most drivers).
>
> Signed-off-by: Boris Brezillon
> ---
> Found this issue while working on panfrost perfcnt where the GPU dumps
> perf counter values in memory and the CPU reads them back in
> kernel-space. This patch seems to solve the unpredictable behavior I
> had.
>
> I can also go for the other option (call dma_map/unmap/_sg() when
> needed) if you think that's more appropriate.
Uh, I guess shmem helpers (or gem helpers in general) need some concept
about what kind of cpu mapping is desired. Since some cpus (like e.g.
i915) do actually want cached mode for everything.
Same is needed for the userspace mmap, those should all agree.
Default probably best if we go with uncached.
-Daniel
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index 1ee208c2c85e..472ea5d81f82 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -255,7 +255,8 @@ static void *drm_gem_shmem_vmap_locked(struct
> drm_gem_shmem_object *shmem)
> if (obj->import_attach)
> shmem->vaddr = dma_buf_vmap(obj->import_attach->dmabuf);
> else
> - shmem->vaddr = vmap(shmem->pages, obj->size >> PAGE_SHIFT,
> VM_MAP, PAGE_KERNEL);
> + shmem->vaddr = vmap(shmem->pages, obj->size >> PAGE_SHIFT,
> + VM_MAP, pgprot_writecombine(PAGE_KERNEL));
>
> if (!shmem->vaddr) {
> DRM_DEBUG_KMS("Failed to vmap pages\n");
> --
> 2.20.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm: mediatek: fix unbind functions
On Wed, May 29, 2019 at 9:35 AM CK Hu wrote: > > I think mtk_dsi_destroy_conn_enc() has much thing to do and I would like > you to do more. You could refer to [2] for complete implementation. > > [2] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/exynos/exynos_drm_dsi.c?h=v5.2-rc2#n1575 > Hi CK, Since drm_encoder_cleanup() would already call drm_bridge_detach() to detach bridge, I think we only need to handle panel case here. We don't need to call mtk_dsi_encoder_disable() since mtk_output_dsi_disable() is called in mtk_dsi_remove() and dsi->enabled will be set to false. Calling second time will just returns immediately. So, besides setting dsi->panel = NULL; dsi->conn.status = connector_status_disconnected; are there other things we need to do here? Original code doesn't have drm_kms_helper_hotplug_event(), and I'm not sure if mtk dsi would need this. Also, mtk_dsi_stop() would also stop irq. Thanks
Re: [PATCHv6 0/4] omapdrm: DSI command mode panel support
On 28/05/2019 13:18, Tony Lindgren wrote: My board is x15 rev A3, attached to AM5 EVM. I've also attached my kernel config. Strange that this is not affecting other x15? I think timer12 would be blocked on HS devices though? Seems that the kernel config affects. omap2plus_defconfig boots ok. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm: mediatek: remove clk_unprepare() in mtk_drm_crtc_destroy()
On Wed, May 29, 2019 at 1:58 PM CK Hu wrote: > > Hi, Hsin-Yi: > > On Mon, 2019-05-27 at 12:50 +0800, Hsin-Yi Wang wrote: > > There is no clk_prepare() called in mtk_drm_crtc_reset(), when unbinding > > drm device, mtk_drm_crtc_destroy() will be triggered, and the clocks will > > be disabled and unprepared in mtk_crtc_ddp_clk_disable. If clk_unprepare() > > is called here, we'll get warnings[1], so remove clk_unprepare() here. > > In original code, clk_prepare() is called in mtk_drm_crtc_create() and > clk_unprepare() is called in mtk_drm_crtc_destroy(). This looks correct. clk_prepare() is removed in https://patchwork.kernel.org/patch/10872777/. > I don't know why we should do any thing about clock in > mtk_drm_crtc_reset(). To debug this, the first step is to print message > when mediatek drm call clk_prepare() and clk_unprepare(). If these two > interface is called in pair, I think we should not modify mediatek drm > driver, the bug maybe in clock driver. >
[PATCH] drm/gem_shmem: Use a writecombine mapping for ->vaddr
Right now, the BO is mapped as a cached region when ->vmap() is called
and the underlying object is not a dmabuf.
Doing that makes cache management a bit more complicated (you'd need
to call dma_map/unmap_sg() on the ->sgt field everytime the BO is about
to be passed to the GPU/CPU), so let's map the BO with writecombine
attributes instead (as done in most drivers).
Signed-off-by: Boris Brezillon
---
Found this issue while working on panfrost perfcnt where the GPU dumps
perf counter values in memory and the CPU reads them back in
kernel-space. This patch seems to solve the unpredictable behavior I
had.
I can also go for the other option (call dma_map/unmap/_sg() when
needed) if you think that's more appropriate.
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 1ee208c2c85e..472ea5d81f82 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -255,7 +255,8 @@ static void *drm_gem_shmem_vmap_locked(struct
drm_gem_shmem_object *shmem)
if (obj->import_attach)
shmem->vaddr = dma_buf_vmap(obj->import_attach->dmabuf);
else
- shmem->vaddr = vmap(shmem->pages, obj->size >> PAGE_SHIFT,
VM_MAP, PAGE_KERNEL);
+ shmem->vaddr = vmap(shmem->pages, obj->size >> PAGE_SHIFT,
+ VM_MAP, pgprot_writecombine(PAGE_KERNEL));
if (!shmem->vaddr) {
DRM_DEBUG_KMS("Failed to vmap pages\n");
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm: mediatek: remove clk_unprepare() in mtk_drm_crtc_destroy()
Hi, Hsin-Yi: On Wed, 2019-05-29 at 14:08 +0800, Hsin-Yi Wang wrote: > On Wed, May 29, 2019 at 1:58 PM CK Hu wrote: > > > > Hi, Hsin-Yi: > > > > On Mon, 2019-05-27 at 12:50 +0800, Hsin-Yi Wang wrote: > > > There is no clk_prepare() called in mtk_drm_crtc_reset(), when unbinding > > > drm device, mtk_drm_crtc_destroy() will be triggered, and the clocks will > > > be disabled and unprepared in mtk_crtc_ddp_clk_disable. If clk_unprepare() > > > is called here, we'll get warnings[1], so remove clk_unprepare() here. > > > > In original code, clk_prepare() is called in mtk_drm_crtc_create() and > > clk_unprepare() is called in mtk_drm_crtc_destroy(). This looks correct. > > clk_prepare() is removed in https://patchwork.kernel.org/patch/10872777/. > I think this patch is a fix of that patch, and I've already applied that patch, so I merge this patch with that patch in my tree [1], thanks. [1] https://github.com/ckhu-mediatek/linux.git-tags/commit/937f861def1a1d49abb92e041efaa5c259281fbf Regards, CK > > I don't know why we should do any thing about clock in > > mtk_drm_crtc_reset(). To debug this, the first step is to print message > > when mediatek drm call clk_prepare() and clk_unprepare(). If these two > > interface is called in pair, I think we should not modify mediatek drm > > driver, the bug maybe in clock driver. > >
[Bug 110795] Unable to install on latest Ubuntu (19.04)
https://bugs.freedesktop.org/show_bug.cgi?id=110795 --- Comment #2 from Rolf --- Also, the install scrip fails without rolling back anything and leaving the system in a half-baked state. The supplied uninstall fails because amdgpu-core isn't installed yet. Since only 18.04 is supported, the install script should at least check for that before installing half a dozen packages for which "apt --fix-broken" cannot resolve their dependencies, due to the hard coded Ubuntu version. Catch-22. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:drm-next-5.3-wip 207/222] drivers/gpu/drm/panfrost/panfrost_job.c:390:3: error: too few arguments to function 'drm_sched_stop'
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-5.3-wip
head: 66ca5577c50a68d89e0e9ad7a2eba697911622c9
commit: ceb7ee86fbedcf20e978b7e41dfce5b144f71dfa [207/222] drm/scheduler:
rework job destruction
config: sparc64-allmodconfig (attached as .config)
compiler: sparc64-linux-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout ceb7ee86fbedcf20e978b7e41dfce5b144f71dfa
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=sparc64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/panfrost/panfrost_job.c: In function 'panfrost_job_timedout':
>> drivers/gpu/drm/panfrost/panfrost_job.c:390:3: error: too few arguments to
>> function 'drm_sched_stop'
drm_sched_stop(>js->queue[i].sched);
^~
In file included from drivers/gpu/drm/panfrost/panfrost_job.c:10:0:
include/drm/gpu_scheduler.h:295:6: note: declared here
void drm_sched_stop(struct drm_gpu_scheduler *sched, struct drm_sched_job
*bad);
^~
vim +/drm_sched_stop +390 drivers/gpu/drm/panfrost/panfrost_job.c
f3ba9122 Rob Herring 2018-09-10 365
f3ba9122 Rob Herring 2018-09-10 366 static void panfrost_job_timedout(struct
drm_sched_job *sched_job)
f3ba9122 Rob Herring 2018-09-10 367 {
f3ba9122 Rob Herring 2018-09-10 368 struct panfrost_job *job =
to_panfrost_job(sched_job);
f3ba9122 Rob Herring 2018-09-10 369 struct panfrost_device *pfdev =
job->pfdev;
f3ba9122 Rob Herring 2018-09-10 370 int js = panfrost_job_get_slot(job);
f3ba9122 Rob Herring 2018-09-10 371 int i;
f3ba9122 Rob Herring 2018-09-10 372
f3ba9122 Rob Herring 2018-09-10 373 /*
f3ba9122 Rob Herring 2018-09-10 374* If the GPU managed to complete this
jobs fence, the timeout is
f3ba9122 Rob Herring 2018-09-10 375* spurious. Bail out.
f3ba9122 Rob Herring 2018-09-10 376*/
f3ba9122 Rob Herring 2018-09-10 377 if
(dma_fence_is_signaled(job->done_fence))
f3ba9122 Rob Herring 2018-09-10 378 return;
f3ba9122 Rob Herring 2018-09-10 379
f3ba9122 Rob Herring 2018-09-10 380 dev_err(pfdev->dev, "gpu sched timeout,
js=%d, status=0x%x, head=0x%x, tail=0x%x, sched_job=%p",
f3ba9122 Rob Herring 2018-09-10 381 js,
f3ba9122 Rob Herring 2018-09-10 382 job_read(pfdev, JS_STATUS(js)),
f3ba9122 Rob Herring 2018-09-10 383 job_read(pfdev, JS_HEAD_LO(js)),
f3ba9122 Rob Herring 2018-09-10 384 job_read(pfdev, JS_TAIL_LO(js)),
f3ba9122 Rob Herring 2018-09-10 385 sched_job);
f3ba9122 Rob Herring 2018-09-10 386
aa202367 Tomeu Vizoso 2019-04-18 387 mutex_lock(>reset_lock);
aa202367 Tomeu Vizoso 2019-04-18 388
f3ba9122 Rob Herring 2018-09-10 389 for (i = 0; i < NUM_JOB_SLOTS; i++)
f3ba9122 Rob Herring 2018-09-10 @390
drm_sched_stop(>js->queue[i].sched);
f3ba9122 Rob Herring 2018-09-10 391
f3ba9122 Rob Herring 2018-09-10 392 if (sched_job)
f3ba9122 Rob Herring 2018-09-10 393
drm_sched_increase_karma(sched_job);
f3ba9122 Rob Herring 2018-09-10 394
f3ba9122 Rob Herring 2018-09-10 395 /* panfrost_core_dump(pfdev); */
f3ba9122 Rob Herring 2018-09-10 396
f3ba9122 Rob Herring 2018-09-10 397
panfrost_devfreq_record_transition(pfdev, js);
f3ba9122 Rob Herring 2018-09-10 398 panfrost_gpu_soft_reset(pfdev);
f3ba9122 Rob Herring 2018-09-10 399
f3ba9122 Rob Herring 2018-09-10 400 /* TODO: Re-enable all other address
spaces */
f3ba9122 Rob Herring 2018-09-10 401 panfrost_mmu_enable(pfdev, 0);
f3ba9122 Rob Herring 2018-09-10 402 panfrost_gpu_power_on(pfdev);
f3ba9122 Rob Herring 2018-09-10 403 panfrost_job_enable_interrupts(pfdev);
f3ba9122 Rob Herring 2018-09-10 404
f3ba9122 Rob Herring 2018-09-10 405 for (i = 0; i < NUM_JOB_SLOTS; i++)
f3ba9122 Rob Herring 2018-09-10 406
drm_sched_resubmit_jobs(>js->queue[i].sched);
f3ba9122 Rob Herring 2018-09-10 407
f3ba9122 Rob Herring 2018-09-10 408 /* restart scheduler after GPU is
usable again */
f3ba9122 Rob Herring 2018-09-10 409 for (i = 0; i < NUM_JOB_SLOTS; i++)
f3ba9122 Rob Herring 2018-09-10 410
drm_sched_start(>js->queue[i].sched, true);
aa202367 Tomeu Vizoso 2019-04-18 411
aa202367 Tomeu Vizoso 2019-04-18 412 mutex_unlock(>reset_lock);
f3ba9122 Rob Herring 2018-09-10 413 }
f3ba9122 Rob Herring 2018-09-10 414
:: The code at line 390 was first introduced by commit
:: f3ba91228e8e917e5bd6c4b72bfe846933d17370 drm/panfrost: Add initial
panfrost driver
:: TO: Rob Herring
:: CC: Rob Herring
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Re: [PATCH v2 4/4] drm: mediatek: clear num_pipes when unbind driver
Hi, Hsin-Yi:
On Wed, 2019-05-29 at 18:25 +0800, Hsin-Yi Wang wrote:
> num_pipes is used for mutex created in mtk_drm_crtc_create(). If we
> don't clear num_pipes count, when rebinding driver, the count will
> be accumulated. From mtk_disp_mutex_get(), there can only be at most
> 10 mutex id. Clear this number so it starts from 0 in every rebind.
Reviewed-by: CK Hu
>
> Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
> Signed-off-by: Hsin-Yi Wang
> ---
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 8718d123ccaa..bbfe3a464aea 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -400,6 +400,7 @@ static void mtk_drm_unbind(struct device *dev)
> drm_dev_unregister(private->drm);
> mtk_drm_kms_deinit(private->drm);
> drm_dev_put(private->drm);
> + private->num_pipes = 0;
> private->drm = NULL;
> }
>
[PATCH 5.1 239/405] drm/pl111: fix possible object reference leak
[ Upstream commit bc29d3a69d4c1bd1a103e8b3c1ed81b807c1870b ]
The call to of_find_matching_node_and_match returns a node pointer with
refcount incremented thus it must be explicitly decremented after the
last usage.
Detected by coccinelle with the following warnings:
drivers/gpu/drm/pl111/pl111_versatile.c:333:3-9: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 317, but without a
corresponding object release within this function.
drivers/gpu/drm/pl111/pl111_versatile.c:340:3-9: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 317, but without a
corresponding object release within this function.
drivers/gpu/drm/pl111/pl111_versatile.c:346:3-9: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 317, but without a
corresponding object release within this function.
drivers/gpu/drm/pl111/pl111_versatile.c:354:2-8: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 317, but without a
corresponding object release within this function.
drivers/gpu/drm/pl111/pl111_versatile.c:395:3-9: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 317, but without a
corresponding object release within this function.
drivers/gpu/drm/pl111/pl111_versatile.c:402:1-7: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 317, but without a
corresponding object release within this function.
Signed-off-by: Wen Yang
Cc: Eric Anholt (supporter:DRM DRIVER FOR ARM PL111 CLCD)
Cc: David Airlie (maintainer:DRM DRIVERS)
Cc: Daniel Vetter (maintainer:DRM DRIVERS)
Cc: dri-devel@lists.freedesktop.org (open list:DRM DRIVERS)
Cc: linux-ker...@vger.kernel.org (open list)
Signed-off-by: Eric Anholt
Link:
https://patchwork.freedesktop.org/patch/msgid/1554307455-40361-6-git-send-email-wen.yan...@zte.com.cn
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/pl111/pl111_versatile.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/pl111/pl111_versatile.c
b/drivers/gpu/drm/pl111/pl111_versatile.c
index b9baefdba38a1..1c318ad32a8cd 100644
--- a/drivers/gpu/drm/pl111/pl111_versatile.c
+++ b/drivers/gpu/drm/pl111/pl111_versatile.c
@@ -330,6 +330,7 @@ int pl111_versatile_init(struct device *dev, struct
pl111_drm_dev_private *priv)
ret = vexpress_muxfpga_init();
if (ret) {
dev_err(dev, "unable to initialize muxfpga driver\n");
+ of_node_put(np);
return ret;
}
@@ -337,17 +338,20 @@ int pl111_versatile_init(struct device *dev, struct
pl111_drm_dev_private *priv)
pdev = of_find_device_by_node(np);
if (!pdev) {
dev_err(dev, "can't find the sysreg device,
deferring\n");
+ of_node_put(np);
return -EPROBE_DEFER;
}
map = dev_get_drvdata(>dev);
if (!map) {
dev_err(dev, "sysreg has not yet probed\n");
platform_device_put(pdev);
+ of_node_put(np);
return -EPROBE_DEFER;
}
} else {
map = syscon_node_to_regmap(np);
}
+ of_node_put(np);
if (IS_ERR(map)) {
dev_err(dev, "no Versatile syscon regmap\n");
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/4] drm: mediatek: unbind components in mtk_drm_unbind()
Hi, Hsin-Yi:
On Wed, 2019-05-29 at 18:25 +0800, Hsin-Yi Wang wrote:
> Unbinding components (i.e. mtk_dsi and mtk_disp_ovl/rdma/color) will
> trigger master(mtk_drm)'s .unbind(), and currently mtk_drm's unbind
> won't actually unbind components. During the next bind,
> mtk_drm_kms_init() is called, and the components are added back.
>
> .unbind() should call mtk_drm_kms_deinit() to unbind components.
>
> And since component_master_del() in .remove() will trigger .unbind(),
> which will also unregister device, it's fine to remove original functions
> called here.
Reviewed-by: CK Hu
>
> Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
> Signed-off-by: Hsin-Yi Wang
> ---
> change log v1->v2:
> * separate another 2 fixes to other patches.
> ---
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 57ce4708ef1b..e7362bdafa82 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -397,6 +397,7 @@ static void mtk_drm_unbind(struct device *dev)
> struct mtk_drm_private *private = dev_get_drvdata(dev);
>
> drm_dev_unregister(private->drm);
> + mtk_drm_kms_deinit(private->drm);
> drm_dev_put(private->drm);
> private->drm = NULL;
> }
> @@ -568,13 +569,8 @@ static int mtk_drm_probe(struct platform_device *pdev)
> static int mtk_drm_remove(struct platform_device *pdev)
> {
> struct mtk_drm_private *private = platform_get_drvdata(pdev);
> - struct drm_device *drm = private->drm;
> int i;
>
> - drm_dev_unregister(drm);
> - mtk_drm_kms_deinit(drm);
> - drm_dev_put(drm);
> -
> component_master_del(>dev, _drm_ops);
> pm_runtime_disable(>dev);
> of_node_put(private->mutex_node);
[PATCH 5.1 173/405] drm/msm: a5xx: fix possible object reference leak
[ Upstream commit 6cd5235c3135ea84b32469ea51b2aae384eda8af ]
The call to of_get_child_by_name returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
drivers/gpu/drm/msm/adreno/a5xx_gpu.c:57:2-8: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 47, but without a
corresponding object release within this function.
drivers/gpu/drm/msm/adreno/a5xx_gpu.c:66:2-8: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 47, but without a
corresponding object release within this function.
drivers/gpu/drm/msm/adreno/a5xx_gpu.c:118:1-7: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 47, but without a
corresponding object release within this function.
drivers/gpu/drm/msm/adreno/a5xx_gpu.c:57:2-8: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 51, but without a
corresponding object release within this function.
drivers/gpu/drm/msm/adreno/a5xx_gpu.c:66:2-8: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 51, but without a
corresponding object release within this function.
drivers/gpu/drm/msm/adreno/a5xx_gpu.c:118:1-7: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 51, but without a
corresponding object release within this function.
Signed-off-by: Wen Yang
Cc: Rob Clark
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: Jordan Crouse
Cc: Mamta Shukla
Cc: Thomas Zimmermann
Cc: Sharat Masetty
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org (open list)
Reviewed-by: Jordan Crouse
Signed-off-by: Rob Clark
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index d5f5e56422f57..270da14cba673 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -34,7 +34,7 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu, const
char *fwname)
{
struct device *dev = >pdev->dev;
const struct firmware *fw;
- struct device_node *np;
+ struct device_node *np, *mem_np;
struct resource r;
phys_addr_t mem_phys;
ssize_t mem_size;
@@ -48,11 +48,13 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu, const
char *fwname)
if (!np)
return -ENODEV;
- np = of_parse_phandle(np, "memory-region", 0);
- if (!np)
+ mem_np = of_parse_phandle(np, "memory-region", 0);
+ of_node_put(np);
+ if (!mem_np)
return -EINVAL;
- ret = of_address_to_resource(np, 0, );
+ ret = of_address_to_resource(mem_np, 0, );
+ of_node_put(mem_np);
if (ret)
return ret;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv6 0/4] omapdrm: DSI command mode panel support
* Tony Lindgren [190529 08:11]:
> * Tomi Valkeinen [190529 07:06]:
> > On 28/05/2019 13:18, Tony Lindgren wrote:
> >
> > > > My board is x15 rev A3, attached to AM5 EVM. I've also attached my
> > > > kernel
> > > > config.
> > >
> > > Strange that this is not affecting other x15? I think timer12 would
> > > be blocked on HS devices though?
> >
> > Seems that the kernel config affects. omap2plus_defconfig boots ok.
>
> OK, this line in your oops:
>
> Unable to handle kernel paging request at virtual address 5a5a5a5a
>
> Probably means we hit some slab poison with DEBUG_SLAB set.
> Looks like your config boots fine with DEBUG_SLAB disabled
> for me.
>
> As this only happens for timer12, I wonder if we're again
> hitting some uncompress issue with corrupted dtb. Changing
> u-boot ftdaddr higher up might possibly make it go away.
> Or else there's a bug elsewhere :)
Oh but CM_WKUPAON_TIMER12_CLKCTRL has no CLKSEL option unlike
CM_WKUPAON_TIMER1_CLKCTRL. Below is one part of the fix, but
it seems like we're missing handling somewhere as trying to
get a non-existing clock should just produce -ENODEV type error.
And the clksel should be just handled with assigned-clocks
in general, but I think we still need it there until we
have drivers/clocksource/ timer drivers updated to boot
using early_platform_device.
Regards,
Tony
8< ---
diff --git a/arch/arm/boot/dts/dra7-l4.dtsi b/arch/arm/boot/dts/dra7-l4.dtsi
--- a/arch/arm/boot/dts/dra7-l4.dtsi
+++ b/arch/arm/boot/dts/dra7-l4.dtsi
@@ -4450,8 +4450,6 @@
timer12: timer@0 {
compatible = "ti,omap5430-timer";
reg = <0x0 0x80>;
- clocks = <_clkctrl
DRA7_WKUPAON_TIMER12_CLKCTRL 24>;
- clock-names = "fck";
interrupts = ;
ti,timer-alwon;
ti,timer-secure;
[Bug 110795] Unable to install on latest Ubuntu (19.04)
https://bugs.freedesktop.org/show_bug.cgi?id=110795 --- Comment #3 from Rolf --- If anyone else finds themselves in this fix by installing this driver, the only way to get apt-get working again is to forcefully remove all of the files using: sudo dpkg --force-all -P [package name] Here is the list of miss-installed packages: The following packages have unmet dependencies: amdgpu-dkms : Depends: amdgpu-core but it is not going to be installed amdgpu-lib : Depends: amdgpu-core (= 19.10-785425) but it is not going to be installed glamor-amdgpu : Depends: amdgpu-core but it is not going to be installed gst-omx-amdgpu : Depends: amdgpu-core but it is not going to be installed libdrm-amdgpu-common : Depends: amdgpu-core but it is not going to be installed libdrm2-amdgpu:i386 : Depends: amdgpu-core:i386 libdrm2-amdgpu : Depends: amdgpu-core but it is not going to be installed libegl1-amdgpu-mesa:i386 : Depends: amdgpu-core:i386 libegl1-amdgpu-mesa : Depends: amdgpu-core but it is not going to be installed libgbm1-amdgpu:i386 : Depends: amdgpu-core:i386 libgbm1-amdgpu : Depends: amdgpu-core but it is not going to be installed libgl1-amdgpu-mesa-dri:i386 : Depends: amdgpu-core:i386 Recommends: libtxc-dxtn-s2tc0:i386 but it is not installable or libtxc-dxtn0:i386 but it is not installable libgl1-amdgpu-mesa-dri : Depends: amdgpu-core but it is not going to be installed Recommends: libtxc-dxtn-s2tc0 but it is not installable or libtxc-dxtn0 but it is not installable libglapi-amdgpu-mesa:i386 : Depends: amdgpu-core:i386 libglapi-amdgpu-mesa : Depends: amdgpu-core but it is not going to be installed libllvm7.1-amdgpu:i386 : Depends: amdgpu-core:i386 libllvm7.1-amdgpu : Depends: amdgpu-core but it is not going to be installed libwayland-amdgpu-client0:i386 : Depends: amdgpu-core:i386 libwayland-amdgpu-client0 : Depends: amdgpu-core but it is not going to be installed libwayland-amdgpu-egl1:i386 : Depends: amdgpu-core:i386 libwayland-amdgpu-egl1 : Depends: amdgpu-core but it is not going to be installed libwayland-amdgpu-server0:i386 : Depends: amdgpu-core:i386 libwayland-amdgpu-server0 : Depends: amdgpu-core but it is not going to be installed mesa-amdgpu-va-drivers:i386 : Depends: amdgpu-core:i386 mesa-amdgpu-va-drivers : Depends: amdgpu-core but it is not going to be installed mesa-amdgpu-vdpau-drivers:i386 : Depends: amdgpu-core:i386 mesa-amdgpu-vdpau-drivers : Depends: amdgpu-core but it is not going to be installed xserver-xorg-amdgpu-video-amdgpu : Depends: amdgpu-core but it is not going to be installed -- 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 110795] Unable to install on latest Ubuntu (19.04)
https://bugs.freedesktop.org/show_bug.cgi?id=110795 --- Comment #4 from Alex Deucher --- The packaged drivers only support the Linux distros listed. -- 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 215/346] drm/pl111: fix possible object reference leak
[ Upstream commit bc29d3a69d4c1bd1a103e8b3c1ed81b807c1870b ]
The call to of_find_matching_node_and_match returns a node pointer with
refcount incremented thus it must be explicitly decremented after the
last usage.
Detected by coccinelle with the following warnings:
drivers/gpu/drm/pl111/pl111_versatile.c:333:3-9: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 317, but without a
corresponding object release within this function.
drivers/gpu/drm/pl111/pl111_versatile.c:340:3-9: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 317, but without a
corresponding object release within this function.
drivers/gpu/drm/pl111/pl111_versatile.c:346:3-9: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 317, but without a
corresponding object release within this function.
drivers/gpu/drm/pl111/pl111_versatile.c:354:2-8: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 317, but without a
corresponding object release within this function.
drivers/gpu/drm/pl111/pl111_versatile.c:395:3-9: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 317, but without a
corresponding object release within this function.
drivers/gpu/drm/pl111/pl111_versatile.c:402:1-7: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 317, but without a
corresponding object release within this function.
Signed-off-by: Wen Yang
Cc: Eric Anholt (supporter:DRM DRIVER FOR ARM PL111 CLCD)
Cc: David Airlie (maintainer:DRM DRIVERS)
Cc: Daniel Vetter (maintainer:DRM DRIVERS)
Cc: dri-devel@lists.freedesktop.org (open list:DRM DRIVERS)
Cc: linux-ker...@vger.kernel.org (open list)
Signed-off-by: Eric Anholt
Link:
https://patchwork.freedesktop.org/patch/msgid/1554307455-40361-6-git-send-email-wen.yan...@zte.com.cn
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/pl111/pl111_versatile.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/pl111/pl111_versatile.c
b/drivers/gpu/drm/pl111/pl111_versatile.c
index b9baefdba38a1..1c318ad32a8cd 100644
--- a/drivers/gpu/drm/pl111/pl111_versatile.c
+++ b/drivers/gpu/drm/pl111/pl111_versatile.c
@@ -330,6 +330,7 @@ int pl111_versatile_init(struct device *dev, struct
pl111_drm_dev_private *priv)
ret = vexpress_muxfpga_init();
if (ret) {
dev_err(dev, "unable to initialize muxfpga driver\n");
+ of_node_put(np);
return ret;
}
@@ -337,17 +338,20 @@ int pl111_versatile_init(struct device *dev, struct
pl111_drm_dev_private *priv)
pdev = of_find_device_by_node(np);
if (!pdev) {
dev_err(dev, "can't find the sysreg device,
deferring\n");
+ of_node_put(np);
return -EPROBE_DEFER;
}
map = dev_get_drvdata(>dev);
if (!map) {
dev_err(dev, "sysreg has not yet probed\n");
platform_device_put(pdev);
+ of_node_put(np);
return -EPROBE_DEFER;
}
} else {
map = syscon_node_to_regmap(np);
}
+ of_node_put(np);
if (IS_ERR(map)) {
dev_err(dev, "no Versatile syscon regmap\n");
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110795] Unable to install on latest Ubuntu (19.04)
https://bugs.freedesktop.org/show_bug.cgi?id=110795 --- Comment #5 from Rolf --- Yet it half-way installs on 19.04 without a check, and your download page does not include any warning of what it will do to your system if it's not 18.04. In fact, the sub heading lists 18.04.2, so is that the only version of 18.04 supported? >From the specificity used, it's reasonable to assume that the listed version was a minimum version, not an exclusive 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
Re: [PATCH v2 3/4] drm: mediatek: call drm_atomic_helper_shutdown() when unbinding driver
Hi, Hsin-Yi:
On Wed, 2019-05-29 at 18:25 +0800, Hsin-Yi Wang wrote:
> shutdown all CRTC when unbinding drm driver.
>
Reviewed-by: CK Hu
> Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
> Signed-off-by: Hsin-Yi Wang
> ---
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index e7362bdafa82..8718d123ccaa 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -311,6 +311,7 @@ static int mtk_drm_kms_init(struct drm_device *drm)
> static void mtk_drm_kms_deinit(struct drm_device *drm)
> {
> drm_kms_helper_poll_fini(drm);
> + drm_atomic_helper_shutdown(drm);
>
> component_unbind_all(drm->dev, drm);
> drm_mode_config_cleanup(drm);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] gpu/drm: mediatek: call mtk_dsi_stop() after mtk_drm_crtc_atomic_disable()
On Tue, May 28, 2019 at 4:53 PM CK Hu wrote: > I think we've already discussed in [1]. I need a reason to understand > this is hardware behavior or software bug. If this is a software bug, we > need to fix the bug and code could be symmetric. > > [1] > http://lists.infradead.org/pipermail/linux-mediatek/2019-March/018423.html > Hi CK, Jitao has replied in v2[1] " mtk_dsi_start must after dsi full setting. If you put it in mtk_dsi_ddp_start, mtk_dsi_set_mode won't work. DSI will keep cmd mode. So you see no irq. ... " [1] https://lore.kernel.org/patchwork/patch/1052505/#1276270 Thanks
[PATCH 4.19 140/276] drm/msm: a5xx: fix possible object reference leak
[ Upstream commit 6cd5235c3135ea84b32469ea51b2aae384eda8af ]
The call to of_get_child_by_name returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
drivers/gpu/drm/msm/adreno/a5xx_gpu.c:57:2-8: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 47, but without a
corresponding object release within this function.
drivers/gpu/drm/msm/adreno/a5xx_gpu.c:66:2-8: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 47, but without a
corresponding object release within this function.
drivers/gpu/drm/msm/adreno/a5xx_gpu.c:118:1-7: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 47, but without a
corresponding object release within this function.
drivers/gpu/drm/msm/adreno/a5xx_gpu.c:57:2-8: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 51, but without a
corresponding object release within this function.
drivers/gpu/drm/msm/adreno/a5xx_gpu.c:66:2-8: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 51, but without a
corresponding object release within this function.
drivers/gpu/drm/msm/adreno/a5xx_gpu.c:118:1-7: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 51, but without a
corresponding object release within this function.
Signed-off-by: Wen Yang
Cc: Rob Clark
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: Jordan Crouse
Cc: Mamta Shukla
Cc: Thomas Zimmermann
Cc: Sharat Masetty
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org (open list)
Reviewed-by: Jordan Crouse
Signed-off-by: Rob Clark
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index ab1d9308c3114..ba6f3c14495c0 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -35,7 +35,7 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu, const
char *fwname)
{
struct device *dev = >pdev->dev;
const struct firmware *fw;
- struct device_node *np;
+ struct device_node *np, *mem_np;
struct resource r;
phys_addr_t mem_phys;
ssize_t mem_size;
@@ -49,11 +49,13 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu, const
char *fwname)
if (!np)
return -ENODEV;
- np = of_parse_phandle(np, "memory-region", 0);
- if (!np)
+ mem_np = of_parse_phandle(np, "memory-region", 0);
+ of_node_put(np);
+ if (!mem_np)
return -EINVAL;
- ret = of_address_to_resource(np, 0, );
+ ret = of_address_to_resource(mem_np, 0, );
+ of_node_put(mem_np);
if (ret)
return ret;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4.19 185/276] drm/pl111: fix possible object reference leak
[ Upstream commit bc29d3a69d4c1bd1a103e8b3c1ed81b807c1870b ]
The call to of_find_matching_node_and_match returns a node pointer with
refcount incremented thus it must be explicitly decremented after the
last usage.
Detected by coccinelle with the following warnings:
drivers/gpu/drm/pl111/pl111_versatile.c:333:3-9: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 317, but without a
corresponding object release within this function.
drivers/gpu/drm/pl111/pl111_versatile.c:340:3-9: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 317, but without a
corresponding object release within this function.
drivers/gpu/drm/pl111/pl111_versatile.c:346:3-9: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 317, but without a
corresponding object release within this function.
drivers/gpu/drm/pl111/pl111_versatile.c:354:2-8: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 317, but without a
corresponding object release within this function.
drivers/gpu/drm/pl111/pl111_versatile.c:395:3-9: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 317, but without a
corresponding object release within this function.
drivers/gpu/drm/pl111/pl111_versatile.c:402:1-7: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 317, but without a
corresponding object release within this function.
Signed-off-by: Wen Yang
Cc: Eric Anholt (supporter:DRM DRIVER FOR ARM PL111 CLCD)
Cc: David Airlie (maintainer:DRM DRIVERS)
Cc: Daniel Vetter (maintainer:DRM DRIVERS)
Cc: dri-devel@lists.freedesktop.org (open list:DRM DRIVERS)
Cc: linux-ker...@vger.kernel.org (open list)
Signed-off-by: Eric Anholt
Link:
https://patchwork.freedesktop.org/patch/msgid/1554307455-40361-6-git-send-email-wen.yan...@zte.com.cn
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/pl111/pl111_versatile.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/pl111/pl111_versatile.c
b/drivers/gpu/drm/pl111/pl111_versatile.c
index b9baefdba38a1..1c318ad32a8cd 100644
--- a/drivers/gpu/drm/pl111/pl111_versatile.c
+++ b/drivers/gpu/drm/pl111/pl111_versatile.c
@@ -330,6 +330,7 @@ int pl111_versatile_init(struct device *dev, struct
pl111_drm_dev_private *priv)
ret = vexpress_muxfpga_init();
if (ret) {
dev_err(dev, "unable to initialize muxfpga driver\n");
+ of_node_put(np);
return ret;
}
@@ -337,17 +338,20 @@ int pl111_versatile_init(struct device *dev, struct
pl111_drm_dev_private *priv)
pdev = of_find_device_by_node(np);
if (!pdev) {
dev_err(dev, "can't find the sysreg device,
deferring\n");
+ of_node_put(np);
return -EPROBE_DEFER;
}
map = dev_get_drvdata(>dev);
if (!map) {
dev_err(dev, "sysreg has not yet probed\n");
platform_device_put(pdev);
+ of_node_put(np);
return -EPROBE_DEFER;
}
} else {
map = syscon_node_to_regmap(np);
}
+ of_node_put(np);
if (IS_ERR(map)) {
dev_err(dev, "no Versatile syscon regmap\n");
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4.14 103/193] drm/msm: a5xx: fix possible object reference leak
[ Upstream commit 6cd5235c3135ea84b32469ea51b2aae384eda8af ]
The call to of_get_child_by_name returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
drivers/gpu/drm/msm/adreno/a5xx_gpu.c:57:2-8: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 47, but without a
corresponding object release within this function.
drivers/gpu/drm/msm/adreno/a5xx_gpu.c:66:2-8: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 47, but without a
corresponding object release within this function.
drivers/gpu/drm/msm/adreno/a5xx_gpu.c:118:1-7: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 47, but without a
corresponding object release within this function.
drivers/gpu/drm/msm/adreno/a5xx_gpu.c:57:2-8: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 51, but without a
corresponding object release within this function.
drivers/gpu/drm/msm/adreno/a5xx_gpu.c:66:2-8: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 51, but without a
corresponding object release within this function.
drivers/gpu/drm/msm/adreno/a5xx_gpu.c:118:1-7: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 51, but without a
corresponding object release within this function.
Signed-off-by: Wen Yang
Cc: Rob Clark
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: Jordan Crouse
Cc: Mamta Shukla
Cc: Thomas Zimmermann
Cc: Sharat Masetty
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org (open list)
Reviewed-by: Jordan Crouse
Signed-off-by: Rob Clark
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 17c59d839e6fa..f1aaa76cc2e4e 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -29,7 +29,7 @@ static void a5xx_dump(struct msm_gpu *gpu);
static int zap_shader_load_mdt(struct device *dev, const char *fwname)
{
const struct firmware *fw;
- struct device_node *np;
+ struct device_node *np, *mem_np;
struct resource r;
phys_addr_t mem_phys;
ssize_t mem_size;
@@ -43,11 +43,13 @@ static int zap_shader_load_mdt(struct device *dev, const
char *fwname)
if (!np)
return -ENODEV;
- np = of_parse_phandle(np, "memory-region", 0);
- if (!np)
+ mem_np = of_parse_phandle(np, "memory-region", 0);
+ of_node_put(np);
+ if (!mem_np)
return -EINVAL;
- ret = of_address_to_resource(np, 0, );
+ ret = of_address_to_resource(mem_np, 0, );
+ of_node_put(mem_np);
if (ret)
return ret;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/4] drm: mediatek: fix unbind functions
Hi, Hsin-Yi:
On Wed, 2019-05-29 at 18:25 +0800, Hsin-Yi Wang wrote:
> detatch panel in mtk_dsi_destroy_conn_enc(), since .bind will try to
> attach it again.
>
Reviewed-by: CK Hu
> Fixes: 2e54c14e310f ("drm/mediatek: Add DSI sub driver")
> Signed-off-by: Hsin-Yi Wang
> ---
> change log v1->v2:
> * mipi_dsi_host_unregister() should be fixed in another patch on the list.
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index b00eb2d2e086..1ae3be99e0ff 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -844,6 +844,8 @@ static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi)
> /* Skip connector cleanup if creation was delegated to the bridge */
> if (dsi->conn.dev)
> drm_connector_cleanup(>conn);
> + if (dsi->panel)
> + drm_panel_detach(dsi->panel);
> }
>
> static void mtk_dsi_ddp_start(struct mtk_ddp_comp *comp)
[PATCH 5.0 158/346] drm/msm: a5xx: fix possible object reference leak
[ Upstream commit 6cd5235c3135ea84b32469ea51b2aae384eda8af ]
The call to of_get_child_by_name returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
drivers/gpu/drm/msm/adreno/a5xx_gpu.c:57:2-8: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 47, but without a
corresponding object release within this function.
drivers/gpu/drm/msm/adreno/a5xx_gpu.c:66:2-8: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 47, but without a
corresponding object release within this function.
drivers/gpu/drm/msm/adreno/a5xx_gpu.c:118:1-7: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 47, but without a
corresponding object release within this function.
drivers/gpu/drm/msm/adreno/a5xx_gpu.c:57:2-8: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 51, but without a
corresponding object release within this function.
drivers/gpu/drm/msm/adreno/a5xx_gpu.c:66:2-8: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 51, but without a
corresponding object release within this function.
drivers/gpu/drm/msm/adreno/a5xx_gpu.c:118:1-7: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 51, but without a
corresponding object release within this function.
Signed-off-by: Wen Yang
Cc: Rob Clark
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: Jordan Crouse
Cc: Mamta Shukla
Cc: Thomas Zimmermann
Cc: Sharat Masetty
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org (open list)
Reviewed-by: Jordan Crouse
Signed-off-by: Rob Clark
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index d5f5e56422f57..270da14cba673 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -34,7 +34,7 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu, const
char *fwname)
{
struct device *dev = >pdev->dev;
const struct firmware *fw;
- struct device_node *np;
+ struct device_node *np, *mem_np;
struct resource r;
phys_addr_t mem_phys;
ssize_t mem_size;
@@ -48,11 +48,13 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu, const
char *fwname)
if (!np)
return -ENODEV;
- np = of_parse_phandle(np, "memory-region", 0);
- if (!np)
+ mem_np = of_parse_phandle(np, "memory-region", 0);
+ of_node_put(np);
+ if (!mem_np)
return -EINVAL;
- ret = of_address_to_resource(np, 0, );
+ ret = of_address_to_resource(mem_np, 0, );
+ of_node_put(mem_np);
if (ret)
return ret;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110787] Glitches in console of the Julia language plugin for Atom (Juno)
https://bugs.freedesktop.org/show_bug.cgi?id=110787 --- Comment #2 from Pierre-Eric Pelloux-Prayer --- Thanks for your bug report. It seems to be the same bug than https://bugs.freedesktop.org/show_bug.cgi?id=110721 Should be fixed on master - can you try it? -- 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 110790] AMD GPU Pro-specific DRM issues
https://bugs.freedesktop.org/show_bug.cgi?id=110790 Andre Klapper changed: What|Removed |Added Group||spam Version|DRI git |unspecified Component|DRM/AMDgpu-pro |Two Product|DRI |Spam --- Comment #2 from Andre Klapper --- Go away and test somewhere else. -- 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 110781] Radeon: heavy r300 performance drop regression between 11.x and 19.x
https://bugs.freedesktop.org/show_bug.cgi?id=110781 --- Comment #4 from Richard Thier --- Btw what is a "slab buffer" or "slab"? It bugs me and I see this everywhere in the code too... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/ioctl: Ditch DRM_UNLOCKED except for the legacy vblank ioctl
This completes Emil's series of removing DRM_UNLOCKED from modern
drivers. It's entirely cargo-culted since we ignore it on
non-DRIVER_LEGACY drivers since:
commit ea487835e8876abf7ad909636e308c801a2bcda6
Author: Daniel Vetter
Date: Mon Sep 28 21:42:40 2015 +0200
drm: Enforce unlocked ioctl operation for kms driver ioctls
Now justifying why we can do this for legacy drives too (and hence
close the source of all the bogus copypasting) is a bit more involved.
DRM_UNLOCKED was introduced in:
commit ed8b67040965e4fe695db333d5914e18ea5f146f
Author: Arnd Bergmann
Date: Wed Dec 16 22:17:09 2009 +
drm: convert drm_ioctl to unlocked_ioctl
As a immediate hack to keep i810 happy, which would have deadlocked
without this trickery. The old BKL is automatically dropped in
schedule(), and hence the i810 vs. mmap_sem deadlock didn't actually
cause a real deadlock. But with a mutex it would. The solution was to
annotate these as DRM_UNLOCKED and mark i810 unsafe on SMP machines.
This conversion caused a regression, because unlike the BKL a mutex
isn't dropped over schedule (that thing again), which caused a vblank
wait in one thread to block the entire desktop and all its apps. Back
then we did vblank scheduling by blocking in the client, awesome isn't
it. This was fixed quickly in (ok not so quickly, took 2 years):
commit 8f4ff2b06afcd6f151868474a432c603057eaf56
Author: Ilija Hadzic
Date: Mon Oct 31 17:46:18 2011 -0400
drm: do not sleep on vblank while holding a mutex
All the other DRM_UNLOCKED annotations for all the core ioctls was
work to reach finer-grained locking for modern drivers. This took
years, and culminated in:
commit fdd5b877e9ebc2029e1373b4a3cd057329a9ab7a
Author: Daniel Vetter
Date: Sat Dec 10 22:52:54 2016 +0100
drm: Enforce BKL-less ioctls for modern drivers
DRM_UNLOCKED was never required by any legacy drivers, except for the
vblank_wait IOCTL. Therefore we will not regress these old drivers by
going back to where we've been in 2011. For all modern drivers nothing
will change.
To make this perfectly clear, also add a comment to DRM_UNLOCKED.
Cc: Emil Velikov
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_ioctl.c | 139 ++--
include/drm/drm_ioctl.h | 3 +
2 files changed, 72 insertions(+), 70 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index a1eb422a5711..365d7a5629f6 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -570,24 +570,23 @@ EXPORT_SYMBOL(drm_ioctl_permit);
/* Ioctl table */
static const struct drm_ioctl_desc drm_ioctls[] = {
- DRM_IOCTL_DEF(DRM_IOCTL_VERSION, drm_version,
- DRM_UNLOCKED|DRM_RENDER_ALLOW),
- DRM_IOCTL_DEF(DRM_IOCTL_GET_UNIQUE, drm_getunique, DRM_UNLOCKED),
- DRM_IOCTL_DEF(DRM_IOCTL_GET_MAGIC, drm_getmagic, DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_VERSION, drm_version, DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_GET_UNIQUE, drm_getunique, 0),
+ DRM_IOCTL_DEF(DRM_IOCTL_GET_MAGIC, drm_getmagic, 0),
DRM_IOCTL_DEF(DRM_IOCTL_IRQ_BUSID, drm_irq_by_busid,
DRM_MASTER|DRM_ROOT_ONLY),
- DRM_LEGACY_IOCTL_DEF(DRM_IOCTL_GET_MAP, drm_legacy_getmap_ioctl,
DRM_UNLOCKED),
+ DRM_LEGACY_IOCTL_DEF(DRM_IOCTL_GET_MAP, drm_legacy_getmap_ioctl, 0),
- DRM_IOCTL_DEF(DRM_IOCTL_GET_CLIENT, drm_getclient, DRM_UNLOCKED),
- DRM_IOCTL_DEF(DRM_IOCTL_GET_STATS, drm_getstats, DRM_UNLOCKED),
- DRM_IOCTL_DEF(DRM_IOCTL_GET_CAP, drm_getcap,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
- DRM_IOCTL_DEF(DRM_IOCTL_SET_CLIENT_CAP, drm_setclientcap, DRM_UNLOCKED),
- DRM_IOCTL_DEF(DRM_IOCTL_SET_VERSION, drm_setversion, DRM_UNLOCKED |
DRM_MASTER),
+ DRM_IOCTL_DEF(DRM_IOCTL_GET_CLIENT, drm_getclient, 0),
+ DRM_IOCTL_DEF(DRM_IOCTL_GET_STATS, drm_getstats, 0),
+ DRM_IOCTL_DEF(DRM_IOCTL_GET_CAP, drm_getcap, DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_SET_CLIENT_CAP, drm_setclientcap, 0),
+ DRM_IOCTL_DEF(DRM_IOCTL_SET_VERSION, drm_setversion, DRM_MASTER),
DRM_IOCTL_DEF(DRM_IOCTL_SET_UNIQUE, drm_invalid_op,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF(DRM_IOCTL_BLOCK, drm_noop,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF(DRM_IOCTL_UNBLOCK, drm_noop,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
- DRM_IOCTL_DEF(DRM_IOCTL_AUTH_MAGIC, drm_authmagic,
DRM_UNLOCKED|DRM_MASTER),
+ DRM_IOCTL_DEF(DRM_IOCTL_AUTH_MAGIC, drm_authmagic, DRM_MASTER),
DRM_LEGACY_IOCTL_DEF(DRM_IOCTL_ADD_MAP, drm_legacy_addmap_ioctl,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_LEGACY_IOCTL_DEF(DRM_IOCTL_RM_MAP, drm_legacy_rmmap_ioctl,
DRM_AUTH),
@@ -595,8 +594,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_LEGACY_IOCTL_DEF(DRM_IOCTL_SET_SAREA_CTX, drm_legacy_setsareactx,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_LEGACY_IOCTL_DEF(DRM_IOCTL_GET_SAREA_CTX, drm_legacy_getsareactx,
Re: [PATCH RFC v2 0/6] ARM: qcom: initial Nexus 5 display support
On Wed, May 29, 2019 at 08:23:17AM +0200, Linus Walleij wrote: > On Wed, May 29, 2019 at 3:17 AM Brian Masney wrote: > > > It's in low speed mode but its usable. > > How low speed is that? I don't have a number but my test with 4.17 is to run 'cat /etc/passwd > /dev/tty1' over a serial cable. The first 2-3 calls will fill up the screen and the file contents appear to show up on the screen immediately to the human eye. The next time that I run it requires scrolling the entire console and there is a small fraction of a second where I see the entire framebuffer contents scroll up. I don't have a graphics background, but I believe that this is the tearing effect that I'm seeing based on what I've read. I believe that disp-te-gpios can be used to mitigate this tearing effect. I have a few questions about this later once we get the basic display working. > > I assume that it's related to the > > vblank events not working properly? > > They are only waiting for 50 ms before timing out, I raised it > to 100ms in the -next kernel. I'm still suspicious about this > even though I think you said this was not the problem. > > For a command mode panel in LP mode it will nevertheless > be more than 100ms for sure, the update is visible to the > naked eye. > > Raise it to 1 ms or something and see what happens. > drivers/gpu/drm/drm_atomic_helper.c: > msecs_to_jiffies(50) I previously raised those timeouts as high as 5 seconds and it still has the same issue. Writing to /dev/tty1 can take anywhere between a few seconds to 30 seconds or more. Brian
Re: [PATCH 3/3] drm: mediatek: unbind components in mtk_drm_unbind()
Hi, Hsin-Yi:
On Mon, 2019-05-27 at 12:50 +0800, Hsin-Yi Wang wrote:
> Unbinding components (i.e. mtk_dsi and mtk_disp_ovl/rdma/color) will
> trigger master(mtk_drm)'s .unbind(), and currently mtk_drm's unbind
> won't actually unbind components. During the next bind,
> mtk_drm_kms_init() is called, and the components are added back.
>
> .unbind() should call mtk_drm_kms_deinit() to unbind components.
>
> And since component_master_del() in .remove() will trigger .unbind(),
> which will also unregister device, it's fine to remove original functions
> called here.
>
> Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
> Signed-off-by: Hsin-Yi Wang
> ---
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 57ce4708ef1b..bbfe3a464aea 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -311,6 +311,7 @@ static int mtk_drm_kms_init(struct drm_device *drm)
> static void mtk_drm_kms_deinit(struct drm_device *drm)
> {
> drm_kms_helper_poll_fini(drm);
> + drm_atomic_helper_shutdown(drm);
This looks not related to this patch. This patch is related to the
unbind timing. You could separate this to an independent patch.
>
> component_unbind_all(drm->dev, drm);
> drm_mode_config_cleanup(drm);
> @@ -397,7 +398,9 @@ static void mtk_drm_unbind(struct device *dev)
> struct mtk_drm_private *private = dev_get_drvdata(dev);
>
> drm_dev_unregister(private->drm);
> + mtk_drm_kms_deinit(private->drm);
> drm_dev_put(private->drm);
> + private->num_pipes = 0;
This looks not related to this patch. This patch is related to the
unbind timing. You could separate this to an independent patch.
Regards,
CK
> private->drm = NULL;
> }
>
> @@ -568,13 +571,8 @@ static int mtk_drm_probe(struct platform_device *pdev)
> static int mtk_drm_remove(struct platform_device *pdev)
> {
> struct mtk_drm_private *private = platform_get_drvdata(pdev);
> - struct drm_device *drm = private->drm;
> int i;
>
> - drm_dev_unregister(drm);
> - mtk_drm_kms_deinit(drm);
> - drm_dev_put(drm);
> -
> component_master_del(>dev, _drm_ops);
> pm_runtime_disable(>dev);
> of_node_put(private->mutex_node);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 3/6] drm/scheduler: rework job destruction
On Thu, Apr 18, 2019 at 5:00 PM Andrey Grodzovsky
wrote:
>
> From: Christian König
>
> We now destroy finished jobs from the worker thread to make sure that
> we never destroy a job currently in timeout processing.
> By this we avoid holding lock around ring mirror list in drm_sched_stop
> which should solve a deadlock reported by a user.
>
> v2: Remove unused variable.
> v4: Move guilty job free into sched code.
> v5:
> Move sched->hw_rq_count to drm_sched_start to account for counter
> decrement in drm_sched_stop even when we don't call resubmit jobs
> if guily job did signal.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109692
>
> Signed-off-by: Christian König
> Signed-off-by: Andrey Grodzovsky
$ make htmldocs
./drivers/gpu/drm/scheduler/sched_main.c:365: warning: Function
parameter or member 'bad' not described in 'drm_sched_stop'
Please fix, thanks.
-Daniel
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 9 +-
> drivers/gpu/drm/etnaviv/etnaviv_dump.c | 4 -
> drivers/gpu/drm/etnaviv/etnaviv_sched.c| 2 +-
> drivers/gpu/drm/lima/lima_sched.c | 2 +-
> drivers/gpu/drm/panfrost/panfrost_job.c| 2 +-
> drivers/gpu/drm/scheduler/sched_main.c | 159
> +
> drivers/gpu/drm/v3d/v3d_sched.c| 2 +-
> include/drm/gpu_scheduler.h| 6 +-
> 8 files changed, 102 insertions(+), 84 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 7cee269..a0e165c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -3334,7 +3334,7 @@ static int amdgpu_device_pre_asic_reset(struct
> amdgpu_device *adev,
> if (!ring || !ring->sched.thread)
> continue;
>
> - drm_sched_stop(>sched);
> + drm_sched_stop(>sched, >base);
>
> /* after all hw jobs are reset, hw fence is meaningless, so
> force_completion */
> amdgpu_fence_driver_force_completion(ring);
> @@ -3343,8 +3343,6 @@ static int amdgpu_device_pre_asic_reset(struct
> amdgpu_device *adev,
> if(job)
> drm_sched_increase_karma(>base);
>
> -
> -
> if (!amdgpu_sriov_vf(adev)) {
>
> if (!need_full_reset)
> @@ -3482,8 +3480,7 @@ static int amdgpu_do_asic_reset(struct amdgpu_hive_info
> *hive,
> return r;
> }
>
> -static void amdgpu_device_post_asic_reset(struct amdgpu_device *adev,
> - struct amdgpu_job *job)
> +static void amdgpu_device_post_asic_reset(struct amdgpu_device *adev)
> {
> int i;
>
> @@ -3623,7 +3620,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device
> *adev,
>
> /* Post ASIC reset for all devs .*/
> list_for_each_entry(tmp_adev, device_list_handle, gmc.xgmi.head) {
> - amdgpu_device_post_asic_reset(tmp_adev, tmp_adev == adev ?
> job : NULL);
> + amdgpu_device_post_asic_reset(tmp_adev);
>
> if (r) {
> /* bad news, how to tell it to userspace ? */
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_dump.c
> b/drivers/gpu/drm/etnaviv/etnaviv_dump.c
> index 33854c9..5778d9c 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_dump.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_dump.c
> @@ -135,13 +135,11 @@ void etnaviv_core_dump(struct etnaviv_gpu *gpu)
> mmu_size + gpu->buffer.size;
>
> /* Add in the active command buffers */
> - spin_lock_irqsave(>sched.job_list_lock, flags);
> list_for_each_entry(s_job, >sched.ring_mirror_list, node) {
> submit = to_etnaviv_submit(s_job);
> file_size += submit->cmdbuf.size;
> n_obj++;
> }
> - spin_unlock_irqrestore(>sched.job_list_lock, flags);
>
> /* Add in the active buffer objects */
> list_for_each_entry(vram, >mmu->mappings, mmu_node) {
> @@ -183,14 +181,12 @@ void etnaviv_core_dump(struct etnaviv_gpu *gpu)
> gpu->buffer.size,
> etnaviv_cmdbuf_get_va(>buffer));
>
> - spin_lock_irqsave(>sched.job_list_lock, flags);
> list_for_each_entry(s_job, >sched.ring_mirror_list, node) {
> submit = to_etnaviv_submit(s_job);
> etnaviv_core_dump_mem(, ETDUMP_BUF_CMD,
> submit->cmdbuf.vaddr,
> submit->cmdbuf.size,
> etnaviv_cmdbuf_get_va(>cmdbuf));
> }
> - spin_unlock_irqrestore(>sched.job_list_lock, flags);
>
> /* Reserve space for the bomap */
> if (n_bomap_pages) {
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> index 6d24fea..a813c82 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> +++
Re: DRM/AST regression (likely 4.14 -> 4.19+), providing EDID manually fails
On Wed, 29 May 2019, Ilpo Järvinen wrote: > On Tue, 28 May 2019, Jani Nikula wrote: > >> On Mon, 27 May 2019, Ashutosh Dixit wrote: >> > On Sun, 26 May 2019 12:50:51 -0700, Ilpo Järvinen wrote: >> >> >> >> Hi all, >> >> >> >> I've a workstation which has internal VGA that is detected as AST 2400 and >> >> with it EDID has been always quite flaky (except for some time it worked >> >> with 4.14 long enough that I thought the problems would be past until the >> >> problems reappeared also with 4.14). Thus, I've provided manually the EDID >> >> that I extracted from the monitor using other computer (the monitor itself >> >> worked just fine on the earlier computer so it is likely fine). >> >> >> >> I setup the manual EDID using drm_kms_helper.edid_firmware, however, >> >> after upgrading to 4.19.45 it stopped working (no "Got external EDID base >> >> block" appears in dmesg, the text mode is kept in the lower res mode, and >> >> Xorg logs no longer dumps the EDID info like it did with 4.14). So I guess >> >> the EDID I provided manually on the command line is not correctly put into >> >> use with 4.19+ kernels. >> >> >> >> The 4.19 dmesg indicated that drm_kms_helper.edid_firmware is deprecated >> >> so I also tested with drm.edid_firmware it suggested as the replacement >> >> but with no luck (but I believe also the drm_kms_helper one should have >> >> worked as it was only "deprecated"). >> >> >> >> I also tried 5.1.2 but it did not work any better (and with it also tried >> >> removing all the manual *.edid_firmware from the command line so I still >> >> need to provide one manually to have it reliable working it seems). >> > >> > I believe there is a bug already tracking this, here: >> > >> > https://bugs.freedesktop.org/show_bug.cgi?id=107583 >> >> Ilpo, does video=VGA-1:e command-line option work around the problem for >> you? > > Yes it does; together with the modeline stuff for Xorg (after reading the > referenced bug report I realized I can fix the X side with it). So I now > have the desired modes/resolutions in use. Thank you all! Great! It should be enough to just have the replacement firmware EDID for the modes, as long as you have an EDID that represents the capabilities of the display. The modelines for Xorg should not be needed. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/4] fix mediatek drm, dis, and disp-* unbind/bind
There are some errors when unbinding and rebinding mediatek drm, dsi, and disp-* drivers. This series is to fix those errors and warnings. Hsin-Yi Wang (4): drm: mediatek: fix unbind functions drm: mediatek: unbind components in mtk_drm_unbind() drm: mediatek: call drm_atomic_helper_shutdown() when unbinding driver drm: mediatek: clear num_pipes when unbind driver drivers/gpu/drm/mediatek/mtk_drm_drv.c | 8 +++- drivers/gpu/drm/mediatek/mtk_dsi.c | 2 ++ 2 files changed, 5 insertions(+), 5 deletions(-) -- 2.20.1
[PATCH v2 4/4] drm: mediatek: clear num_pipes when unbind driver
num_pipes is used for mutex created in mtk_drm_crtc_create(). If we
don't clear num_pipes count, when rebinding driver, the count will
be accumulated. From mtk_disp_mutex_get(), there can only be at most
10 mutex id. Clear this number so it starts from 0 in every rebind.
Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
Signed-off-by: Hsin-Yi Wang
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 8718d123ccaa..bbfe3a464aea 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -400,6 +400,7 @@ static void mtk_drm_unbind(struct device *dev)
drm_dev_unregister(private->drm);
mtk_drm_kms_deinit(private->drm);
drm_dev_put(private->drm);
+ private->num_pipes = 0;
private->drm = NULL;
}
--
2.20.1
[PATCH v2 2/4] drm: mediatek: unbind components in mtk_drm_unbind()
Unbinding components (i.e. mtk_dsi and mtk_disp_ovl/rdma/color) will
trigger master(mtk_drm)'s .unbind(), and currently mtk_drm's unbind
won't actually unbind components. During the next bind,
mtk_drm_kms_init() is called, and the components are added back.
.unbind() should call mtk_drm_kms_deinit() to unbind components.
And since component_master_del() in .remove() will trigger .unbind(),
which will also unregister device, it's fine to remove original functions
called here.
Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
Signed-off-by: Hsin-Yi Wang
---
change log v1->v2:
* separate another 2 fixes to other patches.
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 57ce4708ef1b..e7362bdafa82 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -397,6 +397,7 @@ static void mtk_drm_unbind(struct device *dev)
struct mtk_drm_private *private = dev_get_drvdata(dev);
drm_dev_unregister(private->drm);
+ mtk_drm_kms_deinit(private->drm);
drm_dev_put(private->drm);
private->drm = NULL;
}
@@ -568,13 +569,8 @@ static int mtk_drm_probe(struct platform_device *pdev)
static int mtk_drm_remove(struct platform_device *pdev)
{
struct mtk_drm_private *private = platform_get_drvdata(pdev);
- struct drm_device *drm = private->drm;
int i;
- drm_dev_unregister(drm);
- mtk_drm_kms_deinit(drm);
- drm_dev_put(drm);
-
component_master_del(>dev, _drm_ops);
pm_runtime_disable(>dev);
of_node_put(private->mutex_node);
--
2.20.1
[PATCH v2 3/4] drm: mediatek: call drm_atomic_helper_shutdown() when unbinding driver
shutdown all CRTC when unbinding drm driver.
Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
Signed-off-by: Hsin-Yi Wang
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index e7362bdafa82..8718d123ccaa 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -311,6 +311,7 @@ static int mtk_drm_kms_init(struct drm_device *drm)
static void mtk_drm_kms_deinit(struct drm_device *drm)
{
drm_kms_helper_poll_fini(drm);
+ drm_atomic_helper_shutdown(drm);
component_unbind_all(drm->dev, drm);
drm_mode_config_cleanup(drm);
--
2.20.1
[Bug 110790] AMD GPU Pro-specific DRM issues
https://bugs.freedesktop.org/show_bug.cgi?id=110790 Andre Klapper changed: What|Removed |Added Status|NEW |RESOLVED CC||a9016...@gmx.de Resolution|--- |INVALID --- Comment #1 from Andre Klapper --- vpra...@hotmail.com: Do not file empty tasks that do not help anybody. 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
[PATCH 1/2] mm: cma: export functions to get CMA base and size
Make them usable in modules. Some drivers want to know where their
device CMA area is located to make better decisions about the DMA
programming.
Signed-off-by: Lucas Stach
---
mm/cma.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/cma.c b/mm/cma.c
index 3340ef34c154..191c89bf038d 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -44,11 +44,13 @@ phys_addr_t cma_get_base(const struct cma *cma)
{
return PFN_PHYS(cma->base_pfn);
}
+EXPORT_SYMBOL_GPL(cma_get_base);
unsigned long cma_get_size(const struct cma *cma)
{
return cma->count << PAGE_SHIFT;
}
+EXPORT_SYMBOL_GPL(cma_get_size);
const char *cma_get_name(const struct cma *cma)
{
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/edid: Ignore "DFP 1.x" bit for EDID 1.2 and earlier
From: Ville Syrjälä
From VESA EDID implementation guide v1.0:
"For EDID version 1 revision 2 or earlier data structures when offset 14h
bit 7 is set to one, the value of bits 6-0 are undefined, and therefore
cannot be interpreted to mean anything."
And since EDID 1.4 redefines that bit let's consult it only for
EDID 1.3.
Cc: Mario Kleiner
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index dd601ed6a30e..c3296a72fff9 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4569,8 +4569,8 @@ u32 drm_add_display_info(struct drm_connector *connector,
const struct edid *edi
* tells us to assume 8 bpc color depth if the EDID doesn't have
* extensions which tell otherwise.
*/
- if ((info->bpc == 0) && (edid->revision < 4) &&
- (edid->input & DRM_EDID_DIGITAL_DFP_1_X)) {
+ if (info->bpc == 0 && edid->revision == 3 &&
+ edid->input & DRM_EDID_DIGITAL_DFP_1_X) {
info->bpc = 8;
DRM_DEBUG("%s: Assigning DFP sink color depth as %d bpc.\n",
connector->name, info->bpc);
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/edid: Clean up DRM_EDID_DIGITAL_* flags
From: Ville Syrjälä
Give the "DFP 1.x" bit a proper name, and clean up the rest
of the bits defines as well.
Cc: Mario Kleiner
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 2 +-
include/drm/drm_edid.h | 32 +---
2 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d87f574feeca..dd601ed6a30e 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4570,7 +4570,7 @@ u32 drm_add_display_info(struct drm_connector *connector,
const struct edid *edi
* extensions which tell otherwise.
*/
if ((info->bpc == 0) && (edid->revision < 4) &&
- (edid->input & DRM_EDID_DIGITAL_TYPE_DVI)) {
+ (edid->input & DRM_EDID_DIGITAL_DFP_1_X)) {
info->bpc = 8;
DRM_DEBUG("%s: Assigning DFP sink color depth as %d bpc.\n",
connector->name, info->bpc);
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 0e21e91c4314..88b63801f9db 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -177,21 +177,23 @@ struct detailed_timing {
#define DRM_EDID_INPUT_BLANK_TO_BLACK (1 << 4)
#define DRM_EDID_INPUT_VIDEO_LEVEL (3 << 5)
#define DRM_EDID_INPUT_DIGITAL (1 << 7)
-#define DRM_EDID_DIGITAL_DEPTH_MASK(7 << 4)
-#define DRM_EDID_DIGITAL_DEPTH_UNDEF (0 << 4)
-#define DRM_EDID_DIGITAL_DEPTH_6 (1 << 4)
-#define DRM_EDID_DIGITAL_DEPTH_8 (2 << 4)
-#define DRM_EDID_DIGITAL_DEPTH_10 (3 << 4)
-#define DRM_EDID_DIGITAL_DEPTH_12 (4 << 4)
-#define DRM_EDID_DIGITAL_DEPTH_14 (5 << 4)
-#define DRM_EDID_DIGITAL_DEPTH_16 (6 << 4)
-#define DRM_EDID_DIGITAL_DEPTH_RSVD(7 << 4)
-#define DRM_EDID_DIGITAL_TYPE_UNDEF(0)
-#define DRM_EDID_DIGITAL_TYPE_DVI (1)
-#define DRM_EDID_DIGITAL_TYPE_HDMI_A (2)
-#define DRM_EDID_DIGITAL_TYPE_HDMI_B (3)
-#define DRM_EDID_DIGITAL_TYPE_MDDI (4)
-#define DRM_EDID_DIGITAL_TYPE_DP (5)
+#define DRM_EDID_DIGITAL_DEPTH_MASK(7 << 4) /* 1.4 */
+#define DRM_EDID_DIGITAL_DEPTH_UNDEF (0 << 4) /* 1.4 */
+#define DRM_EDID_DIGITAL_DEPTH_6 (1 << 4) /* 1.4 */
+#define DRM_EDID_DIGITAL_DEPTH_8 (2 << 4) /* 1.4 */
+#define DRM_EDID_DIGITAL_DEPTH_10 (3 << 4) /* 1.4 */
+#define DRM_EDID_DIGITAL_DEPTH_12 (4 << 4) /* 1.4 */
+#define DRM_EDID_DIGITAL_DEPTH_14 (5 << 4) /* 1.4 */
+#define DRM_EDID_DIGITAL_DEPTH_16 (6 << 4) /* 1.4 */
+#define DRM_EDID_DIGITAL_DEPTH_RSVD(7 << 4) /* 1.4 */
+#define DRM_EDID_DIGITAL_TYPE_MASK (7 << 0) /* 1.4 */
+#define DRM_EDID_DIGITAL_TYPE_UNDEF(0 << 0) /* 1.4 */
+#define DRM_EDID_DIGITAL_TYPE_DVI (1 << 0) /* 1.4 */
+#define DRM_EDID_DIGITAL_TYPE_HDMI_A (2 << 0) /* 1.4 */
+#define DRM_EDID_DIGITAL_TYPE_HDMI_B (3 << 0) /* 1.4 */
+#define DRM_EDID_DIGITAL_TYPE_MDDI (4 << 0) /* 1.4 */
+#define DRM_EDID_DIGITAL_TYPE_DP (5 << 0) /* 1.4 */
+#define DRM_EDID_DIGITAL_DFP_1_X (1 << 0) /* 1.3 */
#define DRM_EDID_FEATURE_DEFAULT_GTF (1 << 0)
#define DRM_EDID_FEATURE_PREFERRED_TIMING (1 << 1)
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/powerplay: avoid possible buffer overflow
Make sure the clock level enforced is within the allowed
ranges in case PP_SCLK and PP_MCLK.
Signed-off-by: Young Xiao <92siuy...@gmail.com>
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
index 707cd4b..ae6cbe8 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
@@ -1836,6 +1836,12 @@ static int vega12_force_clock_level(struct pp_hwmgr
*hwmgr,
case PP_SCLK:
soft_min_level = mask ? (ffs(mask) - 1) : 0;
soft_max_level = mask ? (fls(mask) - 1) : 0;
+ if (soft_max_level >= data->dpm_table.gfx_table.count) {
+ pr_err("Clock level specified %d is over max allowed
%d\n",
+ soft_max_level,
+ data->dpm_table.gfx_table.count - 1);
+ return -EINVAL;
+ }
data->dpm_table.gfx_table.dpm_state.soft_min_level =
data->dpm_table.gfx_table.dpm_levels[soft_min_level].value;
@@ -1856,6 +1862,12 @@ static int vega12_force_clock_level(struct pp_hwmgr
*hwmgr,
case PP_MCLK:
soft_min_level = mask ? (ffs(mask) - 1) : 0;
soft_max_level = mask ? (fls(mask) - 1) : 0;
+ if (soft_max_level >= data->dpm_table.gfx_table.count) {
+ pr_err("Clock level specified %d is over max allowed
%d\n",
+ soft_max_level,
+ data->dpm_table.gfx_table.count - 1);
+ return -EINVAL;
+ }
data->dpm_table.mem_table.dpm_state.soft_min_level =
data->dpm_table.mem_table.dpm_levels[soft_min_level].value;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] drm/imx: fix frame rate regression on non-plus i.MX6Q
Hi Dave, Daniel,
please consider merging these fixes for v5.2.
regards
Philipp
The following changes since commit cd6c84d8f0cdc911df435bb075ba22ce3c605b07:
Linux 5.2-rc2 (2019-05-26 16:49:19 -0700)
are available in the Git repository at:
git://git.pengutronix.de/git/pza/linux tags/imx-drm-fixes-2019-05-29
for you to fetch changes up to 137caa702f2308f7ef03876e164b0d0f3300712a:
drm/imx: ipuv3-plane: fix atomic update status query for non-plus i.MX6Q
(2019-05-27 15:13:57 +0200)
drm/imx: ipuv3-plane: fix frame rate regression on non-plus i.MX6Q
Fix a regression introduced by 70e8a0c71e9 ("drm/imx: ipuv3-plane: add
function to query atomic update status") that halves the frame rate on
non-plus i.MX6Q, because the pending check always returns "pending"
even if an update is actually applied.
Philipp Zabel (1):
drm/imx: ipuv3-plane: fix atomic update status query for non-plus i.MX6Q
drivers/gpu/drm/imx/ipuv3-plane.c | 13 -
drivers/gpu/drm/imx/ipuv3-plane.h | 1 -
2 files changed, 8 insertions(+), 6 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/4] drm: mediatek: fix unbind functions
detatch panel in mtk_dsi_destroy_conn_enc(), since .bind will try to
attach it again.
Fixes: 2e54c14e310f ("drm/mediatek: Add DSI sub driver")
Signed-off-by: Hsin-Yi Wang
---
change log v1->v2:
* mipi_dsi_host_unregister() should be fixed in another patch on the list.
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index b00eb2d2e086..1ae3be99e0ff 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -844,6 +844,8 @@ static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi)
/* Skip connector cleanup if creation was delegated to the bridge */
if (dsi->conn.dev)
drm_connector_cleanup(>conn);
+ if (dsi->panel)
+ drm_panel_detach(dsi->panel);
}
static void mtk_dsi_ddp_start(struct mtk_ddp_comp *comp)
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv6 0/4] omapdrm: DSI command mode panel support
* Tomi Valkeinen [190529 07:06]: > On 28/05/2019 13:18, Tony Lindgren wrote: > > > > My board is x15 rev A3, attached to AM5 EVM. I've also attached my kernel > > > config. > > > > Strange that this is not affecting other x15? I think timer12 would > > be blocked on HS devices though? > > Seems that the kernel config affects. omap2plus_defconfig boots ok. OK, this line in your oops: Unable to handle kernel paging request at virtual address 5a5a5a5a Probably means we hit some slab poison with DEBUG_SLAB set. Looks like your config boots fine with DEBUG_SLAB disabled for me. As this only happens for timer12, I wonder if we're again hitting some uncompress issue with corrupted dtb. Changing u-boot ftdaddr higher up might possibly make it go away. Or else there's a bug elsewhere :) Regards, Tony ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: DRM/AST regression (likely 4.14 -> 4.19+), providing EDID manually fails
On Tue, 28 May 2019, Jani Nikula wrote: > On Mon, 27 May 2019, Ashutosh Dixit wrote: > > On Sun, 26 May 2019 12:50:51 -0700, Ilpo Järvinen wrote: > >> > >> Hi all, > >> > >> I've a workstation which has internal VGA that is detected as AST 2400 and > >> with it EDID has been always quite flaky (except for some time it worked > >> with 4.14 long enough that I thought the problems would be past until the > >> problems reappeared also with 4.14). Thus, I've provided manually the EDID > >> that I extracted from the monitor using other computer (the monitor itself > >> worked just fine on the earlier computer so it is likely fine). > >> > >> I setup the manual EDID using drm_kms_helper.edid_firmware, however, > >> after upgrading to 4.19.45 it stopped working (no "Got external EDID base > >> block" appears in dmesg, the text mode is kept in the lower res mode, and > >> Xorg logs no longer dumps the EDID info like it did with 4.14). So I guess > >> the EDID I provided manually on the command line is not correctly put into > >> use with 4.19+ kernels. > >> > >> The 4.19 dmesg indicated that drm_kms_helper.edid_firmware is deprecated > >> so I also tested with drm.edid_firmware it suggested as the replacement > >> but with no luck (but I believe also the drm_kms_helper one should have > >> worked as it was only "deprecated"). > >> > >> I also tried 5.1.2 but it did not work any better (and with it also tried > >> removing all the manual *.edid_firmware from the command line so I still > >> need to provide one manually to have it reliable working it seems). > > > > I believe there is a bug already tracking this, here: > > > > https://bugs.freedesktop.org/show_bug.cgi?id=107583 > > Ilpo, does video=VGA-1:e command-line option work around the problem for > you? Yes it does; together with the modeline stuff for Xorg (after reading the referenced bug report I realized I can fix the X side with it). So I now have the desired modes/resolutions in use. Thank you all! -- i.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[bug report] drm/mcde: Add new driver for ST-Ericsson MCDE
Hello Linus Walleij,
This is a semi-automatic email about new static checker warnings.
The patch 5fc537bfd000: "drm/mcde: Add new driver for ST-Ericsson
MCDE" from May 24, 2019, leads to the following Smatch complaint:
drivers/gpu/drm/mcde/mcde_dsi.c:908 mcde_dsi_bind()
error: we previously assumed 'd->mdsi' could be null (see line 879)
drivers/gpu/drm/mcde/mcde_dsi.c
878 /* If the display attached before binding, set this up */
879 if (d->mdsi)
^^^
Check for NULL
880 d->mcde->mdsi = d->mdsi;
881
882 /* Obtain the clocks */
883 d->hs_clk = devm_clk_get(dev, "hs");
884 if (IS_ERR(d->hs_clk)) {
885 dev_err(dev, "unable to get HS clock\n");
886 return PTR_ERR(d->hs_clk);
887 }
888
889 d->lp_clk = devm_clk_get(dev, "lp");
890 if (IS_ERR(d->lp_clk)) {
891 dev_err(dev, "unable to get LP clock\n");
892 return PTR_ERR(d->lp_clk);
893 }
894
895 /* Assert RESET through the PRCMU, active low */
896 /* FIXME: which DSI block? */
897 regmap_update_bits(d->prcmu, PRCM_DSI_SW_RESET,
898 PRCM_DSI_SW_RESET_DSI0_SW_RESETN, 0);
899
900 usleep_range(100, 200);
901
902 /* De-assert RESET again */
903 regmap_update_bits(d->prcmu, PRCM_DSI_SW_RESET,
904 PRCM_DSI_SW_RESET_DSI0_SW_RESETN,
905 PRCM_DSI_SW_RESET_DSI0_SW_RESETN);
906
907 /* Start up the hardware */
908 mcde_dsi_start(d);
^
d->mdsi is dereferenced without checking for NULL inside here.
909
910 /* Look for a panel as a child to this node */
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/mcde: Fix an uninitialized variable
We never set "vblank" to "false".
Current versions of GCC will initialize it to zero automatically at
certain optimization levels so that's probably why this didn't show up
in testing.
Fixes: 5fc537bfd000 ("drm/mcde: Add new driver for ST-Ericsson MCDE")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/mcde/mcde_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mcde/mcde_display.c
b/drivers/gpu/drm/mcde/mcde_display.c
index f3ef108a41d9..751454ae3cd1 100644
--- a/drivers/gpu/drm/mcde/mcde_display.c
+++ b/drivers/gpu/drm/mcde/mcde_display.c
@@ -65,7 +65,7 @@ enum mcde_dsi_formatter {
void mcde_display_irq(struct mcde *mcde)
{
u32 mispp, misovl, mischnl;
- bool vblank;
+ bool vblank = false;
/* Handle display IRQs */
mispp = readl(mcde->regs + MCDE_MISPP);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110787] Glitches in console of the Julia language plugin for Atom (Juno)
https://bugs.freedesktop.org/show_bug.cgi?id=110787 --- Comment #3 from Manuel Vögele --- Can confirm this is fixed on master. -- 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/i915: selftest_lrc: Check the correct variable
Quoting Dan Carpenter (2019-05-29 12:03:55)
> We should check "request[n]" instead of just "request".
>
> Fixes: 78e41ddd2198 ("drm/i915: Apply an execution_mask to the
> virtual_engine")
> Signed-off-by: Dan Carpenter
Oops.
Reviewd-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[bug report] drm/mcde: Add new driver for ST-Ericsson MCDE
Hello Linus Walleij,
The patch 5fc537bfd000: "drm/mcde: Add new driver for ST-Ericsson
MCDE" from May 24, 2019, leads to the following static checker
warning:
drivers/gpu/drm/mcde/mcde_dsi.c:917 mcde_dsi_bind()
warn: 'bridge' isn't an ERR_PTR
drivers/gpu/drm/mcde/mcde_dsi.c
882 /* Obtain the clocks */
883 d->hs_clk = devm_clk_get(dev, "hs");
884 if (IS_ERR(d->hs_clk)) {
885 dev_err(dev, "unable to get HS clock\n");
886 return PTR_ERR(d->hs_clk);
887 }
888
889 d->lp_clk = devm_clk_get(dev, "lp");
890 if (IS_ERR(d->lp_clk)) {
891 dev_err(dev, "unable to get LP clock\n");
892 return PTR_ERR(d->lp_clk);
893 }
894
895 /* Assert RESET through the PRCMU, active low */
896 /* FIXME: which DSI block? */
897 regmap_update_bits(d->prcmu, PRCM_DSI_SW_RESET,
898 PRCM_DSI_SW_RESET_DSI0_SW_RESETN, 0);
899
900 usleep_range(100, 200);
901
902 /* De-assert RESET again */
903 regmap_update_bits(d->prcmu, PRCM_DSI_SW_RESET,
904 PRCM_DSI_SW_RESET_DSI0_SW_RESETN,
905 PRCM_DSI_SW_RESET_DSI0_SW_RESETN);
906
907 /* Start up the hardware */
908 mcde_dsi_start(d);
909
910 /* Look for a panel as a child to this node */
911 for_each_available_child_of_node(dev->of_node, child) {
912 panel = of_drm_find_panel(child);
913 if (IS_ERR(panel)) {
914 dev_err(dev, "failed to find panel try bridge
(%lu)\n",
915 PTR_ERR(panel));
916 bridge = of_drm_find_bridge(child);
917 if (IS_ERR(bridge)) {
of_drm_find_bridge() returns NULL on error, not error pointers.
918 dev_err(dev, "failed to find bridge
(%lu)\n",
919 PTR_ERR(bridge));
^^^
920 return PTR_ERR(bridge);
^^^
Should this be -EPROBEDEFER? I'm not sure of the rules.
921 }
922 }
923 }
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106302] [radeonsi] Garbage content when accessing a texture in multiple shared EGL contexts
https://bugs.freedesktop.org/show_bug.cgi?id=106302 Pierre-Eric Pelloux-Prayer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/etnaviv: use CMA area to compute linear window offset if possible
The dma_required_mask might overestimate the memory size, or might not match
up with the CMA area placement for other reasons. Get the information about
CMA area placement directly from CMA where it is available, but keep the
dma_required_mask as an approximate fallback for architectures where CMA is
not available.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 72d01e873160..b144f13c 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -4,7 +4,9 @@
*/
#include
+#include
#include
+#include
#include
#include
#include
@@ -724,11 +726,18 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
*/
if (!(gpu->identity.features & chipFeatures_PIPE_3D) ||
(gpu->identity.minor_features0 & chipMinorFeatures0_MC20)) {
- u32 dma_mask = (u32)dma_get_required_mask(gpu->dev);
- if (dma_mask < PHYS_OFFSET + SZ_2G)
+ struct cma *cma = dev_get_cma_area(gpu->dev);
+ phys_addr_t end_mask;
+
+ if (cma)
+ end_mask = cma_get_base(cma) - 1 + cma_get_size(cma);
+ else
+ end_mask = dma_get_required_mask(gpu->dev);
+
+ if (end_mask < PHYS_OFFSET + SZ_2G)
gpu->memory_base = PHYS_OFFSET;
else
- gpu->memory_base = dma_mask - SZ_2G + 1;
+ gpu->memory_base = end_mask - SZ_2G + 1;
} else if (PHYS_OFFSET >= SZ_2G) {
dev_info(gpu->dev, "Need to move linear window on MC1.0,
disabling TS\n");
gpu->memory_base = PHYS_OFFSET;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm/ttm, drm/vmwgfx: Have TTM support AMD SEV encryption
Am 28.05.19 um 19:23 schrieb Lendacky, Thomas: On 5/28/19 12:05 PM, Thomas Hellstrom wrote: On 5/28/19 7:00 PM, Lendacky, Thomas wrote: On 5/28/19 11:32 AM, Koenig, Christian wrote: Am 28.05.19 um 18:27 schrieb Thomas Hellstrom: On Tue, 2019-05-28 at 15:50 +, Lendacky, Thomas wrote: On 5/28/19 10:17 AM, Koenig, Christian wrote: Hi Thomas, Am 28.05.19 um 17:11 schrieb Thomas Hellstrom: Hi, Tom, Thanks for the reply. The question is not graphics specific, but lies in your answer further below: On 5/28/19 4:48 PM, Lendacky, Thomas wrote: On 5/28/19 2:31 AM, Thomas Hellstrom wrote: [SNIP] As for kernel vmaps and user-maps, those pages will be marked encrypted (unless explicitly made un-encrypted by calling set_memory_decrypted()). But, if you are copying to/from those areas into the un- encrypted DMA area then everything will be ok. The question is regarding the above paragraph. AFAICT, set_memory_decrypted() only changes the fixed kernel map PTEs. But when setting up other aliased PTEs to the exact same decrypted pages, for example using dma_mmap_coherent(), kmap_atomic_prot(), vmap() etc. What code is responsible for clearing the encrypted flag on those PTEs? Is there something in the x86 platform code doing that? Tom actually explained this: The encryption bit is bit-47 of a physical address. In other words set_memory_decrypted() changes the physical address in the PTEs of the kernel mapping and all other use cases just copy that from there. Except I don't think the PTE attributes are copied from the kernel mapping +1! in some cases. For example, dma_mmap_coherent() will create the same vm_page_prot value regardless of whether or not the underlying memory is encrypted or not. But kmap_atomic_prot() will return the kernel virtual address of the page, so that would be fine. Yes, on 64-bit systems. On 32-bit systems (do they exist with SEV?), they don't. I don't think so, but feel free to prove me wrong Tom. SEV is 64-bit only. And I just noticed that kmap_atomic_prot() indeed returns the kernel map also for 32-bit lowmem. And similarly TTM user-space mappings and vmap() doesn't copy from the kernel map either, so I think we actually do need to modify the page- prot like done in the patch. Well the problem is that this won't have any effect. As Tom explained encryption is not implemented as a page protection bit, but rather as part of the physical address of the part. This is where things get interesting. Even though the encryption bit is part of the physical address (e.g. under SME the device could/would use an address with the encryption bit set), it is implemented as part of the PTE attributes. So, for example, using _PAGE_ENC when building a pgprot value would produce an entry with the encryption bit set. And the thing to watch out for is using two virtual addresses that point to the same physical address (page) in DRAM but one has the encryption bit set and one doesn't. The hardware does not enforce coherency between an encrypted and un-encrypted mapping of the same physical address (page). See section 7.10.6 of the AMD64 Architecture Programmer's Manual Volume 2. Indeed. And I'm pretty sure the kernel map PTE and a TTM / vmap PTE pointing to the same decrypted page differ in the encryption bit (47) setting. That can't be the case, cause otherwise amdgpu wouldn't already work with SME enabled. I think your patch might go into the right direction, but before we commit anything like that we need to understand first how it actually works currently. Maybe I really need to setup a test system here. Christian. But on the hypervisor that would sort of work, because from what I understand with SEV we select between the guest key and the hypervisor key with that bit. On the hypervisor both keys are the same? On a guest it would probably break. For SEV, if the encryption bit is set then the guest key is used. If the encryption bit is not set, then the hypervisor key is used IFF the encryption bit is set in the hypervisor page tables. You can have SEV guests regardless of whether SME is active (note, there is a difference between SME being enabled vs. SME being active). For SME, there is only one key. The encryption bit determines whether the data is run through the encryption process or not. Thanks, Tom ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm: mediatek: fix unbind functions
Hi, Hsin-Yi: On Wed, 2019-05-29 at 15:06 +0800, Hsin-Yi Wang wrote: > On Wed, May 29, 2019 at 9:35 AM CK Hu wrote: > > > > > I think mtk_dsi_destroy_conn_enc() has much thing to do and I would like > > you to do more. You could refer to [2] for complete implementation. > > > > [2] > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/exynos/exynos_drm_dsi.c?h=v5.2-rc2#n1575 > > > Hi CK, > > Since drm_encoder_cleanup() would already call drm_bridge_detach() to > detach bridge, I think we only need to handle panel case here. > We don't need to call mtk_dsi_encoder_disable() since > mtk_output_dsi_disable() is called in mtk_dsi_remove() and > dsi->enabled will be set to false. Calling second time will just > returns immediately. > So, besides setting > > dsi->panel = NULL; > dsi->conn.status = connector_status_disconnected; Sorry, I think your original patch is good enough, and you need not to do the besides setting. Regards, CK > > are there other things we need to do here? > > Original code doesn't have drm_kms_helper_hotplug_event(), and I'm not > sure if mtk dsi would need this. > Also, mtk_dsi_stop() would also stop irq. > > Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm/ttm, drm/vmwgfx: Have TTM support AMD SEV encryption
On Wed, 2019-05-29 at 09:50 +0200, Christian König wrote: > Am 28.05.19 um 19:23 schrieb Lendacky, Thomas: > > On 5/28/19 12:05 PM, Thomas Hellstrom wrote: > > > On 5/28/19 7:00 PM, Lendacky, Thomas wrote: > > > > On 5/28/19 11:32 AM, Koenig, Christian wrote: > > > > > Am 28.05.19 um 18:27 schrieb Thomas Hellstrom: > > > > > > On Tue, 2019-05-28 at 15:50 +, Lendacky, Thomas wrote: > > > > > > > On 5/28/19 10:17 AM, Koenig, Christian wrote: > > > > > > > > Hi Thomas, > > > > > > > > > > > > > > > > Am 28.05.19 um 17:11 schrieb Thomas Hellstrom: > > > > > > > > > Hi, Tom, > > > > > > > > > > > > > > > > > > Thanks for the reply. The question is not graphics > > > > > > > > > specific, but > > > > > > > > > lies > > > > > > > > > in your answer further below: > > > > > > > > > > > > > > > > > > On 5/28/19 4:48 PM, Lendacky, Thomas wrote: > > > > > > > > > > On 5/28/19 2:31 AM, Thomas Hellstrom wrote: > > > > > > > > > > [SNIP] > > > > > > > > > > As for kernel vmaps and user-maps, those pages will > > > > > > > > > > be marked > > > > > > > > > > encrypted > > > > > > > > > > (unless explicitly made un-encrypted by calling > > > > > > > > > > set_memory_decrypted()). > > > > > > > > > > But, if you are copying to/from those areas into > > > > > > > > > > the un- > > > > > > > > > > encrypted DMA > > > > > > > > > > area then everything will be ok. > > > > > > > > > The question is regarding the above paragraph. > > > > > > > > > > > > > > > > > > AFAICT, set_memory_decrypted() only changes the > > > > > > > > > fixed kernel map > > > > > > > > > PTEs. > > > > > > > > > But when setting up other aliased PTEs to the exact > > > > > > > > > same > > > > > > > > > decrypted > > > > > > > > > pages, for example using dma_mmap_coherent(), > > > > > > > > > kmap_atomic_prot(), > > > > > > > > > vmap() etc. What code is responsible for clearing the > > > > > > > > > encrypted > > > > > > > > > flag > > > > > > > > > on those PTEs? Is there something in the x86 platform > > > > > > > > > code doing > > > > > > > > > that? > > > > > > > > Tom actually explained this: > > > > > > > > > The encryption bit is bit-47 of a physical address. > > > > > > > > In other words set_memory_decrypted() changes the > > > > > > > > physical address > > > > > > > > in > > > > > > > > the PTEs of the kernel mapping and all other use cases > > > > > > > > just copy > > > > > > > > that > > > > > > > > from there. > > > > > > > Except I don't think the PTE attributes are copied from > > > > > > > the kernel > > > > > > > mapping > > > > > > +1! > > > > > > > > > > > > > in some cases. For example, dma_mmap_coherent() will > > > > > > > create the same > > > > > > > vm_page_prot value regardless of whether or not the > > > > > > > underlying memory > > > > > > > is > > > > > > > encrypted or not. But kmap_atomic_prot() will return the > > > > > > > kernel > > > > > > > virtual > > > > > > > address of the page, so that would be fine. > > > > > > Yes, on 64-bit systems. On 32-bit systems (do they exist > > > > > > with SEV?), > > > > > > they don't. > > > > > I don't think so, but feel free to prove me wrong Tom. > > > > SEV is 64-bit only. > > > And I just noticed that kmap_atomic_prot() indeed returns the > > > kernel map > > > also for 32-bit lowmem. > > > > > > > > > And similarly TTM user-space mappings and vmap() doesn't > > > > > > copy from the > > > > > > kernel map either, so I think we actually do need to > > > > > > modify the page- > > > > > > prot like done in the patch. > > > > > Well the problem is that this won't have any effect. > > > > > > > > > > As Tom explained encryption is not implemented as a page > > > > > protection bit, > > > > > but rather as part of the physical address of the part. > > > > This is where things get interesting. Even though the > > > > encryption bit is > > > > part of the physical address (e.g. under SME the device > > > > could/would use an > > > > address with the encryption bit set), it is implemented as part > > > > of the PTE > > > > attributes. So, for example, using _PAGE_ENC when building a > > > > pgprot value > > > > would produce an entry with the encryption bit set. > > > > > > > > And the thing to watch out for is using two virtual addresses > > > > that point > > > > to the same physical address (page) in DRAM but one has the > > > > encryption bit > > > > set and one doesn't. The hardware does not enforce coherency > > > > between an > > > > encrypted and un-encrypted mapping of the same physical address > > > > (page). > > > > See section 7.10.6 of the AMD64 Architecture Programmer's > > > > Manual Volume 2. > > > Indeed. And I'm pretty sure the kernel map PTE and a TTM / vmap > > > PTE > > > pointing to the same decrypted page differ in the encryption bit > > > (47) > > > setting. > > That can't be the case, cause otherwise amdgpu wouldn't already work > with SME enabled. With SME the situation is different. The coherent memory is still encrypted, and TTM is
[PATCH v3 4/4] drm/panfrost: Expose performance counters through unstable ioctls
Expose performance counters through 2 driver specific ioctls: one to
enable/disable the perfcnt block, and one to dump the counter values.
There are discussions to expose global performance monitors (those
counters that can't be retrieved on a per-job basis) in a consistent
way, but this is likely to take time to settle on something that works
for various HW/users.
The ioctls are marked unstable so we can get rid of them when the time
comes. We initally went for a debugfs-based interface, but this was
making the transition to per-FD address space more complicated (we need
to specify the namespace the GPU has to use when dumping the perf
counters), hence the decision to switch back to driver specific ioctls
which are passed the FD they operate on and thus will have a dedicated
address space attached to them.
Other than that, the implementation is pretty simple: it basically dumps
all counters and copy the values to a userspace buffer. The parsing is
left to userspace which has to know the specific layout that's used
by the GPU (layout differs on a per-revision basis).
Signed-off-by: Boris Brezillon
---
Changes in v3:
* Expose things through ioctls instead of debugs (suggested by Rob)
* Fix the BO size calculation (reported by Steven)
* Drop perfcnt suspend/resume logic (runtime suspend is prevented when
perfcnt is enabled)
* Disable the perfcnt block in the _fini() path (suggested by Rob)
* Do not mess with the INT reg in _init() (suggested by Rob)
* Provide a way to select both set of counters on Bifrost GPUs
(suggested by Steven)
Changes in v2:
* Complete rewrite to expose things through debugfs in a simple way
(no counter layout abstraction and no per-job counter tracking to
avoid the perf penalty incurred by the extra serialization fence)
---
drivers/gpu/drm/panfrost/Makefile | 3 +-
drivers/gpu/drm/panfrost/panfrost_device.c | 8 +
drivers/gpu/drm/panfrost/panfrost_device.h | 3 +
drivers/gpu/drm/panfrost/panfrost_drv.c | 4 +
drivers/gpu/drm/panfrost/panfrost_gpu.c | 7 +
drivers/gpu/drm/panfrost/panfrost_perfcnt.c | 329
drivers/gpu/drm/panfrost/panfrost_perfcnt.h | 18 ++
drivers/gpu/drm/panfrost/panfrost_regs.h| 19 ++
include/uapi/drm/panfrost_drm.h | 24 ++
9 files changed, 414 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/panfrost/panfrost_perfcnt.c
create mode 100644 drivers/gpu/drm/panfrost/panfrost_perfcnt.h
diff --git a/drivers/gpu/drm/panfrost/Makefile
b/drivers/gpu/drm/panfrost/Makefile
index 6de72d13c58f..ecf0864cb515 100644
--- a/drivers/gpu/drm/panfrost/Makefile
+++ b/drivers/gpu/drm/panfrost/Makefile
@@ -7,6 +7,7 @@ panfrost-y := \
panfrost_gem.o \
panfrost_gpu.o \
panfrost_job.o \
- panfrost_mmu.o
+ panfrost_mmu.o \
+ panfrost_perfcnt.o
obj-$(CONFIG_DRM_PANFROST) += panfrost.o
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c
b/drivers/gpu/drm/panfrost/panfrost_device.c
index ccb8eb2a518c..8a111d7c0200 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.c
+++ b/drivers/gpu/drm/panfrost/panfrost_device.c
@@ -14,6 +14,7 @@
#include "panfrost_gpu.h"
#include "panfrost_job.h"
#include "panfrost_mmu.h"
+#include "panfrost_perfcnt.h"
static int panfrost_reset_init(struct panfrost_device *pfdev)
{
@@ -171,7 +172,13 @@ int panfrost_device_init(struct panfrost_device *pfdev)
pm_runtime_mark_last_busy(pfdev->dev);
pm_runtime_put_autosuspend(pfdev->dev);
+ err = panfrost_perfcnt_init(pfdev);
+ if (err)
+ goto err_out5;
+
return 0;
+err_out5:
+ panfrost_job_fini(pfdev);
err_out4:
panfrost_mmu_fini(pfdev);
err_out3:
@@ -187,6 +194,7 @@ int panfrost_device_init(struct panfrost_device *pfdev)
void panfrost_device_fini(struct panfrost_device *pfdev)
{
+ panfrost_perfcnt_fini(pfdev);
panfrost_job_fini(pfdev);
panfrost_mmu_fini(pfdev);
panfrost_gpu_fini(pfdev);
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
b/drivers/gpu/drm/panfrost/panfrost_device.h
index e86581c4af7b..83cc01cafde1 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.h
+++ b/drivers/gpu/drm/panfrost/panfrost_device.h
@@ -14,6 +14,7 @@ struct panfrost_device;
struct panfrost_mmu;
struct panfrost_job_slot;
struct panfrost_job;
+struct panfrost_perfcnt;
#define NUM_JOB_SLOTS 3
@@ -78,6 +79,8 @@ struct panfrost_device {
struct panfrost_job *jobs[NUM_JOB_SLOTS];
struct list_head scheduled_jobs;
+ struct panfrost_perfcnt *perfcnt;
+
struct mutex sched_lock;
struct mutex reset_lock;
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 754881ece8d7..e34e86a7378a 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -19,6 +19,7 @@
#include "panfrost_mmu.h"
#include "panfrost_job.h"
#include "panfrost_gpu.h"
+#include
[PATCH v3 2/4] drm/panfrost: Add a module parameter to expose unstable ioctls
We plan to expose performance counters through 2 driver specific
ioctls until there's a solution to expose them in a generic way.
In order to be able to deprecate those ioctls when this new
infrastructure is in place we add an unsafe module parameter that
will keep those ioctls hidden unless it's set to true (which also
has the effect of tainting the kernel).
All unstable ioctl handlers should use panfrost_unstable_ioctl_check()
to check whether they're supposed to handle the request or reject it
with ENOSYS.
Suggested-by: Emil Velikov
Signed-off-by: Boris Brezillon
---
Chnages in v3:
* New patch
---
drivers/gpu/drm/panfrost/panfrost_device.h | 2 ++
drivers/gpu/drm/panfrost/panfrost_drv.c| 11 +++
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
b/drivers/gpu/drm/panfrost/panfrost_device.h
index 8074f221034b..031168f83bd2 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.h
+++ b/drivers/gpu/drm/panfrost/panfrost_device.h
@@ -115,6 +115,8 @@ static inline bool panfrost_model_eq(struct panfrost_device
*pfdev, s32 id)
return !panfrost_model_cmp(pfdev, id);
}
+int panfrost_unstable_ioctl_check(void);
+
int panfrost_device_init(struct panfrost_device *pfdev);
void panfrost_device_fini(struct panfrost_device *pfdev);
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index d11e2281dde6..754881ece8d7 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -20,6 +20,9 @@
#include "panfrost_job.h"
#include "panfrost_gpu.h"
+static bool unstable_ioctls;
+module_param_unsafe(unstable_ioctls, bool, 0600);
+
static int panfrost_ioctl_get_param(struct drm_device *ddev, void *data,
struct drm_file *file)
{
struct drm_panfrost_get_param *param = data;
@@ -297,6 +300,14 @@ static int panfrost_ioctl_get_bo_offset(struct drm_device
*dev, void *data,
return 0;
}
+int panfrost_unstable_ioctl_check(void)
+{
+ if (!unstable_ioctls)
+ return -ENOSYS;
+
+ return 0;
+}
+
static int
panfrost_open(struct drm_device *dev, struct drm_file *file)
{
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/4] drm/panfrost: Expose perf counters to userspace
Hello,
This a new version of the panfrost perfcnt series, this time exposing
this functionality through 2 ioctls instead of the debugfs approach
used in v2.
I also went for Emil's suggestion to expose those ioctls only when
the unstable_iocts unsafe param is set to true. This way, I hope we'll
be able to deprecate those ioctls when the generic solution to expose
global perf counters is out.
Also addressed the problems reported by Rob and Steven.
Regards,
Boris
Changes in v3:
* Expose things through ioctls instead of debugfs (needed for
per-FD address space that is being worked on by Rob)
Changes in v2:
* Complete rewrite to expose things through debugfs
Boris Brezillon (4):
drm/panfrost: Move gpu_{write,read}() macros to panfrost_regs.h
drm/panfrost: Add a module parameter to expose unstable ioctls
drm/panfrost: Add an helper to check the GPU generation
drm/panfrost: Expose performance counters through unstable ioctls
drivers/gpu/drm/panfrost/Makefile | 3 +-
drivers/gpu/drm/panfrost/panfrost_device.c | 8 +
drivers/gpu/drm/panfrost/panfrost_device.h | 10 +
drivers/gpu/drm/panfrost/panfrost_drv.c | 15 +
drivers/gpu/drm/panfrost/panfrost_gpu.c | 10 +-
drivers/gpu/drm/panfrost/panfrost_perfcnt.c | 329
drivers/gpu/drm/panfrost/panfrost_perfcnt.h | 18 ++
drivers/gpu/drm/panfrost/panfrost_regs.h| 22 ++
include/uapi/drm/panfrost_drm.h | 24 ++
9 files changed, 435 insertions(+), 4 deletions(-)
create mode 100644 drivers/gpu/drm/panfrost/panfrost_perfcnt.c
create mode 100644 drivers/gpu/drm/panfrost/panfrost_perfcnt.h
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/4] drm/panfrost: Move gpu_{write, read}() macros to panfrost_regs.h
So they can be used from other files.
Signed-off-by: Boris Brezillon
---
Changes in v3:
- None
Changes in v2:
- None
---
drivers/gpu/drm/panfrost/panfrost_gpu.c | 3 ---
drivers/gpu/drm/panfrost/panfrost_regs.h | 3 +++
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c
b/drivers/gpu/drm/panfrost/panfrost_gpu.c
index 58ef25573cda..6e68a100291c 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gpu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c
@@ -17,9 +17,6 @@
#include "panfrost_gpu.h"
#include "panfrost_regs.h"
-#define gpu_write(dev, reg, data) writel(data, dev->iomem + reg)
-#define gpu_read(dev, reg) readl(dev->iomem + reg)
-
static irqreturn_t panfrost_gpu_irq_handler(int irq, void *data)
{
struct panfrost_device *pfdev = data;
diff --git a/drivers/gpu/drm/panfrost/panfrost_regs.h
b/drivers/gpu/drm/panfrost/panfrost_regs.h
index 578c5fc2188b..42d08860fd76 100644
--- a/drivers/gpu/drm/panfrost/panfrost_regs.h
+++ b/drivers/gpu/drm/panfrost/panfrost_regs.h
@@ -295,4 +295,7 @@
#define AS_FAULTSTATUS_ACCESS_TYPE_READ(0x2 << 8)
#define AS_FAULTSTATUS_ACCESS_TYPE_WRITE (0x3 << 8)
+#define gpu_write(dev, reg, data) writel(data, dev->iomem + reg)
+#define gpu_read(dev, reg) readl(dev->iomem + reg)
+
#endif
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/4] drm/panfrost: Add an helper to check the GPU generation
All models with an ID >= 0x1000 are Bifrost GPUs for now (might change
with new gens).
Suggested-by: Alyssa Rosenzweig
Signed-off-by: Boris Brezillon
---
Changes in v3:
* New patch
---
drivers/gpu/drm/panfrost/panfrost_device.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
b/drivers/gpu/drm/panfrost/panfrost_device.h
index 031168f83bd2..e86581c4af7b 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.h
+++ b/drivers/gpu/drm/panfrost/panfrost_device.h
@@ -110,6 +110,11 @@ static inline int panfrost_model_cmp(struct
panfrost_device *pfdev, s32 id)
return match_id - id;
}
+static inline bool panfrost_model_is_bifrost(struct panfrost_device *pfdev)
+{
+ return panfrost_model_cmp(pfdev, 0x1000) >= 0;
+}
+
static inline bool panfrost_model_eq(struct panfrost_device *pfdev, s32 id)
{
return !panfrost_model_cmp(pfdev, id);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110781] Radeon: heavy r300 performance drop regression between 11.x and 19.x
https://bugs.freedesktop.org/show_bug.cgi?id=110781 Richard Thier changed: What|Removed |Added Severity|normal |major -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] gpu/drm: mediatek: call mtk_dsi_stop() after mtk_drm_crtc_atomic_disable()
On Fri, 2019-03-22 at 13:05 +0800, Hsin-Yi Wang wrote:
> On Fri, Mar 22, 2019 at 9:21 AM CK Hu wrote:
> >
> > Hi, Hsin-yi:
> >
> > On Thu, 2019-03-21 at 22:09 +0800, Hsin-Yi Wang wrote:
> > > On Thu, Mar 21, 2019 at 9:46 AM CK Hu wrote:
> > > >
> > > > Hi, Hsin-yi:
> > > >
> > > > On Thu, 2019-03-21 at 09:28 +0800, CK Hu wrote:
> > > > > Hi, Hsin-yi:
> > > > >
> > > > > On Wed, 2019-03-20 at 15:18 +0800, Hsin-Yi Wang wrote:
> > > > > > mtk_dsi_stop() should be called after
> > > > > > mtk_drm_crtc_atomic_disable(), which needs
> > > > > > ovl irq for drm_crtc_wait_one_vblank(), since after mtk_dsi_stop()
> > > > > > is called,
> > > > > > ovl irq will be disabled. If drm_crtc_wait_one_vblank() is called
> > > > > > after last
> > > > > > irq, it will timeout with this message: "vblank wait timed out on
> > > > > > crtc 0". This
> > > > > > happens sometimes when turning off the screen.
> > > > > >
> > > > > > In drm_atomic_helper.c#disable_outputs(),
> > > > > > the calling sequence when turning off the screen is:
> > > > > >
> > > > > > 1. mtk_dsi_encoder_disable()
> > > > > > --> mtk_output_dsi_disable()
> > > > > >--> mtk_dsi_stop(); // sometimes make vblank timeout in
> > > > > > atomic_disable
> > > > > >--> mtk_dsi_poweroff();
> > > > > > 2. mtk_drm_crtc_atomic_disable()
> > > > > > --> drm_crtc_wait_one_vblank();
> > > > > > ...
> > > > > >--> mtk_dsi_ddp_stop()
> > > > > > --> mtk_dsi_poweroff();
> > > > > >
> > > > > > mtk_dsi_poweroff() has reference count design, change to make
> > > > > > mtk_dsi_stop()
> > > > > > called in mtk_dsi_poweroff() when refcount is 0.
> > > > > >
> > > > > > Fixes: 0707632b5bac ("drm/mediatek: update DSI sub driver flow for
> > > > > > sending commands to panel")
> > > > > > Signed-off-by: Hsin-Yi Wang
> > > > > > ---
> > > > > > change log:
> > > > > > v1->v2:
> > > > > > * update commit message.
> > > > > > * call mtk_dsi_stop() in mtk_dsi_poweroff() when refcount is 0.
> > > > > > ---
> > > > > > drivers/gpu/drm/mediatek/mtk_dsi.c | 5 -
> > > > > > 1 file changed, 4 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > > > > > b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > > > > > index b00eb2d2e086..e152f37af57d 100644
> > > > > > --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > > > > > +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > > > > > @@ -630,6 +630,8 @@ static void mtk_dsi_poweroff(struct mtk_dsi
> > > > > > *dsi)
> > > > > > if (--dsi->refcount != 0)
> > > > > > return;
> > > > > >
> > > > > > + mtk_dsi_stop(dsi);
> > > > > > +
> > > > > > if (!mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500)) {
> > > > > > if (dsi->panel) {
> > > > > > if (drm_panel_unprepare(dsi->panel)) {
> > > > >
> > > > > I think you just move mtk_dsi_stop() into mtk_dsi_poweroff() would
> > > > > works
> > > > > fine, but I would rather like calling mtk_dsi_start() and
> > > > > mtk_dsi_stop()
> > > > > in a symmetric manner. That means you may also move below functions
> > > > > into
> > > > > mtk_dsi_poweron():
> > > > >
> > > > > mtk_dsi_set_mode(dsi);
> > > > > mtk_dsi_clk_hs_mode(dsi, 1);
> > > > > mtk_dsi_start(dsi);
> > >
> > > For MT8183 with bridge panel, calling mtk_dsi_start() in
> > > mtk_dsi_poweron() when refcount is 0->1, like the following order,
> > > will results in no irq, not sure why though. I think this might be the
> > > timing issue you mentioned in patch v1. (MT8183 without bridge panel
> > > doesn't have this issue.)
> > >
> > > atomic_enable
> > > --> mtk_crtc_ddp_hw_init
> > > --> mtk_dsi_ddp_start
> > > --> mtk_dsi_poweron (ref 0->1)
> > > --> drm_panel_prepare
> > > --> *mtk_dsi_start // results in no irq for MT8183 with bridge
> > > --> drm_crtc_vblank_on
> > >
> > > mtk_output_dsi_enable
> > > --> mtk_dsi_poweron (ref 1->2, ignored)
> > > --> mtk_dsi_start //original position
> > >
> > > For mtk_dsi_stop() both with or without bridge is fine.
> Add cc Jitao.
>
> Hi Jitao,
> Do you know if this is a known hardware behavior?
>
> Thanks
mtk_dsi_start must after dsi full setting.
If you put it in mtk_dsi_ddp_start, mtk_dsi_set_mode won't work. DSI
will keep cmd mode. So you see no irq.
I think we show keep the mtk_dsi_start in mtk_output_dsi_enable
Best Regards
Jitao
> >
> > I'm not familiar with dsi hardware, so I could not answer why this
> > problem happen. Jitao is familiar with dsi hardware, you may ask him for
> > help. If this is hardware behavior, I could accept asymmetric flow, but
> > please be sure this is hardware behavior not software bug.
> >
> > Regards,
> > CK
> >
> > >
> > > > >
> > > > >
> > > > > > @@ -696,7 +698,6 @@ static void mtk_output_dsi_disable(struct
> > > > > > mtk_dsi *dsi)
> > > > > > }
> > > > > > }
> > > > > >
> > > > > > - mtk_dsi_stop(dsi);
> > > > > > mtk_dsi_poweroff(dsi);
> > > > >
[PATCH v9 6/9] arm64: dts: allwinner: a64-amarula-relic: Add Techstar TS8550B MIPI-DSI panel
Amarula A64-Relic board by default bound with Techstar TS8550B
MIPI-DSI panel, add support for it.
DSI panel connected via board DSI port with,
- DLDO1 as VCC-DSI supply
- DLDO2 as VCC supply
- DLDO2 as IOVCC supply
- PD24 gpio for reset pin
- PD23 gpio for backlight enable pin
Signed-off-by: Jagan Teki
---
.../allwinner/sun50i-a64-amarula-relic.dts| 35 +++
1 file changed, 35 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
index 5634245d11db..5109c3258a2f 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
@@ -9,6 +9,7 @@
#include "sun50i-a64.dtsi"
#include
+#include
/ {
model = "Amarula A64-Relic";
@@ -18,6 +19,14 @@
serial0 =
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = < 0 5 PWM_POLARITY_INVERTED>;
+ brightness-levels = <1 2 4 8 16 32 64 128 255>;
+ default-brightness-level = <2>;
+ enable-gpios = < 3 23 GPIO_ACTIVE_HIGH>; /* LCD-BL-EN: PD23
*/
+ };
+
chosen {
stdout-path = "serial0:115200n8";
};
@@ -80,6 +89,28 @@
};
};
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ vcc-dsi-supply = <_dldo1>; /* VCC-DSI */
+ status = "okay";
+
+ panel@0 {
+ compatible = "techstar,ts8550b", "sitronix,st7701";
+ reg = <0>;
+ VCC-supply = <_dldo2>; /* VCC-MIPI */
+ IOVCC-supply = <_dldo2>;/* VCC-MIPI */
+ reset-gpios = < 3 24 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD24 */
+ backlight = <>;
+ };
+};
+
{
status = "okay";
};
@@ -151,6 +182,10 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
_rsb {
status = "okay";
--
2.18.0.321.gffc6fa0e3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 3/9] drm/sun4i: dsi: Add has_mod_clk quirk
As per the user manual, look like mod clock is not mandatory
for all Allwinner MIPI DSI controllers, it is connected to
CLK_DSI_SCLK for A31 and not available in A64.
So add has_mod_clk quirk and process the clk accordingly.
Tested-by: Merlijn Wajer
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 38 ++
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 5
2 files changed, 32 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 3846ee91da52..ef878175a79b 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1154,6 +1155,7 @@ static int sun6i_dsi_probe(struct platform_device *pdev)
dsi->dev = dev;
dsi->host.ops = _dsi_host_ops;
dsi->host.dev = dev;
+ dsi->variant = of_device_get_match_data(dev);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
base = devm_ioremap_resource(dev, res);
@@ -1181,17 +1183,20 @@ static int sun6i_dsi_probe(struct platform_device *pdev)
return PTR_ERR(dsi->reset);
}
- dsi->mod_clk = devm_clk_get(dev, "mod");
- if (IS_ERR(dsi->mod_clk)) {
- dev_err(dev, "Couldn't get the DSI mod clock\n");
- return PTR_ERR(dsi->mod_clk);
+ if (dsi->variant->has_mod_clk) {
+ dsi->mod_clk = devm_clk_get(dev, "mod");
+ if (IS_ERR(dsi->mod_clk)) {
+ dev_err(dev, "Couldn't get the DSI mod clock\n");
+ return PTR_ERR(dsi->mod_clk);
+ }
}
/*
* In order to operate properly, that clock seems to be always
* set to 297MHz.
*/
- clk_set_rate_exclusive(dsi->mod_clk, 29700);
+ if (dsi->variant->has_mod_clk)
+ clk_set_rate_exclusive(dsi->mod_clk, 29700);
dsi->dphy = devm_phy_get(dev, "dphy");
if (IS_ERR(dsi->dphy)) {
@@ -1221,7 +1226,8 @@ static int sun6i_dsi_probe(struct platform_device *pdev)
err_pm_disable:
pm_runtime_disable(dev);
err_unprotect_clk:
- clk_rate_exclusive_put(dsi->mod_clk);
+ if (dsi->variant->has_mod_clk)
+ clk_rate_exclusive_put(dsi->mod_clk);
return ret;
}
@@ -1233,7 +1239,8 @@ static int sun6i_dsi_remove(struct platform_device *pdev)
component_del(>dev, _dsi_ops);
mipi_dsi_host_unregister(>host);
pm_runtime_disable(dev);
- clk_rate_exclusive_put(dsi->mod_clk);
+ if (dsi->variant->has_mod_clk)
+ clk_rate_exclusive_put(dsi->mod_clk);
return 0;
}
@@ -1250,7 +1257,8 @@ static int __maybe_unused sun6i_dsi_runtime_resume(struct
device *dev)
}
reset_control_deassert(dsi->reset);
- clk_prepare_enable(dsi->mod_clk);
+ if (dsi->variant->has_mod_clk)
+ clk_prepare_enable(dsi->mod_clk);
/*
* Enable the DSI block.
@@ -1278,7 +1286,8 @@ static int __maybe_unused
sun6i_dsi_runtime_suspend(struct device *dev)
{
struct sun6i_dsi *dsi = dev_get_drvdata(dev);
- clk_disable_unprepare(dsi->mod_clk);
+ if (dsi->variant->has_mod_clk)
+ clk_disable_unprepare(dsi->mod_clk);
reset_control_assert(dsi->reset);
regulator_disable(dsi->regulator);
@@ -1291,9 +1300,16 @@ static const struct dev_pm_ops sun6i_dsi_pm_ops = {
NULL)
};
+static const struct sun6i_dsi_variant sun6i_a31_mipi_dsi = {
+ .has_mod_clk = true,
+};
+
static const struct of_device_id sun6i_dsi_of_table[] = {
- { .compatible = "allwinner,sun6i-a31-mipi-dsi" },
- { }
+ {
+ .compatible = "allwinner,sun6i-a31-mipi-dsi",
+ .data = _a31_mipi_dsi,
+ },
+ { /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, sun6i_dsi_of_table);
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
index c76b71259d2e..76874ff8e3ef 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
@@ -15,6 +15,10 @@
#include
+struct sun6i_dsi_variant {
+ boolhas_mod_clk;
+};
+
struct sun6i_dsi {
struct drm_connectorconnector;
struct drm_encoder encoder;
@@ -33,6 +37,7 @@ struct sun6i_dsi {
struct mipi_dsi_device *device;
struct drm_panel*panel;
struct drm_bridge *bridge;
+ const struct sun6i_dsi_variant *variant;
};
static inline struct sun6i_dsi *host_to_sun6i_dsi(struct mipi_dsi_host *host)
--
2.18.0.321.gffc6fa0e3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[DO NOT MERGE] [PATCH v9 8/9] arm64: dts: allwinner: a64-pine64-lts: Enable Feiyang FY07024DI26A30-D DSI panel
Feiyang FY07024DI26A30-D MIPI_DSI panel is desiged to attach with
DSI connector on pine64 boards, enable the same for pine64 LTS.
DSI panel connected via board DSI port with,
- DLDO1 as VCC-DSI supply
- DC1SW as AVDD supply
- DLDO2 as DVDD supply
- PD24 gpio for reset pin
- PH10 gpio for backlight enable pin
Tested-by: Merlijn Wajer
Signed-off-by: Jagan Teki
---
.../allwinner/sun50i-a64-sopine-baseboard.dts | 31 +++
1 file changed, 31 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
index e6fb9683f213..51b0cf71c3d4 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
@@ -46,6 +46,7 @@
/dts-v1/;
#include "sun50i-a64-sopine.dtsi"
+#include
/ {
model = "SoPine with baseboard";
@@ -61,6 +62,14 @@
stdout-path = "serial0:115200n8";
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <_pwm 0 5 PWM_POLARITY_INVERTED>;
+ brightness-levels = <1 2 4 8 16 32 64 128 255>;
+ default-brightness-level = <8>;
+ enable-gpios = < 7 10 GPIO_ACTIVE_HIGH>; /* LCD-BL-EN: PH10
*/
+ };
+
hdmi-connector {
compatible = "hdmi-connector";
type = "a";
@@ -104,6 +113,24 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
+ {
+ vcc-dsi-supply = <_dldo1>; /* VCC-DSI */
+ status = "okay";
+
+ panel@0 {
+ compatible = "feiyang,fy07024di26a30d";
+ reg = <0>;
+ avdd-supply = <_dc1sw>; /* VCC-LCD */
+ dvdd-supply = <_dldo2>; /* VCC-MIPI */
+ reset-gpios = < 3 24 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD24 */
+ backlight = <>;
+ };
+};
+
{
status = "okay";
};
@@ -184,6 +211,10 @@
vcc-hdmi-supply = <_dldo1>;
};
+_pwm {
+ status = "okay";
+};
+
{
simple-audio-card,aux-devs = <_analog>;
simple-audio-card,widgets = "Microphone", "Microphone Jack",
--
2.18.0.321.gffc6fa0e3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 1/9] dt-bindings: sun6i-dsi: Add A64 MIPI-DSI compatible
The MIPI DSI controller in Allwinner A64 is similar to A33. But unlike A33, A64 doesn't have DSI_SCLK gating so it is valid to with separate compatible for A64 on the same driver. Signed-off-by: Jagan Teki Reviewed-by: Rob Herring Tested-by: Merlijn Wajer --- Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt index 1cc40663b7a2..9877398be69a 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt @@ -12,6 +12,7 @@ The DSI Encoder generates the DSI signal from the TCON's. Required properties: - compatible: value must be one of: * allwinner,sun6i-a31-mipi-dsi +* allwinner,sun50i-a64-mipi-dsi - reg: base address and size of memory-mapped region - interrupts: interrupt associated to this IP - clocks: phandles to the clocks feeding the DSI encoder -- 2.18.0.321.gffc6fa0e3
[PATCH v9 2/9] dt-bindings: sun6i-dsi: Add A64 DPHY compatible (w/ A31 fallback)
The MIPI DSI PHY controller on Allwinner A64 is similar on the one on A31. Add A64 compatible and append A31 compatible as fallback. Signed-off-by: Jagan Teki Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt index 9877398be69a..d0ce51fea103 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt @@ -38,6 +38,7 @@ D-PHY Required properties: - compatible: value must be one of: * allwinner,sun6i-a31-mipi-dphy +* allwinner,sun50i-a64-mipi-dphy, allwinner,sun6i-a31-mipi-dphy - reg: base address and size of memory-mapped region - clocks: phandles to the clocks feeding the DSI encoder * bus: the DSI interface clock -- 2.18.0.321.gffc6fa0e3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 0/9] drm/sun4i: Allwinner A64 MIPI-DSI support
This is v9 version for Allwinner A64 MIPI-DSI support and here is the previous version set[1]. This depends on dsi host controller fixes which were supported in this series[2]. All these changes are tested in Allwinner A64 with 2, 4 lanes devices and whose pixel clocks are 27.5 MHz, 30MHz, 55MHz and 147MHz. Changes for v9: - moved dsi fixes in separate series on top of A33 [2] - rebase on linux-next and on top of [2] Changes for v8: - rebased on drm-misc change along with linux-next - reworked video start delay patch - tested on 4 different dsi panels - reworked commit messages Changes for v7: - moved vcc-dsi binding to required filed. - drop quotes on fallback dphy bindings. - drop min_rate clock pll-mipi patches. - introduce dclk divider computation as like A64 BSP. - add A64 DSI quark patches. - fixed A64 DSI pipeline. - add proper commit messages. - collect Merlijn Wajer Tested-by credits. Changes for v6: - dropped unneeded changes, patches - fixed all burst mode patches as per previous version comments - rebase on master - update proper commit message - dropped unneeded comments - order the patches that make review easy Changes for v5: - collect Rob, Acked-by - droped "Fix VBP size calculation" patch - updated vblk timing calculation. - droped techstar, bananapi dsi panel drivers which may require bridge or other setup. it's under discussion. Changes for v4: - droppoed untested CCU_FEATURE_FIXED_POSTDIV check code in nkm min, max rate patches - create two patches for "Add Allwinner A64 MIPI DSI support" one for has_mod_clk quirk and other one for A64 support - use existing driver code construct for hblk computation - dropped "Increase hfp packet overhead" patch [2], though BSP added this but we have no issues as of now. (no issues on panel side w/o this change) - create separate function for vblk computation - enable vcc-dsi regulator in dsi_runtime_resume - collect Rob, Acked-by - update MAINTAINERS file for panel drivers - cleanup commit messages - fixed checkpatch warnings/errors [1] https://patchwork.freedesktop.org/series/57834/ [2] https://patchwork.freedesktop.org/series/60847/ Jagan Teki (9): dt-bindings: sun6i-dsi: Add A64 MIPI-DSI compatible dt-bindings: sun6i-dsi: Add A64 DPHY compatible (w/ A31 fallback) drm/sun4i: dsi: Add has_mod_clk quirk drm/sun4i: dsi: Add Allwinner A64 MIPI DSI support arm64: dts: allwinner: a64: Add MIPI DSI pipeline arm64: dts: allwinner: a64-amarula-relic: Add Techstar TS8550B MIPI-DSI panel [DO NOT MERGE] arm64: dts: allwinner: bananapi-m64: Enable Bananapi S070WV20-CT16 DSI panel [DO NOT MERGE] arm64: dts: allwinner: a64-pine64-lts: Enable Feiyang FY07024DI26A30-D DSI panel [DO NOT MERGE] arm64: dts: allwinner: oceanic-5205-5inmfd: Enable Microtech MTF050FHDI-03 panel .../bindings/display/sunxi/sun6i-dsi.txt | 2 + .../allwinner/sun50i-a64-amarula-relic.dts| 35 + .../dts/allwinner/sun50i-a64-bananapi-m64.dts | 31 .../sun50i-a64-oceanic-5205-5inmfd.dts| 49 +++ .../allwinner/sun50i-a64-sopine-baseboard.dts | 31 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 38 ++ drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c| 45 - drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h| 5 ++ 8 files changed, 225 insertions(+), 11 deletions(-) -- 2.18.0.321.gffc6fa0e3
[PATCH v9 5/9] arm64: dts: allwinner: a64: Add MIPI DSI pipeline
Add MIPI DSI pipeline for Allwinner A64.
- dsi node, with A64 compatible since it doesn't support
DSI_SCLK gating unlike A33
- dphy node, with A64 compatible with A33 fallback since
DPHY on A64 and A33 is similar
- finally, attach the dsi_in to tcon0 for complete MIPI DSI
Signed-off-by: Jagan Teki
Tested-by: Merlijn Wajer
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 38 +++
1 file changed, 38 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index b275c6d35420..44c1c11db423 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -382,6 +382,12 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
+
+ tcon0_out_dsi: endpoint@1 {
+ reg = <1>;
+ remote-endpoint =
<_in_tcon0>;
+ allwinner,tcon-channel = <1>;
+ };
};
};
};
@@ -985,6 +991,38 @@
status = "disabled";
};
+ dsi: dsi@1ca {
+ compatible = "allwinner,sun50i-a64-mipi-dsi";
+ reg = <0x01ca 0x1000>;
+ interrupts = ;
+ clocks = < CLK_BUS_MIPI_DSI>;
+ clock-names = "bus";
+ resets = < RST_BUS_MIPI_DSI>;
+ phys = <>;
+ phy-names = "dphy";
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port {
+ dsi_in_tcon0: endpoint {
+ remote-endpoint = <_out_dsi>;
+ };
+ };
+ };
+
+ dphy: d-phy@1ca1000 {
+ compatible = "allwinner,sun50i-a64-mipi-dphy",
+"allwinner,sun6i-a31-mipi-dphy";
+ reg = <0x01ca1000 0x1000>;
+ clocks = < CLK_BUS_MIPI_DSI>,
+< CLK_DSI_DPHY>;
+ clock-names = "bus", "mod";
+ resets = < RST_BUS_MIPI_DSI>;
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
hdmi: hdmi@1ee {
compatible = "allwinner,sun50i-a64-dw-hdmi",
"allwinner,sun8i-a83t-dw-hdmi";
--
2.18.0.321.gffc6fa0e3
[DO NOT MERGE] [PATCH v9 7/9] arm64: dts: allwinner: bananapi-m64: Enable Bananapi S070WV20-CT16 DSI panel
This patch add support for Bananapi S070WV20-CT16 DSI panel to
BPI-M64 board.
DSI panel connected via board DSI port with,
- DLDO1 as VCC-DSI supply
- DCDC1 as VDD supply
- PD7 gpio for lcd enable pin
- PD6 gpio for lcd reset pin
- PD5 gpio for backlight enable pin
Signed-off-by: Jagan Teki
---
.../dts/allwinner/sun50i-a64-bananapi-m64.dts | 31 +++
1 file changed, 31 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
index c2a6b73b17cf..166b9761ca83 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
@@ -45,6 +45,7 @@
#include "sun50i-a64.dtsi"
#include
+#include
/ {
model = "BananaPi-M64";
@@ -56,6 +57,14 @@
serial1 =
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <_pwm 0 5 PWM_POLARITY_INVERTED>;
+ brightness-levels = <1 2 4 8 16 32 64 128 255>;
+ default-brightness-level = <2>;
+ enable-gpios = < 3 5 GPIO_ACTIVE_HIGH>; /* LCD-BL-EN: PD5 */
+ };
+
chosen {
stdout-path = "serial0:115200n8";
};
@@ -116,6 +125,24 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
+ {
+ vcc-dsi-supply = <_dldo1>; /* VCC3V3-DSI */
+ status = "okay";
+
+ panel@0 {
+ compatible = "bananapi,s070wv20-ct16-icn6211";
+ reg = <0>;
+ enable-gpios = < 3 7 GPIO_ACTIVE_HIGH>; /* LCD-PWR-EN: PD7
*/
+ reset-gpios = < 3 6 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD6 */
+ vdd-supply = <_dcdc1>;
+ backlight = <>;
+ };
+};
+
{
status = "okay";
};
@@ -206,6 +233,10 @@
status = "okay";
};
+_pwm {
+ status = "okay";
+};
+
_rsb {
status = "okay";
--
2.18.0.321.gffc6fa0e3
[DO NOT MERGE] [PATCH v9 9/9] arm64: dts: allwinner: oceanic-5205-5inmfd: Enable Microtech MTF050FHDI-03 panel
Microtech MTF050FHDI-03 is 1080x1920, 4-lane MIPI DSI LCD panel which
has inbuilt NT35596 IC chip.
DSI panel connected to board via 39-pin FPC port with,
- DLDO1 as VCC-DSI supply
- DLDO2 as DVDD supply
- DC1SW as AVDD supply
- DC1SW as AVEE supply
- PD24 gpio for reset pin
- PH10 gpio for backlight enable pin
Tested-by: Tamas Papp
Signed-off-by: Ryan Pannell
Signed-off-by: Michael Trimarchi
Signed-off-by: Jagan Teki
---
.../sun50i-a64-oceanic-5205-5inmfd.dts| 49 +++
1 file changed, 49 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-oceanic-5205-5inmfd.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-oceanic-5205-5inmfd.dts
index a4ddc0b9664c..ab9ee10ba6a2 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-oceanic-5205-5inmfd.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-oceanic-5205-5inmfd.dts
@@ -8,6 +8,7 @@
/dts-v1/;
#include "sun50i-a64-sopine.dtsi"
+#include
/ {
model = "Oceanic 5205 5inMFD";
@@ -22,6 +23,15 @@
stdout-path = "serial0:115200n8";
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <_pwm 0 5 PWM_POLARITY_INVERTED>;
+ brightness-levels = <412 512>;
+ num-interpolated-steps = <100>;
+ default-brightness-level = <100>;
+ enable-gpios = < 7 10 GPIO_ACTIVE_HIGH>; /* LCD-BL-EN: PH10
*/
+ };
+
can_osc: can-osc {
compatible = "fixed-clock";
#clock-cells = <0>;
@@ -40,6 +50,29 @@
};
};
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ vcc-dsi-supply = <_dldo1>; /* VCC-DSI */
+ status = "okay";
+
+ panel@0 {
+ compatible = "microtech,mtf050fhdi-03", "novatek,nt35596";
+ reg = <0>;
+ dvdd-supply = <_dldo2>; /* VCC-MIPI */
+ avdd-supply = <_dc1sw>; /* AVDD_5V0 */
+ avee-supply = <_dc1sw>; /* AVEE_5V */
+ reset-gpios = < 3 24 GPIO_ACTIVE_HIGH>; /* LCD-RST:
PD24 */
+ backlight = <>;
+ };
+};
+
{
status = "okay";
};
@@ -81,10 +114,26 @@
status = "okay";
};
+_pwm {
+ status = "okay";
+};
+
_dc1sw {
regulator-name = "vcc-phy";
};
+_dldo1 {
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-name = "vcc-dsi";
+};
+
+_dldo2 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-name = "vcc-mipi";
+};
+
_ldo_io0 {
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
--
2.18.0.321.gffc6fa0e3
[PATCH v9 4/9] drm/sun4i: dsi: Add Allwinner A64 MIPI DSI support
The MIPI DSI controller in Allwinner A64 is similar to A33.
But unlike A33, A64 doesn't have DSI_SCLK gating so add compatible
for Allwinner A64 with uninitialized has_mod_clk driver.
Signed-off-by: Jagan Teki
Tested-by: Merlijn Wajer
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index ef878175a79b..dd68fd0888c9 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -1304,11 +1304,18 @@ static const struct sun6i_dsi_variant
sun6i_a31_mipi_dsi = {
.has_mod_clk = true,
};
+static const struct sun6i_dsi_variant sun50i_a64_mipi_dsi = {
+};
+
static const struct of_device_id sun6i_dsi_of_table[] = {
{
.compatible = "allwinner,sun6i-a31-mipi-dsi",
.data = _a31_mipi_dsi,
},
+ {
+ .compatible = "allwinner,sun50i-a64-mipi-dsi",
+ .data = _a64_mipi_dsi,
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, sun6i_dsi_of_table);
--
2.18.0.321.gffc6fa0e3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panfrost: Make sure a BO is only unmapped when appropriate
mmu_ops->unmap() will fail when called on a BO that has not been
previously mapped, and the error path in panfrost_ioctl_create_bo()
can call drm_gem_object_put_unlocked() (which in turn calls
panfrost_mmu_unmap()) on a BO that has not been mapped yet.
Keep track of the mapped/unmapped state to avoid such issues.
Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
Cc:
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panfrost/panfrost_gem.h | 1 +
drivers/gpu/drm/panfrost/panfrost_mmu.c | 8
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.h
b/drivers/gpu/drm/panfrost/panfrost_gem.h
index 045000eb5fcf..6dbcaba020fc 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gem.h
+++ b/drivers/gpu/drm/panfrost/panfrost_gem.h
@@ -11,6 +11,7 @@ struct panfrost_gem_object {
struct drm_gem_shmem_object base;
struct drm_mm_node node;
+ bool is_mapped;
};
static inline
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index 762b1bd2a8c2..fb556aa89203 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -156,6 +156,9 @@ int panfrost_mmu_map(struct panfrost_gem_object *bo)
struct sg_table *sgt;
int ret;
+ if (bo->is_mapped)
+ return 0;
+
sgt = drm_gem_shmem_get_pages_sgt(obj);
if (WARN_ON(IS_ERR(sgt)))
return PTR_ERR(sgt);
@@ -189,6 +192,7 @@ int panfrost_mmu_map(struct panfrost_gem_object *bo)
pm_runtime_mark_last_busy(pfdev->dev);
pm_runtime_put_autosuspend(pfdev->dev);
+ bo->is_mapped = true;
return 0;
}
@@ -203,6 +207,9 @@ void panfrost_mmu_unmap(struct panfrost_gem_object *bo)
size_t unmapped_len = 0;
int ret;
+ if (!bo->is_mapped)
+ return;
+
dev_dbg(pfdev->dev, "unmap: iova=%llx, len=%zx", iova, len);
ret = pm_runtime_get_sync(pfdev->dev);
@@ -230,6 +237,7 @@ void panfrost_mmu_unmap(struct panfrost_gem_object *bo)
pm_runtime_mark_last_busy(pfdev->dev);
pm_runtime_put_autosuspend(pfdev->dev);
+ bo->is_mapped = false;
}
static void mmu_tlb_inv_context_s1(void *cookie)
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110781] Radeon: heavy r300 performance drop regression between 11.x and 19.x
https://bugs.freedesktop.org/show_bug.cgi?id=110781 --- Comment #3 from Richard Thier --- When doing an strace this is what I am getting: ... ioctl(6, DRM_IOCTL_RADEON_GEM_CREATE, 0xbfafd880) = 0 <0.68> > [vdso]() [0x891] ioctl(6, DRM_IOCTL_RADEON_CS, 0xafe2404c) = 0 <0.000102> > [vdso]() [0x891] ioctl(6, DRM_IOCTL_RADEON_GEM_WAIT_IDLE, 0xbfafd9c4) = 0 <0.30> > [vdso]() [0x891] ioctl(6, DRM_IOCTL_GEM_CLOSE, 0xbfafd99c) = 0 <0.43> > [vdso]() [0x891] ioctl(6, DRM_IOCTL_RADEON_GEM_CREATE, 0xbfafd880) = 0 <0.70> > [vdso]() [0x891] ioctl(6, DRM_IOCTL_RADEON_CS, 0xafe380e0) = 0 <0.88> > [vdso]() [0x891] ioctl(6, DRM_IOCTL_RADEON_GEM_WAIT_IDLE, 0xbfafd9c4) = 0 <0.29> > [vdso]() [0x891] ioctl(6, DRM_IOCTL_GEM_CLOSE, 0xbfafd99c) = 0 <0.47> > [vdso]() [0x891] ... These continously appear in the mesa+xorg combination that is slow. I have no idea if the same is happening in the old 11.x version where speed is still good (sadly I could not try a later mesa between 11.x and 19.x so far, but I quess some of them works fast still). I have tried reverting the following changes manually in my mesa.git version: 1. https://github.com/mesa3d/mesa/commit/9ac5504df5c31e60801d9d37c1f3d547c486bf0a 2. https://github.com/mesa3d/mesa/commit/a1e391e39df2b1d8169e773a30153167ab8e13e8 3. https://github.com/mesa3d/mesa/commit/0e40c6a7b70673734dfecf5957c086b30f11befe Actually after reverting the latter things got 1FPS slower than with unchanged 19.x, but the first two have helped a very small amount. In my journey to find the slowdown I started to look around "radeon_create_bo" and "radeon_winsys_bo_create" so that is how I was trying to revert exactly these changes because these seemed to be maybe relevant using git blame lookup. If anyone knows where to look further or have any idea about my problem (maybe on the level of X or other parts of mesa making a lot of "bo"s?) please tell me :-) What is "bo" in this sense btw? Is there any documentation I should read to understand these acronyms in the code? It takes considerable amount of time to understand that cs is some kind of "command stream" (still unsure) and bo is some kind of "buffer object" while I have no idea about "pb_" and a lot of other things and not even knowing if a bo is a general buffer for anything (vertex buffers, constant buffers, backbuffers, zbuffers, who-knows-what-else-stuff) or just for one specific thing here. Is there a list for advised reading before touching the code as a noob like me? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: selftest_lrc: Check the correct variable
We should check "request[n]" instead of just "request".
Fixes: 78e41ddd2198 ("drm/i915: Apply an execution_mask to the virtual_engine")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index a8c50900e2d4..13674f836955 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -1526,8 +1526,8 @@ static int mask_virtual_engine(struct drm_i915_private
*i915,
for (n = 0; n < nsibling; n++) {
request[n] = i915_request_create(ve);
- if (IS_ERR(request)) {
- err = PTR_ERR(request);
+ if (IS_ERR(request[n])) {
+ err = PTR_ERR(request[n]);
nsibling = n;
goto out;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dt-bindings: display: Add ETM0700G0DH6 compatible string
The ETM0700G0DH6 is currently documented as using edt,etm070080dh6 compatible string, however the Linux kernel driver as well as a couple of DTs use edt,etm0700g0dh6 compatible string. Add it into the documentation. Signed-off-by: Marek Vasut Cc: Rob Herring Cc: Jan Tuerk Cc: Thierry Reding Cc: devicet...@vger.kernel.org To: dri-devel@lists.freedesktop.org --- .../devicetree/bindings/display/panel/edt,et-series.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/panel/edt,et-series.txt b/Documentation/devicetree/bindings/display/panel/edt,et-series.txt index be8684327ee4..b7ac1c725f97 100644 --- a/Documentation/devicetree/bindings/display/panel/edt,et-series.txt +++ b/Documentation/devicetree/bindings/display/panel/edt,et-series.txt @@ -40,7 +40,7 @@ simple-panel.txt | Identifier | compatbile | description | +=+=+=+ | ETM0700G0DH6| edt,etm070080dh6| WVGA TFT Display with capacitive| -| | | Touchscreen | +| | edt,etm0700g0dh6| Touchscreen | +-+-+-+ | ETM0700G0BDH6 | edt,etm070080bdh6 | Same as ETM0700G0DH6 but with | | | | inverted pixel clock. | -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[bug report] drm/mcde: Add new driver for ST-Ericsson MCDE
Hello Linus Walleij,
The patch 5fc537bfd000: "drm/mcde: Add new driver for ST-Ericsson
MCDE" from May 24, 2019, leads to the following static checker
warning:
drivers/gpu/drm/mcde/mcde_drv.c:488 mcde_probe()
error: uninitialized symbol 'match'.
drivers/gpu/drm/mcde/mcde_drv.c
470 writel(0x, mcde->regs + MCDE_RISERR);
471
472 /* Spawn child devices for the DSI ports */
473 devm_of_platform_populate(dev);
474
475 /* Create something that will match the subdrivers when we bind
*/
476 for (i = 0; i < ARRAY_SIZE(mcde_component_drivers); i++) {
477 struct device_driver *drv =
_component_drivers[i]->driver;
478 struct device *p = NULL, *d;
479
480 while ((d = bus_find_device(_bus_type, p, drv,
481 (void
*)platform_bus_type.match))) {
^^^
The concern would be that this condintion is never met. I suspet that's
not possible?
482 put_device(p);
483 component_match_add(dev, ,
mcde_compare_dev, d);
484 p = d;
485 }
486 put_device(p);
487 }
488 if (IS_ERR(match)) {
489 dev_err(dev, "could not create component match\n");
490 ret = PTR_ERR(match);
491 goto clk_disable;
492 }
493 ret = component_master_add_with_match(>dev,
_drm_comp_ops,
494match);
495 if (ret) {
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 01/11] drm/sun4i: dsi: Fix TCON DRQ set bits
On Fri, May 24, 2019 at 03:48:51PM +0530, Jagan Teki wrote: > On Fri, May 24, 2019 at 2:04 AM Maxime Ripard > wrote: > > > > 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"
Re: [Intel-gfx] [v11 00/12] Add HDR Metadata Parsing and handling in DRM layer
On Wed, May 29, 2019 at 3:59 PM Shankar, Uma wrote: > > > > >-Original Message- > >From: Daniel Vetter [mailto:dan...@ffwll.ch] > >Sent: Wednesday, May 29, 2019 3:13 PM > >To: Shankar, Uma > >Cc: intel-gfx ; dri-devel >de...@lists.freedesktop.org>; Daniele Castagna ; > >jo...@kwiboo.se; Sean Paul ; Sharma, Shashank > >; Syrjala, Ville > >Subject: Re: [Intel-gfx] [v11 00/12] Add HDR Metadata Parsing and handling > >in DRM > >layer > > > >When building the docs with make htmldocs: > > > >./include/drm/drm_mode_config.h:841: warning: Incorrect use of > >kernel-doc format: * hdr_output_metadata_property: Connector > >property containing hdr > >./include/drm/drm_mode_config.h:918: warning: Function parameter or member > >'hdr_output_metadata_property' not described in 'drm_mode_config' > >./include/drm/drm_connector.h:1251: warning: Function parameter or member > >'hdr_output_metadata' not described in 'drm_connector' > >./include/drm/drm_connector.h:1251: warning: Function parameter or member > >'hdr_sink_metadata' not described in 'drm_connector' > > > >Please fix. > > Thanks Daniel, I missed to check the docs warnings. Will fix this. > > >In general documentation for this patch seems to be extremely lacking. > >No property spec, not docs for most of the new stuff added, no nothing. > > Will add the property description in connector create properties as well. > > >Please fix asap. > > Yeah, will send out the doc fix patch soon. btw I think the hdmi infoframe helper docs also need more polish. Generally we only document the driver interface, formal kerneldoc comments for static functions is overkill. I think you added some of those. If you feel like a comment is needed, sure do that, but just a plain comment. Always worth it to make sure that the documentation you're typing actually shows up in the output, and correctly. If it doesn't, then there's something to improve. Can you pls also take a look at that? Thanks, Daniel > > Regards, > Uma Shankar > > >Shashank, Ville, this is stuff reviewers must catch. > > > >Thanks, Daniel > > > >On Thu, May 16, 2019 at 3:43 PM Uma Shankar wrote: > >> > >> This patch series enables HDR support in drm. It basically defines HDR > >> metadata structures, property to pass content (after blending) > >> metadata from user space compositors to driver. > >> > >> Dynamic Range and Mastering infoframe creation and sending. > >> > >> ToDo: > >> 1. We need to get the color framework in place for all planes > >>which support HDR content in hardware. This is already in progres > >>and patches are out for review in mailing list. > >> 2. UserSpace/Compositors: Blending policies and metadata blob > >>creation and passing to driver. Work is already in progress > >>by Intel's middleware teams on wayland and the patches for > >>the same are in review. > >> > >> A POC has already been developed by Ville based on wayland. Please > >> refer below link to see the component interactions and usage: > >> https://lists.freedesktop.org/archives/wayland-devel/2017-December/036 > >> 403.html > >> > >> v2: Updated Ville's POC changes to the patch series.Incorporated > >> cleanups and fixes from Ville. Rebase on latest drm-tip. > >> > >> v3: Fixed a warning causing builds to break on CI. No major change. > >> > >> v4: Addressed Shashank's review comments. > >> > >> v5: Rebase on top of Ville's infoframe refactoring changes. Fixed non > >> modeset case for HDR metadata update. Dropped a redundant patch. > >> > >> v6: Addressed Shashank's review comments and added RB's received. > >> > >> v7: Squashed 2 patches, dropped 1 change and addressed Brian Starkey's > >> and Shashank's review comments. > >> > >> v8: Addressed Jonas Karlman review comments. Added Shashank's RB to > >> the series, fixed a WARN_ON on BYT/CHT. > >> > >> v9: Addressed Ville and Jonas Karlman's review comments. Added the > >> infoframe state readout and metadata reference count. > >> > >> v10: Addressed review comments from Jonas and Ville. Dropped one patch > >> related to i915 fastset handling as per Ville's feedback. > >> > >> v11: Addressed Ville's review comments. > >> > >> Note: v9 version is already tested with Kodi and a confirmation from > >> team kodi has been received. Branch details for the same as below: > >> https://github.com/xbmc/xbmc/tree/feature_drmprime-vaapi > >> > >> v9 of this series is: > >> Tested-by: Jonas Karlman > >> > >> Jonas Karlman (1): > >> drm: Add reference counting on HDR metadata blob > >> > >> Uma Shankar (9): > >> drm: Add HDR source metadata property > >> drm: Parse HDR metadata info from EDID > >> drm: Enable HDR infoframe support > >> drm/i915: Attach HDR metadata property to connector > >> drm/i915: Write HDR infoframe and send to panel > >> drm/i915:Enabled Modeset when HDR Infoframe changes > >> drm/i915: Added DRM Infoframe handling for BYT/CHT > >> video/hdmi: Add Unpack function for DRM infoframe > >> drm/i915: Add state
Re: [PATCH][next] drm/i915: fix uninitialized variable 'subslice_mask'
On 29/05/2019 16:04, Jani Nikula wrote:
> On Wed, 29 May 2019, Colin King wrote:
>> From: Colin Ian King
>>
>> Currently subslice_mask is not initialized and so data is being
>> bit-wise or'd into a garbage value. Fix this by inintializing
>> subslice_mask to zero.
>>
>> Addresses-Coverity: ("Uninitialized scalar variable")
>> Fixes: 1ac159e23c2c ("drm/i915: Expand subslice mask")
>
> This was already reverted for other reasons. Need to be fixed on the
> next round. For future reference, please Cc: author and reviewers of the
> referenced commit.
OK, will do.
Thanks, Colin
>
> BR,
> Jani.
>
>
>> Signed-off-by: Colin Ian King
>> ---
>> drivers/gpu/drm/i915/intel_device_info.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_device_info.c
>> b/drivers/gpu/drm/i915/intel_device_info.c
>> index 3625f777f3a3..d395a09b994f 100644
>> --- a/drivers/gpu/drm/i915/intel_device_info.c
>> +++ b/drivers/gpu/drm/i915/intel_device_info.c
>> @@ -298,7 +298,7 @@ static void cherryview_sseu_info_init(struct
>> drm_i915_private *dev_priv)
>> {
>> struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
>> u32 fuse;
>> -u8 subslice_mask;
>> +u8 subslice_mask = 0;
>>
>> fuse = I915_READ(CHV_FUSE_GT);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panfrost: Add AArch64 page table format support
On Wed, 29 May 2019 at 15:00, Robin Murphy wrote:
>
> Hi Tomeu, Rob,
>
> On 28/05/2019 08:03, Tomeu Vizoso wrote:
> > Robin, Steven,
> >
> > would you or someone else at Arm be able to run the IGT tests [0] on
> > 5.2-rc2 with this patch on top?
> >
> > I don't have any hw with Bifrost and am not planning to work on the
> > userspace any time soon, but I think it would be good to at least
> > check that the kernel doesn't have any obvious bugs.
>
> I've managed to cobble something together which appears to sort-of-work,
> although I don't have the knowledge, time or patience to dive down the
> rabbit-hole of getting a working Arm DDK driver to actually prove the
> setup. The immediate observation is that I get a lot of this:
>
> [ 305.602001] panfrost 6e00.gpu: error powering up gpu
>
> Which appears to stem from the poking of STACK_PWRON_LO. Judging by
> CONFIG_MALI_CORESTACK in kbase, maybe we shouldn't always be going there
> anyway (Steve probably knows more, but is away for a few weeks ATM).
>
> I can't make much sense of the IGT output, but trying
> "scripts/run-tests.sh -t panfrost" (because I also don't have the
> patience to watch it skip through all ~63,000 tests...) seems pretty
> much consistent with or without this patch.
Oops, sorry about that. It would have been sufficient to directly run
these executables:
tests/panfrost_gem_new
tests/panfrost_get_param
tests/panfrost_prime
tests/panfrost_submit
> Same for trying kmscube with
> mesa/master; that produces lots of job errors:
>
> [ 42.409568] panfrost 6e00.gpu: js fault, js=0,
> status=DATA_INVALID_FAULT, head=0x2400b00, tail=0x2400b00
> [ 42.419380] panfrost 6e00.gpu: gpu sched timeout, js=0,
> status=0x58, head=0x2400b00, tail=0x2400b00, sched_job=d17b91
>
> rather than MMU faults either way, so at least this change doesn't seem
> to present any significant regression.
That sounds pretty good to me. We know that the cmdstream and compiler
aren't ready yet for Bifrost.
> It looks like without this patch
> we end up using AS_TRANSCFG_ADRMODE_LEGACY, which presumably means
> exactly what it sounds like, although whether that's sufficiently
> reliable I don't know; those kinds of backwards-compatibility features
> do have a habit of eventually disappearing, and what I've tried so far
> is certainly not the latest and greatest.
One for Rob when he's back, I think :)
Thanks a lot!
Tomeu
> Robin.
>
> > [0]
> > https://gitlab.freedesktop.org/drm/igt-gpu-tools/blob/master/tests/panfrost_submit.c
> >
> > Thanks,
> >
> > Tomeu
> >
> > On Wed, 15 May 2019 at 10:11, Rob Herring wrote:
> >>
> >> Bifrost GPUs use the standard format stage 1 LPAE page tables matching
> >> the io-pgtable ARM_64_LPAE_S1 format. The one difference is the TCR or
> >> TRANSCFG register as the Mali driver calls it has its own custom layout.
> >>
> >> Signed-off-by: Rob Herring
> >> ---
> >> This and compatible strings should be enough for enabling bifrost.
> >> There's some other feature and issue differences, but I think they all
> >> either don't matter (because of differences in panfrost) or I've already
> >> handled them.
> >>
> >> This is only compile tested as I don't have h/w. Running the existing
> >> IGT tests may be sufficient to test this. We should get an error with
> >> the command stream rather than a MMU fault if this is working correctly.
> >>
> >> Rob
> >>
> >> drivers/gpu/drm/panfrost/panfrost_mmu.c | 28 +++-
> >> drivers/gpu/drm/panfrost/panfrost_regs.h | 3 +++
> >> 2 files changed, 30 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
> >> b/drivers/gpu/drm/panfrost/panfrost_mmu.c
> >> index 762b1bd2a8c2..41d184fab07f 100644
> >> --- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
> >> +++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
> >> @@ -1,5 +1,6 @@
> >> // SPDX-License-Identifier:GPL-2.0
> >> /* Copyright 2019 Linaro, Ltd, Rob Herring */
> >> +/* Copyright (C) 2019 Arm Ltd. */
> >> #include
> >> #include
> >> #include
> >> @@ -111,6 +112,14 @@ void panfrost_mmu_enable(struct panfrost_device
> >> *pfdev, u32 as_nr)
> >> u64 transtab = cfg->arm_mali_lpae_cfg.transtab;
> >> u64 memattr = cfg->arm_mali_lpae_cfg.memattr;
> >>
> >> + if (panfrost_has_hw_feature(pfdev, HW_FEATURE_AARCH64_MMU)) {
> >> + transtab = cfg->arm_lpae_s1_cfg.ttbr[0];
> >> + memattr = cfg->arm_lpae_s1_cfg.mair[0];
> >> + } else {
> >> + transtab = cfg->arm_mali_lpae_cfg.transtab;
> >> + memattr = cfg->arm_mali_lpae_cfg.memattr;
> >> + }
> >> +
> >> mmu_write(pfdev, MMU_INT_CLEAR, ~0);
> >> mmu_write(pfdev, MMU_INT_MASK, ~0);
> >>
> >> @@ -123,6 +132,14 @@ void panfrost_mmu_enable(struct panfrost_device
> >> *pfdev, u32 as_nr)
> >> mmu_write(pfdev, AS_MEMATTR_LO(as_nr), memattr & 0xUL);
> >> mmu_write(pfdev, AS_MEMATTR_HI(as_nr),
Re: [PATCH] drm/sched: Fix make htmldocs warnings.
On Wed, May 29, 2019 at 10:29 AM Andrey Grodzovsky wrote: > > Signed-off-by: Andrey Grodzovsky Reviewed-by: Alex Deucher I'll push it to drm-misc in a minute unless you have commit rights. Alex > --- > drivers/gpu/drm/scheduler/sched_main.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/scheduler/sched_main.c > b/drivers/gpu/drm/scheduler/sched_main.c > index 49e7d07..c1058ee 100644 > --- a/drivers/gpu/drm/scheduler/sched_main.c > +++ b/drivers/gpu/drm/scheduler/sched_main.c > @@ -353,6 +353,7 @@ EXPORT_SYMBOL(drm_sched_increase_karma); > * drm_sched_stop - stop the scheduler > * > * @sched: scheduler instance > + * @bad: job which caused the time out > * > * Stop the scheduler and also removes and frees all completed jobs. > * Note: bad job will not be freed as it might be used later and so it's > @@ -422,6 +423,7 @@ EXPORT_SYMBOL(drm_sched_stop); > * drm_sched_job_recovery - recover jobs after a reset > * > * @sched: scheduler instance > + * @full_recovery: proceed with complete sched restart > * > */ > void drm_sched_start(struct drm_gpu_scheduler *sched, bool full_recovery) > -- > 2.7.4 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv6 0/4] omapdrm: DSI command mode panel support
On 28/05/2019 13.32, Tomi Valkeinen wrote: > On 28/05/2019 13:18, Tony Lindgren wrote: >> Strange that this is not affecting other x15? I think timer12 would >> be blocked on HS devices though? > > I don't know... I can't believe my x15 would be unique =). Can it be > something in the kernel config? u-boot? > > Peter should have the same A3. Peter, can you try with my config? It did not boot with your config. My config boots, I'm using SLUB. Flipping CONFIG_SLUB_DEBUG_ON to y and the kernel does not boot. - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [v11 00/12] Add HDR Metadata Parsing and handling in DRM layer
When building the docs with make htmldocs: ./include/drm/drm_mode_config.h:841: warning: Incorrect use of kernel-doc format: * hdr_output_metadata_property: Connector property containing hdr ./include/drm/drm_mode_config.h:918: warning: Function parameter or member 'hdr_output_metadata_property' not described in 'drm_mode_config' ./include/drm/drm_connector.h:1251: warning: Function parameter or member 'hdr_output_metadata' not described in 'drm_connector' ./include/drm/drm_connector.h:1251: warning: Function parameter or member 'hdr_sink_metadata' not described in 'drm_connector' Please fix. In general documentation for this patch seems to be extremely lacking. No property spec, not docs for most of the new stuff added, no nothing. Please fix asap. Shashank, Ville, this is stuff reviewers must catch. Thanks, Daniel On Thu, May 16, 2019 at 3:43 PM Uma Shankar wrote: > > This patch series enables HDR support in drm. It basically defines > HDR metadata structures, property to pass content (after blending) > metadata from user space compositors to driver. > > Dynamic Range and Mastering infoframe creation and sending. > > ToDo: > 1. We need to get the color framework in place for all planes >which support HDR content in hardware. This is already in progres >and patches are out for review in mailing list. > 2. UserSpace/Compositors: Blending policies and metadata blob >creation and passing to driver. Work is already in progress >by Intel's middleware teams on wayland and the patches for >the same are in review. > > A POC has already been developed by Ville based on wayland. Please refer > below link to see the component interactions and usage: > https://lists.freedesktop.org/archives/wayland-devel/2017-December/036403.html > > v2: Updated Ville's POC changes to the patch series.Incorporated cleanups > and fixes from Ville. Rebase on latest drm-tip. > > v3: Fixed a warning causing builds to break on CI. No major change. > > v4: Addressed Shashank's review comments. > > v5: Rebase on top of Ville's infoframe refactoring changes. Fixed non modeset > case for HDR metadata update. Dropped a redundant patch. > > v6: Addressed Shashank's review comments and added RB's received. > > v7: Squashed 2 patches, dropped 1 change and addressed Brian Starkey's and > Shashank's review comments. > > v8: Addressed Jonas Karlman review comments. Added Shashank's RB to the > series, > fixed a WARN_ON on BYT/CHT. > > v9: Addressed Ville and Jonas Karlman's review comments. Added the infoframe > state readout and metadata reference count. > > v10: Addressed review comments from Jonas and Ville. Dropped one patch related > to i915 fastset handling as per Ville's feedback. > > v11: Addressed Ville's review comments. > > Note: v9 version is already tested with Kodi and a confirmation from team > kodi has been > received. Branch details for the same as below: > https://github.com/xbmc/xbmc/tree/feature_drmprime-vaapi > > v9 of this series is: > Tested-by: Jonas Karlman > > Jonas Karlman (1): > drm: Add reference counting on HDR metadata blob > > Uma Shankar (9): > drm: Add HDR source metadata property > drm: Parse HDR metadata info from EDID > drm: Enable HDR infoframe support > drm/i915: Attach HDR metadata property to connector > drm/i915: Write HDR infoframe and send to panel > drm/i915:Enabled Modeset when HDR Infoframe changes > drm/i915: Added DRM Infoframe handling for BYT/CHT > video/hdmi: Add Unpack function for DRM infoframe > drm/i915: Add state readout for DRM infoframe > > Ville Syrjälä (2): > drm: Add HLG EOTF > drm/i915: Enable infoframes on GLK+ for HDR > > drivers/gpu/drm/drm_atomic_state_helper.c | 5 + > drivers/gpu/drm/drm_atomic_uapi.c | 12 ++ > drivers/gpu/drm/drm_connector.c | 6 + > drivers/gpu/drm/drm_edid.c| 124 ++ > drivers/gpu/drm/i915/i915_reg.h | 4 + > drivers/gpu/drm/i915/intel_atomic.c | 14 +- > drivers/gpu/drm/i915/intel_ddi.c | 3 + > drivers/gpu/drm/i915/intel_display.c | 1 + > drivers/gpu/drm/i915/intel_drv.h | 1 + > drivers/gpu/drm/i915/intel_hdmi.c | 67 +++- > drivers/video/hdmi.c | 257 > ++ > include/drm/drm_connector.h | 10 ++ > include/drm/drm_edid.h| 5 + > include/drm/drm_mode_config.h | 7 + > include/linux/hdmi.h | 55 +++ > include/uapi/drm/drm_mode.h | 23 +++ > 16 files changed, 589 insertions(+), 5 deletions(-) > > -- > 1.9.1 > > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list
Re: [PATCH v6 1/2] drm/sched: Refactor ring mirror list handling.
On Thu, Dec 27, 2018 at 8:28 PM Andrey Grodzovsky
wrote:
>
> Decauple sched threads stop and start and ring mirror
> list handling from the policy of what to do about the
> guilty jobs.
> When stoppping the sched thread and detaching sched fences
> from non signaled HW fenes wait for all signaled HW fences
> to complete before rerunning the jobs.
>
> v2: Fix resubmission of guilty job into HW after refactoring.
>
> v4:
> Full restart for all the jobs, not only from guilty ring.
> Extract karma increase into standalone function.
>
> v5:
> Rework waiting for signaled jobs without relying on the job
> struct itself as those might already be freed for non 'guilty'
> job's schedulers.
> Expose karma increase to drivers.
>
> v6:
> Use list_for_each_entry_safe_continue and drm_sched_process_job
> in case fence already signaled.
> Call drm_sched_increase_karma only once for amdgpu and add documentation.
>
> Suggested-by: Christian Koenig
> Signed-off-by: Andrey Grodzovsky
./drivers/gpu/drm/scheduler/sched_main.c:429: warning: Function
parameter or member 'full_recovery' not described in 'drm_sched_start'
Please fix, thanks.
-Daniel
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 20 ++-
> drivers/gpu/drm/etnaviv/etnaviv_sched.c| 11 +-
> drivers/gpu/drm/scheduler/sched_main.c | 195
> +++--
> drivers/gpu/drm/v3d/v3d_sched.c| 12 +-
> include/drm/gpu_scheduler.h| 8 +-
> 5 files changed, 157 insertions(+), 89 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 98df8e4..6a0601c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -3298,17 +3298,15 @@ static int amdgpu_device_pre_asic_reset(struct
> amdgpu_device *adev,
> if (!ring || !ring->sched.thread)
> continue;
>
> - kthread_park(ring->sched.thread);
> -
> - if (job && job->base.sched != >sched)
> - continue;
> -
> - drm_sched_hw_job_reset(>sched, job ? >base : NULL);
> + drm_sched_stop(>sched, job ? >base : NULL);
>
> /* after all hw jobs are reset, hw fence is meaningless, so
> force_completion */
> amdgpu_fence_driver_force_completion(ring);
> }
>
> + if(job)
> + drm_sched_increase_karma(>base);
> +
>
>
> if (!amdgpu_sriov_vf(adev)) {
> @@ -3454,14 +3452,10 @@ static void amdgpu_device_post_asic_reset(struct
> amdgpu_device *adev,
> if (!ring || !ring->sched.thread)
> continue;
>
> - /* only need recovery sched of the given job's ring
> -* or all rings (in the case @job is NULL)
> -* after above amdgpu_reset accomplished
> -*/
> - if ((!job || job->base.sched == >sched) &&
> !adev->asic_reset_res)
> - drm_sched_job_recovery(>sched);
> + if (!adev->asic_reset_res)
> + drm_sched_resubmit_jobs(>sched);
>
> - kthread_unpark(ring->sched.thread);
> + drm_sched_start(>sched, !adev->asic_reset_res);
> }
>
> if (!amdgpu_device_has_dc_support(adev)) {
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> index 49a6763..6f1268f 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> @@ -109,16 +109,19 @@ static void etnaviv_sched_timedout_job(struct
> drm_sched_job *sched_job)
> }
>
> /* block scheduler */
> - kthread_park(gpu->sched.thread);
> - drm_sched_hw_job_reset(>sched, sched_job);
> + drm_sched_stop(>sched, sched_job);
> +
> + if(sched_job)
> + drm_sched_increase_karma(sched_job);
>
> /* get the GPU back into the init state */
> etnaviv_core_dump(gpu);
> etnaviv_gpu_recover_hang(gpu);
>
> + drm_sched_resubmit_jobs(>sched);
> +
> /* restart scheduler after GPU is usable again */
> - drm_sched_job_recovery(>sched);
> - kthread_unpark(gpu->sched.thread);
> + drm_sched_start(>sched, true);
> }
>
> static void etnaviv_sched_free_job(struct drm_sched_job *sched_job)
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> b/drivers/gpu/drm/scheduler/sched_main.c
> index dbb6906..54e809b 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -60,8 +60,6 @@
>
> static void drm_sched_process_job(struct dma_fence *f, struct dma_fence_cb
> *cb);
>
> -static void drm_sched_expel_job_unlocked(struct drm_sched_job *s_job);
> -
> /**
> * drm_sched_rq_init - initialize a given run queue struct
> *
> @@ -335,6 +333,51 @@ static void drm_sched_job_timedout(struct work_struct
> *work)
>
Re: [Freedreno] [PATCH RFC v2 0/6] ARM: qcom: initial Nexus 5 display support
On Wed, May 29, 2019 at 4:28 AM Brian Masney wrote: > > On Tue, May 28, 2019 at 08:53:49PM -0600, Jeffrey Hugo wrote: > > On Tue, May 28, 2019 at 8:46 PM Brian Masney wrote: > > > > > > On Tue, May 28, 2019 at 07:42:19PM -0600, Jeffrey Hugo wrote: > > > > > > Do you know if the nexus 5 has a video or command mode panel? There > > > > > > is some glitchyness with vblanks and command mode panels. > > > > > > > > > > Its in command mode. I know this because I see two 'pp done time out' > > > > > messages, even on 4.17. Based on my understanding, the ping pong code > > > > > is > > > > > only applicable for command mode panels. > > > > > > > > Actually, the ping pong element exists in both modes, but 'pp done > > > > time out' is a good indicator that it is command mode. > > > > > > > > Are you also seeing vblank timeouts? > > > > > > Yes, here's a snippet of the first one. > > > > > > [2.556014] WARNING: CPU: 0 PID: 5 at > > > drivers/gpu/drm/drm_atomic_helper.c:1429 > > > drm_atomic_helper_wait_for_vblanks.part.1+0x288/0x290 > > > [2.556020] [CRTC:49:crtc-0] vblank wait timed out > > > [2.556023] Modules linked in: > > > [2.556034] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted > > > 5.2.0-rc1-00178-g72c3c1fd5f86-dirty #426 > > > [2.556038] Hardware name: Generic DT based system > > > [2.556056] Workqueue: events deferred_probe_work_func > > > ... > > > > > > > Do you have busybox? > > > > > > > > Can you run - > > > > sudo busybox devmem 0xFD900614 > > > > sudo busybox devmem 0xFD900714 > > > > sudo busybox devmem 0xFD900814 > > > > sudo busybox devmem 0xFD900914 > > > > sudo busybox devmem 0xFD900A14 > > > > > > # busybox devmem 0xFD900614 > > > 0x00020020 > > > > Ok, so CTL_0 path, command mode, ping pong 0, with the output going to DSI > > 1. > > > > Next one please: > > > > busybox devmem 0xFD912D30 > > It's 0x on mainline and 4.17. I used the following script to > dump the entire mdp5 memory region and attached the dump from 4.17 and > 5.2rc1. > ok, 0 means autorefresh is not on. Which is fine. My next guess would be the vblank code checking the hardware vblank counter, which doesn't exist. In video mode, there is a frame counter which increments, which can be used as the vblank counter. Unfortunately, that hardware isn't active in command mode, and there isn't an equivalent. So, the vblank code is going to read the register, and look for an update, which will never happen, thus it will timeout. There is a backup path which uses timestamps (no hardware), which you can activate with a quick hack - make max_vblank_count = 0 at the following line https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c#L753
Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround
On 2019/05/29, Koenig, Christian wrote: > Am 29.05.19 um 15:03 schrieb Emil Velikov: > > On 2019/05/29, Dave Airlie wrote: > >> On Wed, 29 May 2019 at 02:47, Emil Velikov > >> wrote: > >>> On 2019/05/28, Koenig, Christian wrote: > Am 28.05.19 um 18:10 schrieb Emil Velikov: > > On 2019/05/28, Daniel Vetter wrote: > >> On Tue, May 28, 2019 at 10:03 AM Koenig, Christian > >> wrote: > >>> Am 28.05.19 um 09:38 schrieb Daniel Vetter: > [SNIP] > > Might be a good idea looking into reverting it partially, so that at > > least command submission and buffer allocation is still blocked. > I thought the issue is a lot more than vainfo, it's pretty much every > hacked up compositor under the sun getting this wrong one way or > another. Thinking about this some more, I also have no idea how you'd > want to deprecate rendering on primary nodes in general. Apparently > that breaks -modesetting already, and probably lots more compositors. > And it looks like we're finally achieve the goal kms set out to 10 > years ago, and new compositors are sprouting up all the time. I guess > we could just break them all (on new hardware) and tell them to all > suck it up. But I don't think that's a great option. And just > deprecating this on amdgpu is going to be even harder, since then > everywhere else it'll keep working, and it's just amdgpu.ko that > looks > broken. > > Aside: I'm not supporting Emil's idea here because it fixes any > issues > Intel has - Intel doesn't care. I support it because reality sucks, > people get this render vs. primary vs. multi-gpu prime wrong all the > time (that's also why we have hardcoded display+gpu pairs in mesa for > the various soc combinations out there), and this looks like a > pragmatic solution. It'd be nice if every compositor and everything > else would perfectly support multi gpu and only use render nodes for > rendering, and only primary nodes for display. But reality is that > people hack on stuff until gears on screen and then move on to more > interesting things (to them). So I don't think we'll ever win this > :-/ > >>> Yeah, but this is a classic case of working around user space issues > >>> by > >>> making kernel changes instead of fixing user space. > >>> > >>> Having privileged (output control) and unprivileged (rendering > >>> control) > >>> functionality behind the same node is a mistake we have made a long > >>> time > >>> ago and render nodes finally seemed to be a way to fix that. > >>> > >>> I mean why are compositors using the primary node in the first place? > >>> Because they want to have access to privileged resources I think and > >>> in > >>> this case it is perfectly ok to do so. > >>> > >>> Now extending unprivileged access to the primary node actually sounds > >>> like a step into the wrong direction to me. > >>> > >>> I rather think that we should go down the route of completely dropping > >>> command submission and buffer allocation through the primary node for > >>> non master clients. And then as next step at some point drop support > >>> for > >>> authentication/flink. > >>> > >>> I mean we have done this with UMS as well and I don't see much other > >>> way > >>> to move forward and get rid of those ancient interface in the long > >>> term. > >> Well kms had some really good benefits that drove quick adoption, like > >> "suspend/resume actually has a chance of working" or "comes with > >> buffer management so you can run multiple gears". > >> > >> The render node thing is a lot more niche use case (prime, better priv > >> separation), plus "it's cleaner design". And the "cleaner design" part > >> is something that empirically doesn't seem to matter :-/ Just two > >> examples: > >> - KHR_display/leases just iterated display resources on the fd needed > >> for rendering (and iirc there was even a patch to expose that for > >> render nodes too so it works with DRI3), because implementing > >> protocols is too hard. Barely managed to stop that one before it > >> happened. > >> - Various video players use the vblank ioctl on directly to schedule > >> frames, without telling the compositor. I discovered that when I > >> wanted to limite the vblank ioctl to master clients only. Again, > >> apparently too hard to use the existing extensions, or fix the bugs in > >> there, or whatever. One userspace got fixed last year, but it'll > >> probably get copypasted around forever :-/ > >> > >> So I don't think we'll ever manage to roll a clean split out, and best > >> we can do is give in
Re: [PATCH 2/2] drm/edid: Ignore "DFP 1.x" bit for EDID 1.2 and earlier
On Wed, May 29, 2019 at 7:02 AM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> From VESA EDID implementation guide v1.0:
> "For EDID version 1 revision 2 or earlier data structures when offset 14h
> bit 7 is set to one, the value of bits 6-0 are undefined, and therefore
> cannot be interpreted to mean anything."
>
> And since EDID 1.4 redefines that bit let's consult it only for
> EDID 1.3.
>
> Cc: Mario Kleiner
> Signed-off-by: Ville Syrjälä
Yes. Series is:
Reviewed-by: Mario Kleiner
-mario
On Wed, May 29, 2019 at 3:50 PM Alex Deucher wrote:
>
> On Wed, May 29, 2019 at 7:02 AM Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > From VESA EDID implementation guide v1.0:
> > "For EDID version 1 revision 2 or earlier data structures when offset 14h
> > bit 7 is set to one, the value of bits 6-0 are undefined, and therefore
> > cannot be interpreted to mean anything."
> >
> > And since EDID 1.4 redefines that bit let's consult it only for
> > EDID 1.3.
> >
> > Cc: Mario Kleiner
> > Signed-off-by: Ville Syrjälä
>
> Series is:
> Reviewed-by: Alex Deucher
>
> > ---
> > drivers/gpu/drm/drm_edid.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index dd601ed6a30e..c3296a72fff9 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -4569,8 +4569,8 @@ u32 drm_add_display_info(struct drm_connector
> > *connector, const struct edid *edi
> > * tells us to assume 8 bpc color depth if the EDID doesn't have
> > * extensions which tell otherwise.
> > */
> > - if ((info->bpc == 0) && (edid->revision < 4) &&
> > - (edid->input & DRM_EDID_DIGITAL_DFP_1_X)) {
> > + if (info->bpc == 0 && edid->revision == 3 &&
> > + edid->input & DRM_EDID_DIGITAL_DFP_1_X) {
> > info->bpc = 8;
> > DRM_DEBUG("%s: Assigning DFP sink color depth as %d bpc.\n",
> > connector->name, info->bpc);
> > --
> > 2.21.0
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH][next] drm/i915: fix uninitialized variable 'subslice_mask'
From: Colin Ian King
Currently subslice_mask is not initialized and so data is being
bit-wise or'd into a garbage value. Fix this by inintializing
subslice_mask to zero.
Addresses-Coverity: ("Uninitialized scalar variable")
Fixes: 1ac159e23c2c ("drm/i915: Expand subslice mask")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/intel_device_info.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index 3625f777f3a3..d395a09b994f 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -298,7 +298,7 @@ static void cherryview_sseu_info_init(struct
drm_i915_private *dev_priv)
{
struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
u32 fuse;
- u8 subslice_mask;
+ u8 subslice_mask = 0;
fuse = I915_READ(CHV_FUSE_GT);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 0/6] Allwinner H6 Mali GPU support
On Tue, 21 May 2019 at 18:11, Clément Péron wrote: > [snip] > [ 345.204813] panfrost 180.gpu: mmu irq status=1 > [ 345.209617] panfrost 180.gpu: Unhandled Page fault in AS0 at VA > 0x02400400 >From what I can see here, 0x02400400 points to the first byte of the first submitted job descriptor. So mapping buffers for the GPU doesn't seem to be working at all on 64-bit T-760. Steven, Robin, do you have any idea of why this could be? Thanks, Tomeu
[PATCH v2 1/2] a5xx: Define HLSQ_DBG_ECO_CNTL
--- rnndb/adreno/a5xx.xml | 1 + 1 file changed, 1 insertion(+) diff --git a/rnndb/adreno/a5xx.xml b/rnndb/adreno/a5xx.xml index ae654eeb..16203512 100644 --- a/rnndb/adreno/a5xx.xml +++ b/rnndb/adreno/a5xx.xml @@ -1523,6 +1523,7 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ rules-ng.xsd"> + -- 2.17.1
[PATCH v2 0/2] Adreno A540 support
Adreno driver support for the A540 found in the MSM8998 SoC v2: -Removed extra RBBM write -Corrected added RBBM writes to allow for hwcg disable -Patch to add REG_A5XX_HLSQ_DBG_ECO_CNTL to envytools -Regenerated a5xx header file with updated envytools -Used REG_A5XX_HLSQ_DBG_ECO_CNTL in code -Stripped extranious magic number comment Jeffrey Hugo (1): drm/msm/adreno: Add A540 support drivers/gpu/drm/msm/adreno/a5xx.xml.h | 28 drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 21 ++ drivers/gpu/drm/msm/adreno/a5xx_power.c| 76 +- drivers/gpu/drm/msm/adreno/adreno_device.c | 18 + drivers/gpu/drm/msm/adreno/adreno_gpu.h| 6 ++ 5 files changed, 133 insertions(+), 16 deletions(-) -- 2.17.1
[Bug 110781] Radeon: heavy r300 performance drop regression between 11.x and 19.x
https://bugs.freedesktop.org/show_bug.cgi?id=110781 --- Comment #5 from Richard Thier --- Still fast with mesa 17.2.8 and X.Org X Server 1.19.5 The problem is somewhere between 17.x and 19.x mesa versions (and corresponding xorg). Also I have made an strace when it is good in one older system to see number of CREATE and CLOSE ioctl calls (also the number of CS ioctl calls) are a magnitude smaller than in case of 19.x! For example 10-20 seconds of glxgears running leads to 9-10 calls to DRM_IOCTL_RADEON_GEM_CREATE on mesa 17.2.8 while it leads to 708 (!!!) number of same calls in the same time period on mesa 19.x! This is surely a quite big of a difference! The similar pattern in 17.x is never creating a new gem object: ... ioctl(6, DRM_IOCTL_RADEON_GEM_WAIT_IDLE, 0xbfcf9f04) = 0 <0.55> ioctl(6, DRM_IOCTL_RADEON_GEM_BUSY, 0xbfcf9d44) = 0 <0.22> ioctl(6, DRM_IOCTL_RADEON_CS, 0xb307d03c) = 0 <0.89> ioctl(6, DRM_IOCTL_RADEON_GEM_WAIT_IDLE, 0xbfcf9f04) = 0 <0.53> ioctl(6, DRM_IOCTL_RADEON_GEM_BUSY, 0xbfcf9d44) = 0 <0.23> ioctl(6, DRM_IOCTL_RADEON_CS, 0xb30910d0) = 0 <0.95> ioctl(6, DRM_IOCTL_RADEON_GEM_WAIT_IDLE, 0xbfcf9f04) = 0 <0.54> ioctl(6, DRM_IOCTL_RADEON_GEM_BUSY, 0xbfcf9d44) = 0 <0.23> ioctl(6, DRM_IOCTL_RADEON_CS, 0xb307d03c) = 0 <0.90> ... Sometimes when the *_BUSY ioctl call returns -1, it issues a CREATE, but otherwise not. I think GEM is some kind of memory handler for the GPU (just like "ttm" in the perf output) and I think something have messed up with memory handling schemes for Mobility Radeon 200M (r300) at some mesa update between 17.x and 19.x. Will try to bisect a closer version as 17.2.8 is from 2017.12.22 in time... -- 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][next] drm/i915: fix uninitialized variable 'subslice_mask'
On Wed, 29 May 2019, Colin King wrote:
> From: Colin Ian King
>
> Currently subslice_mask is not initialized and so data is being
> bit-wise or'd into a garbage value. Fix this by inintializing
> subslice_mask to zero.
>
> Addresses-Coverity: ("Uninitialized scalar variable")
> Fixes: 1ac159e23c2c ("drm/i915: Expand subslice mask")
This was already reverted for other reasons. Need to be fixed on the
next round. For future reference, please Cc: author and reviewers of the
referenced commit.
BR,
Jani.
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/i915/intel_device_info.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c
> b/drivers/gpu/drm/i915/intel_device_info.c
> index 3625f777f3a3..d395a09b994f 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -298,7 +298,7 @@ static void cherryview_sseu_info_init(struct
> drm_i915_private *dev_priv)
> {
> struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
> u32 fuse;
> - u8 subslice_mask;
> + u8 subslice_mask = 0;
>
> fuse = I915_READ(CHV_FUSE_GT);
--
Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH] drm: Fix docbook warnings in hdr metadata helper structures
On Wed, May 29, 2019 at 4:16 PM Uma Shankar wrote:
>
> Fixes the following warnings:
> ./include/drm/drm_mode_config.h:841: warning: Incorrect use of
> kernel-doc format: * hdr_output_metadata_property: Connector
> property containing hdr
> ./include/drm/drm_mode_config.h:918: warning: Function parameter or member
> 'hdr_output_metadata_property' not described in 'drm_mode_config'
> ./include/drm/drm_connector.h:1251: warning: Function parameter or member
> 'hdr_output_metadata' not described in 'drm_connector'
> ./include/drm/drm_connector.h:1251: warning: Function parameter or member
> 'hdr_sink_metadata' not described in 'drm_connector'
>
> Also adds some property documentation for HDR Metadata Connector
> Property in connector property create function.
>
> 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: Uma Shankar
> ---
> drivers/gpu/drm/drm_connector.c | 8
> include/drm/drm_connector.h | 3 ++-
> include/drm/drm_mode_config.h | 2 +-
> include/linux/hdmi.h| 1 +
> 4 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index c9ac8b9..702307c 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1003,6 +1003,14 @@ int drm_display_info_set_bus_formats(struct
> drm_display_info *info,
> * can also expose this property to external outputs, in which case they
> * must support "None", which should be the default (since external
> screens
> * have a built-in scaler).
> + *
> + * HDR_OUTPUT_METADATA:
> + * Connector property to enable userspace to send HDR Metadata to driver.
> + * This metadata is based on the composition and blending policies
> decided
> + * by user, taking into account the hardware and sink capabilties.
> + * The driver gets this metadata and creates a Dynamic Range and
> Mastering
> + * Infoframe (DRM) which is then sent to sink. This notifies the sink of
> + * the upcoming frame's Color Encoding and Luminance parameters.
> */
Assuming I'm applying this correctly your adding this to the "lcd
panel properties" section. That doesn't make sense to me. I think we
already have a section for hdmi properties somewhere, would fit better
there.
This should also contain a bit more about how this is supposed to
work, how it's set up from a driver pov (sprinkle links all over it)
and how userspace it supposed to use it.
I think since this is a using a rather complicated struct I think we
need to fully document that structure too. Atm uapi/drm_mode.h isn't
pulled into anywhere, so we need to fix that (a new chapter titled
"Userspace API Structures" in drm-uapi.rst would be good, cross-links
will work).
>
> int drm_connector_create_standard_properties(struct drm_device *dev)
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index f8f4003..f226ef0 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -1244,8 +1244,9 @@ struct drm_connector {
> */
> struct llist_node free_node;
>
> - /* HDR metdata */
> + /** @hdr_output_metadata: HDR Metadata to be sent to sink */
> struct hdr_output_metadata hdr_output_metadata;
Uh, is this even used? It would be a bug if so, since the state
userspace can set must be stored in drm_connector_state, not in
drm_connector. Only read-only stuff can be in there.
Please don't just blindly type docs, try to make sure that what you're
documenting actually makes sense. Also, should have been a clear sign
that you've forgotten to document one of the properties in the
enumeration above.
-Daniel
> + /** @hdr_sink_metadata: HDR Metadata Information read from sink */
> struct hdr_sink_metadata hdr_sink_metadata;
> };
>
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 4f88cc9..0b180e0 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -837,7 +837,7 @@ struct drm_mode_config {
> struct drm_property *writeback_out_fence_ptr_property;
>
> /**
> -* hdr_output_metadata_property: Connector property containing hdr
> +* @hdr_output_metadata_property: Connector property containing hdr
> * metatda. This will be provided by userspace compositors based
> * on HDR content
> */
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index ee55ba5..ea5858e 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -398,6 +398,7 @@ ssize_t hdmi_vendor_infoframe_pack_only(const struct
> hdmi_vendor_infoframe *fram
> * @spd: spd infoframe
> * @vendor: union of all vendor
Re: [PATCH][next] drm/i915: fix uninitialized variable 'mask'
On Wed, 29 May 2019, Colin King wrote:
> From: Colin Ian King
>
> Currently mask is not initialized and so data is being bit-wise or'd into
> a garbage value. Fix this by inintializing mask to zero.
>
> Addresses-Coverity: ("Uninitialized scalar variable")
> Fixes: 1ac159e23c2c ("drm/i915: Expand subslice mask")
This was already reverted for other reasons. Need to be fixed on the
next round. For future reference, please Cc: author and reviewers of the
referenced commit.
BR,
Jani.
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/i915/gt/intel_sseu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
> b/drivers/gpu/drm/i915/gt/intel_sseu.c
> index 763b811f2c9d..5a89672d98a2 100644
> --- a/drivers/gpu/drm/i915/gt/intel_sseu.c
> +++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
> @@ -41,7 +41,7 @@ void intel_sseu_copy_subslices(const struct sseu_dev_info
> *sseu, int slice,
> u32 intel_sseu_get_subslices(const struct sseu_dev_info *sseu, u8 slice)
> {
> int i, offset = slice * sseu->ss_stride;
> - u32 mask;
> + u32 mask = 0;
>
> GEM_BUG_ON(slice >= sseu->max_slices);
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH][next] drm/amdkfd: fix null pointer dereference on dev
From: Colin Ian King
The pointer dev is set to null yet it is being dereferenced when
checking dev->dqm->sched_policy. Fix this by performing the check
on dev->dqm->sched_policy after dev has been assigned and null
checked. Also remove the redundant null assignment to dev.
Addresses-Coverity: ("Explicit null dereference")
Fixes: 1a058c337676 ("drm/amdkfd: New IOCTL to allocate queue GWS")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index aab2aa6c1dee..ea82828fdc76 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -1572,10 +1572,9 @@ static int kfd_ioctl_alloc_queue_gws(struct file *filep,
{
int retval;
struct kfd_ioctl_alloc_queue_gws_args *args = data;
- struct kfd_dev *dev = NULL;
+ struct kfd_dev *dev;
- if (!hws_gws_support ||
- dev->dqm->sched_policy == KFD_SCHED_POLICY_NO_HWS)
+ if (!hws_gws_support)
return -EINVAL;
dev = kfd_device_by_id(args->gpu_id);
@@ -1583,6 +1582,8 @@ static int kfd_ioctl_alloc_queue_gws(struct file *filep,
pr_debug("Could not find gpu id 0x%x\n", args->gpu_id);
return -EINVAL;
}
+ if (dev->dqm->sched_policy == KFD_SCHED_POLICY_NO_HWS)
+ return -EINVAL;
mutex_lock(>mutex);
retval = pqm_set_gws(>pqm, args->queue_id, args->num_gws ? dev->gws
: NULL);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110658] MXGP3 (Steam, native Linux port, UE4): graphical glitches
https://bugs.freedesktop.org/show_bug.cgi?id=110658 --- Comment #5 from Alexander Mezin --- (In reply to Timothy Arceri from comment #3) > Are you able to test with llvm 9? I won't have time for that until weekend (In reply to Timothy Arceri from comment #4) > I've run it on llvm 8 and mesa 19.0.5 and was unable to reproduce the issues > seen in the screen capture on my Vega 64. Just re-tested with mesa 19.0.5+llvm 8, the issue is still there. It seems to be track-specific. At least it doesn't happen on "Compound", for example. Also the game runs fine under Proton/SteamPlay (no glitches/artifacts). -- 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
