On Mon, Feb 18, 2013 at 03:42:39PM +0800, Mark Zhang wrote:
> Hi Thierry,
>
> Which version is this patch set based on? I tried to apply it on
> linux-next 0206 & tot 0215 but failed:
This was based on next-20130213.
Thierry
pgppab5N2wus2.pgp
Description: PGP signature
Hi Thierry,
Which version is this patch set based on? I tried to apply it on
linux-next 0206 & tot 0215 but failed:
Applying: drm: Add consistency check for page-flipping
Applying: drm/tegra: Add plane support
error: patch failed: drivers/gpu/drm/tegra/drm.h:121
error: drivers/gpu/drm/tegra/drm.h
On Thursday 14 February 2013 09:24 PM, Rob Clark wrote:
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 plac
On Mon, Feb 18, 2013 at 03:06:10PM +0800, Mark Zhang wrote:
> On 02/18/2013 02:48 PM, Thierry Reding wrote:
> > On Mon, Feb 18, 2013 at 02:17:53PM +0800, Mark Zhang wrote:
> >> On 02/14/2013 12:05 AM, Thierry Reding wrote:
> >>> The sequence for replacing the scanout buffer is much shorter than a
>
On 02/18/2013 03:01 PM, Thierry Reding wrote:
> On Mon, Feb 18, 2013 at 02:55:04PM +0800, Mark Zhang wrote:
>> On 02/18/2013 02:40 PM, Thierry Reding wrote:
>>> On Mon, Feb 18, 2013 at 02:06:56PM +0800, Mark Zhang wrote:
On 02/14/2013 12:05 AM, Thierry Reding wrote:
> Add support for the B
On 02/18/2013 02:48 PM, Thierry Reding wrote:
> On Mon, Feb 18, 2013 at 02:17:53PM +0800, Mark Zhang wrote:
>> On 02/14/2013 12:05 AM, Thierry Reding wrote:
>>> The sequence for replacing the scanout buffer is much shorter than a
>>> full mode change operation so implementing this callback consider
On Mon, Feb 18, 2013 at 02:55:04PM +0800, Mark Zhang wrote:
> On 02/18/2013 02:40 PM, Thierry Reding wrote:
> > On Mon, Feb 18, 2013 at 02:06:56PM +0800, Mark Zhang wrote:
> >> On 02/14/2013 12:05 AM, Thierry Reding wrote:
> >>> Add support for the B and C planes which support RGB and YUV pixel
> >
On 02/18/2013 02:40 PM, Thierry Reding wrote:
> On Mon, Feb 18, 2013 at 02:06:56PM +0800, Mark Zhang wrote:
>> On 02/14/2013 12:05 AM, Thierry Reding wrote:
>>> Add support for the B and C planes which support RGB and YUV pixel
>>> formats and can be used as overlays or hardware cursor. Currently
>
On Mon, Feb 18, 2013 at 02:17:53PM +0800, Mark Zhang wrote:
> On 02/14/2013 12:05 AM, Thierry Reding wrote:
> > The sequence for replacing the scanout buffer is much shorter than a
> > full mode change operation so implementing this callback considerably
> > speeds up cases where only a new framebu
On Mon, Feb 18, 2013 at 02:06:56PM +0800, Mark Zhang wrote:
> On 02/14/2013 12:05 AM, Thierry Reding wrote:
> > Add support for the B and C planes which support RGB and YUV pixel
> > formats and can be used as overlays or hardware cursor. Currently
> > only 32-bit RGBA pixel formats are advertised.
On 02/18/2013 02:17 PM, Mark Zhang wrote:
> On 02/14/2013 12:05 AM, Thierry Reding wrote:
>> The sequence for replacing the scanout buffer is much shorter than a
>> full mode change operation so implementing this callback considerably
>> speeds up cases where only a new framebuffer is to be scanned
On 02/14/2013 12:05 AM, Thierry Reding wrote:
> The sequence for replacing the scanout buffer is much shorter than a
> full mode change operation so implementing this callback considerably
> speeds up cases where only a new framebuffer is to be scanned out.
>
> Signed-off-by: Thierry Reding
> ---
On 02/14/2013 12:05 AM, Thierry Reding wrote:
> Add support for the B and C planes which support RGB and YUV pixel
> formats and can be used as overlays or hardware cursor. Currently
> only 32-bit RGBA pixel formats are advertised.
>
> Signed-off-by: Thierry Reding
[...]
> +static int tegra_dc_ad
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130217/8a971449/attachment.html>
rsion string: 3.0 Mesa 9.2-devel (git-b681ed6)
--
You are 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/20130217/675661b1/attachment.html>
This adds a new fbdev frontend to the dvbe driver. It allows userspace to
access the dvbe driver via an fbdev frontend.
It is disabled by default so you can use dvbe without CONFIG_FB. It should
only be used for backwards-compatibility. Use the DRM dumb API to access
dvbe buffers properly.
Signed
Extend the dvbe core driver by a VESA/VBE backend that simply blits the
data from a framebuffer into the hardware framebuffer on damage.
Modesetting has to be done during the boot-process by the architecture
code (same way as vesafb requires it). No runtime modesetting is allowed
due to RealMode/Pr
This driver uses the VESA BIOS Extensions to control the display device.
Modesetting has to be done during the boot-process by the architecture
code (same way as vesafb requires it). No runtime modesetting is allowed
due to RealMode/ProtectedMode restrictions.
This patch only introduces the stub D
This provides a new DRM bus helper for the system framebuffer bus. It is
very similar in its functionality to the DRM_USB helper. It allows to
write DRM drivers that register as SYSFB drivers to the system.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/Kconfig | 5 ++
drivers/gpu/drm/M
Instead of using our own platform device, we now register as sysfb driver
and get notified whenever we are loaded on a system VBE device. This
allows other VBE drivers to be loaded at the same time and users can
bind/unbind drivers via sysfs. We also no longer need to fake a
platform-device because
From: David Herrmann
Fix the vesafb module to no longer use any static __init data. Also add a
module_exit() function that destroys the platform device.
Note that fbdev hotplugging is broken and the self-reference actually
prevents sane module-unloading. Anyway, this at least allows delayed
modu
From: David Herrmann
HACK: This should be provided by architecture setup code. But to show how it is
supposed to work, we now simply add a "vbefb" device during initialization.
The better way to do this is by moving this into arch-code. So for instance the
x86 boot initialization should create t
From: David Herrmann
This adds the VESA BIOS Extension (VBE) device type. Platform code needs
to provide the "vbefb" platform-device with a screen_info structure as
platform code.
All drivers that depend on VBE can now register as bus drivers and bind
to SYSFB_VBE devices. There is no distinctio
From: David Herrmann
For a long time now we have the problem that there are multiple drivers
available that try to use system framebuffers (like EFI, VESA/VBE, ...).
There is no way to control which driver gets access to the devices, but
instead works on a first-come-first-serve basis.
Furthermo
Hi
This series tries to fix the mess with global system framebuffer access in
device drivers. Currently, architecture initialization sets the "screen_info"
object according to the system framebuffer that was detected during boot. The
device driver that can map VMEM first gets access to it. There i
On Mon, Feb 11, 2013 at 11:18 PM, Patrik Jakobsson
wrote:
> On Mon, Feb 11, 2013 at 2:15 PM, "David M?ller (ELSOFT AG)"
> wrote:
>> Hi Patrik
>>
>> Patrik Jakobsson wrote:
>>> The value of VCO_MIN comes from the Intel PRM for similar GPUs.
>>>
>>> Instead of changing VCO_MIN, could you try settin
On Sun, Feb 17, 2013 at 5:31 PM, Hugh Dickins wrote:
> On Sun, 17 Feb 2013, Daniel Vetter wrote:
>> On Sun, Feb 17, 2013 at 3:21 AM, Hugh Dickins wrote:
>> > On Sat, 16 Feb 2013, Hugh Dickins wrote:
>> >> On Sat, 16 Feb 2013, Linus Torvalds wrote:
>> >> >
>> >> > I think it's worth it to give the
Hi Dave,
Here is pull request for tilcdc drm driver.. it also includes a
handful of dependent patches from me, plus a couple fixes from Daniel
Vetter which haven't showed up yet in drm-next.
--
The following changes since commit 3314fdf8b44bd4914050614fa2c56b7c587fabc2:
Merge branch '
Hi Dave,
This pull moves omapdrm out of staging into drivers/gpu/drm.. since
there are a couple patches already in staging-next, I cherry-picked
these onto omapdrm-next (which is based on drm-next rather than
staging-next). I've also added a couple of Daniel's omapdrm patches,
fixed up to apply
https://bugs.freedesktop.org/show_bug.cgi?id=60802
Alexandre Demers changed:
What|Removed |Added
Summary|Kernel 3.8-rc7 breaks |(bisect
|rendering
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #4 from Alexandre Demers ---
bisected and first bad commit is: 8696e33f06b0c52195152cc6a0e3d52233f486c1
commit 8696e33f06b0c52195152cc6a0e3d52233f486c1
Author: Alex Deucher
Date: Thu Dec 13 18:57:07 2012 -0500
drm/radeon: bump
ring my
git bisect.
--
You are 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/20130217/aebcd018/attachment.html>
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130217/342c0e9c/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130217/83ca31de/attachment.html>
On Sun, Feb 17, 2013 at 2:38 PM, Daniel Vetter
wrote:
> 2. The new i915 force restore code is indeed missing a safety check
> compared to the old crtc helper based one:
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 6eb3882..095094c 100644
>> I'm unsure if I like this or not, and I don't see why its greatly more
>> useful than the interface we have now.
>
> This interface at least solves the problem with having vesafb,
> uvesafb, vgacon, vga16fb, efifb, dvbe, defi and all other similar
> drivers from accessing the system framebuffer
On Sun, Feb 17, 2013 at 11:28 AM, Toralf F?rster
wrote:
> While running the WEB-GL tests in [1] firefox crashed a ThinkPad T420 w/ i915
> graphic.
> The kernel log gives:
>
>
> 2013-02-17T10:32:58.451+01:00 n22 kernel: [drm:__gen6_gt_force_wake_get]
> *ERROR* Timed out waiting for forcewake to
Hi Dave
On Sun, Feb 17, 2013 at 11:02 PM, Dave Airlie wrote:
>>
>> This series tries to fix the mess with global system framebuffer access in
>> device drivers. Currently, architecture initialization sets the "screen_info"
>> object according to the system framebuffer that was detected during boo
Hi Dave,
Here is pull request for tilcdc drm driver.. it also includes a
handful of dependent patches from me, plus a couple fixes from Daniel
Vetter which haven't showed up yet in drm-next.
--
The following changes since commit 3314fdf8b44bd4914050614fa2c56b7c587fabc2:
Merge branch '
Hi Dave,
This pull moves omapdrm out of staging into drivers/gpu/drm.. since
there are a couple patches already in staging-next, I cherry-picked
these onto omapdrm-next (which is based on drm-next rather than
staging-next). I've also added a couple of Daniel's omapdrm patches,
fixed up to apply
On Sun, Feb 17, 2013 at 3:21 AM, Hugh Dickins wrote:
> On Sat, 16 Feb 2013, Hugh Dickins wrote:
>> On Sat, 16 Feb 2013, Linus Torvalds wrote:
>> >
>> > I think it's worth it to give them a heads-up already. So I've cc'd
>> > the main suspects here..
>>
>> Okay, thanks.
>>
>> >
>> > Daniel, Dave -
From: Rob Clark
The libdrm_freedreno helper layer for use by xf86-video-freedreno,
fdre (freedreno r/e library and tests for driving gpu), and eventual
gallium driver for the Adreno GPU. This uses the msm gpu driver
from QCOM's android kernel tree.
Note that current msm kernel driver is a bit s
>
> This series tries to fix the mess with global system framebuffer access in
> device drivers. Currently, architecture initialization sets the "screen_info"
> object according to the system framebuffer that was detected during boot. The
> device driver that can map VMEM first gets access to it. T
https://bugs.freedesktop.org/show_bug.cgi?id=58042
--- Comment #12 from Marek Olšák ---
Could you please attach an apitrace file showing the issue?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dr
https://bugzilla.kernel.org/show_bug.cgi?id=49531
--- Comment #7 from Matthieu Baerts 2013-02-17 13:07:48
---
Created an attachment (id=93461)
--> (https://bugzilla.kernel.org/attachment.cgi?id=93461)
Kernel Oops with version 3.8-rc7
Hello,
I also have this crash with the version 3.8-rc7
https://bugs.freedesktop.org/show_bug.cgi?id=58042
--- Comment #11 from almos ---
I just tried steam and tf2 on linux, and I didn't see any rendering error. The
only abnormal thing was this line:
This system DOES NOT support the OpenGL extension GL_ARB_uniform_buffer.
HD6850, OpenGL version stri
On Sun, 17 Feb 2013, Daniel Vetter wrote:
> On Sun, Feb 17, 2013 at 3:21 AM, Hugh Dickins wrote:
> > On Sat, 16 Feb 2013, Hugh Dickins wrote:
> >> On Sat, 16 Feb 2013, Linus Torvalds wrote:
> >> >
> >> > I think it's worth it to give them a heads-up already. So I've cc'd
> >> > the main suspects h
On Sat, 16 Feb 2013, Hugh Dickins wrote:
> On Sat, 16 Feb 2013, Linus Torvalds wrote:
> >
> > I think it's worth it to give them a heads-up already. So I've cc'd
> > the main suspects here..
>
> Okay, thanks.
>
> >
> > Daniel, Dave - any comments about a NULL fb in
> > intel_choose_pipe_bpp_dit
On Sat, 16 Feb 2013, Linus Torvalds wrote:
> On Sat, Feb 16, 2013 at 1:45 PM, Hugh Dickins wrote:
> >
> > I hacked around on your PM_TRACE set_magic_time() / read_magic_time()
> > yesterday, to save an oopsing core kernel ip there, instead of hashed
> > pm trace info (it makes sense in this case t
While running the WEB-GL tests in [1] firefox crashed a ThinkPad T420 w/ i915
graphic.
The kernel log gives:
2013-02-17T10:32:58.451+01:00 n22 kernel: [drm:__gen6_gt_force_wake_get]
*ERROR* Timed out waiting for forcewake to ack request.
2013-02-17T10:32:58.451+01:00 n22 kernel: [drm:__gen6_gt_
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130217/9fbfe1cc/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130217/32868099/attachment.html>
This adds a new fbdev frontend to the dvbe driver. It allows userspace to
access the dvbe driver via an fbdev frontend.
It is disabled by default so you can use dvbe without CONFIG_FB. It should
only be used for backwards-compatibility. Use the DRM dumb API to access
dvbe buffers properly.
Signed
Extend the dvbe core driver by a VESA/VBE backend that simply blits the
data from a framebuffer into the hardware framebuffer on damage.
Modesetting has to be done during the boot-process by the architecture
code (same way as vesafb requires it). No runtime modesetting is allowed
due to RealMode/Pr
This driver uses the VESA BIOS Extensions to control the display device.
Modesetting has to be done during the boot-process by the architecture
code (same way as vesafb requires it). No runtime modesetting is allowed
due to RealMode/ProtectedMode restrictions.
This patch only introduces the stub D
This provides a new DRM bus helper for the system framebuffer bus. It is
very similar in its functionality to the DRM_USB helper. It allows to
write DRM drivers that register as SYSFB drivers to the system.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/Kconfig | 5 ++
drivers/gpu/drm/M
Instead of using our own platform device, we now register as sysfb driver
and get notified whenever we are loaded on a system VBE device. This
allows other VBE drivers to be loaded at the same time and users can
bind/unbind drivers via sysfs. We also no longer need to fake a
platform-device because
From: David Herrmann
Fix the vesafb module to no longer use any static __init data. Also add a
module_exit() function that destroys the platform device.
Note that fbdev hotplugging is broken and the self-reference actually
prevents sane module-unloading. Anyway, this at least allows delayed
modu
From: David Herrmann
HACK: This should be provided by architecture setup code. But to show how it is
supposed to work, we now simply add a "vbefb" device during initialization.
The better way to do this is by moving this into arch-code. So for instance the
x86 boot initialization should create t
From: David Herrmann
This adds the VESA BIOS Extension (VBE) device type. Platform code needs
to provide the "vbefb" platform-device with a screen_info structure as
platform code.
All drivers that depend on VBE can now register as bus drivers and bind
to SYSFB_VBE devices. There is no distinctio
From: David Herrmann
For a long time now we have the problem that there are multiple drivers
available that try to use system framebuffers (like EFI, VESA/VBE, ...).
There is no way to control which driver gets access to the devices, but
instead works on a first-come-first-serve basis.
Furthermo
Hi
This series tries to fix the mess with global system framebuffer access in
device drivers. Currently, architecture initialization sets the "screen_info"
object according to the system framebuffer that was detected during boot. The
device driver that can map VMEM first gets access to it. There i
On Mon, Feb 11, 2013 at 11:18 PM, Patrik Jakobsson
wrote:
> On Mon, Feb 11, 2013 at 2:15 PM, "David Müller (ELSOFT AG)"
> wrote:
>> Hi Patrik
>>
>> Patrik Jakobsson wrote:
>>> The value of VCO_MIN comes from the Intel PRM for similar GPUs.
>>>
>>> Instead of changing VCO_MIN, could you try settin
https://bugs.freedesktop.org/show_bug.cgi?id=60969
--- Comment #2 from Chris Rankin ---
Created attachment 74995
--> https://bugs.freedesktop.org/attachment.cgi?id=74995&action=edit
dmesg output frpm GPU lockup/reset
This dmesg log shows the GPU lockups and soft resets that occurred during my
https://bugs.freedesktop.org/show_bug.cgi?id=60969
--- Comment #1 from Chris Rankin ---
According to git bisect:
974b482acaf62ced1e8981761a8bda252bd51fe1 is the first bad commit
commit 974b482acaf62ced1e8981761a8bda252bd51fe1
Author: Jerome Glisse
Date: Fri Feb 8 16:02:32 2013 -0500
r600
On Sun, Feb 17, 2013 at 5:31 PM, Hugh Dickins wrote:
> On Sun, 17 Feb 2013, Daniel Vetter wrote:
>> On Sun, Feb 17, 2013 at 3:21 AM, Hugh Dickins wrote:
>> > On Sat, 16 Feb 2013, Hugh Dickins wrote:
>> >> On Sat, 16 Feb 2013, Linus Torvalds wrote:
>> >> >
>> >> > I think it's worth it to give the
On Sun, 17 Feb 2013, Daniel Vetter wrote:
> On Sun, Feb 17, 2013 at 3:21 AM, Hugh Dickins wrote:
> > On Sat, 16 Feb 2013, Hugh Dickins wrote:
> >> On Sat, 16 Feb 2013, Linus Torvalds wrote:
> >> >
> >> > I think it's worth it to give them a heads-up already. So I've cc'd
> >> > the main suspects h
https://bugs.freedesktop.org/show_bug.cgi?id=60981
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Sun, Feb 17, 2013 at 2:38 PM, Daniel Vetter wrote:
> 2. The new i915 force restore code is indeed missing a safety check
> compared to the old crtc helper based one:
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 6eb3882..095094c 100644
>
On Sun, Feb 17, 2013 at 11:28 AM, Toralf Förster wrote:
> While running the WEB-GL tests in [1] firefox crashed a ThinkPad T420 w/ i915
> graphic.
> The kernel log gives:
>
>
> 2013-02-17T10:32:58.451+01:00 n22 kernel: [drm:__gen6_gt_force_wake_get]
> *ERROR* Timed out waiting for forcewake to a
On Sun, Feb 17, 2013 at 3:21 AM, Hugh Dickins wrote:
> On Sat, 16 Feb 2013, Hugh Dickins wrote:
>> On Sat, 16 Feb 2013, Linus Torvalds wrote:
>> >
>> > I think it's worth it to give them a heads-up already. So I've cc'd
>> > the main suspects here..
>>
>> Okay, thanks.
>>
>> >
>> > Daniel, Dave -
https://bugzilla.kernel.org/show_bug.cgi?id=49531
--- Comment #7 from Matthieu Baerts 2013-02-17 13:07:48 ---
Created an attachment (id=93461)
--> (https://bugzilla.kernel.org/attachment.cgi?id=93461)
Kernel Oops with version 3.8-rc7
Hello,
I also have this crash with the version 3.8-rc7
https://bugs.freedesktop.org/show_bug.cgi?id=60995
--- Comment #1 from David Herrmann ---
Created attachment 74974
--> https://bugs.freedesktop.org/attachment.cgi?id=74974&action=edit
GPG public key
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=60995
Priority: medium
Bug ID: 60995
Assignee: dri-devel@lists.freedesktop.org
Summary: Account request for libdrm
Severity: normal
Classification: Unclassified
OS: All
R
While running the WEB-GL tests in [1] firefox crashed a ThinkPad T420 w/ i915
graphic.
The kernel log gives:
2013-02-17T10:32:58.451+01:00 n22 kernel: [drm:__gen6_gt_force_wake_get]
*ERROR* Timed out waiting for forcewake to ack request.
2013-02-17T10:32:58.451+01:00 n22 kernel: [drm:__gen6_gt_
freedesktop.org/archives/dri-devel/attachments/20130217/b14da821/attachment.html>
76 matches
Mail list logo
