Prepare to split up hw and uapi machinally, by adding a uapi and
hw alias. We will remove the base in a bit. This is a split from the
original uapi/hw patch, which did it all in one go.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/display/intel_atomic_plane.c| 16
Splitting plane state is easier than splitting crtc_state,
before plane check we copy the drm properties to hw so we can
do the same in bigjoiner later on.
We copy the state after we did all the modeset handling, but fortunately
i915 seems to be split correctly and nothing during modeset looks
at
Now that we separated everything into uapi and hw, it's
time to make the split definitive. Remove the union and
make a copy of the hw state on modeset and fastset.
Color blobs are copied in crtc atomic_check(), right
before color management is checked.
Changes since v1:
- Copy all blobs
get_crtc_from_states() is called before plane_state is copied to uapi,
so use the uapi state there.
intel_legacy_cursor_update() could probably get away with looking at
the hw state, but for clarity look at the uapi state always
Signed-off-by: Maarten Lankhorst
---
Split up plane_state->base to hw. This is done using the following patch:
@@
struct intel_plane_state *T;
identifier x =~
"^(crtc|fb|alpha|pixel_blend_mode|rotation|color_encoding|color_range)$";
@@
-T->base.x
+T->hw.x
Signed-off-by: Maarten Lankhorst
---
Instead of unconditionally verifying the cursor plane, handle it in the
same way as any other plane, and use our existing api to verify.
While at it, ensure that on gen9+ we verify active_planes mask as well.
This should give the correct results for planar YUV planes too, as we
update
Use this in all the places where we try to acquire planes after the planes
atomic_check().
In case of intel_modeset_all_pipes() this is not yet done after atomic_check,
but seems like it will be in the future. To add some paranoia, add all planes
rather than active planes, because of bigjoiner
Prepare to split up hw and uapi machinally, by adding a uapi and
hw alias. We will remove the base in a bit. This is a split from the
original uapi/hw patch, which did it all in one go.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_atomic.c | 8 --
== Series Details ==
Series: series starting with [1/9] i915_drm.h sync
URL : https://patchwork.freedesktop.org/series/68508/
State : warning
== Summary ==
Did not get list of undocumented tests for this run, something is wrong!
Other than that, pipeline status: FAILED.
see
Op 24-10-2019 om 14:23 schreef Ville Syrjälä:
> On Thu, Oct 24, 2019 at 02:12:46PM +0200, Maarten Lankhorst wrote:
>> Op 22-10-2019 om 20:16 schreef Ville Syrjälä:
>>> On Fri, Oct 18, 2019 at 10:13:23AM +0200, Maarten Lankhorst wrote:
intel_get_load_detect_pipe() needs to set uapi active,
On Thu, Oct 24, 2019 at 02:12:46PM +0200, Maarten Lankhorst wrote:
> Op 22-10-2019 om 20:16 schreef Ville Syrjälä:
> > On Fri, Oct 18, 2019 at 10:13:23AM +0200, Maarten Lankhorst wrote:
> >> intel_get_load_detect_pipe() needs to set uapi active,
> >> uapi enable is set by the call to
On Thu, 24 Oct 2019, Daniel Vetter wrote:
> On Thu, Oct 24, 2019 at 03:12:07PM +0300, Jani Nikula wrote:
>> On Thu, 24 Oct 2019, Daniel Vetter wrote:
>> > On Wed, Oct 23, 2019 at 03:44:17PM +0300, Jani Nikula wrote:
>> >> On Tue, 22 Oct 2019, Daniel Vetter wrote:
>> >> > On Tue, Oct 22, 2019 at
From: Ville Syrjälä
Add CHICKEN_TRANS definition for transcoder D.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index
From: Ville Syrjälä
Currently we're blindly poking at the frame start delay bits
in PIPECONF when trying to sanitize the hardware state. Those
bits decided to move elsewhere on HSW, so on many platforms
we're not doing anything at all here. Also we're forgetting
about the PCH transcoder
From: Ville Syrjälä
Make CHICKEN_TRANS() a bit less special looking by using _PICK().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 14 +++---
drivers/gpu/drm/i915/display/intel_psr.c | 22 +-
drivers/gpu/drm/i915/i915_reg.h |
== Series Details ==
Series: drm/simple-kms: Standardize arguments for callbacks
URL : https://patchwork.freedesktop.org/series/68452/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7163_full -> Patchwork_14946_full
Summary
On Thu, Oct 24, 2019 at 03:12:07PM +0300, Jani Nikula wrote:
> On Thu, 24 Oct 2019, Daniel Vetter wrote:
> > On Wed, Oct 23, 2019 at 03:44:17PM +0300, Jani Nikula wrote:
> >> On Tue, 22 Oct 2019, Daniel Vetter wrote:
> >> > On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote:
> >> >>
Op 22-10-2019 om 20:16 schreef Ville Syrjälä:
> On Fri, Oct 18, 2019 at 10:13:23AM +0200, Maarten Lankhorst wrote:
>> intel_get_load_detect_pipe() needs to set uapi active,
>> uapi enable is set by the call to drm_atomic_set_mode_for_crtc(),
>> so we can remove it.
>>
>>
On Thu, 24 Oct 2019, Daniel Vetter wrote:
> On Wed, Oct 23, 2019 at 03:44:17PM +0300, Jani Nikula wrote:
>> On Tue, 22 Oct 2019, Daniel Vetter wrote:
>> > On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote:
>> >> This patch adds a scaling filter mode porperty
>> >> to allow:
>> >> -
On Wed, 23 Oct 2019, Daniel Vetter wrote:
> Properties can't be attached after registering, userspace would get
> confused (no one bothers to reprobe really).
>
> - Add kerneldoc
> - Enforce this with some checks. This needs a somewhat ugly check
> since connectors can be added later on, but we
On Wed, Oct 23, 2019 at 03:44:17PM +0300, Jani Nikula wrote:
> On Tue, 22 Oct 2019, Daniel Vetter wrote:
> > On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote:
> >> This patch adds a scaling filter mode porperty
> >> to allow:
> >> - A driver/HW to showcase it's scaling filter
On Wed, Oct 23, 2019 at 05:40:32PM +0200, Linus Walleij wrote:
> On Wed, Oct 23, 2019 at 12:13 PM Daniel Vetter wrote:
>
> > Passing the wrong type feels icky, everywhere else we use the pipe as
> > the first parameter. Spotted while discussing patches with Thomas
> > Zimmermann.
> >
> > v2:
> -Original Message-
> From: Jani Nikula
> Sent: Thursday, October 24, 2019 5:08 PM
> To: Kulkarni, Vandita ; intel-
> g...@lists.freedesktop.org
> Cc: ville.syrj...@linux.intel.com; Shankar, Uma ;
> Kulkarni, Vandita
> Subject: Re: [RFC 2/7] drm/i915/dsi: Configure transcoder operation
On Thu, Oct 24, 2019 at 12:43 PM Thierry Reding
wrote:
>
> On Thu, Oct 24, 2019 at 12:40:55PM +0200, Thierry Reding wrote:
> > On Wed, Oct 23, 2019 at 04:49:52PM +0200, Daniel Vetter wrote:
> > > Properties can't be attached after registering, userspace would get
> > > confused (no one bothers to
On 10/22/2019 11:10 PM, Manasi Navare wrote:
On Tue, Oct 22, 2019 at 07:34:13PM +0530, Animesh Manna wrote:
On 10/22/2019 4:27 AM, Manasi Navare wrote:
On Thu, Oct 03, 2019 at 08:36:49PM +0530, Animesh Manna wrote:
vswing/pre-emphasis adjustment calculation is needed in processing
of auto phy
Our existing behaviour is to allow contexts and their GPU requests to
persist past the point of closure until the requests are complete. This
allows clients to operate in a 'fire-and-forget' manner where they can
setup a rendering pipeline and hand it over to the display server and
immediately
Just plain persistence testing this time,
Test-with: 20191024105449.31948-1-ch...@chris-wilson.co.uk
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Our existing behaviour is to allow contexts and their GPU requests to
persist past the point of closure until the requests are complete. This
allows clients to operate in a 'fire-and-forget' manner where they can
setup a rendering pipeline and hand it over to the display server and
immediately
Check the user's flags on the struct file before deciding whether or not
to stall before submitting a request. This allows us to reasonably
cheaply honour O_NONBLOCK without checking at more critical phases
during request submission.
Suggested-by: Joonas Lahtinen
Signed-off-by: Chris Wilson
Cc:
Preliminary stub to add engines underneath /sys/class/drm/cardN/, so
that we can expose properties on each engine to the sysadmin.
To start with we have basic analogues of the i915_query ioctl so that we
can pretty print engine discovery from the shell, and flesh out the
directory structure.
We monitor the health of the system via periodic heartbeat pulses. The
pulses also provide the opportunity to perform garbage collection.
However, we interpret an incomplete pulse (a missed heartbeat) as an
indication that the system is no longer responsive, i.e. hung, and
perform an engine or
Execlists uses a scheduling quantum (a timeslice) to alternate execution
between ready-to-run contexts of equal priority. This ensures that all
users (though only if they of equal importance) have the opportunity to
run and prevents livelocks where contexts may have implicit ordering due
to
After initialising a preemption request, we give the current resident a
small amount of time to vacate the GPU. The preemption request is for a
higher priority context and should be immediate to maintain high
quality of service (and avoid priority inversion). However, the
preemption granularity of
If we do find ourselves with an idle barrier inside our active while
waiting, attempt to flush it by emitting a pulse using the kernel
context.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_active.c | 21 -
drivers/gpu/drm/i915/selftests/i915_active.c | 46
When we allow ourselves to sleep before a GPU reset after disabling
submission, even for a few milliseconds, gives an innocent context the
opportunity to clear the GPU before the reset occurs. However, how long
to sleep depends on the typical non-preemptible duration (a similar
problem to
Use the per-engine sysfs directory to let userspace discover the
mmio_base of each engine. Prior to recent generations, the user
accessible registers on each engine are at a fixed offset relative to
each engine -- but require absolute addressing. As the absolute address
depends on the actual
No good reason why we must always use a static ringsize, so let
userspace select one during construction.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 139 +++-
drivers/gpu/drm/i915/gt/intel_lrc.c | 1 +
We would like some freedom to break the user API/ABI for future HW but
yet still expose the driver for upstream development on that HW.
Currently, we have the i915.force_probe module parameter to avoid binding
to HW while the driver is under development, but that is still a little
too soft with
Hopefully this works. CI all over to you,
Test-with: 20191024105449.31948-1-ch...@chris-wilson.co.uk
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Quoting Mika Kuoppala (2019-10-24 12:03:31)
> On testing the whitelists, using any of the nonpriv
> flags when trying to access the register offset will lead
> to failure.
>
> Define address mask to get the mmio offset in order
> to guard against any current and future flag usage.
>
> v2: apply
On Mon, 14 Oct 2019, Vandita Kulkarni wrote:
> Configure the transcoder to operate in TE GATE command mode
> and take TE events from GPIO.
> Also disable the periodic command mode, that GOP would have
> programmed.
Discussing this with Ville, it just might be a good idea to enable
command mode
On Mon, 14 Oct 2019, Vandita Kulkarni wrote:
> We need to configure TE interrupt in two places.
> Port interrupt and DSI interrupt mask registers.
>
> Signed-off-by: Vandita Kulkarni
> ---
> drivers/gpu/drm/i915/i915_irq.c | 49 -
> 1 file changed, 48
On Thu, Oct 24, 2019 at 12:31:06PM +0200, Thierry Reding wrote:
> On Wed, Oct 23, 2019 at 05:00:41PM -0700, Manasi Navare wrote:
> > Adaptive Sync is a VESA feature so add a DRM core helper to parse
> > the EDID's detailed descritors to obtain the adaptive sync monitor range.
> > Store this info
On Tue, Oct 22, 2019 at 05:12:06PM -0700, Rajat Jain wrote:
> Certain laptops now come with panels that have integrated privacy
> screens on them. This patch adds support for such panels by adding
> a privacy-screen property to the drm_connector for the panel, that
> the userspace can then use to
On Mon, Oct 21, 2019 at 03:42:59PM -0400, Bhawanpreet Lakha wrote:
> The content protection tests only start if this debugfs entry exists.
> Since the name is specific to intel driver these tests cannot be used with
> other drivers. So we should check generic debugfs name also
>
> v2: Check
== Series Details ==
Series: drm/i915/gt: Split intel_ring_submission (rev3)
URL : https://patchwork.freedesktop.org/series/68491/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7169 -> Patchwork_14963
Summary
---
On testing the whitelists, using any of the nonpriv
flags when trying to access the register offset will lead
to failure.
Define address mask to get the mmio offset in order
to guard against any current and future flag usage.
v2: apply also on scrub_whitelisted_registers (Lionel)
Cc: Tapani
Some of the non-privileged registers are at the same offset on each
engine. We can improve our coverage for unknown HW layout by using the
reported engine->mmio_base for relative offsets.
Signed-off-by: Chris Wilson
---
tests/i915/gem_ctx_isolation.c | 160 -
1
Sanity test existing persistence and new exciting non-persistent context
behaviour.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Michał Winiarski
Cc: Jon Bloomfield
Cc: Tvrtko Ursulin
Cc: Andi Shyti
Reviewed-by: Andi Shyti
---
tests/Makefile.sources | 3 +
We [will] expose various per-engine scheduling controls. One of which,
'timeslice_duration_ms', defines the scheduling quantum. If a context
exhausts its timeslice, it will be preempted in favour of running one of
its compatriots.
Signed-off-by: Chris Wilson
---
tests/Makefile.sources
Update to commit fef476f3ab47527a00818ddaf4b46b8c0936 (not upstream!)
Author: Chris Wilson
Date: Mon Aug 5 22:55:44 2019 +0100
drm/i915: Cancel non-persistent contexts on close
for I915_CONTEXT_PARAM_PERSISTENCE
---
include/drm-uapi/i915_drm.h | 22 --
1 file
Several tests depend upon the implicit engine->mmio_base but have no
means of determining the physical layout. Since the kernel has started
providing this information, start putting it to use.
Signed-off-by: Chris Wilson
---
lib/i915/gem_engine_topology.c | 84 ++
Expose a new context parameters to opting out of persistent behaviour.
Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
---
lib/i915/gem_context.c | 37 +
lib/i915/gem_context.h | 8
2 files changed, 45 insertions(+)
diff --git
I915_CONTEXT_PARAM_RINGSIZE specifies how large to create the command
ringbuffer for logical ring contects. This directly affects the number
of batches userspace can submit before blocking waiting for space.
Signed-off-by: Chris Wilson
---
tests/Makefile.sources| 3 +
We [will] expose various per-engine scheduling controls. One of which,
'heartbeat_duration_ms', defines how often we send a heartbeat down the
engine to check upon the health of the engine. If a heartbeat does not
complete within the interval (or two), the engine is declared hung.
Signed-off-by:
We [will] expose various per-engine scheduling controls. One of which,
'preempt_timeout_ms', defines how we wait for a preemption request to be
honoured by the currently executing context. If it fails to relieve the
GPU within the required timeout, the engine is reset and the miscreant
forcibly
On 24/10/2019 13:38, Mika Kuoppala wrote:
On testing the whitelists, using any of the nonpriv
flags when trying to access the register offset will lead
to failure.
Define address mask to get the mmio offset in order
to guard against any current and future flag usage.
Cc: Tapani Pälli
Cc:
== Series Details ==
Series: drm/i915/gt: Split intel_ring_submission (rev3)
URL : https://patchwork.freedesktop.org/series/68491/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
97eb616910b3 drm/i915/gt: Split intel_ring_submission
-:360: WARNING:FILE_PATH_CHANGES: added, moved
On Thu, Oct 24, 2019 at 12:40:55PM +0200, Thierry Reding wrote:
> On Wed, Oct 23, 2019 at 04:49:52PM +0200, Daniel Vetter wrote:
> > Properties can't be attached after registering, userspace would get
> > confused (no one bothers to reprobe really).
> >
> > - Add kerneldoc
> > - Enforce this with
On Wed, Oct 23, 2019 at 04:49:52PM +0200, Daniel Vetter wrote:
> Properties can't be attached after registering, userspace would get
> confused (no one bothers to reprobe really).
>
> - Add kerneldoc
> - Enforce this with some checks. This needs a somewhat ugly check
> since connectors can be
On testing the whitelists, using any of the nonpriv
flags when trying to access the register offset will lead
to failure.
Define address mask to get the mmio offset in order
to guard against any current and future flag usage.
Cc: Tapani Pälli
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
== Series Details ==
Series: drm/i915: Convert PAT setup to uncore mmio
URL : https://patchwork.freedesktop.org/series/68503/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7169 -> Patchwork_14962
Summary
---
From: Tapani Pälli
As with commit 3fe0107e45ab, this change fixes multiple tests that are
using the invocation counts. Documentation doesn't list the workaround
for TGL but applying it fixes the tests.
Signed-off-by: Tapani Pälli
Acked-by: Chris Wilson
Reviewed-by: Lionel Landwerlin
On Wed, Oct 23, 2019 at 04:49:53PM +0200, Daniel Vetter wrote:
> They're midlayer, broken, and because of the old gunk, we can't fix
> them. For examples see the various checks in drm_mode_object.c against
> dev->registered, which cannot be enforced if the driver still uses the
> load hook.
>
>
On Wed, Oct 23, 2019 at 05:00:41PM -0700, Manasi Navare wrote:
> Adaptive Sync is a VESA feature so add a DRM core helper to parse
> the EDID's detailed descritors to obtain the adaptive sync monitor range.
> Store this info as part fo drm_display_info so it can be used
> across all drivers.
>
On Tue, 2019-10-15 at 22:30 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> check_digital_port_conflicts() is done needlessly late. Move it
> earlier.
> This will be needed as later on we want to set any_ms=true a bit
> later
> for non-modesets too and we can't call this guy without the
>
On Tue, 2019-10-15 at 22:30 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> To make the logs a bit less confusing let's toss in some
> debug prints to indicate whether the cdclk reprogramming
> is going to happen with a single pipe active or whether we
> need to turn all pipes off for the
On Tue, 2019-10-15 at 22:30 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> So far we've sort of protected the global state under dev_priv with
> the connection_mutex. I wan to change that so that we can change the
> cdclk even for pure plane updates. To that end let's formalize the
>
== Series Details ==
Series: Extract rps and guc
URL : https://patchwork.freedesktop.org/series/68449/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7162_full -> Patchwork_14945_full
Summary
---
**FAILURE**
== Series Details ==
Series: drm/i915/bios: add compression parameter block definition (rev2)
URL : https://patchwork.freedesktop.org/series/68396/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7169 -> Patchwork_14961
Split the legacy submission backend from the common CS ring buffer
handling.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
Well that was the worst rebase of the year. /o\
---
drivers/gpu/drm/i915/Makefile | 5 +-
drivers/gpu/drm/i915/display/intel_overlay.c |
Quoting Tvrtko Ursulin (2019-10-24 10:34:40)
> From: Tvrtko Ursulin
>
> One more thing which relied on implicit dev_priv can be covnerted to use
> the new mmio accessors.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 98 +
> 1 file
From: Tvrtko Ursulin
One more thing which relied on implicit dev_priv can be covnerted to use
the new mmio accessors.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 98 +
1 file changed, 59 insertions(+), 39 deletions(-)
diff --git
From: Matthew Auld
Simple test writing to dwords across an object, using various engines in
a randomized order, checking that our writes land from the cpu.
Signed-off-by: Matthew Auld
Reviewed-by: Chris Wilson
---
.../drm/i915/selftests/intel_memory_region.c | 166 ++
1 file
From: Matthew Auld
Ditch the dubious static list of sizes to enumerate, in favour of
choosing a random size within the limits of each backing store. With
repeated CI runs this should give us a wider range of object sizes, and
in turn more page-size combinations, while using less machine time.
From: Matthew Auld
Now that for all the relevant backends we do randomised testing, we need
to make sure we still sanity check the obvious cases that might blow up,
such that introducing a temporary regression is less likely. Also
rather than do this for every backend, just limit to our two
From: Abdiel Janulgue
We can create LMEM objects, but we also need to support mapping them
into kernel space for internal use.
Signed-off-by: Abdiel Janulgue
Signed-off-by: Matthew Auld
Signed-off-by: Steve Hampson
Cc: Joonas Lahtinen
Reviewed-by: Chris Wilson
---
From: Abdiel Janulgue
Signed-off-by: Abdiel Janulgue
Cc: Matthew Auld
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_region_lmem.c | 28 ++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_region_lmem.c
From: Matthew Auld
We currently define LMEM, or local memory, as just another memory
region, like system memory or stolen, which we can expose to userspace
and can be mapped to the CPU via some BAR.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Abdiel Janulgue
Reviewed-by: Chris Wilson
From: Matthew Auld
Add LMEM objects to list of backends we test for huge-GTT-pages.
Signed-off-by: Matthew Auld
Reviewed-by: Chris Wilson
---
.../gpu/drm/i915/gem/selftests/huge_pages.c | 121 +-
1 file changed, 120 insertions(+), 1 deletion(-)
diff --git
On Thu, 24 Oct 2019, Jani Nikula wrote:
> On Wed, 16 Oct 2019, "Kulkarni, Vandita" wrote:
>>> -Original Message-
>>> From: Nikula, Jani
>>> Sent: Wednesday, October 16, 2019 12:51 AM
>>> To: Kulkarni, Vandita ; intel-
>>> g...@lists.freedesktop.org
>>> Cc: ville.syrj...@linux.intel.com;
On Wed, 16 Oct 2019, "Kulkarni, Vandita" wrote:
>> -Original Message-
>> From: Nikula, Jani
>> Sent: Wednesday, October 16, 2019 12:51 AM
>> To: Kulkarni, Vandita ; intel-
>> g...@lists.freedesktop.org
>> Cc: ville.syrj...@linux.intel.com; Shankar, Uma ;
>> Chauhan, Madhav ; Kulkarni,
On Mon, Oct 21, 2019 at 4:50 PM Daniel Vetter wrote:
>
> We can't copy_*_user while holding reservations, that will (soon even
> for nouveau) lead to deadlocks. And it breaks the cross-driver
> contract around dma_resv.
>
> Fix this by adding a slowpath for when we need relocations, and by
>
On Wed, 16 Oct 2019, Vandita Kulkarni wrote:
> This patch add dsi_state which provides
> dsi operation mode and the link mode.
> These are needed in order to check if they
> were differently configured by GOP.
>
> In present case the GOP enables dsi in
> periodic update mode, whereas we need
> to
> -Original Message-
> From: Jani Nikula
> Sent: Thursday, October 24, 2019 1:26 PM
> To: Nikula, Jani ; intel-gfx@lists.freedesktop.org
> Cc: Kulkarni, Vandita
> Subject: [PATCH v2] drm/i915/bios: add compression parameter block
> definition
>
> Add definition for block 56, the
Quoting Mika Kuoppala (2019-10-24 09:06:30)
> Chris Wilson writes:
>
> > Quoting Mika Kuoppala (2019-10-24 08:21:14)
> >> Chris Wilson writes:
> >>
> >> > When setting up the system to perform the atomic reset, we need to
> >> > serialise with any ongoing interrupt tasklet or else:
> >> >
> >>
Chris Wilson writes:
> Make trebly sure that all possible callbacks and their delayed brethren
> are complete before asserting that the i915_active should be idle after
> flushing all barriers.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
>
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-10-24 08:21:14)
>> Chris Wilson writes:
>>
>> > When setting up the system to perform the atomic reset, we need to
>> > serialise with any ongoing interrupt tasklet or else:
>> >
>> > <0> [472.951428] i915_sel-44420d..1 466527056us :
>> >
> -Original Message-
> From: Jani Nikula
> Sent: Thursday, October 24, 2019 1:35 PM
> To: Kulkarni, Vandita ; intel-
> g...@lists.freedesktop.org
> Subject: RE: [PATCH] drm/i915/bios: add compression parameter block
> definition
>
> On Thu, 24 Oct 2019, "Kulkarni, Vandita"
> wrote:
>
On Thu, 24 Oct 2019, "Kulkarni, Vandita" wrote:
>> -Original Message-
>> From: Jani Nikula
>> Sent: Tuesday, October 22, 2019 7:33 PM
>> To: intel-gfx@lists.freedesktop.org
>> Cc: Nikula, Jani ; Kulkarni, Vandita
>>
>> Subject: [PATCH] drm/i915/bios: add compression parameter block
Split the legacy submission backend from the common CS ring buffer
handling.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/Makefile | 5 +-
drivers/gpu/drm/i915/display/intel_overlay.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_context.c |
On 24/10/2019 09.40, Rasmus Villemoes wrote:
> column. Maybe your compiler doesn't do string literal merging (since the
> linker does it anyway), so your .rodata.str1.1 might contain several
> copies of "yes" and "no", but they shouldn't really be counted.
Sorry, that's of course nonsense - the
Looks good to me.
Reviewed-by: Vandita Kulkarni
> -Original Message-
> From: Jani Nikula
> Sent: Tuesday, October 22, 2019 3:40 PM
> To: dri-de...@lists.freedesktop.org
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani ;
> Kulkarni, Vandita
> Subject: [PATCH 1/5] drm/dsi: clean up
Add definition for block 56, the compression parameters.
v2: add missing slice_height (Vandita)
Cc: Vandita Kulkarni
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 52 +++
1 file changed, 52 insertions(+)
diff --git
On Wed, 23 Oct 2019, Manasi Navare wrote:
> On Tue, Oct 22, 2019 at 05:03:00PM +0300, Jani Nikula wrote:
>> Add definition for block 56, the compression parameters.
>>
>
> Would this be used on DP connectors for DSC as well?
I think only if needed; with DSI it's not possible to query the
On 24/10/2019 00.56, Andrew Morton wrote:
> On Wed, 23 Oct 2019 16:13:08 +0300 Jani Nikula wrote:
>
>> +
>> +static inline const char *yesno(bool v)
>> +{
>> +return v ? "yes" : "no";
>> +}
>> +
>> +static inline const char *onoff(bool v)
>> +{
>> +return v ? "on" : "off";
>> +}
>> +
>>
> -Original Message-
> From: Jani Nikula
> Sent: Tuesday, October 22, 2019 7:33 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani ; Kulkarni, Vandita
>
> Subject: [PATCH] drm/i915/bios: add compression parameter block definition
>
> Add definition for block 56, the compression
Chris Wilson writes:
> Split the legacy submission backend from the common ring buffer.
Aye.
Didn't spot anything out of ordinary.
Reviewed-by: Mika Kuoppala
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/Makefile | 5 +-
>
== Series Details ==
Series: drm/i915/gt: Split intel_ring_submission
URL : https://patchwork.freedesktop.org/series/68491/
State : failure
== Summary ==
Applying: drm/i915/gt: Split intel_ring_submission
error: sha1 information is lacking or useless
On Wed, 23 Oct 2019, Andrew Morton wrote:
> On Wed, 23 Oct 2019 16:13:08 +0300 Jani Nikula wrote:
>
>> The kernel has plenty of ternary operators to choose between constant
>> strings, such as condition ? "yes" : "no", as well as value == 1 ? "" :
>> "s":
>>
>> $ git grep '? "yes" : "no"' | wc
101 - 200 of 214 matches
Mail list logo
