Quoting Niranjana Vishwanathapura (2019-11-22 22:57:21)
> Shared Virtual Memory (SVM) allows the programmer to use a single virtual
> address space which will be shared between threads executing on CPUs and GPUs.
> It abstracts away from the user the location of the backing memory, and hence
> simp
https://bugs.freedesktop.org/show_bug.cgi?id=110674
Alex Deucher changed:
What|Removed |Added
Attachment #146026|text/x-log |text/plain
mime type|
https://bugzilla.kernel.org/show_bug.cgi?id=205661
Bug ID: 205661
Summary: Upgrade to 5.4 from K5.3.13 fails x2 attempts
Product: Drivers
Version: 2.5
Kernel Version: Kernel 5.4
Hardware: All
OS: Linux
Tree: M
Commit 7f0de8d80816 ("dma-buf: Drop dma_buf_k(un)map") removed map/unmap
handlers, but they still existed in udmabuf. Remove them there as well
Signed-off-by: Maarten Lankhorst
Fixes: 7f0de8d80816 ("dma-buf: Drop dma_buf_k(un)map")
Cc: Sumit Semwal
Cc: Daniel Vetter
Cc: linux-me...@vger.kernel.
On Tue, Nov 26, 2019 at 01:15:59PM +, Mihail Atanassov wrote:
> A simple convenience function to initialize the struct drm_bridge.
>
> Signed-off-by: Mihail Atanassov
The commit message here leaves figuring out why we need this to the
reader. Reading ahead the reasons seems to be to roll out
On Tue, Nov 26, 2019 at 01:16:26PM +, Mihail Atanassov wrote:
> From: Russell King
>
> Bridge devices have been a potential for kernel oops as their lifetime
> is independent of the DRM device that they are bound to. Hence, if a
> bridge device is unbound while the parent DRM device is using
On Tue, Nov 26, 2019 at 03:25:16PM +0100, Maarten Lankhorst wrote:
> Commit 7f0de8d80816 ("dma-buf: Drop dma_buf_k(un)map") removed map/unmap
> handlers, but they still existed in udmabuf. Remove them there as well
>
> Signed-off-by: Maarten Lankhorst
> Fixes: 7f0de8d80816 ("dma-buf: Drop dma_buf
On Fri, Nov 22, 2019 at 07:56:20PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Check for zero width/height destination rectangle in
> drm_rect_clip_scaled() to avoid a division by zero.
>
> Cc: sta...@vger.kernel.org
> Fixes: f96bdf564f3e ("drm/rect: Handle rounding errors in
> drm_re
Shift and mask were reversed. Noticed by chance.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r100.c | 4 ++--
drivers/gpu/drm/radeon/r200.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 708
Op 26-11-2019 om 15:36 schreef Daniel Vetter:
> On Tue, Nov 26, 2019 at 03:25:16PM +0100, Maarten Lankhorst wrote:
>> Commit 7f0de8d80816 ("dma-buf: Drop dma_buf_k(un)map") removed map/unmap
>> handlers, but they still existed in udmabuf. Remove them there as well
>>
>> Signed-off-by: Maarten Lankh
On Tue, Nov 26, 2019 at 3:39 AM Meelis Roos wrote:
>
> I tried latest (5.4) custom kernel (with UBSAN) on my Dell D600 laptop and
> found that it exhibits a
> UBSAN warning triggered by userspace ioctl. Here is dmesg with anything
> radeon-related + the warning, and config:
>
> [ 17.659534] [d
On Fri, Nov 22, 2019 at 07:56:21PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Limit the scaled clip to only clip at most dst_w/h pixels.
> This avoids the problem with clip_scaled() not being able
> to return negative values. Since new_src_w/h is now properly
> bounded we can remove th
This was forgotten in f96bdf564f3e ("drm/rect: Handle rounding errors
in drm_rect_clip_scaled, v3.")
Spotted while reviewing patches from Ville touching this area.
Fixes: f96bdf564f3e ("drm/rect: Handle rounding errors in drm_rect_clip_scaled,
v3.")
Cc: Maarten Lankhorst
Cc: Benjamin Gaignard
> -Original Message-
> From: amd-gfx On Behalf Of
> Christian König
> Sent: 2019/November/26, Tuesday 5:10 AM
> To: Jules Irenge ; Deucher, Alexander
>
> Cc: Zhou, David(ChunMing) ; airl...@linux.ie;
> linux-ker...@vger.kernel.org; amd-...@lists.freedesktop.org; dri-
> de...@lists.freed
On Fri, Nov 22, 2019 at 07:56:22PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Now that we've constrained the clipped source rectangle such
> that it can't have negative dimensions doing the same for the
> dst rectangle seems appropriate. Should at least result in
> the clipped src and
On Tue, Nov 26, 2019 at 03:52:13PM +0100, Daniel Vetter wrote:
> This was forgotten in f96bdf564f3e ("drm/rect: Handle rounding errors
> in drm_rect_clip_scaled, v3.")
>
> Spotted while reviewing patches from Ville touching this area.
>
> Fixes: f96bdf564f3e ("drm/rect: Handle rounding errors in
On Tue, Nov 26, 2019 at 07:03:58AM -0800, Devarsh Thakkar wrote:
> Add inline function to derive floating value of vertical
> refresh rate from pixel clock, horizontal total size and
> vertical total size.
>
> Use this function to find suitable mode having vrefresh
> value which is matching with u
On Fri, Nov 22, 2019 at 07:56:23PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add selftests for drm_rect. A few basic ones for clipped and unclipped
> cases, and a few special ones for specific bugs we had in the code.
>
> I'm too lazy to think of more corner cases to check at this ti
What happened with the patches I posted doing exactly this?
On Tue, Nov 26, 2019 at 01:15:58PM +, Mihail Atanassov wrote:
> Hi all,
>
> This series adds device links support to drm_bridge. The motivation
> behind it is that a drm_bridge in a module could get removed under the
> feet of the br
> -Original Message-
> From: amd-gfx On Behalf Of
> Christian König
> Sent: 2019/November/26, Tuesday 5:10 AM
> To: Jules Irenge ; Deucher, Alexander
>
> Cc: Zhou, David(ChunMing) ; airl...@linux.ie;
> linux-ker...@vger.kernel.org; amd-...@lists.freedesktop.org; dri-
> de...@lists.freed
Ping
Andrey
On 11/25/19 3:51 PM, Andrey Grodzovsky wrote:
Problem:
Due to a race between drm_sched_cleanup_jobs in sched thread and
drm_sched_job_timedout in timeout work there is a possiblity that
bad job was already freed while still being accessed from the
timeout thread.
Fix:
Instead of ju
I recently updated amd-staging-drm-next. Apply whatever makes sense for now
and it'll naturally fall out in the next rebase.
Alex
From: Grodzovsky, Andrey
Sent: Monday, November 25, 2019 7:09 PM
To: Deng, Emily
Cc: dri-devel@lists.freedesktop.org ;
amd-...@lis
On 11/26/19 4:08 AM, Christian König wrote:
Am 25.11.19 um 17:51 schrieb Steven Price:
On 25/11/2019 14:10, Andrey Grodzovsky wrote:
When the sched thread is parked we assume ring_mirror_list is
not accessed from here.
FWIW I don't think this is necessary. kthread_park() will wait until the
t
On Tuesday, 26 November 2019 14:35:34 GMT Daniel Vetter wrote:
> On Tue, Nov 26, 2019 at 01:16:26PM +, Mihail Atanassov wrote:
> > From: Russell King
> >
> > Bridge devices have been a potential for kernel oops as their lifetime
> > is independent of the DRM device that they are bound to. He
On Tuesday, 26 November 2019 15:27:16 GMT Russell King - ARM Linux admin wrote:
> What happened with the patches I posted doing exactly this?
Hi Russell,
>
> [snip]
> >
> > Russell King (1):
> > drm/bridge: add support for device links to bridge
^^^
Do you mean this one? It's 29/30 in the se
Hi Daniel,
Thanks for the quick review.
On Tuesday, 26 November 2019 14:26:10 GMT Daniel Vetter wrote:
> On Tue, Nov 26, 2019 at 01:15:59PM +, Mihail Atanassov wrote:
> > A simple convenience function to initialize the struct drm_bridge.
> >
> > Signed-off-by: Mihail Atanassov
>
> The comm
On Tue, Nov 26, 2019 at 7:10 AM Dan Carpenter wrote:
>
> Originally the last WREG32_SOC15() was a part of the if statement block
> but the curly braces are on the wrong line.
>
> Fixes: bb0db70f3f75 ("drm/amdgpu: separate JPEG1.0 code out from VCN1.0")
> Signed-off-by: Dan Carpenter
Applied. Th
Applied. thanks!
Alex
On Tue, Nov 26, 2019 at 3:15 AM Jules Irenge wrote:
>
> Replace 0 with NULL to fix sparse tool warning
> warning: Using plain integer as NULL pointer
>
> Signed-off-by: Jules Irenge
> ---
> drivers/gpu/drm/radeon/radeon_audio.c | 2 +-
> 1 file changed, 1 insertion(+),
On Tue, Nov 26, 2019 at 4:55 PM Mihail Atanassov
wrote:
>
> Hi Daniel,
>
> Thanks for the quick review.
>
> On Tuesday, 26 November 2019 14:26:10 GMT Daniel Vetter wrote:
> > On Tue, Nov 26, 2019 at 01:15:59PM +, Mihail Atanassov wrote:
> > > A simple convenience function to initialize the str
Looks like the shift and mask are reversed. Does this patch fix it?
Yes, the warning is gone and it still works. Thank you!
Tested-by: Meelis Roos
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listi
On Tue, Nov 26, 2019 at 10:14:13AM +0100, Daniel Vetter wrote:
> 0 means 1 as the default, but it's mighty confusing if the block size
> for the first plane is spelled out explicitly, but not for the 2nd
> plane.
>
> No cc: stable because this is just confusion, but 0 functional issue.
Acked-by:
On 2019-11-25 4:36 p.m., Zuo, Jerry wrote:
> Please kindly give a review on my latest revision. Thanks a lot.
>
Both patches are
Reviewed-by: Harry Wentland
Harry
> Regards,
> Jerry
>
> -Original Message-
> From: Jerry (Fangzhi) Zuo
> Sent: November 5, 2019 11:38 AM
> To: dri-devel@
Commit b0e40e ("vram: Have VRAM MM call GEM VRAM functions directly")
removed this.
Signed-off-by: Gurchetan Singh
---
include/drm/drm_gem_vram_helper.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/drm/drm_gem_vram_helper.h
b/include/drm/drm_gem_vram_helper.h
index e040541a105f..0
Hi
Am 26.11.19 um 19:43 schrieb Gurchetan Singh:
> Commit b0e40e ("vram: Have VRAM MM call GEM VRAM functions directly")
> removed this.
>
> Signed-off-by: Gurchetan Singh
Reviewed-by: Thomas Zimmermann
Thanks! I'll add the patch into drm-misc-next.
Best regards
Thomas
> ---
> include/drm/
Hi Mihail.
> Ack, but with one caveat: bridge->dev is the struct drm_device that is
> the bridge client, we need to add a bridge->device (patch 29 in this
> series) which is the struct device that will manage the bridge lifetime.
Other places uses the variable name "drm" for a drm_device.
This is
Hi Mihail.
On Tue, Nov 26, 2019 at 01:16:26PM +, Mihail Atanassov wrote:
> No functional change.
>
> Signed-off-by: Mihail Atanassov
> ---
> drivers/gpu/drm/sti/sti_dvo.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu
I'm not well versed in MST bw validation, which might explain my confusion here
- so bear with me :)
...
On 2019-11-16 5:01 p.m., mikita.lip...@amd.com wrote:
> From: Mikita Lipski
>
> Adding PBN attribute to drm_dp_vcpi_allocation structure to
> keep track of how much bandwidth each Port requi
From: Thomas Hellstrom
We were using an ugly hack to set the page protection correctly.
Fix that and instead use vmf_insert_mixed_prot() and / or
vmf_insert_pfn_prot().
Also get the default page protection from
struct vm_area_struct::vm_page_prot rather than using vm_get_page_prot().
This way we
Hi Daniel,
Thanks for the comments, please see inline
W dniu 25.11.2019 o 09:55, Daniel Vetter pisze:
On Thu, Nov 21, 2019 at 06:22:44PM +0100, Andrzej Pietrasiewicz wrote:
These are useful for other users of afbc, e.g. rockchip.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/Mak
From: Thomas Hellstrom
The TTM module today uses a hack to be able to set a different page
protection than struct vm_area_struct::vm_page_prot. To be able to do
this properly, add and export vmf_insert_mixed_prot().
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill
Hi Jyri.
Took a quick look - looks like a very nice driver.
Some drive by comments below.
I was left with the impression that there is a lot of code to support
vblank - and I wonder if there is some general code that can help you
here that you have missed.
Sam
On Tue, Nov 26, 2019 at 1
[big snip]
> There is a sysfs attribute called "d3cold_allowed" which can be used
> for "blocking" D3cold, so can you please retest using that?
>
Hey-this is almost certainly not the right place in this thread to respond,
but this thread has gotten so deep evolution can't push the subject further
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #172 from line...@xcpp.org ---
I had dpm=2 as a module option. GPU initialization failure does not occur
without dpm=2
--
You are receiving this mail because:
You are the assignee for the bug.
I'm about to post some more review comments for the v2 version of this, but
some comments down below...
On Tue, 2019-10-08 at 12:19 +0300, Jani Nikula wrote:
> On Mon, 07 Oct 2019, Adam Jackson wrote:
> > On Mon, 2019-10-07 at 12:08 +0300, Jani Nikula wrote:
> >
> > > The problem with the EDID q
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
drivers/gpu/drm/i915/Kconfig.debug
between commit:
d30213e533fa ("drm/i915: Fix Kconfig indentation")
from the drm tree and commit:
fb041bb7c0a9 ("locking/refcount: Consolidate implementations of refcount_t")
from the
Hey! Saw your comment on the RHBZ regarding this, figured I'd take a look
since I've got some DPCD backlight related fixes for one of your other laptops
on the list as well.
On Thu, 2019-10-10 at 00:13 +0800, Lee Shawn C wrote:
> This panel (manufacturer is SDC, product ID is 0x4141)
> used manufa
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Emily Deng
>-Original Message-
>From: Grodzovsky, Andrey
>Sent: Tuesday, November 26, 2019 7:37 AM
>Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; Koenig,
>Christian ; Deng, Emily
>; steven.pr...@arm.
Hi, Yongqiang:
On Tue, 2019-11-26 at 14:47 +0800, yongqiang@mediatek.com wrote:
> From: Yongqiang Niu
>
> This patch fix up 1440x900 dp display black screen issue
> the computed result will overflow rdma1 fifo max size
> when external display pixel clock bigger than 74MHZ
>
> Signed-off-by:
On Tue, 2019-11-26 at 09:49 +0100, Daniel Vetter wrote:
> On Tue, Nov 26, 2019 at 02:29:26PM +0800, Bibby Hsieh wrote:
> > The DRM core takes care of all atomic state refcounting.
> > However, mediatek drm defers some work that accesses planes
> > and plane_states in drm_atomic_state, and must ther
https://bugzilla.kernel.org/show_bug.cgi?id=205675
Bug ID: 205675
Summary: Display locks up. AMDGPU timeout
Product: Drivers
Version: 2.5
Kernel Version: 5.4.0
Hardware: x86-64
OS: Linux
Tree: Mainline
On Fri, Nov 22, 2019 at 09:32:45AM +0800, Philip Li wrote:
> On Thu, Nov 21, 2019 at 07:26:05AM +, Chris Wilson wrote:
> > Quoting kernel test robot (2019-11-21 07:19:43)
> > > Greetings,
> > >
> > > 0day kernel testing robot got the below dmesg and the first bad commit is
> > >
> > > https:/
When enabling the CRTC after waking up from a power-saving mode, the
primary plane's framebuffer might be NULL, which leads to a stack trace
as shown below.
[ 632.624608] BUG: kernel NULL pointer dereference, address: 0048
[ 632.624631] #PF: supervisor read access in kernel mode
Hi Emil,
On Fri, 1 Nov 2019 13:03:13 +
Emil Velikov wrote:
> From: Emil Velikov
>
> As mentioned by Christian, for drivers which support only primary nodes
> this changes the returned error from -EACCES into -EOPNOTSUPP/-ENOSYS.
Are you sure this is true for MODESET-only nodes (those tha
101 - 153 of 153 matches
Mail list logo
