From: Akash Goel
When the object is moved out of CPU read domain, the cachelines
are not invalidated immediately. The invalidation is deferred till
next time the object is brought back into CPU read domain.
But the invalidation is done unconditionally, i.e. even for the case
where the cachelines
On 11/27/2015 08:29 PM, Ander Conselvan De Oliveira wrote:
On Wed, 2015-11-25 at 13:19 +0800, libin.y...@linux.intel.com wrote:
From: Libin Yang
This patch adds support for DP MST audio in i915.
The title says "start adding" so a note of what's still missing would be good
here. I assume som
Making changes in intel_crtc_mode_get() to get correct values for crtc clock,
vdisplay, hdisplay, vtotal.
1. intel_crtc_mode_get() gets clock using i9xx_crtc_clock_get() which wil not
work for hsw, skl, bxt.
2. For BXT DSI, hdisplay, vdisplay, vtotal registers are different. In the
current implemen
From: Libin Yang
This patch adds support for DP MST audio in i915.
Enable audio codec when DP MST is enabled if has_audio flag is set.
Disable audio codec when DP MST is disabled if has_audio flag is set.
Another separated patches to support DP MST audio will be implemented
in audio driver.
Re
From: Libin Yang
This adds code to initialise the SDP streams
for a sink in the simplest ordering.
I've no idea how you'd want to control the
ordering at this level, so don't bother
until someone comes up with a use case.
Reviewed-by: Ander Conselvan de Oliveira
Signed-off-by: Libin Yang
Sign
Since RC6 enabling does not involve PCU communication overhead,
it can be enabled immediately during the resume time.
This will help save additional power & meet power requirements
for active Idle KPI where power is evaluated over
number of transitions of suspend/resume.
v2: RPM ref count is not n
On Wed, Dec 02, 2015 at 02:54:45AM +0100, Rafael J. Wysocki wrote:
> On Monday, November 30, 2015 09:02:55 PM Imre Deak wrote:
> > The runtime PM core doesn't treat EBUSY and EAGAIN retvals from the driver
> > suspend hooks as errors, but they still show up as errors in dmesg. Tune
> > them down. S
On Monday, November 30, 2015 09:02:55 PM Imre Deak wrote:
> The runtime PM core doesn't treat EBUSY and EAGAIN retvals from the driver
> suspend hooks as errors, but they still show up as errors in dmesg. Tune
> them down. See rpm_suspend() for details of handling these return values.
>
> Note tha
On Thu, Nov 5, 2015 at 12:11 PM, Paulo Zanoni wrote:
> 2015-11-05 16:53 GMT-02:00 Rodrigo Vivi :
>> With commit (drm/i915: Delay first PSR activation.) in kernel
>> PSR might take a bit longer to really activate after the modeset.
>
> Can you please expand this commit message a little bit for Futu
The cherryview device shares many characteristics with the valleyview
device. When support was added to the driver for cherryview, the
corresponding device info structure included .is_valleyview = 1.
This is not correct and leads to some confusion.
This patch changes .is_valleyview to .is_cherryv
On Thu, Nov 5, 2015 at 12:30 PM, Paulo Zanoni wrote:
> 2015-11-05 16:53 GMT-02:00 Rodrigo Vivi :
>> Even with all sink crc re-works we still have platforms
>> where after 6 vblanks it is unable to calculate the
>> sink crc. But if we don't get the sink crc it isn't true
>> that test failed, but th
On Tue, Nov 24, 2015 at 10:31:41PM +0200, Ville Syrjälä wrote:
> On Mon, Nov 02, 2015 at 12:33:48PM -0800, Rafael Antognolli wrote:
> > So far, the i915 driver and some other drivers set it to the drm_device,
> > which doesn't allow one to know which DP a given aux channel is related
> > to. Changi
Ideally, we want to automagically have the GPU respond to the
instantaneous load by reclocking itself. However, reclocking occurs
relatively slowly, and to the client waiting for a result from the GPU,
too late. To compensate and reduce the client latency, we allow the
first wait from a client to b
From: Ville Syrjälä
We've never actually enabled or unmasked the GSE interrupt on BDW+,
even though the interrupt handler was always prepared for it.
Let's enable it and see what happens.
Credit to Mark Kettenis who fixed this in the OpenBSD fork of the
driver. He reports that it fixed the "ACPI
On Tue, Dec 01, 2015 at 09:53:50PM +0100, Mark Kettenis wrote:
> I just committed the following cange to the OpenBSD inteldrm(4)
> driver, which currently is mostly a port of the Linux 3.14 codebase.
> This enables the GSE interrupt on Broadwell. Without this interrupt,
> the ASLE backlight bright
From: Ville Syrjälä
Unfortunatey there appear to quite a few HSW/BDW machines (eg.
NUCs, Brix Pro) in the wild with LPT/WPT-H that have no physical
CRT connector and non-working FDI. FDI training fails every
single time on these machines. Dunno, maybe they just didn't
bother wiring it up or somet
From: Ville Syrjälä
While not technically needed on the last case in the switch statement,
the 'break' makes it look better IMO.
v2: Fixed a typo in the commit message (Paulo)
Signed-off-by: Ville Syrjälä
Reviewed-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 1 +
1 file change
From: Ville Syrjälä
On HSW/BDW DDI A and E share 2 lanes, so when DDI A requires the
shared lanes DDI E can't be used. The lanes are not supposed to
be dynamically switched between the two uses, so there's no point
in registering the CRT connector when DDI E has no lanes.
v2: Fix typos in the co
From: Ville Syrjälä
LPT-H has a strap bit for fused off CRT block. Check it to see if
we should register the CRT connector or not. Supposedly this also
forces the ADAP enable bit to 0, so the detection we added in
commit 6c03a6bd0dd8 ("drm/i915: Don't register CRT connector when it's fused
off")
I just committed the following cange to the OpenBSD inteldrm(4)
driver, which currently is mostly a port of the Linux 3.14 codebase.
This enables the GSE interrupt on Broadwell. Without this interrupt,
the ASLE backlight brightness mechanism doesn't work. I've verified
that this fixed the ACPI _B
On Tue, Dec 01, 2015 at 05:34:40PM -0200, Paulo Zanoni wrote:
> 2015-12-01 11:08 GMT-02:00 :
> > From: Ville Syrjälä
> >
> > While not techically needed on the last case in the switch statement,
>
> "techically"
>
> > the 'break' makes it look better IMO.
>
> Just out of curiosity: what's your
On Tue, 2015-12-01 at 20:56 +0200, Ville Syrjälä wrote:
> On Wed, Nov 18, 2015 at 11:19:06AM -0800, Rodrigo Vivi wrote:
> > According to VESA spec: "If a Source device receives and IRQ_HPD
> > while in a PSR active state, and cannot identify what caused the
> > IRQ_HPD to be generated, based on Sin
On Tue, Dec 01, 2015 at 05:28:19PM -0200, Paulo Zanoni wrote:
> 2015-12-01 14:07 GMT-02:00 :
> > From: Ville Syrjälä
> >
> > Unfortunatey there appear to quite a few HSW/BDW machines (eg.
> > NUCs, Brix Pro) in the wild with LPT/WPT-H but non-working FDI.
> > FDI training fails every single time
Beginning with gen7, newer devices repetitively redefine values
for the device info structure members. This patch simplifies the
structure definitions by grouping member value definitions into the
existing GEN7_FEATURES #define and into the new GEN7_LP_FEATURES
and HSW_FEATURES #defines.
Specific
2015-12-01 11:08 GMT-02:00 :
> From: Ville Syrjälä
>
> While not techically needed on the last case in the switch statement,
"techically"
> the 'break' makes it look better IMO.
Just out of curiosity: what's your opinion on the lack of a "break" at
the default case, such as the one we have in
2015-12-01 14:07 GMT-02:00 :
> From: Ville Syrjälä
>
> Unfortunatey there appear to quite a few HSW/BDW machines (eg.
> NUCs, Brix Pro) in the wild with LPT/WPT-H but non-working FDI.
> FDI training fails every single time on these machines. Dunno,
> maybe they just didn't bother wiring it up or
These tests exercise the userptr ioctl to create shared buffers
between CPU and GPU. They contain error and normal usage scenarios.
They also contain a couple of stress tests which copy buffers between
CPU and GPU. These tests rely on the softpin patch in order to pin buffers
to a certain VA.
Cave
On Tue, Dec 01, 2015 at 05:05:42PM -0200, Paulo Zanoni wrote:
> 2015-12-01 11:08 GMT-02:00 :
> > From: Ville Syrjälä
> >
> > LPT-H has a strap bit for fused off CRT block. Check it to see if
> > we should register the CRT connector or not. Supposedly this also
> > forces the ADAP enable bit to 0,
2015-12-01 11:08 GMT-02:00 :
> From: Ville Syrjälä
Subject: s/connectro/connector/
>
> On HSW/BDW DDI A and E share 2 lanes, so when DDI A requires the
> shared lanes DDI E can't be used. The lanes are not suppsoed to
s/suppsoed/supposed/
Reviewed-by: Paulo Zanoni
> be dynamically switched
On Wed, Nov 18, 2015 at 11:19:06AM -0800, Rodrigo Vivi wrote:
> According to VESA spec: "If a Source device receives and IRQ_HPD
> while in a PSR active state, and cannot identify what caused the
> IRQ_HPD to be generated, based on Sink device status registers,
> the Source device can take implemen
2015-12-01 11:08 GMT-02:00 :
> From: Ville Syrjälä
>
> LPT-H has a strap bit for fused off CRT block. Check it to see if
> we should register the CRT connector or not. Supposedly this also
> forces the ADAP enable bit to 0, so the detection we added in
> commit 6c03a6bd0dd8 ("drm/i915: Don't regi
On 30/11/15 14:34, Chris Wilson wrote:
One particularly stressful scenario consists of many independent tasks
all competing for GPU time and waiting upon the results (e.g. realtime
transcoding of many, many streams). One bottleneck in particular is that
each client waits on its own results, but e
On ti, 2015-12-01 at 09:26 -0800, Matt Roper wrote:
> BXT power well support is not yet stable. Starting with patch
>
> commit 9f836f9016ad5320e0c9230419d2102cf15a28aa
> Author: Patrik Jakobsson
> Date: Mon Nov 16 16:20:01 2015 +0100
>
> drm/i915/gen9: Turn
On Tue, Dec 01, 2015 at 06:07:09PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Unfortunatey there appear to quite a few HSW/BDW machines (eg.
> NUCs, Brix Pro) in the wild with LPT/WPT-H but non-working FDI.
> FDI training fails every single time on these machines. Dunno
On 28/10/15 12:08, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
A call to i915_gem_obj_ggtt_pin is being made after this, which again
calls the get_pages function. Hence removing the redundant call to
get_pages.
Signed-off-by: Ankitprasad Sharma
---
drivers/gpu/drm/i915/i9
gpgpu_fill.h is only used internally by the library.
Signed-off-by: Thomas Wood
---
docs/reference/intel-gpu-tools/Makefile.am | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/docs/reference/intel-gpu-tools/Makefile.am
b/docs/reference/intel-gpu-tools/Makefile.am
index
Signed-off-by: Thomas Wood
---
lib/igt_debugfs.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/lib/igt_debugfs.h b/lib/igt_debugfs.h
index ee9ff40..3d5a811 100644
--- a/lib/igt_debugfs.h
+++ b/lib/igt_debugfs.h
@@ -77,6 +77,17 @@ typedef struct {
/**
* intel_pipe_crc_sourc
Signed-off-by: Thomas Wood
---
lib/drmtest.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/drmtest.c b/lib/drmtest.c
index 16a3638..2896af0 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -225,11 +225,10 @@ int drm_get_card(void)
/**
* __drm_open_driver:
+ *
On ti, 2015-12-01 at 09:22 -0800, Bob Paauwe wrote:
> On Tue, 1 Dec 2015 15:56:55 +0200
> Imre Deak wrote:
>
> > On ma, 2015-11-30 at 16:23 -0800, Bob Paauwe wrote:
> > > Now that the frequency can drop below the user specified minimum
> > > when
> > > the gpu is idle, add some checking to verify
2015-12-01 14:54 GMT-02:00 Rodrigo Vivi :
> 'commit 97173eaf5 ("drm/i915: PSR: Increase idle_frames")' was a mistake.
> The special case it tried to cover was already being covered by
> the DP_PSR_NO_TRAIN_ON_EXIT. So this ended up duplicated.
>
> So, instead of reverting that let's take this oppor
On Fri, Nov 20, 2015 at 05:27:43PM +0200, Ville Syrjälä wrote:
> On Fri, Nov 20, 2015 at 10:56:00AM +, Chris Wilson wrote:
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_cmd_parser.c | 51
> > --
> > drivers/gpu/drm/i915/i915_drv.h
On Fri, Nov 20, 2015 at 03:22:03PM +, Chris Wilson wrote:
> On Fri, Nov 20, 2015 at 05:05:05PM +0200, Ville Syrjälä wrote:
> > On Fri, Nov 20, 2015 at 10:55:58AM +, Chris Wilson wrote:
> > > Since we blow the TLB caches by using kmap/kunmap, we may as well go the
> > > whole hog and see if
On Fri, Nov 20, 2015 at 10:55:57AM +, Chris Wilson wrote:
> The cmd parser has the biggest impact on the BLT ring, because it is
> relatively verbose composed to the other engines as the vertex data is
> inline. It also typically has runs of repeating commands (again since
> the vertex data is
BXT power well support is not yet stable. Starting with patch
commit 9f836f9016ad5320e0c9230419d2102cf15a28aa
Author: Patrik Jakobsson
Date: Mon Nov 16 16:20:01 2015 +0100
drm/i915/gen9: Turn DC handling into a power well
DPMS off operations may actually c
On Tue, 1 Dec 2015 15:56:55 +0200
Imre Deak wrote:
> On ma, 2015-11-30 at 16:23 -0800, Bob Paauwe wrote:
> > Now that the frequency can drop below the user specified minimum when
> > the gpu is idle, add some checking to verify that it really does drop
> > down to the RPn frequency in specific ca
On Tue, Dec 01, 2015 at 10:23:52AM +0200, Jani Nikula wrote:
> From: Imre Deak
>
> Per bspec, "Backlight PWM may stop in the asserted state, causing
> backlight to stay fully on. WA: Before disabling PWM, set CLKGATE_DIS_0
> 0x46530 bit 13 PWM1 Gating Dis (for PWM1) or bit 14 PWM2 Gating Dis (for
On 30/11/15 14:18, Chris Wilson wrote:
On Mon, Nov 30, 2015 at 01:32:16PM +, Tvrtko Ursulin wrote:
On 30/11/15 12:30, Chris Wilson wrote:
On Mon, Nov 30, 2015 at 12:05:50PM +, Tvrtko Ursulin wrote:
+ struct intel_breadcrumbs {
+ spinlock_t lock; /* protects the per
On ti, 2015-12-01 at 10:23 +0200, Jani Nikula wrote:
> The only missing piece is the function to convert frequency to PWM
> register value. The PWM is based on 19.2 MHz clock, except for BXT A
> step, which is based on CDCLK, and which we ignore.
>
> Signed-off-by: Jani Nikula
On patch 1 and 2:
On 29/11/15 08:48, Chris Wilson wrote:
We have testcases to ensure that seqno wraparound works fine, so we can
forgo forcing everyone to encounter seqno wraparound during early
uptime. seqno wraparound incurs a full GPU stall so not forcing it
will eliminate one jitter from the early system.
Adv
2015-12-01 14:47 GMT-02:00 Daniel Vetter :
> On Tue, Dec 01, 2015 at 02:40:22PM -0200, Paulo Zanoni wrote:
>> 2015-12-01 14:37 GMT-02:00 Daniel Vetter :
>> > The kernel is free to allocate blob ids however it wants to. And also
>> > to reallocate them whenever it sees fit. The only thing we are all
On Tue, Dec 01, 2015 at 02:40:22PM -0200, Paulo Zanoni wrote:
> 2015-12-01 14:37 GMT-02:00 Daniel Vetter :
> > The kernel is free to allocate blob ids however it wants to. And also
> > to reallocate them whenever it sees fit. The only thing we are allowed
> > to compare is the length and the actual
On Tue, Dec 01, 2015 at 03:27:44PM +0100, Thomas Hellstrom wrote:
> Daniel,
>
> LGTM, except one comment below:
Thanks, I've updated the comment and pushed it out.
-Daniel
>
> On 12/01/2015 08:45 AM, Daniel Vetter wrote:
> > Tests that master state isn't leaked to new masters by checking
> > th
On 01/12/15 15:58, Chris Wilson wrote:
On Tue, Dec 01, 2015 at 03:47:34PM +, Dave Gordon wrote:
On 30/11/15 10:06, Tvrtko Ursulin wrote:
On 29/11/15 08:48, Chris Wilson wrote:
Limit busywaiting only to the request currently being processed by the
GPU. If the request is not currently being
On Tue, Dec 01, 2015 at 05:37:40PM +0100, Daniel Vetter wrote:
> The kernel is free to allocate blob ids however it wants to. And also
> to reallocate them whenever it sees fit. The only thing we are allowed
> to compare is the length and the actual date.
>
> Removing this bogus check makes drm-re
2015-12-01 14:37 GMT-02:00 Daniel Vetter :
> The kernel is free to allocate blob ids however it wants to. And also
> to reallocate them whenever it sees fit. The only thing we are allowed
> to compare is the length and the actual date.
>
> Removing this bogus check makes drm-resources-equal on my s
The kernel is free to allocate blob ids however it wants to. And also
to reallocate them whenever it sees fit. The only thing we are allowed
to compare is the length and the actual date.
Removing this bogus check makes drm-resources-equal on my snb.
Cc: Paulo Zanoni
Signed-off-by: Daniel Vetter
On Sat, Nov 28, 2015 at 09:54:50AM -0800, Marc MERLIN wrote:
> On Tue, Nov 17, 2015 at 05:11:05PM +0200, Jani Nikula wrote:
> > On Tue, 17 Nov 2015, Marc MERLIN wrote:
> > > So, this is probably the 3rd time I send such a report with different
> > > kernels and get 0 response.
> > > Is this a writ
From: Ville Syrjälä
Unfortunatey there appear to quite a few HSW/BDW machines (eg.
NUCs, Brix Pro) in the wild with LPT/WPT-H but non-working FDI.
FDI training fails every single time on these machines. Dunno,
maybe they just didn't bother wiring it up or something?
Unfortunately all the fuse bi
A couple of i915_audio_component ops have been added and accessed
directly from patch_hdmi.c. Ideally all these should be factored out
into hdac_i915.c.
This patch does it, adds two new helper functions for setting N/CTS
and fetching ELD bytes. One bonus is that the hackish widget vs port
mappin
We have a common loop of encoder to look for the given audio port in
two audio component functions. Split out a local helper function to
do it for the code simplification.
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/i915/intel_audio.c | 61 --
1 file chan
to_intel_crtc() always returns a non-NULL pointer.
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/i915/intel_audio.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_audio.c
b/drivers/gpu/drm/i915/intel_audio.c
index 4dccd9b003a1..0c38cc6c82ae 100644
--- a/driv
The ELD notification can be received asynchronously from the graphics
side, and this may happen just at the moment the sound driver is
processing the suspend or the resume, and it would confuse the whole
procedure. Since the ELD and connection states are updated in anyway
at the end of the resume,
Instead of doing in each caller side, snd_hdmi_parse_eld() does
zero-clear of the parsed data by itself. This is safer and simplifies
the code.
Signed-off-by: Takashi Iwai
---
sound/pci/hda/hda_eld.c| 1 +
sound/pci/hda/patch_hdmi.c | 2 --
2 files changed, 1 insertion(+), 2 deletions(-)
d
Hi,
this is a revised patchset to add get_eld op to audio component for
communicating more directly between i915 and HD-audio. Currently, the
HDMI/DP audio status and ELD are notified and obtained via the
hardware-level communication over HD-audio unsolicited event and
verbs although the graphics
This patch adds a reverse mapping from a digital port number to
intel_encoder object containing the corresponding intel_digital_port.
It simplifies the query of the encoder a lot.
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/i915/i915_drv.h| 2 ++
drivers/gpu/drm/i915/intel_audio.c | 22
Since we have a new audio component ops to fetch the current ELD and
state now, we can reduce the usage of unsol event of HDMI/DP pins.
The unsol event isn't only unreliable, but it also needs the power
up/down of the codec and link at each time, which is a significant
power and time loss.
In this
Implement a new i915_audio_component_ops, get_eld(). It's called by
the audio driver to fetch the current audio status and ELD of the
given HDMI/DP port. It returns the size of expected ELD bytes if it's
valid, zero if no valid ELD is found, or a negative error code. The
current state of audio o
This is a preliminary patch for the later change to support ELD/jack
handling with i915 audio component. This splits the ELD update code
from hdmi_present_sense() so that it can be called from other places.
Just a code refactoring, no functional change.
Signed-off-by: Takashi Iwai
---
sound/pc
If head seems stuck and engine in question is rcs,
inspect subunit state transitions from undone to done,
before deciding that this really is a hang instead of limited
progress. Only account the transitions of subunits from
undone to done once, to prevent unstable subunit states
to keep us falsely
On Tue, Dec 01, 2015 at 03:47:34PM +, Dave Gordon wrote:
> On 30/11/15 10:06, Tvrtko Ursulin wrote:
> >
> >On 29/11/15 08:48, Chris Wilson wrote:
> >>Limit busywaiting only to the request currently being processed by the
> >>GPU. If the request is not currently being processed by the GPU, there
Some sources of significant amounts of latency aren't simple sleeps
but instead busy-loops or a series of hundreds of small sleeps simply
because the hardware can't do better. Unfortunately latencytop doesn't
register these and so they slip under the radar. Hence expose a
simplified interface to re
On Tue, Dec 01, 2015 at 05:38:30PM +0200, Jani Nikula wrote:
> On Tue, 01 Dec 2015, Ville Syrjälä wrote:
> > On Tue, Dec 01, 2015 at 04:29:26PM +0200, Jani Nikula wrote:
> >> Choose between i2c bit banging and gmbus in a new higher level function,
> >> and let the i2c core retry the first time we
On Tue, Dec 01, 2015 at 04:29:27PM +0100, Daniel Vetter wrote:
> Some sources of significant amounts of latency aren't simple sleeps
> but instead busy-loops or a series of hundreds of small sleeps simply
> because the hardware can't do better. Unfortunately latencytop doesn't
> register these and
On 30/11/15 10:06, Tvrtko Ursulin wrote:
On 29/11/15 08:48, Chris Wilson wrote:
Limit busywaiting only to the request currently being processed by the
GPU. If the request is not currently being processed by the GPU, there
is a very low likelihood of it being completed within the 2 microsecond
s
On Tue, 01 Dec 2015, Ville Syrjälä wrote:
> On Tue, Dec 01, 2015 at 02:47:41PM +0200, Jani Nikula wrote:
>> On Mon, 30 Nov 2015, ville.syrj...@linux.intel.com wrote:
>> > From: Ville Syrjälä
>> >
>> > Generalize rawclk handling by storing it in dev_priv.
>> >
>> > Presumably our hrawclk readout w
On Tue, 01 Dec 2015, Ville Syrjälä wrote:
> On Tue, Dec 01, 2015 at 04:29:26PM +0200, Jani Nikula wrote:
>> Choose between i2c bit banging and gmbus in a new higher level function,
>> and let the i2c core retry the first time we fall back to bit banging.
>>
>> Signed-off-by: Jani Nikula
>> ---
>
Some sources of significant amounts of latency aren't simple sleeps
but instead busy-loops or a series of hundreds of small sleeps simply
because the hardware can't do better. Unfortunately latencytop doesn't
register these and so they slip under the radar. Hence expose a
simplified interface to re
A forced EDID read takes 22.5ms best-case, and that's per 128byte
block. HDMI screens tend to have 2-3 of those. Mutliply that by a few
outputs and then it's clear that userspace really never ever should
re-probe connector state on its own and trust the kernel to tell it
when anything changed. The
On 12/1/2015 7:30 PM, Ville Syrjälä wrote:
On Tue, Dec 01, 2015 at 01:49:10PM +, Chris Wilson wrote:
On Tue, Dec 01, 2015 at 03:28:28PM +0200, Ville Syrjälä wrote:
On Tue, Dec 01, 2015 at 01:09:33PM +, Chris Wilson wrote:
On Tue, Dec 01, 2015 at 02:34:41PM +0200, Ville Syrjälä wrote:
On Tue, Dec 01, 2015 at 04:29:26PM +0200, Jani Nikula wrote:
> Choose between i2c bit banging and gmbus in a new higher level function,
> and let the i2c core retry the first time we fall back to bit banging.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_i2c.c | 39 ++
On Tue, Dec 01, 2015 at 04:29:25PM +0200, Jani Nikula wrote:
> Shorter, easier to follow code with no functional changes. In all cases,
> the return value ultimately comes from gmbus_wait_hw_status() anyway.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_i2c.c | 12 ---
Use the first retired request on a new context to unpin
the old context. This ensures that the hw context remains
bound until it has been written back to by the GPU.
Now that the context is pinned until later in the request/context
lifecycle, it no longer needs to be pinned from context_queue to
re
Shorter, easier to follow code with no functional changes. In all cases,
the return value ultimately comes from gmbus_wait_hw_status() anyway.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_i2c.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/
Choose between i2c bit banging and gmbus in a new higher level function,
and let the i2c core retry the first time we fall back to bit banging.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_i2c.c | 39 +--
1 file changed, 25 insertions(+), 14 delet
Daniel,
LGTM, except one comment below:
On 12/01/2015 08:45 AM, Daniel Vetter wrote:
> Tests that master state isn't leaked to new masters by checking
> that auth magics for the old master don't work any more.
>
> Based upon a simple test program provided by Thomas.
>
> v2: Use correct test stanz
On Tue, Dec 01, 2015 at 02:06:26PM +, Chris Wilson wrote:
> On Tue, Dec 01, 2015 at 03:57:37PM +0200, Ville Syrjälä wrote:
> > On Tue, Dec 01, 2015 at 01:41:49PM +, Chris Wilson wrote:
> > > On Tue, Dec 01, 2015 at 03:08:34PM +0200, ville.syrj...@linux.intel.com
> > > wrote:
> > > > From:
On Thu, Nov 26, 2015 at 01:42:10PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 26, 2015 at 09:41:36AM +0100, Daniel Vetter wrote:
> > On Wed, Nov 25, 2015 at 04:35:31PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > DPLL_SDVO_HIGH_SPEED must be set for SDVO/H
On Thu, Nov 26, 2015 at 09:40:26AM +0100, Daniel Vetter wrote:
> On Wed, Nov 25, 2015 at 04:35:30PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > ironlake_crtc_compute_clock() gets called during atomic compute phase,
> > so we must check the future pipe type instead
On Mon, Nov 30, 2015 at 09:26:42AM +0100, Daniel Vetter wrote:
> On Thu, Nov 26, 2015 at 06:27:07PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > The .get_config() hooks should not reference anything in crtc->config,
> > everything should be based on the passed in pi
On Tue, Dec 01, 2015 at 03:57:37PM +0200, Ville Syrjälä wrote:
> On Tue, Dec 01, 2015 at 01:41:49PM +, Chris Wilson wrote:
> > On Tue, Dec 01, 2015 at 03:08:34PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > Unfortunatey there appear to quite a few HSW
On Tue, Dec 01, 2015 at 01:49:10PM +, Chris Wilson wrote:
> On Tue, Dec 01, 2015 at 03:28:28PM +0200, Ville Syrjälä wrote:
> > On Tue, Dec 01, 2015 at 01:09:33PM +, Chris Wilson wrote:
> > > On Tue, Dec 01, 2015 at 02:34:41PM +0200, Ville Syrjälä wrote:
> > > > On Mon, Nov 30, 2015 at 12:41
On Tue, Dec 01, 2015 at 01:41:49PM +, Chris Wilson wrote:
> On Tue, Dec 01, 2015 at 03:08:34PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Unfortunatey there appear to quite a few HSW/BDW machines (eg.
> > NUCs, Brix Pro) in the wild with LPT/WPT-H but non-work
On ma, 2015-11-30 at 16:23 -0800, Bob Paauwe wrote:
> Now that the frequency can drop below the user specified minimum when
> the gpu is idle, add some checking to verify that it really does drop
> down to the RPn frequency in specific cases.
>
> To do this, modify the main test flow to take two '
On ma, 2015-11-30 at 16:23 -0800, Bob Paauwe wrote:
> Since commit
>
> commit aed242ff7ebb697e4dff912bd4dc7ec7192f7581
> Author: Chris Wilson
> Date: Wed Mar 18 09:48:21 2015 +
>
> drm/i915: Relax RPS contraints to allows setting minfreq on
> idle
>
> it is now possible that t
On Tue, Dec 01, 2015 at 03:28:28PM +0200, Ville Syrjälä wrote:
> On Tue, Dec 01, 2015 at 01:09:33PM +, Chris Wilson wrote:
> > On Tue, Dec 01, 2015 at 02:34:41PM +0200, Ville Syrjälä wrote:
> > > On Mon, Nov 30, 2015 at 12:41:05PM +0530, akash.g...@intel.com wrote:
> > > > @@ -3982,7 +3983,21 @
On Tue, Dec 01, 2015 at 03:08:34PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Unfortunatey there appear to quite a few HSW/BDW machines (eg.
> NUCs, Brix Pro) in the wild with LPT/WPT-H but non-working FDI.
> FDI training fails every single time on these machines. Dunno
On Tue, Dec 01, 2015 at 10:33:22AM +, Thomas Wood wrote:
> On 1 December 2015 at 10:24, Daniel Vetter wrote:
> > Forcing connector state is a basic piece of our test infrastructure
> > that we use in all the kms_ tests. It allows us to run tests even if
> > no outputs are connected.
> >
> > Th
On Tue, Dec 01, 2015 at 01:12:43PM +0200, Jani Nikula wrote:
> On Tue, 01 Dec 2015, Daniel Vetter wrote:
> > Somehow the kernel's mode list changed with our EDID.
>
> I do not undestand what you're trying to say here.
The EDID we injected stayed the same, but the kernel started listing more
mode
On Tue, Dec 01, 2015 at 01:09:33PM +, Chris Wilson wrote:
> On Tue, Dec 01, 2015 at 02:34:41PM +0200, Ville Syrjälä wrote:
> > On Mon, Nov 30, 2015 at 12:41:05PM +0530, akash.g...@intel.com wrote:
> > > @@ -3982,7 +3983,21 @@ i915_gem_object_set_to_cpu_domain(struct
> > > drm_i915_gem_object *
On Tue, Dec 01, 2015 at 02:47:41PM +0200, Jani Nikula wrote:
> On Mon, 30 Nov 2015, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Generalize rawclk handling by storing it in dev_priv.
> >
> > Presumably our hrawclk readout works at least for CTG and ELK
> > since we've been
1 - 100 of 171 matches
Mail list logo
