21. 3. 15. 오후 3:45에 tiantao (H) 이(가) 쓴 글:
>
> 在 2021/3/15 14:35, Inki Dae 写道:
>> Hi Tian Tao,
>>
>> 21. 3. 2. 오후 12:03에 Tian Tao 이(가) 쓴 글:
>>> remove the legacy GPIO headers but what it really
>>> uses is since only gpio_desc structs are ever
>>> referenced.
>> This driver doesn't reference ev
Hi
Am 11.03.21 um 13:33 schrieb Paul Cercueil:
Le jeu. 11 mars 2021 à 12:28, Christoph Hellwig a
écrit :
On Sun, Mar 07, 2021 at 08:28:34PM +, Paul Cercueil wrote:
+ drm_atomic_for_each_plane_damage(&iter, &clip) {
+ for (i = 0; i < finfo->num_planes; i++) {
+ d
Hi
Am 13.03.21 um 19:29 schrieb Thomas Hellström (Intel):
Hi, Christian
On 3/12/21 10:38 AM, Christian König wrote:
We seem to have some more driver bugs than thought.
Signed-off-by: Christian König
---
include/drm/ttm/ttm_bo_api.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(
Hi Christoph,
On 3/14/21 4:58 PM, Christoph Hellwig wrote:
> On Sun, Mar 14, 2021 at 11:44:52AM +0100, Auger Eric wrote:
>> As mentionned by Robin, there are series planning to use
>> DOMAIN_ATTR_NESTING to get info about the nested caps of the iommu (ARM
>> and Intel):
>>
>> [Patch v8 00/10] vfio
在 2021/3/15 14:35, Inki Dae 写道:
Hi Tian Tao,
21. 3. 2. 오후 12:03에 Tian Tao 이(가) 쓴 글:
remove the legacy GPIO headers but what it really
uses is since only gpio_desc structs are ever
referenced.
This driver doesn't reference even linux/gpio/consumer.h so could you drop only
of_gpio.h inclusio
在 2021/3/15 14:35, Inki Dae 写道:
Hi Tian Tao,
21. 3. 2. 오후 12:03에 Tian Tao 이(가) 쓴 글:
remove the legacy GPIO headers but what it really
uses is since only gpio_desc structs are ever
referenced.
This driver doesn't reference even linux/gpio/consumer.h so could you drop only
of_gpio.h inclusio
Fix the following coccicheck warnings:
./drivers/gpu/drm/amd/display/dc/dcn30/dcn30_mpc.c:358:69-74: WARNING:
conversion to bool not needed here.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/gpu/drm/amd/display/dc/dcn30/dcn30_mpc.c | 2 +-
1 file changed, 1 insertion(+), 1
https://bugzilla.kernel.org/show_bug.cgi?id=212255
--- Comment #4 from Felice Tufo (i...@felicetufo.com) ---
I confirm that the fix solves the bug on kernel 5.12.0-rc3 (at least on my test
system).
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are wat
After this patch cbe16f35bee68 genirq: Add IRQF_NO_AUTOEN for
request_irq/nmi() is merged. request_irq() after setting
IRQ_NOAUTOEN as below
irq_set_status_flags(irq, IRQ_NOAUTOEN);
request_irq(dev, irq...);
can be replaced by request_irq() with IRQF_NO_AUTOEN flag.
Signed-off-by: Tian Tao
---
Am 13.03.21 um 19:29 schrieb Thomas Hellström (Intel):
Hi, Christian
On 3/12/21 10:38 AM, Christian König wrote:
We seem to have some more driver bugs than thought.
Signed-off-by: Christian König
---
include/drm/ttm/ttm_bo_api.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
https://bugzilla.kernel.org/show_bug.cgi?id=203905
--- Comment #25 from m11.1l1@gmail.com ---
I found another workaround and it's easier than EVER and it's done via
mkinitcpio😁
First, what's mkinitcpio(https://wiki.archlinux.org/index.php/Mkinitcpio)?
The initial ramdisk is in essence a v
After this patch cbe16f35bee68 genirq: Add IRQF_NO_AUTOEN for
request_irq/nmi() is merged. request_irq() after setting
IRQ_NOAUTOEN as below
irq_set_status_flags(irq, IRQ_NOAUTOEN);
request_irq(dev, irq...);
can be replaced by request_irq() with IRQF_NO_AUTOEN flag.
v2:
Fix the problem of using w
Hi Thomas,
Le lun. 15 mars 2021 à 8:43, Thomas Zimmermann a
écrit :
Hi
Am 11.03.21 um 13:33 schrieb Paul Cercueil:
Le jeu. 11 mars 2021 à 12:28, Christoph Hellwig
a écrit :
On Sun, Mar 07, 2021 at 08:28:34PM +, Paul Cercueil wrote:
+drm_atomic_for_each_plane_damage(&iter, &cl
After this patch cbe16f35bee68 genirq: Add IRQF_NO_AUTOEN for
request_irq/nmi() is merged. request_irq() after setting
IRQ_NOAUTOEN as below
irq_set_status_flags(irq, IRQ_NOAUTOEN);
request_irq(dev, irq...);
can be replaced by request_irq() with IRQF_NO_AUTOEN flag.
v2:
Fix the problem of using w
On Sun, Mar 14, 2021 at 11:11:10AM +0100, Marijn Suijten wrote:
> From: Obeida Shamoun
>
> WLED3_SINK_REG_SYNC is, as the name implies, a sink register offset.
> Therefore, use the sink address as base instead of the ctrl address.
>
> This fixes the sync toggle on wled4, which can be observed by
The retrieval of driver data can be a bit simplified by using
device_get_match_data(), so switch to it.
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/imx/dcss/dcss-dev.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/imx/dcss/dcss-dev.c
b/drivers/
From: Greg Kroah-Hartman
From: Tong Zhang
commit 874a52f9b693ed8bf7a92b3592a547ce8a684e6f upstream.
drm_fbdev_cleanup() can be called when fb_helper->buffer is null, hence
fb_helper->buffer should be checked before calling
drm_client_buffer_vunmap(). This buffer is also checked in
drm_client_f
On Thu, 11 Mar 2021, Ville Syrjälä wrote:
> On Wed, Mar 10, 2021 at 04:47:56PM -0500, Sean Paul wrote:
>> From: Sean Paul
>>
>> This patch adds some newlines which are missing from debug messages.
>> This will prevent logs from being stacked up in dmesg.
>>
>> Signed-off-by: Sean Paul
>> ---
>
These three patches exist to clean up some of our IOCTL mess in i915.
We've got more clean-up we should do eventually, but these are some of the
easiest to drop and most egregious cases.
Test-with: 20210121083742.46592-1-ashutosh.di...@intel.com
Ashutosh Dixit (1):
drm/i915: Disable pread/pwrit
libdrm has supported the newer execbuffer2 ioctl and using it by default
when it exists since libdrm commit b50964027bef which landed Mar 2, 2010.
The i915 and i965 drivers in Mesa at the time both used libdrm and so
did the Intel X11 back-end. The SNA back-end for X11 has always used
execbuffer2.
The Vulkan driver in Mesa for Intel hardware never uses relocations if
it's running on a version of i915 that supports at least softpin which
all versions of i915 supporting Gen12 do. On the OpenGL side, Gen12+ is
only supported by iris which never uses relocations. The older i965
driver in Mesa
From: Ashutosh Dixit
The rationale for this change is roughly as follows:
1. The functionality can be done entirely in userspace with a
combination of mmap + memcpy
2. The only reason anyone in userspace is still using it is because
someone implemented bo_subdata that way in libdrm ag
ioremap_cache is not supported on some architecture
such as s390. Put the codes into a #ifdef to fix
some compile error reported by test robot.
Signed-off-by: Oak Zeng
Reported-by: Kernel test robot
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-
Instead evict round robin from each devices SYSTEM and TT domain.
v2: reorder num_pages access reported by Dan's script
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c| 33 ++--
drivers/gpu/drm/ttm/ttm_bo_util.c | 1 -
drivers/gpu/drm/ttm/ttm_device.c|
Instead of having a global lock.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 8 ++---
drivers/gpu/drm/qxl/qxl_release.c | 5 +--
drivers/gpu/drm/ttm/ttm_bo.c | 49 --
drivers/gpu/drm/ttm/ttm_device.c | 12 +++
dri
Move the iteration of the global lru into the new function
ttm_global_swapout() and use that instead in drivers.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c| 57 -
drivers/gpu/drm/ttm/ttm_device.c| 29 +++
drivers/gpu/drm/tt
Hi,
On Sat, Mar 13, 2021 at 1:13 PM Laurent Pinchart
wrote:
>
> Hi Douglas,
>
> Thank you for the patch.
>
> On Thu, Mar 04, 2021 at 03:52:00PM -0800, Douglas Anderson wrote:
> > This patch is _only_ code motion to prepare for the patch
> > ("drm/bridge: ti-sn65dsi86: Properly get the EDID, but o
Hi,
On Sat, Mar 13, 2021 at 1:17 PM Laurent Pinchart
wrote:
>
> Hi Doug,
>
> Thank you for the patch.
>
> On Thu, Mar 04, 2021 at 03:52:01PM -0800, Douglas Anderson wrote:
> > In commit 58074b08c04a ("drm/bridge: ti-sn65dsi86: Read EDID blob over
> > DDC") we attempted to make the ti-sn65dsi86 br
Hi Doug,
On Mon, Mar 15, 2021 at 09:31:41AM -0700, Doug Anderson wrote:
> On Sat, Mar 13, 2021 at 1:13 PM Laurent Pinchart wrote:
> > On Thu, Mar 04, 2021 at 03:52:00PM -0800, Douglas Anderson wrote:
> > > This patch is _only_ code motion to prepare for the patch
> > > ("drm/bridge: ti-sn65dsi86:
https://bugzilla.kernel.org/show_bug.cgi?id=212293
Bug ID: 212293
Summary: [amdgpu] divide error: on resume from S3
Product: Drivers
Version: 2.5
Kernel Version: 5.11.6
Hardware: x86-64
OS: Linux
Tree: Ma
https://bugzilla.kernel.org/show_bug.cgi?id=212293
--- Comment #1 from Sefa Eyeoglu (cont...@scrumplex.net) ---
ADDITIONAL SYSTEM INFO
OS: Arch Linux (with testing repos)
Kernels with this issue: 5.11.6.arch1, 5.11.6.zen1, 5.12rc2 (built from Arch
Linux User Repository)
Kernels without this issue
On 3/15/21 11:26 AM, Christian König wrote:
Am 13.03.21 um 19:29 schrieb Thomas Hellström (Intel):
Hi, Christian
On 3/12/21 10:38 AM, Christian König wrote:
We seem to have some more driver bugs than thought.
Signed-off-by: Christian König
---
include/drm/ttm/ttm_bo_api.h | 6 --
1
On 3/15/21 8:48 AM, Thomas Zimmermann wrote:
Hi
Am 13.03.21 um 19:29 schrieb Thomas Hellström (Intel):
Hi, Christian
On 3/12/21 10:38 AM, Christian König wrote:
We seem to have some more driver bugs than thought.
Signed-off-by: Christian König
---
include/drm/ttm/ttm_bo_api.h | 6 --
https://bugzilla.kernel.org/show_bug.cgi?id=212293
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
On 12/03/2021 15:46, Tvrtko Ursulin wrote:
From: Chris Wilson
Currently, we cancel outstanding requests within a context when the
context is closed. We may also want to cancel individual requests using
the same graceful preemption mechanism.
v2 (Tvrtko):
* Cancel waiters carefully consider
On 3/12/21 5:06 AM, Thomas Hellström (Intel) wrote:
On 3/12/21 12:02 AM, Zack Rusin wrote:
On Mar 11, 2021, at 17:35, Thomas Hellström (Intel)
wrote:
Hi, Zack
On 3/11/21 10:07 PM, Zack Rusin wrote:
On Mar 11, 2021, at 05:46, Thomas Hellström (Intel)
wrote:
Hi,
I tried latest drm-fixe
https://bugzilla.kernel.org/show_bug.cgi?id=212279
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
https://bugzilla.kernel.org/show_bug.cgi?id=212281
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
https://bugzilla.kernel.org/show_bug.cgi?id=212259
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
Applied. Thanks!
Alex
On Fri, Mar 12, 2021 at 5:08 AM Colin King wrote:
>
> From: Colin Ian King
>
> There is a spelling mistake in an assert message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c | 2 +-
> 1 file changed, 1 insertion(+
Applied. Thanks!
Alex
On Thu, Mar 11, 2021 at 11:34 AM Colin King wrote:
>
> From: Colin Ian King
>
> The variable result is being initialized with a value that is
> never read and it is being updated later with a new value. The
> initialization is redundant and can be removed.
>
> Addresses-
https://bugzilla.kernel.org/show_bug.cgi?id=212279
--- Comment #2 from Neil (ledu...@hotmail.com) ---
Created attachment 295873
--> https://bugzilla.kernel.org/attachment.cgi?id=295873&action=edit
edid-decode
Here is the edid file for my TV (works full rgb range with windows 10)
I will try to e
On Sun, Mar 14, 2021 at 11:22 PM Bhaskar Chowdhury
wrote:
>
>
> s/"an minimum"/"a minimum"/
> s/"an maxmum"/"a maximum"/
>
> Signed-off-by: Bhaskar Chowdhury
Applied. Thanks!
Alex
> ---
> Changes from V1:
> Randy's suggestion to adjust the subject line text
> And missed out a spell too,w
Applied. Thanks!
Alex
On Mon, Mar 15, 2021 at 4:22 AM Jiapeng Chong
wrote:
>
> Fix the following coccicheck warnings:
>
> ./drivers/gpu/drm/amd/display/dc/dcn30/dcn30_mpc.c:358:69-74: WARNING:
> conversion to bool not needed here.
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Chong
>
15.03.2021 01:31, Michał Mirosław пишет:
> On Thu, Mar 11, 2021 at 08:22:54PM +0300, Dmitry Osipenko wrote:
>> Display controller (DC) performs isochronous memory transfers, and thus,
>> has a requirement for a minimum memory bandwidth that shall be fulfilled,
>> otherwise framebuffer data can't be
Am 15.03.21 um 18:08 schrieb Thomas Hellström (Intel):
On 3/15/21 11:26 AM, Christian König wrote:
Am 13.03.21 um 19:29 schrieb Thomas Hellström (Intel):
Hi, Christian
On 3/12/21 10:38 AM, Christian König wrote:
We seem to have some more driver bugs than thought.
Signed-off-by: Christia
To all X.Org Foundation Members:
The election for the X.Org Foundation Board of Directors will begin on
22 March 2021. We have 6 candidates who are running for 4 seats. They
are (in alphabetical order):
Samuel Iglesias Gonsálvez
Manasi Navare
Lyude Paul
Rodrigo Siqueira
Lu
Hi "Christian,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next linus/master drm/drm-next v5.12-rc3 next-20210315]
[If your patch is applied t
On Mon, 15 Mar 2021 at 16:04, Christian König
wrote:
>
> Instead evict round robin from each devices SYSTEM and TT domain.
>
> v2: reorder num_pages access reported by Dan's script
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/ttm/ttm_bo.c| 33 ++--
> drivers/gpu
Hi "Christian,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next linus/master drm/drm-next v5.12-rc3 next-20210315]
[If your patch is applied t
On 3/15/21 7:47 PM, Christian König wrote:
Am 15.03.21 um 18:08 schrieb Thomas Hellström (Intel):
On 3/15/21 11:26 AM, Christian König wrote:
Am 13.03.21 um 19:29 schrieb Thomas Hellström (Intel):
Hi, Christian
On 3/12/21 10:38 AM, Christian König wrote:
We seem to have some more drive
tree: git://anongit.freedesktop.org/drm-intel topic/core-for-CI
head: 785b066b32b630e4735ca6e51acbb067703e2d3a
commit: 98a674f9cd22c2cf6f507ccc1f26fae3c91d1271 [20/30] Revert "drm/i915:
Don't select BROKEN"
config: alpha-randconfig-r033-20210315 (attached as .config)
compiler:
Just another leftover from a TTM cleanup.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index ca2a8ae1938e..9bb
Remove the unused evict parameter and drop swapping bo->mem.
Signed-off-by: Christian König
---
drivers/gpu/drm/qxl/qxl_ttm.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index b7f77eb685cb..47
Instead of swapping bo->mem just give old and new as parameters.
Also drop unused parameters and code.
v2: cleanup stale documentation as well.
Signed-off-by: Christian König
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 3 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 9 +---
driv
Am 15.03.21 um 19:54 schrieb Matthew Auld:
On Mon, 15 Mar 2021 at 16:04, Christian König
wrote:
[SNIP]
@@ -1193,6 +1164,10 @@ int ttm_bo_swapout(struct ttm_buffer_object *bo, struct
ttm_operation_ctx *ctx,
bool locked;
int ret;
+ if (!bo->ttm || bo->ttm->page_flags & (
Hi Noralf,
super fair call with the BE testing, let's hope for some testing soonish.
I was thinking about my device doing protocol STALL when I try to
return 0 bytes, and while it *is* a bug in my device, from a standards
point of view it's actually completely valid, if not expected:
--8<-- usb
Hi "Christian,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next linus/master drm/drm-next v5.12-rc3 next-20210315]
[If your patch is applied t
On Mon, Mar 15, 2021 at 6:57 PM Zack Rusin wrote:
>
> On 3/12/21 5:06 AM, Thomas Hellström (Intel) wrote:
> >
> > On 3/12/21 12:02 AM, Zack Rusin wrote:
> >>
> >>> On Mar 11, 2021, at 17:35, Thomas Hellström (Intel)
> >>> wrote:
> >>>
> >>> Hi, Zack
> >>>
> >>> On 3/11/21 10:07 PM, Zack Rusin wro
Modern userspace APIs like Vulkan are built on an explicit
synchronization model. This doesn't always play nicely with the
implicit synchronization used in the kernel and assumed by X11 and
Wayland. The client -> compositor half of the synchronization isn't too
bad, at least on intel, because we
From: Christian König
Add a helper to iterate over all fences in a dma_fence_array object.
v2 (Jason Ekstrand)
- Return NULL from dma_fence_array_first if head == NULL. This matches
the iterator behavior of dma_fence_chain_for_each in that it iterates
zero times if head == NULL.
- Retur
From: Christian König
Add a helper function to get a single fence representing
all fences in a dma_resv object.
This fence is either the only one in the object or all not
signaled fences of the object in a flatted out dma_fence_array.
v2 (Jason Ekstrand):
- Take reference of fences both for cr
Modern userspace APIs like Vulkan are built on an explicit
synchronization model. This doesn't always play nicely with the
implicit synchronization used in the kernel and assumed by X11 and
Wayland. The client -> compositor half of the synchronization isn't too
bad, at least on intel, because we
https://bugzilla.kernel.org/show_bug.cgi?id=212279
--- Comment #3 from Neil (ledu...@hotmail.com) ---
Created attachment 295875
--> https://bugzilla.kernel.org/attachment.cgi?id=295875&action=edit
edited edid with wxedid
Got it!
I failed at editing the file first because it was a 0 byte file (d
On Wed, Sep 30, 2020 at 4:55 AM Daniel Vetter wrote:
>
> On Wed, Sep 30, 2020 at 11:39:06AM +0200, Michel Dänzer wrote:
> > On 2020-03-17 10:21 p.m., Jason Ekstrand wrote:
> > > Explicit synchronization is the future. At least, that seems to be what
> > > most userspace APIs are agreeing on at th
On Mon, Mar 15, 2021 at 10:11 PM Jason Ekstrand wrote:
>
> On Wed, Sep 30, 2020 at 4:55 AM Daniel Vetter wrote:
> >
> > On Wed, Sep 30, 2020 at 11:39:06AM +0200, Michel Dänzer wrote:
> > > On 2020-03-17 10:21 p.m., Jason Ekstrand wrote:
> > > > Explicit synchronization is the future. At least, t
On 3/15/21 9:38 PM, Daniel Vetter wrote:
On Mon, Mar 15, 2021 at 6:57 PM Zack Rusin wrote:
On 3/12/21 5:06 AM, Thomas Hellström (Intel) wrote:
On 3/12/21 12:02 AM, Zack Rusin wrote:
On Mar 11, 2021, at 17:35, Thomas Hellström (Intel)
wrote:
Hi, Zack
On 3/11/21 10:07 PM, Zack Rusin wrote:
On Mon, Mar 15, 2021 at 4:05 PM Jason Ekstrand wrote:
>
> Modern userspace APIs like Vulkan are built on an explicit
> synchronization model. This doesn't always play nicely with the
> implicit synchronization used in the kernel and assumed by X11 and
> Wayland. The client -> compositor half of
Hi Jason,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on tegra-drm/drm/tegra/for-next]
[also build test ERROR on linus/master v5.12-rc3 next-20210315]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to
I-G-T tests:
https://lists.freedesktop.org/archives/igt-dev/2021-March/029825.html
On Mon, Mar 15, 2021 at 4:04 PM Jason Ekstrand wrote:
>
> Modern userspace APIs like Vulkan are built on an explicit
> synchronization model. This doesn't always play nicely with the
> implicit synchronization us
The following changes since commit 4042160c2e5433e0759782c402292a90b5bf458d:
drm/nouveau: fix dma syncing for loops (v2) (2021-03-12 11:21:47 +1000)
are available in the Git repository at:
git://linuxtv.org/pinchartl/media.git tags/du-fixes-20210316
for you to fetch changes up to 7a1adbd239
Hi Jason,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on tegra-drm/drm/tegra/for-next]
[also build test ERROR on linus/master v5.12-rc3 next-20210315]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to
On Fri, Mar 12, 2021 at 10:55:21AM +, Brian Starkey wrote:
> (Adding back James again - did you use get_maintainer.pl?)
>
> On Thu, Mar 11, 2021 at 12:08:46PM +, carsten.haitz...@foss.arm.com wrote:
> > From: Carsten Haitzler
> >
> > When setting up a readback connector that writes data
From: Christian König
Add a helper to iterate over all fences in a dma_fence_array object.
v2 (Jason Ekstrand)
- Return NULL from dma_fence_array_first if head == NULL. This matches
the iterator behavior of dma_fence_chain_for_each in that it iterates
zero times if head == NULL.
- Retur
Modern userspace APIs like Vulkan are built on an explicit
synchronization model. This doesn't always play nicely with the
implicit synchronization used in the kernel and assumed by X11 and
Wayland. The client -> compositor half of the synchronization isn't too
bad, at least on intel, because we
Modern userspace APIs like Vulkan are built on an explicit
synchronization model. This doesn't always play nicely with the
implicit synchronization used in the kernel and assumed by X11 and
Wayland. The client -> compositor half of the synchronization isn't too
bad, at least on intel, because we
Add a helper function to get a single fence representing
all fences in a dma_resv object.
This fence is either the only one in the object or all not
signaled fences of the object in a flatted out dma_fence_array.
v2 (Jason Ekstrand):
- Take reference of fences both for creating the dma_fence_arr
On Mon, 15 Mar 2021 07:34:25 -0700, Jason Ekstrand wrote:
>
> These three patches exist to clean up some of our IOCTL mess in i915.
> We've got more clean-up we should do eventually, but these are some of the
> easiest to drop and most egregious cases.
>
> Test-with: 20210121083742.46592-1-ashutosh
78 matches
Mail list logo
