On Wed, May 05, 2021 at 06:24:07PM +0200, Hans de Goede wrote:
> Hi All,
>
> Here is v3 of my patchset making DP over Type-C work on devices where the
> Type-C controller does not drive the HPD pin on the GPU, but instead
> we need to forward HPD events from the Type-C controller to the DRM driver
On Mon, May 10, 2021 at 08:12:31PM +0200, Christian König wrote:
> Am 04.05.21 um 17:11 schrieb Daniel Vetter:
> > On Tue, May 04, 2021 at 04:26:42PM +0200, Christian König wrote:
> > > Hi Daniel,
> > >
> > > Am 04.05.21 um 16:15 schrieb Daniel Vetter:
> > > > Hi Christian,
> > > >
> > > > On Tue
Am 11.05.21 um 08:05 schrieb Christoph Hellwig:
Use the dma_alloc_pages allocator for the TTM pool allocator.
This allocator is a front end to the page allocator which takes the
DMA mask of the device into account, thus offering the best of both
worlds of the two existing allocator versions. Thi
On 11/05/2021 05:58, Dixit, Ashutosh wrote:
On Sun, 09 May 2021 16:11:43 -0700, Jason Ekstrand wrote:
Yes, landing GuC support may be the first step in removing execlist
support. The inevitable reality is that GPU scheduling is coming and
likely to be there only path in the not-too-distant f
Am 11.05.21 um 09:31 schrieb Daniel Vetter:
[SNIP]
And that's just the one ioctl I know is big trouble, I'm sure we'll find
more funny corner cases when we roll out explicit user fencing.
I think we can just ignore sync_file. As far as it concerns me that UAPI is
pretty much dead.
Uh that's ra
On 10/05/2021 19:25, Jason Ekstrand wrote:
On May 10, 2021 08:55:55 Martin Peres wrote:
On 10/05/2021 02:11, Jason Ekstrand wrote:
On May 9, 2021 12:12:36 Martin Peres wrote:
Hi,
On 06/05/2021 22:13, Matthew Brost wrote:
Basic GuC submission support. This is the first bullet point in the
On 10/05/2021 19:33, Daniel Vetter wrote:
On Mon, May 10, 2021 at 3:55 PM Martin Peres wrote:
On 10/05/2021 02:11, Jason Ekstrand wrote:
On May 9, 2021 12:12:36 Martin Peres wrote:
Hi,
On 06/05/2021 22:13, Matthew Brost wrote:
Basic GuC submission support. This is the first bullet point
On Mon, 10 May 2021 17:47:01 -0400
Alex Deucher wrote:
> On Fri, May 7, 2021 at 3:27 PM Werner Sembach
> wrote:
> >
> > xrandr --prop and other userspace info tools have currently no way of
> > telling which color configuration is used on HDMI and DP ports.
> >
> > The ongoing transsition from
When the 'nb' value allocated from 'bl_ida' is greater than or equal to
100, it will not be released. In fact, we can simplify operations by
limiting the range of idas that can be applied for.
By the way, delete the const modifier of the local variable 'nb'.
Fixes: db1a0ae21461 ("drm/nouveau/bl:
v1 --> v2:
1. Add Patch 1 to fix ida leak
2. Modifies nouveau_get_backlight_name() to propagate the actual error code
Zhen Lei (2):
drm/nouveau: Fix ida leak
drm/nouveau: Fix error return code in nouveau_backlight_init()
drivers/gpu/drm/nouveau/nouveau_backlight.c | 14 --
1 file
Fix to return a negative error code from the error handling case instead
of 0, as done elsewhere in this function.
Fixes: db1a0ae21461 ("drm/nouveau/bl: Assign different names to interfaces")
Suggested-by: Pierre Moreau
Signed-off-by: Zhen Lei
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 9
kernel.h is being used as a dump for all kinds of stuff for a long time.
Here is the attempt to start cleaning it up by splitting out panic and
oops helpers.
There are several purposes of doing this:
- dropping dependency in bug.h
- dropping a loop by moving out panic_notifier.h
- unload kernel.h
We have established previously we stop using relocations starting
from gen12 platforms with Tigerlake as an exception. Unfortunately
we need extend transition period and support relocations for two
other igfx platforms - Rocketlake and Alderlake.
Signed-off-by: Zbigniew Kempczyński
Cc: Dave Airli
This feature enables the Guest to wait until a flush has been
performed on a buffer it has submitted to the Host.
Cc: Gerd Hoffmann
Signed-off-by: Vivek Kasireddy
---
include/uapi/linux/virtio_gpu.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/uapi/linux/virtio_gpu.
This implements the hypercall interface for the wait_flush
command.
Cc: Gerd Hoffmann
Signed-off-by: Vivek Kasireddy
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 4
drivers/gpu/drm/virtio/virtgpu_vq.c | 17 +
2 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/v
If this feature is available, a fence will be associated with the
scanout buffer and a dma_fence_wait will be performed as part of
plane update.
Cc: Gerd Hoffmann
Signed-off-by: Vivek Kasireddy
---
drivers/gpu/drm/virtio/virtgpu_debugfs.c | 1 +
drivers/gpu/drm/virtio/virtgpu_drv.c | 1 +
Am 11.05.21 um 10:50 schrieb Christoph Hellwig:
On Tue, May 11, 2021 at 09:35:20AM +0200, Christian König wrote:
We certainly going to need the drm_need_swiotlb() for userptr support
(unless we add some approach for drivers to opt out of swiotlb).
swiotlb use is driven by three things:
1) ad
Em Mon, 10 May 2021 15:33:47 +0100
Edward Cree escreveu:
> On 10/05/2021 14:59, Matthew Wilcox wrote:
> > Most of these
> > UTF-8 characters come from latex conversions and really aren't
> > necessary (and are being used incorrectly).
> I fully agree with fixing those.
> The cover-letter, howev
When devm_ioremap_resource() fails, a clear enough error message will be
printed by its subfunction __devm_ioremap_resource(). The error
information contains the device name, failure cause, and possibly resource
information.
Therefore, remove the error printing here to simplify code and reduce the
On 10/05/2021 16:55, Daniel Vetter wrote:
On Fri, May 07, 2021 at 09:35:21AM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
This is an alternative proposed fix for the below references bug report
where dma fence error propagation is causing undesirable change in
behaviour post GPU hang/re
When devm_ioremap_resource() fails, a clear enough error message will be
printed by its subfunction __devm_ioremap_resource(). The error
information contains the device name, failure cause, and possibly resource
information.
Therefore, remove the error printing here to simplify code and reduce the
On Tue, 2021-05-11 at 11:00 +0200, Mauro Carvalho Chehab wrote:
> Yet, this series has two positive side effects:
>
> - it helps people needing to touch the documents using non-utf8 locales[1];
> - it makes easier to grep for a text;
>
> [1] There are still some widely used distros nowadays (LT
Em Mon, 10 May 2021 14:49:44 +0100
David Woodhouse escreveu:
> On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote:
> > This patch series is doing conversion only when using ASCII makes
> > more sense than using UTF-8.
> >
> > See, a number of converted documents ended with weird cha
When devm_ioremap_resource() fails, a clear enough error message will be
printed by its subfunction __devm_ioremap_resource(). The error
information contains the device name, failure cause, and possibly resource
information.
Therefore, remove the error printing here to simplify code and reduce the
Em Mon, 10 May 2021 15:22:02 -0400
"Theodore Ts'o" escreveu:
> On Mon, May 10, 2021 at 02:49:44PM +0100, David Woodhouse wrote:
> > On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote:
> > > This patch series is doing conversion only when using ASCII makes
> > > more sense than using
When devm_ioremap_resource() fails, a clear enough error message will be
printed by its subfunction __devm_ioremap_resource(). The error
information contains the device name, failure cause, and possibly resource
information.
Therefore, remove the error printing here to simplify code and reduce the
When devm_ioremap_resource() fails, a clear enough error message will be
printed by its subfunction __devm_ioremap_resource(). The error
information contains the device name, failure cause, and possibly resource
information.
Therefore, remove the error printing here to simplify code and reduce the
When devm_ioremap_resource() fails, a clear enough error message will be
printed by its subfunction __devm_ioremap_resource(). The error
information contains the device name, failure cause, and possibly resource
information.
Therefore, remove the error printing here to simplify code and reduce the
Am 11.05.21 um 10:07 schrieb Pekka Paalanen:
> On Mon, 10 May 2021 17:47:01 -0400
> Alex Deucher wrote:
>
>> On Fri, May 7, 2021 at 3:27 PM Werner Sembach
>> wrote:
>>> xrandr --prop and other userspace info tools have currently no way of
>>> telling which color configuration is used on HDMI and
https://bugzilla.kernel.org/show_bug.cgi?id=51381
--- Comment #60 from Luca T. (luca.trom...@gmail.com) ---
(In reply to luminoso from comment #57)
> For users still facing this issue, I workaround it with this:
> https://github.com/aelveborn/vgaswitcheroo-systemd
>
> Basically before suspending
On Tue, May 11, 2021 at 01:36:08AM -0700, Vivek Kasireddy wrote:
> This feature enables the Guest to wait until a flush has been
> performed on a buffer it has submitted to the Host.
This needs a virtio-spec update documenting the new feature.
> + VIRTIO_GPU_CMD_WAIT_FLUSH,
Why a new command
> --- a/include/uapi/linux/virtio_gpu.h
> +++ b/include/uapi/linux/virtio_gpu.h
> @@ -420,6 +420,7 @@ struct virtio_gpu_set_scanout_blob {
> __le32 padding;
> __le32 strides[4];
> __le32 offsets[4];
> + __le64 modifier;
> };
All protocol changes (uapi/linux/virtio_gpu.h upda
Gerd Hoffmann (2):
drm/qxl: drop redundant code
drm/qxl: balance dumb_shadow_bo pin
drivers/gpu/drm/qxl/qxl_display.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--
2.31.1
Not needed, qxl_io_destroy_primary() does that for us.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index a7637e79cb42..be5183733c1b
The shadow bo is created in pinned state, so we have to unpin it when
dropping the reference. Otherwise ttm is unhappy and throws a WARN()
on release.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/qxl/qxl_d
On Mon, May 10, 2021 at 9:08 PM Stephen Boyd wrote:
[cut]
>
> >
> > > I will try it, but then I wonder about things like system wide
> > > suspend/resume too. The drm encoder chain would need to reimplement the
> > > logic for system wide suspend/resume so that any PM ops attached to the
> > > m
On Tue, 11 May 2021 12:03:30 +0200
Werner Sembach wrote:
> Am 11.05.21 um 10:07 schrieb Pekka Paalanen:
> > On Mon, 10 May 2021 17:47:01 -0400
> > Alex Deucher wrote:
> >
> >> On Fri, May 7, 2021 at 3:27 PM Werner Sembach
> >> wrote:
> >>> xrandr --prop and other userspace info tools have
When devm_ioremap_resource() fails, a clear enough error message will be
printed by its subfunction __devm_ioremap_resource(). The error
information contains the device name, failure cause, and possibly resource
information.
Therefore, remove the error printing here to simplify code and reduce the
When devm_ioremap_resource() fails, a clear enough error message will be
printed by its subfunction __devm_ioremap_resource(). The error
information contains the device name, failure cause, and possibly resource
information.
Therefore, remove the error printing here to simplify code and reduce the
When devm_ioremap_resource() fails, a clear enough error message will be
printed by its subfunction __devm_ioremap_resource(). The error
information contains the device name, failure cause, and possibly resource
information.
Therefore, remove the error printing here to simplify code and reduce the
When devm_ioremap_resource() fails, a clear enough error message will be
printed by its subfunction __devm_ioremap_resource(). The error
information contains the device name, failure cause, and possibly resource
information.
Therefore, remove the error printing here to simplify code and reduce the
When devm_ioremap_resource() fails, a clear enough error message will be
printed by its subfunction __devm_ioremap_resource(). The error
information contains the device name, failure cause, and possibly resource
information.
Therefore, remove the error printing here to simplify code and reduce the
On 2021/5/11 21:13, Baruch Siach wrote:
> Hi Zhen Lei,
>
> On Tue, May 11 2021, Zhen Lei wrote:
>> When devm_ioremap_resource() fails, a clear enough error message will be
>> printed by its subfunction __devm_ioremap_resource(). The error
>> information contains the device name, failure cause,
Hi everybody,
Please ignore this patch and other "drm/mediatek". Looks like it would be
better to combine them into a single patch.
On 2021/5/11 18:00, Zhen Lei wrote:
> When devm_ioremap_resource() fails, a clear enough error message will be
> printed by its subfunction __devm_ioremap_resou
[AMD Public Use]
Typo in the subject: devie > device
Alex
From: Grodzovsky, Andrey
Sent: Monday, May 10, 2021 12:36 PM
To: dri-devel@lists.freedesktop.org ;
amd-...@lists.freedesktop.org ;
linux-...@vger.kernel.org ;
ckoenig.leichtzumer...@gmail.com ;
daniel.
This is an initial patch series to move discrete memory management over to
TTM. It will be followed up shortly with adding more functionality.
The buddy allocator is temporarily removed along with its selftests and
It is replaced with the TTM range manager and some selftests are adjusted
to accoun
We are currently sharing the VM reservation locks across a number of
gem objects with page-table memory. Since TTM will individiualize the
reservation locks when freeing objects, including accessing the shared
locks, make sure that the shared locks are not freed until that is done.
For PPGTT we add
From: Thomas Hellström
Any sleeping dma_resv lock taken while the vma pages_mutex is held
will cause a lockdep splat.
Move the i915_gem_object_pin_pages() call out of the pages_mutex
critical section.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/i915_vma.c | 33 +++-
Embed a struct ttm_buffer_object into the i915 gem object, making sure
we alias the gem object part. It's a bit unfortunate that the
struct ttm_buffer_ojbect embeds a gem object since we otherwise could
make the TTM part private to the TTM backend, and use the usual
i915 gem object for the other ba
Temporarily remove the buddy allocator and related selftests
and hook up the TTM range manager for i915 regions.
In order to support some of the mock region-related selftests, we need to
be able to initialize the TTM range-manager standalone without a struct
ttm_device. Add two functions to allow
The internal ttm_bo_util memcpy uses vmap functionality, and while it
probably might be possible to use it for copying in- and out of
sglist represented io memory, using io_mem_reserve() / io_mem_free()
callbacks, that would cause problems with fault().
Instead, implement a method mapping page-by-p
Most logical place to introduce TTM buffer objects is as an i915
gem object backend. We need to add some ops to account for added
functionality like delayed delete and LRU list manipulation.
Initially we support only LMEM and SYSTEM memory, but SYSTEM
(which in this case means evicted LMEM objects
Since objects can be migrated or evicted when not pinned or locked,
update the checks for lmem residency or future residency so that
the value returned is not immediately stale.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
drivers/gpu/drm/i915/gem/i91
On Tue, May 11, 2021 at 12:52 PM Rafael J. Wysocki wrote:
>
> On Mon, May 10, 2021 at 9:08 PM Stephen Boyd wrote:
>
> [cut]
>
> >
> > >
> > > > I will try it, but then I wonder about things like system wide
> > > > suspend/resume too. The drm encoder chain would need to reimplement the
> > > > lo
v1 --> v2:
1. Combine the modifications of several drm/mediatek files into one patch.
2. According to Baruch Siach's review comment, simplify the following code
snippets:
-ret = PTR_ERR(cec->regs);
-return ret;
+return PTR_ERR(cec->regs);
Zhen Lei (1):
When devm_ioremap_resource() fails, a clear enough error message will be
printed by its subfunction __devm_ioremap_resource(). The error
information contains the device name, failure cause, and possibly resource
information.
Therefore, remove the error printing here to simplify code and reduce the
Am 11.05.21 um 12:45 schrieb Gerd Hoffmann:
Gerd Hoffmann (2):
drm/qxl: drop redundant code
drm/qxl: balance dumb_shadow_bo pin
drivers/gpu/drm/qxl/qxl_display.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Acked-by: Thomas Zimmermann
--
Thomas Zimmermann
Graphics
Am 11.05.21 um 15:25 schrieb Thomas Hellström:
Most logical place to introduce TTM buffer objects is as an i915
gem object backend. We need to add some ops to account for added
functionality like delayed delete and LRU list manipulation.
Initially we support only LMEM and SYSTEM memory, but SYST
On 5/11/21 3:58 PM, Christian König wrote:
Am 11.05.21 um 15:25 schrieb Thomas Hellström:
Most logical place to introduce TTM buffer objects is as an i915
gem object backend. We need to add some ops to account for added
functionality like delayed delete and LRU list manipulation.
Initially we
In order to simplify DP code, drop hand-coded loops over clock arrays,
replacing them with clk_bulk_* functions.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/Makefile | 1 -
drivers/gpu/drm/msm/dp/dp_clk_util.c | 120 ---
drivers/gpu/drm/msm/dp/dp_clk
msm_dss_clk_*() functions significantly duplicate clk_bulk_* family of
functions. Drop custom code and use bulk clocks directly.
Dmitry Baryshkov (2):
drm/msm/dpu: simplify clocks handling
drm/msm/dp: rewrite dss_module_p
DPU driver contains code to parse clock items from device tree into
special data struct and then enable/disable/set rate for the clocks
using that data struct. However the DPU driver itself uses only parsing
and enabling/disabling part (the rate setting is used by DP driver).
Move this implementat
Am 11.05.21 um 16:06 schrieb Thomas Hellström (Intel):
On 5/11/21 3:58 PM, Christian König wrote:
Am 11.05.21 um 15:25 schrieb Thomas Hellström:
Most logical place to introduce TTM buffer objects is as an i915
gem object backend. We need to add some ops to account for added
functionality li
dpu_core_irq_en/disable helpers are always called with the irq_count
equal to 1. Merge them with _dpu_core_en/disable functions and make them
handle just one interrupt index at a time.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c | 50
dri
Downstream driver uses dpu->caps->smart_dma_rev to update
sspp->cap->features with the bit corresponding to the supported SmartDMA
version. Upstream driver does not do this, resulting in SSPP subdriver
not enbaling setup_multirect callback. Make SSPP subdriver check global
smart_dma_rev to decide i
On Tue, May 11, 2021 at 09:47:56AM +0200, Christian König wrote:
> Am 11.05.21 um 09:31 schrieb Daniel Vetter:
> > [SNIP]
> > > > And that's just the one ioctl I know is big trouble, I'm sure we'll find
> > > > more funny corner cases when we roll out explicit user fencing.
> > > I think we can jus
On 5/11/21 4:09 PM, Christian König wrote:
Am 11.05.21 um 16:06 schrieb Thomas Hellström (Intel):
On 5/11/21 3:58 PM, Christian König wrote:
Am 11.05.21 um 15:25 schrieb Thomas Hellström:
Most logical place to introduce TTM buffer objects is as an i915
gem object backend. We need to add s
On Mon, May 10, 2021 at 03:33:46PM +0200, Werner Sembach wrote:
> When encoder validation of a display mode fails, retry with less bandwidth
> heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups
> to support 4k60Hz output, which previously failed silently.
>
> AMDGPU had nea
On Thu, May 06, 2021 at 10:30:45AM -0700, Matthew Brost wrote:
> Add entry for i915 GuC submission / DRM scheduler integration plan.
> Follow up patch with details of new parallel submission uAPI to come.
>
> Cc: Jon Bloomfield
> Cc: Jason Ekstrand
> Cc: Dave Airlie
> Cc: Daniel Vetter
> Cc: J
On Tue, May 11, 2021 at 05:29:23PM +0800, Zhen Lei wrote:
> When devm_ioremap_resource() fails, a clear enough error message will be
> printed by its subfunction __devm_ioremap_resource(). The error
> information contains the device name, failure cause, and possibly resource
> information.
>
> The
On 5/11/21 2:41 AM, Andy Shevchenko wrote:
kernel.h is being used as a dump for all kinds of stuff for a long time.
Here is the attempt to start cleaning it up by splitting out panic and
oops helpers.
There are several purposes of doing this:
- dropping dependency in bug.h
- dropping a loop by m
On 2021-05-11 2:38 a.m., Christian König wrote:
Am 10.05.21 um 18:36 schrieb Andrey Grodzovsky:
On device removal reroute all CPU mappings to dummy page.
v3:
Remove loop to find DRM file and instead access it
by vma->vm_file->private_data. Move dummy page installation
into a separate function
On Thu, May 06, 2021 at 10:30:46AM -0700, Matthew Brost wrote:
> Add entry fpr i915 new parallel submission uAPI plan.
>
> Cc: Tvrtko Ursulin
> Cc: Tony Ye
> CC: Carl Zhang
> Cc: Daniel Vetter
> Cc: Jason Ekstrand
> Signed-off-by: Matthew Brost
> ---
> Documentation/gpu/rfc/i915_scheduler.r
On Sat, May 08, 2021 at 12:41:18AM -0700, Stephen Boyd wrote:
> Within the component device framework this usually isn't that bad
> because the real driver work is done at bind time via
> component{,master}_ops::bind(). It becomes a problem when the driver
> core, or host driver, wants to operate o
On 2021-05-11 2:40 a.m., Christian König wrote:
Am 10.05.21 um 18:36 schrieb Andrey Grodzovsky:
Helps to expdite HW related stuff to amdgpu_pci_remove
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 2 +-
On Thu, May 06, 2021 at 10:30:47AM -0700, Matthew Brost wrote:
> Expose logical engine instance to user via query engine info IOCTL. This
> is required for split-frame workloads as these need to be placed on
> engines in a logically contiguous order. The logical mapping can change
> based on fusing
Hi,
On Tue, 11 May 2021 at 15:34, Daniel Vetter wrote:
> On Thu, May 06, 2021 at 10:30:45AM -0700, Matthew Brost wrote:
> > +No major changes are required to the uAPI for basic GuC submission. The
> > only
> > +change is a new scheduler attribute:
> > I915_SCHEDULER_CAP_STATIC_PRIORITY_MAP.
> >
On Thu, May 06, 2021 at 10:30:48AM -0700, Matthew Brost wrote:
> i915_drm.h updates for 'set parallel submit' extension.
>
> Cc: Tvrtko Ursulin
> Cc: Tony Ye
> CC: Carl Zhang
> Cc: Daniel Vetter
> Cc: Jason Ekstrand
> Signed-off-by: Matthew Brost
> ---
> include/uapi/drm/i915_drm.h | 126 ++
Am 11.05.21 um 16:44 schrieb Andrey Grodzovsky:
On 2021-05-11 2:38 a.m., Christian König wrote:
Am 10.05.21 um 18:36 schrieb Andrey Grodzovsky:
On device removal reroute all CPU mappings to dummy page.
v3:
Remove loop to find DRM file and instead access it
by vma->vm_file->private_data. Mo
On Tue, May 11, 2021 at 03:58:43PM +0100, Daniel Stone wrote:
> Hi,
>
> On Tue, 11 May 2021 at 15:34, Daniel Vetter wrote:
> > On Thu, May 06, 2021 at 10:30:45AM -0700, Matthew Brost wrote:
> > > +No major changes are required to the uAPI for basic GuC submission. The
> > > only
> > > +change is
On Thu, May 06, 2021 at 10:30:49AM -0700, Matthew Brost wrote:
> Add I915_EXEC_NUMBER_BB_* to drm_i915_gem_execbuffer2.flags which allows
> submitting N BBs per IOCTL.
>
> Cc: Tvrtko Ursulin
> Cc: Tony Ye
> CC: Carl Zhang
> Cc: Daniel Vetter
> Cc: Jason Ekstrand
> Signed-off-by: Matthew Brost
On Thu, May 06, 2021 at 12:13:34PM -0700, Matthew Brost wrote:
> From: Michal Wajdeczko
>
> New GuC firmware will unify format of MMIO and CTB H2G messages.
> Introduce their definitions now to allow gradual transition of
> our code to match new changes.
>
> Signed-off-by: Michal Wajdeczko
> Si
On Thu, May 06, 2021 at 12:13:46PM -0700, Matthew Brost wrote:
> Introduce i915_sched_engine object which is lower level data structure
> that i915_scheduler / generic code can operate on without touching
> execlist specific structures. This allows additional submission backends
> to be added witho
On Thu, May 06, 2021 at 12:13:57PM -0700, Matthew Brost wrote:
> Add lrc descriptor context lookup array which can resolve the
> intel_context from the lrc descriptor index. In addition to lookup, it
> can determine in the lrc descriptor context is currently registered with
> the GuC by checking if
> -Original Message-
> From: Martin Peres
> Sent: Tuesday, May 11, 2021 1:06 AM
> To: Daniel Vetter
> Cc: Jason Ekstrand ; Brost, Matthew
> ; intel-gfx ;
> dri-devel ; Ursulin, Tvrtko
> ; Ekstrand, Jason ;
> Ceraolo Spurio, Daniele ; Bloomfield, Jon
> ; Vetter, Daniel ;
> Harrison, John C
Am 11.05.21 um 16:23 schrieb Daniel Vetter:
On Tue, May 11, 2021 at 09:47:56AM +0200, Christian König wrote:
Am 11.05.21 um 09:31 schrieb Daniel Vetter:
[SNIP]
And that's just the one ioctl I know is big trouble, I'm sure we'll find
more funny corner cases when we roll out explicit user fencin
On Thu, May 06, 2021 at 12:14:03PM -0700, Matthew Brost wrote:
> Disable engine barriers for unpinning with GuC. This feature isn't
> needed with the GuC as it disables context scheduling before unpinning
> which guarantees the HW will not reference the context. Hence it is
> not necessary to defer
On 2021-05-11 2:44 a.m., Christian König wrote:
Am 10.05.21 um 18:36 schrieb Andrey Grodzovsky:
Handle all DMA IOMMU gropup related dependencies before the
group is removed.
v5: Drop IOMMU notifier and switch to lockless call to ttm_tt_unpopulate
v6: Drop the BO unamp list
Signed-off-by: An
On Fri, May 7, 2021 at 7:45 PM Tejun Heo wrote:
>
> Hello,
>
> On Fri, May 07, 2021 at 06:30:56PM -0400, Alex Deucher wrote:
> > Maybe we are speaking past each other. I'm not following. We got
> > here because a device specific cgroup didn't make sense. With my
> > Linux user hat on, that make
New KMS properties come with a bunch of requirements to avoid each
driver from running their own, inconsistent, set of properties,
eventually leading to issues like property conflicts, inconsistencies
between drivers and semantics, etc.
Let's document what we expect.
Signed-off-by: Maxime Ripard
On Mon, May 10, 2021 at 12:37 PM Andrey Grodzovsky
wrote:
>
> Handle all DMA IOMMU gropup related dependencies before the
> group is removed.
>
> v5: Drop IOMMU notifier and switch to lockless call to ttm_tt_unpopulate
> v6: Drop the BO unamp list
>
> Signed-off-by: Andrey Grodzovsky
> ---
> dri
On 2021-05-11 11:56 a.m., Alex Deucher wrote:
On Mon, May 10, 2021 at 12:37 PM Andrey Grodzovsky
wrote:
Handle all DMA IOMMU gropup related dependencies before the
group is removed.
v5: Drop IOMMU notifier and switch to lockless call to ttm_tt_unpopulate
v6: Drop the BO unamp list
Signed-
From: kernel test robot
drivers/gpu/drm/kmb/kmb_dsi.c:284:3-4: Unneeded semicolon
drivers/gpu/drm/kmb/kmb_dsi.c:304:3-4: Unneeded semicolon
drivers/gpu/drm/kmb/kmb_dsi.c:321:3-4: Unneeded semicolon
drivers/gpu/drm/kmb/kmb_dsi.c:340:3-4: Unneeded semicolon
drivers/gpu/drm/kmb/kmb_dsi.c:364:2-3: Un
Hi, Hsin-Yi:
Hsin-Yi Wang 於 2021年4月29日 週四 下午12:28寫道：
>
> Init panel orientation property after connector is initialized. Let the
> panel driver decides the orientation value later.
Acked-by: Chun-Kuang Hu
>
> Signed-off-by: Hsin-Yi Wang
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 7 +++
On Thu, May 06, 2021 at 12:14:22PM -0700, Matthew Brost wrote:
> GuC will issue a reset on detecting an engine hang and will notify
> the driver via a G2H message. The driver will service the notification
> by resetting the guilty context to a simple state or banning it
> completely.
>
> Cc: Matth
On Thu, May 06, 2021 at 12:14:28PM -0700, Matthew Brost wrote:
> We receive notification of an engine reset from GuC at its
> completion. Meaning GuC has potentially cleared any HW state
> we may have been interested in capturing. GuC resumes scheduling
> on the engine post-reset, as the resets are
On Tue, May 11, 2021 at 11:55 AM Maxime Ripard wrote:
>
> New KMS properties come with a bunch of requirements to avoid each
> driver from running their own, inconsistent, set of properties,
> eventually leading to issues like property conflicts, inconsistencies
> between drivers and semantics, et
On Tue, May 11, 2021 at 05:37:54PM +0200, Daniel Vetter wrote:
> On Thu, May 06, 2021 at 12:14:03PM -0700, Matthew Brost wrote:
> > Disable engine barriers for unpinning with GuC. This feature isn't
> > needed with the GuC as it disables context scheduling before unpinning
> > which guarantees the
On Mon, May 10, 2021 at 11:05 PM Christoph Hellwig wrote:
>
> > +static inline bool is_dev_swiotlb_force(struct device *dev)
> > +{
> > +#ifdef CONFIG_DMA_RESTRICTED_POOL
> > + if (dev->dma_io_tlb_mem)
> > + return true;
> > +#endif /* CONFIG_DMA_RESTRICTED_POOL */
> > + return
On Mon, May 10, 2021 at 11:03 PM Christoph Hellwig wrote:
>
> > +static inline struct io_tlb_mem *get_io_tlb_mem(struct device *dev)
> > +{
> > +#ifdef CONFIG_DMA_RESTRICTED_POOL
> > + if (dev && dev->dma_io_tlb_mem)
> > + return dev->dma_io_tlb_mem;
> > +#endif /* CONFIG_DMA_RESTR
1 - 100 of 156 matches
Mail list logo
