Hi
Am 24.02.21 um 16:21 schrieb Alan Stern:
On Wed, Feb 24, 2021 at 10:23:04AM +0100, Thomas Zimmermann wrote:
USB devices cannot perform DMA and hence have no dma_mask set in their
device structure. Therefore importing dmabuf into a USB-based driver
fails, which breaks joining and mirroring of
Hi
Am 25.02.21 um 02:55 schrieb Dave Airlie:
On Wed, 24 Feb 2021 at 20:27, Thomas Zimmermann wrote:
Hi Dave and Daniel,
here's this week's PR for drm-misc-fixes. One of the patches is a memory
leak; the rest is for hardware issues.
This is based on 5.11 and I'm not currently in the market
Am 24.02.21 um 16:13 schrieb Andrey Grodzovsky:
Ping
Sorry, I've been on vacation this week.
Andrey
On 2021-02-20 7:12 a.m., Andrey Grodzovsky wrote:
On 2/20/21 3:38 AM, Christian König wrote:
Am 18.02.21 um 17:41 schrieb Andrey Grodzovsky:
On 2/18/21 10:15 AM, Christian König wrote:
Hi Dmitry
Thanks for the patch.
On 2021-02-24 15:01, Dmitry Baryshkov wrote:
The number of fractional registers bits is known and already set in
the frac_bits variable of the dsi_pll_config struct here in 7nm:
remove the TODO by simply using that variable. This is a copy of
196145eb1af1 ("drm/m
Hi Dmitry
Thanks for the patch.
On 2021-02-24 15:05, Dmitry Baryshkov wrote:
The PLL_LOCKDET_RATE_1 was being programmed with a hardcoded value
directly, but the same value was also being specified in the
dsi_pll_regs struct pll_lockdet_rate variable: let's use it!
Based on 362cadf34b9f ("drm/
Hi,
On Wed, Feb 24, 2021 at 12:33:45PM +0100, Thomas Zimmermann wrote:
> Hi Maxime,
>
> for the whole series:
>
> Acked-by: Thomas Zimmermann
Applied the whole series, thanks to everyone involved in the review,
it's been a pretty daunting one :)
Maxime
signature.asc
Description: PGP signatu
On Thu, Feb 25, 2021 at 2:22 AM Diego Viola wrote:
>
> Hi Ben,
>
> I can confirm that your last two patches[0][1] fix the timeout issues
> (those from a normal boot and from suspend/resume).
>
> [0]
> https://github.com/skeggsb/linux/commit/90224a17437b1f39dbecbb385567c1fce958f992
> [1]
> https:
Hi Ben,
I can confirm that your last two patches[0][1] fix the timeout issues
(those from a normal boot and from suspend/resume).
[0]
https://github.com/skeggsb/linux/commit/90224a17437b1f39dbecbb385567c1fce958f992
[1]
https://github.com/skeggsb/linux/commit/0ee6dc49601359042fd254bbd8ba6b4685b4
Hi Dave, Daniel,
Fixes for 5.12.
The following changes since commit f730f39eb981af249d57336b47cfe3925632a7fd:
Merge tag 'drm-intel-next-fixes-2021-02-18' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2021-02-19 13:55:07
+1000)
are available in the Git repository at:
https
Hi Ben,
On Wed, Feb 24, 2021 at 6:50 AM Ben Skeggs wrote:
>
> On Wed, 17 Feb 2021 at 13:30, Alexandre Courbot wrote:
> >
> > On Wed, Feb 17, 2021 at 1:20 AM Diego Viola wrote:
> > >
> > > This code times out on GP108, probably because the BIOS puts it into a
> > > bad state.
> > >
> > > Since w
Hi Hsin-Yi, thanks for the comment, I'll change it in the next serial.
As video-interfaces.yaml not exist in drm-next, I'm waiting for 5.12-rc1 to
apply to drm-misc, then I'll upstream patch v5.
Thanks,
Xin
On Wed, Feb 24, 2021 at 05:55:39PM +0800, Hsin-Yi Wang wrote:
> On Thu, Jan 28, 2021 at 1
[AMD Public Use]
Thanks Lyude!
Regards,
Wayne
> -Original Message-
> From: Lyude Paul
> Sent: Thursday, February 25, 2021 2:09 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org
> Cc: ville.syrj...@linux.intel.com; sta...@vger.kernel.org; Kazlauskas,
> Nicholas ; Wentland, Harry
> ;
On Wed, 24 Feb 2021 at 20:27, Thomas Zimmermann wrote:
>
> Hi Dave and Daniel,
>
> here's this week's PR for drm-misc-fixes. One of the patches is a memory
> leak; the rest is for hardware issues.
>
This is based on 5.11 and I'm not currently in the market for a
backmege now before rc1 so can you
https://bugzilla.kernel.org/show_bug.cgi?id=209713
--- Comment #18 from Lahfa Samy (s...@lahfa.xyz) ---
Created attachment 295425
--> https://bugzilla.kernel.org/attachment.cgi?id=295425&action=edit
Trace after resume from S3 state on 5.11.1
--
You may reply to this email to add a comment.
Yo
https://bugzilla.kernel.org/show_bug.cgi?id=209713
--- Comment #17 from Lahfa Samy (s...@lahfa.xyz) ---
> Looks like this is fixed in 5.11.0 and 5.11.1.
I'm still getting this issue reliably under kernel 5.11.1 when resuming from
suspended state.(In reply to Oliver Reeh from comment #16)
So I con
The PLL_LOCKDET_RATE_1 was being programmed with a hardcoded value
directly, but the same value was also being specified in the
dsi_pll_regs struct pll_lockdet_rate variable: let's use it!
Based on 362cadf34b9f ("drm/msm/dsi_pll_10nm: Fix variable usage for
pll_lockdet_rate")
Signed-off-by: Dmitr
On Thu, Feb 18, 2021 at 11:49 PM Nathan Chancellor wrote:
>
> Clang warns:
>
> drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu_cmn.c:764:2: warning:
> variable 'structure_size' is used uninitialized whenever switch default
> is taken [-Wsometimes-uninitialized]
> default:
> ^~~
> dr
The number of fractional registers bits is known and already set in
the frac_bits variable of the dsi_pll_config struct here in 7nm:
remove the TODO by simply using that variable. This is a copy of
196145eb1af1 ("drm/msm/dsi_pll_10nm: Solve TODO for multiplier frac_bits
assignment").
Signed-off-by
Fix setting min/max DSI PLL rate for the V4.1 7nm DSI PLL (used on
sm8250). Current code checks for pll->type before it is set (as it is
set in the msm_dsi_pll_init() after calling device-specific functions.
Cc: Jonathan Marek
Fixes: 1ef7c99d145c ("drm/msm/dsi: add support for 7nm DSI PHY/PLL")
S
On 2/24/21 2:07 PM, Nick Desaulniers wrote:
> On Wed, Feb 24, 2021 at 1:55 PM Randy Dunlap wrote:
>>
>> The previously added stubs for aty_{ld,}st_lcd() make it
>> so that these functions are used regardless of the config
>> options that were guarding them, so remove the #ifdef/#endif
>> lines and
The previously added stubs for aty_{ld,}st_lcd() make it
so that these functions are used regardless of the config
options that were guarding them, so remove the #ifdef/#endif
lines and make their declarations always visible.
This fixes build warnings that were reported by clang:
drivers/video/
On Wed, Feb 24, 2021 at 11:59:45AM -0800, Randy Dunlap wrote:
> On 2/22/21 9:44 AM, Ville Syrjälä wrote:
> > On Sun, Feb 21, 2021 at 07:28:53PM -0800, Randy Dunlap wrote:
> >> Fix build errors when these functions are not defined.
> >>
> >> ../drivers/video/fbdev/aty/atyfb_base.c: In function 'aty_
On Sun, 2021-02-21 at 20:21 +0200, Laurent Pinchart wrote:
> Hi Lyude,
>
> Thank you for the patch.
>
> On Fri, Feb 19, 2021 at 04:53:11PM -0500, Lyude Paul wrote:
> > This is something that we've wanted for a while now: the ability to
> > actually look up the respective drm_device for a given dr
https://bugzilla.kernel.org/show_bug.cgi?id=209713
--- Comment #16 from Oliver Reeh (oli...@diereehs.de) ---
Looks like this is fixed in 5.11.0 and 5.11.1.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
___
Hi!
This is in -next, but I get same behaviour on 5.11; and no, udl does
not work, but monitor is detected:
pavel@amd:~/g/tui/crashled$ xrandr
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
LVDS1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 246mm x
185
On 2/22/21 9:44 AM, Ville Syrjälä wrote:
> On Sun, Feb 21, 2021 at 07:28:53PM -0800, Randy Dunlap wrote:
>> Fix build errors when these functions are not defined.
>>
>> ../drivers/video/fbdev/aty/atyfb_base.c: In function 'aty_power_mgmt':
>> ../drivers/video/fbdev/aty/atyfb_base.c:2002:7: error: i
On Wed, Feb 24, 2021 at 09:45:51AM +0100, Daniel Vetter wrote:
> Hm I figured everyone just uses MAP_SHARED for buffer objects since
> COW really makes absolutely no sense. How would we enforce this?
In RDMA we test
drivers/infiniband/core/ib_core_uverbs.c: if (!(vma->vm_flags &
VM_SHARED
On Fri, 2021-02-19 at 15:42 -0800, Randy Dunlap wrote:
> On 2/19/21 1:52 PM, Lyude Paul wrote:
> > Since we're about to be adding some more fields and update this
> > documentation, let's rewrap it to the new column limit of 100 beforehand.
> > No actual doc or functional changes are made here.
> >
also - I meant to reply to v2, not v1 :). Just so you don't worry that I pushed
the wrong patch series version
On Wed, 2021-02-24 at 18:15 +0800, Wayne Lin wrote:
> While testing MST hotplug events on daisy chain monitors, find out
> that CLEAR_PAYLOAD_ID_TABLE is not broadcasted and payload id ta
ooh, nice catches! For the whole series this is:
Reviewed-by: Lyude Paul
I will go ahead and push these to drm-misc-next
On Mon, 2021-02-22 at 12:00 +0800, Wayne Lin wrote:
> While testing MST hotplug events on daisy chain monitors, find out
> that CLEAR_PAYLOAD_ID_TABLE is not broadcasted and
On Wed, Feb 24, 2021 at 12:03 PM Alex Riesen
wrote:
>
> Ilia Mirkin, Wed, Feb 24, 2021 17:57:41 +0100:
> > On Wed, Feb 24, 2021 at 11:53 AM Alex Riesen
> > wrote:
> > > Ilia Mirkin, Wed, Feb 24, 2021 17:48:39 +0100:
> > > > Just to be crystal clear -- are you saying that 128x128 works or does
>
Den 19.02.2021 14.54, skrev Thomas Zimmermann:
> Hi
>
> Am 19.02.21 um 13:22 schrieb Noralf Trønnes:
>> dma-buf importing was reworked in commit 7d2cd72a9aa3
>> ("drm/shmem-helpers: Simplify dma-buf importing"). Before that commit
>> drm_gem_shmem_prime_import_sg_table() did set ->pages_use_coun
Ilia Mirkin, Wed, Feb 24, 2021 17:57:41 +0100:
> On Wed, Feb 24, 2021 at 11:53 AM Alex Riesen
> wrote:
> > Ilia Mirkin, Wed, Feb 24, 2021 17:48:39 +0100:
> > > Just to be crystal clear -- are you saying that 128x128 works or does
> > > not work? (You said "yes", which would imply it works OK, but
Hi Yannick,
Thanks for testing this change.
On Mon, Feb 15, 2021 at 1:39 PM yannick Fertre
wrote:
>
> Hello Jagan, I tested your patch on the stm32mp1 board.
> Unfortunately, the dsi panel does not probe well with this patch. The
> problem is due to the panel which is placed in the node of the d
On Wed, Feb 24, 2021 at 11:53 AM Alex Riesen
wrote:
>
> Ilia Mirkin, Wed, Feb 24, 2021 17:48:39 +0100:
> > On Wed, Feb 24, 2021 at 11:35 AM Alex Riesen
> > wrote:
> > > Ilia Mirkin, Wed, Feb 24, 2021 16:10:57 +0100:
> > > > The fact that you're getting lines with modetest means there's
> > > > s
Ilia Mirkin, Wed, Feb 24, 2021 17:48:39 +0100:
> On Wed, Feb 24, 2021 at 11:35 AM Alex Riesen
> wrote:
> > Ilia Mirkin, Wed, Feb 24, 2021 16:10:57 +0100:
> > > The fact that you're getting lines with modetest means there's
> > > something wrong with 256x256. What if you do 128x128 -- does that wo
On Wed, Feb 24, 2021 at 11:35 AM Alex Riesen
wrote:
> Ilia Mirkin, Wed, Feb 24, 2021 16:10:57 +0100:
> > The fact that you're getting lines with modetest means there's
> > something wrong with 256x256. What if you do 128x128 -- does that work
> > OK?
>
> Yes. Unfortunately in both cases.
Just to
On 23/02/2021 15:51, Neil Roberts wrote:
When mmapping the shmem, it would previously adjust the pgoff in the
vm_area_struct to remove the fake offset that is added to be able to
identify the buffer. This patch removes the adjustment and makes the
fault handler use the vm_fault address to calcula
On 23/02/2021 15:51, Neil Roberts wrote:
When a buffer is madvised as not needed and then purged, any attempts to
access the buffer from user-space should cause a bus fault. This patch
adds a check for that.
Cc: sta...@vger.kernel.org
Fixes: 17acb9f35ed7 ("drm/shmem: Add madvise state and purge
Ilia Mirkin, Wed, Feb 24, 2021 16:10:57 +0100:
> On Wed, Feb 24, 2021 at 4:09 AM Alex Riesen
> wrote:
> > Ilia Mirkin, Tue, Feb 23, 2021 19:13:59 +0100:
> > > It might also be worthwhile just testing if the 256x256 cursor works
> > > quite the way one would want. If you're interested, grab libdrm
On 2021-02-19 5:24 a.m., Daniel Vetter wrote:
On Thu, Feb 18, 2021 at 9:03 PM Andrey Grodzovsky
wrote:
Looked a bit into it, I want to export sync_object to FD and import from that
FD
such that I will wait on the imported sync object handle from one thread while
signaling the exported sync
We should advertise the reworked fifo/cmd handling and huge pages
support. Also while bumping the version number lets cleanup
the logging, there's no point in logging whether we're atomic
(we always are) or what repo we use (it's always in kernel now).
Signed-off-by: Zack Rusin
Reviewed-by: Marti
On Wed, Feb 24, 2021 at 04:06:05PM +, Daniel Stone wrote:
> Android punted on that from the beginning and just uses
> XBGR for everything ... so it's not really a matter of dumb vs. smart
> userspace, just equally dumb userspaces which disagree with each
> other. ;)
...apart from HAL_PIXEL_FOR
On Wed, Feb 24, 2021 at 8:55 AM Oleksandr Andrushchenko
wrote:
>
> Hello, Jan!
>
> On 2/23/21 6:41 PM, Jan Beulich wrote:
> > By having selected DRM_XEN, I was assuming I would build the frontend
> > driver. As it turns out this is a dummy option, and I have really not
> > been building this (beca
Hey,
On Wed, 24 Feb 2021 at 14:58, Daniel Vetter wrote:
> On Tue, Feb 23, 2021 at 7:50 PM Daniel Stone wrote:
> > The issue is a userspace one though, not a kernel one. Userspace (e.g.
> > GNOME Shell, Weston, Xorg) decides ahead of time that it's going to
> > use XRGB, then use the modifier
From: Sascha Hauer
This is the 3D GPU found on the i.MX8MP SoC.
Signed-off-by: Sascha Hauer
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_hwdb.c | 31 ++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c
b/drivers/g
On Wed, Feb 24, 2021 at 10:23:04AM +0100, Thomas Zimmermann wrote:
> USB devices cannot perform DMA and hence have no dma_mask set in their
> device structure. Therefore importing dmabuf into a USB-based driver
> fails, which breaks joining and mirroring of display in X11.
>
> For USB devices, pic
Ping
Andrey
On 2021-02-20 7:12 a.m., Andrey Grodzovsky wrote:
On 2/20/21 3:38 AM, Christian König wrote:
Am 18.02.21 um 17:41 schrieb Andrey Grodzovsky:
On 2/18/21 10:15 AM, Christian König wrote:
Am 18.02.21 um 16:05 schrieb Andrey Grodzovsky:
On 2/18/21 3:07 AM, Christian König wrote
[+emersion, -various people and lists who definitely don't care]
On Wed, Feb 24, 2021 at 4:09 AM Alex Riesen
wrote:
>
> Ilia Mirkin, Tue, Feb 23, 2021 19:13:59 +0100:
> > On Tue, Feb 23, 2021 at 11:23 AM Alex Riesen
> > wrote:
> > >
> > > $ xrandr --listproviders
> > > Providers: numbe
On Tue, Feb 23, 2021 at 7:50 PM Daniel Stone wrote:
>
> Hi Brian,
>
> On Tue, 23 Feb 2021 at 18:34, Brian Starkey wrote:
> > On Tue, Feb 23, 2021 at 05:10:16PM +, Alyssa Rosenzweig wrote:
> > > But it seems to me allowing
> > > both BGR+YTR and RGB+YTR upstream is the better route than simply
Hi Riadh,
On Wed, Feb 17, 2021 at 8:44 PM Riadh Ghaddab wrote:
>
> Hi Jagan,
>
> On 20/01/2021 12:21, Jagan Teki wrote:
>
> SN65DSI84 is a Single Channel DSI to Dual-link LVDS bridge from
> Texas Instruments.
>
> SN65DSI83, SN65DSI85 are variants of the same family of bridge
> controllers.
>
> Ri
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Alex Deucher
From: Wei Yongjun
Sent: Wednesday, February 24, 2021 4:49 AM
To: Hulk Robot ; Wentland, Harry ;
Li, Sun peng (Leo) ; Deucher, Alexander
; Koenig, Christian ;
David Airlie ; Daniel V
On Wed, Feb 24, 2021 at 12:22 PM Thomas Hellström (Intel)
wrote:
>
>
> On 2/24/21 10:26 AM, Daniel Vetter wrote:
> > On Wed, Feb 24, 2021 at 9:47 AM Thomas Hellström (Intel)
> > wrote:
> >>
> >> On 2/3/21 4:29 PM, Daniel Vetter wrote:
> >>> Recently there was a fairly long thread about recoreable
Hi Laurent,
On Wed, Feb 24, 2021 at 6:44 PM Laurent Pinchart
wrote:
>
> Hi Jagan,
>
> On Wed, Feb 24, 2021 at 06:07:43PM +0530, Jagan Teki wrote:
> > On Mon, Feb 15, 2021 at 5:48 PM Laurent Pinchart wrote:
> > > On Sun, Feb 14, 2021 at 11:22:10PM +0530, Jagan Teki wrote:
> > > > ICN6211 is MIPI-D
Hi,
Some feedback for patches 1-3? Laurent?
Cheers,
-Paul
Le dim. 24 janv. 2021 à 8:55, Paul Cercueil a
écrit :
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, th
Hi Jagan,
On Wed, Feb 24, 2021 at 06:07:43PM +0530, Jagan Teki wrote:
> On Mon, Feb 15, 2021 at 5:48 PM Laurent Pinchart wrote:
> > On Sun, Feb 14, 2021 at 11:22:10PM +0530, Jagan Teki wrote:
> > > ICN6211 is MIPI-DSI to RGB Convertor bridge from Chipone.
> > >
> > > It has a flexible configuratio
From: Nicholas Kazlauskas
[ Upstream commit 44a09e3d95bd2b7b0c224100f78f335859c4e193 ]
[Why]
If the BIOS table is invalid or corrupt then get_i2c_info can fail
and we dereference a NULL pointer.
[How]
Check that ddc_pin is not NULL before using it and log an error if it
is because this is unexp
From: Zqiang
[ Upstream commit 5c0e4110f751934e748a66887c61f8e73805f0f9 ]
The dlfb_alloc_urb_list function is called in dlfb_usb_probe function,
after that if an error occurs, the dlfb_free_urb_list function need to
be called.
BUG: memory leak
unreferenced object 0x88810adde100 (size 32):
From: Nicholas Kazlauskas
[ Upstream commit 44a09e3d95bd2b7b0c224100f78f335859c4e193 ]
[Why]
If the BIOS table is invalid or corrupt then get_i2c_info can fail
and we dereference a NULL pointer.
[How]
Check that ddc_pin is not NULL before using it and log an error if it
is because this is unexp
From: Defang Bo
[ Upstream commit e4180c4253f3f2da09047f5139959227f5cf1173 ]
Similar to commit ("drm/amdgpu: fix IH overflow on Vega10 v2").
When an ring buffer overflow happens the appropriate bit is set in the WPTR
register which is also written back to memory. But clearing the bit in the
WPTR
From: Zqiang
[ Upstream commit 5c0e4110f751934e748a66887c61f8e73805f0f9 ]
The dlfb_alloc_urb_list function is called in dlfb_usb_probe function,
after that if an error occurs, the dlfb_free_urb_list function need to
be called.
BUG: memory leak
unreferenced object 0x88810adde100 (size 32):
From: Tian Tao
[ Upstream commit c855af2f9c5c60760fd1bed7889a81bc37d2591d ]
Fix the problem of dev being released twice.
[ cut here ]
refcount_t: underflow; use-after-free.
WARNING: CPU: 75 PID: 15700 at lib/refcount.c:28
refcount_warn_saturate+0xd4/0x150
CPU: 75 PID: 15
From: Nirmoy Das
[ Upstream commit 8c0225d79273968a65e73a4204fba023ae02714d ]
For high priority compute to work properly we need to enable
wave limiting on gfx pipe. Wave limiting is done through writing
into mmSPI_WCL_PIPE_PERCENT_GFX register. Enable only one high
priority compute queue to avo
From: Jingwen Chen
[ Upstream commit 64dcf2f01d59cf9fad19b1a387bd39736a8f4d69 ]
[Why]
when vram lost happened in guest, try to write vram can lead to
kernel stuck.
[How]
When the readback data is invalid, don't do write work, directly
reschedule a new work.
Signed-off-by: Jingwen Chen
Reviewe
From: Nicholas Kazlauskas
[ Upstream commit 44a09e3d95bd2b7b0c224100f78f335859c4e193 ]
[Why]
If the BIOS table is invalid or corrupt then get_i2c_info can fail
and we dereference a NULL pointer.
[How]
Check that ddc_pin is not NULL before using it and log an error if it
is because this is unexp
From: Defang Bo
[ Upstream commit e4180c4253f3f2da09047f5139959227f5cf1173 ]
Similar to commit ("drm/amdgpu: fix IH overflow on Vega10 v2").
When an ring buffer overflow happens the appropriate bit is set in the WPTR
register which is also written back to memory. But clearing the bit in the
WPTR
From: Zqiang
[ Upstream commit 5c0e4110f751934e748a66887c61f8e73805f0f9 ]
The dlfb_alloc_urb_list function is called in dlfb_usb_probe function,
after that if an error occurs, the dlfb_free_urb_list function need to
be called.
BUG: memory leak
unreferenced object 0x88810adde100 (size 32):
From: Tian Tao
[ Upstream commit c855af2f9c5c60760fd1bed7889a81bc37d2591d ]
Fix the problem of dev being released twice.
[ cut here ]
refcount_t: underflow; use-after-free.
WARNING: CPU: 75 PID: 15700 at lib/refcount.c:28
refcount_warn_saturate+0xd4/0x150
CPU: 75 PID: 15
From: Nirmoy Das
[ Upstream commit 8c0225d79273968a65e73a4204fba023ae02714d ]
For high priority compute to work properly we need to enable
wave limiting on gfx pipe. Wave limiting is done through writing
into mmSPI_WCL_PIPE_PERCENT_GFX register. Enable only one high
priority compute queue to avo
From: Defang Bo
[ Upstream commit e4180c4253f3f2da09047f5139959227f5cf1173 ]
Similar to commit ("drm/amdgpu: fix IH overflow on Vega10 v2").
When an ring buffer overflow happens the appropriate bit is set in the WPTR
register which is also written back to memory. But clearing the bit in the
WPTR
From: Nicholas Kazlauskas
[ Upstream commit 44a09e3d95bd2b7b0c224100f78f335859c4e193 ]
[Why]
If the BIOS table is invalid or corrupt then get_i2c_info can fail
and we dereference a NULL pointer.
[How]
Check that ddc_pin is not NULL before using it and log an error if it
is because this is unexp
From: Zqiang
[ Upstream commit 5c0e4110f751934e748a66887c61f8e73805f0f9 ]
The dlfb_alloc_urb_list function is called in dlfb_usb_probe function,
after that if an error occurs, the dlfb_free_urb_list function need to
be called.
BUG: memory leak
unreferenced object 0x88810adde100 (size 32):
From: Jingwen Chen
[ Upstream commit 64dcf2f01d59cf9fad19b1a387bd39736a8f4d69 ]
[Why]
when vram lost happened in guest, try to write vram can lead to
kernel stuck.
[How]
When the readback data is invalid, don't do write work, directly
reschedule a new work.
Signed-off-by: Jingwen Chen
Reviewe
From: Tian Tao
[ Upstream commit c855af2f9c5c60760fd1bed7889a81bc37d2591d ]
Fix the problem of dev being released twice.
[ cut here ]
refcount_t: underflow; use-after-free.
WARNING: CPU: 75 PID: 15700 at lib/refcount.c:28
refcount_warn_saturate+0xd4/0x150
CPU: 75 PID: 15
On Tue, 23 Feb 2021 at 21:49, Heiko Stuebner wrote:
> On Tue, 11 Aug 2020 16:26:31 -0400, Alyssa Rosenzweig wrote:
> > The AFBC decoder used in the Rockchip VOP assumes the use of the
> > YUV-like colourspace transform (YTR). YTR is lossless for RGB(A)
> > buffers, which covers the RGBA8 and RGB56
Hi Laurent,
On Mon, Feb 15, 2021 at 5:48 PM Laurent Pinchart
wrote:
>
> Hi Jagan,
>
> Thank you for the patch.
>
> On Sun, Feb 14, 2021 at 11:22:10PM +0530, Jagan Teki wrote:
> > ICN6211 is MIPI-DSI to RGB Convertor bridge from Chipone.
> >
> > It has a flexible configuration of MIPI DSI signal i
Hi Geert,
IMHO - QEMU is irrelevant here. since I can do passthrough --
in fact -- many drivers do use timeout in .fb_sync
e.g. i810fb_sync(), nouveau_fbcon_sync(), sm501fb_sync() etc..
I believe the correct behaviour should be a timeout wait instead of
waiting indefinitely.
- Tong
On Wed, Feb 24,
Hello, Jan!
On 2/23/21 6:41 PM, Jan Beulich wrote:
> By having selected DRM_XEN, I was assuming I would build the frontend
> driver. As it turns out this is a dummy option, and I have really not
> been building this (because I had DRM disabled). Make it a promptless
> one, moving the "depends on"
Hi Tong,
On Sun, Feb 21, 2021 at 1:05 AM Tong Zhang wrote:
> On Sat, Feb 20, 2021 at 6:33 PM Randy Dunlap wrote:
> > On 2/20/21 3:02 PM, Tong Zhang wrote:
> > > pm2fb_sync is called when doing /dev/fb read or write.
> > > The original pm2fb_sync wait indefinitely on hardware flags which can
> >
Hi Maxime,
for the whole series:
Acked-by: Thomas Zimmermann
Am 19.02.21 um 13:00 schrieb Maxime Ripard:
The current atomic helpers have either their object state being passed as
an argument or the full atomic state.
The former is the pattern that was done at first, before switching to the
l
On Wed, Feb 24, 2021 at 09:20:48AM +0530, Kiran Gunda wrote:
> Currently the FSC SYNC_BIT and MOD_SYNC_BIT are toggled
> from 1 to 0 to update the FSC and brightenss settings.
> Change this sequence form 0 to 1 as per the hardware team
> recommendation to update the FSC and brightness correctly.
A
On 2/24/21 10:26 AM, Daniel Vetter wrote:
On Wed, Feb 24, 2021 at 9:47 AM Thomas Hellström (Intel)
wrote:
On 2/3/21 4:29 PM, Daniel Vetter wrote:
Recently there was a fairly long thread about recoreable hardware page
faults, how they can deadlock, and what to do about that.
While the discus
On Wed, Feb 24, 2021 at 09:20:47AM +0530, Kiran Gunda wrote:
> Currently, for WLED5, after FSC register update MOD_SYNC_BIT
> is toggled instead of SYNC_BIT. MOD_SYNC_BIT has to be toggled
> after the brightness update and SYNC_BIT has to be toggled after
> FSC update for WLED5. Fix it.
Code looks
Add a virtual hardware or vblank-less mode as a module to enable
VKMS to emulate virtual graphic drivers. This mode can be enabled
by setting enable_virtual_hw=1 at the time of loading VKMS.
A new function vkms_crtc_composer() has been added to bypass the
vblank mode and is called directly in the
On Wed, Feb 24, 2021 at 5:55 PM Hsin-Yi Wang wrote:
>
> On Thu, Jan 28, 2021 at 11:10 AM Xin Ji wrote:
> >
> > Add MIPI rx DPI input support
> >
> > Reported-by: kernel test robot
> > Signed-off-by: Xin Ji
> > ---
> > drivers/gpu/drm/bridge/analogix/anx7625.c | 326
> > +++
Hi Dave and Daniel,
here's this week's PR for drm-misc-fixes. One of the patches is a memory
leak; the rest is for hardware issues.
Best regards
Thomas
drm-misc-fixes-2021-02-24:
* drm/panel: kd35t133: Work with non-continuous DSI clock
* drm/rockchip: Require YTR modifier for AFBC
* drm/ttm:
[Why & How]
According to DP spec, CLEAR_PAYLOAD_ID_TABLE is a path broadcast request
message and current implementation is incorrect. Fix it.
Signed-off-by: Wayne Lin
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/drm_dp_mst_topology.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
di
[Why & How]
According to DP spec, broadcast message LCT equals to 1 and LCR equals
to 6. Current implementation is incorrect. Fix it.
In addition, revise a bit the hdr->rad handling to include broadcast
case.
Signed-off-by: Wayne Lin
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/drm_dp_mst_topo
While testing MST hotplug events on daisy chain monitors, find out
that CLEAR_PAYLOAD_ID_TABLE is not broadcasted and payload id table
is not reset. Dig in deeper and find out two parts needed to be fixed.
1. Link_Count_Total & Link_Count_Remaining of Broadcast message are
incorrect. Should set lc
On Thu, Jan 28, 2021 at 11:10 AM Xin Ji wrote:
>
> Add MIPI rx DPI input support
>
> Reported-by: kernel test robot
> Signed-off-by: Xin Ji
> ---
> drivers/gpu/drm/bridge/analogix/anx7625.c | 326
> --
> drivers/gpu/drm/bridge/analogix/anx7625.h | 20 +-
> 2 files
On Wed, 17 Feb 2021 at 13:30, Alexandre Courbot wrote:
>
> On Wed, Feb 17, 2021 at 1:20 AM Diego Viola wrote:
> >
> > This code times out on GP108, probably because the BIOS puts it into a
> > bad state.
> >
> > Since we reset the PMU on driver load anyway, we are at no risk from
> > missing a re
[AMD Public Use]
> -Original Message-
> From: Ville Syrjälä
> Sent: Tuesday, February 23, 2021 9:26 PM
> To: Lin, Wayne
> Cc: Brol, Eryk ; Zhuo, Qingqing ;
> sta...@vger.kernel.org; Zuo, Jerry
> ; dri-devel@lists.freedesktop.org; Kazlauskas, Nicholas
>
> Subject: Re: [PATCH 1/2] drm/d
Hey Adrien,
This looks good to me. All that is missing is DRM_BRIDGE_OP_HPD
support, when that's been implemented I think this series is ready to
be merged.
On Tue, 23 Feb 2021 at 18:56, Adrien Grassein wrote:
>
> Lontium Lt8912 is a DSI to HDMI bridge.
>
> Signed-off-by: Adrien Grassein
> ---
GCC reports the following warning with W=1:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:5439:33:
warning: unused variable 'dm' [-Wunused-variable]
5439 | struct amdgpu_display_manager *dm = &adev->dm;
| ^~
This variable only used when CONFI
On Wed, Feb 24, 2021 at 10:16 AM Thomas Hellström (Intel)
wrote:
>
>
> On 2/24/21 9:45 AM, Daniel Vetter wrote:
> > On Wed, Feb 24, 2021 at 8:46 AM Thomas Hellström (Intel)
> > wrote:
> >>
> >> On 2/23/21 11:59 AM, Daniel Vetter wrote:
> >>> tldr; DMA buffers aren't normal memory, expecting that
On Wed, Feb 24, 2021 at 9:47 AM Thomas Hellström (Intel)
wrote:
>
>
> On 2/3/21 4:29 PM, Daniel Vetter wrote:
> > Recently there was a fairly long thread about recoreable hardware page
> > faults, how they can deadlock, and what to do about that.
> >
> > While the discussion is still fresh I figur
USB devices cannot perform DMA and hence have no dma_mask set in their
device structure. Therefore importing dmabuf into a USB-based driver
fails, which breaks joining and mirroring of display in X11.
For USB devices, pick the associated USB controller as attachment device.
This allows the DRM imp
On 2/24/21 9:45 AM, Daniel Vetter wrote:
On Wed, Feb 24, 2021 at 8:46 AM Thomas Hellström (Intel)
wrote:
On 2/23/21 11:59 AM, Daniel Vetter wrote:
tldr; DMA buffers aren't normal memory, expecting that you can use
them like that (like calling get_user_pages works, or that they're
accounting
Hi
Am 20.02.21 um 15:37 schrieb Melissa Wen:
Adding support to overlay type in addition to primary and cursor plane.
The planes composition relies on the z order of the active planes and
only occurs if there is a primary plane (as in the current behavior).
The first patch decouples cursor from
Ilia Mirkin, Tue, Feb 23, 2021 19:13:59 +0100:
> On Tue, Feb 23, 2021 at 11:23 AM Alex Riesen
> wrote:
> >
> > $ xrandr --listproviders
> > Providers: number : 1
> > Provider 0: id: 0x68 cap: 0x7, Source Output, Sink Output, Source
> > Offload crtcs: 4 outputs: 5 associated provider
1 - 100 of 103 matches
Mail list logo
