On Fri, Oct 23, 2020 at 11:20 AM Lucas Stach wrote:
>
> On Fr, 2020-10-23 at 09:51 -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > 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
On Fri, Oct 23, 2020 at 8:20 PM Jason Gunthorpe wrote:
>
> On Fri, Oct 23, 2020 at 06:49:11PM +0200, Daniel Vetter wrote:
> > > +struct ib_umem *ib_umem_dmabuf_get(struct ib_device *device,
> > > + unsigned long offset, size_t size,
> > > +
On 2020-10-23 03:46, Takashi Iwai wrote:
> Hi,
>
> the amdgpu driver's ASSERT_CRITICAL() macro calls the
> kgdb_breakpoing() even if no debug option is set, and this leads to a
> kernel panic on distro kernels. The first two patches are the
> oneliner fixes for those, while the last one is the
On Fri, Oct 23, 2020 at 10:03:50PM +, Simon Ser wrote:
> On Friday, October 23, 2020 10:39 PM, Ville Syrjala
> wrote:
>
> > From: Ville Syrjälä ville.syrj...@linux.intel.com
> >
> > The code responsible for creating the IN_FORMATS
> > blob is broken when the driver doesn't provide a
> >
On Friday, October 23, 2020 10:39 PM, Ville Syrjala
wrote:
> From: Ville Syrjälä ville.syrj...@linux.intel.com
>
> The code responsible for creating the IN_FORMATS
> blob is broken when the driver doesn't provide a
> .format_mod_supported() hook. It just copies in
> the format list, but leaves
The pull request you sent on Fri, 23 Oct 2020 10:03:10 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2020-10-23
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/fc03b2d6a9d1398dc855318d6ddfa3be57bdcf2c
Thank you!
--
Deet-doot-dot, I am a bot.
On Fri, Oct 23, 2020 at 02:21:15PM +0200, Daniel Vetter wrote:
> Extracted from slab.h, which seems to have the most complete version
> including the correct might_sleep() check. Roll it out to slob.c.
>
> Motivated by a discussion with Paul about possibly changing call_rcu
> behaviour to
On Fri, Oct 23, 2020 at 02:22:58PM -0500, Rob Herring wrote:
> Clean-up incorrect indentation, extra spaces, and missing EOF newline in
> schema files. Most of the clean-ups are for list indentation which
> should always be 2 spaces more than the preceding keyword.
>
> Found with yamllint (now
From: Ville Syrjälä
The code responsible for creating the IN_FORMATS
blob is broken when the driver doesn't provide a
.format_mod_supported() hook. It just copies in
the format list, but leaves all the modifier information
zeroed. That would indicate (in a very silly way) that
there are in fact
On Fri, Oct 23, 2020 at 02:22:58PM -0500, Rob Herring wrote:
> Clean-up incorrect indentation, extra spaces, and missing EOF newline in
> schema files. Most of the clean-ups are for list indentation which
> should always be 2 spaces more than the preceding keyword.
>
> Found with yamllint (now
https://bugzilla.kernel.org/show_bug.cgi?id=209713
Lahfa Samy (s...@lahfa.xyz) changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Clean-up incorrect indentation, extra spaces, and missing EOF newline in
schema files. Most of the clean-ups are for list indentation which
should always be 2 spaces more than the preceding keyword.
Found with yamllint (now integrated into the checks).
Cc: linux-arm-ker...@lists.infradead.org
Applied. Thanks!
Alex
On Fri, Oct 23, 2020 at 12:33 PM Mauro Carvalho Chehab
wrote:
>
> dm_comressor_info -> dm_compressor_info
>
> The kernel-doc markup is right, but the struct itself
> and their references contain a typo.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
>
Applied. Thanks!
Alex
On Fri, Oct 23, 2020 at 12:51 PM Christian König
wrote:
>
> Am 23.10.20 um 18:32 schrieb Mauro Carvalho Chehab:
> > Some functions have different names between their prototypes
> > and the kernel-doc markup.
> >
> > Signed-off-by: Mauro Carvalho Chehab
>
> Acked-by:
Applied. Thanks!
Alex
On Fri, Oct 23, 2020 at 12:38 PM Christian König
wrote:
>
> Am 23.10.20 um 18:32 schrieb Mauro Carvalho Chehab:
> > A kernel-doc markup can't be mixed with a random comment,
> > as it causes parsing problems.
> >
> > While here, change an invalid kernel-doc markup into
>
On Fr, 2020-10-23 at 09:51 -0700, Rob Clark wrote:
> From: Rob Clark
>
> 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
On Fri, Oct 23, 2020 at 8:09 PM Xiong, Jianxin wrote:
>
>
> > -Original Message-
> > From: Daniel Vetter
> > Sent: Friday, October 23, 2020 9:49 AM
> > To: Xiong, Jianxin
> > Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Leon
> > Romanovsky ; Jason Gunthorpe ;
> >
> -Original Message-
> From: Daniel Vetter
> Sent: Friday, October 23, 2020 9:49 AM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Leon
> Romanovsky ; Jason Gunthorpe ;
> Doug Ledford ; Vetter, Daniel ;
> Christian Koenig
> Subject: Re:
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
Reviewed-by: Kristian H. Kristensen
---
drivers/gpu/drm/msm/msm_gem.c | 1 -
From: Rob Clark
Before adding another lock, give ring->lock a more descriptive name.
Signed-off-by: Rob Clark
Reviewed-by: Jordan Crouse
Reviewed-by: Kristian H. Kristensen
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 ++--
drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 12 ++--
From: Rob Clark
We only want to use the _unlocked() variant in the unlocked case.
Signed-off-by: Rob Clark
Reviewed-by: Kristian H. Kristensen
---
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
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
Reviewed-by: Kristian H. Kristensen
---
drivers/gpu/drm/msm/msm_gem.c | 24
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
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
From: Rob Clark
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 used to synchronize buffer usage across
contexts (which is
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
Reviewed-by: Kristian H. Kristensen
---
drivers/gpu/drm/msm/msm_gpu.c | 8 +---
1 file changed, 1
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
Reviewed-by: Kristian H. Kristensen
---
drivers/gpu/drm/msm/msm_gem.c | 8
1 file changed, 8 deletions(-)
diff --git
Am 23.10.20 um 18:32 schrieb Mauro Carvalho Chehab:
Some functions have different names between their prototypes
and the kernel-doc markup.
Signed-off-by: Mauro Carvalho Chehab
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +-
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
Reviewed-by: Kristian H. Kristensen
---
drivers/gpu/drm/msm/msm_drv.c | 3 ---
drivers/gpu/drm/msm/msm_drv.h | 5 -
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
Reviewed-by: Kristian H. Kristensen
---
drivers/gpu/drm/msm/msm_debugfs.c | 7 +++
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
Reviewed-by: Kristian H. Kristensen
---
drivers/gpu/drm/msm/msm_gem.c | 99 ---
drivers/gpu/drm/msm/msm_gem.h | 28
From: Rob Clark
Signed-off-by: Rob Clark
Reviewed-by: Kristian H. Kristensen
---
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
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
Reviewed-by: Kristian H. Kristensen
---
drivers/gpu/drm/msm/msm_gpu.c | 28 ++--
1 file changed, 14
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
Reviewed-by: Kristian H. Kristensen
---
drivers/gpu/drm/msm/msm_gem.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
From: Rob Clark
The microcode bo's should never be madvise(WONTNEED), so these should
not be using msm_gem_get_vaddr_active().
Signed-off-by: Rob Clark
Reviewed-by: Kristian H. Kristensen
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 2 +-
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
2 files
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 --> >mmap_sem --> reservation_ww_class_mutex
For an explicit fencing userspace, the
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
From: Rob Clark
One less place to rely on dev->struct_mutex.
Signed-off-by: Rob Clark
Reviewed-by: Jordan Crouse
Reviewed-by: Kristian H. Kristensen
---
drivers/gpu/drm/msm/msm_gem_submit.c | 2 ++
drivers/gpu/drm/msm/msm_gpu.c| 37 ++--
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
Reviewed-by: Kristian H. Kristensen
---
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
From: Rob Clark
This also converts the special msm_gem_get_vaddr_active() to expect the
lock to already be held. There are two call-sites for this, one already
has the lock held, so it is more straightforward to just open-code the
locking for the other caller.
Signed-off-by: Rob Clark
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
Reviewed-by: Kristian H. Kristensen
---
drivers/gpu/drm/msm/msm_gem.c | 89
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
Reviewed-by: Kristian H. Kristensen
---
drivers/gpu/drm/msm/msm_gpu.c | 1 -
1 file
On Fri, Oct 23, 2020 at 09:39:58AM -0700, Jianxin Xiong wrote:
> Dma-buf is a standard cross-driver buffer sharing mechanism that can be
> used to support peer-to-peer access from RDMA devices.
>
> Device memory exported via dma-buf is associated with a file descriptor.
> This is passed to the
Am 23.10.20 um 18:32 schrieb Mauro Carvalho Chehab:
A kernel-doc markup can't be mixed with a random comment,
as it causes parsing problems.
While here, change an invalid kernel-doc markup into
a common comment.
Signed-off-by: Mauro Carvalho Chehab
Acked-by: Christian König
---
dm_comressor_info -> dm_compressor_info
The kernel-doc markup is right, but the struct itself
and their references contain a typo.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 6
Some identifiers have different names between their prototypes
and the kernel-doc markup.
Others need to be fixed, as kernel-doc markups should use this format:
identifier - description
Signed-off-by: Mauro Carvalho Chehab
---
drivers/gpu/drm/drm_atomic_state_helper.c | 2 +-
A kernel-doc markup should start with the identifier on its
first line.
Signed-off-by: Mauro Carvalho Chehab
---
include/drm/drm_print.h | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index
Some identifiers have different names between their prototypes
and the kernel-doc markup.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/video/fbdev/core/fbcmap.c | 2 +-
drivers/video/hdmi.c | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git
Some functions have different names between their prototypes
and the kernel-doc markup.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 2 +-
include/uapi/drm/amdgpu_drm.h| 2 +-
3 files
A kernel-doc markup can't be mixed with a random comment,
as it causes parsing problems.
While here, change an invalid kernel-doc markup into
a common comment.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 +---
1 file changed, 5 insertions(+), 3
This is the sixth version of the patch set. Changelog:
v6:
* Move the dma-buf invalidation callback from the core to the device
driver
* Move mapping update from work queue to pagefault handler
* Add dma-buf based MRs to the xarray of mmkeys so that the pagefault
handler can be reached
*
Dma-buf is a standard cross-driver buffer sharing mechanism that can be
used to support peer-to-peer access from RDMA devices.
Device memory exported via dma-buf is associated with a file descriptor.
This is passed to the user space as a property associated with the
buffer allocation. When the
Implement the new driver method 'reg_user_mr_dmabuf'. Utilize the core
functions to import dma-buf based memory region and update the mappings.
Add code to handle dma-buf related page fault.
Signed-off-by: Jianxin Xiong
Reviewed-by: Sean Hefty
Acked-by: Michael J. Ruhl
Acked-by: Christian
Implement a new uverbs ioctl method for memory registration with file
descriptor as an extra parameter.
Signed-off-by: Jianxin Xiong
Reviewed-by: Sean Hefty
Acked-by: Michael J. Ruhl
Acked-by: Christian Koenig
Acked-by: Daniel Vetter
---
drivers/infiniband/core/uverbs_std_types_mr.c | 112
Dma-buf based memory region requires one extra parameter and is processed
quite differently. Adding a separate method allows clean separation from
regular memory regions.
Signed-off-by: Jianxin Xiong
Reviewed-by: Sean Hefty
Acked-by: Michael J. Ruhl
Acked-by: Christian Koenig
Acked-by: Daniel
On Fri, Oct 23, 2020 at 9:00 AM Daniel Vetter wrote:
>
> On Fri, Oct 23, 2020 at 5:02 PM Rob Clark wrote:
> >
> > On Thu, Oct 22, 2020 at 12:16 PM Daniel Vetter
> > wrote:
> > >
> > > On Thu, Oct 22, 2020 at 7:22 PM Rob Clark wrote:
> > > >
> > > > On Thu, Oct 22, 2020 at 10:02 AM Rob Clark
There is no need to use the of_dma_request_slave_channel() directly as
dma_request_chan() is going to try to get the channel via OF as well.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git
There is a signedness bug in shmem_pin_map() error handling because "i"
is unsigned. The "while (--i >= 0)" will loop forever until the system
crashes.
Fixes: bfed6708d6c9 ("drm/i915: use vmap in shmem_pin_map")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/i915/gt/shmem_utils.c | 3 ++-
1
Only the following drivers aren't converted:
- amdgpu, because of the driver_feature mangling due to virt support
- nouveau, because DRIVER_ATOMIC uapi is still not the default on the
platforms where it's supported (i.e. again driver_feature mangling)
- vc4, again because of driver_feature
On Friday, October 23, 2020 5:27 PM, Ville Syrjälä
wrote:
> These are two extreme cases:
Thanks!
> > I'm trying to get
> > a fix for my user-space 1, and I'm wondering if int32_t is enough
> > after dividing by mode->htotal.
> > CC Pekka, just FYI (I think Weston has similar code).
>
> What's
On Fri, Oct 23, 2020 at 5:02 PM Rob Clark wrote:
>
> On Thu, Oct 22, 2020 at 12:16 PM Daniel Vetter wrote:
> >
> > On Thu, Oct 22, 2020 at 7:22 PM Rob Clark wrote:
> > >
> > > On Thu, Oct 22, 2020 at 10:02 AM Rob Clark wrote:
> > > >
> > > > On Wed, Oct 21, 2020 at 9:32 AM Daniel Vetter
> >
Hi, Fabien:
Fabien Parent 於 2020年10月23日 週五 下午9:31寫道：
>
> Add the main (DSI) drm display path for MT8167.
>
> Signed-off-by: Fabien Parent
> ---
>
> Changelog:
>
> V2: No change
>
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 38 ++
> 1 file changed, 38 insertions(+)
>
>
Hi, Fabien:
Fabien Parent 於 2020年10月23日 週五 下午9:31寫道：
>
> Add binding documentation for the MT8167 SoC.
Reviewed-by: Chun-Kuang Hu
In [1], Mediatek DPI binding document has been changed to yaml format,
would you please also change this document to yaml? Ditto for
mediatek,disp.txt.
[1]
Hi, Fabien:
Fabien Parent 於 2020年10月23日 週五 下午9:31寫道：
>
> Add DDP support for MT8167 SoC.
Reviewed-by: Chun-Kuang Hu
> Signed-off-by: Fabien Parent
> ---
>
> Changelog:
>
> V2: don't set DDP_MUTEX_SOF_DSI{1,2,3} since they are not available on MT8167
>
>
Hi Neil,
On Tue, 15 Sep 2020, Neil Armstrong
wrote:
Hi Adrian,
Gentle ping.
can you rebase on drm-misc-next so I can apply the IMX and STM
patches ?
Sorry for the late reply, somehow missed this e-mail chain.
I have a rebase of the series but further investigation revealed
we might
On Fri, Oct 23, 2020 at 03:14:20PM +, Simon Ser wrote:
> On Thursday, October 22, 2020 12:14 PM, Ville Syrjälä
> wrote:
>
> > On Wed, Oct 21, 2020 at 08:13:43PM -0700, Randy Dunlap wrote:
> >
> > > Hi,
> > > With linux-next 20201021, when booting up, I am seeing this:
> > > [ 0.560896]
Hi Daniel,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
linus/master v5.9 next-20201023]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
On Thu, Oct 22, 2020 at 2:50 PM Josh Fuhs wrote:
>
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, October 21, 2020 2:44 PM, Alex Deucher
> wrote:
>
> > On Mon, Oct 19, 2020 at 8:53 PM Josh Fuhs joshua.f...@pm.me wrote:
> >
> > > Thanks. I tried 5.9.1 and I think there's still a problem, or
On Thursday, October 22, 2020 12:14 PM, Ville Syrjälä
wrote:
> On Wed, Oct 21, 2020 at 08:13:43PM -0700, Randy Dunlap wrote:
>
> > Hi,
> > With linux-next 20201021, when booting up, I am seeing this:
> > [ 0.560896] UBSAN: signed-integer-overflow in
> > ../drivers/gpu/drm/drm_modes.c:765:20
>
On Thu, Oct 22, 2020 at 12:16 PM Daniel Vetter wrote:
>
> On Thu, Oct 22, 2020 at 7:22 PM Rob Clark wrote:
> >
> > On Thu, Oct 22, 2020 at 10:02 AM Rob Clark wrote:
> > >
> > > On Wed, Oct 21, 2020 at 9:32 AM Daniel Vetter
> > > wrote:
> > > >
> > > > The stuff never really worked, and leads
On Fri, Oct 23, 2020 at 4:54 PM Christian König
wrote:
>
> Am 23.10.20 um 14:21 schrieb Daniel Vetter:
> > ttm_resource_manager->use_type is only used for runtime changes by
> > vmwgfx. I think ideally we'd push this functionality into drivers -
> > ttm itself does not provide any locking to
Am 23.10.20 um 14:21 schrieb Daniel Vetter:
ttm_resource_manager->use_type is only used for runtime changes by
vmwgfx. I think ideally we'd push this functionality into drivers -
ttm itself does not provide any locking to guarantee this is safe, so
the only way this can work at runtime is if the
On Fri, Oct 23, 2020 at 1:55 AM Kristian Høgsberg wrote:
>
> On Mon, Oct 19, 2020 at 10:45 PM Rob Clark wrote:
> >
> > 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
On Fri, Oct 23, 2020 at 4:37 PM Daniel Vetter wrote:
>
> On Fri, Oct 23, 2020 at 4:16 PM Matthew Wilcox wrote:
> >
> > On Fri, Oct 23, 2020 at 02:21:15PM +0200, Daniel Vetter wrote:
> > > Note that unlike fs_reclaim_acquire/release gfpflags_allow_blocking
> > > does not consult the PF_MEMALLOC
On Fri, Oct 23, 2020 at 4:16 PM Matthew Wilcox wrote:
>
> On Fri, Oct 23, 2020 at 02:21:15PM +0200, Daniel Vetter wrote:
> > Note that unlike fs_reclaim_acquire/release gfpflags_allow_blocking
> > does not consult the PF_MEMALLOC flags. But there is no flag
> > equivalent for GFP_NOWAIT, hence
On 10/23/20 2:21 PM, Daniel Vetter wrote:
Extracted from slab.h, which seems to have the most complete version
including the correct might_sleep() check. Roll it out to slob.c.
Motivated by a discussion with Paul about possibly changing call_rcu
behaviour to allocate memory, but only roughly
We're seeing channel equalization "fail" consistently coming out of DPMS
on the eDP of a Dell Latitude 7200 2-in-1. When the display tries to
come out of DPMS, it briefly flashes on before going dark. This repeats
once per second, and the system is unusable. ssh-ing into the system,
it also
It's the horror and shouldn't be used. Realized we're not clear on
this in a discussion with Rob about what msm is doing to better
support async commits.
v2: Refine existing todo item to include this (Thomas)
Cc: Sean Paul
Cc: Rob Clark
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc:
The stuff never really worked, and leads to lots of fun because it
out-of-order frees atomic states. Which upsets KASAN, among other
things.
For async updates we now have a more solid solution with the
->atomic_async_check and ->atomic_async_commit hooks. Support for that
for msm and vc4 landed.
With the removal of helper support it doesn't do anything anymore.
Also, we already have async plane update code in vc4.
Acked-by: Maxime Ripard
Signed-off-by: Daniel Vetter
Cc: Eric Anholt
Cc: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_kms.c | 6 --
1 file changed, 6 deletions(-)
diff
On Thu, Oct 01, 2020 at 08:46:59AM +1000, Ben Skeggs wrote:
> On Wed, 30 Sep 2020 at 19:37, Daniel Vetter wrote:
> >
> > On Wed, Sep 30, 2020 at 10:45:05AM +1000, Ben Skeggs wrote:
> > > On Wed, 30 Sep 2020 at 00:52, Daniel Vetter
> > > wrote:
> > > >
> > > > On Thu, Sep 17, 2020 at 3:15 PM
This requires for HDCP 2.2 MST check link.
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_display_types.h | 3 ++-
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdcp.c | 2 +-
Add HDCP 2.2 DP MST HDCP2_STREAM_STATUS
and HDCP2_AUTH_STREAM register in i915_reg header.
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/i915_reg.h | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
Enable HDCP 2.2 over DP MST.
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 46 ++-
1 file changed, 44 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
Add support for HDCP 2.2 DP MST shim callback.
This adds existing DP HDCP shim callback for Link Authentication
and Encryption and HDCP 2.2 stream encryption
callback.
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
.../drm/i915/display/intel_display_types.h| 4 +
Enable HDCP 1.4 over DP MST for Gen12.
This also enable the stream encryption support for
older generations, which was missing earlier.
v2:
- Added debug print for stream encryption.
- Disable the hdcp on port after disabling last stream
encryption.
Cc: Ramalingam C
Signed-off-by: Anshuman
Both HDCP_{1.x,2.x} requires to select/deselect Multistream HDCP bit
in TRANS_DDI_FUNC_CTL in order to enable/disable stream HDCP
encryption over DP MST Transport Link.
HDCP 1.4 stream encryption requires to validate the stream encryption
status in HDCP_STATUS_{TRANSCODER,PORT} register driving
Add support for multiple mst stream in hdcp port data
which will be used by RepeaterAuthStreamManage msg and
HDCP 2.2 security f/w for m' validation.
v2:
Init the hdcp port data k for HDMI/DP SST strem.
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
Pass dig_port as an argument to intel_hdcp_init()
and intel_hdcp2_init().
This will be required for HDCP 2.2 stream encryption.
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 4 ++--
drivers/gpu/drm/i915/display/intel_hdcp.c| 12
Let's define Maximum MST content streams up to four
generically which can be supported by modern display
controllers.
Cc: Sean Paul
Cc: Ramalingam C
Acked-by: Maarten Lankhorst
Signed-off-by: Anshuman Gupta
---
include/drm/drm_hdcp.h | 8
1 file changed, 4 insertions(+), 4
hdcp_port_data is specific to a port on which HDCP
encryption is getting enabled, so encapsulate it to
intel_digital_port.
This will be required to enable HDCP 2.2 stream encryption.
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_ddi.c | 2 +
Fix the size of WIRED_REPEATER_AUTH_STREAM_REQ cmd buffer size.
It is based upon the actual number of MST streams and size
of wired_cmd_repeater_auth_stream_req_in.
Excluding the size of hdcp_cmd_header.
v2:
hdcp_cmd_header size annotation nitpick. [Tomas]
Cc: Tomas Winkler
Cc: Ramalingam C
When crtc state need_modeset is true it is not necessary
it is going to be a real modeset, it can turns to be a
update_pipe instead of modeset.
This turns content protection property to be DESIRED and hdcp
update_pipe left with property to be in DESIRED state but
actually hdcp->value was ENABLED.
DP MST stream encryption status requires time of a link frame
in order to change its status, but as there were some HDCP
encryption timeout observed earlier, it is safer to use
ENCRYPT_STATUS_CHANGE_TIMEOUT_MS timeout for stream status too,
it requires to move the macro to a header.
It will be
Get DRM connector reference count while scheduling a prop work
to avoid any possible destroy of DRM connector when it is in
DRM_CONNECTOR_REGISTERED state.
Fixes: a6597faa2d59 ("drm/i915: Protect workers against disappearing
connectors")
Cc: Sean Paul
Cc: Ramalingam C
Signed-off-by: Anshuman
This is v3 version to test with IGT
https://patchwork.freedesktop.org/series/82987/
This has some fix for Type1 content igt test.
It has been also tested manually with IGT above series.
[PATCH v3 10/16] misc/mei/hdcp: Fix AUTH_STREAM_REQ cmd buffer len
has an Ack from Tomas to merge it via
Handle CP_IRQ in DEVICE_SERVICE_IRQ_VECTOR_ESI0
It requires to call intel_hdcp_handle_cp_irq() in case
of CP_IRQ is triggered by a sink in DP-MST topology.
Cc: "Ville Syrjälä"
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_dp.c | 14 +-
1
Gen12 has H/W delta with respect to HDCP{1.x,2.x} display engine
instances lies in Transcoder instead of DDI as in Gen11.
This requires hdcp driver to use mst_master_transcoder for link
authentication and stream transcoder for stream encryption
separately.
This will be used for both HDCP 1.4 and
On Fri, Sep 04, 2020 at 04:39:27PM +0200, Daniel Vetter wrote:
> - Need to embedded the drm_device, but for now we keep the usual
> pointer chasing.
> - No more devm_kzalloc, which fixes a lifetime issues on driver
> remove.
> - No more drm_dev_put, that's done by devm_ now.
>
> Acked-by: Sam
1 - 100 of 188 matches
Mail list logo
