On Tue, Feb 25, 2014 at 3:36 AM, Jani Nikula wrote:
> On Sun, 23 Feb 2014, Josh Boyer wrote:
>> Backport of upstream commit c91c9f328
>>
>> ---
>> drivers/gpu/drm/i915/i915_drv.h | 1 +
>> drivers/gpu/drm/i915/intel_opregion.c | 31 ++-
>> drivers/gpu/drm/i915/
On Wed, 26 Feb 2014 20:02:19 +0200
Imre Deak wrote:
> On Thu, 2014-02-20 at 11:58 -0800, Jesse Barnes wrote:
> > On Wed, 19 Feb 2014 14:29:44 +0200
> > Ville Syrjälä wrote:
> >
> > > On Tue, Feb 18, 2014 at 12:02:20AM +0200, Imre Deak wrote:
> > > > Based on an early draft from Jesse.
> > > >
On Fri, 21 Feb 2014 21:03:33 +0200
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Allow the driver to specify whether all new vblank requests after
> drm_vblank_off() should be rejected. And add a counterpart called
> drm_vblank_on() which will again allow vblank requests to come
On Tue, 25 Feb 2014 11:58:26 +0900
Michel Dänzer wrote:
> On Mon, 2014-02-24 at 14:11 +0200, Ville Syrjälä wrote:
> > On Mon, Feb 24, 2014 at 12:48:55PM +0900, Michel Dänzer wrote:
> > > On Fre, 2014-02-21 at 21:03 +0200, ville.syrj...@linux.intel.com wrote:
> > > >
> > > > We can kill of the dr
On Fri, 21 Feb 2014 21:03:34 +0200
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> If someone holds a vblank reference across the modeset, and after/during
> the modeset someone tries to grab a vblank reference, the current code
> won't re-enable the vblank interrupts. That's not
On Fri, 21 Feb 2014 21:03:32 +0200
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Currently there's one per-device vblank disable timer, and it gets
> reset wheneven the vblank refcount for any crtc drops to zero. That
> means that one crtc could accidentally be keeping the vblan
On Fri, 21 Feb 2014 21:03:31 +0200
ville.syrj...@linux.intel.com wrote:
> From: Peter Hurley
>
> The irq flags state is already established by the outer
> spin_lock_irqsave(); re-disabling irqs is redundant.
>
> Signed-off-by: Peter Hurley
> ---
> drivers/gpu/drm/drm_irq.c | 6 +++---
> 1 fil
On Thu, 2014-02-20 at 11:58 -0800, Jesse Barnes wrote:
> On Wed, 19 Feb 2014 14:29:44 +0200
> Ville Syrjälä wrote:
>
> > On Tue, Feb 18, 2014 at 12:02:20AM +0200, Imre Deak wrote:
> > > Based on an early draft from Jesse.
> > >
> > > Add support for powering on/off the dynamic power wells on VLV
From: Tvrtko Ursulin
Allow userptr objects to be created and used via libdrm_intel.
At the moment tiling and mapping to GTT aperture is not supported
due hardware limitations across different generations and uncertainty
about its usefulness.
Signed-off-by: Tvrtko Ursulin
---
include/drm/i915_
On Mon, 13 Jan 2014 16:25:21 +0530
akash.g...@intel.com wrote:
> From: Akash Goel
>
> There is a conflict seen when requesting the kernel to reserve
> the physical space used for the stolen area. This is because
> some BIOS are wrapping the stolen area in the root PCI bus, but have
> an off-by-o
From: Tvrtko Ursulin
This patch series replaces the old vmap with the new userptr test case
and also adds a benchmark for the new feature.
Tested against version 20 of the kernel patch.
Tvrtko Ursulin (3):
tests/gem_userptr_blits: Expanded userptr test cases
tests/gem_vmap_blits: Remove obs
From: Tvrtko Ursulin
A set of userptr test cases to support the new feature.
For the eviction and swapping stress testing I have extracted
some common behaviour from gem_evict_everything and made both
test cases use it to avoid duplicating the code.
Both unsynchronized and synchronized userptr
From: Tvrtko Ursulin
No need for the old test case once the new one was added.
Signed-off-by: Tvrtko Ursulin
---
tests/.gitignore | 1 -
tests/Makefile.sources | 1 -
tests/gem_vmap_blits.c | 344 -
3 files changed, 346 deletions(-)
de
On 02/21/2014 06:45 PM, Chris Wilson wrote:
[snip]
v20: Refuse to implement read-only support until we have the required
infrastructure - but reserve the bit in flags for future use.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: "Gong, Zhipeng"
Cc: Akash Goel
Cc: "Volkin, Bradley
From: Tvrtko Ursulin
This adds a small benchmark for the new userptr functionality.
Apart from basic surface creation and destruction, also tested is the
impact of having userptr surfaces in the process address space. Reason
for that is the impact of MMU notifiers on common address space
operati
On Wed, Feb 26, 2014 at 01:32:44PM +, Goel, Akash wrote:
> To expose the panel fitter for arbitrary use by User-space, we will expose
> the manual scaling ratio & Input/Src size info to User, apart from the
> available scaling modes like Full screen, Centered, Aspect.
> Please suggest that h
On Wed, Feb 26, 2014 at 02:57:16PM +0100, Rafael J. Wysocki wrote:
> On Monday, February 24, 2014 05:24:00 PM Borislav Petkov wrote:
> > This started happening this morning after booting -rc4+tip, let's
> > add *everybody* to CC :-)
>
> What about -rc4 without tip?
I don't think so because
commi
On Wed, Feb 26, 2014 at 02:57:16PM +0100, Rafael J. Wysocki wrote:
> On Monday, February 24, 2014 05:24:00 PM Borislav Petkov wrote:
> > This started happening this morning after booting -rc4+tip, let's
> > add *everybody* to CC :-)
>
> What about -rc4 without tip?
The driver causing this is new
On Wed, Feb 26, 2014 at 01:32:44PM +, Goel, Akash wrote:
> To expose the panel fitter for arbitrary use by User-space, we will expose
> the manual scaling ratio & Input/Src size info to User, apart from the
> available scaling modes like Full screen, Centered, Aspect.
You can simply add new
On Monday, February 24, 2014 05:24:00 PM Borislav Petkov wrote:
> This started happening this morning after booting -rc4+tip, let's
> add *everybody* to CC :-)
What about -rc4 without tip?
> We have intel_uncore_init, snb_uncore_imc_init_box, uncore_pci_probe and
> other goodies on the stack.
>
To expose the panel fitter for arbitrary use by User-space, we will expose the
manual scaling ratio & Input/Src size info to User, apart from the available
scaling modes like Full screen, Centered, Aspect.
Please suggest that how shall we extend the current interface to incorporate
these extra
On Tue, Feb 25, 2014 at 01:11:47PM +0200, Jani Nikula wrote:
> i915gm and i945gm also seem to use and need the legacy combination mode
> bit in BLC_PWM_CTL.
>
> v2: Also do this for i915gm (Ville).
>
> Reported-and-tested-by: Luis Ortega
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=7
Can you please, pretty please, not top-post...
On Wed, Feb 26, 2014 at 10:47:05AM +0100, Stephane Eranian wrote:
> Hi,
>
> Ok, so I am getting the same error message as you.
> I checked my syslog now.
>
> I have my uncore_imc addr=0xfed1 (after masking)
>
> And I also have pnp 00:01 overlap
On Wed, Feb 26, 2014 at 07:56:58AM +0100, Stephane Eranian wrote:
> > Also IVB, model 58?
> >
> Yes.
Right, so it must be chipset-specific.
> > Dunno. What do you mean by "pm callbacks" exactly? I don't know that
> > code so I have to ask.
> >
> power management callbacks.
Ok, just as I thought.
24 matches
Mail list logo
