On Fri, Oct 09, 2020 at 06:30:36PM -0700, Eric Biggers wrote:
> On Sat, Oct 10, 2020 at 01:39:54AM +0100, Matthew Wilcox wrote:
> > On Fri, Oct 09, 2020 at 02:34:34PM -0700, Eric Biggers wrote:
> > > On Fri, Oct 09, 2020 at 12:49:57PM -0700, ira.we...@intel.com wrote:
> > > > The kmap() calls in th
Hi Neil/Anitha.
On Fri, Oct 09, 2020 at 11:09:45AM +0200, Neil Armstrong wrote:
> Hi,
>
> On 09/10/2020 03:03, Anitha Chrisanthus wrote:
> > This patch adds bindings for Intel KeemBay Display
> >
> > v2: review changes from Rob Herring
> >
> > Signed-off-by: Anitha Chrisanthus
> > ---
> > ...
On Fri, Oct 09, 2020 at 07:53:07PM -0700, John Hubbard wrote:
> On 10/9/20 12:50 PM, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > The pmem driver uses a cached virtual address to access its memory
> > directly. Because the nvdimm driver is well aware of the special
> > protections it h
On Sat, Oct 10, 2020 at 10:20:34AM +0800, Coly Li wrote:
> On 2020/10/10 03:50, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > These kmap() calls are localized to a single thread. To avoid the over
> > head of global PKRS updates use the new kmap_thread() call.
> >
>
> Hi Ira,
>
> The
On Sat, Oct 10, 2020 at 11:36:49AM +, Bernard Metzler wrote:
> -ira.we...@intel.com wrote: -
>
[snip]
> >@@ -505,7 +505,7 @@ static int siw_tx_hdt(struct siw_iwarp_tx *c_tx,
> >struct socket *s)
> > page_array[seg] = p;
> >
> >
On Sun, 11 Oct 2020 at 23:01, Randy Dunlap wrote:
>
> kernel test robot reported build errors (undefined references)
> that didn't make much sense. After reproducing them, there is also
> a Kconfig warning that is the root cause of the build errors, so
> fix that Kconfig problem.
>
> Fixes this Kc
Hi all,
[Just adding Dave to cc's]
On Mon, 12 Oct 2020 15:24:52 +1100 Stephen Rothwell
wrote:
>
> Hi all,
>
> On Thu, 8 Oct 2020 15:42:02 +1100 Stephen Rothwell
> wrote:
> >
> > On Thu, 8 Oct 2020 14:09:03 +1100 Stephen Rothwell
> > wrote:
> > >
> > > After merging the drm-misc tree, tod
Hi all,
On Thu, 8 Oct 2020 15:42:02 +1100 Stephen Rothwell
wrote:
>
> On Thu, 8 Oct 2020 14:09:03 +1100 Stephen Rothwell
> wrote:
> >
> > After merging the drm-misc tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
>
> In file included from include/linux/clk.h:13,
>
Hi all,
On Tue, 6 Oct 2020 13:41:20 -0300 Jason Gunthorpe wrote:
>
> On Tue, Oct 06, 2020 at 08:35:08PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the hmm tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this:
> >
> >
> > Caused by commit
> >
> >
Hi all,
On Wed, 23 Sep 2020 15:13:36 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> drivers/gpu/drm/amd/amdkfd/kfd_priv.h
>
> between commit:
>
> 59d7115dae02 ("drm/amdkfd: Move process doorbell allocation into kfd
> device")
>
> from t
From: Rob Clark
Now that we are not relying on dev->struct_mutex to protect the
ring->submits lists, drop the struct_mutex lock.
Signed-off-by: Rob Clark
Reviewed-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_gpu.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/dri
From: Rob Clark
One less place to rely on dev->struct_mutex.
Signed-off-by: Rob Clark
Reviewed-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_gem_submit.c | 2 ++
drivers/gpu/drm/msm/msm_gpu.c| 37 ++--
drivers/gpu/drm/msm/msm_ringbuffer.c | 1 +
drivers/gpu/d
From: Rob Clark
We'll need to introduce a _locked() version of msm_gem_get_iova(), so we
need to make that name available.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/driver
From: Rob Clark
Now that active_list/inactive_list is protected by mm_lock, we no longer
need dev->struct_mutex in the free_object() path.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drive
From: Rob Clark
Now that we don't need struct_mutex in the free path, we can get rid of
the asynchronous free altogether.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 3 ---
drivers/gpu/drm/msm/msm_drv.h | 5 -
drivers/gpu/drm/msm/msm_gem.c | 27 --
From: Rob Clark
The obj->lock is sufficient for what we need.
This *does* have the implication that userspace can try to shoot
themselves in the foot by racing madvise(DONTNEED) with submit. But
the result will be about the same if they did madvise(DONTNEED) before
the submit ioctl, ie. they mi
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c| 4 +---
drivers/gpu/drm/msm/msm_gem.h| 16 +---
drivers/gpu/drm/msm/msm_gem_submit.c | 4 ++--
drivers/gpu/drm/msm/msm_gpu.c| 2 +-
4 files changed, 9 insertions(+), 17 deletions(-
From: Rob Clark
Before we remove dev->struct_mutex from the retire path, we have to deal
with the situation of a submit retiring before the submit ioctl returns.
To deal with this, ring->submits will hold a reference to the submit,
which is dropped when the submit is retired. And the submit ioc
From: Rob Clark
Before adding another lock, give ring->lock a more descriptive name.
Signed-off-by: Rob Clark
Reviewed-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 ++--
drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 12 ++--
drivers/gpu/drm/msm/adreno/a6xx_gpu.c
From: Rob Clark
Small cleanup, update_fences() is used in the hangcheck path, but also
in the normal retire path.
Signed-off-by: Rob Clark
Reviewed-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_gpu.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --
From: Rob Clark
Move grabbing the bo lock into shrinker, with a msm_gem_trylock() to
skip over bo's that are already locked. This gets rid of the nested
lock classes.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 24 +
drivers/gpu/drm/msm/msm_gem.h
From: Rob Clark
It cannot be atomically updated with obj->active_count, and the only
purpose is a useless WARN_ON() (which becomes a buggy WARN_ON() once
retire_submits() is not serialized with incoming submits via
struct_mutex)
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 2 --
From: Rob Clark
Unfortunately, due to an dev_pm_opp locking interaction with
mm->mmap_sem, we need to do pm get before aquiring obj locks,
otherwise we can have anger lockdep with the chain:
opp_table_lock --> &mm->mmap_sem --> reservation_ww_class_mutex
For an explicit fencing userspace, the
From: Rob Clark
Rather than relying on the big dev->struct_mutex hammer, introduce a
more specific lock for protecting the bo lists.
Signed-off-by: Rob Clark
Reviewed-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_debugfs.c | 7 +++
drivers/gpu/drm/msm/msm_drv.c | 7 +++
From: Rob Clark
When we cut-over to using dma_resv_lock/etc instead of msm_obj->lock,
we'll need these for the submit path (where resv->lock is already held).
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 50 +++
drivers/gpu/drm/msm/msm_gem.h | 4
From: Rob Clark
This will make it easier to transition over to obj->resv locking for
everything that is per-bo locking.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 99 ---
drivers/gpu/drm/msm/msm_gem.h | 28 ++
2 files changed, 74 insert
From: Rob Clark
Any cross-device sync use-cases *must* use explicit sync. And if there
is only a single ring (no-preemption), everything is FIFO order and
there is no need to implicit-sync.
Mesa should probably just always use MSM_SUBMIT_NO_IMPLICIT, as behavior
is undefined when fences are not
From: Rob Clark
We cannot switch to using obj->resv for locking without first moving all
the copy_from_user() ahead of submit_lock_objects(). Otherwise in the
mm fault path we aquire mm->mmap_sem before obj lock, but in the submit
path the order is reversed.
Signed-off-by: Rob Clark
---
drive
From: Rob Clark
We only want to use the _unlocked() variant in the unlocked case.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 210bf5c9c2dd
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 1 +
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 1 +
drivers/gpu/drm/msm/dsi/dsi_host.c| 1 +
drivers/gpu/drm/msm/msm_drv.h | 54 --
drivers/gpu/drm/msm/msm_fbdev
From: Rob Clark
This doesn't remove *all* the struct_mutex, but it covers the worst
of it, ie. shrinker/madvise/free/retire. The submit path still uses
struct_mutex, but it still needs *something* serialize a portion of
the submit path, and lock_stat mostly just shows the lock contention
there b
From: Rob Clark
It is somewhat redundant with the gpu tracepoints, and anyways not too
useful to justify spamming the log when debug traces are enabled.
Signed-off-by: Rob Clark
Reviewed-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_gpu.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/dri
From: Rob Clark
Now that the inactive_list is protected by mm_lock, and everything
else on per-obj basis is protected by obj->lock, we no longer depend
on struct_mutex.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 1 -
drivers/gpu/drm/msm/msm_gem_shrinker.c | 54 -
Hi Jyri,
Thank you for the patch.
On Sat, Oct 10, 2020 at 08:00:59PM +0300, Jyri Sarha wrote:
> We already have a private data member for maximum display width so
> let's use it and get rid of the redundant tilcdc_crtc_max_width().
>
> The LCDC version probing is moved to before reading the devi
Hi Maxime,
Thank you for the patch.
On Mon, Oct 05, 2020 at 05:15:39PM +0200, Maxime Ripard wrote:
> The drm_of_lvds_get_dual_link_pixel_order() function took so far the
> device_node of the two ports used together to make up a dual-link LVDS
> output.
>
> This assumes that a binding would use a
35 matches
Mail list logo
