On Fri, Jan 13, 2023 at 09:46:49AM +0200, Laurent Pinchart wrote:
> Hi Christoph,
>
> Thank you for the patch.
>
> On Fri, Jan 13, 2023 at 07:23:18AM +0100, Christoph Hellwig wrote:
> > This driver depends on ARM && ARCH_SHMOBILE, but ARCH_SHMOBILE can only be
> > set for each/sh, making the
On 12/01/2023 23:52, Rob Herring wrote:
On Mon, Jan 09, 2023 at 07:01:50AM +0200, Dmitry Baryshkov wrote:
Add platform-specific compatible entries to the qcom,mdp5.yaml to allow
distinguishing between various platforms. For msm8998 list
qcom,msm8998-dpu rather than -mdp5 to allow this binding
Hi Christoph,
Thank you for the patch.
On Fri, Jan 13, 2023 at 07:23:18AM +0100, Christoph Hellwig wrote:
> This driver depends on ARM && ARCH_SHMOBILE, but ARCH_SHMOBILE can only be
> set for each/sh, making the driver dead code except for the COMPILE_TEST
> case.
>
> Signed-off-by: Christoph
On Fri, 13 Jan 2023 at 09:12, Laurentiu Palcu
wrote:
>
> Hi Dmitry,
>
> On Thu, Jan 12, 2023 at 05:42:47PM +0200, Dmitry Baryshkov wrote:
> > There are two flags attemting to guard connector polling:
> > poll_enabled and poll_running. While poll_enabled semantics is clearly
> > defined and fully
On Fri, Jan 13, 2023 at 07:23:19AM +0100, Christoph Hellwig wrote:
> USB_OHCI_SH is a dummy option that never builds any code, remove it.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/usb/host/Kconfig | 11 ---
> 1 file changed, 11 deletions(-)
>
> diff --git
Hi Dmitry,
On Thu, Jan 12, 2023 at 05:42:47PM +0200, Dmitry Baryshkov wrote:
> There are two flags attemting to guard connector polling:
> poll_enabled and poll_running. While poll_enabled semantics is clearly
> defined and fully adhered (mark that drm_kms_helper_poll_init() was
> called and not
Correct the struct name and add a short struct description to fix the
kernel-doc notation.
Prevents this kernel-doc warning:
drivers/video/backlight/sky81452-backlight.c:64: warning: expecting prototype
for struct sky81452_platform_data. Prototype was for struct
sky81452_bl_platform_data
Convert comments for START_BYTE() and CHECK_FREQ_REG() macros into
kernel-doc notation to avoid these kernel-doc warnings:
drivers/video/backlight/ili922x.c:85: warning: This comment starts with '/**',
but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
* START_BYTE(id,
Fix a kernel-doc warning by correcting the function name in the
kernel-doc comment:
drivers/video/fbdev/core/fbmon.c:1073: warning: expecting prototype for
fb_get_hblank_by_freq(). Prototype was for fb_get_hblank_by_hfreq() instead
Signed-off-by: Randy Dunlap
Cc: Daniel Vetter
Cc: Helge
Signed-off-by: Dmitry Baryshkov
---
.../devicetree/bindings/display/msm/dsi-phy-10nm.yaml | 3 +--
.../devicetree/bindings/display/msm/dsi-phy-14nm.yaml | 3 +--
.../devicetree/bindings/display/msm/dsi-phy-20nm.yaml | 3 +--
Use debugfs_remove_recursive to remove the /sys/kernel/debug/ttm
directory for better compatibility. Becuase debugfs_remove fails
on older kernel.
Signed-off-by: Ma Jun
---
drivers/gpu/drm/ttm/ttm_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Check the ttm_debugfs_root before creating files under it.
If the ttm_debugfs_root is NULL, all the files created for
ttm/ will be placed in the /sys/kerne/debug/ but not
/sys/kernel/debug/ttm/
Signed-off-by: Ma Jun
---
drivers/gpu/drm/ttm/ttm_device.c | 3 ++-
drivers/gpu/drm/ttm/ttm_pool.c
Hi Linus,
Back from a week off, managed to do a couple of dives (one with happy
manta ray about 3-4m away for 5mins).
Thanks to Daniel for taking care of fixes last week.
There is a bit of a post-holiday build up here I expect, small fixes
across the board, amdgpu and msm being the main
On 1/12/2023 8:37 PM, Dixit, Ashutosh wrote:
On Thu, 12 Jan 2023 20:26:34 -0800, Belgaumkar, Vinay wrote:
I think the ABI was changed by the patch mentioned in the commit
(a8a4f0467d70).
The ABI was originally changed in 80cf8af17af04 and 56a709cf77468.
Yes, you are right. @Andi, did we
Enable SDP error detection configuration, this will set CRC16 in
128b/132b link layer.
For DISPLAY13 a hardware bit31 in register VIDEO_DIP_CTL is added to
enable/disable SDP CRC applicable for DP2.0 only, but the default value
of this bit will enable CRC16 in 128b/132b hence skipping this write.
DP2.0 E11 defines a new register to facilitate SDP error detection by a
128B/132B capable DPRX device.
Signed-off-by: Arun R Murthy
---
include/drm/display/drm_dp.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
index
On 13/01/2023 05:59, Richard Acayan wrote:
The Snapdragon 670 uses similar clocks (with one frequency added) to the
Snapdragon 845 but reports DPU revision 4.1.0. Add support for this DPU
with configuration from the Pixel 3a downstream kernel.
Link:
On Thu, 12 Jan 2023 20:26:34 -0800, Belgaumkar, Vinay wrote:
>
> I think the ABI was changed by the patch mentioned in the commit
> (a8a4f0467d70).
The ABI was originally changed in 80cf8af17af04 and 56a709cf77468.
On 1/12/2023 7:15 PM, Dixit, Ashutosh wrote:
On Thu, 12 Jan 2023 18:27:52 -0800, Vinay Belgaumkar wrote:
Reading current root sysfs entries gives a min/max of all
GTs. Updating this so we return default (GT0) values when root
level sysfs entries are accessed, instead of min/max for the card.
On 13/01/2023 06:10, Bjorn Andersson wrote:
Invoking drm_bridge_hpd_notify() on a drm_bridge with a HPD-enabled
bridge_connector ends up in drm_bridge_connector_hpd_cb() calling
drm_kms_helper_hotplug_event(), which assumes that the associated
drm_device's mode_config.funcs is a valid pointer.
Invoking drm_bridge_hpd_notify() on a drm_bridge with a HPD-enabled
bridge_connector ends up in drm_bridge_connector_hpd_cb() calling
drm_kms_helper_hotplug_event(), which assumes that the associated
drm_device's mode_config.funcs is a valid pointer.
But in the MSM DisplayPort driver the HPD
On Thu, Jan 12, 2023 at 11:42 PM Dmitry Baryshkov
wrote:
>
> There are two flags attemting to guard connector polling:
> poll_enabled and poll_running. While poll_enabled semantics is clearly
> defined and fully adhered (mark that drm_kms_helper_poll_init() was
> called and not finalized by the
Hi Nicolas,
Thanks for your information.
On Thu, 2023-01-12 at 15:58 -0500, Nícolas F. R. A. Prado wrote:
> On Wed, May 18, 2022 at 08:30:02PM +0800, Yunfei Dong wrote:
> > Vp8 need to use MM21, but vp9 and h264 need to use HyFbc mode
> > for mt8195. Vp8/vp9/h264 use the same MM21 format for
On Thu, 12 Jan 2023 18:27:52 -0800, Vinay Belgaumkar wrote:
>
> Reading current root sysfs entries gives a min/max of all
> GTs. Updating this so we return default (GT0) values when root
> level sysfs entries are accessed, instead of min/max for the card.
> Tests that are not multi GT capable will
Reading current root sysfs entries gives a min/max of all
GTs. Updating this so we return default (GT0) values when root
level sysfs entries are accessed, instead of min/max for the card.
Tests that are not multi GT capable will read incorrect sysfs
values without this change on multi-GT platforms
A gap was recently discovered where if an application did not
invalidate all of the stream keys (intentionally or not), and the
driver did a full PXP global teardown on the GT subsystem, we
find that future session creation would fail on the security
firmware's side of the equation. i915 is the
A driver bug was recently discovered where the security firmware was
receiving internal HW signals indicating that session key expirations
had occurred. Architecturally, the firmware was expecting a response
from the GuC to acknowledge the event with the firmware side.
However the OS was in a
From: Alexander Usyskin
Client on bus have only one vtag map slot and should disregard the vtag
value when cleaning pending read flag.
Fixes read flow control message unexpectedly generated when
clent on bus send messages with different vtags.
Signed-off-by: Alexander Usyskin
Signed-off-by:
During suspend flow, i915 currently achors' on the pm_suspend_prepare
callback as the location where we quiesce the entire GPU and perform
all necessary cleanup in order to go into suspend. PXP is also called
during this time to perform the arbitration session teardown (with
the assurance no
From: Alexander Usyskin
Add device link with i915 as consumer and mei_pxp as supplier
to ensure proper ordering of power flows.
V2: condition on absence of heci_pxp to filter out DG
Signed-off-by: Alexander Usyskin
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 7
From: Alexander Usyskin
Asynchronous runtime resume is not possible while the system
is suspending.
The power management subsystem resumes the device only in the
suspend phase, not in the prepare phase.
Force resume device in prepare to allow drivers on mei bus
to communicate in their prepare
A customer issue was recently discovered and in the process a
gap in i915's PXP interaction with HW+FW architecure was also
realized. This series adds those missing pieces.
This fix includes changes where i915 calls into the mei
component interface in order to submit requests to the security
On 1/11/2023 14:56, Jason Ekstrand wrote:
On Wed, Jan 11, 2023 at 4:32 PM Matthew Brost
wrote:
On Wed, Jan 11, 2023 at 04:18:01PM -0600, Jason Ekstrand wrote:
> On Wed, Jan 11, 2023 at 2:50 AM Tvrtko Ursulin <
> tvrtko.ursu...@linux.intel.com> wrote:
>
> >
[snip]
>
On Thu, Jan 12, 2023 at 2:39 PM Thomas Zimmermann wrote:
>
> Remove nouveau's support for legacy contexts and buffers. It was
> required by libdrm earlier than 2.4.33, released in March 2012. A
> previous attempt in 2013 to remove the functionality [1] had to be
> reverted [2] as there were still
Thanks for reviewing. Will fix all and re-rev.
On Thu, 2023-01-12 at 09:28 -0800, Ceraolo Spurio, Daniele wrote:
>
> On 1/11/2023 4:37 PM, Alan Previn wrote:
> > During suspend flow, i915 currently achors' on the
> > pm_suspend_prepare
> > callback as the location where we quiesce the entire GPU
On Wed, Jan 11, 2023 at 10:21 PM Pin-yen Lin wrote:
>
> Analogix 7625 can be used in systems to switch the DP traffic between
> two downstreams, which can be USB Type-C DisplayPort alternate mode
> lane or regular DisplayPort output ports.
>
> Update the binding to accommodate this usage by
On Mon, Jan 09, 2023 at 07:39:30PM -0600, Gustavo A. R. Silva wrote:
> Zero-length arrays are deprecated[1] and we are moving towards
> adopting C99 flexible-array members instead. So, replace zero-length
> array declaration in struct nvfw_hs_load_header_v2 with flex-array
> member.
>
> This
Hi Dave,
A few fixes for the v6.3 cycle. Summary below.
The following changes since commit 8d1d17d47eaebe4466459846d07e4ba8953fa585:
Merge branches 'msm-next-lumag-core', 'msm-next-lumag-dpu',
'msm-next-lumag-dp', 'msm-next-lumag-dsi', 'msm-next-lumag-hdmi' and
'msm-next-lumag-mdp5' into
On Thu, Jan 12, 2023 at 10:39:20PM +, Limonciello, Mario wrote:
> This particular one was fixed already in
> https://patchwork.freedesktop.org/patch/518050/ which got applied today.
Ah-ha; thanks!
--
Kees Cook
On Wed, Jan 11, 2023 at 10:21 PM Pin-yen Lin wrote:
>
>
> This series introduces bindings for anx7625/it6505 to register Type-C
> mode-switch in their output endpoints, and use data-lanes property to
> describe the pin connections.
>
> The first two patch modifies fwnode_graph_devcon_matches and
On 1/11/2023 7:31 PM, Felix Kuehling wrote:
Use proper amdgpu_gem_prime_import function to handle all kinds of
imports. Remember the dmabuf reference to enable proper multi-GPU
attachment to multiple VMs without erroneously re-exporting the
underlying BO multiple times.
Signed-off-by: Felix
[AMD Official Use Only - General]
This particular one was fixed already in
https://patchwork.freedesktop.org/patch/518050/ which got applied today.
> -Original Message-
> From: coverity-bot
> Sent: Thursday, January 12, 2023 16:25
> To: Limonciello, Mario
> Cc:
;
| ^~~
Caused by commit
07a2975c65f2 ("drm/vc4: bo: Fix drmm_mutex_init memory hog")
I have used the drm-misc-fixes tree from next-20230112 for today.
--
Cheers,
Stephen Rothwell
pgpHe_7HABnZ4.pgp
Description: OpenPGP digital signature
HI Sakari,
On Thu, Jan 12, 2023 at 5:32 AM Sakari Ailus
wrote:
>
> Hi Pin-yen,
>
> On Thu, Jan 12, 2023 at 12:20:56PM +0800, Pin-yen Lin wrote:
> > From: Prashant Malani
> > + /*
> > + * Some drivers may register devices for endpoints. Check
> > + * the
Hello!
This is an experimental semi-automated report about issues detected by
Coverity from a scan of next-20230111 as part of the linux-next scan project:
https://scan.coverity.com/projects/linux-next-weekly-scan
You're getting this email because you were associated with the identified
lines of
Hello!
This is an experimental semi-automated report about issues detected by
Coverity from a scan of next-20230111 as part of the linux-next scan project:
https://scan.coverity.com/projects/linux-next-weekly-scan
You're getting this email because you were associated with the identified
lines of
On Mon, Jan 09, 2023 at 07:01:50AM +0200, Dmitry Baryshkov wrote:
> Add platform-specific compatible entries to the qcom,mdp5.yaml to allow
> distinguishing between various platforms. For msm8998 list
> qcom,msm8998-dpu rather than -mdp5 to allow this binding to be handled
> by either of the
On Wed, Jan 11, 2023 at 11:35:53PM +0100, Marijn Suijten wrote:
> On 2023-01-12 00:31:33, Dmitry Baryshkov wrote:
> > On 12/01/2023 00:29, Marijn Suijten wrote:
> > > On 2023-01-10 06:40:27, Dmitry Baryshkov wrote:
> > >> On 09/01/2023 09:49, Marijn Suijten wrote:
> > >>> On 2023-01-09 07:01:49,
On Thu, Jan 05, 2023 at 01:35:52PM +, Tvrtko Ursulin wrote:
Okay to sum it up below with some final notes..
On 04/01/2023 19:34, Matt Roper wrote:
On Wed, Jan 04, 2023 at 09:58:13AM +, Tvrtko Ursulin wrote:
On 23/12/2022 18:28, Lucas De Marchi wrote:
On Fri, Dec 23, 2022 at
On Mon, Jan 09, 2023 at 06:54:53AM +0200, Dmitry Baryshkov wrote:
> On Qualcomm devices HDMI PHY node names were changed from hdmi-phy to
> phy. Follow this change.
Okay, but foo-phy is generally accepted...
>
> Signed-off-by: Dmitry Baryshkov
> ---
>
Acked-by: Lyude Paul
On Thu, 2023-01-12 at 16:50 +0800, Wayne Lin wrote:
> This reverts commit 4d07b0bc403403438d9cf88450506240c5faf92f.
>
> [Why]
> Changes cause regression on amdgpu mst.
> E.g.
> In fill_dc_mst_payload_table_from_drm(), amdgpu expects to add/remove payload
> one by one and
On 12.01.2023 16:42, Dmitry Baryshkov wrote:
> There are two flags attemting to guard connector polling:
> poll_enabled and poll_running. While poll_enabled semantics is clearly
> defined and fully adhered (mark that drm_kms_helper_poll_init() was
> called and not finalized by the _fini() call),
On 1/12/2023 02:15, Tvrtko Ursulin wrote:
On 12/01/2023 02:53, john.c.harri...@intel.com wrote:
From: John Harrison
Engine resets are supposed to never fail. But in the case when one
does (due to unknown reasons that normally come down to a missing
w/a), it is useful to get as much
On Wed, May 18, 2022 at 08:30:02PM +0800, Yunfei Dong wrote:
> Vp8 need to use MM21, but vp9 and h264 need to use HyFbc mode
> for mt8195. Vp8/vp9/h264 use the same MM21 format for mt8192.
Hi Yunfei,
why do VP9 and H264 need to use HyFbc (is this the same as MT21C?) mode on
MT8195? The SCP
On 1/12/2023 02:06, Tvrtko Ursulin wrote:
On 12/01/2023 02:53, john.c.harri...@intel.com wrote:
From: John Harrison
A hang situation has been observed where the only requests on the
context were either completed or not yet started according to the
breaadcrumbs. However, the register state
On 1/12/2023 02:01, Tvrtko Ursulin wrote:
On 12/01/2023 02:53, john.c.harri...@intel.com wrote:
From: John Harrison
There was a report of error captures occurring without any hung
context being indicated despite the capture being initiated by a 'hung
context notification' from GuC. The
Set the framebuffer info for drivers that support VGA switcheroo. Only
affects the amdgpu and nouveau drivers, which use VGA switcheroo and
generic fbdev emulation. For other drivers, this does nothing.
This fixes a potential regression in the console code. Both, amdgpu and
nouveau, invoked
Always allow switching away via vga-switcheroo if the display is
uninitalized. Instead prevent switching to i915 if the device has
not been initialized.
This issue was introduced by commit 5df7bd130818 ("drm/i915: skip
display initialization when there is no display") protected, which
protects
Several lastclose helpers call vga_switcheroo_process_delayed_switch().
It's better to call the helper from drm_lastclose() after the kernel
client's screen has been restored. This way, all drivers can benefit
without having to implement their own lastclose helper. For drivers
without
(was: drm/fb-helper: Set framebuffer for vga-switcheroo clients)
This patch has now turned into a little series. The first two patches
are bug fixes for the existing code. The third patch cleans up the
drivers.
Patch 1 fixes i915 to do the correct thing if the device has not been
initialized
On Thu, 05 Jan 2023 14:45:55 +0100, Arnd Bergmann wrote:
> Most of the legacy PXA board files were marked as unused in linux-5.19 and
> can get removed in linux-6.3. There is support for pxa250/pxa270/pxa300
> using devicetree already, which supports a number of boards, but progress
> on
On 10/01/2023 01:43, Dmitry Baryshkov wrote:
On Mon, 21 Nov 2022 01:08:12 -0800, Kalyan Thota wrote:
Add color management support for the crtc provided there are
enough dspps that can be allocated from the catalog
Kalyan Thota (3):
drm/msm/disp/dpu1: pin 1 crtc to 1 encoder
Applied. Thanks!
Alex
On Thu, Jan 12, 2023 at 8:51 AM Deepak R Varma wrote:
>
> A logical evaluation already results in bool. There is no need for using
> a ternary operator based evaluation and bool conversion of the outcome.
> Issue identified using boolconv.cocci Coccinelle semantic patch.
Applied. Thanks!
On Wed, Jan 11, 2023 at 10:21 PM Jiapeng Chong
wrote:
>
> The assignment of the else and if branches is the same, so the if else
> here is redundant, so we remove it.
>
> ./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:1951:2-4: WARNING:
> possible condition with no effect
On 1/9/2023 5:23 AM, Jacek Lawrynowicz wrote:
- Implement cold and warm firmware boot flows
- Add hang recovery support
- Add runtime power management support
Co-developed-by: Krystian Pradzynski
Signed-off-by: Krystian Pradzynski
Signed-off-by: Jacek Lawrynowicz
I don't claim to
On 11/01/2023 22:19, Daniel Vetter wrote:
On Tue, Jan 10, 2023 at 01:14:51PM +, Tvrtko Ursulin wrote:
On 06/01/2023 18:00, Daniel Vetter wrote:
On Fri, Jan 06, 2023 at 03:53:13PM +0100, Christian König wrote:
Am 06.01.23 um 11:53 schrieb Daniel Vetter:
On Fri, Jan 06, 2023 at
On 11/01/2023 19:40, Matthew Brost wrote:
On Wed, Jan 11, 2023 at 08:50:37AM +, Tvrtko Ursulin wrote:
[snip]
This example is where it would hurt on large systems. Imagine only an even
wider media transcode card...
Second example is only a single engine class used (3d desktop?) but
On 1/9/2023 5:23 AM, Jacek Lawrynowicz wrote:
Each of the user contexts has two command queues, one for compute engine
and one for the copy engine. Command queues are allocated and registered
in the device when the first job (command buffer) is submitted from
the user space to the VPU device.
On Mon, Dec 26, 2022 at 10:53:24PM -0700, Drew Davenport wrote:
> The error message suggests that the height of the src rect must be at
> least 1. Reject source with height of 0.
>
> Signed-off-by: Drew Davenport
>
> ---
> I was investigating some divide-by-zero crash reports on ChromeOS which
On 1/9/2023 5:23 AM, Jacek Lawrynowicz wrote:
Read, parse and boot VPU firmware image.
Co-developed-by: Andrzej Kacprowski
Signed-off-by: Andrzej Kacprowski
Co-developed-by: Krystian Pradzynski
Signed-off-by: Krystian Pradzynski
Signed-off-by: Jacek Lawrynowicz
Reviewed-by: Jeffrey Hugo
On 11/01/2023 17:52, Matthew Brost wrote:
On Wed, Jan 11, 2023 at 09:09:45AM +, Tvrtko Ursulin wrote:
[snip]
Anyway, since you are not buying any arguments on paper perhaps you are more
open towards testing. If you would adapt gem_wsim for Xe you would be able
to spawn N simulated
On 1/9/2023 5:23 AM, Jacek Lawrynowicz wrote:
The IPC driver is used to send and receive messages to/from firmware
running on the VPU.
The only supported IPC message format is Job Submission Model (JSM)
defined in vpu_jsm_api.h header.
Co-developed-by: Andrzej Kacprowski
Signed-off-by:
From: Chris Morgan
Add documentation for Samsung AMS495QA01 panel (with Magnachip
D53E6EA8966 controller IC).
Signed-off-by: Chris Morgan
Signed-off-by: Maya Matuszczyk
Reviewed-by: Rob Herring
---
.../display/panel/samsung,ams495qa01.yaml | 57 +++
1 file changed, 57
From: Chris Morgan
Add helper function to find DSI host for devices where DSI panel is not
a minor of a DSI bus (such as the Samsung AMS495QA01 panel or the
official Raspberry Pi touchscreen display).
Signed-off-by: Chris Morgan
Signed-off-by: Maya Matuszczyk
---
drivers/gpu/drm/drm_of.c |
From: Chris Morgan
Add Samsung AMS495QA01 panel to RG503.
Signed-off-by: Chris Morgan
Signed-off-by: Maya Matuszczyk
---
.../dts/rockchip/rk3566-anbernic-rg503.dts| 55 +++
1 file changed, 55 insertions(+)
diff --git
From: Chris Morgan
Support Magnachip D53E6EA8966 based panels such as the Samsung
AMS495QA01 panel as found on the Anbernic RG503. Note this driver
supports only the AMS495QA01 today which receives video signals via DSI,
however it receives commands via 3-wire SPI using DBI.
Signed-off-by:
From: Chris Morgan
Add the Magnachip D53E6EA8966 panel IC controller for display panels
such as the Samsung AMS495QA01 panel as found on the Anbernic RG503.
This panel uses DSI to receive video signals, but 3-wire SPI to receive
command signals using DBI.
Changes since V9:
- Set an ifdef to
On 1/9/2023 5:23 AM, Jacek Lawrynowicz wrote:
Adds four types of GEM-based BOs for the VPU:
- shmem
- userptr
- internal
- prime
All types are implemented as struct ivpu_bo, based on
struct drm_gem_object. VPU address is allocated when buffer is created
except for imported prime
https://bugzilla.kernel.org/show_bug.cgi?id=216917
Mario Limonciello (AMD) (mario.limoncie...@amd.com) changed:
What|Removed |Added
Status|ASSIGNED
On 1/9/2023 5:23 AM, Jacek Lawrynowicz wrote:
VPU Memory Management Unit is based on ARM MMU-600.
It allows the creation of multiple virtual address spaces for
the device and map noncontinuous host memory (there is no dedicated
memory on the VPU).
Address space is implemented as a struct
On 1/12/2023 02:50, Wayne Lin wrote:
This reverts commit 4d07b0bc403403438d9cf88450506240c5faf92f.
[Why]
Changes cause regression on amdgpu mst.
E.g.
In fill_dc_mst_payload_table_from_drm(), amdgpu expects to add/remove payload
one by one and call fill_dc_mst_payload_table_from_drm() to update
On 1/9/2023 5:23 AM, Jacek Lawrynowicz wrote:
VPU stands for Versatile Processing Unit and it's a CPU-integrated
inference accelerator for Computer Vision and Deep Learning
applications.
The VPU device consist of following components:
- Buttress - provides CPU to VPU integration, interrupt,
On 1/11/2023 4:37 PM, Alan Previn wrote:
During suspend flow, i915 currently achors' on the pm_suspend_prepare
callback as the location where we quiesce the entire GPU and perform
all necessary cleanup in order to go into suspend. PXP is also called
during this time to perform the arbitration
Hi Rob,
I love your patch! Yet something to improve:
[auto build test ERROR on drm/drm-next]
[also build test ERROR on drm-exynos/exynos-drm-next drm-intel/for-linux-next
drm-intel/for-linux-next-fixes drm-tip/drm-tip linus/master v6.2-rc3
next-20230112]
[cannot apply to drm-misc/drm-misc-next
https://bugzilla.kernel.org/show_bug.cgi?id=216917
--- Comment #10 from kolAflash (kolafl...@kolahilft.de) ---
Looks like the display issue with linux-6.1.y is on a good way.
Hibernation still works fine with the latest revert-commit by Mario & Wayne,
which I tested here.
On Thu, Jan 12, 2023 at 10:54:25AM +0100, Lucas De Marchi wrote:
> On Thu, Jan 05, 2023 at 09:27:57PM +, Matthew Brost wrote:
> > On Tue, Jan 03, 2023 at 12:21:08PM +, Tvrtko Ursulin wrote:
> > >
> > > On 22/12/2022 22:21, Matthew Brost wrote:
> > > > Hello,
> > > >
> > > > This is a
Hello,
Moving the discussion that started here [1] to a separate thread to stop
polluting the Xe RFC.
> > > Also if you do the allocation in ->prepare_job with dma_fence and not
> > > run_job, then I think can sort out fairness issues (if they do pop up) in
> > > the drm/sched code instead of
On 1/9/2023 5:23 AM, Jacek Lawrynowicz wrote:
Hi,
This patchset contains a new Linux* Kernel Driver for Intel® VPUs.
VPU stands for Versatile Processing Unit and it is an AI inference accelerator
integrated with Intel non-server CPUs starting from 14th generation.
VPU enables efficient
From: Tvrtko Ursulin
Similar to CPU scheduling, implement a concept of weight in the drm cgroup
controller.
Uses the same range and default as the CPU controller - CGROUP_WEIGHT_MIN,
CGROUP_WEIGHT_DFL and CGROUP_WEIGHT_MAX.
Later each cgroup is assigned a time budget proportionaly based on the
From: Tvrtko Ursulin
When notified by the drm core we are over our allotted time budget, i915
instance will check if any of the GPU engines it is reponsible for is
fully saturated. If it is, and the client in question is using that
engine, it will throttle it.
For now throttling is done
From: Tvrtko Ursulin
Implement the drm_cgroup_ops->active_time_us callback.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_driver.c | 10
drivers/gpu/drm/i915/i915_drm_client.c | 76 ++
drivers/gpu/drm/i915/i915_drm_client.h | 2 +
3 files
From: Tvrtko Ursulin
Add a driver callback and core helper which allow querying the time spent
on GPUs for processes belonging to a group.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/drm_cgroup.c | 24
include/drm/drm_clients.h| 2 ++
include/drm/drm_drv.h
From: Tvrtko Ursulin
We need the ability for DRM core to inform the cgroup controller when a
client has closed a DRM file descriptor. This will allow us not needing
to keep state relating to GPU time usage by tasks sets in the cgroup
controller itself.
Signed-off-by: Tvrtko Ursulin
---
From: Tvrtko Ursulin
Add a new callback via which the drm cgroup controller is notifying the
drm core that a certain process is above its allotted GPU time.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/drm_cgroup.c | 21 +
include/drm/drm_clients.h| 1 +
From: Tvrtko Ursulin
To reduce the number of tracking going on, especially with drivers which
will not support any sort of control from the drm cgroup controller side,
lets express the funcionality as opt-in and use the presence of
drm_cgroup_ops as activation criteria.
Signed-off-by: Tvrtko
From: Tvrtko Ursulin
Entry points from the cgroup subsystem into the drm cgroup controller will
need to walk the file_priv structures associated with registered clients
and since those are not RCU protected lets add a hack for now to make this
safe.
Signed-off-by: Tvrtko Ursulin
---
From: Tvrtko Ursulin
To enable propagation of settings from the cgroup drm controller to drm we
need to start tracking which processes own which drm clients.
Implement that by tracking the struct pid pointer of the owning process in
a new XArray, pointing to a structure containing a list of
From: Tvrtko Ursulin
Skeleton controller without any functionality.
Signed-off-by: Tvrtko Ursulin
---
include/linux/cgroup_drm.h| 9 ++
include/linux/cgroup_subsys.h | 4 +++
init/Kconfig | 7 +
kernel/cgroup/Makefile| 1 +
kernel/cgroup/drm.c
From: Tvrtko Ursulin
With the typical model where the display server opends the file descriptor
and then hands it over to the client we were showing stale data in
debugfs.
Fix it by updating the drm_file->pid on ioctl access from a different
process.
The field is also made RCU protected to
From: Tvrtko Ursulin
Thread group id (aka pid from userspace point of view) is a more
interesting thing to show as an owner of a DRM fd, so track and show that
instead of the thread id.
In the next patch we will make the owner updated post file descriptor
handover, which will also be tgid based
1 - 100 of 199 matches
Mail list logo
