On Fri, Nov 27, 2020 at 5:42 PM Daniel Vetter wrote:
>
> Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims
> the region") /dev/kmem zaps ptes when the kernel requests exclusive
> acccess to an iomem region. And with CONFIG_IO_STRICT_DEVMEM, this is
> the default for all driver us
On Mon, 18 Jan 2021, Daniel Vetter wrote:
> On Mon, Jan 18, 2021 at 03:09:45PM +, Lee Jones wrote:
> > On Mon, 18 Jan 2021, Daniel Vetter wrote:
> >
> > > On Fri, Jan 15, 2021 at 06:27:15PM +, Zack Rusin wrote:
> > > >
> > > > > On Jan 15, 2021, at 13:15, Lee Jones wrote:
> > > > >
> >
On Mon, 18 Jan 2021 09:36:47 -0500
Aurabindo Pillai wrote:
> On Thu, 2021-01-14 at 11:14 +0200, Pekka Paalanen wrote:
> >
> > Hi,
> >
> > please document somewhere that ends up in git history (commit
> > message,
> > code comments, description of the parameter would be the best but
> > maybe
>
On Fri, Jan 15, 2021 at 08:12:09PM +0100, Nicolas Saenz Julienne wrote:
> User-space ALSA matches a card's driver name against an internal list of
> aliases in order to select the correct configuration for the system.
> When the driver name isn't defined, the match is performed against the
> card's
Hi,
Just a comment about the comments:
On 1/18/21 10:03 AM, Christian König wrote:
> DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT can't be used when we hold locks
> since we are basically waiting for userspace to do something.
>
> Holding a lock while doing so can trivial deadlock with page faults
> e
> attached patchfile and report if it fixes the issue?
Yes, fixed. Thanks.
18.01.2021 08:25, Thomas Zimmermann пишет:
(cc'ing dri-devel)
Hi
thanks for reporting the bug.
Am 17.01.21 um 12:12 schrieb Andy Lavr:
Hey,
You forgot to add these commits to linux-next:
drm: Move struct drm
On 12/01/2021 16:24, Hans Verkuil wrote:
> Hi Maxime,
>
> On 11/01/2021 15:22, Maxime Ripard wrote:
>> Hi,
>>
>> Here's a series introducing the CEC support for the BCM2711 found on the
>> RaspberryPi4.
>>
>> The BCM2711 HDMI controller uses a similar layout for the CEC registers, the
>> main diff
On Tue, Jan 5, 2021 at 3:06 AM Yongqiang Niu wrote:
>
> The following series are intended to prepare the mtk-mmsys driver to
> allow different DDP (Data Display Path) function call per SoC.
>
> base 5.11-rc1
>
> change since v3:
> - move register operation into mmsys path select function
>
> Yongq
On Mon, Jan 18, 2021 at 10:30:56AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 18.01.21 um 10:13 schrieb Eli Cohen:
> > On Mon, Jan 18, 2021 at 08:54:07AM +0100, Thomas Zimmermann wrote:
> > > Hi
> > >
> > > Am 18.01.21 um 08:43 schrieb Christian König:
> > > > Hi Eli,
> > > >
> > > > have you a
On Mon, Jan 18, 2021 at 01:10:40PM +0100, Nicolas Saenz Julienne wrote:
> Hi Stefan, Maxime,
>
> On Mon, 2021-01-18 at 12:28 +0100, Stefan Wahren wrote:
> > Hi,
> >
> > Am 15.01.21 um 19:39 schrieb Mark Brown:
> > > On Fri, Jan 15, 2021 at 07:14:37PM +0100, Maxime Ripard wrote:
> > > > On Wed, Ja
18.01.2021 09:22, Thomas Zimmermann пишет:
Hi
Am 18.01.21 um 10:14 schrieb Andy Lavr:
> attached patchfile and report if it fixes the issue?
Yes, fixed. Thanks.
OK. Can I add you in Tested-by and Reported-by tag to the fix?
Andy Lavr
Best regards
Thomas
18.01.2021 08:25, Tho
On Mon, Jan 18, 2021 at 10:30:56AM +0100, Thomas Zimmermann wrote:
>
> Here's the patch against the latest DRM tree. v5.11-rc3 should work as well.
>
> I was able to reproduce the memory leak locally and found that the patch
> fixes it. Please give it a try.
>
As far as I am concerned, this iss
On Mon, Jan 18, 2021 at 08:57:26AM +0100, Christian König wrote:
> Am 18.01.21 um 08:49 schrieb Eli Cohen:
> > On Mon, Jan 18, 2021 at 08:43:12AM +0100, Christian König wrote:
> > > Hi Eli,
> > >
> > > have you already tried using kmemleak?
> > >
> > > This sounds like a leak of memory allocated
The previous registers were *almost* correct, but instead of
PHYs, they were pointing at DSI PLLs, resulting in the PHY id
autodetection failing miserably.
Fixes: dcefc117cc19 ("drm/msm/dsi: Add support for msm8x94")
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_20nm.c | 2
On Mon, Jan 18, 2021 at 02:20:49PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 18.01.21 um 14:16 schrieb Eli Cohen:
> > On Mon, Jan 18, 2021 at 10:30:56AM +0100, Thomas Zimmermann wrote:
> > >
> > > Here's the patch against the latest DRM tree. v5.11-rc3 should work as
> > > well.
> > >
> > > I
On Mon, Jan 18, 2021 at 08:54:07AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 18.01.21 um 08:43 schrieb Christian König:
> > Hi Eli,
> >
> > have you already tried using kmemleak?
> >
> > This sounds like a leak of memory allocated using kmalloc(), so kmemleak
> > should be able to catch it.
>
Hi Stefan, Maxime,
On Mon, 2021-01-18 at 12:28 +0100, Stefan Wahren wrote:
> Hi,
>
> Am 15.01.21 um 19:39 schrieb Mark Brown:
> > On Fri, Jan 15, 2021 at 07:14:37PM +0100, Maxime Ripard wrote:
> > > On Wed, Jan 13, 2021 at 11:42:23AM +, Mark Brown wrote:
> > > > On Wed, Jan 13, 2021 at 10:19:
With commit 55c5cc63ab, the hdmi_codec_set_jack() will report unsupport
failure if set_jack handler is missing. Add set_jack handler to resolve
this failure.
Signed-off-by: Jun Nie
---
.../gpu/drm/bridge/adv7511/adv7511_audio.c| 27 ++-
1 file changed, 20 insertions(+), 7 del
Hi Laurent,
Le lun. 18 janv. 2021 à 11:43, Laurent Pinchart
a écrit :
Hi Paul,
Thank you for the patch.
On Sun, Jan 17, 2021 at 11:26:45AM +, Paul Cercueil wrote:
Since the encoders have been devm-allocated, they will be freed way
before drm_mode_config_cleanup() is called. To avoid u
Hi Sam
On Fri, Jan 15, 2021 at 09:43:24PM +0100, Sam Ravnborg wrote:
> On Fri, Jan 15, 2021 at 01:56:55PM +0100, Maxime Ripard wrote:
> > Subsequent reworks will pass the global atomic state in the function
> > prototype, and atomic_check and atomic_update already have such a
> > variable already.
Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
On device removal reroute all CPU mappings to dummy page.
v3:
Remove loop to find DRM file and instead access it
by vma->vm_file->private_data. Move dummy page installation
into a separate function.
v4:
Map the entire BOs VA space into on demand a
This is a bug fix and should probably be pushed separately to drm-misc-next.
Christian.
Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
To avoid any possible use after free.
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
---
drivers/gpu/drm/scheduler/sched_main.c | 3 +++
1
Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
Some of the stuff in amdgpu_device_fini such as HW interrupts
disable and pending fences finilization must be done right away on
pci_remove while most of the stuff which relates to finilizing and
releasing driver data structures can be kept until
dr
Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
Handle all DMA IOMMU gropup related dependencies before the
group is removed.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 5
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 46 +++
Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
We can't allocate and submit IBs post device unplug.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
On device removal reroute all CPU mappings to dummy page
per drm_file instance or imported GEM object.
v4:
Update for modified ttm_bo_vm_dummy_page
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgp
Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
This allows to remove explicit creation and destruction
of those attrs and by this avoids warnings on device
finilizing post physical device extraction.
Signed-off-by: Andrey Grodzovsky
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdg
Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
This should prevent writing to memory or IO ranges possibly
already allocated for other uses after our device is removed.
Wow, that adds quite some overhead to every register access. I'm not
sure we can do this.
Christian.
Signed-off-by: And
On Mon, Jan 18, 2021 at 07:03:34PM +0100, Christian König wrote:
> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> index 6e74e6745eca..f51458615158 100644
> --- a/drivers/gpu/drm/drm_syncobj.c
> +++ b/drivers/gpu/drm/drm_syncobj.c
> @@ -387,6 +387,13 @@ int drm_syncobj
Am 19.01.21 um 10:35 schrieb Peter Zijlstra:
On Mon, Jan 18, 2021 at 07:03:34PM +0100, Christian König wrote:
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 6e74e6745eca..f51458615158 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.
Added a CC: stable tag and pushed it.
Thanks,
Christian.
Am 19.01.21 um 09:42 schrieb Christian König:
This is a bug fix and should probably be pushed separately to
drm-misc-next.
Christian.
Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
To avoid any possible use after free.
Signed-off-by
On Tue, Jan 19, 2021 at 10:46:53AM +0100, Christian König wrote:
> But I'm going to double check if drm_syncobj_fence_add_wait() isn't used
> elsewhere as well.
drm_syncobj_array_wait_timeout()
Which is why I asked.. :-)
___
dri-devel mailing list
dri-d
Am 19.01.21 um 11:05 schrieb Peter Zijlstra:
On Tue, Jan 19, 2021 at 10:46:53AM +0100, Christian König wrote:
But I'm going to double check if drm_syncobj_fence_add_wait() isn't used
elsewhere as well.
drm_syncobj_array_wait_timeout()
Which is why I asked.. :-)
Ok, good point as well. But th
On Tuesday, January 19th, 2021 at 2:54 AM, Lyude Paul wrote:
> Nvidia hardware doesn't actually support using tiling formats with the
> cursor plane, only linear is allowed. In the future, we should write a
> testcase for this.
>
> Fixes: c586f30bf74c ("drm/nouveau/kms: Add format mod prop to
>
On Tuesday, January 19th, 2021 at 2:54 AM, Lyude Paul wrote:
> Cc: Martin Peres
> Cc: Jeremy Cline
> Cc: Simon Ser
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/dis
> Cc: Martin Peres
> Cc: Jeremy Cline
> Cc: Simon Ser
> Signed-off-by: Lyude Paul
Code LGTM:
Reviewed-by: Simon Ser
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
https://bugzilla.kernel.org/show_bug.cgi?id=211277
Bug ID: 211277
Summary: sometimes crash at s2ram-wake (Ryzen 3500U): amdgpu,
drm, commit_tail, amdgpu_dm_atomic_commit_tail
Product: Drivers
Version: 2.5
Kernel Version: 5.10.4
https://bugzilla.kernel.org/show_bug.cgi?id=211277
--- Comment #1 from kolAflash (kolafl...@kolahilft.de) ---
Created attachment 294747
--> https://bugzilla.kernel.org/attachment.cgi?id=294747&action=edit
kern.log
--
You may reply to this email to add a comment.
You are receiving this mail be
https://bugzilla.kernel.org/show_bug.cgi?id=211277
--- Comment #2 from kolAflash (kolafl...@kolahilft.de) ---
Created attachment 294749
--> https://bugzilla.kernel.org/attachment.cgi?id=294749&action=edit
BIOS update history (just in case someone has a clue if something looks
suspicios and this
drm-misc-next-2021-01-19:
drm-misc-next for v5.12:
UAPI Changes:
- Fix fourcc macro for amlogic video fbc.
Cross-subsystem Changes:
- Export pci_rebar_bytes_to_size.
- Add a PCI quirk to increase bar0 for RX 5600 XT Pulse to max possible size.
- Convert devicetree bindings to use the OF graph sch
DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT can't be used when we hold locks
since we are basically waiting for userspace to do something.
Holding a lock while doing so can trivial deadlock with page faults
etc...
So make lockdep complain when a driver tries to do this.
v2: Add lockdep_assert_none_he
https://bugzilla.kernel.org/show_bug.cgi?id=211219
Aleksandr Makarov (aleksandr.o.maka...@gmail.com) changed:
What|Removed |Added
CC||dri-de
Am 07.01.21 um 17:38 schrieb Daniel Vetter:
On Thu, Jan 07, 2021 at 01:49:45PM +0100, Christian König wrote:
Am 22.12.20 um 14:51 schrieb Daniel Vetter:
On Fri, Dec 18, 2020 at 06:55:38PM +0100, Christian König wrote:
Only initialize the DMA coherent pools if they are used.
Signed-off-by: Chr
As far as I can tell the buffer_count was never used by an
userspace application.
The number of BOs in the system is far better suited in
debugfs than sysfs and we now should be able to add other
information here as well.
v2: add that additionally to sysfs
Signed-off-by: Christian König
Acked-b
Useful for testing.
v2: add fs_reclaim_acquire()/_release()
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_pool.c | 53 ++
1 file changed, 35 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
Instead of printing this on the per device pool.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_pool.c | 70 --
1 file changed, 50 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index 7b2f60
Only initialize the DMA coherent pools if they are used.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_pool.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index 98ecb9c984
On 27/11/2020 17:41, Daniel Vetter wrote:
> The media model assumes that buffers are all preallocated, so that
> when a media pipeline is running we never miss a deadline because the
> buffers aren't allocated or available.
>
> This means we cannot fix the v4l follow_pfn usage through
> mmu_notifi
On Mon, Jan 18, 2021 at 2:47 PM Yiwei Zhang wrote:
>
> On the success of virtio_gpu_object_create, add size of newly allocated
> bo to the tracled total_mem. In drm_gem_object_funcs.free, after the gem
> bo lost its last refcount, subtract the bo size from the tracked
> total_mem if the original u
On the success of virtio_gpu_object_create, add size of newly allocated
bo to the tracled total_mem. In drm_gem_object_funcs.free, after the gem
bo lost its last refcount, subtract the bo size from the tracked
total_mem if the original underlying memory allocation is successful.
Signed-off-by: Yiw
On the success of virtio_gpu_object_create, add size of newly allocated
bo to the tracled total_mem. In drm_gem_object_funcs.free, after the gem
bo lost its last refcount, subtract the bo size from the tracked
total_mem if the original underlying memory allocation is successful.
Signed-off-by: Yiw
While reviewing Christian's annotation patch I noticed that we have a
user-after-free for the WAIT_FOR_SUBMIT case: We drop the syncobj
reference before we've completed the waiting.
Of course usually there's nothing bad happening here since userspace
keeps the reference, but we can't rely on users
On Tue, Jan 19, 2021 at 12:48 PM Christian König
wrote:
>
> DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT can't be used when we hold locks
> since we are basically waiting for userspace to do something.
>
> Holding a lock while doing so can trivial deadlock with page faults
> etc...
>
> So make lockdep c
Am 19.01.21 um 14:03 schrieb Daniel Vetter:
While reviewing Christian's annotation patch I noticed that we have a
user-after-free for the WAIT_FOR_SUBMIT case: We drop the syncobj
reference before we've completed the waiting.
Of course usually there's nothing bad happening here since userspace
k
On Tue, Jan 19, 2021 at 9:35 AM Pekka Paalanen wrote:
>
> On Mon, 18 Jan 2021 09:36:47 -0500
> Aurabindo Pillai wrote:
>
> > On Thu, 2021-01-14 at 11:14 +0200, Pekka Paalanen wrote:
> > >
> > > Hi,
> > >
> > > please document somewhere that ends up in git history (commit
> > > message,
> > > code
On Tue, Jan 19, 2021 at 01:11:36PM +0100, Christian König wrote:
> Am 07.01.21 um 17:38 schrieb Daniel Vetter:
> > On Thu, Jan 07, 2021 at 01:49:45PM +0100, Christian König wrote:
> > > Am 22.12.20 um 14:51 schrieb Daniel Vetter:
> > > > On Fri, Dec 18, 2020 at 06:55:38PM +0100, Christian König wro
On Tue, Jan 19, 2021 at 04:11:27AM -0800, Pan Bian wrote:
> Put the state before returning error code.
>
> Fixes: 44596b8c4750 ("drm/atomic: Unify conflicting encoder handling.")
>
> Signed-off-by: Pan Bian
Nice catch, patch merged to drm-misc-fixes with cc: stable.
-Daniel
> ---
> drivers/gp
On Tue, Jan 19, 2021 at 09:48:03AM +0100, Christian König wrote:
> Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
> > Handle all DMA IOMMU gropup related dependencies before the
> > group is removed.
> >
> > Signed-off-by: Andrey Grodzovsky
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu.h
On Mon, Jan 18, 2021 at 04:01:10PM -0500, Andrey Grodzovsky wrote:
> On device removal reroute all CPU mappings to dummy page.
>
> v3:
> Remove loop to find DRM file and instead access it
> by vma->vm_file->private_data. Move dummy page installation
> into a separate function.
>
> v4:
> Map the e
On Tue, Jan 19, 2021 at 01:18:19PM +0100, Christian König wrote:
> Instead of printing this on the per device pool.
>
> Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
btw I think ttm should also set up the per-bdev debugfs stuff, feels silly
having that boilerplate. Same for the per
On Tue, Jan 19, 2021 at 01:18:20PM +0100, Christian König wrote:
> Useful for testing.
>
> v2: add fs_reclaim_acquire()/_release()
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/ttm/ttm_pool.c | 53 ++
> 1 file changed, 35 insertions(+), 18 deletions(
Only planes that are displayed via the Display Processor (DP) path
support color space conversion. Limit formats on planes that are
shown via the direct Display Controller (DC) path to RGB.
Reported-by: Fabio Estevam
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/ipuv3-plane.c | 41 ++
On Tue, Jan 19, 2021 at 01:18:21PM +0100, Christian König wrote:
> Only initialize the DMA coherent pools if they are used.
>
> Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/ttm/ttm_pool.c | 23 ---
> 1 file changed, 16 insertions(+), 7
On Mon, Jan 18, 2021 at 04:01:09PM -0500, Andrey Grodzovsky wrote:
> Until now extracting a card either by physical extraction (e.g. eGPU with
> thunderbolt connection or by emulation through syfs ->
> /sys/bus/pci/devices/device_id/remove)
> would cause random crashes in user apps. The random
On Tue, Jan 19, 2021 at 09:17:55AM +0100, Daniel Vetter wrote:
> On Fri, Nov 27, 2020 at 5:42 PM Daniel Vetter wrote:
> >
> > Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims
> > the region") /dev/kmem zaps ptes when the kernel requests exclusive
> > acccess to an iomem region.
On Tue, Jan 19, 2021 at 3:32 PM Greg Kroah-Hartman
wrote:
>
> On Tue, Jan 19, 2021 at 09:17:55AM +0100, Daniel Vetter wrote:
> > On Fri, Nov 27, 2020 at 5:42 PM Daniel Vetter
> > wrote:
> > >
> > > Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims
> > > the region") /dev/kmem z
FYI patches 1 and 5 are now in drm-misc-next.
Am 18.01.21 um 14:14 schrieb Thomas Zimmermann:
I merged more patches into drm-misc-next. I'm mostly sending out v4 of
this patchset to split the final patch into the core changes and the
patch for moving pdev behind CONFIG_DRM_LEGACY. The former are
On Tue, Jan 19, 2021 at 03:34:47PM +0100, Daniel Vetter wrote:
> On Tue, Jan 19, 2021 at 3:32 PM Greg Kroah-Hartman
> wrote:
> >
> > On Tue, Jan 19, 2021 at 09:17:55AM +0100, Daniel Vetter wrote:
> > > On Fri, Nov 27, 2020 at 5:42 PM Daniel Vetter
> > > wrote:
> > > >
> > > > Since 3234ac664a87
There is really no other way according to this article
https://lwn.net/Articles/767885/
"A perfect solution seems nearly impossible though; we cannot acquire a mutex on
the user
to prevent them from yanking a device and we cannot check for a presence change
after every
device access for perfo
The is also the possibility to have the drm_dev_enter/exit much more
high level.
E.g. we should it have anyway on every IOCTL and what remains are work
items, scheduler threads and interrupts.
Christian.
Am 19.01.21 um 16:35 schrieb Andrey Grodzovsky:
There is really no other way according t
Changes in V5
=
* More info in commit messages on the rationale of changes being added
to the kernel.
* Minor fixes
Changes in V4
=
1) Add module parameter for freesync video mode
* Change module parameter name to freesync_video
2) Add freesync video modes based on pref
[Why]
This option shall be opt-in by default since it is a temporary solution
until long term solution is agreed upon which may require userspace interface
changes. There has been precedent of manufacturing modes in the kernel. In
AMDGPU, the existing usage are for common modes and scaling modes. O
On Mon, Jan 18, 2021 at 08:54:12PM -0500, Lyude Paul wrote:
> Nvidia hardware doesn't actually support using tiling formats with the
> cursor plane, only linear is allowed. In the future, we should write a
> testcase for this.
There are a couple of old modifier/format sanity tests here:
https://pa
[Why]
A seamless transition between modes can be performed if the new incoming
mode has the same timing parameters as the optimized mode on a display with a
variable vtotal min/max.
Smooth video playback usecases can be enabled with this seamless transition by
switching to a new mode which has a r
[Why]
While possible for userspace to create and add custom mode based off the
optimized mode for the connected display which differs only in front porch
timing, this patch set adds a list of common video modes in advance.
The list of common video refresh rates is small, well known and the optimiz
Gah, yes, good catch.
Reviewed-by: James Jones
On 1/18/21 5:54 PM, Lyude Paul wrote:
Nvidia hardware doesn't actually support using tiling formats with the
cursor plane, only linear is allowed. In the future, we should write a
testcase for this.
Fixes: c586f30bf74c ("drm/nouveau/kms: Add form
On Tue, Jan 19, 2021 at 02:05:09PM +0100, Daniel Vetter wrote:
> > diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
> > index b9e9adec73e8..6eb117c0d0f3 100644
> > --- a/include/linux/lockdep.h
> > +++ b/include/linux/lockdep.h
> > @@ -310,6 +310,10 @@ extern void lock_unpin_lock(str
On Tue, Jan 19, 2021 at 4:20 PM Greg Kroah-Hartman
wrote:
>
> On Tue, Jan 19, 2021 at 03:34:47PM +0100, Daniel Vetter wrote:
> > On Tue, Jan 19, 2021 at 3:32 PM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Tue, Jan 19, 2021 at 09:17:55AM +0100, Daniel Vetter wrote:
> > > > On Fri, Nov 27, 2020 at
[AMD Official Use Only - Internal Distribution Only]
Hi Daniel,
Could you please be more specific about the _unsafe API options you mentioned ?
--
Thanks & Regards,
Aurabindo Pillai
From: Daniel Vetter
Sent: Tuesday, January 19, 2021 8:11 AM
To: Pekka Paalanen
Hi Phillip,
On Tue, Jan 19, 2021 at 11:08 AM Philipp Zabel wrote:
>
> Only planes that are displayed via the Display Processor (DP) path
> support color space conversion. Limit formats on planes that are
> shown via the direct Display Controller (DC) path to RGB.
>
> Reported-by: Fabio Estevam
>
On Mon, Jan 18, 2021 at 11:00 PM Daniel Vetter wrote:
>
> On Mon, Jan 18, 2021 at 11:00 PM Fabio Estevam wrote:
> >
> > On Mon, Jan 18, 2021 at 6:44 PM Fabio Estevam wrote:
> > >
> > > Adding some more folks in case anyone has any suggestions to fix this
> > > reboot hang.
> >
> > Not sure if th
On 1/19/21 2:34 AM, Greg KH wrote:
On Mon, Jan 18, 2021 at 04:01:19PM -0500, Andrey Grodzovsky wrote:
static struct pci_driver amdgpu_kms_pci_driver = {
.name = DRIVER_NAME,
.id_table = pciidlist,
@@ -1595,6 +1607,7 @@ static struct pci_driver amdgpu_kms_pci_driver = {
forgot to CC Krishna
On Tue, Jan 19, 2021 at 8:34 AM Rob Clark wrote:
>
> On Mon, Jan 18, 2021 at 11:00 PM Daniel Vetter wrote:
> >
> > On Mon, Jan 18, 2021 at 11:00 PM Fabio Estevam wrote:
> > >
> > > On Mon, Jan 18, 2021 at 6:44 PM Fabio Estevam wrote:
> > > >
> > > > Adding some more folks
On Mon, Jan 18, 2021 at 1:39 PM Will Deacon wrote:
>
> On Mon, Jan 18, 2021 at 01:16:03PM -0800, Rob Clark wrote:
> > On Mon, Dec 21, 2020 at 4:44 PM Isaac J. Manjarres
> > wrote:
> > >
> > > The MSM DRM driver depends on the availability of the ARM LPAE io-pgtable
> > > format code to work prope
On 1/19/21 9:16 AM, Daniel Vetter wrote:
On Mon, Jan 18, 2021 at 04:01:09PM -0500, Andrey Grodzovsky wrote:
Until now extracting a card either by physical extraction (e.g. eGPU with
thunderbolt connection or by emulation through syfs ->
/sys/bus/pci/devices/device_id/remove)
would cause rando
Hi Rob,
On Tue, Jan 19, 2021 at 1:40 PM Rob Clark wrote:
> > I suppose we should do the drm_atomic_helper_shutdown() conditionally?
This suggestion works, thanks. I will submit a patch shortly.
Thanks
___
dri-devel mailing list
dri-devel@lists.freede
Calling the drm_atomic_helper_shutdown() on i.MX5 leads to
the following flow:
[ 24.557742] [] (msm_atomic_commit_tail) from []
(commit_tail+0xa4/0x1b0)
[ 24.566349] [] (commit_tail) from []
(drm_atomic_helper_commit+0x154/0x188)
[ 24.575193] [] (drm_atomic_helper_commit) from
[] (drm_atomic
On 2021-01-19 2:53 a.m., Christian König wrote:
> Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
>> From: Luben Tuikov
>>
>> This patch does not change current behaviour.
>>
>> The driver's job timeout handler now returns
>> status indicating back to the DRM layer whether
>> the task (job) was su
On Tue, Jan 19, 2021 at 6:36 PM Fabio Estevam wrote:
>
> Hi Rob,
>
> On Tue, Jan 19, 2021 at 1:40 PM Rob Clark wrote:
>
> > > I suppose we should do the drm_atomic_helper_shutdown() conditionally?
>
> This suggestion works, thanks. I will submit a patch shortly.
I think the cleanest way to do th
On Tue, Jan 19, 2021 at 6:47 PM Fabio Estevam wrote:
>
> Calling the drm_atomic_helper_shutdown() on i.MX5 leads to
> the following flow:
>
> [ 24.557742] [] (msm_atomic_commit_tail) from []
> (commit_tail+0xa4/0x1b0)
> [ 24.566349] [] (commit_tail) from []
> (drm_atomic_helper_commit+0x154/0x
On Tue, Jan 19, 2021 at 4:35 PM Andrey Grodzovsky
wrote:
>
> There is really no other way according to this article
> https://lwn.net/Articles/767885/
>
> "A perfect solution seems nearly impossible though; we cannot acquire a mutex
> on
> the user
> to prevent them from yanking a device and we c
On Tue, Jan 19, 2021 at 6:31 PM Andrey Grodzovsky
wrote:
>
>
> On 1/19/21 9:16 AM, Daniel Vetter wrote:
> > On Mon, Jan 18, 2021 at 04:01:09PM -0500, Andrey Grodzovsky wrote:
> >> Until now extracting a card either by physical extraction (e.g. eGPU with
> >> thunderbolt connection or by emulation
On 1/19/21 1:08 PM, Daniel Vetter wrote:
On Tue, Jan 19, 2021 at 6:31 PM Andrey Grodzovsky
wrote:
On 1/19/21 9:16 AM, Daniel Vetter wrote:
On Mon, Jan 18, 2021 at 04:01:09PM -0500, Andrey Grodzovsky wrote:
Until now extracting a card either by physical extraction (e.g. eGPU with
thunderbol
On 1/19/21 1:05 PM, Daniel Vetter wrote:
On Tue, Jan 19, 2021 at 4:35 PM Andrey Grodzovsky
wrote:
There is really no other way according to this article
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flwn.net%2FArticles%2F767885%2F&data=04%7C01%7CAndrey.Grodzovsky%40amd.com%7
On Tue, Jan 19, 2021 at 11:36:01AM -0500, Andrey Grodzovsky wrote:
>
> On 1/19/21 2:34 AM, Greg KH wrote:
> > On Mon, Jan 18, 2021 at 04:01:19PM -0500, Andrey Grodzovsky wrote:
> > > static struct pci_driver amdgpu_kms_pci_driver = {
> > > .name = DRIVER_NAME,
> > > .id_table
Am 19.01.21 um 18:47 schrieb Luben Tuikov:
On 2021-01-19 2:53 a.m., Christian König wrote:
Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
From: Luben Tuikov
This patch does not change current behaviour.
The driver's job timeout handler now returns
status indicating back to the DRM layer whe
On Tue, Jan 19, 2021 at 5:08 PM Pillai, Aurabindo
wrote:
>
> [AMD Official Use Only - Internal Distribution Only]
>
>
> Hi Daniel,
>
> Could you please be more specific about the _unsafe API options you mentioned
> ?
module_param_named_unsafe()
Cheers, Daniel
>
> --
>
> Thanks & Regards,
> Aur
Am 19.01.21 um 19:22 schrieb Andrey Grodzovsky:
On 1/19/21 1:05 PM, Daniel Vetter wrote:
On Tue, Jan 19, 2021 at 4:35 PM Andrey Grodzovsky
wrote:
There is really no other way according to this article
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flwn.net%2FArticles%2F76788
On Tue, Jan 19, 2021 at 1:26 PM Greg KH wrote:
>
> On Tue, Jan 19, 2021 at 11:36:01AM -0500, Andrey Grodzovsky wrote:
> >
> > On 1/19/21 2:34 AM, Greg KH wrote:
> > > On Mon, Jan 18, 2021 at 04:01:19PM -0500, Andrey Grodzovsky wrote:
> > > > static struct pci_driver amdgpu_kms_pci_driver = {
> >
On 1/19/21 2:04 PM, Alex Deucher wrote:
On Tue, Jan 19, 2021 at 1:26 PM Greg KH wrote:
On Tue, Jan 19, 2021 at 11:36:01AM -0500, Andrey Grodzovsky wrote:
On 1/19/21 2:34 AM, Greg KH wrote:
On Mon, Jan 18, 2021 at 04:01:19PM -0500, Andrey Grodzovsky wrote:
static struct pci_driver amdgpu
1 - 100 of 155 matches
Mail list logo
