On Sat, Feb 15, 2014 at 12:02:37AM +0100, Hans de Goede wrote:
> Once the xserver stops running as root on kms capabable systems, we will need
> some other way to access the backlight.
>
> The approach taken in this patch leaves most of the heavy lifting (wrt
> doing everything suid root safe) to
On Sat, Feb 15, 2014 at 12:02:35AM +0100, Hans de Goede wrote:
> O_NONBLOCK is a status flag not a descriptor flag, so F_GETFL / F_SETFL should
> be used to modify it.
>
> Signed-off-by: Hans de Goede
Oops, that was a silly typo that unfortunately compiled.
Thanks,
-Chris
--
Chris Wilson, Inte
O_NONBLOCK is a status flag not a descriptor flag, so F_GETFL / F_SETFL should
be used to modify it.
Signed-off-by: Hans de Goede
---
src/intel_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/intel_device.c b/src/intel_device.c
index effda24..07b7d2e 100644
-
Once the xserver stops running as root on kms capabable systems, we will need
some other way to access the backlight.
The approach taken in this patch leaves most of the heavy lifting (wrt
doing everything suid root safe) to pkexec, as is done in ie
gnome-settings-daemon, which controls the backli
Allow fd_set_cloexec / fd_set_nonblock to be used outside of intel_device.c.
Signed-off-by: Hans de Goede
---
src/intel_device.c | 8
src/intel_driver.h | 2 ++
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/src/intel_device.c b/src/intel_device.c
index 07b7d2e..fd0b735
I get the following splat in my tests running 3.14-rc2:
[3.955123] WARNING: CPU: 0 PID: 1 at
/work/autotest/nobackup/linux-test.git/drivers/gpu/drm/i915/intel_display.c:857
intel_wait_for_pipe_off+0x17a/0x2d0()
[3.955124] pipe_off wait timed out
[3.955127] CPU: 0 PID: 1 Comm: swapper
In commit e4e0c058a19c41150d12ad2d3023b3cf09c5de67
Author: Eugeni Dodonov
Date: Wed Feb 8 12:53:50 2012 -0800
drm/i915: gen7: Implement an L3 caching workaround.
the L3 cache aging was disabled. This was part of a shotgun response
to a number of GPU hang bugs, but there appears to be no do
On certain OpenGL benchmark applications, setting this bit results in
frequent GPU hangs. On BYT-M/I, the hangs go away by not setting this
bit.
---
drivers/gpu/drm/i915/intel_pm.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_p
On Fri, Feb 14, 2014 at 12:34:22PM -0800, Ben Widawsky wrote:
> On Tue, Feb 11, 2014 at 05:12:17PM +0100, Daniel Vetter wrote:
> > - 6/9 lacks review ...
> >
>
> 6/9 can be skipped for this series, though I think it's a reasonable
> patch. Maybe Chris or Jesse has an opinion on 6/9?
Yes, program
On Tue, Feb 11, 2014 at 05:12:17PM +0100, Daniel Vetter wrote:
> On Thu, Feb 06, 2014 at 11:42:39AM -0200, Rodrigo Vivi wrote:
> > Reviewed-by: Rodrigo Vivi
> >
> > On Wed, Jan 29, 2014 at 2:25 AM, Ben Widawsky
> > wrote:
> > > Signed-off-by: Ben Widawsky
> > > ---
> > > drivers/gpu/drm/i915/i
> On Fri, Feb 14, 2014 at 09:09:52AM +0200, Jani Nikula wrote:
>
> It seems that it will be better to track this in bugzilla rather than
> the mailing lists. Please file a bug on DRM/Intel component at
> https://bugs.freedesktop.org/enter_bug.cgi?product=DRI. Attach these
> files.
Done. We can co
On Fri, Feb 14, 2014 at 08:23:54PM +0200, Imre Deak wrote:
> pci_get_class(class, from) drops the refcount for 'from', so the
> extra pci_dev_put we do on it will result in a use after free bug
> starting with the WARN below.
>
> Regression introduced in
>
> commit 6a9c4b35e6696a63805b6da5e4889c6
pci_get_class(class, from) drops the refcount for 'from', so the
extra pci_dev_put we do on it will result in a use after free bug
starting with the WARN below.
Regression introduced in
commit 6a9c4b35e6696a63805b6da5e4889c6986e9ee1b
Author: Rui Guo
Date: Wed Jun 19 21:10:23 2013 +0800
dr
On Fri, Feb 14, 2014 at 05:29:30PM +, Damien Lespiau wrote:
> On Fri, Feb 14, 2014 at 02:06:06PM +0100, Daniel Vetter wrote:
> > Spotted while auditing the code for fencing issues.
> >
> > Cc: Chris Wilson
> > Signed-off-by: Daniel Vetter
>
> Reviewed-by: Damien Lespiau
Queued for -next,
On Fri, 2014-02-14 at 19:48 +0200, Imre Deak wrote:
> On Fri, 2014-02-14 at 17:35 +, Chris Wilson wrote:
> > On Fri, Feb 14, 2014 at 07:23:32PM +0200, Imre Deak wrote:
> > > pci_get_class(class, from) drops the refcount for 'from', so the
> > > extra pci_dev_put we do on it will result in a use
Hi all,
New -testing cycle with cool stuff:
- Fix the execbuf rebind performance regression due to topic/ppgtt (Chris).
- Fix up the connector cleanup ordering for sdvod i2c and dp aux devices (Imre).
- Try to preserve the firmware modeset config on driver load. And a bit of prep
work for smooth
On Fri, Feb 14, 2014 at 07:48:18PM +0200, Imre Deak wrote:
> On Fri, 2014-02-14 at 17:35 +, Chris Wilson wrote:
> > @@ -382,18 +379,15 @@ void intel_detect_pch(struct drm_device *dev)
> > DRM_DEBUG_KMS("Found LynxPoint LP PCH\n");
> > WARN
On Fri, 2014-02-14 at 17:35 +, Chris Wilson wrote:
> On Fri, Feb 14, 2014 at 07:23:32PM +0200, Imre Deak wrote:
> > pci_get_class(class, from) drops the refcount for 'from', so the
> > extra pci_dev_put we do on it will result in a use after free bug
> > sometime later starting with the WARN be
On Fri, Feb 14, 2014 at 07:23:32PM +0200, Imre Deak wrote:
> pci_get_class(class, from) drops the refcount for 'from', so the
> extra pci_dev_put we do on it will result in a use after free bug
> sometime later starting with the WARN below.
That's a very nice find.
But you can tidy this loop up e
On Fri, Feb 14, 2014 at 02:06:06PM +0100, Daniel Vetter wrote:
> Spotted while auditing the code for fencing issues.
>
> Cc: Chris Wilson
> Signed-off-by: Daniel Vetter
Reviewed-by: Damien Lespiau
--
Damien
> ---
> drivers/gpu/drm/i915/intel_display.c | 10 +-
> drivers/gpu/drm/i91
pci_get_class(class, from) drops the refcount for 'from', so the
extra pci_dev_put we do on it will result in a use after free bug
sometime later starting with the WARN below.
Regression introduced in
commit 6a9c4b35e6696a63805b6da5e4889c6986e9ee1b
Author: Rui Guo
Date: Wed Jun 19 21:10:23 201
On Fri, 14 Feb 2014 15:32:18 +0530
Vandana Kannan wrote:
> From: Pradeep Bhat
>
> This patch reads the DRRS support and Mode type from VBT fields.
> The read information will be stored in VBT struct during BIOS
> parsing. The above functionality is needed for decision making
> whether DRRS feat
On Fri, 14 Feb 2014 16:35:54 +0100
Daniel Vetter wrote:
> Looks like I've missed one of the potential NULL deref bugs in Jesse's
> fbdev->fb embedded struct to pointer conversions. Fix it up.
>
> This regression has been introduced in
>
> commit 8bcd45534ddf68ab71aeed709dacd9cf65dc0f75
> Author
Looks like I've missed one of the potential NULL deref bugs in Jesse's
fbdev->fb embedded struct to pointer conversions. Fix it up.
This regression has been introduced in
commit 8bcd45534ddf68ab71aeed709dacd9cf65dc0f75
Author: Jesse Barnes
Date: Fri Feb 7 12:10:38 2014 -0800
drm/i915: all
Hi Dave,
First pull request for 3.15! One week later than usual since our QA was
celbrating Chines New Year ;-)
drm-intel-next-2014-02-07:
- Yet more steps towards atomic modeset from Ville.
- DP panel power sequencing improvements from Paulo.
- irq code cleanups from Ville.
- 5.4 GHz dp lane clo
On Fri, Feb 14, 2014 at 02:06:07PM +0100, Daniel Vetter wrote:
> Otherwise we end up tearing down fences when e.g. the client quits
> way too early. Might or might not fix a fence pin_count BUG Ville has
> reported.
>
> Cc: Ville Syrjälä
> Signed-off-by: Daniel Vetter
Good catch. I am slightly
On Fri, Feb 14, 2014 at 02:06:07PM +0100, Daniel Vetter wrote:
> Otherwise we end up tearing down fences when e.g. the client quits
> way too early. Might or might not fix a fence pin_count BUG Ville has
> reported.
>
> Cc: Ville Syrjälä
> Signed-off-by: Daniel Vetter
This one should also have:
On Fri, Feb 14, 2014 at 01:08:05PM +, Chris Wilson wrote:
> On Fri, Feb 14, 2014 at 02:01:10PM +0100, Daniel Vetter wrote:
> > So I've finally gotten around to shuffle these patches a bit more and
> > hopefully
> > in the process cleared up any lingering misunderstandings I've had about
> > C
On Fri, Feb 14, 2014 at 02:01:10PM +0100, Daniel Vetter wrote:
> So I've finally gotten around to shuffle these patches a bit more and
> hopefully
> in the process cleared up any lingering misunderstandings I've had about
> Chris'
> originally patch.
>
> I'll pull this in later today (presuming
Userspace can currently provoke this when e.g. trying to use a pinned
scanout as a cursor or overlay target. Later on that might lead to
some fun fence pin count mayhem.
Spurred by Ville's report that something goes wrong here and
originally I've thought that this might slip through the pwrite gtt
Otherwise we end up tearing down fences when e.g. the client quits
way too early. Might or might not fix a fence pin_count BUG Ville has
reported.
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-
Spotted while auditing the code for fencing issues.
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 10 +-
drivers/gpu/drm/i915/intel_overlay.c | 2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dis
One side-effect of the introduction of ppgtt was that we needed to
rebind the object into the appropriate vm (and global gtt in some
peculiar cases). For simplicity this was done twice for every object on
every call to execbuffer. However, that adds a tremendous amount of CPU
overhead (rewriting al
This is prep work for reworking the object_pin logic. Atm
it still does a (now redundant) lookup of the vma. The next
patch will fix this.
Split out from Chris vma-bind rework.
Cc: Chris Wilson
Cc: Ben Widawsky
Reviewed-by: Jani Nikula
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i9
With abitrary pin flags it makes sense to split out a "please bind
this into global gtt" from the "please allocate in the mappable
range".
Use this unconditionally in our global gtt pin helper since this is
what its callers want. Later patches will drop PIN_MAPPABLE where it's
not strictly needed.
There's no need not to, really.
Split out from Chris vma-bind rework.
Cc: Chris Wilson
Cc: Ben Widawsky
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/d
Only the hardware really access them, so no need to have cpu
gtt access available.
Split out from Chris vma-bind rework.
Note that this is only possible due to the split-up of the mappable
pin flag into PIN_GLOBAL and PIN_MAPPABLE.
Cc: Chris Wilson
Cc: Ben Widawsky
Signed-off-by: Daniel Vetter
We access it through the cpu window. No functional difference expected
atm since we default to a bottom-up allocation scheme. But that might
eventually change so that we prefer the unmappable range for buffers
that don't need cpu gtt access.
Split out from Chris vma-bind rework.
Note that this is
Split out from Chris vma-bind rework.
Cc: Chris Wilson
Cc: Ben Widawsky
Reviewed-by: Jani Nikula
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/g
So I've finally gotten around to shuffle these patches a bit more and hopefully
in the process cleared up any lingering misunderstandings I've had about Chris'
originally patch.
I'll pull this in later today (presuming nothing bad shows up) and then cut a
new -testing before heading off for 2 week
Split out from Chris vma-bind rework.
Cc: Chris Wilson
Cc: Ben Widawsky
Cc: Jani Nikula
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i9
Tighter code since legacy gem has only mappable anyway.
Split out from Chris vma-bind rework.
Note that this is only possible due to the split-up of the mappable
pin flag into PIN_GLOBAL and PIN_MAPPABLE.
Cc: Chris Wilson
Cc: Ben Widawsky
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915
Split out from Chris vma-bind rework.
Jani wondered why this is save, and the reason is that i915_vma_unbind
does all these checks, too. So they're redundant.
Cc: Chris Wilson
Cc: Ben Widawsky
Cc: Jani Nikula
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h | 10 --
d
Anything more than just one bool parameter is just a pain to read,
symbolic constants are much better.
Split out from Chris' vma-binding rework patch.
v2: Undo the behaviour change in object_pin that Chris spotted.
v3: Split out misplaced hunk to handle set_cache_level errors,
spotted by Jani.
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 the writes will be latched
together in one atomic operation.
We do the vblank evade by che
On Fri, Feb 14, 2014 at 12:28:29PM +, Chris Wilson wrote:
> On Fri, Feb 14, 2014 at 02:18:57PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Make sure the line_time_us isn't zero in the gmch watermarks code as
> > that would cause a div by zero. This can be trigg
On Fri, Feb 14, 2014 at 02:18:57PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Make sure the line_time_us isn't zero in the gmch watermarks code as
> that would cause a div by zero. This can be triggered by specifying
> a very fast pixel clock for the mode.
Very fast bu
From: Ville Syrjälä
Make sure the line_time_us isn't zero in the gmch watermarks code as
that would cause a div by zero. This can be triggered by specifying
a very fast pixel clock for the mode.
At some point we should probably just switch over to using the same
math we use on PCH platforms whic
From: Ville Syrjälä
In interlaced modes, the pixel counter counts all pixels,
so one field will have htotal more pixels. In order to avoid
the reported position from jumping backwards when the pixel
counter is beyond the length of the shorter field, just
clamp the position the length of the short
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 the writes will be latched
together in one atomic operation.
We do the vblank evade by che
From: Ville Syrjälä
Add a new function intel_get_crtc_scanline() that returns the current
scanline counter for the crtc.
v2: Rebase after vblank timestamp changes.
Use intel_ prefix instead of i915_ as is more customary for
display related functions.
Include DRM_SCANOUTPOS_INVBL in t
On Fri, Feb 14, 2014 at 04:31:17PM +0530, Sagar Arun Kamble wrote:
> On Wed, 2014-02-12 at 23:15 +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > The cursor plane also supports 180 degree rotation. Add a new
> > "cursor-rotation" property on the crtc which controls this
On Wed, 2014-02-12 at 23:15 +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The cursor plane also supports 180 degree rotation. Add a new
> "cursor-rotation" property on the crtc which controls this.
>
> Unlike sprites, the cursor has a fixed size, so if you have a small
>
On Fri, Feb 14, 2014 at 03:32:21PM +0530, Vandana Kannan wrote:
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 1933675..3407af6 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3411,11 +3411,17 @@ void intel_dp_en
On Thu, Feb 13, 2014 at 04:11:55PM +0200, Antti Koskipää wrote:
> On 02/11/2014 05:12 PM, Imre Deak wrote:
> > The main point of this patchset is to fix a driver unload bug caused by
> > incorrect order of dp aux i2c cleanup wrt. destroying the corresponding
> > encoder/connector objects, see the s
From: Pradeep Bhat
This patch reads the DRRS support and Mode type from VBT fields.
The read information will be stored in VBT struct during BIOS
parsing. The above functionality is needed for decision making
whether DRRS feature is supported in i915 driver for eDP panels.
This information helps
For Broadwell, there is one instance of Transcoder MN values per transcoder.
For dynamic switching between multiple refreshr rates, M/N values may be
reprogrammed on the fly. Link N programming triggers update of all data and
link M & N registers and the new M/N values will be used in the next fram
Adding support to detect display idleness by tracking page flip from
user space. Switch to low refresh rate is triggered after 2 seconds of
idleness. The delay is configurable. If there is a page flip or call to
update the plane, then high refresh rate is applied.
The feature is not used in dual-di
Dynamic Refresh Rate Switching (DRRS) is a power conservation feature which
enables swtiching between low and high refresh rates based on the usage
scenario. This feature is applciable for internal eDP panel. Indication that
the panel supports DRRS is given by the panel EDID, whic
From: Pradeep Bhat
This patch computes and stored 2nd M/N/TU for switching to different
refresh rate dynamically. PIPECONF_EDP_RR_MODE_SWITCH bit helps toggle
between alternate refresh rates programmed in 2nd M/N/TU registers.
v2: Daniel's review comments
Computing M2/N2 in compute_config and st
From: Pradeep Bhat
This patch and finds out the lowest refresh rate supported for the resolution
same as the fixed_mode, based on the implementaion find_panel_downclock.
It also checks the VBT fields to see if panel supports seamless DRRS or not.
Based on above data it marks whether eDP panel sup
Hi Dave,
3 fixes plus 1 prep patch, all four cc: stable. Jani will take over from
here and the plan is that he'll do 3.14-fixes for the entire release just
to work things out a bit.
Cheers, Daniel
The following changes since commit 1d2cb9a54abc6e1d239f28f07661366d5662a94a:
drm/i915: Pair va_
Hi,
On 02/13/2014 09:24 PM, Mark Kettenis wrote:
>> Date: Thu, 13 Feb 2014 20:37:47 +0100
>> From: Hans de Goede
>> Right, that is what I was thinking too, so the question then becomes how
>> hard you will scream at me if I add something like this to xf86-video-intel
>> linux specific backligh
63 matches
Mail list logo
