On Thu, Jun 06, 2019 at 11:59:15AM +0100, Emil Velikov wrote:
> On Mon, 27 May 2019 at 09:19, Emil Velikov wrote:
> >
> > From: Emil Velikov
> >
> > The authentication can be circumvented, by design, by using the render
> > node.
> >
> > From the driver POV there is no distinction between primary
Hello Thomas
On Wed, 12 Jun 2019 08:42:39 +0200 Thomas Hellstrom wrote:
> From: Thomas Hellstrom
>
> With the vmwgfx dirty tracking, the default TTM fault handler is not
> completely sufficient (vmwgfx need to modify the vma->vm_flags member,
> and also needs to restrict the number of prefaults
Hi Vincenzo,
On Tue, Jun 11, 2019 at 06:09:10PM +0100, Vincenzo Frascino wrote:
> > diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> > index 3767fb21a5b8..69d0be1fc708 100644
> > --- a/arch/arm64/kernel/process.c
> > +++ b/arch/arm64/kernel/process.c
> > @@ -30,6 +30,7 @@
>
On Wed, Jun 12, 2019 at 7:43 AM Sumit Semwal wrote:
>
> Hello Chenbo,
>
> Thanks very much for your patches. Other than a couple tiny nits
> below, I think these look good, and I will merge them before the end
> of this week.
> On Tue, 11 Jun 2019 at 05:32, Chenbo Feng wrote:
> >
> > From: Greg H
On Mon, Jun 03, 2019 at 06:55:17PM +0200, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> vaddr_get_pfn() uses provided user pointe
This patch is a part of a series that extends arm64 kernel ABI to allow to
pass tagged user pointers (with the top byte set to something else other
than 0x00) as syscall arguments.
This patch allows tagged pointers to be passed to the following memory
syscalls: get_mempolicy, madvise, mbind, minco
On Mon, Jun 03, 2019 at 06:55:11PM +0200, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> userfaultfd code use provided user pointe
From: Greg Hackmann
By traversing /proc/*/fd and /proc/*/map_files, processes with CAP_ADMIN
can get a lot of fine-grained data about how shmem buffers are shared
among processes. stat(2) on each entry gives the caller a unique
ID (st_ino), the buffer's size (st_size), and even the number of pag
From: Greg Hackmann
This patch adds complimentary DMA_BUF_SET_NAME ioctls, which lets
userspace processes attach a free-form name to each buffer.
This information can be extremely helpful for tracking and accounting
shared buffers. For example, on Android, we know what each buffer will
be used
On Tue, Jun 11, 2019 at 7:02 AM Russell King wrote:
>
> The TDA998x derives the CTS value using the supplied I2S bit clock
> (ACLK, in TDA998x parlence) rather than 128·fs. TDA998x uses two
> constants named m and k in the CTS generator such that we have this
> relationship between the I2S source
On Tue, Jun 11, 2019 at 7:50 PM Catalin Marinas wrote:
>
> On Tue, Jun 11, 2019 at 07:18:04PM +0200, Andrey Konovalov wrote:
> > On Tue, Jun 11, 2019 at 5:01 PM Catalin Marinas
> > wrote:
> > > static void *tag_ptr(void *ptr)
> > > {
> > > static int tagged_addr_err = 1;
> > > un
On Wed, Jun 12, 2019 at 12:28 PM Russell King - ARM Linux admin
wrote:
>
> The platform data path has never supported the HDMI codec way of doing
> things, so that really isn't a concern here. The platform data way
> was sufficient to allow SPDIF streams to work with a static setup of
> the TDA99
On Tue, Jun 04, 2019 at 03:09:26PM +0200, Andrey Konovalov wrote:
> On Tue, Jun 4, 2019 at 3:02 PM Jason Gunthorpe wrote:
> > On Tue, Jun 04, 2019 at 02:45:32PM +0200, Andrey Konovalov wrote:
> > > On Tue, Jun 4, 2019 at 2:27 PM Jason Gunthorpe wrote:
> > > > On Tue, Jun 04, 2019 at 02:18:19PM +0
On 12/06/2019 12:43, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> vaddr_get_pfn() uses provided user pointers for vma lookups, w
=== Overview
arm64 has a feature called Top Byte Ignore, which allows to embed pointer
tags into the top byte of each pointer. Userspace programs (such as
HWASan, a memory debugging tool [1]) might use this feature and pass
tagged user pointers to the kernel through syscalls or other interfaces.
On Tue, Jun 11, 2019 at 7:45 PM Catalin Marinas wrote:
>
> On Tue, Jun 11, 2019 at 05:35:31PM +0200, Andrey Konovalov wrote:
> > On Mon, Jun 10, 2019 at 4:28 PM Catalin Marinas
> > wrote:
> > > On Mon, Jun 03, 2019 at 06:55:07PM +0200, Andrey Konovalov wrote:
> > > > This patch is a part of a se
Le mar. 11 juin 2019 à 23:55, Rob Herring a écrit :
On Mon, 3 Jun 2019 17:23:30 +0200, Paul Cercueil wrote:
Add documentation for the devicetree bindings of the LCD controller
present in
the JZ47xx family of SoCs from Ingenic.
Signed-off-by: Paul Cercueil
Tested-by: Artur Rojek
---
Hi Catalin,
On 12/06/2019 10:32, Catalin Marinas wrote:
> Hi Vincenzo,
>
> On Tue, Jun 11, 2019 at 06:09:10PM +0100, Vincenzo Frascino wrote:
>>> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
>>> index 3767fb21a5b8..69d0be1fc708 100644
>>> --- a/arch/arm64/kernel/process.
On Wed, Jun 12, 2019 at 10:35:26PM -0400, Alex Deucher wrote:
> On Wed, Jun 12, 2019 at 10:34 PM Hariprasad Kelam
> wrote:
> >
> > this patch fixes below compilation error
> >
> > drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c: In
> > function ‘dcn10_apply_ctx_for_surface’:
>
This patch is a part of a series that extends arm64 kernel ABI to allow to
pass tagged user pointers (with the top byte set to something else other
than 0x00) as syscall arguments.
get_vaddr_frames uses provided user pointers for vma lookups, which can
only by done with untagged pointers. Instead
On 11/06/2019 at 19:09, Colin King wrote:
> External E-Mail
>
>
> From: Colin Ian King
>
> Currently variable ret is being initialized with -ENOENT however that
> value is never read and ret is being re-assigned later on. Hence this
> assignment is redundant and can be removed.
>
> Addresses-C
This patch is a part of a series that extends arm64 kernel ABI to allow to
pass tagged user pointers (with the top byte set to something else other
than 0x00) as syscall arguments.
In radeon_gem_userptr_ioctl() an MMU notifier is set up with a (tagged)
userspace pointer. The untagged address shoul
From: Catalin Marinas
It is not desirable to relax the ABI to allow tagged user addresses into
the kernel indiscriminately. This patch introduces a prctl() interface
for enabling or disabling the tagged ABI with a global sysctl control
for preventing applications from enabling the relaxed ABI (me
This patch is a part of a series that extends arm64 kernel ABI to allow to
pass tagged user pointers (with the top byte set to something else other
than 0x00) as syscall arguments.
vaddr_get_pfn() uses provided user pointers for vma lookups, which can
only by done with untagged pointers.
Untag us
On Wed, Jun 12, 2019 at 01:03:10PM +0200, Andrey Konovalov wrote:
> On Tue, Jun 11, 2019 at 7:39 PM Catalin Marinas
> wrote:
> > On Tue, Jun 11, 2019 at 07:09:46PM +0200, Andrey Konovalov wrote:
> > > Should I drop access_ok() change from my patch, since yours just reverts
> > > it?
> >
> > Not
On 12/06/2019 12:43, Andrey Konovalov wrote:
> --- /dev/null
> +++ b/tools/testing/selftests/arm64/tags_lib.c
> @@ -0,0 +1,62 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include
> +#include
> +
> +#define TAG_SHIFT(56)
> +#define TAG_MASK (0xffUL << TAG_SHIFT)
> +
> +#define PR_SET_
On Tue, Jun 11, 2019 at 10:18 PM Khalid Aziz wrote:
>
> On 6/3/19 10:55 AM, Andrey Konovalov wrote:
> > This patch is a part of a series that extends arm64 kernel ABI to allow to
> > pass tagged user pointers (with the top byte set to something else other
> > than 0x00) as syscall arguments.
> >
>
On Tue, Jun 11, 2019 at 4:38 PM Andrey Konovalov wrote:
>
> On Sat, Jun 8, 2019 at 6:02 AM Kees Cook wrote:
> >
> > On Mon, Jun 03, 2019 at 06:55:10PM +0200, Andrey Konovalov wrote:
> > > This patch is a part of a series that extends arm64 kernel ABI to allow to
> > > pass tagged user pointers (w
On 12/06/2019 12:43, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> copy_from_user (and a few other similar functions) are used to
This patch is a part of a series that extends arm64 kernel ABI to allow to
pass tagged user pointers (with the top byte set to something else other
than 0x00) as syscall arguments.
copy_from_user (and a few other similar functions) are used to copy data
from user memory into the kernel memory or v
This patch is a part of a series that extends arm64 kernel ABI to allow to
pass tagged user pointers (with the top byte set to something else other
than 0x00) as syscall arguments.
This patch adds a simple test, that calls the uname syscall with a
tagged user pointer as an argument. Without the ke
On Tue, Jun 11, 2019 at 7:01 AM Russell King wrote:
>
> Introduce a structure to hold the register values to be programmed while
> programming the TDA998x audio settings. This is currently a stub
> structure, which will be populated in subsequent commits.
>
> When we initialise this from the plat
On 12/06/2019 12:43, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> userfaultfd code use provided user pointers for vma lookups, w
This patch is a part of a series that extends arm64 kernel ABI to allow to
pass tagged user pointers (with the top byte set to something else other
than 0x00) as syscall arguments.
strncpy_from_user and strnlen_user accept user addresses as arguments, and
do not go through the same path as copy_fr
This patch is a part of a series that extends arm64 kernel ABI to allow to
pass tagged user pointers (with the top byte set to something else other
than 0x00) as syscall arguments.
In amdgpu_gem_userptr_ioctl() and amdgpu_amdkfd_gpuvm.c/init_user_pages()
an MMU notifier is set up with a (tagged) u
From: Greg Hackmann
The show_fdinfo handler exports the same information available through
debugfs on a per-buffer basis.
Signed-off-by: Greg Hackmann
Signed-off-by: Chenbo Feng
---
drivers/dma-buf/dma-buf.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/dma-buf/
This patch is a part of a series that extends arm64 kernel ABI to allow to
pass tagged user pointers (with the top byte set to something else other
than 0x00) as syscall arguments.
In copy_mount_options a user address is being subtracted from TASK_SIZE.
If the address is lower than TASK_SIZE, the
On Tue, Jun 11, 2019 at 7:02 AM Russell King wrote:
>
> Move the mux and clocking selection out of tda998x_configure_audio()
> into the parent functions, so we can validate this when parameters
> are set outside of the audio mutex.
>
> Signed-off-by: Russell King
> ---
+/* Configure the TDA998x
On Tue, Jun 11, 2019 at 7:02 AM Russell King wrote:
>
> tda998x_configure_audio() is called via some paths where an error
> return is meaningless, and as a result of moving the audio routing
> code, this function no longer returns any errors, so let's make it
> void. We can also make tda998x_write
This patch is a part of a series that extends arm64 kernel ABI to allow to
pass tagged user pointers (with the top byte set to something else other
than 0x00) as syscall arguments.
mlx4_get_umem_mr() uses provided user pointers for vma lookups, which can
only by done with untagged pointers.
Untag
On Wed, Jun 12, 2019 at 01:43:20PM +0200, Andrey Konovalov wrote:
> From: Catalin Marinas
>
> It is not desirable to relax the ABI to allow tagged user addresses into
> the kernel indiscriminately. This patch introduces a prctl() interface
> for enabling or disabling the tagged ABI with a global
On 12/06/2019 12:43, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> This patch allows tagged pointers to be passed to the followin
This patch is a part of a series that extends arm64 kernel ABI to allow to
pass tagged user pointers (with the top byte set to something else other
than 0x00) as syscall arguments.
videobuf_dma_contig_user_get() uses provided user pointers for vma
lookups, which can only by done with untagged poin
this patch fixes below compilation error
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c: In
function ‘dcn10_apply_ctx_for_surface’:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:2378:3:
error: implicit declaration of function ‘udelay’
[-Werror=implicit-fu
On Wed, Jun 12, 2019 at 12:12:34AM -0700, Christoph Hellwig wrote:
> On Tue, Jun 11, 2019 at 04:44:31PM -0300, Jason Gunthorpe wrote:
> > On Sat, Jun 08, 2019 at 01:54:25AM -0700, Christoph Hellwig wrote:
> > > FYI, I very much disagree with the direction this is moving.
> > >
> > > struct hmm_mir
This patch is a part of a series that extends arm64 kernel ABI to allow to
pass tagged user pointers (with the top byte set to something else other
than 0x00) as syscall arguments.
userfaultfd code use provided user pointers for vma lookups, which can
only by done with untagged pointers.
Untag us
On Tue, Jun 11, 2019 at 7:39 PM Catalin Marinas wrote:
>
> On Tue, Jun 11, 2019 at 07:09:46PM +0200, Andrey Konovalov wrote:
> > On Tue, Jun 11, 2019 at 4:57 PM Catalin Marinas
> > wrote:
> > >
> > > On Mon, Jun 10, 2019 at 06:53:27PM +0100, Catalin Marinas wrote:
> > > > On Mon, Jun 03, 2019 at
On 12/06/2019 12:43, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> In copy_mount_options a user address is being subtracted from
On Wed, Jun 12, 2019 at 12:42 PM Russell King - ARM Linux admin
wrote:
>
> I think you're confusing tda998x_derive_cts_n() and tda998x_get_adiv().
> tda998x_derive_cts_n() only returns 0 or -EINVAL.
>
True. Apologies for the confusion.
___
dri-devel mai
Currently, all dma-bufs share the same anonymous inode. While we can count
how many dma-buf fds or mappings a process has, we can't get the size of
the backing buffers or tell if two entries point to the same dma-buf. And
in debugfs, we can get a per-buffer breakdown of size and reference count,
bu
On 12/06/2019 12:43, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> mm/gup.c provides a kernel interface that accepts user address
On Tue, Jun 11, 2019 at 7:02 AM Russell King wrote:
>
> Improve the selection of the audio clock divisor so that more modes
> and sample rates work.
>
> Signed-off-by: Russell King
> ---
+static u8 tda998x_get_adiv(struct tda998x_priv *priv, unsigned int fs)
+{
+ unsigned long min_audio_cl
On Tue, Jun 11, 2019 at 7:01 AM Russell King - ARM Linux admin
wrote:
>
> This series represents development work collected over the last six
> months to improve the TDA998x driver, particularly for the audio
> side. These patches can be found in my "drm-tda998x-devel" branch
> at git://git.armli
On 12/06/2019 12:43, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> strncpy_from_user and strnlen_user accept user addresses as ar
On 12/06/2019 12:43, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> get_vaddr_frames uses provided user pointers for vma lookups,
On Tue, Jun 11, 2019 at 7:04 AM Russell King wrote:
>
> Add bridge timing information so that bridge users can figure out the
> timing parameters that are necessary for TDA998x.
>
> Signed-off-by: Russell King
> ---
+static const struct drm_bridge_timings tda9989_timings = {
+ .sampling_ed
This patch is a part of a series that extends arm64 kernel ABI to allow to
pass tagged user pointers (with the top byte set to something else other
than 0x00) as syscall arguments.
mm/gup.c provides a kernel interface that accepts user addresses and
manipulates user pages directly (for example get
This patch is a part of a series that extends arm64 kernel ABI to allow to
pass tagged user pointers (with the top byte set to something else other
than 0x00) as syscall arguments.
tee_shm_register()->optee_shm_unregister()->check_mem_type() uses provided
user pointers for vma lookups (via __check
On 12/06/2019 12:43, Andrey Konovalov wrote:
> From: Catalin Marinas
>
> It is not desirable to relax the ABI to allow tagged user addresses into
> the kernel indiscriminately. This patch introduces a prctl() interface
> for enabling or disabling the tagged ABI with a global sysctl control
> for
Another explicit lock operation of a GEM VRAM BO is located in mgag200's
framebuffer update code. Instead of locking the BO, we pin it to wherever
it is.
v2:
* update with pin flag of 0
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_fb.c | 27 ++
On 6/12/19 10:52 AM, Mauro Carvalho Chehab wrote:
> Convert the PM documents to ReST, in order to allow them to
> build with Sphinx.
>
> The conversion is actually:
> - add blank lines and identation in order to identify paragraphs;
> - fix tables markups;
> - add some lists markups;
> - m
Pinning a buffer prevents it from being moved to a different memory
location. For some operations, such as buffer updates, it is not
important where the buffer is located. Setting the pin function's
pl_flag argument to 0 will pin the buffer to whereever it is stored.
v2:
* document pin fla
The cursor handling in mgag200 is complicated to understand. It touches a
number of different BOs, but doesn't really use all of them.
Rewriting the cursor update reduces the amount of cursor state. There are
two BOs for double-buffered HW updates. The source BO updates the one that
is currently n
The unpin operation was missing from ast_cursor_fini(). Fixed now.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_mode.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index fb700d620b64..41741cd6cd15 100644
--- a
On Wed, Jun 12, 2019 at 01:30:36PM +0100, Szabolcs Nagy wrote:
> On 12/06/2019 12:43, Andrey Konovalov wrote:
> > --- /dev/null
> > +++ b/tools/testing/selftests/arm64/tags_lib.c
> > @@ -0,0 +1,62 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +#include
> > +#include
> > +
> > +#define TAG
Implementation of tc_poll_timeout() is almost a 100% copy-and-paste of
the code for regmap_read_poll_timeout(). Replace copied code with a
call to the original. While at it change tc_poll_timeout to accept
"struct tc_data *" instead of "struct regmap *" for brevity. No
functional change intended.
The GEM VRAM functions with kmap-object argument are not requried any
longer. Remove them.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 50 +--
include/drm/drm_gem_vram_helper.h | 4 ---
2 files changed, 8 insertions(+), 46 deletions(-
The lock functions and the locked-pin/unpin functions of GEM VRAM are not
requried any longer. Remove them.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 109 --
include/drm/drm_gem_vram_helper.h | 5 --
2 files changed, 114 deletions(
Drivers should not have to care about internal locking of GEM VRAM objects
and their memory-mapping structures. This patch set removes both from the
GEM VRAM interface.
This affects the ast and mgag200 drivers. In places where GEM objects are
being locked by the driver, the patch converts the lock
Another explicit lock operation of a GEM VRAM BO is located in AST's
framebuffer update code. Instead of locking the BO, we pin it to wherever
it is.
v2:
* update with pin flag of 0
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_fb.c | 33 -
The ast driver's data structures store unused or uncecessary cursor
state. Most of the cursor state is already stored elsewhere and can
be retrieved when necessary. Remove the obsolete fields and adapt
users accordingly.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_drv.h | 7 --
The ast driver used to lock the cursor source BO during updates. Locking
should be done internally by the BO's implementation, so we pin it instead
to system memory. The mapping information is also stored in the BO. No
need to have an extra argument to the kmap function.
v2:
* pin cursor B
https://bugs.freedesktop.org/show_bug.cgi?id=99970
--- Comment #8 from Michel Dänzer ---
(In reply to cosiekvfj from comment #7)
> Is is worth to try to fix DRI3 and EXA for this driver or is it better to
> stick to DRI2?
I'd say the latter.
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=110883
--- Comment #8 from Michel Dänzer ---
*** Bug 110906 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing lis
https://bugs.freedesktop.org/show_bug.cgi?id=110906
Michel Dänzer changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=110783
--- Comment #12 from Gert Wollny ---
I might add that the DIV is lowered in glsl to RCP+MUL before it is translated
to TGSI, so no need for it there.
When I look at the bicubic shader with the offending opcodes, I have to say
that using DIV th
https://bugzilla.kernel.org/show_bug.cgi?id=203879
--- Comment #2 from Michel Dänzer (mic...@daenzer.net) ---
That sounds like a general CPU related stability issue, not directly related to
the amdgpu driver.
--
You are receiving this mail because:
You are watching the assignee of the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=110822
--- Comment #20 from Gobinda Joy ---
(In reply to Alex Deucher from comment #19)
> (In reply to Gobinda Joy from comment #18)
> >
> > What I don't get is why they are using 2 calls to get the bandwidth reading.
> > Since both function walking t
Hi, Yongqiang:
On Wed, 2019-06-05 at 19:42 +0800, yongqiang@mediatek.com wrote:
> From: Yongqiang Niu
>
> mutex sof register offset will be private data of ddp
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 13 ++---
> 1 file changed, 10 insertio
On Wed, Jun 12, 2019 at 10:38:23AM -0300, Rodrigo Siqueira wrote:
> On Thu, Jun 6, 2019 at 7:28 PM Daniel Vetter wrote:
> >
> > Plus add a comment about what it actually protects. It's very little.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Rodrigo Siqueira
> > Cc: Haneen Mohammed
> > Cc: Dan
On Mon, Jun 10, 2019 at 10:36:27AM -0300, Helen Koike wrote:
> commit 89a4aac0ab0e6f5eea10d7bf4869dd15c3de2cd4 upstream.
>
> In the case of a normal sync update, the preparation of framebuffers (be
> it calling drm_atomic_helper_prepare_planes() or doing setups with
> drm_framebuffer_get()) are pe
On Mon, Jun 10, 2019 at 10:18:59AM -0300, Helen Koike wrote:
> commit c16b85559dcfb5a348cc085a7b4c75ed49b05e2c upstream.
>
> Async update callbacks are expected to set the old_fb in the new_state
> so prepare/cleanup framebuffers are balanced.
>
> Calling drm_atomic_set_fb_for_plane() (which gets
On Wed, Jun 12, 2019 at 10:42:42AM -0300, Rodrigo Siqueira wrote:
> On Thu, Jun 6, 2019 at 7:28 PM Daniel Vetter wrote:
> >
> > Currently we flush pending crc workers very late in the commit flow,
> > when we destry all the old crtc states. Unfortunately at that point
>
> destry -> destroy
>
> >
On Thu, Jun 13, 2019 at 09:53:55AM +0200, Daniel Vetter wrote:
> On Wed, Jun 12, 2019 at 10:42:42AM -0300, Rodrigo Siqueira wrote:
> > On Thu, Jun 6, 2019 at 7:28 PM Daniel Vetter wrote:
> > >
> > > Currently we flush pending crc workers very late in the commit flow,
> > > when we destry all the o
On Mon, Jun 3, 2019 at 7:19 PM Maxime Ripard wrote:
>
> On Mon, May 20, 2019 at 02:33:16PM +0530, Jagan Teki wrote:
> > Allwinner MIPI DSI controllers are supplied with SoC
> > DSI power rails via VCC-DSI pin.
> >
> > Add support for this supply pin by adding voltage
> > regulator handling code to
On Wed, Jun 12, 2019 at 10:46:28AM -0300, Rodrigo Siqueira wrote:
> On Thu, Jun 6, 2019 at 7:28 PM Daniel Vetter wrote:
> >
> > The crc computation worker needs to be able to get at some data
> > structures and framebuffer mappings, while potentially more atomic
> > updates are going on. The solut
On Fri, May 31, 2019 at 12:23 AM Maxime Ripard
wrote:
>
> On Fri, May 24, 2019 at 03:55:42PM +0530, Jagan Teki wrote:
> > On Fri, May 24, 2019 at 2:07 AM Maxime Ripard
> > wrote:
> > >
> > > On Mon, May 20, 2019 at 02:33:09PM +0530, Jagan Teki wrote:
> > > > start value in video start delay comp
https://bugs.freedesktop.org/show_bug.cgi?id=110795
Andre Klapper changed:
What|Removed |Added
Resolution|WONTFIX |INVALID
--- Comment #17 from Andre Klap
On Wed, Jun 12, 2019 at 02:26:24AM +, james qian wang (Arm Technology
China) wrote:
> On Tue, Jun 11, 2019 at 02:30:38PM +0200, Daniel Vetter wrote:
> > On Tue, Jun 11, 2019 at 11:13:45AM +, Lowry Li (Arm Technology China)
> > wrote:
> > > From: "Lowry Li (Arm Technology China)"
> > >
>
On Thu, Jun 13, 2019 at 08:45:49AM +0200, Thomas Zimmermann wrote:
> Acked-by: Thomas Zimmermann
Thanks for taking a look, pushed to drm-misc-next.
-Daniel
>
> Am 12.06.19 um 11:12 schrieb Daniel Vetter:
> > ast doesn't implement the mode_set_base_atomic hook this would need,
> > so this is dea
https://bugs.freedesktop.org/show_bug.cgi?id=110907
Michel Dänzer changed:
What|Removed |Added
Attachment #144525|text/x-log |text/plain
mime type|
On Wed, Jun 12, 2019 at 11:10:54PM -0300, Rodrigo Siqueira wrote:
> For historical reason, the function drm_wait_vblank_ioctl always return
> -EINVAL if something gets wrong. This scenario limits the flexibility
> for the userspace make detailed verification of the problem and take
> some action. I
https://bugs.freedesktop.org/show_bug.cgi?id=110907
--- Comment #1 from Michel Dänzer ---
[ 4.187] (EE) 3: /opt/mesa-latest/x86_64/radeonsi_dri.so
(0x7f5f52ac+0x1b9335) [0x7f5f52c79335]
[ 4.187] (EE) 4: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
(0x7f5f4528c000+0x264dce) [0x7f5f454
On Thu, Jun 13, 2019 at 08:18:54AM +0530, Hariprasad Kelam wrote:
> On Wed, Jun 12, 2019 at 10:35:26PM -0400, Alex Deucher wrote:
> > On Wed, Jun 12, 2019 at 10:34 PM Hariprasad Kelam
> > wrote:
> > >
> > > this patch fixes below compilation error
> > >
> > > drivers/gpu/drm/amd/amdgpu/../display/
On Thu, Jun 13, 2019 at 02:31:18PM +0800, CK Hu wrote:
> Hi, Daniel:
>
> On Wed, 2019-06-12 at 18:25 +0200, Daniel Vetter wrote:
> > On Wed, Jun 12, 2019 at 03:51:08PM +0800, CK Hu wrote:
> > > Hi Dave, Daniel:
> > >
> > > This include unbind error fix, clock control flow refinement, and PRIME
>
On Thu, Jun 13, 2019 at 10:17:27AM +0200, Daniel Vetter wrote:
> On Wed, Jun 12, 2019 at 02:26:24AM +, james qian wang (Arm Technology
> China) wrote:
> > On Tue, Jun 11, 2019 at 02:30:38PM +0200, Daniel Vetter wrote:
> > > On Tue, Jun 11, 2019 at 11:13:45AM +, Lowry Li (Arm Technology Chi
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #15 from Richard Thier ---
(In reply to cosiekvfj from comment #14)
> Created attachment 144524 [details]
> bigger glxgears window
>
> >Is HyperZ just good without any changes to stock mesa?
> yes, mesa is from manjaro repo, and I t
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #16 from Richard Thier ---
Btw I now have no problems at all... This is weird... all I did was to remove
my printfs so that code is actually stock mesa and I both see the speed gain
and there is no problems whatsoever...
But I reboo
On Thu, Jun 13, 2019 at 09:28:13AM +0100, Liviu Dudau wrote:
> On Thu, Jun 13, 2019 at 10:17:27AM +0200, Daniel Vetter wrote:
> > On Wed, Jun 12, 2019 at 02:26:24AM +, james qian wang (Arm Technology
> > China) wrote:
> > > On Tue, Jun 11, 2019 at 02:30:38PM +0200, Daniel Vetter wrote:
> > > >
https://bugs.freedesktop.org/show_bug.cgi?id=110856
--- Comment #2 from Arek Tumas ---
Created attachment 144527
--> https://bugs.freedesktop.org/attachment.cgi?id=144527&action=edit
Dmesg log file
This is during a Rocket League session with kernel version 5.1.4-1-MANJARO
--
You are receivin
1 - 100 of 303 matches
Mail list logo
