[Bug 71090] pp_free () from /usr/X11R6/lib/modules/dri/r600_dri.so
https://bugs.freedesktop.org/show_bug.cgi?id=71090 --- Comment #1 from Alex Deucher --- Is this still an issue with a newer version of mesa? -- 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/20140209/7b0132a1/attachment.html>
[Bug 65730] no sound via HDMI for Radeon 6850
https://bugs.freedesktop.org/show_bug.cgi?id=65730 --- Comment #12 from Alex Deucher --- Is this still an issue with a newer kernel? -- 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/20140209/49c26ec6/attachment.html>
[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1
https://bugzilla.kernel.org/show_bug.cgi?id=68571 --- Comment #27 from Alex Deucher --- dpm is disabled by default again on these asics until we fix this issue. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 74764] Steam overlay not working
https://bugs.freedesktop.org/show_bug.cgi?id=74764 --- Comment #1 from Thomas Rohloff --- Forgot to say: This is on a HD 6950. Can't test other cards as I own that one only. Would be nice if others could test (also nouveau/intel) to see if that's really radeon only. -- 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/20140209/517a5a2d/attachment.html>
[Bug 74764] New: Steam overlay not working
https://bugs.freedesktop.org/show_bug.cgi?id=74764 Priority: medium Bug ID: 74764 Assignee: dri-devel at lists.freedesktop.org Summary: Steam overlay not working Severity: normal Classification: Unclassified OS: Linux (All) Reporter: v10lator at myway.de Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa I switched from stable to git and since then the Steam overlay is not working anymore. I tested it with two games (Rust and Worms Reloaded) but could test it with more if needed. With not working I mean exactly this. The message that it's enabled and you have to type shift + tab to open is doesn't show up, also shift + tab or F12 (taking screenshot) does nothing. I may try to bisect it later but am not sure if I'll find the time. -- 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/20140209/ef982fac/attachment.html>
GeForce 6100 (NV4E) & nouveau regression in 3.12
= MAC=33:33:00:00:00:fb:1c:ab:a7:e7:23:86:86:dd SRC=fe80::::1eab:a7ff:fee7:2386 DST=ff02:::::::00fb LEN=97 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=UDP SPT=5353 DPT=5353 LEN=57 [ 925.574982] SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=33:33:00:00:00:fb:1c:ab:a7:e7:23:86:86:dd SRC=fe80::::1eab:a7ff:fee7:2386 DST=ff02:::::::00fb LEN=97 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=UDP SPT=5353 DPT=5353 LEN=57 -- next part -- A non-text attachment was scrubbed... Name: konsole-pink.png Type: image/png Size: 26266 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140209/4410711b/attachment-0001.png>
[PATCH] drm/ttm: declare 'struct device' in ttm_page_alloc.h
Declare 'struct device' explicitly in ttm_page_alloc.h as this file does not include any file declaring it. This removes the following warning: warning: 'struct device' declared inside parameter list Signed-off-by: Alexandre Courbot --- This warning was visible when compiling Nouveau on -next today. include/drm/ttm/ttm_page_alloc.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/drm/ttm/ttm_page_alloc.h b/include/drm/ttm/ttm_page_alloc.h index d1f61bf..49a8284 100644 --- a/include/drm/ttm/ttm_page_alloc.h +++ b/include/drm/ttm/ttm_page_alloc.h @@ -29,6 +29,8 @@ #include #include +struct device; + /** * Initialize pool allocator. */ -- 1.8.5.4
DRM Hotplug
Hi On Sat, Feb 8, 2014 at 1:16 AM, Rian Quinn wrote: > I noticed that the hotplug IOTCLs were removed. How are monitor hotplug > events captured? You get a "change"-uevent on the card-node. Use libudev with udev_monitor to listen for them. Hotplug-events will have HOTPLUG=1 as uevent-variable. Thanks David
[Bug 73191] [radeonsi] vdpau playback issues, skipping & looping
https://bugs.freedesktop.org/show_bug.cgi?id=73191 --- Comment #33 from Eric Valette --- Just to confirm, I have a kabini chipset with Libux kernel 3.13.2, mesa rc1 + the last two flush patches I got from this thread applied, and XBMC with amd surface patch from amd branch and still have exactly the same symptoms as described in the beginning of the bug (short video sequence repeating itself and then jumping to a new sequence). When I disable vdpau mixer all is fine. -- 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/20140209/6a8203d6/attachment.html>
GeForce 6100 (NV4E) & nouveau regression in 3.12
On Sun, Feb 9, 2014 at 5:08 PM, Rafa? Mi?ecki wrote: > Hi guys, > > Last week I've switched from my old & good 3.4.63 to 3.14-rc1 and > noticed nasty display corruptions when using nouveau. It seems that > changing parts of the screen are appearing for a fraction of second in > random places. I've recorded this behavior: > http://www.youtube.com/watch?v=IEq7JzGVzj0 > > My hardware is some old motherboard with > 00:05.0 VGA compatible controller [0300]: NVIDIA Corporation C51G > [GeForce 6100] [10de:0242] (rev a2) > integrated. Since my CPU is ancient AMD Sempron(tm) Processor 2800+ it > took me few days to track this issue. > > There goes some summary of various kernels: > > 1) 3.4.63 > No display problems. Works great. > > 2) commit 928c2f0c006bf7f381f58af2b2786d2a858ae311 > drm/fb-helper: don't sleep for screen unblank when an oops is in progress > Scrollbars have a pink line. I didn't track which commit introduced > this pink corruption. No other problems. > > 3) commit c21eb21cb50d58e7cbdcb8b9e7ff68b85cfa5095 > Revert "drm: mark context support as a legacy subsystem" > This fixes pink lines on scrollbars and introduces this nasty display > corruption. It's one commit after previous one. > It means it's the first bad commit for these nasty corruptions recoded > and uploaded to YouTube. > > 4) 3.14-rc1 > No changes since c21eb21cb50d58e7cbdcb8b9e7ff68b85cfa5095. No pink > lines, but display corruptions happening. Can you boot with nouveau.config=NvMSI=0 ? If that helps, there are some patches on the nouveau/dri-devel lists (search for "nv4c") that may help you. -ilia
[PATCH 2/2] drm/nouveau/abi16: fix handles past the 32nd one
abi16->handles is a u64, so make sure to use 1ULL << val when modifying.
Signed-off-by: Ilia Mirkin
---
Noticed this when doing the previous patch. I'm not sure whether this affects
64-bit builds or not, didn't care to look at the assembly or check the
standard.
drivers/gpu/drm/nouveau/nouveau_abi16.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c
b/drivers/gpu/drm/nouveau/nouveau_abi16.c
index b701117..66abf4d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
+++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
@@ -139,7 +139,7 @@ nouveau_abi16_chan_fini(struct nouveau_abi16 *abi16,
/* destroy channel object, all children will be killed too */
if (chan->chan) {
- abi16->handles &= ~(1 << (chan->chan->handle & 0x));
+ abi16->handles &= ~(1ULL << (chan->chan->handle & 0x));
nouveau_channel_del(>chan);
}
@@ -280,7 +280,7 @@ nouveau_abi16_ioctl_channel_alloc(ABI16_IOCTL_ARGS)
INIT_LIST_HEAD(>notifiers);
list_add(>head, >channels);
- abi16->handles |= (1 << init->channel);
+ abi16->handles |= (1ULL << init->channel);
/* create channel object and initialise dma and fence management */
ret = nouveau_channel_new(drm, cli, NVDRM_DEVICE, NVDRM_CHAN |
--
1.8.3.2
[PATCH 1/2] drm/nouveau: replace ffsll with __ffs64
The ffsll function is a lot slower than the __ffs64 built-in which
compiles to a single instruction on 64-bit. It's also nice to avoid
custom versions of standard functions. Note that __ffs == ffs - 1.
Signed-off-by: Ilia Mirkin
---
I wrote a user-space program to test these out and make sure that the
functions behaved as expected. The logic in abi16 had to be flipped around a
bit since __ffs doesn't distinguish between 0 and 1. There's a minor
difference in that init->channel is going to get returned as 0 for ENOSPC vs
-1, but I can't imagine that'd matter.
drivers/gpu/drm/nouveau/core/core/parent.c | 2 +-
drivers/gpu/drm/nouveau/core/os.h | 11 ---
drivers/gpu/drm/nouveau/nouveau_abi16.c| 4 ++--
3 files changed, 3 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/core/parent.c
b/drivers/gpu/drm/nouveau/core/core/parent.c
index 313380c..dee5d12 100644
--- a/drivers/gpu/drm/nouveau/core/core/parent.c
+++ b/drivers/gpu/drm/nouveau/core/core/parent.c
@@ -49,7 +49,7 @@ nouveau_parent_sclass(struct nouveau_object *parent, u16
handle,
mask = nv_parent(parent)->engine;
while (mask) {
- int i = ffsll(mask) - 1;
+ int i = __ffs64(mask);
if (nv_iclass(parent, NV_CLIENT_CLASS))
engine = nv_engine(nv_client(parent)->device);
diff --git a/drivers/gpu/drm/nouveau/core/os.h
b/drivers/gpu/drm/nouveau/core/os.h
index 191e739..3cd6120 100644
--- a/drivers/gpu/drm/nouveau/core/os.h
+++ b/drivers/gpu/drm/nouveau/core/os.h
@@ -23,17 +23,6 @@
#include
-static inline int
-ffsll(u64 mask)
-{
- int i;
- for (i = 0; i < 64; i++) {
- if (mask & (1ULL << i))
- return i + 1;
- }
- return 0;
-}
-
#ifndef ioread32_native
#ifdef __BIG_ENDIAN
#define ioread16_native ioread16be
diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c
b/drivers/gpu/drm/nouveau/nouveau_abi16.c
index 900fae0..b701117 100644
--- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
+++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
@@ -270,8 +270,8 @@ nouveau_abi16_ioctl_channel_alloc(ABI16_IOCTL_ARGS)
return nouveau_abi16_put(abi16, -EINVAL);
/* allocate "abi16 channel" data and make up a handle for it */
- init->channel = ffsll(~abi16->handles);
- if (!init->channel--)
+ init->channel = __ffs64(~abi16->handles);
+ if (~abi16->handles == 0)
return nouveau_abi16_put(abi16, -ENOSPC);
chan = kzalloc(sizeof(*chan), GFP_KERNEL);
--
1.8.3.2
[Bug 74717] r600g: 'invalid read' linking geometry shader
https://bugs.freedesktop.org/show_bug.cgi?id=74717 --- Comment #6 from kwahoo2 at wp.pl --- (In reply to comment #5) > > You need to run it from the source root, like this: > > $ build/build/release/gl-320-primitive-shading > > build/release/gl-320-primitive-shading Right, now the examples works. Except gl-320-primitive-shading ./build/release/gl-320-primitive-shading OpenGL Version Needed 3.2 ( 3.3 Found ) Compiling shader gl-320/primitive-shading.vert... Compiling shader gl-320/primitive-shading.geom... Compiling shader gl-320/primitive-shading.frag... Segmentation fault -- 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/20140209/578d6a10/attachment.html>
[Bug 73785] Team Fortress 2 causes random GPU stalls on radeonsi with dpm enabled
https://bugs.freedesktop.org/show_bug.cgi?id=73785 --- Comment #4 from Lukas Kahnert --- I have the same Problem but it doesn't matter if DPM is enabled or not. I can reproduce this Bug when i play on the map "Ghost Town"(Wave 666). Always when the Tanks are comming and I going to them the GPU hangs. On other maps its more or less random. Every component was build yesterday Linux 3.14-rc1(drm-fixes branch) LLVM 3.5-svn Mesa 10.2-devel git xorg 1.15.0 glamor 0.6 PS: Sorry for my bad English >_< -- 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/20140209/4ad6ff63/attachment.html>
[Bug 74717] r600g: 'invalid read' linking geometry shader
https://bugs.freedesktop.org/show_bug.cgi?id=74717 --- Comment #5 from T?r?k Edwin <edwin+mesa at etorok.net> --- (In reply to comment #4) > (In reply to comment #3) > > G-truck samples don't work for me too (similar error for ether samples): > > > > ./gl-320-primitive-shading > > OpenGL Version Needed 3.2 ( 3.3 Found ) > > Shader Compiler: error(high) 2: 0:1(1): error: syntax error, unexpected $end > > Shader Compiler: error(high) 3: 0:1(1): error: syntax error, unexpected $end > > Shader Compiler: error(high) 4: 0:1(1): error: syntax error, unexpected $end > > You need to run it from the source root, like this: > $ build/build/release/gl-320-primitive-shading build/release/gl-320-primitive-shading -- 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/20140209/eac800a8/attachment.html>
[Bug 74717] r600g: 'invalid read' linking geometry shader
https://bugs.freedesktop.org/show_bug.cgi?id=74717 --- Comment #4 from T?r?k Edwin <edwin+mesa at etorok.net> --- (In reply to comment #3) > G-truck samples don't work for me too (similar error for ether samples): > > ./gl-320-primitive-shading > OpenGL Version Needed 3.2 ( 3.3 Found ) > Shader Compiler: error(high) 2: 0:1(1): error: syntax error, unexpected $end > Shader Compiler: error(high) 3: 0:1(1): error: syntax error, unexpected $end > Shader Compiler: error(high) 4: 0:1(1): error: syntax error, unexpected $end You need to run it from the source root, like this: $ build/build/release/gl-320-primitive-shading Otherwise it can't find/load the shader, and thats a shortcoming in the samples, not Mesa. -- 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/20140209/b5c262b4/attachment.html>
[PATCH] drm/tegra: fix typo 'CONFIG_TEGRA_DRM_FBDEV'
Signed-off-by: Paul Bolle
---
Entirely untested. But it's clear that this is what was intended.
drivers/gpu/drm/tegra/drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 88a5290..c715947 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -104,7 +104,7 @@ static void tegra_drm_context_free(struct tegra_drm_context
*context)
static void tegra_drm_lastclose(struct drm_device *drm)
{
-#ifdef CONFIG_TEGRA_DRM_FBDEV
+#ifdef CONFIG_DRM_TEGRA_FBDEV
struct tegra_drm *tegra = drm->dev_private;
tegra_fbdev_restore_mode(tegra->fbdev);
--
1.8.5.3
[Bug 71239] Metro Last Light quits(?) on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=71239 --- Comment #18 from kwahoo2 at wp.pl --- Could be connected with https://bugs.freedesktop.org/show_bug.cgi?id=74717 ? Both uses GL3.2 features. -- 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/20140209/53daacad/attachment.html>
[Bug 74717] r600g: 'invalid read' linking geometry shader
https://bugs.freedesktop.org/show_bug.cgi?id=74717 --- Comment #3 from kwahoo2 at wp.pl --- G-truck samples don't work for me too (similar error for ether samples): ./gl-320-primitive-shading OpenGL Version Needed 3.2 ( 3.3 Found ) Shader Compiler: error(high) 2: 0:1(1): error: syntax error, unexpected $end Shader Compiler: error(high) 3: 0:1(1): error: syntax error, unexpected $end Shader Compiler: error(high) 4: 0:1(1): error: syntax error, unexpected $end Compiling shader gl-320/primitive-shading.vert... 0:1(1): error: syntax error, unexpected $end Running Test Test Ended glxinfo | grep OpenGL OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD TURKS OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.2.0-devel (git-020c43f saucy-oibaf-ppa) OpenGL core profile shading language version string: 3.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 10.2.0-devel (git-020c43f saucy-oibaf-ppa) OpenGL shading language version string: 1.30 OpenGL context flags: (none) 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Turks XT [Radeon HD 6670/7670] -- 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/20140209/84ceff55/attachment.html>
[Bug 68451] Texture flicker in native Dota2 in mesa 9.2.0rc1
https://bugs.freedesktop.org/show_bug.cgi?id=68451 --- Comment #57 from Tilman Sauerbeck --- Alright, that fixed the CS rejections as expected. However the Mesa patch doesn't fix the flickering. -- 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/20140209/68f00665/attachment.html>
[PATCH RFC 0/2] drivers/base: simplify simple DT-based components
On Sun, Feb 09, 2014 at 10:22:19AM +0100, Jean-Francois Moine wrote: > On Fri, 7 Feb 2014 20:23:51 + > Russell King - ARM Linux wrote: > > > Here's my changes to the TDA998x driver to add support for the component > > helper. The TDA998x driver retains support for the old way so that > > drivers can be transitioned. For any one DRM "card" the transition to > > I rewrote the tda998x as a simple encoder+connector (i.e. not a > slave_encoder) with your component helper, and the code is much clearer > and simpler: the DRM driver has nothing to do except to know that the > tda998x is a component and to set the possible_crtcs. That's exactly what I've done - the slave encoder veneer can be simply deleted when tilcdc is converted. > AFAIK, only the tilcdc drm driver is using the tda998x as a > slave_encoder. It does a (encoder+connector) conversion to > (slave_encoder). Then, in your changes in the TDA998x, you do a > (slave_encoder) translation to (encoder+connector). > This seems rather complicated! No. I first split out the slave encoder functions to be a veneer onto the tda998x backend, and then add the encoder & connector component support. Later, the slave encoder veneer can be deleted. The reason for this is that virtually all the tda998x backend is what's required by the encoder & connector support - which is completely logical when you realise that the generic slave encoder support is just a veneer itself adapting the encoder & connector support to a slave encoder. So, we're basically getting rid of two veneers, but we end up with exactly the same functionality. > > And yes, I'm thinking that maybe moving compare_of() into the component > > support so that drivers can share this generic function may be a good > > idea. > > This function exists already in drivers/of/platform.c as > of_dev_node_match(). It just needs to be exported. Good, thanks for pointing that out. -- FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was "up to 13.2Mbit".
[PATCH v4 02/11] drm: Add support_bits parameter to drm_property_create_bitmask()
On Fri, Feb 7, 2014 at 8:45 AM, wrote:
> From: Ville Syrj?l?
>
> Make drm_property_create_bitmask() a bit more generic by allowing the
> caller to specify which bits are in fact supported. This allows multiple
> callers to use the same enum list, but still create different versions
> of the same property with different list of supported bits.
>
> Signed-off-by: Ville Syrj?l?
> Tested-by: Sagar Kamble
very minor nit here: this patch probably should fix up the callers of
this fxn for bisectability. Although it could be the only other
caller was omapdrm which gets converted over to the new API a few
patches later..
with that,
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/drm_crtc.c | 6 +-
> include/drm/drm_crtc.h | 3 ++-
> 2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 3b7d32d..628d3d3 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -2906,7 +2906,8 @@ EXPORT_SYMBOL(drm_property_create_enum);
> struct drm_property *drm_property_create_bitmask(struct drm_device *dev,
> int flags, const char *name,
> const struct drm_prop_enum_list
> *props,
> -int num_values)
> +int num_values,
> +unsigned int supported_bits)
> {
> struct drm_property *property;
> int i, ret;
> @@ -2918,6 +2919,9 @@ struct drm_property *drm_property_create_bitmask(struct
> drm_device *dev,
> return NULL;
>
> for (i = 0; i < num_values; i++) {
> + if (!(supported_bits & (1 << i)))
> + continue;
> +
> ret = drm_property_add_enum(property, i,
> props[i].type,
> props[i].name);
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index d5c46c1..41b86d2 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1070,7 +1070,8 @@ extern struct drm_property
> *drm_property_create_enum(struct drm_device *dev, int
> struct drm_property *drm_property_create_bitmask(struct drm_device *dev,
> int flags, const char *name,
> const struct drm_prop_enum_list
> *props,
> -int num_values);
> +int num_values,
> +unsigned int supported_bits);
> struct drm_property *drm_property_create_range(struct drm_device *dev, int
> flags,
> const char *name,
> uint64_t min, uint64_t max);
> --
> 1.8.5
>
[PATCH v4 04/11] drm/omap: Switch omapdrm over to drm_mode_create_rotation_property()
On Fri, Feb 7, 2014 at 8:45 AM, wrote:
> From: Ville Syrj?l?
>
> Use the new drm_mode_create_rotation_property() in omapdrm.
>
> Signed-off-by: Ville Syrj?l?
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/omapdrm/omap_plane.c | 17 +++--
> 1 file changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c
> b/drivers/gpu/drm/omapdrm/omap_plane.c
> index 046d5e6..fee8f35 100644
> --- a/drivers/gpu/drm/omapdrm/omap_plane.c
> +++ b/drivers/gpu/drm/omapdrm/omap_plane.c
> @@ -300,16 +300,13 @@ void omap_plane_install_properties(struct drm_plane
> *plane,
> if (priv->has_dmm) {
> prop = priv->rotation_prop;
> if (!prop) {
> - const struct drm_prop_enum_list props[] = {
> - { DRM_ROTATE_0, "rotate-0" },
> - { DRM_ROTATE_90, "rotate-90" },
> - { DRM_ROTATE_180, "rotate-180" },
> - { DRM_ROTATE_270, "rotate-270" },
> - { DRM_REFLECT_X, "reflect-x" },
> - { DRM_REFLECT_Y, "reflect-y" },
> - };
> - prop = drm_property_create_bitmask(dev, 0, "rotation",
> - props, ARRAY_SIZE(props));
> + prop = drm_mode_create_rotation_property(dev,
> +
> BIT(DRM_ROTATE_0) |
> +
> BIT(DRM_ROTATE_90) |
> +
> BIT(DRM_ROTATE_180) |
> +
> BIT(DRM_ROTATE_270) |
> +
> BIT(DRM_REFLECT_X) |
> +
> BIT(DRM_REFLECT_Y));
> if (prop == NULL)
> return;
> priv->rotation_prop = prop;
> --
> 1.8.5
>
