On 2020-10-30 08:04, Daniel Vetter wrote:
> On Fri, Oct 30, 2020 at 11:41 AM Liu, Monk wrote:
>>
>> [AMD Official Use Only - Internal Distribution Only]
>>
>> What's the purpose of the patch sets
>>
>> e.g.: what bug can those 5 patches fix or what feature provided
>>
>> for this particular one (3
On Fri, Oct. 30, 2020, 5:35 p.m., Matt Roper wrote:
>On Fri, Oct 30, 2020 at 09:41:37PM +0800, Lee Shawn C wrote:
>> After boot into kernel. Driver configured ddc pin mapping based on
>> predefined table in parse_ddi_port(). Now driver configure rkl ddc pin
>> mapping depends on icp_ddc_pin_map
> On Oct 29, 2020, at 10:21 PM, Zhenyu Wang wrote:
>
> On 2020.10.28 11:18:45 +, Vivi, Rodrigo wrote:
>
>>
>> I'm actually pulling it off. I had bypassed dim, considering this was an old
>> issue with our email decoder,
>> but it happens that
>>
>> $ git show 401ccfa87856 | grep Fixes
== Series Details ==
Series: drm/i915: ilk+ wm cleanups
URL : https://patchwork.freedesktop.org/series/83289/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9229_full -> Patchwork_18817_full
Summary
---
**WARNING**
== Series Details ==
Series: drm/i915/ehl: Remove invalid PCI ID
URL : https://patchwork.freedesktop.org/series/83292/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9230 -> Patchwork_18820
Summary
---
**FAILURE**
Update the EHL PCI IDs from BSpec.
Remove the invalid ones.
Cc: Ville Syrjälä
Signed-off-by: Anusha Srivatsa
---
include/drm/i915_pciids.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 3b5ed1e4f3ec..28428e08a8d3 100644
--- a/inclu
== Series Details ==
Series: drm/i915: Sort EHL/JSL PCI IDs
URL : https://patchwork.freedesktop.org/series/83288/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9229_full -> Patchwork_18816_full
Summary
---
**FAILURE*
Hi Ville,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip v5.10-rc1 next-20201030]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
== Series Details ==
Series: drm/i915: Reduce severity for fixing up mistaken VBT tc->legacy_port
URL : https://patchwork.freedesktop.org/series/83286/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9229_full -> Patchwork_18815_full
=
On Fri, Oct 30, 2020 at 07:34:01PM +, Srivatsa, Anusha wrote:
>
>
> > -Original Message-
> > From: Ville Syrjala
> > Sent: Friday, October 30, 2020 9:41 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Srivatsa, Anusha
> > Subject: [PATCH v2] drm/i915: Sort EHL/JSL PCI IDs
> >
>
> -Original Message-
> From: Ville Syrjala
> Sent: Friday, October 30, 2020 9:41 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Srivatsa, Anusha
> Subject: [PATCH v2] drm/i915: Sort EHL/JSL PCI IDs
>
> From: Ville Syrjälä
>
> Sort the EHL/JSL PCI IDs numerically. Some order seems bet
== Series Details ==
Series: drm/i915/rkl: new rkl ddc map for different PCH (rev2)
URL : https://patchwork.freedesktop.org/series/83154/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9229_full -> Patchwork_18814_full
Summa
On Fri, Oct 30, 2020 at 6:11 AM Daniel Vetter wrote:
>
> It's nice if a big function/ioctl table like this is const. Only
> downside here is that we need a few more #ifdef to paper over the
> differences when CONFIG_DRM_LEGACY is enabled. Maybe provides more
> motivation to sunset that horror show
On Fri, Oct 30, 2020 at 6:11 AM Daniel Vetter wrote:
>
> Only the following drivers aren't converted:
> - amdgpu, because of the driver_feature mangling due to virt support
> - nouveau, because DRIVER_ATOMIC uapi is still not the default on the
> platforms where it's supported (i.e. again driver
On Fri, Oct 30, 2020 at 6:11 AM Daniel Vetter wrote:
>
> Prep work to make drm_device->driver const.
>
> Signed-off-by: Daniel Vetter
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: Evan Quan
> Cc: Felix Kuehling
> Cc: Hawking Zhang
> Cc: Andrey Grodzovsky
> Cc: Luben Tuikov
> Cc: Thomas
== Series Details ==
Series: drm/i915/gvt: use DEFINE_DEBUGFS_ATTRIBUTE with
debugfs_create_file_unsafe()
URL : https://patchwork.freedesktop.org/series/83291/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9229 -> Patchwork_18818
==
== Series Details ==
Series: series starting with [1/5] drm/radeon: Stop changing the drm_driver
struct (rev2)
URL : https://patchwork.freedesktop.org/series/83262/
State : failure
== Summary ==
Applying: drm/radeon: Stop changing the drm_driver struct
Applying: drm: Compile out legacy chunks
On Fri, Oct 30, 2020 at 6:11 AM Daniel Vetter wrote:
>
> This means some very few #ifdef in code, but it allows us to
> enlist the compiler to make sure this stuff isn't used anymore.
>
> More important, only legacy drivers change drm_device (for the
> legacy_dev_list shadow attach management), th
On Fri, Oct 30, 2020 at 6:11 AM Daniel Vetter wrote:
>
> With only the kms driver left, we can fold this in. This means
> we need to move the ioctl table, which means one additional ioctl
> must be defined in headers.
>
> Also there's a conflict between the radeon_init macro and the module
> init
== Series Details ==
Series: drm/i915: ilk+ wm cleanups
URL : https://patchwork.freedesktop.org/series/83289/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9229 -> Patchwork_18817
Summary
---
**SUCCESS**
No regres
== Series Details ==
Series: drm/i915: ilk+ wm cleanups
URL : https://patchwork.freedesktop.org/series/83289/
State : warning
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
CHK include/generated/compile.h
CC [M] drivers/gpu/drm/i915/intel_pm.o
Using DEFINE_DEBUGFS_ATTRIBUTE macro with debugfs_create_file_unsafe()
function in place of the debugfs_create_file() function will make the
file operation struct "reset" aware of the file's lifetime. Additional
details here: https://lists.archive.carbon60.com/linux/kernel/2369498
Issue reported b
On 30/10/2020 10:17, Joonas Lahtinen wrote:
> + intel-gfx mailing list
>
> Quoting Joonas Lahtinen (2020-10-30 12:15:44)
>> Quoting Jonny Grant (2020-10-27 22:42:19)
>>> Hello Jani, Joonas
>>>
>>> https://gitlab.gnome.org/GNOME/eog/-/issues/146
>>>
>>> Is this issue something you could debug?
>
On 30/10/2020 10:54, Chris Wilson wrote:
> Quoting Joonas Lahtinen (2020-10-30 10:17:17)
>> + intel-gfx mailing list
>>
>> Quoting Joonas Lahtinen (2020-10-30 12:15:44)
>>> Quoting Jonny Grant (2020-10-27 22:42:19)
Hello Jani, Joonas
https://gitlab.gnome.org/GNOME/eog/-/issues/146
[AMD Official Use Only - Internal Distribution Only]
What's the purpose of the patch sets
e.g.: what bug can those 5 patches fix or what feature provided
for this particular one (3/5) I didn't see how it helpful, could you give a
background ?
thanks
_
Monk
== Series Details ==
Series: drm/i915: ilk+ wm cleanups
URL : https://patchwork.freedesktop.org/series/83289/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b3a6a0cd6f2b drm/i915: s/USHRT_MAX/U16_MAX/
0a33e58a3709 drm/i915: Shrink ilk-bdw wm storage by using u16
2fd87c0096c8 drm
== Series Details ==
Series: drm/i915: Sort EHL/JSL PCI IDs
URL : https://patchwork.freedesktop.org/series/83288/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9229 -> Patchwork_18816
Summary
---
**SUCCESS**
No re
On Fri, Oct 30, 2020 at 09:41:37PM +0800, Lee Shawn C wrote:
> After boot into kernel. Driver configured ddc pin mapping based on
> predefined table in parse_ddi_port(). Now driver configure rkl
> ddc pin mapping depends on icp_ddc_pin_map[]. Then this table will
> give incorrect gmbus port number
== Series Details ==
Series: drm/i915: Reduce severity for fixing up mistaken VBT tc->legacy_port
URL : https://patchwork.freedesktop.org/series/83286/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9229 -> Patchwork_18815
S
On Fri, Oct 30, 2020 at 06:48:12PM +0200, Imre Deak wrote:
> [...]
>
> Btw, if intel_pipe_config_compare() wouldn't show a mismatch for the
> PSR state (I suppose it doesn't) then intel_crtc_check_fastset() will
> reset mode_changed, so probably better to use connectors_changed.
Ah, nvm, PSR will
From: Ville Syrjälä
Rename ilk_pipe_wm to ilk_wm_state to match how things are
named for g4x/vlv.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_types.h| 8 +++---
drivers/gpu/drm/i915/intel_pm.c | 28 +--
2 files changed, 18 insertions(+
From: Ville Syrjälä
Give names to the SSKPD/MLTR fields, and use the
REG_GENMASK* and REG_FIELD_GET*.
Also drop the bogus non-mirrored SSKP register define.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 25 -
drivers/gpu/drm/i915/intel_pm.c | 24 ++
From: Ville Syrjälä
snb_wm_latency_quirk() already boosts up the latency values
so the extra warning about the SSKPD value being insufficient
is now redundant. Drop it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 2 --
drivers/gpu/drm/i915/intel_pm.c | 15 --
From: Ville Syrjälä
Rename the 'hw' thing to 'ilk' to make sure it's specific
to ilk+. We already have 'g4x' and 'vlv' next to it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 10 +-
2 files changed, 6 insertions(+), 6 dele
From: Ville Syrjälä
intel_atomic_crtc_state_for_each_plane_state() is causing some grief
for the bigjoiner stuff. To remedy that I want to eliminate
intel_atomic_crtc_state_for_each_plane_state() entirely so people
don't get any bright ideas about using it for anything new. To that
end let's star
From: Ville Syrjälä
We treat SSKPD as a 64 bit register. Add the support macros
to define/extract bits in such registers.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 57 +
1 file changed, 43 insertions(+), 14 deletions(-)
diff --git a/dri
From: Ville Syrjälä
Rename all the watermark related structs/enums specific to ilk-bdw
to have an ilk_ prefix rather than an intel_ prefix. Should make it
less confusing for everyone when it's clear where these things
get used.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_displa
From: Ville Syrjälä
Use REG_GENMASK() & co. for ilk+ watermarm registers.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_reg.h | 41 +++--
drivers/gpu/drm/i915/intel_pm.c | 59 +--
From: Ville Syrjälä
On ILK-IVB we must write the latency value read from SSKPD into
the latency field in the WM_LP registers. While bspec was never
clear on how the punit (or whatever) interprets these values
empirical evidence has shown that these are treated as a cookie
rather than as a literal
From: Ville Syrjälä
The maximum watermark value we can ever have on ilk-bdw is
11 bits. Thus we can safely store all of these values in
u16.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_types.h| 8 +-
drivers/gpu/drm/i915/intel_pm.c | 74 +-
From: Ville Syrjälä
We use u16 for the watermarks so let's switch from
USHRT_MAX to U16_MAX for consistency.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 44 -
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/
On Fri, Oct 30, 2020 at 06:26:06PM +0200, Souza, Jose wrote:
> On Thu, 2020-10-29 at 18:12 +0200, Imre Deak wrote:
> > On Wed, Oct 28, 2020 at 02:07:12PM -0700, José Roberto de Souza wrote:
> > > After commit 00e5deb5c4f5 ("drm/i915: Fix encoder lookup during PSR
> > > atomic check") dig_port was n
From: Ville Syrjälä
Sort the EHL/JSL PCI IDs numerically. Some order seems better than
randomness.
v2: Deal with the JSL vs. EHL split
Reviewed-by: Anusha Srivatsa #v1
Signed-off-by: Ville Syrjälä
---
include/drm/i915_pciids.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions
== Series Details ==
Series: drm/i915/rkl: new rkl ddc map for different PCH (rev2)
URL : https://patchwork.freedesktop.org/series/83154/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9229 -> Patchwork_18814
Summary
---
On Thu, 2020-10-29 at 18:12 +0200, Imre Deak wrote:
> On Wed, Oct 28, 2020 at 02:07:12PM -0700, José Roberto de Souza wrote:
> > After commit 00e5deb5c4f5 ("drm/i915: Fix encoder lookup during PSR
> > atomic check") dig_port was not being used but while fixing it I
> > realized that would be better
== Series Details ==
Series: drm/i915/rkl: new rkl ddc map for different PCH (rev2)
URL : https://patchwork.freedesktop.org/series/83154/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2114e70dca7c drm/i915/rkl: new rkl ddc map for different PCH
-:11: WARNING:UNKNOWN_COMMIT_ID:
On Fri, Oct 30, 2020 at 03:32:09PM +, Chris Wilson wrote:
> If the VBT assigned tc->legacy_port mismatches the live_status indicator
> for the connector, we ignore the VBT directive and switch over to the HW
> setting. This is not a driver error, unless we happen to misparse the
> VBT or the li
If the VBT assigned tc->legacy_port mismatches the live_status indicator
for the connector, we ignore the VBT directive and switch over to the HW
setting. This is not a driver error, unless we happen to misparse the
VBT or the live_status registers. However, for the system in CI where
the error is
On 10/16/20 12:44 PM, Maarten Lankhorst wrote:
Take the ww lock around engine_unpark. Because of the
many many places where rpm is used, I chose the safest option
and used a trylock to opportunistically take this lock for
__engine_unpark.
Signed-off-by: Maarten Lankhorst
---
Reviewed-by: Tho
On 10/16/20 12:44 PM, Maarten Lankhorst wrote:
Make creation separate from pinning, in order to take the lock only
once, and pin the mapping with the lock held.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 43 ++---
1 file changed, 33 in
On 10/16/20 12:44 PM, Maarten Lankhorst wrote:
We previously complained when ww == NULL.
This function is now only used in selftests to pin an object,
and ww locking is now fixed.
Signed-off-by: Maarten Lankhorst
---
Reviewed-by: Thomas Hellström
_
On 10/16/20 12:44 PM, Maarten Lankhorst wrote:
This should be done as part of the ww loop, in order to remove a
i915_vma_pin that needs ww held.
Now only i915_ggtt_pin() callers remaining.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
On 10/16/20 12:44 PM, Maarten Lankhorst wrote:
Take a simple lock so we hold ww around (un)pin_pages as needed.
Signed-off-by: Maarten Lankhorst
---
Reviewed-by: Thomas Hellström
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https:/
On 10/16/20 12:43 PM, Maarten Lankhorst wrote:
i915_vma_pin may fail with -EDEADLK when we start locking page tables,
so ensure we handle this correctly.
Signed-off-by: Maarten Lankhorst
When previous review comments addressed,
Reviewed-by: Thomas Hellström
__
On 10/16/20 12:44 PM, Maarten Lankhorst wrote:
Pin in the caller, not in the work itself. This should also
work better for dma-fence annotations.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 15 +++
1 file changed, 7 insertions(+), 8 deleti
On Fri, Oct 30, 2020 at 02:19:45PM +, Chris Wilson wrote:
> Quoting Ville Syrjala (2020-10-22 20:42:56)
> > From: Ville Syrjälä
> >
> > The new >8k CEA modes have dotclocks reaching 5.94 GHz, which
> > means our clock*1000 will now overflow the 32bit unsigned
> > integer. Switch to 64bit math
Quoting Ville Syrjala (2020-10-22 20:42:56)
> From: Ville Syrjälä
>
> The new >8k CEA modes have dotclocks reaching 5.94 GHz, which
> means our clock*1000 will now overflow the 32bit unsigned
> integer. Switch to 64bit maths to avoid it.
>
> Cc: sta...@vger.kernel.org
> Reported-by: Randy Dunlap
On 10/30/20 11:11 AM, Maarten Lankhorst wrote:
Op 30-10-2020 om 10:26 schreef Thomas Hellström (Intel):
On 10/16/20 12:43 PM, Maarten Lankhorst wrote:
We should not allow this any more, as it will break with the new userptr
implementation, it could still be made to work, but there's no point i
On 10/30/20 11:10 AM, Maarten Lankhorst wrote:
Op 30-10-2020 om 10:26 schreef Thomas Hellström (Intel):
On 10/16/20 12:43 PM, Maarten Lankhorst wrote:
We should not allow this any more, as it will break with the new userptr
implementation, it could still be made to work, but there's no point i
Hi, Maarten,
On 10/30/20 10:56 AM, Maarten Lankhorst wrote:
Op 30-10-2020 om 10:22 schreef Thomas Hellström (Intel):
On 10/16/20 12:43 PM, Maarten Lankhorst wrote:
Allow set_domain to fail silently, waiting for idle should be good enough.
set_tiling and set_caching are rejected with -ENXIO, th
On Wed, Oct 28, 2020 at 03:16:57PM -0700, Lucas De Marchi wrote:
> On Wed, Oct 28, 2020 at 11:33:21PM +0200, Ville Syrjälä wrote:
> >From: Ville Syrjälä
> >
> >Let's enable the hardware hpd logic only for the ports we
> >can actually use.
> >
> >In theory this may save some miniscule amounts of po
After boot into kernel. Driver configured ddc pin mapping based on
predefined table in parse_ddi_port(). Now driver configure rkl
ddc pin mapping depends on icp_ddc_pin_map[]. Then this table will
give incorrect gmbus port number to cause HDMI can't work.
Refer to commit d0a89527d06 ("drm/i915/rkl
== Series Details ==
Series: series starting with [1/5] drm/radeon: Stop changing the drm_driver
struct
URL : https://patchwork.freedesktop.org/series/83262/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9226_full -> Patchwork_18812_full
==
On Thu, Oct 22, 2020 at 05:17:00PM -0700, Aditya Swarup wrote:
> On 10/16/20 4:40 PM, Aditya Swarup wrote:
> > On 9/24/20 11:51 AM, Ville Syrjala wrote:
> >> From: Ville Syrjälä
> >>
> >> Reduce this maintenance nightmare a bit by converting the plane
> >> min/max width/height stuff into vfuncs.
>
On 29/10/2020 15:22, Daniel Vetter wrote:
> So ever since syzbot discovered fbcon, we have solid proof that it's
> full of bugs. And often the solution is to just delete code and remove
> features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code").
>
> Now the problem is that most modern-i
== Series Details ==
Series: series starting with [1/7] drm/i915/gt: Wrap
intel_timeline.has_initial_breadcrumb
URL : https://patchwork.freedesktop.org/series/83269/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9227 -> Patchwork_18813
On Fri, Oct 30, 2020 at 11:41 AM Liu, Monk wrote:
>
> [AMD Official Use Only - Internal Distribution Only]
>
> What's the purpose of the patch sets
>
> e.g.: what bug can those 5 patches fix or what feature provided
>
> for this particular one (3/5) I didn't see how it helpful, could you give a
>
== Series Details ==
Series: series starting with [1/7] drm/i915/gt: Wrap
intel_timeline.has_initial_breadcrumb
URL : https://patchwork.freedesktop.org/series/83269/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be ch
== Series Details ==
Series: series starting with [1/7] drm/i915/gt: Wrap
intel_timeline.has_initial_breadcrumb
URL : https://patchwork.freedesktop.org/series/83269/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a14ed43522cc drm/i915/gt: Wrap intel_timeline.has_initial_breadcr
== Series Details ==
Series: drm/i915: Tweaked Wa_14010685332 for PCHs used on gen11 platforms
URL : https://patchwork.freedesktop.org/series/83233/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9224_full -> Patchwork_18811_full
Add another lower level to emit_ggtt_write so that the GGTT nature of
the write is not hardcoded into the emitter.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine.h | 55 --
1 file changed, 35 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/d
A quick test to verify that the backend accepts each type of timeline
and can use them to track and control request emission.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_timeline.c | 89 +
1 file changed, 89 insertions(+)
diff --git a/drivers/gpu/drm/i91
Currently we know that the timeline status page is at most a page in
size, and so we can preserve the lower 12bits of the offset when
relocating the status page in the GGTT. If we want to use a larger
object, such as the context state, we may not necessarily use a position
within the first page and
Relative timelines are relative to either the global or per-process
HWSP, and so we can replace the absolute addressing with store-index
variants for position invariance.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 110 +++
drivers/gpu/drm/i915/
Explicitly differentiate between the absolute and relative timelines,
and the global HWSP and ppHWSP relative offsets. When using a timeline
that is relative to a known status page, we can replace the absolute
addressing in the commands with indexed variants.
Signed-off-by: Chris Wilson
---
driv
In preparation for removing the has_initial_breadcrumb field, add a
helper function for the existing callers.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +-
drivers/gpu/drm/i915/gt/intel_ring_submission.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_timeline.c
When we are not using semaphores with a context/engine, we can simply
reuse the same seqno location across wraps, but we still require each
timeline to have its own address. For LRC submission, each context is
prefixed by a per-process HWSP, which provides us with a unique location
for each context
== Series Details ==
Series: series starting with [1/5] drm/radeon: Stop changing the drm_driver
struct
URL : https://patchwork.freedesktop.org/series/83262/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9226 -> Patchwork_18812
Quoting Joonas Lahtinen (2020-10-30 10:17:17)
> + intel-gfx mailing list
>
> Quoting Joonas Lahtinen (2020-10-30 12:15:44)
> > Quoting Jonny Grant (2020-10-27 22:42:19)
> > > Hello Jani, Joonas
> > >
> > > https://gitlab.gnome.org/GNOME/eog/-/issues/146
> > >
> > > Is this issue something you co
== Series Details ==
Series: series starting with [1/5] drm/radeon: Stop changing the drm_driver
struct
URL : https://patchwork.freedesktop.org/series/83262/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked se
== Series Details ==
Series: series starting with [1/5] drm/radeon: Stop changing the drm_driver
struct
URL : https://patchwork.freedesktop.org/series/83262/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
db362a15426f drm/radeon: Stop changing the drm_driver struct
-:60: CHECK:
+ intel-gfx mailing list
Quoting Joonas Lahtinen (2020-10-30 12:15:44)
> Quoting Jonny Grant (2020-10-27 22:42:19)
> > Hello Jani, Joonas
> >
> > https://gitlab.gnome.org/GNOME/eog/-/issues/146
> >
> > Is this issue something you could debug?
>
> Can you file a bug according to the instructions
Only the following drivers aren't converted:
- amdgpu, because of the driver_feature mangling due to virt support
- nouveau, because DRIVER_ATOMIC uapi is still not the default on the
platforms where it's supported (i.e. again driver_feature mangling)
- vc4, again because of driver_feature mangli
Op 30-10-2020 om 10:26 schreef Thomas Hellström (Intel):
>
> On 10/16/20 12:43 PM, Maarten Lankhorst wrote:
>> We should not allow this any more, as it will break with the new userptr
>> implementation, it could still be made to work, but there's no point in
>> doing so.
>>
>> Signed-off-by: Maarte
Prep work to make drm_device->driver const.
Signed-off-by: Daniel Vetter
Cc: Alex Deucher
Cc: "Christian König"
Cc: Evan Quan
Cc: Felix Kuehling
Cc: Hawking Zhang
Cc: Andrey Grodzovsky
Cc: Luben Tuikov
Cc: Thomas Zimmermann
Cc: Monk Liu
Cc: Yintian Tao
Cc: Dennis Li
Cc: shaoyunl
Cc: B
It's nice if a big function/ioctl table like this is const. Only
downside here is that we need a few more #ifdef to paper over the
differences when CONFIG_DRM_LEGACY is enabled. Maybe provides more
motivation to sunset that horror show :-)
v2:
- Fix super important checkpatch warning (Sam)
- Updat
This means some very few #ifdef in code, but it allows us to
enlist the compiler to make sure this stuff isn't used anymore.
More important, only legacy drivers change drm_device (for the
legacy_dev_list shadow attach management), therefore this is
prep to allow modern drivers to have a const driv
With only the kms driver left, we can fold this in. This means
we need to move the ioctl table, which means one additional ioctl
must be defined in headers.
Also there's a conflict between the radeon_init macro and the module
init function, so rename the module functions to avoid that.
Signed-off
Op 30-10-2020 om 10:26 schreef Thomas Hellström (Intel):
>
> On 10/16/20 12:43 PM, Maarten Lankhorst wrote:
>> We should not allow this any more, as it will break with the new userptr
>> implementation, it could still be made to work, but there's no point in
>> doing so.
>>
>> Signed-off-by: Maarte
Op 30-10-2020 om 10:22 schreef Thomas Hellström (Intel):
>
> On 10/16/20 12:43 PM, Maarten Lankhorst wrote:
>> Allow set_domain to fail silently, waiting for idle should be good enough.
>> set_tiling and set_caching are rejected with -ENXIO, there's no valid reason
>> to allow it.
>
> Please list a
On Fri, 30 Oct 2020, Deepak R Varma wrote:
> Using DEFINE_DEBUGFS_ATTRIBUTE macro with debugfs_create_file_unsafe()
> function in place of the debugfs_create_file() function will make the
> file operation struct "reset" aware of the file's lifetime. Additional
> details here: https://lists.archive
On 10/16/20 12:44 PM, Maarten Lankhorst wrote:
Try to pin to ggtt first, and use a full ww loop to handle
eviction correctly.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 37 +++
1 file changed, 24 insertions(+), 13 deletions(-)
Revi
On 10/16/20 12:44 PM, Maarten Lankhorst wrote:
We map the initial context during first pin.
This allows us to remove pin_map from state allocation, which saves
us a few retry loops. We won't need this until first pin anyway.
intel_ring_submission_setup() is also reworked slightly to do all
pin
Quoting john.c.harri...@intel.com (2020-10-28 16:58:23)
> From: John Harrison
>
> Update to the latest GuC firmware
>
> v2: Rebase to newer tree, updated a commit message (review feedback
> from Daniele) and dropped the patch to enable GuC/HuC loading by
> default as apparently this is not allow
On 10/16/20 12:44 PM, Maarten Lankhorst wrote:
This allows us to remove pin_map from state allocation, which saves
us a few retry loops. We won't need this until first pin, anyway.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 13 ++-
drivers/gpu/drm/
On 10/16/20 12:43 PM, Maarten Lankhorst wrote:
With userptr fixed, there is no need for all separate lockdep classes
now, and we can remove all lockdep tricks used. A trylock in the
shrinker is all we need now to flatten the locking hierarchy.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Th
On 10/16/20 12:43 PM, Maarten Lankhorst wrote:
We should not allow this any more, as it will break with the new userptr
implementation, it could still be made to work, but there's no point in
doing so.
Signed-off-by: Maarten Lankhorst
Ifdefs don't appear consistent with the commit message.
On 10/16/20 12:43 PM, Maarten Lankhorst wrote:
Allow set_domain to fail silently, waiting for idle should be good enough.
set_tiling and set_caching are rejected with -ENXIO, there's no valid reason
to allow it.
Please list all affected ioctls affected by the IS_PROXY flag. We also
need user
On 10/16/20 12:43 PM, Maarten Lankhorst wrote:
It doesn't make sense to export a memory address, we will prevent
allowing access this way to different address spaces when we
rework userptr handling, so best to explicitly disable it.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellst
On 10/16/20 12:43 PM, Maarten Lankhorst wrote:
Userptr should not need the kernel for a userspace memcpy, userspace
needs to call memcpy directly.
Signed-off-by: Maarten Lankhorst
We need an ack from userspace maintainers that this is indeed not used
anywhere
besides igt.
Assuming there i
1 - 100 of 109 matches
Mail list logo
