On 01/21/2014 11:17 AM, Matthew Garrett wrote:
> On Tue, 2014-01-21 at 10:24 +0800, Aaron Lu wrote:
>> On 01/20/2014 09:34 PM, Matthew Garrett wrote:
>>> On Mon, 2014-01-20 at 16:12 +0800, Aaron Lu wrote:
>>>
1 remove the win8 OSI check, I've seen win7 laptops that also needs to
have on
On Tue, 2014-01-21 at 10:24 +0800, Aaron Lu wrote:
> On 01/20/2014 09:34 PM, Matthew Garrett wrote:
> > On Mon, 2014-01-20 at 16:12 +0800, Aaron Lu wrote:
> >
> >> 1 remove the win8 OSI check, I've seen win7 laptops that also needs to
> >> have only the GPU interface left and checking win8 doesn
Since acpi_evaluate_object() returns acpi_status and not plain int,
ACPI_FAILURE() should be used for checking its return value.
Reviewed-by: Jani Nikula
Signed-off-by: Yijing Wang
---
v3->v4: Fix spell error, add Jani Nikula reviewed-by.
v2->v3: Fix compile error pointed out by Hanjun.
v1->v2:
On 01/20/2014 09:34 PM, Matthew Garrett wrote:
> On Mon, 2014-01-20 at 16:12 +0800, Aaron Lu wrote:
>
>> 1 remove the win8 OSI check, I've seen win7 laptops that also needs to
>> have only the GPU interface left and checking win8 doesn't make much
>> sense now;
>
> Are we sure that those aren
Can be expanded up on to include all sorts of things (HDMI infoframe
data, more DP status, etc). Should be useful for bug reports to get a
baseline on the display config and info.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_debugfs.c | 155
dri
Just like we have for connector type etc.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c | 20
include/drm/drm_crtc.h | 1 +
2 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 266a01d..3982dd9 100644
On Mon, Jan 20, 2014 at 11:24:53PM +0100, Mark Kettenis wrote:
> Commit 50a45a1cdd4d8319ba9358974d241069689591c5 introduced the use of
> "struct stat" but doesn't include . Presumably that leaks
> in trough some other header on Linux, but on OpenBSD compilation fails
> because the struct isn't kno
Commit 50a45a1cdd4d8319ba9358974d241069689591c5 introduced the use of
"struct stat" but doesn't include . Presumably that leaks
in trough some other header on Linux, but on OpenBSD compilation fails
because the struct isn't known.
diff --git a/src/sna/kgem.c b/src/sna/kgem.c
index 8e073e2..66f5e7
Read out and calculate the port and pixel clocks on DDI configs as well.
This means we have to grab the DP divider values and look at the port
mapping to figure out which clock select reg to read out.
v2: do the work from ddi_get_config (Ville)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i9
Now that we have DDI support, we can check these all the time.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 40e5252
On Mon, Jan 20, 2014 at 10:17:36AM +, Chris Wilson wrote:
> On older generations (gen2, gen3) the GPU requires fences for many
> operations, such as blits. The display hardware also requires fences for
> scanouts and this leads to a situation where an arbitrary number of
> fences may be pinned
On Mon, Jan 20, 2014 at 7:38 PM, Ville Syrjälä
wrote:
> We have the same problem already w/ underrun interrupts at least, no?
Yeah, but iirc we've hand-waved over the issue with "hopefully the
bios wm setup never underruns while we take over". If it does we're
screwed ;-)
Wrt vblank interrupts I
On Mon, Jan 20, 2014 at 06:43:42PM +0100, Daniel Vetter wrote:
> On Mon, Jan 20, 2014 at 5:56 PM, Ville Syrjälä
> wrote:
> >> > +{
> >> > + struct drm_device *dev = crtc->dev;
> >> > + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> >> > + const struct drm_display_mode *mode =
> >> >
On Mon, Jan 20, 2014 at 5:56 PM, Ville Syrjälä
wrote:
>> > +{
>> > + struct drm_device *dev = crtc->dev;
>> > + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>> > + const struct drm_display_mode *mode =
>> > &intel_crtc->config.adjusted_mode;
>> > + enum pipe pipe = intel_crtc->pip
For HSW+ platforms, enable the 5.4Ghz (HBR2) link rate for devices that support
it. The
sink device must report that is supports Displayport 1.2 and the HBR2 bit rate
in the
DPCD in order to use HBR2.
Signed-off-by: Todd Previte
---
drivers/gpu/drm/i915/intel_dp.c | 31 +++
More whitepsace cleanup.
One caveat with this patch: current link policy dictates that the driver will
train the
"wide and slow", i.e. max lanes at low speed. It will increase lanes and speed
when the
specified resolution demands greater bandwidth. Consequently, the resolution
w
On Mon, Dec 23, 2013 at 11:27:40AM +0530, Vandana Kannan wrote:
> Adding picture aspect ratio for CEA modes based on CEA-861D Table 3 or
> CEA-861E Table 4. This is useful for filling up the detail in AVI
> infoframe.
>
> v2: Ville's inputs incorporated. Added picture aspect ratio as part of
> edi
On Mon, Jan 20, 2014 at 05:23:39PM +0100, Daniel Vetter wrote:
> On Fri, Jan 17, 2014 at 08:09:04PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Add a mechanism by which we can evade the leading edge of vblank. This
> > guarantees that no two sprite register writes
On Sat, 18 Jan 2014 16:01:06 +0200
Ville Syrjälä wrote:
> On Fri, Jan 17, 2014 at 01:16:56PM -0800, Jesse Barnes wrote:
> > In DDI configs, we need to get the encoder to CRTC mapping early on so
> > we can read out and calculate the clock state correctly, as it depends
> > on the port.
> >
> > S
On Fri, Jan 17, 2014 at 08:09:04PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Add a mechanism by which we can evade the leading edge of vblank. This
> guarantees that no two sprite register writes will straddle on either
> side of the vblank start, and that means all th
On Mon, Jan 20, 2014 at 10:44:27AM +, Chris Wilson wrote:
> On Mon, Jan 20, 2014 at 11:37:42AM +0100, Daniel Vetter wrote:
> > On Mon, Jan 20, 2014 at 09:49:24AM +, Chris Wilson wrote:
> > > On Sun, Jan 19, 2014 at 10:55:26PM +0100, Daniel Vetter wrote:
> > > > Also there's a certain chance
On Mon, Jan 20, 2014 at 09:06:40AM -0600, Jeff McGee wrote:
> On Sun, Jan 19, 2014 at 02:49:19PM +0100, Daniel Vetter wrote:
> > If it's not in the multi-test target group testrunners won't pick up
> > on the fact that they need to enumerate subtests first.
> >
>
> OK. I haven't yet tried piglit,
On Fri, Jan 17, 2014 at 06:14:50PM -0200, Paulo Zanoni wrote:
> 2014/1/16 Daniel Vetter :
> > Currently we're doing the reset handling a bit late, and we're doing
> > it both in the driver load code and on resume. This makes it unusable
> > for e.g. resetting the panel power sequence state like Pau
On Fri, Jan 17, 2014 at 02:57:42PM +0100, Daniel Vetter wrote:
> On Thu, Dec 19, 2013 at 09:39:12AM -0800, Jesse Barnes wrote:
> > On Thu, 19 Dec 2013 14:29:44 -0200
> > Paulo Zanoni wrote:
> >
> > > From: Paulo Zanoni
> > >
> > > Because we already do the wait in software: see
> > > ironlake_w
On Mon, Jan 20, 2014 at 01:47:51PM -0200, Paulo Zanoni wrote:
> 2014/1/17 Daniel Vetter :
> > On Fri, Jan 17, 2014 at 10:21 PM, Chris Wilson
> > wrote:
> >> On Fri, Jan 17, 2014 at 07:11:14PM -0200, Paulo Zanoni wrote:
> >>> 2014/1/17 Chris Wilson :
> >>> > On Fri, Jan 17, 2014 at 06:17:42PM -020
Also, move that computation outside of the for loop that tries 5 times,
this value doesn't change between tries.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_dp.c | 59 ++---
1 file changed, 37 insertions(+), 22 deletions(-)
diff --git a/drive
A tiny clean-up to allow better code separation between platforms.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_dp.c | 79
drivers/gpu/drm/i915/intel_drv.h | 2 +
2 files changed, 58 insertions(+), 23 deletions(-)
diff --git a/drivers/g
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_dp.c | 10 ++
drivers/gpu/drm/i915/intel_drv.h | 8
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ae9902a..95147ac 100644
--- a
A tiny bit of refactoring to make the code more pluggable:
1/ separate the get_aux_clock_divider() into multiple functions. I Tested
this patch on IVB and HSW, the simpler to review that patch is to not look at
the diff but the before/after version and follow the different code path for
ea
So it's easier to compare what we program with the documentation, not
having to jump at all.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_dp.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_
2014/1/17 Daniel Vetter :
> On Fri, Jan 17, 2014 at 10:21 PM, Chris Wilson
> wrote:
>> On Fri, Jan 17, 2014 at 07:11:14PM -0200, Paulo Zanoni wrote:
>>> 2014/1/17 Chris Wilson :
>>> > On Fri, Jan 17, 2014 at 06:17:42PM -0200, Paulo Zanoni wrote:
>>> >> From: Paulo Zanoni
>>> >>
>>> >> The eDP co
On Sun, Jan 19, 2014 at 02:49:19PM +0100, Daniel Vetter wrote:
> If it's not in the multi-test target group testrunners won't pick up
> on the fact that they need to enumerate subtests first.
>
OK. I haven't yet tried piglit, so missed this detail. Thanks
Jeff
___
Hi Dave,
Here's the vblank timestamp pull request you wanted.
I addressed the few bugs that Mario pointed out and added
the r-bs.
As it has been a while since I made the changes, I gave it a
quick spin on a few different i915 machines. Fortunately
everything still seems to be fine.
The followin
On Mon, 2014-01-20 at 16:12 +0800, Aaron Lu wrote:
> 1 remove the win8 OSI check, I've seen win7 laptops that also needs to
> have only the GPU interface left and checking win8 doesn't make much
> sense now;
Are we sure that those aren't simply some other bug?
--
Matthew Garrett
__
On Mon, Jan 20, 2014 at 01:26:55PM +0200, Ville Syrjälä wrote:
> On Mon, Jan 20, 2014 at 11:18:53AM +, Chris Wilson wrote:
> > On Fri, Jan 17, 2014 at 11:22:52AM +, Chris Wilson wrote:
> > > On Fri, Jan 17, 2014 at 11:35:16AM +0200, ville.syrj...@linux.intel.com
> > > wrote:
> > > > From:
From: Deepak S
When current delay is already at max delay, Let's disable the PM UP
THRESHOLD INTRRUPTS, so that we will not get further interrupts until
current delay is less than max delay, Also request for the PM DOWN
THRESHOLD INTRRUPTS to indicate the decrease in clock freq. and
viceversa for
From: Deepak S
With RC6 enabled, BYT has an HW issue in determining the right
Gfx busyness.
WA for Turbo + RC6: Use SW based Gfx busy-ness detection to decide
on increasing/decreasing the freq. This logic will monitor C0
counters of render/media power-wells over EI period and takes
necessary acti
From: Deepak S
When we enter RC6 and GFX Clocks are off, the voltage remains higher
than Vmin. When we try to set the freq to RPe, it might fail since the
Gfx clocks are down. So to fix this in Gfx idle, Bring the GFX clock up
and set the freq to RPe then move GFx down.
v2: remove vlv_update_rps
From: Deepak S
Below patches addes WA to set Gfx freq while clock are down. Also, added a WA
to enables both RC6 and Turbo work together.
Deepak S (3):
drm/i915: Disable/Enable PM Intrrupts based on the current freq.
drm/i915/vlv: WA to fix Voltage not getting dropped to Vmin when Gfx
On Mon, Jan 20, 2014 at 11:18:53AM +, Chris Wilson wrote:
> On Fri, Jan 17, 2014 at 11:22:52AM +, Chris Wilson wrote:
> > On Fri, Jan 17, 2014 at 11:35:16AM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > Not sure anyone cares about this information.
On Fri, Jan 17, 2014 at 11:22:52AM +, Chris Wilson wrote:
> On Fri, Jan 17, 2014 at 11:35:16AM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Not sure anyone cares about this information. I suppose most people
> > would just look at /proc/interrupts instead.
> >
On Mon, Jan 20, 2014 at 11:37:42AM +0100, Daniel Vetter wrote:
> On Mon, Jan 20, 2014 at 09:49:24AM +, Chris Wilson wrote:
> > On Sun, Jan 19, 2014 at 10:55:26PM +0100, Daniel Vetter wrote:
> > > Also there's a certain chance we'll starve
> > > the unpin work, similar to the issues around flush
On Mon, Jan 20, 2014 at 09:49:24AM +, Chris Wilson wrote:
> On Sun, Jan 19, 2014 at 10:55:26PM +0100, Daniel Vetter wrote:
> > On Sun, Jan 19, 2014 at 10:20 PM, Chris Wilson
> > wrote:
> > > On older generations (gen2, gen3) the GPU requires fences for many
> > > operations, such as blits. Th
Since an old pageflip will keep its scanout buffer object pinned until
it has executed its unpin task on the common workqueue, we can clog up
our GGTT with stale pinned objects. As we cannot flush those workqueues
without dropping our locks, we have to resort to falling back to
userspace and tellin
On older generations (gen2, gen3) the GPU requires fences for many
operations, such as blits. The display hardware also requires fences for
scanouts and this leads to a situation where an arbitrary number of
fences may be pinned by old scanouts following a pageflip but before we
have executed the u
On Sun, Jan 19, 2014 at 10:55:26PM +0100, Daniel Vetter wrote:
> On Sun, Jan 19, 2014 at 10:20 PM, Chris Wilson
> wrote:
> > On older generations (gen2, gen3) the GPU requires fences for many
> > operations, such as blits. The display hardware also requires fences for
> > scanouts and this leads
On Mon, Jan 20, 2014 at 08:21:54AM +0100, Daniel Vetter wrote:
> At least drm/i915 expects that the obj->dev pointer is set even in
> failure paths. Specifically when the shmem initialization fails we
> call i915_gem_object_free which needs to deref obj->base.dev to get at
> the slab pointer in the
Hi
On Mon, Jan 20, 2014 at 8:21 AM, Daniel Vetter wrote:
> At least drm/i915 expects that the obj->dev pointer is set even in
> failure paths. Specifically when the shmem initialization fails we
> call i915_gem_object_free which needs to deref obj->base.dev to get at
> the slab pointer in the dev
>> Really? WaReadAfterWriteHazard in intel_ring_flush_all_caches() and
>> WaTlbInvalidateStoreDataBefore in intel_ring_invalidate_all_caches()?
Sorry for this lapse, we have already identified this, will cover this change
inside the VLV platform check.
>> My opinion still stands. I think all wor
On Sun, 19 Jan 2014, "Goel, Akash" wrote:
>>> Frankly, I don't know much about these particular workarounds, but
>>> for bisecting any regressions it would probably be a good idea to
>>> split the patch per workaround touched.
> Sorry for late response on this, actually we have done sufficient
>
Hi Igor,
On 01/18/2014 09:54 PM, Igor Gnatenko wrote:
> From: Aaron Lu
>
> Some system's ACPI video backlight control interface is broken and the
> native backlight control interface should be used by default. This patch
> sets the use_native_backlight parameter to true for those systems so
> th
51 matches
Mail list logo
