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 successfully aborted or whether
more time should be given to the
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 = {
> .shutdown = amdgpu_pci_shutdown,
>
On Tue, Jan 19, 2021 at 12:41 AM 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
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next
head: d5a0d4b9380a499cc140c7ee04ec80e15a8d49e5
commit: 2a743b7b8a8be8c8fc7c130c304c1243f6bbe9b7 [8/19] drm/i915/hdcp:
Configure HDCP1.4 MST steram encryption status
config: x86_64-randconfig-m001-20210115 (attached as .config)
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 this is a valid fix, but the change below makes reboot
> works correctly.
-Original Message-
From: Thomas Zimmermann [mailto:tzimmerm...@suse.de]
Sent: Monday, January 18, 2021 5:06 PM
To: Kuo-Hsiang Chou ;
dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org
Subject: Re: [PATCH v2] drm/ast: Disable fast reset after DRAM initial
Hi, Thomas,
Hi
Am
While we do handle the additional cursor sizes introduced in NVE4, it looks
like we accidentally broke this when converting over to use Nvidia's
display headers. Since we now use NVVAL in dispnv50/head907d.c in order to
format the value for the cursor layout and NVD9 only had one byte reserved
vs.
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/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index c6367035970e..5f4f09a601d4
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 base/ovly/nvdisp")
Cc: James Jones
Cc: Martin Peres
Cc: Jeremy Cline
Noticed this while trying to figure out the bit that we need to set in
order to get cursor CRCs to come up correctly on volta+: we never actually
went and added these methods to gv100_disp_core_mthd_head in
drm/nouveau/nvkm/engine/disp/coregv100.c which means we don't trace their
values when disp
While working on igt support for nouveau, I noticed that CRC calculation
appeared to be broken when the cursor channel was being used. For example,
if I had an igt test that would compare a software rendered image of a
completely black fb with a green square in it, and then attempt to
reproduce
Originally it was assumed based on Nvidia's open-gpu-docs and testing that
NVDisplay required that at least one wndw which belongs to a given head to be
used as the controlling channel
(NVC37D_HEAD_SET_CRC_CONTROL_CONTROLLING_CHANNEL) in order for CRC capture to
function. While this is the case on
While I haven't seen us take too long in nv50_crc_ctx_flip_work() outside of
users with kernel logging on a serial port, it probably would be a good idea to
check how long we take just in case we need to go faster in the future.
Cc: Martin Peres
Cc: Jeremy Cline
Cc: Simon Ser
Signed-off-by:
Cc: Martin Peres
Cc: Jeremy Cline
Cc: Simon Ser
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/crc.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/crc.c
b/drivers/gpu/drm/nouveau/dispnv50/crc.c
index
https://bugzilla.kernel.org/show_bug.cgi?id=211263
Paulo Marcos de Souza Arruda do Nascimento (contato-mygh...@protonmail.com)
changed:
What|Removed |Added
Status|NEW
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 this is a valid fix, but the change below makes reboot
works correctly.
kmscube still works.
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++
On Mon, Jan 18, 2021 at 4:02 PM Andrey Grodzovsky
wrote:
>
> Handle all DMA IOMMU gropup related dependencies before the
gropup -> group
Alex
> group is removed.
>
> Signed-off-by: Andrey Grodzovsky
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu.h| 5
>
On Mon, Jan 18, 2021 at 4:02 PM Andrey Grodzovsky
wrote:
>
> To avoid any possible use after free.
>
> Signed-off-by: Andrey Grodzovsky
> Reviewed-by: Christian König
In the subject:
oustatdning -> outstanding
Alex
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 3 +++
> 1 file changed, 3
On Mon, Jan 18, 2021 at 4:02 PM 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 entire
Adding some more folks in case anyone has any suggestions to fix this
reboot hang.
Thanks
On Tue, Jan 12, 2021 at 5:07 PM Fabio Estevam wrote:
>
> Hi,
>
> I have noticed that on an imx53-qsb, it is no longer possible to
> reboot the system as it fails like this:
>
> Requesting system reboot
> [
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 properly. In preparation for having the io-pgtable
> > formats as
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 properly. In preparation for having the io-pgtable
> formats as modules, add a "pre" dependency with MODULE_SOFTDEP() to
> ensure that the
This should prevent writing to memory or IO ranges possibly
already allocated for other uses after our device is removed.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 57
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c| 9
Return DRM_TASK_STATUS_ENODEV back to the scheduler when device
is not present so they timeout timer will not be rearmed.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git
We don't want to rearm the timer if driver hook reports
that the device is gone.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/scheduler/sched_main.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
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 successfully aborted or whether
more time should be given to the task to complete.
Default behaviour as of this
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
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 21 -
1 file changed, 16 insertions(+), 5
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
---
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 17 +
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
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index
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 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c |
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
drm_driver.release hook is called, i.e. when the
Use it to call disply code dependent on device->drv_data
before it's set to NULL on device unplug
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 20
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 12 ++--
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 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index
It's needed to drop iommu backed pages on device unplug
before device's IOMMU group is released.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/ttm/ttm_tt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index
Invalidate all BOs CPU mappings once device is removed.
v3: Move the code from TTM into drm_dev_unplug
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
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 allocated dummy page
on the first fault for that
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 crashes in apps were
mostly due to the app having mapped a device backed
> On Jan 18, 2021, at 08:14, Thomas Zimmermann wrote:
>
> Using struct drm_device.pdev is deprecated in favor of drm_device.dev.
> The reference to the field was reintroduced during a rebase.
>
> Signed-off-by: Thomas Zimmermann
> Fixes: 9703bb329206 ("drm/vmwgfx: Switch to a managed drm
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
Hi guys,
because of the Vulkan graphics API we have a specialized synchronization object
to handle both inter process as well as process to hardware synchronization.
The problem is now that when drivers call this interface with some lock help it
is trivial to create a deadlock when those locks
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:
> > > >
> > > > This set is part of a larger effort attempting to
On Mon, 18 Jan 2021, Linus Walleij wrote:
> This converts the lms283gf05 backlight driver to use GPIO
> descriptors and switches the single PXA Palm Z2 device
> over to defining these.
>
> Since the platform data was only used to convey GPIO
> information we can delete the platform data header.
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:
> > >
> > > This set is part of a larger effort attempting to clean-up W=1
> > > kernel builds, which are currently overwhelmingly
Hi
Am 18.01.21 um 15:56 schrieb Daniel Vetter:
On Mon, Jan 18, 2021 at 3:40 PM Thomas Zimmermann wrote:
Hi
Am 18.01.21 um 14:50 schrieb Christian König:
Hi Thomas,
this patch unfortunately completely broke amdgpu.
See the splat below:
[ 74.553881]
On Mon, Jan 18, 2021 at 3:40 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 18.01.21 um 14:50 schrieb Christian König:
> > Hi Thomas,
> >
> > this patch unfortunately completely broke amdgpu.
> >
> > See the splat below:
> >
> > [ 74.553881]
> >
On Fri, Jan 15, 2021 at 06:27:15PM +, Zack Rusin wrote:
>
> > On Jan 15, 2021, at 13:15, Lee Jones wrote:
> >
> > This set is part of a larger effort attempting to clean-up W=1
> > kernel builds, which are currently overwhelmingly riddled with
> > niggly little warnings.
> >
> > Last set!
Hi
Am 18.01.21 um 14:38 schrieb Chris Wilson:
Quoting Thomas Zimmermann (2021-01-18 13:14:17)
Using struct drm_device.pdev is deprecated. Convert i915 to struct
drm_device.dev. No functional changes.
This needs to be before or in the previous patch, as that patch removed
assignment of
Hi
Am 18.01.21 um 14:23 schrieb Christian König:
Am 18.01.21 um 14:22 schrieb Eli Cohen:
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
For performance, BO page mappings can stay in place even if the
map counter has returned to 0. In these cases, the existing page
mapping has to be reused by the next vmap operation. Otherwise
a new mapping would be installed and the old mapping's pages leak.
Fix the issue by reusing existing page
On Fri, Jan 15, 2021 at 06:22:23PM +, Zack Rusin wrote:
>
> > On Jan 15, 2021, at 13:12, Lee Jones wrote:
> >
> > This set is part of a larger effort attempting to clean-up W=1
> > kernel builds, which are currently overwhelmingly riddled with
> > niggly little warnings.
> >
> >
Hi
Am 18.01.21 um 14:50 schrieb Christian König:
Hi Thomas,
this patch unfortunately completely broke amdgpu.
See the splat below:
[ 74.553881]
==
[ 74.554060] BUG: KASAN: null-ptr-deref in
drm_pci_set_busid+0x38/0x100
https://bugzilla.kernel.org/show_bug.cgi?id=211263
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
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
> there isn't enough space?) what Christian König explained in
>
>
>
https://bugzilla.kernel.org/show_bug.cgi?id=211263
Bug ID: 211263
Summary: amdgpu: navi (RX 5500 XT) high power consumption while
idling on 75Hz display
Product: Drivers
Version: 2.5
Kernel Version: 5.10.7
Hardware:
From: Carsten Haitzler
Another issue found by KASAN. The bit finding is bueried inside the
dp_for_each_set_bit() macro (that passes on to for_each_set_bit() that
calls the bit stuff. These bit functions want an unsigned long pointer
as input and just dumbly casting leads to out-of-bounds
Hi Thomas,
this patch unfortunately completely broke amdgpu.
See the splat below:
[ 74.553881]
==
[ 74.554060] BUG: KASAN: null-ptr-deref in
drm_pci_set_busid+0x38/0x100 [drm]
[ 74.554393] Read of size 4 at addr
Quoting Thomas Zimmermann (2021-01-18 13:14:17)
> Using struct drm_device.pdev is deprecated. Convert i915 to struct
> drm_device.dev. No functional changes.
This needs to be before or in the previous patch, as that patch removed
assignment of i915->drm.pdev.
Or the removal of the assignment
On Mon, Jan 18, 2021 at 02:14:15PM +0100, Thomas Zimmermann wrote:
> We have DRM drivers based on USB, SPI and platform devices. All of them
> are fine with storing their device reference in struct drm_device.dev.
> PCI devices should be no exception. Therefore struct drm_device.pdev is
>
On Fri, Jan 15, 2021 at 07:52:53PM +0100, Christian König wrote:
> Am 15.01.21 um 17:47 schrieb Daniel Vetter:
> > We have too many people abusing the struct page they can get at but
> > really shouldn't in importers. Aside from that the backing page might
> > simply not exist (for dynamic p2p
This converts the lms283gf05 backlight driver to use GPIO
descriptors and switches the single PXA Palm Z2 device
over to defining these.
Since the platform data was only used to convey GPIO
information we can delete the platform data header.
Notice that we define the proper active low semantics
Am 18.01.21 um 14:22 schrieb Eli Cohen:
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
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 was able to reproduce the memory leak locally and found that the patch
fixes it. Please give it a try.
On Thu, Jan 14, 2021 at 04:31:09PM +0100, Roland Scheidegger wrote:
> Hi,
>
> looking at it, seems alright. Not sure why the lock was supposedly
> needed, maybe it was at some point (it seems like all usage of this lock
> was introduced way back in 2015, commit 153b3d5b037ee).
>
> For the
Struct drm_device.pdev is being moved to legacy status as only legacy
DRM drivers use it. A possible follow-up patchset could remove pdev
entirely.
v4:
* rebased
Signed-off-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
---
include/drm/drm_device.h | 6 +++---
1 file changed, 3
Using struct drm_device.pdev is deprecated. Convert i915 to struct
drm_device.dev. No functional changes.
Signed-off-by: Thomas Zimmermann
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/gvt/cfg_space.c | 5 +++--
drivers/gpu/drm/i915/gvt/firmware.c | 10
Using struct drm_device.pdev is deprecated in favor of drm_device.dev.
The reference to the field was reintroduced during a rebase.
Signed-off-by: Thomas Zimmermann
Fixes: 9703bb329206 ("drm/vmwgfx: Switch to a managed drm device")
Cc: Zack Rusin
Cc: Martin Krastev
Cc: Roland Scheidegger
Cc:
Using struct drm_device.pdev is deprecated. Convert i915 to struct
drm_device.dev. No functional changes.
v3:
* rebased
v2:
* move gt/ and gvt/ changes into separate patches
Signed-off-by: Thomas Zimmermann
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
---
Using struct drm_device.pdev is deprecated. Convert i915 to struct
drm_device.dev. No functional changes.
Signed-off-by: Thomas Zimmermann
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/gt/intel_ggtt.c |
We have DRM drivers based on USB, SPI and platform devices. All of them
are fine with storing their device reference in struct drm_device.dev.
PCI devices should be no exception. Therefore struct drm_device.pdev is
deprecated.
Instead upcast from struct drm_device.dev with to_pci_dev().
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 required
to fix a reported bug. [1] There's also a fix to vmwgfx.
The pdev field in struct
On Mon, Jan 18, 2021 at 11:37:49AM +, Paul Cercueil wrote:
> 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
On Sat, 9 Jan 2021 14:09:51 +0100, Heiko Stuebner wrote:
> The Innolux n116bge panel has an eDP connector and 3*6 bits bus format.
Applied, thanks!
[1/1] drm/panel: panel-simple: add bus-format and connector-type to Innolux
n116bge
commit: 87969bcd49480508568070fd93d7367f03316aa9
Best
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:57AM +0100, Maxime Ripard wrote:
I'd like to get Mark's opinion before merging though
On Mon, Jan 18, 2021 at 01:03:55AM +, Yue Zou wrote:
> Remove superfluous semicolons after function definitions.
>
> Signed-off-by: Yue Zou
Thanks for your patch, applied.
-Daniel
> ---
> include/linux/vgaarb.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git
On Fri, Jan 15, 2021 at 06:27:15PM +, Zack Rusin wrote:
>
> > On Jan 15, 2021, at 13:15, Lee Jones wrote:
> >
> > This set is part of a larger effort attempting to clean-up W=1
> > kernel builds, which are currently overwhelmingly riddled with
> > niggly little warnings.
> >
> > Last set!
On Mon, Jan 18, 2021 at 10:40:52AM +0200, Pekka Paalanen wrote:
> On Fri, 15 Jan 2021 12:06:25 +0100
> Simon Ser wrote:
>
> > The docs for enum drm_plane_type mention legacy IOCTLs, however the
> > plane type is not tied to legacy IOCTLs, the drm_cursor.primary and
> > cursor fields are. Add a
Hi Paul,
Thank you for the patch.
On Sun, Jan 17, 2021 at 11:26:44AM +, Paul Cercueil wrote:
> If we don't call drm_connector_cleanup() manually in
> panel_bridge_detach(), the connector will be cleaned up with the other
> DRM objects in the call to drm_mode_config_cleanup(). However, since
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 use-after-free
> conditions, we then must ensure that
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 already tried using kmemleak?
This sounds like a leak of memory allocated using kmalloc(), so kmemleak
should be
On Sun, Jan 17, 2021 at 03:29:05AM -0800, syzbot wrote:
> syzbot has bisected this issue to:
>
> commit ea40d7857d5250e5400f38c69ef9e17321e9c4a2
> Author: Daniel Vetter
> Date: Fri Oct 9 23:21:56 2020 +
>
> drm/vkms: fbdev emulation support
Not sure you want to annotate this, but
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?
Best regards
Thomas
18.01.2021 08:25, Thomas Zimmermann пишет:
(cc'ing dri-devel)
Hi
thanks for
Hi
Am 12.01.21 um 08:58 schrieb KuoHsiang Chou:
[Bug][AST2500]
V1:
When AST2500 acts as stand-alone VGA so that DRAM and DVO initialization
have to be achieved by VGA driver with P2A (PCI to AHB) enabling.
However, HW suggests disable Fast reset mode after DRAM initializaton,
because fast
[Bug][AST2500]
If SCU00 is not unlocked, just enter its password again.
It is unnecessary to clear AHB lock condition and restore WDT default
setting again, before Fast-reset clearing.
Signed-off-by: KuoHsiang Chou
---
drivers/gpu/drm/ast/ast_post.c | 5 +
1 file changed, 1 insertion(+), 4
On Fri, 15 Jan 2021 12:06:26 +0100
Simon Ser wrote:
> Add a new entry for "type" in the section for standard plane properties.
>
> v3: improve paragraph about mixing legacy IOCTLs with explicit usage,
> note that a driver may support cursors without cursor planes (Daniel)
>
> v4: fixing rebase
On Fri, 15 Jan 2021 12:06:25 +0100
Simon Ser wrote:
> The docs for enum drm_plane_type mention legacy IOCTLs, however the
> plane type is not tied to legacy IOCTLs, the drm_cursor.primary and
> cursor fields are. Add a small paragraph to reference these.
>
> Instead, document expectations for
(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_device.pdev to legacy
https://patchwork.kernel.org/project/intel-gfx/cover/20210107080748.4768-1-tzimmerm...@suse.de/
I
syzbot has found a reproducer for the following issue on:
HEAD commit:b3a3cbde Add linux-next specific files for 20210115
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=164096d750
kernel config:
The drm_display_mode_to_videomode() does not populate DISPLAY_FLAGS_DE_LOW
or DISPLAY_FLAGS_PIXDATA_NEGEDGE flags in struct videomode. Therefore, no
matter what polarity the next bridge or display might require, these flags
are never set, and thus the LTDC GCR_DEPOL and GCR_PCPOL bits are never
On 10/01/21, Fabio Estevam wrote:
> On Sun, Jan 10, 2021 at 5:09 PM Oliver Graute wrote:
>
> > here the schematics and my dts. The board is using a LVDS connector for
> > the display.
>
> The schematics shows the GKTW70SDAD1SD panel in the J4 connector, not
> the LVDS J7 connector.
yes you are
- Call wake_up() when EDID ready event is received to wake
wait_event_interruptible_timeout()
- Increase waiting timeout, reading EDID can take longer than 100ms, so
let's be on a safe side.
Signed-off-by: Dmitry Baryshkov
Fixes: 0cbbd5b1a012 ("drm: bridge: add support for lontium LT9611UXC
Remove superfluous semicolons after function definitions.
Signed-off-by: Yue Zou
---
include/linux/vgaarb.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/vgaarb.h b/include/linux/vgaarb.h
index 977caf96c8d2..fc6dfeba04a5 100644
---
Since the encoders have been devm-allocated, they will be freed way
before drm_mode_config_cleanup() is called. To avoid use-after-free
conditions, we then must ensure that drm_encoder_cleanup() is called
before the encoders are freed.
Fixes: c369cb27c267 ("drm/ingenic: Support multiple
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 using kmalloc(), so kmemleak
> should be able to catch it.
>
Hi Christian,
I have the following configured but I did not see
Even though the JZ4740 did not have the OSD mode, it had (according to
the documentation) two DMA channels, but there is absolutely no
information about how to select the second DMA channel.
Make the ingenic-drm driver work in non-OSD mode by using the
foreground0 plane (which is bound to the
syzbot has bisected this issue to:
commit ea40d7857d5250e5400f38c69ef9e17321e9c4a2
Author: Daniel Vetter
Date: Fri Oct 9 23:21:56 2020 +
drm/vkms: fbdev emulation support
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=148e2748d0
start commit: b3a3cbde Add
- state->output_bus_cfg.format, memcpy and
unsigned int used
- atomic_check removed
- video data input and output formats added
- bus formats read from drm_bridge_state.output_bus_cfg.format
and .atomic_get_input_bus_fmts() instead of connector
Reviewed-by: Laurent Pinchart
Signed-off-by:
Return NULL pointer from get_edid() callback rather than ERR_PTR()
pointer, as DRM code does NULL checks rather than IS_ERR(). Also while
we are at it, return NULL if getting EDID timed out.
Signed-off-by: Dmitry Baryshkov
Fixes: 0cbbd5b1a012 ("drm: bridge: add support for lontium LT9611UXC
If we don't call drm_connector_cleanup() manually in
panel_bridge_detach(), the connector will be cleaned up with the other
DRM objects in the call to drm_mode_config_cleanup(). However, since our
drm_connector is devm-allocated, by the time drm_mode_config_cleanup()
will be called, our connector
On Fri, Jan 15, 2021 at 10:03:50AM +0100, Thomas Zimmermann wrote:
>
> Could you please double-check that 3fb91f56aea4 ("drm/udl: Retrieve USB
> device from struct drm_device.dev") works correctly
Checked again, it does not seem to leak.
> and that 823efa922102
> ("drm/cma-helper: Remove empty
Hi,
Here are three independent fixes. The first one addresses a
use-after-free in bridge/panel.c; the second one addresses a
use-after-free in the ingenic-drm driver; finally, the third one makes
the ingenic-drm driver work again on older Ingenic SoCs.
Cheers,
-Paul
Paul Cercueil (3):
drm:
1 - 100 of 102 matches
Mail list logo
