For now, it just contains the hack for cirrusfb on Amiga, which is moved
out of with some slight modifications (use raw_*() instead of
z_*(), which are defined on all m68k platforms).
This makes it safe to include in all contexts. Before it
could fail to compile with
include/video/vga.h: In fun
Hi Tomasz,
Thanks for the patch.
On Wednesday 18 April 2012 11:44:59 Tomasz Stanislawski wrote:
> This patch adds a new constructor for an sg table. The table is constructed
> from an array of struct pages. All contiguous chunks of the pages are merged
> into a single sg nodes. A user may provide
David & co, any ideas?
There are other reports of problems with 3.3.x kernels, there's a
report from Tim which may be related (also
apparently working in 3.2, broken black screen in all 3.3.x).
Nick, I realize you had trouble with a bisection already, but it might
really be worth trying again. D
David & co, any ideas?
There are other reports of problems with 3.3.x kernels, there's a
report from Tim which may be related (also
apparently working in 3.2, broken black screen in all 3.3.x).
Nick, I realize you had trouble with a bisection already, but it might
really be worth trying again. D
On 21.04.2012 19:30, Jerome Glisse wrote:
> 2012/4/21 Christian K?nig:
>> On 21.04.2012 17:57, Dave Airlie wrote:
>>> 2012/4/21 Jerome Glisse:
2012/4/21 Christian K?nig:
> On 21.04.2012 16:08, Jerome Glisse wrote:
>> 2012/4/21 Christian K?nig:
>>> Interesting, I'm pretty sure that
On sobota, 21 kwietnia 2012 o 15:13:52 Daniel Vetter wrote:
> On Sat, Apr 21, 2012 at 03:03:07PM +0200, Daniel Vetter wrote:
> > On Sat, Apr 21, 2012 at 07:39:08AM +0200, Maciej Rutecki wrote:
> > > Bad kernel: 3.4-rc3
> > > Last known good: 3.3
> > >
> > > Subsystem: dri-intel (guess)
> > >
> >
Hi Tomasz,
Thanks for the patch.
On Friday 20 April 2012 16:45:29 Tomasz Stanislawski wrote:
> From: Andrzej Pietrasiewicz
>
> This patch introduces usage of dma_map_sg to map memory behind
> a userspace pointer to a device as dma-contiguous mapping.
>
> Signed-off-by: Andrzej Pietrasiewicz
>
Hi R?mi,
On Friday 20 April 2012 15:03:17 R?mi Denis-Courmont wrote:
> On Fri, 20 Apr 2012 14:25:01 +0200, Tomasz Stanislawski wrote:
> >>> The USERPTR simplifies userspace code but introduce
> >>> a lot of complexity problems for the kernel drivers
> >>> and frameworks.
> >>
> >> It is not only
On 21.04.2012 17:57, Dave Airlie wrote:
> 2012/4/21 Jerome Glisse:
>> 2012/4/21 Christian K?nig:
>>> On 21.04.2012 16:08, Jerome Glisse wrote:
2012/4/21 Christian K?nig:
> Interesting, I'm pretty sure that I haven't touched the locking order of
> the
> cs_mutex vs. vm_mutex.
>
Resolving deadlock problems with the cs_mutex.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h|2 +-
drivers/gpu/drm/radeon/radeon_device.c |1 +
drivers/gpu/drm/radeon/radeon_gart.c | 25 +
3 files changed, 11 insertions(+), 17 dele
From: Paulo Zanoni
In the future we'll have more than just connector properties, so create
a dump_prop function that can handle any property (instead of the
current dump_props function that only handles connector properties).
Also, make this function print a lot more information about the existi
From: Paulo Zanoni
24 (16 direct, 8 indirect) bytes in 1 blocks are definitely lost in loss record
2 of 7
at 0x402994D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4A25950: drmMalloc (xf86drm.c:147)
by 0x4A2E26D: drmModeGetPlaneResources (xf86drmMode.c:951)
b
From: Paulo Zanoni
Don't "continue" without freeing the connector.
192 bytes in 6 blocks are indirectly lost in loss record 6 of 12
at 0x4C2779D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4E30DD8: drmMalloc (xf86drm.c:147)
by 0x4E35024: drmAllocCpy (xf86drmMod
From: Paulo Zanoni
Use unsigned int instead of int:
- modetest.c:90:1: warning: comparison between signed and unsigned integer
expressions [-Wsign-compare]
- modetest.c:98:1: warning: comparison between signed and unsigned integer
expressions [-Wsign-compare]
- modetest.c:118:1: warning: compar
2012/3/29 Eugeni Dodonov :
> On Thu, Mar 29, 2012 at 18:28, Paulo Zanoni wrote:
>
>
> I don't know if it should go into a separate patch though. But it is aligned
> to the other formatting patterns you do, and it certainly looks nicer this
> way, and it shouldn't break anything anyway. So I am fi
2012/3/29 Eugeni Dodonov :
> I wonder if we could drop the dead^W#ifd 0'ed code here as well, perhaps
> with a separate patch? I don't think it will get used again in the future
> (but I might be wrong).
>
Removing #if 0'ed code won't fix compiler warnings, so if we do this,
it should
be done in a
2012/4/21 Jerome Glisse :
> 2012/4/21 Christian K?nig :
>> On 21.04.2012 16:08, Jerome Glisse wrote:
>>>
>>> 2012/4/21 Christian K?nig:
Interesting, I'm pretty sure that I haven't touched the locking order of
the
cs_mutex vs. vm_mutex.
Maybe it is just some kind of sid
On 21.04.2012 16:08, Jerome Glisse wrote:
> 2012/4/21 Christian K?nig:
>> Interesting, I'm pretty sure that I haven't touched the locking order of the
>> cs_mutex vs. vm_mutex.
>>
>> Maybe it is just some kind of side effect, going to locking into it anyway.
>>
>> Christian.
>>
> It's the using, in
On Sat, 2012-04-21 at 14:54 +0200, Daniel Vetter wrote:
> Please file a bug report with the error state attach (the
> entire thing), complete dmesg showing when the problem happens and a short
> description of the issue at bugs.freedesktop.org against DRI, component
> DRM/Intel.
See https://bugs.f
On Sat, Apr 21, 2012 at 03:03:07PM +0200, Daniel Vetter wrote:
> On Sat, Apr 21, 2012 at 07:39:08AM +0200, Maciej Rutecki wrote:
> > Bad kernel: 3.4-rc3
> > Last known good: 3.3
> >
> > Subsystem: dri-intel (guess)
> >
> > Steps to reproduce:
> > 1. Suspend to ram
> > 2. Resume
> >
> > After res
On Sat, Apr 21, 2012 at 02:58:39PM +0200, Paul Bolle wrote:
> On Sat, 2012-04-21 at 14:54 +0200, Daniel Vetter wrote:
> > On Sat, Apr 21, 2012 at 02:25:55PM +0200, Paul Bolle wrote:
> > > What part of that almost 700K file could be of interest?
> >
> > All of it. Please file a bug report with the
On Sat, Apr 21, 2012 at 07:39:08AM +0200, Maciej Rutecki wrote:
> Bad kernel: 3.4-rc3
> Last known good: 3.3
>
> Subsystem: dri-intel (guess)
>
> Steps to reproduce:
> 1. Suspend to ram
> 2. Resume
>
> After resume laptop works ok, but in dmesg I found:
> [ 164.098113] [ cut here ]-
On Sat, 2012-04-21 at 14:54 +0200, Daniel Vetter wrote:
> On Sat, Apr 21, 2012 at 02:25:55PM +0200, Paul Bolle wrote:
> > What part of that almost 700K file could be of interest?
>
> All of it. Please file a bug report with the error state attach (the
> entire thing), complete dmesg showing when t
On Sat, Apr 21, 2012 at 02:25:55PM +0200, Paul Bolle wrote:
> On Thu, 2012-04-19 at 11:04 +0200, Paul Bolle wrote:
> > <6>[14673.824599] [drm] capturing error event; look for more information in
> > /debug/dri/0/i915_error_state
>
> I triggered this issue once again in the session I run currently
Interesting, I'm pretty sure that I haven't touched the locking order of
the cs_mutex vs. vm_mutex.
Maybe it is just some kind of side effect, going to locking into it anyway.
Christian.
On 21.04.2012 13:39, Dave Airlie wrote:
> running 3.4.0-rc3 + Christian's reset patch series.
>
> The locks
On Thu, 2012-04-19 at 11:04 +0200, Paul Bolle wrote:
> <6>[14673.824599] [drm] capturing error event; look for more information in
> /debug/dri/0/i915_error_state
I triggered this issue once again in the session I run currently:
$ cat /sys/kernel/debug/dri/0/i915_error_state | wc -c
68968
Hi Tomasz,
Thanks for the patch.
On Wednesday 18 April 2012 11:44:59 Tomasz Stanislawski wrote:
> This patch adds a new constructor for an sg table. The table is constructed
> from an array of struct pages. All contiguous chunks of the pages are merged
> into a single sg nodes. A user may provide
From: Paulo Zanoni
In the future we'll have more than just connector properties, so create
a dump_prop function that can handle any property (instead of the
current dump_props function that only handles connector properties).
Also, make this function print a lot more information about the existi
From: Paulo Zanoni
24 (16 direct, 8 indirect) bytes in 1 blocks are definitely lost in loss record
2 of 7
at 0x402994D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4A25950: drmMalloc (xf86drm.c:147)
by 0x4A2E26D: drmModeGetPlaneResources (xf86drmMode.c:951)
b
From: Paulo Zanoni
Don't "continue" without freeing the connector.
192 bytes in 6 blocks are indirectly lost in loss record 6 of 12
at 0x4C2779D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4E30DD8: drmMalloc (xf86drm.c:147)
by 0x4E35024: drmAllocCpy (xf86drmMod
From: Paulo Zanoni
Use unsigned int instead of int:
- modetest.c:90:1: warning: comparison between signed and unsigned integer
expressions [-Wsign-compare]
- modetest.c:98:1: warning: comparison between signed and unsigned integer
expressions [-Wsign-compare]
- modetest.c:118:1: warning: compar
2012/3/29 Eugeni Dodonov :
> On Thu, Mar 29, 2012 at 18:28, Paulo Zanoni wrote:
>
>
> I don't know if it should go into a separate patch though. But it is aligned
> to the other formatting patterns you do, and it certainly looks nicer this
> way, and it shouldn't break anything anyway. So I am fi
2012/3/29 Eugeni Dodonov :
> I wonder if we could drop the dead^W#ifd 0'ed code here as well, perhaps
> with a separate patch? I don't think it will get used again in the future
> (but I might be wrong).
>
Removing #if 0'ed code won't fix compiler warnings, so if we do this,
it should
be done in a
2012/4/21 Christian K?nig :
> On 21.04.2012 17:57, Dave Airlie wrote:
>>
>> 2012/4/21 Jerome Glisse:
>>>
>>> 2012/4/21 Christian K?nig:
On 21.04.2012 16:08, Jerome Glisse wrote:
>
> 2012/4/21 Christian K?nig:
>>
>> Interesting, I'm pretty sure that I haven't touched the lo
For now, it just contains the hack for cirrusfb on Amiga, which is moved
out of with some slight modifications (use raw_*() instead of
z_*(), which are defined on all m68k platforms).
This makes it safe to include in all contexts. Before it
could fail to compile with
include/video/vga.h: In fun
https://bugs.freedesktop.org/show_bug.cgi?id=17902
--- Comment #70 from Daniel Vetter 2012-04-21 06:08:48 PDT
---
Created attachment 60416
--> https://bugs.freedesktop.org/attachment.cgi?id=60416
drm driver reload script
Looks like you've made a start alright. As I've said, I've you're gettin
thanks for your patch but your patch set needs some codes for
identifying whether pixel format is multiplanar or not as you
mentioned. so I will add the codes and apply your patch set to
exynos-drm-fixes branch for drm-fixes.
2012? 4? 21? ?? 12:26, ?? ?:
> From: Ville Syrj?l?
>
> The NV12M/YUV4
2012? 4? 20? ?? 11:22, Rob Clark ?? ?:
> On Fri, Apr 20, 2012 at 8:49 AM, Ville Syrj?l?
> wrote:
>> On Fri, Apr 20, 2012 at 07:48:07AM -0500, Rob Clark wrote:
>>> On Fri, Apr 20, 2012 at 7:29 AM, Dave Airlie wrote:
>>> > On Fri, Apr 20, 2012 at 1:23 PM, Ville Syrj?l?
>>> > wrote:
>>> >> On Fri,
Hi Rémi,
On Friday 20 April 2012 15:03:17 Rémi Denis-Courmont wrote:
> On Fri, 20 Apr 2012 14:25:01 +0200, Tomasz Stanislawski wrote:
> >>> The USERPTR simplifies userspace code but introduce
> >>> a lot of complexity problems for the kernel drivers
> >>> and frameworks.
> >>
> >> It is not only
Hi Tomasz,
Thanks for the patch.
On Friday 20 April 2012 16:45:29 Tomasz Stanislawski wrote:
> From: Andrzej Pietrasiewicz
>
> This patch introduces usage of dma_map_sg to map memory behind
> a userspace pointer to a device as dma-contiguous mapping.
>
> Signed-off-by: Andrzej Pietrasiewicz
>
running 3.4.0-rc3 + Christian's reset patch series.
The locks are definitely taken in different orders between vm_bo_add
and cs ioctl.
Dave.
==
[ INFO: possible circular locking dependency detected ]
3.4.0-rc3+ #33 Not tainted
-
On 21.04.2012 19:30, Jerome Glisse wrote:
2012/4/21 Christian König:
On 21.04.2012 17:57, Dave Airlie wrote:
2012/4/21 Jerome Glisse:
2012/4/21 Christian König:
On 21.04.2012 16:08, Jerome Glisse wrote:
2012/4/21 Christian König:
Interesting, I'm pretty sure that I haven't touched the locki
On sobota, 21 kwietnia 2012 o 15:13:52 Daniel Vetter wrote:
> On Sat, Apr 21, 2012 at 03:03:07PM +0200, Daniel Vetter wrote:
> > On Sat, Apr 21, 2012 at 07:39:08AM +0200, Maciej Rutecki wrote:
> > > Bad kernel: 3.4-rc3
> > > Last known good: 3.3
> > >
> > > Subsystem: dri-intel (guess)
> > >
> >
On 20.04.2012 01:47, Jerome Glisse wrote:
> 2012/4/19 Christian K?nig:
>> This includes mostly fixes for multi ring lockups and GPU resets, but it
>> should general improve the behavior of the kernel mode driver in case
>> something goes badly wrong.
>>
>> On the other hand it completely rewrites
On 04/20/2012 09:45 AM, Tomasz Stanislawski wrote:
> Hello everyone,
> This patchset adds support for DMABUF [2] importing to V4L2 stack.
> The support for DMABUF exporting was moved to separate patchset
> due to dependency on patches for DMA mapping redesign by
> Marek Szyprowski [4].
Would it be
2012/4/21 Christian K?nig :
> On 21.04.2012 16:08, Jerome Glisse wrote:
>>
>> 2012/4/21 Christian K?nig:
>>>
>>> Interesting, I'm pretty sure that I haven't touched the locking order of
>>> the
>>> cs_mutex vs. vm_mutex.
>>>
>>> Maybe it is just some kind of side effect, going to locking into it
>>
2012/4/21 Christian König :
> On 21.04.2012 17:57, Dave Airlie wrote:
>>
>> 2012/4/21 Jerome Glisse:
>>>
>>> 2012/4/21 Christian König:
On 21.04.2012 16:08, Jerome Glisse wrote:
>
> 2012/4/21 Christian König:
>>
>> Interesting, I'm pretty sure that I haven't touched the lo
On Fri, Apr 20, 2012 at 03:33:14PM +0200, Daniel Vetter wrote:
> On Fri, Apr 20, 2012 at 03:10:05PM +0200, Sascha Hauer wrote:
> > (BTW each driver in drm has this layer somewhere in it. If I had hidden
> > it in imx specific functions I probably wouldn't have raised any
> > questions, but I don't
2012/4/21 Christian K?nig :
> On 20.04.2012 01:47, Jerome Glisse wrote:
>>
>> 2012/4/19 Christian K?nig:
>>>
>>> This includes mostly fixes for multi ring lockups and GPU resets, but it
>>> should general improve the behavior of the kernel mode driver in case
>>> something goes badly wrong.
>>>
>>>
2012/4/21 Christian K?nig :
> Interesting, I'm pretty sure that I haven't touched the locking order of the
> cs_mutex vs. vm_mutex.
>
> Maybe it is just some kind of side effect, going to locking into it anyway.
>
> Christian.
>
It's the using, init path take lock in different order than cs path
On 21.04.2012 17:57, Dave Airlie wrote:
2012/4/21 Jerome Glisse:
2012/4/21 Christian König:
On 21.04.2012 16:08, Jerome Glisse wrote:
2012/4/21 Christian König:
Interesting, I'm pretty sure that I haven't touched the locking order of
the
cs_mutex vs. vm_mutex.
Maybe it is just some kind of s
2012/4/21 Jerome Glisse :
> 2012/4/21 Christian König :
>> On 21.04.2012 16:08, Jerome Glisse wrote:
>>>
>>> 2012/4/21 Christian König:
Interesting, I'm pretty sure that I haven't touched the locking order of
the
cs_mutex vs. vm_mutex.
Maybe it is just some kind of sid
2012/4/21 Christian König :
> On 21.04.2012 16:08, Jerome Glisse wrote:
>>
>> 2012/4/21 Christian König:
>>>
>>> Interesting, I'm pretty sure that I haven't touched the locking order of
>>> the
>>> cs_mutex vs. vm_mutex.
>>>
>>> Maybe it is just some kind of side effect, going to locking into it
>>
Bad kernel: 3.4-rc3
Last known good: 3.3
Subsystem: dri-intel (guess)
Steps to reproduce:
1. Suspend to ram
2. Resume
After resume laptop works ok, but in dmesg I found:
[ 164.098113] [ cut here ]
[ 164.098124] WARNING: at drivers/gpu/drm/i915/i915_drv.c:398
gen6_gt_ch
On 21.04.2012 16:08, Jerome Glisse wrote:
2012/4/21 Christian König:
Interesting, I'm pretty sure that I haven't touched the locking order of the
cs_mutex vs. vm_mutex.
Maybe it is just some kind of side effect, going to locking into it anyway.
Christian.
It's the using, init path take lock
2012/4/21 Christian König :
> On 20.04.2012 01:47, Jerome Glisse wrote:
>>
>> 2012/4/19 Christian König:
>>>
>>> This includes mostly fixes for multi ring lockups and GPU resets, but it
>>> should general improve the behavior of the kernel mode driver in case
>>> something goes badly wrong.
>>>
>>>
2012/4/21 Christian König :
> Interesting, I'm pretty sure that I haven't touched the locking order of the
> cs_mutex vs. vm_mutex.
>
> Maybe it is just some kind of side effect, going to locking into it anyway.
>
> Christian.
>
It's the using, init path take lock in different order than cs path
https://bugzilla.kernel.org/show_bug.cgi?id=43138
--- Comment #5 from bugtraq at hobbit.in-berlin.de 2012-04-21 06:51:09 ---
considering the age of that code I share your suspicions, but why then does a
stock debian kernel & initrd show same behavior as my self-compiled (newer)
one?
--
Conf
On Sat, 2012-04-21 at 14:54 +0200, Daniel Vetter wrote:
> Please file a bug report with the error state attach (the
> entire thing), complete dmesg showing when the problem happens and a short
> description of the issue at bugs.freedesktop.org against DRI, component
> DRM/Intel.
See https://bugs.f
On Sat, Apr 21, 2012 at 03:03:07PM +0200, Daniel Vetter wrote:
> On Sat, Apr 21, 2012 at 07:39:08AM +0200, Maciej Rutecki wrote:
> > Bad kernel: 3.4-rc3
> > Last known good: 3.3
> >
> > Subsystem: dri-intel (guess)
> >
> > Steps to reproduce:
> > 1. Suspend to ram
> > 2. Resume
> >
> > After res
https://bugs.freedesktop.org/show_bug.cgi?id=17902
--- Comment #70 from Daniel Vetter 2012-04-21 06:08:48 PDT ---
Created attachment 60416
--> https://bugs.freedesktop.org/attachment.cgi?id=60416
drm driver reload script
Looks like you've made a start alright. As I've said, I've you're getting
On Sat, Apr 21, 2012 at 02:58:39PM +0200, Paul Bolle wrote:
> On Sat, 2012-04-21 at 14:54 +0200, Daniel Vetter wrote:
> > On Sat, Apr 21, 2012 at 02:25:55PM +0200, Paul Bolle wrote:
> > > What part of that almost 700K file could be of interest?
> >
> > All of it. Please file a bug report with the
On Sat, Apr 21, 2012 at 07:39:08AM +0200, Maciej Rutecki wrote:
> Bad kernel: 3.4-rc3
> Last known good: 3.3
>
> Subsystem: dri-intel (guess)
>
> Steps to reproduce:
> 1. Suspend to ram
> 2. Resume
>
> After resume laptop works ok, but in dmesg I found:
> [ 164.098113] [ cut here ]-
On Sat, 2012-04-21 at 14:54 +0200, Daniel Vetter wrote:
> On Sat, Apr 21, 2012 at 02:25:55PM +0200, Paul Bolle wrote:
> > What part of that almost 700K file could be of interest?
>
> All of it. Please file a bug report with the error state attach (the
> entire thing), complete dmesg showing when t
On Sat, Apr 21, 2012 at 02:25:55PM +0200, Paul Bolle wrote:
> On Thu, 2012-04-19 at 11:04 +0200, Paul Bolle wrote:
> > <6>[14673.824599] [drm] capturing error event; look for more information in
> > /debug/dri/0/i915_error_state
>
> I triggered this issue once again in the session I run currently
Interesting, I'm pretty sure that I haven't touched the locking order of
the cs_mutex vs. vm_mutex.
Maybe it is just some kind of side effect, going to locking into it anyway.
Christian.
On 21.04.2012 13:39, Dave Airlie wrote:
running 3.4.0-rc3 + Christian's reset patch series.
The locks are
On Thu, 2012-04-19 at 11:04 +0200, Paul Bolle wrote:
> <6>[14673.824599] [drm] capturing error event; look for more information in
> /debug/dri/0/i915_error_state
I triggered this issue once again in the session I run currently:
$ cat /sys/kernel/debug/dri/0/i915_error_state | wc -c
68968
running 3.4.0-rc3 + Christian's reset patch series.
The locks are definitely taken in different orders between vm_bo_add
and cs ioctl.
Dave.
==
[ INFO: possible circular locking dependency detected ]
3.4.0-rc3+ #33 Not tainted
-
https://bugs.freedesktop.org/show_bug.cgi?id=49030
Bug #: 49030
Summary: Possible recursive locking detected in r600g
Classification: Unclassified
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Hello,
Since linux-3.3 I have been experiencing screen "blackouts" with the
gma500_gfx driver. My laptop display would turn off and on again frequently.
After activating the drm.debug=255 kernel option, the logs showed this during
the blackout :
[ 166.940676] [drm:psb_intel_sdvo_read_respons
On 04/19/2012 11:05 PM, Lucas Stach wrote:
Am Freitag, den 20.04.2012, 07:02 +0200 schrieb Thierry Reding:
*cut*
Yes, I think we should go the route that Jerome Glisse pointed out: get
in a basic KMS driver first and hide any accel ioctl under a staging
config option.
Everyone seems happy w
On 20.04.2012 01:47, Jerome Glisse wrote:
2012/4/19 Christian König:
This includes mostly fixes for multi ring lockups and GPU resets, but it should
general improve the behavior of the kernel mode driver in case something goes
badly wrong.
On the other hand it completely rewrites the IB pool
On Fri, Apr 20, 2012 at 03:33:14PM +0200, Daniel Vetter wrote:
> On Fri, Apr 20, 2012 at 03:10:05PM +0200, Sascha Hauer wrote:
> > (BTW each driver in drm has this layer somewhere in it. If I had hidden
> > it in imx specific functions I probably wouldn't have raised any
> > questions, but I don't
Hello,
Since linux-3.3 I have been experiencing screen "blackouts" with the
gma500_gfx driver. My laptop display would turn off and on again frequently.
After activating the drm.debug=255 kernel option, the logs showed this during
the blackout :
[ 166.940676] [drm:psb_intel_sdvo_read_respons
74 matches
Mail list logo