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 like any other normal memory)
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 figured good time to try and
document the conclusions a bit. This documentation section
Am 24.02.21 um 04:28 schrieb xinhui pan:
BO would be added into swap list if it is validated into system domain.
If BO is validated again into non-system domain, say, VRAM domain. It
actually should not be in the swap list.
Signed-off-by: xinhui pan
Reviewed-by: Christian König
Going to pus
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
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
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
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 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
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
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
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
> ---
[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
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
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
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
[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
[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
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:
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
> > +++
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 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
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: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
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
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
> >
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 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,
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
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
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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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
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
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 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
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
[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
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
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
[+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
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
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
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
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
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
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
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 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
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 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
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 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
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: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
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
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
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
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
>
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
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
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.
> >
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 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
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
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.
___
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
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_
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 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
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
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
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 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
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
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
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
[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
> ;
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
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 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,
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
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,
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
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 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
1 - 100 of 103 matches
Mail list logo
