expect this to all be
resolved in the glorious atomic mode setting future we've been promised
for so long.
--
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140908/23a26c56/attachment-0001.sig>
ted to this
bug. Please open a new one.
--
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/20140908/9082558c/attachment.html>
Forcing AGP to PCIE mode
So, maybe GTT/GART grows to big?
--
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/20140908/07953c89/attachment-0001.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140908/948974ec/attachment.html>
- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140908/e589b07c/attachment.html>
ause:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140908/877dcc6b/attachment.html>
ause:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140908/915cc220/attachment.html>
vel/attachments/20140908/e0cd0b09/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140908/50a0f1ef/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140908/d0985914/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140908/09a35c9b/attachment-0001.html>
ting:
drm-radeon-fix-display-handling-in-radeon_gpu_reset.patch
Any ideas, Alex/Christian?
--
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-dev
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140908/e35fe616/attachment.html>
Le 02/05/2014 00:52, Martin Peres a ?crit :
> Hello,
>
> I have the pleasure to announce that the X.org Developer Conference 2014
> will
> be held in Bordeaux, France from October 8th to October 10th. The venue is
> located in the campus of the University of Bordeaux 1, in the computer
> science
>
On Mon, Sep 08, 2014 at 04:59:42PM +0300, Ville Syrj?l? wrote:
> On Fri, Sep 05, 2014 at 05:04:45PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > This is the beginning of the work to prepare i915 for the upcoming
> > atomic modesetting API. Here we split the plane update fucntio
On Thu, Sep 4, 2014 at 8:44 AM, Andy Shevchenko
wrote:
> There is no need to use hex_dump_to_buffer() since we have a kernel helper to
> dump up to 64 bytes just via printk(). In our case the actual size is 15
> bytes.
>
> Signed-off-by: Andy Shevchenko
Patch generates the following warning:
L:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140908/a8eb5bc3/attachment-0001.html>
On 06.09.2014 01:49, Mikael Pettersson wrote:
> Michel D?nzer writes:
> > On 30.08.2014 22:59, Mikael Pettersson wrote:
> > > Since 3.17-rc1 my radeon card (RV370 / X1050 card) causes screen
> corruption
> > > after a while in X + firefox. This still occurs with yesterday's HEAD
> > > of
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140908/d0a7e183/attachment.html>
is 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/20140908/fe1d0554/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=83651
--- Comment #4 from Garri ---
Created attachment 149461
--> https://bugzilla.kernel.org/attachment.cgi?id=149461&action=edit
journalctl -b _EXE=/usr/bin/Xorg _PID=7729
--
You are receiving this mail because:
You are watching the assignee of th
https://bugzilla.kernel.org/show_bug.cgi?id=83651
--- Comment #3 from Garri ---
Created attachment 149451
--> https://bugzilla.kernel.org/attachment.cgi?id=149451&action=edit
journalctl -b _EXE=/usr/bin/Xorg _PID=2217
--
You are receiving this mail because:
You are watching the assignee of th
https://bugzilla.kernel.org/show_bug.cgi?id=83651
--- Comment #2 from Garri ---
Created attachment 149441
--> https://bugzilla.kernel.org/attachment.cgi?id=149441&action=edit
journalctl -b -k
--
You are receiving this mail because:
You are watching the assignee of the bug.
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140908/ba3bfbdd/attachment.html>
org/archives/dri-devel/attachments/20140908/ebd11331/attachment.html>
On Fri, Sep 05, 2014 at 05:04:45PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> This is the beginning of the work to prepare i915 for the upcoming
> atomic modesetting API. Here we split the plane update fucntions in
> the check and commit states.
>
> v2: use struct intel_plane_stat
vel/attachments/20140908/f3d52c87/attachment.html>
On Fri, Sep 05, 2014 at 05:04:45PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> This is the beginning of the work to prepare i915 for the upcoming
> atomic modesetting API. Here we split the plane update fucntions in
> the check and commit states.
>
> v2: use struct intel_plane_stat
* Jyri Sarha [140818 14:49]:
> Add external clock provider for am33xx devices.
Please send all the .dts and defconfig changes separately
so I can pick them up and we don't get pointless merge
conflicts.
Regards,
TOny
> Signed-off-by: Jyri Sarha
> ---
> arch/arm/boot/dts/am33xx.dtsi | 10 ++
done in the preclose. The
performance is not an issue here, so I went for "better safe than sorry".
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140908/64d19aba/attachment-0001.sig>
e flush_workqueue
there. We have two things to wait for: work on the workqueue and work
which is triggered by the vsync irq. So we loop and test for both of
those, until there's no more work.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.a
llish fixes to the driver for now.
How about only unlocking/locking the crtc->mutex as Rob suggested? I
think it should work, but I didn't try it yet. Would that be as bad for
the locking rework?
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140908/ccfea5f8/attachment-0001.sig>
On Mon, Sep 08, 2014 at 09:39:40AM -0400, Rob Clark wrote:
> On Mon, Sep 8, 2014 at 9:24 AM, Daniel Vetter wrote:
> > On Mon, Sep 08, 2014 at 03:53:18PM +0300, Tomi Valkeinen wrote:
> >> On 03/09/14 17:25, Daniel Vetter wrote:
> >> > On Wed, Sep 03, 2014 at 02:55:05PM +0300, Tomi Valkeinen wrote:
On Mon, Sep 08, 2014 at 02:57:23PM +0200, Thomas Hellstrom wrote:
> On 09/08/2014 09:03 AM, Daniel Vetter wrote:
> > At driver init no one can access modeset objects and we're
> > single-threaded. So locking is just cargo-culting here. Worse, with
> > the new ww mutexes and ww mutex slowpath debugg
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140908/e17483c7/attachment.html>
4670]"
(ChipID = 0x9490)
--
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/20140908/4bbd087b/attachment-0001.html>
On Mon, Sep 08, 2014 at 04:03:18PM +0300, Tomi Valkeinen wrote:
> On 03/09/14 17:27, Daniel Vetter wrote:
> > On Wed, Sep 03, 2014 at 02:55:08PM +0300, Tomi Valkeinen wrote:
> >> omap_crtc_flush() is used to wait for scheduled work to be done for the
> >> give crtc. However, it's not quite right at
On Mon, Sep 08, 2014 at 03:53:18PM +0300, Tomi Valkeinen wrote:
> On 03/09/14 17:25, Daniel Vetter wrote:
> > On Wed, Sep 03, 2014 at 02:55:05PM +0300, Tomi Valkeinen wrote:
> >> Currently modesetting is not done synchronously, but it queues work that
> >> is done later. In theory this is fine, but
On 09/08/2014 09:03 AM, Daniel Vetter wrote:
> At driver init no one can access modeset objects and we're
> single-threaded. So locking is just cargo-culting here. Worse, with
> the new ww mutexes and ww mutex slowpath debugging the mutex_lock
> might actually fail, and we don't have the full-blown
---
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140908/0dd44acb/attachment.sig>
Hi!
On 09/08/2014 02:01 PM, Emil Velikov wrote:
> Hi Josh
>
> On 05/09/14 18:19, Josh Boyer wrote:
>> The userspace drm.h include doesn't prefix the drm directory. This can lead
>> to compile failures as /usr/include/drm/ isn't in the standard gcc include
>> paths. Fix it to be , which matches t
On Mon, Sep 08, 2014 at 01:10:59PM +0200, Jakob Bornecrantz wrote:
> On Sun, Sep 7, 2014 at 11:29 PM, Emil Velikov
> wrote:
> > Hello list,
> >
> > Here is the final batch that I've been planning to get upstreamed.
> > Everything else that remains are some custom downstream "hacks" that
> > will
On 08/09/14 13:15, Thomas Hellstrom wrote:
> Hi!
>
> On 09/08/2014 02:01 PM, Emil Velikov wrote:
[snip]
>>
>> To the VMware guys,
>>
>> Any objections if we update the libdrm header and drop the mesa/ddx copies ?
>>
>> Cheers,
>> Emil
> Hi!
>
> vmwgfx libdrm is pretty obsolete and AFAIK not used
rm/radeon_drm.h
>> @@ -803,6 +803,8 @@ struct drm_radeon_gem_info {
>> #define RADEON_GEM_GTT_WC(1 << 2)
>> /* BO is expected to be accessed by the CPU */
>> #define RADEON_GEM_CPU_ACCESS(1 << 3)
>> +/* BO is expected to not be accessed by the CPU */
>> +#define RADEON_GEM_NO_CPU_ACCESS (1 << 4)
>
> I'd use stronger wording for this, e.g.
>
> /* CPU access is not expected to work for this BO */
Updated version with comments integrated.
Alex
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-add-RADEON_GEM_NO_CPU_ACCESS-BO-creation-.patch
Type: text/x-diff
Size: 1882 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140908/3fc2b801/attachment.patch>
On 08/09/14 13:14, Josh Boyer wrote:
> On Mon, Sep 8, 2014 at 8:01 AM, Emil Velikov
> wrote:
[snip]
>> Any objections if we update the libdrm header and drop the mesa/ddx copies ?
>>
>> Cheers,
>> Emil
>>
>> P.S. I'm against the patch in any way :)
>
> Was that meant to say "I'm not against the
On Sun, Sep 7, 2014 at 6:06 AM, Christian K?nig
wrote:
> From: Christian K?nig
>
> Semaphore values have 64 bits, not 32. This fixes a very subtle bug
> that disables synchronization when the upper 32bits wasn't zero.
>
> Signed-off-by: Christian K?nig
> Cc: stable at vger.kernel.org
Applied t
y if disabling also fixes
it.
--
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/20140908/c9209224/attachment.html>
On Sun, Sep 7, 2014 at 11:29 PM, Emil Velikov
wrote:
> Hello list,
>
> Here is the final batch that I've been planning to get upstreamed.
> Everything else that remains are some custom downstream "hacks" that
> will get upstreamed by their original authors in due time :)
>
>
> Highlights:
> - Dr
Hi Josh
On 05/09/14 18:19, Josh Boyer wrote:
> The userspace drm.h include doesn't prefix the drm directory. This can lead
> to compile failures as /usr/include/drm/ isn't in the standard gcc include
> paths. Fix it to be , which matches the rest of the driver drm
> header files that get install
On Tue, Jul 29, 2014 at 11:57:06AM +0200, Philipp Zabel wrote:
> For the overlay plane scanning out a framebuffer with an alpha component,
> enable the DP local alpha feature on the partial plane.
>
> Signed-off-by: Philipp Zabel
> ---
> drivers/staging/imx-drm/ipuv3-plane.c | 12 ++--
>
Michel D?nzer writes:
> On 06.09.2014 01:49, Mikael Pettersson wrote:
> > Michel D?nzer writes:
> > > On 30.08.2014 22:59, Mikael Pettersson wrote:
> > > > Since 3.17-rc1 my radeon card (RV370 / X1050 card) causes screen
> > corruption
> > > > after a while in X + firefox. This still
https://bugzilla.kernel.org/show_bug.cgi?id=78221
--- Comment #21 from t3st3r at mail.ru ---
2) About 3.17... I attempted 3.17-rc1 and it crashed in about 30 seconds of run
of problematic work.
I will try newer -RCs as well, as I can see there were some extra changes to
radeon-related code.
--
https://bugzilla.kernel.org/show_bug.cgi?id=78221
--- Comment #20 from t3st3r at mail.ru ---
1) About 3.15 + patch: I gave it a try and it took quite a while to get opinion
about it. Overall it is quite stable and survives about several days of run of
problematic load. But eventually GPU still cou
On Sun, Sep 7, 2014 at 11:30 PM, Emil Velikov
wrote:
> Signed-off-by: Emil Velikov
> ---
> configure.ac | 3 +++
> libkms/Makefile.am | 5 -
> libkms/linux.c | 16 +++-
> 3 files changed, 18 insertions(+), 6 deletions(-)
Reviewed-by: Jakob Bornecrantz
Cheers, Jako
On Sun, Sep 7, 2014 at 11:30 PM, Emil Velikov
wrote:
> Cc: Benjamin Gaignard
> Signed-off-by: Emil Velikov
> ---
> Android.mk| 3 ++-
> libkms/Android.mk | 53 +
> 2 files changed, 55 insertions(+), 1 deletion(-)
> create mode 10064
On Mon, Sep 08, 2014 at 12:08:59PM -0700, Greg Kroah-Hartman wrote:
> On Mon, Sep 01, 2014 at 06:07:12PM +0100, Russell King - ARM Linux wrote:
> > Greg,
> >
> > Here's two oops fixes for imx-drm, which I've had queued up for a number
> > of months now. Shawn posted different fixes for the same o
On Mon, Sep 01, 2014 at 06:07:12PM +0100, Russell King - ARM Linux wrote:
> Greg,
>
> Here's two oops fixes for imx-drm, which I've had queued up for a number
> of months now. Shawn posted different fixes for the same oops recently
> as well.
So do I take your patches, or Shawn's?
confused,
gr
Enable LCD related nodes.
Signed-off-by: Boris BREZILLON
---
arch/arm/boot/dts/sama5d31ek.dts | 20
arch/arm/boot/dts/sama5d33ek.dts | 20
arch/arm/boot/dts/sama5d34ek.dts | 20
arch/arm/boot/dts/sama5d36ek.dts | 20 +
Add LCD panel related nodes (backlight, regulators and panel) to sama5d3
Display Module dtsi.
Reference LCD pin muxing used by sama5d3xek boards.
Signed-off-by: Boris BREZILLON
---
arch/arm/boot/dts/sama5d3xdm.dtsi | 58 +++
1 file changed, 58 insertions(+)
Define the HLCDC (HLCD Controller) IP available on some sama5d3 SoCs
(i.e. sama5d31, sama5d33, sama5d34 and sama5d36) in sama5d3 dtsi file.
Signed-off-by: Boris BREZILLON
---
arch/arm/boot/dts/sama5d3_lcd.dtsi | 28
1 file changed, 28 insertions(+)
diff --git a/arch
Define alternative pin muxing for the LCDC pins.
Signed-off-by: Boris BREZILLON
---
arch/arm/boot/dts/sama5d3_lcd.dtsi | 50 ++
1 file changed, 50 insertions(+)
diff --git a/arch/arm/boot/dts/sama5d3_lcd.dtsi
b/arch/arm/boot/dts/sama5d3_lcd.dtsi
index 2186b8
The HLCDC (HLCD Controller) IP supports 4 different output mode (RGB444,
RGB565, RGB666 and RGB888) and the pin muxing will depend on the chosen
RGB mode.
Split pin definitions to be able to set pin config according to the
selected mode.
Signed-off-by: Boris BREZILLON
---
arch/arm/boot/dts/sama
The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e.
at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display
controller device.
The HLCDC block provides a single RGB output port, and only supports LCD
panels connection to LCD panels for now.
The atmel,panel propert
The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e.
at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display
controller device.
This display controller supports at least one primary plane and might
provide several overlays and an hardware cursor depending on the IP
The HLCDC IP available in some Atmel SoCs (i.e. sam9x5i.e. at91sam9n12,
at91sam9x5 family or sama5d3 family) provide a PWM device.
The DT bindings used for this PWM device is following the default 3 cells
bindings described in Documentation/devicetree/bindings/pwm/pwm.txt.
Signed-off-by: Boris BR
The HLCDC IP available in some Atmel SoCs (i.e. sam9x5i.e. at91sam9n12,
at91sam9x5 family or sama5d3 family) provide a PWM device.
This driver add support for a PWM chip exposing a single PWM device (which
will most likely be used to drive a backlight device).
Signed-off-by: Boris BREZILLON
---
The HLCDC IP available on some Atmel SoCs (i.e. at91sam9n12, at91sam9x5
family or sama5d3 family) exposes 2 subdevices:
- a display controller (controlled by a DRM driver)
- a PWM chip
This patch adds documentation for atmel-hlcdc DT bindings.
Signed-off-by: Boris BREZILLON
---
.../devicetree/b
The HLCDC IP available on some Atmel SoCs (i.e. at91sam9n12, at91sam9x5
family or sama5d3 family) exposes 2 subdevices:
- a display controller (controlled by a DRM driver)
- a PWM chip
The MFD device provides a regmap and several clocks (those connected
to this hardware block) to its subdevices.
Hello,
This patch series adds support for Atmel HLCDC (HLCD Controller) available
on some Atmel SoCs (i.e. the sama5d3 family).
The HLCDC actually provides a Display Controller and a PWM device, hence I
decided to declare an MFD device exposing 2 subdevices: a display
controller and a PWM chip.
T
On 07.09.2014 01:01, Christoph Brill wrote:
>
> I'm currently trying to get a HD 4670 aka RV730 XT to work against X.org
> 1.16, xf86-video-ati 7.4.0 on a Linux 3.16.1.
>
> Can anyone tell me: Should this card be able to handle an average Gnome
> desktop?
Of course.
> The problem was: 3D renderi
On Fri, 2014-09-05 at 15:13 -0700, Greg Kroah-Hartman wrote:
> > + /*
> > +* this seems racy, but I don't see a notifier or such on
> > +* a struct device to know when it goes away?
> > +*/
> > + if (devcd->failing_dev->kobj.sd)
> > + sysfs_delete_link(&devcd->failing_dev
On 09/05/14 10:50, Johannes Berg wrote:
> From: Johannes Berg
>
> Many devices run firmware and/or complex hardware, and most of that
> can have bugs. When it misbehaves, however, it is often much harder
> to debug than software running on the host.
>
> Introduce a "device coredump" mechanism to al
Am 07.09.2014 um 19:41 schrieb Grigori Goronzy:
> On 07.09.2014 12:06, Christian K?nig wrote:
>> From: Christian K?nig
>>
>> Semaphore values have 64 bits, not 32. This fixes a very subtle bug
>> that disables synchronization when the upper 32bits wasn't zero.
>>
> So essentially, half the semapho
On Mon, Sep 8, 2014 at 9:50 AM, Daniel Vetter wrote:
> On Mon, Sep 08, 2014 at 09:39:40AM -0400, Rob Clark wrote:
>> On Mon, Sep 8, 2014 at 9:24 AM, Daniel Vetter wrote:
>> > On Mon, Sep 08, 2014 at 03:53:18PM +0300, Tomi Valkeinen wrote:
>> >> On 03/09/14 17:25, Daniel Vetter wrote:
>> >> > On W
On Mon, Sep 8, 2014 at 9:24 AM, Daniel Vetter wrote:
> On Mon, Sep 08, 2014 at 03:53:18PM +0300, Tomi Valkeinen wrote:
>> On 03/09/14 17:25, Daniel Vetter wrote:
>> > On Wed, Sep 03, 2014 at 02:55:05PM +0300, Tomi Valkeinen wrote:
>> >> Currently modesetting is not done synchronously, but it queue
On 2014.09.07 at 23:47 -0400, Alex Deucher wrote:
> On Sun, Sep 7, 2014 at 9:24 AM, Markus Trippelsdorf
> wrote:
> > On 2014.08.25 at 11:10 +0200, Christian K?nig wrote:
> >> Let me know if it works for you, cause we don't really have any hardware
> >> any more to test it.
> >
> > I've tested your
At driver init no one can access modeset objects and we're
single-threaded. So locking is just cargo-culting here. Worse, with
the new ww mutexes and ww mutex slowpath debugging the mutex_lock
might actually fail, and we don't have the full-blown ww recovery
dance.
Which then leads to fireworks wh
On 09/07/2014 05:02 PM, Rob Clark wrote:
> On Fri, Sep 5, 2014 at 8:25 AM, Daniel Vetter wrote:
>> On Fri, Sep 05, 2014 at 07:59:45AM -0400, Rob Clark wrote:
>>> While in real life, we could never fail to grab the newly created mutex,
>>> ww_mutex fault injection has no way to know this. Which co
On Mon, Sep 8, 2014 at 7:27 AM, Michael N. Henry
wrote:
> crtc->mutex is acquired in drm_modeset_lock_crtc(). The next call
> to drm_modeset_unlock_crt() would not unlock it, causing a deadlock
> during the next call to drm_modest_lock_crtc().
> ---
> drivers/gpu/drm/drm_modeset_lock.c | 2 ++
>
On Mon, Sep 8, 2014 at 8:01 AM, Emil Velikov
wrote:
> Hi Josh
>
> On 05/09/14 18:19, Josh Boyer wrote:
>> The userspace drm.h include doesn't prefix the drm directory. This can lead
>> to compile failures as /usr/include/drm/ isn't in the standard gcc include
>> paths. Fix it to be , which matc
hments/20140908/1a32e18c/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=83531
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1 fr
iving 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/20140908/d3e43a8c/attachment-0001.html>
dri-devel/attachments/20140908/6be170e4/attachment.html>
log.
--
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/20140908/e32e107c/attachment.html>
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/20140908/79bda17e/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=83461
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1 fr
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140908/7eb4439f/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140908/5df297ee/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=83651
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1 fr
https://bugzilla.kernel.org/show_bug.cgi?id=83861
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1 fr
ely the same as disabling dpm.
--
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/20140908/af2f7d3e/attachment.html>
On Fri, Aug 29, 2014 at 6:12 AM, David Herrmann
wrote:
> Radeon UMS is the last user of drm_buffer. Move it out of sight so radeon
> can drop it together with UMS.
>
> Signed-off-by: David Herrmann
Reviewed-by: Alex Deucher
We can probably dump radeon UMS support as well at this point.
Alex
93 matches
Mail list logo
