... The missed kconfig.
On Fri, Jul 06, 2012 at 10:46:22PM +0800, Fengguang Wu wrote:
> Hi Thomas,
>
> I got this error while running kvm boot tests on linux-next.
> Attached is the kconfig.
>
> [7.064962] [drm:drm_core_init] *ERROR* Cannot create /proc/dri
> [7.067443] general protectio
Hi Thomas,
I got this error while running kvm boot tests on linux-next.
Attached is the kconfig.
[7.064962] [drm:drm_core_init] *ERROR* Cannot create /proc/dri
[7.067443] general protection fault: [#1] PREEMPT
[7.068713] CPU 0
[7.068713] Pid: 1, comm: swapper Not tainted 3.
Hi,
On Fri, Jul 6, 2012 at 9:28 PM, Leela Krishna Amudala
wrote:
> Add device tree based discovery support for DRM-FIMD driver.
>
> Signed-off-by: Leela Krishna Amudala
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 29fdbfe..37769c
On Fri, Jul 06, 2012 at 06:09:20PM +0100, Dave Airlie wrote:
> On Fri, Jul 6, 2012 at 5:49 PM, Dave Airlie wrote:
> > On Fri, Jul 6, 2012 at 3:48 PM, Fengguang Wu wrote:
> >> ... The missed kconfig.
> >>
> >> On Fri, Jul 06, 2012 at 10:46:22PM +0800, Fengguang Wu wrote:
> >>> Hi Thomas,
> >
> > W
- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-fail-gracefully-when-proc-isn-t-setup.patch
Type: application/octet-stream
Size: 892 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120706/5915005f/attachment.obj>
Hi,
I'm sorry having to report that I'm only able to suspend once with Linux
3.5-rc5; any subsequent attempts fail. This is a regression from 3.4
where suspend/resume worked flawlessly and arbitrarily often on my
machine.
Bisection show that the problem was introduced in commit c420b2dc8dc:
,--
From: Prathyush K
The name of the exynos drm fimd device is renamed to exynos-drm-fimd
and two ids are created for exynos4-fb and exynos5-fb.
Signed-off-by: Prathyush K
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 37769cf..f7bb0a0 1006
Add device tree based discovery support for DRM-FIMD driver.
Signed-off-by: Leela Krishna Amudala
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 29fdbfe..37769cf 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/e
This patch set adds device tree support for DRM-FIMD for Samsung's Exynos5250.
It includes parsing platform data from dts file.
This patchset is based and tested on top of v3.5-rc4.
Leela Krishna Amudala (1):
video: drm: exynos: Add device tree support
Prathyush K (1):
drm/exynos: Modifying
On Fri, Jul 6, 2012 at 3:48 PM, Fengguang Wu wrote:
> ... The missed kconfig.
>
> On Fri, Jul 06, 2012 at 10:46:22PM +0800, Fengguang Wu wrote:
>> Hi Thomas,
Wierd, I'm sorta tempted to just depend drm on CONFIG_PROC_FS, but it
looks like the error path is failing to dtrt.
Dave.
Am Freitag, den 06.07.2012, 17:34 +0200 schrieb Paul Menzel:
> Am Donnerstag, den 05.07.2012, 08:58 -0400 schrieb Alex Deucher:
> > On Wed, Jul 4, 2012 at 10:11 AM, Paul Menzel wrote:
> > > Am Mittwoch, den 04.07.2012, 09:55 -0400 schrieb Alex Deucher:
> > >> On Wed, Jul 4, 2012 at 9:41 AM, Paul Me
:08 debian-host acpid: client connected from
> >> >> 8677[0:0]
> >> >> Jun 29 19:45:08 debian-host acpid: 1 client rule loaded
> >> >
> >> > Does someone have an idea what the problem might be and how to fix it?
> >>
> >> Is this a regression? If so can you bisect?
> >
> > I do not think so. But the problem is I just got that board, have only
> > used it with Linux 3.2.x (from Debian Sid/unstable) and this issue is
> > not reproducible, that means, it happens in less then 5(?) percent of
> > the suspend and resume cycles.
> >
> > Any idea what these acpid messages could mean?
It just happened again. This time with the monitor not getting any
signal. Switching to other virtual terminals does not work.
What debug levels should I increase?
Thanks,
Paul
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120706/a1cf625c/attachment.pgp>
On Mon, Jul 02, 2012 at 12:05:06PM +0200, Sascha Hauer wrote:
> On Thu, Jun 14, 2012 at 03:43:22PM +0200, Sascha Hauer wrote:
> > Hi All,
> >
> > The following is the state-of-the-art i.MX IPU (Image Processing Unit)
> > DRM support.
> >
> > This code is around for quite some time now and has bee
On 07/05/2012 06:15 AM, Thierry Reding wrote:
> Here's a new proposal that should address all issues collected
> during the discussion of the previous one:
>
> From tegra20.dtsi:
...
At a quick glance, that all seems pretty reasonable now.
> One problem I've come across when trying to get some r
Hi,
On Fri, Jul 6, 2012 at 5:28 AM, Leela Krishna Amudala
wrote:
>
> Add device tree based discovery support for DRM-FIMD driver.
>
> Signed-off-by: Leela Krishna Amudala
This also needs to be sent to devicetree-disc...@lists.ozlabs.org, and
the device tree bindings need to be documented under
From: Prathyush K
The name of the exynos drm fimd device is renamed to exynos-drm-fimd
and two ids are created for exynos4-fb and exynos5-fb.
Signed-off-by: Prathyush K
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 37769cf..f7bb0a0 1006
Add device tree based discovery support for DRM-FIMD driver.
Signed-off-by: Leela Krishna Amudala
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 29fdbfe..37769cf 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/e
This patch set adds device tree support for DRM-FIMD for Samsung's Exynos5250.
It includes parsing platform data from dts file.
This patchset is based and tested on top of v3.5-rc4.
Leela Krishna Amudala (1):
video: drm: exynos: Add device tree support
Prathyush K (1):
drm/exynos: Modifying
From: Alan Cox
Otherwise we end up getting the masks wrong, can get events before we are
doing power control and other ungood things.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/opregion.c |8 +++-
drivers/gpu/drm/gma500/opregion.h |5 +
drivers/gpu/drm/gma500/psb_drv.c
soc_ioctl,
+ .release = drm_soc_release,
+};
+
+static struct drm_driver soc_drm = {
+ .driver_features = DRIVER_MODESET | DRIVER_GEM,
+ .load = soc_drm_load,
+ .unload = soc_drm_unload,
+ .open = soc_drm_open,
+ .preclose = soc_drm_preclose,
+ .lastclose = soc_drm_la
This commit adds an initial framework that can be used to plug SoC
graphics devices into the DRM/KMS subsystem.
SoCs often don't have a dedicated device to which a DRM driver can bind,
but instead the graphics complex typically consists of several platform-
type devices that work together. The DRM
This series adds an initial framework that allows to register a graphics
complex as found on many SoCs with the DRM/KMS subsystem. Patch 1 adds
the actual framework and patch 2 implements a very rudimentary skeleton
driver on top of it. It's really just to show off how to use the DRM/SoC
API and of
On Mon, Jul 02, 2012 at 12:05:06PM +0200, Sascha Hauer wrote:
> On Thu, Jun 14, 2012 at 03:43:22PM +0200, Sascha Hauer wrote:
> > Hi All,
> >
> > The following is the state-of-the-art i.MX IPU (Image Processing Unit)
> > DRM support.
> >
> > This code is around for quite some time now and has bee
https://bugs.freedesktop.org/show_bug.cgi?id=51787
--- Comment #1 from Michel D?nzer 2012-07-06 08:25:03
PDT ---
FWIW, I suspect it's more likely (re)compiling fragment shaders than vertex
shaders. Possibly related to constantly changing fixed-function emulation
shaders, UT2004 seems to burn thr
https://bugs.freedesktop.org/show_bug.cgi?id=51787
Bug #: 51787
Summary: performance regression with llvm shader compiler in
ut2004
Classification: Unclassified
Product: Mesa
Version: git
Platform: Other
OS/Ver
On 07/05/2012 06:15 AM, Thierry Reding wrote:
> Here's a new proposal that should address all issues collected
> during the discussion of the previous one:
>
> From tegra20.dtsi:
...
At a quick glance, that all seems pretty reasonable now.
> One problem I've come across when trying to get some r
> From: linux-tegra-owner at vger.kernel.org [mailto:linux-tegra-
> owner at vger.kernel.org] On Behalf Of Thierry Reding
> Sent: Thursday, July 05, 2012 8:15 PM
> To: linux-tegra at vger.kernel.org
> Cc: devicetree-discuss at lists.ozlabs.org; dri-devel at lists.freedesktop.org
> Subject: Re: Tegr
https://bugzilla.kernel.org/show_bug.cgi?id=44121
--- Comment #15 from Alex Deucher 2012-07-06
13:13:17 ---
That's the problem with GPU drivers. It's impossible to test every combination
of userspace and kernel drivers and there can be very subtle bugs with certain
combinations like this o
https://bugzilla.kernel.org/show_bug.cgi?id=44121
Jean Delvare changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugzilla.kernel.org/show_bug.cgi?id=44121
Jean Delvare changed:
What|Removed |Added
Attachment #74771|0 |1
is obsolete|
On 02.07.2012 18:45, j.glisse at gmail.com wrote:
> From: Jerome Glisse
>
> GPU reset need to be exclusive, one happening at a time. For this
> add a rw semaphore so that any path that trigger GPU activities
> have to take the semaphore as a reader thus allowing concurency.
>
> The GPU reset path
On Fri, Jul 6, 2012 at 5:49 PM, Dave Airlie wrote:
> On Fri, Jul 6, 2012 at 3:48 PM, Fengguang Wu wrote:
>> ... The missed kconfig.
>>
>> On Fri, Jul 06, 2012 at 10:46:22PM +0800, Fengguang Wu wrote:
>>> Hi Thomas,
>
> Wierd, I'm sorta tempted to just depend drm on CONFIG_PROC_FS, but it
> looks
On Fri, Jul 6, 2012 at 3:48 PM, Fengguang Wu wrote:
> ... The missed kconfig.
>
> On Fri, Jul 06, 2012 at 10:46:22PM +0800, Fengguang Wu wrote:
>> Hi Thomas,
Wierd, I'm sorta tempted to just depend drm on CONFIG_PROC_FS, but it
looks like the error path is failing to dtrt.
Dave.
Hi,
On Fri, Jul 6, 2012 at 5:28 AM, Leela Krishna Amudala
wrote:
>
> Add device tree based discovery support for DRM-FIMD driver.
>
> Signed-off-by: Leela Krishna Amudala
This also needs to be sent to devicetree-discuss at lists.ozlabs.org, and
the device tree bindings need to be documented un
Hi,
I'm sorry having to report that I'm only able to suspend once with Linux
3.5-rc5; any subsequent attempts fail. This is a regression from 3.4
where suspend/resume worked flawlessly and arbitrarily often on my
machine.
Bisection show that the problem was introduced in commit c420b2dc8dc:
,--
Am Donnerstag, den 05.07.2012, 08:58 -0400 schrieb Alex Deucher:
> On Wed, Jul 4, 2012 at 10:11 AM, Paul Menzel wrote:
> > Am Mittwoch, den 04.07.2012, 09:55 -0400 schrieb Alex Deucher:
> >> On Wed, Jul 4, 2012 at 9:41 AM, Paul Menzel wrote:
> >> > Am Samstag, den 30.06.2012, 21:00 +0200 schrieb Pa
https://bugs.freedesktop.org/show_bug.cgi?id=51787
--- Comment #1 from Michel Dänzer 2012-07-06 08:25:03 PDT
---
FWIW, I suspect it's more likely (re)compiling fragment shaders than vertex
shaders. Possibly related to constantly changing fixed-function emulation
shaders, UT2004 seems to burn thr
Hi Thomas,
I got this error while running kvm boot tests on linux-next.
Attached is the kconfig.
[7.064962] [drm:drm_core_init] *ERROR* Cannot create /proc/dri
[7.067443] general protection fault: [#1] PREEMPT
[7.068713] CPU 0
[7.068713] Pid: 1, comm: swapper Not tainted 3.
https://bugs.freedesktop.org/show_bug.cgi?id=51787
Bug #: 51787
Summary: performance regression with llvm shader compiler in
ut2004
Classification: Unclassified
Product: Mesa
Version: git
Platform: Other
OS/Ver
soc_ioctl,
+ .release = drm_soc_release,
+};
+
+static struct drm_driver soc_drm = {
+ .driver_features = DRIVER_MODESET | DRIVER_GEM,
+ .load = soc_drm_load,
+ .unload = soc_drm_unload,
+ .open = soc_drm_open,
+ .preclose = soc_drm_preclose,
+ .lastclose = soc_drm_la
This commit adds an initial framework that can be used to plug SoC
graphics devices into the DRM/KMS subsystem.
SoCs often don't have a dedicated device to which a DRM driver can bind,
but instead the graphics complex typically consists of several platform-
type devices that work together. The DRM
This series adds an initial framework that allows to register a graphics
complex as found on many SoCs with the DRM/KMS subsystem. Patch 1 adds
the actual framework and patch 2 implements a very rudimentary skeleton
driver on top of it. It's really just to show off how to use the DRM/SoC
API and of
https://bugzilla.kernel.org/show_bug.cgi?id=44121
--- Comment #15 from Alex Deucher 2012-07-06 13:13:17
---
That's the problem with GPU drivers. It's impossible to test every combination
of userspace and kernel drivers and there can be very subtle bugs with certain
combinations like this o
https://bugzilla.kernel.org/show_bug.cgi?id=44121
Jean Delvare changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugzilla.kernel.org/show_bug.cgi?id=44121
Jean Delvare changed:
What|Removed |Added
Attachment #74771|0 |1
is obsolete|
On 02.07.2012 18:45, j.gli...@gmail.com wrote:
From: Jerome Glisse
GPU reset need to be exclusive, one happening at a time. For this
add a rw semaphore so that any path that trigger GPU activities
have to take the semaphore as a reader thus allowing concurency.
The GPU reset path take the sema
46 matches
Mail list logo
