It is OK for me for all your comments, thanks!
Just one question need to confirm with you inline.
>A couple of comments below.
>
>
>On Thu, Jan 19, 2017 at 04:32:19PM +0800, Terrence Xu wrote:
>> GVT-g (Intel(r) Graphics Virtualization Technology) is a full GPU
>> virtualization solution with medi
On Fri, Dec 16, 2016 at 12:29:06PM +0200, Jani Nikula wrote:
> From: Manasi Navare
>
> At the time userspace does setcrtc, we've already promised the mode
> would work. The promise is based on the theoretical capabilities of
> the link, but it's possible we can't reach this in practice. The DP
>
On Wed, Feb 15, 2017 at 03:52:59PM +0200, Mika Kuoppala wrote:
> Certain Baytrails, namely the 4 cpu core variants, have been
> plaqued by spurious system hangs, mostly occurring with light loads.
>
> Multiple bisects by various people point to a commit which changes the
> reclocking strategy for
My normalization hack fell over a topic branch :(
Signed-off-by: Daniel Vetter
---
dim | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dim b/dim
index 457bf93d8a11..6d3b9734b348 100755
--- a/dim
+++ b/dim
@@ -502,7 +502,7 @@ function dim_rebuild_tip
gi
On Thu, Feb 09, 2017 at 09:34:49AM +0200, Joonas Lahtinen wrote:
> On ke, 2017-02-08 at 18:18 -0800, Michel Thierry wrote:
> > Bring the test/set/clear bit functions we have into a single place.
> >
> > Signed-off-by: Michel Thierry
>
> Reviewed-by: Joonas Lahtinen
Can we please have docs for
Currently we are already setting a pm_runtime_disabled flag and disabling
runtime-pm for i2c-busses used for accessing the system PMIC on x86.
But this is not enough, there are ACPI opregions which may want to access
the PMIC during late-suspend and early-resume, so we need to completely
disable pm
Hi All,
Note these 2 patches apply on top of my previous i2c-designware patches.
Daniel Vetter should merge these soon (together with the dependent i915
patches) and then provide a stable branch to merge into the i2c subsys
next branch.
These will not apply cleanly without these patches in places
Cherrytrail devices use the dw i2c-bus with uid 7 to access their PMIC.
Even if the i2c-bus to the PMIC is not shared with the SoC's P-Unit
and i2c-designware-baytrail.c thus does not set the pm_disabled flag,
we still need to disable pm so that ACPI PMIC opregions can access the
PMIC during late-s
On 22/02/2017 08:44, Chris Wilson wrote:
On Wed, Feb 22, 2017 at 08:29:06AM +, Tvrtko Ursulin wrote:
On 21/02/2017 15:01, Joonas Lahtinen wrote:
On pe, 2017-02-17 at 15:10 +, Chris Wilson wrote:
The object already stores (computed on the fly) the index to dma address
so use it instea
On 24/02/2017 18:01, Chris Wilson wrote:
The two users of the return value from intel_engine_wakeup() are
expecting different results. In the breadcrumbs hangcheck, we are using
it to determine whether wake_up_process() detected the waiter was
currently running (and if so we presume that it hasn
On 25/02/2017 10:05, Chris Wilson wrote:
As execlists and other non-semaphore multi-engine devices coordinate
between engines using interrupts, we can shave off a few 10s of
microsecond of scheduling latency by doing the fence signaling from the
interrupt as opposed to a RT kthread. (Realistical
On Mon, Feb 27, 2017 at 09:55:10AM +, Tvrtko Ursulin wrote:
>
> On 22/02/2017 08:44, Chris Wilson wrote:
> >I also think that's an argument for improving the general cache rather
> >than arguing against using it.
>
> Well I wasn't concerned about the cache per se, but about whether it
> is co
On 27/02/2017 10:06, Chris Wilson wrote:
On Mon, Feb 27, 2017 at 09:55:10AM +, Tvrtko Ursulin wrote:
On 22/02/2017 08:44, Chris Wilson wrote:
I also think that's an argument for improving the general cache rather
than arguing against using it.
Well I wasn't concerned about the cache per
On 24/02/2017 18:01, Chris Wilson wrote:
By deferring hangcheck to the fake breadcrumb interrupt, we can simply
the enabling procedure slightly - as by enabling the fake, we then
enable the hangcheck. By always enabling the hangcheck from each fake
interrupt (it will be a no-op for an already qu
On Mon, Feb 27, 2017 at 10:14:12AM +, Tvrtko Ursulin wrote:
>
> On 27/02/2017 10:06, Chris Wilson wrote:
> >On Mon, Feb 27, 2017 at 09:55:10AM +, Tvrtko Ursulin wrote:
> >>
> >>On 22/02/2017 08:44, Chris Wilson wrote:
> >>>I also think that's an argument for improving the general cache rat
On some devices only MIPI PORT C is used, in this case checking the
MIPI PORT A CTRL AFE_LATCHOUT bit (there is no such bit for PORT C
on VLV/CHT) will result in false positive "DSI LP not going Low" errors
as this checks the PORT A clk status.
In case both ports are used we have already checked t
On Mon, 27 Feb 2017 10:38:29 +0100,
Hans de Goede wrote:
>
> index a8e74ca..a4ac473 100644
> --- a/drivers/i2c/busses/i2c-designware-core.h
> +++ b/drivers/i2c/busses/i2c-designware-core.h
> @@ -79,7 +79,7 @@
> * @pm_qos: pm_qos_request used while holding a hardware lock on the bus
> * @acquir
== Series Details ==
Series: i915: Dealing with 90° rotated display ?
URL : https://patchwork.freedesktop.org/series/20254/
State : success
== Summary ==
Series 20254v1 i915: Dealing with 90° rotated display ?
https://patchwork.freedesktop.org/api/1.0/series/20254/revisions/1/mbox/
fi-bdw-555
On 24/02/2017 18:01, Chris Wilson wrote:
A significant cost in setting up a wait is the overhead of enabling the
interrupt. As we disable the interrupt whenever the queue of waiters is
empty, if we are frequently waiting on alternating batches, we end up
re-enabling the interrupt on a frequent b
Hi,
On 27-02-17 11:25, Takashi Iwai wrote:
On Mon, 27 Feb 2017 10:38:29 +0100,
Hans de Goede wrote:
index a8e74ca..a4ac473 100644
--- a/drivers/i2c/busses/i2c-designware-core.h
+++ b/drivers/i2c/busses/i2c-designware-core.h
@@ -79,7 +79,7 @@
* @pm_qos: pm_qos_request used while holding a har
On 24/02/2017 18:01, Chris Wilson wrote:
Now the only use of the return value is ask whether or not we actually
woke a process up. With a single condition to report, we can go back to
using a boolean.
Argh! :) I guess it depends on whether you keep or not the open coded
intel_engine_wakeup's
On Mon, Feb 27, 2017 at 10:03:32AM +, Tvrtko Ursulin wrote:
>
> On 24/02/2017 18:01, Chris Wilson wrote:
> >The two users of the return value from intel_engine_wakeup() are
> >expecting different results. In the breadcrumbs hangcheck, we are using
> >it to determine whether wake_up_process() d
On Mon, Feb 27, 2017 at 11:25:01AM +0100, Takashi Iwai wrote:
> On Mon, 27 Feb 2017 10:38:29 +0100,
> Hans de Goede wrote:
> >
> > index a8e74ca..a4ac473 100644
> > --- a/drivers/i2c/busses/i2c-designware-core.h
> > +++ b/drivers/i2c/busses/i2c-designware-core.h
> > @@ -79,7 +79,7 @@
> > * @pm_q
Michał Winiarski writes:
> Used by production device:
> Intel(R) Iris(TM) Graphics P555
>
> Cc: Mika Kuoppala
> Cc: Rodrigo Vivi
> Signed-off-by: Michał Winiarski
Reviewed-by: Mika Kuoppala
> ---
> include/drm/i915_pciids.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>
== Series Details ==
Series: drm/i915: Only unwind the local pgtable layer if empty
URL : https://patchwork.freedesktop.org/series/20256/
State : success
== Summary ==
Series 20256v1 drm/i915: Only unwind the local pgtable layer if empty
https://patchwork.freedesktop.org/api/1.0/series/20256/r
On Mon, Feb 27, 2017 at 10:31:36AM +, Tvrtko Ursulin wrote:
>
> On 24/02/2017 18:01, Chris Wilson wrote:
> >A significant cost in setting up a wait is the overhead of enabling the
> >interrupt. As we disable the interrupt whenever the queue of waiters is
> >empty, if we are frequently waiting
On Mon, 27 Feb 2017 11:32:45 +0100,
Hans de Goede wrote:
>
> Hi,
>
> On 27-02-17 11:25, Takashi Iwai wrote:
> > On Mon, 27 Feb 2017 10:38:29 +0100,
> > Hans de Goede wrote:
> >>
> >> index a8e74ca..a4ac473 100644
> >> --- a/drivers/i2c/busses/i2c-designware-core.h
> >> +++ b/drivers/i2c/busses/i2
== Series Details ==
Series: series starting with [1/3] drm/i915: Only unwind the local pgtable
layer if empty
URL : https://patchwork.freedesktop.org/series/20257/
State : success
== Summary ==
Series 20257v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/20257/
Used by production device:
Intel(R) Iris(TM) Graphics P555
Cc:
Cc: Mika Kuoppala
Cc: Rodrigo Vivi
Signed-off-by: Michał Winiarski
Reviewed-by: Rodrigo Vivi
Reviewed-by: Mika Kuoppala
---
include/drm/i915_pciids.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/incl
On 25 February 2017 at 23:25, Chris Wilson wrote:
> Only if we allocated the layer and the lower level failed should we
> remove this layer when unwinding. Otherwise we ignore the overlapping
> entries by overwritting the old layer with scratch.
overwriting
>
> Fixes: c5d092a4293f ("drm/i915: Rem
== Series Details ==
Series: drm/i915: Include fence-hint for timeout warning
URL : https://patchwork.freedesktop.org/series/20264/
State : success
== Summary ==
Series 20264v1 drm/i915: Include fence-hint for timeout warning
https://patchwork.freedesktop.org/api/1.0/series/20264/revisions/1/m
Op 23-02-17 om 16:24 schreef Sean Paul:
> On Tue, Feb 21, 2017 at 02:51:42PM +0100, Maarten Lankhorst wrote:
>> This introduces a slight behavioral change to rmfb. Instead of
>> disabling a crtc when the primary plane is disabled, we try to
>> preserve it.
>>
>> Apart from old versions of the vmwgf
On la, 2017-02-25 at 23:25 +, Chris Wilson wrote:
> As we track whether a vma has been inserted into the drm_mm using the
> vma->flags, if we fail to bind the vma into the GTT we do not update
> those bits and will attempt to reinsert the vma into the drm_mm on
> future passes. To prevent that,
On pe, 2017-02-24 at 11:48 -0800, Daniele Ceraolo Spurio wrote:
> Reviewed-by: Daniele Ceraolo Spurio
Pushed, thanks for the patch and review.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing lis
On Mon, Feb 27, 2017 at 02:02:00PM +0200, Joonas Lahtinen wrote:
> On la, 2017-02-25 at 23:25 +, Chris Wilson wrote:
> > As we track whether a vma has been inserted into the drm_mm using the
> > vma->flags, if we fail to bind the vma into the GTT we do not update
> > those bits and will attempt
On Mon, Feb 27, 2017 at 11:48:46AM +, Matthew Auld wrote:
> On 25 February 2017 at 23:25, Chris Wilson wrote:
> > Only if we allocated the layer and the lower level failed should we
> > remove this layer when unwinding. Otherwise we ignore the overlapping
> > entries by overwritting the old la
On 25 February 2017 at 23:25, Chris Wilson wrote:
> If we fail to allocate the ppgtt range after allocating the pages for
> the vma, we should unwind the local allocation before reporting back the
> failure.
>
> Fixes: ff685975d97f ("drm/i915: Move allocate_va_range to GTT")
> Signed-off-by: Chris
On pe, 2017-02-24 at 16:39 +0100, Arkadiusz Hiler wrote:
> Instead of calling intel_guc_init() and intel_huc_init() one by one this
> patch introduces intel_uc_init_fw() function that calls them both.
>
> Called functions are renamed accordingly.
>
> Trying to have subject_verb_object ordering an
On 22 February 2017 at 15:25, Robert Bragg wrote:
> A minor improvement to debugging output
>
> Signed-off-by: Robert Bragg
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listi
== Series Details ==
Series: drm/i915/skl: Add missing SKL ID (rev3)
URL : https://patchwork.freedesktop.org/series/3537/
State : success
== Summary ==
Series 3537v3 drm/i915/skl: Add missing SKL ID
https://patchwork.freedesktop.org/api/1.0/series/3537/revisions/3/mbox/
fi-bdw-5557u total
On pe, 2017-02-24 at 16:40 +0100, Arkadiusz Hiler wrote:
> intel_{h,g}uc_init_fw selects correct firmware and then triggers it's
> preparation (fetch + initial parsing).
>
> This change separates out select steps, so those can be called by
> the sanitize_options().
>
> Then, during the init_fw()
Only if we allocated the layer and the lower level failed should we
remove this layer when unwinding. Otherwise we ignore the overlapping
entries by overwriting the old layer with scratch.
Fixes: c5d092a4293f ("drm/i915: Remove bitmap tracking for used-pml4")
Fixes: e2b763caa6eb ("drm/i915: Remove
As we track whether a vma has been inserted into the drm_mm using the
vma->flags, if we fail to bind the vma into the GTT we do not update
those bits and will attempt to reinsert the vma into the drm_mm on
future passes. To prevent that, we want to unwind i915_vma_insert() if
we fail in our attempt
If we fail to allocate the ppgtt range after allocating the pages for
the vma, we should unwind the local allocation before reporting back the
failure.
Fixes: ff685975d97f ("drm/i915: Move allocate_va_range to GTT")
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Reviewed-by: Matthew Auld
---
dri
The file fits better.
Additionally rename it to intel_uc_prepare_fw(), as the function does
more than simple fetch.
v2: remove second declaration, reorder (M. Wajdeczko)
Cc: Michal Wajdeczko
Signed-off-by: Arkadiusz Hiler
---
drivers/gpu/drm/i915/intel_guc_loader.c | 137 +
On pe, 2017-02-24 at 16:40 +0100, Arkadiusz Hiler wrote:
> `guc_firmware_path` and `huc_firmware_path` module parameters are added.
>
> Using the parameter disabled version checks and loads desired firmware
> instead of the default one.
>
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Michal Wi
Let intel_guc_init_fw() focus on determining and fetching the correct
firmware.
This patch introduces intel_uc_sanitize_options() that is called from
intel_sanitize_options().
Then, if we have GuC, we can call intel_guc_init_fw() conditionally
and we do not have to do the internal checks.
v2: fi
On ma, 2017-02-27 at 10:21 +, Chris Wilson wrote:
> On Mon, Feb 27, 2017 at 10:14:12AM +, Tvrtko Ursulin wrote:
> > Perhaps you could say what kind of optimisation you have in mind to
> > save me guessing? :)
>
> I was thinking you would like an inactivity timer. Or we could have a
> separ
== Series Details ==
Series: series starting with [CI,1/3] drm/i915: Only unwind the local pgtable
layer if empty
URL : https://patchwork.freedesktop.org/series/20303/
State : success
== Summary ==
Series 20303v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/203
Michał Winiarski writes:
> Used by production device:
> Intel(R) Iris(TM) Graphics P555
>
> Cc:
> Cc: Mika Kuoppala
> Cc: Rodrigo Vivi
> Signed-off-by: Michał Winiarski
> Reviewed-by: Rodrigo Vivi
> Reviewed-by: Mika Kuoppala
Pushed to dinq, thanks for patch and review.
-Mika
> ---
>
Chris Wilson writes:
> On Wed, Feb 15, 2017 at 03:52:59PM +0200, Mika Kuoppala wrote:
>> Certain Baytrails, namely the 4 cpu core variants, have been
>> plaqued by spurious system hangs, mostly occurring with light loads.
>>
>> Multiple bisects by various people point to a commit which changes t
A significant cost in setting up a wait is the overhead of enabling the
interrupt. As we disable the interrupt whenever the queue of waiters is
empty, if we are frequently waiting on alternating batches, we end up
re-enabling the interrupt on a frequent basis. We do want to disable the
interrupt du
The two users of the return value from intel_engine_wakeup() are
expecting different results. In the breadcrumbs hangcheck, we are using
it to determine whether wake_up_process() detected the waiter was
currently running (and if so we presume that it hasn't yet missed the
interrupt). However, in th
By deferring hangcheck to the fake breadcrumb interrupt, we can simply
the enabling procedure slightly - as by enabling the fake, we then
enable the hangcheck. By always enabling the hangcheck from each fake
interrupt (it will be a no-op for an already queued hangcheck), it will
make restoring the
As execlists and other non-semaphore multi-engine devices coordinate
between engines using interrupts, we can shave off a few 10s of
microsecond of scheduling latency by doing the fence signaling from the
interrupt as opposed to a RT kthread. (Realistically the delay adds
about 1% to an individual
On Sun, 26 Feb 2017, Enrico Mioso wrote:
> Hello. I am not using this computer actively and can't report easily
> on the state of the screen. Still, I observed the following situation
> in the system's dmesg: running the stock Archlinux Kernel. This is an
> Apple MacMini system, booted via an EF
On Mon, 27 Feb 2017, Joonas Lahtinen wrote:
> On pe, 2017-02-24 at 16:40 +0100, Arkadiusz Hiler wrote:
>> `guc_firmware_path` and `huc_firmware_path` module parameters are added.
>>
>> Using the parameter disabled version checks and loads desired firmware
>> instead of the default one.
>>
>> Cc:
In the next patch, we will allow for obj->mm.__pages to be populated
asynchronously. This means that simply acquiring a pages_pin_count is no
longer sufficient to be sure the pages are there, we need to acquire the
pin (to prevent the pages from disappearing again) and then wait for the
completion.
Currently we have a heavyweight EAGAIN loop round tripping to userspace
to handle asynchronous loading. However, we now have fences to handle
asynchronous execution. Fun times ahead. For starters, let's move the
current asynchronous get_pages onto a more secure footing.
-Chris
Check that we can retrieve the right page for a random index, and that
we can map the whole object.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_object.c | 1 +
drivers/gpu/drm/i915/selftests/i915_gem_object.c | 405 +
.../gpu/drm/i915/selftes
To begin with move obj->mm related operations to i915_gem_object.c, in
preparation for future tweaks.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_drv.h| 107 --
drivers/gpu/drm/i915/i915_gem.c
+Mika & Andy
On Saturday, February 25, 2017 07:23:28 PM Hans de Goede wrote:
> Several cherrytrail devices (all of which ship with windows 10) hide the
> lpss pwm controller in ACPI, typically the _STA method looks like this:
>
> Method (_STA, 0, NotSerialized) // _STA: Status
> {
>
On 02/27/2017 10:13 AM, Xu, Terrence wrote:
[Xu, Terrence] Yes the root is needed for all our "echo" related commands, can I suppose
the case is running under root privilege? Or need to return "skip" when it is not under
root privilege?
Right, seems I was a bit confused there and there are
On 27/02/2017 13:24, Chris Wilson wrote:
A significant cost in setting up a wait is the overhead of enabling the
interrupt. As we disable the interrupt whenever the queue of waiters is
empty, if we are frequently waiting on alternating batches, we end up
re-enabling the interrupt on a frequent b
We are required to reload the TLBs around context switches
(MI_SET_CONTEXT specifically) and the recommendation is do that before
the MI_SET_CONTEXT so that it is serialised with the switch and not
forgotten:
[DevSNB] If Flush TLB invalidation Mode is enabled it’s the driver’s
responsibility to in
We are required to reload the TLBs around ppgtt switches. However, we
already do an unconditional TLB invalidate before every batch and a flush
afterwards, so this condition is already satisfied without extra flushes
around the LRI instructions.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuopp
No hardware was ever shipped that needed more than 4096 byte alignment
and future hardware will not use this legacy path. So reduce the
alignment to make it easier and quicker to launch workloads.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_context.c
== Series Details ==
Series: GuC Scrub vol. 1 (rev7)
URL : https://patchwork.freedesktop.org/series/16856/
State : failure
== Summary ==
In file included from drivers/gpu/drm/i915/i915_drv.h:60:0,
from drivers/gpu/drm/i915/i915_gem_execbuffer.c:37:
drivers/gpu/drm/i915/intel_u
On Mon, Feb 27, 2017 at 01:57:35PM +, Tvrtko Ursulin wrote:
>
> On 27/02/2017 13:24, Chris Wilson wrote:
> > if (b->hangcheck_interrupts != atomic_read(&engine->irq_count)) {
> >@@ -67,7 +76,7 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
> > * to process the pending
On Mon, Feb 27, 2017 at 02:06:58PM +, Chris Wilson wrote:
> On Mon, Feb 27, 2017 at 01:57:35PM +, Tvrtko Ursulin wrote:
> >
> > On 27/02/2017 13:24, Chris Wilson wrote:
> > > if (b->hangcheck_interrupts != atomic_read(&engine->irq_count)) {
> > >@@ -67,7 +76,7 @@ static void intel_breadc
To make our adjustments to RPS requires taking a mutex and potentially
sleeping for an unknown duration - until we have completed our
adjustments further RPS interrupts are immaterial (they are based on
stale thresholds) and we can safely ignore them.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
On Baytrail, we manually calculate busyness over the evaluation interval
to avoid issues with miscaluations with RC6 enabled. However, it turns
out that the DOWN_EI interrupt generator is completely bust - it
operates in two modes, continuous or never. Neither of which are
conducive to good behavio
Hi,
On 27-02-17 14:30, Rafael J. Wysocki wrote:
+Mika & Andy
On Saturday, February 25, 2017 07:23:28 PM Hans de Goede wrote:
Several cherrytrail devices (all of which ship with windows 10) hide the
lpss pwm controller in ACPI, typically the _STA method looks like this:
Method (_STA, 0, No
On 27/02/2017 10:21, Chris Wilson wrote:
On Mon, Feb 27, 2017 at 10:14:12AM +, Tvrtko Ursulin wrote:
On 27/02/2017 10:06, Chris Wilson wrote:
On Mon, Feb 27, 2017 at 09:55:10AM +, Tvrtko Ursulin wrote:
On 22/02/2017 08:44, Chris Wilson wrote:
I also think that's an argument for imp
On Mon, 27 Feb 2017 15:25:32 +0100,
Hans de Goede wrote:
>
> Hi,
>
> On 27-02-17 14:30, Rafael J. Wysocki wrote:
> > +Mika & Andy
> >
> > On Saturday, February 25, 2017 07:23:28 PM Hans de Goede wrote:
> >> Several cherrytrail devices (all of which ship with windows 10) hide the
> >> lpss pwm con
== Series Details ==
Series: series starting with [v5,1/4] drm/i915: Report both waiters and success
from intel_engine_wakeup()
URL : https://patchwork.freedesktop.org/series/20310/
State : failure
== Summary ==
Series 20310v1 Series without cover letter
https://patchwork.freedesktop.org/api/
On Mon, Feb 27, 2017 at 02:52:27PM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [v5,1/4] drm/i915: Report both waiters and
> success from intel_engine_wakeup()
> URL : https://patchwork.freedesktop.org/series/20310/
> State : failure
>
> == Summary ==
>
> Se
On Sun, Feb 26, 2017 at 10:22:42PM +0100, Daniel Vetter wrote:
> On Fri, Feb 17, 2017 at 05:20:54PM +0200, Jani Nikula wrote:
> > Handle debugfs override edid and firmware edid at the low level to
> > transparently and completely replace the real edid. Previously, we
> > practically only used the m
On Sun, Feb 26, 2017 at 02:41:50PM -0800, Chad Versace wrote:
> On Wed 04 Jan 2017, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > SKL+ display engine can scan out certain kinds of compressed surfaces
> > produced by the render engine. This involved telling the display engin
== Series Details ==
Series: series starting with [1/3] drm/i915: Start splitting out
i915_gem_object routines
URL : https://patchwork.freedesktop.org/series/20312/
State : warning
== Summary ==
Series 20312v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/20312/
On Fri, Feb 24, 2017 at 06:26:10PM +0100, Michal Wajdeczko wrote:
> On Fri, Feb 24, 2017 at 04:40:01PM +0100, Arkadiusz Hiler wrote:
> > Current version of intel_guc_init_hw() does a lot:
> > - cares about submission
> > - loads huc
> > - implement WA
> >
> > This change offloads some of the lo
Hi Dave,
drm-misc-next-fixes-2017-02-27:
Misc fixes for the 4.11 merge window.
- vmwgfx drm_control node compat patch
- rockchip&zte fixes
- compat32 support for dma-buf ioctl (cc: stable ofc, since this is a
massive fumble. oops)
Nothing major outstanding afaik.
Cheers, Daniel
The followin
== Series Details ==
Series: series starting with [CI,1/3] drm/i915: Remove redundant TLB invalidate
on switching contexts
URL : https://patchwork.freedesktop.org/series/20313/
State : success
== Summary ==
Series 20313v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/s
On Mon, Feb 27, 2017 at 03:52:12PM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [CI,1/3] drm/i915: Remove redundant TLB
> invalidate on switching contexts
> URL : https://patchwork.freedesktop.org/series/20313/
> State : success
>
> == Summary ==
>
> Series
On Mon, Feb 27, 2017 at 05:09:44PM +0200, Ville Syrjälä wrote:
> On Sun, Feb 26, 2017 at 10:22:42PM +0100, Daniel Vetter wrote:
> > On Fri, Feb 17, 2017 at 05:20:54PM +0200, Jani Nikula wrote:
> > > Handle debugfs override edid and firmware edid at the low level to
> > > transparently and completel
On Thu, 23 Feb 2017, Chris Wilson wrote:
> After initiating a sideband transaction, we only want to wait for the
> transaction to become idle. If, as we are, we wait for both the busy
> and error flag to clear, if an error is raised we just spin until the
> timeout. Once the hw is idle, we can the
On Mon, Feb 27, 2017 at 05:19:21PM +0100, Daniel Vetter wrote:
> On Mon, Feb 27, 2017 at 05:09:44PM +0200, Ville Syrjälä wrote:
> > On Sun, Feb 26, 2017 at 10:22:42PM +0100, Daniel Vetter wrote:
> > > On Fri, Feb 17, 2017 at 05:20:54PM +0200, Jani Nikula wrote:
> > > > Handle debugfs override edid
On Sat, 25 Feb 2017 11:35:03 +0100
Hans de Goede wrote:
> Hi,
>
> On 24-02-17 18:00, Bob Paauwe wrote:
> > On Mon, 20 Feb 2017 15:08:37 +0100
> > Hans de Goede wrote:
> >
> >> MIPI_SEQ_ASSERT_RESET before POWER_ON is not necessary for 2 reasons:
> >> 1) The reset should already be asserted be
On Sat, 25 Feb 2017 11:37:50 +0100
Hans de Goede wrote:
> Hi,
>
> On 24-02-17 18:00, Bob Paauwe wrote:
> > On Mon, 20 Feb 2017 15:08:41 +0100
> > Hans de Goede wrote:
> >
> >> Execute the MIPI_SEQ_BACKLIGHT_ON/OFF VBT sequences at the same time as
> >> we call intel_panel_enable_backlight() /
On Sat, 25 Feb 2017 11:42:09 +0100
Hans de Goede wrote:
> Hi,
>
> On 24-02-17 18:02, Bob Paauwe wrote:
> > On Mon, 20 Feb 2017 15:08:42 +0100
> > Hans de Goede wrote:
> >
> >> According to the spec for v2 VBTs we should call MIPI_SEQ_DISPLAY_OFF
> >> before sending SHUTDOWN, where as for v3 V
== Series Details ==
Series: series starting with [1/2] drm/i915: Stop using RP_DOWN_EI on Baytrail
URL : https://patchwork.freedesktop.org/series/20314/
State : success
== Summary ==
Series 20314v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/20314/revisions/1/
On Sat, 25 Feb 2017 11:49:09 +0100
Hans de Goede wrote:
> HI,
>
> On 24-02-17 18:02, Bob Paauwe wrote:
> > On Mon, 20 Feb 2017 15:08:45 +0100
> > Hans de Goede wrote:
> >
> >> For v3 VBTs in vid-mode the delays are part of the VBT sequences, so
> >> we should not also delay ourselves otherwis
On Mon, Feb 27, 2017 at 06:34:26PM +0200, Jani Nikula wrote:
> On Thu, 23 Feb 2017, Chris Wilson wrote:
> > After initiating a sideband transaction, we only want to wait for the
> > transaction to become idle. If, as we are, we wait for both the busy
> > and error flag to clear, if an error is rai
On Sat, 25 Feb 2017 11:47:32 +0100
Hans de Goede wrote:
> Hi,
>
> On 24-02-17 18:02, Bob Paauwe wrote:
> > On Mon, 20 Feb 2017 15:08:44 +0100
> > Hans de Goede wrote:
> >
> >> According to the spec we should call MIPI_SEQ_TEAR_ON and DISPLAY_ON
> >> on enable for cmd-mode, just like we alread
On Mon, 27 Feb 2017, Bob Paauwe wrote:
> On Sat, 25 Feb 2017 11:37:50 +0100
> Hans de Goede wrote:
>
>> Hi,
>>
>> On 24-02-17 18:00, Bob Paauwe wrote:
>> > On Mon, 20 Feb 2017 15:08:41 +0100
>> > Hans de Goede wrote:
>> >
>> >> Execute the MIPI_SEQ_BACKLIGHT_ON/OFF VBT sequences at the same t
On Mon, 27 Feb 2017, Bob Paauwe wrote:
> On Sat, 25 Feb 2017 11:42:09 +0100
> Hans de Goede wrote:
>
>> Hi,
>>
>> On 24-02-17 18:02, Bob Paauwe wrote:
>> > On Mon, 20 Feb 2017 15:08:42 +0100
>> > Hans de Goede wrote:
>> >
>> >> According to the spec for v2 VBTs we should call MIPI_SEQ_DISPLAY
On Sat, 25 Feb 2017, Hans de Goede wrote:
> Hi,
>
> On 24-02-17 18:02, Bob Paauwe wrote:
>> On Mon, 20 Feb 2017 15:08:43 +0100
>> Hans de Goede wrote:
>>
>>> For v3 VBTs we should call MIPI_SEQ_TEAR_OFF before
>>> MIPI_SEQ_DISPLAY_OFF, for non v3 VBTs this is a nop.
>>
>> Isn't this only for comm
On Mon, 27 Feb 2017 11:22:32 +0100
Hans de Goede wrote:
> On some devices only MIPI PORT C is used, in this case checking the
> MIPI PORT A CTRL AFE_LATCHOUT bit (there is no such bit for PORT C
> on VLV/CHT) will result in false positive "DSI LP not going Low" errors
> as this checks the PORT A
== Series Details ==
Series: drm/edid: Add EDID_QUIRK_FORCE_8BPC quirk for Rotel RSX-1058
URL : https://patchwork.freedesktop.org/series/19959/
State : success
== Summary ==
Series 19959v1 drm/edid: Add EDID_QUIRK_FORCE_8BPC quirk for Rotel RSX-1058
https://patchwork.freedesktop.org/api/1.0/se
On Sun, 2017-02-26 at 20:57 +0100, Daniel Vetter wrote:
> On Wed, Feb 22, 2017 at 12:01:12AM +, Pandiyan, Dhinakaran wrote:
> > On Fri, 2017-02-17 at 15:37 +0530, Archit Taneja wrote:
> > >
> > > On 02/16/2017 05:43 AM, Pandiyan, Dhinakaran wrote:
> > > > On Wed, 2017-02-15 at 16:53 +0530, Arc
1 - 100 of 136 matches
Mail list logo
