Re: [PATCH 02/10] drm: xlnx: Add xlnx crtc of Xilinx DRM KMS
On Thu, Jan 11, 2018 at 02:04:47AM +, Hyun Kwon wrote:
> Hi Daniel,
>
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Tuesday, January 09, 2018 1:38 AM
> > To: Hyun Kwon
> > Cc: dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; Michal
> > Simek
> > Subject: Re: [PATCH 02/10] drm: xlnx: Add xlnx crtc of Xilinx DRM KMS
> >
> > On Thu, Jan 04, 2018 at 06:05:51PM -0800, Hyun Kwon wrote:
> > > xlnx_crtc is a part of Xilinx DRM KMS and a layer that
> > > provides some interface between the Xilinx DRM KMS and
> > > crtc drivers.
> > >
> > > Signed-off-by: Hyun Kwon
> >
> > Personal style, but I don't see much value in these small helpers.
> > Splitting them from the main driver at least makes reading the patches a
> > bit harder. But no strong opinion, just a bikeshed, feel free to ignore
> > :-)
>
> I also don't, but some reviewers prefer this way. I'll leave it this way for
> now. :-)
Patch splitting is good imo, but I don't like free-standing new code. Imo
all functions you're adding need to have a caller (or at least be part of
a function table), so that it's clear how they're used. Without the users
being known it's not possible to review the code, rendering the splitting
pointless.
But splitting itself isn't a bad idea, just not splitting so much that the
individual patches dont' make sense anymore :-)
-Daniel
>
> Thanks,
> -hyun
>
> > -Daniel
> >
> > > ---
> > > drivers/gpu/drm/xlnx/xlnx_crtc.c | 194
> > +++
> > > drivers/gpu/drm/xlnx/xlnx_crtc.h | 70 ++
> > > 2 files changed, 264 insertions(+)
> > > create mode 100644 drivers/gpu/drm/xlnx/xlnx_crtc.c
> > > create mode 100644 drivers/gpu/drm/xlnx/xlnx_crtc.h
> > >
> > > diff --git a/drivers/gpu/drm/xlnx/xlnx_crtc.c
> > b/drivers/gpu/drm/xlnx/xlnx_crtc.c
> > > new file mode 100644
> > > index 000..57ee939
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/xlnx/xlnx_crtc.c
> > > @@ -0,0 +1,194 @@
> > > +/*
> > > + * Xilinx DRM crtc driver
> > > + *
> > > + * Copyright (C) 2017 - 2018 Xilinx, Inc.
> > > + *
> > > + * Author: Hyun Woo Kwon
> > > + *
> > > + * SPDX-License-Identifier: GPL-2.0
> > > + */
> > > +
> > > +#include
> > > +
> > > +#include
> > > +
> > > +#include "xlnx_crtc.h"
> > > +
> > > +/*
> > > + * Overview
> > > + *
> > > + *
> > > + * The Xilinx CRTC layer is to enable the custom interface to CRTC
> > > drivers.
> > > + * The interface is used by Xilinx DRM driver where it needs CRTC
> > > + * functionailty. CRTC drivers should attach the desired callbacks
> > > + * to struct xlnx_crtc and register the xlnx_crtc with correcsponding
> > > + * drm_device. It's highly recommended CRTC drivers register all
> > callbacks
> > > + * even though many of them are optional.
> > > + * The CRTC helper simply walks through the registered CRTC device,
> > > + * and call the callbacks.
> > > + */
> > > +
> > > +/**
> > > + * struct xlnx_crtc_helper - Xilinx CRTC helper
> > > + * @xlnx_crtcs: list of Xilinx CRTC devices
> > > + * @lock: lock to protect @xlnx_crtcs
> > > + * @drm: back pointer to DRM core
> > > + */
> > > +struct xlnx_crtc_helper {
> > > + struct list_head xlnx_crtcs;
> > > + struct mutex lock; /* lock for @xlnx_crtcs */
> > > + struct drm_device *drm;
> > > +};
> > > +
> > > +#define XLNX_CRTC_MAX_HEIGHT_WIDTH UINT_MAX
> > > +
> > > +int xlnx_crtc_helper_enable_vblank(struct xlnx_crtc_helper *helper,
> > > +unsigned int crtc_id)
> > > +{
> > > + struct xlnx_crtc *crtc;
> > > +
> > > + list_for_each_entry(crtc, &helper->xlnx_crtcs, list)
> > > + if (drm_crtc_index(&crtc->crtc) == crtc_id)
> > > + if (crtc->enable_vblank)
> > > + return crtc->enable_vblank(crtc);
> > > + return -ENODEV;
> > > +}
> > > +
> > > +void xlnx_crtc_helper_disable_vblank(struct xlnx_crtc_helper *helper,
> > > + unsigned int crtc_id)
> > > +{
> > > + struct xlnx_crtc *crtc;
> > > +
> > > + list_for_each_entry(crtc, &helper->xlnx_crtcs, list) {
> > > + if (drm_crtc_index(&crtc->crtc) == crtc_id) {
> > > + if (crtc->disable_vblank)
> > > + crtc->disable_vblank(crtc);
> > > + return;
> > > + }
> > > + }
> > > +}
> > > +
> > > +unsigned int xlnx_crtc_helper_get_align(struct xlnx_crtc_helper *helper)
> > > +{
> > > + struct xlnx_crtc *crtc;
> > > + unsigned int align = 1, tmp;
> > > +
> > > + list_for_each_entry(crtc, &helper->xlnx_crtcs, list) {
> > > + if (crtc->get_align) {
> > > + tmp = crtc->get_align(crtc);
> > > + align = ALIGN(align, tmp);
> > > + }
> > > + }
> > > +
> > > + return align;
> > > +}
> > > +
> > > +u64 xlnx_crtc_helper_get_dma_mask(struct xlnx_crtc_helper *helper)
> > > +{
> > > + struct xlnx_crtc *crtc;
> > > + u64 mask = DMA_BIT_MASK(sizeof(dma_addr
Re: [RFC v2 6/8] drm: Handle fbdev emulation in core
On Wed, Jan 10, 2018 at 06:02:38PM +0100, Noralf Trønnes wrote:
>
> Den 09.01.2018 11.38, skrev Daniel Vetter:
> > On Wed, Jan 03, 2018 at 11:21:08PM +0100, Noralf Trønnes wrote:
> > > Prepare for generic fbdev emulation by letting DRM core work directly
> > > with the fbdev compatibility layer. This is done by adding new fbdev
> > > helper vtable callbacks for restore, hotplug_event, unregister and
> > > release.
> > >
> > > Signed-off-by: Noralf Trønnes
> > No clue whether my idea is any good, but inspired by the bootsplash
> > discussion, and the prospect that we might get other in-kernel drm/kms
> > clients I'm wondering whether we should make this a bit more generic and
> > tie it to drm_file?
> >
> > The idea would be to have a list of internal drm clients by putting all
> > the internal drm_files onto a list (same way we do with the userspace
> > ones). Then we'd just walk that list and call ->hotplug, ->unregister and
> > ->release at the right places.
> >
> > ->restore would be a bit different, I guess for that we'd only call the
> > ->restore callback of the very first kernel-internal client.
> >
> > With that we could then add/remove kernel-internal drm clients like normal
> > userspace clients, which should make integration of emergency consoles,
> > boot splashes and whatever else real easy. And I think it would be a lot
> > cleaner than leaking fb_helper knowledge into the drm core, which feels a
> > rather backwards.
> >
> > Otoh that feels a bit overengineered (but at least it shouldn't be a lot
> > more code really). If the list is too much work we could start with 1
> > drm_file * pointer for internal stuff (but would still need locking, so
> > list_head is probably easier).
> >
> > Thoughts?
>
> I prefer to have a proper in-kernel client API from the get go, instead
> of fixing it up later. The reason I skipped spending time on it in this
> RFC, was that I didn't know if I was on the right track at the right time
> to get the necessary attention to make this dumb_buffer idea happen.
>
> With a drm_file centric approach, are you thinking something like this:
>
> struct drm_device {
> + struct list_head filelist_internal;
> };
>
> +struct drm_file_funcs {
> + int (*restore)(struct drm_file *file);
> + void (*hotplug)(struct drm_file *file);
> + void (*unregister)(struct drm_file *file);
I guess we still need a cleanup callback here? For the usual two-stage
driver unload sequence of 1. unregister 2. cleanup.
> +};
>
> struct drm_file {
> + struct drm_device *dev;
> + const struct drm_file_funcs *funcs;
> };
>
> struct drm_file *drm_file_alloc(struct drm_minor *minor)
> {
> + file->dev = dev;
> }
>
> struct drm_file* drm_internal_open(struct drm_device *dev,
> const struct drm_file_funcs *funcs)
> struct drm_file *file;
> int ret;
>
> if (!try_module_get(dev->driver->fops->owner))
> return ERR_PTR(-ENODEV);
>
> drm_dev_ref(dev);
>
> file = drm_file_alloc(dev);
> if (IS_ERR(file)) {
> drm_dev_unref(dev);
> module_put(dev->driver->fops->owner);
> return file;
> }
>
> file->funcs = funcs;
>
> mutex_lock(&dev->filelist_mutex);
> list_add(&file->lhead, &dev->filelist_internal);
> mutex_unlock(&dev->filelist_mutex);
>
> return file;
> }
>
> void drm_internal_release(struct drm_file *file)
> {
> struct drm_device *dev = file->dev;
>
> mutex_lock(&dev->filelist_mutex);
> list_del(&file->lhead);
> mutex_unlock(&dev->filelist_mutex);
>
> drm_file_free(file);
> drm_dev_unref(dev);
> module_put(dev->driver->fops->owner);
> }
>
> void drm_lastclose(struct drm_device *dev)
> {
>
> + mutex_lock(&dev->filelist_mutex);
> + list_for_each_entry(file, &dev->filelist_internal, lhead) {
> + if (file->funcs && file->funcs->restore &&
> + !file->funcs->restore(file))
> + break;
> + mutex_unlock(&dev->filelist_mutex);
> }
>
> void drm_kms_helper_hotplug_event(struct drm_device *dev)
> {
>
> + mutex_lock(&dev->filelist_mutex);
> + list_for_each_entry(file, &dev->filelist_internal, lhead) {
> + if (file->funcs && file->funcs->hotplug)
> + file->funcs->hotplug(file);
> + mutex_unlock(&dev->filelist_mutex);
> }
>
> How is locking done when .unregister will call into drm_internal_release()?
>
> void drm_dev_unregister(struct drm_device *dev)
> {
>
> + list_for_each_entry(file, &dev->filelist_internal, lhead) {
> + if (file->funcs && file->funcs->unregister)
> + file->funcs->unregister(file);
> }
>
> There is also the case where .unregister can't release the drm_file
> because userspace has mmap'ed the buffer (fbdev). The client holds a ref
> on drm_device so cleanup is stalled but that requires a driver that can
> handle that (ref the tinydrm unplug series which is awaiting a timeslot).
Yeah we need the usual split into 2 things, with un
Re: [PATCH 3/3] drm/amdgpu: Move to gtt before cpu accesses dma buf.
Hi Samuel,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.15-rc7 next-20180110]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Samuel-Li/drm-amdgpu-allow-framebuffer-in-GART-memory-as-well/20180106-050432
base: git://people.freedesktop.org/~airlied/linux.git drm-next
smatch warnings:
drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c:226 amdgpu_gem_prime_export() error:
'buf' dereferencing possible ERR_PTR()
#
https://github.com/0day-ci/linux/commit/6aa2afecb5a3efc463d200023839399571404843
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 6aa2afecb5a3efc463d200023839399571404843
vim +/buf +226 drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
6aa2afecb5 Samuel Li 2018-01-04 211
d38ceaf99e Alex Deucher2015-04-20 212 struct dma_buf
*amdgpu_gem_prime_export(struct drm_device *dev,
d38ceaf99e Alex Deucher2015-04-20 213
struct drm_gem_object *gobj,
d38ceaf99e Alex Deucher2015-04-20 214
int flags)
d38ceaf99e Alex Deucher2015-04-20 215 {
d38ceaf99e Alex Deucher2015-04-20 216 struct amdgpu_bo *bo =
gem_to_amdgpu_bo(gobj);
4b277247b1 Christian König 2017-11-13 217 struct dma_buf *buf;
d38ceaf99e Alex Deucher2015-04-20 218
e1eb899b45 Christian König 2017-08-25 219 if
(amdgpu_ttm_tt_get_usermm(bo->tbo.ttm) ||
e1eb899b45 Christian König 2017-08-25 220 bo->flags &
AMDGPU_GEM_CREATE_VM_ALWAYS_VALID)
d38ceaf99e Alex Deucher2015-04-20 221 return ERR_PTR(-EPERM);
d38ceaf99e Alex Deucher2015-04-20 222
4b277247b1 Christian König 2017-11-13 223 buf = drm_gem_prime_export(dev,
gobj, flags);
4b277247b1 Christian König 2017-11-13 224 if (!IS_ERR(buf))
4b277247b1 Christian König 2017-11-13 225 buf->file->f_mapping =
dev->anon_inode->i_mapping;
6aa2afecb5 Samuel Li 2018-01-04 @226 buf->ops = &amdgpu_dmabuf_ops;
6aa2afecb5 Samuel Li 2018-01-04 227
4b277247b1 Christian König 2017-11-13 228 return buf;
d38ceaf99e Alex Deucher2015-04-20 229 }
6aa2afecb5 Samuel Li 2018-01-04 230
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-staging-drm-next 374/955] sound/soc/amd/raven/acp3x-pcm-dma.c:638:22: error: implicit declaration of function 'devm_ioremap'; did you mean 'of_ioremap'?
Hi Maruthi,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: 22531a0d76e105084ebb3b076c93e2923254c9c8
commit: c1888183e1764d55d51ae051bd8651e634febe4d [374/955] ASoC: AMD: enable
ACP3x drivers build
config: sparc-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.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 c1888183e1764d55d51ae051bd8651e634febe4d
# save the attached .config to linux build tree
make.cross ARCH=sparc
All errors (new ones prefixed by >>):
In file included from sound/soc/amd/raven/acp3x-pcm-dma.c:26:0:
sound/soc/amd/raven/acp3x.h: In function 'rv_readl':
sound/soc/amd/raven/acp3x.h:28:9: error: implicit declaration of function
'readl'; did you mean 'vread'? [-Werror=implicit-function-declaration]
return readl(base_addr - ACP3x_PHY_BASE_ADDRESS);
^
vread
sound/soc/amd/raven/acp3x.h: In function 'rv_writel':
sound/soc/amd/raven/acp3x.h:33:2: error: implicit declaration of function
'writel'; did you mean 'vwrite'? [-Werror=implicit-function-declaration]
writel(val, base_addr - ACP3x_PHY_BASE_ADDRESS);
^~
vwrite
sound/soc/amd/raven/acp3x-pcm-dma.c: In function 'acp3x_audio_probe':
>> sound/soc/amd/raven/acp3x-pcm-dma.c:638:22: error: implicit declaration of
>> function 'devm_ioremap'; did you mean 'of_ioremap'?
>> [-Werror=implicit-function-declaration]
adata->acp3x_base = devm_ioremap(&pdev->dev, res->start,
^~~~
of_ioremap
sound/soc/amd/raven/acp3x-pcm-dma.c:638:20: warning: assignment makes
pointer from integer without a cast [-Wint-conversion]
adata->acp3x_base = devm_ioremap(&pdev->dev, res->start,
^
cc1: some warnings being treated as errors
vim +638 sound/soc/amd/raven/acp3x-pcm-dma.c
f1e465ee Maruthi Srinivas Bayyavarapu 2017-03-29 616
f1e465ee Maruthi Srinivas Bayyavarapu 2017-03-29 617 static int
acp3x_audio_probe(struct platform_device *pdev)
f1e465ee Maruthi Srinivas Bayyavarapu 2017-03-29 618 {
f1e465ee Maruthi Srinivas Bayyavarapu 2017-03-29 619 int status;
f1e465ee Maruthi Srinivas Bayyavarapu 2017-03-29 620 struct resource *res;
f1e465ee Maruthi Srinivas Bayyavarapu 2017-03-29 621 struct i2s_dev_data
*adata;
f1e465ee Maruthi Srinivas Bayyavarapu 2017-03-29 622 unsigned int irqflags;
f1e465ee Maruthi Srinivas Bayyavarapu 2017-03-29 623
f1e465ee Maruthi Srinivas Bayyavarapu 2017-03-29 624 if
(pdev->dev.platform_data == NULL) {
f1e465ee Maruthi Srinivas Bayyavarapu 2017-03-29 625
dev_err(&pdev->dev, "platform_data not retrieved\n");
f1e465ee Maruthi Srinivas Bayyavarapu 2017-03-29 626 return -ENODEV;
f1e465ee Maruthi Srinivas Bayyavarapu 2017-03-29 627 }
f1e465ee Maruthi Srinivas Bayyavarapu 2017-03-29 628 irqflags = *((unsigned
int *)(pdev->dev.platform_data));
f1e465ee Maruthi Srinivas Bayyavarapu 2017-03-29 629
f1e465ee Maruthi Srinivas Bayyavarapu 2017-03-29 630 adata =
devm_kzalloc(&pdev->dev, sizeof(struct i2s_dev_data),
f1e465ee Maruthi Srinivas Bayyavarapu 2017-03-29 631
GFP_KERNEL);
f1e465ee Maruthi Srinivas Bayyavarapu 2017-03-29 632 res =
platform_get_resource(pdev, IORESOURCE_MEM, 0);
f1e465ee Maruthi Srinivas Bayyavarapu 2017-03-29 633 if (!res) {
f1e465ee Maruthi Srinivas Bayyavarapu 2017-03-29 634
dev_err(&pdev->dev, "IORESOURCE_IRQ FAILED\n");
f1e465ee Maruthi Srinivas Bayyavarapu 2017-03-29 635 return
-ENODEV;
f1e465ee Maruthi Srinivas Bayyavarapu 2017-03-29 636 }
f1e465ee Maruthi Srinivas Bayyavarapu 2017-03-29 637
f1e465ee Maruthi Srinivas Bayyavarapu 2017-03-29 @638 adata->acp3x_base =
devm_ioremap(&pdev->dev, res->start,
f1e465ee Maruthi Srinivas Bayyavarapu 2017-03-29 639
resource_size(res));
f1e465ee Maruthi Srinivas Bayyavarapu 2017-03-29 640
31058cda Maruthi Srinivas Bayyavarapu 2017-03-30 641 res =
platform_get_resource(pdev, IORESOURCE_IRQ, 0);
31058cda Maruthi Srinivas Bayyavarapu 2017-03-30 642 if (!res) {
31058cda Maruthi Srinivas Bayyavarapu 2017-03-30 643
dev_err(&pdev->dev, "IORESOURCE_IRQ FAILED\n");
31058cda Maruthi Srinivas Bayyavarapu 2017-03-30 644 return -ENODEV;
31058cda Maruthi Srinivas Bayyavarapu 2017-03-30 645 }
31058cda Maruthi Srinivas Bayyavarapu 2017-03-30 646
31058cda Maruthi Srinivas Bayyavarapu 2017-03-30 647 adata->i2s_irq =
res->start;
f1e465ee Maruthi Srinivas Bayyavarapu 2017-03-29 648 adata->play_stream =
NULL;
f1e465ee Maruthi Srinivas Bayyavarapu 2017-03-29 649 adata->capture_stream =
NULL;
f1e465ee Maruthi Srinivas Bayyavarapu 2017-03-29 650
f1e465ee Maruthi Srinivas Bayyavarapu 2017-03
[PATCH] drm/ttm: check the return value of register_shrinker
This fixes the build warning:
"ignoring return value of 'register_shrinker', declared with
attribute warn_unused_result [-Wunused-result]"
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 21 -
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 24 ++--
2 files changed, 26 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 79854ab..0eab24e 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -477,12 +477,12 @@ ttm_pool_shrink_count(struct shrinker *shrink, struct
shrink_control *sc)
return count;
}
-static void ttm_pool_mm_shrink_init(struct ttm_pool_manager *manager)
+static int ttm_pool_mm_shrink_init(struct ttm_pool_manager *manager)
{
manager->mm_shrink.count_objects = ttm_pool_shrink_count;
manager->mm_shrink.scan_objects = ttm_pool_shrink_scan;
manager->mm_shrink.seeks = 1;
- register_shrinker(&manager->mm_shrink);
+ return register_shrinker(&manager->mm_shrink);
}
static void ttm_pool_mm_shrink_fini(struct ttm_pool_manager *manager)
@@ -1034,15 +1034,18 @@ int ttm_page_alloc_init(struct ttm_mem_global *glob,
unsigned max_pages)
ret = kobject_init_and_add(&_manager->kobj, &ttm_pool_kobj_type,
&glob->kobj, "pool");
- if (unlikely(ret != 0)) {
- kobject_put(&_manager->kobj);
- _manager = NULL;
- return ret;
- }
-
- ttm_pool_mm_shrink_init(_manager);
+ if (unlikely(ret != 0))
+ goto error;
+ ret = ttm_pool_mm_shrink_init(_manager);
+ if (unlikely(ret != 0))
+ goto error;
return 0;
+
+error:
+ kobject_put(&_manager->kobj);
+ _manager = NULL;
+ return ret;
}
void ttm_page_alloc_fini(void)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index 4c65940..c7f01a4 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -1182,12 +1182,12 @@ ttm_dma_pool_shrink_count(struct shrinker *shrink,
struct shrink_control *sc)
return count;
}
-static void ttm_dma_pool_mm_shrink_init(struct ttm_pool_manager *manager)
+static int ttm_dma_pool_mm_shrink_init(struct ttm_pool_manager *manager)
{
manager->mm_shrink.count_objects = ttm_dma_pool_shrink_count;
manager->mm_shrink.scan_objects = &ttm_dma_pool_shrink_scan;
manager->mm_shrink.seeks = 1;
- register_shrinker(&manager->mm_shrink);
+ return register_shrinker(&manager->mm_shrink);
}
static void ttm_dma_pool_mm_shrink_fini(struct ttm_pool_manager *manager)
@@ -1197,7 +1197,7 @@ static void ttm_dma_pool_mm_shrink_fini(struct
ttm_pool_manager *manager)
int ttm_dma_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages)
{
- int ret = -ENOMEM;
+ int ret;
WARN_ON(_manager);
@@ -1205,7 +1205,7 @@ int ttm_dma_page_alloc_init(struct ttm_mem_global *glob,
unsigned max_pages)
_manager = kzalloc(sizeof(*_manager), GFP_KERNEL);
if (!_manager)
- goto err;
+ return -ENOMEM;
mutex_init(&_manager->lock);
INIT_LIST_HEAD(&_manager->pools);
@@ -1217,13 +1217,17 @@ int ttm_dma_page_alloc_init(struct ttm_mem_global
*glob, unsigned max_pages)
/* This takes care of auto-freeing the _manager */
ret = kobject_init_and_add(&_manager->kobj, &ttm_pool_kobj_type,
&glob->kobj, "dma_pool");
- if (unlikely(ret != 0)) {
- kobject_put(&_manager->kobj);
- goto err;
- }
- ttm_dma_pool_mm_shrink_init(_manager);
+ if (unlikely(ret != 0))
+ goto error;
+
+ ret = ttm_dma_pool_mm_shrink_init(_manager);
+ if (unlikely(ret != 0))
+ goto error;
return 0;
-err:
+
+error:
+ kobject_put(&_manager->kobj);
+ _manager = NULL;
return ret;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: next/master build: 198 builds: 1 failed, 197 passed, 1 error, 148 warnings (next-20180110)
Calling kobject_put() after a failed kobject_init_and_add() seemed
wrong, and it also appears to be missing a kfree(), so I didn't want
to mess it up any further.
ttm_pool_kobj_release will do that, so no need kfree() here.
I will fix this warning today. Thanks.
Thanks
Roger(Hongbo.He)
-Original Message-
From: arndbergm...@gmail.com [mailto:arndbergm...@gmail.com] On Behalf Of Arnd
Bergmann
Sent: Thursday, January 11, 2018 12:18 AM
To: Koenig, Christian
Cc: kernelci.org bot ; Kernel Build Reports Mailman List
; Linux Kernel Mailing List
; Thomas Hellstrom ; Dave
Airlie ; He, Roger ; Maarten Lankhorst
; Francisco Jerez ;
Viresh Kumar ; Shiraz Hashim
; Linus Walleij ;
dri-devel
Subject: Re: next/master build: 198 builds: 1 failed, 197 passed, 1 error, 148
warnings (next-20180110)
On Wed, Jan 10, 2018 at 4:54 PM, Christian König
wrote:
> Hi Arnd,
>
> Am 10.01.2018 um 16:45 schrieb Arnd Bergmann:
>>>
>>> 14 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c:1186:2: warning:
>>> ignoring return value of 'register_shrinker', declared with
>>> attribute warn_unused_result [-Wunused-result]
>>> 14 drivers/gpu/drm/ttm/ttm_page_alloc.c:485:2: warning: ignoring
>>> return value of 'register_shrinker', declared with attribute
>>> warn_unused_result [-Wunused-result]
>>
>> ttm and kvm are now the last user of register_shrinker that doesn't
>> propagate the return code to its caller, all other callers got fixed
>> in one way or another.
>>
>> I tried to fix this one too, but couldn't come up with a proper way
>> of unwinding both
>> kobject_init_and_add() and ttm_pool_mm_shrink_init():
>>
>> ret = kobject_init_and_add(&_manager->kobj, &ttm_pool_kobj_type,
>> &glob->kobj, "pool");
>> if (unlikely(ret != 0)) {
>> kobject_put(&_manager->kobj);
>> _manager = NULL;
>> return ret;
>> }
>>
>> ttm_pool_mm_shrink_init(_manager);
>>
>> Calling kobject_put() after a failed kobject_init_and_add() seemed
>> wrong, and it also appears to be missing a kfree(), so I didn't want
>> to mess it up any further. Added a few people to Cc that touched this
>> file most, maybe one of them can have a look, or they already have a
>> patch waiting to get merged.
>
>
> That isn't urgent, isn't it? So I would say I put it on my TODO list
> and I'm going to take care of it no later than 4.17.
>
> Otherwise Roger or me could take a look tomorrow.
My understanding is that the warning will be in 4.16, so the fix should be as
well, if only to get a clean build again. There were around a dozen such
warnings when the warn_unused_result got added, but the others are all fixed in
linux-next.
This is how the flag got added:
commit 64067c5cbfa24a2202b92e8fda7323610cad3043
Author: Tetsuo Handa
Date: Fri Jan 5 13:25:45 2018 +1100
mm,vmscan: mark register_shrinker() as __must_check
There are users not checking for register_shrinker() failure. Continuing
with ignoring failure can lead to later oops at unregister_shrinker().
Link:
http://lkml.kernel.org/r/1511265757-15563-1-git-send-email-penguin-ker...@i-love.sakura.ne.jp
Signed-off-by: Tetsuo Handa
Arnd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: fill in rb backend map on evergreen/ni.
Applied. thanks! Alex On Tue, Jan 9, 2018 at 6:17 PM, Roland Scheidegger wrote: > FWIW I was wrong that it was never filled in - when the backend map > query was introduced, the data indeed got filled in. However that got > lost very soon afterwards (over 6 years ago) by some fixes for backend > map calculation. > In any case, > Reviewed-by: Roland Scheidegger > > Am 09.01.2018 um 04:43 schrieb Dave Airlie: >> From: Dave Airlie >> >> This looks to have never gotten filled in, and it seems to >> trigger a bug in mesa. >> >> Reported-by: Roland Scheidegger >> Signed-off-by: Dave Airlie >> --- >> drivers/gpu/drm/radeon/evergreen.c | 1 + >> drivers/gpu/drm/radeon/ni.c| 1 + >> 2 files changed, 2 insertions(+) >> >> diff --git a/drivers/gpu/drm/radeon/evergreen.c >> b/drivers/gpu/drm/radeon/evergreen.c >> index 24fe66c..5712d63 100644 >> --- a/drivers/gpu/drm/radeon/evergreen.c >> +++ b/drivers/gpu/drm/radeon/evergreen.c >> @@ -3513,6 +3513,7 @@ static void evergreen_gpu_init(struct radeon_device >> *rdev) >> tmp = r6xx_remap_render_backend(rdev, tmp, >> rdev->config.evergreen.max_backends, >> EVERGREEN_MAX_BACKENDS, >> disabled_rb_mask); >> } >> + rdev->config.evergreen.backend_map = tmp; >> WREG32(GB_BACKEND_MAP, tmp); >> >> WREG32(CGTS_SYS_TCC_DISABLE, 0); >> diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c >> index 9eccd0c..381b0255 100644 >> --- a/drivers/gpu/drm/radeon/ni.c >> +++ b/drivers/gpu/drm/radeon/ni.c >> @@ -1148,6 +1148,7 @@ static void cayman_gpu_init(struct radeon_device *rdev) >> >> rdev->config.cayman.max_shader_engines, >> CAYMAN_MAX_BACKENDS, >> disabled_rb_mask); >> } >> + rdev->config.cayman.backend_map = tmp; >> WREG32(GB_BACKEND_MAP, tmp); >> >> cgts_tcc_disable = 0x; >> > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 06/10] dt-bindings: display: xlnx: Add ZynqMP DP subsystem bindings
Hi Rob,
Thanks for the review.
> -Original Message-
> From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
> Of Rob Herring
> Sent: Monday, January 08, 2018 8:07 PM
> To: Hyun Kwon
> Cc: devicet...@vger.kernel.org; Michal Simek ;
> dri-devel@lists.freedesktop.org
> Subject: Re: [PATCH 06/10] dt-bindings: display: xlnx: Add ZynqMP DP
> subsystem bindings
>
> On Thu, Jan 04, 2018 at 06:05:55PM -0800, Hyun Kwon wrote:
> > This add a dt binding for ZynqMP DP subsystem.
> >
> > Signed-off-by: Hyun Kwon
> > ---
> > .../bindings/display/xlnx/xlnx,zynqmp-dpsub.txt| 94
> ++
> > 1 file changed, 94 insertions(+)
> > create mode 100644
> Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.txt
> >
> > diff --git a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-
> dpsub.txt b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-
> dpsub.txt
> > new file mode 100644
> > index 000..4e478ca
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-
> dpsub.txt
> > @@ -0,0 +1,94 @@
> > +Xilinx ZynqMP DisplayPort subsystem
> > +---
> > +
> > +Required properties:
> > +
> > +- compatible: Must be "xlnx,zynqmp-dpsub-1.7".
> > +
> > +- reg: Physical base address and length of the registers set for the
> > device.
> > +- reg-names: Must be "dp", "blend", "av_buf", and "aud" to map logical
> register
> > + partitions.
> > +
> > +- interrupts: Interrupt number.
> > +- interrupts-parent: phandle for interrupt controller.
> > +
> > +- clocks: phandles for axi, audio, non-live video, and live video clocks.
> > + axi clock is required. Audio clock is optional. If not present, audio
> > will
> > + be disabled. One of non-live or live video clock should be present.
> > +- clock-names: The identification strings are required. "aclk" for axi
> > clock.
> > + "dp_aud_clk" for audio clock. "dp_vtc_pixel_clk_in" for non-live video
> clock.
> > + "dp_live_video_in_clk" for live video clock (clock from programmable
> logic).
>
> "_clk" is redundant.
This is to reflect the name of signal spelled out in the hardware spec, so I'd
like to keep it this way unless you are still against it.
>
> > +
> > +- phys: phandles for phy specifier.
> > +- phy-names: The identifier strings. "dp-phy" followed by index.
> > +
> > +- power-domains: phandle for the corresponding power domain
> > +
> > +- ports: crtc and encoder ports are required using DT bindings defined in
> > + Documentation/devicetree/bindings/graph.txt.
>
> Isn't the connection crtc->encoder?
It's bidirectional: crtc <-> encoder. Currently, as in this example, it's only
connected between internal ports, but any of those ports can be connected with
external ports too.
>
> Also, crtc is pretty much a DRM term. Don't use that in bindings.
> Describe the h/w blocks.
Sure. Will fix.
>
> > +
> > +- vid-layer, gfx-layer: Required to represent available layers
> > +
> > +Required layer properties
> > +
> > +- dmas: phandles for DMA channels as defined in
> > + Documentation/devicetree/bindings/dma/dma.txt.
> > +- dma-names: The identifier strings are required. "graphics0" for graphics
> > + layer. "video" followed by index for video layer
> > +
> > +Optional child node
> > +
> > +- The driver populates any child device node in this node. This can be
> used,
> > + for example, to populate the sound device from the DisplayPort
> subsystem
> > + driver.
> > +
> > +Example:
> > + zynqmp_dpsub: zynqmp_dpsub@fd4a {
>
> display-controller@...
>
> > + compatible = "xlnx,zynqmp-dpsub-1.7";
> > + reg = <0x0 0xfd4a 0x0 0x1000>,
> > + <0x0 0xfd4aa000 0x0 0x1000>,
> > + <0x0 0xfd4ab000 0x0 0x1000>,
> > + <0x0 0xfd4ac000 0x0 0x1000>;
> > + reg-names = "dp", "blend", "av_buf", "aud";
> > + interrupts = <0 119 4>;
> > + interrupt-parent = <&gic>;
> > +
> > + clock-names = "dp_apb_clk", "dp_aud_clk",
> "dp_live_video_in_clk";
> > + clocks = <&dp_aclk>, <&clkc 17>, <&si570_1>;
> > +
> > + phys = <&lane1 PHY_TYPE_DP 0 1 2700>,
> > + <&lane0 PHY_TYPE_DP 1 1 2700>;
> > + phy-names = "dp-phy0", "dp-phy1";
> > +
> > + power-domains = <&pd_dp>;
> > +
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + vid-layer {
> > + dma-names = "vid0", "vid1", "vid2";
> > + dmas = <&xlnx_dpdma 0>,
> > + <&xlnx_dpdma 1>,
> > + <&xlnx_dpdma 2>;
> > + };
> > +
> > + gfx-layer {
>
> These 2 nodes don't seem necessary. Just make "dmas" take 4 values and
> define where the gfx0 channel is located (index 0 or 3?).
>
That is correct, as of now. But, in the follow up patch / internal development,
each layer needs to be referenced by e
RE: [PATCH 00/10] Xilinx ZynqMP DisplayPort subsystem DRM KMS driver
Hi Daniel, > -Original Message- > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel > Vetter > Sent: Tuesday, January 09, 2018 1:57 AM > To: Hyun Kwon > Cc: dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; Michal > Simek > Subject: Re: [PATCH 00/10] Xilinx ZynqMP DisplayPort subsystem DRM > KMS driver > > On Thu, Jan 04, 2018 at 06:05:49PM -0800, Hyun Kwon wrote: > > Hi, > > > > This patchset adds the DRM KMS driver for Xilinx ZynqMP DisplayPort > > subsystem. The Xilinx ZynqMP SoC has a hardened full display pipeline > > which supports blending of up to 2 planes, and the encoder is > > DisplayPort v1.2 compatible. > > > > This series mainly includes 2 sets: Xilinx DRM KMS (patch 1/10 - 5/10) > > and ZynqMP DP subsystem drivers (patch 6/10 - 10/10). > > > > The Xilinx DRM KMS is intended as a common layer shared across other > > (upcoming) Xilinx sub-drivers. It helps sub-drivers for both hardened as > > well as soft IPs interoperate together. > > > > ZynqMP DP subsystem driver is a sub-driver that implements > corresponding > > drm objects (crtc, plane, encoder, connector,,,) for ZynqMP SoC display > > pipeline. The entire pipeline is mainly partitioned into 2 blocks: > > generic display logic (zynqmp_disp.c) such as blending, csc,,, and the > > DP transmitter logic (zynqmp_dp.c). > > I read through it all (well mostly the drm relevant bits, not your backend > code) and looks fairly resonable. Few minor clenaups and code removals > tbh. > > Wrt merging/maintianing, do you want to maintain it as part of the > drm-misc small drivers group? Highly recommended imo. See > > https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm- > misc.html#small-drivers > > for details. Ideally we'd need 2 xilinx maintainers to be able to push > patches & cross-review stuff. I don't have any preference on how to maintain, so I'll follow your suggestion. One thing that may be worth a note is that there is sizable amount of development within Xilinx, and those will come in near future (considering what can be done with FPGA :-)). I'll look for the 2nd reviewer, and specify that in the next patch if found. Thanks, -hyun > -Daniel > > > > > Thanks, > > -hyun > > > > Hyun Kwon (10): > > dt-bindings: display: xlnx: Add Xilinx kms bindings > > drm: xlnx: Add xlnx crtc of Xilinx DRM KMS > > drm: xlnx: Add xlnx fb of Xilinx DRM KMS > > drm: xlnx: Add xlnx gem of Xilinx DRM KMS > > drm: xlnx: Xilinx DRM KMS driver > > dt-bindings: display: xlnx: Add ZynqMP DP subsystem bindings > > drm: xlnx: DRM KMS driver for Xilinx ZynqMP DP subsystem display > > drm: xlnx: DRM KMS driver for Xilinx ZynqMP DisplayPort > > drm: xlnx: ZynqMP DP subsystem DRM KMS driver > > drm: xlnx: zynqmp: Add debugfs > > > > .../devicetree/bindings/display/xlnx/xlnx,kms.txt | 20 + > > .../bindings/display/xlnx/xlnx,zynqmp-dpsub.txt| 94 + > > MAINTAINERS|8 + > > drivers/gpu/drm/Kconfig|2 + > > drivers/gpu/drm/Makefile |1 + > > drivers/gpu/drm/xlnx/Kconfig | 44 + > > drivers/gpu/drm/xlnx/Makefile |5 + > > drivers/gpu/drm/xlnx/xlnx_crtc.c | 195 ++ > > drivers/gpu/drm/xlnx/xlnx_crtc.h | 70 + > > drivers/gpu/drm/xlnx/xlnx_drv.c| 436 +++ > > drivers/gpu/drm/xlnx/xlnx_drv.h| 22 + > > drivers/gpu/drm/xlnx/xlnx_fb.c | 468 +++ > > drivers/gpu/drm/xlnx/xlnx_fb.h | 30 + > > drivers/gpu/drm/xlnx/xlnx_gem.c| 39 + > > drivers/gpu/drm/xlnx/xlnx_gem.h| 18 + > > drivers/gpu/drm/xlnx/zynqmp_disp.c | 3261 > > > drivers/gpu/drm/xlnx/zynqmp_disp.h | 28 + > > drivers/gpu/drm/xlnx/zynqmp_dp.c | 2168 + > > drivers/gpu/drm/xlnx/zynqmp_dp.h | 29 + > > drivers/gpu/drm/xlnx/zynqmp_dpsub.c| 141 + > > drivers/gpu/drm/xlnx/zynqmp_dpsub.h| 19 + > > 21 files changed, 7098 insertions(+) > > create mode 100644 > Documentation/devicetree/bindings/display/xlnx/xlnx,kms.txt > > create mode 100644 > Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.txt > > create mode 100644 drivers/gpu/drm/xlnx/Kconfig > > create mode 100644 drivers/gpu/drm/xlnx/Makefile > > create mode 100644 drivers/gpu/drm/xlnx/xlnx_crtc.c > > create mode 100644 drivers/gpu/drm/xlnx/xlnx_crtc.h > > create mode 100644 drivers/gpu/drm/xlnx/xlnx_drv.c > > create mode 100644 drivers/gpu/drm/xlnx/xlnx_drv.h > > create mode 100644 drivers/gpu/drm/xlnx/xlnx_fb.c > > create mode 100644 drivers/gpu/drm/xlnx/xlnx_fb.h > > create mode 100644 drivers/gpu/drm/xlnx/xlnx_gem.c > > create mode 100644 drivers/gpu/drm/xlnx/xlnx_gem.h > > create mode 100644 d
RE: [PATCH 05/10] drm: xlnx: Xilinx DRM KMS driver
Hi Daniel, Thanks for the review. > -Original Message- > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel > Vetter > Sent: Tuesday, January 09, 2018 1:51 AM > To: Hyun Kwon > Cc: dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; Michal > Simek > Subject: Re: [PATCH 05/10] drm: xlnx: Xilinx DRM KMS driver > > On Thu, Jan 04, 2018 at 06:05:54PM -0800, Hyun Kwon wrote: > > Xilinx has various platforms for display, where users can create > > using multiple IPs in the programmable FPGA fabric, or where > > some hardened piepline is available on the chip. Furthermore, > > hardened pipeline can also interact with soft logics in FPGA. > > > > The Xilinx DRM KMS is a softwrae layer to glue subdevice drivers > > with DRM core and integrate multiple subdevice drivers together. > > > > Signed-off-by: Hyun Kwon > > --- > > MAINTAINERS | 8 + > > drivers/gpu/drm/Kconfig | 2 + > > drivers/gpu/drm/Makefile | 1 + > > drivers/gpu/drm/xlnx/Kconfig | 12 ++ > > drivers/gpu/drm/xlnx/Makefile| 2 + > > drivers/gpu/drm/xlnx/xlnx_crtc.c | 1 + > > drivers/gpu/drm/xlnx/xlnx_drv.c | 436 > +++ > > drivers/gpu/drm/xlnx/xlnx_drv.h | 22 ++ > > drivers/gpu/drm/xlnx/xlnx_fb.c | 1 + > > drivers/gpu/drm/xlnx/xlnx_gem.c | 1 + > > 10 files changed, 486 insertions(+) > > create mode 100644 drivers/gpu/drm/xlnx/Kconfig > > create mode 100644 drivers/gpu/drm/xlnx/Makefile > > create mode 100644 drivers/gpu/drm/xlnx/xlnx_drv.c > > create mode 100644 drivers/gpu/drm/xlnx/xlnx_drv.h > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index d4b1635..101a3e6 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -4785,6 +4785,14 @@ F: drivers/gpu/drm/etnaviv/ > > F: include/uapi/drm/etnaviv_drm.h > > F: Documentation/devicetree/bindings/display/etnaviv/ > > > > +DRM DRIVERS FOR XILINX > > +M: Hyun Kwon > > +L: dri-devel@lists.freedesktop.org > > +S: Maintained > > +F: drivers/gpu/drm/xlnx/ > > +F: Documentation/devicetree/bindings/display/xlnx/ > > +T: git git://anongit.freedesktop.org/drm/drm-misc > > + > > DRM DRIVERS FOR ZTE ZX > > M: Shawn Guo > > L: dri-devel@lists.freedesktop.org > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > > index 0bc3744..82b7fc3 100644 > > --- a/drivers/gpu/drm/Kconfig > > +++ b/drivers/gpu/drm/Kconfig > > @@ -293,6 +293,8 @@ source "drivers/gpu/drm/pl111/Kconfig" > > > > source "drivers/gpu/drm/tve200/Kconfig" > > > > +source "drivers/gpu/drm/xlnx/Kconfig" > > + > > # Keep legacy drivers last > > > > menuconfig DRM_LEGACY > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > > index dd5ae67..72ee1a1 100644 > > --- a/drivers/gpu/drm/Makefile > > +++ b/drivers/gpu/drm/Makefile > > @@ -103,3 +103,4 @@ obj-$(CONFIG_DRM_TINYDRM) += tinydrm/ > > obj-$(CONFIG_DRM_PL111) += pl111/ > > obj-$(CONFIG_DRM_TVE200) += tve200/ > > obj-$(CONFIG_DRM_SCHED)+= scheduler/ > > +obj-$(CONFIG_DRM_XLNX) += xlnx/ > > diff --git a/drivers/gpu/drm/xlnx/Kconfig b/drivers/gpu/drm/xlnx/Kconfig > > new file mode 100644 > > index 000..19fd7cd > > --- /dev/null > > +++ b/drivers/gpu/drm/xlnx/Kconfig > > @@ -0,0 +1,12 @@ > > +config DRM_XLNX > > + tristate "Xilinx DRM KMS Driver" > > + depends on DRM && OF > > + select DRM_KMS_HELPER > > + select DRM_KMS_CMA_HELPER > > + select DRM_GEM_CMA_HELPER > > + help > > + Xilinx DRM KMS driver. Choose this option if you have > > + a Xilinx SoCs with hardened display pipeline or soft > > + display pipeline using Xilinx IPs in FPGA. This module > > + provides the kernel mode setting functionalities > > + for Xilinx display drivers. > > diff --git a/drivers/gpu/drm/xlnx/Makefile > b/drivers/gpu/drm/xlnx/Makefile > > new file mode 100644 > > index 000..c60a281 > > --- /dev/null > > +++ b/drivers/gpu/drm/xlnx/Makefile > > @@ -0,0 +1,2 @@ > > +xlnx_drm-objs += xlnx_crtc.o xlnx_drv.o xlnx_fb.o xlnx_gem.o > > +obj-$(CONFIG_DRM_XLNX) += xlnx_drm.o > > diff --git a/drivers/gpu/drm/xlnx/xlnx_crtc.c > b/drivers/gpu/drm/xlnx/xlnx_crtc.c > > index 57ee939..8387e1e 100644 > > --- a/drivers/gpu/drm/xlnx/xlnx_crtc.c > > +++ b/drivers/gpu/drm/xlnx/xlnx_crtc.c > > @@ -13,6 +13,7 @@ > > #include > > > > #include "xlnx_crtc.h" > > +#include "xlnx_drv.h" > > > > /* > > * Overview > > diff --git a/drivers/gpu/drm/xlnx/xlnx_drv.c > b/drivers/gpu/drm/xlnx/xlnx_drv.c > > new file mode 100644 > > index 000..273420b > > --- /dev/null > > +++ b/drivers/gpu/drm/xlnx/xlnx_drv.c > > @@ -0,0 +1,436 @@ > > +/* > > + * Xilinx DRM KMS Driver > > + * > > + * Copyright (C) 2013 - 2018 Xilinx, Inc. > > + * > > + * Author: Hyun Woo Kwon > > + * > > + * SPDX-License-Identifier: GPL-2.0 > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#inclu
RE: [PATCH 10/10] drm: xlnx: zynqmp: Add debugfs
Hi Daniel,
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Tuesday, January 09, 2018 1:54 AM
> To: Hyun Kwon
> Cc: dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; Tejas
> Upadhyay ; Michal Simek
> Subject: Re: [PATCH 10/10] drm: xlnx: zynqmp: Add debugfs
>
> On Thu, Jan 04, 2018 at 06:05:59PM -0800, Hyun Kwon wrote:
> > Debugfs can be used to exploit some specific setting. Main purpose
> > is for testing and debug diagnostic.
> >
> > Signed-off-by: Tejas Upadhyay
> > Signed-off-by: Hyun Kwon
>
> Hm, not sure what's the use, it seems to just be for setting/getting
> your driver-private properties. Usually people use modetest and similar
> tools, but if there's demand for setting properties in debugfs (we already
> have all the infrastructure for dumping the entire kms state, see the
> various atomic_print_state callbacks) I think that should be done with
> generic drm code.
>
> I'd drop this patch for now (if there's no other reason for it).
Thanks for the input. It'd be helpful, for my own understanding, if this can be
elaborated a little more. We are using standard tools as well as custom
script/tool, but some specific properties / controls are hard to be executed
with modetest only unless we change the entire set up / design between each
run. The debugfs is used to run all (or as much as possible) properties in a
single run, and from what I understand, that doesn't violate intended debugfs
usage as long as it's not treated as a stable ABI. The intention is to help
isolate issues and enhance the diagnostics. I agree, in the long term, this
kind of stuff should be handled in generic way, but would it be still
reasonable to keep it driver specific in the meantime?
Thanks,
-hyun
> -Daniel
>
> > ---
> > drivers/gpu/drm/xlnx/Kconfig | 21 +++
> > drivers/gpu/drm/xlnx/zynqmp_disp.c | 326
> +
> > drivers/gpu/drm/xlnx/zynqmp_dp.c | 304
> ++
> > 3 files changed, 651 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/xlnx/Kconfig b/drivers/gpu/drm/xlnx/Kconfig
> > index 7c5529c..befce0f 100644
> > --- a/drivers/gpu/drm/xlnx/Kconfig
> > +++ b/drivers/gpu/drm/xlnx/Kconfig
> > @@ -21,3 +21,24 @@ config DRM_ZYNQMP_DPSUB
> > this option if you have a Xilinx ZynqMP SoC with DisplayPort
> > subsystem. The driver provides the kernel mode setting
> > functionlaities for ZynqMP DP subsystem.
> > +
> > +config DRM_ZYNQMP_DISP_DEBUG_FS
> > + bool "ZynqMP Display debugfs"
> > + depends on DEBUG_FS && DRM_ZYNQMP_DPSUB
> > + select DRM_ZYNQMP_DP_DEBUG_FS
> > + help
> > + Enable the debugfs code for DP Sub driver. The debugfs code
> > + enables debugging or testing related features. It exposes some
> > + low level controls to the user space to help testing automation,
> > + as well as can enable additional diagnostic or statistical
> > + information.
> > +
> > +config DRM_ZYNQMP_DP_DEBUG_FS
> > + bool "ZynqMP DP debugfs"
> > + depends on DEBUG_FS && DRM_ZYNQMP_DPSUB
> > + help
> > + Enable the debugfs code for DP driver. The debugfs code
> > + enables debugging or testing related features. It exposes some
> > + low level controls to the user space to help testing automation,
> > + as well as can enable additional diagnostic or statistical
> > + information.
> > diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c
> b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> > index 68f829c..9fe6d49 100644
> > --- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
> > +++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> > @@ -17,6 +17,7 @@
> > #include
> >
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -508,6 +509,325 @@ static void zynqmp_disp_set(void __iomem
> *base, int offset, u32 set)
> > zynqmp_disp_write(base, offset, zynqmp_disp_read(base, offset) |
> set);
> > }
> >
> > +#ifdef CONFIG_DRM_ZYNQMP_DISP_DEBUG_FS
> > +
> > +#define ZYNQMP_DISP_DEBUGFS_READ_MAX_SIZE 32UL
> > +#define ZYNQMP_DISP_DEBUGFS_MAX_BG_COLOR_VAL 0xFFF
> > +#define IN_RANGE(x, min, max) ({ \
> > + typeof(x) _x = (x); \
> > + _x >= (min) && _x <= (max); })
> > +
> > +/* Match xilinx_dp_testcases vs dp_debugfs_reqs[] entry */
> > +enum zynqmp_disp_testcases {
> > + DP_SUB_TC_BG_COLOR,
> > + DP_SUB_TC_OUTPUT_FMT,
> > + DP_SUB_TC_NONE
> > +};
> > +
> > +struct zynqmp_disp_debugfs {
> > + enum zynqmp_disp_testcases testcase;
> > + u16 r_value;
> > + u16 g_value;
> > + u16 b_value;
> > + u32 output_fmt;
> > + struct zynqmp_disp *zynqmp_disp;
> > +};
> > +
> > +static struct dentry *zynqmp_disp_debugfs_dir;
> > +struct zynqmp_disp_debugfs disp_debugfs;
> > +struct zynqmp_disp_debugfs_request {
> > + const char *req;
> > + enum zynqmp_disp_testcases tc;
> > + ssize_t (*read_handler)(char **kern_buff);
> > + ssize_t (*write_handler)(char **cmd
RE: [PATCH 01/10] dt-bindings: display: xlnx: Add Xilinx kms bindings
Hi Rob,
Thanks for the feedback.
> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: Monday, January 08, 2018 8:00 PM
> To: Hyun Kwon
> Cc: dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; Michal
> Simek
> Subject: Re: [PATCH 01/10] dt-bindings: display: xlnx: Add Xilinx kms
> bindings
>
> On Thu, Jan 04, 2018 at 06:05:50PM -0800, Hyun Kwon wrote:
> > The dt binding for Xilinx DRM KMS driver.
>
> Bindings are for h/w, not drivers.
I'll rephrase this.
>
> >
> > Signed-off-by: Hyun Kwon
> > ---
> > .../devicetree/bindings/display/xlnx/xlnx,kms.txt| 20
>
> > 1 file changed, 20 insertions(+)
> > create mode 100644
> Documentation/devicetree/bindings/display/xlnx/xlnx,kms.txt
> >
> > diff --git a/Documentation/devicetree/bindings/display/xlnx/xlnx,kms.txt
> b/Documentation/devicetree/bindings/display/xlnx/xlnx,kms.txt
> > new file mode 100644
> > index 000..8dcd552
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/xlnx/xlnx,kms.txt
> > @@ -0,0 +1,20 @@
> > +Xilinx KMS Pipeline
> > +---
> > +
> > +Xilinx display pipelines can be designed with hardened video IPs and soft
> video
> > +IPs in programmable logic. This KMS module provides the common
> functionality
> > +of individual subdevice drivers, and glue logics between them.
> > +
> > +Required properties:
> > +
> > +- compatible: Must be "xlnx,kms".
I'll also rephrase the description and rename this to xlnx,display.
> > +
> > +- ports: phandles for CRTC ports, using the DT bindings defined in
> > + Documentation/devicetree/bindings/graph.txt.
>
> This use of ports is not part of the graph binding.
I'll add more details in the description.
>
> > +
> > +Example:
> > +
> > + xlnx_drm: xlnx_drm {
> > + compatible = "xlnx,kms";
>
> drm and kms are Linuxisms.
I agree. I'll remove linux subsystem specific terms.
>
> Why do you need this node?
This node is used to represent a display pipeline as a single entity, which can
consist of multiple components / IPs. I'll elaborate more per your suggestion.
Thanks,
-hyun
>
> > + ports = <&crtc_port>;
> > + };
> > --
> > 2.7.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe devicetree" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 07/10] drm: xlnx: DRM KMS driver for Xilinx ZynqMP DP subsystem display
Hi Daniel, > -Original Message- > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel > Vetter > Sent: Tuesday, January 09, 2018 1:47 AM > To: Hyun Kwon > Cc: dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; Michal > Simek > Subject: Re: [PATCH 07/10] drm: xlnx: DRM KMS driver for Xilinx ZynqMP > DP subsystem display > > On Thu, Jan 04, 2018 at 06:05:56PM -0800, Hyun Kwon wrote: > > Xilinx ZynqMP has a hardened display pipeline. The pipeline can > > be logically partitioned into 2 parts: display and DisplayPort. > > This driver handles the display part of the pipeline that handles > > buffer management and blending. > > > > Signed-off-by: Hyun Kwon > > --- > > drivers/gpu/drm/xlnx/zynqmp_disp.c | 2935 > > > drivers/gpu/drm/xlnx/zynqmp_disp.h | 28 + > > 2 files changed, 2963 insertions(+) > > create mode 100644 drivers/gpu/drm/xlnx/zynqmp_disp.c > > create mode 100644 drivers/gpu/drm/xlnx/zynqmp_disp.h > > > > diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c > b/drivers/gpu/drm/xlnx/zynqmp_disp.c > > new file mode 100644 > > index 000..68f829c > > --- /dev/null > > +++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c > > @@ -0,0 +1,2935 @@ > > +/* > > + * ZynqMP Display Controller Driver > > + * > > + * Copyright (C) 2017 - 2018 Xilinx, Inc. > > + * > > + * Author: Hyun Woo Kwon > > + * > > + * SPDX-License-Identifier: GPL-2.0 > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include "xlnx_crtc.h" > > +#include "xlnx_fb.h" > > +#include "zynqmp_disp.h" > > +#include "zynqmp_dp.h" > > +#include "zynqmp_dpsub.h" > > + > > +/* > > + * Overview > > + * > > + * > > + * The display part of ZynqMP DP subsystem. Internally, the device > > + * is partitioned into 3 blocks: AV buffer manager, Blender, Audio. > > + * The driver creates the DRM crtc and plane objectes and maps the DRM > > + * interface into those 3 blocks. In high level, the driver is layered > > + * in the following way: > > + * > > + * zynqmp_disp_crtc & zynqmp_disp_plane > > + * |->zynqmp_disp > > + * |->zynqmp_disp_aud > > + * |->zynqmp_disp_blend > > + * |->zynqmp_disp_av_buf > > + * > > + * The driver APIs are used externally by > > + * - zynqmp_dpsub: Top level ZynqMP DP subsystem driver > > + * - zynqmp_dp: ZynqMP DP driver > > + * - xlnx_crtc: Xilinx DRM specific crtc functions > > + */ > > + > > +/* Blender registers */ > > +#define ZYNQMP_DISP_V_BLEND_BG_CLR_0 0x0 > > +#define ZYNQMP_DISP_V_BLEND_BG_CLR_1 0x4 > > +#define ZYNQMP_DISP_V_BLEND_BG_CLR_2 0x8 > > +#define ZYNQMP_DISP_V_BLEND_BG_MAX 0xfff > > +#define ZYNQMP_DISP_V_BLEND_SET_GLOBAL_ALPHA 0xc > > +#define ZYNQMP_DISP_V_BLEND_SET_GLOBAL_ALPHA_MASK 0x1fe > > +#define ZYNQMP_DISP_V_BLEND_SET_GLOBAL_ALPHA_MAX 0xff > > +#define ZYNQMP_DISP_V_BLEND_OUTPUT_VID_FMT 0x14 > > +#define ZYNQMP_DISP_V_BLEND_OUTPUT_VID_FMT_RGB > 0x0 > > +#define ZYNQMP_DISP_V_BLEND_OUTPUT_VID_FMT_YCBCR4440x1 > > +#define ZYNQMP_DISP_V_BLEND_OUTPUT_VID_FMT_YCBCR4220x2 > > +#define ZYNQMP_DISP_V_BLEND_OUTPUT_VID_FMT_YONLY 0x3 > > +#define ZYNQMP_DISP_V_BLEND_OUTPUT_VID_FMT_XVYCC 0x4 > > +#define ZYNQMP_DISP_V_BLEND_OUTPUT_EN_DOWNSAMPLE BIT(4) > > +#define ZYNQMP_DISP_V_BLEND_LAYER_CONTROL 0x18 > > +#define ZYNQMP_DISP_V_BLEND_LAYER_CONTROL_EN_US > BIT(0) > > +#define ZYNQMP_DISP_V_BLEND_LAYER_CONTROL_RGB BIT(1) > > +#define ZYNQMP_DISP_V_BLEND_LAYER_CONTROL_BYPASS BIT(8) > > +#define ZYNQMP_DISP_V_BLEND_NUM_COEFF 9 > > +#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF0 0x20 > > +#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF1 0x24 > > +#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF2 0x28 > > +#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF3 0x2c > > +#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF4 0x30 > > +#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF5 0x34 > > +#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF6 0x38 > > +#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF7 0x3c > > +#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF8 0x40 > > +#define ZYNQMP_DISP_V_BLEND_IN1CSC_COEFF0 0x44 > > +#define ZYNQMP_DISP_V_BLEND_IN1CSC_COEFF1 0x48 > > +#define ZYNQMP_DISP_V_BLEND_IN1CSC_COEFF2 0x4c > > +#define ZYNQMP_DISP_V_BLEND_IN1CSC_COEFF3 0x50 > > +#define ZYNQMP_DISP_V_BLEND_IN1CSC_COEFF4 0x54 > > +#define ZYNQMP_DISP_V_BLEND_IN1CSC_COEFF5 0x58 > > +#define ZYNQMP_DISP_V_BLEND_IN1CSC_COEFF6 0x5c > > +#
RE: [PATCH 03/10] drm: xlnx: Add xlnx fb of Xilinx DRM KMS
Hi Daniel,
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Tuesday, January 09, 2018 1:36 AM
> To: Hyun Kwon
> Cc: dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; Michal
> Simek
> Subject: Re: [PATCH 03/10] drm: xlnx: Add xlnx fb of Xilinx DRM KMS
>
> On Thu, Jan 04, 2018 at 06:05:52PM -0800, Hyun Kwon wrote:
> > Helpers for framebuffers backed by cma allocator.
> >
> > Signed-off-by: Hyun Kwon
>
> Please take a look at the very new drm_gem_framebuffer_helper.c file.
> There's lots of helpers in there that you can use to remove almost the
> entire file here :-) You might even want to entirely drop this if it
> becomes too small.
Thanks for the pointer. I replaced some, but some still remain.
Thanks,
-hyun
> -Daniel
>
> > ---
> > drivers/gpu/drm/xlnx/xlnx_fb.c | 467
> +
> > drivers/gpu/drm/xlnx/xlnx_fb.h | 30 +++
> > 2 files changed, 497 insertions(+)
> > create mode 100644 drivers/gpu/drm/xlnx/xlnx_fb.c
> > create mode 100644 drivers/gpu/drm/xlnx/xlnx_fb.h
> >
> > diff --git a/drivers/gpu/drm/xlnx/xlnx_fb.c
> b/drivers/gpu/drm/xlnx/xlnx_fb.c
> > new file mode 100644
> > index 000..dbe9fbf
> > --- /dev/null
> > +++ b/drivers/gpu/drm/xlnx/xlnx_fb.c
> > @@ -0,0 +1,467 @@
> > +/*
> > + * Xilinx DRM KMS Framebuffer helper
> > + *
> > + * Copyright (C) 2015 - 2018 Xilinx, Inc.
> > + *
> > + * Author: Hyun Woo Kwon
> > + *
> > + * Based on drm_fb_cma_helper.c
> > + *
> > + * Copyright (C) 2012 Analog Device Inc.
> > + *
> > + * SPDX-License-Identifier: GPL-2.0
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "xlnx_fb.h"
> > +
> > +#define XLNX_MAX_PLANES4
> > +
> > +struct xlnx_fb {
> > + struct drm_framebuffer base;
> > + struct drm_gem_cma_object *obj[XLNX_MAX_PLANES];
> > +};
> > +
> > +struct xlnx_fbdev {
> > + struct drm_fb_helper fb_helper;
> > + struct xlnx_fb *fb;
> > + unsigned int align;
> > + unsigned int vres_mult;
> > +};
> > +
> > +static inline struct xlnx_fbdev *to_fbdev(struct drm_fb_helper
> *fb_helper)
> > +{
> > + return container_of(fb_helper, struct xlnx_fbdev, fb_helper);
> > +}
> > +
> > +static inline struct xlnx_fb *to_fb(struct drm_framebuffer *base_fb)
> > +{
> > + return container_of(base_fb, struct xlnx_fb, base);
> > +}
> > +
> > +static void xlnx_fb_destroy(struct drm_framebuffer *base_fb)
> > +{
> > + struct xlnx_fb *fb = to_fb(base_fb);
> > + int i;
> > +
> > + for (i = 0; i < XLNX_MAX_PLANES; i++)
> > + if (fb->obj[i])
> > + drm_gem_object_unreference_unlocked(&fb-
> >obj[i]->base);
> > +
> > + drm_framebuffer_cleanup(base_fb);
> > + kfree(fb);
> > +}
> > +
> > +static int xlnx_fb_create_handle(struct drm_framebuffer *base_fb,
> > +struct drm_file *file_priv,
> > +unsigned int *handle)
> > +{
> > + struct xlnx_fb *fb = to_fb(base_fb);
> > +
> > + return drm_gem_handle_create(file_priv, &fb->obj[0]->base,
> handle);
> > +}
> > +
> > +static struct drm_framebuffer_funcs xlnx_fb_funcs = {
> > + .destroy= xlnx_fb_destroy,
> > + .create_handle = xlnx_fb_create_handle,
> > +};
> > +
> > +/**
> > + * xlnx_fb_alloc - Allocate a xlnx_fb
> > + * @drm: DRM object
> > + * @mode_cmd: drm_mode_fb_cmd2 struct
> > + * @obj: pointers for returned drm_gem_cma_objects
> > + * @num_planes: number of planes to be allocated
> > + *
> > + * This function is based on drm_fb_cma_alloc().
> > + *
> > + * Return: a xlnx_fb object, or ERR_PTR.
> > + */
> > +static struct xlnx_fb *
> > +xlnx_fb_alloc(struct drm_device *drm,
> > + const struct drm_mode_fb_cmd2 *mode_cmd,
> > + struct drm_gem_cma_object **obj, unsigned int num_planes)
> > +{
> > + struct xlnx_fb *fb;
> > + int ret;
> > + int i;
> > +
> > + fb = kzalloc(sizeof(*fb), GFP_KERNEL);
> > + if (!fb)
> > + return ERR_PTR(-ENOMEM);
> > +
> > + drm_helper_mode_fill_fb_struct(drm, &fb->base, mode_cmd);
> > +
> > + for (i = 0; i < num_planes; i++)
> > + fb->obj[i] = obj[i];
> > +
> > + ret = drm_framebuffer_init(drm, &fb->base, &xlnx_fb_funcs);
> > + if (ret) {
> > + dev_err(drm->dev, "Failed to initialize fb: %d\n", ret);
> > + kfree(fb);
> > + return ERR_PTR(ret);
> > + }
> > +
> > + return fb;
> > +}
> > +
> > +/**
> > + * xlnx_fb_get_paddr - Get physycal address of framebuffer
> > + * @base_fb: the framebuffer
> > + * @plane: which plane
> > + *
> > + * This function is based on drm_fb_cma_get_gem_obj().
> > + *
> > + * Return: a physical address of the plane, or 0
> > + */
> > +dma_addr_t
> > +xlnx_fb_get_paddr(struct drm_framebuffer *base_fb, unsigned int plane)
> > +{
> > + struct xlnx_fb *fb = to_fb(base_fb);
> > +
> > + if (plane >= XLNX_MAX_PLANES)
> > + return 0;
> > +
> > + return fb->obj[p
RE: [PATCH 02/10] drm: xlnx: Add xlnx crtc of Xilinx DRM KMS
Hi Daniel,
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Tuesday, January 09, 2018 1:38 AM
> To: Hyun Kwon
> Cc: dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; Michal
> Simek
> Subject: Re: [PATCH 02/10] drm: xlnx: Add xlnx crtc of Xilinx DRM KMS
>
> On Thu, Jan 04, 2018 at 06:05:51PM -0800, Hyun Kwon wrote:
> > xlnx_crtc is a part of Xilinx DRM KMS and a layer that
> > provides some interface between the Xilinx DRM KMS and
> > crtc drivers.
> >
> > Signed-off-by: Hyun Kwon
>
> Personal style, but I don't see much value in these small helpers.
> Splitting them from the main driver at least makes reading the patches a
> bit harder. But no strong opinion, just a bikeshed, feel free to ignore
> :-)
I also don't, but some reviewers prefer this way. I'll leave it this way for
now. :-)
Thanks,
-hyun
> -Daniel
>
> > ---
> > drivers/gpu/drm/xlnx/xlnx_crtc.c | 194
> +++
> > drivers/gpu/drm/xlnx/xlnx_crtc.h | 70 ++
> > 2 files changed, 264 insertions(+)
> > create mode 100644 drivers/gpu/drm/xlnx/xlnx_crtc.c
> > create mode 100644 drivers/gpu/drm/xlnx/xlnx_crtc.h
> >
> > diff --git a/drivers/gpu/drm/xlnx/xlnx_crtc.c
> b/drivers/gpu/drm/xlnx/xlnx_crtc.c
> > new file mode 100644
> > index 000..57ee939
> > --- /dev/null
> > +++ b/drivers/gpu/drm/xlnx/xlnx_crtc.c
> > @@ -0,0 +1,194 @@
> > +/*
> > + * Xilinx DRM crtc driver
> > + *
> > + * Copyright (C) 2017 - 2018 Xilinx, Inc.
> > + *
> > + * Author: Hyun Woo Kwon
> > + *
> > + * SPDX-License-Identifier: GPL-2.0
> > + */
> > +
> > +#include
> > +
> > +#include
> > +
> > +#include "xlnx_crtc.h"
> > +
> > +/*
> > + * Overview
> > + *
> > + *
> > + * The Xilinx CRTC layer is to enable the custom interface to CRTC drivers.
> > + * The interface is used by Xilinx DRM driver where it needs CRTC
> > + * functionailty. CRTC drivers should attach the desired callbacks
> > + * to struct xlnx_crtc and register the xlnx_crtc with correcsponding
> > + * drm_device. It's highly recommended CRTC drivers register all
> callbacks
> > + * even though many of them are optional.
> > + * The CRTC helper simply walks through the registered CRTC device,
> > + * and call the callbacks.
> > + */
> > +
> > +/**
> > + * struct xlnx_crtc_helper - Xilinx CRTC helper
> > + * @xlnx_crtcs: list of Xilinx CRTC devices
> > + * @lock: lock to protect @xlnx_crtcs
> > + * @drm: back pointer to DRM core
> > + */
> > +struct xlnx_crtc_helper {
> > + struct list_head xlnx_crtcs;
> > + struct mutex lock; /* lock for @xlnx_crtcs */
> > + struct drm_device *drm;
> > +};
> > +
> > +#define XLNX_CRTC_MAX_HEIGHT_WIDTH UINT_MAX
> > +
> > +int xlnx_crtc_helper_enable_vblank(struct xlnx_crtc_helper *helper,
> > + unsigned int crtc_id)
> > +{
> > + struct xlnx_crtc *crtc;
> > +
> > + list_for_each_entry(crtc, &helper->xlnx_crtcs, list)
> > + if (drm_crtc_index(&crtc->crtc) == crtc_id)
> > + if (crtc->enable_vblank)
> > + return crtc->enable_vblank(crtc);
> > + return -ENODEV;
> > +}
> > +
> > +void xlnx_crtc_helper_disable_vblank(struct xlnx_crtc_helper *helper,
> > +unsigned int crtc_id)
> > +{
> > + struct xlnx_crtc *crtc;
> > +
> > + list_for_each_entry(crtc, &helper->xlnx_crtcs, list) {
> > + if (drm_crtc_index(&crtc->crtc) == crtc_id) {
> > + if (crtc->disable_vblank)
> > + crtc->disable_vblank(crtc);
> > + return;
> > + }
> > + }
> > +}
> > +
> > +unsigned int xlnx_crtc_helper_get_align(struct xlnx_crtc_helper *helper)
> > +{
> > + struct xlnx_crtc *crtc;
> > + unsigned int align = 1, tmp;
> > +
> > + list_for_each_entry(crtc, &helper->xlnx_crtcs, list) {
> > + if (crtc->get_align) {
> > + tmp = crtc->get_align(crtc);
> > + align = ALIGN(align, tmp);
> > + }
> > + }
> > +
> > + return align;
> > +}
> > +
> > +u64 xlnx_crtc_helper_get_dma_mask(struct xlnx_crtc_helper *helper)
> > +{
> > + struct xlnx_crtc *crtc;
> > + u64 mask = DMA_BIT_MASK(sizeof(dma_addr_t) * 8), tmp;
> > +
> > + list_for_each_entry(crtc, &helper->xlnx_crtcs, list) {
> > + if (crtc->get_dma_mask) {
> > + tmp = crtc->get_dma_mask(crtc);
> > + mask = min(mask, tmp);
> > + }
> > + }
> > +
> > + return mask;
> > +}
> > +
> > +int xlnx_crtc_helper_get_max_width(struct xlnx_crtc_helper *helper)
> > +{
> > + struct xlnx_crtc *crtc;
> > + unsigned int width = XLNX_CRTC_MAX_HEIGHT_WIDTH, tmp;
> > +
> > + list_for_each_entry(crtc, &helper->xlnx_crtcs, list) {
> > + if (crtc->get_max_width) {
> > + tmp = crtc->get_max_width(crtc);
> > + width = min(width, tmp);
> > + }
> > + }
> > +
>
Re: [RFC][PATCH 1/5] drm_hwcomposer: provide a common gralloc handle definition
On Wed, Jan 10, 2018 at 12:39 PM, Rob Herring wrote: > On Wed, Jan 10, 2018 at 12:05 AM, John Stultz wrote: >> From: Rob Herring >> >> EGL, gralloc, and HWC must all have a common definition of fd's and int's >> in native_handle_t to share the fd and width, height, format, etc. of a >> dmabuf. >> >> Move the definition into HWC so we aren't dependent on a specific gralloc >> implementation and so we don't have to create an importer just for >> different native_handle_t layouts. This will allow supporting multiple >> gralloc implementations that conform to this layout. >> >> For now, this is aligned with gbm_gralloc's struct. Once we change >> gbm_gralloc and mesa to point to this copy, we can make modifications to >> the struct. >> >> Change-Id: I0e0e9994c7a13e6c47f00a70d13cd2ef9b1543d3 >> Cc: Marissa Wall >> Cc: Sean Paul >> Cc: Dmitry Shmidt >> Cc: Robert Foss >> Cc: Matt Szczesiak >> Cc: Liviu Dudau >> Cc: David Hanna >> Signed-off-by: Rob Herring >> [jstultz: This patch is important to be able to build AOSP >> without having to include the gbm_gralloc project.] >> Signed-off-by: John Stultz >> --- >> Android.mk | 1 - >> gralloc_drm_handle.h | 87 >> >> 2 files changed, 87 insertions(+), 1 deletion(-) >> create mode 100644 gralloc_drm_handle.h > > We have since decided that libdrm is a better place for this. Robert > Foss is working on that. > > But you shouldn't need this at all with your custom importer. Unfortunately the platformdrmgeneric.cpp is part of the build either way, and tries to #include the gralloc_drm_handle.h file (the USE_DRM_GENERIC_IMPORTER conditional is under the includes), which causes build failures. But I'll rework the Andorid.mk logic to conditionally add the platformhisi.cpp or platformdrmgeneric.cpp so this patch can be skipped. thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Xen-devel] [RFC PATCH 01/60] hyper_dmabuf: initial working version of hyper_dmabuf drv
On Wed, Dec 20, 2017 at 09:17:07AM +0100, Juergen Gross wrote: > On 20/12/17 00:27, Dongwon Kim wrote: > > I forgot to include this brief information about this patch series. > > > > This patch series contains the implementation of a new device driver, > > hyper_dmabuf, which provides a method for DMA-BUF sharing across > > different OSes running on the same virtual OS platform powered by > > a hypervisor. > > Some general remarks regarding this series: > > You are starting the whole driver in drivers/xen/ and in the last patch > you move it over to drivers/dma-buf/. Why don't you use drivers/dma-buf/ > from the beginning? The same applies to e.g. patch 22 changing the > license. Please make it easier for the reviewers by not letting us > review the development history of your work. Yeah, I tried to clean up our developement history but because of dependencies among patches, I couldn't make those things clear in the first place. I will try to clean things up further. > > Please run ./scripts/checkpatch.pl on each patch and correct the issues > it is reporting. At the first glance I've seen several style problems > which I won't comment until the next round. hmm.. I ran the script only on the final version and try to fix all the issues after that. If it's required for individual patches, I will clean up every patch once again. > > Please add the maintainers as Cc:, not only the related mailing lists. > As you seem to aim supporting other hypervisors than Xen you might want > to add virtualizat...@lists.linux-foundation.org as well. Ok, thanks! > > > Juergen ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 01/60] hyper_dmabuf: initial working version of hyper_dmabuf drv
On Wed, Dec 20, 2017 at 10:59:57AM +0100, Daniel Vetter wrote: > On Tue, Dec 19, 2017 at 03:27:31PM -0800, Dongwon Kim wrote: > > I forgot to include this brief information about this patch series. > > > > This patch series contains the implementation of a new device driver, > > hyper_dmabuf, which provides a method for DMA-BUF sharing across > > different OSes running on the same virtual OS platform powered by > > a hypervisor. > > > > Detailed information about this driver is described in a high-level doc > > added by the second patch of the series. > > > > [RFC PATCH 02/60] hyper_dmabuf: added a doc for hyper_dmabuf sharing > > > > I am attaching 'Overview' section here as a summary. > > > > -- > > Section 1. Overview > > -- > > > > Hyper_DMABUF driver is a Linux device driver running on multiple Virtual > > achines (VMs), which expands DMA-BUF sharing capability to the VM > > environment > > where multiple different OS instances need to share same physical data > > without > > data-copy across VMs. > > > > To share a DMA_BUF across VMs, an instance of the Hyper_DMABUF drv on the > > exporting VM (so called, “exporter”) imports a local DMA_BUF from the > > original > > producer of the buffer, then re-exports it with an unique ID, > > hyper_dmabuf_id > > for the buffer to the importing VM (so called, “importer”). > > > > Another instance of the Hyper_DMABUF driver on importer registers > > a hyper_dmabuf_id together with reference information for the shared > > physical > > pages associated with the DMA_BUF to its database when the export happens. > > > > The actual mapping of the DMA_BUF on the importer’s side is done by > > the Hyper_DMABUF driver when user space issues the IOCTL command to access > > the shared DMA_BUF. The Hyper_DMABUF driver works as both an importing and > > exporting driver as is, that is, no special configuration is required. > > Consequently, only a single module per VM is needed to enable cross-VM > > DMA_BUF > > exchange. > > So I know that most dma-buf implementations (especially lots of importers > in drivers/gpu) break this, but fundamentally only the original exporter > is allowed to know about the underlying pages. There's various scenarios > where a dma-buf isn't backed by anything like a struct page. > > So your first step of noodling the underlying struct page out from the > dma-buf is kinda breaking the abstraction, and I think it's not a good > idea to have that. Especially not for sharing across VMs. > > I think a better design would be if hyper-dmabuf would be the dma-buf > exporter in both of the VMs, and you'd import it everywhere you want to in > some gpu/video/whatever driver in the VMs. That way hyper-dmabuf is always > in control of the pages, and a lot of the troubling forwarding you > currently need to do disappears. It could be another way to implement dma-buf sharing however, it would break the flexibility and transparency that this driver has now. With suggested method, there will be two different types of dma-buf exist in general usage model, one is local-dmabuf, a traditional dmabuf that can be shared only within in the same OS instance and the other is cross-vm sharable dmabuf created by hyper_dmabuf driver. The problem with this approach is that an application needs to know whether the contents will be shared or not across VMs in advance before deciding what type of dma-buf it needs to create. Otherwise, the application should always use hyper_dmabuf as the exporter for all contents that can be possibly shared in the future and I think this will require significant amount of application changes and also adds unnecessary dependency on hyper_dmabuf driver. > > 2nd thing: This seems very much related to what's happening around gvt and > allowing at least the host (in a kvm based VM environment) to be able to > access some of the dma-buf (or well, framebuffers in general) that the > client is using. Adding some mailing lists for that. I think you are talking about exposing framebuffer to another domain via GTT memory sharing. And yes, one of primary use cases for hyper_dmabuf is to share a framebuffer or other graphic object across VMs but it is designed to do it via more general way using existing dma-buf framework. Also, we wanted to make this feature available virtually for any sharable contents which can currently be shared via dma-buf locally. > -Daniel > > > > > -- > > > > There is a git repository at github.com where this series of patches are all > > integrated in Linux kernel tree based on the commit: > > > > commit ae64f9bd1d3621b5e60d7363bc20afb46aede215 > > Author: Linus Torvalds > > Date: Sun Dec 3 11:01:47 2017 -0500 > > > > Linux 4.15-rc2 > > > >
Re: [Xen-devel] [RFC PATCH 01/60] hyper_dmabuf: initial working version of hyper_dmabuf drv
Yes, I will post a test application. Thanks On Wed, Dec 20, 2017 at 10:38:08AM +0200, Oleksandr Andrushchenko wrote: > > On 12/20/2017 01:27 AM, Dongwon Kim wrote: > >This patch series contains the implementation of a new device driver, > >hyper_dmabuf, which provides a method for DMA-BUF sharing across > >different OSes running on the same virtual OS platform powered by > >a hypervisor. > This is very interesting at least in context of embedded systems. > Could you please share use-cases for this work and, if possible, > sources of the test applications if any. > > Thank you, > Oleksandr ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99353] Kaveri 7400K shows random colored noise instead of GUI in X or Wayland
https://bugs.freedesktop.org/show_bug.cgi?id=99353 --- Comment #14 from Bong Cosca --- I have the same setup and I'm experiencing the same symptoms. 7400K on Asus A68HM-K with VGA/DVI-D output on ArchLinux 4.14.12 Xorg 1.19.6, colored noise (sometimes tiled garbage). I tried every possible combination of kernel and R600_DEBUG flags along with xorg.conf options with same result. Both amdgpu and radeon drivers exhibit identical behavior. Any updates on this issue? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdkfd: Fix potential NULL pointer dereferences
Yeah, this looks good to me.
Regards,
Felix
On 2018-01-10 04:58 PM, Gustavo A. R. Silva wrote:
> Hi Felix,
>
> Quoting Felix Kuehling :
>
>> Hi Gustavo,
>>
>> Thanks for catching that. When returning a fault, I think you also need
>> to srcu_read_unlock(&kfd_processes_srcu, idx).
>>
>> However, instead of returning an error, I think I'd prefer to skip PDDs
>> that can't be found with continue statements. That way others would
>> still suspend and resume successfully. Maybe just print a WARN_ON for
>> PDDs that aren't found, because that's an unexpected situation,
>> currently. Maybe in the future it could be normal thing if we ever
>> support GPU hotplug.
>>
>
> I got it. In that case, what do you think about the following patch
> instead?
>
> index a22fb071..4ff5f0f 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> @@ -461,7 +461,8 @@ int kfd_bind_processes_to_device(struct kfd_dev *dev)
> hash_for_each_rcu(kfd_processes_table, temp, p, kfd_processes) {
> mutex_lock(&p->mutex);
> pdd = kfd_get_process_device_data(dev, p);
> - if (pdd->bound != PDD_BOUND_SUSPENDED) {
> +
> + if (WARN_ON(!pdd) || pdd->bound != PDD_BOUND_SUSPENDED) {
> mutex_unlock(&p->mutex);
> continue;
> }
> @@ -501,6 +502,11 @@ void kfd_unbind_processes_from_device(struct
> kfd_dev *dev)
> mutex_lock(&p->mutex);
> pdd = kfd_get_process_device_data(dev, p);
>
> + if (WARN_ON(!pdd)) {
> + mutex_unlock(&p->mutex);
> + continue;
> + }
> +
> if (pdd->bound == PDD_BOUND)
> pdd->bound = PDD_BOUND_SUSPENDED;
> mutex_unlock(&p->mutex);
>
>
> Thank you for the feedback.
> --
> Gustavo
>
>> Regards,
>> Felix
>>
>>
>> On 2018-01-10 11:50 AM, Gustavo A. R. Silva wrote:
>>> In case kfd_get_process_device_data returns null, there are some
>>> null pointer dereferences in functions kfd_bind_processes_to_device
>>> and kfd_unbind_processes_from_device.
>>>
>>> Fix this by null checking pdd before dereferencing it.
>>>
>>> Addresses-Coverity-ID: 1463794 ("Dereference null return value")
>>> Addresses-Coverity-ID: 1463772 ("Dereference null return value")
>>> Signed-off-by: Gustavo A. R. Silva
>>> ---
>>> drivers/gpu/drm/amd/amdkfd/kfd_process.c | 12
>>> 1 file changed, 12 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
>>> b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
>>> index a22fb071..29d51d5 100644
>>> --- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
>>> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
>>> @@ -461,6 +461,13 @@ int kfd_bind_processes_to_device(struct kfd_dev
>>> *dev)
>>> hash_for_each_rcu(kfd_processes_table, temp, p, kfd_processes) {
>>> mutex_lock(&p->mutex);
>>> pdd = kfd_get_process_device_data(dev, p);
>>> +
>>> + if (!pdd) {
>>> + pr_err("Process device data doesn't exist\n");
>>> + mutex_unlock(&p->mutex);
>>> + return -EFAULT;
>>> + }
>>> +
>>> if (pdd->bound != PDD_BOUND_SUSPENDED) {
>>> mutex_unlock(&p->mutex);
>>> continue;
>>> @@ -501,6 +508,11 @@ void kfd_unbind_processes_from_device(struct
>>> kfd_dev *dev)
>>> mutex_lock(&p->mutex);
>>> pdd = kfd_get_process_device_data(dev, p);
>>>
>>> + if (!pdd) {
>>> + mutex_unlock(&p->mutex);
>>> + return;
>>> + }
>>> +
>>> if (pdd->bound == PDD_BOUND)
>>> pdd->bound = PDD_BOUND_SUSPENDED;
>>> mutex_unlock(&p->mutex);
>
>
>
>
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu, radeon, ttm drm-next-4.16
Hi Dave, A few fixes for 4.16: - Cleanup the the remains of ttm io_mem_pfn - A couple dpm quirks for SI - Add Chunming as another amdgpu maintainer - A few more huge page fixes - A few other misc fixes The following changes since commit fb8baefc7b2d7b93ad96abacbe63fa99e3d213d6: drm/amdgpu: use %pap format string for phys_addr_t (2018-01-09 10:59:28 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-4.16 for you to fetch changes up to ad8cec7df5d4bf3b1109fabbb1d61663857045ae: drm/amd/pp: Implement get_max_high_clocks for CI/VI (2018-01-10 15:44:55 -0500) Alex Deucher (4): drm/radeon: Add dpm quirk for Jet PRO (v2) drm/amdgpu: Add dpm quirk for Jet PRO (v2) drm/amdgpu: add atpx quirk handling (v2) drm/amdgpu/gfx9: only init the apertures used by KGD (v2) Christian König (8): drm/ttm: specify DMA_ATTR_NO_WARN for huge page pools drm/amdgpu: loosen the criteria for huge pages a bit drm/amdgpu: minor optimize VM moved handling v2 drm/amdgpu: update VM PDs after the PTs drm/amdgpu: simplify huge page handling drm/amdgpu: optimize moved handling only when vm_debug is inactive drm/amdgpu: fix 64bit BAR detection MAINTAINERS: add David (Chunming) Zhou as additional amdgpu maintainer Evan Quan (1): drm/amd/powerplay: set pp_num_states as 0 on error situation Rex Zhu (1): drm/amd/pp: Implement get_max_high_clocks for CI/VI Tan Xiaojun (2): staging: remove the default io_mem_pfn set drm/ttm: remove ttm_bo_default_io_mem_pfn Yintian Tao (1): drm/amd/powerplay: fix memory leakage when reload (v2) MAINTAINERS| 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 57 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 8 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 8 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 78 +- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/si_dpm.c| 5 ++ drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 2 + drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 20 ++ drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c | 6 ++ drivers/gpu/drm/radeon/si_dpm.c| 5 ++ drivers/gpu/drm/ttm/ttm_bo_vm.c| 11 +-- drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 8 ++- drivers/staging/vboxvideo/vbox_ttm.c | 1 - include/drm/ttm/ttm_bo_api.h | 11 --- 16 files changed, 139 insertions(+), 86 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] drm/msm: msm-next for 4.16
Hi Dave, Updates for 4.16.. fairly small this time around, main thing is devfreq support for the gpu. The following changes since commit 9428088c90b6f7d5edd2a1b0d742c75339b36f6e: drm/qxl: reapply cursor after resetting primary (2017-12-08 13:37:02 +1000) are available in the Git repository at: git://people.freedesktop.org/~robclark/linux tags/drm-msm-next-2018-01-10 for you to fetch changes up to f91c14ab448af4d9d57350301dd9d6b6a7b6128a: drm/msm: Add devfreq support for the GPU (2018-01-10 14:30:03 -0500) Archit Taneja (1): drm/msm: Fix NULL deref in adreno_load_gpu Arnd Bergmann (2): drm/msm: fix msm_rd_dump_submit prototype drm/msm: avoid false-positive -Wmaybe-uninitialized warning Colin Ian King (1): drm/msm: fix spelling mistake: "ringubffer" -> "ringbuffer" Jordan Crouse (9): drm/msm: gpu: Only sync fences on rings that exist drm/msm/adreno: Call dev_pm_opp_put() drm/msm/adreno: Remove a useless call to dev_pm_opp_get_freq() drm/msm/gpu: Remove unused bus scaling code drm/msm/adreno: Cleanup chipid parsing drm/msm/adreno: Move clock parsing to adreno_gpu_init() drm/msm/adreno: Read the speed bins for a5xx targets drm/msm/adreno: a5xx: Explicitly program the CP0 performance counter drm/msm: Add devfreq support for the GPU Lukas Wunner (1): drm/msm/mdp4: Deduplicate bus_find_device() by name matching Nicolas Dechesne (2): drm/msm: update adreno firmware path in MODULE_FIRMWARE drm/msm: add missing MODULE_FIRMWARE declarations Prakash Kamliya (1): drm/msm: fix leak in failed get_pages Rob Clark (1): drm/msm: free kstrdup'd cmdline drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 38 drivers/gpu/drm/msm/adreno/a5xx_power.c| 8 +- drivers/gpu/drm/msm/adreno/adreno_device.c | 140 - drivers/gpu/drm/msm/adreno/adreno_gpu.c| 85 +++--- drivers/gpu/drm/msm/adreno/adreno_gpu.h| 4 - drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h| 7 +- drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 9 +- drivers/gpu/drm/msm/msm_drv.h | 3 +- drivers/gpu/drm/msm/msm_gem.c | 14 ++- drivers/gpu/drm/msm/msm_gpu.c | 112 +-- drivers/gpu/drm/msm/msm_gpu.h | 14 +-- 11 files changed, 264 insertions(+), 170 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 1/5] drm_hwcomposer: provide a common gralloc handle definition
On Wed, Jan 10, 2018 at 12:05 AM, John Stultz wrote: > From: Rob Herring > > EGL, gralloc, and HWC must all have a common definition of fd's and int's > in native_handle_t to share the fd and width, height, format, etc. of a > dmabuf. > > Move the definition into HWC so we aren't dependent on a specific gralloc > implementation and so we don't have to create an importer just for > different native_handle_t layouts. This will allow supporting multiple > gralloc implementations that conform to this layout. > > For now, this is aligned with gbm_gralloc's struct. Once we change > gbm_gralloc and mesa to point to this copy, we can make modifications to > the struct. > > Change-Id: I0e0e9994c7a13e6c47f00a70d13cd2ef9b1543d3 > Cc: Marissa Wall > Cc: Sean Paul > Cc: Dmitry Shmidt > Cc: Robert Foss > Cc: Matt Szczesiak > Cc: Liviu Dudau > Cc: David Hanna > Signed-off-by: Rob Herring > [jstultz: This patch is important to be able to build AOSP > without having to include the gbm_gralloc project.] > Signed-off-by: John Stultz > --- > Android.mk | 1 - > gralloc_drm_handle.h | 87 > > 2 files changed, 87 insertions(+), 1 deletion(-) > create mode 100644 gralloc_drm_handle.h We have since decided that libdrm is a better place for this. Robert Foss is working on that. But you shouldn't need this at all with your custom importer. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] libdrm: intel/Android.mk: Filter libdrm_intel library requirements on x86
On Wed, Jan 10, 2018 at 1:09 PM, John Stultz wrote: > On Wed, Jan 10, 2018 at 5:48 AM, Rob Herring wrote: >> On Tue, Jan 9, 2018 at 11:25 PM, John Stultz wrote: >>> When building AOSP after updating libdrm project to the >>> freedesktop/master branch, I've seen the following build errors: >>> >>> external/libdrm/intel/Android.mk: error: libdrm_intel >> >> This is only needed for i915 (not i965) now BTW. I'm not sure at what >> point we stop caring about i915. >> >>> (SHARED_LIBRARIES android-arm64) missing libpciaccess >>> (SHARED_LIBRARIES android-arm64) You can set >>> ALLOW_MISSING_DEPENDENCIES=true in your environment if this is >>> intentional, but that may defer real problems until later in the >>> build. >>> >>> Using ALLOW_MISSING_DEPENDENCIES=true when building allows >>> things to function properly, but is not ideal. >>> >>> So basically, while I'm not including the libdrm_intel package >>> into the build, just the fact that the Android.mk file references >>> libpciaccess which isn't a repo included in AOSP causes the build >>> failure. >>> >>> So it seems we need some sort of conditional filter in the >>> Android.mk to skip over it if we're not building for intel. >>> >>> This is my initial attempt at solving this. >>> >>> Feedback would be greatly appreciated! >>> >>> I note that in the AOSP version of libdrm, the reference to >>> libpciaccess has been removed. See: >>> >>> https://android.googlesource.com/platform/external/libdrm/+/f6a1130dffae8de9ddd0c379066daf1df27fc8af%5E%21/ >>> So I wonder if it make sense to instead remove this upstream as >>> well? >> >> Only if we drop i915. > > To be more precise, drop i915 for Android builds (I'm not suggesting > dropping it elsewhere, just for the Android.mk). I'm really not sure > which devices might be affected. Anyone able to point me to someone in > Intel who would know? The android-x86 folks would be the ones to ask. I added Chih-Wei. >>> +ifeq ($(TARGET_ARCH), x86) >> >> This doesn't work for x86_64. i915 and 64-bit may not be a valid >> combination, not sure, but we do at least build test that. > > Out of curiosity, which environment is being used for this build > testing? Are you describing your generic-build/qemu work or something > else done as part of freedesktop.org? The CI job I setup to build mesa master (and libdrm implicitly). Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits, v2.
On Wed, Jan 10, 2018 at 6:00 AM, Maarten Lankhorst
wrote:
> From: "Leo (Sunpeng) Li"
>
> During a non-blocking commit, it is possible to return before the
> commit_tail work is queued (-ERESTARTSYS, for example).
>
> Since a reference on the crtc commit object is obtained for the pending
> vblank event when preparing the commit, the above situation will leave
> us with an extra reference.
>
> Therefore, if the commit_tail worker has not consumed the event at the
> end of a commit, release it's reference.
>
> Changes since v1:
> - Also check for state->event->base.completion being set, to
> handle the case where stall_checks() fails in setup_crtc_commit().
>
> Fixes: 24835e442f28 ("drm: reference count event->completion")
Thanks for fixing this up. You mentioned on IRC that this version
still caused problems. What were those?
Thanks,
Alex
> Cc: # v4.11+
> Signed-off-by: Leo (Sunpeng) Li
> Acked-by: Harry Wentland #v1
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index b16f1d69a0bb..1d43f3e85a7d 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3327,6 +3327,15 @@ EXPORT_SYMBOL(drm_atomic_helper_crtc_duplicate_state);
> void __drm_atomic_helper_crtc_destroy_state(struct drm_crtc_state *state)
> {
> if (state->commit) {
> + /*
> +* In the event that a non-blocking commit returns
> +* -ERESTARTSYS before the commit_tail work is queued, we will
> +* have an extra reference to the commit object. Release it,
> if
> +* the event has not been consumed by the worker.
> +*/
> + if (state->event && state->event->base.completion)
> + drm_crtc_commit_put(state->commit);
> +
> kfree(state->commit->event);
> state->commit->event = NULL;
> drm_crtc_commit_put(state->commit);
> --
> 2.15.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-staging-drm-next 374/952] sound/soc/amd/raven/acp3x.h:28:9: error: implicit declaration of function 'readl'; did you mean 'vread'?
Hi Maruthi,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: 95b5f448bf04b220423808df1bb36ca1bd07b270
commit: c1888183e1764d55d51ae051bd8651e634febe4d [374/952] ASoC: AMD: enable
ACP3x drivers build
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.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 c1888183e1764d55d51ae051bd8651e634febe4d
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
In file included from sound/soc/amd/raven/acp3x-pcm-dma.c:26:0:
sound/soc/amd/raven/acp3x.h: In function 'rv_readl':
>> sound/soc/amd/raven/acp3x.h:28:9: error: implicit declaration of function
>> 'readl'; did you mean 'vread'? [-Werror=implicit-function-declaration]
return readl(base_addr - ACP3x_PHY_BASE_ADDRESS);
^
vread
sound/soc/amd/raven/acp3x.h: In function 'rv_writel':
>> sound/soc/amd/raven/acp3x.h:33:2: error: implicit declaration of function
>> 'writel'; did you mean 'vwrite'? [-Werror=implicit-function-declaration]
writel(val, base_addr - ACP3x_PHY_BASE_ADDRESS);
^~
vwrite
sound/soc/amd/raven/acp3x-pcm-dma.c: In function 'acp3x_audio_probe':
>> sound/soc/amd/raven/acp3x-pcm-dma.c:638:22: error: implicit declaration of
>> function 'devm_ioremap'; did you mean 'devm_kmemdup'?
>> [-Werror=implicit-function-declaration]
adata->acp3x_base = devm_ioremap(&pdev->dev, res->start,
^~~~
devm_kmemdup
sound/soc/amd/raven/acp3x-pcm-dma.c:638:20: warning: assignment makes
pointer from integer without a cast [-Wint-conversion]
adata->acp3x_base = devm_ioremap(&pdev->dev, res->start,
^
cc1: some warnings being treated as errors
vim +28 sound/soc/amd/raven/acp3x.h
0360f007 Maruthi Srinivas Bayyavarapu 2017-03-27 25
0360f007 Maruthi Srinivas Bayyavarapu 2017-03-27 26 static inline u32
rv_readl(void __iomem *base_addr)
0360f007 Maruthi Srinivas Bayyavarapu 2017-03-27 27 {
0360f007 Maruthi Srinivas Bayyavarapu 2017-03-27 @28return readl(base_addr
- ACP3x_PHY_BASE_ADDRESS);
0360f007 Maruthi Srinivas Bayyavarapu 2017-03-27 29 }
0360f007 Maruthi Srinivas Bayyavarapu 2017-03-27 30
0360f007 Maruthi Srinivas Bayyavarapu 2017-03-27 31 static inline void
rv_writel(u32 val, void __iomem *base_addr)
0360f007 Maruthi Srinivas Bayyavarapu 2017-03-27 32 {
0360f007 Maruthi Srinivas Bayyavarapu 2017-03-27 @33writel(val, base_addr -
ACP3x_PHY_BASE_ADDRESS);
:: The code at line 28 was first introduced by commit
:: 0360f0076fa5ee321ca46b062374c17decdcfbe2 ASoC: AMD: add ACP3.0 PCI driver
:: TO: Maruthi Srinivas Bayyavarapu
:: CC: Alex Deucher
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] libdrm: intel/Android.mk: Filter libdrm_intel library requirements on x86
On Wed, Jan 10, 2018 at 5:48 AM, Rob Herring wrote: > On Tue, Jan 9, 2018 at 11:25 PM, John Stultz wrote: >> When building AOSP after updating libdrm project to the >> freedesktop/master branch, I've seen the following build errors: >> >> external/libdrm/intel/Android.mk: error: libdrm_intel > > This is only needed for i915 (not i965) now BTW. I'm not sure at what > point we stop caring about i915. > >> (SHARED_LIBRARIES android-arm64) missing libpciaccess >> (SHARED_LIBRARIES android-arm64) You can set >> ALLOW_MISSING_DEPENDENCIES=true in your environment if this is >> intentional, but that may defer real problems until later in the >> build. >> >> Using ALLOW_MISSING_DEPENDENCIES=true when building allows >> things to function properly, but is not ideal. >> >> So basically, while I'm not including the libdrm_intel package >> into the build, just the fact that the Android.mk file references >> libpciaccess which isn't a repo included in AOSP causes the build >> failure. >> >> So it seems we need some sort of conditional filter in the >> Android.mk to skip over it if we're not building for intel. >> >> This is my initial attempt at solving this. >> >> Feedback would be greatly appreciated! >> >> I note that in the AOSP version of libdrm, the reference to >> libpciaccess has been removed. See: >> >> https://android.googlesource.com/platform/external/libdrm/+/f6a1130dffae8de9ddd0c379066daf1df27fc8af%5E%21/ >> So I wonder if it make sense to instead remove this upstream as >> well? > > Only if we drop i915. To be more precise, drop i915 for Android builds (I'm not suggesting dropping it elsewhere, just for the Android.mk). I'm really not sure which devices might be affected. Anyone able to point me to someone in Intel who would know? >> +ifeq ($(TARGET_ARCH), x86) > > This doesn't work for x86_64. i915 and 64-bit may not be a valid > combination, not sure, but we do at least build test that. Out of curiosity, which environment is being used for this build testing? Are you describing your generic-build/qemu work or something else done as part of freedesktop.org? thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/7] drm/tinydrm/mi0283qt: Use common include order
Include linux headers before drm headers as it's commonly done. Signed-off-by: Noralf Trønnes Reviewed-by: David Lechner --- drivers/gpu/drm/tinydrm/mi0283qt.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c b/drivers/gpu/drm/tinydrm/mi0283qt.c index 674d407640be..45f02b6052b1 100644 --- a/drivers/gpu/drm/tinydrm/mi0283qt.c +++ b/drivers/gpu/drm/tinydrm/mi0283qt.c @@ -9,17 +9,18 @@ * (at your option) any later version. */ -#include -#include -#include -#include -#include #include #include #include #include #include #include + +#include +#include +#include +#include +#include #include static int mi0283qt_init(struct mipi_dbi *mipi) -- 2.15.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/7] drm/tinydrm/mipi-dbi: Add mipi_dbi_enable_flush()
Add and use a function for enabling, flushing and turning on backlight.
Signed-off-by: Noralf Trønnes
Reviewed-by: David Lechner
---
drivers/gpu/drm/tinydrm/ili9225.c | 6 +-
drivers/gpu/drm/tinydrm/mipi-dbi.c | 20
drivers/gpu/drm/tinydrm/st7586.c | 6 +-
drivers/gpu/drm/tinydrm/st7735r.c | 2 +-
include/drm/tinydrm/mipi-dbi.h | 1 +
5 files changed, 24 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/tinydrm/ili9225.c
b/drivers/gpu/drm/tinydrm/ili9225.c
index c0cf49849302..a0759502b81a 100644
--- a/drivers/gpu/drm/tinydrm/ili9225.c
+++ b/drivers/gpu/drm/tinydrm/ili9225.c
@@ -180,7 +180,6 @@ static void ili9225_pipe_enable(struct
drm_simple_display_pipe *pipe,
{
struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
- struct drm_framebuffer *fb = pipe->plane.fb;
struct device *dev = tdev->drm->dev;
int ret;
u8 am_id;
@@ -269,10 +268,7 @@ static void ili9225_pipe_enable(struct
drm_simple_display_pipe *pipe,
ili9225_command(mipi, ILI9225_DISPLAY_CONTROL_1, 0x1017);
- mipi->enabled = true;
-
- if (fb)
- fb->funcs->dirty(fb, NULL, 0, 0, NULL, 0);
+ mipi_dbi_enable_flush(mipi);
}
static void ili9225_pipe_disable(struct drm_simple_display_pipe *pipe)
diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c
b/drivers/gpu/drm/tinydrm/mipi-dbi.c
index aa6b6ce56891..1c8ef0c4d6d4 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -270,6 +270,26 @@ static const struct drm_framebuffer_funcs
mipi_dbi_fb_funcs = {
.dirty = mipi_dbi_fb_dirty,
};
+/**
+ * mipi_dbi_enable_flush - MIPI DBI enable helper
+ * @mipi: MIPI DBI structure
+ *
+ * This function sets &mipi_dbi->enabled, flushes the whole framebuffer and
+ * enables the backlight. Drivers can use this in their
+ * &drm_simple_display_pipe_funcs->enable callback.
+ */
+void mipi_dbi_enable_flush(struct mipi_dbi *mipi)
+{
+ struct drm_framebuffer *fb = mipi->tinydrm.pipe.plane.fb;
+
+ mipi->enabled = true;
+ if (fb)
+ fb->funcs->dirty(fb, NULL, 0, 0, NULL, 0);
+
+ tinydrm_enable_backlight(mipi->backlight);
+}
+EXPORT_SYMBOL(mipi_dbi_enable_flush);
+
/**
* mipi_dbi_pipe_enable - MIPI DBI pipe enable helper
* @pipe: Display pipe
diff --git a/drivers/gpu/drm/tinydrm/st7586.c b/drivers/gpu/drm/tinydrm/st7586.c
index 5aebfceb740e..9fd4423c8e70 100644
--- a/drivers/gpu/drm/tinydrm/st7586.c
+++ b/drivers/gpu/drm/tinydrm/st7586.c
@@ -179,7 +179,6 @@ static void st7586_pipe_enable(struct
drm_simple_display_pipe *pipe,
{
struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
- struct drm_framebuffer *fb = pipe->plane.fb;
struct device *dev = tdev->drm->dev;
int ret;
u8 addr_mode;
@@ -241,10 +240,7 @@ static void st7586_pipe_enable(struct
drm_simple_display_pipe *pipe,
mipi_dbi_command(mipi, MIPI_DCS_SET_DISPLAY_ON);
- mipi->enabled = true;
-
- if (fb)
- fb->funcs->dirty(fb, NULL, 0, 0, NULL, 0);
+ mipi_dbi_enable_flush(mipi);
}
static void st7586_pipe_disable(struct drm_simple_display_pipe *pipe)
diff --git a/drivers/gpu/drm/tinydrm/st7735r.c
b/drivers/gpu/drm/tinydrm/st7735r.c
index 98ff447f40b4..1f38e15da676 100644
--- a/drivers/gpu/drm/tinydrm/st7735r.c
+++ b/drivers/gpu/drm/tinydrm/st7735r.c
@@ -102,7 +102,7 @@ static void jd_t18003_t01_pipe_enable(struct
drm_simple_display_pipe *pipe,
msleep(20);
- mipi_dbi_pipe_enable(pipe, crtc_state);
+ mipi_dbi_enable_flush(mipi);
}
static const struct drm_simple_display_pipe_funcs jd_t18003_t01_pipe_funcs = {
diff --git a/include/drm/tinydrm/mipi-dbi.h b/include/drm/tinydrm/mipi-dbi.h
index 5d0e82b36eaf..6441d9a9161a 100644
--- a/include/drm/tinydrm/mipi-dbi.h
+++ b/include/drm/tinydrm/mipi-dbi.h
@@ -67,6 +67,7 @@ int mipi_dbi_init(struct device *dev, struct mipi_dbi *mipi,
const struct drm_simple_display_pipe_funcs *pipe_funcs,
struct drm_driver *driver,
const struct drm_display_mode *mode, unsigned int rotation);
+void mipi_dbi_enable_flush(struct mipi_dbi *mipi);
void mipi_dbi_pipe_enable(struct drm_simple_display_pipe *pipe,
struct drm_crtc_state *crtc_state);
void mipi_dbi_pipe_disable(struct drm_simple_display_pipe *pipe);
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 6/7] drm/tinydrm: Embed the mode in tinydrm_connector
Embed the mode in tinydrm_connector instead of doing an devm_ allocation.
Remove unnecessary use of ret variable at the end of
tinydrm_display_pipe_init().
Signed-off-by: Noralf Trønnes
Reviewed-by: David Lechner
---
drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c | 34 +++--
1 file changed, 13 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
index f41fc506ff87..11ae950b0fc9 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
@@ -15,7 +15,7 @@
struct tinydrm_connector {
struct drm_connector base;
- const struct drm_display_mode *mode;
+ struct drm_display_mode mode;
};
static inline struct tinydrm_connector *
@@ -29,7 +29,7 @@ static int tinydrm_connector_get_modes(struct drm_connector
*connector)
struct tinydrm_connector *tconn = to_tinydrm_connector(connector);
struct drm_display_mode *mode;
- mode = drm_mode_duplicate(connector->dev, tconn->mode);
+ mode = drm_mode_duplicate(connector->dev, &tconn->mode);
if (!mode) {
DRM_ERROR("Failed to duplicate mode\n");
return 0;
@@ -92,7 +92,7 @@ tinydrm_connector_create(struct drm_device *drm,
if (!tconn)
return ERR_PTR(-ENOMEM);
- tconn->mode = mode;
+ drm_mode_copy(&tconn->mode, mode);
connector = &tconn->base;
drm_connector_helper_add(connector, &tinydrm_connector_hfuncs);
@@ -199,35 +199,27 @@ tinydrm_display_pipe_init(struct tinydrm_device *tdev,
unsigned int rotation)
{
struct drm_device *drm = tdev->drm;
- struct drm_display_mode *mode_copy;
+ struct drm_display_mode mode_copy;
struct drm_connector *connector;
int ret;
- mode_copy = devm_kmalloc(drm->dev, sizeof(*mode_copy), GFP_KERNEL);
- if (!mode_copy)
- return -ENOMEM;
-
- *mode_copy = *mode;
- ret = tinydrm_rotate_mode(mode_copy, rotation);
+ drm_mode_copy(&mode_copy, mode);
+ ret = tinydrm_rotate_mode(&mode_copy, rotation);
if (ret) {
DRM_ERROR("Illegal rotation value %u\n", rotation);
return -EINVAL;
}
- drm->mode_config.min_width = mode_copy->hdisplay;
- drm->mode_config.max_width = mode_copy->hdisplay;
- drm->mode_config.min_height = mode_copy->vdisplay;
- drm->mode_config.max_height = mode_copy->vdisplay;
+ drm->mode_config.min_width = mode_copy.hdisplay;
+ drm->mode_config.max_width = mode_copy.hdisplay;
+ drm->mode_config.min_height = mode_copy.vdisplay;
+ drm->mode_config.max_height = mode_copy.vdisplay;
- connector = tinydrm_connector_create(drm, mode_copy, connector_type);
+ connector = tinydrm_connector_create(drm, &mode_copy, connector_type);
if (IS_ERR(connector))
return PTR_ERR(connector);
- ret = drm_simple_display_pipe_init(drm, &tdev->pipe, funcs, formats,
- format_count, NULL, connector);
- if (ret)
- return ret;
-
- return 0;
+ return drm_simple_display_pipe_init(drm, &tdev->pipe, funcs, formats,
+ format_count, NULL, connector);
}
EXPORT_SYMBOL(tinydrm_display_pipe_init);
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 7/7] drm/tinydrm/mipi-dbi: Change reset active time
The MIPI DBI spec states that reset active/low time should be more than 9us. Change from 20ms to 20us. Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/tinydrm/mipi-dbi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c b/drivers/gpu/drm/tinydrm/mipi-dbi.c index 6798b4837441..75dd65c57e74 100644 --- a/drivers/gpu/drm/tinydrm/mipi-dbi.c +++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c @@ -414,7 +414,7 @@ void mipi_dbi_hw_reset(struct mipi_dbi *mipi) return; gpiod_set_value_cansleep(mipi->reset, 0); - msleep(20); + usleep_range(20, 1000); gpiod_set_value_cansleep(mipi->reset, 1); msleep(120); } -- 2.15.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 5/7] drm/tinydrm/mi0283qt: Let the display pipe handle power
It's better to leave power handling and controller init to the
modesetting machinery using the simple pipe .enable and .disable
callbacks. Remove unused mipi_dbi_pipe_enable().
Signed-off-by: Noralf Trønnes
Reviewed-by: David Lechner
---
drivers/gpu/drm/tinydrm/mi0283qt.c | 47 --
drivers/gpu/drm/tinydrm/mipi-dbi.c | 32 --
include/drm/tinydrm/mipi-dbi.h | 2 --
3 files changed, 15 insertions(+), 66 deletions(-)
diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index 1617405faed4..79cb5af5abac 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -47,8 +47,11 @@
#define ILI9341_MADCTL_MX BIT(6)
#define ILI9341_MADCTL_MY BIT(7)
-static int mi0283qt_init(struct mipi_dbi *mipi)
+static void mi0283qt_enable(struct drm_simple_display_pipe *pipe,
+ struct drm_crtc_state *crtc_state)
{
+ struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
+ struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
u8 addr_mode;
int ret;
@@ -56,9 +59,9 @@ static int mi0283qt_init(struct mipi_dbi *mipi)
ret = mipi_dbi_poweron_conditional_reset(mipi);
if (ret < 0)
- return ret;
+ return;
if (ret == 1)
- return 0;
+ goto out_enable;
mipi_dbi_command(mipi, MIPI_DCS_SET_DISPLAY_OFF);
@@ -121,19 +124,12 @@ static int mi0283qt_init(struct mipi_dbi *mipi)
mipi_dbi_command(mipi, MIPI_DCS_SET_DISPLAY_ON);
msleep(100);
- return 0;
-}
-
-static void mi0283qt_fini(void *data)
-{
- struct mipi_dbi *mipi = data;
-
- DRM_DEBUG_KMS("\n");
- regulator_disable(mipi->regulator);
+out_enable:
+ mipi_dbi_enable_flush(mipi);
}
static const struct drm_simple_display_pipe_funcs mi0283qt_pipe_funcs = {
- .enable = mipi_dbi_pipe_enable,
+ .enable = mi0283qt_enable,
.disable = mipi_dbi_pipe_disable,
.update = tinydrm_display_pipe_update,
.prepare_fb = tinydrm_display_pipe_prepare_fb,
@@ -214,17 +210,6 @@ static int mi0283qt_probe(struct spi_device *spi)
if (ret)
return ret;
- ret = mi0283qt_init(mipi);
- if (ret)
- return ret;
-
- /* use devres to fini after drm unregister (drv->remove is before) */
- ret = devm_add_action(dev, mi0283qt_fini, mipi);
- if (ret) {
- mi0283qt_fini(mipi);
- return ret;
- }
-
spi_set_drvdata(spi, mipi);
return devm_tinydrm_register(&mipi->tinydrm);
@@ -240,25 +225,13 @@ static void mi0283qt_shutdown(struct spi_device *spi)
static int __maybe_unused mi0283qt_pm_suspend(struct device *dev)
{
struct mipi_dbi *mipi = dev_get_drvdata(dev);
- int ret;
- ret = drm_mode_config_helper_suspend(mipi->tinydrm.drm);
- if (ret)
- return ret;
-
- mi0283qt_fini(mipi);
-
- return 0;
+ return drm_mode_config_helper_suspend(mipi->tinydrm.drm);
}
static int __maybe_unused mi0283qt_pm_resume(struct device *dev)
{
struct mipi_dbi *mipi = dev_get_drvdata(dev);
- int ret;
-
- ret = mi0283qt_init(mipi);
- if (ret)
- return ret;
drm_mode_config_helper_resume(mipi->tinydrm.drm);
diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c
b/drivers/gpu/drm/tinydrm/mipi-dbi.c
index 3e879d605ed3..6798b4837441 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -290,31 +290,6 @@ void mipi_dbi_enable_flush(struct mipi_dbi *mipi)
}
EXPORT_SYMBOL(mipi_dbi_enable_flush);
-/**
- * mipi_dbi_pipe_enable - MIPI DBI pipe enable helper
- * @pipe: Display pipe
- * @crtc_state: CRTC state
- *
- * This function enables backlight. Drivers can use this as their
- * &drm_simple_display_pipe_funcs->enable callback.
- */
-void mipi_dbi_pipe_enable(struct drm_simple_display_pipe *pipe,
- struct drm_crtc_state *crtc_state)
-{
- struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
- struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
- struct drm_framebuffer *fb = pipe->plane.fb;
-
- DRM_DEBUG_KMS("\n");
-
- mipi->enabled = true;
- if (fb)
- fb->funcs->dirty(fb, NULL, 0, 0, NULL, 0);
-
- tinydrm_enable_backlight(mipi->backlight);
-}
-EXPORT_SYMBOL(mipi_dbi_pipe_enable);
-
static void mipi_dbi_blank(struct mipi_dbi *mipi)
{
struct drm_device *drm = mipi->tinydrm.drm;
@@ -336,8 +311,8 @@ static void mipi_dbi_blank(struct mipi_dbi *mipi)
* mipi_dbi_pipe_disable - MIPI DBI pipe disable helper
* @pipe: Display pipe
*
- * This function disables backlight if present or if not the
- * display memory is blanked. Drivers can use this as their
+ * This function disables backlight if present, if not the display memory is
+ * blanked. The regul
[PATCH v3 0/7] drm/tinydrm: Cleanup
Fix a few things that came up during the tinydrm review but wasn't addressed at the time. Noralf. Changes since version 2: - s/mipi_dbi_por_conditional/mipi_dbi_poweron_reset_conditional/ - Add sleep after soft reset to comply with spec. - Remove reset msleep from mi0283qt following the previous change. - Use (ret == 1) to test for display is ON, no reset. - Add patch to change hard reset active time. Changes since version 1: - Add mipi_dbi_enable_flush() instead of the pipe enable helper mipi_dbi_pipe_enable() that doesn't really fit anymore. - Add common poweron-reset functionality. - Use drm_mode_copy() instead of direct assignment Noralf Trønnes (7): drm/tinydrm/mi0283qt: Use common include order drm/tinydrm/mi0283qt: Remove ili9341.h drm/tinydrm/mipi-dbi: Add mipi_dbi_enable_flush() drm/tinydrm/mipi-dbi: Add poweron-reset functions drm/tinydrm/mi0283qt: Let the display pipe handle power drm/tinydrm: Embed the mode in tinydrm_connector drm/tinydrm/mipi-dbi: Change reset active time drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c | 34 - drivers/gpu/drm/tinydrm/ili9225.c | 6 +- drivers/gpu/drm/tinydrm/mi0283qt.c | 106 drivers/gpu/drm/tinydrm/mipi-dbi.c | 101 ++ drivers/gpu/drm/tinydrm/st7586.c| 15 ++-- drivers/gpu/drm/tinydrm/st7735r.c | 10 +-- include/drm/tinydrm/ili9341.h | 54 -- include/drm/tinydrm/mipi-dbi.h | 5 +- 8 files changed, 154 insertions(+), 177 deletions(-) delete mode 100644 include/drm/tinydrm/ili9341.h -- 2.15.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/7] drm/tinydrm/mipi-dbi: Add poweron-reset functions
Split out common poweron-reset functionality.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/tinydrm/mi0283qt.c | 22 ++--
drivers/gpu/drm/tinydrm/mipi-dbi.c | 73 ++
drivers/gpu/drm/tinydrm/st7586.c | 9 ++---
drivers/gpu/drm/tinydrm/st7735r.c | 8 ++---
include/drm/tinydrm/mipi-dbi.h | 2 ++
5 files changed, 83 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index c69a4d958f24..1617405faed4 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -49,33 +49,17 @@
static int mi0283qt_init(struct mipi_dbi *mipi)
{
- struct tinydrm_device *tdev = &mipi->tinydrm;
- struct device *dev = tdev->drm->dev;
u8 addr_mode;
int ret;
DRM_DEBUG_KMS("\n");
- ret = regulator_enable(mipi->regulator);
- if (ret) {
- DRM_DEV_ERROR(dev, "Failed to enable regulator %d\n", ret);
+ ret = mipi_dbi_poweron_conditional_reset(mipi);
+ if (ret < 0)
return ret;
- }
-
- /* Avoid flicker by skipping setup if the bootloader has done it */
- if (mipi_dbi_display_is_on(mipi))
+ if (ret == 1)
return 0;
- mipi_dbi_hw_reset(mipi);
- ret = mipi_dbi_command(mipi, MIPI_DCS_SOFT_RESET);
- if (ret) {
- DRM_DEV_ERROR(dev, "Error sending command %d\n", ret);
- regulator_disable(mipi->regulator);
- return ret;
- }
-
- msleep(20);
-
mipi_dbi_command(mipi, MIPI_DCS_SET_DISPLAY_OFF);
mipi_dbi_command(mipi, ILI9341_PWCTRLB, 0x00, 0x83, 0x30);
diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c
b/drivers/gpu/drm/tinydrm/mipi-dbi.c
index 1c8ef0c4d6d4..3e879d605ed3 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -463,6 +463,7 @@ bool mipi_dbi_display_is_on(struct mipi_dbi *mipi)
val &= ~DCS_POWER_MODE_RESERVED_MASK;
+ /* The poweron/reset value is 08h DCS_POWER_MODE_DISPLAY_NORMAL_MODE */
if (val != (DCS_POWER_MODE_DISPLAY |
DCS_POWER_MODE_DISPLAY_NORMAL_MODE | DCS_POWER_MODE_SLEEP_MODE))
return false;
@@ -473,6 +474,78 @@ bool mipi_dbi_display_is_on(struct mipi_dbi *mipi)
}
EXPORT_SYMBOL(mipi_dbi_display_is_on);
+static int mipi_dbi_poweron_reset_conditional(struct mipi_dbi *mipi, bool cond)
+{
+ struct device *dev = mipi->tinydrm.drm->dev;
+ int ret;
+
+ if (mipi->regulator) {
+ ret = regulator_enable(mipi->regulator);
+ if (ret) {
+ DRM_DEV_ERROR(dev, "Failed to enable regulator (%d)\n",
ret);
+ return ret;
+ }
+ }
+
+ if (cond && mipi_dbi_display_is_on(mipi))
+ return 1;
+
+ mipi_dbi_hw_reset(mipi);
+ ret = mipi_dbi_command(mipi, MIPI_DCS_SOFT_RESET);
+ if (ret) {
+ DRM_DEV_ERROR(dev, "Failed to send reset command (%d)\n", ret);
+ if (mipi->regulator)
+ regulator_disable(mipi->regulator);
+ return ret;
+ }
+
+ /*
+* If we did a hw reset, we know the controller is in Sleep mode and
+* per MIPI DSC spec should wait 5ms after soft reset. If we didn't,
+* we assume worst case and wait 120ms.
+*/
+ if (mipi->reset)
+ usleep_range(5000, 2);
+ else
+ msleep(120);
+
+ return 0;
+}
+
+/**
+ * mipi_dbi_poweron_reset - MIPI DBI poweron and reset
+ * @mipi: MIPI DBI structure
+ *
+ * This function enables the regulator if used and does a hardware and software
+ * reset.
+ *
+ * Returns:
+ * Zero on success, or a negative error code.
+ */
+int mipi_dbi_poweron_reset(struct mipi_dbi *mipi)
+{
+ return mipi_dbi_poweron_reset_conditional(mipi, false);
+}
+EXPORT_SYMBOL(mipi_dbi_poweron_reset);
+
+/**
+ * mipi_dbi_poweron_conditional_reset - MIPI DBI poweron and conditional reset
+ * @mipi: MIPI DBI structure
+ *
+ * This function enables the regulator if used and if the display is off, it
+ * does a hardware and software reset. If mipi_dbi_display_is_on() determines
+ * that the display is on, no reset is performed.
+ *
+ * Returns:
+ * Zero if the controller was reset, 1 if the display was already on, or a
+ * negative error code.
+ */
+int mipi_dbi_poweron_conditional_reset(struct mipi_dbi *mipi)
+{
+ return mipi_dbi_poweron_reset_conditional(mipi, true);
+}
+EXPORT_SYMBOL(mipi_dbi_poweron_conditional_reset);
+
#if IS_ENABLED(CONFIG_SPI)
/**
diff --git a/drivers/gpu/drm/tinydrm/st7586.c b/drivers/gpu/drm/tinydrm/st7586.c
index 9fd4423c8e70..a6396ef9cc4a 100644
--- a/drivers/gpu/drm/tinydrm/st7586.c
+++ b/drivers/gpu/drm/tinydrm/st7586.c
@@ -179,19 +179,16 @@ static void st7586_pipe_enable(struct
drm_simple_display_pipe *pipe,
{
struct tinydrm_device *tdev
[PATCH v3 2/7] drm/tinydrm/mi0283qt: Remove ili9341.h
No need for a public header file for the command macros.
Just include the necessary ones in the driver.
Also use the MIPI_DCS_PIXEL_FMT_16BIT macro.
Signed-off-by: Noralf Trønnes
Reviewed-by: David Lechner
---
drivers/gpu/drm/tinydrm/mi0283qt.c | 28 ++--
include/drm/tinydrm/ili9341.h | 54 --
2 files changed, 26 insertions(+), 56 deletions(-)
delete mode 100644 include/drm/tinydrm/ili9341.h
diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index 45f02b6052b1..c69a4d958f24 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -18,11 +18,35 @@
#include
#include
-#include
#include
#include
#include
+#define ILI9341_FRMCTR10xb1
+#define ILI9341_DISCTRL0xb6
+#define ILI9341_ETMOD 0xb7
+
+#define ILI9341_PWCTRL10xc0
+#define ILI9341_PWCTRL20xc1
+#define ILI9341_VMCTRL10xc5
+#define ILI9341_VMCTRL20xc7
+#define ILI9341_PWCTRLA0xcb
+#define ILI9341_PWCTRLB0xcf
+
+#define ILI9341_PGAMCTRL 0xe0
+#define ILI9341_NGAMCTRL 0xe1
+#define ILI9341_DTCTRLA0xe8
+#define ILI9341_DTCTRLB0xea
+#define ILI9341_PWRSEQ 0xed
+
+#define ILI9341_EN3GAM 0xf2
+#define ILI9341_PUMPCTRL 0xf7
+
+#define ILI9341_MADCTL_BGR BIT(3)
+#define ILI9341_MADCTL_MV BIT(5)
+#define ILI9341_MADCTL_MX BIT(6)
+#define ILI9341_MADCTL_MY BIT(7)
+
static int mi0283qt_init(struct mipi_dbi *mipi)
{
struct tinydrm_device *tdev = &mipi->tinydrm;
@@ -69,7 +93,7 @@ static int mi0283qt_init(struct mipi_dbi *mipi)
mipi_dbi_command(mipi, ILI9341_VMCTRL2, 0xbe);
/* Memory Access Control */
- mipi_dbi_command(mipi, MIPI_DCS_SET_PIXEL_FORMAT, 0x55);
+ mipi_dbi_command(mipi, MIPI_DCS_SET_PIXEL_FORMAT,
MIPI_DCS_PIXEL_FMT_16BIT);
switch (mipi->rotation) {
default:
diff --git a/include/drm/tinydrm/ili9341.h b/include/drm/tinydrm/ili9341.h
deleted file mode 100644
index 807a09f43cad..
--- a/include/drm/tinydrm/ili9341.h
+++ /dev/null
@@ -1,54 +0,0 @@
-/*
- * ILI9341 LCD controller
- *
- * Copyright 2016 Noralf Trønnes
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- */
-
-#ifndef __LINUX_ILI9341_H
-#define __LINUX_ILI9341_H
-
-#define ILI9341_FRMCTR10xb1
-#define ILI9341_FRMCTR20xb2
-#define ILI9341_FRMCTR30xb3
-#define ILI9341_INVTR 0xb4
-#define ILI9341_PRCTR 0xb5
-#define ILI9341_DISCTRL0xb6
-#define ILI9341_ETMOD 0xb7
-
-#define ILI9341_PWCTRL10xc0
-#define ILI9341_PWCTRL20xc1
-#define ILI9341_VMCTRL10xc5
-#define ILI9341_VMCTRL20xc7
-#define ILI9341_PWCTRLA0xcb
-#define ILI9341_PWCTRLB0xcf
-
-#define ILI9341_RDID1 0xda
-#define ILI9341_RDID2 0xdb
-#define ILI9341_RDID3 0xdc
-#define ILI9341_RDID4 0xd3
-
-#define ILI9341_PGAMCTRL 0xe0
-#define ILI9341_NGAMCTRL 0xe1
-#define ILI9341_DGAMCTRL1 0xe2
-#define ILI9341_DGAMCTRL2 0xe3
-#define ILI9341_DTCTRLA0xe8
-#define ILI9341_DTCTRLB0xea
-#define ILI9341_PWRSEQ 0xed
-
-#define ILI9341_EN3GAM 0xf2
-#define ILI9341_IFCTRL 0xf6
-#define ILI9341_PUMPCTRL 0xf7
-
-#define ILI9341_MADCTL_MH BIT(2)
-#define ILI9341_MADCTL_BGR BIT(3)
-#define ILI9341_MADCTL_ML BIT(4)
-#define ILI9341_MADCTL_MV BIT(5)
-#define ILI9341_MADCTL_MX BIT(6)
-#define ILI9341_MADCTL_MY BIT(7)
-
-#endif /* __LINUX_ILI9341_H */
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdkfd: Fix potential NULL pointer dereferences
Hi Gustavo,
Thanks for catching that. When returning a fault, I think you also need
to srcu_read_unlock(&kfd_processes_srcu, idx).
However, instead of returning an error, I think I'd prefer to skip PDDs
that can't be found with continue statements. That way others would
still suspend and resume successfully. Maybe just print a WARN_ON for
PDDs that aren't found, because that's an unexpected situation,
currently. Maybe in the future it could be normal thing if we ever
support GPU hotplug.
Regards,
Felix
On 2018-01-10 11:50 AM, Gustavo A. R. Silva wrote:
> In case kfd_get_process_device_data returns null, there are some
> null pointer dereferences in functions kfd_bind_processes_to_device
> and kfd_unbind_processes_from_device.
>
> Fix this by null checking pdd before dereferencing it.
>
> Addresses-Coverity-ID: 1463794 ("Dereference null return value")
> Addresses-Coverity-ID: 1463772 ("Dereference null return value")
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_process.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> index a22fb071..29d51d5 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> @@ -461,6 +461,13 @@ int kfd_bind_processes_to_device(struct kfd_dev *dev)
> hash_for_each_rcu(kfd_processes_table, temp, p, kfd_processes) {
> mutex_lock(&p->mutex);
> pdd = kfd_get_process_device_data(dev, p);
> +
> + if (!pdd) {
> + pr_err("Process device data doesn't exist\n");
> + mutex_unlock(&p->mutex);
> + return -EFAULT;
> + }
> +
> if (pdd->bound != PDD_BOUND_SUSPENDED) {
> mutex_unlock(&p->mutex);
> continue;
> @@ -501,6 +508,11 @@ void kfd_unbind_processes_from_device(struct kfd_dev
> *dev)
> mutex_lock(&p->mutex);
> pdd = kfd_get_process_device_data(dev, p);
>
> + if (!pdd) {
> + mutex_unlock(&p->mutex);
> + return;
> + }
> +
> if (pdd->bound == PDD_BOUND)
> pdd->bound = PDD_BOUND_SUSPENDED;
> mutex_unlock(&p->mutex);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 6/8] drm/bridge/synopsys: dw-hdmi: Add missing bridge detach
From: Jeffy Chen
We inited connector in attach(), so need a detach() to cleanup.
Also fix wrong use of dw_hdmi_remove() in bind().
Signed-off-by: Jeffy Chen
Signed-off-by: Thierry Escande
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index a38db40ce990..1cc63a18b7d5 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1967,6 +1967,13 @@ static int dw_hdmi_bridge_attach(struct drm_bridge
*bridge)
return 0;
}
+static void dw_hdmi_bridge_detach(struct drm_bridge *bridge)
+{
+ struct dw_hdmi *hdmi = bridge->driver_private;
+
+ drm_connector_cleanup(&hdmi->connector);
+}
+
static enum drm_mode_status
dw_hdmi_bridge_mode_valid(struct drm_bridge *bridge,
const struct drm_display_mode *mode)
@@ -2023,6 +2030,7 @@ static void dw_hdmi_bridge_enable(struct drm_bridge
*bridge)
static const struct drm_bridge_funcs dw_hdmi_bridge_funcs = {
.attach = dw_hdmi_bridge_attach,
+ .detach = dw_hdmi_bridge_detach,
.enable = dw_hdmi_bridge_enable,
.disable = dw_hdmi_bridge_disable,
.mode_set = dw_hdmi_bridge_mode_set,
@@ -2616,7 +2624,7 @@ int dw_hdmi_bind(struct platform_device *pdev, struct
drm_encoder *encoder,
ret = drm_bridge_attach(encoder, &hdmi->bridge, NULL);
if (ret) {
- dw_hdmi_remove(pdev);
+ __dw_hdmi_remove(hdmi);
DRM_ERROR("Failed to initialize bridge with drm\n");
return ret;
}
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 1/8] drm/bridge: analogix: Do not use device's drvdata
From: Jeffy Chen
The driver that instantiates the bridge should own the drvdata, as all
driver model callbacks (probe, remove, shutdown, PM ops, etc.) are also
owned by its driver struct. Moreover, storing two different pointer
types in driver data depending on driver initialization status is barely
a good practice and in fact has led to many bugs in this driver.
Let's clean up this mess and change Analogix entry points to simply
accept some opaque struct pointer, adjusting their users at the same
time to avoid breaking the compilation.
Signed-off-by: Tomasz Figa
Signed-off-by: Jeffy Chen
Signed-off-by: Thierry Escande
Reviewed-by: Andrzej Hajda
Reviewed-by: Sean Paul
Acked-by: Jingoo Han
Acked-by: Archit Taneja
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 50 +-
drivers/gpu/drm/exynos/exynos_dp.c | 26 ++-
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 48 -
include/drm/bridge/analogix_dp.h | 19
4 files changed, 74 insertions(+), 69 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index a8905049b9da..878f61b65cb2 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -98,17 +98,15 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device
*dp)
return 0;
}
-int analogix_dp_psr_supported(struct device *dev)
+int analogix_dp_psr_supported(struct analogix_dp_device *dp)
{
- struct analogix_dp_device *dp = dev_get_drvdata(dev);
return dp->psr_support;
}
EXPORT_SYMBOL_GPL(analogix_dp_psr_supported);
-int analogix_dp_enable_psr(struct device *dev)
+int analogix_dp_enable_psr(struct analogix_dp_device *dp)
{
- struct analogix_dp_device *dp = dev_get_drvdata(dev);
struct edp_vsc_psr psr_vsc;
if (!dp->psr_support)
@@ -129,9 +127,8 @@ int analogix_dp_enable_psr(struct device *dev)
}
EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
-int analogix_dp_disable_psr(struct device *dev)
+int analogix_dp_disable_psr(struct analogix_dp_device *dp)
{
- struct analogix_dp_device *dp = dev_get_drvdata(dev);
struct edp_vsc_psr psr_vsc;
int ret;
@@ -1283,8 +1280,9 @@ static ssize_t analogix_dpaux_transfer(struct drm_dp_aux
*aux,
return analogix_dp_transfer(dp, msg);
}
-int analogix_dp_bind(struct device *dev, struct drm_device *drm_dev,
-struct analogix_dp_plat_data *plat_data)
+struct analogix_dp_device *
+analogix_dp_bind(struct device *dev, struct drm_device *drm_dev,
+struct analogix_dp_plat_data *plat_data)
{
struct platform_device *pdev = to_platform_device(dev);
struct analogix_dp_device *dp;
@@ -1294,14 +1292,12 @@ int analogix_dp_bind(struct device *dev, struct
drm_device *drm_dev,
if (!plat_data) {
dev_err(dev, "Invalided input plat_data\n");
- return -EINVAL;
+ return ERR_PTR(-EINVAL);
}
dp = devm_kzalloc(dev, sizeof(struct analogix_dp_device), GFP_KERNEL);
if (!dp)
- return -ENOMEM;
-
- dev_set_drvdata(dev, dp);
+ return ERR_PTR(-ENOMEM);
dp->dev = &pdev->dev;
dp->dpms_mode = DRM_MODE_DPMS_OFF;
@@ -1318,7 +1314,7 @@ int analogix_dp_bind(struct device *dev, struct
drm_device *drm_dev,
ret = analogix_dp_dt_parse_pdata(dp);
if (ret)
- return ret;
+ return ERR_PTR(ret);
dp->phy = devm_phy_get(dp->dev, "dp");
if (IS_ERR(dp->phy)) {
@@ -1332,14 +1328,14 @@ int analogix_dp_bind(struct device *dev, struct
drm_device *drm_dev,
if (ret == -ENOSYS || ret == -ENODEV)
dp->phy = NULL;
else
- return ret;
+ return ERR_PTR(ret);
}
}
dp->clock = devm_clk_get(&pdev->dev, "dp");
if (IS_ERR(dp->clock)) {
dev_err(&pdev->dev, "failed to get clock\n");
- return PTR_ERR(dp->clock);
+ return ERR_CAST(dp->clock);
}
clk_prepare_enable(dp->clock);
@@ -1348,7 +1344,7 @@ int analogix_dp_bind(struct device *dev, struct
drm_device *drm_dev,
dp->reg_base = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(dp->reg_base))
- return PTR_ERR(dp->reg_base);
+ return ERR_CAST(dp->reg_base);
dp->force_hpd = of_property_read_bool(dev->of_node, "force-hpd");
@@ -1369,7 +1365,7 @@ int analogix_dp_bind(struct device *dev, struct
drm_device *drm_dev,
"hpd_gpio");
if (ret) {
dev_err(&pdev->dev, "failed to get hpd gpio\n");
- return ret;
+
[PATCH v8 5/8] drm/rockchip: inno_hdmi: Fix error handling path
From: Jeffy Chen
Add missing error handling in bind().
Fixes: 412d4ae6b7a5 ("drm/rockchip: hdmi: add Innosilicon HDMI support")
Signed-off-by: Jeffy Chen
Signed-off-by: Thierry Escande
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index fab30927a889..b775283d7363 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -852,8 +852,10 @@ static int inno_hdmi_bind(struct device *dev, struct
device *master,
}
irq = platform_get_irq(pdev, 0);
- if (irq < 0)
- return irq;
+ if (irq < 0) {
+ ret = irq;
+ goto err_disable_clk;
+ }
inno_hdmi_reset(hdmi);
@@ -861,7 +863,7 @@ static int inno_hdmi_bind(struct device *dev, struct device
*master,
if (IS_ERR(hdmi->ddc)) {
ret = PTR_ERR(hdmi->ddc);
hdmi->ddc = NULL;
- return ret;
+ goto err_disable_clk;
}
/*
@@ -875,7 +877,7 @@ static int inno_hdmi_bind(struct device *dev, struct device
*master,
ret = inno_hdmi_register(drm, hdmi);
if (ret)
- return ret;
+ goto err_put_adapter;
dev_set_drvdata(dev, hdmi);
@@ -885,7 +887,17 @@ static int inno_hdmi_bind(struct device *dev, struct
device *master,
ret = devm_request_threaded_irq(dev, irq, inno_hdmi_hardirq,
inno_hdmi_irq, IRQF_SHARED,
dev_name(dev), hdmi);
+ if (ret < 0)
+ goto err_cleanup_hdmi;
+ return 0;
+err_cleanup_hdmi:
+ hdmi->connector.funcs->destroy(&hdmi->connector);
+ hdmi->encoder.funcs->destroy(&hdmi->encoder);
+err_put_adapter:
+ i2c_put_adapter(hdmi->ddc);
+err_disable_clk:
+ clk_disable_unprepare(hdmi->pclk);
return ret;
}
@@ -897,8 +909,8 @@ static void inno_hdmi_unbind(struct device *dev, struct
device *master,
hdmi->connector.funcs->destroy(&hdmi->connector);
hdmi->encoder.funcs->destroy(&hdmi->encoder);
- clk_disable_unprepare(hdmi->pclk);
i2c_put_adapter(hdmi->ddc);
+ clk_disable_unprepare(hdmi->pclk);
}
static const struct component_ops inno_hdmi_ops = {
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/stm: ltdc: add clut mode support
On 2018-01-09 12:28, Philippe CORNU wrote: > Hi all, > > Do you think the patch is "acceptable" or should I change it somehow? > Any opinion is welcomed : ) Maybe you should try Daniel Vetter? He was very helpful (thanks) when I worked on the clut changes... Cheers, Peter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 8/8] drm/rockchip: dw_hdmi: Fix error handling path
From: Jeffy Chen
Add missing clk_disable_unprepare() in bind()'s error handling path and
unbind().
Also inline clk_prepare_enable() with bind().
Fixes: 12b9f204e804 ("drm: bridge/dw_hdmi: add rockchip rk3288 support")
Signed-off-by: Jeffy Chen
Signed-off-by: Thierry Escande
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index d406d7779ed9..0b2c1a5dd1e6 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -166,7 +166,6 @@ static const struct dw_hdmi_phy_config
rockchip_phy_config[] = {
static int rockchip_hdmi_parse_dt(struct rockchip_hdmi *hdmi)
{
struct device_node *np = hdmi->dev->of_node;
- int ret;
hdmi->regmap = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
if (IS_ERR(hdmi->regmap)) {
@@ -194,13 +193,6 @@ static int rockchip_hdmi_parse_dt(struct rockchip_hdmi
*hdmi)
return PTR_ERR(hdmi->grf_clk);
}
- ret = clk_prepare_enable(hdmi->vpll_clk);
- if (ret) {
- DRM_DEV_ERROR(hdmi->dev,
- "Failed to enable HDMI vpll: %d\n", ret);
- return ret;
- }
-
return 0;
}
@@ -375,6 +367,13 @@ static int dw_hdmi_rockchip_bind(struct device *dev,
struct device *master,
return ret;
}
+ ret = clk_prepare_enable(hdmi->vpll_clk);
+ if (ret) {
+ DRM_DEV_ERROR(hdmi->dev, "Failed to enable HDMI vpll: %d\n",
+ ret);
+ return ret;
+ }
+
drm_encoder_helper_add(encoder, &dw_hdmi_rockchip_encoder_helper_funcs);
drm_encoder_init(drm, encoder, &dw_hdmi_rockchip_encoder_funcs,
DRM_MODE_ENCODER_TMDS, NULL);
@@ -382,6 +381,7 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct
device *master,
hdmi->hdmi = dw_hdmi_bind(pdev, encoder, plat_data);
if (IS_ERR(hdmi->hdmi)) {
encoder->funcs->destroy(encoder);
+ clk_disable_unprepare(hdmi->vpll_clk);
return PTR_ERR(hdmi->hdmi);
}
@@ -397,6 +397,7 @@ static void dw_hdmi_rockchip_unbind(struct device *dev,
struct device *master,
dw_hdmi_unbind(hdmi->hdmi);
hdmi->encoder.funcs->destroy(&hdmi->encoder);
+ clk_disable_unprepare(hdmi->vpll_clk);
}
static const struct component_ops dw_hdmi_rockchip_ops = {
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 4/8] drm/rockchip: dw-mipi-dsi: Fix error handling path
From: Jeffy Chen
Add missing pm_runtime_disable() in bind()'s error handling path.
Also cleanup encoder & connector in unbind().
Fixes: 80a9a059d4e4 ("drm/rockchip/dsi: add dw-mipi power domain support")
Signed-off-by: Jeffy Chen
Signed-off-by: Thierry Escande
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index b1fe0639227e..78e6b7919bf7 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -1282,7 +1282,7 @@ static int dw_mipi_dsi_bind(struct device *dev, struct
device *master,
ret = dw_mipi_dsi_register(drm, dsi);
if (ret) {
DRM_DEV_ERROR(dev, "Failed to register mipi_dsi: %d\n", ret);
- goto err_pllref;
+ goto err_disable_pllref;
}
dsi->dsi_host.ops = &dw_mipi_dsi_host_ops;
@@ -1290,24 +1290,25 @@ static int dw_mipi_dsi_bind(struct device *dev, struct
device *master,
ret = mipi_dsi_host_register(&dsi->dsi_host);
if (ret) {
DRM_DEV_ERROR(dev, "Failed to register MIPI host: %d\n", ret);
- goto err_cleanup;
+ goto err_disable_pm_runtime;
}
if (!dsi->panel) {
ret = -EPROBE_DEFER;
- goto err_mipi_dsi_host;
+ goto err_unreg_mipi_dsi_host;
}
dev_set_drvdata(dev, dsi);
pm_runtime_enable(dev);
return 0;
-err_mipi_dsi_host:
+err_unreg_mipi_dsi_host:
mipi_dsi_host_unregister(&dsi->dsi_host);
-err_cleanup:
- drm_encoder_cleanup(&dsi->encoder);
- drm_connector_cleanup(&dsi->connector);
-err_pllref:
+err_disable_pm_runtime:
+ pm_runtime_disable(dev);
+ dsi->connector.funcs->destroy(&dsi->connector);
+ dsi->encoder.funcs->destroy(&dsi->encoder);
+err_disable_pllref:
clk_disable_unprepare(dsi->pllref_clk);
return ret;
}
@@ -1319,6 +1320,10 @@ static void dw_mipi_dsi_unbind(struct device *dev,
struct device *master,
mipi_dsi_host_unregister(&dsi->dsi_host);
pm_runtime_disable(dev);
+
+ dsi->connector.funcs->destroy(&dsi->connector);
+ dsi->encoder.funcs->destroy(&dsi->encoder);
+
clk_disable_unprepare(dsi->pllref_clk);
}
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdkfd: Fix potential NULL pointer dereferences
In case kfd_get_process_device_data returns null, there are some
null pointer dereferences in functions kfd_bind_processes_to_device
and kfd_unbind_processes_from_device.
Fix this by null checking pdd before dereferencing it.
Addresses-Coverity-ID: 1463794 ("Dereference null return value")
Addresses-Coverity-ID: 1463772 ("Dereference null return value")
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index a22fb071..29d51d5 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -461,6 +461,13 @@ int kfd_bind_processes_to_device(struct kfd_dev *dev)
hash_for_each_rcu(kfd_processes_table, temp, p, kfd_processes) {
mutex_lock(&p->mutex);
pdd = kfd_get_process_device_data(dev, p);
+
+ if (!pdd) {
+ pr_err("Process device data doesn't exist\n");
+ mutex_unlock(&p->mutex);
+ return -EFAULT;
+ }
+
if (pdd->bound != PDD_BOUND_SUSPENDED) {
mutex_unlock(&p->mutex);
continue;
@@ -501,6 +508,11 @@ void kfd_unbind_processes_from_device(struct kfd_dev *dev)
mutex_lock(&p->mutex);
pdd = kfd_get_process_device_data(dev, p);
+ if (!pdd) {
+ mutex_unlock(&p->mutex);
+ return;
+ }
+
if (pdd->bound == PDD_BOUND)
pdd->bound = PDD_BOUND_SUSPENDED;
mutex_unlock(&p->mutex);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 0/8] rockchip: kevin: Enable edp display
Hi, This patchset makes edp display work on Chromebook kevin. This patchset has been originally posted by Jeffy Chen and the 2 first commits from a previous version (v6) are already merged in mainline. v8: Fixed compilation issue between patches #7 and #8 reported by Archit. v7: Rebased on top of next-20180108 and fixed conflicts Fixed a few warnings reported by checkpatch Jeffy Chen (8): drm/bridge: analogix: Do not use device's drvdata drm/bridge: analogix_dp: Fix connector and encoder cleanup drm/rockchip: analogix_dp: Add a sanity check for rockchip_drm_psr_register() drm/rockchip: dw-mipi-dsi: Fix error handling path drm/rockchip: inno_hdmi: Fix error handling path drm/bridge/synopsys: dw-hdmi: Add missing bridge detach drm/bridge/synopsys: dw-hdmi: Do not use device's drvdata drm/rockchip: dw_hdmi: Fix error handling path drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 52 +++-- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 53 - drivers/gpu/drm/exynos/exynos_dp.c | 29 ++ drivers/gpu/drm/imx/dw_hdmi-imx.c | 22 --- drivers/gpu/drm/meson/meson_dw_hdmi.c | 20 +-- drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 14 - drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 67 +- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 21 --- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c| 39 +++-- drivers/gpu/drm/rockchip/inno_hdmi.c | 22 +-- include/drm/bridge/analogix_dp.h | 19 +++--- include/drm/bridge/dw_hdmi.h | 17 +++--- 12 files changed, 214 insertions(+), 161 deletions(-) -- 2.14.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 7/8] drm/bridge/synopsys: dw-hdmi: Do not use device's drvdata
From: Jeffy Chen
Let plat drivers own the drvdata, so that they could cleanup resources
in their unbind().
Signed-off-by: Jeffy Chen
Signed-off-by: Thierry Escande
Reviewed-by: Neil Armstrong
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 43 ++---
drivers/gpu/drm/imx/dw_hdmi-imx.c | 22 +--
drivers/gpu/drm/meson/meson_dw_hdmi.c | 20 ++
drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 14 --
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 22 +--
include/drm/bridge/dw_hdmi.h| 17 ++--
6 files changed, 77 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 1cc63a18b7d5..f0380bcae513 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2073,7 +2073,7 @@ static irqreturn_t dw_hdmi_hardirq(int irq, void *dev_id)
return ret;
}
-void __dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense)
+void dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense)
{
mutex_lock(&hdmi->mutex);
@@ -2099,13 +2099,6 @@ void __dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool
hpd, bool rx_sense)
}
mutex_unlock(&hdmi->mutex);
}
-
-void dw_hdmi_setup_rx_sense(struct device *dev, bool hpd, bool rx_sense)
-{
- struct dw_hdmi *hdmi = dev_get_drvdata(dev);
-
- __dw_hdmi_setup_rx_sense(hdmi, hpd, rx_sense);
-}
EXPORT_SYMBOL_GPL(dw_hdmi_setup_rx_sense);
static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
@@ -2141,9 +2134,8 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
*/
if (intr_stat &
(HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD)) {
- __dw_hdmi_setup_rx_sense(hdmi,
-phy_stat & HDMI_PHY_HPD,
-phy_stat & HDMI_PHY_RX_SENSE);
+ dw_hdmi_setup_rx_sense(hdmi, phy_stat & HDMI_PHY_HPD,
+ phy_stat & HDMI_PHY_RX_SENSE);
if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0)
cec_notifier_set_phys_addr(hdmi->cec_notifier,
@@ -2533,8 +2525,6 @@ __dw_hdmi_probe(struct platform_device *pdev,
if (hdmi->i2c)
dw_hdmi_i2c_init(hdmi);
- platform_set_drvdata(pdev, hdmi);
-
return hdmi;
err_iahb:
@@ -2584,25 +2574,23 @@ static void __dw_hdmi_remove(struct dw_hdmi *hdmi)
/*
-
* Probe/remove API, used from platforms based on the DRM bridge API.
*/
-int dw_hdmi_probe(struct platform_device *pdev,
- const struct dw_hdmi_plat_data *plat_data)
+struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
+ const struct dw_hdmi_plat_data *plat_data)
{
struct dw_hdmi *hdmi;
hdmi = __dw_hdmi_probe(pdev, plat_data);
if (IS_ERR(hdmi))
- return PTR_ERR(hdmi);
+ return hdmi;
drm_bridge_add(&hdmi->bridge);
- return 0;
+ return hdmi;
}
EXPORT_SYMBOL_GPL(dw_hdmi_probe);
-void dw_hdmi_remove(struct platform_device *pdev)
+void dw_hdmi_remove(struct dw_hdmi *hdmi)
{
- struct dw_hdmi *hdmi = platform_get_drvdata(pdev);
-
drm_bridge_remove(&hdmi->bridge);
__dw_hdmi_remove(hdmi);
@@ -2612,31 +2600,30 @@ EXPORT_SYMBOL_GPL(dw_hdmi_remove);
/*
-
* Bind/unbind API, used from platforms based on the component framework.
*/
-int dw_hdmi_bind(struct platform_device *pdev, struct drm_encoder *encoder,
-const struct dw_hdmi_plat_data *plat_data)
+struct dw_hdmi *dw_hdmi_bind(struct platform_device *pdev,
+struct drm_encoder *encoder,
+const struct dw_hdmi_plat_data *plat_data)
{
struct dw_hdmi *hdmi;
int ret;
hdmi = __dw_hdmi_probe(pdev, plat_data);
if (IS_ERR(hdmi))
- return PTR_ERR(hdmi);
+ return hdmi;
ret = drm_bridge_attach(encoder, &hdmi->bridge, NULL);
if (ret) {
__dw_hdmi_remove(hdmi);
DRM_ERROR("Failed to initialize bridge with drm\n");
- return ret;
+ return ERR_PTR(ret);
}
- return 0;
+ return hdmi;
}
EXPORT_SYMBOL_GPL(dw_hdmi_bind);
-void dw_hdmi_unbind(struct device *dev)
+void dw_hdmi_unbind(struct dw_hdmi *hdmi)
{
- struct dw_hdmi *hdmi = dev_get_drvdata(dev);
-
__dw_hdmi_remove(hdmi);
}
EXPORT_SYMBOL_GPL(dw_hdmi_unbind);
diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index b62763aa8706..b01d03e02ce0 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/im
[PATCH v8 3/8] drm/rockchip: analogix_dp: Add a sanity check for rockchip_drm_psr_register()
From: Jeffy Chen
The rockchip_drm_psr_register() can fail, so add a sanity check for that.
Also reorder the calls in unbind() to match bind().
Signed-off-by: Jeffy Chen
Signed-off-by: Thierry Escande
---
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 37250ab63bd7..eb88c52336a7 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -354,15 +354,22 @@ static int rockchip_dp_bind(struct device *dev, struct
device *master,
dp->psr_state = ~EDP_VSC_PSR_STATE_ACTIVE;
INIT_WORK(&dp->psr_work, analogix_dp_psr_work);
- rockchip_drm_psr_register(&dp->encoder, analogix_dp_psr_set);
+ ret = rockchip_drm_psr_register(&dp->encoder, analogix_dp_psr_set);
+ if (ret < 0)
+ goto err_cleanup_encoder;
dp->adp = analogix_dp_bind(dev, dp->drm_dev, &dp->plat_data);
if (IS_ERR(dp->adp)) {
- dp->encoder.funcs->destroy(&dp->encoder);
- return PTR_ERR(dp->adp);
+ ret = PTR_ERR(dp->adp);
+ goto err_unreg_psr;
}
return 0;
+err_unreg_psr:
+ rockchip_drm_psr_unregister(&dp->encoder);
+err_cleanup_encoder:
+ dp->encoder.funcs->destroy(&dp->encoder);
+ return ret;
}
static void rockchip_dp_unbind(struct device *dev, struct device *master,
@@ -370,8 +377,8 @@ static void rockchip_dp_unbind(struct device *dev, struct
device *master,
{
struct rockchip_dp_device *dp = dev_get_drvdata(dev);
- rockchip_drm_psr_unregister(&dp->encoder);
analogix_dp_unbind(dp->adp);
+ rockchip_drm_psr_unregister(&dp->encoder);
dp->encoder.funcs->destroy(&dp->encoder);
}
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 2/8] drm/bridge: analogix_dp: Fix connector and encoder cleanup
From: Jeffy Chen
Since we are initing connector in the core driver and encoder in the
plat driver, let's clean them up in the right places.
Signed-off-by: Jeffy Chen
Signed-off-by: Thierry Escande
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 --
drivers/gpu/drm/exynos/exynos_dp.c | 7 +--
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 12 +---
3 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 878f61b65cb2..cb5e18d6ba04 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1411,7 +1411,6 @@ analogix_dp_bind(struct device *dev, struct drm_device
*drm_dev,
ret = analogix_dp_create_bridge(drm_dev, dp);
if (ret) {
DRM_ERROR("failed to create bridge (%d)\n", ret);
- drm_encoder_cleanup(dp->encoder);
goto err_disable_pm_runtime;
}
@@ -1434,7 +1433,6 @@ void analogix_dp_unbind(struct analogix_dp_device *dp)
{
analogix_dp_bridge_disable(dp->bridge);
dp->connector.funcs->destroy(&dp->connector);
- dp->encoder->funcs->destroy(dp->encoder);
if (dp->plat_data->panel) {
if (drm_panel_unprepare(dp->plat_data->panel))
diff --git a/drivers/gpu/drm/exynos/exynos_dp.c
b/drivers/gpu/drm/exynos/exynos_dp.c
index f7e5b2c405ed..33319a858f3a 100644
--- a/drivers/gpu/drm/exynos/exynos_dp.c
+++ b/drivers/gpu/drm/exynos/exynos_dp.c
@@ -185,8 +185,10 @@ static int exynos_dp_bind(struct device *dev, struct
device *master, void *data)
dp->plat_data.encoder = encoder;
dp->adp = analogix_dp_bind(dev, dp->drm_dev, &dp->plat_data);
- if (IS_ERR(dp->adp))
+ if (IS_ERR(dp->adp)) {
+ dp->encoder.funcs->destroy(&dp->encoder);
return PTR_ERR(dp->adp);
+ }
return 0;
}
@@ -196,7 +198,8 @@ static void exynos_dp_unbind(struct device *dev, struct
device *master,
{
struct exynos_dp_device *dp = dev_get_drvdata(dev);
- return analogix_dp_unbind(dp->adp);
+ analogix_dp_unbind(dp->adp);
+ dp->encoder.funcs->destroy(&dp->encoder);
}
static const struct component_ops exynos_dp_ops = {
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 8a58ad80f509..37250ab63bd7 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -259,13 +259,8 @@ static struct drm_encoder_helper_funcs
rockchip_dp_encoder_helper_funcs = {
.atomic_check = rockchip_dp_drm_encoder_atomic_check,
};
-static void rockchip_dp_drm_encoder_destroy(struct drm_encoder *encoder)
-{
- drm_encoder_cleanup(encoder);
-}
-
static struct drm_encoder_funcs rockchip_dp_encoder_funcs = {
- .destroy = rockchip_dp_drm_encoder_destroy,
+ .destroy = drm_encoder_cleanup,
};
static int rockchip_dp_of_probe(struct rockchip_dp_device *dp)
@@ -362,8 +357,10 @@ static int rockchip_dp_bind(struct device *dev, struct
device *master,
rockchip_drm_psr_register(&dp->encoder, analogix_dp_psr_set);
dp->adp = analogix_dp_bind(dev, dp->drm_dev, &dp->plat_data);
- if (IS_ERR(dp->adp))
+ if (IS_ERR(dp->adp)) {
+ dp->encoder.funcs->destroy(&dp->encoder);
return PTR_ERR(dp->adp);
+ }
return 0;
}
@@ -375,6 +372,7 @@ static void rockchip_dp_unbind(struct device *dev, struct
device *master,
rockchip_drm_psr_unregister(&dp->encoder);
analogix_dp_unbind(dp->adp);
+ dp->encoder.funcs->destroy(&dp->encoder);
}
static const struct component_ops rockchip_dp_component_ops = {
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-17.50 2016/2100] drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smc.c:579:62: warning: 'tmp' may be used uninitialized in this function
Hi Rex,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-17.50
head: 4b295aab3256d700354748dcd64017d76065d684
commit: 9c2014d08693830897cad6bbd359d905825d8a18 [2016/2100] drm/amd/powerplay:
add CI asics support to smumgr
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
git checkout 9c2014d08693830897cad6bbd359d905825d8a18
# save the attached .config to linux build tree
make ARCH=i386
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smc.c: In function
'ci_init_smc_table':
>> drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smc.c:579:62: warning:
>> 'tmp' may be used uninitialized in this function [-Wmaybe-uninitialized]
smu_data->power_tune_table.FuzzyFan_PwmSetDelta =
CONVERT_FROM_HOST_TO_SMC_US(tmp);
~^~~
drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smc.c:571:11: note: 'tmp'
was declared here
uint16_t tmp;
^~~
vim +/tmp +579 drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smc.c
568
569 static int ci_populate_fuzzy_fan(struct pp_hwmgr *hwmgr, uint32_t
fuse_table_offset)
570 {
571 uint16_t tmp;
572 struct ci_smumgr *smu_data = (struct ci_smumgr
*)(hwmgr->smumgr->backend);
573
574 if
((hwmgr->thermal_controller.advanceFanControlParameters.usFanOutputSensitivity
& (1 << 15))
575 || 0 ==
hwmgr->thermal_controller.advanceFanControlParameters.usFanOutputSensitivity)
576 tmp =
hwmgr->thermal_controller.advanceFanControlParameters.usFanOutputSensitivity
577 =
hwmgr->thermal_controller.advanceFanControlParameters.usDefaultFanOutputSensitivity;
578
> 579 smu_data->power_tune_table.FuzzyFan_PwmSetDelta =
> CONVERT_FROM_HOST_TO_SMC_US(tmp);
580
581 return 0;
582 }
583
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v2 PATCH] drm/msm: Add devfreq support for the GPU
Add support for devfreq to dynamically control the GPU frequency.
By default try to use the 'simple_ondemand' governor which can
adjust the frequency based on GPU load.
v2: Fix __aeabi_uldivmod issue from the 0 day bot and use
devfreq_recommended_opp() as suggested by Rob.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 12 +
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 1 -
drivers/gpu/drm/msm/msm_gpu.c | 91 +
drivers/gpu/drm/msm/msm_gpu.h | 7 +++
4 files changed, 110 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 56c2c44..7e09d44 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -600,6 +600,9 @@ static int a5xx_hw_init(struct msm_gpu *gpu)
/* Select CP0 to always count cycles */
gpu_write(gpu, REG_A5XX_CP_PERFCTR_CP_SEL_0, PERF_CP_ALWAYS_COUNT);
+ /* Select RBBM0 to countable 6 to get the busy status for devfreq */
+ gpu_write(gpu, REG_A5XX_RBBM_PERFCTR_RBBM_SEL_0, 6);
+
/* Increase VFD cache access so LRZ and other data gets evicted less */
gpu_write(gpu, REG_A5XX_UCHE_CACHE_WAYS, 0x02);
@@ -1170,6 +1173,14 @@ static struct msm_ringbuffer *a5xx_active_ring(struct
msm_gpu *gpu)
return a5xx_gpu->cur_ring;
}
+static int a5xx_gpu_busy(struct msm_gpu *gpu, uint64_t *value)
+{
+ *value = gpu_read64(gpu, REG_A5XX_RBBM_PERFCTR_RBBM_0_LO,
+ REG_A5XX_RBBM_PERFCTR_RBBM_0_HI);
+
+ return 0;
+}
+
static const struct adreno_gpu_funcs funcs = {
.base = {
.get_param = adreno_get_param,
@@ -1185,6 +1196,7 @@ static struct msm_ringbuffer *a5xx_active_ring(struct
msm_gpu *gpu)
#ifdef CONFIG_DEBUG_FS
.show = a5xx_show,
#endif
+ .gpu_busy = a5xx_gpu_busy,
},
.get_timestamp = a5xx_get_timestamp,
};
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index b4bac84..de63ff2 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -22,7 +22,6 @@
#include "msm_gem.h"
#include "msm_mmu.h"
-
int adreno_get_param(struct msm_gpu *gpu, uint32_t param, uint64_t *value)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 5416fe8..bd376f9 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -21,12 +21,91 @@
#include "msm_fence.h"
#include
+#include
+#include
/*
* Power Management:
*/
+static int msm_devfreq_target(struct device *dev, unsigned long *freq,
+ u32 flags)
+{
+ struct msm_gpu *gpu = platform_get_drvdata(to_platform_device(dev));
+ struct dev_pm_opp *opp;
+
+ opp = devfreq_recommended_opp(dev, freq, flags);
+
+ if (IS_ERR(opp))
+ return PTR_ERR(opp);
+
+ clk_set_rate(gpu->core_clk, *freq);
+ dev_pm_opp_put(opp);
+
+ return 0;
+}
+
+static int msm_devfreq_get_dev_status(struct device *dev,
+ struct devfreq_dev_status *status)
+{
+ struct msm_gpu *gpu = platform_get_drvdata(to_platform_device(dev));
+ u64 cycles;
+ u32 freq = ((u32) status->current_frequency) / 100;
+ ktime_t time;
+
+ status->current_frequency = (unsigned long) clk_get_rate(gpu->core_clk);
+ gpu->funcs->gpu_busy(gpu, &cycles);
+
+ status->busy_time = ((u32) (cycles - gpu->devfreq.busy_cycles)) / freq;
+
+ gpu->devfreq.busy_cycles = cycles;
+
+ time = ktime_get();
+ status->total_time = ktime_us_delta(time, gpu->devfreq.time);
+ gpu->devfreq.time = time;
+
+ return 0;
+}
+
+static int msm_devfreq_get_cur_freq(struct device *dev, unsigned long *freq)
+{
+ struct msm_gpu *gpu = platform_get_drvdata(to_platform_device(dev));
+
+ *freq = (unsigned long) clk_get_rate(gpu->core_clk);
+
+ return 0;
+}
+
+static struct devfreq_dev_profile msm_devfreq_profile = {
+ .polling_ms = 10,
+ .target = msm_devfreq_target,
+ .get_dev_status = msm_devfreq_get_dev_status,
+ .get_cur_freq = msm_devfreq_get_cur_freq,
+};
+
+static void msm_devfreq_init(struct msm_gpu *gpu)
+{
+ /* We need target support to do devfreq */
+ if (!gpu->funcs->gpu_busy)
+ return;
+
+ msm_devfreq_profile.initial_freq = gpu->fast_rate;
+
+ /*
+* Don't set the freq_table or max_state and let devfreq build the table
+* from OPP
+*/
+
+ gpu->devfreq.devfreq = devm_devfreq_add_device(&gpu->pdev->dev,
+ &msm_devfreq_profile, "simple_ondemand", NULL);
+
+ if (IS_ERR(gpu->devfreq.devfreq)) {
+ dev_err(&gpu->pdev->dev, "Couldn't initialize GPU devfreq\n");
+ gpu->devfreq.devfreq = NULL;
+ }
Re: [PATCH 0/3] Meson build system
I forgot to CC you on this like you asked, Dylan Quoting Dylan Baker (2018-01-05 12:00:57) > This is a fifth iteration of the meson build system for libdrm. This > version is significantly cleaned up from the last version and uses a > style more like the build system in mesa. > > It builds all of the drivers and tests, and the tests can be run via > `ninja test`. > > It has support for being used as a wrapped dependency with ext_foo > variables (I have a branch of mesa that will build this code as a wrap, > which has also been useful for testing). This means it can be used to > build a mesa that requires a newer libdrm than the system provides > (which can be especially useful if you can't install packages on that > system), or to build libdrm support that your distro doesn't ship (like > arm only drivers on x86), cross compiling, and for testing. > > This has been build tested and mesa has been compiled against it, but > only minimal functional testing has been done, since I only have i965 > machines, and i965 only uses libdrm lightly. > > Some reviewers of the previous versions have done some additional > testing. > > Changes since v3: > - Fix freedreno kgsl check > - Fix kgls -> kgsl typo > - standardize meson options to use only `-` and not `_` > - fix typo radoen -> radeon > - add help messages to options > - fix typo in kms-universal-planes binary > - build and install modetest (this was missed in the first version for > some reason) > - install amdgpu.ids as 644 instead of 444 > > Changes since v4: > - Fix minor nits in options descriptions (Igor) > - Fix editorconfig settings > - Fix amdgpu.ids searh path > - Style nits for Eric E. > - Remove more tabs > - Ensure that 1/0 defines are always defined, instead of only when > their value is 1 > - Don't add header files into file lists. (Meson figures out header > dependencies automatically using graphs that the compiler generates > during compilation) > - Don't assign file lists to variables when possible. In a few cases > files need to be conditionally added, but if we're not in one of > those cases just put the lists directly in the exectuable or library > declaration. > > Dylan Baker (3): > Add meson build system > autotools: Include meson.build files in tarball > README: Add note about meson > > .editorconfig | 4 +- > Makefile.am | 30 ++- > README | 24 +- > amdgpu/.editorconfig| 4 +- > amdgpu/meson.build | 65 +++- > data/meson.build| 27 +++- > etnaviv/meson.build | 59 ++- > exynos/meson.build | 53 +- > freedreno/meson.build | 76 - > intel/meson.build | 105 +++- > libkms/meson.build | 74 - > man/meson.build | 67 +++- > meson.build | 364 +- > meson_options.txt | 143 +++- > nouveau/meson.build | 58 ++- > omap/meson.build| 53 +- > radeon/meson.build | 63 ++- > tegra/meson.build | 52 +- > tests/amdgpu/meson.build| 34 +++- > tests/etnaviv/meson.build | 45 +- > tests/exynos/meson.build| 54 +- > tests/kms/meson.build | 49 +- > tests/kmstest/meson.build | 30 +++- > tests/meson.build | 86 +- > tests/modeprint/meson.build | 29 +++- > tests/modetest/meson.build | 29 +++- > tests/nouveau/meson.build | 30 +++- > tests/proptest/meson.build | 28 +++- > tests/radeon/meson.build| 27 +++- > tests/tegra/meson.build | 27 +++- > tests/util/meson.build | 28 +++- > tests/vbltest/meson.build | 28 +++- > vc4/meson.build | 28 +++- > 33 files changed, 1869 insertions(+), 4 deletions(-) > create mode 100644 amdgpu/meson.build > create mode 100644 data/meson.build > create mode 100644 etnaviv/meson.build > create mode 100644 exynos/meson.build > create mode 100644 freedreno/meson.build > create mode 100644 intel/meson.build > create mode 100644 libkms/meson.build > create mode 100644 man/meson.build > create mode 100644 meson.build > create mode 100644 meson_options.txt > create mode 100644 nouveau/meson.build > create mode 100644 omap/meson.build > create mode 100644 radeon/meson.build > create mode 100644 tegra/meson.build > create mode 100644 tests/amdgpu/meson.build > create mode 100644 tests/etnaviv/meson.build > create mode 100644 tests/exynos/meson.build > create mode 100644 tests/kms/meson.build > create mode 100644 tests/kmstest/meson.build > create mode 100644 tests/meson.build > create mode 100644 tests/modeprint/meson.build > create mode 100644 tests/modetest/meson.build > create mode 100644 tests/nouveau/meson.build > create mode 100644 tests/proptest/meson.build > create mode 100644 tests/radeon/meson.build > create mode 100
Re: [RFC v2 6/8] drm: Handle fbdev emulation in core
Den 09.01.2018 11.38, skrev Daniel Vetter:
On Wed, Jan 03, 2018 at 11:21:08PM +0100, Noralf Trønnes wrote:
Prepare for generic fbdev emulation by letting DRM core work directly
with the fbdev compatibility layer. This is done by adding new fbdev
helper vtable callbacks for restore, hotplug_event, unregister and
release.
Signed-off-by: Noralf Trønnes
No clue whether my idea is any good, but inspired by the bootsplash
discussion, and the prospect that we might get other in-kernel drm/kms
clients I'm wondering whether we should make this a bit more generic and
tie it to drm_file?
The idea would be to have a list of internal drm clients by putting all
the internal drm_files onto a list (same way we do with the userspace
ones). Then we'd just walk that list and call ->hotplug, ->unregister and
->release at the right places.
->restore would be a bit different, I guess for that we'd only call the
->restore callback of the very first kernel-internal client.
With that we could then add/remove kernel-internal drm clients like normal
userspace clients, which should make integration of emergency consoles,
boot splashes and whatever else real easy. And I think it would be a lot
cleaner than leaking fb_helper knowledge into the drm core, which feels a
rather backwards.
Otoh that feels a bit overengineered (but at least it shouldn't be a lot
more code really). If the list is too much work we could start with 1
drm_file * pointer for internal stuff (but would still need locking, so
list_head is probably easier).
Thoughts?
I prefer to have a proper in-kernel client API from the get go, instead
of fixing it up later. The reason I skipped spending time on it in this
RFC, was that I didn't know if I was on the right track at the right time
to get the necessary attention to make this dumb_buffer idea happen.
With a drm_file centric approach, are you thinking something like this:
struct drm_device {
+ struct list_head filelist_internal;
};
+struct drm_file_funcs {
+ int (*restore)(struct drm_file *file);
+ void (*hotplug)(struct drm_file *file);
+ void (*unregister)(struct drm_file *file);
+};
struct drm_file {
+ struct drm_device *dev;
+ const struct drm_file_funcs *funcs;
};
struct drm_file *drm_file_alloc(struct drm_minor *minor)
{
+ file->dev = dev;
}
struct drm_file* drm_internal_open(struct drm_device *dev,
const struct drm_file_funcs *funcs)
struct drm_file *file;
int ret;
if (!try_module_get(dev->driver->fops->owner))
return ERR_PTR(-ENODEV);
drm_dev_ref(dev);
file = drm_file_alloc(dev);
if (IS_ERR(file)) {
drm_dev_unref(dev);
module_put(dev->driver->fops->owner);
return file;
}
file->funcs = funcs;
mutex_lock(&dev->filelist_mutex);
list_add(&file->lhead, &dev->filelist_internal);
mutex_unlock(&dev->filelist_mutex);
return file;
}
void drm_internal_release(struct drm_file *file)
{
struct drm_device *dev = file->dev;
mutex_lock(&dev->filelist_mutex);
list_del(&file->lhead);
mutex_unlock(&dev->filelist_mutex);
drm_file_free(file);
drm_dev_unref(dev);
module_put(dev->driver->fops->owner);
}
void drm_lastclose(struct drm_device *dev)
{
+ mutex_lock(&dev->filelist_mutex);
+ list_for_each_entry(file, &dev->filelist_internal, lhead) {
+ if (file->funcs && file->funcs->restore &&
+ !file->funcs->restore(file))
+ break;
+ mutex_unlock(&dev->filelist_mutex);
}
void drm_kms_helper_hotplug_event(struct drm_device *dev)
{
+ mutex_lock(&dev->filelist_mutex);
+ list_for_each_entry(file, &dev->filelist_internal, lhead) {
+ if (file->funcs && file->funcs->hotplug)
+ file->funcs->hotplug(file);
+ mutex_unlock(&dev->filelist_mutex);
}
How is locking done when .unregister will call into drm_internal_release()?
void drm_dev_unregister(struct drm_device *dev)
{
+ list_for_each_entry(file, &dev->filelist_internal, lhead) {
+ if (file->funcs && file->funcs->unregister)
+ file->funcs->unregister(file);
}
There is also the case where .unregister can't release the drm_file
because userspace has mmap'ed the buffer (fbdev). The client holds a ref
on drm_device so cleanup is stalled but that requires a driver that can
handle that (ref the tinydrm unplug series which is awaiting a timeslot).
amdgpu iterates dev->filelist in amdgpu_gem_force_release() and
amdgpu_sched_process_priority_override(). I don't know if it needs to
handle the internal ones as well.
What's the rational for having separate lists for internal and userspace?
There is one thing missing and that is notification of new drm_devices.
The client iterates the available drm_devices on module init, but it
needs a way to know about any later drm_device registrations.
Noralf.
-Daniel
---
drivers/gpu/drm/drm_file.c | 12 +++-
drivers/gpu/drm/drm_mode_config.c | 10 ++
d
[Bug 104306] Mesa 17.3 breaks Firefox and other Xwayland apps on AMD HD7750
https://bugs.freedesktop.org/show_bug.cgi?id=104306 --- Comment #14 from eric vz --- Thanks, Michel. On a hanging call to glxinfo, dri2_validate_usage is being called from gbm_dri_bo_import, which gets parameters of a 100x100 FD image buffer for usage 5 (scanout | rendering). However, the image texture winds up with is_displayable = 0, so si_check_resource_capabilities returns false, gbm_dri_bo_import destroys the image, and glxinfo hangs. I confirmed that if I set variable usage = 0 the problem does not occur. I have not yet been able to trace where the texture flags are set, but I got far enough to find that they're being read from the image buffer as metadata. However, it occurs to me that as a newcomer to the domain (e.g., I had to google what a scanout is), I don't know the real problem: * Should usage include scanout? * Should the image metadata include is_displayable? * Should the null return from gbm_dri_bo_import cause the caller to hang? Either point 1 or point 2 seems like it must be wrong, and might be the easiest fix. Point 1 seems the stronger case, since glxinfo doesn't actually draw anything as far as I'm aware. Since Firefox, Chromium, and other apps also seem to fail on this, I'm expecting to find some kind of common initialization code that does it. Will report back when I get time to dig. Or, if anyone knows better than I do which avenue to pursue, I'm happy to be redirected. I don't expect to have time to look at this until the weekend. -- 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] video: fbdev/mmp: add MODULE_LICENSE
Kbuild complains about the lack of a license tag in this driver:
WARNING: modpost: missing MODULE_LICENSE() in drivers/video/fbdev/mmp/mmp_disp.o
This adds the license, author and description tags.
Signed-off-by: Arnd Bergmann
---
drivers/video/fbdev/mmp/core.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/video/fbdev/mmp/core.c b/drivers/video/fbdev/mmp/core.c
index a0f496049db7..3a6bb6561ba0 100644
--- a/drivers/video/fbdev/mmp/core.c
+++ b/drivers/video/fbdev/mmp/core.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
static struct mmp_overlay *path_get_overlay(struct mmp_path *path,
@@ -249,3 +250,7 @@ void mmp_unregister_path(struct mmp_path *path)
mutex_unlock(&disp_lock);
}
EXPORT_SYMBOL_GPL(mmp_unregister_path);
+
+MODULE_AUTHOR("Zhou Zhu ");
+MODULE_DESCRIPTION("Marvell MMP display framework");
+MODULE_LICENSE("GPL");
--
2.9.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5] drm/omap: plane zpos/zorder management improvements
On 01/09/2018 04:40 PM, Daniel Vetter wrote: > On Tue, Jan 09, 2018 at 04:18:48PM +0200, Peter Ujfalusi wrote: >> Hi, >> >> On 2018-01-09 14:44, Daniel Vetter wrote: Changes since v4: - further simplify the zpos checking by using a mask and a single loop - Commit message has been extended Changes since v3: - Use drm_plane_index() instead of storing the same index wothin omap_plane struct - Optimize the zpos validation loop so we avoid extra checks. Changes since v2: - The check for duplicate zpos is moved to omap_crtc Changes since v1: - Dropped the zpos normalization related patches - New patch based on the discussion, see commit message. >>> >>> Sorry for jumping in late to the party, but except when you have a really, >>> really, really good reason for why omapdrm has to not normalize zpos like >>> the other drivers do in this case, then I think we should be consistent. >>> >>> An inconsistent kms uapi is a lot worse than an uapi with some design >>> issues: The latter just means we eventually need v2, the former guarantees >>> we need v2. >> >> Even if the v2 contains the "drm/blend: Account also the primary plane >> of the crtc for normalized_zpos"? >> It is to ensure that the crtc->primary plane is going to have zpos = 0, >> even if it's plane_id is higher. > > It's a bit a hack, but imo makes sense, given where we are with uapi.> Except > it sounds like we have more bikesheds going on about what exactly > zpos is supposed to do. As https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html have this to say about zpos: "priority of the given plane on crtc (optional) Note that multiple active planes on the same crtc can have an identical zpos value. The rule to solving the conflict is to compare the plane object IDs; the plane with a higher ID must be stacked on top of a plane with a lower ID." It implies that the driver should not try to be clever about the normalization of the zpos. Even if it make sense. Considering only crtc->primary is a bit flowed anyway as for the sake of completeness the crtc->cursor plane should have been kept on top at the same time. >> As it was discussed we have use case when we have two (or more) crtcs, >> each with one plane (they are the primary planes for the given crtc) and >> user moves one of the plane from one crtc to another, where it is no >> longer the primary plane, but still holds zpos = 0. >> >> In this case we prefer to keep the actual primary plane of the crtc at >> the bottom and stack the new planes on top. > > Yeah that all sounds reasonable. Or we state that userspace in that case > better readjust zpos to make it non-ambiguous. Or something else. > > Just something that's consistent across drivers. I'm totally fine with > "organically grown uapi with lots of cruds and hacks". I'm fine with using the current normalization as it is and refer to the UAPI doc if user space is not complying with it. But then, should the normalization be forced in the core for all drivers to get consistency? > -Daniel > >> >>> Thanks, Daniel -- 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: next/master build: 198 builds: 1 failed, 197 passed, 1 error, 148 warnings (next-20180110)
On Wed, Jan 10, 2018 at 4:54 PM, Christian König
wrote:
> Hi Arnd,
>
> Am 10.01.2018 um 16:45 schrieb Arnd Bergmann:
>>>
>>> 14 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c:1186:2: warning: ignoring
>>> return value of 'register_shrinker', declared with attribute
>>> warn_unused_result [-Wunused-result]
>>> 14 drivers/gpu/drm/ttm/ttm_page_alloc.c:485:2: warning: ignoring return
>>> value of 'register_shrinker', declared with attribute warn_unused_result
>>> [-Wunused-result]
>>
>> ttm and kvm are now the last user of register_shrinker that doesn't
>> propagate the return code to its
>> caller, all other callers got fixed in one way or another.
>>
>> I tried to fix this one too, but couldn't come up with a proper way of
>> unwinding both
>> kobject_init_and_add() and ttm_pool_mm_shrink_init():
>>
>> ret = kobject_init_and_add(&_manager->kobj, &ttm_pool_kobj_type,
>> &glob->kobj, "pool");
>> if (unlikely(ret != 0)) {
>> kobject_put(&_manager->kobj);
>> _manager = NULL;
>> return ret;
>> }
>>
>> ttm_pool_mm_shrink_init(_manager);
>>
>> Calling kobject_put() after a failed kobject_init_and_add() seemed wrong,
>> and it also appears to be missing a kfree(), so I didn't want to mess it
>> up any further. Added a few people to Cc that touched this file most,
>> maybe one of them can have a look, or they already have a patch waiting
>> to get merged.
>
>
> That isn't urgent, isn't it? So I would say I put it on my TODO list and I'm
> going to take care of it no later than 4.17.
>
> Otherwise Roger or me could take a look tomorrow.
My understanding is that the warning will be in 4.16, so the fix should be
as well, if only to get a clean build again. There were around a dozen such
warnings when the warn_unused_result got added, but the others are all
fixed in linux-next.
This is how the flag got added:
commit 64067c5cbfa24a2202b92e8fda7323610cad3043
Author: Tetsuo Handa
Date: Fri Jan 5 13:25:45 2018 +1100
mm,vmscan: mark register_shrinker() as __must_check
There are users not checking for register_shrinker() failure. Continuing
with ignoring failure can lead to later oops at unregister_shrinker().
Link:
http://lkml.kernel.org/r/1511265757-15563-1-git-send-email-penguin-ker...@i-love.sakura.ne.jp
Signed-off-by: Tetsuo Handa
Arnd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panel: lvds: Handle the optional regulator case properly
The devm_regulator_get_optional function, unlike it was assumed in the
commit a1c55bccf600 ("drm/panel: lvds: Add support for the power-supply
property"), is actually returning an error pointer with -ENODEV instead of
NULL when there's no regulator to find.
Make sure we handle that case properly.
Fixes: a1c55bccf600 ("drm/panel: lvds: Add support for the power-supply
property")
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/panel/panel-lvds.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-lvds.c
b/drivers/gpu/drm/panel/panel-lvds.c
index 57e38a9e7ab4..9f46e7095c0e 100644
--- a/drivers/gpu/drm/panel/panel-lvds.c
+++ b/drivers/gpu/drm/panel/panel-lvds.c
@@ -215,8 +215,13 @@ static int panel_lvds_probe(struct platform_device *pdev)
lvds->supply = devm_regulator_get_optional(lvds->dev, "power");
if (IS_ERR(lvds->supply)) {
ret = PTR_ERR(lvds->supply);
- dev_err(lvds->dev, "failed to request regulator: %d\n", ret);
- return ret;
+
+ if (ret != -ENODEV) {
+ dev_err(lvds->dev, "failed to request regulator: %d\n",
ret);
+ return ret;
+ } else {
+ lvds->supply = NULL;
+ }
}
/* Get GPIOs and backlight controller. */
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: next/master build: 198 builds: 1 failed, 197 passed, 1 error, 148 warnings (next-20180110)
Hi Arnd,
Am 10.01.2018 um 16:45 schrieb Arnd Bergmann:
14 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c:1186:2: warning: ignoring return
value of 'register_shrinker', declared with attribute warn_unused_result
[-Wunused-result]
14 drivers/gpu/drm/ttm/ttm_page_alloc.c:485:2: warning: ignoring return value
of 'register_shrinker', declared with attribute warn_unused_result
[-Wunused-result]
ttm and kvm are now the last user of register_shrinker that doesn't
propagate the return code to its
caller, all other callers got fixed in one way or another.
I tried to fix this one too, but couldn't come up with a proper way of
unwinding both
kobject_init_and_add() and ttm_pool_mm_shrink_init():
ret = kobject_init_and_add(&_manager->kobj, &ttm_pool_kobj_type,
&glob->kobj, "pool");
if (unlikely(ret != 0)) {
kobject_put(&_manager->kobj);
_manager = NULL;
return ret;
}
ttm_pool_mm_shrink_init(_manager);
Calling kobject_put() after a failed kobject_init_and_add() seemed wrong,
and it also appears to be missing a kfree(), so I didn't want to mess it
up any further. Added a few people to Cc that touched this file most,
maybe one of them can have a look, or they already have a patch waiting
to get merged.
That isn't urgent, isn't it? So I would say I put it on my TODO list and
I'm going to take care of it no later than 4.17.
Otherwise Roger or me could take a look tomorrow.
Regards,
Christian.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: next/master build: 198 builds: 1 failed, 197 passed, 1 error, 148 warnings (next-20180110)
On Wed, Jan 10, 2018 at 7:59 AM, kernelci.org bot wrote:
>
> next/master build: 198 builds: 1 failed, 197 passed, 1 error, 148 warnings
> (next-20180110)
>
> Errors summary:
> 1 drivers/perf/arm_dsu_pmu.c:661:2: error: implicit declaration of function
> 'bitmap_from_u32array' [-Werror=implicit-function-declaration]
I sent a patch, waiting for it to get merged
> Warnings summary:
> 1 arch/x86/kvm/mmu.c:5485:2: warning: ignoring return value of
> 'register_shrinker', declared with attribute warn_unused_result
> [-Wunused-result]
I have a patch for this, will send after some more testing.
> 14 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c:1186:2: warning: ignoring return
> value of 'register_shrinker', declared with attribute warn_unused_result
> [-Wunused-result]
> 14 drivers/gpu/drm/ttm/ttm_page_alloc.c:485:2: warning: ignoring return value
> of 'register_shrinker', declared with attribute warn_unused_result
> [-Wunused-result]
ttm and kvm are now the last user of register_shrinker that doesn't
propagate the return code to its
caller, all other callers got fixed in one way or another.
I tried to fix this one too, but couldn't come up with a proper way of
unwinding both
kobject_init_and_add() and ttm_pool_mm_shrink_init():
ret = kobject_init_and_add(&_manager->kobj, &ttm_pool_kobj_type,
&glob->kobj, "pool");
if (unlikely(ret != 0)) {
kobject_put(&_manager->kobj);
_manager = NULL;
return ret;
}
ttm_pool_mm_shrink_init(_manager);
Calling kobject_put() after a failed kobject_init_and_add() seemed wrong,
and it also appears to be missing a kfree(), so I didn't want to mess it
up any further. Added a few people to Cc that touched this file most,
maybe one of them can have a look, or they already have a patch waiting
to get merged.
> 4 WARNING: modpost: missing MODULE_LICENSE() in net/9p/9pnet_xen.o
> 4 WARNING: modpost: missing MODULE_LICENSE() in
> drivers/auxdisplay/img-ascii-lcd.o
Patches for these two got posted a while ago but never picked up. I've
merged those
into my tree, and plan to forward them to Andrew Morton.
> 3 WARNING: modpost: missing MODULE_LICENSE() in
> sound/soc/ux500/snd-soc-ux500-plat-dma.o
> 3 WARNING: modpost: missing MODULE_LICENSE() in
> sound/soc/ux500/snd-soc-ux500-mach-mop500.o
> 3 WARNING: modpost: missing MODULE_LICENSE() in
> drivers/video/fbdev/mmp/mmp_disp.o
> 2 WARNING: modpost: missing MODULE_LICENSE() in
> drivers/phy/qualcomm/phy-qcom-ufs.o
> 2 WARNING: modpost: missing MODULE_LICENSE() in
> drivers/net/ethernet/cirrus/cs89x0.o
> 2 WARNING: modpost: missing MODULE_LICENSE() in arch/arm/mach-pxa/tosa-bt.o
> 2 WARNING: modpost: missing MODULE_LICENSE() in
> arch/arm/common/bL_switcher_dummy_if.o
I made patches for these now, will send them in a bit.
> 7 arch/arm/boot/dts/spear1340-evb.dtb: Warning (dmas_property): Property
> 'dmas', cell 4 is not a phandle reference in /ahb/apb/serial@b410
> 7 arch/arm/boot/dts/spear1340-evb.dtb: Warning (dmas_property): Missing
> property '#dma-cells' in node /interrupt-controller@ec801000 or bad phandle
> (referred from /ahb/apb/serial@b410:dmas[4])
> 7 arch/arm/boot/dts/spear1310-evb.dtb: Warning (gpios_property): Property
> 'cs-gpios', cell 6 is not a phandle reference in /ahb/apb/spi@e010
> 7 arch/arm/boot/dts/spear1310-evb.dtb: Warning (gpios_property): Missing
> property '#gpio-cells' in node /interrupt-controller@ec801000 or bad phandle
> (referred from /ahb/apb/spi@e010:cs-gpios[6])
> 2 arch/arm/boot/dts/spear600-evb.dtb: Warning (interrupts_property): Missing
> interrupt-parent for /ahb/apb/rtc@fc90
Viresh, could you have a look here?
> 2 arch/arm/boot/dts/ste-nomadik-s8815.dtb: Warning (interrupts_property):
> Missing interrupt-parent for /amba/clcd@1012
> 2 arch/arm/boot/dts/ste-nomadik-nhk15.dtb: Warning (interrupts_property):
> Missing interrupt-parent for /amba/clcd@1012
Linus, can you look at this? I don't know which interrupt-parent is
the right one here, maybe
you can find out from the hardware or some documentation you have.
> 2 arch/arm/boot/dts/lpc3250-phy3250.dtb: Warning (gpios_property): reset-gpio
> property size (12) too small for cell size 3 in
> /ahb/apb/i2c@400A/uda1380@18
> 2 arch/arm/boot/dts/lpc3250-phy3250.dtb: Warning (gpios_property): power-gpio
> property size (12) too small for cell size 3 in
> /ahb/apb/i2c@400A/uda1380@18
> 2 arch/arm/boot/dts/lpc3250-ea3250.dtb: Warning (gpios_property): reset-gpio
> property size (12) too small for cell size 3 in
> /ahb/apb/i2c@400A/uda1380@18
> 2 arch/arm/boot/d
[git pull] vmwgfx-fixes-4.15
Dave, Two important fixes for vmwgfx. The off-by-one fix could cause a malicious user to potentially crash the kernel. The framebuffer map cache fix can under some circumstances enable a user to read from or write to freed pages. The following changes since commit b0bb222440a5c8273f67dd37946707e6ba6ad832: Merge branch 'linux-4.15' of git://github.com/skeggsb/linux into drm-fixes (2018-01-09 12:03:10 +1000) are available in the git repository at: git://people.freedesktop.org/~thomash/linux vmwgfx-fixes-4.15 for you to fetch changes up to 0d9cac0ca0429830c40fe1a4e50e60f6221fd7b6: drm/vmwgfx: Potential off by one in vmw_view_add() (2018-01-10 15:21:39 +0100) Dan Carpenter (1): drm/vmwgfx: Potential off by one in vmw_view_add() Thomas Hellstrom (1): drm/vmwgfx: Don't cache framebuffer maps drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 ++ drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 6 - drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c| 41 ++--- 4 files changed, 15 insertions(+), 36 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vc4: Fix NULL pointer dereference in vc4_save_hang_state()
When saving BOs in the hang state we skip one entry of the
kernel_state->bo[] array, thus leaving it to NULL. This leads to a NULL
pointer dereference when, later in this function, we iterate over all
BOs to check their ->madv state.
Fixes: ca26d28bbaa3 ("drm/vc4: improve throughput by pipelining binning and
rendering jobs")
Cc:
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/vc4/vc4_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index 6c32c89a83a9..19ac7fe0e5db 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -208,7 +208,7 @@ vc4_save_hang_state(struct drm_device *dev)
kernel_state->bo[j + prev_idx] = &bo->base.base;
j++;
}
- prev_idx = j + 1;
+ prev_idx = j;
}
if (exec[0])
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: AMD DC test results
On Thu, Dec 21, 2017 at 1:45 PM, Daniel Drake wrote: > Hi, Hi again, in Endless we are still actively working with DC on several laptops, so I just wanted to give you a quick update regarding the regressions indicated in Daniel's email. > 1. System hangs on S3 resume. > Bug can't be reproduced when booting with amdgpu.dc=0 > Also reproduced with DC on Linus master (4.15-rc), but appears fixed > on agd5f/amd-staging-drm-next > https://bugs.freedesktop.org/show_bug.cgi?id=104281 This keeps being an issue. Unfortunately (as stated in the bug report) this problem is still reproducible on the agd5f/amd-staging-drm-next branch (tested it today with HEAD at 95b5f44) even though the frequency is not high (maybe 1/10 suspends or less). In the bug report you can find the dmesg log if interested. > 2. Display corruption when using multiple displays > Bug can't be reproduced when booting with amdgpu.dc=0 > Also reproduced with DC on Linus master (4.15-rc), but appears fixed > on agd5f/amd-staging-drm-next > https://bugs.freedesktop.org/show_bug.cgi?id=104319 I was able to bisect this problem down to 1 specific commit (see [0]). > 3. HDMI audio device still shown as present and active even after > disconnecting HDMI cable > Bug can't be reproduced when booting with amdgpu.dc=0 > Appears fixed with DC on Linus master (4.15-rc). This was indeed fixed in on Linus master. Thank you very much for the DC work! Cheers, [0] https://www.spinics.net/lists/dri-devel/msg161258.html -- Carlo Caione | +44.7384.69.16.04 | Endless ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 2/3] drm: export gem dmabuf_ops for drivers to reuse
OK. I'll do it.
Samuel Li
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Wednesday, January 10, 2018 3:17 AM
> To: Alex Deucher
> Cc: Deucher, Alexander ; Li, Samuel
> ; Daniel Vetter ; Koenig, Christian
> ; dri-devel@lists.freedesktop.org; amd-
> g...@lists.freedesktop.org
> Subject: Re: [PATCH 2/3] drm: export gem dmabuf_ops for drivers to reuse
>
> On Tue, Jan 09, 2018 at 01:13:08PM -0500, Alex Deucher wrote:
> > On Tue, Jan 9, 2018 at 10:56 AM, Deucher, Alexander
> > wrote:
> > > I'll can push this and a few other misc patches today.
> > >
> >
> > Pushed to drm-misc-next.
>
> One thing I just noticed: Some kerneldoc for the newly exported functions
> and maybe a small update to the intro section to explain what to do with this
> would be neat.
> -Daniel
>
> >
> > Thanks,
> >
> > Alex
> >
> >
> > >
> > > Alex
> > >
> > > From: amd-gfx on behalf of
> > > Li, Samuel
> > > Sent: Tuesday, January 9, 2018 10:20 AM
> > > To: Daniel Vetter; Koenig, Christian
> > > Cc: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> > > Subject: RE: [PATCH 2/3] drm: export gem dmabuf_ops for drivers to
> > > reuse
> > >
> > > Yes, please hush this for me.
> > >
> > > Regards,
> > > Samuel Li
> > >
> > >
> > >> -Original Message-
> > >> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> > >> Daniel Vetter
> > >> Sent: Tuesday, January 09, 2018 4:22 AM
> > >> To: Koenig, Christian
> > >> Cc: Li, Samuel ;
> > >> dri-devel@lists.freedesktop.org; amd- g...@lists.freedesktop.org
> > >> Subject: Re: [PATCH 2/3] drm: export gem dmabuf_ops for drivers to
> > >> reuse
> > >>
> > >> On Fri, Jan 05, 2018 at 10:16:04AM +0100, Christian König wrote:
> > >> > Am 04.01.2018 um 22:12 schrieb Samuel Li:
> > >> > > Change-Id: I03c22a890d2305f3243d88019d1a28bddd4ddda7
> > >> > > Signed-off-by: Samuel Li
> > >> >
> > >> > Reviewed-by: Christian König
> > >>
> > >> Want to push to drm-misc or some other plan with this?
> > >> -Daniel
> > >>
> > >> >
> > >> > > ---
> > >> > > drivers/gpu/drm/drm_prime.c | 53
> > >> > > ++---
> > >>
> > >> > > include/drm/drm_prime.h | 22 +++
> > >> > > 2 files changed, 53 insertions(+), 22 deletions(-)
> > >> > >
> > >> > > diff --git a/drivers/gpu/drm/drm_prime.c
> > >> > > b/drivers/gpu/drm/drm_prime.c index 8de93a2..68a69e9 100644
> > >> > > --- a/drivers/gpu/drm/drm_prime.c
> > >> > > +++ b/drivers/gpu/drm/drm_prime.c
> > >> > > @@ -180,9 +180,8 @@ static int
> > >> > > drm_prime_lookup_buf_handle(struct
> > >> drm_prime_file_private *prime_fpri
> > >> > >return -ENOENT;
> > >> > > }
> > >> > > -static int drm_gem_map_attach(struct dma_buf *dma_buf,
> > >> > > - struct device *target_dev,
> > >> > > - struct dma_buf_attachment *attach)
> > >> > > +int drm_gem_map_attach(struct dma_buf *dma_buf, struct
> device
> > >> *target_dev,
> > >> > > +struct dma_buf_attachment *attach)
> > >> > > {
> > >> > >struct drm_prime_attachment *prime_attach;
> > >> > >struct drm_gem_object *obj = dma_buf->priv; @@ -200,9
> > >> > > +199,10
> > >> @@
> > >> > > static int drm_gem_map_attach(struct dma_buf *dma_buf,
> > >> > >return dev->driver->gem_prime_pin(obj);
> > >> > > }
> > >> > > +EXPORT_SYMBOL(drm_gem_map_attach);
> > >> > > -static void drm_gem_map_detach(struct dma_buf *dma_buf,
> > >> > > -struct dma_buf_attachment *attach)
> > >> > > +void drm_gem_map_detach(struct dma_buf *dma_buf,
> > >> > > + struct dma_buf_attachment *attach)
> > >> > > {
> > >> > >struct drm_prime_attachment *prime_attach = attach->priv;
> > >> > >struct drm_gem_object *obj = dma_buf->priv; @@ -227,6 +227,7
> > >> @@
> > >> > > static void drm_gem_map_detach(struct dma_buf *dma_buf,
> > >> > >kfree(prime_attach);
> > >> > >attach->priv = NULL;
> > >> > > }
> > >> > > +EXPORT_SYMBOL(drm_gem_map_detach);
> > >> > > void drm_prime_remove_buf_handle_locked(struct
> > >> drm_prime_file_private *prime_fpriv,
> > >> > >struct dma_buf *dma_buf) @@
> > >> > > -253,8 +254,8 @@ void
> > >> drm_prime_remove_buf_handle_locked(struct
> drm_prime_file_private
> > >> *prime_fpr
> > >> > >}
> > >> > > }
> > >> > > -static struct sg_table *drm_gem_map_dma_buf(struct
> > >> dma_buf_attachment *attach,
> > >> > > - enum dma_data_direction dir)
> > >> > > +struct sg_table *drm_gem_map_dma_buf(struct
> dma_buf_attachment
> > >> *attach,
> > >> > > + enum dma_data_direction dir)
> > >> > > {
> > >> > >struct drm_prime_attachment *prime_attach = attach->priv;
> > >> > >struct drm_gem_object *obj = attach->dmabuf->priv; @@
> > >> > > -289,13
> > >> > > +290,15 @@ static struct sg_table *drm_ge
Re: [PATCH 2/4 v6] drm/bridge: Provide a way to embed timing info in bridges
On Wed, Jan 10, 2018 at 03:12:24PM +0100, Linus Walleij wrote:
> After some discussion and failed patch sets trying to convey
> the right timing information between the display engine and
> a bridge using the connector, I try instead to use an optional
> timing information container in the bridge itself, so that
> display engines can retrieve it from any bridge and use it to
> determine how to drive outputs.
>
> Signed-off-by: Linus Walleij
> ---
> ChangeLog v5->v6:
> - Sort forward struct declarations alphabetically
> - Switch to using DRM_BUS_FLAG_PIXDATA_[POS|NEG]EDGE to indicate
> positive or negatice clock samling edge
> ChangeLog ->v5:
> - New patch
> ---
> include/drm/drm_bridge.h | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index 682d01ba920c..28c9ac6d9036 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -29,6 +29,7 @@
> #include
>
> struct drm_bridge;
> +struct drm_bridge_timings;
> struct drm_panel;
>
> /**
> @@ -222,6 +223,23 @@ struct drm_bridge_funcs {
> void (*enable)(struct drm_bridge *bridge);
> };
>
> +/**
> + * struct drm_bridge_timings - timing information for the bridge
> + * @sampling_edge: whether the bridge samples the digital input signal from
> the
> + * display engine on the positive or negative edge of the clock, this should
> + * reuse the DRM_BUS_FLAG_PIXDATA_[POS|NEG]EDGE bitwise flags from the DRM
> + * connector (bit 2 and 3 valid)
> + * @setup_time_ps: the time in picoseconds the input data lines must be
> stable
> + * before the clock edge
> + * @hold_time_ps: the time in picoseconds taken for the bridge to sample the
> + * input signal after the clock edge
> + */
Just a style nit: for longer kerneldoc comments for struct members the
in-line style, split up for each member, is imo better.
-Daniel
> +struct drm_bridge_timings {
> + u32 sampling_edge;
> + u32 setup_time_ps;
> + u32 hold_time_ps;
> +};
> +
> /**
> * struct drm_bridge - central DRM bridge control structure
> * @dev: DRM device this bridge belongs to
> @@ -229,6 +247,8 @@ struct drm_bridge_funcs {
> * @next: the next bridge in the encoder chain
> * @of_node: device node pointer to the bridge
> * @list: to keep track of all added bridges
> + * @timings: the timing specification for the bridge, if any (may
> + * be NULL)
> * @funcs: control functions
> * @driver_private: pointer to the bridge driver's internal context
> */
> @@ -240,6 +260,7 @@ struct drm_bridge {
> struct device_node *of_node;
> #endif
> struct list_head list;
> + const struct drm_bridge_timings *timings;
>
> const struct drm_bridge_funcs *funcs;
> void *driver_private;
> --
> 2.14.3
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [-next PATCH 2/4] treewide: Use DEVICE_ATTR_RW
On 2017-12-20 12:54, Jarkko Nikula wrote: > On Wed, Dec 20, 2017 at 10:32:11AM +0100, Greg Kroah-Hartman wrote: >> On Wed, Dec 20, 2017 at 01:24:44AM -0800, Joe Perches wrote: >>> On Wed, 2017-12-20 at 10:34 +0200, Jarkko Nikula wrote: On Tue, Dec 19, 2017 at 10:15:07AM -0800, Joe Perches wrote: > Convert DEVICE_ATTR uses to DEVICE_ATTR_RW where possible. >>> [] > diff --git a/sound/soc/omap/mcbsp.c b/sound/soc/omap/mcbsp.c >>> [] > @@ -854,7 +854,7 @@ static ssize_t dma_op_mode_store(struct device *dev, > return size; > } > > -static DEVICE_ATTR(dma_op_mode, 0644, dma_op_mode_show, > dma_op_mode_store); > +static DEVICE_ATTR_RW(dma_op_mode); > While I can ack this part here if it helps generic cleanup effort I don't understart would it improve code readability in general? Mode 644 is clear and don't need any grepping but for DEVICE_ATTR_RW() I had to go through all of these files in order to see what does it mean: >> >> Yeah, 644 is "clear", but _RW() is even more clear. Ideally I want to >> get rid of all of the "non-standard" users that set random modes of >> sysfs files, as we get it wrong too many times. Using the "defaults" is >> much better. >> > Fair enough. For the sound/soc/omap/ (Acked-by was missing from my > previous reply): > > Acked-by: Jarkko Nikula And from me to the same file (sound/soc/omap/mcbsp.c): Acked-by: Peter Ujfalusi - 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: [PATCH v2 2/2] drm/bridge/synopsys: dsi: handle endianness correctly in dw_mipi_dsi_write()
On 09.01.2018 21:32, Brian Norris wrote:
> We're filling the "remainder" word with little-endian data, then writing
> it out to IO registers with endian-correcting writel(). That probably
> won't work on big-endian systems.
>
> Let's mark the "remainder" variable as LE32 (since we fill it with
> memcpy()) and do the swapping explicitly.
>
> Some of this function could be done more easily without memcpy(), but
> the unaligned "remainder" case is a little hard to do without
> potentially overrunning 'tx_buf', so I just applied the same solution in
> all cases (memcpy() + le32_to_cpu()).
>
> Tested only on a little-endian system.
>
> Signed-off-by: Brian Norris
> ---
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index ed91e32ee43a..90f13df6f106 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -360,18 +360,18 @@ static int dw_mipi_dsi_write(struct dw_mipi_dsi *dsi,
> {
> const u8 *tx_buf = packet->payload;
> int len = packet->payload_length, pld_data_bytes = sizeof(u32), ret;
> - u32 remainder;
> + __le32 word;
> u32 val;
>
> while (len) {
> if (len < pld_data_bytes) {
> - remainder = 0;
> - memcpy(&remainder, tx_buf, len);
> - dsi_write(dsi, DSI_GEN_PLD_DATA, remainder);
> + word = 0;
> + memcpy(&word, tx_buf, len);
> + dsi_write(dsi, DSI_GEN_PLD_DATA, le32_to_cpu(word));
> len = 0;
> } else {
> - memcpy(&remainder, tx_buf, pld_data_bytes);
> - dsi_write(dsi, DSI_GEN_PLD_DATA, remainder);
> + memcpy(&word, tx_buf, pld_data_bytes);
> + dsi_write(dsi, DSI_GEN_PLD_DATA, le32_to_cpu(word));
> tx_buf += pld_data_bytes;
> len -= pld_data_bytes;
> }
> @@ -386,9 +386,9 @@ static int dw_mipi_dsi_write(struct dw_mipi_dsi *dsi,
> }
> }
>
> - remainder = 0;
> - memcpy(&remainder, packet->header, sizeof(packet->header));
> - return dw_mipi_dsi_gen_pkt_hdr_write(dsi, remainder);
> + word = 0;
> + memcpy(&word, packet->header, sizeof(packet->header));
> + return dw_mipi_dsi_gen_pkt_hdr_write(dsi, le32_to_cpu(word));
You could create and use appropriate helper, lets say:
u32 le_to_cpup(const u8 *p, int count)
{
__le32 r = 0;
memcpy(&r, p, count);
return le32_to_cpu(r);
}
With or without this change:
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> }
>
> static ssize_t dw_mipi_dsi_host_transfer(struct mipi_dsi_host *host,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vmwgfx: Potential off by one in vmw_view_add()
Hi!
On 01/10/2018 10:40 AM, Dan Carpenter wrote:
The vmw_view_cmd_to_type() function returns vmw_view_max (3) on error.
It's one element beyond the end of the vmw_view_cotables[] table.
My read on this is that it's possible to hit this failure. header->id
comes from vmw_cmd_check() and it's a user controlled number between
1040 and 1225 so we can hit that error. But I don't have the hardware
to test this code.
Fixes: d80efd5cb3de ("drm/vmwgfx: Initial DX support")
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index b700667f6f0b..c9d5cc237124 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -2731,6 +2731,8 @@ static int vmw_cmd_dx_view_define(struct vmw_private
*dev_priv,
}
view_type = vmw_view_cmd_to_type(header->id);
+ if (view_type == vmw_view_max)
+ return -EINVAL;
cmd = container_of(header, typeof(*cmd), header);
ret = vmw_cmd_res_check(dev_priv, sw_context, vmw_res_surface,
user_surface_converter,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
This looks correct to me. I'll queue this for a -fixes pull. Thanks.
Reviewed-by: Thomas Hellstrom
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4 v6] drm/bridge: Add timing support to dumb VGA DAC
This extends the dumb VGA DAC bridge to handle the THS8134A
and THS8134B VGA DACs in addition to those already handled.
We assign the proper timing data to the pointer inside the
bridge struct so display controllers that need to align their
timings to the bridge can pick it up and work from there.
Cc: Bartosz Golaszewski
Cc: Maxime Ripard
Reviewed-by: Laurent Pinchart
Signed-off-by: Linus Walleij
---
ChangeLog v5->v6:
- Use DRM_BUS_FLAG_PIXDATA_[POS|NEG]EDGE to indicate
the sampling edge of the clock signal.
- Skip intermediate variable for timings.
- Leave timings as NULL for really dumb VGA DACs.
- Collect Laurent's Review tag.
ChangeLog v4->v5:
- Rewrite the support using the new concept of defining
fine-granular sampling (setup+hold) timing definitions
stored in the bridge timings struct.
ChangeLog v3->v4:
- Actually have the code syntactically correct and compiling :(
(Kconfig mistake.)
(...)
AS usr/initramfs_data.o
AR usr/built-in.o
CC drivers/gpu/drm/bridge/dumb-vga-dac.o
AR drivers/gpu/drm/bridge/built-in.o
AR drivers/gpu/drm/built-in.o
AR drivers/gpu/built-in.o
AR drivers/built-in.o
(...)
ChangeLog v2->v3:
- Move const specifier.
- Cut one line of code assigning bus flags.
- Preserve the "ti,ths8135" compatible for elder device trees.
ChangeLog v1->v2:
- Alphabetize includes
- Use a u32 with the bus polarity flags and just encode the
polarity using the DRM define directly.
- Rename vendor_data to vendor_info.
- Simplify assignment of the flag as it is just a simple
u32 now.
- Probe all TI variants on the "ti,ths813x" wildcard for now,
we only need to know that the device is in this family to
set the clock edge flag right.
---
drivers/gpu/drm/bridge/dumb-vga-dac.c | 59 +--
1 file changed, 56 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
b/drivers/gpu/drm/bridge/dumb-vga-dac.c
index de5e7dee7ad6..498d5948d1a8 100644
--- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
+++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
@@ -11,6 +11,7 @@
*/
#include
+#include
#include
#include
@@ -204,6 +205,7 @@ static int dumb_vga_probe(struct platform_device *pdev)
vga->bridge.funcs = &dumb_vga_bridge_funcs;
vga->bridge.of_node = pdev->dev.of_node;
+ vga->bridge.timings = of_device_get_match_data(&pdev->dev);
drm_bridge_add(&vga->bridge);
@@ -222,10 +224,61 @@ static int dumb_vga_remove(struct platform_device *pdev)
return 0;
}
+/*
+ * We assume the ADV7123 DAC is the "default" for historical reasons
+ * Information taken from the ADV7123 datasheet, revision D.
+ * NOTE: the ADV7123EP seems to have other timings and need a new timings
+ * set if used.
+ */
+static const struct drm_bridge_timings default_dac_timings = {
+ /* Timing specifications, datasheet page 7 */
+ .sampling_edge = DRM_BUS_FLAG_PIXDATA_POSEDGE,
+ .setup_time_ps = 500,
+ .hold_time_ps = 1500,
+};
+
+/*
+ * Information taken from the THS8134, THS8134A, THS8134B datasheet named
+ * "SLVS205D", dated May 1990, revised March 2000.
+ */
+static const struct drm_bridge_timings ti_ths8134_dac_timings = {
+ /* From timing diagram, datasheet page 9 */
+ .sampling_edge = DRM_BUS_FLAG_PIXDATA_POSEDGE,
+ /* From datasheet, page 12 */
+ .setup_time_ps = 3000,
+ /* I guess this means latched input */
+ .hold_time_ps = 0,
+};
+
+/*
+ * Information taken from the THS8135 datasheet named "SLAS343B", dated
+ * May 2001, revised April 2013.
+ */
+static const struct drm_bridge_timings ti_ths8135_dac_timings = {
+ /* From timing diagram, datasheet page 14 */
+ .sampling_edge = DRM_BUS_FLAG_PIXDATA_POSEDGE,
+ /* From datasheet, page 16 */
+ .setup_time_ps = 2000,
+ .hold_time_ps = 500,
+};
+
static const struct of_device_id dumb_vga_match[] = {
- { .compatible = "dumb-vga-dac" },
- { .compatible = "adi,adv7123" },
- { .compatible = "ti,ths8135" },
+ {
+ .compatible = "dumb-vga-dac",
+ .data = NULL,
+ },
+ {
+ .compatible = "adi,adv7123",
+ .data = &default_dac_timings,
+ },
+ {
+ .compatible = "ti,ths8135",
+ .data = &ti_ths8135_dac_timings,
+ },
+ {
+ .compatible = "ti,ths8134",
+ .data = &ti_ths8134_dac_timings,
+ },
{},
};
MODULE_DEVICE_TABLE(of, dumb_vga_match);
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4 v6] drm/bridge: Provide a way to embed timing info in bridges
After some discussion and failed patch sets trying to convey
the right timing information between the display engine and
a bridge using the connector, I try instead to use an optional
timing information container in the bridge itself, so that
display engines can retrieve it from any bridge and use it to
determine how to drive outputs.
Signed-off-by: Linus Walleij
---
ChangeLog v5->v6:
- Sort forward struct declarations alphabetically
- Switch to using DRM_BUS_FLAG_PIXDATA_[POS|NEG]EDGE to indicate
positive or negatice clock samling edge
ChangeLog ->v5:
- New patch
---
include/drm/drm_bridge.h | 21 +
1 file changed, 21 insertions(+)
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 682d01ba920c..28c9ac6d9036 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -29,6 +29,7 @@
#include
struct drm_bridge;
+struct drm_bridge_timings;
struct drm_panel;
/**
@@ -222,6 +223,23 @@ struct drm_bridge_funcs {
void (*enable)(struct drm_bridge *bridge);
};
+/**
+ * struct drm_bridge_timings - timing information for the bridge
+ * @sampling_edge: whether the bridge samples the digital input signal from the
+ * display engine on the positive or negative edge of the clock, this should
+ * reuse the DRM_BUS_FLAG_PIXDATA_[POS|NEG]EDGE bitwise flags from the DRM
+ * connector (bit 2 and 3 valid)
+ * @setup_time_ps: the time in picoseconds the input data lines must be stable
+ * before the clock edge
+ * @hold_time_ps: the time in picoseconds taken for the bridge to sample the
+ * input signal after the clock edge
+ */
+struct drm_bridge_timings {
+ u32 sampling_edge;
+ u32 setup_time_ps;
+ u32 hold_time_ps;
+};
+
/**
* struct drm_bridge - central DRM bridge control structure
* @dev: DRM device this bridge belongs to
@@ -229,6 +247,8 @@ struct drm_bridge_funcs {
* @next: the next bridge in the encoder chain
* @of_node: device node pointer to the bridge
* @list: to keep track of all added bridges
+ * @timings: the timing specification for the bridge, if any (may
+ * be NULL)
* @funcs: control functions
* @driver_private: pointer to the bridge driver's internal context
*/
@@ -240,6 +260,7 @@ struct drm_bridge {
struct device_node *of_node;
#endif
struct list_head list;
+ const struct drm_bridge_timings *timings;
const struct drm_bridge_funcs *funcs;
void *driver_private;
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4 v6] drm/pl111: Support handling bridge timings
If the bridge has a too strict setup time for the incoming
signals, we may not be fast enough and then we need to
compensate by outputting the signal on the inverse clock
edge so it is for sure stable when the bridge samples it.
Since bridges in difference to panels does not expose their
connectors, make the connector optional in the display
setup code.
Acked-by: Laurent Pinchart
Signed-off-by: Linus Walleij
---
ChangeLog v5->v6:
- Collect Laurent's ACK.
ChangeLog v4->v5:
- Use the new bridge timings setup method.
---
drivers/gpu/drm/pl111/Kconfig | 1 +
drivers/gpu/drm/pl111/pl111_display.c | 35 +++
drivers/gpu/drm/pl111/pl111_drv.c | 20 +++-
3 files changed, 43 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/pl111/Kconfig b/drivers/gpu/drm/pl111/Kconfig
index e5e2abd66491..82cb3e60ddc8 100644
--- a/drivers/gpu/drm/pl111/Kconfig
+++ b/drivers/gpu/drm/pl111/Kconfig
@@ -8,6 +8,7 @@ config DRM_PL111
select DRM_GEM_CMA_HELPER
select DRM_BRIDGE
select DRM_PANEL_BRIDGE
+ select DRM_DUMB_VGA_DAC
select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
help
Choose this option for DRM support for the PL111 CLCD controller.
diff --git a/drivers/gpu/drm/pl111/pl111_display.c
b/drivers/gpu/drm/pl111/pl111_display.c
index 06c4bf756b69..7fe4040aea46 100644
--- a/drivers/gpu/drm/pl111/pl111_display.c
+++ b/drivers/gpu/drm/pl111/pl111_display.c
@@ -94,6 +94,7 @@ static void pl111_display_enable(struct
drm_simple_display_pipe *pipe,
const struct drm_display_mode *mode = &cstate->mode;
struct drm_framebuffer *fb = plane->state->fb;
struct drm_connector *connector = priv->connector;
+ struct drm_bridge *bridge = priv->bridge;
u32 cntl;
u32 ppl, hsw, hfp, hbp;
u32 lpp, vsw, vfp, vbp;
@@ -143,11 +144,37 @@ static void pl111_display_enable(struct
drm_simple_display_pipe *pipe,
if (mode->flags & DRM_MODE_FLAG_NVSYNC)
tim2 |= TIM2_IVS;
- if (connector->display_info.bus_flags & DRM_BUS_FLAG_DE_LOW)
- tim2 |= TIM2_IOE;
+ if (connector) {
+ if (connector->display_info.bus_flags & DRM_BUS_FLAG_DE_LOW)
+ tim2 |= TIM2_IOE;
- if (connector->display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_NEGEDGE)
- tim2 |= TIM2_IPC;
+ if (connector->display_info.bus_flags &
+ DRM_BUS_FLAG_PIXDATA_NEGEDGE)
+ tim2 |= TIM2_IPC;
+ }
+
+ if (bridge) {
+ const struct drm_bridge_timings *btimings = bridge->timings;
+
+ /*
+* Here is when things get really fun. Sometimes the bridge
+* timings are such that the signal out from PL11x is not
+* stable before the receiving bridge (such as a dumb VGA DAC
+* or similar) samples it. If that happens, we compensate by
+* the only method we have: output the data on the opposite
+* edge of the clock so it is for sure stable when it gets
+* sampled.
+*
+* The PL111 manual does not contain proper timining diagrams
+* or data for these details, but we know from experiments
+* that the setup time is more than 3000 picoseconds (3 ns).
+* If we have a bridge that requires the signal to be stable
+* earlier than 3000 ps before the clock pulse, we have to
+* output the data on the opposite edge to avoid flicker.
+*/
+ if (btimings && btimings->setup_time_ps >= 3000)
+ tim2 ^= TIM2_IPC;
+ }
tim2 |= cpl << 16;
writel(tim2, priv->regs + CLCD_TIM2);
diff --git a/drivers/gpu/drm/pl111/pl111_drv.c
b/drivers/gpu/drm/pl111/pl111_drv.c
index 201d57d5cb54..101a9c7db6ff 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -107,11 +107,17 @@ static int pl111_modeset_init(struct drm_device *dev)
ret = PTR_ERR(bridge);
goto out_config;
}
- /*
-* TODO: when we are using a different bridge than a panel
-* (such as a dumb VGA connector) we need to devise a different
-* method to get the connector out of the bridge.
-*/
+ } else if (bridge) {
+ dev_info(dev->dev, "Using non-panel bridge\n");
+ } else {
+ dev_err(dev->dev, "No bridge, exiting\n");
+ return -ENODEV;
+ }
+
+ priv->bridge = bridge;
+ if (panel) {
+ priv->panel = panel;
+ priv->connector = panel->connector;
}
ret = pl111_display_init(dev);
@@ -125,10 +131,6 @@ static int pl111_modeset_init(struct drm_device *dev)
[PATCH 1/4 v6] drm/bridge: Add bindings for TI THS8134
This adds device tree bindings for the Texas Instruments
THS8134, THS8134A and THS8134B VGA DACs by extending and
renaming the existing bindings for THS8135.
These DACs are used for the VGA outputs on the ARM reference
designs such as Integrator, Versatile and RealView.
Cc: devicet...@vger.kernel.org
Cc: Bartosz Golaszewski
Acked-by: Rob Herring
Reviewed-by: Laurent Pinchart
Signed-off-by: Linus Walleij
---
ChangeLog v5->v6:
- Fix the more-to-less specific compatible strings.
- Fix some speling.
- Collect Laurent's review tag.
ChangeLog v2->v5:
- Dropped the "ti,ths813x" as it turns out we need precise info
about the sub-variant anyways as they all very in timings.
- Refine the THS8134 variants, it turns out ths8134, ths8134a
and ths8134b are three different variants of ths8134.
ChangeLog v1->v2:
- Introduce specific-to-general compatible string:
compatible = "ti,ths8134a", "ti,ths813x";
so drivers can handle the whole family the same way.
- Collected Rob's ACK.
---
.../display/bridge/{ti,ths8135.txt => ti,ths813x.txt} | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
rename Documentation/devicetree/bindings/display/bridge/{ti,ths8135.txt =>
ti,ths813x.txt} (69%)
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
b/Documentation/devicetree/bindings/display/bridge/ti,ths813x.txt
similarity index 69%
rename from Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
rename to Documentation/devicetree/bindings/display/bridge/ti,ths813x.txt
index 6ec1a880ac18..df3d7c1ac09e 100644
--- a/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
+++ b/Documentation/devicetree/bindings/display/bridge/ti,ths813x.txt
@@ -1,11 +1,16 @@
-THS8135 Video DAC
--
+THS8134 and THS8135 Video DAC
+-
-This is the binding for Texas Instruments THS8135 Video DAC bridge.
+This is the binding for Texas Instruments THS8134, THS8134A, THS8134B and
+THS8135 Video DAC bridges.
Required properties:
-- compatible: Must be "ti,ths8135"
+- compatible: Must be one of
+ "ti,ths8134"
+ "ti,ths8134a," "ti,ths8134"
+ "ti,ths8134b", "ti,ths8134"
+ "ti,ths8135"
Required nodes:
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [PATCH] dma-buf: make returning the exclusive fence optional
On Wed, Jan 10, 2018 at 02:46:32PM +0100, Christian König wrote:
> Am 10.01.2018 um 14:21 schrieb Daniel Vetter:
> > On Wed, Jan 10, 2018 at 01:53:41PM +0100, Christian König wrote:
> > > Change reservation_object_get_fences_rcu to make the exclusive fence
> > > pointer optional.
> > >
> > > If not specified the exclusive fence is put into the fence array as
> > > well.
> > >
> > > This is helpful for a couple of cases where we need all fences in a
> > > single array.
> > >
> > > Signed-off-by: Christian König
> > Seeing the use-case for this would be a lot more interesting ...
>
> Yeah, sorry the use case is a 20 patches set on amd-gfx.
>
> Didn't wanted to post all those here as well.
Imo better to spam more lists instead of splitting up discussions ... It's
at least what we tend to do for i915 stuff, and no one seems to complain.
-Daniel
>
> Christian.
>
> > -Daniel
> >
> > > ---
> > > drivers/dma-buf/reservation.c | 31 ++-
> > > 1 file changed, 22 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
> > > index b759a569b7b8..461afa9febd4 100644
> > > --- a/drivers/dma-buf/reservation.c
> > > +++ b/drivers/dma-buf/reservation.c
> > > @@ -374,8 +374,9 @@ EXPORT_SYMBOL(reservation_object_copy_fences);
> > >* @pshared: the array of shared fence ptrs returned (array is
> > > krealloc'd to
> > >* the required size, and must be freed by caller)
> > >*
> > > - * RETURNS
> > > - * Zero or -errno
> > > + * Retrieve all fences from the reservation object. If the pointer for
> > > the
> > > + * exclusive fence is not specified the fence is put into the array of
> > > the
> > > + * shared fences as well. Returns either zero or -ENOMEM.
> > >*/
> > > int reservation_object_get_fences_rcu(struct reservation_object *obj,
> > > struct dma_fence **pfence_excl,
> > > @@ -389,8 +390,8 @@ int reservation_object_get_fences_rcu(struct
> > > reservation_object *obj,
> > > do {
> > > struct reservation_object_list *fobj;
> > > - unsigned seq;
> > > - unsigned int i;
> > > + unsigned int i, seq;
> > > + size_t sz = 0;
> > > shared_count = i = 0;
> > > @@ -402,9 +403,14 @@ int reservation_object_get_fences_rcu(struct
> > > reservation_object *obj,
> > > goto unlock;
> > > fobj = rcu_dereference(obj->fence);
> > > - if (fobj) {
> > > + if (fobj)
> > > + sz += sizeof(*shared) * fobj->shared_max;
> > > +
> > > + if (!pfence_excl && fence_excl)
> > > + sz += sizeof(*shared);
> > > +
> > > + if (sz) {
> > > struct dma_fence **nshared;
> > > - size_t sz = sizeof(*shared) * fobj->shared_max;
> > > nshared = krealloc(shared, sz,
> > > GFP_NOWAIT | __GFP_NOWARN);
> > > @@ -420,13 +426,19 @@ int reservation_object_get_fences_rcu(struct
> > > reservation_object *obj,
> > > break;
> > > }
> > > shared = nshared;
> > > - shared_count = fobj->shared_count;
> > > -
> > > + shared_count = fobj ? fobj->shared_count : 0;
> > > for (i = 0; i < shared_count; ++i) {
> > > shared[i] =
> > > rcu_dereference(fobj->shared[i]);
> > > if (!dma_fence_get_rcu(shared[i]))
> > > break;
> > > }
> > > +
> > > + if (!pfence_excl && fence_excl) {
> > > + shared[i] = fence_excl;
> > > + fence_excl = NULL;
> > > + ++i;
> > > + ++shared_count;
> > > + }
> > > }
> > > if (i != shared_count || read_seqcount_retry(&obj->seq,
> > > seq)) {
> > > @@ -448,7 +460,8 @@ int reservation_object_get_fences_rcu(struct
> > > reservation_object *obj,
> > > *pshared_count = shared_count;
> > > *pshared = shared;
> > > - *pfence_excl = fence_excl;
> > > + if (pfence_excl)
> > > + *pfence_excl = fence_excl;
> > > return ret;
> > > }
> > > --
> > > 2.14.1
> > >
> > > ___
> > > Linaro-mm-sig mailing list
> > > linaro-mm-...@lists.linaro.org
> > > https://lists.linaro.org/mailman/listinfo/linaro-mm-sig
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] libdrm: intel/Android.mk: Filter libdrm_intel library requirements on x86
On Tue, Jan 9, 2018 at 11:25 PM, John Stultz wrote: > When building AOSP after updating libdrm project to the > freedesktop/master branch, I've seen the following build errors: > > external/libdrm/intel/Android.mk: error: libdrm_intel This is only needed for i915 (not i965) now BTW. I'm not sure at what point we stop caring about i915. > (SHARED_LIBRARIES android-arm64) missing libpciaccess > (SHARED_LIBRARIES android-arm64) You can set > ALLOW_MISSING_DEPENDENCIES=true in your environment if this is > intentional, but that may defer real problems until later in the > build. > > Using ALLOW_MISSING_DEPENDENCIES=true when building allows > things to function properly, but is not ideal. > > So basically, while I'm not including the libdrm_intel package > into the build, just the fact that the Android.mk file references > libpciaccess which isn't a repo included in AOSP causes the build > failure. > > So it seems we need some sort of conditional filter in the > Android.mk to skip over it if we're not building for intel. > > This is my initial attempt at solving this. > > Feedback would be greatly appreciated! > > I note that in the AOSP version of libdrm, the reference to > libpciaccess has been removed. See: > > https://android.googlesource.com/platform/external/libdrm/+/f6a1130dffae8de9ddd0c379066daf1df27fc8af%5E%21/ > So I wonder if it make sense to instead remove this upstream as > well? Only if we drop i915. > > While this patch addresses upstream's Andorid.mk, I also notice > that the AOSP version of libdrm has converted to Android.bp files: > > https://android.googlesource.com/platform/external/libdrm/+/fa32e29a1fe81e5472aabc65d3aa25a5af5aec55%5E%21/ > and wonder if getting that conversion upstream would be a good > idea here? No, because we still support Android versions back to L. There's also some desire to get meson builds to work in Android build system so we don't have to support multiple build systems. > > Cc: Emil Velikov > Cc: Chad Versace > Cc: Marissa Wall > Cc: Sean Paul > Cc: Rob Herring > Cc: Dan Willemsen > Cc: Tomasz Figa > Signed-off-by: John Stultz > --- > intel/Android.mk | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/intel/Android.mk b/intel/Android.mk > index 5407ff3..d834692 100644 > --- a/intel/Android.mk > +++ b/intel/Android.mk > @@ -21,6 +21,7 @@ > # IN THE SOFTWARE. > # > > +ifeq ($(TARGET_ARCH), x86) This doesn't work for x86_64. i915 and 64-bit may not be a valid combination, not sure, but we do at least build test that. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [PATCH] dma-buf: make returning the exclusive fence optional
Am 10.01.2018 um 14:21 schrieb Daniel Vetter:
On Wed, Jan 10, 2018 at 01:53:41PM +0100, Christian König wrote:
Change reservation_object_get_fences_rcu to make the exclusive fence
pointer optional.
If not specified the exclusive fence is put into the fence array as
well.
This is helpful for a couple of cases where we need all fences in a
single array.
Signed-off-by: Christian König
Seeing the use-case for this would be a lot more interesting ...
Yeah, sorry the use case is a 20 patches set on amd-gfx.
Didn't wanted to post all those here as well.
Christian.
-Daniel
---
drivers/dma-buf/reservation.c | 31 ++-
1 file changed, 22 insertions(+), 9 deletions(-)
diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index b759a569b7b8..461afa9febd4 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -374,8 +374,9 @@ EXPORT_SYMBOL(reservation_object_copy_fences);
* @pshared: the array of shared fence ptrs returned (array is krealloc'd to
* the required size, and must be freed by caller)
*
- * RETURNS
- * Zero or -errno
+ * Retrieve all fences from the reservation object. If the pointer for the
+ * exclusive fence is not specified the fence is put into the array of the
+ * shared fences as well. Returns either zero or -ENOMEM.
*/
int reservation_object_get_fences_rcu(struct reservation_object *obj,
struct dma_fence **pfence_excl,
@@ -389,8 +390,8 @@ int reservation_object_get_fences_rcu(struct
reservation_object *obj,
do {
struct reservation_object_list *fobj;
- unsigned seq;
- unsigned int i;
+ unsigned int i, seq;
+ size_t sz = 0;
shared_count = i = 0;
@@ -402,9 +403,14 @@ int reservation_object_get_fences_rcu(struct reservation_object *obj,
goto unlock;
fobj = rcu_dereference(obj->fence);
- if (fobj) {
+ if (fobj)
+ sz += sizeof(*shared) * fobj->shared_max;
+
+ if (!pfence_excl && fence_excl)
+ sz += sizeof(*shared);
+
+ if (sz) {
struct dma_fence **nshared;
- size_t sz = sizeof(*shared) * fobj->shared_max;
nshared = krealloc(shared, sz,
GFP_NOWAIT | __GFP_NOWARN);
@@ -420,13 +426,19 @@ int reservation_object_get_fences_rcu(struct
reservation_object *obj,
break;
}
shared = nshared;
- shared_count = fobj->shared_count;
-
+ shared_count = fobj ? fobj->shared_count : 0;
for (i = 0; i < shared_count; ++i) {
shared[i] = rcu_dereference(fobj->shared[i]);
if (!dma_fence_get_rcu(shared[i]))
break;
}
+
+ if (!pfence_excl && fence_excl) {
+ shared[i] = fence_excl;
+ fence_excl = NULL;
+ ++i;
+ ++shared_count;
+ }
}
if (i != shared_count || read_seqcount_retry(&obj->seq, seq)) {
@@ -448,7 +460,8 @@ int reservation_object_get_fences_rcu(struct
reservation_object *obj,
*pshared_count = shared_count;
*pshared = shared;
- *pfence_excl = fence_excl;
+ if (pfence_excl)
+ *pfence_excl = fence_excl;
return ret;
}
--
2.14.1
___
Linaro-mm-sig mailing list
linaro-mm-...@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-mm-sig
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [PATCH] dma-buf: make returning the exclusive fence optional
On Wed, Jan 10, 2018 at 01:53:41PM +0100, Christian König wrote:
> Change reservation_object_get_fences_rcu to make the exclusive fence
> pointer optional.
>
> If not specified the exclusive fence is put into the fence array as
> well.
>
> This is helpful for a couple of cases where we need all fences in a
> single array.
>
> Signed-off-by: Christian König
Seeing the use-case for this would be a lot more interesting ...
-Daniel
> ---
> drivers/dma-buf/reservation.c | 31 ++-
> 1 file changed, 22 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
> index b759a569b7b8..461afa9febd4 100644
> --- a/drivers/dma-buf/reservation.c
> +++ b/drivers/dma-buf/reservation.c
> @@ -374,8 +374,9 @@ EXPORT_SYMBOL(reservation_object_copy_fences);
> * @pshared: the array of shared fence ptrs returned (array is krealloc'd to
> * the required size, and must be freed by caller)
> *
> - * RETURNS
> - * Zero or -errno
> + * Retrieve all fences from the reservation object. If the pointer for the
> + * exclusive fence is not specified the fence is put into the array of the
> + * shared fences as well. Returns either zero or -ENOMEM.
> */
> int reservation_object_get_fences_rcu(struct reservation_object *obj,
> struct dma_fence **pfence_excl,
> @@ -389,8 +390,8 @@ int reservation_object_get_fences_rcu(struct
> reservation_object *obj,
>
> do {
> struct reservation_object_list *fobj;
> - unsigned seq;
> - unsigned int i;
> + unsigned int i, seq;
> + size_t sz = 0;
>
> shared_count = i = 0;
>
> @@ -402,9 +403,14 @@ int reservation_object_get_fences_rcu(struct
> reservation_object *obj,
> goto unlock;
>
> fobj = rcu_dereference(obj->fence);
> - if (fobj) {
> + if (fobj)
> + sz += sizeof(*shared) * fobj->shared_max;
> +
> + if (!pfence_excl && fence_excl)
> + sz += sizeof(*shared);
> +
> + if (sz) {
> struct dma_fence **nshared;
> - size_t sz = sizeof(*shared) * fobj->shared_max;
>
> nshared = krealloc(shared, sz,
> GFP_NOWAIT | __GFP_NOWARN);
> @@ -420,13 +426,19 @@ int reservation_object_get_fences_rcu(struct
> reservation_object *obj,
> break;
> }
> shared = nshared;
> - shared_count = fobj->shared_count;
> -
> + shared_count = fobj ? fobj->shared_count : 0;
> for (i = 0; i < shared_count; ++i) {
> shared[i] = rcu_dereference(fobj->shared[i]);
> if (!dma_fence_get_rcu(shared[i]))
> break;
> }
> +
> + if (!pfence_excl && fence_excl) {
> + shared[i] = fence_excl;
> + fence_excl = NULL;
> + ++i;
> + ++shared_count;
> + }
> }
>
> if (i != shared_count || read_seqcount_retry(&obj->seq, seq)) {
> @@ -448,7 +460,8 @@ int reservation_object_get_fences_rcu(struct
> reservation_object *obj,
>
> *pshared_count = shared_count;
> *pshared = shared;
> - *pfence_excl = fence_excl;
> + if (pfence_excl)
> + *pfence_excl = fence_excl;
>
> return ret;
> }
> --
> 2.14.1
>
> ___
> Linaro-mm-sig mailing list
> linaro-mm-...@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/linaro-mm-sig
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 7/8] drm: Check that the plane supports the request format+modifier combo
On Fri, Dec 22, 2017 at 09:22:30PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Currently we only check that the plane supports the pixel format of the
> fb we're about to feed to it. Extend it to check also the modifier, and
> more specifically that the combination of the format and modifier is
> supported.
>
> Cc: dri-devel@lists.freedesktop.org
> Cc: Ben Widawsky
> Cc: Jason Ekstrand
> Cc: Daniel Stone
> Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_atomic.c| 10 ++
> drivers/gpu/drm/drm_crtc.c | 10 ++
> drivers/gpu/drm/drm_crtc_internal.h | 4 ++--
> drivers/gpu/drm/drm_plane.c | 33 ++---
> 4 files changed, 40 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index b76d49218cf1..6e5c3ea1e43b 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -882,12 +882,14 @@ static int drm_atomic_plane_check(struct drm_plane
> *plane,
> }
>
> /* Check whether this plane supports the fb pixel format. */
> - ret = drm_plane_check_pixel_format(plane, state->fb->format->format);
> + ret = drm_plane_check_pixel_format(plane, state->fb->format->format,
> +state->fb->modifier);
> if (ret) {
> struct drm_format_name_buf format_name;
> - DRM_DEBUG_ATOMIC("Invalid pixel format %s\n",
> - drm_get_format_name(state->fb->format->format,
> - &format_name));
> + DRM_DEBUG_ATOMIC("Invalid pixel format %s, modifier 0x%llx\n",
> + drm_get_format_name(state->fb->format->format,
> + &format_name),
> + state->fb->modifier);
> return ret;
> }
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index f0556e654116..816c30a0f030 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -625,12 +625,14 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
>*/
> if (!crtc->primary->format_default) {
> ret = drm_plane_check_pixel_format(crtc->primary,
> -fb->format->format);
> +fb->format->format,
> +fb->modifier);
> if (ret) {
> struct drm_format_name_buf format_name;
> - DRM_DEBUG_KMS("Invalid pixel format %s\n",
> -
> drm_get_format_name(fb->format->format,
> -
> &format_name));
> + DRM_DEBUG_KMS("Invalid pixel format %s,
> modifier 0x%llx\n",
> +
> drm_get_format_name(fb->format->format,
> + &format_name),
> + fb->modifier);
> goto out;
> }
> }
> diff --git a/drivers/gpu/drm/drm_crtc_internal.h
> b/drivers/gpu/drm/drm_crtc_internal.h
> index af00f42ba269..860968a64ae7 100644
> --- a/drivers/gpu/drm/drm_crtc_internal.h
> +++ b/drivers/gpu/drm/drm_crtc_internal.h
> @@ -196,8 +196,8 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> /* drm_plane.c */
> int drm_plane_register_all(struct drm_device *dev);
> void drm_plane_unregister_all(struct drm_device *dev);
> -int drm_plane_check_pixel_format(const struct drm_plane *plane,
> - u32 format);
> +int drm_plane_check_pixel_format(struct drm_plane *plane,
> + u32 format, u64 modifier);
>
> /* drm_bridge.c */
> void drm_bridge_detach(struct drm_bridge *bridge);
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 2c90519576a3..8ac19379fe99 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -545,16 +545,33 @@ int drm_mode_getplane(struct drm_device *dev, void
> *data,
> return 0;
> }
>
> -int drm_plane_check_pixel_format(const struct drm_plane *plane, u32 format)
> +int drm_plane_check_pixel_format(struct drm_plane *plane,
> + u32 format, u64 modifier)
> {
> unsigned int i;
>
> for (i = 0; i < plane->format_count; i++) {
> if (format == plane->format_types[i])
> - return 0;
> + break;
> + }
> + if (i == plane->format_count)
> + return -EINVAL;
> +
> + if (!plane->modifier_count)
> + return 0;
> +
> + for (i =
[PATCH] dma-buf: make returning the exclusive fence optional
Change reservation_object_get_fences_rcu to make the exclusive fence
pointer optional.
If not specified the exclusive fence is put into the fence array as
well.
This is helpful for a couple of cases where we need all fences in a
single array.
Signed-off-by: Christian König
---
drivers/dma-buf/reservation.c | 31 ++-
1 file changed, 22 insertions(+), 9 deletions(-)
diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index b759a569b7b8..461afa9febd4 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -374,8 +374,9 @@ EXPORT_SYMBOL(reservation_object_copy_fences);
* @pshared: the array of shared fence ptrs returned (array is krealloc'd to
* the required size, and must be freed by caller)
*
- * RETURNS
- * Zero or -errno
+ * Retrieve all fences from the reservation object. If the pointer for the
+ * exclusive fence is not specified the fence is put into the array of the
+ * shared fences as well. Returns either zero or -ENOMEM.
*/
int reservation_object_get_fences_rcu(struct reservation_object *obj,
struct dma_fence **pfence_excl,
@@ -389,8 +390,8 @@ int reservation_object_get_fences_rcu(struct
reservation_object *obj,
do {
struct reservation_object_list *fobj;
- unsigned seq;
- unsigned int i;
+ unsigned int i, seq;
+ size_t sz = 0;
shared_count = i = 0;
@@ -402,9 +403,14 @@ int reservation_object_get_fences_rcu(struct
reservation_object *obj,
goto unlock;
fobj = rcu_dereference(obj->fence);
- if (fobj) {
+ if (fobj)
+ sz += sizeof(*shared) * fobj->shared_max;
+
+ if (!pfence_excl && fence_excl)
+ sz += sizeof(*shared);
+
+ if (sz) {
struct dma_fence **nshared;
- size_t sz = sizeof(*shared) * fobj->shared_max;
nshared = krealloc(shared, sz,
GFP_NOWAIT | __GFP_NOWARN);
@@ -420,13 +426,19 @@ int reservation_object_get_fences_rcu(struct
reservation_object *obj,
break;
}
shared = nshared;
- shared_count = fobj->shared_count;
-
+ shared_count = fobj ? fobj->shared_count : 0;
for (i = 0; i < shared_count; ++i) {
shared[i] = rcu_dereference(fobj->shared[i]);
if (!dma_fence_get_rcu(shared[i]))
break;
}
+
+ if (!pfence_excl && fence_excl) {
+ shared[i] = fence_excl;
+ fence_excl = NULL;
+ ++i;
+ ++shared_count;
+ }
}
if (i != shared_count || read_seqcount_retry(&obj->seq, seq)) {
@@ -448,7 +460,8 @@ int reservation_object_get_fences_rcu(struct
reservation_object *obj,
*pshared_count = shared_count;
*pshared = shared;
- *pfence_excl = fence_excl;
+ if (pfence_excl)
+ *pfence_excl = fence_excl;
return ret;
}
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH] drm/nouveau/bar/gk20a: Avoid bar teardown during init
On Thu, Jan 04, 2018 at 11:29:09AM +, Jon Hunter wrote:
> Commit bbb163e18960 ("drm/nouveau/bar: implement bar1 teardown")
> introduced add a teardown helper function for BAR1. During
> initialisation of the Nouveau, initially all the teardown helpers are
> called once, before calling their init counterparts. For gk20a, after
> the BAR1 teardown function is called, the device is hanging during the
> initialisation of the FB sub-device. At this point it is unclear why
> this is happening and this is still under investigation. However, this
> change is preventing Tegra124 devices from booting when Nouveau is
> enabled. To allow Tegra124 to boot, remove the teardown helper for
> gk20a.
>
> This is based upon a previous patch by Guillaume Tucker but limits
> the workaround to only gk20a GPUs.
>
> Fixes: bbb163e18960 ("drm/nouveau/bar: implement bar1 teardown")
> Reported-by: Guillaume Tucker
> Signed-off-by: Jon Hunter
> ---
> I am not happy that we do not yet fully understand the cause of
> the hang, but I am talking with a few people at NVIDIA about this
> and have a few things to look into. However, given that we are
> close to v4.15 being released and I am not sure we will have a
> proper fix in place before, I think it is best to workaround
> this for now.
>
> drivers/gpu/drm/nouveau/nvkm/subdev/bar/base.c | 3 ++-
> drivers/gpu/drm/nouveau/nvkm/subdev/bar/gk20a.c | 1 -
> 2 files changed, 2 insertions(+), 2 deletions(-)
Acked-by: Thierry Reding
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Bug 198123] Console is the wrong color at boot with radeon 6670
On Sun, Jan 07, 2018 at 07:14:41PM +, Deposite Pirate wrote:
> December 22, 2017 4:35 PM, "Michel Dänzer" wrote:
>
> > "Deposite Pirate", do the attached (only compile tested) patches work?
>
> Hi,
>
> Sorry for the delay. I was not at home for a while. So, I've compiled and
> booted a kernel with both
> of these patches and
> the issue is still present.
Below a revised version of Michel's first patch. This one should work I
hope.
-Daniel
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index d22f4b6a8828..dc0abdf8be00 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -213,9 +213,6 @@ void radeon_crtc_load_lut(struct drm_crtc *crtc)
struct drm_device *dev = crtc->dev;
struct radeon_device *rdev = dev->dev_private;
- if (!crtc->enabled)
- return;
-
if (ASIC_IS_DCE5(rdev))
dce5_crtc_load_lut(crtc);
else if (ASIC_IS_DCE4(rdev))
@@ -702,6 +699,8 @@ static void radeon_crtc_init(struct drm_device *dev, int
index)
radeon_atombios_init_crtc(dev, radeon_crtc);
else
radeon_legacy_init_crtc(dev, radeon_crtc);
+
+ radeon_crtc_load_lut(&radeon_crtc->base);
}
static const char *encoder_names[38] = {
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 1/1] drm/tegra: sor: Fix hang on tegra124 due to NULL clk_out
On Tue, Jan 02, 2018 at 06:32:11PM +, Jon Hunter wrote:
>
> On 20/12/17 18:15, Thierry Reding wrote:
> > On Wed, Dec 20, 2017 at 11:32:23AM +, Guillaume Tucker wrote:
> >> When neither HDMI nor DP is supported such as on the tegra124, the
> >> sor->clk_out is not initialised and remains NULL. In this case, the
> >> parent clock can't be assigned to it so revert to the previous
> >> behaviour of assigning it to the main sor->clk instead.
> >>
> >> This fixes a kernel hang on tegra124 and should also affect tegra210
> >> as they both don't support HDMI and DP. Tested on tegra124 only.
> >>
> >> Fixes: e1335e2f0cfc ("drm/tegra: sor: Reimplement pad clock")
> >> Signed-off-by: Guillaume Tucker
> >> CC: Thierry Reding
> >> ---
> >> drivers/gpu/drm/tegra/sor.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > How about just the below instead? It's one more line than your patch,
> > but it will automatically handle all occurrences of clk_out properly.
> >
> > --- >8 ---
> > diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
> > index f6313c4d612e..4be9edf9c6fe 100644
> > --- a/drivers/gpu/drm/tegra/sor.c
> > +++ b/drivers/gpu/drm/tegra/sor.c
> > @@ -3047,6 +3047,8 @@ static int tegra_sor_probe(struct platform_device
> > *pdev)
> > name, err);
> > goto remove;
> > }
> > + } else {
> > + sor->clk_out = sor->clk;
> > }
> >
> > sor->clk_parent = devm_clk_get(&pdev->dev, "parent");
> > --- >8 ---
> >
> > That said, I suspect the SOR might be compatible from a clock point of
> > view with later versions and perhaps we just didn't implement clocks
> > correctly back in the Tegra124 timeframe.
> >
> > Maybe Peter knows.
>
> So the above change from Thierry works for me and we need this for v4.15
> (otherwise nyan-big does not boot) so you can have my ...
>
> Tested-by: Jon Hunter
>
> However, would be good to have Peter's ACK, especially seeing that
> Tegra210 sor0 does not support HDMI and DP. So we need to make sure this
> is correct for Tegra210 as well (although I have not seen any
> regressions for Tegra210).
There are no Tegra210 boards with eDP or LVDS support, which are the
only setups that are impacted by this.
I've sent out the above as a proper patch. I'll submit this for a late
fixes pull request.
Thierry
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/tegra: sor: Fix hang on Tegra124 eDP
From: Thierry Reding
The SOR0 found on Tegra124 and Tegra210 only supports eDP and LVDS and
therefore has a slightly different clock tree than the SOR1 which does
not support eDP, but HDMI and DP instead.
Commit e1335e2f0cfc ("drm/tegra: sor: Reimplement pad clock") breaks
setups with eDP because the sor->clk_out clock is uninitialized and
therefore setting the parent clock (either the safe clock or either of
the display PLLs) fails, which can cause hangs later on since there is
no clock driving the module.
Fix this by falling back to the module clock for sor->clk_out on those
setups. This guarantees that the module will always be clocked by an
enabled clock and hence prevents those hangs.
Fixes: e1335e2f0cfc ("drm/tegra: sor: Reimplement pad clock")
Reported-by: Guillaume Tucker
Tested-by: Jon Hunter
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/sor.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index b0a1dedac802..476079f1255f 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -2656,6 +2656,9 @@ static int tegra_sor_probe(struct platform_device *pdev)
name, err);
goto remove;
}
+ } else {
+ /* fall back to the module clock on SOR0 (eDP/LVDS only) */
+ sor->clk_out = sor->clk;
}
sor->clk_parent = devm_clk_get(&pdev->dev, "parent");
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits, v2.
From: "Leo (Sunpeng) Li"
During a non-blocking commit, it is possible to return before the
commit_tail work is queued (-ERESTARTSYS, for example).
Since a reference on the crtc commit object is obtained for the pending
vblank event when preparing the commit, the above situation will leave
us with an extra reference.
Therefore, if the commit_tail worker has not consumed the event at the
end of a commit, release it's reference.
Changes since v1:
- Also check for state->event->base.completion being set, to
handle the case where stall_checks() fails in setup_crtc_commit().
Fixes: 24835e442f28 ("drm: reference count event->completion")
Cc: # v4.11+
Signed-off-by: Leo (Sunpeng) Li
Acked-by: Harry Wentland #v1
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index b16f1d69a0bb..1d43f3e85a7d 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3327,6 +3327,15 @@ EXPORT_SYMBOL(drm_atomic_helper_crtc_duplicate_state);
void __drm_atomic_helper_crtc_destroy_state(struct drm_crtc_state *state)
{
if (state->commit) {
+ /*
+* In the event that a non-blocking commit returns
+* -ERESTARTSYS before the commit_tail work is queued, we will
+* have an extra reference to the commit object. Release it, if
+* the event has not been consumed by the worker.
+*/
+ if (state->event && state->event->base.completion)
+ drm_crtc_commit_put(state->commit);
+
kfree(state->commit->event);
state->commit->event = NULL;
drm_crtc_commit_put(state->commit);
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] radeon: completely remove lut leftovers
On 2018-01-10 09:18 AM, Daniel Vetter wrote:
> This is an oversight from
>
> commit 42585395ebc1034a98937702849669f17eadb35f
> Author: Peter Rosin
> Date: Thu Jul 13 18:25:36 2017 +0200
>
> drm: radeon: remove dead code and pointless local lut storage
>
> Cc: Peter Rosin
> Cc: Alex Deucher
> Cc: Michel Dänzer
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/radeon/radeon_display.c | 6 --
> drivers/gpu/drm/radeon/radeon_mode.h| 1 -
> 2 files changed, 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c
> b/drivers/gpu/drm/radeon/radeon_display.c
> index dfda5e0ed166..d22f4b6a8828 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -698,12 +698,6 @@ static void radeon_crtc_init(struct drm_device *dev, int
> index)
> radeon_crtc->mode_set.num_connectors = 0;
> #endif
>
> - for (i = 0; i < 256; i++) {
> - radeon_crtc->lut_r[i] = i << 2;
> - radeon_crtc->lut_g[i] = i << 2;
> - radeon_crtc->lut_b[i] = i << 2;
> - }
> -
> if (rdev->is_atom_bios && (ASIC_IS_AVIVO(rdev) || radeon_r4xx_atom))
> radeon_atombios_init_crtc(dev, radeon_crtc);
> else
> diff --git a/drivers/gpu/drm/radeon/radeon_mode.h
> b/drivers/gpu/drm/radeon/radeon_mode.h
> index 3243e5e01432..5f61facafe36 100644
> --- a/drivers/gpu/drm/radeon/radeon_mode.h
> +++ b/drivers/gpu/drm/radeon/radeon_mode.h
> @@ -328,7 +328,6 @@ enum radeon_flip_status {
> struct radeon_crtc {
> struct drm_crtc base;
> int crtc_id;
> - u16 lut_r[256], lut_g[256], lut_b[256];
> bool enabled;
> bool can_tile;
> bool cursor_out_of_bounds;
>
I posted a more complete patch (also removing the now unused local i)
for this in
https://lists.freedesktop.org/archives/dri-devel/2017-December/161116.html
. I'd like to only apply this once the problem discussed in that thread
is fixed though, but unfortunately the other patch I attached there
doesn't seem to fix it. What's the current plan for fixing this issue?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 4/8] drm/rockchip: dw-mipi-dsi: Fix error handling path
On 01/09/2018 08:18 PM, Thierry Escande wrote:
From: Jeffy Chen
Add missing pm_runtime_disable() in bind()'s error handling path.
Also cleanup encoder & connector in unbind().
I guess you'll need to drop this commit if this patch goes in first:
https://patchwork.kernel.org/patch/10106105/
Thanks,
Archit
Fixes: 80a9a059d4e4 ("drm/rockchip/dsi: add dw-mipi power domain support")
Signed-off-by: Jeffy Chen
Signed-off-by: Thierry Escande
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index b1fe0639227e..78e6b7919bf7 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -1282,7 +1282,7 @@ static int dw_mipi_dsi_bind(struct device *dev, struct
device *master,
ret = dw_mipi_dsi_register(drm, dsi);
if (ret) {
DRM_DEV_ERROR(dev, "Failed to register mipi_dsi: %d\n", ret);
- goto err_pllref;
+ goto err_disable_pllref;
}
dsi->dsi_host.ops = &dw_mipi_dsi_host_ops;
@@ -1290,24 +1290,25 @@ static int dw_mipi_dsi_bind(struct device *dev, struct
device *master,
ret = mipi_dsi_host_register(&dsi->dsi_host);
if (ret) {
DRM_DEV_ERROR(dev, "Failed to register MIPI host: %d\n", ret);
- goto err_cleanup;
+ goto err_disable_pm_runtime;
}
if (!dsi->panel) {
ret = -EPROBE_DEFER;
- goto err_mipi_dsi_host;
+ goto err_unreg_mipi_dsi_host;
}
dev_set_drvdata(dev, dsi);
pm_runtime_enable(dev);
return 0;
-err_mipi_dsi_host:
+err_unreg_mipi_dsi_host:
mipi_dsi_host_unregister(&dsi->dsi_host);
-err_cleanup:
- drm_encoder_cleanup(&dsi->encoder);
- drm_connector_cleanup(&dsi->connector);
-err_pllref:
+err_disable_pm_runtime:
+ pm_runtime_disable(dev);
+ dsi->connector.funcs->destroy(&dsi->connector);
+ dsi->encoder.funcs->destroy(&dsi->encoder);
+err_disable_pllref:
clk_disable_unprepare(dsi->pllref_clk);
return ret;
}
@@ -1319,6 +1320,10 @@ static void dw_mipi_dsi_unbind(struct device *dev,
struct device *master,
mipi_dsi_host_unregister(&dsi->dsi_host);
pm_runtime_disable(dev);
+
+ dsi->connector.funcs->destroy(&dsi->connector);
+ dsi->encoder.funcs->destroy(&dsi->encoder);
+
clk_disable_unprepare(dsi->pllref_clk);
}
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 3/3] drm/rockchip: Add ROCKCHIP DW MIPI DSI controller driver
On 12/12/2017 06:40 AM, Nickey Yang wrote: Add the ROCKCHIP DSI controller driver that uses the Synopsys DesignWare MIPI DSI host controller bridge. Reviewed-by: Archit Taneja Signed-off-by: Nickey Yang Signed-off-by: Brian Norris Reviewed-by: Brian Norris Reviewed-by: Sean Paul --- changes: v2: add err_pllref, remove unnecessary encoder.enable & disable correct spelling mistakes v3: call dw_mipi_dsi_unbind() in dw_mipi_dsi_rockchip_unbind() fix typo, use of_device_get_match_data(), change some ‘bind()’ logic into 'probe()' add 'dev_set_drvdata()' v4: return -EINVAL when can not get best_freq add a clarifying comment when get vco add review tag v5: keep our power domain enabled while touching GRF v6: change func name dw_mipi_encoder_disable to dw_mipi_dsi_encoder_disable drivers/gpu/drm/rockchip/Kconfig|2 +- drivers/gpu/drm/rockchip/Makefile |2 +- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 1349 --- drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c | 785 + drivers/gpu/drm/rockchip/rockchip_drm_drv.c |2 +- drivers/gpu/drm/rockchip/rockchip_drm_drv.h |2 +- 6 files changed, 789 insertions(+), 1353 deletions(-) delete mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi.c create mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig index 0ccc762..9eb4795 100644 --- a/drivers/gpu/drm/rockchip/Kconfig +++ b/drivers/gpu/drm/rockchip/Kconfig @@ -7,7 +7,7 @@ config DRM_ROCKCHIP select VIDEOMODE_HELPERS select DRM_ANALOGIX_DP if ROCKCHIP_ANALOGIX_DP select DRM_DW_HDMI if ROCKCHIP_DW_HDMI - select DRM_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI + select DRM_DW_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI select SND_SOC_HDMI_CODEC if ROCKCHIP_CDN_DP && SND_SOC help Choose this option if you have a Rockchip soc chipset. diff --git a/drivers/gpu/drm/rockchip/Makefile b/drivers/gpu/drm/rockchip/Makefile index a314e21..c05fe47 100644 --- a/drivers/gpu/drm/rockchip/Makefile +++ b/drivers/gpu/drm/rockchip/Makefile @@ -11,7 +11,7 @@ rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o -rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o +rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi_rockchip.o rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o rockchipdrm-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c deleted file mode 100644 index b15755b..000 --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c +++ /dev/null @@ -1,1349 +0,0 @@ -/* - * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - */ -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -#include "rockchip_drm_drv.h" -#include "rockchip_drm_vop.h" - -#define DRIVER_NAME"dw-mipi-dsi" - -#define RK3288_GRF_SOC_CON60x025c -#define RK3288_DSI0_SEL_VOP_LITBIT(6) -#define RK3288_DSI1_SEL_VOP_LITBIT(9) - -#define RK3399_GRF_SOC_CON20 0x6250 -#define RK3399_DSI0_SEL_VOP_LITBIT(0) -#define RK3399_DSI1_SEL_VOP_LITBIT(4) - -/* disable turnrequest, turndisable, forcetxstopmode, forcerxmode */ -#define RK3399_GRF_SOC_CON22 0x6258 -#define RK3399_GRF_DSI_MODE0x - -#define DSI_VERSION0x00 -#define DSI_PWR_UP 0x04 -#define RESET 0 -#define POWERUPBIT(0) - -#define DSI_CLKMGR_CFG 0x08 -#define TO_CLK_DIVIDSION(div) (((div) & 0xff) << 8) -#define TX_ESC_CLK_DIVIDSION(div) (((div) & 0xff) << 0) - -#define DSI_DPI_VCID 0x0c -#define DPI_VID(vid) (((vid) & 0x3) << 0) - -#define DSI_DPI_COLOR_CODING 0x10 -#define EN18_LOOSELY BIT(8) -#define DPI_COLOR_CODING_16BIT_1 0x0 -#define DPI_COLOR_CODING_16BIT_2 0x1 -#define DPI_COLOR_CODING_16BIT_3 0x2 -#define DPI_COLOR_CODING_18BIT_1 0x3 -#define DPI_COLOR_CODING_18BIT_2 0x4 -#define DPI_COLOR_CODING_24BIT 0x5 - -#define DSI_DPI_CFG_POL0x14 -#define COLORM_ACT
Re: [PATCH v7 00/10] rockchip: kevin: Enable edp display
On 01/09/2018 08:18 PM, Thierry Escande wrote: Hi, This patchset makes edp display work on Chromebook kevin. This patchset has been originally posted by Jeffy Chen and the 2 first commits from the previous version (v6) are already merged in mainline. This v7 has been rebased on top of next-20180108 and a few conflicts have been fixed as well. v7: Rebased on top of next-20180108 and fixed conflicts Fixed a few warnings reported by checkpatch Jeffy Chen (10): arm64: dts: rockchip: Enable edp disaplay on kevin drm/rockchip: analogix_dp: Remove unnecessary init code drm/bridge: analogix: Do not use device's drvdata drm/bridge: analogix_dp: Fix connector and encoder cleanup drm/rockchip: analogix_dp: Add a sanity check for rockchip_drm_psr_register() drm/rockchip: dw-mipi-dsi: Fix error handling path drm/rockchip: inno_hdmi: Fix error handling path drm/bridge/synopsys: dw-hdmi: Add missing bridge detach drm/bridge/synopsys: dw-hdmi: Do not use device's drvdata drm/rockchip: dw_hdmi: Fix error handling path I think all the bridge related patches (#s 1, 2, 6 and 7)have been reviewed. I tried to build a kernel with just the 4 of these, and I get a build error with patch #7 (drm/bridge/synopsys: dw-hdmi: Do not use device's drvdata). Applying patch #8 (drm/rockchip: dw_hdmi: Fix error handling path) fixes this. Could you make these 2 patches independent of each other so that the kernel builds successfully after each commit? I don't know if the rest of the rockchip patches in the series depend on the 4 bridge patches. If they do, the rockchip maintainer can queue both rockchip and bridge patches. If not, I can pick up the bridge patches. Thanks, Archit arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 29 +++ arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 16 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 52 +--- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 53 ++-- drivers/gpu/drm/exynos/exynos_dp.c | 29 --- drivers/gpu/drm/imx/dw_hdmi-imx.c | 22 +++-- drivers/gpu/drm/meson/meson_dw_hdmi.c | 20 +++-- drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 14 +++- drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 95 +++--- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 21 +++-- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c| 39 + drivers/gpu/drm/rockchip/inno_hdmi.c | 22 +++-- include/drm/bridge/analogix_dp.h | 19 +++-- include/drm/bridge/dw_hdmi.h | 17 ++-- 14 files changed, 265 insertions(+), 183 deletions(-) -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits
Op 08-01-18 om 22:30 schreef Harry Wentland: > On 2018-01-04 02:47 PM, sunpeng...@amd.com wrote: >> From: "Leo (Sunpeng) Li" >> >> During a non-blocking commit, it is possible to return before the >> commit_tail work is queued (-ERESTARTSYS, for example). >> >> Since a reference on the crtc commit object is obtained for the pending >> vblank event when preparing the commit, the above situation will leave >> us with an extra reference. >> >> Therefore, if the commit_tail worker has not consumed the event at the >> end of a commit, release it's reference. >> >> Signed-off-by: Leo (Sunpeng) Li > No expert on this but looks sane to me. > > Acked-by: Harry Wentland > > Harry Hey, I've reverted the patch for now. I planned to apply it to the drm-misc-fixes branch with the appropriate commits referenced, but it is causing crashes on the kms_flip testcase. https://bugs.freedesktop.org/show_bug.cgi?id=104566 I'll investigate it some more then send out a fixed patch. :) ~Maarten ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vmwgfx: Potential off by one in vmw_view_add()
The vmw_view_cmd_to_type() function returns vmw_view_max (3) on error.
It's one element beyond the end of the vmw_view_cotables[] table.
My read on this is that it's possible to hit this failure. header->id
comes from vmw_cmd_check() and it's a user controlled number between
1040 and 1225 so we can hit that error. But I don't have the hardware
to test this code.
Fixes: d80efd5cb3de ("drm/vmwgfx: Initial DX support")
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index b700667f6f0b..c9d5cc237124 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -2731,6 +2731,8 @@ static int vmw_cmd_dx_view_define(struct vmw_private
*dev_priv,
}
view_type = vmw_view_cmd_to_type(header->id);
+ if (view_type == vmw_view_max)
+ return -EINVAL;
cmd = container_of(header, typeof(*cmd), header);
ret = vmw_cmd_res_check(dev_priv, sw_context, vmw_res_surface,
user_surface_converter,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 7/8] drm/bridge/synopsys: dw-hdmi: Do not use device's drvdata
On 01/09/2018 08:18 PM, Thierry Escande wrote:
From: Jeffy Chen
Let plat drivers own the drvdata, so that they could cleanup resources
in their unbind().
Signed-off-by: Jeffy Chen
Signed-off-by: Thierry Escande
Reviewed-by: Neil Armstrong
Reviewed-by: Archit Taneja
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 43 ++---
drivers/gpu/drm/imx/dw_hdmi-imx.c | 22 +--
drivers/gpu/drm/meson/meson_dw_hdmi.c | 20 ++
drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 14 --
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 23 ---
include/drm/bridge/dw_hdmi.h| 17 ++--
6 files changed, 77 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 1cc63a18b7d5..f0380bcae513 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2073,7 +2073,7 @@ static irqreturn_t dw_hdmi_hardirq(int irq, void *dev_id)
return ret;
}
-void __dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense)
+void dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense)
{
mutex_lock(&hdmi->mutex);
@@ -2099,13 +2099,6 @@ void __dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense)
}
mutex_unlock(&hdmi->mutex);
}
-
-void dw_hdmi_setup_rx_sense(struct device *dev, bool hpd, bool rx_sense)
-{
- struct dw_hdmi *hdmi = dev_get_drvdata(dev);
-
- __dw_hdmi_setup_rx_sense(hdmi, hpd, rx_sense);
-}
EXPORT_SYMBOL_GPL(dw_hdmi_setup_rx_sense);
static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
@@ -2141,9 +2134,8 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
*/
if (intr_stat &
(HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD)) {
- __dw_hdmi_setup_rx_sense(hdmi,
-phy_stat & HDMI_PHY_HPD,
-phy_stat & HDMI_PHY_RX_SENSE);
+ dw_hdmi_setup_rx_sense(hdmi, phy_stat & HDMI_PHY_HPD,
+ phy_stat & HDMI_PHY_RX_SENSE);
if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0)
cec_notifier_set_phys_addr(hdmi->cec_notifier,
@@ -2533,8 +2525,6 @@ __dw_hdmi_probe(struct platform_device *pdev,
if (hdmi->i2c)
dw_hdmi_i2c_init(hdmi);
- platform_set_drvdata(pdev, hdmi);
-
return hdmi;
err_iahb:
@@ -2584,25 +2574,23 @@ static void __dw_hdmi_remove(struct dw_hdmi *hdmi)
/*
-
* Probe/remove API, used from platforms based on the DRM bridge API.
*/
-int dw_hdmi_probe(struct platform_device *pdev,
- const struct dw_hdmi_plat_data *plat_data)
+struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
+ const struct dw_hdmi_plat_data *plat_data)
{
struct dw_hdmi *hdmi;
hdmi = __dw_hdmi_probe(pdev, plat_data);
if (IS_ERR(hdmi))
- return PTR_ERR(hdmi);
+ return hdmi;
drm_bridge_add(&hdmi->bridge);
- return 0;
+ return hdmi;
}
EXPORT_SYMBOL_GPL(dw_hdmi_probe);
-void dw_hdmi_remove(struct platform_device *pdev)
+void dw_hdmi_remove(struct dw_hdmi *hdmi)
{
- struct dw_hdmi *hdmi = platform_get_drvdata(pdev);
-
drm_bridge_remove(&hdmi->bridge);
__dw_hdmi_remove(hdmi);
@@ -2612,31 +2600,30 @@ EXPORT_SYMBOL_GPL(dw_hdmi_remove);
/*
-
* Bind/unbind API, used from platforms based on the component framework.
*/
-int dw_hdmi_bind(struct platform_device *pdev, struct drm_encoder *encoder,
-const struct dw_hdmi_plat_data *plat_data)
+struct dw_hdmi *dw_hdmi_bind(struct platform_device *pdev,
+struct drm_encoder *encoder,
+const struct dw_hdmi_plat_data *plat_data)
{
struct dw_hdmi *hdmi;
int ret;
hdmi = __dw_hdmi_probe(pdev, plat_data);
if (IS_ERR(hdmi))
- return PTR_ERR(hdmi);
+ return hdmi;
ret = drm_bridge_attach(encoder, &hdmi->bridge, NULL);
if (ret) {
__dw_hdmi_remove(hdmi);
DRM_ERROR("Failed to initialize bridge with drm\n");
- return ret;
+ return ERR_PTR(ret);
}
- return 0;
+ return hdmi;
}
EXPORT_SYMBOL_GPL(dw_hdmi_bind);
-void dw_hdmi_unbind(struct device *dev)
+void dw_hdmi_unbind(struct dw_hdmi *hdmi)
{
- struct dw_hdmi *hdmi = dev_get_drvdata(dev);
-
__dw_hdmi_remove(hdmi);
}
EXPORT_SYMBOL_GPL(dw_hdmi_unbind);
diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index b62763aa8706.
Re: [PATCH] drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits
On Tue, Jan 09, 2018 at 01:13:33PM -0500, Alex Deucher wrote:
> On Mon, Jan 8, 2018 at 4:30 PM, Harry Wentland wrote:
> > On 2018-01-04 02:47 PM, sunpeng...@amd.com wrote:
> >> From: "Leo (Sunpeng) Li"
> >>
> >> During a non-blocking commit, it is possible to return before the
> >> commit_tail work is queued (-ERESTARTSYS, for example).
> >>
> >> Since a reference on the crtc commit object is obtained for the pending
> >> vblank event when preparing the commit, the above situation will leave
> >> us with an extra reference.
> >>
> >> Therefore, if the commit_tail worker has not consumed the event at the
> >> end of a commit, release it's reference.
> >>
> >> Signed-off-by: Leo (Sunpeng) Li
> >
> > No expert on this but looks sane to me.
> >
> > Acked-by: Harry Wentland
>
>
> Pushed to drm-misc-next.
This blows up all over the place in our CI:
https://bugs.freedesktop.org/show_bug.cgi?id=104566
I think as a leak fix it should also be pushed to -fixes. And we didn't
really figure out what's wrong, so we're going with the quick revert until
you folks are all awake.
Cheers, Daniel
>
> Thanks,
>
> Alex
>
> >
> > Harry
> >
> >> ---
> >> drivers/gpu/drm/drm_atomic_helper.c | 9 +
> >> 1 file changed, 9 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> >> b/drivers/gpu/drm/drm_atomic_helper.c
> >> index ab40321..4253f57 100644
> >> --- a/drivers/gpu/drm/drm_atomic_helper.c
> >> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >> @@ -3421,6 +3421,15 @@
> >> EXPORT_SYMBOL(drm_atomic_helper_crtc_duplicate_state);
> >> void __drm_atomic_helper_crtc_destroy_state(struct drm_crtc_state *state)
> >> {
> >> if (state->commit) {
> >> + /*
> >> + * In the event that a non-blocking commit returns
> >> + * -ERESTARTSYS before the commit_tail work is queued, we
> >> will
> >> + * have an extra reference to the commit object. Release it,
> >> if
> >> + * the event has not been consumed by the worker.
> >> + */
> >> + if (state->event)
> >> + drm_crtc_commit_put(state->commit);
> >> +
> >> kfree(state->commit->event);
> >> state->commit->event = NULL;
> >> drm_crtc_commit_put(state->commit);
> >>
> > ___
> > 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
--
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 v7 6/8] drm/bridge/synopsys: dw-hdmi: Add missing bridge detach
On 01/09/2018 08:18 PM, Thierry Escande wrote:
From: Jeffy Chen
We inited connector in attach(), so need a detach() to cleanup.
Also fix wrong use of dw_hdmi_remove() in bind().
Signed-off-by: Jeffy Chen
Signed-off-by: Thierry Escande
Reviewed-by: Archit Taneja
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index a38db40ce990..1cc63a18b7d5 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1967,6 +1967,13 @@ static int dw_hdmi_bridge_attach(struct drm_bridge
*bridge)
return 0;
}
+static void dw_hdmi_bridge_detach(struct drm_bridge *bridge)
+{
+ struct dw_hdmi *hdmi = bridge->driver_private;
+
+ drm_connector_cleanup(&hdmi->connector);
+}
+
static enum drm_mode_status
dw_hdmi_bridge_mode_valid(struct drm_bridge *bridge,
const struct drm_display_mode *mode)
@@ -2023,6 +2030,7 @@ static void dw_hdmi_bridge_enable(struct drm_bridge
*bridge)
static const struct drm_bridge_funcs dw_hdmi_bridge_funcs = {
.attach = dw_hdmi_bridge_attach,
+ .detach = dw_hdmi_bridge_detach,
.enable = dw_hdmi_bridge_enable,
.disable = dw_hdmi_bridge_disable,
.mode_set = dw_hdmi_bridge_mode_set,
@@ -2616,7 +2624,7 @@ int dw_hdmi_bind(struct platform_device *pdev, struct
drm_encoder *encoder,
ret = drm_bridge_attach(encoder, &hdmi->bridge, NULL);
if (ret) {
- dw_hdmi_remove(pdev);
+ __dw_hdmi_remove(hdmi);
DRM_ERROR("Failed to initialize bridge with drm\n");
return ret;
}
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] radeon: completely remove lut leftovers
This is an oversight from
commit 42585395ebc1034a98937702849669f17eadb35f
Author: Peter Rosin
Date: Thu Jul 13 18:25:36 2017 +0200
drm: radeon: remove dead code and pointless local lut storage
Cc: Peter Rosin
Cc: Alex Deucher
Cc: Michel Dänzer
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon_display.c | 6 --
drivers/gpu/drm/radeon/radeon_mode.h| 1 -
2 files changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index dfda5e0ed166..d22f4b6a8828 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -698,12 +698,6 @@ static void radeon_crtc_init(struct drm_device *dev, int
index)
radeon_crtc->mode_set.num_connectors = 0;
#endif
- for (i = 0; i < 256; i++) {
- radeon_crtc->lut_r[i] = i << 2;
- radeon_crtc->lut_g[i] = i << 2;
- radeon_crtc->lut_b[i] = i << 2;
- }
-
if (rdev->is_atom_bios && (ASIC_IS_AVIVO(rdev) || radeon_r4xx_atom))
radeon_atombios_init_crtc(dev, radeon_crtc);
else
diff --git a/drivers/gpu/drm/radeon/radeon_mode.h
b/drivers/gpu/drm/radeon/radeon_mode.h
index 3243e5e01432..5f61facafe36 100644
--- a/drivers/gpu/drm/radeon/radeon_mode.h
+++ b/drivers/gpu/drm/radeon/radeon_mode.h
@@ -328,7 +328,6 @@ enum radeon_flip_status {
struct radeon_crtc {
struct drm_crtc base;
int crtc_id;
- u16 lut_r[256], lut_g[256], lut_b[256];
bool enabled;
bool can_tile;
bool cursor_out_of_bounds;
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm: export gem dmabuf_ops for drivers to reuse
On Tue, Jan 09, 2018 at 01:13:08PM -0500, Alex Deucher wrote:
> On Tue, Jan 9, 2018 at 10:56 AM, Deucher, Alexander
> wrote:
> > I'll can push this and a few other misc patches today.
> >
>
> Pushed to drm-misc-next.
One thing I just noticed: Some kerneldoc for the newly exported functions
and maybe a small update to the intro section to explain what to do with
this would be neat.
-Daniel
>
> Thanks,
>
> Alex
>
>
> >
> > Alex
> >
> > From: amd-gfx on behalf of Li,
> > Samuel
> > Sent: Tuesday, January 9, 2018 10:20 AM
> > To: Daniel Vetter; Koenig, Christian
> > Cc: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> > Subject: RE: [PATCH 2/3] drm: export gem dmabuf_ops for drivers to reuse
> >
> > Yes, please hush this for me.
> >
> > Regards,
> > Samuel Li
> >
> >
> >> -Original Message-
> >> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> >> Vetter
> >> Sent: Tuesday, January 09, 2018 4:22 AM
> >> To: Koenig, Christian
> >> Cc: Li, Samuel ; dri-devel@lists.freedesktop.org; amd-
> >> g...@lists.freedesktop.org
> >> Subject: Re: [PATCH 2/3] drm: export gem dmabuf_ops for drivers to reuse
> >>
> >> On Fri, Jan 05, 2018 at 10:16:04AM +0100, Christian König wrote:
> >> > Am 04.01.2018 um 22:12 schrieb Samuel Li:
> >> > > Change-Id: I03c22a890d2305f3243d88019d1a28bddd4ddda7
> >> > > Signed-off-by: Samuel Li
> >> >
> >> > Reviewed-by: Christian König
> >>
> >> Want to push to drm-misc or some other plan with this?
> >> -Daniel
> >>
> >> >
> >> > > ---
> >> > > drivers/gpu/drm/drm_prime.c | 53 ++---
> >>
> >> > > include/drm/drm_prime.h | 22 +++
> >> > > 2 files changed, 53 insertions(+), 22 deletions(-)
> >> > >
> >> > > diff --git a/drivers/gpu/drm/drm_prime.c
> >> > > b/drivers/gpu/drm/drm_prime.c index 8de93a2..68a69e9 100644
> >> > > --- a/drivers/gpu/drm/drm_prime.c
> >> > > +++ b/drivers/gpu/drm/drm_prime.c
> >> > > @@ -180,9 +180,8 @@ static int drm_prime_lookup_buf_handle(struct
> >> drm_prime_file_private *prime_fpri
> >> > >return -ENOENT;
> >> > > }
> >> > > -static int drm_gem_map_attach(struct dma_buf *dma_buf,
> >> > > - struct device *target_dev,
> >> > > - struct dma_buf_attachment *attach)
> >> > > +int drm_gem_map_attach(struct dma_buf *dma_buf, struct device
> >> *target_dev,
> >> > > +struct dma_buf_attachment *attach)
> >> > > {
> >> > >struct drm_prime_attachment *prime_attach;
> >> > >struct drm_gem_object *obj = dma_buf->priv; @@ -200,9 +199,10
> >> @@
> >> > > static int drm_gem_map_attach(struct dma_buf *dma_buf,
> >> > >return dev->driver->gem_prime_pin(obj);
> >> > > }
> >> > > +EXPORT_SYMBOL(drm_gem_map_attach);
> >> > > -static void drm_gem_map_detach(struct dma_buf *dma_buf,
> >> > > -struct dma_buf_attachment *attach)
> >> > > +void drm_gem_map_detach(struct dma_buf *dma_buf,
> >> > > + struct dma_buf_attachment *attach)
> >> > > {
> >> > >struct drm_prime_attachment *prime_attach = attach->priv;
> >> > >struct drm_gem_object *obj = dma_buf->priv; @@ -227,6 +227,7
> >> @@
> >> > > static void drm_gem_map_detach(struct dma_buf *dma_buf,
> >> > >kfree(prime_attach);
> >> > >attach->priv = NULL;
> >> > > }
> >> > > +EXPORT_SYMBOL(drm_gem_map_detach);
> >> > > void drm_prime_remove_buf_handle_locked(struct
> >> drm_prime_file_private *prime_fpriv,
> >> > >struct dma_buf *dma_buf)
> >> > > @@ -253,8 +254,8 @@ void
> >> drm_prime_remove_buf_handle_locked(struct drm_prime_file_private
> >> *prime_fpr
> >> > >}
> >> > > }
> >> > > -static struct sg_table *drm_gem_map_dma_buf(struct
> >> dma_buf_attachment *attach,
> >> > > - enum dma_data_direction dir)
> >> > > +struct sg_table *drm_gem_map_dma_buf(struct dma_buf_attachment
> >> *attach,
> >> > > + enum dma_data_direction dir)
> >> > > {
> >> > >struct drm_prime_attachment *prime_attach = attach->priv;
> >> > >struct drm_gem_object *obj = attach->dmabuf->priv; @@ -289,13
> >> > > +290,15 @@ static struct sg_table *drm_gem_map_dma_buf(struct
> >> dma_buf_attachment *attach,
> >> > >return sgt;
> >> > > }
> >> > > +EXPORT_SYMBOL(drm_gem_map_dma_buf);
> >> > > -static void drm_gem_unmap_dma_buf(struct dma_buf_attachment
> >> *attach,
> >> > > - struct sg_table *sgt,
> >> > > - enum dma_data_direction dir)
> >> > > +void drm_gem_unmap_dma_buf(struct dma_buf_attachment *attach,
> >> > > +struct sg_table *sgt,
> >> > > +enum dma_data_direction dir)
> >> > > {
> >> > >/* nothing to be done here */
> >> > > }
> >> > > +EXPORT_SYMBOL(drm_gem_unmap_dma_buf);
> >> > > /**
> >> > >* drm_gem_dmabuf_export - dma_buf export imp
Re: [RFC][PATCH 2/5] drm_hwcomposer: glworker: Add build time options for certain shader feature names
On Tue, Jan 09, 2018 at 10:05:42PM -0800, John Stultz wrote:
> In order to get the hikey960, which uses the mali bifrost driver
> working with drm_hwcomposer, its needed to tweak some extension
> and funciton names used in the shaders.
>
> Specifically:
> * GL_OES_EGL_image_external_essl3 instead of
> GL_OES_EGL_image_external
> * texture() instead of texture2D()
>
> Which is configured using a build time definition.
Build time is kinda uncool, at least in the spirit of multiarch kernels
:-) Can't we try a few alternatives until the glsl compiler takes it? For
extensions you could/should even query them upfront and then pick the
right one.
-Daniel
> Credit to Matt Szczesiak for suggesting these changes to get
> hikey960 working!
>
> I'm a bit new to all this, and I expect there may be a better
> way to do this, so I'd love any feedback or comments!
>
> Change-Id: I2c8f08341ad086479b66241b903c79b00f2a0feb
> Cc: Marissa Wall
> Cc: Sean Paul
> Cc: Dmitry Shmidt
> Cc: Robert Foss
> Cc: Matt Szczesiak
> Cc: Liviu Dudau
> Cc: David Hanna
> Cc: Rob Herring
> Signed-off-by: John Stutlz
> ---
> glworker.cpp | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/glworker.cpp b/glworker.cpp
> index ca726bf..c35d1b6 100644
> --- a/glworker.cpp
> +++ b/glworker.cpp
> @@ -41,6 +41,17 @@
>
> #define MAX_OVERLAPPING_LAYERS 64
>
> +#ifdef USE_TEXTURE_FN
> + #define TEXTURE_STR "texture"
> +#else
> + #define TEXTURE_STR "texture2D"
> +#endif
> +
> +#ifdef USE_IMAGE_EXTERNAL_ESSL3
> + #define IMAGE_EXTERNAL_STR "GL_OES_EGL_image_external_essl3"
> +#else
> + #define IMAGE_EXTERNAL_STR "GL_OES_EGL_image_external"
> +#endif
> namespace android {
>
> // clang-format off
> @@ -237,7 +248,7 @@ static std::string GenerateFragmentShader(int
> layer_count) {
>std::ostringstream fragment_shader_stream;
>fragment_shader_stream << "#version 300 es\n"
> << "#define LAYER_COUNT " << layer_count << "\n"
> - << "#extension GL_OES_EGL_image_external :
> require\n"
> + << "#extension " << IMAGE_EXTERNAL_STR << " :
> require\n"
> << "precision mediump float;\n";
>for (int i = 0; i < layer_count; ++i) {
> fragment_shader_stream << "uniform samplerExternalOES uLayerTexture" << i
> @@ -257,7 +268,7 @@ static std::string GenerateFragmentShader(int
> layer_count) {
>fragment_shader_stream << " if (alphaCover > 0.5/255.0) {\n";
> // clang-format off
> fragment_shader_stream
> -<< " texSample = texture2D(uLayerTexture" << i << ",\n"
> +<< " texSample = " << TEXTURE_STR << "(uLayerTexture" << i << ",\n"
> << "fTexCoords[" << i << "]);\n"
> << " multRgb = texSample.rgb *\n"
> << "max(texSample.a, uLayerPremult[" << i << "]);\n"
> --
> 2.7.4
>
> ___
> 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
[PATCH v7 2/8] drm/bridge: analogix_dp: Fix connector and encoder cleanup
From: Jeffy Chen
Since we are initing connector in the core driver and encoder in the
plat driver, let's clean them up in the right places.
Signed-off-by: Jeffy Chen
Signed-off-by: Thierry Escande
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 --
drivers/gpu/drm/exynos/exynos_dp.c | 7 +--
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 12 +---
3 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 878f61b65cb2..cb5e18d6ba04 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1411,7 +1411,6 @@ analogix_dp_bind(struct device *dev, struct drm_device
*drm_dev,
ret = analogix_dp_create_bridge(drm_dev, dp);
if (ret) {
DRM_ERROR("failed to create bridge (%d)\n", ret);
- drm_encoder_cleanup(dp->encoder);
goto err_disable_pm_runtime;
}
@@ -1434,7 +1433,6 @@ void analogix_dp_unbind(struct analogix_dp_device *dp)
{
analogix_dp_bridge_disable(dp->bridge);
dp->connector.funcs->destroy(&dp->connector);
- dp->encoder->funcs->destroy(dp->encoder);
if (dp->plat_data->panel) {
if (drm_panel_unprepare(dp->plat_data->panel))
diff --git a/drivers/gpu/drm/exynos/exynos_dp.c
b/drivers/gpu/drm/exynos/exynos_dp.c
index f7e5b2c405ed..33319a858f3a 100644
--- a/drivers/gpu/drm/exynos/exynos_dp.c
+++ b/drivers/gpu/drm/exynos/exynos_dp.c
@@ -185,8 +185,10 @@ static int exynos_dp_bind(struct device *dev, struct
device *master, void *data)
dp->plat_data.encoder = encoder;
dp->adp = analogix_dp_bind(dev, dp->drm_dev, &dp->plat_data);
- if (IS_ERR(dp->adp))
+ if (IS_ERR(dp->adp)) {
+ dp->encoder.funcs->destroy(&dp->encoder);
return PTR_ERR(dp->adp);
+ }
return 0;
}
@@ -196,7 +198,8 @@ static void exynos_dp_unbind(struct device *dev, struct
device *master,
{
struct exynos_dp_device *dp = dev_get_drvdata(dev);
- return analogix_dp_unbind(dp->adp);
+ analogix_dp_unbind(dp->adp);
+ dp->encoder.funcs->destroy(&dp->encoder);
}
static const struct component_ops exynos_dp_ops = {
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 8a58ad80f509..37250ab63bd7 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -259,13 +259,8 @@ static struct drm_encoder_helper_funcs
rockchip_dp_encoder_helper_funcs = {
.atomic_check = rockchip_dp_drm_encoder_atomic_check,
};
-static void rockchip_dp_drm_encoder_destroy(struct drm_encoder *encoder)
-{
- drm_encoder_cleanup(encoder);
-}
-
static struct drm_encoder_funcs rockchip_dp_encoder_funcs = {
- .destroy = rockchip_dp_drm_encoder_destroy,
+ .destroy = drm_encoder_cleanup,
};
static int rockchip_dp_of_probe(struct rockchip_dp_device *dp)
@@ -362,8 +357,10 @@ static int rockchip_dp_bind(struct device *dev, struct
device *master,
rockchip_drm_psr_register(&dp->encoder, analogix_dp_psr_set);
dp->adp = analogix_dp_bind(dev, dp->drm_dev, &dp->plat_data);
- if (IS_ERR(dp->adp))
+ if (IS_ERR(dp->adp)) {
+ dp->encoder.funcs->destroy(&dp->encoder);
return PTR_ERR(dp->adp);
+ }
return 0;
}
@@ -375,6 +372,7 @@ static void rockchip_dp_unbind(struct device *dev, struct
device *master,
rockchip_drm_psr_unregister(&dp->encoder);
analogix_dp_unbind(dp->adp);
+ dp->encoder.funcs->destroy(&dp->encoder);
}
static const struct component_ops rockchip_dp_component_ops = {
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 7/8] drm/bridge/synopsys: dw-hdmi: Do not use device's drvdata
From: Jeffy Chen
Let plat drivers own the drvdata, so that they could cleanup resources
in their unbind().
Signed-off-by: Jeffy Chen
Signed-off-by: Thierry Escande
Reviewed-by: Neil Armstrong
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 43 ++---
drivers/gpu/drm/imx/dw_hdmi-imx.c | 22 +--
drivers/gpu/drm/meson/meson_dw_hdmi.c | 20 ++
drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 14 --
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 23 ---
include/drm/bridge/dw_hdmi.h| 17 ++--
6 files changed, 77 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 1cc63a18b7d5..f0380bcae513 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2073,7 +2073,7 @@ static irqreturn_t dw_hdmi_hardirq(int irq, void *dev_id)
return ret;
}
-void __dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense)
+void dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense)
{
mutex_lock(&hdmi->mutex);
@@ -2099,13 +2099,6 @@ void __dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool
hpd, bool rx_sense)
}
mutex_unlock(&hdmi->mutex);
}
-
-void dw_hdmi_setup_rx_sense(struct device *dev, bool hpd, bool rx_sense)
-{
- struct dw_hdmi *hdmi = dev_get_drvdata(dev);
-
- __dw_hdmi_setup_rx_sense(hdmi, hpd, rx_sense);
-}
EXPORT_SYMBOL_GPL(dw_hdmi_setup_rx_sense);
static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
@@ -2141,9 +2134,8 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
*/
if (intr_stat &
(HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD)) {
- __dw_hdmi_setup_rx_sense(hdmi,
-phy_stat & HDMI_PHY_HPD,
-phy_stat & HDMI_PHY_RX_SENSE);
+ dw_hdmi_setup_rx_sense(hdmi, phy_stat & HDMI_PHY_HPD,
+ phy_stat & HDMI_PHY_RX_SENSE);
if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0)
cec_notifier_set_phys_addr(hdmi->cec_notifier,
@@ -2533,8 +2525,6 @@ __dw_hdmi_probe(struct platform_device *pdev,
if (hdmi->i2c)
dw_hdmi_i2c_init(hdmi);
- platform_set_drvdata(pdev, hdmi);
-
return hdmi;
err_iahb:
@@ -2584,25 +2574,23 @@ static void __dw_hdmi_remove(struct dw_hdmi *hdmi)
/*
-
* Probe/remove API, used from platforms based on the DRM bridge API.
*/
-int dw_hdmi_probe(struct platform_device *pdev,
- const struct dw_hdmi_plat_data *plat_data)
+struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
+ const struct dw_hdmi_plat_data *plat_data)
{
struct dw_hdmi *hdmi;
hdmi = __dw_hdmi_probe(pdev, plat_data);
if (IS_ERR(hdmi))
- return PTR_ERR(hdmi);
+ return hdmi;
drm_bridge_add(&hdmi->bridge);
- return 0;
+ return hdmi;
}
EXPORT_SYMBOL_GPL(dw_hdmi_probe);
-void dw_hdmi_remove(struct platform_device *pdev)
+void dw_hdmi_remove(struct dw_hdmi *hdmi)
{
- struct dw_hdmi *hdmi = platform_get_drvdata(pdev);
-
drm_bridge_remove(&hdmi->bridge);
__dw_hdmi_remove(hdmi);
@@ -2612,31 +2600,30 @@ EXPORT_SYMBOL_GPL(dw_hdmi_remove);
/*
-
* Bind/unbind API, used from platforms based on the component framework.
*/
-int dw_hdmi_bind(struct platform_device *pdev, struct drm_encoder *encoder,
-const struct dw_hdmi_plat_data *plat_data)
+struct dw_hdmi *dw_hdmi_bind(struct platform_device *pdev,
+struct drm_encoder *encoder,
+const struct dw_hdmi_plat_data *plat_data)
{
struct dw_hdmi *hdmi;
int ret;
hdmi = __dw_hdmi_probe(pdev, plat_data);
if (IS_ERR(hdmi))
- return PTR_ERR(hdmi);
+ return hdmi;
ret = drm_bridge_attach(encoder, &hdmi->bridge, NULL);
if (ret) {
__dw_hdmi_remove(hdmi);
DRM_ERROR("Failed to initialize bridge with drm\n");
- return ret;
+ return ERR_PTR(ret);
}
- return 0;
+ return hdmi;
}
EXPORT_SYMBOL_GPL(dw_hdmi_bind);
-void dw_hdmi_unbind(struct device *dev)
+void dw_hdmi_unbind(struct dw_hdmi *hdmi)
{
- struct dw_hdmi *hdmi = dev_get_drvdata(dev);
-
__dw_hdmi_remove(hdmi);
}
EXPORT_SYMBOL_GPL(dw_hdmi_unbind);
diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index b62763aa8706..b01d03e02ce0 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/im
Re: [PATCH 04/11] drm/bridge/synopsys: dw-hdmi: Export some PHY related functions
Hi Laurent,
Dne torek, 09. januar 2018 ob 14:30:22 CET je Laurent Pinchart napisal(a):
> Hi Jernej,
>
> Thank you for the patch.
>
> On Saturday, 30 December 2017 23:01:56 EET Jernej Skrabec wrote:
> > Parts of PHY code could be useful also for custom PHYs. For example,
> > Allwinner A83T has custom PHY which is probably Synopsys gen2 PHY
> > with few additional memory mapped registers, so most of the Synopsys PHY
> > related code could be reused.
> >
> > It turns out that even completely custom HDMI PHYs, such as the one
> > found in Allwinner H3, can reuse some of those functions. This would
> > suggest that (some?) functions exported in this commit are actually part
> > of generic PHY interface and not really specific to Synopsys PHYs.
>
> That's correct, those functions control the interface between the HDMI
> controller and the PHY. They're not specific to Synopsys PHYs, but they're
> specific to the PHY interface as designed by Synopsys.
Ok, I'll update commit message.
>
> > Export useful PHY functions.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 45
> > ---
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 2 ++
> > include/drm/bridge/dw_hdmi.h | 10 +++
> > 3 files changed, 44 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> > 7ca14d7325b5..67467d0b683a 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > @@ -1037,19 +1037,21 @@ static void dw_hdmi_phy_enable_svsret(struct
> > dw_hdmi *hdmi, u8 enable) HDMI_PHY_CONF0_SVSRET_MASK);
> >
> > }
> >
> > -static void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
> > +void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
> >
> > {
> >
> > hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
> >
> > HDMI_PHY_CONF0_GEN2_PDDQ_OFFSET,
> > HDMI_PHY_CONF0_GEN2_PDDQ_MASK);
> >
> > }
> >
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_pddq);
> >
> > -static void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
> > +void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
> >
> > {
> >
> > hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
> >
> > HDMI_PHY_CONF0_GEN2_TXPWRON_OFFSET,
> > HDMI_PHY_CONF0_GEN2_TXPWRON_MASK);
> >
> > }
> >
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_txpwron);
> >
> > static void dw_hdmi_phy_sel_data_en_pol(struct dw_hdmi *hdmi, u8 enable)
> > {
> >
> > @@ -1065,6 +1067,23 @@ static void
> > dw_hdmi_phy_sel_interface_control(struct
> > dw_hdmi *hdmi, u8 enable) HDMI_PHY_CONF0_SELDIPIF_MASK);
> >
> > }
> >
> > +void dw_hdmi_phy_gen2_reset(struct dw_hdmi *hdmi, u8 enable)
> > +{
> > + hdmi_mask_writeb(hdmi, enable, HDMI_MC_PHYRSTZ,
> > +HDMI_MC_PHYRSTZ_PHYRSTZ_OFFSET,
> > +HDMI_MC_PHYRSTZ_PHYRSTZ_MASK);
> > +}
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_reset);
> > +
> > +void dw_hdmi_phy_set_slave_addr(struct dw_hdmi *hdmi)
> > +{
> > + hdmi_phy_test_clear(hdmi, 1);
> > + hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
> > + HDMI_PHY_I2CM_SLAVE_ADDR);
> > + hdmi_phy_test_clear(hdmi, 0);
> > +}
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_set_slave_addr);
>
> Should the I2C address be passed as an argument ?
Yes, I already planned to do that for v2.
Best regards,
Jernej
>
> > static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
> > {
> >
> > const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
> >
> > @@ -1204,15 +1223,12 @@ static int hdmi_phy_configure(struct dw_hdmi
> > *hdmi)
> >
> > dw_hdmi_phy_enable_svsret(hdmi, 1);
> >
> > /* PHY reset. The reset signal is active high on Gen2 PHYs. */
> >
> > - hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
> > - hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
> > + dw_hdmi_phy_gen2_reset(hdmi, 1);
> > + dw_hdmi_phy_gen2_reset(hdmi, 0);
> >
> > hdmi_writeb(hdmi, HDMI_MC_HEACPHY_RST_ASSERT, HDMI_MC_HEACPHY_RST);
> >
> > - hdmi_phy_test_clear(hdmi, 1);
> > - hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
> > - HDMI_PHY_I2CM_SLAVE_ADDR);
> > - hdmi_phy_test_clear(hdmi, 0);
> > + dw_hdmi_phy_set_slave_addr(hdmi);
> >
> > /* Write to the PHY as configured by the platform */
> > if (pdata->configure_phy)
> >
> > @@ -1251,15 +1267,16 @@ static void dw_hdmi_phy_disable(struct dw_hdmi
> > *hdmi, void *data) dw_hdmi_phy_power_off(hdmi);
> >
> > }
> >
> > -static enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi
> > *hdmi, - void *data)
> > +enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
> > + void *data)
> >
> > {
> >
> > retur
[PATCH v7 4/8] drm/rockchip: dw-mipi-dsi: Fix error handling path
From: Jeffy Chen
Add missing pm_runtime_disable() in bind()'s error handling path.
Also cleanup encoder & connector in unbind().
Fixes: 80a9a059d4e4 ("drm/rockchip/dsi: add dw-mipi power domain support")
Signed-off-by: Jeffy Chen
Signed-off-by: Thierry Escande
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index b1fe0639227e..78e6b7919bf7 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -1282,7 +1282,7 @@ static int dw_mipi_dsi_bind(struct device *dev, struct
device *master,
ret = dw_mipi_dsi_register(drm, dsi);
if (ret) {
DRM_DEV_ERROR(dev, "Failed to register mipi_dsi: %d\n", ret);
- goto err_pllref;
+ goto err_disable_pllref;
}
dsi->dsi_host.ops = &dw_mipi_dsi_host_ops;
@@ -1290,24 +1290,25 @@ static int dw_mipi_dsi_bind(struct device *dev, struct
device *master,
ret = mipi_dsi_host_register(&dsi->dsi_host);
if (ret) {
DRM_DEV_ERROR(dev, "Failed to register MIPI host: %d\n", ret);
- goto err_cleanup;
+ goto err_disable_pm_runtime;
}
if (!dsi->panel) {
ret = -EPROBE_DEFER;
- goto err_mipi_dsi_host;
+ goto err_unreg_mipi_dsi_host;
}
dev_set_drvdata(dev, dsi);
pm_runtime_enable(dev);
return 0;
-err_mipi_dsi_host:
+err_unreg_mipi_dsi_host:
mipi_dsi_host_unregister(&dsi->dsi_host);
-err_cleanup:
- drm_encoder_cleanup(&dsi->encoder);
- drm_connector_cleanup(&dsi->connector);
-err_pllref:
+err_disable_pm_runtime:
+ pm_runtime_disable(dev);
+ dsi->connector.funcs->destroy(&dsi->connector);
+ dsi->encoder.funcs->destroy(&dsi->encoder);
+err_disable_pllref:
clk_disable_unprepare(dsi->pllref_clk);
return ret;
}
@@ -1319,6 +1320,10 @@ static void dw_mipi_dsi_unbind(struct device *dev,
struct device *master,
mipi_dsi_host_unregister(&dsi->dsi_host);
pm_runtime_disable(dev);
+
+ dsi->connector.funcs->destroy(&dsi->connector);
+ dsi->encoder.funcs->destroy(&dsi->encoder);
+
clk_disable_unprepare(dsi->pllref_clk);
}
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 1/6] base: power: runtime: Export pm_runtime_get/put_suppliers
The device link allows the pm framework to tie the supplier and
consumer. So, whenever the consumer is powered-on the supplier
is powered-on first.
There are however cases in which the consumer wants to power-on
the supplier, but not itself.
E.g., A Graphics or multimedia driver wants to power-on the SMMU
to unmap a buffer and finish the TLB operations without powering
on itself. Some of these unmap requests are coming from the
user space when the controller itself is not powered-up, and it
can be huge penalty in terms of power and latency to power-up
the graphics/mm controllers.
There can be an argument that the supplier should handle this case
on its own and there should not be a need for the consumer to
power-on the supplier. But as discussed on the thread [1] about
ARM-SMMU runtime pm, we don't want to introduce runtime pm calls
in atomic path in arm_smmu_unmap.
[1] https://patchwork.kernel.org/patch/9827825/
Signed-off-by: Vivek Gautam
---
* This is v2 of the patch [1]. Adding it to this patch series.
[1] https://patchwork.kernel.org/patch/10102447/
drivers/base/power/runtime.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 6e89b51ea3d9..06a2a88fe866 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -1579,6 +1579,7 @@ void pm_runtime_get_suppliers(struct device *dev)
device_links_read_unlock(idx);
}
+EXPORT_SYMBOL_GPL(pm_runtime_get_suppliers);
/**
* pm_runtime_put_suppliers - Drop references to supplier devices.
@@ -1597,6 +1598,7 @@ void pm_runtime_put_suppliers(struct device *dev)
device_links_read_unlock(idx);
}
+EXPORT_SYMBOL_GPL(pm_runtime_put_suppliers);
void pm_runtime_new_link(struct device *dev)
{
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: [PATCH 01/11] clk: sunxi-ng: Don't set k if width is 0 for nkmp plls
Hi Chen-Yu,
Dne ponedeljek, 08. januar 2018 ob 10:19:47 CET je Chen-Yu Tsai napisal(a):
> On Fri, Jan 5, 2018 at 3:28 AM, Jernej Škrabec
wrote:
> > Hi,
> >
> > Dne četrtek, 04. januar 2018 ob 15:45:18 CET je Chen-Yu Tsai napisal(a):
> >> On Sun, Dec 31, 2017 at 5:01 AM, Jernej Skrabec
> >
> > wrote:
> >> > For example, A83T have nmp plls which are modelled as nkmp plls. Since
> >> > k
> >> > is not specified, it has offset 0, shift 0 and lowest value 1. This
> >> > means that LSB bit is always set to 1, which may change clock rate.
> >> >
> >> > Fix that by applying k factor only if k width is greater than 0.
> >> >
> >> > Signed-off-by: Jernej Skrabec
> >> > ---
> >> >
> >> > drivers/clk/sunxi-ng/ccu_nkmp.c | 21 +
> >> > 1 file changed, 13 insertions(+), 8 deletions(-)
> >> >
> >> > diff --git a/drivers/clk/sunxi-ng/ccu_nkmp.c
> >> > b/drivers/clk/sunxi-ng/ccu_nkmp.c index e58c95787f94..709f528af2b3
> >> > 100644
> >> > --- a/drivers/clk/sunxi-ng/ccu_nkmp.c
> >> > +++ b/drivers/clk/sunxi-ng/ccu_nkmp.c
> >> > @@ -81,7 +81,7 @@ static unsigned long ccu_nkmp_recalc_rate(struct
> >> > clk_hw
> >> > *hw,>
> >> >
> >> > unsigned long parent_rate)
> >> >
> >> > {
> >> >
> >> > struct ccu_nkmp *nkmp = hw_to_ccu_nkmp(hw);
> >> >
> >> > - unsigned long n, m, k, p;
> >> > + unsigned long n, m, k = 1, p;
> >> >
> >> > u32 reg;
> >> >
> >> > reg = readl(nkmp->common.base + nkmp->common.reg);
> >> >
> >> > @@ -92,11 +92,13 @@ static unsigned long ccu_nkmp_recalc_rate(struct
> >> > clk_hw *hw,>
> >> >
> >> > if (!n)
> >> >
> >> > n++;
> >> >
> >> > - k = reg >> nkmp->k.shift;
> >> > - k &= (1 << nkmp->k.width) - 1;
> >> > - k += nkmp->k.offset;
> >> > - if (!k)
> >> > - k++;
> >> > + if (nkmp->k.width) {
> >> > + k = reg >> nkmp->k.shift;
> >> > + k &= (1 << nkmp->k.width) - 1;
> >> > + k += nkmp->k.offset;
> >> > + if (!k)
> >> > + k++;
> >> > + }
> >>
> >> The conditional shouldn't be necessary. With nkmp->k.width = 0,
> >> you'd simply get k & 0, which is 0, which then gets bumped up to 1,
> >> unless k.offset > 1, which would be a bug.
> >>
> >> > m = reg >> nkmp->m.shift;
> >> > m &= (1 << nkmp->m.width) - 1;
> >> >
> >> > @@ -153,12 +155,15 @@ static int ccu_nkmp_set_rate(struct clk_hw *hw,
> >> > unsigned long rate,>
> >> >
> >> > reg = readl(nkmp->common.base + nkmp->common.reg);
> >> > reg &= ~GENMASK(nkmp->n.width + nkmp->n.shift - 1,
> >> > nkmp->n.shift);
> >> >
> >> > - reg &= ~GENMASK(nkmp->k.width + nkmp->k.shift - 1,
> >> > nkmp->k.shift);
> >> > + if (nkmp->k.width)
> >> > + reg &= ~GENMASK(nkmp->k.width + nkmp->k.shift - 1,
> >> > + nkmp->k.shift);
> >> >
> >> > reg &= ~GENMASK(nkmp->m.width + nkmp->m.shift - 1,
> >> > nkmp->m.shift);
> >> > reg &= ~GENMASK(nkmp->p.width + nkmp->p.shift - 1,
> >> > nkmp->p.shift);
> >> >
> >> > reg |= (_nkmp.n - nkmp->n.offset) << nkmp->n.shift;
> >> >
> >> > - reg |= (_nkmp.k - nkmp->k.offset) << nkmp->k.shift;
> >> > + if (nkmp->k.width)
> >> > + reg |= (_nkmp.k - nkmp->k.offset) << nkmp->k.shift;
> >>
> >> I think a better way would be
> >>
> >> reg |= ((_nkmp.k - nkmp->k.offset) << nkmp->k.shift) &
> >>
> >>GENMASK(nkmp->k.width + nkmp->k.shift - 1, nkmp->k.shift);
> >>
> >> And do this for all the factors, not just k. This pattern is what
> >> regmap_update_bits does, which seems much safer. I wonder what
> >> GENMASK() with a negative value would do though...
> >
> > You're right, GENMASK(-1, 0) equals 0 (calculated by hand, not tested).
> > This seems much more elegant solution.
> >
> > Semi-related question: All nmp PLLs have much wider N range than real nkmp
> > PLLs. This causes integer overflow when using nkmp formula from datasheet.
> > Usually, N is 1-256 for nmp PLLs, which means that for very high N
> > factors, it overflows. This also causes issue that M factor is never
> > higher than 1.
> Sounds like we can't use u8 for storing the factors. At least the
> intermediate values we use to calculate the rates.
Only issue with u8 could be max field in struct ccu_mult_internal for K factor.
But since it's not used, there is no issue. All intermediate variables in
ccu_nkmp are wider.
>
> > I was wondering, if patch would be acceptable which would change this
> > formula:
> >
> > RATE = (24MHz * N * K) / (M * P)
> >
> > to this:
> >
> > RATE ((24MHz / M) * N * K) / P
> >
> > I checked all M factors and are all in 1-4 or 1-2 range, which means it
> > wouldn't have any impact for real nkmp PLLs when parent is 24 MHz clock
> > which is probably always.
> >
