-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/03/2015 06:46 PM, Thierry Reding wrote:
> On Wed, Jan 21, 2015 at 04:48:12PM +0530, Shobhit Kumar wrote:
>> This driver provides support for the "crystal_cove_panel" cell
>> device. On BYT-T pmic has to be used to enable/disable panel.
>>
>> v2:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/03/2015 06:35 PM, Thierry Reding wrote:
> On Wed, Jan 21, 2015 at 04:48:11PM +0530, Shobhit Kumar wrote:
>> On BYT-T configuration, panel enable/disable signals are routed
>> through PMIC. Add a cell device for the same.
>>
>> Signed-off-by: Sho
Good catch!
Reviewed-by: Rodrigo Vivi
On Thu, Jan 29, 2015 at 6:13 AM, Damien Lespiau
wrote:
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/intel_ringbuffer.c | 8 +---
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
On Thu, Jan 29, 2015 at 6:13 AM, Damien Lespiau
wrote:
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/i915_drv.c | 19 +--
> 1 file changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 6
On Thu, Jan 29, 2015 at 6:13 AM, Damien Lespiau
wrote:
> We need to have a separate GT3 struct intel_device_info to declare they
> have a second VCS. Let's start by splitting the PCI ids per-GT.
>
> Signed-off-by: Damien Lespiau
> ---
> include/drm/i915_pciids.h | 28 +++-
plane->state->fb and plane->fb should always reference the same FB so
that atomic and legacy codepaths have the same view of display state.
In commit
commit db068420560511de80ac59222644f2bdf278c3d5
Author: Matt Roper
Date: Fri Jan 30 16:22:36 2015 -0800
drm/
On Tue, Feb 03, 2015 at 08:13:56PM +0100, Michał Winiarski wrote:
> It was possible for invalidate range start mmu notifier callback to race
> with releasing userptr object. If the object is released prior to
> taking a spinlock in the callback, we'll encounter a null pointer
> dereference.
>
> v2
On Tue, Feb 03, 2015 at 10:15:47PM +0300, Andrey Skvortsov wrote:
> Hi,
>
> tested next-20150202. System boots, but graphic output is broken (empty black
> screen).
> Booted five times the same kernel, always got the same result. The system
> works with 3.19-rc7.
Those two warnings are more or
On Tue, Feb 03, 2015 at 05:22:31PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Start using frame buffer modifiers instead of object tiling mode
> for display purposes.
>
> To ensure compatibility with old userspace which is using set_tiling
> and does not know about frame buffer modi
On Tue, Feb 3, 2015 at 8:24 PM, Chris Wilson wrote:
> On Tue, Feb 03, 2015 at 07:57:34PM +0100, Sedat Dilek wrote:
>> Ping?
>
> It's upstream and enabled by default for kernel v3.20+.
>
Thanks, I have looked into Linux-next (next-20150203) and se
On Mon, Feb 02, 2015 at 04:00:51PM +0100, Michal Hocko wrote:
> From: Michal Hocko
> Date: Mon, 2 Feb 2015 15:22:19 +0100
> Subject: [PATCH] memcg, shmem: fix shmem migration to use lrucare.
>
> It has been reported that 965GM might trigger
>
> VM_BUG_ON_PAGE(!lrucare && PageLRU(oldpage), oldpag
Dear Developers/Support!
I can't configure the 2nd or 3rd display on my Dell Latitude e5540
notebook and Dell NB Port Replicator.
I tried to connect DVI, DP and VGA to Port Replicator and it is
working only in mirror mode.
The only way to use 2 external display if I connect the DVI or DP to
Port R
A FreeBSD developer discovered that intel_fbc_enabled has a
declaration in two headers:
sys/dev/drm2/i915/i915_drv.h:extern bool intel_fbc_enabled(struct
drm_device *dev);
sys/dev/drm2/i915/intel_drv.h:extern bool intel_fbc_enabled(struct
drm_device *dev);
We have a slightly older version of the
On Tue, Feb 03, 2015 at 10:46:49AM -0800, Rodrigo Vivi wrote:
> On Tue, Feb 3, 2015 at 8:21 AM, Matt Roper wrote:
> > On Tue, Feb 03, 2015 at 12:57:31PM +0100, Daniel Vetter wrote:
> >> On Mon, Feb 02, 2015 at 03:38:16PM -0800, Rodrigo Vivi wrote:
> >> > frontbuffer bits must be updated during com
On Tue, Feb 03, 2015 at 11:14:10AM -0800, Matt Roper wrote:
> On Tue, Feb 03, 2015 at 10:46:49AM -0800, Rodrigo Vivi wrote:
> > On Tue, Feb 3, 2015 at 8:21 AM, Matt Roper
> > wrote:
> > > On Tue, Feb 03, 2015 at 12:57:31PM +0100, Daniel Vetter wrote:
> > >> On Mon, Feb 02, 2015 at 03:38:16PM -080
On Tue, Feb 03, 2015 at 08:21:33AM -0800, Matt Roper wrote:
> On Tue, Feb 03, 2015 at 12:57:31PM +0100, Daniel Vetter wrote:
> > On Mon, Feb 02, 2015 at 03:38:16PM -0800, Rodrigo Vivi wrote:
> > > frontbuffer bits must be updated during commit times not on atomica
> > > prepare
> > > one, otherwis
On Tue, Feb 03, 2015 at 07:57:34PM +0100, Sedat Dilek wrote:
> Ping?
It's upstream and enabled by default for kernel v3.20+.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://l
On Tue, Feb 03, 2015 at 07:40:21PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 03, 2015 at 04:11:05PM +, Siluvery, Arun wrote:
> > On 01/08/2014 17:34, Jesse Barnes wrote:
> > > On Thu, 31 Jul 2014 12:08:20 -0700
> > > Rodrigo Vivi wrote:
> > >
> > >> WA to skip the first page of stolen memory d
Hi,
tested next-20150202. System boots, but graphic output is broken (empty black
screen).
Booted five times the same kernel, always got the same result. The system works
with 3.19-rc7.
This is the first warning in the log:
WARNING: CPU: 0 PID: 855 at drivers/gpu/drm/i915/intel_uncore.c:169
It was possible for invalidate range start mmu notifier callback to race
with releasing userptr object. If the object is released prior to
taking a spinlock in the callback, we'll encounter a null pointer
dereference.
v2: Moved expressions inside igt_assert(), added mem barrier (Chris)
Cc: Chris
On Tue, Feb 03, 2015 at 10:46:49AM -0800, Rodrigo Vivi wrote:
> On Tue, Feb 3, 2015 at 8:21 AM, Matt Roper wrote:
> > On Tue, Feb 03, 2015 at 12:57:31PM +0100, Daniel Vetter wrote:
> >> On Mon, Feb 02, 2015 at 03:38:16PM -0800, Rodrigo Vivi wrote:
> >> > frontbuffer bits must be updated during com
Ping?
- Sedat -
On Fri, Nov 14, 2014 at 11:04 AM, Daniel Vetter wrote:
> On Thu, Nov 13, 2014 at 04:28:46PM +0100, Sedat Dilek wrote:
>> Hi,
>>
>> what is the status of drm-intel-wc-mmap patchset (#2 + #3)?
>> I have refreshed them on top of drm-intel-coherent-phys-gtt patch (#1).
>> Playing wit
On Tue, Feb 3, 2015 at 8:21 AM, Matt Roper wrote:
> On Tue, Feb 03, 2015 at 12:57:31PM +0100, Daniel Vetter wrote:
>> On Mon, Feb 02, 2015 at 03:38:16PM -0800, Rodrigo Vivi wrote:
>> > frontbuffer bits must be updated during commit times not on atomica prepare
>> > one, otherwise we have a risk of
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5706
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -5 283/283
On Tue, Feb 03, 2015 at 04:11:05PM +, Siluvery, Arun wrote:
> On 01/08/2014 17:34, Jesse Barnes wrote:
> > On Thu, 31 Jul 2014 12:08:20 -0700
> > Rodrigo Vivi wrote:
> >
> >> WA to skip the first page of stolen memory due to sporadic HW write on *CS
> >> Idle
> >>
> >> v2: Improve variable na
From: Tvrtko Ursulin
Start using frame buffer modifiers instead of object tiling mode
for display purposes.
To ensure compatibility with old userspace which is using set_tiling
and does not know about frame buffer modifiers, the latter are faked
internally when tile object is set for display. Th
From: Tvrtko Ursulin
Instead of using driver private set tiling ioctl, use the proposed addfb2 ioctl
extension to tell the driver about display buffer special formatting.
Lightly tested only with a hacked up igt/testdisplay.
v2:
* Refactor the series to use fb->modifier[0] directly at call s
From: Rob Clark
In DRM/KMS we are lacking a good way to deal with tiled/compressed
formats. Especially in the case of dmabuf/prime buffer sharing, where
we cannot always rely on under-the-hood flags passed to driver specific
gem-create ioctl to pass around these extra flags.
The proposal is to
From: Tvrtko Ursulin
To be used from the new addfb2 extension.
Signed-off-by: Tvrtko Ursulin
---
include/uapi/drm/i915_drm.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 6eed16b..a7327fd 100644
--- a/include/
From: Tvrtko Ursulin
Let the DRM core know we can handle it.
v2: Change to boolean true. (Daniel Vetter)
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/in
On Tue, Feb 03, 2015 at 12:57:31PM +0100, Daniel Vetter wrote:
> On Mon, Feb 02, 2015 at 03:38:16PM -0800, Rodrigo Vivi wrote:
> > frontbuffer bits must be updated during commit times not on atomica prepare
> > one, otherwise we have a risk of false positive.
> >
> > Cc Daniel Vetter
> > Cc: Sonik
On 01/08/2014 17:34, Jesse Barnes wrote:
On Thu, 31 Jul 2014 12:08:20 -0700
Rodrigo Vivi wrote:
WA to skip the first page of stolen memory due to sporadic HW write on *CS Idle
v2: Improve variable names and fix allocated size.
Reviewed-by: Ben Widawsky
Signed-off-by: Rodrigo Vivi
---
dri
On Tue, Feb 03, 2015 at 03:08:17PM +, Chris Wilson wrote:
> On Tue, Feb 03, 2015 at 03:48:17PM +0100, Michał Winiarski wrote:
> > It's possible for invalidate_range_start mmu notifier callback to race
> > against userptr object release. If the gem object was released prior to
> > obtaining the
On Tue, Feb 03, 2015 at 03:01:38PM +, Chris Wilson wrote:
> On Tue, Feb 03, 2015 at 03:39:17PM +0100, Michał Winiarski wrote:
> > It was possible for invalidate range start mmu notifier callback to race
> > with releasing userptr object. If the object is released prior to
> > taking a spinlock
On Tue, Feb 03, 2015 at 04:40:42PM +0200, Jani Nikula wrote:
> On Tue, 03 Feb 2015, Shobhit Kumar wrote:
> > This isuue got introduced in -
> >
> > commit 24ee0e64909bf7f1953d87d3e1e29d93eafcad73
> > Author: Gaurav K Singh
> > Date: Fri Dec 5 14:24:21 2014 +0530
> >
> > drm/i915: Update the
On Tue, Feb 03, 2015 at 04:33:51PM +0200, Jani Nikula wrote:
> On Tue, 03 Feb 2015, Matt Roper wrote:
> > As of kernel commit
> >
> > commit a679064a7e9e8799177a64a31668a34a1bc6a4f1
> > Author: Matt Roper
> > Date: Fri Jan 30 16:22:37 2015 -0800
> >
> > drm/i915: Switch plan
On Fri, Jan 30, 2015 at 05:08:23PM +0100, Daniel Vetter wrote:
> From: Rob Clark
>
> In DRM/KMS we are lacking a good way to deal with tiled/compressed
> formats. Especially in the case of dmabuf/prime buffer sharing, where
> we cannot always rely on under-the-hood flags passed to driver specifi
On Tue, Feb 03, 2015 at 03:48:17PM +0100, Michał Winiarski wrote:
> It's possible for invalidate_range_start mmu notifier callback to race
> against userptr object release. If the gem object was released prior to
> obtaining the spinlock in invalidate_range_start we're hitting null
> pointer derefe
On Tue, 03 Feb 2015, William Hua wrote:
> The downstream Ubuntu bug report is
> https://bugs.launchpad.net/mir/+bug/1409133.
And the upstream one is at
https://bugs.freedesktop.org/show_bug.cgi?id=88944
--
Jani Nikula, Intel Open Source Technology Center
___
On Tue, Feb 03, 2015 at 03:39:17PM +0100, Michał Winiarski wrote:
> It was possible for invalidate range start mmu notifier callback to race
> with releasing userptr object. If the object is released prior to
> taking a spinlock in the callback, we'll encounter a null pointer
> dereference.
>
> Cc
It's possible for invalidate_range_start mmu notifier callback to race
against userptr object release. If the gem object was released prior to
obtaining the spinlock in invalidate_range_start we're hitting null
pointer dereference.
Testcase: igt/gem_userptr_blits/stress-mm-invalidate-close
Testcas
It was possible for invalidate range start mmu notifier callback to race
with releasing userptr object. If the object is released prior to
taking a spinlock in the callback, we'll encounter a null pointer
dereference.
Cc: Chris Wilson
Signed-off-by: Michał Winiarski
---
tests/gem_userptr_blits.
On Tue, 03 Feb 2015, Shobhit Kumar wrote:
> This isuue got introduced in -
>
> commit 24ee0e64909bf7f1953d87d3e1e29d93eafcad73
> Author: Gaurav K Singh
> Date: Fri Dec 5 14:24:21 2014 +0530
>
> drm/i915: Update the DSI enable path to support dual
>
> Signed-off-by: Shobhit Kumar
Reviewed-
On Tue, 03 Feb 2015, Matt Roper wrote:
> As of kernel commit
>
> commit a679064a7e9e8799177a64a31668a34a1bc6a4f1
> Author: Matt Roper
> Date: Fri Jan 30 16:22:37 2015 -0800
>
> drm/i915: Switch planes from transitional helpers to full atomic
> helpers
>
> the kernel now che
At the moment we compare the whole EDRAM_PRESENT/EDRAMCAP register value
to 1 while EDRAM_PRESENT is only bit 0 (the rest may be used to describe
eDRAM capabilities).
To be more future proof, only look at bit 0 to detect eDRAM presence.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i91
Suggested-by: Daniel Vetter
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_uncore.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 00c91be..d67346c 100644
--- a/drivers/gpu/drm/i
On Tue, Feb 03, 2015 at 01:36:50PM +, Chris Wilson wrote:
> On Mon, Feb 02, 2015 at 07:09:50PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Replace the valleyview_set_rps() and gen6_set_rps() calls with
> > intel_set_rps() which itself does the IS_VALLEYVIEW() c
Chris Wilson writes:
> On Mon, Feb 02, 2015 at 10:38:19AM +0100, Daniel Vetter wrote:
>> On Mon, Feb 02, 2015 at 09:17:14AM +, Chris Wilson wrote:
>> > On Wed, Jan 28, 2015 at 05:03:14PM +0200, Mika Kuoppala wrote:
>> > > @@ -2616,6 +2612,9 @@ void i915_handle_error(struct drm_device *dev,
>
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5702
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 283/283
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5702
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 283/283
On Tue, Feb 03, 2015 at 01:36:00PM +, Damien Lespiau wrote:
> On Tue, Feb 03, 2015 at 02:34:05PM +0200, Jani Nikula wrote:
> > Spell all the PCI IDs out to be able to quickly grep for the IDs. No
> > functional changes.
> >
> > Signed-off-by: Jani Nikula
> >
> > ---
> >
> > I tested this by
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[1.] One line summary of the problem:
Switching from an X VT to a Mir VT with Intel graphics causes heavy
black flickering.
[2.] Full description of the problem/report:
This is a regression caused by
https://git.kernel.org/cgit/linux/kernel/git/to
On Mon, Feb 02, 2015 at 07:09:50PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Replace the valleyview_set_rps() and gen6_set_rps() calls with
> intel_set_rps() which itself does the IS_VALLEYVIEW() check. The
> code becomes simpler since the callers don't have to do this
On Tue, Feb 03, 2015 at 02:34:05PM +0200, Jani Nikula wrote:
> Spell all the PCI IDs out to be able to quickly grep for the IDs. No
> functional changes.
>
> Signed-off-by: Jani Nikula
>
> ---
>
> I tested this by comparing the results of
>
> $ make drivers/gpu/drm/i915/i915_drv.s
> $ make arc
On Wed, Jan 21, 2015 at 04:48:12PM +0530, Shobhit Kumar wrote:
> This driver provides support for the "crystal_cove_panel" cell device.
> On BYT-T pmic has to be used to enable/disable panel.
>
> v2: Addressed Jani's comments
> - Moved inside i915
> - Correct licensing
> - Remove unuse
On Tue, Feb 03, 2015 at 03:05:05PM +0200, Jani Nikula wrote:
> On Tue, 03 Feb 2015, Chris Wilson wrote:
> > On Tue, Feb 03, 2015 at 02:34:05PM +0200, Jani Nikula wrote:
> >> Spell all the PCI IDs out to be able to quickly grep for the IDs. No
> >> functional changes.
> >
> > On the other hand this
On Wed, Jan 21, 2015 at 04:48:11PM +0530, Shobhit Kumar wrote:
> On BYT-T configuration, panel enable/disable signals are routed through
> PMIC. Add a cell device for the same.
>
> Signed-off-by: Shobhit Kumar
> ---
> drivers/mfd/intel_soc_pmic_crc.c | 3 +++
> 1 file changed, 3 insertions(+)
>
On Tue, 03 Feb 2015, Chris Wilson wrote:
> On Tue, Feb 03, 2015 at 02:34:05PM +0200, Jani Nikula wrote:
>> Spell all the PCI IDs out to be able to quickly grep for the IDs. No
>> functional changes.
>
> On the other hand this is a loss of contextual information in the header
> file.
I assume the
On Wed, Jan 21, 2015 at 04:48:10PM +0530, Shobhit Kumar wrote:
> For scenarios where OF is not available, we can use panel identification by
> name.
>
> Signed-off-by: Shobhit Kumar
> ---
> drivers/gpu/drm/drm_panel.c | 18 ++
> include/drm/drm_panel.h | 3 +++
> 2 files cha
On Tue, 03 Feb 2015, Mika Kuoppala wrote:
> If we bail out from handling the error, we never wake up
> the waiters, resulting in a stuck processes.
>
> This regression was introduced in:
>
> commit b8d24a06568368076ebd5a858a011699a97bfa42
> Author: Mika Kuoppala
> Date: Wed Jan 28 17:03:14 2015
On Tue, Feb 03, 2015 at 02:34:05PM +0200, Jani Nikula wrote:
> Spell all the PCI IDs out to be able to quickly grep for the IDs. No
> functional changes.
On the other hand this is a loss of contextual information in the header
file.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Spell all the PCI IDs out to be able to quickly grep for the IDs. No
functional changes.
Signed-off-by: Jani Nikula
---
I tested this by comparing the results of
$ make drivers/gpu/drm/i915/i915_drv.s
$ make arch/x86/kernel/early-quirks.s
before and after the patch. No change.
---
include/dr
On Tue, Feb 03, 2015 at 02:27:25PM +0200, Mika Kuoppala wrote:
> If we bail out from handling the error, we never wake up
> the waiters, resulting in a stuck processes.
>
> This regression was introduced in:
>
> commit b8d24a06568368076ebd5a858a011699a97bfa42
> Author: Mika Kuoppala
> Date: We
If we bail out from handling the error, we never wake up
the waiters, resulting in a stuck processes.
This regression was introduced in:
commit b8d24a06568368076ebd5a858a011699a97bfa42
Author: Mika Kuoppala
Date: Wed Jan 28 17:03:14 2015 +0200
drm/i915: Remove nested work in gpu error han
On Wed, 28 Jan 2015, shuang...@intel.com wrote:
> Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
> shuang...@intel.com)
> Task id: 5645
> -Summary-
> Platform Delta drm-intel-nightly S
On Mon, Feb 02, 2015 at 03:44:15PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Daniel Vetter spotted a bug while reviewing some of my refactoring in this
> are of the code. I'll quote:
>
> """
> > @@ -9764,6 +9768,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
> > wo
On Mon, Feb 02, 2015 at 03:38:16PM -0800, Rodrigo Vivi wrote:
> frontbuffer bits must be updated during commit times not on atomica prepare
> one, otherwise we have a risk of false positive.
>
> Cc Daniel Vetter
> Cc: Sonika Jindal
> Signed-off-by: Rodrigo Vivi
atomic.fb_bits isn't used at all
On Tue, Feb 03, 2015 at 01:31:34PM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> Thank you for the patch.
>
> On Tuesday 03 February 2015 11:30:11 Daniel Vetter wrote:
> > At driver load we need to tell the vblank code about the state of the
> > pipes, so that the logic around reject vblank_get
On Tue, Feb 03, 2015 at 10:41:49AM +, Tvrtko Ursulin wrote:
>
> On 02/02/2015 08:17 PM, Daniel Vetter wrote:
> >On Mon, Feb 02, 2015 at 05:30:36PM +, Tvrtko Ursulin wrote:
> >>
> >>On 02/02/2015 05:15 PM, Daniel Vetter wrote:
> >>>On Mon, Feb 02, 2015 at 10:36:30AM +, Tvrtko Ursulin wr
Hi Daniel,
Thank you for the patch.
On Tuesday 03 February 2015 11:30:11 Daniel Vetter wrote:
> At driver load we need to tell the vblank code about the state of the
> pipes, so that the logic around reject vblank_get when the pipe is off
> works correctly.
>
> Thus far i915 used drm_vblank_off,
On Tue, Feb 03, 2015 at 12:14:18PM +0100, Daniel Vetter wrote:
> On Tue, Feb 03, 2015 at 11:00:56AM +, Chris Wilson wrote:
> > On Tue, Feb 03, 2015 at 11:49:00AM +0100, Daniel Vetter wrote:
> > > You can _never_ assert that a lock is not held, except in some very
> > > restricted corner cases w
On Tue, Feb 03, 2015 at 11:00:56AM +, Chris Wilson wrote:
> On Tue, Feb 03, 2015 at 11:49:00AM +0100, Daniel Vetter wrote:
> > You can _never_ assert that a lock is not held, except in some very
> > restricted corner cases where it's guranteed that your code is running
> > single-threade (e.g.
On Tue, Feb 03, 2015 at 10:50:27AM +, Chris Wilson wrote:
> On Tue, Feb 03, 2015 at 11:49:00AM +0100, Daniel Vetter wrote:
> > Aside: It is possible to check whether a given task doesn't hold a
> > lock, but only when lockdep is enabled, using the lockdep_assert_held
> > stuff.
>
> Bah. That's
On Tue, Feb 03, 2015 at 11:49:00AM +0100, Daniel Vetter wrote:
> You can _never_ assert that a lock is not held, except in some very
> restricted corner cases where it's guranteed that your code is running
> single-threade (e.g. driver load before you've published any pointers
> leading to that loc
UMS is no more!
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 36 +++-
1 file changed, 11 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 80f35dcffea4..37189a25ca82 100644
--
At driver load we need to tell the vblank code about the state of the
pipes, so that the logic around reject vblank_get when the pipe is off
works correctly.
Thus far i915 used drm_vblank_off, but one of the side-effects of it
is that it also saves the vblank counter. And for that it calls down
in
Where possible right now. Just a small step towards nirvana ...
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 9 +
drivers/gpu/drm/i915/intel_sprite.c | 4 ++--
3 files changed, 8 insertions(+), 7 deletions(-)
diff
With Ville's rework to use drm_crtc_vblank_on/off the core will take
care of rejecting drm_vblank_get calls when the pipe is off. Also the
core won't call the get_vblank_counter hooks in that case either. And
since we've dropped ums support recently we can now remove these
hacks, yay!
Noticed whil
On Tue, Feb 03, 2015 at 11:49:00AM +0100, Daniel Vetter wrote:
> Aside: It is possible to check whether a given task doesn't hold a
> lock, but only when lockdep is enabled, using the lockdep_assert_held
> stuff.
Bah. That's what I said, but a certain Daniel insists on using WARN_ON().
-Chris
--
You can _never_ assert that a lock is not held, except in some very
restricted corner cases where it's guranteed that your code is running
single-threade (e.g. driver load before you've published any pointers
leading to that lock).
In addition the early return breaks a bunch of testcases since wit
On 02/02/2015 08:17 PM, Daniel Vetter wrote:
On Mon, Feb 02, 2015 at 05:30:36PM +, Tvrtko Ursulin wrote:
On 02/02/2015 05:15 PM, Daniel Vetter wrote:
On Mon, Feb 02, 2015 at 10:36:30AM +, Tvrtko Ursulin wrote:
On 02/02/2015 09:54 AM, Daniel Vetter wrote:
On Fri, Jan 30, 2015 at 05:
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5700
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 283/283
On 28/01/15 12:54, Sumit Semwal wrote:
> At present, dma_buf_export() takes a series of parameters, which
> makes it difficult to add any new parameters for exporters, if required.
>
> Make it simpler by moving all these parameters into a struct, and pass
> the struct * as parameter to dma_buf_exp
83 matches
Mail list logo
