Hi Dave,
[Andrew: Pull contains the patch "drm/fb-helper: don't sleep for screen
unblank when an oopps is in progress" which is also in your tree, hence
the cc.]
I've figured a pull request is easier to handle ;-)
This is the drm fb helper cleanup, mostly motivated by strange things I've
seen in
On Thursday 07 February 2013, Maarten Lankhorst wrote:
Hi Maarten,
I cannot help a lot on this patch set, but there are a few things that
I noticed when reading it.
> Functions:
> --
>
> mutex_reserve_lock, and mutex_reserve_lock_interruptible:
> Lock a buffer with a reservation_id se
https://bugs.freedesktop.org/show_bug.cgi?id=60073
--- Comment #6 from Wojciech Pyczak ---
I'm currently using latest version (cb4616d3) and the issue is gone.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mai
On Thu, Feb 14, 2013 at 11:22 AM, Arnd Bergmann wrote:
>
>> These functions will return -EDEADLK instead of -EAGAIN if
>> reservation_id is the same as the reservation_id that's attempted to
>> lock the mutex with, since in that case you presumably attempted to
>> lock the same lock twice.
The omapdrm driver requires omapdss panel drivers to expose ops like detect,
set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
and SDI drivers. At some places, there are no checks to see if the panel driver
has these ops or not, and that leads to a crash.
The following
On Wed, Feb 13, 2013 at 10:20:21PM +0100, Patrik Jakobsson wrote:
> The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 and
> 5-9.
> Since we do all calculations based on them being register values (which are
> subtracted by 2) we need to specify them accordingly.
>
> Signed-o
Hi Steven,
Since about a year ago we've switched drm/i915 to buffer around 2
weeks worth of patches so that we can do decent QA before breaking
everyone's tree when things land in Dave's drm-next. But that also
means we'll miss out a bit in the integration testing -next provides,
which did hurt a
On 2013-02-13 00:45, Stéphane Marchesin wrote:
> So, a part which is completely omitted in this thread is how to handle
> suspend/resume ordering. If you have multiple encoders which need to
> be turned on/off in a given order at suspend/resume, how do you handle
> that given the current scheme wh
Hi Mr. Lee,
thanks for the review.
On 14 February 2013 07:30, Donghwa Lee wrote:
> On Wed, Feb 13, 2013 at 19:01, Vikas Sajjan wrote:
>>
>> Made necessary changes in s6e8ax0 panel driver as per the CDF-T.
>> It also removes the dependency on backlight and lcd framework
>>
>> Signed-off-by: Vika
From: Prathyush K
If mixer is runtime suspended (by DPMS OFF), mixer_suspend
does not call mixer_poweroff and just returns. Similarily the
mixer_resume should not resume the mixer if mixer is
runtime_suspended. It should be done through DPMS ON.
The existing check is stopping the resume. This is
Hey,
Op 14-02-13 11:22, Arnd Bergmann schreef:
> On Thursday 07 February 2013, Maarten Lankhorst wrote:
>
> Hi Maarten,
>
> I cannot help a lot on this patch set, but there are a few things that
> I noticed when reading it.
>
>> Functions:
>> --
>>
>> mutex_reserve_lock, and mutex_reserve_
On Thu, Feb 14, 2013 at 03:12:02PM +0100, Daniel Vetter wrote:
> Hi Steven,
>
> Since about a year ago we've switched drm/i915 to buffer around 2
> weeks worth of patches so that we can do decent QA before breaking
> everyone's tree when things land in Dave's drm-next. But that also
> means we'll
On Thu, Feb 14, 2013 at 3:28 PM, Steven Rostedt wrote:
> On Thu, 2013-02-14 at 15:19 +0100, Borislav Petkov wrote:
>> On Thu, Feb 14, 2013 at 03:12:02PM +0100, Daniel Vetter wrote:
>> > Hi Steven,
>> >
>> > Since about a year ago we've switched drm/i915 to buffer around 2
>> > weeks worth of patch
https://bugs.freedesktop.org/show_bug.cgi?id=60848
Priority: medium
Bug ID: 60848
Assignee: dri-devel@lists.freedesktop.org
Summary: [bisected] r600g: add htile support cause gpu lockup
in Dishonored wine.
Severity: normal
https://bugs.freedesktop.org/show_bug.cgi?id=60073
Jerome Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=60848
--- Comment #1 from Jerome Glisse ---
Does it happen without --enable-gallium-llvm also does it happen when running
with R600_HTILE=0 env variable ?
--
You are receiving this mail because:
You are the assignee for the bug.
_
On Thu, Feb 14, 2013 at 6:52 AM, Archit Taneja wrote:
> The omapdrm driver requires omapdss panel drivers to expose ops like detect,
> set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
> and SDI drivers. At some places, there are no checks to see if the panel
> driver
On 02/14/2013 01:10 PM, Sedat Dilek wrote:
Hi,
noticed when polishing up my build-scripts fot libdrm | mesa |
xf86-video-intel (last one requires gl.h).
/*
* Mesa 3-D graphics library
* Version: 7.6<--- ???
I could remove that obsolete line.
*
* Copyright (C) 1999-2006 Brian Paul
On Thursday, 14 February 2013, Sylwester Nawrocki <
sylvester.nawro...@gmail.com> wrote:
> On 02/12/2013 06:30 PM, Sachin Kamat wrote:
>>
>> Hi Sylwester,
>>
>> On Wednesday, 6 February 2013, Sachin Kamat
wrote:
>>>
>>> This patch adds device tree based discovery support to G2D driver
>>>
>>> Si
On Thu, 2013-02-14 at 15:19 +0100, Borislav Petkov wrote:
> On Thu, Feb 14, 2013 at 03:12:02PM +0100, Daniel Vetter wrote:
> > Hi Steven,
> >
> > Since about a year ago we've switched drm/i915 to buffer around 2
> > weeks worth of patches so that we can do decent QA before breaking
> > everyone's
Hi,
noticed when polishing up my build-scripts fot libdrm | mesa |
xf86-video-intel (last one requires gl.h).
/*
* Mesa 3-D graphics library
* Version: 7.6 <--- ???
*
* Copyright (C) 1999-2006 Brian Paul All Rights Reserved. <--- ???
* Copyright (C) 2009 VMware, Inc. All Rights Reserve
On Thu, Feb 14, 2013 at 9:26 PM, Brian Paul wrote:
> On 02/14/2013 01:10 PM, Sedat Dilek wrote:
>>
>> Hi,
>>
>> noticed when polishing up my build-scripts fot libdrm | mesa |
>> xf86-video-intel (last one requires gl.h).
>>
>> /*
>> * Mesa 3-D graphics library
>> * Version: 7.6<--- ???
>
>
>
On Wed, Feb 13, 2013 at 10:20:22PM +0100, Patrik Jakobsson wrote:
> The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 and
> 5-9.
> Since we do all calculations based on them being register values (which are
> subtracted by 2) we need to specify them accordingly.
>
> Signed-o
On Thu, Feb 14, 2013 at 08:50:25PM +, Chris Wilson wrote:
> On Wed, Feb 13, 2013 at 10:20:22PM +0100, Patrik Jakobsson wrote:
> > The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 and
> > 5-9.
> > Since we do all calculations based on them being register values (which are
On Fri, Feb 15, 2013 at 6:59 AM, Daniel Vetter wrote:
> On Thu, Feb 14, 2013 at 08:50:25PM +, Chris Wilson wrote:
>> On Wed, Feb 13, 2013 at 10:20:22PM +0100, Patrik Jakobsson wrote:
>> > The Intel PRM says the M1 and M2 divisors must be in the range of 10-20
>> > and 5-9.
>> > Since we do al
On Thu, Feb 14, 2013 at 10:45 PM, Dave Airlie wrote:
> On Fri, Feb 15, 2013 at 6:59 AM, Daniel Vetter wrote:
>> On Thu, Feb 14, 2013 at 08:50:25PM +, Chris Wilson wrote:
>>> On Wed, Feb 13, 2013 at 10:20:22PM +0100, Patrik Jakobsson wrote:
>>> > The Intel PRM says the M1 and M2 divisors must
On 02/14/2013 12:29 PM, Sedat Dilek wrote:
On Thu, Feb 14, 2013 at 9:26 PM, Brian Paul wrote:
On 02/14/2013 01:10 PM, Sedat Dilek wrote:
Hi,
noticed when polishing up my build-scripts fot libdrm | mesa |
xf86-video-intel (last one requires gl.h).
/*
* Mesa 3-D graphics library
* Versi
Hi Daniel,
On Thu, 14 Feb 2013 15:19:53 +0100 Borislav Petkov wrote:
>
> On Thu, Feb 14, 2013 at 03:12:02PM +0100, Daniel Vetter wrote:
> >
> > Since about a year ago we've switched drm/i915 to buffer around 2
> > weeks worth of patches so that we can do decent QA before breaking
> > everyone's
On Wed, Feb 13, 2013 at 10:20:21PM +0100, Patrik Jakobsson wrote:
> The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 and
> 5-9.
> Since we do all calculations based on them being register values (which are
> subtracted by 2) we need to specify them accordingly.
One thing I'
Hi all,
After merging the drm-intel tree, today's linux-next build (x86_64
allmodconfig) failed like this:
ERROR: "pm_vt_switch_unregister" [drivers/video/fb.ko] undefined!
I have dropped the tree for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpbVHZH4ZWzz.pg
2013/2/6 Vikas Sajjan :
> Add support for parsing the display-timing node using video helper
> function.
>
> The DT node parsing and pinctrl selection is done only if 'dev.of_node'
> exists and the NON-DT logic is still maintained under the 'else' part.
>
> Signed-off-by: Leela Krishna Amudala
> S
Hi Dave,
This pull-request includes hdmi mode relevant some improvements,
bug fixes and code cleanups.
The summary:
. Add display mode check operaion to mixer driver
- Mixer IP also can put certain restrictions on the proposed
display modes and these restrictions need to be considered
d
https://bugs.freedesktop.org/show_bug.cgi?id=56659
--- Comment #3 from runetmem...@gmail.com ---
Still reproducible with radeon 7.0.0 and newer git snapshots.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel maili
Hi Mr. Inki Dae,
Thanks for review.
On 15 February 2013 08:50, Inki Dae wrote:
> 2013/2/6 Vikas Sajjan :
>> Add support for parsing the display-timing node using video helper
>> function.
>>
>> The DT node parsing and pinctrl selection is done only if 'dev.of_node'
>> exists and the NON-DT logic
On Wed, Feb 13, 2013 at 01:40:56PM +0100, Daniel Vetter wrote:
> On Tue, Feb 05, 2013 at 01:07:01PM +1000, Dave Airlie wrote:
> > On Tue, Feb 5, 2013 at 12:55 AM, Daniel Vetter wrote:
> > > On Thu, Jan 31, 2013 at 07:43:38PM +0200, ville.syrjala at
> > > linux.intel.com wrote:
> > >> From: Ville
ou are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130214/ba19c43b/attachment.html>
ng this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130214/868197c0/attachment.html>
ceiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130214/e0cdbd34/attachment.html>
On 02/12/2013 06:30 PM, Sachin Kamat wrote:
>
> Hi Sylwester,
>
> On Wednesday, 6 February 2013, Sachin Kamat
> wrote:
>> This patch adds device tree based discovery support to G2D driver
>>
>> Signed-off-by: Sachin Kamat
>> ---
>> Based on for_v3.9 branch of below tree:
>> git://linuxtv.or
On Wed, Feb 13, 2013 at 07:18:33PM +0100, Laurent Pinchart wrote:
> Hi Simon,
>
> On Wednesday 13 February 2013 21:28:20 Simon Horman wrote:
> > On Thu, Jan 31, 2013 at 02:45:02AM +0100, Laurent Pinchart wrote:
> > > The R-Car Display Unit (DU) DRM driver supports both superposition
> > > processo
On Wed, Feb 13, 2013 at 19:01, Vikas Sajjan wrote:
> Made necessary changes in s6e8ax0 panel driver as per the CDF-T.
> It also removes the dependency on backlight and lcd framework
>
> Signed-off-by: Vikas Sajjan
> ---
> drivers/video/exynos/s6e8ax0.c | 848
> +
Hi Dave,
[Andrew: Pull contains the patch "drm/fb-helper: don't sleep for screen
unblank when an oopps is in progress" which is also in your tree, hence
the cc.]
I've figured a pull request is easier to handle ;-)
This is the drm fb helper cleanup, mostly motivated by strange things I've
seen in
On Thursday 07 February 2013, Maarten Lankhorst wrote:
Hi Maarten,
I cannot help a lot on this patch set, but there are a few things that
I noticed when reading it.
> Functions:
> --
>
> mutex_reserve_lock, and mutex_reserve_lock_interruptible:
> Lock a buffer with a reservation_id se
hment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130214/3a272d1b/attachment.html>
On Thu, Feb 14, 2013 at 11:22 AM, Arnd Bergmann wrote:
>
>> These functions will return -EDEADLK instead of -EAGAIN if
>> reservation_id is the same as the reservation_id that's attempted to
>> lock the mutex with, since in that case you presumably attempted to
>> lock the same lock twice.
The omapdrm driver requires omapdss panel drivers to expose ops like detect,
set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
and SDI drivers. At some places, there are no checks to see if the panel driver
has these ops or not, and that leads to a crash.
The following
On Wed, Feb 13, 2013 at 10:20:21PM +0100, Patrik Jakobsson wrote:
> The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 and
> 5-9.
> Since we do all calculations based on them being register values (which are
> subtracted by 2) we need to specify them accordingly.
>
> Signed-o
Hi Steven,
Since about a year ago we've switched drm/i915 to buffer around 2
weeks worth of patches so that we can do decent QA before breaking
everyone's tree when things land in Dave's drm-next. But that also
means we'll miss out a bit in the integration testing -next provides,
which did hurt a
Hey,
Op 14-02-13 11:22, Arnd Bergmann schreef:
> On Thursday 07 February 2013, Maarten Lankhorst wrote:
>
> Hi Maarten,
>
> I cannot help a lot on this patch set, but there are a few things that
> I noticed when reading it.
>
>> Functions:
>> --
>>
>> mutex_reserve_lock, and mutex_reserve_
application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130214/51e11dab/attachment.pgp>
Hi Mr. Lee,
thanks for the review.
On 14 February 2013 07:30, Donghwa Lee wrote:
> On Wed, Feb 13, 2013 at 19:01, Vikas Sajjan wrote:
>>
>> Made necessary changes in s6e8ax0 panel driver as per the CDF-T.
>> It also removes the dependency on backlight and lcd framework
>>
>> Signed-off-by: Vika
From: Prathyush K
If mixer is runtime suspended (by DPMS OFF), mixer_suspend
does not call mixer_poweroff and just returns. Similarily the
mixer_resume should not resume the mixer if mixer is
runtime_suspended. It should be done through DPMS ON.
The existing check is stopping the resume. This is
On Thu, Feb 14, 2013 at 03:12:02PM +0100, Daniel Vetter wrote:
> Hi Steven,
>
> Since about a year ago we've switched drm/i915 to buffer around 2
> weeks worth of patches so that we can do decent QA before breaking
> everyone's tree when things land in Dave's drm-next. But that also
> means we'll
On Thu, Feb 14, 2013 at 3:28 PM, Steven Rostedt wrote:
> On Thu, 2013-02-14 at 15:19 +0100, Borislav Petkov wrote:
>> On Thu, Feb 14, 2013 at 03:12:02PM +0100, Daniel Vetter wrote:
>> > Hi Steven,
>> >
>> > Since about a year ago we've switched drm/i915 to buffer around 2
>> > weeks worth of patch
receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130214/469148da/attachment-0001.html>
nts/20130214/cd70692a/attachment.html>
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130214/beab3727/attachment.html>
On Thu, Feb 14, 2013 at 6:52 AM, Archit Taneja wrote:
> The omapdrm driver requires omapdss panel drivers to expose ops like detect,
> set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
> and SDI drivers. At some places, there are no checks to see if the panel
> driver
On 02/14/2013 01:10 PM, Sedat Dilek wrote:
> Hi,
>
> noticed when polishing up my build-scripts fot libdrm | mesa |
> xf86-video-intel (last one requires gl.h).
>
> /*
> * Mesa 3-D graphics library
> * Version: 7.6<--- ???
I could remove that obsolete line.
> *
> * Copyright (C) 1999-20
> e.g. { "sclk", "gate" }. This could simplify a bit subsystems like
devfreq.
Yes. That makes sense.
>
> Also I noticed there are some issues caused by splitting mux + div + gate
> clocks into 3 different clocks. One solution to this might be to use the
> new composite clock type.
Ok.
>
> [1] http://www.spinics.net/lists/arm-kernel/msg214149.html
>
--
With warm regards,
Sachin
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130214/446beb86/attachment.html>
On Thu, 2013-02-14 at 15:19 +0100, Borislav Petkov wrote:
> On Thu, Feb 14, 2013 at 03:12:02PM +0100, Daniel Vetter wrote:
> > Hi Steven,
> >
> > Since about a year ago we've switched drm/i915 to buffer around 2
> > weeks worth of patches so that we can do decent QA before breaking
> > everyone's
Hi,
noticed when polishing up my build-scripts fot libdrm | mesa |
xf86-video-intel (last one requires gl.h).
/*
* Mesa 3-D graphics library
* Version: 7.6 <--- ???
*
* Copyright (C) 1999-2006 Brian Paul All Rights Reserved. <--- ???
* Copyright (C) 2009 VMware, Inc. All Rights Reserve
On Thu, Feb 14, 2013 at 9:26 PM, Brian Paul wrote:
> On 02/14/2013 01:10 PM, Sedat Dilek wrote:
>>
>> Hi,
>>
>> noticed when polishing up my build-scripts fot libdrm | mesa |
>> xf86-video-intel (last one requires gl.h).
>>
>> /*
>> * Mesa 3-D graphics library
>> * Version: 7.6<--- ???
>
>
>
On Wed, Feb 13, 2013 at 10:20:22PM +0100, Patrik Jakobsson wrote:
> The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 and
> 5-9.
> Since we do all calculations based on them being register values (which are
> subtracted by 2) we need to specify them accordingly.
>
> Signed-o
On Thu, Feb 14, 2013 at 08:50:25PM +, Chris Wilson wrote:
> On Wed, Feb 13, 2013 at 10:20:22PM +0100, Patrik Jakobsson wrote:
> > The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 and
> > 5-9.
> > Since we do all calculations based on them being register values (which are
On Thu, Feb 14, 2013 at 10:45 PM, Dave Airlie wrote:
> On Fri, Feb 15, 2013 at 6:59 AM, Daniel Vetter wrote:
>> On Thu, Feb 14, 2013 at 08:50:25PM +, Chris Wilson wrote:
>>> On Wed, Feb 13, 2013 at 10:20:22PM +0100, Patrik Jakobsson wrote:
>>> > The Intel PRM says the M1 and M2 divisors must
On 02/14/2013 12:29 PM, Sedat Dilek wrote:
> On Thu, Feb 14, 2013 at 9:26 PM, Brian Paul wrote:
>> On 02/14/2013 01:10 PM, Sedat Dilek wrote:
>>>
>>> Hi,
>>>
>>> noticed when polishing up my build-scripts fot libdrm | mesa |
>>> xf86-video-intel (last one requires gl.h).
>>>
>>> /*
>>>* Mesa 3
67 matches
Mail list logo
