Re: [PATCH v2] backlight: pwm_bl: Fix uninitialized variable
On Mon, Jul 23, 2018 at 08:23:43AM +0100, Lee Jones wrote:
> On Thu, 19 Jul 2018, Daniel Thompson wrote:
>
> > Currently, if the DT does not define num-interpolated-steps then
> > num_steps is undefined and the interpolation code will deploy randomly.
> > Fix this.
> >
> > Additionally fix a small grammar error that was identified and
> > tighten up return code checking of DT properties, both of which came
> > up during review of this patch.
> >
> > Fixes: 573fe6d1c25c ("backlight: pwm_bl: Linear interpolation between
> > brightness-levels")
> > Reported-by: Marcel Ziswiler
> > Signed-off-by: Daniel Thompson
> > Tested-by: Marcel Ziswiler
> > ---
> >
> > Notes:
> > v2:
> > - Simplify SoB chain (with Marcel's permission)
> > - Separate complex if statement and make other similar calls use same
> >return code checking approach
> > - Tidy up comment formatting and fix pre-existing grammar error
> >
> > drivers/video/backlight/pwm_bl.c | 25 -
> > 1 file changed, 12 insertions(+), 13 deletions(-)
>
> I'm hesitant to provide feedback on this, as I feel as though I've
> messed you around enough, however ... ;)
>
> > diff --git a/drivers/video/backlight/pwm_bl.c
> > b/drivers/video/backlight/pwm_bl.c
> > index 9ee4c1b735b2..f7799f62fea0 100644
> > --- a/drivers/video/backlight/pwm_bl.c
> > +++ b/drivers/video/backlight/pwm_bl.c
> > @@ -284,30 +284,29 @@ static int pwm_backlight_parse_dt(struct device *dev,
> > ret = of_property_read_u32_array(node, "brightness-levels",
> > data->levels,
> > data->max_brightness);
> > - if (ret < 0)
> > + if (!ret)
> > return ret;
> >
> > ret = of_property_read_u32(node, "default-brightness-level",
> >&value);
> > - if (ret < 0)
> > + if (!ret)
> > return ret;
>
> Just FYI (it didn't even make it to 'nit' status), this should really
> be done in a separate patch since it is unrelated to the rest of the
> patch.
Did wonder which way to go on this... I figured this close I'd accept
code either way so adopted fewest patches.
However I will split this out because I'm going to go back to the orignal
pre-v1 approach of just initializing the damn variable.
> > data->dft_brightness = value;
> >
> > /*
> > * This property is optional, if is set enables linear
> > -* interpolation between each of the values of brightness levels
> > -* and creates a new pre-computed table.
> > +* interpolation between each of the values of brightness
> > +* levels and creates a new pre-computed table.
> > */
> > - of_property_read_u32(node, "num-interpolated-steps",
> > -&num_steps);
> > -
> > - /*
> > -* Make sure that there is at least two entries in the
> > -* brightness-levels table, otherwise we can't interpolate
> > -* between two points.
> > -*/
> > - if (num_steps) {
> > + ret = of_property_read_u32(node, "num-interpolated-steps",
> > + &num_steps);
> > + if (!ret || num_steps) {
>
> Not sure if it's even possible for of_property_read_u32() to fail AND
> still populate num_steps, however this check makes it sound like that's
> okay. Is that correct?
>
> I can't help but think that this all 'just goes away' if you
> pre-initialise num_steps. I wouldn't let the "do not initialise too
> far away from the code using variable" affect this. However, if
> you're insistent, perhaps consider moving the declaration to just
> below:
>
> if (data->max_brightness > 0) {
>
> > + /*
> > +* Make sure that there are at least two entries in
> > +* the brightness-levels table, otherwise we can't
> > +* interpolate between two points.
> > +*/
> > if (data->max_brightness < 2) {
> > dev_err(dev, "can't interpolate\n");
> > return -EINVAL;
>
> --
> Lee Jones [李琼斯]
> Linaro Services Technical Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/exynos: Drop useless check from exynos_drm_{suspend,resume}
2018년 06월 11일 21:24에 Marek Szyprowski 이(가) 쓴 글: > The virtual Exynos DRM device has no runtime PM enabled, so checking > for its runtime suspended state is useless. > > Signed-off-by: Marek Szyprowski > --- > drivers/gpu/drm/exynos/exynos_drm_drv.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c > b/drivers/gpu/drm/exynos/exynos_drm_drv.c > index a81b4a5e24a7..c0b4a03ae1b6 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c > @@ -153,7 +153,7 @@ static int exynos_drm_suspend(struct device *dev) > struct drm_device *drm_dev = dev_get_drvdata(dev); > struct exynos_drm_private *private; > > - if (pm_runtime_suspended(dev) || !drm_dev) > + if (!drm_dev) > return 0; > > private = drm_dev->dev_private; > @@ -175,8 +175,8 @@ static int exynos_drm_resume(struct device *dev) > struct drm_device *drm_dev = dev_get_drvdata(dev); > struct exynos_drm_private *private; > > - if (pm_runtime_suspended(dev) || !drm_dev) > - return 0; > + if (!drm_dev) > + return; return 0. I will fix it. Thanks, Inki Dae > > private = drm_dev->dev_private; > drm_atomic_helper_resume(drm_dev, private->suspend_state); > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] backlight: pwm_bl: Fix uninitialized variable
Currently, if the DT does not define num-interpolated-steps then
num_steps is undefined and the interpolation code will deploy randomly.
Fix with a simple initialize to zero.
Fixes: 573fe6d1c25c ("backlight: pwm_bl: Linear interpolation between
brightness-levels")
Reported-by: Marcel Ziswiler
Signed-off-by: Daniel Thompson
Tested-by: Marcel Ziswiler
---
Notes:
v3:
- Switch to the simplest fix and zero the uninitialized variable. git
grep indicates that ~25% of calls to of_property_read_u32() use this
pattern (pre-initialize optional properties with sane values and
ignore the return code).
v2:
- Simplify SoB chain (with Marcel's permission)
- Separate complex if statement and make other similar calls use same
return code checking approach
- Tidy up comment formatting and fix pre-existing grammar error
drivers/video/backlight/pwm_bl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 9ee4c1b735b2..bdfcc0a71db1 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -250,7 +250,7 @@ static int pwm_backlight_parse_dt(struct device *dev,
struct device_node *node = dev->of_node;
unsigned int num_levels = 0;
unsigned int levels_count;
- unsigned int num_steps;
+ unsigned int num_steps = 0;
struct property *prop;
unsigned int *table;
int length;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] gpu: drm: virtio: code cleanup
On Tue, Jul 17, 2018 at 5:04 PM, Souptick Joarder wrote:
> On Tue, Jul 3, 2018 at 9:03 PM, Souptick Joarder wrote:
>> The fault handler code is commented since v4.2.
>> If there is no plan to enable the fault handler
>> code in future, we can remove this dead code.
>>
>> Signed-off-by: Souptick Joarder
>> ---
>> v2: corrected subject line
>>
>
> Any further comment on this patch ?
If no further comment, can we get this patch in queue for 4.19 ?
>
>> drivers/gpu/drm/virtio/virtgpu_ttm.c | 36
>> +---
>> 1 file changed, 1 insertion(+), 35 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/virtio/virtgpu_ttm.c
>> b/drivers/gpu/drm/virtio/virtgpu_ttm.c
>> index 11f8ae5..b6f021c 100644
>> --- a/drivers/gpu/drm/virtio/virtgpu_ttm.c
>> +++ b/drivers/gpu/drm/virtio/virtgpu_ttm.c
>> @@ -106,29 +106,6 @@ static void virtio_gpu_ttm_global_fini(struct
>> virtio_gpu_device *vgdev)
>> }
>> }
>>
>> -#if 0
>> -/*
>> - * Hmm, seems to not do anything useful. Leftover debug hack?
>> - * Something like printing pagefaults to kernel log?
>> - */
>> -static struct vm_operations_struct virtio_gpu_ttm_vm_ops;
>> -static const struct vm_operations_struct *ttm_vm_ops;
>> -
>> -static int virtio_gpu_ttm_fault(struct vm_fault *vmf)
>> -{
>> - struct ttm_buffer_object *bo;
>> - struct virtio_gpu_device *vgdev;
>> - int r;
>> -
>> - bo = (struct ttm_buffer_object *)vmf->vma->vm_private_data;
>> - if (bo == NULL)
>> - return VM_FAULT_NOPAGE;
>> - vgdev = virtio_gpu_get_vgdev(bo->bdev);
>> - r = ttm_vm_ops->fault(vmf);
>> - return r;
>> -}
>> -#endif
>> -
>> int virtio_gpu_mmap(struct file *filp, struct vm_area_struct *vma)
>> {
>> struct drm_file *file_priv;
>> @@ -143,19 +120,8 @@ int virtio_gpu_mmap(struct file *filp, struct
>> vm_area_struct *vma)
>> return -EINVAL;
>> }
>> r = ttm_bo_mmap(filp, vma, &vgdev->mman.bdev);
>> -#if 0
>> - if (unlikely(r != 0))
>> - return r;
>> - if (unlikely(ttm_vm_ops == NULL)) {
>> - ttm_vm_ops = vma->vm_ops;
>> - virtio_gpu_ttm_vm_ops = *ttm_vm_ops;
>> - virtio_gpu_ttm_vm_ops.fault = &virtio_gpu_ttm_fault;
>> - }
>> - vma->vm_ops = &virtio_gpu_ttm_vm_ops;
>> - return 0;
>> -#else
>> +
>> return r;
>> -#endif
>> }
>>
>> static int virtio_gpu_invalidate_caches(struct ttm_bo_device *bdev,
>> --
>> 1.9.1
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu/drm/vkms: Use new return type vm_fault_t
Use new return type vm_fault_t for fault handler.
Signed-off-by: Souptick Joarder
---
drivers/gpu/drm/vkms/vkms_drv.h | 2 +-
drivers/gpu/drm/vkms/vkms_gem.c | 5 ++---
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index 07be29f..d5d04a8 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -65,7 +65,7 @@ struct drm_gem_object *vkms_gem_create(struct drm_device *dev,
u32 *handle,
u64 size);
-int vkms_gem_fault(struct vm_fault *vmf);
+vm_fault_t vkms_gem_fault(struct vm_fault *vmf);
int vkms_dumb_create(struct drm_file *file, struct drm_device *dev,
struct drm_mode_create_dumb *args);
diff --git a/drivers/gpu/drm/vkms/vkms_gem.c b/drivers/gpu/drm/vkms/vkms_gem.c
index c7e3836..62e05dc 100644
--- a/drivers/gpu/drm/vkms/vkms_gem.c
+++ b/drivers/gpu/drm/vkms/vkms_gem.c
@@ -43,14 +43,14 @@ void vkms_gem_free_object(struct drm_gem_object *obj)
kfree(gem);
}
-int vkms_gem_fault(struct vm_fault *vmf)
+vm_fault_t vkms_gem_fault(struct vm_fault *vmf)
{
struct vm_area_struct *vma = vmf->vma;
struct vkms_gem_object *obj = vma->vm_private_data;
unsigned long vaddr = vmf->address;
pgoff_t page_offset;
loff_t num_pages;
- int ret;
+ vm_fault_t ret = VM_FAULT_SIGBUS;
page_offset = (vaddr - vma->vm_start) >> PAGE_SHIFT;
num_pages = DIV_ROUND_UP(obj->gem.size, PAGE_SIZE);
@@ -58,7 +58,6 @@ int vkms_gem_fault(struct vm_fault *vmf)
if (page_offset > num_pages)
return VM_FAULT_SIGBUS;
- ret = -ENOENT;
mutex_lock(&obj->pages_lock);
if (obj->pages) {
get_page(obj->pages[page_offset]);
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/8] xen: dma-buf support for grant device
On 07/23/2018 09:26 AM, Oleksandr Andrushchenko wrote: > On 07/23/2018 11:38 AM, Oleksandr Andrushchenko wrote: >> >>> data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c: In function >>> ‘gntdev_ioctl_dmabuf_exp_from_refs’: >>> /data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c:503:6: warning: >>> ‘args.fd’ may be used uninitialized in this function >>> [-Wmaybe-uninitialized] >>> *fd = args.fd; >>> ^ >>> /data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c:467:35: note: >>> ‘args.fd’ was declared here >>> struct gntdev_dmabuf_export_args args; >>> ^~~~ >> Strangely, but my i386 build goes smooth. >> Which version of gcc you use and could you please give me your >> .config, so I can test the same? > Now I see this warning which seems to be a false positive. > Boris, could you please apply the following: > > diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c > index e4c9f1f74476..0680dbcba616 100644 > --- a/drivers/xen/gntdev-dmabuf.c > +++ b/drivers/xen/gntdev-dmabuf.c > @@ -495,6 +495,7 @@ static int dmabuf_exp_from_refs(struct gntdev_priv > *priv, int flags, > args.dmabuf_priv = priv->dmabuf_priv; > args.count = map->count; > args.pages = map->pages; > + args.fd = -1; > > ret = dmabuf_exp_from_pages(&args); > if (ret < 0) > > or please let me know if you want me to resend with this fix? Missed this message. Yes, this obviously fixes the problem. And it is due to the code fragment that I mentioned in the earlier response. Which patch is this for? I can add this when committing. -boris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/8] xen: dma-buf support for grant device
On 07/20/2018 05:08 PM, Boris Ostrovsky wrote: On 07/20/2018 05:01 AM, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko This work is in response to my previous attempt to introduce Xen/DRM zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based frontends/backends. There is also an existing hyper_dmabuf approach available [3] which, if reworked to utilize the proposed solution, can greatly benefit as well. Lot of warnings on i386 build: In file included from /data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.c:24: /data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h: In function ‘xen_drm_front_fb_to_cookie’: /data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h:129:9: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] return (u64)fb; ^ /data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h: In function ‘xen_drm_front_dbuf_to_cookie’: /data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h:134:9: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] return (u64)gem_obj; ^ CC [M] net/netfilter/ipset/ip_set_hash_ipport.o CC drivers/media/rc/keymaps/rc-tango.o CC [M] drivers/gpu/drm/vmwgfx/vmwgfx_fifo.o AR drivers/misc/built-in.a In file included from /data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front_kms.c:20: /data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h: In function ‘xen_drm_front_fb_to_cookie’: CC [M] drivers/gpu/drm/xen/xen_drm_front_conn.o /data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h:129:9: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] return (u64)fb; (and more) The above warnings already have a fix [1] which is expected in 4.19 and then data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c: In function ‘gntdev_ioctl_dmabuf_exp_from_refs’: /data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c:503:6: warning: ‘args.fd’ may be used uninitialized in this function [-Wmaybe-uninitialized] *fd = args.fd; ^ /data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c:467:35: note: ‘args.fd’ was declared here struct gntdev_dmabuf_export_args args; ^~~~ Strangely, but my i386 build goes smooth. Which version of gcc you use and could you please give me your .config, so I can test the same? -boris Thank you, Oleksandr [1] https://cgit.freedesktop.org/drm/drm-misc/commit/?id=9eece5d9c6e0316f17091e37ff3ec87331bdedf3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu: drm: amdgpu: Replace mdelay with msleep in cik_pcie_gen3_enable()
cik_pcie_gen3_enable() is only called by cik_common_hw_init(), which is never called in atomic context. cik_pcie_gen3_enable() calls mdelay() to busily wait, which is not necessary. mdelay() can be replaced with msleep(). This is found by a static analysis tool named DCNS written by myself. Signed-off-by: Jia-Ju Bai --- drivers/gpu/drm/amd/amdgpu/cik.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/cik.c b/drivers/gpu/drm/amd/amdgpu/cik.c index 0df22030e713..5b7fab2c2008 100644 --- a/drivers/gpu/drm/amd/amdgpu/cik.c +++ b/drivers/gpu/drm/amd/amdgpu/cik.c @@ -1476,7 +1476,7 @@ static void cik_pcie_gen3_enable(struct amdgpu_device *adev) tmp |= PCIE_LC_CNTL4__LC_REDO_EQ_MASK; WREG32_PCIE(ixPCIE_LC_CNTL4, tmp); - mdelay(100); + msleep(100); /* linkctl */ pci_read_config_word(root, bridge_pos + PCI_EXP_LNKCTL, &tmp16); -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm/atomic: add ASYNC_UPDATE flag to the Atomic IOCTL.
Hi Ville,
On 06/07/18 12:54, Gustavo Padovan wrote:
> Hi Ville,
>
> On Thu, 2018-06-28 at 16:35 +0300, Ville Syrjälä wrote:
>> On Wed, Jun 27, 2018 at 11:25:06PM +0200, Enric Balletbo i Serra
>> wrote:
>>> From: Gustavo Padovan
>>>
>>> This flag tells core to jump ahead the queued update if the
>>> conditions
>>> in drm_atomic_async_check() are met. That means we are only able to
>>> do an
>>> async update if no modeset is pending and update for the same plane
>>> is
>>> not queued.
>>>
>>> It uses the already in place infrastructure for async updates.
>>
>> I still dislike the name. On Intel hw "async flip" means "flip
>> asap and tear". Whereas the legcay cursor thing i915 has is a normal
>> sync flip. "unthrottled" or something like that would be less
>> confusing.
>
> Maybe "amend"? However if we submit an amend commit when no commit is
> pending it will become a regular atomic commit.
>
This has been following the names we introduced one year ago [1], basically to
solve the legacy cursor hack, some platforms are already using the async funcs
and there is another patch at least in the ML. I agree that async is not the
best name,
>>
>> As far as introducing this flag, at least i915 totally lacks a
>> mechanism for deferring the buffer unpinning after the vblank. Hence
>> this can't be used by i915 currently. I think the only reason we get
>> away with the cursor hack is that we unbind the vma lazily and it's
>> unlikely that the small cursor vma is going to get knocked out before
>> the next vblank. For larger buffers that risk grows. We would
>> probably
>> want a stress test that smashes the gtt hard while doing "async
>> updates" to catch this.
>
> Right. We'll look into more detail to this in i915.
>
We only have one use case for this api/flag, it is used to get cursor updates to
bypass pending atomic updates without having to rely on the legacy API for that.
The current behaviour is to amend the pending atomic update to get the cursor on
the next vblank. I believe intel on intel we would do the same despite having
the chance update right away and tear? Or do you see we doing this differently?
Do you have an usecase for flip asap and tear?
Do you see here a need for 2 apis/flags and have a usecase for both? (one for
updating the plane on the hw asap and tear and another one to wait the next
vblank).
>>
>> There's also the question of how out fences work with the async
>> updates. I see that you disallow such an update if there's a previous
>> sync update still pending. That simplifies things a little bit I
>> suppose. But still you would need to track the fences per-plane and
>> signal the old fence ones as soon as the new update overrides the
>> pending update. And if you want to allow multiple planes in one async
>> update then I think the uapi would need to be changed to have
>> per-plane fences as well because subsequent updates could override
>> only a part of a previous update.
>
> The only usecase (and userspace) we have on our side for now is for
> cursors. I'm not sure an uAPI that only work for cursor in the first
> stage would be acceptable. That would make things easier.
>
> For updates on other planes or multiples planes I agree with you on
> having per-plane fences - but I guess we need a userspace usecase for
> it first.
>
Best regards,
Enric
[1] fef9df8b59453 ("drm/atomic: initial support for asynchronous plane update")
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: etnaviv oops on imx6dl/2G, works fine on imx6s/512M
On 23.7.2018 12:13, Lucas Stach wrote:
Hi Michal,
Am Mittwoch, den 18.07.2018, 14:29 +0200 schrieb Michal Vokáč:
Ahoj,
I encountered an error in etnaviv driver on one of my two very similar SBCs.
They have the same board design but slightly different HW configuration.
SW configuration/setup is the same for both. Including kernel configuration.
1. is based on i.MX6S, single core, 512MB RAM, parallel LCD.
2. is based on i.MX6DL, dual core, 2GB RAM, HDMI display.
System No.1 boots OK. I can run kmscube and HW acceleration works.
System No.2 does not boot until I disable etnaviv driver in the kernel.
When digging deeper where the problem might be I found those two threads
[1],[2]. None of these apply to me. CMA is enabled and I do not specify
fixed CMA regions in DT.
I get the same results on v4.18-rc2 and on v4.18-rc5.
Relevant parts of boot log:
[0.00] Memory: 1984044K/2097152K available (11264K kernel code, 738K
rwdata, 2672K rodata, 1024K init, 426K bss, 113108K reserved, 0K cma-reserved,
262144K highmem)
[0.00] Virtual kernel memory layout:
[0.00] vector : 0x - 0x1000 ( 4 kB)
[0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB)
[0.00] vmalloc : 0xf080 - 0xff80 ( 240 MB)
[0.00] lowmem : 0x8000 - 0xf000 (1792 MB)
[0.00] pkmap : 0x7fe0 - 0x8000 ( 2 MB)
[0.00] .text : 0x(ptrval) - 0x(ptrval) (12256 kB)
[0.00] .init : 0x(ptrval) - 0x(ptrval) (1024 kB)
[0.00] .data : 0x(ptrval) - 0x(ptrval) ( 739 kB)
[0.00].bss : 0x(ptrval) - 0x(ptrval) ( 427 kB)
[... snip ...]
[8.973561] etnaviv etnaviv: bound 13.gpu (ops gpu_ops)
[8.979464] etnaviv etnaviv: bound 134000.gpu (ops gpu_ops)
[8.985105] etnaviv-gpu 13.gpu: model: GC880, revision: 5106
[8.997639] etnaviv-gpu 13.gpu: command buffer outside valid memory
window
[9.005465] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007
[9.018325] etnaviv-gpu 134000.gpu: command buffer outside valid memory
window
[9.026767] [drm] Initialized etnaviv 1.2.0 20151214 for etnaviv on minor 0
[9.035510] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[9.042138] [drm] No driver support for vblank timestamp query.
[9.048363] imx-drm display-subsystem: bound imx-ipuv3-crtc.2 (ops
ipu_crtc_ops)
[9.055948] imx-drm display-subsystem: bound imx-ipuv3-crtc.3 (ops
ipu_crtc_ops)
[9.063409] [drm] Cannot find any crtc or sizes
[9.068354] [drm] Initialized imx-drm 1.0.0 20120507 for display-subsystem
on minor 1
[9.076283] imx-ipuv3 240.ipu: IPUv3H probed
[...]
The system does not make it to the login promt but it seems kernel is running
as I see a LED with a heart-beat trigger flashing.
Any idea what might be wrong? How to further debug this?
I'll look into why things are crashing in the RPM routines, but the
root-cause of your issue is that your system doesn't provide any CMA
memory ("0K cma-reserved" in the log above). This is required for
etnaviv to work, any working configuration without CMA memory is pure
luck. You will need to tweak your configuration to always have some CMA
memory, looking at the imx_v6_v7_defconfig should provide a good
starting point.
Glad you replied Lucas! You nailed it, I totally overlooked that option.
I am able to boot both systems and run kmscube with cma=64M kernel
command line parameter.
Thank you very much for your time,
Michal
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/8] xen: dma-buf support for grant device
On 07/23/2018 06:22 PM, Boris Ostrovsky wrote: On 07/23/2018 09:26 AM, Oleksandr Andrushchenko wrote: On 07/23/2018 11:38 AM, Oleksandr Andrushchenko wrote: data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c: In function ‘gntdev_ioctl_dmabuf_exp_from_refs’: /data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c:503:6: warning: ‘args.fd’ may be used uninitialized in this function [-Wmaybe-uninitialized] *fd = args.fd; ^ /data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c:467:35: note: ‘args.fd’ was declared here struct gntdev_dmabuf_export_args args; ^~~~ Strangely, but my i386 build goes smooth. Which version of gcc you use and could you please give me your .config, so I can test the same? Now I see this warning which seems to be a false positive. Boris, could you please apply the following: diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c index e4c9f1f74476..0680dbcba616 100644 --- a/drivers/xen/gntdev-dmabuf.c +++ b/drivers/xen/gntdev-dmabuf.c @@ -495,6 +495,7 @@ static int dmabuf_exp_from_refs(struct gntdev_priv *priv, int flags, args.dmabuf_priv = priv->dmabuf_priv; args.count = map->count; args.pages = map->pages; + args.fd = -1; ret = dmabuf_exp_from_pages(&args); if (ret < 0) or please let me know if you want me to resend with this fix? Missed this message. Yes, this obviously fixes the problem. And it is due to the code fragment that I mentioned in the earlier response. Which patch is this for? I can add this when committing. Thank you, this is for "[PATCH v5 7/8] xen/gntdev: Implement dma-buf export functionality" -boris Thank you, Oleksandr ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC RESEND PATCH] drm/rockchip: update cursors asynchronously through atomic.
Hi Enric,
On 07/23/2018 11:36 AM, Sean Paul wrote:
On Wed, Jun 27, 2018 at 11:14:47PM +0200, Enric Balletbo i Serra wrote:
Add support to async updates of cursors by using the new atomic
interface for that.
Signed-off-by: Enric Balletbo i Serra
LGTM. Given rockchip hasn't weighed in on the patch, and that you've tested it
on real hardware, let's land it.
Reviewed-by: Sean Paul
Your patch don't apply cleanly anymore. Can you rebase it and add the
r-b to the patch while at it? Thanks!
Gustavo
---
I am sending this as RFC because I still don't have a deep knowledge of
the hw and I am not sure if the vop_plane_update function can be reused
in both cases, atomic_updates and atomic_async_updates. I think that
someone with more knowledge should take a look. The patch was tested on
a Samsung Chromebook Plus in two ways.
1. Running all igt kms_cursor_legacy and kms_atomic@plane_cursor_legacy
tests and see that there is no regression after the patch.
2. Running weston using the atomic API.
Best regards,
Enric
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 80 -
1 file changed, 64 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 53d4afe15278..1eb6bda924af 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -688,8 +688,7 @@ static void vop_plane_atomic_disable(struct drm_plane
*plane,
spin_unlock(&vop->reg_lock);
}
-static void vop_plane_atomic_update(struct drm_plane *plane,
- struct drm_plane_state *old_state)
+static void vop_plane_update(struct drm_plane *plane)
{
struct drm_plane_state *state = plane->state;
struct drm_crtc *crtc = state->crtc;
@@ -710,20 +709,6 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
bool rb_swap;
int format;
- /*
-* can't update plane when vop is disabled.
-*/
- if (WARN_ON(!crtc))
- return;
-
- if (WARN_ON(!vop->is_enabled))
- return;
-
- if (!state->visible) {
- vop_plane_atomic_disable(plane, old_state);
- return;
- }
-
obj = rockchip_fb_get_gem_obj(fb, 0);
rk_obj = to_rockchip_obj(obj);
@@ -794,10 +779,73 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
spin_unlock(&vop->reg_lock);
}
+static void vop_plane_atomic_update(struct drm_plane *plane,
+ struct drm_plane_state *old_state)
+{
+ struct drm_plane_state *state = plane->state;
+ struct vop *vop = to_vop(state->crtc);
+
+ /*
+* can't update plane when vop is disabled.
+*/
+ if (WARN_ON(!state->crtc))
+ return;
+
+ if (WARN_ON(!vop->is_enabled))
+ return;
+
+ if (!state->visible) {
+ vop_plane_atomic_disable(plane, old_state);
+ return;
+ }
+
+ vop_plane_update(plane);
+}
+
+static int vop_plane_atomic_async_check(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+ struct drm_crtc_state *crtc_state;
+
+ crtc_state = drm_atomic_get_existing_crtc_state(state->state,
+ state->crtc);
+ if (WARN_ON(!crtc_state))
+ return -EINVAL;
+
+ if (!crtc_state->active)
+ return -EINVAL;
+
+ if (plane->state->crtc != state->crtc ||
+ plane->state->src_w != state->src_w ||
+ plane->state->src_h != state->src_h ||
+ plane->state->crtc_w != state->crtc_w ||
+ plane->state->crtc_h != state->crtc_h ||
+ !plane->state->fb ||
+ plane->state->fb != state->fb)
+ return -EINVAL;
+
+ return 0;
+}
+
+static void vop_plane_atomic_async_update(struct drm_plane *plane,
+ struct drm_plane_state *new_state)
+{
+ plane->state->src_x = new_state->src_x;
+ plane->state->src_y = new_state->src_y;
+ plane->state->crtc_x = new_state->crtc_x;
+ plane->state->crtc_y = new_state->crtc_y;
+ plane->state->fb = new_state->fb;
+ *plane->state = *new_state;
+
+ vop_plane_update(plane);
+}
+
static const struct drm_plane_helper_funcs plane_helper_funcs = {
.atomic_check = vop_plane_atomic_check,
.atomic_update = vop_plane_atomic_update,
.atomic_disable = vop_plane_atomic_disable,
+ .atomic_async_check = vop_plane_atomic_async_check,
+ .atomic_async_update = vop_plane_atomic_async_update,
};
static const struct drm_plane_funcs vop_plane_funcs = {
--
2.18.0
--
Gustavo Padovan
Collabora Ltd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-d
Re: [PATCH v5 0/8] xen: dma-buf support for grant device
On 07/23/2018 11:38 AM, Oleksandr Andrushchenko wrote: On 07/20/2018 05:08 PM, Boris Ostrovsky wrote: On 07/20/2018 05:01 AM, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko This work is in response to my previous attempt to introduce Xen/DRM zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based frontends/backends. There is also an existing hyper_dmabuf approach available [3] which, if reworked to utilize the proposed solution, can greatly benefit as well. Lot of warnings on i386 build: In file included from /data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.c:24: /data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h: In function ‘xen_drm_front_fb_to_cookie’: /data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h:129:9: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] return (u64)fb; ^ /data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h: In function ‘xen_drm_front_dbuf_to_cookie’: /data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h:134:9: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] return (u64)gem_obj; ^ CC [M] net/netfilter/ipset/ip_set_hash_ipport.o CC drivers/media/rc/keymaps/rc-tango.o CC [M] drivers/gpu/drm/vmwgfx/vmwgfx_fifo.o AR drivers/misc/built-in.a In file included from /data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front_kms.c:20: /data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h: In function ‘xen_drm_front_fb_to_cookie’: CC [M] drivers/gpu/drm/xen/xen_drm_front_conn.o /data/upstream/linux-xen/drivers/gpu/drm/xen/xen_drm_front.h:129:9: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] return (u64)fb; (and more) The above warnings already have a fix [1] which is expected in 4.19 and then data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c: In function ‘gntdev_ioctl_dmabuf_exp_from_refs’: /data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c:503:6: warning: ‘args.fd’ may be used uninitialized in this function [-Wmaybe-uninitialized] *fd = args.fd; ^ /data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c:467:35: note: ‘args.fd’ was declared here struct gntdev_dmabuf_export_args args; ^~~~ Strangely, but my i386 build goes smooth. Which version of gcc you use and could you please give me your .config, so I can test the same? Now I see this warning which seems to be a false positive. Boris, could you please apply the following: diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c index e4c9f1f74476..0680dbcba616 100644 --- a/drivers/xen/gntdev-dmabuf.c +++ b/drivers/xen/gntdev-dmabuf.c @@ -495,6 +495,7 @@ static int dmabuf_exp_from_refs(struct gntdev_priv *priv, int flags, args.dmabuf_priv = priv->dmabuf_priv; args.count = map->count; args.pages = map->pages; + args.fd = -1; ret = dmabuf_exp_from_pages(&args); if (ret < 0) or please let me know if you want me to resend with this fix? -boris Thank you, Oleksandr [1] https://cgit.freedesktop.org/drm/drm-misc/commit/?id=9eece5d9c6e0316f17091e37ff3ec87331bdedf3 Thank you, Oleksandr ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm: Replace PTR_RET with PTR_ERR_OR_ZERO
PTR_RET is deprecated, use PTR_ERR_OR_ZERO instead.
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
index 8d907fa..25ddbb8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
@@ -35,7 +35,7 @@ int msm_dss_get_clk(struct device *dev, struct dss_clk
*clk_arry, int num_clk)
for (i = 0; i < num_clk; i++) {
clk_arry[i].clk = clk_get(dev, clk_arry[i].clk_name);
- rc = PTR_RET(clk_arry[i].clk);
+ rc = PTR_ERR_OR_ZERO(clk_arry[i].clk);
if (rc) {
DEV_ERR("%pS->%s: '%s' get failed. rc=%d\n",
__builtin_return_address(0), __func__,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdgpu/pm: Fix potential Spectre v1
idx can be indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c:408 amdgpu_set_pp_force_state() warn: potential spectre issue 'data.states' Fix this by sanitizing idx before using it to index data.states Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Cc: sta...@vger.kernel.org Signed-off-by: Gustavo A. R. Silva --- drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c index 15a1192..a446c7c 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c @@ -31,7 +31,7 @@ #include #include #include - +#include static int amdgpu_debugfs_pm_init(struct amdgpu_device *adev); @@ -403,6 +403,7 @@ static ssize_t amdgpu_set_pp_force_state(struct device *dev, count = -EINVAL; goto fail; } + idx = array_index_nospec(idx, ARRAY_SIZE(data.states)); amdgpu_dpm_get_pp_num_states(adev, &data); state = data.states[idx]; -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/tegra: hdmi: probe deferral error reporting
On July 23, 2018 10:49:15 PM GMT+02:00, Lucas Stach wrote:
>Am Freitag, den 20.07.2018, 09:55 +0200 schrieb Marcel Ziswiler:
>> From: Marcel Ziswiler
>>
>> Actually report the error code from devm_regulator_get() which may as
>> well just be a probe deferral.
>
>This is still noisy, so while you are changing this I would prefer if
>this wouldn't print the error message if it's a simple probe deferral.
Yeah, trust me, I'm not the inventor of this probe deferral disaster!
>Suppressing the log message in that case gets us much cleaner kernel
>logs, where real errors stand out.
Ok, agreed. Will send a v2.
>Regards,
>Lucas
>
>>
>> Signed-off-by: Marcel Ziswiler
>>
>> ---
>>
>> drivers/gpu/drm/tegra/hdmi.c | 10 ++
>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/tegra/hdmi.c
>b/drivers/gpu/drm/tegra/hdmi.c
>> index 0082468f703c..94c182dbb6d0 100644
>> --- a/drivers/gpu/drm/tegra/hdmi.c
>> +++ b/drivers/gpu/drm/tegra/hdmi.c
>> @@ -1693,14 +1693,16 @@ static int tegra_hdmi_probe(struct
>platform_device *pdev)
>>
>> hdmi->hdmi = devm_regulator_get(&pdev->dev, "hdmi");
>> if (IS_ERR(hdmi->hdmi)) {
>> -dev_err(&pdev->dev, "failed to get HDMI regulator\n");
>> -return PTR_ERR(hdmi->hdmi);
>> +err = PTR_ERR(hdmi->hdmi);
>> +dev_err(&pdev->dev, "failed to get HDMI regulator: %d\n", err);
>> +return err;
>> }
>>
>> hdmi->pll = devm_regulator_get(&pdev->dev, "pll");
>> if (IS_ERR(hdmi->pll)) {
>> -dev_err(&pdev->dev, "failed to get PLL regulator\n");
>> -return PTR_ERR(hdmi->pll);
>> +err = PTR_ERR(hdmi->pll);
>> +dev_err(&pdev->dev, "failed to get PLL regulator: %d\n", err);
>> +return err;
>> }
>>
>> hdmi->vdd = devm_regulator_get(&pdev->dev, "vdd");
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/10] drm/imx: Use __drm_atomic_helper_plane_reset instead of copying the logic
Hi Alexandru,
On Fri, 2018-07-20 at 22:15 +0100, Alexandru Gheorghe wrote:
> Signed-off-by: Alexandru Gheorghe
> ---
> drivers/gpu/drm/imx/ipuv3-plane.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
> b/drivers/gpu/drm/imx/ipuv3-plane.c
> index 203f247d4854..1bd4de03ce9e 100644
> --- a/drivers/gpu/drm/imx/ipuv3-plane.c
> +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
> @@ -281,16 +281,14 @@ static void ipu_plane_state_reset(struct drm_plane
> *plane)
> ipu_state = to_ipu_plane_state(plane->state);
> __drm_atomic_helper_plane_destroy_state(plane->state);
> kfree(ipu_state);
> + plane->state = NULL;
With __drm_atomic_helper_plane_reset as-is, this could be dropped ...
> }
>
> ipu_state = kzalloc(sizeof(*ipu_state), GFP_KERNEL);
>
> - if (ipu_state) {
> - ipu_state->base.plane = plane;
> - ipu_state->base.rotation = DRM_MODE_ROTATE_0;
> - }
> + if (ipu_state)
> + __drm_atomic_helper_plane_reset(plane, &ipu_state->base);
... if this is change to just
__drm_atomic_helper_plane_reset(plane, &ipu_state->base);
>
> - plane->state = &ipu_state->base;
> }
>
> static struct drm_plane_state *
regards
Philipp
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/9] drm/exynos: rename "bridge_node" to "mic_bridge_node"
Hi,
2018년 06월 19일 17:19에 Maciej Purski 이(가) 쓴 글:
> When adding support for peripheral out bridges, the "bridge" name
> becomes imprecise as it refers to a different device than the
> "out_bridge".
Could you give me more details? I'm afriad that I don't understand what you say.
And in case of Exynos5433 SoC, SMIES(Samsung Mobile Image Enhancement System)
can be located between DECON and MIPI-DSI devices also.
Therefore, having specific name isn't reasonable.
Thanks,
Inki Dae
>
> Signed-off-by: Maciej Purski
> ---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index eae44fd..9599e6b 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -279,7 +279,7 @@ struct exynos_dsi {
> struct list_head transfer_list;
>
> const struct exynos_dsi_driver_data *driver_data;
> - struct device_node *bridge_node;
> + struct device_node *mic_bridge_node;
> };
>
> #define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
> @@ -1631,7 +1631,7 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
> if (ret < 0)
> return ret;
>
> - dsi->bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);
> + dsi->mic_bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);
>
> return 0;
> }
> @@ -1642,7 +1642,7 @@ static int exynos_dsi_bind(struct device *dev, struct
> device *master,
> struct drm_encoder *encoder = dev_get_drvdata(dev);
> struct exynos_dsi *dsi = encoder_to_dsi(encoder);
> struct drm_device *drm_dev = data;
> - struct drm_bridge *bridge;
> + struct drm_bridge *mic_bridge;
> int ret;
>
> drm_encoder_init(drm_dev, encoder, &exynos_dsi_encoder_funcs,
> @@ -1661,10 +1661,10 @@ static int exynos_dsi_bind(struct device *dev, struct
> device *master,
> return ret;
> }
>
> - if (dsi->bridge_node) {
> - bridge = of_drm_find_bridge(dsi->bridge_node);
> - if (bridge)
> - drm_bridge_attach(encoder, bridge, NULL);
> + if (dsi->mic_bridge_node) {
> + mic_bridge = of_drm_find_bridge(dsi->mic_bridge_node);
> + if (mic_bridge)
> + drm_bridge_attach(encoder, mic_bridge, NULL);
> }
>
> return mipi_dsi_host_register(&dsi->dsi_host);
> @@ -1783,7 +1783,7 @@ static int exynos_dsi_remove(struct platform_device
> *pdev)
> {
> struct exynos_dsi *dsi = platform_get_drvdata(pdev);
>
> - of_node_put(dsi->bridge_node);
> + of_node_put(dsi->mic_bridge_node);
>
> pm_runtime_disable(&pdev->dev);
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/10] drm/atomic: Add __drm_atomic_helper_plane_reset
Hi Alexandru,
On Fri, 2018-07-20 at 22:15 +0100, Alexandru Gheorghe wrote:
> There are a lot of drivers that subclass drm_plane_state, all of them
> duplicate the code that links toghether the plane with plane_state.
>
> On top of that, drivers that enable core properties also have to
> duplicate the code for initializing the properties to their default
> values, which in all cases are the same as the defaults from core.
>
> Signed-off-by: Alexandru Gheorghe
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 32 +
> include/drm/drm_atomic_helper.h | 2 ++
> 2 files changed, 25 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 8008a7de2e10..e1c6f101652e 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3507,6 +3507,28 @@ void drm_atomic_helper_crtc_destroy_state(struct
> drm_crtc *crtc,
> }
> EXPORT_SYMBOL(drm_atomic_helper_crtc_destroy_state);
>
> +/**
> + * __drm_atomic_helper_plane_reset - resets planes state to default values
> + * @plane: plane object
> + * @new_state: atomic plane state
> + *
> + * Initializes plane state to default. This is useful for drivers that
> subclass
> + * the plane state.
> + */
> +void __drm_atomic_helper_plane_reset(struct drm_plane *plane,
> + struct drm_plane_state *state)
> +{
> + if (state) {
> + state->plane = plane;
> + state->rotation = DRM_MODE_ROTATE_0;
> + /* Reset the alpha value to fully opaque if it matters */
> + if (plane->alpha_property)
> + state->alpha = plane->alpha_property->values[1];
> + }
Is this function supposed to be callable with state == NULL ?
> + plane->state = state;
If so, the comment could mention that this sets plane->state to NULL if
state == NULL, and a few of the call sites could be simplified.
If not, I would remove the conditional if (state) {} part and also
mention this in the comment.
regards
Philipp
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/exynos: Drop useless check from exynos_drm_{suspend,resume}
Hi Inki, On 2018-07-24 09:12, Inki Dae wrote: > 2018년 06월 11일 21:24에 Marek Szyprowski 이(가) 쓴 글: >> The virtual Exynos DRM device has no runtime PM enabled, so checking >> for its runtime suspended state is useless. >> >> Signed-off-by: Marek Szyprowski >> --- >> drivers/gpu/drm/exynos/exynos_drm_drv.c | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c >> b/drivers/gpu/drm/exynos/exynos_drm_drv.c >> index a81b4a5e24a7..c0b4a03ae1b6 100644 >> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c >> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c >> @@ -153,7 +153,7 @@ static int exynos_drm_suspend(struct device *dev) >> struct drm_device *drm_dev = dev_get_drvdata(dev); >> struct exynos_drm_private *private; >> >> -if (pm_runtime_suspended(dev) || !drm_dev) >> +if (!drm_dev) >> return 0; >> >> private = drm_dev->dev_private; >> @@ -175,8 +175,8 @@ static int exynos_drm_resume(struct device *dev) >> struct drm_device *drm_dev = dev_get_drvdata(dev); >> struct exynos_drm_private *private; >> >> -if (pm_runtime_suspended(dev) || !drm_dev) >> -return 0; >> +if (!drm_dev) >> +return; > return 0. I will fix it. Ah, my fault. This is a result of reordering the patches in the final patchset. After patch 2/3 exynos_drm_resume is assigned to .complete callback, which use 'void' return signature, so the 'return 0' has to be changed to 'return' again then. Thanks for fixing this. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200633] [Regression] VGA not being detected with R9 380 using AMDGPU after 4.17 kernel update.
https://bugzilla.kernel.org/show_bug.cgi?id=200633 --- Comment #1 from Michel Dänzer (mic...@daenzer.net) --- Please attach the dmesg output and Xorg log file corresponding to the problem. amdgpu.dc=0 on the kernel command line might serve as a workaround for the time being. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/10] drm/imx: Use __drm_atomic_helper_plane_reset instead of copying the logic
On Tue, 2018-07-24 at 09:49 +0200, Philipp Zabel wrote:
> Hi Alexandru,
>
> On Fri, 2018-07-20 at 22:15 +0100, Alexandru Gheorghe wrote:
> > Signed-off-by: Alexandru Gheorghe
> > ---
> > drivers/gpu/drm/imx/ipuv3-plane.c | 8 +++-
> > 1 file changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
> > b/drivers/gpu/drm/imx/ipuv3-plane.c
> > index 203f247d4854..1bd4de03ce9e 100644
> > --- a/drivers/gpu/drm/imx/ipuv3-plane.c
> > +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
> > @@ -281,16 +281,14 @@ static void ipu_plane_state_reset(struct drm_plane
> > *plane)
> > ipu_state = to_ipu_plane_state(plane->state);
> > __drm_atomic_helper_plane_destroy_state(plane->state);
> > kfree(ipu_state);
> > + plane->state = NULL;
>
> With __drm_atomic_helper_plane_reset as-is, this could be dropped ...
>
> > }
> >
> > ipu_state = kzalloc(sizeof(*ipu_state), GFP_KERNEL);
> >
> > - if (ipu_state) {
> > - ipu_state->base.plane = plane;
> > - ipu_state->base.rotation = DRM_MODE_ROTATE_0;
> > - }
> > + if (ipu_state)
> > + __drm_atomic_helper_plane_reset(plane, &ipu_state->base);
>
> ... if this is change to just
>
> __drm_atomic_helper_plane_reset(plane, &ipu_state->base);
Euh, obviously that won't be possible, sorry for the noise.
I blame the heat.
regards
Philipp
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/exynos: Drop useless check from exynos_drm_{suspend,resume}
2018년 07월 24일 16:49에 Marek Szyprowski 이(가) 쓴 글: > Hi Inki, > > On 2018-07-24 09:12, Inki Dae wrote: >> 2018년 06월 11일 21:24에 Marek Szyprowski 이(가) 쓴 글: >>> The virtual Exynos DRM device has no runtime PM enabled, so checking >>> for its runtime suspended state is useless. >>> >>> Signed-off-by: Marek Szyprowski >>> --- >>> drivers/gpu/drm/exynos/exynos_drm_drv.c | 6 +++--- >>> 1 file changed, 3 insertions(+), 3 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c >>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c >>> index a81b4a5e24a7..c0b4a03ae1b6 100644 >>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c >>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c >>> @@ -153,7 +153,7 @@ static int exynos_drm_suspend(struct device *dev) >>> struct drm_device *drm_dev = dev_get_drvdata(dev); >>> struct exynos_drm_private *private; >>> >>> - if (pm_runtime_suspended(dev) || !drm_dev) >>> + if (!drm_dev) >>> return 0; >>> >>> private = drm_dev->dev_private; >>> @@ -175,8 +175,8 @@ static int exynos_drm_resume(struct device *dev) >>> struct drm_device *drm_dev = dev_get_drvdata(dev); >>> struct exynos_drm_private *private; >>> >>> - if (pm_runtime_suspended(dev) || !drm_dev) >>> - return 0; >>> + if (!drm_dev) >>> + return; >> return 0. I will fix it. > > Ah, my fault. This is a result of reordering the patches in the final > patchset. > After patch 2/3 exynos_drm_resume is assigned to .complete callback, > which use > 'void' return signature, so the 'return 0' has to be changed to 'return' > again Already done. :) > then. Thanks for fixing this. > > Best regards > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106441] Totem video playback stuttering and graphical artifacts
https://bugs.freedesktop.org/show_bug.cgi?id=106441 Michel Dänzer changed: What|Removed |Added Resolution|--- |NOTOURBUG Status|NEW |RESOLVED --- Comment #7 from Michel Dänzer --- Resolving per comments #2 & #5, thanks for the report and follow-ups. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/9] drm/exynos: enable out_bridge in exynos_dsi_enable()
Hi,
2018년 06월 19일 17:19에 Maciej Purski 이(가) 쓴 글:
> As the out bridge will not be enabled directly by the framework,
> it should be enabled by DSI. Exynos_dsi_enable() should handle a case,
> when there is an out_bridge connected as a DSI peripheral.
>
> Signed-off-by: Maciej Purski
> ---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 34
> +
> 1 file changed, 22 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index c0408c0..8aa7ace 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -1386,25 +1386,33 @@ static void exynos_dsi_enable(struct drm_encoder
> *encoder)
>
> dsi->state |= DSIM_STATE_ENABLED;
>
> - ret = drm_panel_prepare(dsi->panel);
> - if (ret < 0) {
> - dsi->state &= ~DSIM_STATE_ENABLED;
> - pm_runtime_put_sync(dsi->dev);
> - return;
> + if (dsi->panel) {
> + ret = drm_panel_prepare(dsi->panel);
> + if (ret < 0) {
> + dsi->state &= ~DSIM_STATE_ENABLED;
Why did you remove pm_runtime_put_sync call?
> + return;
> + }
> }
>
> + if (dsi->out_bridge)
> + drm_bridge_pre_enable(dsi->out_bridge);
> +
> exynos_dsi_set_display_mode(dsi);
> exynos_dsi_set_display_enable(dsi, true);
>
> - ret = drm_panel_enable(dsi->panel);
> - if (ret < 0) {
> - dsi->state &= ~DSIM_STATE_ENABLED;
> - exynos_dsi_set_display_enable(dsi, false);
> - drm_panel_unprepare(dsi->panel);
> - pm_runtime_put_sync(dsi->dev);
> - return;
> + if (dsi->panel) {
> + ret = drm_panel_enable(dsi->panel);
> + if (ret < 0) {
> + dsi->state &= ~DSIM_STATE_ENABLED;
> + exynos_dsi_set_display_enable(dsi, false);
> + drm_panel_unprepare(dsi->panel);
Ditto.
Thanks,
Inki Dae
> + return;
> + }
> }
>
> + if (dsi->out_bridge)
> + drm_bridge_enable(dsi->out_bridge);
> +
> dsi->state |= DSIM_STATE_VIDOUT_AVAILABLE;
> }
>
> @@ -1418,8 +1426,10 @@ static void exynos_dsi_disable(struct drm_encoder
> *encoder)
> dsi->state &= ~DSIM_STATE_VIDOUT_AVAILABLE;
>
> drm_panel_disable(dsi->panel);
> + drm_bridge_disable(dsi->out_bridge);
> exynos_dsi_set_display_enable(dsi, false);
> drm_panel_unprepare(dsi->panel);
> + drm_bridge_post_disable(dsi->out_bridge);
>
> dsi->state &= ~DSIM_STATE_ENABLED;
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/9] drm/exynos: move connector creation to attach callback
Hi,
2018년 06월 19일 17:19에 Maciej Purski 이(가) 쓴 글:
> The current implementation assumes that the only possible peripheral
> device for DSIM is a panel. Using an output bridge child device
> should also be possible.
>
> If an output bridge is available, don't create a new connector.
> Instead, call drm_bridge_attach() and set encoder's bridge to NULL
> in order to avoid an out bridge from being visible by the framework, as
> the DSI bus needs control on enabling its child output bridge.
>
> Such sequence is required by Toshiba TC358764 bridge, which is a DSI
> peripheral bridge device.
Right, we should consider DSI to LVDS bridge.
Thanks,
Inki Dae
>
> Signed-off-by: Maciej Purski
> ---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 38
> ++---
> 1 file changed, 25 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 9599e6b..c0408c0 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -255,6 +255,7 @@ struct exynos_dsi {
> struct mipi_dsi_host dsi_host;
> struct drm_connector connector;
> struct drm_panel *panel;
> + struct drm_bridge *out_bridge;
> struct device *dev;
>
> void __iomem *reg_base;
> @@ -1499,7 +1500,30 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host
> *host,
> struct mipi_dsi_device *device)
> {
> struct exynos_dsi *dsi = host_to_dsi(host);
> - struct drm_device *drm = dsi->connector.dev;
> + struct drm_encoder *encoder = &dsi->encoder;
> + struct drm_device *drm = encoder->dev;
> + struct drm_bridge *out_bridge;
> +
> + out_bridge = of_drm_find_bridge(device->dev.of_node);
> + if (out_bridge) {
> + drm_bridge_attach(encoder, out_bridge, NULL);
> + dsi->out_bridge = out_bridge;
> + encoder->bridge = NULL;
> + } else {
> + int ret = exynos_dsi_create_connector(encoder);
> +
> + if (ret) {
> + DRM_ERROR("failed to create connector ret = %d\n", ret);
> + drm_encoder_cleanup(encoder);
> + return ret;
> + }
> +
> + dsi->panel = of_drm_find_panel(device->dev.of_node);
> + if (dsi->panel) {
> + drm_panel_attach(dsi->panel, &dsi->connector);
> + dsi->connector.status = connector_status_connected;
> + }
> + }
>
> /*
>* This is a temporary solution and should be made by more generic way.
> @@ -1518,11 +1542,6 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host
> *host,
> dsi->lanes = device->lanes;
> dsi->format = device->format;
> dsi->mode_flags = device->mode_flags;
> - dsi->panel = of_drm_find_panel(device->dev.of_node);
> - if (dsi->panel) {
> - drm_panel_attach(dsi->panel, &dsi->connector);
> - dsi->connector.status = connector_status_connected;
> - }
> exynos_drm_crtc_get_by_type(drm, EXYNOS_DISPLAY_TYPE_LCD)->i80_mode =
> !(dsi->mode_flags & MIPI_DSI_MODE_VIDEO);
>
> @@ -1654,13 +1673,6 @@ static int exynos_dsi_bind(struct device *dev, struct
> device *master,
> if (ret < 0)
> return ret;
>
> - ret = exynos_dsi_create_connector(encoder);
> - if (ret) {
> - DRM_ERROR("failed to create connector ret = %d\n", ret);
> - drm_encoder_cleanup(encoder);
> - return ret;
> - }
> -
> if (dsi->mic_bridge_node) {
> mic_bridge = of_drm_find_bridge(dsi->mic_bridge_node);
> if (mic_bridge)
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/9] drm/exynos: move connector creation to attach callback
2018년 07월 24일 17:04에 Inki Dae 이(가) 쓴 글:
> Hi,
>
> 2018년 06월 19일 17:19에 Maciej Purski 이(가) 쓴 글:
>> The current implementation assumes that the only possible peripheral
>> device for DSIM is a panel. Using an output bridge child device
>> should also be possible.
>>
>> If an output bridge is available, don't create a new connector.
>> Instead, call drm_bridge_attach() and set encoder's bridge to NULL
>> in order to avoid an out bridge from being visible by the framework, as
>> the DSI bus needs control on enabling its child output bridge.
>>
>> Such sequence is required by Toshiba TC358764 bridge, which is a DSI
>> peripheral bridge device.
>
> Right, we should consider DSI to LVDS bridge.
In addition, could you update below binding document?
Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
Thanks,
Inki Dae
>
> Thanks,
> Inki Dae
>
>>
>> Signed-off-by: Maciej Purski
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 38
>> ++---
>> 1 file changed, 25 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> index 9599e6b..c0408c0 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> @@ -255,6 +255,7 @@ struct exynos_dsi {
>> struct mipi_dsi_host dsi_host;
>> struct drm_connector connector;
>> struct drm_panel *panel;
>> +struct drm_bridge *out_bridge;
>> struct device *dev;
>>
>> void __iomem *reg_base;
>> @@ -1499,7 +1500,30 @@ static int exynos_dsi_host_attach(struct
>> mipi_dsi_host *host,
>>struct mipi_dsi_device *device)
>> {
>> struct exynos_dsi *dsi = host_to_dsi(host);
>> -struct drm_device *drm = dsi->connector.dev;
>> +struct drm_encoder *encoder = &dsi->encoder;
>> +struct drm_device *drm = encoder->dev;
>> +struct drm_bridge *out_bridge;
>> +
>> +out_bridge = of_drm_find_bridge(device->dev.of_node);
>> +if (out_bridge) {
>> +drm_bridge_attach(encoder, out_bridge, NULL);
>> +dsi->out_bridge = out_bridge;
>> +encoder->bridge = NULL;
>> +} else {
>> +int ret = exynos_dsi_create_connector(encoder);
>> +
>> +if (ret) {
>> +DRM_ERROR("failed to create connector ret = %d\n", ret);
>> +drm_encoder_cleanup(encoder);
>> +return ret;
>> +}
>> +
>> +dsi->panel = of_drm_find_panel(device->dev.of_node);
>> +if (dsi->panel) {
>> +drm_panel_attach(dsi->panel, &dsi->connector);
>> +dsi->connector.status = connector_status_connected;
>> +}
>> +}
>>
>> /*
>> * This is a temporary solution and should be made by more generic way.
>> @@ -1518,11 +1542,6 @@ static int exynos_dsi_host_attach(struct
>> mipi_dsi_host *host,
>> dsi->lanes = device->lanes;
>> dsi->format = device->format;
>> dsi->mode_flags = device->mode_flags;
>> -dsi->panel = of_drm_find_panel(device->dev.of_node);
>> -if (dsi->panel) {
>> -drm_panel_attach(dsi->panel, &dsi->connector);
>> -dsi->connector.status = connector_status_connected;
>> -}
>> exynos_drm_crtc_get_by_type(drm, EXYNOS_DISPLAY_TYPE_LCD)->i80_mode =
>> !(dsi->mode_flags & MIPI_DSI_MODE_VIDEO);
>>
>> @@ -1654,13 +1673,6 @@ static int exynos_dsi_bind(struct device *dev, struct
>> device *master,
>> if (ret < 0)
>> return ret;
>>
>> -ret = exynos_dsi_create_connector(encoder);
>> -if (ret) {
>> -DRM_ERROR("failed to create connector ret = %d\n", ret);
>> -drm_encoder_cleanup(encoder);
>> -return ret;
>> -}
>> -
>> if (dsi->mic_bridge_node) {
>> mic_bridge = of_drm_find_bridge(dsi->mic_bridge_node);
>> if (mic_bridge)
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/10] drm/vc4: Use __drm_atomic_helper_plane_reset instead of copying the logic
Hi Maxime, On Tue, Jul 24, 2018 at 08:57:20AM +0200, Maxime Ripard wrote: > On Fri, Jul 20, 2018 at 10:15:08PM +0100, Alexandru Gheorghe wrote: > > Signed-off-by: Alexandru Gheorghe > > --- > > drivers/gpu/drm/vc4/vc4_plane.c | 4 +--- > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > diff --git a/drivers/gpu/drm/vc4/vc4_plane.c > > b/drivers/gpu/drm/vc4/vc4_plane.c > > index 9d7a36f148cf..688ad9bb0f08 100644 > > --- a/drivers/gpu/drm/vc4/vc4_plane.c > > +++ b/drivers/gpu/drm/vc4/vc4_plane.c > > @@ -200,9 +200,7 @@ static void vc4_plane_reset(struct drm_plane *plane) > > if (!vc4_state) > > return; > > > > - plane->state = &vc4_state->base; > > - plane->state->alpha = DRM_BLEND_ALPHA_OPAQUE; > > - vc4_state->base.plane = plane; > > + __drm_atomic_helper_plane_reset(plane, &vc4_state->base); > > For vc4, rcar-du, atmel-hlcdc and sun4i, you're changing the reset > value of alpha from DRM_BLEND_ALPHA_OPAQUE to > plane->alpha_property->values[1]. plane->alpha_property->values[1] holds the max value for alpha, and it's initialized by the core to DRM_BLEND_ALPHA_OPAQUE. > > This might or might not be a good idea, but you should definitely > explain why. Would a commit message suffice? Or do you have other ideas? > > Maxime > > -- > Maxime Ripard, Bootlin (formerly Free Electrons) > Embedded Linux and Kernel engineering > https://bootlin.com -- Cheers, Alex G ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/10] drm/atomic: Add __drm_atomic_helper_plane_reset
On Tue, Jul 24, 2018 at 09:48:53AM +0200, Philipp Zabel wrote:
> Hi Alexandru,
>
> On Fri, 2018-07-20 at 22:15 +0100, Alexandru Gheorghe wrote:
> > There are a lot of drivers that subclass drm_plane_state, all of them
> > duplicate the code that links toghether the plane with plane_state.
> >
> > On top of that, drivers that enable core properties also have to
> > duplicate the code for initializing the properties to their default
> > values, which in all cases are the same as the defaults from core.
> >
> > Signed-off-by: Alexandru Gheorghe
> > ---
> > drivers/gpu/drm/drm_atomic_helper.c | 32 +
> > include/drm/drm_atomic_helper.h | 2 ++
> > 2 files changed, 25 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 8008a7de2e10..e1c6f101652e 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -3507,6 +3507,28 @@ void drm_atomic_helper_crtc_destroy_state(struct
> > drm_crtc *crtc,
> > }
> > EXPORT_SYMBOL(drm_atomic_helper_crtc_destroy_state);
> >
> > +/**
> > + * __drm_atomic_helper_plane_reset - resets planes state to default values
> > + * @plane: plane object
> > + * @new_state: atomic plane state
> > + *
> > + * Initializes plane state to default. This is useful for drivers that
> > subclass
> > + * the plane state.
> > + */
> > +void __drm_atomic_helper_plane_reset(struct drm_plane *plane,
> > +struct drm_plane_state *state)
> > +{
> > + if (state) {
> > + state->plane = plane;
> > + state->rotation = DRM_MODE_ROTATE_0;
> > + /* Reset the alpha value to fully opaque if it matters */
> > + if (plane->alpha_property)
> > + state->alpha = plane->alpha_property->values[1];
> > + }
>
> Is this function supposed to be callable with state == NULL ?
>
> > + plane->state = state;
>
> If so, the comment could mention that this sets plane->state to NULL if
> state == NULL, and a few of the call sites could be simplified.
>
> If not, I would remove the conditional if (state) {} part and also
> mention this in the comment.
Yes, It's intended to be callable with null. I will update the
comment.
>
> regards
> Philipp
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/10] drm/atomic: Add __drm_atomic_helper_plane_reset
On Tue, 24 Jul 2018 09:14:02 +0100
Alexandru-Cosmin Gheorghe wrote:
> On Tue, Jul 24, 2018 at 09:48:53AM +0200, Philipp Zabel wrote:
> > Hi Alexandru,
> >
> > On Fri, 2018-07-20 at 22:15 +0100, Alexandru Gheorghe wrote:
> > > There are a lot of drivers that subclass drm_plane_state, all of them
> > > duplicate the code that links toghether the plane with plane_state.
> > >
> > > On top of that, drivers that enable core properties also have to
> > > duplicate the code for initializing the properties to their default
> > > values, which in all cases are the same as the defaults from core.
> > >
> > > Signed-off-by: Alexandru Gheorghe
> > > ---
> > > drivers/gpu/drm/drm_atomic_helper.c | 32 +
> > > include/drm/drm_atomic_helper.h | 2 ++
> > > 2 files changed, 25 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > index 8008a7de2e10..e1c6f101652e 100644
> > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > @@ -3507,6 +3507,28 @@ void drm_atomic_helper_crtc_destroy_state(struct
> > > drm_crtc *crtc,
> > > }
> > > EXPORT_SYMBOL(drm_atomic_helper_crtc_destroy_state);
> > >
> > > +/**
> > > + * __drm_atomic_helper_plane_reset - resets planes state to default
> > > values
> > > + * @plane: plane object
> > > + * @new_state: atomic plane state
> > > + *
> > > + * Initializes plane state to default. This is useful for drivers that
> > > subclass
> > > + * the plane state.
> > > + */
> > > +void __drm_atomic_helper_plane_reset(struct drm_plane *plane,
> > > + struct drm_plane_state *state)
> > > +{
> > > + if (state) {
> > > + state->plane = plane;
> > > + state->rotation = DRM_MODE_ROTATE_0;
> > > + /* Reset the alpha value to fully opaque if it matters */
> > > + if (plane->alpha_property)
> > > + state->alpha = plane->alpha_property->values[1];
> > > + }
> >
> > Is this function supposed to be callable with state == NULL ?
> >
> > > + plane->state = state;
> >
> > If so, the comment could mention that this sets plane->state to NULL if
> > state == NULL, and a few of the call sites could be simplified.
> >
> > If not, I would remove the conditional if (state) {} part and also
> > mention this in the comment.
>
> Yes, It's intended to be callable with null.
May I ask why? I'd assume drivers that call this function to pass a
non-NULL plane state. What's the use case for passing a NULL state here?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 07/15] drm/mediatek: add layer config to set RDMA for plane setting
This patch add layer config to set RDMA for plane setting
Layer config set the data address and pitch to RDMA from plane setting.
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 78a1a0057aff..4ad0715c8341 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -36,13 +36,17 @@
#define DISP_REG_RDMA_SIZE_CON_0 0x0014
#define DISP_REG_RDMA_SIZE_CON_1 0x0018
#define DISP_REG_RDMA_TARGET_LINE 0x001c
+#define DISP_RDMA_MEM_SRC_PITCH0x002c
+#define DISP_RDMA_MEM_GMC_SETTING_00x0030
#define DISP_REG_RDMA_FIFO_CON 0x0040
#define RDMA_FIFO_UNDERFLOW_EN BIT(31)
#define RDMA_FIFO_PSEUDO_SIZE(bytes) (((bytes) / 16) << 16)
#define RDMA_OUTPUT_VALID_FIFO_THRESHOLD(bytes)((bytes) / 16)
#define RDMA_FIFO_SIZE(rdma) ((rdma)->data->fifo_size)
+#define DISP_RDMA_MEM_START_ADDR 0x0f00
#define MATRIX_INT_MTX_SEL_DEFAULT 0xb0
+#define RDMA_MEM_GMC 0x40402020
struct mtk_disp_rdma_data {
unsigned int fifo_size;
@@ -152,12 +156,28 @@ static void mtk_rdma_config(struct mtk_ddp_comp *comp,
unsigned int width,
writel(reg, comp->regs + DISP_REG_RDMA_FIFO_CON);
}
+static void mtk_rdma_layer_config(struct mtk_ddp_comp *comp, unsigned int idx,
+ struct mtk_plane_state *state)
+{
+ struct mtk_plane_pending_state *pending = &state->pending;
+ unsigned int addr = pending->addr;
+ unsigned int pitch = pending->pitch & 0x;
+
+ if (pending->height == 0u || pending->width == 0u)
+ return;
+
+ writel_relaxed(addr, comp->regs + DISP_RDMA_MEM_START_ADDR);
+ writel_relaxed(pitch, comp->regs + DISP_RDMA_MEM_SRC_PITCH);
+ writel(RDMA_MEM_GMC, comp->regs + DISP_RDMA_MEM_GMC_SETTING_0);
+}
+
static const struct mtk_ddp_comp_funcs mtk_disp_rdma_funcs = {
.config = mtk_rdma_config,
.start = mtk_rdma_start,
.stop = mtk_rdma_stop,
.enable_vblank = mtk_rdma_enable_vblank,
.disable_vblank = mtk_rdma_disable_vblank,
+ .layer_config = mtk_rdma_layer_config,
};
static int mtk_disp_rdma_bind(struct device *dev, struct device *master,
--
2.12.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 09/15] drm/mediatek: add YUYV/UYVY color format support for RDMA
This patch add YUYV/UYVY color format support for RDMA
and transform matrix for YUYV/UYVY.
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 5b7dadc21016..49edbae50167 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -34,6 +34,8 @@
#define RDMA_SOFT_RESETBIT(4)
#define RDMA_MODE_MEMORY BIT(1)
#define DISP_REG_RDMA_SIZE_CON_0 0x0014
+#define RDMA_MATRIX_ENABLE BIT(17)
+#define RDMA_MATRIX_INT_MTX_SEL(7UL << 20)
#define DISP_REG_RDMA_SIZE_CON_1 0x0018
#define DISP_REG_RDMA_TARGET_LINE 0x001c
#define DISP_RDMA_MEM_CON 0x0024
@@ -54,6 +56,8 @@
#define MEM_MODE_INPUT_FORMAT_RGB888 (0x001 << 4)
#define MEM_MODE_INPUT_FORMAT_RGBA (0x002 << 4)
#define MEM_MODE_INPUT_FORMAT_ARGB (0x003 << 4)
+#define MEM_MODE_INPUT_FORMAT_UYVY (0x004 << 4)
+#define MEM_MODE_INPUT_FORMAT_YUYV (0x005 << 4)
struct mtk_disp_rdma_data {
unsigned int fifo_size;
@@ -188,6 +192,10 @@ static unsigned int rdma_fmt_convert(struct mtk_disp_rdma
*rdma,
case DRM_FORMAT_XBGR:
case DRM_FORMAT_ABGR:
return MEM_MODE_INPUT_FORMAT_RGBA | MEM_MODE_INPUT_SWAP;
+ case DRM_FORMAT_UYVY:
+ return MEM_MODE_INPUT_FORMAT_UYVY;
+ case DRM_FORMAT_YUYV:
+ return MEM_MODE_INPUT_FORMAT_YUYV;
}
}
@@ -206,6 +214,12 @@ static void mtk_rdma_layer_config(struct mtk_ddp_comp
*comp, unsigned int idx,
con = rdma_fmt_convert(rdma, fmt);
writel_relaxed(con, comp->regs + DISP_RDMA_MEM_CON);
+ if (fmt == DRM_FORMAT_UYVY || fmt == DRM_FORMAT_YUYV)
+ rdma_update_bits(comp, DISP_REG_RDMA_SIZE_CON_0, 0xff,
+RDMA_MATRIX_ENABLE | RDMA_MATRIX_INT_MTX_SEL);
+ else
+ rdma_update_bits(comp, DISP_REG_RDMA_SIZE_CON_0, 0xff,
+MATRIX_INT_MTX_SEL_DEFAULT);
writel_relaxed(addr, comp->regs + DISP_RDMA_MEM_START_ADDR);
writel_relaxed(pitch, comp->regs + DISP_RDMA_MEM_SRC_PITCH);
--
2.12.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 00/15] Add RDMA memory mode support for mediatek SOC MT2712
This patch series add RDMA memory mode support for mediatek SOC MT2712. MT2712 has three display data path, including three HW engine, two OVL and one RDMA. The RDMA used in third ddp and it need to be set memory mode, then RDMA could read data from memory and output to panel. Stu Hsieh (15): drm/mediatek: add connection from RDMA0 to DPI1 drm/mediatek: add connection from RDMA0 to DSI1 drm/mediatek: add connection from RDMA1 to DSI0 drm/mediatek: add connection from RDMA2 to DSI0 drm/mediatek: add RDMA memory mode for crtc created drm/mediatek: add memory mode for RDMA drm/mediatek: add layer config to set RDMA for plane setting drm/mediatek: add RGB color format support for RDMA drm/mediatek: add YUYV/UYVY color format support for RDMA drm/mediatek: add drm_device in RDMA for mamory mode to reaquest buffer drm/mediatek: add dummy buffer for RDMA memory mode drm/mediatek: add layer number condition for RDMA to control plane drm/mediatek: Update some variable name from ovl to comp drm/mediatek: fixed the error value for add DSI1 in mutex drm/mediatek: fixed connection from RDMA2 to DSI1 drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 122 +++- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 59 +- drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 4 +- drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 20 - drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 2 + 5 files changed, 181 insertions(+), 26 deletions(-) -- 2.12.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 04/15] drm/mediatek: add connection from RDMA2 to DSI0
This patch add connection from RDMA2 to DSI0
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 31189fad8d4e..3239f22785fd 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -125,6 +125,7 @@
#define DPI1_SEL_IN_RDMA1 (0x1 << 8)
#define DPI1_SEL_IN_RDMA2 (0x3 << 8)
#define DSI0_SEL_IN_RDMA1 0x1
+#define DSI0_SEL_IN_RDMA2 0x4
#define DSI1_SEL_IN_RDMA1 0x1
#define DSI1_SEL_IN_RDMA2 0x4
#define DSI2_SEL_IN_RDMA1 (0x1 << 16)
@@ -309,6 +310,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
} else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI1) {
*addr = DISP_REG_CONFIG_DPI_SEL_IN;
value = DPI1_SEL_IN_RDMA2;
+ } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI0) {
+ *addr = DISP_REG_CONFIG_DSIE_SEL_IN;
+ value = DSI0_SEL_IN_RDMA2;
} else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI1) {
*addr = DISP_REG_CONFIG_DSIE_SEL_IN;
value = DSI1_SEL_IN_RDMA2;
--
2.12.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 12/15] drm/mediatek: add layer number condition for RDMA to control plane
This patch add layer number condition for RDMA to control plane
When plane init in crtc create,
it use the number of OVL layer to init plane.
That's OVL can read 4 memory address.
For mt2712 third ddp, it use RDMA to read memory.
RDMA can read 1 memory address, so it just init one plane.
For compatibility, this patch use two define OVL_LAYER_NR and
RDMA_LAYER_NR to distingush two difference HW engine.
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 25 +
drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 2 ++
2 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 4bf636e466f2..8ad90c62caa6 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -45,7 +45,8 @@ struct mtk_drm_crtc {
boolpending_needs_vblank;
struct drm_pending_vblank_event *event;
- struct drm_planeplanes[OVL_LAYER_NR];
+ struct drm_planeplanes[MAX_LAYER_NR];
+ unsigned intlayer_nr;
boolpending_planes;
void __iomem*config_regs;
@@ -286,7 +287,7 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc
*mtk_crtc)
}
/* Initially configure all planes */
- for (i = 0; i < OVL_LAYER_NR; i++) {
+ for (i = 0; i < mtk_crtc->layer_nr; i++) {
struct drm_plane *plane = &mtk_crtc->planes[i];
struct mtk_plane_state *plane_state;
@@ -351,7 +352,7 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
}
if (mtk_crtc->pending_planes) {
- for (i = 0; i < OVL_LAYER_NR; i++) {
+ for (i = 0; i < mtk_crtc->layer_nr; i++) {
struct drm_plane *plane = &mtk_crtc->planes[i];
struct mtk_plane_state *plane_state;
@@ -403,7 +404,7 @@ static void mtk_drm_crtc_atomic_disable(struct drm_crtc
*crtc,
return;
/* Set all pending plane state to disabled */
- for (i = 0; i < OVL_LAYER_NR; i++) {
+ for (i = 0; i < mtk_crtc->layer_nr; i++) {
struct drm_plane *plane = &mtk_crtc->planes[i];
struct mtk_plane_state *plane_state;
@@ -450,7 +451,7 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc *crtc,
if (mtk_crtc->event)
mtk_crtc->pending_needs_vblank = true;
- for (i = 0; i < OVL_LAYER_NR; i++) {
+ for (i = 0; i < mtk_crtc->layer_nr; i++) {
struct drm_plane *plane = &mtk_crtc->planes[i];
struct mtk_plane_state *plane_state;
@@ -559,6 +560,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
if (!mtk_crtc)
return -ENOMEM;
+ mtk_crtc->layer_nr = OVL_LAYER_NR;
mtk_crtc->config_regs = priv->config_regs;
mtk_crtc->ddp_comp_nr = path_len;
mtk_crtc->ddp_comp = devm_kmalloc_array(dev, mtk_crtc->ddp_comp_nr,
@@ -601,12 +603,13 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
comp_id == DDP_COMPONENT_RDMA2)) {
rdma_memory_mode = comp->comp_mode;
*rdma_memory_mode = true;
+ mtk_crtc->layer_nr = RDMA_LAYER_NR;
}
mtk_crtc->ddp_comp[i] = comp;
}
- for (zpos = 0; zpos < OVL_LAYER_NR; zpos++) {
+ for (zpos = 0; zpos < mtk_crtc->layer_nr; zpos++) {
type = (zpos == 0) ? DRM_PLANE_TYPE_PRIMARY :
(zpos == 1) ? DRM_PLANE_TYPE_CURSOR :
DRM_PLANE_TYPE_OVERLAY;
@@ -616,8 +619,14 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
goto unprepare;
}
- ret = mtk_drm_crtc_init(drm_dev, mtk_crtc, &mtk_crtc->planes[0],
- &mtk_crtc->planes[1], pipe);
+ if (mtk_crtc->layer_nr == 1) {
+ ret = mtk_drm_crtc_init(drm_dev, mtk_crtc, &mtk_crtc->planes[0],
+ NULL, pipe);
+ } else {
+ ret = mtk_drm_crtc_init(drm_dev, mtk_crtc, &mtk_crtc->planes[0],
+ &mtk_crtc->planes[1], pipe);
+ }
+
if (ret < 0)
goto unprepare;
drm_mode_crtc_set_gamma_size(&mtk_crtc->base, MTK_LUT_SIZE);
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
index 9d9410c67ae9..b44fefadf14a 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
@@ -18,7 +18,9 @@
#include "mtk_drm_ddp_comp.h"
#include "mtk_drm_plane.h"
+#define MAX_LAYER_NR 4
#define OVL_LAYER_NR 4
+#define RDMA_LAYER_NR 1
#define MTK_LUT_SIZE 512
#define MTK_MAX_BPC10
#define M
[PATCH v1 03/15] drm/mediatek: add connection from RDMA1 to DSI0
This patch add connection from RDMA1 to DSI0
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 310d8482d5a0..31189fad8d4e 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -124,6 +124,7 @@
#define DPI0_SEL_IN_RDMA2 0x3
#define DPI1_SEL_IN_RDMA1 (0x1 << 8)
#define DPI1_SEL_IN_RDMA2 (0x3 << 8)
+#define DSI0_SEL_IN_RDMA1 0x1
#define DSI1_SEL_IN_RDMA1 0x1
#define DSI1_SEL_IN_RDMA2 0x4
#define DSI2_SEL_IN_RDMA1 (0x1 << 16)
@@ -290,6 +291,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
} else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI1) {
*addr = DISP_REG_CONFIG_DPI_SEL_IN;
value = DPI1_SEL_IN_RDMA1;
+ } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI0) {
+ *addr = DISP_REG_CONFIG_DSIE_SEL_IN;
+ value = DSI0_SEL_IN_RDMA1;
} else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI1) {
*addr = DISP_REG_CONFIG_DSIO_SEL_IN;
value = DSI1_SEL_IN_RDMA1;
--
2.12.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 10/15] drm/mediatek: add drm_device in RDMA for mamory mode to reaquest buffer
If RDMA want to request gem buffer, it need to save the drm device.
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 49edbae50167..8d41f5cd485b 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -72,6 +72,7 @@ struct mtk_disp_rdma {
struct mtk_ddp_comp ddp_comp;
struct drm_crtc *crtc;
const struct mtk_disp_rdma_data *data;
+ struct drm_device *drm_dev;
bool rdma_memory_mode;
};
@@ -240,6 +241,7 @@ static int mtk_disp_rdma_bind(struct device *dev, struct
device *master,
{
struct mtk_disp_rdma *priv = dev_get_drvdata(dev);
struct mtk_ddp_comp *comp = &priv->ddp_comp;
+ struct mtk_disp_rdma *rdma = comp_to_rdma(comp);
struct drm_device *drm_dev = data;
int ret;
@@ -250,6 +252,7 @@ static int mtk_disp_rdma_bind(struct device *dev, struct
device *master,
return ret;
}
+ rdma->drm_dev = drm_dev;
comp->comp_mode = &priv->rdma_memory_mode;
--
2.12.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 08/15] drm/mediatek: add RGB color format support for RDMA
This patch add RGB color format support for RDMA,
including RGB565, RGB888, RGBA and ARGB.
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 41
1 file changed, 41 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 4ad0715c8341..5b7dadc21016 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -36,6 +36,8 @@
#define DISP_REG_RDMA_SIZE_CON_0 0x0014
#define DISP_REG_RDMA_SIZE_CON_1 0x0018
#define DISP_REG_RDMA_TARGET_LINE 0x001c
+#define DISP_RDMA_MEM_CON 0x0024
+#define MEM_MODE_INPUT_SWAPBIT(8)
#define DISP_RDMA_MEM_SRC_PITCH0x002c
#define DISP_RDMA_MEM_GMC_SETTING_00x0030
#define DISP_REG_RDMA_FIFO_CON 0x0040
@@ -48,6 +50,11 @@
#define MATRIX_INT_MTX_SEL_DEFAULT 0xb0
#define RDMA_MEM_GMC 0x40402020
+#define MEM_MODE_INPUT_FORMAT_RGB565 0x0
+#define MEM_MODE_INPUT_FORMAT_RGB888 (0x001 << 4)
+#define MEM_MODE_INPUT_FORMAT_RGBA (0x002 << 4)
+#define MEM_MODE_INPUT_FORMAT_ARGB (0x003 << 4)
+
struct mtk_disp_rdma_data {
unsigned int fifo_size;
};
@@ -156,16 +163,50 @@ static void mtk_rdma_config(struct mtk_ddp_comp *comp,
unsigned int width,
writel(reg, comp->regs + DISP_REG_RDMA_FIFO_CON);
}
+static unsigned int rdma_fmt_convert(struct mtk_disp_rdma *rdma,
+unsigned int fmt)
+{
+ switch (fmt) {
+ default:
+ case DRM_FORMAT_RGB565:
+ return MEM_MODE_INPUT_FORMAT_RGB565;
+ case DRM_FORMAT_BGR565:
+ return MEM_MODE_INPUT_FORMAT_RGB565 | MEM_MODE_INPUT_SWAP;
+ case DRM_FORMAT_RGB888:
+ return MEM_MODE_INPUT_FORMAT_RGB888;
+ case DRM_FORMAT_BGR888:
+ return MEM_MODE_INPUT_FORMAT_RGB888 | MEM_MODE_INPUT_SWAP;
+ case DRM_FORMAT_RGBX:
+ case DRM_FORMAT_RGBA:
+ return MEM_MODE_INPUT_FORMAT_ARGB;
+ case DRM_FORMAT_BGRX:
+ case DRM_FORMAT_BGRA:
+ return MEM_MODE_INPUT_FORMAT_ARGB | MEM_MODE_INPUT_SWAP;
+ case DRM_FORMAT_XRGB:
+ case DRM_FORMAT_ARGB:
+ return MEM_MODE_INPUT_FORMAT_RGBA;
+ case DRM_FORMAT_XBGR:
+ case DRM_FORMAT_ABGR:
+ return MEM_MODE_INPUT_FORMAT_RGBA | MEM_MODE_INPUT_SWAP;
+ }
+}
+
static void mtk_rdma_layer_config(struct mtk_ddp_comp *comp, unsigned int idx,
struct mtk_plane_state *state)
{
+ struct mtk_disp_rdma *rdma = comp_to_rdma(comp);
struct mtk_plane_pending_state *pending = &state->pending;
unsigned int addr = pending->addr;
unsigned int pitch = pending->pitch & 0x;
+ unsigned int fmt = pending->format;
+ unsigned int con;
if (pending->height == 0u || pending->width == 0u)
return;
+ con = rdma_fmt_convert(rdma, fmt);
+ writel_relaxed(con, comp->regs + DISP_RDMA_MEM_CON);
+
writel_relaxed(addr, comp->regs + DISP_RDMA_MEM_START_ADDR);
writel_relaxed(pitch, comp->regs + DISP_RDMA_MEM_SRC_PITCH);
writel(RDMA_MEM_GMC, comp->regs + DISP_RDMA_MEM_GMC_SETTING_0);
--
2.12.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 05/15] drm/mediatek: add RDMA memory mode for crtc created
This patch add RDMA memory mode for crtc created
For mt2712, the third ddp use RDMA engine to read data from dram.
Therefore, when crtc created, crtc need to decide using OVL or RDMA
by ddp to read data from dram.
If this ddp use RDMA, the crtc should set this RDMA which in the crtc
using memory mode.
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 5 -
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 8
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 585943c81e1f..60851bb2dd63 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -150,6 +150,7 @@ static int mtk_disp_rdma_bind(struct device *dev, struct
device *master,
void *data)
{
struct mtk_disp_rdma *priv = dev_get_drvdata(dev);
+ struct mtk_ddp_comp *comp = &priv->ddp_comp;
struct drm_device *drm_dev = data;
int ret;
@@ -160,8 +161,10 @@ static int mtk_disp_rdma_bind(struct device *dev, struct
device *master,
return ret;
}
- return 0;
+ comp->comp_mode = &priv->rdma_memory_mode;
+
+ return 0;
}
static void mtk_disp_rdma_unbind(struct device *dev, struct device *master,
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 2d6aa150a9ff..4bf636e466f2 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -578,6 +578,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
enum mtk_ddp_comp_id comp_id = path[i];
struct mtk_ddp_comp *comp;
struct device_node *node;
+ bool *rdma_memory_mode;
node = priv->comp_node[comp_id];
comp = priv->ddp_comp[comp_id];
@@ -595,6 +596,13 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
goto unprepare;
}
+ if (i == 0 && (comp_id == DDP_COMPONENT_RDMA0 ||
+ comp_id == DDP_COMPONENT_RDMA1 ||
+ comp_id == DDP_COMPONENT_RDMA2)) {
+ rdma_memory_mode = comp->comp_mode;
+ *rdma_memory_mode = true;
+ }
+
mtk_crtc->ddp_comp[i] = comp;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index 7413ffeb3c9d..a1988ce15141 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -93,6 +93,7 @@ struct mtk_ddp_comp {
struct device *larb_dev;
enum mtk_ddp_comp_id id;
const struct mtk_ddp_comp_funcs *funcs;
+ void *comp_mode;
};
static inline void mtk_ddp_comp_config(struct mtk_ddp_comp *comp,
--
2.12.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 13/15] drm/mediatek: Update some variable name from ovl to comp
This patch Update some variable name from ovl to comp
Because RDMA would be first HW in ddp, the naming ovl
should be change to comp.
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 26 +-
drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 2 +-
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 8ad90c62caa6..2509ed3e0278 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -172,9 +172,9 @@ static void mtk_drm_crtc_mode_set_nofb(struct drm_crtc
*crtc)
static int mtk_drm_crtc_enable_vblank(struct drm_crtc *crtc)
{
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
- struct mtk_ddp_comp *ovl = mtk_crtc->ddp_comp[0];
+ struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
- mtk_ddp_comp_enable_vblank(ovl, &mtk_crtc->base);
+ mtk_ddp_comp_enable_vblank(comp, &mtk_crtc->base);
return 0;
}
@@ -182,9 +182,9 @@ static int mtk_drm_crtc_enable_vblank(struct drm_crtc *crtc)
static void mtk_drm_crtc_disable_vblank(struct drm_crtc *crtc)
{
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
- struct mtk_ddp_comp *ovl = mtk_crtc->ddp_comp[0];
+ struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
- mtk_ddp_comp_disable_vblank(ovl);
+ mtk_ddp_comp_disable_vblank(comp);
}
static int mtk_crtc_ddp_clk_enable(struct mtk_drm_crtc *mtk_crtc)
@@ -335,7 +335,7 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
{
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
struct mtk_crtc_state *state = to_mtk_crtc_state(mtk_crtc->base.state);
- struct mtk_ddp_comp *ovl = mtk_crtc->ddp_comp[0];
+ struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
unsigned int i;
/*
@@ -344,7 +344,7 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
* queue update module registers on vblank.
*/
if (state->pending_config) {
- mtk_ddp_comp_config(ovl, state->pending_width,
+ mtk_ddp_comp_config(comp, state->pending_width,
state->pending_height,
state->pending_vrefresh, 0);
@@ -359,7 +359,7 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
plane_state = to_mtk_plane_state(plane->state);
if (plane_state->pending.config) {
- mtk_ddp_comp_layer_config(ovl, i, plane_state);
+ mtk_ddp_comp_layer_config(comp, i, plane_state);
plane_state->pending.config = false;
}
}
@@ -371,12 +371,12 @@ static void mtk_drm_crtc_atomic_enable(struct drm_crtc
*crtc,
struct drm_crtc_state *old_state)
{
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
- struct mtk_ddp_comp *ovl = mtk_crtc->ddp_comp[0];
+ struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
int ret;
DRM_DEBUG_DRIVER("%s %d\n", __func__, crtc->base.id);
- ret = mtk_smi_larb_get(ovl->larb_dev);
+ ret = mtk_smi_larb_get(comp->larb_dev);
if (ret) {
DRM_ERROR("Failed to get larb: %d\n", ret);
return;
@@ -384,7 +384,7 @@ static void mtk_drm_crtc_atomic_enable(struct drm_crtc
*crtc,
ret = mtk_crtc_ddp_hw_init(mtk_crtc);
if (ret) {
- mtk_smi_larb_put(ovl->larb_dev);
+ mtk_smi_larb_put(comp->larb_dev);
return;
}
@@ -396,7 +396,7 @@ static void mtk_drm_crtc_atomic_disable(struct drm_crtc
*crtc,
struct drm_crtc_state *old_state)
{
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
- struct mtk_ddp_comp *ovl = mtk_crtc->ddp_comp[0];
+ struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
int i;
DRM_DEBUG_DRIVER("%s %d\n", __func__, crtc->base.id);
@@ -419,7 +419,7 @@ static void mtk_drm_crtc_atomic_disable(struct drm_crtc
*crtc,
drm_crtc_vblank_off(crtc);
mtk_crtc_ddp_hw_fini(mtk_crtc);
- mtk_smi_larb_put(ovl->larb_dev);
+ mtk_smi_larb_put(comp->larb_dev);
mtk_crtc->enabled = false;
}
@@ -517,7 +517,7 @@ static int mtk_drm_crtc_init(struct drm_device *drm,
return ret;
}
-void mtk_crtc_ddp_irq(struct drm_crtc *crtc, struct mtk_ddp_comp *ovl)
+void mtk_crtc_ddp_irq(struct drm_crtc *crtc, struct mtk_ddp_comp *comp)
{
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
struct mtk_drm_private *priv = crtc->dev->dev_private;
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
index b44fefadf14a..0de77f60c806 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
[PATCH v1 02/15] drm/mediatek: add connection from RDMA0 to DSI1
This patch add connection from RDMA0 to DSI1
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 03e3628b5b0d..310d8482d5a0 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -107,6 +107,7 @@
#define GAMMA_MOUT_EN_RDMA10x1
#define RDMA0_SOUT_DPI00x2
#define RDMA0_SOUT_DPI10x3
+#define RDMA0_SOUT_DSI10x1
#define RDMA0_SOUT_DSI20x4
#define RDMA0_SOUT_DSI30x5
#define RDMA1_SOUT_DPI00x2
@@ -228,6 +229,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id
cur,
} else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DPI1) {
*addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
value = RDMA0_SOUT_DPI1;
+ } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI1) {
+ *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
+ value = RDMA0_SOUT_DSI1;
} else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI2) {
*addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
value = RDMA0_SOUT_DSI2;
--
2.12.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 01/15] drm/mediatek: add connection from RDMA0 to DPI1
This patch add connection from RDMA0 to DPI1
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 87e4191c250e..03e3628b5b0d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -106,6 +106,7 @@
#define OVL1_MOUT_EN_COLOR10x1
#define GAMMA_MOUT_EN_RDMA10x1
#define RDMA0_SOUT_DPI00x2
+#define RDMA0_SOUT_DPI10x3
#define RDMA0_SOUT_DSI20x4
#define RDMA0_SOUT_DSI30x5
#define RDMA1_SOUT_DPI00x2
@@ -224,6 +225,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id
cur,
} else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DPI0) {
*addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
value = RDMA0_SOUT_DPI0;
+ } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DPI1) {
+ *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
+ value = RDMA0_SOUT_DPI1;
} else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI2) {
*addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
value = RDMA0_SOUT_DSI2;
--
2.12.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 15/15] drm/mediatek: fixed connection from RDMA2 to DSI1
This patch fixed connection from RDMA2 to DSI1
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index ac047fdb1a2b..66a27b6a7583 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -314,7 +314,7 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
*addr = DISP_REG_CONFIG_DSIE_SEL_IN;
value = DSI0_SEL_IN_RDMA2;
} else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI1) {
- *addr = DISP_REG_CONFIG_DSIE_SEL_IN;
+ *addr = DISP_REG_CONFIG_DSIO_SEL_IN;
value = DSI1_SEL_IN_RDMA2;
} else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI2) {
*addr = DISP_REG_CONFIG_DSIE_SEL_IN;
--
2.12.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 11/15] drm/mediatek: add dummy buffer for RDMA memory mode
This patch add dummy buffer for RDMA memory mode
When display power on, the drm frame work would modeset and
set up the display HW.
In this time, the RDMA would start wroking and read the data from memory.
But, user space not send the data to drm yet.
For this case, if user space not send data to display hw(RDMA) yet,
RDMA would read the wrong address to show garbage.
Therefore, we create dummy buffer for RDMA reading memory
when userspace not send the data yet.
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 23 +++
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 8d41f5cd485b..e28f368728cd 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -20,6 +20,7 @@
#include "mtk_drm_crtc.h"
#include "mtk_drm_ddp_comp.h"
+#include "mtk_drm_gem.h"
#define DISP_REG_RDMA_INT_ENABLE 0x
#define DISP_REG_RDMA_INT_STATUS 0x0004
@@ -59,6 +60,9 @@
#define MEM_MODE_INPUT_FORMAT_UYVY (0x004 << 4)
#define MEM_MODE_INPUT_FORMAT_YUYV (0x005 << 4)
+#define RDMA_DUMMY_BUFFER_SIZE(h, v) ((h) * (v) * 4)
+#define RDMA_DUMMY_BUFFER_PITCH(h) ((h) * 4)
+
struct mtk_disp_rdma_data {
unsigned int fifo_size;
};
@@ -74,6 +78,7 @@ struct mtk_disp_rdma {
const struct mtk_disp_rdma_data *data;
struct drm_device *drm_dev;
bool rdma_memory_mode;
+ unsigned int dummy_size;
};
static inline struct mtk_disp_rdma *comp_to_rdma(struct mtk_ddp_comp *comp)
@@ -126,14 +131,29 @@ static void mtk_rdma_disable_vblank(struct mtk_ddp_comp
*comp)
static void mtk_rdma_start(struct mtk_ddp_comp *comp)
{
+ struct mtk_disp_rdma *rdma = comp_to_rdma(comp);
+ bool *rdma_memory_mode = comp->comp_mode;
+
+ if (*rdma_memory_mode == true) {
+ comp->mtk_gem = mtk_drm_gem_create(rdma->drm_dev,
+ rdma->dummy_size, false);
+ writel(comp->mtk_gem->dma_addr & 0x,
+ comp->regs + DISP_RDMA_MEM_START_ADDR);
+ }
+
rdma_update_bits(comp, DISP_REG_RDMA_GLOBAL_CON, RDMA_ENGINE_EN,
RDMA_ENGINE_EN);
}
static void mtk_rdma_stop(struct mtk_ddp_comp *comp)
{
+ bool *rdma_memory_mode = comp->comp_mode;
+
writel(RDMA_SOFT_RESET, comp->regs + DISP_REG_RDMA_GLOBAL_CON);
writel(0, comp->regs + DISP_REG_RDMA_GLOBAL_CON);
+
+ if (*rdma_memory_mode == true)
+ mtk_drm_gem_free_object(&comp->mtk_gem->base);
}
static void mtk_rdma_config(struct mtk_ddp_comp *comp, unsigned int width,
@@ -149,8 +169,11 @@ static void mtk_rdma_config(struct mtk_ddp_comp *comp,
unsigned int width,
rdma_update_bits(comp, DISP_REG_RDMA_SIZE_CON_1, 0xf, height);
if (*rdma_memory_mode == true) {
+ rdma->dummy_size = RDMA_DUMMY_BUFFER_SIZE(width, height);
rdma_update_bits(comp, DISP_REG_RDMA_SIZE_CON_0, 0xff,
MATRIX_INT_MTX_SEL_DEFAULT);
+ writel(RDMA_DUMMY_BUFFER_PITCH(width),
+ comp->regs + DISP_RDMA_MEM_SRC_PITCH);
rdma_update_bits(comp, DISP_REG_RDMA_GLOBAL_CON,
RDMA_MODE_MEMORY, RDMA_MODE_MEMORY);
}
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index a1988ce15141..6dbb83144a74 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -92,6 +92,7 @@ struct mtk_ddp_comp {
int irq;
struct device *larb_dev;
enum mtk_ddp_comp_id id;
+ struct mtk_drm_gem_obj *mtk_gem;
const struct mtk_ddp_comp_funcs *funcs;
void *comp_mode;
};
--
2.12.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 06/15] drm/mediatek: add memory mode for RDMA
This patch add memory mode for RDMA
If use RDMA to read data from memory, it should set memory mode to RDMA
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 60851bb2dd63..78a1a0057aff 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -31,6 +31,8 @@
#define RDMA_REG_UPDATE_INTBIT(0)
#define DISP_REG_RDMA_GLOBAL_CON 0x0010
#define RDMA_ENGINE_EN BIT(0)
+#define RDMA_SOFT_RESETBIT(4)
+#define RDMA_MODE_MEMORY BIT(1)
#define DISP_REG_RDMA_SIZE_CON_0 0x0014
#define DISP_REG_RDMA_SIZE_CON_1 0x0018
#define DISP_REG_RDMA_TARGET_LINE 0x001c
@@ -40,6 +42,8 @@
#define RDMA_OUTPUT_VALID_FIFO_THRESHOLD(bytes)((bytes) / 16)
#define RDMA_FIFO_SIZE(rdma) ((rdma)->data->fifo_size)
+#define MATRIX_INT_MTX_SEL_DEFAULT 0xb0
+
struct mtk_disp_rdma_data {
unsigned int fifo_size;
};
@@ -53,6 +57,7 @@ struct mtk_disp_rdma {
struct mtk_ddp_comp ddp_comp;
struct drm_crtc *crtc;
const struct mtk_disp_rdma_data *data;
+ bool rdma_memory_mode;
};
static inline struct mtk_disp_rdma *comp_to_rdma(struct mtk_ddp_comp *comp)
@@ -111,7 +116,8 @@ static void mtk_rdma_start(struct mtk_ddp_comp *comp)
static void mtk_rdma_stop(struct mtk_ddp_comp *comp)
{
- rdma_update_bits(comp, DISP_REG_RDMA_GLOBAL_CON, RDMA_ENGINE_EN, 0);
+ writel(RDMA_SOFT_RESET, comp->regs + DISP_REG_RDMA_GLOBAL_CON);
+ writel(0, comp->regs + DISP_REG_RDMA_GLOBAL_CON);
}
static void mtk_rdma_config(struct mtk_ddp_comp *comp, unsigned int width,
@@ -121,10 +127,18 @@ static void mtk_rdma_config(struct mtk_ddp_comp *comp,
unsigned int width,
unsigned int threshold;
unsigned int reg;
struct mtk_disp_rdma *rdma = comp_to_rdma(comp);
+ bool *rdma_memory_mode = comp->comp_mode;
rdma_update_bits(comp, DISP_REG_RDMA_SIZE_CON_0, 0xfff, width);
rdma_update_bits(comp, DISP_REG_RDMA_SIZE_CON_1, 0xf, height);
+ if (*rdma_memory_mode == true) {
+ rdma_update_bits(comp, DISP_REG_RDMA_SIZE_CON_0, 0xff,
+MATRIX_INT_MTX_SEL_DEFAULT);
+ rdma_update_bits(comp, DISP_REG_RDMA_GLOBAL_CON,
+RDMA_MODE_MEMORY, RDMA_MODE_MEMORY);
+ }
+
/*
* Enable FIFO underflow since DSI and DPI can't be blocked.
* Keep the FIFO pseudo size reset default of 8 KiB. Set the
--
2.12.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 14/15] drm/mediatek: fixed the error value for add DSI1 in mutex
This patch fixed the error value for add DSI1 in mutex Signed-off-by: Stu Hsieh --- drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c index 3239f22785fd..ac047fdb1a2b 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c @@ -437,7 +437,7 @@ void mtk_disp_mutex_add_comp(struct mtk_disp_mutex *mutex, reg = MUTEX_SOF_DSI0; break; case DDP_COMPONENT_DSI1: - reg = MUTEX_SOF_DSI0; + reg = MUTEX_SOF_DSI1; break; case DDP_COMPONENT_DSI2: reg = MUTEX_SOF_DSI2; -- 2.12.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC] drm: Allow DRM_IOCTL_MODE_MAP_DUMB for render nodes
From: Tomasz Figa
There is no particular reason to prevent userspace for using this IOCTL,
considering that it already has access to other, platform-specific
IOCTLs. This patch makes is possible to have the same userspace code
work regardless on the underlying platform, which significantly
simplifies the stack.
Signed-off-by: Tomasz Figa
Reviewed-by: Zach Reizner
Signed-off-by: Nicolas Norvez
Reviewed-by: Tomasz Figa
Signed-off-by: Robert Foss
---
I've been looking into enabling a kms_swrast based driver for mesa on
the Android platform[1].
But have come up against the issue of dumb buffer related ioctls below
not being flagged with DRM_RENDER_ALLOW.
DRM_IOCTL_MODE_CREATE_DUMB
DRM_IOCTL_MODE_MAP_DUMB
To be more precise, I've been seeing a failure due to DRM_IOCTL_MODE_MAP_DUMB
not being allowed for /dev/dri/renderD* nodes, and used in mesa
kms_sw_displaytarget_map().
As I understand it the DRM_RENDER_ALLOW flag being unset is a very intentional
restriction placed on dumb buffers in order to minimize its use.
But as far as alternative solutions for software renderers there seems to only
be VGEM and mmap()-ing DMABUFs.
While it would be convenient from the point of view of software renderers if
dumb buffers had more promiscuous permissions, it may be a hard sell upstream.
If dumb buffers aren't the way forward, what is? VGEM? Or are there any other
preferable ways?
[1] https://patchwork.freedesktop.org/series/45966/
drivers/gpu/drm/drm_ioctl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 0d4cfb232576..ef716246baf6 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -642,8 +642,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_MODE_RMFB, drm_mode_rmfb, DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_PAGE_FLIP, drm_mode_page_flip_ioctl,
DRM_MASTER|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_DIRTYFB, drm_mode_dirtyfb_ioctl,
DRM_MASTER|DRM_UNLOCKED),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_CREATE_DUMB, drm_mode_create_dumb_ioctl,
DRM_UNLOCKED),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_MAP_DUMB, drm_mode_mmap_dumb_ioctl,
DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_CREATE_DUMB, drm_mode_create_dumb_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_MAP_DUMB, drm_mode_mmap_dumb_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_DESTROY_DUMB, drm_mode_destroy_dumb_ioctl,
DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_OBJ_GETPROPERTIES,
drm_mode_obj_get_properties_ioctl, DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_OBJ_SETPROPERTY,
drm_mode_obj_set_property_ioctl, DRM_MASTER|DRM_UNLOCKED),
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/10] drm: mali-dp: Use __drm_atomic_helper_plane_reset instead of copying the logic
On Fri, Jul 20, 2018 at 10:15:02PM +0100, Alexandru Gheorghe wrote:
With a more detailed commit message:
Acked-by: Liviu Dudau
> Signed-off-by: Alexandru Gheorghe
> ---
> drivers/gpu/drm/arm/malidp_planes.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_planes.c
> b/drivers/gpu/drm/arm/malidp_planes.c
> index 29409a65d864..49c37f6dd63e 100644
> --- a/drivers/gpu/drm/arm/malidp_planes.c
> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> @@ -78,11 +78,8 @@ static void malidp_plane_reset(struct drm_plane *plane)
> kfree(state);
> plane->state = NULL;
> state = kzalloc(sizeof(*state), GFP_KERNEL);
> - if (state) {
> - state->base.plane = plane;
> - state->base.rotation = DRM_MODE_ROTATE_0;
> - plane->state = &state->base;
> - }
> + if (state)
> + __drm_atomic_helper_plane_reset(plane, &state->base);
> }
>
> static struct
> --
> 2.18.0
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107324] Radeon driver fails to install with modprobe: ERROR: could not insert 'radeon': Invalid argument
https://bugs.freedesktop.org/show_bug.cgi?id=107324 --- Comment #12 from jamesstewartmil...@gmail.com --- Is there any way to selectively swap out that portion of the driver for the inoffensive parts of code for the imac (and perhaps other problematic models) that I have? Is there any point in me investing time to learn to bisect and learn the coding specifics of plls and calculations etc? At the moment it is either do something like that, or put up with the vesa driver and cope with the memory loss (I use this machine for audio), or swap out the graphics card. In the last instance, do you know Christian, if it is possible to find a list of affected cards? I can exchange my radeon 4850 for a 6970M 2GB, increasing the ram, but there is no point at all, if it doesn't work with the radeon driver, and I will have to pick up my game, quite substantially as a programmer, if I want to edit that myself. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107328] radeon_gart_table_vram_pin takes 473 ms during ACPI S3 resume
https://bugs.freedesktop.org/show_bug.cgi?id=107328
Paul Menzel changed:
What|Removed |Added
Resolution|WONTFIX |INVALID
--- Comment #2 from Paul Menzel ---
Just as a follow-up, the long time seems to have been caused by ftrace.
With the patch below on top of drm-tip from this morning, it only takes 7 ms.
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index 1cef155cc933..f79a2f8b8d8e 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -175,10 +175,13 @@ int radeon_gart_table_vram_pin(struct radeon_device
*rdev)
/* We might have dropped some GART table updates while it
wasn't
* mapped, restore all entries
*/
+ DRM_INFO("GART: Restore entries: num cpu pages %u, num gpu
pages %u\n",
+ rdev->gart.num_cpu_pages,
rdev->gart.num_gpu_pages);
for (i = 0; i < rdev->gart.num_gpu_pages; i++)
radeon_gart_set_page(rdev, i,
rdev->gart.pages_entry[i]);
mb();
radeon_gart_tlb_flush(rdev);
+ DRM_INFO("GART: Done restoring entries\n");
}
return r;
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI
https://bugs.freedesktop.org/show_bug.cgi?id=105684 --- Comment #36 from jian-h...@endlessm.com --- Created attachment 140806 --> https://bugs.freedesktop.org/attachment.cgi?id=140806&action=edit dmesg of 4.18.0-rc6 Tested with Linux 4.18.0-rc6 kernel. It seems the amdgpu module could be loaded correctly. I tried over 20 times. The attachment is the full dmesg. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/10] drm/atomic: Add __drm_atomic_helper_plane_reset
On Tue, Jul 24, 2018 at 10:16:56AM +0200, Boris Brezillon wrote:
> On Tue, 24 Jul 2018 09:14:02 +0100
> Alexandru-Cosmin Gheorghe wrote:
>
> > On Tue, Jul 24, 2018 at 09:48:53AM +0200, Philipp Zabel wrote:
> > > Hi Alexandru,
> > >
> > > On Fri, 2018-07-20 at 22:15 +0100, Alexandru Gheorghe wrote:
> > > > There are a lot of drivers that subclass drm_plane_state, all of them
> > > > duplicate the code that links toghether the plane with plane_state.
> > > >
> > > > On top of that, drivers that enable core properties also have to
> > > > duplicate the code for initializing the properties to their default
> > > > values, which in all cases are the same as the defaults from core.
> > > >
> > > > Signed-off-by: Alexandru Gheorghe
> > > > ---
> > > > drivers/gpu/drm/drm_atomic_helper.c | 32 +
> > > > include/drm/drm_atomic_helper.h | 2 ++
> > > > 2 files changed, 25 insertions(+), 9 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > > index 8008a7de2e10..e1c6f101652e 100644
> > > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > @@ -3507,6 +3507,28 @@ void drm_atomic_helper_crtc_destroy_state(struct
> > > > drm_crtc *crtc,
> > > > }
> > > > EXPORT_SYMBOL(drm_atomic_helper_crtc_destroy_state);
> > > >
> > > > +/**
> > > > + * __drm_atomic_helper_plane_reset - resets planes state to default
> > > > values
> > > > + * @plane: plane object
> > > > + * @new_state: atomic plane state
> > > > + *
> > > > + * Initializes plane state to default. This is useful for drivers that
> > > > subclass
> > > > + * the plane state.
> > > > + */
> > > > +void __drm_atomic_helper_plane_reset(struct drm_plane *plane,
> > > > +struct drm_plane_state *state)
> > > > +{
> > > > + if (state) {
> > > > + state->plane = plane;
> > > > + state->rotation = DRM_MODE_ROTATE_0;
> > > > + /* Reset the alpha value to fully opaque if it matters
> > > > */
> > > > + if (plane->alpha_property)
> > > > + state->alpha = plane->alpha_property->values[1];
> > > > + }
> > >
> > > Is this function supposed to be callable with state == NULL ?
> > >
> > > > + plane->state = state;
> > >
> > > If so, the comment could mention that this sets plane->state to NULL if
> > > state == NULL, and a few of the call sites could be simplified.
> > >
> > > If not, I would remove the conditional if (state) {} part and also
> > > mention this in the comment.
> >
> > Yes, It's intended to be callable with null.
>
> May I ask why? I'd assume drivers that call this function to pass a
> non-NULL plane state. What's the use case for passing a NULL state here?
Drivers check it, drm_atomic_helper_plane_reset doesn't.
Looking at the existing __drm_atomic_helper_plane_* it seems they all
assume state not null, so I think it probably makes more sense to do
that for this function as well.
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107337] [CI][DRMTIP] igt@kms_3d - fail - Failed assertion: debugfs_fd != -1 / Last errno: 2, No such file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=107337 Chris Wilson changed: What|Removed |Added Resolution|--- |FIXED Component|DRM/Intel |IGT QA Contact|intel-gfx-bugs@lists.freede | |sktop.org | Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop |sktop.org |.org Status|NEW |RESOLVED --- Comment #1 from Chris Wilson --- commit 9b064015df14506b23cd2d7245a73e1b1d16ee1f (HEAD, upstream/master) Author: Chris Wilson Date: Mon Jul 23 14:35:09 2018 +0100 lib: Don't assert all KMS drivers support edid_override edid_override is a i915.ko debugfs feature; just skip any kms test that depends on being able to override the edid. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107337 Signed-off-by: Chris Wilson Reviewed-by: Katarzyna Dec -- 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 RESEND 1/2] drm/msm: call drm_atomic_helper_suspend() and drm_atomic_helper_resume()
On Tue, Jul 24, 2018 at 3:24 AM, Daniel Mack wrote:
> To make suspend and resume work on msm8916 platforms, call into the generic
> helpers and preserve the state across suspends.
>
> Signed-off-by: Daniel Mack
> ---
> I've sent these two small patches twice already in May, but I haven't
> gotten any feedback, not sure why.
These two are in msm-next (and will be in my next pull request in the
coming days)
Thanks
BR,
-R
>
> We're using these on a number of prototypes and they seem to do work
> just fine.
>
> drivers/gpu/drm/msm/msm_drv.c | 9 +
> drivers/gpu/drm/msm/msm_drv.h | 1 +
> 2 files changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index 0a3ea3034e39..cdbe9249bff2 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -907,16 +907,25 @@ static struct drm_driver msm_driver = {
> static int msm_pm_suspend(struct device *dev)
> {
> struct drm_device *ddev = dev_get_drvdata(dev);
> + struct msm_drm_private *priv = ddev->dev_private;
>
> drm_kms_helper_poll_disable(ddev);
>
> + priv->pm_state = drm_atomic_helper_suspend(ddev);
> + if (IS_ERR(priv->pm_state)) {
> + drm_kms_helper_poll_enable(ddev);
> + return PTR_ERR(priv->pm_state);
> + }
> +
> return 0;
> }
>
> static int msm_pm_resume(struct device *dev)
> {
> struct drm_device *ddev = dev_get_drvdata(dev);
> + struct msm_drm_private *priv = ddev->dev_private;
>
> + drm_atomic_helper_resume(ddev, priv->pm_state);
> drm_kms_helper_poll_enable(ddev);
>
> return 0;
> diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> index 0a653dd2e618..459d06a1ab9f 100644
> --- a/drivers/gpu/drm/msm/msm_drv.h
> +++ b/drivers/gpu/drm/msm/msm_drv.h
> @@ -155,6 +155,7 @@ struct msm_drm_private {
> struct shrinker shrinker;
>
> struct msm_vblank_ctrl vblank_ctrl;
> + struct drm_atomic_state *pm_state;
> };
>
> struct msm_format {
> --
> 2.14.3
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106707] [CI] igt@gem_exec_schedule@deep-* - fail - Failed assertion: __vgem_fence_signal(fd, fence) == 0
https://bugs.freedesktop.org/show_bug.cgi?id=106707 Chris Wilson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Chris Wilson --- commit 2884f91dd6d7682ea738ef6f0943cc591643dda2 (HEAD, upstream/master) Author: Chris Wilson Date: Fri Jul 20 12:29:30 2018 +0100 igt/gem_exec_schedule: Trim deep runtime Time the runtime for emitting deep dependency tree, while keeping it full of umpteen thousand requests. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106707 Signed-off-by: Chris Wilson Reviewed-by: Katarzyna Dec -- 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/sun4i: Use (struct drm_format_info) fields to determine if a format is yuv and multi planar or not.
On Mon, Jul 23, 2018 at 09:57:00AM +0100, Ayan Kumar Halder wrote: > We do not need sun4i_backend_format_is_packed_yuv422() / > sun4i_backend_format_is_planar_yuv() to determine if the format is yuv multi > planar > or not. (struct drm_format_info *)->is_yuv tells if the format is yuv or not. > And (struct drm_format_info *)->num_planes denotes the number of planes. > > This issue was identified during a review on a previous patch:- > https://lists.freedesktop.org/archives/dri-devel/2018-July/183840.html > > Signed-off-by: Ayan Kumar halder Applied, thanks! Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/7] drm: add simpledrm driver
Hey On request of Noralf, I picked up the patches and prepared v5. Works fine with Xorg, if configured according to: https://lists.freedesktop.org/archives/dri-devel/2014-January/052777.html If anyone knows how to make Xorg pick it up dynamically without such a static configuration, please let me know. Thanks David David Herrmann (7): x86/sysfb: add support for 64bit EFI lfb_base x86/sysfb: fix lfb_size calculation of/platform: expose of_platform_device_destroy() video: add generic framebuffer eviction drm: switch to sysfb_evict_conflicts() drm: add SimpleDRM driver drm/simpledrm: add fbdev fallback support ... Hi! I asked Noralf about this patch set recently, and he mentioned that this never made it any further than this patch series... Are there still any interest in getting this mainlined? Does the code exist in any repo anywhere? For my own part, this would be an awesome driver to have to resurrect some old hardware I have lying around... - Mads ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/18] Allwinner R40 HDMI refactoring
On Sun, Jul 22, 2018 at 04:43:56PM +0200, Jernej Škrabec wrote: > Hi Maxime, > > Dne sreda, 11. julij 2018 ob 10:30:36 CEST je Maxime Ripard napisal(a): > > On Tue, Jul 10, 2018 at 10:34:53PM +0200, Jernej Skrabec wrote: > > > This series fixes several issues found in R40 HDMI patch series after > > > it was applied. Conversation can be found here: > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2018-June/586011.htm > > > l > > > > > > Patches are based on latest linux-next (next-20180710) and are ordered > > > in such way that they don't break R40 HDMI at any time. Because of that > > > I suggest that whole series goes through drm-misc to preserve that order. > > > > > > I also tested those patches on H3 to make sure it doesn't break other > > > platforms. However, it would be nice to test for regressions also on > > > older SoCs (with DE1). > > > > > > Best regards, > > > Jernej > > > > Applied all patches but the patch 10, thanks! > > Maxime > > It seems that you forgot to merge some patches: > > [PATCH v2 12/18] drm/sun4i: tcon: Add another way for matching mixers with > tcon > [PATCH v2 13/18] drm/sun4i: tcon: Add support for R40 TCON > > Without them, R40 display pipeline can't work. > > Maybe they are in your spam folder? Thanks for telling me, I'm not quite sure what happened. I've applied them. Sorry, Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/10] drm/vc4: Use __drm_atomic_helper_plane_reset instead of copying the logic
On Tue, Jul 24, 2018 at 09:11:21AM +0100, Alexandru-Cosmin Gheorghe wrote: > Hi Maxime, > > On Tue, Jul 24, 2018 at 08:57:20AM +0200, Maxime Ripard wrote: > > On Fri, Jul 20, 2018 at 10:15:08PM +0100, Alexandru Gheorghe wrote: > > > Signed-off-by: Alexandru Gheorghe > > > --- > > > drivers/gpu/drm/vc4/vc4_plane.c | 4 +--- > > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/vc4/vc4_plane.c > > > b/drivers/gpu/drm/vc4/vc4_plane.c > > > index 9d7a36f148cf..688ad9bb0f08 100644 > > > --- a/drivers/gpu/drm/vc4/vc4_plane.c > > > +++ b/drivers/gpu/drm/vc4/vc4_plane.c > > > @@ -200,9 +200,7 @@ static void vc4_plane_reset(struct drm_plane *plane) > > > if (!vc4_state) > > > return; > > > > > > - plane->state = &vc4_state->base; > > > - plane->state->alpha = DRM_BLEND_ALPHA_OPAQUE; > > > - vc4_state->base.plane = plane; > > > + __drm_atomic_helper_plane_reset(plane, &vc4_state->base); > > > > For vc4, rcar-du, atmel-hlcdc and sun4i, you're changing the reset > > value of alpha from DRM_BLEND_ALPHA_OPAQUE to > > plane->alpha_property->values[1]. > > plane->alpha_property->values[1] holds the max value for alpha, and > it's initialized by the core to DRM_BLEND_ALPHA_OPAQUE. > > > > > This might or might not be a good idea, but you should definitely > > explain why. > > Would a commit message suffice? Or do you have other ideas? Yes, that would be enough. Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107328] radeon_gart_table_vram_pin takes 473 ms during ACPI S3 resume
https://bugs.freedesktop.org/show_bug.cgi?id=107328 Christian König changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #3 from Christian König --- (In reply to Paul Menzel from comment #2) > Just as a follow-up, the long time seems to have been caused by ftrace. > > With the patch below on top of drm-tip from this morning, it only takes 7 > ms. Interesting. I wasn't aware that ftrace could have such negative side effects. Anyway if somebody has a radeon in a box with halve a TB system memory he can probably live with a few ms resume time :) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99923] HITMAN (2016) having lighting and artefacting, and overly light room.
https://bugs.freedesktop.org/show_bug.cgi?id=99923 --- Comment #33 from Alex Smith --- We've had several user reports of this through our support, and reproduced it internally as well (on a 270X, which is our officially supported minimum spec). Seems to be specific to SI cards. Given that this has regressed since the original release of the game, is it possible to get a workaround into Mesa, e.g. disabling the load/store vectorizer like suggested for SI cards (perhaps just restricted to Hitman), until the issue is resolved in LLVM? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/atomic: Check old_plane_state->crtc in drm_atomic_helper_async_check()
Async plane update is supposed to work only when updating the FB or FB
position of an already enabled plane. That does not apply to requests
where the plane was previously disabled or assigned to a different
CTRC.
Check old_plane_state->crtc value to make sure async plane update is
allowed.
Fixes: fef9df8b5945 ("drm/atomic: initial support for asynchronous plane
update")
Cc:
Signed-off-by: Boris Brezillon
Reviewed-by: Eric Anholt
---
Changes in v2:
- Cc stable
- Add Eric's R-b
---
drivers/gpu/drm/drm_atomic_helper.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 866a2cc72ef6..f7ccfebd3ca8 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1555,7 +1555,8 @@ int drm_atomic_helper_async_check(struct drm_device *dev,
if (n_planes != 1)
return -EINVAL;
- if (!new_plane_state->crtc)
+ if (!new_plane_state->crtc ||
+ old_plane_state->crtc != new_plane_state->crtc)
return -EINVAL;
funcs = plane->helper_private;
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/atomic: Initialize variables in drm_atomic_helper_async_check() to make gcc happy
drm_atomic_helper_async_check() declares the plane, old_plane_state and
new_plane_state variables to iterate over all planes of the atomic
state and make sure only one plane is enabled.
Unfortunately gcc is not smart enough to figure out that the check on
n_planes is enough to guarantee that plane, new_plane_state and
old_plane_state are initialized.
Explicitly initialize those variables to NULL to make gcc happy.
Fixes: fef9df8b5945 ("drm/atomic: initial support for asynchronous plane
update")
Cc:
Signed-off-by: Boris Brezillon
Reviewed-by: Sean Paul
---
Changes in v2:
- Cc stable
- Add Sean's R-b
- Fix a typo in the commit message
---
drivers/gpu/drm/drm_atomic_helper.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index f7ccfebd3ca8..80be74df7ba6 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1538,8 +1538,9 @@ int drm_atomic_helper_async_check(struct drm_device *dev,
{
struct drm_crtc *crtc;
struct drm_crtc_state *crtc_state;
- struct drm_plane *plane;
- struct drm_plane_state *old_plane_state, *new_plane_state;
+ struct drm_plane *plane = NULL;
+ struct drm_plane_state *old_plane_state = NULL;
+ struct drm_plane_state *new_plane_state = NULL;
const struct drm_plane_helper_funcs *funcs;
int i, n_planes = 0;
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vc4: Reset ->{x, y}_scaling[1] when dealing with uniplanar formats
This is needed to ensure ->is_unity is correct when the plane was
previously configured to output a multi-planar format with scaling
enabled, and is then being reconfigured to output a uniplanar format.
Fixes: fc04023fafec ("drm/vc4: Add support for YUV planes.")
Cc:
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/vc4/vc4_plane.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 9d7a36f148cf..cfb50fedfa2b 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -320,6 +320,9 @@ static int vc4_plane_setup_clipping_and_scaling(struct
drm_plane_state *state)
vc4_state->x_scaling[0] = VC4_SCALING_TPZ;
if (vc4_state->y_scaling[0] == VC4_SCALING_NONE)
vc4_state->y_scaling[0] = VC4_SCALING_TPZ;
+ } else {
+ vc4_state->x_scaling[1] = VC4_SCALING_NONE;
+ vc4_state->y_scaling[1] = VC4_SCALING_NONE;
}
vc4_state->is_unity = (vc4_state->x_scaling[0] == VC4_SCALING_NONE &&
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCHv2 1/9] drm: Add support for extracting sync signal drive edge from videomode
Hi Tomi,
Thank you for the patch.
On Monday, 18 June 2018 16:22:34 EEST Tomi Valkeinen wrote:
> From: Peter Ujfalusi
>
> The sync in some panels needs to be driven by different edge of the pixel
> clock compared to data. This is reflected by the
> DISPLAY_FLAGS_SYNC_(POS|NEG)EDGE in videmode flags.
> Add similar similar definitions for bus_flags and convert the sync drive
> edge via drm_bus_flags_from_videomode().
>
> Signed-off-by: Peter Ujfalusi
> Signed-off-by: Tomi Valkeinen
> Signed-off-by: Jyri Sarha
Given "[PATCH 08/23] drm: Add display info bus flags to specify sync signals
clock edges" (https://patchwork.kernel.org/patch/10454713/),
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_modes.c | 15 +++
> include/drm/drm_connector.h | 4
> 2 files changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index e82b61e08f8c..1661bfc55687 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -659,10 +659,12 @@ EXPORT_SYMBOL_GPL(drm_display_mode_to_videomode);
> * drm_bus_flags_from_videomode - extract information about pixelclk and
> * DE polarity from videomode and store it in a separate variable
> * @vm: videomode structure to use
> - * @bus_flags: information about pixelclk and DE polarity will be stored
> here + * @bus_flags: information about pixelclk, sync and DE polarity will
> be stored + * here
> *
> - * Sets DRM_BUS_FLAG_DE_(LOW|HIGH) and DRM_BUS_FLAG_PIXDATA_(POS|NEG)EDGE
> - * in @bus_flags according to DISPLAY_FLAGS found in @vm
> + * Sets DRM_BUS_FLAG_DE_(LOW|HIGH), DRM_BUS_FLAG_PIXDATA_(POS|NEG)EDGE and
> + * DISPLAY_FLAGS_SYNC_(POS|NEG)EDGE in @bus_flags according to
> DISPLAY_FLAGS + * found in @vm
> */
> void drm_bus_flags_from_videomode(const struct videomode *vm, u32
> *bus_flags) {
> @@ -672,6 +674,11 @@ void drm_bus_flags_from_videomode(const struct
> videomode *vm, u32 *bus_flags) if (vm->flags &
> DISPLAY_FLAGS_PIXDATA_NEGEDGE)
> *bus_flags |= DRM_BUS_FLAG_PIXDATA_NEGEDGE;
>
> + if (vm->flags & DISPLAY_FLAGS_SYNC_POSEDGE)
> + *bus_flags |= DRM_BUS_FLAG_SYNC_POSEDGE;
> + if (vm->flags & DISPLAY_FLAGS_SYNC_NEGEDGE)
> + *bus_flags |= DRM_BUS_FLAG_SYNC_NEGEDGE;
> +
> if (vm->flags & DISPLAY_FLAGS_DE_LOW)
> *bus_flags |= DRM_BUS_FLAG_DE_LOW;
> if (vm->flags & DISPLAY_FLAGS_DE_HIGH)
> @@ -684,7 +691,7 @@ EXPORT_SYMBOL_GPL(drm_bus_flags_from_videomode);
> * of_get_drm_display_mode - get a drm_display_mode from devicetree
> * @np: device_node with the timing specification
> * @dmode: will be set to the return value
> - * @bus_flags: information about pixelclk and DE polarity
> + * @bus_flags: information about pixelclk, sync and DE polarity
> * @index: index into the list of display timings in devicetree
> *
> * This function is expensive and should only be used, if only one mode is
> to be diff --git a/include/drm/drm_connector.h
> b/include/drm/drm_connector.h index 675cc3f8cf85..8fa901637f00 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -290,6 +290,10 @@ struct drm_display_info {
> #define DRM_BUS_FLAG_DATA_MSB_TO_LSB (1<<4)
> /* data is transmitted LSB to MSB on the bus */
> #define DRM_BUS_FLAG_DATA_LSB_TO_MSB (1<<5)
> +/* drive sync on pos. edge */
> +#define DRM_BUS_FLAG_SYNC_POSEDGE(1<<6)
> +/* drive sync on neg. edge */
> +#define DRM_BUS_FLAG_SYNC_NEGEDGE(1<<7)
>
> /**
>* @bus_flags: Additional information (like pixel signal polarity) for
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] mm, oom: distinguish blockable mode for mmu notifiers
On Fri 20-07-18 17:09:02, Andrew Morton wrote:
[...]
> - Undocumented return value.
>
> - comment "failed to reap part..." is misleading - sounds like it's
> referring to something which happened in the past, is in fact
> referring to something which might happen in the future.
>
> - fails to call trace_finish_task_reaping() in one case
>
> - code duplication.
>
> - Increases mmap_sem hold time a little by moving
> trace_finish_task_reaping() inside the locked region. So sue me ;)
>
> - Sharing the finish: path means that the trace event won't
> distinguish between the two sources of finishing.
>
> Please take a look?
oom_reap_task_mm should return false when __oom_reap_task_mm return
false. This is what my patch did but it seems this changed by
http://www.ozlabs.org/~akpm/mmotm/broken-out/mm-oom-remove-oom_lock-from-oom_reaper.patch
so that one should be fixed.
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 104ef4a01a55..88657e018714 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -565,7 +565,7 @@ static bool oom_reap_task_mm(struct task_struct *tsk,
struct mm_struct *mm)
/* failed to reap part of the address space. Try again later */
if (!__oom_reap_task_mm(mm)) {
up_read(&mm->mmap_sem);
- return true;
+ return false;
}
pr_info("oom_reaper: reaped process %d (%s), now anon-rss:%lukB,
file-rss:%lukB, shmem-rss:%lukB\n",
On top of that the proposed cleanup looks as follows:
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 88657e018714..4e185a282b3d 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -541,8 +541,16 @@ bool __oom_reap_task_mm(struct mm_struct *mm)
return ret;
}
+/*
+ * Reaps the address space of the give task.
+ *
+ * Returns true on success and false if none or part of the address space
+ * has been reclaimed and the caller should retry later.
+ */
static bool oom_reap_task_mm(struct task_struct *tsk, struct mm_struct *mm)
{
+ bool ret = true;
+
if (!down_read_trylock(&mm->mmap_sem)) {
trace_skip_task_reaping(tsk->pid);
return false;
@@ -555,28 +563,28 @@ static bool oom_reap_task_mm(struct task_struct *tsk,
struct mm_struct *mm)
* down_write();up_write() cycle in exit_mmap().
*/
if (test_bit(MMF_OOM_SKIP, &mm->flags)) {
- up_read(&mm->mmap_sem);
trace_skip_task_reaping(tsk->pid);
- return true;
+ goto out_unlock;
}
trace_start_task_reaping(tsk->pid);
/* failed to reap part of the address space. Try again later */
- if (!__oom_reap_task_mm(mm)) {
- up_read(&mm->mmap_sem);
- return false;
- }
+ ret = __oom_reap_task_mm(mm);
+ if (!ret)
+ goto out_finish;
pr_info("oom_reaper: reaped process %d (%s), now anon-rss:%lukB,
file-rss:%lukB, shmem-rss:%lukB\n",
task_pid_nr(tsk), tsk->comm,
K(get_mm_counter(mm, MM_ANONPAGES)),
K(get_mm_counter(mm, MM_FILEPAGES)),
K(get_mm_counter(mm, MM_SHMEMPAGES)));
+out_finish:
+ trace_finish_task_reaping(tsk->pid);
+out_unlock:
up_read(&mm->mmap_sem);
- trace_finish_task_reaping(tsk->pid);
- return true;
+ return ret;
}
#define MAX_OOM_REAP_RETRIES 10
--
Michal Hocko
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCHv2 2/9] dt-bindings: display/ti: add k2g-dss bindings
Hi Tomi, Thank you for the patch. On Monday, 18 June 2018 16:22:35 EEST Tomi Valkeinen wrote: > Add DT bindings for Texas Instruments K2G SoC Display Subsystem. The DSS > is quite simple, with a single plane and a single output. > > Signed-off-by: Tomi Valkeinen > Cc: devicet...@vger.kernel.org > Reviewed-by: Rob Herring > --- > .../devicetree/bindings/display/ti/ti,k2g-dss.txt | 15 +++ > 1 file changed, 15 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/ti/ti,k2g-dss.txt > > diff --git a/Documentation/devicetree/bindings/display/ti/ti,k2g-dss.txt > b/Documentation/devicetree/bindings/display/ti/ti,k2g-dss.txt new file mode > 100644 > index ..1af11425eda3 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/ti/ti,k2g-dss.txt > @@ -0,0 +1,15 @@ > +Texas Instruments K2G Display Subsystem > +=== > + > +Required properties: > +- compatible: "ti,k2g-dss" > +- reg: address and length of the register spaces for DSS submodules > +- reg-names: "cfg", "common", "vid1", "ovr1", "vp1" When seeing multiple register ranges for a DT node I always suspect that we describe multiple IP cores that could be better modeled as independent nodes. What prompted you not to model the DISPC as a separate DT node (possibly a child of the DSS DT node) ? Furthermore, "cfg" corresponds to the DSS registers, so I wonder whether it shouldn't be named "dss". Similarly, "common" really sounds like DSS common registers, while it relates to the DISPC. > +- clocks: phandle to fclk and vp1 clocks > +- clock-names: "fck", "vp1" > +- interrupts: phandle to the DISPC interrupt > + > +The DSS outputs are described using the device graphs as documented in > +Documentation/devicetree/bindings/graph.txt. K2G DSS has a single DPI > output as > +port 0. Both SPRUHY8H and SPRSP07D document a DPI output and a DBI output. Am I looking at the wrong document ? > + Extra blank line ? -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbdev: Distinguish between interlaced and progressive modes
On Wednesday, July 04, 2018 09:08:48 PM Fredrik Noring wrote:
> Hi Bartlomiej,
>
> > > With this change fb_find_mode can match interlaced and progressive
> > > modes equally well, and distinguish between for example 1920x1080i
> > > and 1920x1080p.
> > >
> > > Signed-off-by: Fredrik Noring
> >
> > Could you please give some examples of use cases that need this change
> > (i.e. which fbdev drivers need it for which modes etc.)?
>
> I discovered the problem when developing a frame buffer driver for the
> PlayStation 2 (not yet merged), using the following video modes for the
> PlayStation 3 in drivers/video/fbdev/ps3fb.c:
>
> }, {
> /* 1080if */
> "1080if", 50, 1920, 1080, 13468, 148, 484, 36, 4, 88, 5,
> FB_SYNC_BROADCAST, FB_VMODE_INTERLACED
> }, {
> /* 1080pf */
> "1080pf", 50, 1920, 1080, 6734, 148, 484, 36, 4, 88, 5,
> FB_SYNC_BROADCAST, FB_VMODE_NONINTERLACED
> },
>
> In ps3fb_probe, the mode_option module parameter is used with fb_find_mode
> but it can only select the interlaced variant of 1920x1080 since the loop
> matching the modes does not take the difference between interlaced and
> progressive modes into account.
>
> In short, without the patch, progressive 1920x1080 cannot be chosen as a
> mode_option parameter since fb_find_mode (falsely) thinks interlace is a
> perfect match.
Patch queued for 4.19 (with the above explanation used as patch description),
thanks!
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] dt-bindings: display: add devicetree bindings for pxa300-gcu
On Wednesday, July 04, 2018 09:35:01 PM Daniel Mack wrote: > This patch adds the binding documentation for the pxa300 gcu. > > Signed-off-by: Daniel Mack Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] video: fbdev: pxa3xx_gcu: add devicetree bindings
On Wednesday, July 04, 2018 09:35:02 PM Daniel Mack wrote: > Add a device tree match table for this hardware graphics acceleration > driver so it can be used by pxa3xx boards booted with a devicetree. > > Signed-off-by: Daniel Mack Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] video: fbdev: pxafb: switch to devm_* API
On Sunday, June 24, 2018 05:38:15 PM Daniel Mack wrote: > This helps us clean up the probe() and remove() implementations. > > Signed-off-by: Daniel Mack Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] video: fbdev: pxafb: clear allocated memory for video modes
On Sunday, June 24, 2018 05:38:14 PM Daniel Mack wrote: > When parsing the video modes from DT properties, make sure to zero out > memory before using it. This is important because not all fields in the mode > struct are explicitly initialized, even though they are used later on. > > Fixes: 420a488278e86 (video: fbdev: pxafb: initial devicetree conversion) > Reviewed-by: Robert Jarzmik > Signed-off-by: Daniel Mack Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] video: fbdev: pxafb: handle errors from pxafb_init_fbinfo() correctly
On Sunday, June 24, 2018 05:38:16 PM Daniel Mack wrote: > pxafb_init_fbinfo() can not only report errors caused by failed > allocations but also when the clock can't be found. > > To fix this, return an error pointer instead of NULL in case of errors, > and up-chain the result. > > Signed-off-by: Daniel Mack Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] video: fbdev: pxafb: Add support for lcd-supply regulator
On Sunday, June 24, 2018 05:38:17 PM Daniel Mack wrote: > Optionally obtain a lcd-supply regulator during probe and use it in > __pxafb_lcd_power() to switch the power supply of LCD panels. > > This helps boards booted from DT to control such voltages without > callbacks. > > Signed-off-by: Daniel Mack Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] video: fbdev: pxafb: clear allocated memory for video modes
On Monday, July 09, 2018 07:12:50 AM Daniel Mack wrote: > Hi Bartlomiej, Hi, > Should I resend with Robert's Reviewed-bys again? I'd like to get this > merged for 4.19 if possible. No need for resend, I added Robert's tags while applying your patches. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] tests/modetest: Add modetest_atomic tool
2018-07-23 18:30 GMT+02:00 Eric Engestrom :
> On Friday, 2018-07-20 13:33:29 +0200, Benjamin Gaignard wrote:
>> This is a modetest like tool but using atomic API.
>>
>> With modetest_atomic it is mandatory to specify a mode ("-s")
>> and a plane ("-P") to display a pattern on screen.
>>
>> "-v" does a loop swapping between two framebuffers for each
>> active planes.
>>
>> modetest_atomic doesn't offer cursor support
>>
>> Signed-off-by: Benjamin Gaignard
>> ---
>>
>> The code is based on modetest and keep most of it infrastructure
>> like arguments parsing, finding properties id from their name,
>> resources dumping or the general way of working.
>> It duplicates modetest code but adding compilation flags or
>> conditional tests everywhere in modetest would have made it
>> more complex and unreadable.
>
> I don't have an opinion on whether duplicating the test is the right
> thing, but if you do, please also duplicate the lines in
> tests/modetest/meson.build :)
You are right, I will also make it compile for Android.
>
>>
>> Creating modetest_atomic could allow to test atomic API without
>> need to use "big" frameworks like weston, drm_hwcomposer or igt
>> with all their dependencies.
>> kmscube could also be used to test atomic API but it need EGL.
>>
>> It have been tested (only) on stm driver with one or two planes
>> actived.
>>
>> tests/modetest/Makefile.am | 13 +-
>> tests/modetest/Makefile.sources |7 +
>> tests/modetest/modetest_atomic.c | 1546
>> ++
>> 3 files changed, 1564 insertions(+), 2 deletions(-)
>> create mode 100644 tests/modetest/modetest_atomic.c
>>
>> diff --git a/tests/modetest/Makefile.am b/tests/modetest/Makefile.am
>> index 4b296c83..8f697bb3 100644
>> --- a/tests/modetest/Makefile.am
>> +++ b/tests/modetest/Makefile.am
>> @@ -10,10 +10,12 @@ AM_CFLAGS += \
>>
>> if HAVE_INSTALL_TESTS
>> bin_PROGRAMS = \
>> - modetest
>> + modetest \
>> + modetest_atomic
>> else
>> noinst_PROGRAMS = \
>> - modetest
>> + modetest \
>> + modetest_atomic
>> endif
>>
>> modetest_SOURCES = $(MODETEST_FILES)
>> @@ -22,3 +24,10 @@ modetest_LDADD = \
>> $(top_builddir)/libdrm.la \
>> $(top_builddir)/tests/util/libutil.la \
>> $(CAIRO_LIBS)
>> +
>> +modetest_atomic_SOURCES = $(MODETEST_ATOMIC_FILES)
>> +
>> +modetest_atomic_LDADD = \
>> + $(top_builddir)/libdrm.la \
>> + $(top_builddir)/tests/util/libutil.la \
>> + $(CAIRO_LIBS)
>> diff --git a/tests/modetest/Makefile.sources
>> b/tests/modetest/Makefile.sources
>> index 399af0df..0a1df4c0 100644
>> --- a/tests/modetest/Makefile.sources
>> +++ b/tests/modetest/Makefile.sources
>> @@ -4,3 +4,10 @@ MODETEST_FILES := \
>> cursor.c \
>> cursor.h \
>> modetest.c
>> +
>> +MODETEST_ATOMIC_FILES := \
>> + buffers.c \
>> + buffers.h \
>> + cursor.c \
>> + cursor.h \
>> + modetest_atomic.c
>> diff --git a/tests/modetest/modetest_atomic.c
>> b/tests/modetest/modetest_atomic.c
>> new file mode 100644
>> index ..8c877860
>> --- /dev/null
>> +++ b/tests/modetest/modetest_atomic.c
>> @@ -0,0 +1,1546 @@
>> +/*
>> + * DRM based mode setting test program
>> + * Copyright 2008 Tungsten Graphics
>> + * Jakob Bornecrantz
>> + * Copyright 2008 Intel Corporation
>> + * Jesse Barnes
>> + *
>> + * Permission is hereby granted, free of charge, to any person obtaining a
>> + * copy of this software and associated documentation files (the
>> "Software"),
>> + * to deal in the Software without restriction, including without limitation
>> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
>> + * and/or sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be included
>> in
>> + * all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
>> OR
>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
>> THE
>> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
>> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
>> DEALINGS
>> + * IN THE SOFTWARE.
>> + */
>> +
>> +/*
>> + * This fairly simple test program dumps output in a similar format to the
>> + * "xrandr" tool everyone knows & loves. It's necessarily slightly
>> different
>> + * since the kernel separates outputs into encoder and connector structures,
>> + * each with their own unique ID. The program also allows test testing of
>> the
>> + * memory management and mode setting APIs by allowing the user to specify a
>> + * connector and mode to use for mode setting. If all wo
Re: [PATCH] video: fbdev: fsl-diu-fb: Remove VLA usage
On Saturday, June 30, 2018 10:59:15 AM Timur Tabi wrote: > On 6/29/18 1:46 PM, Kees Cook wrote: > > In the quest to remove all stack VLA usage from the kernel[1], this moves > > the buffer off the stack (since it could be as much as 1024 bytes), and > > uses a new area in the cursor data structure. Additionally adds missed > > documentation and removes redundant assignments. > > > > [1]https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com > > > > Signed-off-by: Kees Cook > > Acked-by: Timur Tabi Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 fbdev-for-next 1/2] fbcon: introduce for_each_registered_fb() helper
On Saturday, June 30, 2018 03:29:49 PM Yisheng Xie wrote:
> Following pattern is often used:
>
> for (i = 0; i < FB_MAX; i++) {
> if (registered_fb[i]) {
> ...
> }
> }
>
> Therefore, as Andy's suggestion, for_each_registered_fb() helper can
> be introduced to make the code easier to read and write by reducing
> indentation level. It also saves few lines of code in each occurrence.
>
> This patch convert all part here at the same time.
>
> Suggested-by: Andy Shevchenko
> Signed-off-by: Yisheng Xie
Patch queued for 4.19, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 fbdev-for-next 2/2] fbdev: fix typo in comment
On Saturday, June 30, 2018 03:30:48 PM Yisheng Xie wrote: > change beeng to being and occured to occurred. > > Signed-off-by: Yisheng Xie Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video/console/vgacon: Print big fat warning with nomodeset
On Monday, July 02, 2018 05:04:40 PM Lyude Paul wrote: > It's been a pretty good while since kernel modesetting was introduced. > It has almost entirely replaced previous solutions which required > userspace modesetting, and I can't even recall any drivers off the top > of my head for modern day hardware that don't only support one or the > other. Even nvidia's ugly blob does not require the use of nomodeset, > and only requires that nouveau be blacklisted. > > Effectively, the only thing nomodeset does in the year 2018 is disable > your graphics drivers. Since VESA is a thing, this will give many users > the false impression that they've actually fixed an issue they were > having with their machine simply because the laptop will boot up to a > degraded GUI. This of course, is never actually the case. > > Things get even worse when you consider that there's still an enormous > amount of tutorials users find on the internet that still suggest adding > nomodeset, along with various users who have been around long enough to > still suggest it. > > There really isn't any legitimate reason I can see for this to be an > option that's used by anyone else other then developers, or properly > informed users. So, let's end the confusion and start printing warnings > whenever it's enabled. > > Signed-off-by: Lyude Paul Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: metronomefb: fix some off by one bugs
On Tuesday, July 03, 2018 03:28:13 PM Dan Carpenter wrote: > The "mem" buffer has "size" bytes. The ">" should be ">=" to prevent > reading one character beyond the end of the array. > > Signed-off-by: Dan Carpenter Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 0/3] Add Colorspace connector property interface
This patch series creates a new connector property to program colorspace to sink devices. Modern sink devices support more than 1 type of colorspace like 601, 709, BT2020 etc. This helps to switch based on content type which is to be displayed. The decision lies with compositors as to in which scenarios, a particular colorspace will be picked. This will be helpful mostly to switch to higher gamut colorspaces like BT2020 when the media content is encoded as BT2020. Thereby giving a good visual experience to users. The expectation from userspace is that it should parse the EDID and get supported colorspaces. Use this property and switch to the one supported. Kernel will not give the supported colorspaces since this is panel dependant and our curremt property infrastructure is not supporting it. Have tested this using xrandr by using below command: xrandr --output HDMI2 --set "Colorspace" "BT2020_rgb" Please provide comments on this current approach. This is just an RFC to get some feedback. Will refine the series based on inputs and feedback. Uma Shankar (3): drm: Add colorspace property drm/i915: Attach colorspace property and enable modeset drm/i915: Set colorspace by enabling Infoframe drivers/gpu/drm/drm_atomic.c| 4 drivers/gpu/drm/drm_connector.c | 31 +++ drivers/gpu/drm/i915/intel_atomic.c | 1 + drivers/gpu/drm/i915/intel_hdmi.c | 5 + include/drm/drm_connector.h | 7 +++ include/drm/drm_mode_config.h | 6 ++ include/uapi/drm/drm_mode.h | 11 +++ 7 files changed, 65 insertions(+) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 2/3] drm/i915: Attach colorspace property and enable modeset
This patch attaches the colorspace connector property to the hdmi connector. Based on colorspace change, modeset will be triggered to switch to new colorspace. Signed-off-by: Uma Shankar --- drivers/gpu/drm/i915/intel_atomic.c | 1 + drivers/gpu/drm/i915/intel_hdmi.c | 3 +++ 2 files changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_atomic.c b/drivers/gpu/drm/i915/intel_atomic.c index b04952b..8e7d540 100644 --- a/drivers/gpu/drm/i915/intel_atomic.c +++ b/drivers/gpu/drm/i915/intel_atomic.c @@ -125,6 +125,7 @@ int intel_digital_connector_atomic_check(struct drm_connector *conn, */ if (new_conn_state->force_audio != old_conn_state->force_audio || new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb || + new_state->colorspace != old_state->colorspace || new_conn_state->base.picture_aspect_ratio != old_conn_state->base.picture_aspect_ratio || new_conn_state->base.content_type != old_conn_state->base.content_type || new_conn_state->base.scaling_mode != old_conn_state->base.scaling_mode) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index d06cf42..7fb96e2 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -2110,6 +2110,9 @@ static void intel_hdmi_destroy(struct drm_connector *connector) intel_attach_broadcast_rgb_property(connector); intel_attach_aspect_ratio_property(connector); drm_connector_attach_content_type_property(connector); + drm_object_attach_property(&connector->base, + connector->dev->mode_config.colorspace_property, + EXTENDED_COLORIMETRY_XV_YCC_601); connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE; } -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 1/3] drm: Add colorspace property
This patch adds a colorspace property, enabling
userspace to switch to various supported colorspaces.
This will help enable BT2020 along with other colorspaces.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_atomic.c| 4
drivers/gpu/drm/drm_connector.c | 31 +++
include/drm/drm_connector.h | 7 +++
include/drm/drm_mode_config.h | 6 ++
include/uapi/drm/drm_mode.h | 11 +++
5 files changed, 59 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 3eb061e..f065e6f 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1397,6 +1397,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
state->picture_aspect_ratio = val;
} else if (property == config->content_type_property) {
state->content_type = val;
+ } else if (property == config->colorspace_property) {
+ state->colorspace = val;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
} else if (property == connector->content_protection_property) {
@@ -1502,6 +1504,8 @@ static void drm_atomic_connector_print_state(struct
drm_printer *p,
*val = state->picture_aspect_ratio;
} else if (property == config->content_type_property) {
*val = state->content_type;
+ } else if (property == config->colorspace_property) {
+ *val = state->colorspace;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
} else if (property == connector->content_protection_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 5ada064..cfe1d79 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -805,6 +805,25 @@ int drm_display_info_set_bus_formats(struct
drm_display_info *info,
};
DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
+static const struct drm_prop_enum_list colorspace[] = {
+ /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+ { EXTENDED_COLORIMETRY_XV_YCC_601, "601" },
+ /* High Definition Colorimetry based on IEC 61966-2-4 */
+ { EXTENDED_COLORIMETRY_XV_YCC_709, "709" },
+ /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
+ { EXTENDED_COLORIMETRY_S_YCC_601, "s601" },
+ /* Colorimetry based on IEC 61966-2-5 [33] */
+ { EXTENDED_COLORIMETRY_ADOBE_YCC_601, "adobe601" },
+ /* Colorimetry based on IEC 61966-2-5 */
+ { EXTENDED_COLORIMETRY_ADOBE_RGB, "adobe_rgb" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { EXTENDED_COLORIMETRY_BT2020_RGB, "BT2020_rgb" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { EXTENDED_COLORIMETRY_BT2020_YCC, "BT2020_ycc" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { EXTENDED_COLORIMETRY_BT2020_CYCC, "BT2020_cycc" },
+};
+
/**
* DOC: standard connector properties
*
@@ -951,6 +970,12 @@ int drm_display_info_set_bus_formats(struct
drm_display_info *info,
* can also expose this property to external outputs, in which case they
* must support "None", which should be the default (since external screens
* have a built-in scaler).
+ *
+ * colorspace:
+ * This property helps select a suitable colorspace based on the sink
+ * capability. Modern sink devices support wider gamut like BT2020.
+ * This helps switch to BT2020 mode if the BT2020 encoded video stream
+ * is being played by the user, same for any other colorspace.
*/
int drm_connector_create_standard_properties(struct drm_device *dev)
@@ -999,6 +1024,12 @@ int drm_connector_create_standard_properties(struct
drm_device *dev)
return -ENOMEM;
dev->mode_config.non_desktop_property = prop;
+ prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM, "Colorspace",
+ colorspace, ARRAY_SIZE(colorspace));
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.colorspace_property = prop;
+
return 0;
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index a5179eb..306b536 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -443,6 +443,13 @@ struct drm_connector_state {
unsigned int content_protection;
/**
+* @colorspace: Connector property to request colorspace
+* change. This is most commonly used to switch to wider color
+* gamuts like BT2020.
+*/
+ enum extended_colorimetry colorspace;
+
+ /**
* @writeback_job: Writeback job for writeback connectors
*
* Holds the framebuffer and out-fence for a writeback connector. As
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index a0b202e..3afe30b
[RFC 3/3] drm/i915: Set colorspace by enabling Infoframe
Based on colorspace property value create an infoframe with appropriate colorspace. This can be used to send an infoframe packet with proper colorspace value set which will help to enable wider color gamut like BT2020 on sink. Signed-off-by: Uma Shankar --- drivers/gpu/drm/i915/intel_hdmi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 7fb96e2..319da1b 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -491,6 +491,8 @@ static void intel_hdmi_set_avi_infoframe(struct drm_encoder *encoder, else frame.avi.colorspace = HDMI_COLORSPACE_RGB; + frame.avi.extended_colorimetry = conn_state->colorspace; + drm_hdmi_avi_infoframe_quant_range(&frame.avi, adjusted_mode, crtc_state->limited_color_range ? HDMI_QUANTIZATION_RANGE_LIMITED : -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/10] Add helper for plane reset
On 2018-07-20 05:14 PM, Alexandru Gheorghe wrote: > Drivers that subclass drm_plane need to copy the logic for linking the > drm_plane with its state and to initialize core properties to their > default values. E.g (alpha and rotation) > > Having a helper to reset the plane_state makes sense because of multiple > reasons: > 1. Eliminate code duplication. > 2. Add a single place for initializing core properties to their > default values, no need for driver to do it if what the helper sets > makes sense for them. > 3. No need to debug the driver when you enable a core property and > observe it doesn't have a proper default value. > > Tested with mali-dp the other drivers are just built-tested. > For some reason I lost 02/10 hence I'm replying to the cover letter. Patches 1 & 2 are Reviewed-by: Harry Wentland Harry > > Alexandru Gheorghe (10): > drm/atomic: Add __drm_atomic_helper_plane_reset > drm/amd/display: Use __drm_atomic_helper_plane_reset instead of > copying the logic > drm: mali-dp: Use __drm_atomic_helper_plane_reset instead of copying > the logic > drm: atmel-hlcdc: Use __drm_atomic_helper_plane_reset instead of > copying the logic > drm/exynos: Use __drm_atomic_helper_plane_reset instead of copying the > logic > drm/imx: Use __drm_atomic_helper_plane_reset instead of copying the > logic > drm: rcar-du: Use __drm_atomic_helper_plane_reset instead of copying > the logic > drm/sun4i: Use __drm_atomic_helper_plane_reset instead of copying the > logic > drm/vc4: Use __drm_atomic_helper_plane_reset instead of copying the > logic > drm/vmwgfx: Use __drm_atomic_helper_plane_reset instead of copying the > logic > > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 ++-- > drivers/gpu/drm/arm/malidp_planes.c | 7 ++-- > .../gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 5 +-- > drivers/gpu/drm/drm_atomic_helper.c | 32 +-- > drivers/gpu/drm/exynos/exynos_drm_plane.c | 3 +- > drivers/gpu/drm/imx/ipuv3-plane.c | 8 ++--- > drivers/gpu/drm/rcar-du/rcar_du_plane.c | 4 +-- > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 4 +-- > drivers/gpu/drm/sun4i/sun4i_layer.c | 4 +-- > drivers/gpu/drm/vc4/vc4_plane.c | 4 +-- > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 +-- > include/drm/drm_atomic_helper.h | 2 ++ > 12 files changed, 39 insertions(+), 45 deletions(-) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107309] libGL error: MESA-LOADER: failed to retrieve device information on virgl
https://bugs.freedesktop.org/show_bug.cgi?id=107309 --- Comment #1 from Emil Velikov --- The message is harmless since Mesa falls back to use the DRM driver name. That said, a slightly better (I'm obviously biased) solution has been on the list for ~month [1]. Just double-checked and pushed it to master. [1] https://lists.freedesktop.org/archives/dri-devel/2018-June/181067.html -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107309] libGL error: MESA-LOADER: failed to retrieve device information on virgl
https://bugs.freedesktop.org/show_bug.cgi?id=107309 Emil Velikov changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm: mark PM functions as __maybe_unused
The suspend/resume functions are not referenced when power
management is disabled:
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c:1288:12: error: 'dpu_runtime_resume'
defined but not used [-Werror=unused-function]
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c:1261:12: error: 'dpu_runtime_suspend'
defined but not used [-Werror=unused-function]
This marks them as __maybe_unused to let the compiler
drop the functions without complaining.
Fixes: 591225291ca2 ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 8d4678d29cc7..1c0838801e78 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1258,7 +1258,7 @@ static int dpu_dev_remove(struct platform_device *pdev)
return 0;
}
-static int dpu_runtime_suspend(struct device *dev)
+static int __maybe_unused dpu_runtime_suspend(struct device *dev)
{
int rc = -1;
struct platform_device *pdev = to_platform_device(dev);
@@ -1285,7 +1285,7 @@ static int dpu_runtime_suspend(struct device *dev)
return rc;
}
-static int dpu_runtime_resume(struct device *dev)
+static int __maybe_unused dpu_runtime_resume(struct device *dev)
{
int rc = -1;
struct platform_device *pdev = to_platform_device(dev);
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbdev: fix modedb docs in fb_find_mode
On Thursday, July 05, 2018 03:52:17 PM Daniel Vetter wrote: > Fix up the indenting that confused sphinx. To make sure we > don't have to make the examples unreadable with escaping just > put them in as block quotes, that seems the simplest solution. > > Cc: Bartlomiej Zolnierkiewicz > Cc: linux-fb...@vger.kernel.org > Signed-off-by: Daniel Vetter Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: goldfishfb: fix memory leak on driver remove
On Friday, July 06, 2018 03:04:22 PM Anton Vasilyev wrote: > goldfish_fb_probe() allocates memory for fb, but goldfish_fb_remove() does > not have deallocation of fb, which leads to memory leak on probe/remove. > > The patch adds deallocation into goldfish_fb_remove(). > > Found by Linux Driver Verification project (linuxtesting.org). > > Signed-off-by: Anton Vasilyev Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] omapfb: rename omap2 module to omap2fb.ko
On Monday, July 09, 2018 12:02:16 AM Tony Lindgren wrote: > * Arnd Bergmann [180706 12:39]: > > In a kernel configuration with both CONFIG_FB_OMAP=m and CONFIG_FB_OMAP2=m, > > Kbuild fails to point out that we have two modules with the same name > > (omapfb.ko), > > but instead fails with a cryptic error message like: > > > > ERROR: "omapfb_register_panel" [drivers/video/fbdev/omap/lcd_osk.ko] > > undefined! > > > > This can now happen when building a randconfig kernel with > > CONFIG_ARCH_OMAP1, > > as the omap1 fbdev driver depends on that, whiel the omap2 fbdev driver can > > now be built anywhere with CONFIG_COMPILE_TEST. > > > > The solution is to rename one of the two modules, so for consistency with > > the directory naming I decided to rename the omap2 version to omap2fb.ko. > > Sounds good to me: > > Acked-by: Tony Lindgren Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbdev/via: fix defined but not used warning
On Saturday, July 07, 2018 08:29:36 AM Randy Dunlap wrote: > From: Randy Dunlap > > Fix a build warning in viafbdev.c when CONFIG_PROC_FS is not enabled > by marking the unused function as __maybe_unused. > > ../drivers/video/fbdev/via/viafbdev.c:1471:12: warning: > 'viafb_sup_odev_proc_show' defined but not used [-Wunused-function] > > Signed-off-by: Randy Dunlap > Cc: Florian Tobias Schandinat > Cc: linux-fb...@vger.kernel.org > Cc: Bartlomiej Zolnierkiewicz > Cc: dri-devel@lists.freedesktop.org Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbdev: fbmem: mark expected switch fall-through
On Monday, July 09, 2018 04:36:08 PM Gustavo A. R. Silva wrote: > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > where we are expecting to fall through. > > Signed-off-by: Gustavo A. R. Silva Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] omapfb: Mark expected switch fall-throughs
On Monday, July 09, 2018 05:04:36 PM Gustavo A. R. Silva wrote: > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > where we are expecting to fall through. > > Signed-off-by: Gustavo A. R. Silva Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: mark expected switch fall-throughs
On Monday, July 09, 2018 05:41:45 PM Gustavo A. R. Silva wrote: > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > where we are expecting to fall through. > > Signed-off-by: Gustavo A. R. Silva Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] console: Replace #if 1 with a bool to ignore
On Thursday, July 12, 2018 09:29:38 AM Steven Rostedt wrote: > > From: Steven Rostedt (VMware) > > There's been discussion on the fb list about the addition of > WARN_CONSOLE_UNLOCKED() inside the fb code. The complaint is that when > the fb module is loaded with lockless_register_fb the console lock is > not taken for debugging reasons. With the addition of > WARN_CONSOLE_UNLOCK() within the fb code, this causes the console to > fill up with warnings when trying to debug the fb driver. > > There's also a #if 1 that enables the warning which was added before > git history, and we look down on constant #if's in the kernel nowadays > anyway. > > Remove the #if 1 and add a ignore_console_lock_warning boolean that can > be set by drivers to ignore the warning in order to do debugging. > > Link: http://lkml.kernel.org/r/717e6337-e7a6-7a92-1c1b-8929a2569...@suse.de > Reviewed-by: Hans de Goede > Acked-by: Sergey Senozhatsky > Signed-off-by: Steven Rostedt (VMware) Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] console: Replace #if 1 with a bool to ignore
On Tuesday, July 24, 2018 06:13:19 PM Bartlomiej Zolnierkiewicz wrote: > On Thursday, July 12, 2018 09:29:38 AM Steven Rostedt wrote: > > > > From: Steven Rostedt (VMware) > > > > There's been discussion on the fb list about the addition of > > WARN_CONSOLE_UNLOCKED() inside the fb code. The complaint is that when > > the fb module is loaded with lockless_register_fb the console lock is > > not taken for debugging reasons. With the addition of > > WARN_CONSOLE_UNLOCK() within the fb code, this causes the console to > > fill up with warnings when trying to debug the fb driver. > > > > There's also a #if 1 that enables the warning which was added before > > git history, and we look down on constant #if's in the kernel nowadays > > anyway. > > > > Remove the #if 1 and add a ignore_console_lock_warning boolean that can > > be set by drivers to ignore the warning in order to do debugging. > > > > Link: http://lkml.kernel.org/r/717e6337-e7a6-7a92-1c1b-8929a2569...@suse.de > > Reviewed-by: Hans de Goede > > Acked-by: Sergey Senozhatsky > > Signed-off-by: Steven Rostedt (VMware) > > Patch queued for 4.19, thanks. Dequeued, I've just noticed a newer patch from Thomas for this issue (I plan to apply it later this week). Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/dp: add extended receiver capability field present bit
On Mon, Jul 23, 2018 at 02:27:34PM -0700, matthew.s.atw...@intel.com wrote: > From: Matt Atwood > > This bit was added to DP Training Aux RD interval with DP 1.3. Via > descriptiion of the spec this field indicates the panels true > capabilities are described in DPCD address space 02200h through 022FFh. > > v2: version comment update > v3: version comment correction, commit message update > v4: white space correction I'm afraid the wrong space that I had mentioned it is still there s/"(1 << 7)/* DP 1.3 */"/"(1 << 7) /* DP 1.3 *"/g > > Signed-off-by: Matt Atwood > --- > include/drm/drm_dp_helper.h | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index c01564991a9f..44aaefdc8448 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -123,8 +123,9 @@ > # define DP_FRAMING_CHANGE_CAP (1 << 1) > # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher > */ > > -#define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */ > -# define DP_TRAINING_AUX_RD_MASK0x7F/* XXX 1.2? */ > +#define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */ > +# define DP_TRAINING_AUX_RD_MASK0x7F/* DP 1.3 */ > +# define DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT (1 << 7)/* DP 1.3 */ ^ here > > #define DP_ADAPTER_CAP 0x00f /* 1.2 */ > # define DP_FORCE_LOAD_SENSE_CAP (1 << 0) > -- > 2.17.1 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/i915: implement EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT
On Mon, Jul 23, 2018 at 02:27:35PM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood
>
> According to DP spec (2.9.3.1 of DP 1.4) if
> EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT is set the addresses in DPCD
> 02200h through 0220Fh shall contain the DPRX's true capability. These
> values will match 0h through Fh, except for DPCD_REV,
> MAX_LINK_RATE, DOWN_STREAM_PORT_PRESENT.
>
> Read from DPCD once for all 3 values as this is an expensive operation.
> Spec mentions that all of address space 02200h through 0220Fh should
> contain the right information however currently only 3 values can
> differ.
>
> There is no address space in the intel_dp->dpcd struct for addresses
> 02200h through 0220Fh, and since so much of the data is a identical,
> simply overwrite the values stored in 0h through Fh with the
> values that can be overwritten from addresses 02200h through 0220Fh.
>
> This patch helps with backward compatibility for devices pre DP1.3.
>
> v2: read only dpcd values which can be affected, remove incorrect check,
> split into drm include changes into separate patch, commit message,
> verbose debugging statements during overwrite.
> v3: white space fixes
> v4: make path dependent on DPCD revision > 1.2
> v5: split into function, removed DPCD rev check
>
> Signed-off-by: Matt Atwood
> ---
> drivers/gpu/drm/i915/intel_dp.c | 54 +
> 1 file changed, 54 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index dde92e4af5d3..ed16b93bfe40 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3731,6 +3731,58 @@ intel_dp_link_down(struct intel_encoder *encoder,
> }
> }
>
> +static void
> +intel_dp_extended_receiver_capabilities(struct intel_dp *intel_dp)
> +{
> + /*
> + * Prior to DP1.3 the bit represented by
> + * DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT was reserved.
> + * if it is set DP_DPCD_REV at h could be at a value less than
> + * the true capability of the panel. The only way to check is to
> + * then compare h and 2200h.
> + */
> + if (intel_dp->dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> + DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT) {
> + uint8_t dpcd_ext[6];
> +
> + DRM_DEBUG_KMS("DPCD: Extended Receiver Capability Field
> Present, accessing 02200h through 022FFh\n");
> +
> + if (drm_dp_dpcd_read(&intel_dp->aux, DP_DP13_DPCD_REV,
> + &dpcd_ext, sizeof(dpcd_ext)) < 0)
> + return;
> +
> + if (intel_dp->dpcd[DP_DPCD_REV] > dpcd_ext[DP_DPCD_REV])
> + return;
I'm still missing the debug messages here and above...
> +
> + if (memcmp(&intel_dp->dpcd[DP_DPCD_REV], &dpcd_ext[DP_DPCD_REV],
> +sizeof(u8))) {
> + DRM_DEBUG_KMS("DPCD: new value for DPCD Revision
> previous value %2x new value %2x\n",
> + intel_dp->dpcd[DP_DPCD_REV],
> + dpcd_ext[DP_DPCD_REV]);
> + memcpy(&intel_dp->dpcd[DP_DPCD_REV],
> +&dpcd_ext[DP_DPCD_REV], sizeof(u8));
> + }
> + if (memcmp(&intel_dp->dpcd[DP_MAX_LINK_RATE],
> +&dpcd_ext[DP_MAX_LINK_RATE], sizeof(u8))) {
> + DRM_DEBUG_KMS("DPCD: new value for DPCD Max Link Rate
> previous value %2x new value %2x\n",
> + intel_dp->dpcd[DP_MAX_LINK_RATE],
> + dpcd_ext[DP_MAX_LINK_RATE]);
> + memcpy(&intel_dp->dpcd[DP_MAX_LINK_RATE],
> +&dpcd_ext[DP_MAX_LINK_RATE], sizeof(u8));
> + }
> + if (memcmp(&intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT],
> +&dpcd_ext[DP_DOWNSTREAMPORT_PRESENT], sizeof(u8))) {
> + DRM_DEBUG_KMS("DPCD: new value for DPCD Downstream Port
> Present previous value %2x new value %2x\n",
> + intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT],
> + dpcd_ext[DP_DOWNSTREAMPORT_PRESENT]);
> + memcpy(&intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT],
> +&dpcd_ext[DP_DOWNSTREAMPORT_PRESENT],
> +sizeof(u8));
> + }
> + }
> +}
> +
> +
> bool
> intel_dp_read_dpcd(struct intel_dp *intel_dp)
> {
> @@ -3738,6 +3790,8 @@ intel_dp_read_dpcd(struct intel_dp *intel_dp)
>sizeof(intel_dp->dpcd)) < 0)
> return false; /* aux transfer failed */
>
> + intel_dp_extended_receiver_capabilities(intel_dp);
> +
> DRM_DEBUG_KMS("DPCD: %*ph\n", (int) sizeof(intel_dp->dpcd),
> intel_dp->dpcd);
>
> return intel_dp->dpcd[DP_DPCD_REV] != 0;
> --
> 2.17.1
>
__
