Hi,
Here's two fixes for gvt. One for missed locking and another for
firmware allocation change for late load.
Thanks
--
The following changes since commit 5e822e44cecec1ea48925630aa31dfac827fd202:
drm/i915/gvt: Fix guest boot warning (2019-12-17 11:19:58 +0800)
are available in the Git
> -Original Message-
> From: Laxminarayan Bharadiya, Pankaj
> Sent: Tuesday, February 4, 2020 1:35 PM
> To: Syrjala, Ville
> Cc: Jani Nikula ; dan...@ffwll.ch; Deak, Imre
> ; Vivi, Rodrigo ; intel-
> g...@lists.freedesktop.org; Shankar, Uma ; Laxminarayan
> Bharadiya, Pankaj
>
> -Original Message-
> From: Syrjala, Ville
> Sent: Friday, January 31, 2020 5:22 PM
> To: Jani Nikula
> Cc: Laxminarayan Bharadiya, Pankaj ;
> dan...@ffwll.ch; Deak, Imre ; Vivi, Rodrigo
> ; intel-gfx@lists.freedesktop.org; Shankar, Uma
>
> Subject: Re: RFC: pipe writeback design for
Hi Daniele,
On Tue, Feb 11, 2020 at 04:31:19PM -0800, Daniele Ceraolo Spurio wrote:
> We want to map uC-level checks to GuC/HuC-level ones. The mapping from
> the uC state to the GuC/HuC one follows the same pattern for all the
> functions:
>
> uc_xxx_guc() -> guc_is_yyy()
>
> So we can easily
Hi Daniele,
> + if (intel_uc_uses_huc(uc)) {
> + ret = intel_huc_init(huc);
are we ever going to call intel_huc_init() if
!intel_uc_uses_huc()? if not, why don't check intel_uc_uses_huc()
inside intel_huc_init()? just to avoid always the double "if".
Not a big deal though:
Hi Daniele,
On Tue, Feb 11, 2020 at 04:31:15PM -0800, Daniele Ceraolo Spurio wrote:
> The log struct is the only thing the function needs (apart from
> the seq_file), so we can pass just that instead of the whole dev_priv.
>
> v2: Split this change to its own patch (Michal)
>
> Signed-off-by:
Hi Daniele,
On Tue, Feb 11, 2020 at 04:31:16PM -0800, Daniele Ceraolo Spurio wrote:
> use intel_uc_uses_guc() directly instead, to be consistent in the way we
> check what we want to do with the GuC.
>
> v2: split guc_log_info changes to their own patch (Michal)
>
> Signed-off-by: Daniele
On 2/10/20 12:57 PM, Chris Wilson wrote:
To prevent the context from proceeding past the end of the request as we
unwind, we embed a semaphore into the footer of each request. (If the
context were to skip past the end of the request as we perform the
preemption, next time we reload the
We want to map uC-level checks to GuC/HuC-level ones. The mapping from
the uC state to the GuC/HuC one follows the same pattern for all the
functions:
uc_xxx_guc() -> guc_is_yyy()
So we can easily use a macro to autogenerate the functions via macros by
passing in the 2 mapped states.
v2: Split
To be able to differentiate the before and after of our commitment to
GuC submission, which will be used in follow-up patches to early set-up
the submission structures.
v2: move functions to guc_submission.h (Michal)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
---
In a follow up patch we will rely on the fact that the status always
moves away from "SELECTED" after the fetch is attempted to decide what
to do with the GuC.
v2: Split this change to its own patch (Michal)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: John Harrison
Cc:
use intel_uc_uses_guc_submission() directly instead, to be consistent in
the way we check what we want to do with the GuC.
v2: do not go through ctx->vm->gt, use i915->gt instead
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: John Harrison
Cc: Matthew Brost
Reviewed-by:
To be able to setup GuC submission functions during engine init we need
to commit to using GuC as soon as possible.
Currently, the only thing that can stop us from using the
microcontrollers once we've fetched the blobs is a fundamental
error (e.g. OOM); given that if we hit such an error we can't
We are quite trigger happy in cleaning up the firmware blobs, as we do
so from several error/fini paths in GuC/HuC/uC code. We do have the
__uc_cleanup_firmwares cleanup function, which unwinds
__uc_fetch_firmwares and is already called both from the error path of
gem_init and from
To enable GuC and HuC loading on all gen9+ CI machines.
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/i915_params.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index
The log struct is the only thing the function needs (apart from
the seq_file), so we can pass just that instead of the whole dev_priv.
v2: Split this change to its own patch (Michal)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: John Harrison
Cc: Matthew Brost
Reviewed-by:
Now that we can differentiate wants vs uses GuC/HuC, intel_uc_init is
restricted to running only if we have successfully fetched the required
blob(s) and are committed to using the microcontroller(s).
The only remaining thing that can go wrong in uc_init is the allocation
of GuC/HuC related
Addressed review comments on v2.
Cc: Chris Wilson
Cc: Michal Wajdeczko
Cc: John Harrison
Cc: Matthew Brost
Daniele Ceraolo Spurio (10):
drm/i915/debugfs: Pass guc_log struct to i915_guc_log_info
drm/i915/guc: Kill USES_GUC macro
drm/i915/guc: Kill USES_GUC_SUBMISSION macro
use intel_uc_uses_guc() directly instead, to be consistent in the way we
check what we want to do with the GuC.
v2: split guc_log_info changes to their own patch (Michal)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: John Harrison
Cc: Matthew Brost
Reviewed-by: Michal
Disable Early Read and Src Swap (bit 14) by setting the chicken
register.
BSpec: 46045,52890
v2: Follow the Bspec implementation for the WA.
v3: Have 2 separate defines for bit 14 and 15.
- Rename register definitions with TGL_ prefix
v4: Bspec changed. Again. Add WA to rcs_ WA list.
Cc:
From: "Rafael J. Wysocki"
Call cpu_latency_qos_add/update/remove_request() instead of
pm_qos_add/update/remove_request(), respectively, because the
latter are going to be dropped.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki
---
drivers/gpu/drm/i915/display/intel_dp.c |
Hi Chris,
On Fri, Feb 07, 2020 at 03:17:20PM +, Chris Wilson wrote:
> We try hard to select a suitable hole in the drm_mm first time. But if
> that is unsuccessful, we then have to look at neighbouring nodes, and
> this requires traversing the rbtree. Walking the rbtree can be slow
> (much
Show the ring/request/context state if we see what we believe is an
early CS completion.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_context.c | 3 ++-
drivers/gpu/drm/i915/gt/intel_lrc.c | 31 +++--
2 files changed, 31 insertions(+), 3 deletions(-)
Hi Tvrtko,
> > +void intel_gt_sysfs_register(struct intel_gt *gt)
> > +{
> > + struct kobject *parent =
> > kobject_get(>i915->drm.primary->kdev->kobj);
>
> Does this needs a kobject_put to balance out somewhere?
Yes, I forgot the two kobject_put that are needed.
> > + int ret;
> > +
> >
On 2/11/20 11:57 AM, Michal Wajdeczko wrote:
On Tue, 11 Feb 2020 18:53:05 +0100, Fosha, Robert M
wrote:
On 2/4/20 4:43 PM, Ye, Tony wrote:
On 1/27/2020 1:41 AM, Michal Wajdeczko wrote:
On Thu, 23 Jan 2020 16:51:58 +0100, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2020-01-23
Hi,
I got a gpu hang, see attached, and the syslog instructed me to report
it to bugs.freedesktop.org. Since it is not possible to report bugs
there anymore (and I do not have an account) I hope, that this e-mail
also reaches the right people.
With best regards,
Julian
--
() ascii ribbon
Generated with make headers_install from drm-misc-next:
commit e62bf83aa1bb9d9953eec2e3663528c766b148ea
Author: Jani Nikula
Date: Tue Feb 11 16:47:53 2020 +0200
drm/irq: remove check on dev->dev_private
include/drm-uapi/drm_fourcc.h was not synced as the
From: Daniel Stone
Mirroring addfb2, add tests for the new ioctl which will return us
information about framebuffers containing multiple buffers, as well as
modifiers.
Changes since v5:
- Add documentation
Changes since v4:
- Remove unnecessary bo creation for getfb2-handle-closed subtest
On retiring the request, we should not re-use these elements in the ring
(at least not until we fill the ringbuffer and knowingly reuse the space).
Leave behind some poison to (hopefully) trap ourselves if we make a
mistake.
Suggested-by: Mika Kuoppala
Signed-off-by: Chris Wilson
Cc: Mika
Apply vast quantities of poison and not tell anyone to see if we fall
for the trap of using a stale RING_HEAD.
References: 42827350f75c ("drm/i915/gt: Avoid resetting ring->head outside of
its timeline mutex")
Signed-off-by: Chris Wilson
Cc: Andi Shyti
Cc: Mika Kuoppala
Reviewed-by: Mika
On Tue, Feb 11, 2020 at 10:41:48AM +0100, Michel Dänzer wrote:
> On 2020-02-11 7:13 a.m., Nathan Chancellor wrote:
> > A recent commit in clang added -Wtautological-compare to -Wall, which is
> > enabled for i915 so we see the following warning:
> >
> >
Tvrtko spotted a race condition between replacing a set of hanging
engines and closing the context. So exercise it.
5s is not much time to hit the small window, but a little bit of testing
several times a day is better than nothing.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
On 11/02/2020 18:10, Andi Shyti wrote:
From: Andi Shyti
The GT has its own properties and in sysfs they should be grouped
in the 'gt/' directory.
Create the 'gt/' directory in sysfs and move the power management
related files.
Signed-off-by: Andi Shyti
---
Hi,
this second version takes
On Tue, 11 Feb 2020 18:53:05 +0100, Fosha, Robert M
wrote:
On 2/4/20 4:43 PM, Ye, Tony wrote:
On 1/27/2020 1:41 AM, Michal Wajdeczko wrote:
On Thu, 23 Jan 2020 16:51:58 +0100, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2020-01-23 15:38:52)
On Thu, 23 Jan 2020 16:02:17 +0100,
On 11/02/2020 14:48, Chris Wilson wrote:
If we have a set of active engines marked as being non-persistent, we
lose track of those if the user replaces those engines with
I915_CONTEXT_PARAM_ENGINES. As part of our uABI contract is that
non-persistent requests are terminated if they are no
Tvrtko spotted a race condition between replacing a set of hanging
engines and closing the context. So exercise it.
5s is not much time to hit the small window, but a little bit of testing
several times a day is better than nothing.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
From: Andi Shyti
The GT has its own properties and in sysfs they should be grouped
in the 'gt/' directory.
Create the 'gt/' directory in sysfs and move the power management
related files.
Signed-off-by: Andi Shyti
---
Hi,
this second version takes into account the compatibility with the
The hotplug interruption detection was not being enabled for TC5 and
TC6 in the north detection side.
Cc: Matt Roper
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_irq.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c
Commit 1c9d2eb24153 ("drm/i915: move intel_dp_set_m_n() to encoder for
DDI platforms") moved the intel_dp_set_m_n() from hsw_crtc_enable()
to intel_ddi_pre_enable_dp() but it missed add it to
intel_mst_pre_enable_dp() causing MST slaves to not work.
v2: Not setting intel_ddi_set_dp_msa() twice
On Tue, Feb 11, 2020 at 08:10:27PM +0200, Andi Shyti wrote:
> From: Andi Shyti
>
> The GT has its own properties and in sysfs they should be grouped
> in the 'gt/' directory.
>
> Create the 'gt/' directory in sysfs and move the power management
> related files.
>
> Signed-off-by: Andi Shyti
>
According to Dell, trying to match their panels via OUI is not reliable
enough and we've been told that we should check against the EDID
instead. As well, Dell seems to have some panels that are actually
intended to switch between using PWM for backlight controls and DPCD for
backlight controls
The X1 Extreme is one of the systems that lies about which backlight
interface that it uses in its VBIOS as PWM backlight controls don't work
at all on this machine. It's possible that this panel could be one of
the infamous ones that can switch between PWM mode and DPCD backlight
control mode,
The whole point of using OUIs is so that we can recognize certain
devices and potentially apply quirks for them. Normally this should work
quite well, but there appears to be quite a number of laptop panels out
there that will fill the OUI but not the device ID. As such, for devices
like this I
Unfortunately, it turned out that the DPCD is also not a reliable way of
probing for DPCD backlight support as some panels will lie and say they
have DPCD backlight controls when they don't actually.
So, revert back to the old behavior and add a bunch of EDID-based DP
quirks for the panels that
From: "Yokoyama, Caz"
MAD_INTER_CHANNEL_0_0_0_MCHBAR:
code nameoffset DRAM_DDR_TYPE
SKL 0x5000 1:0 DDR4/DDR3/LPDDR3
TGL 0x6048/0x6248/0xd800 2:0 DDR4/DDR3/LPDDR3/LPDDR4
ICL 0x5000/0x6048/0x48
On Tue, 2020-02-11 at 18:12 +0200, Jani Nikula wrote:
> On Mon, 10 Feb 2020, Jani Nikula wrote:
> > On Mon, 10 Feb 2020, José Roberto de Souza
> > wrote:
> > > Commit 1c9d2eb24153 ("drm/i915: move intel_dp_set_m_n() to
> > > encoder for
> > > DDI platforms") moved the intel_dp_set_m_n() from
> >
On Tue, 11 Feb 2020, Jani Nikula wrote:
On Thu, 06 Feb 2020, Wambui Karuga wrote:
@@ -1364,11 +1372,15 @@ int intel_hdmi_hdcp_write_an_aksv(struct
intel_digital_port *intel_dig_port,
static int intel_hdmi_hdcp_read_bksv(struct intel_digital_port *intel_dig_port,
On Tue, 11 Feb 2020, Jani Nikula wrote:
drm->dev_private is to be avoided. Use to_i915() on the struct
drm_device pointer instead. Rename the affected local dev_priv variables
to i915 while at it.
Applies cleanly, and compiles.
Changes also look good to me.
Reviewed by: Wambui Karuga
On 2/4/20 4:43 PM, Ye, Tony wrote:
On 1/27/2020 1:41 AM, Michal Wajdeczko wrote:
On Thu, 23 Jan 2020 16:51:58 +0100, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2020-01-23 15:38:52)
On Thu, 23 Jan 2020 16:02:17 +0100, Chris Wilson
wrote:
> Quoting Daniele Ceraolo Spurio
Chris Wilson writes:
> Apply vast quantities of poison and not tell anyone to see if we fall
> for the trap of using a stale RING_HEAD.
>
> References: 42827350f75c ("drm/i915/gt: Avoid resetting ring->head outside of
> its timeline mutex")
> Signed-off-by: Chris Wilson
> Cc: Andi Shyti
> Cc:
skl_ddb_allocation_overlaps() num_entries hass been passed as
INTEL_NUM_PIPES, it should be I915_MAX_PIPES.
Cc: Ville Syrjälä
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_display.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git
It should not be assumed that a disabled display pipe will be
always last the pipe.
for_each_pipe() should iterate over I915_MAX_PIPES and check
for the disabled pipe and skip that pipe so that it should not
initialize the intel crtc for any disabled pipes.
Below compilation error require to be
As a disabled pipe in pipe_mask is not having a valid intel crtc,
driver wrongly populates the possible_crtcs mask while initializing
the plane for a CRTC. Fixing up the plane possible_crtcs mask.
changes since RFC:
- Simplify the possible_crtcs initialization. [Ville]
v2:
- Removed the
Skip the transcoder whose pipe is disabled while
initializing transcoder error state in 3 non-contiguous
display pipe system.
v2:
- Don't skip EDP_TRANSCODER error state. [Ville]
- Use a helper has_transcoder(). [Ville]
Cc: Ville Syrjälä
Signed-off-by: Anshuman Gupta
---
we can't have (pipe == crtc->index) assumption in
driver in order to support 3 non-contiguous
display pipe system.
FIXME: Remove the WARN_ON(drm_crtc_index(>base) != crtc->pipe)
when we will fix all such assumption.
changes since RFC:
- Added again removed (pipe == crtc->index) WARN_ON.
- Pass
Add a WARN_ON for a disabled pipe in pipe_mask at
intel_get_crtc_for_pipe() function.
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_display_types.h | 2 ++
1 file changed, 2 insertions(+)
diff --git
intel_plane_fb_max_stride should return the max stride of
primary plane for first available pipe in intel device info
pipe_mask.
Similarly glk_force_audio_cdclk() should also use the first
available CRTC instead of pipe 'A' crtc to force the cdclk
changes.
changes since RFC:
- Introduced a helper
Chris Wilson writes:
> Currently on execlists, we use a local hwsp for the kernel_context,
> rather than the engine's HWSP, as this is the default for execlists.
> However, seqno rollover requires allocating a new HWSP cachline, and may
s/cachline/cacheline
> require pinning a new HWSP page in
Updated version after fixing some review comment provided by
ville on v2 version, which unfortunately didn't reach to mailing
list due to typo in "to address".
Anshuman Gupta (7):
drm/i915: Iterate over pipe and skip the disabled one
drm/i915: Remove (pipe == crtc->index) assumption
On Tue, Feb 11, 2020 at 06:05:45PM +0100, Daniel Vetter wrote:
> On Tue, Feb 11, 2020 at 06:22:08PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Let's simplify life of driver by allowing them to leave
> > encoder->possible_crtcs unset if they have no restrictions
> > in
On Tue, Feb 11, 2020 at 06:02:33PM +0100, Daniel Vetter wrote:
> On Tue, Feb 11, 2020 at 06:22:06PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Many drivers are populating encoder->possible_clones wrong. Let's
> > persuade them to get it right by adding some loud WARNs.
> >
> >
On 2020-02-11 at 18:26:13 +0200, Ville Syrjälä wrote:
> On Tue, Feb 11, 2020 at 09:39:37PM +0530, Anshuman Gupta wrote:
> > On 2020-02-07 at 18:15:31 +0200, Ville Syrjälä wrote:
> > > On Fri, Feb 07, 2020 at 07:50:36PM +0530, Anshuman Gupta wrote:
> > > > Updated version after rebase and fixing
On Tue, Feb 11, 2020 at 06:22:08PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Let's simplify life of driver by allowing them to leave
> encoder->possible_crtcs unset if they have no restrictions
> in crtc<->encoder linkage. We'll just populate possible_crtcs
> with the full crtc mask
On Tue, Feb 11, 2020 at 06:22:07PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> WARN if the encoder possible_crtcs is effectively empty or contains
> bits for non-existing crtcs.
>
> v2: Move to drm_mode_config_validate() (Daniel)
> Make the docs say we WARN when this is wrong
On Tue, Feb 11, 2020 at 06:22:06PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Many drivers are populating encoder->possible_clones wrong. Let's
> persuade them to get it right by adding some loud WARNs.
>
> We'll cross check the bits between any two encoders. So either
> both
On Tue, Feb 11, 2020 at 06:22:02PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The docs say possible_clones should always include the encoder itself.
> Since most drivers don't want to deal with the complexities of cloning
> let's allow them to set possible_clones=0 and instead we'll
Quoting Janusz Krzysztofik (2020-02-11 14:30:48)
> @@ -2009,8 +2016,31 @@ igt_main_args("c:", NULL, help_str, opt_handler, NULL)
> igt_subtest("invalid-null-pointer")
> test_invalid_null_pointer(fd);
>
> - igt_subtest("invalid-gtt-mapping")
>
On Tue, 11 Feb 2020, Ville Syrjälä wrote:
> On Tue, Feb 11, 2020 at 06:14:50PM +0200, Jani Nikula wrote:
>> The DMC firmware is about display. Move the handling under display. No
>> functional changes.
>>
>> Cc: Ville Syrjälä
>> Signed-off-by: Jani Nikula
>
> Acked-by: Ville Syrjälä
>
> I'm
Quoting Ville Syrjälä (2020-02-11 16:29:03)
> On Tue, Feb 11, 2020 at 06:14:50PM +0200, Jani Nikula wrote:
> > The DMC firmware is about display. Move the handling under display. No
> > functional changes.
> >
> > Cc: Ville Syrjälä
> > Signed-off-by: Jani Nikula
>
> Acked-by: Ville Syrjälä
>
On 2020-02-11 at 15:00:01 +0530, Ramalingam C wrote:
> As per the HDCP2.2 compliance test 1B-10 expectation, when stream
> management for a repeater fails, we retry thrice and when it fails
> in all retries, HDCP2.2 reauthentication aborted at kernel.
>
> v2:
> seq_num_m++ is extended for steam
On Tue, Feb 11, 2020 at 06:14:50PM +0200, Jani Nikula wrote:
> The DMC firmware is about display. Move the handling under display. No
> functional changes.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Acked-by: Ville Syrjälä
I'm also thinking s/csr/dmc/ migth be a good idea. I don't
Prefer i915 over dev_priv where possible. No functional changes.
Cc: Ville Syrjälä
Reviewed-by: Chris Wilson
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.c | 54 -
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git
Move vga switcheroo and dsm handler register later in
i915_driver_register(), and unregister in i915_driver_unregister(). The
dsm handler unregister is a nop, and is only added for completeness.
My unsubstantiated suspicion is that the vga switcheroo state change
would not work as early as we
On Tue, Feb 11, 2020 at 09:39:37PM +0530, Anshuman Gupta wrote:
> On 2020-02-07 at 18:15:31 +0200, Ville Syrjälä wrote:
> > On Fri, Feb 07, 2020 at 07:50:36PM +0530, Anshuman Gupta wrote:
> > > Updated version after rebase and fixing few comments.
> > >
> > > Anshuman Gupta (6):
> > > drm/i915:
From: Ville Syrjälä
WARN if the encoder possible_crtcs is effectively empty or contains
bits for non-existing crtcs.
v2: Move to drm_mode_config_validate() (Daniel)
Make the docs say we WARN when this is wrong (Daniel)
Extract full_crtc_mask()
Cc: Thomas Zimmermann
Cc: Daniel Vetter
From: Ville Syrjälä
The docs say possible_clones should always include the encoder itself.
Since most drivers don't want to deal with the complexities of cloning
let's allow them to set possible_clones=0 and instead we'll fix that
up in the core.
We can't put this special case into
From: Ville Syrjälä
Let's simplify life of driver by allowing them to leave
encoder->possible_crtcs unset if they have no restrictions
in crtc<->encoder linkage. We'll just populate possible_crtcs
with the full crtc mask when registering the encoder so that
userspace doesn't have to deal with
From: Ville Syrjälä
It's not at all clear what cloning options this driver supports.
So let's just clear possible_clones instead of setting it to some
bogus value.
v2: Adjust the FIXME (Daniel)
Cc: Philipp Zabel
Acked-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Many drivers are populating encoder->possible_clones wrong. Let's
persuade them to get it right by adding some loud WARNs.
We'll cross check the bits between any two encoders. So either
both encoders can clone with the other, or neither can.
We'll also complain about
From: Ville Syrjälä
I doubt the DP+DP and SDVO+SDVO cloning works for this driver.
i915 at least doesn't do those. Truthfully there could be some very
specific circumstances where some of them would do doable, but
genereally it's too much pain to deal with so we've chose not to
bother. Let's use
From: Ville Syrjälä
Replace the hand rolled encoder bitmask thing with drm_encoder_mask()
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Acked-by: Thomas Zimmermann
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++---
1 file changed, 2
From: Ville Syrjälä
Another respin of the possible_clones/crtcs fixing.
Changes based on v2 review:
- introduce drm_mode_config_validate()
- WARN for possible_clones!=0 when the encoder
itself isn't in the mask
- update the documentation to match the code
Other changes:
- sligth refactoring
On 2020-02-07 at 18:15:31 +0200, Ville Syrjälä wrote:
> On Fri, Feb 07, 2020 at 07:50:36PM +0530, Anshuman Gupta wrote:
> > Updated version after rebase and fixing few comments.
> >
> > Anshuman Gupta (6):
> > drm/i915: Iterate over pipe and skip the disabled one
> > drm/i915: Remove (pipe ==
The DMC firmware is about display. Move the handling under display. No
functional changes.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/Makefile | 2 +-
drivers/gpu/drm/i915/{ => display}/intel_csr.c | 0
drivers/gpu/drm/i915/{ => display}/intel_csr.h
On Mon, 10 Feb 2020, Jani Nikula wrote:
> On Mon, 10 Feb 2020, José Roberto de Souza wrote:
>> Commit 1c9d2eb24153 ("drm/i915: move intel_dp_set_m_n() to encoder for
>> DDI platforms") moved the intel_dp_set_m_n() from hsw_crtc_enable()
>> to intel_ddi_pre_enable_dp() but it missed add it to
>>
Quoting Mika Kuoppala (2020-02-11 15:54:07)
> Chris Wilson writes:
>
> > Quoting Mika Kuoppala (2020-02-11 15:23:24)
> >> Chris Wilson writes:
> >> > + /* Kick the tasklet to process the error */
> >> > +
Chris Wilson writes:
> Quoting Mika Kuoppala (2020-02-11 15:23:24)
>> Chris Wilson writes:
>> > + /* Kick the tasklet to process the error */
>> > + intel_engine_flush_submission(engine);
>>
>> This pattern of usage in selftests makes me
== Series Details ==
Series: series starting with [1/2] drm/i915: terminate reauth at stream
management failure
URL : https://patchwork.freedesktop.org/series/73282/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7909 -> Patchwork_16517
Quoting Mika Kuoppala (2020-02-11 15:23:24)
> Chris Wilson writes:
> > + /* Kick the tasklet to process the error */
> > + intel_engine_flush_submission(engine);
>
> This pattern of usage in selftests makes me want to add mb(); to
>
Chris Wilson writes:
> We can not require that the system process a tasklet in reasonable time
> (thanks be to ksoftirqd), but we can insist that having waited
> sufficiently for the error interrupt to have been raised and having
> kicked the tasklet, the reset has begun and the request will be
Quoting Mika Kuoppala (2020-02-11 14:50:08)
> Chris Wilson writes:
> > + /* Release the hounds! */
> > + slot[0] = 1;
> > + wmb();
> > +
> > + for (i = 1; i <= 3; i++) {
> > + unsigned long timeout = jiffies + HZ / 2;
> > +
> > +
Apply vast quantities of poison and not tell anyone to see if we fall
for the trap of using a stale RING_HEAD.
References: 42827350f75c ("drm/i915/gt: Avoid resetting ring->head outside of
its timeline mutex")
Signed-off-by: Chris Wilson
Cc: Andi Shyti
Cc: Mika Kuoppala
---
Chris Wilson writes:
> Originally, I did not expect having to rewind a context upon
> timeslicing: the point was to replace the executing context with an idle
I think you said 'non executing' and it would fit better.
> one! However, given a second context that depends on requests from the
>
If we have a set of active engines marked as being non-persistent, we
lose track of those if the user replaces those engines with
I915_CONTEXT_PARAM_ENGINES. As part of our uABI contract is that
non-persistent requests are terminated if they are no longer being
tracked by the user's context (in
Working with a userptr GEM object backed by any type of mapping to
another GEM object, not only GTT mapping currently examined bu the
test, may cause a currently unavoidable lockdep splat inside the i915
driver. Then, for as long as that issue is not resolved in the driver,
such operations are
On Tue, 2020-02-11 at 16:12 +0200, Jani Nikula wrote:
> On Tue, 11 Feb 2020, "Lisovskiy, Stanislav" <
> stanislav.lisovs...@intel.com> wrote:
> > Well, you can just take all those checks and put them into separate
> > function. Something like:
> >
> > bool intel_dp_supports_mst(intel_dp) {
> >
On Tue, Feb 11, 2020 at 03:55:45PM +0200, Jani Nikula wrote:
> On Tue, 11 Feb 2020, "Lisovskiy, Stanislav"
> wrote:
> > On Tue, 2020-02-11 at 15:03 +0200, Jani Nikula wrote:
> >> On Tue, 11 Feb 2020, Stanislav Lisovskiy <
> >> stanislav.lisovs...@intel.com> wrote:
> >> > I guess it would still
Quoting Tvrtko Ursulin (2020-02-11 13:41:22)
>
> On 10/02/2020 20:57, Chris Wilson wrote:
> > +static void kill_context(struct i915_gem_context *ctx)
> > +{
> > + if (!list_empty(>stale.engines))
> > + kill_stale_engines(ctx);
>
> Lets see.. set_engines can freely race with
On Tue, 11 Feb 2020, "Lisovskiy, Stanislav"
wrote:
> Well, you can just take all those checks and put them into separate
> function. Something like:
>
> bool intel_dp_supports_mst(intel_dp) {
> if (HAS_DP_MST(i915) && !intel_dp_is_edp(intel_dp)) &&
> !(INTEL_GEN(i915) < 12 &&
On Thu, 06 Feb 2020, Wambui Karuga wrote:
> This patchset continues the conversion of the printk based drm logging
> macros in drm/i915 to use the struct drm_device based logging macros.
> This series was done both using coccinelle and manually.
Thank you for the patches! I pushed all the
1 - 100 of 137 matches
Mail list logo
