== Series Details ==
Series: drm/i915: Reserve powerctx for chv from the stolen allocator
URL : https://patchwork.freedesktop.org/series/33192/
State : failure
== Summary ==
Series 33192v1 drm/i915: Reserve powerctx for chv from the stolen allocator
https://patchwork.freedesktop.org/api/1.0/se
Ensure that we do not overwrite the cherryview power context by
reserving its range in the stolen allocator; exactly like how we handle
the same reservation for valleyview.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h | 3 +-
drivers/gpu/drm/i915/intel_pm.c
== Series Details ==
Series: series starting with [CI,1/7] drm/i915: Define an engine class enum for
the uABI
URL : https://patchwork.freedesktop.org/series/33183/
State : success
== Summary ==
Test kms_setmode:
Subgroup basic:
pass -> FAIL (shard-hsw) fdo#
== Series Details ==
Series: series starting with [CI,1/7] drm/i915: Define an engine class enum for
the uABI
URL : https://patchwork.freedesktop.org/series/33183/
State : success
== Summary ==
Series 33183v1 series starting with [CI,1/7] drm/i915: Define an engine class
enum for the uABI
ht
Take a copy of the HW state after a reset upon module loading by
executing a context switch from a blank context to the kernel context,
thus saving the default hw state over the blank context image.
We can then use the default hw state to initialise any future context,
ensuring that each starts wit
Let userspace know if they can trust that new contexts are created using
HW default values; and avoid inheriting state from existing contexts.
Note: I intend to squash this into the bugfix once we agree on the uabi.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Joonas Lahtinen
Cc: Tvrtko U
From: Tvrtko Ursulin
We want to be able to report back to userspace details about an engine's
class, and in return for userspace to be able to request actions
regarding certain classes of engines. To isolate the uABI from any
variations between hw generations, we define an abstract class for the
In the next few patches, we will want to both copy out of the context
image and write a valid image into a new context. To be completely safe,
we should then couple in our domain tracking to ensure that we don't
have any issues with stale data remaining in unwanted cachelines.
Historically, we omi
In the next few patches, we will have a hard requirement that we emit a
context-switch to the perma-pinned i915->kernel_context (so that we can
save the HW state using that context-switch). As the first context
itself may be classed as a kernel context, we want to be explicit in our
comparison. For
intel_modeset_gem_init() now only sets up the legacy overlay, so let's
remove the function and call the setup directly during driver load. This
should help us find a better point in the initialisation sequence for it
later.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Reviewed-by: Mi
GT powersaving is tightly coupled to the request infrastructure. To
avoid complications with the order of initialisation in the next patch
(where we want to send requests to hw during GEM init) move the
powersaving initialisation into the purview of i915_gem_init().
Signed-off-by: Chris Wilson
Cc
== Series Details ==
Series: series starting with [CI,01/10] drm/i915: Define an engine class enum
for the uABI
URL : https://patchwork.freedesktop.org/series/33181/
State : failure
== Summary ==
Series 33181v1 series starting with [CI,01/10] drm/i915: Define an engine class
enum for the uAB
Let userspace know if they can trust that new contexts are created using
HW default values; and avoid inheriting state from existing contexts.
Note: I intend to squash this into the bugfix once we agree on the uabi.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Joonas Lahtinen
Cc: Tvrtko U
intel_modeset_gem_init() now only sets up the legacy overlay, so let's
remove the function and call the setup directly during driver load. This
should help us find a better point in the initialisation sequence for it
later.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Reviewed-by: Mi
In the next few patches, we will want to both copy out of the context
image and write a valid image into a new context. To be completely safe,
we should then couple in our domain tracking to ensure that we don't
have any issues with stale data remaining in unwanted cachelines.
Historically, we omi
Now that we always execute a context switch upon module load, there is
no need to queue a delayed task for doing so. The purpose of the delayed
task is to enable GT powersaving, for which we need the HW state to be
valid (i.e. having loaded a context and initialised basic state). We
used to defer t
From: Tvrtko Ursulin
We want to be able to report back to userspace details about an engine's
class, and in return for userspace to be able to request actions
regarding certain classes of engines. To isolate the uABI from any
variations between hw generations, we define an abstract class for the
The first request submitted to an engine will take the prolonged GT
wakeref. If we discard that wakeref to issue a reset/suspend/etc, then
before restarting the engines, reacquire the GT's wakeref.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 3 +-
drivers/gpu/drm/
In the next few patches, we will have a hard requirement that we emit a
context-switch to the perma-pinned i915->kernel_context (so that we can
save the HW state using that context-switch). As the first context
itself may be classed as a kernel context, we want to be explicit in our
comparison. For
As we now record the default HW state and so only emit the "golden"
renderstate once to prepare the HW, there is no advantage in keeping the
renderstate batch around as it will never be used again.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h
GT powersaving is tightly coupled to the request infrastructure. To
avoid complications with the order of initialisation in the next patch
(where we want to send requests to hw during GEM init) move the
powersaving initialisation into the purview of i915_gem_init().
Signed-off-by: Chris Wilson
Cc
Take a copy of the HW state after a reset upon module loading by
executing a context switch from a blank context to the kernel context,
thus saving the default hw state over the blank context image.
We can then use the default hw state to initialise any future context,
ensuring that each starts wit
== Series Details ==
Series: drm/fbdev: Panel orientation connector property support (rev3)
URL : https://patchwork.freedesktop.org/series/32447/
State : warning
== Summary ==
Series 32447v3 drm/fbdev: Panel orientation connector property support
https://patchwork.freedesktop.org/api/1.0/serie
Hi All,
Here is v5 of my series to add a "panel orientation" property to
the drm-connector for the LCD panel to let userspace know about LCD
panels which are not mounted upright, as well as detecting upside-down
panels without needing quirks (like we do for 90 degree rotated screens).
New in v5:
On some hardware the LCD panel is not mounted upright in the casing,
but rotated by 90 degrees. In this case we want the console to
automatically be rotated to compensate.
The drm subsys has a quirk table for this, use the
drm_get_panel_orientation_quirk function to get the panel orientation
and s
On some devices the LCD panel is mounted in the casing in such a way that
the up/top side of the panel does not match with the top side of the
device (e.g. it is mounted upside-down).
This commit adds the necessary infra for lcd-panel drm_connector-s to
have a "panel orientation" property to commu
Apply the "panel orientation" drm connector prop to the primary plane so
that fbcon and fbdev using userspace programs display the right way up.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=94894
Signed-off-by: Hans de Goede
---
Changes in v2:
-New patch in v2 of this patch-set
Changes in
Some x86 clamshell design devices use portrait tablet screens and a display
engine which cannot rotate in hardware, so the firmware just leaves things
as is and we cannot figure out that the display is oriented non upright
from the hardware.
So at least on x86, we need a quirk table for this. This
On some hardware the LCD panel is not mounted upright in the casing,
but upside-down or rotated 90 degrees. In this case we want the console
to automatically be rotated to compensate.
The fbdev-driver may know about the need to rotate. Add a new
fbcon_rotate_hint field to struct fb_info, which get
Ideally we could use the VBT for this, that would be simple, in
intel_dsi_init() check dev_priv->vbt.dsi.config->rotation, set
connector->display_info.panel_orientation accordingly and call
drm_connector_init_panel_orientation_property(), done.
Unfortunately vbt.dsi.config->rotation is always 0 ev
This is now all handled in the drivers and communicated through
fb_info.fbcon_rotate_hint.
Signed-off-by: Hans de Goede
---
drivers/video/fbdev/core/Makefile | 3 -
drivers/video/fbdev/core/fbcon.c| 4 +-
drivers/video/fbdev/core/fbcon.h| 6 --
drivers/vid
Hi,
On 30-10-17 10:53, Daniel Vetter wrote:
On Mon, Oct 23, 2017 at 09:14:24AM +0200, Hans de Goede wrote:
On some hardware the LCD panel is not mounted upright in the casing,
but rotated by 90 degrees. In this case we want the console to
automatically be rotated to compensate.
The drm subsys
== Series Details ==
Series: series starting with [v4,01/10] drm/i915: Define an engine class enum
for the uABI
URL : https://patchwork.freedesktop.org/series/33173/
State : failure
== Summary ==
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-A:
pass -> DME
== Series Details ==
Series: series starting with [v4,01/10] drm/i915: Define an engine class enum
for the uABI
URL : https://patchwork.freedesktop.org/series/33173/
State : success
== Summary ==
Series 33173v1 series starting with [v4,01/10] drm/i915: Define an engine class
enum for the uAB
In the next few patches, we will have a hard requirement that we emit a
context-switch to the perma-pinned i915->kernel_context (so that we can
save the HW state using that context-switch). As the first context
itself may be classed as a kernel context, we want to be explicit in our
comparison. For
intel_modeset_gem_init() now only sets up the legacy overlay, so let's
remove the function and call the setup directly during driver load. This
should help us find a better point in the initialisation sequence for it
later.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Reviewed-by: Mi
Take a copy of the HW state after a reset upon module loading by
executing a context switch from a blank context to the kernel context,
thus saving the default hw state over the blank context image.
We can then use the default hw state to initialise any future context,
ensuring that each starts wit
Now that we always execute a context switch upon module load, there is
no need to queue a delayed task for doing so. The purpose of the delayed
task is to enable GT powersaving, for which we need the HW state to be
valid (i.e. having loaded a context and initialised basic state). We
used to defer t
Let userspace know if they can trust that new contexts are created using
HW default values; and avoid inheriting state from existing contexts.
Note: I intend to squash this into the bugfix once we agree on the uabi.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Joonas Lahtinen
Cc: Tvrtko U
The first request submitted to an engine will take the prolonged GT
wakeref. If we discard that wakeref to issue a reset/suspend/etc, then
before restarting the engines, reacquire the GT's wakeref.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 1 -
drivers/gpu/drm/i915/i915_
As we now record the default HW state and so only emit the "golden"
renderstate once to prepare the HW, there is no advantage in keeping the
renderstate batch around as it will never be used again.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h
In the next few patches, we will want to both copy out of the context
image and write a valid image into a new context. To be completely safe,
we should then couple in our domain tracking to ensure that we don't
have any issues with stale data remaining in unwanted cachelines.
Historically, we omi
GT powersaving is tightly coupled to the request infrastructure. To
avoid complications with the order of initialisation in the next patch
(where we want to send requests to hw during GEM init) move the
powersaving initialisation into the purview of i915_gem_init().
Signed-off-by: Chris Wilson
Cc
From: Tvrtko Ursulin
We want to be able to report back to userspace details about an engine's
class, and in return for userspace to be able to request actions
regarding certain classes of engines. To isolate the uABI from any
variations between hw generations, we define an abstract class for the
44 matches
Mail list logo
