On Fri, Aug 18, 2017 at 2:07 AM, Jani Nikula
wrote:
> On Thu, 17 Aug 2017, Stéphane Marchesin wrote:
>> On Mon, Jun 19, 2017 at 11:45 AM, Jani Nikula
>> wrote:
>>>
>>> On Thu, 15 Jun 2017, Imre Deak wrote:
>>> > On Thu, Jun 15, 2017 at 10:20:57AM -0700, Rodrigo Vivi wrote:
>>> >> I believe it i
On Fri, Aug 18, 2017 at 12:07 AM, Jani Nikula wrote:
> On Thu, 17 Aug 2017, Rodrigo Vivi wrote:
>> So far we could use *dim* to apply a whole series
>> in a mbox, but only the very last patch was receiving
>> all the checks and patchwork link.
>>
>> So this patch remove this limitation by using g
No modification to the original content.
Cc: Jani Nikula
Cc: Daniel Vetter
Signed-off-by: Rodrigo Vivi
---
index.rst | 1 +
qf| 282 +-
qf.rst| 250 +++
3 files changed
On my own workflow I was missing a way to download mboxes
directly from patchwork with the patchwork id. So my first
reflex was to modify dim to fulfil my needs. However that
was increasing dim in complexity and dependencies and leaving
that messy.
That was when Jani suggested me the dimrc extensi
Quoting Chris Wilson (2017-08-18 13:56:08)
> Quoting Chris Wilson (2017-08-16 15:23:06)
> > Prefer to defer activating our GEM shrinker until we have a few
> > megabytes to free; or we have accumulated sufficient mempressure by
> > deferring the reclaim to force a shrink. The intent is that because
patches merged to dinq
thanks for the reviews
On Fri, Aug 18, 2017 at 6:39 AM, Oscar Mateo wrote:
>
>
> On 08/15/2017 04:16 PM, Rodrigo Vivi wrote:
>>
>> From: Ben Widawsky
>>
>> This bit enables hardware that will change the approximation used for
>> distances
>> calculations for AA wide lines
Quoting Michel Thierry (2017-08-18 17:31:38)
> On 18/08/17 02:05, Chris Wilson wrote:
> > During a global reset, we disable the irq. As we disable the irq, the
> > hardware may be raising a GT interrupt that we then ignore, leaving it
> > pending in the GTIIR. After the reset, we then re-enable the
On 08/15/2017 04:16 PM, Rodrigo Vivi wrote:
Let's inherit workarounds from previous platforms that
according to wa_database and BSpec are still valid for
Cannonlake.
v2: Add missed workarounds.
v3: Rebase
v4: Remove bad chunk that was added to rc6 disable. (Ander)
Also remove A0 W/a that
Quoting Daniel Vetter (2017-08-18 21:28:08)
> On Fri, Aug 18, 2017 at 02:45:32PM +0100, Chris Wilson wrote:
> > Quoting Katarzyna Dec (2017-08-18 12:08:44)
> > > While I'm here let's also make sure that we're running as DRM
> > > master to catch the common case, where the test is being ran
> > > al
On 08/15/2017 04:16 PM, Rodrigo Vivi wrote:
From: Ben Widawsky
This bit enables hardware that will change the approximation used for distances
calculations for AA wide lines so that they are rendered more accurately.
The default value for this bit leaves the legacy behavior. There is no good
On Fri, Aug 18, 2017 at 4:19 PM, Daniel Vetter wrote:
> On Fri, Aug 18, 2017 at 11:57:34AM -0400, Sean Paul wrote:
>> Hi Dave,
>> Here's the latest and greatest from drm-misc-fixes. We have a couple nice
>> cleanups from Maarten centered around properly handling errors (and
>> specifically
>> EDE
-Auld/huge-gtt-pages/20170818-202207
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-a0-08190316 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All
On Fri, Aug 18, 2017 at 12:34:39PM +0300, Jani Nikula wrote:
> On Fri, 18 Aug 2017, Daniel Vetter wrote:
> > More visibility
> >
> > Signed-off-by: Daniel Vetter
>
> Ack.
>
> I guess qf man page should be extracted from the script, and put here
> too.
Yeah, I'm hoping the unified upstream/inte
On Fri, Aug 18, 2017 at 02:45:32PM +0100, Chris Wilson wrote:
> Quoting Katarzyna Dec (2017-08-18 12:08:44)
> > While I'm here let's also make sure that we're running as DRM
> > master to catch the common case, where the test is being ran
> > along with Xorg.
>
> Semantic changes to the test thoug
Quoting Patchwork (2017-08-18 20:41:45)
> == Series Details ==
>
> Series: drm/i915: Redo old gmch irq handling (rev2)
> URL : https://patchwork.freedesktop.org/series/26215/
> State : success
>
> == Summary ==
>
> Series 26215v2 drm/i915: Redo old gmch irq handling
> https://patchwork.freedes
On Fri, Aug 18, 2017 at 11:57:34AM -0400, Sean Paul wrote:
> Hi Dave,
> Here's the latest and greatest from drm-misc-fixes. We have a couple nice
> cleanups from Maarten centered around properly handling errors (and
> specifically
> EDEADLK) in atomic_check.
They're not cleanups, stuff actually b
On Fri, Aug 18, 2017 at 10:13:08PM +0200, Daniel Vetter wrote:
> On Fri, Aug 18, 2017 at 01:59:10PM -0300, Gustavo Padovan wrote:
> > 2017-08-14 Maarten Lankhorst :
> >
> > > complete_crtc_signaling is freeing fence_state, but when retrying
> > > num_fences and fence_state are not zero'd. This cau
On Fri, Aug 18, 2017 at 01:59:10PM -0300, Gustavo Padovan wrote:
> 2017-08-14 Maarten Lankhorst :
>
> > complete_crtc_signaling is freeing fence_state, but when retrying
> > num_fences and fence_state are not zero'd. This caused duplicate
> > fd's in the fence_state array, followed by a BUG_ON in
== Series Details ==
Series: drm/i915: Redo old gmch irq handling (rev2)
URL : https://patchwork.freedesktop.org/series/26215/
State : success
== Summary ==
Series 26215v2 drm/i915: Redo old gmch irq handling
https://patchwork.freedesktop.org/api/1.0/series/26215/revisions/2/mbox/
Test gem_ex
== Series Details ==
Series: i915, drm/fourcc: Improve the CCS modifier documentation
URL : https://patchwork.freedesktop.org/series/29016/
State : success
== Summary ==
Series 29016v1 i915, drm/fourcc: Improve the CCS modifier documentation
https://patchwork.freedesktop.org/api/1.0/series/290
Quoting ville.syrj...@linux.intel.com (2017-08-18 19:37:00)
> From: Ville Syrjälä
>
> Eliminate the loops from the gen2-3 irq handlers. Since we don't use
> MSI anymore on these platforms, and thus the CPU interrupt will be level
> triggered, we shouldn't need to play any tricks with IER to induc
Quoting ville.syrj...@linux.intel.com (2017-08-18 19:36:53)
> From: Ville Syrjälä
>
> Replace the manual IMR+IER+IIR write sequences with the appropriate
> GEN3_IRQ_RESET/INIT macro invocations in gen3/4.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson
-Chris
___
Thanks for the patch, will rebase my patch on top of this.
Manasi
On Fri, Aug 18, 2017 at 12:30:20PM +0300, Jani Nikula wrote:
> Expose across driver for future work. No functional changes.
>
> Cc: Manasi Navare
> Cc: Jim Bride
> Signed-off-by: Jani Nikula
Reviewed-by: Manasi Navare
> ---
== Series Details ==
Series: drm/i915: Make infoframe code available to (e)DP ports (rev3)
URL : https://patchwork.freedesktop.org/series/8183/
State : success
== Summary ==
Series 8183v3 drm/i915: Make infoframe code available to (e)DP ports
https://patchwork.freedesktop.org/api/1.0/series/81
On Fri, Aug 18, 2017 at 12:30:19PM +0300, Jani Nikula wrote:
> Emphasize that this is based on the port, not intel_dp. This is also in
> line with the underlying intel_bios_is_port_edp() function. No
> functional changes.
>
> Cc: Manasi Navare
> Cc: Jim Bride
> Signed-off-by: Jani Nikula
Revie
On Fri, 18 Aug 2017, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Now that we're not using MSI anymore on gen4 we can start
> using GMBUS and AUX interrupts again. These were disable on
> account of them causing the hardware to somehow generate
> legacy interrupts even when MSI
From: Ville Syrjälä
Currently we're unmasking some random looking bits in HWSTAM
on gen3/4/5. The two bits we apparently unmask are 0 and 12,
and also bits 16-31 on gen4/5.
What those bits do depends on the gen as follows:
bit 0: Breakpoint (gen2), ASLE (gen3), reserved (gen4), render user inter
From: Ville Syrjälä
Bspec claims that HWSTAM is only 16 bits on gen3, but the other
interrupts registers are 32 bits and there are 18 valid interrupt
bits. Hence a 16 bit HWSTAM wouldn't be able to contain all the
bits, so it seems the spec is incorrect about the size of the
register. And indeed
From: Ville Syrjälä
The execlist code already masks everything in the ring HWSTAM, but
the ringbuffer code doesn't. Let's go ahead and do that. Pre-gen6
platforms setup HWSTAM during irq setup already since there's just
the one register, and it also contains bits for non-ring interrupts.
Signed-
From: Ville Syrjälä
Now that we're not using MSI anymore on gen4 we can start
using GMBUS and AUX interrupts again. These were disable on
account of them causing the hardware to somehow generate
legacy interrupts even when MSI was enabled.
See commit c12aba5aa0e6 ("drm/i915: stop using GMBUS IRQ
From: Ville Syrjälä
All the irq_preinstall and irq_uninstall hooks are now identical. Let's
just rename them all the irq_reset and remove the pointless duplicates.
Reviewed-by: Chris Wilson
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 117 ++--
Clean up drm-misc-commit-flow.svg when running make clean.
Signed-off-by: Sean Paul
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 44fcdc9..8daa912 100644
--- a/Makefile
+++ b/Makefile
@@ -47,6 +47,6 @@ mancheck:
check: shellcheck manc
From: Ville Syrjälä
Eliminate the loops from the gen2-3 irq handlers. Since we don't use
MSI anymore on these platforms, and thus the CPU interrupt will be level
triggered, we shouldn't need to play any tricks with IER to induce edges
from IIR. IIR itself still detects only edges from PIPESTAT &
From: Ville Syrjälä
Do the irq_mask/enable_mask setup in the same way on gen3/4, and also
reorder the steps to make the code more uniform.
Reviewed-by: Chris Wilson
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 28 +---
1 file changed, 17 insertion
From: Ville Syrjälä
Extract the gen2-4 PIPESTAT irq handling into separate functions just
like we already do on VLV/CHV.
We can share valleyview_pipestat_irq_ack() on all gmch platforms to
actually read and clear the PIPESTAT status bits, so let's rename
it to i9xx_pipestat_irq_ack().
Reviewed-
From: Ville Syrjälä
There should be no way to land in irq_uninstall without a
valid dev_priv. Let's kill off the remaining checks, which are
probably some kind of UMS leftovers. Not all the irq_uninstall
hooks even had them anymore.
Reviewed-by: Chris Wilson
Signed-off-by: Ville Syrjälä
---
d
From: Ville Syrjälä
Reposted GMCH irq rework series. A few patches fell out completely
since the flip interrupt handling was nuked in the meantime. I also
added a patch to remove some more flip irq leftover, and I tossed in
a patch to reinstate GMBUS/AUX irqs on gen4/g4x since we no longer
use MS
From: Ville Syrjälä
commit fd3a40242e87 ("drm/i915: Rip out legacy page_flip completion/irq
handling") removed the code to hande the flip done/pending interrupts,
but it failed to actually disable/mask those interrupts. Let's do that
now.
Also remove a stale comment that was left behind.
Cc: Da
From: Ville Syrjälä
Unify the appearance of the gen2 irq code with the gen3+ code by
introducing the GEN2_IRQ_RESET/INIT macros.
Reviewed-by: Chris Wilson
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 54 -
1 file changed, 42 insert
From: Ville Syrjälä
We've already cleared PORT_HOTPLUG_EN in the .irq_preinstall hook
so doing it again in the .irq_postinstall is pointless.
Reviewed-by: Chris Wilson
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/dri
From: Ville Syrjälä
Unify the appaerance of the gen2-4 irq postinstall hooks a little
bit by doing the EMR setup first on all the platforms.
Reviewed-by: Chris Wilson
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 37 +++--
1 file changed, 1
From: Ville Syrjälä
Replace the manual IMR+IER+IIR write sequences with the appropriate
GEN3_IRQ_RESET/INIT macro invocations in gen3/4.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 24 ++--
1 file changed, 6 insertions(+), 18 deletions(-)
diff --git
From: Ville Syrjälä
We have a lot of different ways of clearing the PIPESTAT registers.
Let's unify it all into one function. There's no magic in PIPESTAT
that would require any of the double clearing and whatnot that
some of the code tries to do. All we can really do is clear the status
bits and
From: Ville Syrjälä
The GEN5_IRQ_RESET/INIT macros are perfectly suitable even for
gen3/4 hardware as those have 32 bit interrupt registers. Let's
rename the macros to reflect that fact.
Gen2 on the other hand has 16 bit interrupt registers so these
macros aren't really appropriate there.
v2: F
This updates the documentation on the intel CCS modifiers for a couple
of reasons:
1) The old documentation required that the CCS modifier only be used
with formats. While i915 currently only supports CCS scanout
with formats (and advertises such through the blob format), CCS
== Series Details ==
Series: drm/doc: Document ioctl errno value patterns (rev2)
URL : https://patchwork.freedesktop.org/series/28974/
State : success
== Summary ==
Series 28974v2 drm/doc: Document ioctl errno value patterns
https://patchwork.freedesktop.org/api/1.0/series/28974/revisions/2/mb
== Series Details ==
Series: drm/i915: Re-enable per-engine reset for Broxton
URL : https://patchwork.freedesktop.org/series/29011/
State : success
== Summary ==
Series 29011v1 drm/i915: Re-enable per-engine reset for Broxton
https://patchwork.freedesktop.org/api/1.0/series/29011/revisions/1/m
We're not super-consistent about these, but I think it's worth to
document at least the commmon patterns.
v2:
- Add a not about ENOTTY (it's just a confusing name, but used
exactly what it's meant for in DRM) (Chris).
- Unconfuse the text for ENODEV (Daniel)
- Move text undert the IOCTL heading (C
== Series Details ==
Series: drm/i915: Make infoframe code available to (e)DP ports (rev3)
URL : https://patchwork.freedesktop.org/series/8183/
State : failure
== Summary ==
Series 8183v3 drm/i915: Make infoframe code available to (e)DP ports
https://patchwork.freedesktop.org/api/1.0/series/81
The corruption in CSB mmio reads we were seeing has been tracked down to
incorrectly touching forcewake of all domains, following an engine reset.
It is still a mistery why we only catched this in Broxton, since it
could happen in any platform.
With that fix already merged, commit 4055dc75d6b5 ("d
Hi Dave,
Here's the last of -misc-next for 4.14, we'll switch over to drm-misc-next-fixes
now and drm-misc-next will target 4.15. I'll send a PSA to misc committers once
the branches are set up.
Since we just send a pull a few days ago, there's not much here, and the tl;dr
is Noralf. We have the e
2017-08-14 Maarten Lankhorst :
> complete_crtc_signaling is freeing fence_state, but when retrying
> num_fences and fence_state are not zero'd. This caused duplicate
> fd's in the fence_state array, followed by a BUG_ON in fs/file.c
> because we reallocate freed memory, and installing over an exis
On Fri, Aug 18, 2017 at 12:30:20PM +0300, Jani Nikula wrote:
> Expose across driver for future work. No functional changes.
Reviewed-by: Jim Bride
> Cc: Manasi Navare
> Cc: Jim Bride
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_dp.c | 77
> +--
On Thu, Aug 17, 2017 at 08:03:04PM -0700, Manasi Navare wrote:
> In the channel EQ retry loop, we break from the loop in case
> of failure to get link status or failure in clock recovery or
> failure to update link training. In these cases channel_eq_status
> is still false even though the retry lo
On Fri, Aug 18, 2017 at 12:30:19PM +0300, Jani Nikula wrote:
> Emphasize that this is based on the port, not intel_dp. This is also in
> line with the underlying intel_bios_is_port_edp() function. No
> functional changes.
Reviewed-by: Jim Bride
> Cc: Manasi Navare
> Cc: Jim Bride
> Signed-off-
On 18/08/17 02:05, Chris Wilson wrote:
During a global reset, we disable the irq. As we disable the irq, the
hardware may be raising a GT interrupt that we then ignore, leaving it
pending in the GTIIR. After the reset, we then re-enable the irq,
triggering the pending interrupt. However, that int
And two more small changes
On Thu, 2017-08-17 at 19:05 +0300, Paul Kocialkowski wrote:
> This introduces an ALSA library, with dedicated helpers for handling
> playback and capture. It handles ALSA device identification and
> configuration as well as a run loop with callback mechanisms for
> feedi
One more small formatting change
On Thu, 2017-08-17 at 19:05 +0300, Paul Kocialkowski wrote:
> This introduces an audio library, with dedicated helpers for both
> generating signals and detecting peak frequencies in a signal.
>
> This library paves the way for testing audio going through display
Nice job! Only one small formatting change
On Thu, 2017-08-17 at 19:05 +0300, Paul Kocialkowski wrote:
> This introduces a new test for audio going through display
> connectors.
> It currently contains a single subtest for HDMI signal integrity, but
> other test cases will be added later on.
>
>
Hi Dave,
Here's the latest and greatest from drm-misc-fixes. We have a couple nice
cleanups from Maarten centered around properly handling errors (and specifically
EDEADLK) in atomic_check.
I probably would have liked Mark's DRM_ERROR patch to go through -misc-next, but
hopefully it's harmless eno
Quoting Tahvanainen, Jari (2017-08-18 15:26:03)
> " Do we have a bug about this at bugs.freedesktop.org?" I did quick query on
> fdo.bugzilla and did not find any matching item (afaik) from there (with
> i915_feature = GPU *hang*|*DMC*) so I would claim that bug is not filed.
> Stephane can corr
== Series Details ==
Series: drm/i915: "Race-to-idle" on switching to the kernel context
URL : https://patchwork.freedesktop.org/series/28998/
State : success
== Summary ==
Series 28998v1 drm/i915: "Race-to-idle" on switching to the kernel context
https://patchwork.freedesktop.org/api/1.0/seri
" Do we have a bug about this at bugs.freedesktop.org?" I did quick query on
fdo.bugzilla and did not find any matching item (afaik) from there (with
i915_feature = GPU *hang*|*DMC*) so I would claim that bug is not filed.
Stephane can correct my wrong sayings here.
BR, Jari
-Original Mes
Hi,
On 18 August 2017 at 10:21, Daniel Vetter wrote:
> +Recommended IOCTL Return Values
> +===
> +
> +In theory a driver's IOCTL callback is only allowed to return very few error
> +codes. In practice it's good to abuse a few more. This section documents
> common
> +p
== Series Details ==
Series: drm/i915: Make infoframe code available to (e)DP ports (rev3)
URL : https://patchwork.freedesktop.org/series/8183/
State : failure
== Summary ==
Series 8183v3 drm/i915: Make infoframe code available to (e)DP ports
https://patchwork.freedesktop.org/api/1.0/series/81
During suspend we want to flush out all active contexts and their
rendering. To do so we queue a request from the kernel's context, once
we know that request is done, we know the GPU is completely idle. To
speed up that switch bump the GPU clocks.
Switching to the kernel context prior to idling is
Quoting Chris Wilson (2017-08-18 10:30:47)
> Quoting Chris Wilson (2017-08-17 13:37:06)
> > If we miss the current vblank because the gpu was busy, that may cause a
> > jitter as the frame rate temporarily drops. We try to limit the impact
> > of this by then boosting the GPU clock to deliver the f
From: Ville Syrjälä
The PSR enable/disable need to know things about the crtc state, so
plumb it through. This will become even more important when we start
to reuse the generic infoframe code for the VSC DIP programming as the
infoframe code wants the crtc state as well.
v2: Fix kernel docs
Re
From: Ville Syrjälä
Disabling the video DIP when shutting the port down seems like a good
idea.
Bspec says:
"When disabling both the DIP port and DIP transmission,
first disable the port and then disable DIP."
and
"Restriction : GCP is only supported with HDMI when the bits per color is
not eq
From: Ville Syrjälä
DP ports may want to use the video DIP for SDP transmission, so let's
initialize the vfuncs for DP encoders as well. The only exception is
port A eDP prior to HSW as that one doesn't have a video DIP instance.
Signed-off-by: Ville Syrjälä
Reviewed-by: Shashank Sharma
---
d
From: Ville Syrjälä
has_infoframe is what tells us whether infoframes should be enabled, so
let's pass that instead of has_hdmi_sink to .set_infoframes().
Reviewed-by: Rodrigo Vivi
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_ddi.c | 6 +++---
drivers/gpu/drm/i915/intel_hdmi.c
From: Ville Syrjälä
The enable/disable/etc. encoder hooks aren't supposed to alter the
state(s), so pass them as const. Unfortunately C lacks any kind of deep
const thingy, so this can't catch all abuses. But at least it acts as a
hint to the reader telling them not to mess about with the state(s
From: Ville Syrjälä
Now that the infoframe hooks are part of the intel_dig_port, we can use
the normal .write_infoframe() hook to update the VSC SDP. We do need to
deal with the size difference between the VSC DIP and the others though.
Another minor snag is that the compiler will complain to us
From: Ville Syrjälä
DP ports will also want to utilize the video DIP for SDP transmission.
So let's move the vfuncs into the dig_port.
v2: Rebase due to DDI changes
Signed-off-by: Ville Syrjälä
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_ddi.c | 22 ++---
drivers/gpu
From: Ville Syrjälä
A rebased reposting of the dig_port infoframe series.
Notable changes since last time:
* Dealt with the new intel_sdvo_connector_state
* Annotated the SDP types with the DP spec version information
* Fixed the kernel docs for the PSR enable/disable funcs
Ville Syrjälä (8):
From: Ville Syrjälä
Add defines for the secondary data packet (SDP) types from the spec.
These are the DP specific ones, and in addition HDMI infoframe types
(see enum hdmi_infoframe_type) are also valid SDP types.
v2: Add more SDP types
v3: Note the DP version that added each SDP type (Rodrigo)
Quoting Katarzyna Dec (2017-08-18 12:08:44)
> CI is observing sporadical failures in pm_rps subtests.
For reference a real bug report looks like:
https://bugs.freedesktop.org/show_bug.cgi?id=102199
which is very much a functional regression that we don't cover.
-Chris
_
Quoting Katarzyna Dec (2017-08-18 12:08:44)
> While I'm here let's also make sure that we're running as DRM
> master to catch the common case, where the test is being ran
> along with Xorg.
Semantic changes to the test though, that implies its needs to be master
to run.
If you want to impose the
Quoting Katarzyna Dec (2017-08-18 08:33:11)
> Waitboost and reset test cases were failing because maximum
> frequency is not always boost frequency (sometimes overcloking
> occurs).
> Moreover more time is needed for boost to be finished.
> Changed boost_freq function so boost occurred on the same
== Series Details ==
Series: pm_rps: Changes in waitboost scenario (rev2)
URL : https://patchwork.freedesktop.org/series/28966/
State : success
== Summary ==
IGT patchset tested on top of latest successful build
5a17ee2c8f9013f5db852d27564b837f9f2c5a9f tools/intel_vbt_decode: Fix decoding
of
On Fri, 18 Aug 2017, Mika Kahola wrote:
> On Thu, 2017-08-17 at 14:06 +0300, Mika Kahola wrote:
>> Tested with GLK + MIPI/DSI panel (AU Optronics B101UAN01)
> Tested also with APL + MIPI/DSI setup.
Pushed to drm-intel-next-queued, thanks for the patch and testing.
BR,
Jani.
>
>>
>> Tested-by:
On Fri, Aug 18, 2017 at 01:46:12PM +0200, Michal Wajdeczko wrote:
> On Fri, Aug 18, 2017 at 11:53:22AM +0100, Chris Wilson wrote:
> > Quoting Chris Wilson (2017-08-18 11:46:19)
> > > igt_require_gem() checks whether we can use the i915 fd for submitting
> > > requests by detecting a wedged driver.
== Series Details ==
Series: lib: Avoid actually throttling from igt_require_gem()
URL : https://patchwork.freedesktop.org/series/28983/
State : failure
== Summary ==
IGT patchset build failed on latest successful build
5a17ee2c8f9013f5db852d27564b837f9f2c5a9f tools/intel_vbt_decode: Fix decod
Quoting Chris Wilson (2017-08-16 15:23:06)
> Prefer to defer activating our GEM shrinker until we have a few
> megabytes to free; or we have accumulated sufficient mempressure by
> deferring the reclaim to force a shrink. The intent is that because our
> objects may typically be large, we are too e
On Fri, Aug 18, 2017 at 11:53:22AM +0100, Chris Wilson wrote:
> Quoting Chris Wilson (2017-08-18 11:46:19)
> > igt_require_gem() checks whether we can use the i915 fd for submitting
> > requests by detecting a wedged driver. It was intended to be used just
> > after opening DRIVER_INTEL for a gem t
On Thu, Aug 17, 2017 at 03:58:19PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Beef up the IPS vs. CRC workaround (rev3)
> URL : https://patchwork.freedesktop.org/series/17084/
> State : warning
>
> == Summary ==
>
> Series 17084v3 drm/i915: Beef up the IPS vs. CRC wor
== Series Details ==
Series: drm/i915/gvt: Dma-buf support for GVT-g
URL : https://patchwork.freedesktop.org/series/28980/
State : success
== Summary ==
Series 28980v1 drm/i915/gvt: Dma-buf support for GVT-g
https://patchwork.freedesktop.org/api/1.0/series/28980/revisions/1/mbox/
Test gem_exe
== Series Details ==
Series: series starting with [1/2] drm/i915/dp: rename intel_dp_is_edp to
intel_dp_is_port_edp
URL : https://patchwork.freedesktop.org/series/28976/
State : success
== Summary ==
Series 28976v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/2
Quoting Daniel Vetter (2017-08-18 10:21:24)
> We're not super-consistent about these, but I think it's worth to
> document at least the commmon patterns.
>
> Cc: Joonas Lahtinen
> Cc: Chris Wilson
> Cc: "Zhang, Tina"
> Signed-off-by: Daniel Vetter
One extra used outside of i915 is ENOSYS. Per
== Series Details ==
Series: drm/doc: Document ioctl errno value patterns
URL : https://patchwork.freedesktop.org/series/28974/
State : success
== Summary ==
Series 28974v1 drm/doc: Document ioctl errno value patterns
https://patchwork.freedesktop.org/api/1.0/series/28974/revisions/1/mbox/
fi
On Fri, Aug 18, 2017 at 11:53:22AM +0100, Chris Wilson wrote:
> Quoting Chris Wilson (2017-08-18 11:46:19)
> > igt_require_gem() checks whether we can use the i915 fd for submitting
> > requests by detecting a wedged driver. It was intended to be used just
> > after opening DRIVER_INTEL for a gem t
On Thu, 2017-08-17 at 14:06 +0300, Mika Kahola wrote:
> Tested with GLK + MIPI/DSI panel (AU Optronics B101UAN01)
Tested also with APL + MIPI/DSI setup.
>
> Tested-by: Mika Kahola
>
> On Thu, 2017-08-17 at 13:55 +0300, Andy Shevchenko wrote:
> >
> > The commit 213e08ad60ba
> > ("drm/i915/b
Quoting Patchwork (2017-08-17 16:36:15)
> == Series Details ==
>
> Series: series starting with [1/7] drm/i915: Don't use MI_STORE_DWORD_IMM on
> Sandybridge/vcs (rev2)
> URL : https://patchwork.freedesktop.org/series/28859/
> State : success
>
> == Summary ==
>
> Series 28859v2 Series withou
On Fri, 2017-08-18 at 18:21 +0800, Tina Zhang wrote:
> GEM proxy is a kind of GEM, whose backing physical memory is pinned
> and produced by guest VM and is used by host as read only. With GEM
> proxy, host is able to access guest physical memory through GEM object
> interface. As GEM proxy is such
== Series Details ==
Series: drm/i915: Clear lost context-switch interrupts across reset (rev2)
URL : https://patchwork.freedesktop.org/series/28450/
State : success
== Summary ==
Series 28450v2 drm/i915: Clear lost context-switch interrupts across reset
https://patchwork.freedesktop.org/api/1
Chris Wilson writes:
> Quoting Mika Kuoppala (2017-08-18 12:07:20)
>> Chris Wilson writes:
>> > if (!eb->reloc_cache.vaddr &&
>> > (DBG_FORCE_RELOC == FORCE_GPU_RELOC ||
>> > - !reservation_object_test_signaled_rcu(vma->resv, true))) {
>> > + !reservation_object
Quoting Mika Kuoppala (2017-08-18 12:07:20)
> Chris Wilson writes:
> > if (!eb->reloc_cache.vaddr &&
> > (DBG_FORCE_RELOC == FORCE_GPU_RELOC ||
> > - !reservation_object_test_signaled_rcu(vma->resv, true))) {
> > + !reservation_object_test_signaled_rcu(vma->resv,
Chris Wilson writes:
> MI_STORE_DWORD_IMM just doesn't work on the video decode engine under
> Sandybridge, so refrain from using it. Then switch the selftests over to
> using the now common test prior to using MI_STORE_DWORD_IMM.
>
> Fixes: 7dd4f6729f92 ("drm/i915: Async GPU relocation processin
CI is observing sporadical failures in pm_rps subtests.
There are a couple of reasons. One of them is the fact that
on gen6, gen7 and gen7.5, max frequency (as in the HW limit)
is not set to RP0, but the value obtaind from PCODE (which
may be different from RP0). Thus the test is operating under
wr
Quoting Chris Wilson (2017-08-18 11:46:19)
> igt_require_gem() checks whether we can use the i915 fd for submitting
> requests by detecting a wedged driver. It was intended to be used just
> after opening DRIVER_INTEL for a gem test to provide an early skip if
> the device was unusable. However, it
1 - 100 of 146 matches
Mail list logo
