https://bugzilla.kernel.org/show_bug.cgi?id=205585
--- Comment #4 from Timothy Pearson (tpear...@raptorengineering.com) ---
Stack decodes to:
arch/powerpc/include/asm/eeh.h:403 [if (EEH_POSSIBLE_ERROR(val, u32))]
drivers/gpu/drm/amd/amdgpu/vi.c:913 [RREG32(mmHDP_MEM_COHERENCY_FLUSH_CNTL)]
drivers
On Thu, Nov 28, 2019 at 04:58:26PM +0100, Andrzej Pietrasiewicz wrote:
> W dniu 27.11.2019 o 19:00, Daniel Vetter pisze:
> > If rockchip would switch over to the generic fbdev setup we could
> > grabage collect even more of all this code (all of the remaining fb
> > handling code really).
> >
> >
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 to trigger
> all the time, so remove it. Everything works fine without.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/tegra/hub.c
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 allocated with
> them. At the same time an SG table for them can't be derived using the
> DMA API helpers because the necessary information doesn't
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 needs to verify at
> map-time whether it can access the buffer.
>
> Signed-o
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 without
> the controller being powered, out-of-reset or clocked in some cor
On Thu, Nov 28, 2019 at 04:37:41PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> The SOR supports multiple display modes, but only when driving an HDMI
> monitor does it make sense to control the +5V power supply. eDP and DP
> don't need this, so make it optional.
>
> This fixes a cras
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 remark below, otherwise
Acked-by: Thomas Zimmermann
> ---
> Documentation/gpu/to
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//8PRICkK4MW
> > Content-Type: text/plain; charset=us-ascii
> > Content-Disposition: inline
> > Content-Transfer-Encoding: quoted-printable
> >
>
On 28/11/2019 20:54, Robin Murphy wrote:
> When we have devfreq, also try to register a basic cooling device in
> case GPU workloads manage to hit thermal throttling thresholds.
>
> Signed-off-by: Robin Murphy
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost_devfreq.c | 32
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, November 28, 2019 5:50:26 PM CET Thierry Reding wrote:
> > >
> > > --0F1p//8PRICkK4MW
> > > Content-Type: text/plain; charset=us-ascii
> > >
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//8PRICkK4MW
> > > Content-Type: text/plain; charset=us-ascii
> > > Content-Dispos
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 to trigger
> > all the time, so remove it. Everything works fine without.
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 allocated with
> > them. At the same time an SG table for them can't be deriv
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, November 28, 2019 5:50:26 PM CET Thierry Reding wrote:
> > > >
> > > > --0F1p
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 to merge all this via the drm-misc tree. This is
especially important for
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
---
drivers/gpu/drm/drm_fb_helper.c | 25 +++--
1 file changed, 3 inser
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 make struct fb_ops const
anywhere. Second, a few pla
Deferred IO now preserves the fb_ops.
Cc: Steve Glendinning
Cc: linux-fb...@vger.kernel.org
Reviewed-by: Daniel Vetter
Signed-off-by: Jani Nikula
---
drivers/video/fbdev/smscufx.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/smscufx.c b/drivers/video/fbdev/smscufx.c
i
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(-)
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
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
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/
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(+
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.
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: 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
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
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: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 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 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 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 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: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 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
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
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
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
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
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
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
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
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 -
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
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
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
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
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
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
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 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 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 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:
> 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 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:
> 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, 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 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 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 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 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 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 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 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 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 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
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: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
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 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: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:
> 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, 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 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
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
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
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
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
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
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'
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 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 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 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 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: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, 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, 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, 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
1 - 100 of 119 matches
Mail list logo
