On Fri, Jan 27, 2023 at 01:31:54PM +, Tvrtko Ursulin
wrote:
> I think you missed the finish_suspend_scanning() part:
>
> if (root_drmcs.suspended_period_us)
> cancel_delayed_work_sync(_drmcs.scan_work);
>
> So if scanning was in progress migration will wait until it
On Wed 25-01-23 00:38:49, Suren Baghdasaryan wrote:
> Replace indirect modifications to vma->vm_flags with calls to modifier
> functions to be able to track flag changes and to keep vma locking
> correctness. Add a BUG_ON check in ksm_madvise() to catch indirect
> vm_flags modification attempts.
This laptop uses inverted backlight PWM. Thus, without this quirk,
backlight brightness decreases as the brightness value increases and
vice versa.
Signed-off-by: Mavroudis Chatzilaridis
---
drivers/gpu/drm/i915/display/intel_quirks.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
Hi Thomas!
Driver Changes:
* Remove obsolete drivers for userspace modesetting i810, mga, r128,
savage, sis, tdfx, via
Is the Rage 128 GPU still supported via the generic modesetting driver?
I'm asking because, we're still supporting PowerMacs in Debian Ports of which
some of those are
On Wed, Jan 25, 2023 at 1:30 AM 'Michal Hocko' via kernel-team
wrote:
>
> On Wed 25-01-23 00:38:48, Suren Baghdasaryan wrote:
> > Replace direct modifications to vma->vm_flags with calls to modifier
> > functions to be able to track flag changes and to keep vma locking
> > correctness.
>
> Is
On Thu, Jan 26, 2023 at 7:09 AM Matthew Wilcox wrote:
>
> On Thu, Jan 26, 2023 at 04:50:59PM +0200, Mike Rapoport wrote:
> > On Thu, Jan 26, 2023 at 11:17:09AM +0200, Mike Rapoport wrote:
> > > On Wed, Jan 25, 2023 at 12:38:46AM -0800, Suren Baghdasaryan wrote:
> > > > +/* Use when VMA is not
On Thu, Jan 26, 2023 at 04:50:59PM +0200, Mike Rapoport wrote:
> On Thu, Jan 26, 2023 at 11:17:09AM +0200, Mike Rapoport wrote:
> > On Wed, Jan 25, 2023 at 12:38:46AM -0800, Suren Baghdasaryan wrote:
> > > +/* Use when VMA is not part of the VMA tree and needs no locking */
> > > +static inline
On Fri, Jan 27, 2023 at 11:40:58AM +, Tvrtko Ursulin
wrote:
> The main point is, should someone prove me wrong and come up a smarter way
> at some point in the future, then "drm.weight" as an ABI remains compatible
> and the improvement can happen completely under the hood. In the mean time
Hello Tvrtko.
Interesting work.
On Thu, Jan 12, 2023 at 04:55:57PM +, Tvrtko Ursulin
wrote:
> Because of the heterogenous hardware and driver DRM capabilities, soft limits
> are implemented as a loose co-operative (bi-directional) interface between the
> controller and DRM core.
IIUC,
On Wed, Jan 25, 2023 at 12:38:46AM -0800, Suren Baghdasaryan wrote:
> +/* Use when VMA is not part of the VMA tree and needs no locking */
> +static inline void init_vm_flags(struct vm_area_struct *vma,
> + unsigned long flags)
> +{
> + vma->vm_flags = flags;
On Wed, Jan 25, 2023 at 12:38:50AM -0800, Suren Baghdasaryan wrote:
> In cases when VMA flags are modified after VMA was isolated and mmap_lock
> was downgraded, flags modifications would result in an assertion because
> mmap write lock is not held.
> Introduce mod_vm_flags_nolock to be used in
On Wed 25-01-23 00:38:46, Suren Baghdasaryan wrote:
> vm_flags are among VMA attributes which affect decisions like VMA merging
> and splitting. Therefore all vm_flags modifications are performed after
> taking exclusive mmap_lock to prevent vm_flags updates racing with such
> operations.
On Wed, Jan 25, 2023 at 1:10 AM Peter Zijlstra wrote:
>
> On Wed, Jan 25, 2023 at 12:38:46AM -0800, Suren Baghdasaryan wrote:
>
> > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> > index 2d6d790d9bed..6c7c70bf50dd 100644
> > --- a/include/linux/mm_types.h
> > +++
On Wed, Jan 25, 2023 at 06:11:35PM +, Tvrtko Ursulin
wrote:
> I don't immediately see how you envisage the half-userspace implementation
> would look like in terms of what functionality/new APIs would be provided by
> the kernel?
Output:
drm.stat (with consumed time(s))
Input:
Replace direct modifications to vma->vm_flags with calls to modifier
functions to be able to track flag changes and to keep vma locking
correctness.
Signed-off-by: Suren Baghdasaryan
---
arch/arm/kernel/process.c | 2 +-
arch/ia64/mm/init.c
On Wed, Jan 25, 2023 at 12:38:48AM -0800, Suren Baghdasaryan wrote:
> Replace direct modifications to vma->vm_flags with calls to modifier
> functions to be able to track flag changes and to keep vma locking
> correctness.
>
> Signed-off-by: Suren Baghdasaryan
Acked-by: Mike Rapoport (IBM)
>
On Wed, Jan 25, 2023 at 10:33 AM Matthew Wilcox wrote:
>
> On Wed, Jan 25, 2023 at 12:38:46AM -0800, Suren Baghdasaryan wrote:
> > +/* Use when VMA is not part of the VMA tree and needs no locking */
> > +static inline void init_vm_flags(struct vm_area_struct *vma,
> > +
On Wed 25-01-23 00:38:50, Suren Baghdasaryan wrote:
> In cases when VMA flags are modified after VMA was isolated and mmap_lock
> was downgraded, flags modifications would result in an assertion because
> mmap write lock is not held.
> Introduce mod_vm_flags_nolock to be used in such situation.
>
On Wed, Jan 25, 2023 at 12:38:46AM -0800, Suren Baghdasaryan wrote:
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 2d6d790d9bed..6c7c70bf50dd 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -491,7 +491,13 @@ struct vm_area_struct {
>
This patchset was originally published as a part of per-VMA locking [1] and
was split after suggestion that it's viable on its own and to facilitate
the review process. It is now a preprequisite for the next version of per-VMA
lock patchset, which reuses vm_flags modifier functions to lock the VMA
When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time. To make things simpler, just
call debugfs_lookup_and_remove() instead which handles all of the logic
at once.
Cc: Zhenyu Wang
Cc: Zhi Wang
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc:
== Series Details ==
Series: drm/i915/dmc: some dmc id related fixes and cleanups
URL : https://patchwork.freedesktop.org/series/113596/
State : warning
== Summary ==
Error: dim checkpatch failed
20fa69323f49 drm/i915/dmc: add proper name to dmc id enum and use it
b2de2d242648 drm/i915/dmc:
== Series Details ==
Series: Fix logic to get slice_height for dp
URL : https://patchwork.freedesktop.org/series/113594/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12683 -> Patchwork_113594v1
Summary
---
Hi Dave and Daniel,
Here goes this week's fixes with couple targeting stable.
drm-intel-fixes-2023-02-02:
- Fixes for potential use-after-free and double-free (Rob)
- GuC locking and refcount fixes (John)
- Display's reference clock value fix (Chaitanya)
Thanks,
Rodrigo.
The following changes
On Thu, 02 Feb 2023, Suraj Kandpal wrote:
> According to Bpec: 49259 VDSC spec implies that 108 lines is an optimal
> slice height, but any size can be used as long as vertical active
> integer multiple and maximum vertical slice count requirements are met.
The commit message and subject should
On 2/1/23 11:10 PM, Tian, Kevin wrote:
>> From: Alex Williamson
>> Sent: Thursday, February 2, 2023 7:28 AM
>>>
>>> +#ifdef CONFIG_HAVE_KVM
>>> +static bool vfio_kvm_get_kvm_safe(struct vfio_device *device, struct kvm
>> *kvm)
>>
>> I'm tempted to name these vfio_device_get_kvm_safe() and only
On Thu, 02 Feb 2023, Suraj Kandpal wrote:
> According to bspec :49259 VDSC spec implies that 108 lines is an optimal
> slice height, but any size can be used as long as vertical active
> integer multiple and maximum vertical slice count requirements are met.
> Add a fix in this patch to go for
There is a spelling mistake in a literal string. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/gvt/firmware.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gvt/firmware.c
b/drivers/gpu/drm/i915/gvt/firmware.c
index
drm-tip drm-tip
> patch link:
> https://lore.kernel.org/r/20230131150548.1614458-12-imre.deak%40intel.com
> patch subject: [PATCH v2 11/17] drm/display/dp_mst: Add helpers to query for
> payload allocation errors
> config: x86_64-randconfig-m001
> (https://download.01.org/0day
%40intel.com
patch subject: [PATCH v2 11/17] drm/display/dp_mst: Add helpers to query for
payload allocation errors
config: x86_64-randconfig-m001
(https://download.01.org/0day-ci/archive/20230202/202302021855.yyqieq2o-...@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-8) 11.3.0
If you fix the issue
Add validity checks for the dmc ids computed from pipe parameters in
intel_dmc_enable_pipe() and intel_dmc_disable_pipe(). It's slightly
difficult for humans and static analyzers alike to ensure the resulting
dmc ids are within bounds. Just check them and reject invalid ones.
Signed-off-by: Jani
Add a name to the dmc id validity check.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dmc.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index
The dmc_id comes from for_each_dmc_id() in parse_dmc_fw() ->
parse_dmc_fw_header() -> dmc_mmio_addr_sanity_check(). It's valid by
definition.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dmc.c | 5 -
1 file changed, 5 deletions(-)
diff --git
The loop is duplicated many times, with slightly different ways. Unify.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dmc.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
Clarify DMC ID usage by adding enum intel_dmc_id name to the enum, and
use dmc_id as the variable name for it throughout.
Convert a switch-case to if-ladder to avoid warnings about not handling
DMC_FW_MAX enumeration constant in the switch-case.
Signed-off-by: Jani Nikula
---
Address some static analyzer complaints around dmc id usage.
Jani Nikula (5):
drm/i915/dmc: add proper name to dmc id enum and use it
drm/i915/dmc: add for_each_dmc_id() and use it
drm/i915/dmc: remove unnecessary dmc_id validity check
drm/i915/dmc: add is_valid_dmc_id() and use it
According to Bpec: 49259 VDSC spec implies that 108 lines is an optimal
slice height, but any size can be used as long as vertical active
integer multiple and maximum vertical slice count requirements are met.
Cc: Ankit Nautiyal
Cc: Swati Sharma
Signed-off-by: Suraj Kandpal
diff --git
According to bspec :49259 VDSC spec implies that 108 lines is an optimal
slice height, but any size can be used as long as vertical active
integer multiple and maximum vertical slice count requirements are met.
Add a fix in this patch to go for most optimal lines and move ahead from
there instead
> -Original Message-
> From: Ville Syrjälä
> Sent: Thursday, February 2, 2023 2:54 PM
> To: Murthy, Arun R
> Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville
> Subject: Re: [Intel-gfx] [PATCHv3] drm/i915: Support Async Flip on Linear
> buffers
>
> On Thu, Feb 02, 2023 at 06:51:49AM
On 2/2/23 11:28 AM, Andi Shyti wrote:
Hi GG,
On Thu, Feb 02, 2023 at 10:22:30AM +0200, Gwan-gyeong Mun wrote:
Hi Andi,
You gave a lot of explanations, and confirmed that this patch solves the
problem, but the root cause of this problem still seems to be unclear.
In the logs where this
== Series Details ==
Series: We need to have additional checks for DP MST UHBR (rev2)
URL : https://patchwork.freedesktop.org/series/112876/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12681 -> Patchwork_112876v2
Summary
Hi Janusz,
On 2023-02-01 at 20:16:11 +0100, Janusz Krzysztofik wrote:
> Hi Kamil,
>
> On Wednesday, 1 February 2023 19:21:57 CET Kamil Konieczny wrote:
> > Hi Janusz,
> >
> > please send patches to igt ML and add other addresses to cc:
> > I have one nit, see below.
> >
> > On 2023-01-31 at
On Wed, 01 Feb 2023, Ville Syrjälä wrote:
> On Wed, Feb 01, 2023 at 09:26:29AM -0800, Lucas De Marchi wrote:
>> On Wed, Feb 01, 2023 at 02:09:54PM +0200, Ville Syrjälä wrote:
>> >On Wed, Feb 01, 2023 at 11:59:19AM +0200, Jani Nikula wrote:
>> >> On Tue, 31 Jan 2023, Lucas De Marchi wrote:
>> >>
== Series Details ==
Series: drm/i915: Consolidate TLB invalidation flow (rev2)
URL : https://patchwork.freedesktop.org/series/113563/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12681 -> Patchwork_113563v2
Summary
On Thu, 02 Feb 2023, Stanislav Lisovskiy wrote:
> According to spec, we should check if output_bpp * pixel_rate is less
> than DDI clock * 72, if UHBR is used.
>
> HSDES: 1406899791
> BSPEC: 49259
>
> v2: - Removed wrong comment(Rodrigo Vivi)
> - Added HSDES to the commit msg(Rodrigo Vivi)
>
On Thu, 02 Feb 2023, Stanislav Lisovskiy wrote:
> There are might be multiple contraints which we need to check while
> determining
> if we can use desired compressed bpp, so might be good idea to add a special
> helper, so that we don't overcomplicate the main bpp calculation function.
It is,
According to spec, we should check if output_bpp * pixel_rate is less
than DDI clock * 72, if UHBR is used.
HSDES: 1406899791
BSPEC: 49259
v2: - Removed wrong comment(Rodrigo Vivi)
- Added HSDES to the commit msg(Rodrigo Vivi)
- Moved UHBR check to the MST specific code
v3: - Changed
According to BSpec UHBR might hit hw limitation which must be checked.
So this series adds first some generic checker function, which might
be used to add this or similar checks in future, then we introduce
that particular UHBR check.
Stanislav Lisovskiy (2):
drm/i915: Add generic constraint
There are might be multiple contraints which we need to check while determining
if we can use desired compressed bpp, so might be good idea to add a special
helper, so that we don't overcomplicate the main bpp calculation function.
Signed-off-by: Stanislav Lisovskiy
---
On 02.02.2023 09:33, Tvrtko Ursulin wrote:
On 02/02/2023 07:43, Andrzej Hajda wrote:
On 01.02.2023 17:51, Tvrtko Ursulin wrote:
[snip]
Btw - do you have any idea why the test is suppressed already?! CI told
me BAT was a success...
Except this patch, igt@i915_selftest@live@gt_tlb
Hi GG,
On Thu, Feb 02, 2023 at 10:22:30AM +0200, Gwan-gyeong Mun wrote:
> Hi Andi,
>
> You gave a lot of explanations, and confirmed that this patch solves the
> problem, but the root cause of this problem still seems to be unclear.
>
> In the logs where this problem was reported, the logs were
On Thu, Feb 02, 2023 at 06:51:49AM +, Murthy, Arun R wrote:
> Gentle Reminder!
> The patch is pending since a long time.
Please review the igt changes here:
https://patchwork.freedesktop.org/series/113525/
then we can actually test this (and any other new
modifier in the future).
>
>
== Series Details ==
Series: drm/i915/pxp: limit drm-errors or warnings on firmware API failures
URL : https://patchwork.freedesktop.org/series/113584/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12681 -> Patchwork_113584v1
Hi,
Here's this week drm-misc-fixes PR
Maxime
drm-misc-fixes-2023-02-02:
A fix for a non-unique CEC adapter name registration in vc4, a
regression breaking the display in ssd130x, a signaling bit issue in
dma-fence, a couple of fixes in nouveau for Turing and Ampere, and a
disable fix for the
On 02/02/2023 08:13, Alan Previn wrote:
MESA driver is creating protected context on every driver handle
initialization to query caps bit for app. So when running CI tests,
they are observing hundreds of drm_errors when enabling PXP
in .config but using SOC or BIOS configuration that cannot
looks good to me, but could you please add bpsec# to commit log?
Reviewed-by: Gwan-gyeong Mun
On 2/2/23 4:52 AM, Ashutosh Dixit wrote:
Previous documentation suggested that PL1 power limit is always
enabled. However we now find this not to be the case on some
platforms (such as ATSM).
On 02/02/2023 07:43, Andrzej Hajda wrote:
On 01.02.2023 17:51, Tvrtko Ursulin wrote:
[snip]
+static int intel_engine_init_tlb_invalidation(struct intel_engine_cs
*engine)
+{
+ static const union intel_engine_tlb_inv_reg gen8_regs[] = {
+ [RENDER_CLASS].reg = GEN8_RTCR,
+
From: Tvrtko Ursulin
As the logic for selecting the register and corresponsing values grew, the
code become a bit unsightly. Consolidate by storing the required values at
engine init time in the engine itself, and by doing so minimise the amount
of invariant platform and engine checks during
Hi Andi,
You gave a lot of explanations, and confirmed that this patch solves the
problem, but the root cause of this problem still seems to be unclear.
In the logs where this problem was reported, the logs were output in the
following order.
link
:
Hi Dave and Daniel,
here's the first PR for drm-misc-next-fixes for this release cycle.
Best regards
Thomas
drm-misc-next-fixes-2023-02-02:
Short summary of fixes pull:
A number of simple fixes throughout the DRM codebase.
The following changes since commit
MESA driver is creating protected context on every driver handle
initialization to query caps bit for app. So when running CI tests,
they are observing hundreds of drm_errors when enabling PXP
in .config but using SOC or BIOS configuration that cannot support
PXP sessions.
Update error handling
== Series Details ==
Series: vfio: fix deadlock between group lock and kvm lock (rev4)
URL : https://patchwork.freedesktop.org/series/113535/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12681 -> Patchwork_113535v4
101 - 162 of 162 matches
Mail list logo
