https://bugzilla.kernel.org/show_bug.cgi?id=205675
--- Comment #20 from swebwaer (gosesen...@tjuln.com) ---
https://gitlab.com/gitlab-org/gitlab/-/issues/286834
https://gitlab.com/gitlab-org/gitlab/-/issues/286835
https://gitlab.com/gitlab-org/gitlab/-/issues/286835
https://bugzilla.kernel.org/show_bug.cgi?id=205675
--- Comment #19 from swebwaer (gosesen...@tjuln.com) ---
https://gitlab.com/gitlab-org/gitlab/-/issues/286778
https://gitlab.com/gitlab-org/gitlab/-/issues/286779
https://gitlab.com/gitlab-org/gitlab/-/issues/286780
https://bugzilla.kernel.org/show_bug.cgi?id=205675
--- Comment #18 from swebwaer (gosesen...@tjuln.com) ---
https://gitlab.com/gitlab-org/gitlab/-/issues/286778
https://gitlab.com/gitlab-org/gitlab/-/issues/286779
https://gitlab.com/gitlab-org/gitlab/-/issues/286780
https://bugzilla.kernel.org/show_bug.cgi?id=205675
--- Comment #17 from swebwaer (gosesen...@tjuln.com) ---
https://gitlab.com/gitlab-org/gitlab/-/issues/286743
https://gitlab.com/gitlab-org/gitlab/-/issues/286745
https://bugzilla.kernel.org/show_bug.cgi?id=205675
--- Comment #16 from swebwaer (gosesen...@tjuln.com) ---
https://gitlab.com/gitlab-org/gitlab/-/issues/286709
https://gitlab.com/gitlab-org/gitlab/-/issues/286710
https://gitlab.com/gitlab-org/gitlab/-/issues/286711
tree: git://people.freedesktop.org/~agd5f/linux.git amd-20.45
head: 1807abbb3a7f17fc931a15d7fd4365ea148c6bb1
commit: 2731dbcd0d317dd03d7552e0356ce0ea08b0b838 [2115/2417] drm/amd/display:
Adjust static-ness of resource functions
config: i386-randconfig-a003-20201120 (attached as .config)
https://bugzilla.kernel.org/show_bug.cgi?id=205675
--- Comment #15 from swebwaer (gosesen...@tjuln.com) ---
https://gitlab.com/gitlab-org/gitlab/-/issues/286634
https://gitlab.com/gitlab-org/gitlab/-/issues/286635
https://gitlab.com/gitlab-org/gitlab/-/issues/286636
https://bugzilla.kernel.org/show_bug.cgi?id=205675
--- Comment #14 from swebwaer (gosesen...@tjuln.com) ---
https://gitlab.com/gitlab-org/gitlab/-/issues/286634
https://gitlab.com/gitlab-org/gitlab/-/issues/286635
https://gitlab.com/gitlab-org/gitlab/-/issues/286636
tree: git://people.freedesktop.org/~agd5f/linux.git amd-20.45
head: 1807abbb3a7f17fc931a15d7fd4365ea148c6bb1
commit: 24a52b0a25c5c311e471b0552284d8c359ca7047 [2113/2417] drm/amd/display:
Add dsc_to_stream_resource for dcn3
config: i386-randconfig-a003-20201120 (attached as .config)
compiler:
https://bugzilla.kernel.org/show_bug.cgi?id=205675
--- Comment #13 from swebwaer (gosesen...@tjuln.com) ---
https://gitlab.com/gitlab-org/gitlab/-/issues/286588
https://gitlab.com/gitlab-org/gitlab/-/issues/286589
https://gitlab.com/gitlab-org/gitlab/-/issues/286590
This patch is basically a port of Ørjan Eide's similar patch for ION
https://lore.kernel.org/lkml/20200414134629.54567-1-orjan.e...@arm.com/
Only sync the sg-list of dma-buf heap attachment when the attachment
is actually mapped on the device.
dma-bufs may be synced at any time. It can be
The heap-helpers code was not as generic as initially hoped
and it is now not being used, so remove it from the tree.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc:
While the system heap can return non-contiguous pages,
try to allocate larger order pages if possible.
This will allow slight performance gains and make implementing
page pooling easier.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren
Since the heap-helpers logic ended up not being as generic as
hoped, move the heap-helpers dma_buf_ops implementations into
the cma_heap directly.
This will allow us to remove the heap_helpers code in a following
patch.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc:
In preparation for some patches to optmize the system
heap code, rework the dmabuf exporter to utilize sgtables rather
then pageslists for tracking the associated pages.
This will allow for large order page allocations, as well as
more efficient page pooling.
In doing so, the system heap stops
Hey All,
So Sumit noted a flub I made in adapting the last series to
the new dma-buf-map code that is in drm-misc-next. Thus I wanted
to send this (hopefully) last revision of my patch series of
performance optimizations to the dma-buf system heap, once again
against drm-misc-next.
This series
https://bugzilla.kernel.org/show_bug.cgi?id=205675
--- Comment #12 from swebwaer (gosesen...@tjuln.com) ---
https://gitlab.com/gitlab-org/gitlab/-/issues/286503
https://gitlab.com/gitlab-org/gitlab/-/issues/286504
https://gitlab.com/gitlab-org/gitlab/-/issues/286505
https://bugzilla.kernel.org/show_bug.cgi?id=210301
Bug ID: 210301
Summary: *ERROR* IB test failed on gfx (-110) on Ryzen 4750u
Product: Drivers
Version: 2.5
Kernel Version: 5.9.8
Hardware: Intel
OS: Linux
https://bugzilla.kernel.org/show_bug.cgi?id=205675
--- Comment #11 from swebwaer (gosesen...@tjuln.com) ---
https://gitlab.com/gitlab-org/gitlab/-/issues/286386
https://gitlab.com/gitlab-org/gitlab/-/issues/286387
https://gitlab.com/gitlab-org/gitlab/-/issues/286389
tree: git://people.freedesktop.org/~agd5f/linux.git amd-20.45
head: 1807abbb3a7f17fc931a15d7fd4365ea148c6bb1
commit: 470f4be73099cc46478d2c708411fecde8197ca3 [1379/2417] drm/amdkcl: update
DRM_AMD_DC_DCN3_0 to depends on legacy display config
config: i386-randconfig-a003-20201120 (attached as
https://bugzilla.kernel.org/show_bug.cgi?id=205675
--- Comment #10 from swebwaer (gosesen...@tjuln.com) ---
https://gitlab.com/gitlab-org/gitlab/-/issues/286267
https://gitlab.com/gitlab-org/gitlab/-/issues/286268
https://gitlab.com/gitlab-org/gitlab/-/issues/286269
https://bugzilla.kernel.org/show_bug.cgi?id=205675
--- Comment #9 from swebwaer (gosesen...@tjuln.com) ---
https://gitlab.com/gitlab-org/gitlab/-/issues/286267
https://gitlab.com/gitlab-org/gitlab/-/issues/286268
https://gitlab.com/gitlab-org/gitlab/-/issues/286269
https://bugzilla.kernel.org/show_bug.cgi?id=205675
--- Comment #8 from swebwaer (gosesen...@tjuln.com) ---
https://gitlab.com/gitlab-org/gitlab/-/issues/286240
https://gitlab.com/gitlab-org/gitlab/-/issues/286241
https://gitlab.com/gitlab-org/gitlab/-/issues/286242
https://bugzilla.kernel.org/show_bug.cgi?id=205675
--- Comment #7 from swebwaer (gosesen...@tjuln.com) ---
https://gitlab.com/gitlab-org/gitlab/-/issues/286167
https://gitlab.com/gitlab-org/gitlab/-/issues/286168
https://gitlab.com/gitlab-org/gitlab/-/issues/286169
https://bugzilla.kernel.org/show_bug.cgi?id=205675
--- Comment #6 from swebwaer (gosesen...@tjuln.com) ---
https://gitlab.com/gitlab-org/gitlab/-/issues/286167
https://gitlab.com/gitlab-org/gitlab/-/issues/286168
https://gitlab.com/gitlab-org/gitlab/-/issues/286169
https://bugzilla.kernel.org/show_bug.cgi?id=205675
swebwaer (gosesen...@tjuln.com) changed:
What|Removed |Added
CC||gosesen...@tjuln.com
On Sat, 2020-11-21 at 09:18 -0800, James Bottomley wrote:
> On Sat, 2020-11-21 at 08:50 -0800, t...@redhat.com wrote:
> > A difficult part of automating commits is composing the subsystem
> > preamble in the commit log. For the ongoing effort of a fixer
> > producing one or two fixes a release
On Sat, 2020-11-21 at 08:50 -0800, t...@redhat.com wrote:
> A difficult part of automating commits is composing the subsystem
> preamble in the commit log. For the ongoing effort of a fixer
> producing
> one or two fixes a release the use of 'treewide:' does not seem
> appropriate.
>
> It would
On Sat, 2020-11-21 at 08:50 -0800, t...@redhat.com wrote:
> A difficult part of automating commits is composing the subsystem
> preamble in the commit log. For the ongoing effort of a fixer producing
> one or two fixes a release the use of 'treewide:' does not seem appropriate.
>
> It would be
A difficult part of automating commits is composing the subsystem
preamble in the commit log. For the ongoing effort of a fixer producing
one or two fixes a release the use of 'treewide:' does not seem appropriate.
It would be better if the normal prefix was used. Unfortunately normal is
not
tree: git://people.freedesktop.org/~agd5f/linux.git amd-20.45
head: 1807abbb3a7f17fc931a15d7fd4365ea148c6bb1
commit: 90e75e02fc4f30c8139b7321f8bbd635ec9d75ce [1835/2417] drm/amdkcl: dkms
support for hmm
config: sparc-randconfig-c004-20201120 (attached as .config)
compiler: sparc64-linux-gcc
On Fri 2020-11-13 12:54:41, Sakari Ailus wrote:
> Add a printk modifier %p4cc (for pixel format) for printing V4L2 and DRM
> pixel formats denoted by fourccs. The fourcc encoding is the same for both
> so the same implementation can be used.
>
> Suggested-by: Mauro Carvalho Chehab
>
Late in 2019, 2 commits (see the 2 Fixes tags) were introduced to
mitigate the slow framebuffer issue. Now that we have fixed the
slowness issue by correctly mapping the MMIO VRAM (see
commit 5f1251a48c17 ("video: hyperv_fb: Fix the cache type when mapping
the VRAM")), we can remove most of the
Hi Dexuan,
On Fri, Nov 20, 2020 at 05:45:47PM -0800, Dexuan Cui wrote:
> Late in 2019, 2 commits (see the 2 Fixes tags) were introduced to
> mitigate the slow framebuffer issue. Now that we have fixed the
> slowness issue by correctly mapping the MMIO VRAM (see
> commit 5f1251a48c17 ("video:
Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky:
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
---
drivers/gpu/drm/drm_drv.c | 3 +++
1 file changed, 3 insertions(+)
Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky:
Will be used to reroute CPU mapped BO's page faults once
device is removed.
Uff, one page for each exported DMA-buf? That's not something we can do.
We need to find a different approach here.
Can't we call alloc_page() on each fault and link
Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky:
Fixes oops.
That file doesn't even exist any more. What oops should this fix?
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
On Fri, 13 Nov 2020 18:06:19 +0300, Cengiz Can wrote:
> Example `display-subsystem` has an incorrect compatible string.
>
> Required properties section tells that developers should use
> "fsl,imx-display-subsystem" as "compatible" string but the example
> misses 'imx-' prefix.
>
> Change example
On Thu, Nov 12, 2020 at 04:37:03PM +0800, Hsin-Yi Wang wrote:
> anx7625 requires 3 power supply regulators.
>
> Signed-off-by: Hsin-Yi Wang
> ---
> .../display/bridge/analogix,anx7625.yaml | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git
>
On Thu, Nov 19, 2020 at 4:41 PM Daniel Vetter wrote:
>
> All we need are a pages array, pin_user_pages_fast can give us that
> directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.
>
> Note that pin_user_pages_fast is a safe replacement despite the
> seeming lack of checking for
tree: git://people.freedesktop.org/~agd5f/linux.git amd-20.45
head: 1807abbb3a7f17fc931a15d7fd4365ea148c6bb1
commit: 641803ba0aabf8d823eb6cf6667dda3fdca58872 [198/2417] drm/amdgpu:
[hybrid] add semaphore object support
config: x86_64-randconfig-a011-20201120 (attached as .config)
compiler:
On Fri, Nov 20, 2020 at 10:54:43AM +0100, Daniel Vetter wrote:
> diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
> index d5ece7a9a403..f94405d43fd1 100644
> --- a/include/linux/sched/mm.h
> +++ b/include/linux/sched/mm.h
> @@ -180,6 +180,22 @@ static inline void
Hello,
We have a patch in Weston to replace drmGetConnector() calls with
drmGetConnectorCurrent():
https://gitlab.freedesktop.org/wayland/weston/-/issues/437
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/518
Unfortunately this is not working when we use VKMS (upstream
The current HVS muxing code will consider the CRTCs in a given state to
setup their muxing in the HVS, and disable the other CRTCs muxes.
However, it's valid to only update a single CRTC with a state, and in this
situation we would mux out a CRTC that was enabled but left untouched by
the new
Hi!
On Thu, Nov 19, 2020 at 09:59:15AM +0100, Thomas Zimmermann wrote:
> Am 05.11.20 um 14:56 schrieb Maxime Ripard:
> > If a CRTC is enabled but not active, and that we're then doing a page
> > flip on another CRTC, drm_atomic_get_crtc_state will bring the first
> > CRTC state into the global
Hi,
Here's a second attempt at fixing the current issues we have with the
muxing code that results in a PV muxing its HVS muxing when only another
CRTC is modified by a state, or vblank timeouts when trying to wait for a
vblank on a single CRTC while another one is inactive but enabled.
Let me
On Thu, Nov 19, 2020 at 03:41:46PM +0100, Daniel Vetter wrote:
> @@ -4805,21 +4824,15 @@ EXPORT_SYMBOL(follow_pte_pmd);
> * Return: zero and the pfn at @pfn on success, -ve otherwise.
> */
> int follow_pfn(struct vm_area_struct *vma, unsigned long address,
> - unsigned long *pfn)
> +
The explicit out-fences in crtc are signaled as part of vblank event,
indicating all framebuffers present on the Atomic Commit request are
scanned out on the screen. Though the fence signal and the vblank event
notification happens at the same time, triggered by the same hardware
vsync event, the
Hi,
On 11/20/20 1:54 AM, Daniel Vetter wrote:
> diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
> index d5ece7a9a403..f94405d43fd1 100644
> --- a/include/linux/sched/mm.h
> +++ b/include/linux/sched/mm.h
> @@ -180,6 +180,22 @@ static inline void fs_reclaim_acquire(gfp_t gfp_mask)
On Fri, Nov 20, 2020 at 10:54:42AM +0100, Daniel Vetter wrote:
> fs_reclaim_acquire/release nicely catch recursion issues when
> allocating GFP_KERNEL memory against shrinkers (which gpu drivers tend
> to use to keep the excessive caches in check). For mmu notifier
> recursions we do have lockdep
Commit 03e0d26fcf79 ("drm/nouveau: slowpath for pushbuf ioctl") included
a logic-bug which results in the relocations not actually getting
applied at all as the call to nouveau_gem_pushbuf_reloc_apply() is
never reached. This causes a regression with graphical corruption,
triggered when
From: Thomas Zimmermann
> Sent: 20 November 2020 13:42
...
> I did a diff from v5.10-rc4 to drm-tip to look for suspicious changes.
> Some candidates are
>
>8e3784dfef8a ("drm/ast: Reload gamma LUT after changing primary
> plane's color format")
Ok, that one fixes the screen colours (etc).
From: Thomas Zimmermann
> Sent: 20 November 2020 10:14
...
> > Is there any way to bisect through the parts of the
> > drm merge patch into v5.10-rc1 ?
> >
> > That ought to be quicker (and less error prone) than
> > the bisect builds I was doing.
> >
> > Note that the stack 'splat' is due to a
From: Thomas Zimmermann
> Sent: 20 November 2020 11:27
...
> >> You can use drm-tip for testing, where many of the DRM patches go through.
> >>
> >> https://cgit.freedesktop.org/drm/drm-tip/
> >>
> >> It's fairly up-to-date.
> >
> > Any idea of tags either side of the 5.10 merge?
>
> The
Hi Gustavo,
On Fri, Nov 20, 2020 at 7:21 PM Gustavo A. R. Silva
wrote:
>
> Hi all,
>
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
Thanks for this.
Since this warning is reliable in both/all compilers and we are
If a CRTC is enabled but not active, and that we're then doing a page
flip on another CRTC, drm_atomic_get_crtc_state will bring the first
CRTC state into the global state, and will make us wait for its vblank
as well, even though that might never occur.
Instead of creating the list of the free
Hi Daniel,
Thanks for your review
On Fri, Nov 13, 2020 at 10:02:40PM +0100, Daniel Vetter wrote:
> > +* is not used by the atomic helpers.
> > +*
> > +* This function is called at the end of
> > +* drm_atomic_helper_setup_commit(), so once the commit has been
> > +* properly
On Thu, 2020-10-29 at 14:40 +0100, Maxime Ripard wrote:
> The RPi4 WiFi chip and HDMI outputs have some frequency overlap with
> crosstalk around 2.4GHz. Let's mark it as such so we can use some evasive
> maneuvers.
>
> Signed-off-by: Maxime Ripard
>
> ---
>
> Changes from v1:
> - Changed
> Hi David
>
> Am 18.11.20 um 23:01 schrieb David Laight:
...
> Did you try Daniel's suggestion of testing with the direct parent commit?
(I was on holiday yesterday and didn't want to spend a sunny
afternoon doing bisects.)
I've just done that and it is bad.
Is there any way to bisect through
Some drivers have hardware capability to get the precise timestamp of
certain events based on which the fences are triggered. This allows it to
set accurate timestamp factoring out any software and IRQ latencies. Add
a timestamp variant of fence signal function, dma_fence_signal_timestamp
to allow
Hi,
On Thu, Nov 19, 2020 at 05:21:48PM +0200, Ville Syrjälä wrote:
> On Wed, Nov 18, 2020 at 10:47:58AM +0100, Maxime Ripard wrote:
> > 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
From: Thomas Zimmermann
> Sent: 20 November 2020 12:30
>
> Am 20.11.20 um 12:45 schrieb David Laight:
> > From: Thomas Zimmermann
> >> Sent: 20 November 2020 11:27
> > ...
> You can use drm-tip for testing, where many of the DRM patches go
> through.
>
>
Bilal Wasim 於 2020年11月20日 週五 上午8:30寫道：
>
> Hi CK,
>
> On Fri, 20 Nov 2020 07:23:35 +0800
> Chun-Kuang Hu wrote:
>
> > From: CK Hu
> >
> > In the patch to be fixed, horizontal_backporch_byte become to large
> > for some panel, so roll back that patch. For small hfp or hbp panel,
> > using
On Thu, Nov 19, 2020 at 4:41 PM Daniel Vetter wrote:
>
> These are persistent, not just for the duration of a dma operation.
>
> Signed-off-by: Daniel Vetter
> Cc: Jason Gunthorpe
> Cc: Andrew Morton
> Cc: John Hubbard
> Cc: Jérôme Glisse
> Cc: Jan Kara
> Cc: Dan Williams
> Cc:
tree: git://people.freedesktop.org/~agd5f/linux.git amd-20.45
head: 1807abbb3a7f17fc931a15d7fd4365ea148c6bb1
commit: b46fcb031f1ca11f48ea670680cb5eed851e9870 [189/2417] drm/amdgpu:
[hybrid] add query for aperture va range
config: x86_64-randconfig-a011-20201120 (attached as .config)
compiler:
65 matches
Mail list logo
