https://bugzilla.kernel.org/show_bug.cgi?id=213917
ker...@mail.niknah.com changed:
What|Removed |Added
CC||ker...@mail.niknah.com
---
On 2023-10-04 23:33, Matthew Brost wrote:
> On Tue, Sep 26, 2023 at 11:32:10PM -0400, Luben Tuikov wrote:
>> Hi,
>>
>> On 2023-09-19 01:01, Matthew Brost wrote:
>>> In XE, the new Intel GPU driver, a choice has made to have a 1 to 1
>>> mapping between a drm_gpu_scheduler and drm_sched_entity. At
On Fri, Sep 29, 2023 at 05:58:46PM -0400, Luben Tuikov wrote:
> Hi,
>
> On 2023-09-19 01:01, Matthew Brost wrote:
> > If the TDR is set to a value, it can fire before a job is submitted in
> > drm_sched_main. The job should be always be submitted before the TDR
> > fires, fix this ordering.
> >
On Thu, Sep 28, 2023 at 12:14:12PM -0400, Luben Tuikov wrote:
> On 2023-09-19 01:01, Matthew Brost wrote:
> > Rather than call free_job and run_job in same work item have a dedicated
> > work item for each. This aligns with the design and intended use of work
> > queues.
> >
> > v2:
> >- Test
On Wed, Sep 27, 2023 at 10:36:49AM -0400, Luben Tuikov wrote:
> Hi,
>
> On 2023-09-19 01:01, Matthew Brost wrote:
> > DRM_SCHED_POLICY_SINGLE_ENTITY creates a 1 to 1 relationship between
> > scheduler and entity. No priorities or run queue used in this mode.
> > Intended for devices with firmware
Hi all,
After merging the drm-misc-fixes tree, today's linux-next build (htmldocs)
produced this warning:
include/uapi/drm/nouveau_drm.h:49: warning: Cannot understand *
@NOUVEAU_GETPARAM_EXEC_PUSH_MAX
on line 49 - I thought it was a doc line
Introduced by commit
d59e75eef52d
Hi all,
After merging the drm-misc tree, today's linux-next build (htmldocs)
produced this warning:
Documentation/gpu/panfrost.rst: WARNING: document isn't included in any toctree
Introduced by commit
f11b0417eec2 ("drm/panfrost: Add fdinfo support GPU load metrics")
--
Cheers,
Stephen
Hi Dave, Daniel,
Fixes for 6.6.
The following changes since commit 8a749fd1a8720d4619c91c8b6e7528c0a355c0aa:
Linux 6.6-rc4 (2023-10-01 14:15:13 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-6.6-2023-10-04
for you to
Hi Jocelyn,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 2dde18cd1d8fac735875f2e4987f11817cc0bc2c]
url:
https://github.com/intel-lab-lkp/linux/commits/Jocelyn-Falempe/drm-format-helper-Export-line-conversion-helper-for-drm_panic/20231003-222642
base:
On Tue, Sep 26, 2023 at 11:32:10PM -0400, Luben Tuikov wrote:
> Hi,
>
> On 2023-09-19 01:01, Matthew Brost wrote:
> > In XE, the new Intel GPU driver, a choice has made to have a 1 to 1
> > mapping between a drm_gpu_scheduler and drm_sched_entity. At first this
> > seems a bit odd but let us
On Fri, Sep 29, 2023 at 06:44:53PM -0400, Luben Tuikov wrote:
> On 2023-09-19 01:01, Matthew Brost wrote:
> > Add helper to queue TDR immediately for current and future jobs. This
> > will be used in XE, new Intel GPU driver, to trigger the TDR to cleanup
>
> Please use present tense, "is", in
On 2023-10-04 23:11, Matthew Brost wrote:
> On Sat, Sep 30, 2023 at 03:48:07PM -0400, Luben Tuikov wrote:
>> On 2023-09-29 17:53, Luben Tuikov wrote:
>>> Hi,
>>>
>>> On 2023-09-19 01:01, Matthew Brost wrote:
If the TDR is set to a very small value it can fire before the
submission is
On Sat, Sep 30, 2023 at 03:48:07PM -0400, Luben Tuikov wrote:
> On 2023-09-29 17:53, Luben Tuikov wrote:
> > Hi,
> >
> > On 2023-09-19 01:01, Matthew Brost wrote:
> >> If the TDR is set to a very small value it can fire before the
> >> submission is started in the function drm_sched_start. The
> -Original Message-
> From: Christian König
> Sent: Wednesday, October 4, 2023 8:45 AM
> To: Thomas Hellström ; Zeng, Oak
>
> Cc: intel...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Subject: Re: bulk_move in ttm_resource manager
>
> Am 04.10.23 um 09:17 schrieb Thomas
Hi Dmitry,
Resource flush is what is waiting for the fence to be signaled.
(in current code before my patches are applied)
static void virtio_gpu_resource_flush(struct drm_plane *plane,
uint32_t x, uint32_t y,
uint32_t
On 9/6/23 00:08, Kim, Dongwon wrote:
>
> I don't believe the guest will start rendering on the same FB while host is
> consuming it because the virtio-gpu driver on the guest won't release
> the FB for the next
> frame before it gets the virtio resp for the resource flush command and
> the host
On Wed, Oct 04, 2023 at 10:58:32PM +0200, Andi Shyti wrote:
> Hi Matt,
>
> > > > > > > The MCR steering semaphore is a shared lock entry between i915
> > > > > > > and various firmware components.
> > > > > > >
> > > > > > > Getting the lock might sinchronize on some shared resources.
> > > > >
On 10/4/2023 13:58, Andi Shyti wrote:
Hi Matt,
The MCR steering semaphore is a shared lock entry between i915
and various firmware components.
Getting the lock might sinchronize on some shared resources.
Sometimes though, it might happen that the firmware forgets to
unlock causing unnecessary
On 10/4/2023 13:09, Andi Shyti wrote:
Hi John,
The MCR steering semaphore is a shared lock entry between i915
and various firmware components.
Getting the lock might sinchronize on some shared resources.
Sometimes though, it might happen that the firmware forgets to
unlock causing unnecessary
On 9/21/23 10:15, Sebastian Andrzej Siewior wrote:
Hi,
I stumbled uppon the amdgpu driver via a bugzilla report. The actual fix
is #4 + #5 and the rest was made while looking at the code.
Sebastian
I have applied the series, thanks!
--
Hamza
On 9/21/23 08:15, Sebastian Andrzej Siewior wrote:
Hi,
I stumbled uppon the amdgpu driver via a bugzilla report. The actual fix
is #4 + #5 and the rest was made while looking at the code.
Sebastian
Hi Sebastian,
Thanks a lot for this patchset. We tested it on multiple devices, and
Hi Matt,
> > > > > > The MCR steering semaphore is a shared lock entry between i915
> > > > > > and various firmware components.
> > > > > >
> > > > > > Getting the lock might sinchronize on some shared resources.
> > > > > > Sometimes though, it might happen that the firmware forgets to
> > > >
Hi John,
> > > > > > The MCR steering semaphore is a shared lock entry between i915
> > > > > > and various firmware components.
> > > > > >
> > > > > > Getting the lock might sinchronize on some shared resources.
> > > > > > Sometimes though, it might happen that the firmware forgets to
> > > >
On Wed, Oct 04, 2023 at 09:35:27PM +0200, Andi Shyti wrote:
> Hi John,
>
> > > > > The MCR steering semaphore is a shared lock entry between i915
> > > > > and various firmware components.
> > > > >
> > > > > Getting the lock might sinchronize on some shared resources.
> > > > > Sometimes
Reviewed-by: Simon Ser
On 10/4/2023 12:35, Andi Shyti wrote:
Hi John,
The MCR steering semaphore is a shared lock entry between i915
and various firmware components.
Getting the lock might sinchronize on some shared resources.
Sometimes though, it might happen that the firmware forgets to
unlock causing unnecessary
Hi,
On Wed, Oct 4, 2023 at 1:28 PM Ville Syrjälä
wrote:
> No one really seemed all that interested in it. I'd still like to get
> it in, if for no other reason than to make things operate more uniformly.
> Though there are lots of legacy codepaths left that still hold the locks
> over the whole
Hi John,
> > > > The MCR steering semaphore is a shared lock entry between i915
> > > > and various firmware components.
> > > >
> > > > Getting the lock might sinchronize on some shared resources.
> > > > Sometimes though, it might happen that the firmware forgets to
> > > > unlock causing
On 10/4/2023 07:08, Andi Shyti wrote:
Hi Tvrtko,
The MCR steering semaphore is a shared lock entry between i915
and various firmware components.
Getting the lock might sinchronize on some shared resources.
Sometimes though, it might happen that the firmware forgets to
unlock causing
6.5-stable review patch. If anyone has any objections, please let me know.
--
From: Jani Nikula
commit 099f0af9d98231bb74956ce92508e87cbcb896be upstream.
The EDID returned by drm_bridge_get_edid() needs to be freed.
Fixes: 0af5e0b41110 ("drm/meson: encoder_hdmi: switch to
On 10/4/23 19:57, Thomas Hellström wrote:
On Wed, 2023-10-04 at 19:17 +0200, Danilo Krummrich wrote:
On 10/4/23 17:29, Thomas Hellström wrote:
On Wed, 2023-10-04 at 14:57 +0200, Danilo Krummrich wrote:
On 10/3/23 11:11, Thomas Hellström wrote:
+
+/**
+ * drm_gpuvm_bo_evict() - add /
6.1-stable review patch. If anyone has any objections, please let me know.
--
From: Jani Nikula
commit 099f0af9d98231bb74956ce92508e87cbcb896be upstream.
The EDID returned by drm_bridge_get_edid() needs to be freed.
Fixes: 0af5e0b41110 ("drm/meson: encoder_hdmi: switch to
5.15-stable review patch. If anyone has any objections, please let me know.
--
From: Jani Nikula
commit 099f0af9d98231bb74956ce92508e87cbcb896be upstream.
The EDID returned by drm_bridge_get_edid() needs to be freed.
Fixes: 0af5e0b41110 ("drm/meson: encoder_hdmi: switch to
On Thu, 2023-09-28 at 13:46 +0100, Tvrtko Ursulin wrote:
> On 27/09/2023 17:36, Teres Alexis, Alan Previn wrote:
> > Thanks for taking the time to review this Tvrtko, replies inline below.
alan:snip
> > >
> > > Main concern is that we need to be sure there are no possible
> > > ill-effects, like
On Wed, 2023-10-04 at 19:17 +0200, Danilo Krummrich wrote:
> On 10/4/23 17:29, Thomas Hellström wrote:
> >
> > On Wed, 2023-10-04 at 14:57 +0200, Danilo Krummrich wrote:
> > > On 10/3/23 11:11, Thomas Hellström wrote:
> > >
> > >
> > >
> > > > > > +
> > > > > > +/**
> > > > > > + *
On 2023-10-03 19:29, Kees Cook wrote:
> Prepare for the coming implementation by GCC and Clang of the __counted_by
> attribute. Flexible array members annotated with __counted_by can have
> their accesses bounds-checked at run-time via CONFIG_UBSAN_BOUNDS (for
> array indexing) and
On Thu, Sep 28, 2023 at 03:33:46PM -0400, Ray Strode wrote:
> hI,
>
> On Thu, Sep 28, 2023 at 11:05 AM Ville Syrjälä
> wrote:
> > Here's my earlier take on this:
> > https://patchwork.freedesktop.org/series/108668/
>
> Nice. Was there push back? Why didn't it go in?
No one really seemed all
On 10/4/23 17:29, Thomas Hellström wrote:
On Wed, 2023-10-04 at 14:57 +0200, Danilo Krummrich wrote:
On 10/3/23 11:11, Thomas Hellström wrote:
+
+/**
+ * drm_gpuvm_bo_evict() - add / remove a _gpuvm_bo to /
from the _gpuvms
+ * evicted list
+ * @vm_bo: the _gpuvm_bo to add or remove
+ *
On 10/4/2023 10:29 PM, Felix Kuehling wrote:
On 2023-10-04 12:16, Arvind Yadav wrote:
This patch is to align the absolute doorbell offset
based on the doorbell's size. So that doorbell offset
will be aligned for both 32 bit and 64 bit.
v2:
- Addressed the review comment from Felix.
v3:
-
On Wed, Oct 04, 2023 at 07:21:49PM +0300, Jani Nikula wrote:
> Prefer struct drm_edid where possible. With limited users for the
> drm_dp_downstream_*() helpers, this is fairly straightforward.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
>
This is a note to let you know that I've just added the patch titled
drm/meson: fix memory leak on ->hpd_notify callback
to the 6.5-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
drm/meson: fix memory leak on ->hpd_notify callback
to the 6.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
On 2023-10-04 12:16, Arvind Yadav wrote:
This patch is to align the absolute doorbell offset
based on the doorbell's size. So that doorbell offset
will be aligned for both 32 bit and 64 bit.
v2:
- Addressed the review comment from Felix.
v3:
- Adding doorbell_size as parameter to get db
On Wed, 2023-10-04 at 06:34 +, Gupta, Anshuman wrote:
>
> > -Original Message-
> > From: Teres Alexis, Alan Previn > @@ -289,6 +289,13 @@ int intel_gt_resume(struct intel_gt *gt)
> >
> > static void wait_for_suspend(struct intel_gt *gt) {
> > + /*
> > +* On rare occasions,
Currently eDP population is done at msm_dp_modeset_init() which happen
at binding time. Move eDP population to be done at display probe time
so that probe deferral cases can be handled effectively.
wait_for_hpd_asserted callback is added during drm_dp_aux_init()
to ensure eDP's HPD is up before
EV_HPD_INIT_SETUP flag is used to trigger the initialization of external
DP host controller. Since external DP host controller initialization had
been incorporated into pm_runtime_resume(), this flag became obsolete.
msm_dp_irq_postinstall() which triggers EV_HPD_INIT_SETUP event is
obsoleted
Currently DP driver is executed independent of PM runtime framework.
This leads msm eDP panel can not being detected by edp_panel driver during
generic_edp_panel_probe() due to AUX DPCD read failed at edp panel driver.
Incorporate PM runtime framework into DP driver so that host controller's
power
Original both parser->parse() and dp_power_client_init() are done at
dp_display_bind() since eDP population is done at binding time.
In the preparation of having eDP population done at probe() time,
move both function from dp_display_bind() to dp_display_probe().
Changes in v4:
-- explain why
The is_connected flag is set to true after DP mainlink successfully
finishes link training to enter into ST_MAINLINK_READY state rather
than being set after the DP dongle is connected. Rename the
is_connected flag with link_ready flag to match the state of DP
driver's state machine.
Changes in
Currently DP driver use drm_helper_hpd_irq_event(), bypassing drm bridge
framework, to report HPD status changes to user space frame work.
Replace it with drm_bridge_hpd_notify() since DP driver is part of drm
bridge.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Dmitry Baryshkov
---
Currently the dp_display_request_irq() is executed at msm_dp_modeset_init()
which ties irq registering to the DPU device's life cycle, while depending on
resources that are released as the DP device is torn down. Move register DP
driver irq handler to dp_display_probe() to have
The purpose of this patch series is to incorporate pm runtime framework
into MSM eDP/DP driver so that eDP panel can be detected by DRM eDP panel
driver during system probe time. During incorporating procedure, original
customized pm realted fucntions, such as dp_pm_prepare(), dp_pm_suspend(),
Prefer struct drm_edid where possible. With limited users for the
drm_dp_downstream_*() helpers, this is fairly straightforward.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/display/drm_dp_helper.c | 39 ++-
.../drm/i915/display/intel_display_debugfs.c | 3 +-
This is a note to let you know that I've just added the patch titled
drm/meson: fix memory leak on ->hpd_notify callback
to the 5.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
Hi Rodrigo,
On 10/4/2023 4:37 PM, Rodrigo Vivi wrote:
On Wed, Oct 04, 2023 at 03:54:59PM +0200, Nirmoy Das wrote:
Hi Rodrigo,
On 10/4/2023 2:44 PM, Rodrigo Vivi wrote:
On Wed, Oct 04, 2023 at 02:04:07PM +0200, Nirmoy Das wrote:
Take the mcr lock only when driver needs to write into a mcr
This patch is to align the absolute doorbell offset
based on the doorbell's size. So that doorbell offset
will be aligned for both 32 bit and 64 bit.
v2:
- Addressed the review comment from Felix.
v3:
- Adding doorbell_size as parameter to get db absolute offset.
Cc: Christian Koenig
Cc: Alex
Here, passing db_size in byte to find the doorbell's
absolute offset for both 32-bit and 64-bit doorbell sizes.
So that doorbell offset will be aligned based on the doorbell
size.
v3:
- Adding db_size as parameter to get db absolute offset.
Cc: Christian Koenig
Cc: Alex Deucher
Signed-off-by:
On older chips, the absolute doorbell offset within
the doorbell page is based on the queue ID.
KFD is using queue ID and doorbell size to get an
absolute doorbell offset in userspace.
Here, adding db_size in byte to find the doorbell's
absolute offset for both 32-bit and 64-bit doorbell sizes.
On Mon, 02 Oct 2023, Niko Tsirakis wrote:
> This is to eliminate all cases of "*ERROR* LSPCON mode hasn't settled",
> followed by link training errors. Intel engineers recommended increasing
> this timeout and that does resolve the issue.
>
> On some CometLake-based device designs the Parade
On Wed, 2023-10-04 at 14:57 +0200, Danilo Krummrich wrote:
> On 10/3/23 11:11, Thomas Hellström wrote:
>
>
>
> > > > +
> > > > +/**
> > > > + * drm_gpuvm_bo_evict() - add / remove a _gpuvm_bo to /
> > > > from the _gpuvms
> > > > + * evicted list
> > > > + * @vm_bo: the _gpuvm_bo to add or
On Wed, 27 Sep 2023 07:47:53 -0500, Adam Ford wrote:
> On Sun, Sep 3, 2023 at 8:05 PM Inki Dae wrote:
> >
> > 2023년 8월 29일 (화) 오전 7:38, Adam Ford 님이 작성:
> > >
> > > On Mon, Aug 28, 2023 at 10:59 AM Michael Tretter
> > > wrote:
> > > >
> > > > From: Marco Felsch
> > > >
> > > > Since the MIPI
Hi Daniel,
...
> ...
> > > > > +required:
> > > > > + - compatible
> > > > > + - reg
> > > > > + - max-brightness
> > > >
> > > > Why is this mandatory?
> > > >
> > > > There's no point in setting max-brightness when running in I2C
> > > > mode
> > > > (max- brightness should default to 31 in
On Wed, Oct 04, 2023 at 03:54:59PM +0200, Nirmoy Das wrote:
> Hi Rodrigo,
>
> On 10/4/2023 2:44 PM, Rodrigo Vivi wrote:
> > On Wed, Oct 04, 2023 at 02:04:07PM +0200, Nirmoy Das wrote:
> > > Take the mcr lock only when driver needs to write into a mcr based
> > > tlb based registers.
> > >
> > >
The pm_runtime_enable function increases the power disable depth,
which means that we must perform a matching decrement on the error
handling path to maintain balance within the given context.
Additionally, we need to address the same issue for pm_runtime_get_sync.
We fix this by invoking
Am 04.10.23 um 01:03 schrieb Andi Shyti:
From: Chris Wilson
Enforce that an mmap of a dmabuf is always using MAP_SHARED so that all
access (both read and writes) using the device memory and not a local
copy-on-write page in system memory.
As much as I would like to do this I fear that this
Hi Tvrtko,
> > The MCR steering semaphore is a shared lock entry between i915
> > and various firmware components.
> >
> > Getting the lock might sinchronize on some shared resources.
> > Sometimes though, it might happen that the firmware forgets to
> > unlock causing unnecessary noise in the
Hi Rodrigo,
On 10/4/2023 2:44 PM, Rodrigo Vivi wrote:
On Wed, Oct 04, 2023 at 02:04:07PM +0200, Nirmoy Das wrote:
Take the mcr lock only when driver needs to write into a mcr based
tlb based registers.
To prevent GT reset interference, employ gt->reset.mutex instead, since
On 10/3/23 19:37, Thomas Hellström wrote:
Hi, Danilo
On Tue, 2023-10-03 at 18:55 +0200, Danilo Krummrich wrote:
It seems like we're mostly aligned on this series, except for the key
controversy we're discussing for a few versions now: locking of the
internal
lists. Hence, let's just re-iterate
On 10/3/23 11:11, Thomas Hellström wrote:
+
+/**
+ * drm_gpuvm_bo_evict() - add / remove a _gpuvm_bo to / from the
_gpuvms
+ * evicted list
+ * @vm_bo: the _gpuvm_bo to add or remove
+ * @evict: indicates whether the object is evicted
+ *
+ * Adds a _gpuvm_bo to or removes it from the
On Thu, 21 Sep 2023, Jani Nikula wrote:
> Since the edid_firmware module parameter was moved from
> drm_kms_helper.ko to drm.ko in v4.15, we've had a backwards
> compatibility helper in place, with a DRM_NOTE() suggesting to migrate
> to drm.edid_firmware. This was added in commit ac6c35a4d8c7
On Sat, 30 Sep 2023, Shyam Sundar S K wrote:
> In order to provide GPU inputs to TA for the Smart PC solution to work, we
> need to have interface between the PMF driver and the AMDGPU driver.
>
> Add the initial code path for get interface from AMDGPU.
>
> Co-developed-by: Mario Limonciello
>
On Wed, Oct 04, 2023 at 02:04:07PM +0200, Nirmoy Das wrote:
> Take the mcr lock only when driver needs to write into a mcr based
> tlb based registers.
>
> To prevent GT reset interference, employ gt->reset.mutex instead, since
> intel_gt_mcr_multicast_write relies on gt->uncore->lock not being
On 2023-10-03 15:54, Harry Wentland wrote:
> On 2023-10-02 06:58, Sebastian Andrzej Siewior wrote:
>> On 2023-09-22 07:33:26 [+0200], Christian König wrote:
>>> Am 21.09.23 um 16:15 schrieb Sebastian Andrzej Siewior:
Hi,
I stumbled uppon the amdgpu driver via a bugzilla report.
Am 04.10.23 um 09:17 schrieb Thomas Hellström:
On Wed, 2023-10-04 at 03:52 +, Zeng, Oak wrote:
Hi Christian,
As a follow up to this thread:
https://www.spinics.net/lists/dri-devel/msg410740.html, I started the
work of moving the lru out of ttm_resource_manager and make it a
common
On Sat, 30 Sep 2023, Shyam Sundar S K wrote:
> Sometimes policy binary retrieved from the BIOS maybe incorrect that can
> end up in failing to enable the Smart PC solution feature.
>
> Use print_hex_dump_debug() to dump the policy binary in hex, so that we
> debug the issues related to the
On Sat, 30 Sep 2023, Shyam Sundar S K wrote:
> PMF driver sends constant inputs to TA which its gets via the other
> subsystems in the kernel. To debug certain TA issues knowing what inputs
> being sent to TA becomes critical. Add debug facility to the driver which
> can isolate Smart PC and TA
On Sat, 30 Sep 2023, Shyam Sundar S K wrote:
> PMF driver based on the output actions from the TA can request to update
> the system states like entering s0i3, lock screen etc. by generating
> an uevent. Based on the udev rules set in the userspace the event id
> matching the uevent shall get
On Sat, 30 Sep 2023, Shyam Sundar S K wrote:
> PMF driver sends changing inputs from each subystem to TA for evaluating
> the conditions in the policy binary.
>
> Add initial support of plumbing in the PMF driver for Smart PC to get
> information from other subsystems in the kernel.
>
>
On 10/3/23 15:53, Harry Wentland wrote:
On 2023-09-21 10:15, Sebastian Andrzej Siewior wrote:
This is a revert of the commit mentioned below while it is not wrong, as
in the kernel will explode, having migrate_disable() here it is
complete waste of resources.
Additionally commit message is
Take the mcr lock only when driver needs to write into a mcr based
tlb based registers.
To prevent GT reset interference, employ gt->reset.mutex instead, since
intel_gt_mcr_multicast_write relies on gt->uncore->lock not being held.
v2: remove unused var, flags.
Signed-off-by: Nirmoy Das
---
On Sat, 30 Sep 2023, Shyam Sundar S K wrote:
> PMF TA (Trusted Application) loads via the TEE environment into the
> AMD ASP.
>
> PMF-TA supports two commands:
> 1) Init: Initialize the TA with the PMF Smart PC policy binary and
> start the policy engine. A policy is a combination of inputs and
On Sat, 30 Sep 2023, Shyam Sundar S K wrote:
> PMF Policy binary is a encrypted and signed binary that will be part
> of the BIOS. PMF driver via the ACPI interface checks the existence
> of Smart PC bit. If the advertised bit is found, PMF driver walks
> the acpi namespace to find out the policy
Take the mcr lock only when driver needs to write into a mcr based
tlb based registers.
To prevent GT reset interference, employ gt->reset.mutex instead, since
intel_gt_mcr_multicast_write relies on gt->uncore->lock not being held.
Signed-off-by: Nirmoy Das
---
On Sat, 30 Sep 2023, Shyam Sundar S K wrote:
> AMD PMF driver loads the PMF TA (Trusted Application) into the AMD
> ASP's (AMD Security Processor) TEE (Trusted Execution Environment).
>
> PMF Trusted Application is a secured firmware placed under
> /lib/firmware/amdtee gets loaded only when the
On Fri, 29 Sep 2023 19:14:26 +0100
Adrián Larumbe wrote:
> This patch series adds fdinfo support to the Panfrost DRM driver. It will
> display a series of key:value pairs under /proc/pid/fdinfo/fd for render
> processes that open the Panfrost DRM file.
>
> The pairs contain basic drm gpu engine
On Sat, 30 Sep 2023, Shyam Sundar S K wrote:
> In the current code, the metrics table information was required only
> for auto-mode or CnQF at a given time. Hence keeping the return type
> of amd_pmf_set_dram_addr() as static made sense.
>
> But with the addition of Smart PC builder feature, the
On Sat, 30 Sep 2023, Shyam Sundar S K wrote:
> PMF TA (Trusted Application) loads via the TEE environment into the
> AMD ASP.
>
> PMF-TA supports two commands:
> 1) Init: Initialize the TA with the PMF Smart PC policy binary and
> start the policy engine. A policy is a combination of inputs and
On Sat, 30 Sep 2023, Shyam Sundar S K wrote:
> AMD PMF driver loads the PMF TA (Trusted Application) into the AMD
> ASP's (AMD Security Processor) TEE (Trusted Execution Environment).
>
> PMF Trusted Application is a secured firmware placed under
> /lib/firmware/amdtee gets loaded only when the
On 04/10/2023 10:43, Andi Shyti wrote:
The MCR steering semaphore is a shared lock entry between i915
and various firmware components.
Getting the lock might sinchronize on some shared resources.
Sometimes though, it might happen that the firmware forgets to
unlock causing unnecessary noise
> -Original Message-
> From: Manna, Animesh
> Sent: Thursday, September 21, 2023 11:44 AM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Nikula, Jani ;
> Hogander, Jouni ; Murthy, Arun R
> ; Manna, Animesh
> Subject: [PATCH v6 3/6] drm/i915/panelreplay:
> -Original Message-
> From: Manna, Animesh
> Sent: Thursday, September 21, 2023 11:44 AM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Nikula, Jani ;
> Hogander, Jouni ; Murthy, Arun R
> ; Manna, Animesh
> Subject: [PATCH v6 6/6] drm/i915/panelreplay:
> -Original Message-
> From: Manna, Animesh
> Sent: Thursday, September 21, 2023 11:44 AM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Nikula, Jani ;
> Hogander, Jouni ; Murthy, Arun R
> ; Manna, Animesh
> Subject: [PATCH v6 5/6] drm/i915/panelreplay:
The MCR steering semaphore is a shared lock entry between i915
and various firmware components.
Getting the lock might sinchronize on some shared resources.
Sometimes though, it might happen that the firmware forgets to
unlock causing unnecessary noise in the driver which keeps doing
what was
On 2023-10-03 15:53:41 [-0400], Harry Wentland wrote:
> On 2023-09-21 10:15, Sebastian Andrzej Siewior wrote:
> > This is a revert of the commit mentioned below while it is not wrong, as
> > in the kernel will explode, having migrate_disable() here it is
> > complete waste of resources.
> >
> >
> -Original Message-
> From: Manna, Animesh
> Sent: Thursday, September 21, 2023 11:44 AM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Nikula, Jani ;
> Hogander, Jouni ; Murthy, Arun R
>
> Subject: [PATCH v6 2/6] drm/i915/psr: Move psr specific dpcd init
On 2023-10-03 15:54:58 [-0400], Harry Wentland wrote:
> On 2023-10-02 06:58, Sebastian Andrzej Siewior wrote:
> > On 2023-09-22 07:33:26 [+0200], Christian König wrote:
> >> Am 21.09.23 um 16:15 schrieb Sebastian Andrzej Siewior:
> >>> Hi,
> >>>
> >>> I stumbled uppon the amdgpu driver via a
> -Original Message-
> From: Manna, Animesh
> Sent: Thursday, September 21, 2023 11:44 AM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Nikula, Jani ;
> Hogander, Jouni ; Murthy, Arun R
> ; Manna, Animesh
> Subject: [PATCH v6 1/6] drm/panelreplay: dpcd
On Wed, Oct 4, 2023 at 4:32 PM Chen-Yu Tsai wrote:
>
> The MediaTek DRM driver implements GEM PRIME vmap by fetching the
> sg_table for the object, iterating through the pages, and then
> vmapping them. In essence, unlike the GEM DMA helpers which vmap
> when the object is first created or
The MediaTek DRM driver implements GEM PRIME vmap by fetching the
sg_table for the object, iterating through the pages, and then
vmapping them. In essence, unlike the GEM DMA helpers which vmap
when the object is first created or imported, the MediaTek version
does it on request.
Unfortunately,
Il 04/10/23 04:40, Jason-JH.Lin ha scritto:
Add dynamic select available connector flow in mtk_drm_crtc_create()
and mtk_drm_crtc_atomic_enable().
In mtk_drm_crtc_create(), if there is a connector routes array in drm
driver data, all components definded in the connector routes array will
be
1 - 100 of 109 matches
Mail list logo
