In some cases like latency[level]==0, wm[level].res_lines>31,
min_ddb_alloc can be U16_MAX, exclude it from the WARN_ON.
v2: Specify the cases in which we hit U16_MAX, indentation (Ville)
Fixes: 10a7e07b68b9 ("drm/i915: Make sure cursor has enough ddb for the
selected wm level")
Suggested-by: Vi
[...]
> > > > > > > > > Which use a Crystal Cove PMIC, yet the LCD is connected to
> > > > > > > > > the SoC/LPSS
> > > > > > > > > PWM controller (and the VBT correctly indicates this), so
> > > > > > > > > here our old
> > > > > > > > > heuristics fail.
> > > > > > > > >
> > > > > > > > > Sin
Don't flat out fail if the system doesn't support OA, just skip.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/834
Signed-off-by: Chris Wilson
---
tests/perf.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/tests/perf.c b/tests/perf.c
index f5dd6051e..12f552743
On 2019.12.16 11:44:05 +0800, zhengbin wrote:
> Fixes coccicheck warning:
>
> drivers/gpu/drm/i915/gem/i915_gem_region.c:88:2-3: Unneeded semicolon
> drivers/gpu/drm/i915/gvt/gtt.c:1285:2-3: Unneeded semicolon
>
> Reported-by: Hulk Robot
> Signed-off-by: zhengbin
> ---
> drivers/gpu/drm/i915/g
On 16/12/2019 11:34, Chris Wilson wrote:
Don't flat out fail if the system doesn't support OA, just skip.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/834
Signed-off-by: Chris Wilson
---
tests/perf.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/tests/perf
Quoting Lionel Landwerlin (2019-12-16 09:46:56)
> On 16/12/2019 11:34, Chris Wilson wrote:
> > Don't flat out fail if the system doesn't support OA, just skip.
> >
> > Closes: https://gitlab.freedesktop.org/drm/intel/issues/834
> > Signed-off-by: Chris Wilson
> > ---
> > tests/perf.c | 4 +---
>
Hi,
On 16-12-2019 10:30, Lee Jones wrote:
[...]
Which use a Crystal Cove PMIC, yet the LCD is connected to the SoC/LPSS
PWM controller (and the VBT correctly indicates this), so here our old
heuristics fail.
Since only the i915 driver has access to the VBT, this commit renames
the "pwm_backli
On 16/12/2019 11:56, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-12-16 09:46:56)
On 16/12/2019 11:34, Chris Wilson wrote:
Don't flat out fail if the system doesn't support OA, just skip.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/834
Signed-off-by: Chris Wilson
---
tes
Quoting Lionel Landwerlin (2019-12-16 10:06:53)
> On 16/12/2019 11:56, Chris Wilson wrote:
>
> Quoting Lionel Landwerlin (2019-12-16 09:46:56)
>
> On 16/12/2019 11:34, Chris Wilson wrote:
>
> Don't flat out fail if the system doesn't support OA, just skip.
>
>
On 16/12/2019 11:34, Chris Wilson wrote:
Don't flat out fail if the system doesn't support OA, just skip.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/834
Signed-off-by: Chris Wilson
---
tests/perf.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/tests/perf
On Sun, Dec 15, 2019 at 5:38 PM Hans de Goede wrote:
> Linus, this series starts with the already discussed pinctrl change to
> export the function to unregister a pinctrl-map. We can either merge this
> through drm-intel, or you could pick it up and then provide an immutable
> branch with it for
Chris Wilson writes:
> The cmdparser tests are tied to the generation, so rename the tests to
> indicate that and remove the ambiguity that they are more generic tests.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
Acked-by: Mika Kuoppala
> ---
> tests/Makefile.sources
On Sun, Dec 15, 2019 at 5:38 PM Hans de Goede wrote:
> When the LCD has not been turned on by the firmware/GOP, because e.g. the
> device was booted with an external monitor connected over HDMI, we should
> not turn on the panel-enable GPIO when we request it.
>
> Turning on the panel-enable GPIO
On Sun, Dec 15, 2019 at 5:38 PM Hans de Goede wrote:
> On some older devices (BYT, CHT) which may use v2 VBT MIPI-sequences,
> we need to manually control the panel enable GPIO as v2 sequences do
> not do this.
>
> So far we have been carrying the code to do this on BYT/CHT devices
> with a Cryst
On Fri, 13 Dec 2019, Venkata Sandeep Dhanalakota
wrote:
> We do not require to register the sysctl paths per instance,
> so making registration global.
>
> v2: make sysctl path register and unregister function driver
> specific (Tvrtko and Lucas).
>
> v3: remove the NULL-check as unregister_s
Quoting Lionel Landwerlin (2019-12-16 10:06:53)
> On 16/12/2019 11:56, Chris Wilson wrote:
>
> Quoting Lionel Landwerlin (2019-12-16 09:46:56)
>
> On 16/12/2019 11:34, Chris Wilson wrote:
>
> Don't flat out fail if the system doesn't support OA, just skip.
>
>
On Sun, Dec 15, 2019 at 5:38 PM Hans de Goede wrote:
> On Bay Trail devices the MIPI power on/off sequences for DSI LCD panels
> do not control the LCD panel- and backlight-enable GPIOs. So far, when
> the VBT indicates we should use the SoC for backlight control, we have
> been relying on these
On Sun, Dec 15, 2019 at 5:38 PM Hans de Goede wrote:
> Move the Crystal Cove PMIC panel GPIO lookup-table from
> drivers/mfd/intel_soc_pmic_core.c to the i915 driver.
>
> The moved looked-up table is adding a GPIO lookup to the i915 PCI
> device and the GPIO subsys allows only one lookup table pe
If we inherit an error along the fence chain, we skip the main work
callback and go straight to the error. In the case of the vma bind
worker, we only dropped the pinned pages from the worker.
In the process, make sure we call the release earlier rather than wait
until the final reference to the f
Since obj->frontbuffer is no longer protected by the struct_mutex, as we
are processing the execbuf, it may be removed. Mark the
intel_frontbuffer as rcu protected, and so acquire a reference to
the struct as we track activity upon it.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/827
Fi
If the object is closed while we wait, that may move the vma we are
waiting on to the parked list allowing it to be destroyed underneath the
waiter. (i915_vma.kref! When do we want it? Yesterday!)
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 2 ++
1 file changed, 2 insertion
On 16/12/2019 12:27, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-12-16 10:06:53)
On 16/12/2019 11:56, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-12-16 09:46:56)
On 16/12/2019 11:34, Chris Wilson wrote:
Don't flat out fail if the system doesn't suppo
Hi Chris,
On Fri, Dec 13, 2019 at 10:31:40PM +, Chris Wilson wrote:
> Wait for the object to be idle before changing its cache-level and
> unbinding. This was dropped as supposedly superfluous from commit
> 8b1c78e06e61 ("drm/i915: Avoid calling i915_gem_object_unbind holding
> object lock"),
Hi,
On 16-12-2019 11:26, Linus Walleij wrote:
On Sun, Dec 15, 2019 at 5:38 PM Hans de Goede wrote:
Linus, this series starts with the already discussed pinctrl change to
export the function to unregister a pinctrl-map. We can either merge this
through drm-intel, or you could pick it up and th
Quoting Lionel Landwerlin (2019-12-16 10:41:40)
> On 16/12/2019 12:27, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2019-12-16 10:06:53)
> >> On 16/12/2019 11:56, Chris Wilson wrote:
> >>
> >> Quoting Lionel Landwerlin (2019-12-16 09:46:56)
> >>
> >> On 16/12/2019 11:34, Chris W
Hi,
On 16-12-2019 11:26, Linus Walleij wrote:
On Sun, Dec 15, 2019 at 5:38 PM Hans de Goede wrote:
Linus, this series starts with the already discussed pinctrl change to
export the function to unregister a pinctrl-map. We can either merge this
through drm-intel, or you could pick it up and th
Quoting Jani Nikula (2019-12-16 10:27:59)
> On Fri, 13 Dec 2019, Venkata Sandeep Dhanalakota
> wrote:
> > We do not require to register the sysctl paths per instance,
> > so making registration global.
> >
> > v2: make sysctl path register and unregister function driver
> > specific (Tvrtko a
Hi All,
This is a resend of the last 2 remaining patches of my series for adding
support for specifying panel_orientation on the kernel cmdline.
I've already pushed the other 11 patches which were mostly cleanups /
bug-fixes to the cmdline-parsing code and where all acked by Maxime
to drm-misc-ne
From: Derek Basehore
Not every platform needs quirk detection for panel orientation, so
split the drm_connector_init_panel_orientation_property into two
functions. One for platforms without the need for quirks, and the
other for platforms that need quirks.
Hans de Goede (changes in v2):
Rename
If the new video=... panel_orientation option is set for a connector, honor
it and setup a matching "panel orientation" property on the connector.
BugLink: https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/83
Acked-by: Maxime Ripard
Signed-off-by: Hans de Goede
---
drivers/gpu/drm
On Fri, Dec 13, 2019 at 04:14:55PM -0800, Lucas De Marchi wrote:
> On Thu, Dec 12, 2019 at 05:52:49PM +0200, Ville Syrjälä wrote:
> >On Wed, Dec 11, 2019 at 10:45:21AM -0800, José Roberto de Souza wrote:
> >> intel_connector_needs_modeset() will be used outside of
> >> intel_display.c in a future p
On Fri, Dec 13, 2019 at 06:28:40PM -0800, Manasi Navare wrote:
> On Fri, Dec 13, 2019 at 10:05:49PM +0200, Ville Syrjälä wrote:
> > On Wed, Dec 11, 2019 at 01:14:23PM -0800, Manasi Navare wrote:
> > > In case of tiled displays, all the tiles are linke dto each other
> > > for transcoder port sync.
From: Tvrtko Ursulin
Another re-spin of the per-client engine busyness series.
Review feedback from last round has been addressed* and the tracking simplified.
(*Apart from re-using the ctx->idr_lock for the global toggle, I kept using
struct mutext for that.)
Internally we track time spent on
From: Tvrtko Ursulin
Expose per-client and per-engine busyness under the previously added sysfs
client root.
The new files are one per-engine instance and located under the 'busy'
directory. Each contains a monotonically increasing nano-second resolution
times each client's jobs were executing o
From: Tvrtko Ursulin
Some clients have the DRM fd passed to them over a socket by the X server.
Grab the real client and pid when they create their first context and
update the exposed data for more useful enumeration.
v2:
* Do not leak the pid reference and borrow context idr_lock. (Chris)
S
Use intel_panel_compute_brightness() from pwm_setup_backlight() so that
we correctly take i915_modparams.invert_brightness and/or
QUIRK_INVERT_BRIGHTNESS into account when setting + getting the initial
brightness value.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_panel.c
Hi All,
Here is a resend of my series to fix the brightness being inverted on
Thundersoft TST178 tablets. This resend is based on top of dinq so that
the CI can properly test it. No changes other then the rebase on top of
dinq.
Regards,
Hans
___
Intel
From: Tvrtko Ursulin
By default we are not collecting any per-engine and per-context
statistcs.
Add a new sysfs toggle to enable this facility:
$ echo 1 >/sys/class/drm/card0/clients/enable_stats
v2: Rebase.
v3: sysfs_attr_init.
v4: Scheduler caps.
v5: for_each_uabi_engine
Signed-off-by: Tvrt
From: Tvrtko Ursulin
Some customers want to know how much of the GPU time are their clients
using in order to make dynamic load balancing decisions.
With the hooks already in place which track the overall engine busyness,
we can extend that slightly to split that time between contexts.
v2: Fix
The Thundersoft TST178 tablet uses a DSI panel with an external PWM
controller (as all DSI panels do). But unlike other DSI panels a duty-cycle
of 100% turns the backlight off and 0% sets it to maximum brightness.
I've checked the VBT and there is a BDB_LVDS_BACKLIGHT section, but
it does not set
From: Tvrtko Ursulin
Expose a list of clients with open file handles in sysfs.
This will be a basis for a top-like utility showing per-client and per-
engine GPU load.
Currently we only expose each client's pid and name under opaque numbered
directories in /sys/class/drm/card0/clients/.
For in
On Sun, Dec 15, 2019 at 05:38:09PM +0100, Hans de Goede wrote:
> Move the Crystal Cove PMIC panel GPIO lookup-table from
> drivers/mfd/intel_soc_pmic_core.c to the i915 driver.
>
> The moved looked-up table is adding a GPIO lookup to the i915 PCI
> device and the GPIO subsys allows only one lookup
On Mon, Dec 16, 2019 at 12:11 PM Hans de Goede wrote:
> Ugh, taking one last look at the "pinctrl: Export pinctrl_unregister_mappings"
> patch it is no good, sorry.
Ooops!
> Linus, can you please drop this from your -next ?
Sure, done.
> So I see 2 options:
> 1) Add an orig_map member to maps
On Sun, Dec 15, 2019 at 05:38:05PM +0100, Hans de Goede wrote:
> Hi All,
>
> This is a new (completely rewritten) version of my patches to make the
> i915 code control the SoC panel- and backlight-enable GPIOs on Bay Trail
> devices when the VBT indicates that the SoC should be used for backlight
When creating a handle, it is just that, an abstract handle. The fact
that we cannot currently support a handle larger than the size of the
backing storage is an artifact of our whole-object-at-a-time handling in
get_pages() and being an implementation limitation is best handled at
that point -- si
Quoting Tvrtko Ursulin (2019-12-16 12:07:00)
> @@ -1389,6 +1415,9 @@ static void execlists_submit_ports(struct
> intel_engine_cs *engine)
> write_desc(execlists,
>rq ? execlists_update_context(rq) : 0,
>n);
> +
> +
Hi,
* igt@gem_ctx_persistence@vcs1-mixed-process:
- shard-iclb: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7560/shard-iclb2/igt@gem_ctx_persiste...@vcs1-mixed-process.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15747/shard-icl
Quoting Tvrtko Ursulin (2019-12-16 12:07:01)
> From: Tvrtko Ursulin
>
> Expose a list of clients with open file handles in sysfs.
>
> This will be a basis for a top-like utility showing per-client and per-
> engine GPU load.
>
> Currently we only expose each client's pid and name under opaque n
Quoting Tvrtko Ursulin (2019-12-16 12:07:01)
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 0781b6326b8c..9fcbcb6d6f76 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -224,6 +224,20 @@ struct drm_i915_file_private
Quoting Tvrtko Ursulin (2019-12-16 12:07:01)
> +static void i915_gem_remove_client(struct drm_i915_file_private *file_priv)
> +{
> + struct i915_drm_clients *clients = &file_priv->dev_priv->clients;
> + struct i915_drm_client *client = &file_priv->client;
> +
> + if (!client->name
Quoting Tvrtko Ursulin (2019-12-16 12:07:02)
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 46b4d1d643f8..cd4ba6486f35 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
== Series Details ==
Series: Refactor Gen11+ SAGV support (rev14)
URL : https://patchwork.freedesktop.org/series/68028/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7560_full -> Patchwork_15747_full
Summary
---
**FA
On 16/12/2019 12:40, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-12-16 12:07:00)
@@ -1389,6 +1415,9 @@ static void execlists_submit_ports(struct intel_engine_cs
*engine)
write_desc(execlists,
rq ? execlists_update_context(rq) : 0,
Quoting Tvrtko Ursulin (2019-12-16 12:06:59)
> Implementation wise we add a a bunch of files in sysfs like:
>
> # cd /sys/class/drm/card0/clients/
> # tree
> .
> ├── 7
> │ ├── busy
> │ │ ├── 0
Prefer '0' over rcs?
> I will post the correspond
Hi,
On 16-12-2019 13:16, Andy Shevchenko wrote:
On Sun, Dec 15, 2019 at 05:38:09PM +0100, Hans de Goede wrote:
Move the Crystal Cove PMIC panel GPIO lookup-table from
drivers/mfd/intel_soc_pmic_core.c to the i915 driver.
The moved looked-up table is adding a GPIO lookup to the i915 PCI
device
On 16/12/2019 12:53, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-12-16 12:07:01)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0781b6326b8c..9fcbcb6d6f76 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -224,6 +22
On 16/12/2019 12:55, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-12-16 12:07:01)
+static void i915_gem_remove_client(struct drm_i915_file_private *file_priv)
+{
+ struct i915_drm_clients *clients = &file_priv->dev_priv->clients;
+ struct i915_drm_client *client = &file_priv->c
Quoting Tvrtko Ursulin (2019-12-16 12:07:01)
> From: Tvrtko Ursulin
>
> Expose a list of clients with open file handles in sysfs.
>
> This will be a basis for a top-like utility showing per-client and per-
> engine GPU load.
>
> Currently we only expose each client's pid and name under opaque n
On Mon, 16 Dec 2019 at 12:26, Chris Wilson wrote:
>
> When creating a handle, it is just that, an abstract handle. The fact
> that we cannot currently support a handle larger than the size of the
> backing storage is an artifact of our whole-object-at-a-time handling in
> get_pages() and being an
On 16/12/2019 13:09, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-12-16 12:06:59)
Implementation wise we add a a bunch of files in sysfs like:
# cd /sys/class/drm/card0/clients/
# tree
.
├── 7
│ ├── busy
│ │ ├── 0
Prefer '0' ove
Those shader tests are also irrelevant.
Best Regards,
Lisovskiy Stanislav
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
From: Patchwork [patchw...@emeril.freedesktop.org]
Sent: Monday, December 16, 2019 3:00 PM
To: Lisovs
Hi,
On 16-12-2019 13:16, Linus Walleij wrote:
On Mon, Dec 16, 2019 at 12:11 PM Hans de Goede wrote:
Ugh, taking one last look at the "pinctrl: Export pinctrl_unregister_mappings"
patch it is no good, sorry.
Ooops!
Linus, can you please drop this from your -next ?
Sure, done.
So I see
On 16/12/2019 13:17, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-12-16 12:07:01)
From: Tvrtko Ursulin
Expose a list of clients with open file handles in sysfs.
This will be a basis for a top-like utility showing per-client and per-
engine GPU load.
Currently we only expose each client
On Sun, Dec 15, 2019 at 10:33:06PM +0100, Hans de Goede wrote:
> Commit 82daca297506 ("drm/i915: Add "panel orientation" property to the
> panel connector, v6.") uses hardware state readback to determine if the
> GOP is rotating the image by 180 degrees to compensate for upside-down
> mounted panel
On Sun, Dec 15, 2019 at 10:33:07PM +0100, Hans de Goede wrote:
> Some devices with a builtin panel have the panel mounted upside down,
> this is indicated by the rotate_180 bit in the BDB_GENERAL_FEATURES VBT
> block.
>
> We store this info in dev_priv->vbt.orientation, use this to set the
> conne
Quoting Tvrtko Ursulin (2019-12-16 13:28:18)
>
> On 16/12/2019 13:17, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-12-16 12:07:01)
> >> From: Tvrtko Ursulin
> >>
> >> Expose a list of clients with open file handles in sysfs.
> >>
> >> This will be a basis for a top-like utility showing pe
On Sun, Dec 15, 2019 at 05:38:08PM +0100, Hans de Goede wrote:
> When the LCD has not been turned on by the firmware/GOP, because e.g. the
> device was booted with an external monitor connected over HDMI, we should
> not turn on the panel-enable GPIO when we request it.
>
> Turning on the panel-en
Stan,
spec@arb_gpu_shader5@texturegather@vs-rgba-3-float-cubearray is new test which
doesn't exist in CI bug log, so I can't do much here.
@Latvala, Petri/@Peres, Martin How do we proceed with these kind of issues in
future?
Lakshmi.
-Original Message-
From: Lisovskiy, Stanislav
Se
On Sun, Dec 15, 2019 at 05:38:07PM +0100, Hans de Goede wrote:
> On some older devices (BYT, CHT) which may use v2 VBT MIPI-sequences,
> we need to manually control the panel enable GPIO as v2 sequences do
> not do this.
>
> So far we have been carrying the code to do this on BYT/CHT devices
> wit
Hi,
Thank you for the reviews.
On 16-12-2019 14:45, Ville Syrjälä wrote:
On Sun, Dec 15, 2019 at 05:38:08PM +0100, Hans de Goede wrote:
When the LCD has not been turned on by the firmware/GOP, because e.g. the
device was booted with an external monitor connected over HDMI, we should
not turn o
On 16/12/2019 15:50, Vudum, Lakshminarayana wrote:
> Stan,
> spec@arb_gpu_shader5@texturegather@vs-rgba-3-float-cubearray is new test
> which doesn't exist in CI bug log, so I can't do much here.
>
> @Latvala, Petri/@Peres, Martin How do we proceed with these kind of issues in
> future?
Right
On Sun, Dec 15, 2019 at 05:38:09PM +0100, Hans de Goede wrote:
> Move the Crystal Cove PMIC panel GPIO lookup-table from
> drivers/mfd/intel_soc_pmic_core.c to the i915 driver.
>
> The moved looked-up table is adding a GPIO lookup to the i915 PCI
> device and the GPIO subsys allows only one lookup
On Sun, Dec 15, 2019 at 05:38:10PM +0100, Hans de Goede wrote:
> On Bay Trail devices the MIPI power on/off sequences for DSI LCD panels
> do not control the LCD panel- and backlight-enable GPIOs. So far, when
> the VBT indicates we should use the SoC for backlight control, we have
> been relying o
On Mon, Dec 16, 2019 at 02:51:54PM +0100, Hans de Goede wrote:
> Hi,
>
> Thank you for the reviews.
>
> On 16-12-2019 14:45, Ville Syrjälä wrote:
> > On Sun, Dec 15, 2019 at 05:38:08PM +0100, Hans de Goede wrote:
> >> When the LCD has not been turned on by the firmware/GOP, because e.g. the
> >>
Hi,
On 16-12-2019 14:56, Ville Syrjälä wrote:
On Sun, Dec 15, 2019 at 05:38:09PM +0100, Hans de Goede wrote:
Move the Crystal Cove PMIC panel GPIO lookup-table from
drivers/mfd/intel_soc_pmic_core.c to the i915 driver.
The moved looked-up table is adding a GPIO lookup to the i915 PCI
device an
On 09.12.2019 03.32, Chris Wilson wrote:
In order to avoid confusing the HW, we must never submit an empty ring
during lite-restore, that is we should always advance the RING_TAIL
before submitting to stay ahead of the RING_HEAD.
Normally this is prevented by keeping a couple of spare NOPs in th
Signed-off-by: Maya Rashish
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 7fcdcf31dc76..a0e437aa65b7 100644
--- a/drivers/gpu/drm/i915/i915_cmd_p
On 12/16/19 2:14 AM, Alexey Budankov wrote:
Introduce CAP_SYS_PERFMON capability devoted to secure system performance
monitoring and observability operations so that CAP_SYS_PERFMON would assist
CAP_SYS_ADMIN capability in its governing role for perf_events, i915_perf
and other performance monit
lgtm
Reviewed-by: Thomas Anderson
On Fri, Dec 13, 2019 at 07:43:47PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Now that the cea mode handling is not 100% tied to the single
> array the dummy VIC 0 mode is pretty much pointles. Throw it
> out.
>
> v2: Rebase
>
> Cc: Tom Anderson
Latest patch looks good to me, thanks for the changes!
Reviewed-by: Thomas Anderson
On Fri, Dec 13, 2019 at 07:43:45PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We're going to need two cea mode tables (one for VICs < 128,
> another one for VICs >= 193). To that end replace the dire
Hello,
I am working together with a small team of volunteers on a project that
aims to make Linux usable on Microsoft Surface devices (linux-surface).
The touchscreens of these devices use Intel Precise Touch & Stylus
(IPTS) technology, which makes use of the GPU (through GuC submission)
to proce
Fixes coccicheck warning:
drivers/gpu/drm/i915/gem/i915_gem_region.c:88:2-3: Unneeded semicolon
drivers/gpu/drm/i915/gvt/gtt.c:1285:2-3: Unneeded semicolon
Reported-by: Hulk Robot
Signed-off-by: zhengbin
---
drivers/gpu/drm/i915/gem/i915_gem_region.c | 2 +-
drivers/gpu/drm/i915/gvt/gtt.c
With a couple more memory barriers dotted around the place we can
significantly reduce the MTBF on Ivybridge. Still doesn't really help
Haswell though.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
.../gpu/drm/i915/gt/intel_ring_submission.c | 110 +++---
drivers/gpu/drm/i915/
Hi,
On 16-12-2019 15:04, Ville Syrjälä wrote:
On Sun, Dec 15, 2019 at 05:38:10PM +0100, Hans de Goede wrote:
On Bay Trail devices the MIPI power on/off sequences for DSI LCD panels
do not control the LCD panel- and backlight-enable GPIOs. So far, when
the VBT indicates we should use the SoC for
On Fri, 2019-12-13 at 16:52 -0800, Matt Roper wrote:
> On Fri, Dec 13, 2019 at 03:02:28PM +0200, Stanislav Lisovskiy wrote:
> > Added proper DBuf slice mapping to correspondent
> > pipes, depending on pipe configuration as stated
> > in BSpec.
> >
> > v2:
> > - Remove unneeded braces
> > -
On Wed, Dec 11, 2019 at 01:14:23PM -0800, Manasi Navare wrote:
> In case of tiled displays, all the tiles are linke dto each other
> for transcoder port sync. So in intel_atomic_check() we need to make
> sure that we add all the tiles to the modeset and if one of the
> tiles needs a full modeset th
== Series Details ==
Series: Refactor Gen11+ SAGV support (rev14)
URL : https://patchwork.freedesktop.org/series/68028/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7560_full -> Patchwork_15747_full
Summary
---
**FA
Hi,
On 15-12-2019 21:08, Patchwork wrote:
== Series Details ==
Series: drm/i915: opregion: set opregion chpd value to indicate the driver
handles hotplug (rev4)
URL : https://patchwork.freedesktop.org/series/69902/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7569_full ->
Hi,
On 16-12-2019 15:14, Ville Syrjälä wrote:
On Mon, Dec 16, 2019 at 02:51:54PM +0100, Hans de Goede wrote:
Hi,
Thank you for the reviews.
On 16-12-2019 14:45, Ville Syrjälä wrote:
On Sun, Dec 15, 2019 at 05:38:08PM +0100, Hans de Goede wrote:
When the LCD has not been turned on by the fir
On Fri, 2019-12-13 at 11:01 -0800, Matt Roper wrote:
> On Fri, Dec 13, 2019 at 03:02:27PM +0200, Stanislav Lisovskiy wrote:
> > Start manipulating DBuf slices as a mask,
> > but not as a total number, as current approach
> > doesn't give us full control on all combinations
> > of slices, which we m
On Fri, Dec 13, 2019 at 01:03:30PM -0800, Tom Anderson wrote:
> Latest patch looks good to me, thanks for the changes!
>
> Reviewed-by: Thomas Anderson
Thanks for the review. Series pushed to drm-misc-next.
>
> On Fri, Dec 13, 2019 at 07:43:45PM +0200, Ville Syrjala wrote:
> > From: Ville Syrj
== Series Details ==
Series: AUX power well fixes (rev4)
URL : https://patchwork.freedesktop.org/series/70857/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7554_full -> Patchwork_15737_full
Summary
---
**FAILURE**
== Series Details ==
Series: drm/i915: Fix WARN_ON condition for cursor plane ddb allocation (rev2)
URL : https://patchwork.freedesktop.org/series/70893/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7573 -> Patchwork_15784
== Series Details ==
Series: Refactor Gen11+ SAGV support (rev14)
URL : https://patchwork.freedesktop.org/series/68028/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7560_full -> Patchwork_15747_full
Summary
---
**SU
On Mon, 16 Dec 2019, Andy Shevchenko wrote:
> On Sun, Dec 15, 2019 at 05:38:05PM +0100, Hans de Goede wrote:
> > Hi All,
> >
> > This is a new (completely rewritten) version of my patches to make the
> > i915 code control the SoC panel- and backlight-enable GPIOs on Bay Trail
> > devices when the
== Series Details ==
Series: series starting with [1/2] drm/i915/dsi: Remove readback of panel
orientation on BYT / CHT (rev2)
URL : https://patchwork.freedesktop.org/series/70952/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
795b7491bcca drm/i915/dsi: Remove readback of pane
== Series Details ==
Series: series starting with [1/3] drm/i915: Unpin vma->obj on early error
URL : https://patchwork.freedesktop.org/series/70974/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7573 -> Patchwork_15785
Sum
Since obj->frontbuffer is no longer protected by the struct_mutex, as we
are processing the execbuf, it may be removed. Mark the
intel_frontbuffer as rcu protected, and so acquire a reference to
the struct as we track activity upon it.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/827
Fi
If we inherit an error along the fence chain, we skip the main work
callback and go straight to the error. In the case of the vma bind
worker, we only dropped the pinned pages from the worker.
In the process, make sure we call the release earlier rather than wait
until the final reference to the f
On 12/12/2019 01:46, Chris Wilson wrote:
Currently we use the intel_timeline.mutex to guard constructing and
retiring requests in the timeline, including the adding and removing of
the request from the list of requests (intel_timeline.requests).
However, we want to peek at neighbouring elements
1 - 100 of 226 matches
Mail list logo
