On Mon, Sep 21, 2020 at 08:11:57PM +0100, Matthew Wilcox wrote:
> This is awkward. I'd like it if we had a vfree() variant which called
> put_page() instead of __free_pages(). I'd like it even more if we
> used release_pages() instead of our own loop that called put_page().
Note that we don't ne
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/i915/selftests/mock_gem_device.c
between commit:
9f9f4101fc98 ("drm/i915/selftests: Push the fake iommu device from the stack
to data")
from the drm-intel tree and commit:
cd01269d11a3 ("drm/i915/s
On 9/21/2020 5:38 PM, John Harrison wrote:
On 9/21/2020 17:24, Daniele Ceraolo Spurio wrote:
On 9/21/2020 10:54 AM, john.c.harri...@intel.com wrote:
From: John Harrison
The latest GuC firmware includes a number of interface changes that
require driver updates to match.
* Starting from Gen1
On 9/21/2020 17:24, Daniele Ceraolo Spurio wrote:
On 9/21/2020 10:54 AM, john.c.harri...@intel.com wrote:
From: John Harrison
The latest GuC firmware includes a number of interface changes that
require driver updates to match.
* Starting from Gen11, the ID to be provided to GuC needs to conta
On 9/21/2020 10:54 AM, john.c.harri...@intel.com wrote:
From: John Harrison
Rather than just saying 'GuC failed to load: -110', actually print out
the GuC status register and break it down into the individual fields.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_f
Hi Logan,
On 9/21/20 11:48 PM, Logan Gunthorpe wrote:
On 2020-09-20 12:36 a.m., Lu Baolu wrote:
Hi Logan,
On 2020/9/19 4:47, Logan Gunthorpe wrote:
Hi Lu,
On 2020-09-11 9:21 p.m., Lu Baolu wrote:
Tom Murphy has almost done all the work. His latest patch series was
posted here.
https://lo
On 9/21/2020 10:54 AM, john.c.harri...@intel.com wrote:
From: John Harrison
The latest GuC firmware includes a number of interface changes that
require driver updates to match.
* Starting from Gen11, the ID to be provided to GuC needs to contain
the engine class in bits [0..2] and the in
So if I understand this correctly, it sounds like that some Pixelbooks boot up
with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB set to a non-zero value, without the
panel actually having DPCD backlight controls enabled?
If I'm understanding that correctly, then this patch looks good to me:
Reviewed-by: Lyude
On 9/21/2020 13:36, Daniele Ceraolo Spurio wrote:
On 9/21/2020 12:22 PM, John Harrison wrote:
On 9/16/2020 23:48, Petri Latvala wrote:
On Wed, Sep 16, 2020 at 06:22:45PM -0700, John Harrison wrote:
Hello,
The failures below all appear to be because the new GuC firmware
was not
found on the
On Mon, Sep 14, 2020 at 12:21:26PM -0700, Navare, Manasi wrote:
> On Thu, Sep 03, 2020 at 10:23:35PM +0300, Ville Syrjälä wrote:
> > On Wed, Jul 15, 2020 at 03:42:21PM -0700, Manasi Navare wrote:
> > > From: Maarten Lankhorst
> > >
> > > Enabling is done in a special sequence and so should plane
On Mon, Sep 14, 2020 at 09:52:57PM +0300, Ville Syrjälä wrote:
> On Mon, Sep 14, 2020 at 11:32:48AM -0700, Navare, Manasi wrote:
> > On Mon, Sep 07, 2020 at 03:35:23PM +0300, Ville Syrjälä wrote:
> > > On Thu, Sep 03, 2020 at 09:40:44PM +0300, Ville Syrjälä wrote:
> > > > On Thu, Sep 03, 2020 at 11
On 9/21/2020 12:22 PM, John Harrison wrote:
On 9/16/2020 23:48, Petri Latvala wrote:
On Wed, Sep 16, 2020 at 06:22:45PM -0700, John Harrison wrote:
Hello,
The failures below all appear to be because the new GuC firmware was
not
found on the test system.
My understanding is that all we nee
== Series Details ==
Series: drm/i915/guc: Update to GuC v49
URL : https://patchwork.freedesktop.org/series/81906/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9027_full -> Patchwork_18542_full
Summary
---
**FAILURE
On Sat, Sep 19, 2020 at 06:39:06PM +0100, Matthew Wilcox wrote:
> On Sat, Sep 19, 2020 at 10:18:54AM -0700, Linus Torvalds wrote:
> > On Sat, Sep 19, 2020 at 2:50 AM Thomas Gleixner wrote:
> > >
> > > this provides a preemptible variant of kmap_atomic & related
> > > interfaces. This is achieved b
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:44 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 20/20] drm/i915: Add 10bit gamma mode for gen2/3
>
> From: Ville Syrjälä
>
> Some gen2/gen3 parts have a 10bi
On Mon, Sep 21 2020 at 09:24, Linus Torvalds wrote:
> On Mon, Sep 21, 2020 at 12:39 AM Thomas Gleixner wrote:
>>
>> If a task is migrated to a different CPU then the mapping address will
>> change which will explode in colourful ways.
>
> Right you are.
>
> Maybe we really *could* call this new km
On 9/16/2020 23:48, Petri Latvala wrote:
On Wed, Sep 16, 2020 at 06:22:45PM -0700, John Harrison wrote:
Hello,
The failures below all appear to be because the new GuC firmware was not
found on the test system.
My understanding is that all we need to do to get the CI system to update
with new f
On Fri, Sep 18, 2020 at 06:37:21PM +0200, Christoph Hellwig wrote:
> void shmem_unpin_map(struct file *file, void *ptr)
> {
> + long i = shmem_npages(file);
> +
> mapping_clear_unevictable(file->f_mapping);
> - __shmem_unpin_map(file, ptr, shmem_npte(file));
> + vunmap(ptr);
> +
== Series Details ==
Series: drm/i915/guc: Update to GuC v49
URL : https://patchwork.freedesktop.org/series/81906/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9027 -> Patchwork_18542
Summary
---
**WARNING**
Mino
== Series Details ==
Series: series starting with [1/6] zsmalloc: switch from alloc_vm_area to
get_vm_area (rev3)
URL : https://patchwork.freedesktop.org/series/81855/
State : failure
== Summary ==
Applying: zsmalloc: switch from alloc_vm_area to get_vm_area
error: sha1 information is lacking
On Mon, Sep 21, 2020 at 11:42:29AM -0700, Minchan Kim wrote:
> It seems zsmalloc is only customer the function so let's have the helper
> when we see another customer.
>
> If we don't have objection, I'd like to ask to Andrew fold this up.
Fine with me.
___
On Mon, Sep 21, 2020 at 08:17:08PM +0200, Christoph Hellwig wrote:
> On Mon, Sep 21, 2020 at 10:42:56AM -0700, Minchan Kim wrote:
> > IIRC, the problem was runtime pte popluating needs GFP_KERNEL but
> > zs_map_object API runs under non-preemtible section.
>
> Make sense.
>
> > > - area->vm = all
On Mon, 21 Sep 2020, Lyude Paul wrote:
> On Tue, 2020-09-01 at 21:01 +0300, Jani Nikula wrote:
>> I guess we can try without the change, and fix later if we hit issues.
>
> I'm fine with the change if it doesn't break things btw - just as long as
> we're making sure that we don't zero things out b
== Series Details ==
Series: drm/i915/guc: Update to GuC v49
URL : https://patchwork.freedesktop.org/series/81906/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a2bf36c707f0 drm/i915/guc: Update to use firmware v49.0.1
-:231: WARNING:LONG_LINE: line length of 103 exceeds 100 co
On Mon, Sep 21, 2020 at 10:42:56AM -0700, Minchan Kim wrote:
> IIRC, the problem was runtime pte popluating needs GFP_KERNEL but
> zs_map_object API runs under non-preemtible section.
Make sense.
> > - area->vm = alloc_vm_area(PAGE_SIZE * 2, NULL);
> > + area->vm = get_vm_area(PAGE_SIZE * 2,
On Tue, 2020-09-01 at 21:01 +0300, Jani Nikula wrote:
> On Tue, 01 Sep 2020, Lyude Paul wrote:
> > On Tue, 2020-09-01 at 15:32 +0300, Jani Nikula wrote:
> > > In the future, we'll be needing more of the extended receiver capability
> > > field starting at DPCD address 0x2200. (Specifically, we'll
From: John Harrison
Update to the latest GuC firmware and enable by default.
Signed-off-by: John Harrison
Daniele Ceraolo Spurio (1):
drm/i915/uc: turn on GuC/HuC auto mode by default
John Harrison (3):
drm/i915/guc: Update to use firmware v49.0.1
drm/i915/guc: Improved reporting when
From: John Harrison
The latest GuC firmware includes a number of interface changes that
require driver updates to match.
* Starting from Gen11, the ID to be provided to GuC needs to contain
the engine class in bits [0..2] and the instance in bits [3..6].
NOTE: this patch breaks pointer dere
From: John Harrison
Rather than just saying 'GuC failed to load: -110', actually print out
the GuC status register and break it down into the individual fields.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 27 ++-
1 file changed, 22 insertion
From: Daniele Ceraolo Spurio
This will enable HuC loading for Gen11+ by default if the binaries
are available on the system. GuC submission still requires explicit
enabling by the user.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/i915_params.h | 2 +-
1
From: John Harrison
Was hitting null pointers and similar issues when running various
module load/unload and inject failure type tests. So clear those
pointers down when the objects have been de-allocated.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 1 +
drive
== Series Details ==
Series: series starting with [1/6] zsmalloc: switch from alloc_vm_area to
get_vm_area (rev2)
URL : https://patchwork.freedesktop.org/series/81855/
State : failure
== Summary ==
Applying: zsmalloc: switch from alloc_vm_area to get_vm_area
error: sha1 information is lacking
== Series Details ==
Series: drm/i915: check i915_vm_alloc_pt_stash for errors
URL : https://patchwork.freedesktop.org/series/81901/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9027_full -> Patchwork_18540_full
Summary
--
On Fri, Sep 18, 2020 at 06:37:19PM +0200, Christoph Hellwig wrote:
> There is no obvious reason why zsmalloc needs to pre-fault the PTEs
> given that it later uses map_kernel_range to just like vmap().
IIRC, the problem was runtime pte popluating needs GFP_KERNEL but
zs_map_object API runs under n
Quoting Matthew Auld (2020-09-21 17:08:44)
> If we are really unlucky and encounter an error during
> i915_vm_alloc_pt_stash, we end up passing an empty pt/pd stash all the
> way down into the low-level ppgtt alloc code, leading to explosions,
> since it expects at least the required number of pt/p
== Series Details ==
Series: drm/i915: check i915_vm_alloc_pt_stash for errors
URL : https://patchwork.freedesktop.org/series/81901/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9027 -> Patchwork_18540
Summary
---
*
On Mon, Sep 21, 2020 at 12:39 AM Thomas Gleixner wrote:
>
> If a task is migrated to a different CPU then the mapping address will
> change which will explode in colourful ways.
Heh.
Right you are.
Maybe we really *could* call this new kmap functionality something
like "kmap_percpu()" (or maybe
If we are really unlucky and encounter an error during
i915_vm_alloc_pt_stash, we end up passing an empty pt/pd stash all the
way down into the low-level ppgtt alloc code, leading to explosions,
since it expects at least the required number of pt/pd for the va range.
[ 211.981418] BUG: kernel NUL
On 2020-09-20 12:36 a.m., Lu Baolu wrote:
> Hi Logan,
>
> On 2020/9/19 4:47, Logan Gunthorpe wrote:
>> Hi Lu,
>>
>> On 2020-09-11 9:21 p.m., Lu Baolu wrote:
>>> Tom Murphy has almost done all the work. His latest patch series was
>>> posted here.
>>>
>>> https://lore.kernel.org/linux-iommu/2020
Hi!
Since Daniel wanted a few thing to make it into 5.10, here's a final
drm-misc-next PR for this cycle :)
Thanks!
Maxime
drm-misc-next-2020-09-21:
drm-misc-next for 5.10:
UAPI Changes:
Cross-subsystem Changes:
Core Changes:
- dev: More devm_drm convertions and removal of drm_dev_init
Dri
First off, I think you all did a fantastic job. I felt that things
ran very smoothly and, as far as the talks themselves go, I think it
went almost as smoothly as an in-person XDC. I'm really quite
impressed. I do have a couple pieces of more nuanced feedback:
1. I think we were maybe a bit to
== Series Details ==
Series: Asynchronous flip implementation for i915 (rev12)
URL : https://patchwork.freedesktop.org/series/74386/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9027_full -> Patchwork_18539_full
Summary
--
On Tue, Sept. 15, 2020, 1:35 p.m. Ville Syrjälä wrote:
>On Tue, Sep 15, 2020 at 01:18:13PM +, Lee, Shawn C wrote:
>> On Fri, Sept. 11, 2020, 2:21 p.m. Ville Syrjälä wrote:
>> >On Thu, Aug 27, 2020 at 01:51:29PM +0800, Lee Shawn C wrote:
>> >> Customer report random display flicker issue on Nigh
On Tue, Sept. 15, 2020, 1:35 p.m. Ville Syrjälä wrote:
>On Tue, Sep 15, 2020 at 01:18:13PM +, Lee, Shawn C wrote:
>> On Fri, Sept. 11, 2020, 2:21 p.m. Ville Syrjälä wrote:
>> >On Thu, Aug 27, 2020 at 01:51:29PM +0800, Lee Shawn C wrote:
>> >> Customer report random display flicker issue on Nigh
Hi
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.8.10, v5.4.66, v4.19.146, v4.14.198,
v4.9.236, v4.4.236.
v5.8.10: Build OK!
v5.4
Hi all,
Huge thanks again to the entire team from Intel, for their great work
organizing XDC 2020, our first virtual conference!
As usual we're looking for feedback on both XDC itself, and the CFP
process and program selection. Both about what was great and should be
kept for next year's edition,
> +# ifndef ARCH_NEEDS_KMAP_HIGH_GET
> +static inline void *arch_kmap_temporary_high_get(struct page *page)
> +{
> + return NULL;
> +}
> +# endif
Turn this into a macro and use #ifndef on the symbol name?
> +static inline void __kunmap_atomic(void *addr)
> +{
> + kumap_atomic_indexed(addr
On Sat, Sep 19, 2020 at 11:17:52AM +0200, Thomas Gleixner wrote:
> Nothing in modules can use that.
>
> Signed-off-by: Thomas Gleixner
Looks good,
Reviewed-by: Christoph Hellwig
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists
== Series Details ==
Series: Asynchronous flip implementation for i915 (rev12)
URL : https://patchwork.freedesktop.org/series/74386/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9027 -> Patchwork_18539
Summary
---
*
== Series Details ==
Series: Asynchronous flip implementation for i915 (rev12)
URL : https://patchwork.freedesktop.org/series/74386/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/d
This hook is added to avoid writing other plane registers in case of
async flips, so that we do not write the double buffered registers
during async surface address update.
v7: -Plane ctl needs bits from skl_plane_ctl_crtc as well. (Ville)
-Add a vfunc for skl_program_async_surface_address
Enable asynchronous flips in i915 for gen9+ platforms.
v2: -Async flip enablement should be a stand alone patch (Paulo)
v3: -Move the patch to the end of the series (Paulo)
v4: -Rebased.
v5: -Rebased.
v6: -Rebased.
v7: -Rebased.
v8: -Rebased.
v9: -Rebased.
v10: -Rebased.
Signed-off-by: Ka
In Gen 9 and Gen 10 platforms, async address update enable bit is
double buffered. Due to this, during the transition from async flip
to sync flip we have to wait until this bit is updated before continuing
with the normal commit for sync flip.
v9: -Rename skl_toggle_async_sync() to skl_disable_as
Since the flip done event will be sent in the flip_done_handler,
no need to add the event to the list and delay it for later.
v2: -Moved the async check above vblank_get as it
was causing issues for PSR.
v3: -No need to wait for vblank to pass, as this wait was causing a
16ms delay once
If flip is requested on any other plane, reject it.
Make sure there is no change in fbc, offset and framebuffer modifiers
when async flip is requested.
If any of these are modified, reject async flip.
v2: -Replace DRM_ERROR (Paulo)
-Add check for changes in OFFSET, FBC, RC(Paulo)
v3: -Remov
Add the details of the implementation of asynchronous flips for i915.
v7: -Rebased.
v8: -Rebased.
v9: -Rebased.
v10: Move all documentation changes to this patch. (Ville)
Signed-off-by: Karthik B S
Signed-off-by: Vandita Kulkarni
Reviewed-by: Ville Syrjälä
---
Documentation/gpu/i915.rst
Add enable/disable flip done functions and the flip done handler
function which handles the flip done interrupt.
Enable the flip done interrupt in IER.
Enable flip done function is called before writing the
surface address register as the write to this register triggers
the flip done interrupt
F
Set the Async Address Update Enable bit in plane ctl
when async flip is requested.
v2: -Move the Async flip enablement to individual patch (Paulo)
v3: -Rebased.
v4: -Add separate plane hook for async flip case (Ville)
v5: -Rebased.
v6: -Move the plane hook to separate patch. (Paulo)
-Remov
Without async flip support in the kernel, fullscreen apps where game
resolution is equal to the screen resolution, must perform an extra blit
per frame prior to flipping.
Asynchronous page flips will also boost the FPS of Mesa benchmarks.
v2: -Few patches have been squashed and patches have been
On 9/18/2020 5:33 PM, Ville Syrjälä wrote:
On Wed, Sep 16, 2020 at 08:38:24PM +0530, Karthik B S wrote:
Enable asynchronous flips in i915 for gen9+ platforms.
v2: -Async flip enablement should be a stand alone patch (Paulo)
v3: -Move the patch to the end of the series (Paulo)
v4: -Rebased.
On 9/18/2020 5:28 PM, Ville Syrjälä wrote:
On Wed, Sep 16, 2020 at 08:38:23PM +0530, Karthik B S wrote:
Add the details of the implementation of asynchronous flips for i915.
v7: -Rebased.
v8: -Rebased.
v9: -Rebased.
Signed-off-by: Karthik B S
Signed-off-by: Vandita Kulkarni
---
Documen
On 9/18/2020 5:24 PM, Ville Syrjälä wrote:
On Wed, Sep 16, 2020 at 08:38:22PM +0530, Karthik B S wrote:
In Gen 9 and Gen 10 platforms, async address update enable bit is
double buffered. Due to this, during the transition from async flip
to sync flip we have to wait until this bit is updated b
On 9/18/2020 5:23 PM, Ville Syrjälä wrote:
On Fri, Sep 18, 2020 at 12:30:45PM +0530, Karthik B S wrote:
This hook is added to avoid writing other plane registers in case of
async flips, so that we do not write the double buffered registers
during async surface address update.
v7: -Plane ctl n
On 9/18/2020 5:21 PM, Ville Syrjälä wrote:
On Fri, Sep 18, 2020 at 02:32:34PM +0530, Karthik B S wrote:
If flip is requested on any other plane, reject it.
Make sure there is no change in fbc, offset and framebuffer modifiers
when async flip is requested.
If any of these are modified, reject
Op 18-09-2020 om 19:19 schreef Rodrigo Vivi:
> On Fri, Sep 18, 2020 at 01:12:08PM +0200, Maarten Lankhorst wrote:
>> In case backoff fails with an error, we return an undefined rq,
>> assign err to rq correctly.
>>
>> Fixes: 8a929c9eb1c2 ("drm/i915: Use ww pinning for
>> intel_context_create_reque
On Fri, Sep 18, 2020 at 01:12:21PM -0400, Rodrigo Vivi wrote:
> On Fri, Sep 18, 2020 at 11:03:12AM -0400, Alex Deucher wrote:
> > On Fri, Sep 18, 2020 at 9:25 AM Daniel Vetter
> > wrote:
> > >
> > > Hi all,
> > >
> > > These are the leftovers of the leftovers of my initial drmm series to
> > > ma
Quoting Zbigniew Kempczyński (2020-09-21 04:50:17)
> On !llc platforms when buffer is mapped with WB using GEM_MMAP_OFFSET
> pagefault handler clears its dirty flag. This has consequences
> buffer is not flushed on exec before moving to render domain.
> So make sure we keep dirty flag for buffers m
On Sun, Sep 20 2020 at 10:42, Linus Torvalds wrote:
> On Sun, Sep 20, 2020 at 10:40 AM Thomas Gleixner wrote:
>>
>> I think the more obvious solution is to split the whole exercise:
>>
>> schedule()
>> prepare_switch()
>> unmap()
>>
>> switch_to()
>>
>> finish_switch()
>>
On Mon, Sep 21, 2020 at 06:55:36AM +, Patchwork wrote:
>Patch Details
>
>Series: drm/i915: Ensure bo is dirty when WB-mapped on !llc in pagefault
>
> handler (rev2)
>
>URL: https://patchwork.freedesktop.or
69 matches
Mail list logo
