Hi Jani,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v5.4 next-20191129]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base&#x
https://bugzilla.kernel.org/show_bug.cgi?id=205497
Luya Tshimbalanga (l...@fedoraproject.org) changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugzilla.kernel.org/show_bug.cgi?id=205585
Timothy Pearson (tpear...@raptorengineering.com) changed:
What|Removed |Added
Status|NEW |RESOLVE
On Fri, 29 Nov 2019 21:43:45 +0200
Ville Syrjälä wrote:
> On Fri, Nov 29, 2019 at 08:24:37PM +0100, Boris Brezillon wrote:
> > On Fri, 29 Nov 2019 19:40:38 +0100
> > Daniel Vetter wrote:
> >
> > > On Fri, Nov 29, 2019 at 03:19:36PM +0100, Boris Brezillon wrote:
> > > > On Fri, 29 Nov 2019 1
On 11/29/19 3:23 AM, Jan Kara wrote:
On Mon 25-11-19 15:10:33, John Hubbard wrote:
1. Convert from get_user_pages() to pin_user_pages().
2. As required by pin_user_pages(), release these pages via
put_user_page(). In this case, do so via put_user_pages_dirty_lock().
That has the side effect of
On Fri, 29 Nov 2019 21:07:33 +0100
Daniel Vetter wrote:
> On Fri, Nov 29, 2019 at 02:40:34PM +, Steven Price wrote:
> > On 29/11/2019 14:33, Boris Brezillon wrote:
> > > On Fri, 29 Nov 2019 14:24:48 +
> > > Steven Price wrote:
> > >
> > >> On 29/11/2019 13:59, Boris Brezillon wrote:
On Fri, 29 Nov 2019 21:14:59 +0100
Daniel Vetter wrote:
> On Fri, Nov 29, 2019 at 02:59:07PM +0100, Boris Brezillon wrote:
> > With the introduction of per-FD address space, the same BO can be mapped
> > in different address space if the BO is globally visible (GEM_FLINK)
>
> Also dma-buf self
https://bugzilla.kernel.org/show_bug.cgi?id=205585
--- Comment #6 from Timothy Pearson (tpear...@raptorengineering.com) ---
Yes, my fault, sorry about that -- different box, unbeknownst to me had a
different GPU (note to self, check lspci next time before decoding trace).
To top it off, this part
On Fri, 29 Nov 2019 21:12:13 +0100
Daniel Vetter wrote:
> On Fri, Nov 29, 2019 at 02:59:06PM +0100, Boris Brezillon wrote:
> > We don't want imported/exported BOs to be purges, as those are shared
> > with other processes that might still use them. We should also refuse
> > to export a BO if it's
https://bugzilla.kernel.org/show_bug.cgi?id=64721
--- Comment #8 from stanleyk (ichap...@videotron.ca) ---
I'm the originator and with my newer HW as of 2019 no problems. Thanks to all
Ian.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
On Fri, Nov 29, 2019 at 09:16:42PM +0100, Miguel Ojeda wrote:
> On Fri, Nov 29, 2019 at 4:24 PM Daniel Vetter wrote:
> >
> > Oh, another display subsystem? Intriguing ...
> >
> > Reviewed-by: Daniel Vetter
>
> It is intended for displays that are not intended as the usual/main
> display, e.g. ve
On Fri, Nov 29, 2019 at 01:07:19PM +0100, Thierry Reding wrote:
> On Fri, Nov 29, 2019 at 11:22:08AM +0100, Rafael J. Wysocki wrote:
> > On Fri, Nov 29, 2019 at 11:08 AM Thierry Reding
> > wrote:
> > >
> > > On Thu, Nov 28, 2019 at 11:20:01PM +0100, Rafael J. Wysocki wrote:
> > > > On Thursday, No
On Fri, Nov 29, 2019 at 11:44:12AM +0100, Thierry Reding wrote:
> On Fri, Nov 29, 2019 at 10:23:19AM +0100, Daniel Vetter wrote:
> > On Thu, Nov 28, 2019 at 04:37:40PM +0100, Thierry Reding wrote:
> > > From: Thierry Reding
> > >
> > > Ensure that a runtime PM reference is acquired each time the
https://bugzilla.kernel.org/show_bug.cgi?id=205585
--- Comment #5 from Alex Deucher (alexdeuc...@gmail.com) ---
This doesn't look related to the first one. The first one is a vega10 asic
according to the description, the second one is from a older VI asic.
mmHDP_MEM_COHERENCY_FLUSH_CNTL is a reg
On Fri, Nov 29, 2019 at 02:59:07PM +0100, Boris Brezillon wrote:
> With the introduction of per-FD address space, the same BO can be mapped
> in different address space if the BO is globally visible (GEM_FLINK)
Also dma-buf self-imports for wayland/dri3 ...
> and opened in different context. The
On Fri, Nov 29, 2019 at 02:59:06PM +0100, Boris Brezillon wrote:
> We don't want imported/exported BOs to be purges, as those are shared
> with other processes that might still use them. We should also refuse
> to export a BO if it's been marked purgeable or has already been purged.
>
> Fixes: 013
On 2019-10-11 1:12 p.m., t...@kernel.org wrote:
Hello, Daniel.
On Wed, Oct 09, 2019 at 06:06:52PM +0200, Daniel Vetter wrote:
That's not the point I was making. For cpu cgroups there's a very well
defined connection between the cpu bitmasks/numbers in cgroups and the cpu
bitmasks you use in var
On Fri, Nov 29, 2019 at 02:40:34PM +, Steven Price wrote:
> On 29/11/2019 14:33, Boris Brezillon wrote:
> > On Fri, 29 Nov 2019 14:24:48 +
> > Steven Price wrote:
> >
> >> On 29/11/2019 13:59, Boris Brezillon wrote:
> >>> If 2 threads change the MADVISE property of the same BO in parallel
On Fri, Nov 29, 2019 at 11:33:45AM +0100, Thierry Reding wrote:
> On Fri, Nov 29, 2019 at 10:12:44AM +0100, Daniel Vetter wrote:
> > On Thu, Nov 28, 2019 at 04:37:35PM +0100, Thierry Reding wrote:
> > > From: Thierry Reding
> > >
> > > It's not known at import time whether or not all users of a D
On Fri, Nov 29, 2019 at 08:24:37PM +0100, Boris Brezillon wrote:
> On Fri, 29 Nov 2019 19:40:38 +0100
> Daniel Vetter wrote:
>
> > On Fri, Nov 29, 2019 at 03:19:36PM +0100, Boris Brezillon wrote:
> > > On Fri, 29 Nov 2019 14:13:33 +
> > > Steven Price wrote:
> > >
> > > > On 29/11/2019 13
On Fri, 29 Nov 2019 14:38:50 +
Steven Price wrote:
> On 29/11/2019 14:31, Boris Brezillon wrote:
> > On Fri, 29 Nov 2019 14:19:50 +
> > Steven Price wrote:
> >
> >> On 29/11/2019 13:59, Boris Brezillon wrote:
> >>> If we don't do that, dma_fence_set_error() complains (called from
>
On Fri, 29 Nov 2019 19:40:38 +0100
Daniel Vetter wrote:
> On Fri, Nov 29, 2019 at 03:19:36PM +0100, Boris Brezillon wrote:
> > On Fri, 29 Nov 2019 14:13:33 +
> > Steven Price wrote:
> >
> > > On 29/11/2019 13:56, Boris Brezillon wrote:
> > > > I've spent hours chasing a memory corruptio
On Fri, Nov 29, 2019 at 11:15:37AM +0100, Thierry Reding wrote:
> On Fri, Nov 29, 2019 at 10:10:38AM +0100, Daniel Vetter wrote:
> > On Thu, Nov 28, 2019 at 04:37:34PM +0100, Thierry Reding wrote:
> > > From: Thierry Reding
> > >
> > > Buffers that are imported from a DMA-BUF don't have pages all
On Fri, Nov 29, 2019 at 07:57:39PM +0100, Daniel Vetter wrote:
> On Fri, Nov 29, 2019 at 10:34:10AM +0100, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 27.11.19 um 19:00 schrieb Daniel Vetter:
> > > We're doing a great job for really simple drivers right now, but still
> > > a lot of boilerplate for
On Fri, Nov 29, 2019 at 11:12:55AM +0100, Thierry Reding wrote:
> On Fri, Nov 29, 2019 at 10:06:43AM +0100, Daniel Vetter wrote:
> > On Thu, Nov 28, 2019 at 04:37:33PM +0100, Thierry Reding wrote:
> > > From: Thierry Reding
> > >
> > > I have no recollection why that check is there, but it seems
On Bay Trail devices the MIPI power on/off sequences for DSI LCD panels
do not control the LCD panel and backlight GPIOs. So far we have been
relying on these GPIOs being configured as output and driven high by
the Video BIOS (GOP) when it initializes the panel.
This does not work when the device
Hi All,
On Bay Trail devices the MIPI power on/off sequences for DSI LCD panels
do not control the LCD panel- and backlight-enable GPIOs. So far, when
the VBT indicates we should use the SoC for backlight control, we have
been relying on these GPIOs being configured as output and driven high by
th
On Bay Trail devices the MIPI power on/off sequences for DSI LCD panels
do not control the LCD panel- and backlight-enable GPIOs. So far, when
the VBT indicates we should use the SoC for backlight control, we have
been relying on these GPIOs being configured as output and driven high by
the Video B
On Fri, Nov 29, 2019 at 10:34:10AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 27.11.19 um 19:00 schrieb Daniel Vetter:
> > We're doing a great job for really simple drivers right now, but still
> > a lot of boilerplate for the bigger ones.
> >
> > Signed-off-by: Daniel Vetter
>
> Just a small
On Fri, Nov 29, 2019 at 03:19:36PM +0100, Boris Brezillon wrote:
> On Fri, 29 Nov 2019 14:13:33 +
> Steven Price wrote:
>
> > On 29/11/2019 13:56, Boris Brezillon wrote:
> > > I've spent hours chasing a memory corruption that was caused by
> > > insertion of an extra field field before ->base
On Fri, Nov 29, 2019 at 06:04:02PM +, Emil Velikov wrote:
> Hi Thomas,
>
> On Tue, 26 Nov 2019 at 13:47, Thomas Zimmermann wrote:
> >
> > The infrastruture for atomic modesetting allows us to use the generic
> > code for dirty-FB and damage handling. Switch over udl and remove the
> > driver'
Am 29.11.19 um 14:26 schrieb Lucas Stach:
Signed-off-by: Lucas Stach
Reviewed-by: Christian König
---
drivers/gpu/drm/scheduler/sched_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 596a28d
Hi Thomas,
On Tue, 26 Nov 2019 at 13:47, Thomas Zimmermann wrote:
>
> The infrastruture for atomic modesetting allows us to use the generic
> code for dirty-FB and damage handling. Switch over udl and remove the
> driver's implementation.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu
On Thu, Nov 28, 2019 at 10:56 PM Harigovindan P wrote:
>
> Add a compatible string to support sc7180 panel version.
>
> Signed-off-by: Harigovindan P
> ---
> .../bindings/display/visionox,rm69299.txt | 68
> ++
> 1 file changed, 68 insertions(+)
> create mode 10075
https://bugs.freedesktop.org/show_bug.cgi?id=109881
Bug 109881 depends on bug 109873, which changed state.
Bug 109873 Summary: Screens reorganise, failed to enable link training errors
in dmesg about 60s after plugging in dock
https://bugs.freedesktop.org/show_bug.cgi?id=109873
What
From: Colin Ian King
The sizeof is currently on args.src and args.dst and should be on
*args.src and *args.dst. Fortunately these sizes just so happen
to be the same size so it worked, however, this should be fixed
and it also cleans up static analysis warnings
Addresses-Coverity: ("sizeof not p
On 29/11/2019 16:07, Boris Brezillon wrote:
> On Fri, 29 Nov 2019 15:48:15 +
> Steven Price wrote:
>
>> On 29/11/2019 13:59, Boris Brezillon wrote:
>>> Userspace might tag a BO purgeable while it's still referenced by GPU
>>> jobs. We need to make sure the shrinker does not purge such BOs unt
On Fri, 29 Nov 2019 15:48:15 +
Steven Price wrote:
> On 29/11/2019 13:59, Boris Brezillon wrote:
> > Userspace might tag a BO purgeable while it's still referenced by GPU
> > jobs. We need to make sure the shrinker does not purge such BOs until
> > all jobs referencing it are finished.
> >
>
On 29/11/2019 13:59, Boris Brezillon wrote:
> Userspace might tag a BO purgeable while it's still referenced by GPU
> jobs. We need to make sure the shrinker does not purge such BOs until
> all jobs referencing it are finished.
>
> Fixes: 013b65101315 ("drm/panfrost: Add madvise and shrinker suppo
On Fri, Nov 29, 2019 at 12:29:30PM +0200, Jani Nikula wrote:
> This is v2 of https://patchwork.freedesktop.org/series/70119/
>
> I wanted to make our struct fb_ops const because we don't modify
> it... and this is what I ended up with to fix it and a bunch of others.
>
> I would appreciate acks t
On 29/11/2019 13:59, Boris Brezillon wrote:
> With the introduction of per-FD address space, the same BO can be mapped
> in different address space if the BO is globally visible (GEM_FLINK)
> and opened in different context. The current implementation does not
> take case into account, and attaches
On Fri, Nov 29, 2019 at 12:29:36PM +0200, Jani Nikula wrote:
> Use const for fb_ops to let us make the info->fbops pointer const in the
> future.
>
> v2: rebase
>
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: Jani Nikula
I guess my r-b got lost on this, not sure, anyway.
Reviewed-by: Dani
On Fri, Nov 29, 2019 at 12:29:44PM +0200, Jani Nikula wrote:
> Now that the fbops member of struct fb_info is const, we can start
> making the ops const as well.
>
> Cc: Miguel Ojeda Sandonis
> Cc: Robin van der Gracht
> Signed-off-by: Jani Nikula
> ---
> drivers/auxdisplay/cfag12864bfb.c | 2
To enable HDMI audio the SND_SOC_HDMI_CODEC needs to be
configured. Enable HDMI audio by selecting SND_SOC_HDMI_CODEC if
SND_SOC is configured. SND_SOC_HDMI_CODEC has no config menu entry and
should be selected atomatically by the drivers using it.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/b
On Fri, Nov 29, 2019 at 12:29:31PM +0200, Jani Nikula wrote:
> Modifying fb_ops directly to override fb_mmap with fb_deferred_io_mmap
> and then resetting it to NULL afterwards causes problems all over the
> place. First, it prevents making the fbops member of struct fb_info a
> const pointer, whic
On Mon, Nov 18, 2019 at 06:18:31PM +0800, Wayne Lin wrote:
> [Why]
> HDMI 2.0 adds aspect ratio attribute to distinguish different
> 4k modes. According to Appendix E of HDMI 2.0 spec, source should
> use VSIF to indicate video mode only when the mode is one defined
> in HDMI 1.4b 4K modes. Otherwi
On Tue, 29 Oct 2019 14:07:48 -0400
Andrey Grodzovsky wrote:
> Fix a static code checker warning.
>
> v2: Drop PTR_ERR_OR_ZERO.
>
> Signed-off-by: Andrey Grodzovsky
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/d
On Fri, 29 Nov 2019 14:45:41 +
Steven Price wrote:
> On 29/11/2019 13:59, Boris Brezillon wrote:
> > We don't want imported/exported BOs to be purges, as those are shared
>
> s/purges/purged/
>
> > with other processes that might still use them. We should also refuse
> > to export a BO if
On 29/11/2019 13:59, Boris Brezillon wrote:
> We don't want imported/exported BOs to be purges, as those are shared
s/purges/purged/
> with other processes that might still use them. We should also refuse
> to export a BO if it's been marked purgeable or has already been purged.
>
> Fixes: 013b6
On 29/11/2019 14:33, Boris Brezillon wrote:
> On Fri, 29 Nov 2019 14:24:48 +
> Steven Price wrote:
>
>> On 29/11/2019 13:59, Boris Brezillon wrote:
>>> If 2 threads change the MADVISE property of the same BO in parallel we
>>> might end up with an shmem->madv value that's inconsistent with th
On 29/11/2019 14:31, Boris Brezillon wrote:
> On Fri, 29 Nov 2019 14:19:50 +
> Steven Price wrote:
>
>> On 29/11/2019 13:59, Boris Brezillon wrote:
>>> If we don't do that, dma_fence_set_error() complains (called from
>>> drm_sched_main()).
>>>
>>> Fixes: f3ba91228e8e ("drm/panfrost: Add init
On 29/11/2019 13:59, Boris Brezillon wrote:
> Commit a5efb4c9a562 ("drm/panfrost: Restructure the GEM object creation")
> moved the drm_mm_insert_node_generic() call to the gem->open() hook,
> but forgot to update perfcnt accordingly.
>
> Patch the perfcnt logic to call panfrost_gem_open/close() w
On Fri, 29 Nov 2019 14:24:48 +
Steven Price wrote:
> On 29/11/2019 13:59, Boris Brezillon wrote:
> > If 2 threads change the MADVISE property of the same BO in parallel we
> > might end up with an shmem->madv value that's inconsistent with the
> > presence of the BO in the shrinker list.
>
On Fri, 29 Nov 2019 14:19:50 +
Steven Price wrote:
> On 29/11/2019 13:59, Boris Brezillon wrote:
> > If we don't do that, dma_fence_set_error() complains (called from
> > drm_sched_main()).
> >
> > Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
> > Cc:
> > Signed-off-by:
On 29/11/2019 13:59, Boris Brezillon wrote:
> panfrost_gem_shrinker_scan() might purge a BO (release the sgt and
> kill the GPU mapping) that's being freed by panfrost_gem_free_object()
> if we don't remove the BO from the shrinker list at the beginning of
> panfrost_gem_free_object().
>
> Fixes:
On Fri, Nov 29, 2019 at 02:56:14PM +0100, Boris Brezillon wrote:
> I've spent hours chasing a memory corruption that was caused by
> insertion of an extra field field before ->base. Let's document the
> fact that base has to be the first field in panfrost_gem_object.
>
> Signed-off-by: Boris Brezi
On 29/11/2019 13:59, Boris Brezillon wrote:
> We should release the reference we grabbed when an error occurs.
>
> Fixes: 187d2929206e ("drm/panfrost: Add support for GPU heap allocations")
> Cc:
> Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panf
On 29/11/2019 13:59, Boris Brezillon wrote:
> If 2 threads change the MADVISE property of the same BO in parallel we
> might end up with an shmem->madv value that's inconsistent with the
> presence of the BO in the shrinker list.
I'm a bit worried from the point of view of user space sanity that y
On 29/11/2019 13:59, Boris Brezillon wrote:
> If we don't do that, dma_fence_set_error() complains (called from
> drm_sched_main()).
>
> Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
> Cc:
> Signed-off-by: Boris Brezillon
This might be worth doing, but actually it's not Panf
On Fri, 29 Nov 2019 14:13:33 +
Steven Price wrote:
> On 29/11/2019 13:56, Boris Brezillon wrote:
> > I've spent hours chasing a memory corruption that was caused by
> > insertion of an extra field field before ->base. Let's document the
> > fact that base has to be the first field in panfrost
On Fri, 29 Nov 2019 14:59:06 +0100
Boris Brezillon wrote:
> We don't want imported/exported BOs to be purges, as those are shared
> with other processes that might still use them. We should also refuse
> to export a BO if it's been marked purgeable or has already been purged.
>
> Fixes: 013b6510
On 29/11/2019 13:56, Boris Brezillon wrote:
> I've spent hours chasing a memory corruption that was caused by
> insertion of an extra field field before ->base. Let's document the
> fact that base has to be the first field in panfrost_gem_object.
>
> Signed-off-by: Boris Brezillon
This seems to
Den 29.11.2019 11.29, skrev Jani Nikula:
> Deferred IO now preserves the fb_ops.
>
> v2: Remove the no-op vfree, drop a local var (Noralf)
>
> Cc: Noralf Trønnes
> Cc: dri-devel@lists.freedesktop.org
> Reviewed-by: Daniel Vetter
> Signed-off-by: Jani Nikula
> ---
Reviewed-by: Noralf Trønne
Den 29.11.2019 11.29, skrev Jani Nikula:
> Modifying fb_ops directly to override fb_mmap with fb_deferred_io_mmap
> and then resetting it to NULL afterwards causes problems all over the
> place. First, it prevents making the fbops member of struct fb_info a
> const pointer, which means we can't m
On 29/11/2019 13:26, Lucas Stach wrote:
> If the job submission fails with a NULL fence returned instead of an
> error pointer we must not try to convert this into an error. The error
> code in this case will be 0, which causes a warning splat from
> dma_fence_set_error().
>
> Also most drivers re
Userspace might tag a BO purgeable while it's still referenced by GPU
jobs. We need to make sure the shrinker does not purge such BOs until
all jobs referencing it are finished.
Fixes: 013b65101315 ("drm/panfrost: Add madvise and shrinker support")
Cc:
Signed-off-by: Boris Brezillon
---
drivers
We don't want imported/exported BOs to be purges, as those are shared
with other processes that might still use them. We should also refuse
to export a BO if it's been marked purgeable or has already been purged.
Fixes: 013b65101315 ("drm/panfrost: Add madvise and shrinker support")
Cc:
Signed-of
We should release the reference we grabbed when an error occurs.
Fixes: 187d2929206e ("drm/panfrost: Add support for GPU heap allocations")
Cc:
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a
Commit a5efb4c9a562 ("drm/panfrost: Restructure the GEM object creation")
moved the drm_mm_insert_node_generic() call to the gem->open() hook,
but forgot to update perfcnt accordingly.
Patch the perfcnt logic to call panfrost_gem_open/close() where
appropriate.
Fixes: a5efb4c9a562 ("drm/panfrost:
With the introduction of per-FD address space, the same BO can be mapped
in different address space if the BO is globally visible (GEM_FLINK)
and opened in different context. The current implementation does not
take case into account, and attaches the mapping directly to the
panfrost_gem_object.
L
panfrost_gem_shrinker_scan() might purge a BO (release the sgt and
kill the GPU mapping) that's being freed by panfrost_gem_free_object()
if we don't remove the BO from the shrinker list at the beginning of
panfrost_gem_free_object().
Fixes: 013b65101315 ("drm/panfrost: Add madvise and shrinker su
If we don't do that, dma_fence_set_error() complains (called from
drm_sched_main()).
Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
Cc:
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panfrost/panfrost_job.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -
If 2 threads change the MADVISE property of the same BO in parallel we
might end up with an shmem->madv value that's inconsistent with the
presence of the BO in the shrinker list.
The easiest solution to fix that is to protect the
drm_gem_shmem_madvise() call with the shrinker lock.
Fixes: 013b65
Hello,
I've recently come to test a 5.4 kernel on a rk3288 platform (T760),
and, as reported by many people on #panfrost, I've hit a page-fault
storm when running various GL apps.
This series tries to address the problems I could spot during my debug
session, with patch 7 being the most invasive
Wrong prefix, should be "drm/panfrost: ". I'll send a v2 (sorry for the
noise).
On Fri, 29 Nov 2019 14:39:20 +0100
Boris Brezillon wrote:
> I've spent hours chasing a memory corruption that was caused by
> insertion of an extra field field before ->base. Let's document the
> fact that base has t
I've spent hours chasing a memory corruption that was caused by
insertion of an extra field field before ->base. Let's document the
fact that base has to be the first field in panfrost_gem_object.
Signed-off-by: Boris Brezillon
---
Changes in v2:
* Use the proper prefix in the subject line
---
d
I've spent hours chasing a memory corruption that was caused by
insertion of an extra field field before ->base. Let's document the
fact that base has to be the first field in panfrost_gem_object.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panfrost/panfrost_gem.h | 4
1 file changed
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/scheduler/sched_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 596a28d90e5c..d6efb35404a2 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/dr
If the job submission fails with a NULL fence returned instead of an
error pointer we must not try to convert this into an error. The error
code in this case will be 0, which causes a warning splat from
dma_fence_set_error().
Also most drivers return NULL from the run_job callback if the fence
alr
On Thu, Nov 07, 2019 at 06:18:14PM +0100, Markus Elfring wrote:
> From: Markus Elfring
> Date: Thu, 7 Nov 2019 18:05:08 +0100
>
> A coccicheck run provided information like the following.
>
> drivers/gpu/drm/qxl/qxl_kms.c:295:1-7: ERROR: missing iounmap;
> ioremap on line 178 and execution via c
On Fri, Nov 29, 2019 at 11:22:08AM +0100, Rafael J. Wysocki wrote:
> On Fri, Nov 29, 2019 at 11:08 AM Thierry Reding
> wrote:
> >
> > On Thu, Nov 28, 2019 at 11:20:01PM +0100, Rafael J. Wysocki wrote:
> > > On Thursday, November 28, 2019 11:03:57 PM CET Rafael J. Wysocki wrote:
> > > > On Thursday
On Tuesday, November 19, 2019 4:18:16 PM CET Hans de Goede wrote:
> At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2
> different PWM controllers for controlling the LCD's backlight brightness.
> Either the one integrated into the PMIC or the one integrated into the
> SoC (the
On Fri, Nov 29, 2019 at 11:09:26AM +0100, Rafael J. Wysocki wrote:
> On Fri, Nov 29, 2019 at 10:34 AM Thierry Reding
> wrote:
> >
> > On Thu, Nov 28, 2019 at 11:03:57PM +0100, Rafael J. Wysocki wrote:
> > > On Thursday, November 28, 2019 5:50:26 PM CET Thierry Reding wrote:
> > > >
> > > > --0F1p/
On Sat, Nov 02, 2019 at 06:56:28PM +0100, Thierry Reding wrote:
> Thierry Reding (9):
> iommu: Document iommu_fwspec::flags field
> iommu: Add dummy dev_iommu_fwspec_get() helper
Acked-by: Joerg Roedel
___
dri-devel mailing list
dri-devel@lists.fre
On Mon 25-11-19 15:10:33, John Hubbard wrote:
> 1. Convert from get_user_pages() to pin_user_pages().
>
> 2. As required by pin_user_pages(), release these pages via
> put_user_page(). In this case, do so via put_user_pages_dirty_lock().
>
> That has the side effect of calling set_page_dirty_lock
On Fri, Nov 29, 2019 at 10:23:19AM +0100, Daniel Vetter wrote:
> On Thu, Nov 28, 2019 at 04:37:40PM +0100, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > Ensure that a runtime PM reference is acquired each time the DPAUX
> > registers are accessed. Otherwise the code may end up running wi
On Fri, 29 Nov 2019, Jani Nikula wrote:
> Now that the fbops member of struct fb_info is const, we can start
> making the ops const as well.
>
> This does not cover all drivers; some actually modify the fbops struct,
> for example to adjust for different configurations, and others do more
> involv
On Fri, 29 Nov 2019, Jani Nikula wrote:
> Now that the fbops member of struct fb_info is const, we can start
> making the ops const as well.
>
> Remove the redundant fbops assignments while at it.
>
> v2:
> - actually add const in vivid
> - fix typo (Christophe de Dinechin)
>
> Cc: Hans Verkuil
>
On Fri, Nov 29, 2019 at 10:12:44AM +0100, Daniel Vetter wrote:
> On Thu, Nov 28, 2019 at 04:37:35PM +0100, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > It's not known at import time whether or not all users of a DMA-BUF will
> > be able to deal with non-contiguous memory. Each user need
Now that the fbops member of struct fb_info is const, we can start
making the ops const as well.
v2: fix typo (Christophe de Dinechin)
Cc: Bruno Prémont
Cc: linux-in...@vger.kernel.org
Reviewed-by: Daniel Vetter
Signed-off-by: Jani Nikula
---
drivers/hid/hid-picolcd_fb.c | 3 +--
1 file chang
Now that the fbops member of struct fb_info is const, we can start
making the ops const as well.
Remove the redundant fbops assignments while at it.
v2:
- actually add const in vivid
- fix typo (Christophe de Dinechin)
Cc: Hans Verkuil
Cc: Andy Walls
Cc: linux-me...@vger.kernel.org
Cc: ivtv-de
Now that the fbops member of struct fb_info is const, we can start
making the ops const as well.
v2: fix typo (Christophe de Dinechin)
Cc: Kirti Wankhede
Cc: k...@vger.kernel.org
Reviewed-by: Daniel Vetter
Signed-off-by: Jani Nikula
---
samples/vfio-mdev/mdpy-fb.c | 2 +-
1 file changed, 1 in
Now that the fbops member of struct fb_info is const, we can start
making the ops const as well.
Cc: Miguel Ojeda Sandonis
Cc: Robin van der Gracht
Signed-off-by: Jani Nikula
---
drivers/auxdisplay/cfag12864bfb.c | 2 +-
drivers/auxdisplay/ht16k33.c | 2 +-
2 files changed, 2 insertions(+
Use const for fb_ops to let us make the info->fbops pointer const in the
future.
v2: rebase
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Jani Nikula
---
drivers/video/fbdev/core/fbmem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmem.c b/
Deferred IO now preserves the fb_ops.
Cc: Bernie Thompson
Cc: linux-fb...@vger.kernel.org
Reviewed-by: Daniel Vetter
Signed-off-by: Jani Nikula
---
drivers/video/fbdev/udlfb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/udlfb.c b/drivers/video/fbdev/udlfb.c
index fe3
Avoid modifying the fb_ops via info->fbops to let us make the pointer
const in the future.
Cc: linux-fb...@vger.kernel.org
Reviewed-by: Daniel Vetter
Signed-off-by: Jani Nikula
---
drivers/video/fbdev/vesafb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/vid
Now that the fbops member of struct fb_info is const, we can start
making the ops const as well.
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Daniel Vetter
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 2 +-
drivers/gpu/drm/armada/armada_fbdev.c
Now that we no longer modify the fbops, or hold non-const pointers to
it, we can make it const. After this, we can start making the fbops
const all over the place.
Cc: linux-fb...@vger.kernel.org
Reviewed-by: Daniel Vetter
Signed-off-by: Jani Nikula
---
include/linux/fb.h | 2 +-
1 file changed
Now that the fbops member of struct fb_info is const, we can start
making the ops const as well.
This does not cover all drivers; some actually modify the fbops struct,
for example to adjust for different configurations, and others do more
involved things that I'd rather not touch in practically o
Use const for fb_ops to let us make the info->fbops pointer const in the
future.
Cc: linux-fb...@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Reviewed-by: Daniel Vetter
Signed-off-by: Jani Nikula
---
drivers/video/fbdev/omap/omapfb_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
1 - 100 of 119 matches
Mail list logo
