date:20130402

https://bugs.freedesktop.org/show_bug.cgi?id=62756

--- Comment #6 from Andy Furniss  ---
(In reply to comment #5)
> No, I don't receive mail from bugzilla until someone add me manually to the
> cc list (dont know what to do to fix that though)

drivers/gallium/r600 bugs get sent to the dri-devel list.

-- 
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/20130402/ff850a65/attachment.html>

[Bug 62756] Rendering errors on rv790 with llvm and unigine heaven 3.0

https://bugs.freedesktop.org/show_bug.cgi?id=62756

--- Comment #5 from vincent  ---
No, I don't receive mail from bugzilla until someone add me manually to the cc
list (dont know what to do to fix that though)

I'm aware of the regression with latest HEAD, I'm working on a fix.
r600g still adds CF_ALU on its own which break CF_CLAUSE address natively
encoded by llvm.

-- 
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/20130402/46101f23/attachment.html>

[PATCH] drm/radeon: UVD support for RV710-SI

On Tue, Apr 2, 2013 at 7:18 PM, Christian K?nig  
wrote:
> Hi everyone,
>
> the following patchset implements the kernel side of UVD support for the 
> radeon hardware generations RV710-SI.
>
> The R6xx and RS780/RS880 chipset generations are currently not supported, but 
> might be added in the future.
>
> The newest firmware can be found here: from 
> http://people.freedesktop.org/~agd5f/radeon_ucode/

To those looking to try this out, you need both the uvd ucode and the
updated rlc ucode.

Alex

[PATCH v2 2/3] mutex: add support for reservation style locks, v2

On Tue, Apr 2, 2013 at 6:59 PM, Peter Zijlstra  
wrote:
>> > Also, is there anything in CS literature that comes close to this? I'd
>> > think the DBMS people would have something similar with their
>> > transactional systems. What do they call it?
>
>> I didn't study cs, but judging from your phrasing I guess you mean you
>> want me to call it transaction_mutexes instead?
>
> Nah, me neither, I just hate reinventing names for something that's
> already got a perfectly fine name under which a bunch of people know
> it.
>
> See the email from Daniel, apparently its known as wound-wait deadlock
> avoidance -- its actually described in the "deadlock" wikipedia
> article.
>
> So how about we call the thing something like:
>
>   struct ww_mutex; /* wound/wait */
>
>   int mutex_wound_lock(struct ww_mutex *); /* returns -EDEADLK */
>   int mutex_wait_lock(struct ww_mutex *);  /* does not fail */

I'm not sold on this prefix, since wound-wait is just the
implementation detail of how it detects/handles deadlocks. For users a
really dumb strategy of just doing a mutex trylock and always
returning -EAGAIN if that fails (together with a msleep(rand) in the
slowpath) would have the same interface. Almost at least, we could
ditch the ticket - but the ticket is used as a virtual lock for the
lockdep annotation, so ditching it would also reduce lockdep
usefulness (due to all those trylocks). So in case we ever switch the
deadlock/backoff algo ww_ would be a bit misleading.

Otoh reservation_ is just what it's used for in graphics-land, so not
that much better. I don't really have a good idea for what this is
besides mutexes_with_magic_deadlock_detection_and_backoff. Which is a
bit long.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v2 2/3] mutex: add support for reservation style locks, v2

On Tue, Apr 2, 2013 at 6:59 PM, Peter Zijlstra  
wrote:
>> > Head hurts, needs more time to ponder. It would be good if someone else
>> > (this would probably be you maarten) would also consider this explore
>> > this 'interesting' problem space :-)
>
>> My head too, evil priority stuff!
>>
>> Hacky but pragmatical workaround for now: use a real mutex around all
>> the reserve_mutex_lock* calls instead of a virtual lock. It can be
>> unlocked as soon as all locks have been taken, before any actual work
>> is done.
>>
>> It only slightly kills the point of having a reservation in the first
>> place, but at least it won't break completely -rt completely for now.
>
> Yeah, global lock, yay :-(

We've discussed this quite a bit on irc and came up with a bunch of
other ideas. The global lock is completely transparent to users, since
the lockdep annotations already rely on ticket_init/fini being a
virtual lock. So we can always fall back to that option.

For more fancy approaches we need to consider the aim first - do we
just want to prevent deadlocks through PI or do we aim for bounded
per-reservation_mutex wait block-to-acquire times for the thread with
highest rt-prio.

If it's just the former I think we can get by by piggy-packing on top
of the existing PI mutex code. Only downside is that threads can lock
arbitrary many reservation locks and so we're looking at boosting an
entire tree of processes. Otoh common operations done while holding
such a lock are swapping buffer objects in or waiting for gpu
rendering. And since we can easily queue up a few ms of rendering rt
guarantees are out the window ;-)

If that's not good enough and the global lock not scalable enough we
could try to limit the fan-out by setting a PI-boost flag in the
reservation ticket (in additional to the normal PI boosting for the
reservation mutex). Threads which are boosted in that fashion will get
a -EAGAIN on the next mutex_reserv_lock call, ensuring that the
blocking doesn't spread to further threads. But that requires that we
pass around pointers to tickets instead of values, so lifetime fun
(atm the ticket is on the stack) and probably tons of races in
updating the ticket boost state. I'd like to avoid that until we've
demonstrated a need for it ...

In any way I think that all three approaches should fit into the
proposed interfaces, so we should be able to do something sane here.
But since I have pretty much zero clue about rt I have no idea which
of the first two approaches would be preferable.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v2 2/3] mutex: add support for reservation style locks, v2

On Tue, 2013-04-02 at 16:57 +0200, Maarten Lankhorst wrote:
> Hey,
> 
> Thanks for reviewing.

Only partway through so far :-)

> Op 02-04-13 13:00, Peter Zijlstra schreef:
> > On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
> >> +Reservation type mutexes
> >> +struct ticket_mutex {
> >> +extern int __must_check _mutex_reserve_lock(struct ticket_mutex *lock,
> > That's two different names and two different forms of one (for a total
> > of 3 variants) for the same scheme.
> >
> > FAIL...

> It's been hard since I haven't seen anything similar in the kernel, I
> originally went with tickets since that's what ttm originally called
> it, and tried to kill as many references as I could when I noticed
> ticket mutexes already being taken.

Ticket mutexes as such don't exist, but we have ticket based spinlock
implementations. It seems a situation ripe for confusion to have two
locking primitives (mutex, spinlock) with similar names (ticket) but
vastly different semantics.

> I'll fix up the ticket_mutex -> reservation_mutex, and mutex_reserve_*
> -> reserve_mutex_*

Do a google for "lock reservation" and observe the results.. its some
scheme where they pre-assign lock ownership to the most likely thread.

> > On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
> >> +mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow:
> >> +  Similar to mutex_reserve_lock, except it won't backoff with
> >> -EAGAIN.
> >> +  This is useful when mutex_reserve_lock failed with -EAGAIN, and you
> >> +  unreserved all reservation_locks so no deadlock can occur.
> >> +
> > I don't particularly like these function names, with lock
> > implementations the _slow post-fix is typically used for slow path
> > implementations, not API type interfaces.

>  I didn't intend for drivers to use the new calls directly, but rather
> through a wrapper, for example by ttm_eu_reserve_buffers in
> drivers/gpu/drm/ttm/ttm_execbuf_util.c

You're providing a generic interface to the core kernel, other people
will end up using it. Providing a proper API is helpful.

> > Also, is there anything in CS literature that comes close to this? I'd
> > think the DBMS people would have something similar with their
> > transactional systems. What do they call it?

> I didn't study cs, but judging from your phrasing I guess you mean you
> want me to call it transaction_mutexes instead?

Nah, me neither, I just hate reinventing names for something that's
already got a perfectly fine name under which a bunch of people know
it.

See the email from Daniel, apparently its known as wound-wait deadlock
avoidance -- its actually described in the "deadlock" wikipedia
article.

So how about we call the thing something like:

  struct ww_mutex; /* wound/wait */

  int mutex_wound_lock(struct ww_mutex *); /* returns -EDEADLK */
  int mutex_wait_lock(struct ww_mutex *);  /* does not fail */

Hmm.. thinking about that,.. you only need that second variant because
you don't have a clear lock to wait for the 'older' process to
complete; but having the unconditional wait makes the entire thing
prone to accidents and deadlocks when the 'user' (read your fellow
programmers) make a mistake.

Ideally we'd only have the one primitive that returns -EDEADLK and use
a 'proper' mutex to wait on or somesuch.. let me ponder this a bit more.

> > Head hurts, needs more time to ponder. It would be good if someone else 
> > (this would probably be you maarten) would also consider this explore 
> > this 'interesting' problem space :-) 

> My head too, evil priority stuff!
> 
> Hacky but pragmatical workaround for now: use a real mutex around all
> the reserve_mutex_lock* calls instead of a virtual lock. It can be
> unlocked as soon as all locks have been taken, before any actual work
> is done.
> 
> It only slightly kills the point of having a reservation in the first
> place, but at least it won't break completely -rt completely for now.

Yeah, global lock, yay :-(

[Bug 62889] ColorTiling results in glitches on Radeon HD 7970 + Glamor

https://bugs.freedesktop.org/show_bug.cgi?id=62889

--- Comment #10 from Alexander von Gluck  ---
Created attachment 77336
  --> https://bugs.freedesktop.org/attachment.cgi?id=77336=edit
gnome-session --debug output nocolortile

-- 
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/20130402/16d93621/attachment.html>

[Bug 62889] ColorTiling results in glitches on Radeon HD 7970 + Glamor

https://bugs.freedesktop.org/show_bug.cgi?id=62889

--- Comment #9 from Alexander von Gluck  ---
Created attachment 77335
  --> https://bugs.freedesktop.org/attachment.cgi?id=77335=edit
glxinfo-nocolortile

-- 
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/20130402/02efa3f4/attachment.html>

[Bug 62889] ColorTiling results in glitches on Radeon HD 7970 + Glamor

https://bugs.freedesktop.org/show_bug.cgi?id=62889

--- Comment #8 from Alexander von Gluck  ---
Thanks for the input.

I disabled colortiling and installed xfce.. success!

It seems like Gnome 3.6 won't work unless color tiling is enabled. I double
checked the gnome session logs and don't see the previously mentioned error
anymore.. just a blank desktop wallpaper across both monitors.  I erased the
gnome config files in .local without any success.

I ran a glxinfo from .xinit, and it does confirm that Gallium is in use.
(attached)

-- 
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/20130402/e7ef2a79/attachment-0001.html>

[Bug 61182] r600g causes KWin crashes with kernel 3.8

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #25 from ogjerstad at gmail.com ---
Not without some instructions, I have never done that before.

And, I must admit, I also downgraded llvm-libs, mesa-dri-filesystem and
mesa-libxatracker. I think I had to because of dependences.

I guess I will have to build from source in that case?

-- 
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/20130402/3c3bf928/attachment.html>

radeonsi tiling dilema

On Tue, Apr 2, 2013 at 4:32 PM, Alex Deucher  wrote:

> On Tue, Apr 2, 2013 at 2:13 PM, Jerome Glisse  wrote:
> > So i am facing a dilema regarding tiling on radeonsi. Given that we now
> have
> > a fixed table of tiling mode this put more pressure on the kernel
> userspace
> > api. I see either 2 solutions.
> >
> > Enforce kernel to set at fixed index in the table best tiling mode for
> given
> > gpu for given format, such as DEPTH32_2D_4AA at index 4, or
> COLOR_SCANOUT_2D
> > at index 13 ... that way kernel can still adapt the tile mode array
> value.
> > Note that this match the design behind the tile mode index being that
> there
> > is a limited number of useful tile mode combination and for each surface
> > format  (depth/color/macro tile/micro/tile) there is a best one.
> >
> > Second solution is to add an ioctl to compute mipmap information in
> kernel
> > (pitch alignment slice size ...) based on format, size of the surface.
> >
> > Some might argue that we could just export the table content to
> userspace,
> > but that would loose information and possibly froze the tile mode table
> > forever as API. The information we loose is what index match to prefered
> > surface format/type combination. And the tile mode might be considered
> API
> > as if kernel ever change what userspace expect then we might break some
> > userspace.
> >
> >
> > Thought, idea ?
>
> If it helps any, the tiling information for the GB_TILE_MODE register
> settings and index locations come from a table provided by the
> hardware team during bring up and barring any typos in transcribing
> the information, never really changes.
>
> Alex
>

Still sounds like you likely want to update those given gap there is inside
them.

Patch set for solution 1:
http://people.freedesktop.org/~glisse/si2d-sol1/

Cheers,
Jerome
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130402/8bb67af7/attachment.html>

[Bug 62976] UEFI + SUMO [6550D] freeze after loading radeon

https://bugs.freedesktop.org/show_bug.cgi?id=62976

--- Comment #5 from David Heidelberger  ---
3.9.0-rc5, with patch. Boot successfull, first time :)

Thank you!

-- 
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/20130402/6eec7cc5/attachment.html>

[PATCH] drm/exynos: change the method for getting the interrupt resource of FIMD

2013-04-02 Thread Inki Dae

Applied. :)

Thanks,
Inki Dae


2013/4/2 Vikas Sajjan 

> Hi Mr. Inki Dae,
>
> Can you please review this patch.?
>
> On Wed, Mar 13, 2013 at 4:22 PM, Vikas Sajjan 
> wrote:
> > Replaces the "platform_get_resource() for IORESOURCE_IRQ" with
> > platform_get_resource_byname().
> > Both in exynos4 and exynos5, FIMD IP has 3 interrupts in the order:
> "fifo",
> > "vsync", and "lcd_sys".
> > But The FIMD driver expects the "vsync" interrupt to be mentioned as the
> > 1st parameter in the FIMD DT node. So to meet this expectation of the
> > driver, the FIMD DT node was forced to be made by keeping "vsync" as the
> > 1st paramter.
> > For example in exynos4, the FIMD DT node has interrupt numbers
> > mentioned as <11, 1> <11, 0> <11, 2> keeping "vsync" as the 1st paramter.
> >
> > This patch fixes the above mentioned "hack" of re-ordering of the
> > FIMD interrupt numbers by getting interrupt resource of FIMD by using
> > platform_get_resource_byname().
> >
> > Signed-off-by: Vikas Sajjan 
> > ---
> >  drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > index 1ea173a..cd79d38 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > @@ -945,7 +945,7 @@ static int fimd_probe(struct platform_device *pdev)
> > return -ENXIO;
> > }
> >
> > -   res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> > +   res = platform_get_resource_byname(pdev, IORESOURCE_IRQ,
> "vsync");
> > if (!res) {
> > dev_err(dev, "irq request failed.\n");
> > return -ENXIO;
> > --
> > 1.7.9.5
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130402/193b1c82/attachment.html>

[PATCH v2 2/3] mutex: add support for reservation style locks, v2

On Tue, Apr 2, 2013 at 1:00 PM, Peter Zijlstra  
wrote:
> Also, is there anything in CS literature that comes close to this? I'd
> think the DBMS people would have something similar with their
> transactional systems. What do they call it?

I've looked around a bit and in dbms row-locking land this seems to be
called the wound-wait deadlock avoidance algorithm. It's the same
approach where if you encounter an older ticket (there called
transaction timestamp) you drop all locked rows and retry (or abort)
the transaction. If you encounter a newer ticket when trying to grab a
lock simply do a blocking wait. So ticket/reservation in Maartens
patches is the analog of timestamp/transaction.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 62976] UEFI + SUMO [6550D] freeze after loading radeon

https://bugs.freedesktop.org/show_bug.cgi?id=62976

--- Comment #4 from Alex Deucher  ---
Created attachment 77331
  --> https://bugs.freedesktop.org/attachment.cgi?id=77331=edit
Possible fix

Does this patch help?

-- 
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/20130402/7c166c5f/attachment.html>

[Bug 62756] Rendering errors on rv790 with llvm and unigine heaven 3.0

https://bugs.freedesktop.org/show_bug.cgi?id=62756

Michel D?nzer  changed:

   What|Removed |Added

 CC||vljn at ovi.com

--- Comment #4 from Michel D?nzer  ---
Vincent, are you seeing r600g/LLVM bug reports like this 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/20130402/d275a38c/attachment.html>

[Bug 62226] Build Fails with LLVM

https://bugs.freedesktop.org/show_bug.cgi?id=62226

Michel D?nzer  changed:

   What|Removed |Added

 CC|michel at daenzer.net  |

--- Comment #13 from Michel D?nzer  ---
(In reply to comment #12)
> @MrCooper: Can you confirm the runtime assertion issue has been fixed
> (radeon AND radeonsi)?
> http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-
> devel_names==2012-12-07

Ah no, I failed to test this properly. :( Thanks for the reminder Johannes.

[ I read bug reports on the lists ]

-- 
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/20130402/776c9fc2/attachment.html>

[PATCH v2 2/3] mutex: add support for reservation style locks, v2

2013-04-02 Thread Maarten Lankhorst

Hey,

Thanks for reviewing.

Op 02-04-13 13:00, Peter Zijlstra schreef:
> On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
>> +Reservation type mutexes
>> +struct ticket_mutex {
>> +extern int __must_check _mutex_reserve_lock(struct ticket_mutex *lock,
> That's two different names and two different forms of one (for a total
> of 3 variants) for the same scheme.
>
> FAIL...
It's been hard since I haven't seen anything similar in the kernel, I 
originally went with tickets
since that's what ttm originally called it, and tried to kill as many 
references as I could
when I noticed ticket mutexes already being taken.

I'll fix up the ticket_mutex -> reservation_mutex, and mutex_reserve_* -> 
reserve_mutex_*

> On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
>> +mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow:
>> +  Similar to mutex_reserve_lock, except it won't backoff with
>> -EAGAIN.
>> +  This is useful when mutex_reserve_lock failed with -EAGAIN, and you
>> +  unreserved all reservation_locks so no deadlock can occur.
>> +
> I don't particularly like these function names, with lock
> implementations the _slow post-fix is typically used for slow path
> implementations, not API type interfaces.
 I didn't intend for drivers to use the new calls directly, but rather through 
a wrapper,
for example by ttm_eu_reserve_buffers in drivers/gpu/drm/ttm/ttm_execbuf_util.c

> Also, is there anything in CS literature that comes close to this? I'd
> think the DBMS people would have something similar with their
> transactional systems. What do they call it?
I didn't study cs, but judging from your phrasing I guess you mean you want me 
to call it transaction_mutexes instead?

> Head hurts, needs more time to ponder. It would be good if someone else
> (this would probably be you maarten) would also consider this and
> explore
> this 'interesting' problem space :-)
My head too, evil priority stuff!

Hacky but pragmatical workaround for now: use a real mutex around all the 
reserve_mutex_lock* calls instead of a virtual lock.
It can be unlocked as soon as all locks have been taken, before any actual work 
is done.

It only slightly kills the point of having a reservation in the first place, 
but at least it won't break completely -rt completely for now.

~Maarten

radeonsi tiling dilema

On Tue, Apr 2, 2013 at 2:13 PM, Jerome Glisse  wrote:
> So i am facing a dilema regarding tiling on radeonsi. Given that we now have
> a fixed table of tiling mode this put more pressure on the kernel userspace
> api. I see either 2 solutions.
>
> Enforce kernel to set at fixed index in the table best tiling mode for given
> gpu for given format, such as DEPTH32_2D_4AA at index 4, or COLOR_SCANOUT_2D
> at index 13 ... that way kernel can still adapt the tile mode array value.
> Note that this match the design behind the tile mode index being that there
> is a limited number of useful tile mode combination and for each surface
> format  (depth/color/macro tile/micro/tile) there is a best one.
>
> Second solution is to add an ioctl to compute mipmap information in kernel
> (pitch alignment slice size ...) based on format, size of the surface.
>
> Some might argue that we could just export the table content to userspace,
> but that would loose information and possibly froze the tile mode table
> forever as API. The information we loose is what index match to prefered
> surface format/type combination. And the tile mode might be considered API
> as if kernel ever change what userspace expect then we might break some
> userspace.
>
>
> Thought, idea ?

If it helps any, the tiling information for the GB_TILE_MODE register
settings and index locations come from a table provided by the
hardware team during bring up and barring any typos in transcribing
the information, never really changes.

Alex

[Intel-gfx] [PATCH] drm/i915: Add i915.dp_limit_max_lane_count driver option.

2013-04-02 Thread Michal Srb

On Tuesday 26 of March 2013 16:49:30 Daniel Vetter wrote:
> On Tue, Mar 26, 2013 at 4:40 PM, Michal Srb  wrote:
> > I have IBM POS machine (4852-570 Truman) that has internal monitor
> > connected over display port. It reports to have 2 lanes, but only 1
> > lane works reliably. With 2 lanes used, the monitor sometimes doesn't
> > turn on. It seems that this is hardware issue specific for this model.
> > 
> > From discussion that was around the
> > 2514bc510d0c3aadcc5204056bb440fa36845147 commit I understand there are
> > more machines that have similar problems. This option can be used to
> > solve them.
> 
> It sounds like we need to start with a DPCD quirk database ... Ajax?
> -Daniel

Any update?
DPCD of this monitor is 10 0a 82 40 00 00 01 00 02 00 00 00 10 01 00 by the 
way.

Is the i915.dp_limit_max_lane_count unacceptable even as temporary workaround?

Michal Srb

[PATCH] drm/i915: drop the coditional mutex

On Tue, Apr 02, 2013 at 03:30:58PM +0200, Sebastian Andrzej Siewior wrote:
> mutex_is_locked_by() checks the owner of the lock against current. This
> is done by accessing a private member of struct mutex which works on
> mainline but does not on RT.
> I did not figure out, why this "lock-owner-check" and the "lock stealing
> flag" is required. If the lock can not be acquire the lock (because it
> would deadlock) then it can return -1.
> The lock stealing makes actually no sense to me. If
> shrinker_no_lock_stealing is true then the same functions
> (i915_gem_purge(), i915_gem_shrink_all()) are called from
> i915_gem_object_create_mmap_offset() as from i915_gem_inactive_shrink().
> I haven't found a path in which i915_gem_inactive_shrink() is invoked
> from i915_gem_object_create_mmap_offset() that means there is no way
> shrinker_no_lock_stealing is true _and_ the lock is owned by the current
> process.

Every invocation of a memory allocation function can potentially recourse
into the shrinker callbacks. Since we currently protect almost all our gpu
buffer object state with one single lock, and we can also easily hold onto
tons of memory, we can easily OOM without that lock stealing trick.

The patch you're reverting here was added to work around spurious OOM when
trying to allocate sg tables, so this is real.

I fully realize that this is an awful hack and I'll burn on a pretty big
pyre for merging it. I also know that it doesn't really work if someone
else is trying to allocate while another thread is hogging our single
mutex. But without a replacement fix, this is nacked.

The no_lock_stealing hack is probably even worse, we use it to protect
critical section which are touching the gpu lru.

Long term we're working towards that goal (also for a bunch of other
reasons) and aim for more fine-grained locking, so that we can free memory
in smaller chunks. But that's gonna be a lot of work.

Cheers, Daniel


> Since I don't see why the i915 needs this hack while all other user do
> not I recommend to remove this hack and return -1 in case of a dead
> lock. Here is the patch.
> 
> Signed-off-by: Sebastian Andrzej Siewior 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |1 -
>  drivers/gpu/drm/i915/i915_gem.c |   32 +++-
>  2 files changed, 3 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 01769e2..47f28ee 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -724,7 +724,6 @@ struct i915_gem_mm {
>   struct i915_hw_ppgtt *aliasing_ppgtt;
>  
>   struct shrinker inactive_shrinker;
> - bool shrinker_no_lock_stealing;
>  
>   /**
>* List of objects currently involved in rendering.
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 0e207e6..7949517 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1500,8 +1500,6 @@ static int i915_gem_object_create_mmap_offset(struct 
> drm_i915_gem_object *obj)
>   if (obj->base.map_list.map)
>   return 0;
>  
> - dev_priv->mm.shrinker_no_lock_stealing = true;
> -
>   ret = drm_gem_create_mmap_offset(>base);
>   if (ret != -ENOSPC)
>   goto out;
> @@ -1521,8 +1519,6 @@ static int i915_gem_object_create_mmap_offset(struct 
> drm_i915_gem_object *obj)
>   i915_gem_shrink_all(dev_priv);
>   ret = drm_gem_create_mmap_offset(>base);
>  out:
> - dev_priv->mm.shrinker_no_lock_stealing = false;
> -
>   return ret;
>  }
>  
> @@ -4368,19 +4364,6 @@ void i915_gem_release(struct drm_device *dev, struct 
> drm_file *file)
>   spin_unlock(_priv->mm.lock);
>  }
>  
> -static bool mutex_is_locked_by(struct mutex *mutex, struct task_struct *task)
> -{
> - if (!mutex_is_locked(mutex))
> - return false;
> -
> -#if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_MUTEXES)
> - return mutex->owner == task;
> -#else
> - /* Since UP may be pre-empted, we cannot assume that we own the lock */
> - return false;
> -#endif
> -}
> -
>  static int
>  i915_gem_inactive_shrink(struct shrinker *shrinker, struct shrink_control 
> *sc)
>  {
> @@ -4391,18 +4374,10 @@ i915_gem_inactive_shrink(struct shrinker *shrinker, 
> struct shrink_control *sc)
>   struct drm_device *dev = dev_priv->dev;
>   struct drm_i915_gem_object *obj;
>   int nr_to_scan = sc->nr_to_scan;
> - bool unlock = true;
>   int cnt;
>  
> - if (!mutex_trylock(>struct_mutex)) {
> - if (!mutex_is_locked_by(>struct_mutex, current))
> - return 0;
> -
> - if (dev_priv->mm.shrinker_no_lock_stealing)
> - return 0;
> -
> - unlock = false;
> - }
> + if (!mutex_trylock(>struct_mutex))
> + return -1;
>  
>   if (nr_to_scan) {
>   nr_to_scan -= i915_gem_purge(dev_priv, nr_to_scan);
> @@ -4421,7 +4396,6

[PATCH] drm/i915: drop the coditional mutex

2013-04-02 Thread Sebastian Andrzej Siewior

mutex_is_locked_by() checks the owner of the lock against current. This
is done by accessing a private member of struct mutex which works on
mainline but does not on RT.
I did not figure out, why this "lock-owner-check" and the "lock stealing
flag" is required. If the lock can not be acquire the lock (because it
would deadlock) then it can return -1.
The lock stealing makes actually no sense to me. If
shrinker_no_lock_stealing is true then the same functions
(i915_gem_purge(), i915_gem_shrink_all()) are called from
i915_gem_object_create_mmap_offset() as from i915_gem_inactive_shrink().
I haven't found a path in which i915_gem_inactive_shrink() is invoked
from i915_gem_object_create_mmap_offset() that means there is no way
shrinker_no_lock_stealing is true _and_ the lock is owned by the current
process.
Since I don't see why the i915 needs this hack while all other user do
not I recommend to remove this hack and return -1 in case of a dead
lock. Here is the patch.

Signed-off-by: Sebastian Andrzej Siewior 
---
 drivers/gpu/drm/i915/i915_drv.h |1 -
 drivers/gpu/drm/i915/i915_gem.c |   32 +++-
 2 files changed, 3 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 01769e2..47f28ee 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -724,7 +724,6 @@ struct i915_gem_mm {
struct i915_hw_ppgtt *aliasing_ppgtt;

struct shrinker inactive_shrinker;
-   bool shrinker_no_lock_stealing;

/**
 * List of objects currently involved in rendering.
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0e207e6..7949517 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1500,8 +1500,6 @@ static int i915_gem_object_create_mmap_offset(struct 
drm_i915_gem_object *obj)
if (obj->base.map_list.map)
return 0;

-   dev_priv->mm.shrinker_no_lock_stealing = true;
-
ret = drm_gem_create_mmap_offset(>base);
if (ret != -ENOSPC)
goto out;
@@ -1521,8 +1519,6 @@ static int i915_gem_object_create_mmap_offset(struct 
drm_i915_gem_object *obj)
i915_gem_shrink_all(dev_priv);
ret = drm_gem_create_mmap_offset(>base);
 out:
-   dev_priv->mm.shrinker_no_lock_stealing = false;
-
return ret;
 }

@@ -4368,19 +4364,6 @@ void i915_gem_release(struct drm_device *dev, struct 
drm_file *file)
spin_unlock(_priv->mm.lock);
 }

-static bool mutex_is_locked_by(struct mutex *mutex, struct task_struct *task)
-{
-   if (!mutex_is_locked(mutex))
-   return false;
-
-#if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_MUTEXES)
-   return mutex->owner == task;
-#else
-   /* Since UP may be pre-empted, we cannot assume that we own the lock */
-   return false;
-#endif
-}
-
 static int
 i915_gem_inactive_shrink(struct shrinker *shrinker, struct shrink_control *sc)
 {
@@ -4391,18 +4374,10 @@ i915_gem_inactive_shrink(struct shrinker *shrinker, 
struct shrink_control *sc)
struct drm_device *dev = dev_priv->dev;
struct drm_i915_gem_object *obj;
int nr_to_scan = sc->nr_to_scan;
-   bool unlock = true;
int cnt;

-   if (!mutex_trylock(>struct_mutex)) {
-   if (!mutex_is_locked_by(>struct_mutex, current))
-   return 0;
-
-   if (dev_priv->mm.shrinker_no_lock_stealing)
-   return 0;
-
-   unlock = false;
-   }
+   if (!mutex_trylock(>struct_mutex))
+   return -1;

if (nr_to_scan) {
nr_to_scan -= i915_gem_purge(dev_priv, nr_to_scan);
@@ -4421,7 +4396,6 @@ i915_gem_inactive_shrink(struct shrinker *shrinker, 
struct shrink_control *sc)
if (obj->pin_count == 0 && obj->pages_pin_count == 0)
cnt += obj->base.size >> PAGE_SHIFT;

-   if (unlock)
-   mutex_unlock(>struct_mutex);
+   mutex_unlock(>struct_mutex);
return cnt;
 }
-- 
1.7.6.5

[Bug 62226] Build Fails with LLVM

https://bugs.freedesktop.org/show_bug.cgi?id=62226

Johannes Obermayr  changed:

   What|Removed |Added

 CC||michel at daenzer.net

--- Comment #12 from Johannes Obermayr  ---
(In reply to comment #10)
> Also this statement is wrong:
> "This library was originally changed to a shared object to work around
> linker error in egl_static.so, but these appear to be fixed now."
> 
> It was changed to be built '-shared' because there were and possibly be
> troubles with crashing egl things if r600 AND radeonsi were built together
> (see on #dri-devel from mid december 2012 [MrCooper, jobermayr])
> 
> You should also see the conditional there. If it makes sense and is required
> (r600 AND radeonsi) it is shared. If it doesn't (r600 XOR radeonsi) it is
> static.

"Please test to make sure this works for your build configuration.

Tested-by: Michel D?nzer "

@MrCooper: Can you confirm the runtime assertion issue has been fixed (radeon
AND radeonsi)?
http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel_names==2012-12-07

-- 
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/20130402/dd523865/attachment.html>

[PATCH] gma500: medfield: Fix possible NULL pointer dereference

On Sun, Feb 24, 2013 at 11:31 PM, Syam Sidhardhan
 wrote:
> The use of pointer sender should be after the NULL check.
>
> Signed-off-by: Syam Sidhardhan 
> ---
>  drivers/gpu/drm/gma500/mdfld_dsi_output.c |7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_output.c 
> b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
> index 2d4ab48..3abf831 100644
> --- a/drivers/gpu/drm/gma500/mdfld_dsi_output.c
> +++ b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
> @@ -92,8 +92,8 @@ void mdfld_dsi_brightness_init(struct mdfld_dsi_config 
> *dsi_config, int pipe)
>  {
> struct mdfld_dsi_pkg_sender *sender =
> mdfld_dsi_get_pkg_sender(dsi_config);
> -   struct drm_device *dev = sender->dev;
> -   struct drm_psb_private *dev_priv = dev->dev_private;
> +   struct drm_device *dev;
> +   struct drm_psb_private *dev_priv;
> u32 gen_ctrl_val;
>
> if (!sender) {
> @@ -101,6 +101,9 @@ void mdfld_dsi_brightness_init(struct mdfld_dsi_config 
> *dsi_config, int pipe)
> return;
> }
>
> +   dev = sender->dev;
> +   dev_priv = dev->dev_private;
> +
> /* Set default display backlight value to 85% (0xd8)*/
> mdfld_dsi_send_mcs_short(sender, write_display_brightness, 0xd8, 1,
> true);
> --
> 1.7.9.5

Your patch has been applied to:
https://github.com/patjak/drm-gma500.git gma500-next

Thanks
Patrik Jakobsson

[PATCH] drivers: gpu: drm: gma500: Replaced calls kzalloc & memcpy with kmemdup

On Mon, Mar 11, 2013 at 8:46 PM, Alexandru Gheorghiu
 wrote:
> Replaced calls kzalloc followed by memcpy with call to kmemdup.
> Patch found using coccinelle.
>
> Signed-off-by: Alexandru Gheorghiu 
> ---
>  drivers/gpu/drm/gma500/intel_bios.c |3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/intel_bios.c 
> b/drivers/gpu/drm/gma500/intel_bios.c
> index 403fffb..d349734 100644
> --- a/drivers/gpu/drm/gma500/intel_bios.c
> +++ b/drivers/gpu/drm/gma500/intel_bios.c
> @@ -218,12 +218,11 @@ static void parse_backlight_data(struct drm_psb_private 
> *dev_priv,
> bl_start = find_section(bdb, BDB_LVDS_BACKLIGHT);
> vbt_lvds_bl = (struct bdb_lvds_backlight *)(bl_start + 1) + p_type;
>
> -   lvds_bl = kzalloc(sizeof(*vbt_lvds_bl), GFP_KERNEL);
> +   lvds_bl = kmemdup(vbt_lvds_bl, sizeof(*vbt_lvds_bl), GFP_KERNEL);
> if (!lvds_bl) {
> dev_err(dev_priv->dev->dev, "out of memory for backlight 
> data\n");
> return;
> }
> -   memcpy(lvds_bl, vbt_lvds_bl, sizeof(*vbt_lvds_bl));
> dev_priv->lvds_bl = lvds_bl;
>  }
>
> --
> 1.7.9.5
>
> --

Your patch has been applied to:
https://github.com/patjak/drm-gma500.git gma500-next

Thanks
Patrik Jakobsson

[PATCH] gma500: Make VGA and HDMI connector hotpluggable

On Sun, Mar 31, 2013 at 1:38 PM, Kero  wrote:
> From: Kero van Gelder 
>
> Both VGA and HDMI connectors are available on my Asus EeePC X101CH.
> This patch will cause output to be shown on either when plugged in.
> For both, it shows the leftmost 800x600, of the 1024x600 on LVDS.
>
> Signed-off-by: Kero van Gelder 
> ---
> diff --git a/drivers/gpu/drm/gma500/cdv_intel_crt.c 
> b/drivers/gpu/drm/gma500/cdv_intel_crt.c
> index 8c17534..7b8386f 100644
> --- a/drivers/gpu/drm/gma500/cdv_intel_crt.c
> +++ b/drivers/gpu/drm/gma500/cdv_intel_crt.c
> @@ -276,6 +276,7 @@ void cdv_intel_crt_init(struct drm_device *dev,
> goto failed_connector;
>
> connector = _intel_connector->base;
> +   connector->polled = DRM_CONNECTOR_POLL_HPD;
> drm_connector_init(dev, connector,
> _intel_crt_connector_funcs, DRM_MODE_CONNECTOR_VGA);
>
> diff --git a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c 
> b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
> index e223b50..464153d 100644
> --- a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
> +++ b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
> @@ -319,6 +319,7 @@ void cdv_hdmi_init(struct drm_device *dev,
> goto err_priv;
>
> connector = _intel_connector->base;
> +   connector->polled = DRM_CONNECTOR_POLL_HPD;
> encoder = _intel_encoder->base;
> drm_connector_init(dev, connector,
>_hdmi_connector_funcs,
> --

Your patch has been applied to:
https://github.com/patjak/drm-gma500.git gma500-next

We might also consider polling if this causes problems for people, but for now
this is fine. No biggie, but your tabs where converted to spaces so I recommend
running checkpatch.pl before submitting.

Thanks
Patrik Jakobsson

radeonsi tiling dilema

On Tue, Apr 2, 2013 at 2:13 PM, Jerome Glisse  wrote:

> So i am facing a dilema regarding tiling on radeonsi. Given that we now
> have a fixed table of tiling mode this put more pressure on the kernel
> userspace api. I see either 2 solutions.
>
> Enforce kernel to set at fixed index in the table best tiling mode for
> given gpu for given format, such as DEPTH32_2D_4AA at index 4, or
> COLOR_SCANOUT_2D at index 13 ... that way kernel can still adapt the tile
> mode array value. Note that this match the design behind the tile mode
> index being that there is a limited number of useful tile mode combination
> and for each surface format  (depth/color/macro tile/micro/tile) there is a
> best one.
> Second solution is to add an ioctl to compute mipmap information in kernel
> (pitch alignment slice size ...) based on format, size of the surface.
>

Well that one can also be slightly modified to not strictly enfore index
association with surface format/type preference.


>
> Some might argue that we could just export the table content to userspace,
> but that would loose information and possibly froze the tile mode table
> forever as API. The information we loose is what index match to prefered
> surface format/type combination. And the tile mode might be considered API
> as if kernel ever change what userspace expect then we might break some
> userspace.
>
>
> Thought, idea ?
>
> Cheers,
> Jerome
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130402/a86439ec/attachment.html>

radeonsi tiling dilema

So i am facing a dilema regarding tiling on radeonsi. Given that we now
have a fixed table of tiling mode this put more pressure on the kernel
userspace api. I see either 2 solutions.

Enforce kernel to set at fixed index in the table best tiling mode for
given gpu for given format, such as DEPTH32_2D_4AA at index 4, or
COLOR_SCANOUT_2D at index 13 ... that way kernel can still adapt the tile
mode array value. Note that this match the design behind the tile mode
index being that there is a limited number of useful tile mode combination
and for each surface format  (depth/color/macro tile/micro/tile) there is a
best one.

Second solution is to add an ioctl to compute mipmap information in kernel
(pitch alignment slice size ...) based on format, size of the surface.

Some might argue that we could just export the table content to userspace,
but that would loose information and possibly froze the tile mode table
forever as API. The information we loose is what index match to prefered
surface format/type combination. And the tile mode might be considered API
as if kernel ever change what userspace expect then we might break some
userspace.


Thought, idea ?

Cheers,
Jerome
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130402/4bad0378/attachment.html>

[PATCH] drm: fix i_mapping and f_mapping initialization in drm_open in error path

2013-04-02 Thread Marco Munderloh

Hi Ilija,

> Thanks for testing. Other issues are probably unrelated, so I'll send the 
> last version of the patch to Dave.

I came across another problem which seems related. rmmod radeon works, however, 
modprobe radeon afterwards results in a crash (divide error), see attachment.

Best, Marco

On 02.04.2013 13:23, Ilija Hadzic wrote:
>
> -- Ilija
>
> On Tue, Apr 2, 2013 at 6:36 AM, Marco Munderloh  tnt.uni-hannover.de <mailto:munderl at tnt.uni-hannover.de>> wrote:
>
> Attached is a v2 of the patch, for reference. I would appreciate if 
> the original reporter or you tested it in lieu of your proposed patch and let 
> me know if it
> fixes your
> issue.
>
>
> The patch works for me. echo 3 > /proc/sys/vm/drop_caches as well as 
> rmmod radeon do not end up in a crash anymore. However, I have still no clue 
> why one of these makes
> drm_open to fail. On rmmod radeon I get the following log messages. If 
> don't know if the 'unpin not necessary' has anything to do with it.
>
> [drm] radeon: finishing device.
> radeon :01:00.0: 88024e526c00 unpin not necessary
> radeon :01:00.0: 88024f2f6000 unpin not necessary
> radeon :01:00.0: 88024f2f6000 unpin not necessary
> [TTM] Finalizing pool allocator
> [TTM] Finalizing DMA pool allocator
> [TTM] Zone  kernel: Used memory at exit: 0 kiB
> [TTM] Zone   dma32: Used memory at exit: 0 kiB
> [drm] radeon: ttm finalized
> vga_switcheroo: disabled
> [drm] Module unloaded
>
> By the way, sometimes my r8169 ethernet controller does not survive 
> suspend/hibernation (does not detect link). rmmod/modprobe helps. I don't 
> know if this is related.
>
>

-- 
Dipl.-Ing. Marco Munderloh Mail: munderl at tnt.uni-hannover.de
Institut f?r Informationsverarbeitung (TNT) Phone: +49 511 762-19587
Leibniz Universitaet Hannover, Appelstr. 9a   Fax: +49 511 762- 5333
30167 Hannover, Germany Web: http://www.tnt.uni-hannover.de/~munderl
-- next part --
A non-text attachment was scrubbed...
Name: crash_modprobe_radeon.log
Type: text/x-log
Size: 12046 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130402/1b198711/attachment-0002.bin>
-- next part --
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4523 bytes
Desc: S/MIME Cryptographic Signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130402/1b198711/attachment-0003.bin>

linux-next: manual merge of the drm-intel tree with Linus' tree

2013-04-02 Thread Stephen Rothwell

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_dp.c between commit 9d1a455b0ca1 ("") from
Linus' tree and commit 965e0c489f36 ("drm/i915: introduce
pipe_config->dither|pipe_bpp") from the drm-intel tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwellsfr at canb.auug.org.au

diff --cc drivers/gpu/drm/i915/intel_dp.c
index d7d4afe,92a7c62..000
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@@ -850,10 -792,10 +802,10 @@@ intel_dp_set_m_n(struct drm_crtc *crtc
 * the number of bytes_per_pixel post-LUT, which we always
 * set up for 8-bits of R/G/B, or 3 bytes total.
 */
-   intel_link_compute_m_n(intel_crtc->bpp, lane_count,
+   intel_link_compute_m_n(intel_crtc->config.pipe_bpp, lane_count,
 - mode->clock, adjusted_mode->clock, _n);
 + target_clock, adjusted_mode->clock, _n);

-   if (IS_HASWELL(dev)) {
+   if (HAS_DDI(dev)) {
I915_WRITE(PIPE_DATA_M1(cpu_transcoder),
   TU_SIZE(m_n.tu) | m_n.gmch_m);
I915_WRITE(PIPE_DATA_N1(cpu_transcoder), m_n.gmch_n);
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130402/c1e13c2d/attachment.pgp>

[Bug 62226] Build Fails with LLVM

https://bugs.freedesktop.org/show_bug.cgi?id=62226

--- Comment #11 from Christian K?nig  ---
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > I am against this sort of patches.
> > > 
> > 
> > Can you explain why?
> 
> Because you are working against aboll and me - we want to build as much
> '-shared' as possible (and also distributions [should] want to do so):
> http://lists.freedesktop.org/archives/mesa-dev/2013-March/036449.html
> http://lists.freedesktop.org/archives/mesa-dev/2013-March/036493.html
> 
> Also this statement is wrong:
> "This library was originally changed to a shared object to work around
> linker error in egl_static.so, but these appear to be fixed now."
> 
> It was changed to be built '-shared' because there were and possibly be
> troubles with crashing egl things if r600 AND radeonsi were built together
> (see on #dri-devel from mid december 2012 [MrCooper, jobermayr])
> 
> You should also see the conditional there. If it makes sense and is required
> (r600 AND radeonsi) it is shared. If it doesn't (r600 XOR radeonsi) it is
> static.

I don't think I like the general idea here, for most distributions driver size
doesn't matter so much, but on the other hand it is highly likely that we want
to have different version of this and other libs for r600 and radeonsi.

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-devel/attachments/20130402/22108f06/attachment-0001.html>

[PATCH v2 2/3] mutex: add support for reservation style locks, v2

On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
> +The algorithm that TTM came up with for dealing with this problem is
> +quite simple.  For each group of buffers (execbuf) that need to be
> +locked, the caller would be assigned a unique reservation_id, from a
> +global counter.  In case of deadlock while locking all the buffers
> +associated with a execbuf, the one with the lowest reservation_id
> +wins, and the one with the higher reservation_id unlocks all of the
> +buffers that it has already locked, and then tries again.

So the thing that made me cringe inside when I read this was making it
all work on -rt, where we also need to take PI into account and ensure
the entire thing is deterministic.

It _might_ be 'easy' and we could fall back to PI mutex behaviour in
the case the reservation IDs match; however the entire for-all-bufs
retry loops do worry me still.

Head hurts, needs more time to ponder. It would be good if someone else
(this would probably be you maarten) would also consider this and
explore
this 'interesting' problem space :-)

[PATCH v2 2/3] mutex: add support for reservation style locks, v2

On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
> +Reservation type mutexes

> +struct ticket_mutex {

> +extern int __must_check _mutex_reserve_lock(struct ticket_mutex *lock,

That's two different names and two different forms of one (for a total
of 3 variants) for the same scheme.

FAIL...

Also, is there anything in CS literature that comes close to this? I'd
think the DBMS people would have something similar with their
transactional systems. What do they call it?

[Bug 61182] r600g causes KWin crashes with kernel 3.8

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #24 from Alex Deucher  ---
(In reply to comment #23)
> I can confirm now that downgrading mesa-dri-drivers to 9.0.1-1 (as packaged
> by Fedora) fixes the problem.

Can you bisect 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/20130402/587af819/attachment.html>

[PATCH v2 2/3] mutex: add support for reservation style locks, v2

On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
> +struct ticket_mutex {
> +   struct mutex base;
> +   atomic_long_t reservation_id;
> +};

I'm not sure this is a good name, esp. due to the potential confusion
vs the ticket spinlocks we have.

[PATCH v2 2/3] mutex: add support for reservation style locks, v2

On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
> +mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow:
> +  Similar to mutex_reserve_lock, except it won't backoff with
> -EAGAIN.
> +  This is useful when mutex_reserve_lock failed with -EAGAIN, and you
> +  unreserved all reservation_locks so no deadlock can occur.
> +

I don't particularly like these function names, with lock
implementations the _slow post-fix is typically used for slow path
implementations, not API type interfaces.

[PATCH] drm: fix i_mapping and f_mapping initialization in drm_open in error path

2013-04-02 Thread Marco Munderloh

> Attached is a v2 of the patch, for reference. I would appreciate if the 
> original reporter or you tested it in lieu of your proposed patch and let me 
> know if it fixes your
> issue.

The patch works for me. echo 3 > /proc/sys/vm/drop_caches as well as rmmod 
radeon do not end up in a crash anymore. However, I have still no clue why one 
of these makes 
drm_open to fail. On rmmod radeon I get the following log messages. If don't 
know if the 'unpin not necessary' has anything to do with it.

[drm] radeon: finishing device.
radeon :01:00.0: 88024e526c00 unpin not necessary
radeon :01:00.0: 88024f2f6000 unpin not necessary
radeon :01:00.0: 88024f2f6000 unpin not necessary
[TTM] Finalizing pool allocator
[TTM] Finalizing DMA pool allocator
[TTM] Zone  kernel: Used memory at exit: 0 kiB
[TTM] Zone   dma32: Used memory at exit: 0 kiB
[drm] radeon: ttm finalized
vga_switcheroo: disabled
[drm] Module unloaded

By the way, sometimes my r8169 ethernet controller does not survive 
suspend/hibernation (does not detect link). rmmod/modprobe helps. I don't know 
if this is related.

-- next part --
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4523 bytes
Desc: S/MIME Cryptographic Signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130402/36316fe3/attachment.bin>

[PULL] drm-intel-next

Hi Dave,

So I've figured we should get drm-next for 3.10 started ;-)

Highlights:
- Imre's for_each_sg_pages rework (now also with the stolen mem backed
  case fixed with a hack) plus the drm prime sg list coalescing patch from
  Rahul Sharma. I have some follow-up cleanups pending, already acked by
  Andrew Morton.
- Some prep-work for the crazy no-pch/display-less platform by Ben.
- Some vlv patches, by far not all (Jesse et al).
- Clean up the HDMI/SDVO #define confusion (Paulo)
- gen2-4 vblank fixes from Ville.
- Unclaimed register warning fixes for hsw (Paulo). More still to come ...
- Complete pageflips which have been stuck in a gpu hang, should prevent
  stuck gl compositors (Ville).
- pm patches for vt-switchless resume (Jesse). Note that the i915 enabling
  is not (yet) included, that took a bit longer to settle. PM patches are
  acked by Rafael Wysocki.
- Minor fixlets all over from various people.

All together it's been pretty quiet thus far.

Cheers, Daniel


The following changes since commit a937536b868b8369b98967929045f1df54234323:

  Linux 3.9-rc3 (2013-03-17 15:59:32 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-next-2013-03-23

for you to fetch changes up to e3dff585508636c8d2915cc1595e04f16ccd66ba:

  drm/i915: Implement WaSwitchSolVfFArbitrationPriority (2013-03-23 12:18:06 
+0100)


Ben Widawsky (9):
  drm/i915: Created a sized object error dump
  drm/i915: exclude CCID for platforms without it
  drm/i915: Capture current context on error
  drm/i915: Remove unused file arg from execbuf
  drm/i915: Remove unneeded dev argument
  drm/i915: Move num_pipes to intel info
  drm/i915: Introduce GEN7_FEATURES for device info
  drm/i915: Correct sandybrige overclocking
  drm/i915: Implement WaSwitchSolVfFArbitrationPriority

Chris Wilson (1):
  drm/i915: Resurrect ring kicking for semaphores, selectively

Damien Lespiau (1):
  drm/i915: Remove platforms in the preliminary_hw_support description

Daniel Vetter (4):
  drm/i915: gen2 has no tv out support
  Merge tag 'v3.9-rc3' into drm-intel-next-queued
  style nit: Align function parameter continuation properly.
  drm/i915: fixup pd vs pt confusion in gen6 ppgtt code

Imre Deak (5):
  drm: handle compact dma scatter lists in drm_clflush_sg()
  drm/i915: set dummy page for stolen objects
  drm/i915: handle walking compact dma scatter lists
  drm/i915: create compact dma scatter lists for gem objects
  drm/i915: use for_each_sg_page for setting up the gtt ptes

Jani Nikula (2):
  drm/i915: add \n to the end of sysfs attributes
  drm/i915: reduce power in the ilk rc6 enable error message

Jesse Barnes (18):
  PM: make VT switching to the suspend console optional v3
  fb: add support for drivers not needing VT switch at suspend/resume time
  drm/i915: don't restore LVDS enable state blindly v2
  drm/i915: remove disabled memset of framebuffer from intel_fb
  drm/i915: don't init LVDS on VLV
  drm/i915: VLV has force wake
  drm/i915/dp: don't use ILK paths on VLV
  drm/i915: use gen6 stolen check on VLV
  drm/i915/dp: add pre-PCH eDP checking to DP detect for VLV
  drm/i915: allow force wake at init time on VLV v2
  drm/i915: don't use plane pipe select on VLV
  drm/i915: add media well to VLV force wake routines v2
  drm/i915: use VLV DIP routines on VLV v2
  drm/i915: add more VLV IDs
  drm/i915: fix WaDisablePSDDualDispatchEnable on VLV v2
  drm/i915: set conservative clock gating values on VLV v2
  drm/i915: DSPFW and BLC regs are in the display offset range
  drm/i915: VLV doesn't have HDMI on port C

Kees Cook (2):
  drm/i915: use simple attribute in debugfs routines
  drm/i915: clarify reasoning for the access_ok call

Mihnea Dobrescu-Balaur (1):
  gpu: don't cast kzalloc() return value

Mika Kuoppala (1):
  drm/i915: remove obsolete obj assignment in page flip

Paulo Zanoni (19):
  drm/i915: use HAS_DDI on intel_hdmi.c and intel_display.c
  drm/i915: wait_event_timeout's timeout is in jiffies
  drm/i915: add aux_ch_ctl_reg to struct intel_dp
  drm/i915: rename sdvox_reg to hdmi_reg on HDMI context
  drm/i915: create functions for the "unclaimed register" checks
  drm/i915: use FPGA_DBG for the "unclaimed register" checks
  drm/i915: clear the FPGA_DBG_RM_NOCLAIM bit at driver init
  drm/i915: clarify confusion between SDVO and HDMI registers
  drm/i915: unify the definitions of the HDMI/SDVO register
  drm/i915: remove duplicated SDVO/HDMI bit definitions
  drm/i915: rename some HDMI bit definitions
  drm/i915: disable sound first on intel_disable_ddi
  drm/i915: capture the correct cursor registers on IVB
  drm/i915: there's no DSPSIZE register on gen4+
  drm/i915: there's no

[PATCH] drm/exynos: change the method for getting the interrupt resource of FIMD

2013-04-02 Thread Vikas Sajjan

Hi Mr. Inki Dae,

Can you please review this patch.?

On Wed, Mar 13, 2013 at 4:22 PM, Vikas Sajjan  
wrote:
> Replaces the "platform_get_resource() for IORESOURCE_IRQ" with
> platform_get_resource_byname().
> Both in exynos4 and exynos5, FIMD IP has 3 interrupts in the order: "fifo",
> "vsync", and "lcd_sys".
> But The FIMD driver expects the "vsync" interrupt to be mentioned as the
> 1st parameter in the FIMD DT node. So to meet this expectation of the
> driver, the FIMD DT node was forced to be made by keeping "vsync" as the
> 1st paramter.
> For example in exynos4, the FIMD DT node has interrupt numbers
> mentioned as <11, 1> <11, 0> <11, 2> keeping "vsync" as the 1st paramter.
>
> This patch fixes the above mentioned "hack" of re-ordering of the
> FIMD interrupt numbers by getting interrupt resource of FIMD by using
> platform_get_resource_byname().
>
> Signed-off-by: Vikas Sajjan 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 1ea173a..cd79d38 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -945,7 +945,7 @@ static int fimd_probe(struct platform_device *pdev)
> return -ENXIO;
> }
>
> -   res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> +   res = platform_get_resource_byname(pdev, IORESOURCE_IRQ, "vsync");
> if (!res) {
> dev_err(dev, "irq request failed.\n");
> return -ENXIO;
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

drm/tilcdc: LCD panels clocks initialization and earlier backlight initialization

2013-04-02 Thread Michal Bachraty

Hi Rob,

On Monday, April 01, 2013 09:46:05 Rob Clark wrote:
> On Mon, Apr 1, 2013 at 7:31 AM, Hiremath, Vaibhav  wrote:
> >> -Original Message-
> >> From: devicetree-discuss [mailto:devicetree-discuss-
> >> bounces+hvaibhav=ti.com at lists.ozlabs.org] On Behalf Of Michal Bachraty
> >> Sent: Thursday, March 28, 2013 11:02 PM
> >> To: dri-devel at lists.freedesktop.org; devicetree-
> >> discuss at lists.ozlabs.org
> >> Cc: robdclark at gmail.com; koen at dominion.thruhere.net
> >> Subject: drm/tilcdc: LCD panels clocks initialization and earlier
> >> backlight initialization
> >> 
> >> Hi,
> >> 
> >> I'm trying to use tilcdc driver for KWH050TG08 LCD panel connected to
> >> AM335x
> >> processor (3.9 rc1 kernel). I have prepared DT bindings for that
> >> (listed
> >> bellow). I see fb0 device but I have no clocks going from cpu to LCD.
> >> My
> >> clocks for LCD seems not properly to be set ...
> >> 
> >> virt_2500_ck   1   12500
> >> 
> >> sys_clkin_ck8   19   2500
> >> 
> >>dpll_disp_ck 0   12500
> >>
> >>   dpll_disp_m2_ck   0   12500
> >>   
> >>  lcd_gclk   0   12500
> >> 
> >> and tilcdc_crtc is not called. I also set lcd_gclk to 300MHz, but I got
> >> same
> >> result. The question is there any way how to properly set clocks for
> >> LCD?
> > 
> > Not sure  about the LCDC DRM driver, but I just tested clk_set_rate()
> > For lcdc_gclk clock and it is working for me. I could able to set
> > 300MHz freq on my BeagleBone platform, with below code -
> 
> fwiw, tilcdc drm driver won't set clocks until you do modeset, as it
> is setting them based on the requested pixel clock.  As opposed to
> setting it once at boot time.
> 
> Michal, you may want to add 'drm.debug=7' in your bootargs, and send
> the bootlog.  That should set some light about whether it is even
> trying to modeset but failing, or some other issue.
> 

Yes, here it is:

[3.098732] platform audio.11: Driver snd-soc-am33xx-s800 requests probe 
deferral
[3.107280] TCP: cubic registered
[3.110822] Initializing XFRM netlink socket
[3.115844] NET: Registered protocol family 10
[3.123212] NET: Registered protocol family 17
[3.128064] NET: Registered protocol family 15
[3.133176] Key type dns_resolver registered
[3.137846] VFP support v0.3: implementor 41 architecture 3 part 30 variant 
c rev 3
[3.146087] ThumbEE CPU extension supported.
[3.150659] Registering SWP/SWPB emulation handler
[3.160695] registered taskstats version 1
[3.166007] [drm:tilcdc_drm_init], init
[3.171117] pinctrl core: add 1 pinmux maps
[3.175564] pinctrl-single 44e10800.pinmux: found group selector 6 for 
pinmux_lcd_pins
[3.183957] pinctrl-single 44e10800.pinmux: request pin 59 (44e108ec) for 
lcd_panel.15
[3.192312] pinctrl-single 44e10800.pinmux: request pin 57 (44e108e4) for 
lcd_panel.15
[3.200662] pinctrl-single 44e10800.pinmux: request pin 56 (44e108e0) for 
lcd_panel.15
[3.209010] pinctrl-single 44e10800.pinmux: request pin 58 (44e108e8) for 
lcd_panel.15
[3.217321] pinctrl-single 44e10800.pinmux: request pin 55 (44e108dc) for 
lcd_panel.15
[3.225666] pinctrl-single 44e10800.pinmux: request pin 54 (44e108d8) for 
lcd_panel.15
[3.234012] pinctrl-single 44e10800.pinmux: request pin 53 (44e108d4) for 
lcd_panel.15
[3.242359] pinctrl-single 44e10800.pinmux: request pin 52 (44e108d0) for 
lcd_panel.15
[3.250708] pinctrl-single 44e10800.pinmux: request pin 51 (44e108cc) for 
lcd_panel.15
[3.259052] pinctrl-single 44e10800.pinmux: request pin 50 (44e108c8) for 
lcd_panel.15
[3.267362] pinctrl-single 44e10800.pinmux: request pin 49 (44e108c4) for 
lcd_panel.15
[3.275710] pinctrl-single 44e10800.pinmux: request pin 48 (44e108c0) for 
lcd_panel.15
[3.284057] pinctrl-single 44e10800.pinmux: request pin 47 (44e108bc) for 
lcd_panel.15
[3.292404] pinctrl-single 44e10800.pinmux: request pin 46 (44e108b8) for 
lcd_panel.15
[3.300748] pinctrl-single 44e10800.pinmux: request pin 45 (44e108b4) for 
lcd_panel.15
[3.309091] pinctrl-single 44e10800.pinmux: request pin 44 (44e108b0) for 
lcd_panel.15
[3.317404] pinctrl-single 44e10800.pinmux: request pin 43 (44e108ac) for 
lcd_panel.15
[3.325751] pinctrl-single 44e10800.pinmux: request pin 42 (44e108a8) for 
lcd_panel.15
[3.334098] pinctrl-single 44e10800.pinmux: request pin 41 (44e108a4) for 
lcd_panel.15
[3.342445] pinctrl-single 44e10800.pinmux: request pin 40 (44e108a0) for 
lcd_panel.15
[3.350794] pinctrl-single 44e10800.pinmux: enabling pinmux_lcd_pins 
function6
[3.358477] panel lcd_panel.15: obtain a copy of previously claimed pinctrl
[3.366365] [drm:drm_platform_init], 
[3.370270] [drm:drm_get_platform_dev], 
[3.374940] [drm:drm_get_minor], 
[

[Bug 61182] r600g causes KWin crashes with kernel 3.8

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #23 from ogjerstad at gmail.com ---
I can confirm now that downgrading mesa-dri-drivers to 9.0.1-1 (as packaged by
Fedora) fixes the problem.

-- 
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/20130402/19d678bb/attachment.html>

[PATCH] drm: fix i_mapping and f_mapping initialization in drm_open in error path

2013-04-02 Thread Michal Hocko

On Mon 01-04-13 13:14:50, Ilija Hadzic wrote:
> 
> 
> On Sun, 31 Mar 2013, Michal Hocko wrote:
> 
> >On Sat 30-03-13 18:26:53, Ilija Hadzic wrote:
> >>This looks a bit like a hack and it doesn't look right,
> >>conceptually. If the call fails, it should restore things as if
> >>nothing has ever happened and overwriting old_mapping is not going to
> >>do the trick.
> >
> >OK, I thought this is what the patch does as it falls back to
> >>i_data which is the default mapping for all inodes or it uses
> >what used to be in device mapping.
> >
> >I am obviously not familiar with the drm code but it feels a bit strange
> >that the device mapping can be different than inode's resp. file's one
> 
> The reason for this is explained in commit message associated with
> 949c4a34.
> 
> In summary, the device's mapping is that of the inode associated with the
> first opener. Before 949c4a34, subsequent openers would have to come in
> through exactly the same inode that the first opener came in
> (otherwise the open call would fail). So if a user did something
> like: start X, remove /dev/dri/cardN file, mknod the same file
> again, the applications started after such an action would stop
> working. Also, using the GPU from chroot-ed environment was not
> possible if there was another opener from different root.

Oh, I see. Thanks for the clarification.

> The 949c4a34, removed this restriction, but introduced a problem
> with VmWare GPU drivers, which fdb40a08. However, fdb40a08
> introduced the bug that you have reported.
> 
> The problem that I have with your proposed fix is that if the first
> opener fails, it can set the device's mapping to that of the inode
> that was never used and never opened (and could even be removed
> later down the road).

Makes sense.

> >and even more confusing that inode and file are saved separately.
> >
> 
> I was trying to quickly get out the patch that was safe in terms of
> introducing new breakage. So the "conservative" thing to do (without
> having to think through all possible scenarios) was to restore each
> of the three pointers from their own temporary variable. Thinking
> about it, you are probably right that file descriptor's and inode's
> mapping pointer are equal when open call is entered so we could use
> one variable. However, you still need a separate variable to store
> the device's mapping pointer because that one can be different.

Right.

> Attached is a v2 of the patch, for reference. I would appreciate if
> the original reporter or you tested it in lieu of your proposed
> patch and let me know if it fixes your issue.

OK, this is a call for Marco. I have attached this bug to our bugzilla
as well (just for reference:
https://bugzilla.novell.com/show_bug.cgi?id=807850)

> 
> -- Ilija

> From 7e3c832158e2552e5e106a588e2b9e61c35b68f2 Mon Sep 17 00:00:00 2001
> From: Ilija Hadzic 
> Date: Sat, 30 Mar 2013 18:20:35 -0400
> Subject: [PATCH] drm: correctly restore mappings if drm_open fails
> 
> If first drm_open fails, the error-handling path will
> incorrectly restore inode's mapping to NULL. This can
> cause the crash later on. Fix by separately storing
> away mapping pointers that drm_open can touch and
> restore each from its own respective variable if the
> call fails.
> 
> Reference:
> http://lists.freedesktop.org/archives/dri-devel/2013-March/036564.html
> 
> v2: use one variable to store file and inode mapping
> since they are the same at the function entry; also
> fix spelling mistakes in commit message.
> 
> Reported-by: Marco Munderloh 
> Signed-off-by: Ilija Hadzic 
> Cc: Michal Hocko 
> Cc: stable at vger.kernel.org

Feel free to add
Reviewed-by: Michal Hocko 

Thanks!

> Signed-off-by: Ilija Hadzic 
> ---
>  drivers/gpu/drm/drm_fops.c |6 --
>  1 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
> index 13fdcd1..429e07d 100644
> --- a/drivers/gpu/drm/drm_fops.c
> +++ b/drivers/gpu/drm/drm_fops.c
> @@ -123,6 +123,7 @@ int drm_open(struct inode *inode, struct file *filp)
>   int retcode = 0;
>   int need_setup = 0;
>   struct address_space *old_mapping;
> + struct address_space *old_imapping;
>  
>   minor = idr_find(_minors_idr, minor_id);
>   if (!minor)
> @@ -137,6 +138,7 @@ int drm_open(struct inode *inode, struct file *filp)
>   if (!dev->open_count++)
>   need_setup = 1;
>   mutex_lock(>struct_mutex);
> + old_imapping = inode->i_mapping;
>   old_mapping = dev->dev_mapping;
>   if (old_mapping == NULL)
>   dev->dev_mapping = >i_data;
> @@ -159,8 +161,8 @@ int drm_open(struct inode *inode, struct file *filp)
>  
>  err_undo:
>   mutex_lock(>struct_mutex);
> - filp->f_mapping = old_mapping;
> - inode->i_mapping = old_mapping;
> + filp->f_mapping = old_imapping;
> + inode->i_mapping = old_imapping;
>   iput(container_of(dev->dev_mapping, struct inode, i_data));
>

[Bug 62756] Rendering errors on rv790 with llvm and unigine heaven 3.0

https://bugs.freedesktop.org/show_bug.cgi?id=62756

--- Comment #3 from Andy Furniss  ---
Created attachment 77308
  --> https://bugs.freedesktop.org/attachment.cgi?id=77308=edit
heaven regressed more with current heads

The recent changes to llvm and mesa have regressed heaven more.

Still OK with R600_LLVM=0, and other games are not affected.

-- 
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/20130402/4b637ac6/attachment-0001.html>

[PATCH]gpu:drm: Add missing dependency on DRM KMS/FB CMA helper

2013-04-02 Thread Wang YanQing

Commit 2e3b3c42f06ff6801b3d7839757bbdb231619083
(Add DRM KMS/FB CMA helper) add a kbuild entry,
config DRM_KMS_CMA_HELPER, in DRM's Kconfig without
dependence on DRM, it cause DRM's kconfig can't
be show in a submenu.

This patch fix it.

Signed-off-by: Wang YanQing 
---
 drivers/gpu/drm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 1e82882..28e3cb4 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -63,6 +63,7 @@ config DRM_GEM_CMA_HELPER

 config DRM_KMS_CMA_HELPER
bool
+   depends on DRM
select DRM_GEM_CMA_HELPER
select FB_SYS_FILLRECT
select FB_SYS_COPYAREA
-- 
1.7.12.4.dirty

drm/tilcdc: LCD panels clocks initialization and earlier backlight initialization

2013-04-02 Thread Rob Clark

On Tue, Apr 2, 2013 at 4:45 AM, Michal Bachraty
 wrote:
> Hi Rob,
>
> On Monday, April 01, 2013 09:46:05 Rob Clark wrote:
>> On Mon, Apr 1, 2013 at 7:31 AM, Hiremath, Vaibhav  wrote:
>> >> -Original Message-
>> >> From: devicetree-discuss [mailto:devicetree-discuss-
>> >> bounces+hvaibhav=ti.com at lists.ozlabs.org] On Behalf Of Michal Bachraty
>> >> Sent: Thursday, March 28, 2013 11:02 PM
>> >> To: dri-devel at lists.freedesktop.org; devicetree-
>> >> discuss at lists.ozlabs.org
>> >> Cc: robdclark at gmail.com; koen at dominion.thruhere.net
>> >> Subject: drm/tilcdc: LCD panels clocks initialization and earlier
>> >> backlight initialization
>> >>
>> >> Hi,
>> >>
>> >> I'm trying to use tilcdc driver for KWH050TG08 LCD panel connected to
>> >> AM335x
>> >> processor (3.9 rc1 kernel). I have prepared DT bindings for that
>> >> (listed
>> >> bellow). I see fb0 device but I have no clocks going from cpu to LCD.
>> >> My
>> >> clocks for LCD seems not properly to be set ...
>> >>
>> >> virt_2500_ck   1   12500
>> >>
>> >> sys_clkin_ck8   19   2500
>> >>
>> >>dpll_disp_ck 0   12500
>> >>
>> >>   dpll_disp_m2_ck   0   12500
>> >>
>> >>  lcd_gclk   0   12500
>> >>
>> >> and tilcdc_crtc is not called. I also set lcd_gclk to 300MHz, but I got
>> >> same
>> >> result. The question is there any way how to properly set clocks for
>> >> LCD?
>> >
>> > Not sure  about the LCDC DRM driver, but I just tested clk_set_rate()
>> > For lcdc_gclk clock and it is working for me. I could able to set
>> > 300MHz freq on my BeagleBone platform, with below code -
>>
>> fwiw, tilcdc drm driver won't set clocks until you do modeset, as it
>> is setting them based on the requested pixel clock.  As opposed to
>> setting it once at boot time.
>>
>> Michal, you may want to add 'drm.debug=7' in your bootargs, and send
>> the bootlog.  That should set some light about whether it is even
>> trying to modeset but failing, or some other issue.
>>
>
> Yes, here it is:

Hmm, looks like tilcdc_crtc_update_clk() is not getting called.. and
in fact either tilcdc_crtc_mode_set() is not called or bails out early
(maybe _mode_valid() falis?)

I'd perhaps throw a few traces in tilcdc_crtc_mode_set() and see why
that is bailing out..

BR,
-R


>
> [3.098732] platform audio.11: Driver snd-soc-am33xx-s800 requests probe
> deferral
> [ 3.107280] TCP: cubic registered
> [3.110822] Initializing XFRM netlink socket
> [3.115844] NET: Registered protocol family 10
> [3.123212] NET: Registered protocol family 17
> [3.128064] NET: Registered protocol family 15
> [3.133176] Key type dns_resolver registered
> [3.137846] VFP support v0.3: implementor 41 architecture 3 part 30 variant
> c rev 3
> [3.146087] ThumbEE CPU extension supported.
> [3.150659] Registering SWP/SWPB emulation handler
> [3.160695] registered taskstats version 1
> [3.166007] [drm:tilcdc_drm_init], init
> [3.171117] pinctrl core: add 1 pinmux maps
> [3.175564] pinctrl-single 44e10800.pinmux: found group selector 6 for
> pinmux_lcd_pins
> [3.183957] pinctrl-single 44e10800.pinmux: request pin 59 (44e108ec) for
> lcd_panel.15
> [3.192312] pinctrl-single 44e10800.pinmux: request pin 57 (44e108e4) for
> lcd_panel.15
> [3.200662] pinctrl-single 44e10800.pinmux: request pin 56 (44e108e0) for
> lcd_panel.15
> [3.209010] pinctrl-single 44e10800.pinmux: request pin 58 (44e108e8) for
> lcd_panel.15
> [3.217321] pinctrl-single 44e10800.pinmux: request pin 55 (44e108dc) for
> lcd_panel.15
> [3.225666] pinctrl-single 44e10800.pinmux: request pin 54 (44e108d8) for
> lcd_panel.15
> [3.234012] pinctrl-single 44e10800.pinmux: request pin 53 (44e108d4) for
> lcd_panel.15
> [3.242359] pinctrl-single 44e10800.pinmux: request pin 52 (44e108d0) for
> lcd_panel.15
> [3.250708] pinctrl-single 44e10800.pinmux: request pin 51 (44e108cc) for
> lcd_panel.15
> [3.259052] pinctrl-single 44e10800.pinmux: request pin 50 (44e108c8) for
> lcd_panel.15
> [3.267362] pinctrl-single 44e10800.pinmux: request pin 49 (44e108c4) for
> lcd_panel.15
> [3.275710] pinctrl-single 44e10800.pinmux: request pin 48 (44e108c0) for
> lcd_panel.15
> [3.284057] pinctrl-single 44e10800.pinmux: request pin 47 (44e108bc) for
> lcd_panel.15
> [3.292404] pinctrl-single 44e10800.pinmux: request pin 46 (44e108b8) for
> lcd_panel.15
> [3.300748] pinctrl-single 44e10800.pinmux: request pin 45 (44e108b4) for
> lcd_panel.15
> [3.309091] pinctrl-single 44e10800.pinmux: request pin 44 (44e108b0) for
> lcd_panel.15
> [3.317404] pinctrl-single 44e10800.pinmux: request pin 43 (44e108ac) for
> lcd_panel.15
> [3.325751] pinctrl-single 44e10800.pinmux: request pin 42 (44e108a8) for
> lcd_panel.15
> [3.334098] pinctrl-single

[PATCH] drm: correctly restore mappings if drm_open fails

If first drm_open fails, the error-handling path will
incorrectly restore inode's mapping to NULL. This can
cause the crash later on. Fix by separately storing
away mapping pointers that drm_open can touch and
restore each from its own respective variable if the
call fails.

Fixes: https://bugzilla.novell.com/show_bug.cgi?id=807850
(thanks to Michal Hocko for investigating investigating and
finding the root cause of the bug)

Reference:
http://lists.freedesktop.org/archives/dri-devel/2013-March/036564.html

v2: Use one variable to store file and inode mapping
since they are the same at the function entry.
Fix spelling mistakes in commit message.

v3: Add reference to the original bug report.

Reported-by: Marco Munderloh 
Tested-by: Marco Munderloh 
Signed-off-by: Ilija Hadzic 
Cc: Michal Hocko 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/drm_fops.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 13fdcd1..429e07d 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -123,6 +123,7 @@ int drm_open(struct inode *inode, struct file *filp)
int retcode = 0;
int need_setup = 0;
struct address_space *old_mapping;
+   struct address_space *old_imapping;

minor = idr_find(_minors_idr, minor_id);
if (!minor)
@@ -137,6 +138,7 @@ int drm_open(struct inode *inode, struct file *filp)
if (!dev->open_count++)
need_setup = 1;
mutex_lock(>struct_mutex);
+   old_imapping = inode->i_mapping;
old_mapping = dev->dev_mapping;
if (old_mapping == NULL)
dev->dev_mapping = >i_data;
@@ -159,8 +161,8 @@ int drm_open(struct inode *inode, struct file *filp)

 err_undo:
mutex_lock(>struct_mutex);
-   filp->f_mapping = old_mapping;
-   inode->i_mapping = old_mapping;
+   filp->f_mapping = old_imapping;
+   inode->i_mapping = old_imapping;
iput(container_of(dev->dev_mapping, struct inode, i_data));
dev->dev_mapping = old_mapping;
mutex_unlock(>struct_mutex);
-- 
1.8.1

[PATCH] drm: fix i_mapping and f_mapping initialization in drm_open in error path

On Tue, Apr 2, 2013 at 9:31 AM, Ilija Hadzic
 wrote:
>
> Marco,
>
> What makes you think that the crash after second modprobe is related to the
> mappings pointers in DRM module? Can you actually establish the correlation
> between these patches and the crash or you are just suspecting because your
> other bug had something to do with module removal/insertion?
>
> If it's the latter, then you may want to open another bug report here
> https://bugs.freedesktop.org/ (use DRI for product and pick DRM/radeon for
> component) and have this issue tracked and addressed separately.
>
> The divide error that your log shows apparently happens at this line
> inside r6xx_remap_render_backend:
>
> pipe_rb_ratio = rendering_pipe_num / req_rb_num;
>
> I would suspect that req_rb_num somehow evaluates to zero at the second
> modprobe. That variable seems to be the derived of the last three arguments
> to r6xx_remap_render_backend. If I look at the caller (evergreen_gpu_init)
> the arguments that have the play here are all derived from the GPU's
> hardware registers (or are the constant for a given GPU device). So I
> suspect that the GPU driver leaves some state in GPU at module removal that
> later bites you.

Newer kernels have a fix for this.
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f689e3acbd2e48cc4101e0af454193f81af4baaf

Alex

>
> -- Ilija
>
> On Tue, 2 Apr 2013, Marco Munderloh wrote:
>
>> Hi Ilija,
>>
>>> Thanks for testing. Other issues are probably unrelated, so I'll send the
>>> last version of the patch to Dave.
>>
>>
>> I came across another problem which seems related. rmmod radeon works,
>> however, modprobe radeon afterwards results in a crash (divide error), see
>> attachment.
>>
>> Best, Marco
>>
>> On 02.04.2013 13:23, Ilija Hadzic wrote:
>>>
>>>
>>> -- Ilija
>>>
>>> On Tue, Apr 2, 2013 at 6:36 AM, Marco Munderloh
>>> mailto:munderl at tnt.uni-hannover.de>> 
>>> wrote:
>>>
>>> Attached is a v2 of the patch, for reference. I would appreciate
>>> if the original reporter or you tested it in lieu of your proposed patch and
>>> let me know if it
>>> fixes your
>>> issue.
>>>
>>>
>>> The patch works for me. echo 3 > /proc/sys/vm/drop_caches as well as
>>> rmmod radeon do not end up in a crash anymore. However, I have still no clue
>>> why one of these makes
>>> drm_open to fail. On rmmod radeon I get the following log messages.
>>> If don't know if the 'unpin not necessary' has anything to do with it.
>>>
>>> [drm] radeon: finishing device.
>>> radeon :01:00.0: 88024e526c00 unpin not necessary
>>> radeon :01:00.0: 88024f2f6000 unpin not necessary
>>> radeon :01:00.0: 88024f2f6000 unpin not necessary
>>> [TTM] Finalizing pool allocator
>>> [TTM] Finalizing DMA pool allocator
>>> [TTM] Zone  kernel: Used memory at exit: 0 kiB
>>> [TTM] Zone   dma32: Used memory at exit: 0 kiB
>>> [drm] radeon: ttm finalized
>>> vga_switcheroo: disabled
>>> [drm] Module unloaded
>>>
>>> By the way, sometimes my r8169 ethernet controller does not survive
>>> suspend/hibernation (does not detect link). rmmod/modprobe helps. I don't
>>> know if this is related.
>>>
>>>
>>
>> --
>> Dipl.-Ing. Marco Munderloh Mail: munderl at tnt.uni-hannover.de
>> Institut f?r Informationsverarbeitung (TNT) Phone: +49 511 762-19587
>> Leibniz Universitaet Hannover, Appelstr. 9a   Fax: +49 511 762- 5333
>> 30167 Hannover, Germany Web: http://www.tnt.uni-hannover.de/~munderl
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[PATCH] drm: fix i_mapping and f_mapping initialization in drm_open in error path

Marco,

What makes you think that the crash after second modprobe is related to 
the mappings pointers in DRM module? Can you actually establish the 
correlation between these patches and the crash or you are just suspecting 
because your other bug had something to do with module removal/insertion?

If it's the latter, then you may want to open another bug report here 
https://bugs.freedesktop.org/ (use DRI for product and pick DRM/radeon for 
component) and have this issue tracked and addressed separately.

The divide error that your log shows apparently happens at this line
inside r6xx_remap_render_backend:

pipe_rb_ratio = rendering_pipe_num / req_rb_num;

I would suspect that req_rb_num somehow evaluates to zero at the second 
modprobe. That variable seems to be the derived of the last three 
arguments to r6xx_remap_render_backend. If I look at the caller 
(evergreen_gpu_init) the arguments that have the play here are all derived 
from the GPU's hardware registers (or are the constant for a given GPU 
device). So I suspect that the GPU driver leaves some state in GPU at 
module removal that later bites you.

-- Ilija

On Tue, 2 Apr 2013, Marco Munderloh wrote:

> Hi Ilija,
>
>> Thanks for testing. Other issues are probably unrelated, so I'll send the 
>> last version of the patch to Dave.
>
> I came across another problem which seems related. rmmod radeon works, 
> however, modprobe radeon afterwards results in a crash (divide error), see 
> attachment.
>
> Best, Marco
>
> On 02.04.2013 13:23, Ilija Hadzic wrote:
>> 
>> -- Ilija
>> 
>> On Tue, Apr 2, 2013 at 6:36 AM, Marco Munderloh 
>> mailto:munderl at tnt.uni-hannover.de>> 
>> wrote:
>>
>> Attached is a v2 of the patch, for reference. I would appreciate if 
>> the original reporter or you tested it in lieu of your proposed patch and 
>> let me know if it
>> fixes your
>> issue.
>> 
>>
>> The patch works for me. echo 3 > /proc/sys/vm/drop_caches as well as 
>> rmmod radeon do not end up in a crash anymore. However, I have still no 
>> clue why one of these makes
>> drm_open to fail. On rmmod radeon I get the following log messages. If 
>> don't know if the 'unpin not necessary' has anything to do with it.
>>
>> [drm] radeon: finishing device.
>> radeon :01:00.0: 88024e526c00 unpin not necessary
>> radeon :01:00.0: 88024f2f6000 unpin not necessary
>> radeon :01:00.0: 88024f2f6000 unpin not necessary
>> [TTM] Finalizing pool allocator
>> [TTM] Finalizing DMA pool allocator
>> [TTM] Zone  kernel: Used memory at exit: 0 kiB
>> [TTM] Zone   dma32: Used memory at exit: 0 kiB
>> [drm] radeon: ttm finalized
>> vga_switcheroo: disabled
>> [drm] Module unloaded
>>
>> By the way, sometimes my r8169 ethernet controller does not survive 
>> suspend/hibernation (does not detect link). rmmod/modprobe helps. I don't 
>> know if this is related.
>> 
>> 
>
> -- 
> Dipl.-Ing. Marco Munderloh Mail: munderl at tnt.uni-hannover.de
> Institut f?r Informationsverarbeitung (TNT) Phone: +49 511 762-19587
> Leibniz Universitaet Hannover, Appelstr. 9a   Fax: +49 511 762- 5333
> 30167 Hannover, Germany Web: http://www.tnt.uni-hannover.de/~munderl
>

[Bug 61182] r600g causes KWin crashes with kernel 3.8

https://bugs.freedesktop.org/show_bug.cgi?id=61182

ogjerstad at gmail.com changed:

   What|Removed |Added

 CC||ogjerstad at gmail.com

--- Comment #22 from ogjerstad at gmail.com ---
I can also confirm this bug on Fedora 18 X86_64, radeon driver, HD5870 card.
I cannot log into the system with two external monitors attached, but with only
one external monitor it works fine. This seems to have started to happen after
upgrade to mesa-dri-drivers 9.1-1 or 9.1-3 (I did not restart between those
updates). Here is my backtrace:
b7b62d4d01e98c8b31d95895cbede393b8b0c6e8 0x8954b __memset_sse2 /lib64/libc.so.6
45eccba94f5fef95c8933974ac014d83e50a9ebb
c9e82f1ca30be88ed6ef697aa581a1c940858291 0x349ff2 r600_texture_create_object
/usr/lib64/dri/r600_dri.so 4f51004f888b1ba8194719f476c2fd4ff4aad900
c9e82f1ca30be88ed6ef697aa581a1c940858291 0x34a2c7 r600_texture_create
/usr/lib64/dri/r600_dri.so 5baaed899c5ecf15a1568310eff18dc385cdf50d
c9e82f1ca30be88ed6ef697aa581a1c940858291 0x35ca25 dri2_allocate_textures
/usr/lib64/dri/r600_dri.so 0a2fa38b05320f36fa5b90de563948aac101910e
c9e82f1ca30be88ed6ef697aa581a1c940858291 0x35b595 dri_st_framebuffer_validate
/usr/lib64/dri/r600_dri.so 45eccba94f5fef95c8933974ac014d83e50a9ebb
c9e82f1ca30be88ed6ef697aa581a1c940858291 0x35b7ce dri_set_tex_buffer2
/usr/lib64/dri/r600_dri.so 55f8abe768545f45025c61cca676f0352439722d
67f4899c1db4d10dd1558ccbb7b8fad4e81e3379 0x68702
_cogl_winsys_texture_pixmap_x11_update /lib64/libcogl.so.11
ac79bd8478de58b10ea1b2bbc9d920bfbe437214
67f4899c1db4d10dd1558ccbb7b8fad4e81e3379 0x66104
_cogl_texture_pixmap_x11_update /lib64/libcogl.so.11
96f709cfd3fe851395649feeda7d4dd459e3ca60
67f4899c1db4d10dd1558ccbb7b8fad4e81e3379 0x666ad
_cogl_texture_pixmap_x11_get_texture /lib64/libcogl.so.11
6179db327fe5f11fb226532cabb471745b820c8f
67f4899c1db4d10dd1558ccbb7b8fad4e81e3379 0x66709
_cogl_texture_pixmap_x11_get_type /lib64/libcogl.so.11
ad318b56f9bf3c97e02782cfada93e8f37221c59
67f4899c1db4d10dd1558ccbb7b8fad4e81e3379 0x437d9
cogl_pipeline_set_layer_texture /lib64/libcogl.so.11
ba1ae932f4a148b027fd73337e04d05fbae9862e
c043a38bda0d5dc29bb15a1e211273a4ec3dea5d 0x33eb2 set_texture_on_actor
/lib64/libmutter.so.0 47169c9a5b07212ae0061e199a81ca87080a2e4c
c043a38bda0d5dc29bb15a1e211273a4ec3dea5d 0x34008 set_texture
/lib64/libmutter.so.0 6647294c524f089a0c77389826b0a954c997c085
c043a38bda0d5dc29bb15a1e211273a4ec3dea5d 0x3491f meta_background_actor_update
/lib64/libmutter.so.0 184cb323b2f3eaf40fc3b375371bdf1393e6882a
c043a38bda0d5dc29bb15a1e211273a4ec3dea5d 0x3352a meta_compositor_process_event
/lib64/libmutter.so.0 5c8e84a4b7a1c62daf4be566f862cf325d9b1926
c043a38bda0d5dc29bb15a1e211273a4ec3dea5d 0x45367 event_callback
/lib64/libmutter.so.0 11cf28c10df323150560c808d8bf75e7ed72e0c8
c043a38bda0d5dc29bb15a1e211273a4ec3dea5d 0x8f476 filter_func
/lib64/libmutter.so.0 7bfd96ce0e83046b4b4da64b6d99cf1d3ce823d6
1c54a46d2f8de1beadccfa39550b5eef67ab6bc0 0x4a901 gdk_event_apply_filters
/lib64/libgdk-3.so.0 a28856cf0bdff41c2ad87be20d4186aeea868a26
1c54a46d2f8de1beadccfa39550b5eef67ab6bc0 0x4aad7 _gdk_x11_display_queue_events
/lib64/libgdk-3.so.0 50da1079f5dfea096a6ddfd4caca8af2b76726e4
1c54a46d2f8de1beadccfa39550b5eef67ab6bc0 0x20511 gdk_display_get_event
/lib64/libgdk-3.so.0 457cc16f8850789e7b3830330439fcf89b9a418b
1c54a46d2f8de1beadccfa39550b5eef67ab6bc0 0x4a812 gdk_event_source_dispatch
/lib64/libgdk-3.so.0 d2af43c4e5d993f84766ffa06ddb024ac500e725
9442c0d3ccde3c8dbc81f858e03246a133f086d6 0x47a55 g_main_context_dispatch
/lib64/libglib-2.0.so.0 d4b6d4f2836ef32bd9d5847446bdcc7c19cfa379
9442c0d3ccde3c8dbc81f858e03246a133f086d6 0x47d88 g_main_context_iterate.isra.24
/lib64/libglib-2.0.so.0 ba0d551b7f0614ded38071cba2b37e156703e7f2
9442c0d3ccde3c8dbc81f858e03246a133f086d6 0x48182 g_main_loop_run
/lib64/libglib-2.0.so.0 97ad0c44e2f6c8d6c6037025add5aa29f54a351c
c043a38bda0d5dc29bb15a1e211273a4ec3dea5d 0x53467 meta_run /lib64/libmutter.so.0
0e5cc7fe0eb8f1fbe596e745f6fb64c36c5455ed
b7584e5ed0db7d29ef55ff77ab8344f06b0c3f94 0x1e2c main /usr/bin/gnome-shell
bd96fec6192e77e3dbc72e49eae3be6a52f6ef62

-- 
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/20130402/b0951029/attachment-0001.html>

[Bug 62889] ColorTiling results in glitches on Radeon HD 7970 + Glamor

https://bugs.freedesktop.org/show_bug.cgi?id=62889

--- Comment #7 from Michel D?nzer  ---
This is why ColorTiling is still disabled by default for your card... just
leave it at that? :)

(In reply to comment #5)
> If I disable ColorTiling, Gnome doesn't load completely only showing the
> desktop wallpaper Errors about unable to find displaybuffer (or something
> like that... not sure of exact error)

Sounds like a separate issue. FWIW, 'unable to find displaybuffer' sounds like
something I've seen myself, though AFAIR without ill effect.

-- 
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/20130402/86220365/attachment.html>

[PATCH] drm: fix i_mapping and f_mapping initialization in drm_open in error path

Thanks for testing. Other issues are probably unrelated, so I'll send the
last version of the patch to Dave.

-- Ilija

On Tue, Apr 2, 2013 at 6:36 AM, Marco Munderloh  wrote:

> Attached is a v2 of the patch, for reference. I would appreciate if the
>> original reporter or you tested it in lieu of your proposed patch and let
>> me know if it fixes your
>> issue.
>>
>
> The patch works for me. echo 3 > /proc/sys/vm/drop_caches as well as rmmod
> radeon do not end up in a crash anymore. However, I have still no clue why
> one of these makes drm_open to fail. On rmmod radeon I get the following
> log messages. If don't know if the 'unpin not necessary' has anything to do
> with it.
>
> [drm] radeon: finishing device.
> radeon :01:00.0: 88024e526c00 unpin not necessary
> radeon :01:00.0: 88024f2f6000 unpin not necessary
> radeon :01:00.0: 88024f2f6000 unpin not necessary
> [TTM] Finalizing pool allocator
> [TTM] Finalizing DMA pool allocator
> [TTM] Zone  kernel: Used memory at exit: 0 kiB
> [TTM] Zone   dma32: Used memory at exit: 0 kiB
> [drm] radeon: ttm finalized
> vga_switcheroo: disabled
> [drm] Module unloaded
>
> By the way, sometimes my r8169 ethernet controller does not survive
> suspend/hibernation (does not detect link). rmmod/modprobe helps. I don't
> know if this is related.
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130402/91215733/attachment.html>

[Bug 61182] r600g causes KWin crashes with kernel 3.8

 in KWin::SceneOpenGL::paint(QRegion,
QList<KWin::Toplevel*>) () from /usr/lib/libkdeinit4_kwin.so
#25 0x7fb64b96efcc in KWin::Compositor::performCompositing() () from
/usr/lib/libkdeinit4_kwin.so
#26 0x7fb64b96faa0 in KWin::Compositor::slotCompositingOptionsInitialized()
() from /usr/lib/libkdeinit4_kwin.so
#27 0x7fb6469b8b8f in QMetaObject::activate(QObject*, QMetaObject const*,
int, void**) () from /usr/lib/libQtCore.so.4
#28 0x7fb646897487 in QFutureWatcherBase::event(QEvent*) () from
/usr/lib/libQtCore.so.4
#29 0x7fb645b3618c in QApplicationPrivate::notify_helper(QObject*, QEvent*)
() from /usr/lib/libQtGui.so.4
#30 0x7fb645b3a60a in QApplication::notify(QObject*, QEvent*) () from
/usr/lib/libQtGui.so.4
#31 0x7fb64b0eb8c6 in KApplication::notify(QObject*, QEvent*) () from
/usr/lib/libkdeui.so.5
#32 0x7fb6469a36ae in QCoreApplication::notifyInternal(QObject*, QEvent*)
() from /usr/lib/libQtCore.so.4
#33 0x7fb6469a7011 in QCoreApplicationPrivate::sendPostedEvents(QObject*,
int, QThreadData*) () from /usr/lib/libQtCore.so.4
#34 0x7fb645bd731c in ?? () from /usr/lib/libQtGui.so.4
#35 0x7fb6469a23ff in
QEventLoop::processEvents(QFlags) () from
/usr/lib/libQtCore.so.4
#36 0x7fb6469a2688 in
QEventLoop::exec(QFlags) () from
/usr/lib/libQtCore.so.4
#37 0x7fb6469a7328 in QCoreApplication::exec() () from
/usr/lib/libQtCore.so.4
#38 0x7fb64b925d9a in kdemain () from /usr/lib/libkdeinit4_kwin.so
#39 0x7fb64b532a15 in __libc_start_main () from /usr/lib/libc.so.6
#40 0x00400701 in _start ()

-- 
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/20130402/5188f46f/attachment-0001.html>

[Bug 62226] Build Fails with LLVM

https://bugs.freedesktop.org/show_bug.cgi?id=62226

Johannes Obermayr  changed:

   What|Removed |Added

 CC||andreas.boll.dev at gmail.com,
   ||johannesobermayr at gmx.de

--- Comment #10 from Johannes Obermayr  ---
(In reply to comment #9)
> (In reply to comment #8)
> > I am against this sort of patches.
> > 
> 
> Can you explain why?

Because you are working against aboll and me - we want to build as much
'-shared' as possible (and also distributions [should] want to do so):
http://lists.freedesktop.org/archives/mesa-dev/2013-March/036449.html
http://lists.freedesktop.org/archives/mesa-dev/2013-March/036493.html

Also this statement is wrong:
"This library was originally changed to a shared object to work around
linker error in egl_static.so, but these appear to be fixed now."

It was changed to be built '-shared' because there were and possibly be
troubles with crashing egl things if r600 AND radeonsi were built together (see
on #dri-devel from mid december 2012 [MrCooper, jobermayr])

You should also see the conditional there. If it makes sense and is required
(r600 AND radeonsi) it is shared. If it doesn't (r600 XOR radeonsi) it is
static.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

[PATCH] drm/tilcdc: Disable building as module

2013-04-02 Thread Guenter Roeck

Attempts to compile tilcdc as module results in:

drivers/gpu/drm/tilcdc/tilcdc_slave.o:(.data+0x54): multiple definition of
`__mod_of_device_table'
drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
drivers/gpu/drm/tilcdc/tilcdc_panel.o:(.data+0x54): multiple definition of
`__mod_of_device_table'
drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
drivers/gpu/drm/tilcdc/tilcdc_drv.o:(.data+0x184): multiple definition of
`__mod_of_device_table'
drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
make[5]: [drivers/gpu/drm/tilcdc/tilcdc.o] Error 1 (ignored)

It appears it was never even tried to build it as module, or the problem
would have been seen. So running this driver as module was never really
tested. Disable it. If really needed, the code wil require some structural
changes and in-depth testing, which can and should be done separately.

Cc: Rob Clark robdcl...@gmail.com
Signed-off-by: Guenter Roeck li...@roeck-us.net
---
 drivers/gpu/drm/tilcdc/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/Kconfig b/drivers/gpu/drm/tilcdc/Kconfig
index d24d040..6ddb729 100644
--- a/drivers/gpu/drm/tilcdc/Kconfig
+++ b/drivers/gpu/drm/tilcdc/Kconfig
@@ -1,5 +1,5 @@
 config DRM_TILCDC
-   tristate DRM Support for TI LCDC Display Controller
+   bool DRM Support for TI LCDC Display Controller
depends on DRM  OF  ARM
select DRM_KMS_HELPER
select DRM_KMS_CMA_HELPER
-- 
1.7.9.7

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH]gpu:drm: Add missing dependency on DRM KMS/FB CMA helper

2013-04-02 Thread Wang YanQing

Commit 2e3b3c42f06ff6801b3d7839757bbdb231619083
(Add DRM KMS/FB CMA helper) add a kbuild entry,
config DRM_KMS_CMA_HELPER, in DRM's Kconfig without
dependence on DRM, it cause DRM's kconfig can't
be show in a submenu.

This patch fix it.

Signed-off-by: Wang YanQing udkni...@gmail.com
---
 drivers/gpu/drm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 1e82882..28e3cb4 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -63,6 +63,7 @@ config DRM_GEM_CMA_HELPER
 
 config DRM_KMS_CMA_HELPER
bool
+   depends on DRM
select DRM_GEM_CMA_HELPER
select FB_SYS_FILLRECT
select FB_SYS_COPYAREA
-- 
1.7.12.4.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/exynos: change the method for getting the interrupt resource of FIMD

2013-04-02 Thread Vikas Sajjan

Hi Mr. Inki Dae,

Can you please review this patch.?

On Wed, Mar 13, 2013 at 4:22 PM, Vikas Sajjan vikas.saj...@linaro.org wrote:
 Replaces the platform_get_resource() for IORESOURCE_IRQ with
 platform_get_resource_byname().
 Both in exynos4 and exynos5, FIMD IP has 3 interrupts in the order: fifo,
 vsync, and lcd_sys.
 But The FIMD driver expects the vsync interrupt to be mentioned as the
 1st parameter in the FIMD DT node. So to meet this expectation of the
 driver, the FIMD DT node was forced to be made by keeping vsync as the
 1st paramter.
 For example in exynos4, the FIMD DT node has interrupt numbers
 mentioned as 11, 1 11, 0 11, 2 keeping vsync as the 1st paramter.

 This patch fixes the above mentioned hack of re-ordering of the
 FIMD interrupt numbers by getting interrupt resource of FIMD by using
 platform_get_resource_byname().

 Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
 ---
  drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
 b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 index 1ea173a..cd79d38 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 @@ -945,7 +945,7 @@ static int fimd_probe(struct platform_device *pdev)
 return -ENXIO;
 }

 -   res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
 +   res = platform_get_resource_byname(pdev, IORESOURCE_IRQ, vsync);
 if (!res) {
 dev_err(dev, irq request failed.\n);
 return -ENXIO;
 --
 1.7.9.5

 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 62889] ColorTiling results in glitches on Radeon HD 7970 + Glamor

https://bugs.freedesktop.org/show_bug.cgi?id=62889

--- Comment #7 from Michel Dänzer mic...@daenzer.net ---
This is why ColorTiling is still disabled by default for your card... just
leave it at that? :)

(In reply to comment #5)
 If I disable ColorTiling, Gnome doesn't load completely only showing the
 desktop wallpaper Errors about unable to find displaybuffer (or something
 like that... not sure of exact error)

Sounds like a separate issue. FWIW, 'unable to find displaybuffer' sounds like
something I've seen myself, though AFAIR without ill effect.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 61182] r600g causes KWin crashes with kernel 3.8

https://bugs.freedesktop.org/show_bug.cgi?id=61182

ogjers...@gmail.com changed:

   What|Removed |Added

 CC||ogjers...@gmail.com

--- Comment #22 from ogjers...@gmail.com ---
I can also confirm this bug on Fedora 18 X86_64, radeon driver, HD5870 card.
I cannot log into the system with two external monitors attached, but with only
one external monitor it works fine. This seems to have started to happen after
upgrade to mesa-dri-drivers 9.1-1 or 9.1-3 (I did not restart between those
updates). Here is my backtrace:
b7b62d4d01e98c8b31d95895cbede393b8b0c6e8 0x8954b __memset_sse2 /lib64/libc.so.6
45eccba94f5fef95c8933974ac014d83e50a9ebb
c9e82f1ca30be88ed6ef697aa581a1c940858291 0x349ff2 r600_texture_create_object
/usr/lib64/dri/r600_dri.so 4f51004f888b1ba8194719f476c2fd4ff4aad900
c9e82f1ca30be88ed6ef697aa581a1c940858291 0x34a2c7 r600_texture_create
/usr/lib64/dri/r600_dri.so 5baaed899c5ecf15a1568310eff18dc385cdf50d
c9e82f1ca30be88ed6ef697aa581a1c940858291 0x35ca25 dri2_allocate_textures
/usr/lib64/dri/r600_dri.so 0a2fa38b05320f36fa5b90de563948aac101910e
c9e82f1ca30be88ed6ef697aa581a1c940858291 0x35b595 dri_st_framebuffer_validate
/usr/lib64/dri/r600_dri.so 45eccba94f5fef95c8933974ac014d83e50a9ebb
c9e82f1ca30be88ed6ef697aa581a1c940858291 0x35b7ce dri_set_tex_buffer2
/usr/lib64/dri/r600_dri.so 55f8abe768545f45025c61cca676f0352439722d
67f4899c1db4d10dd1558ccbb7b8fad4e81e3379 0x68702
_cogl_winsys_texture_pixmap_x11_update /lib64/libcogl.so.11
ac79bd8478de58b10ea1b2bbc9d920bfbe437214
67f4899c1db4d10dd1558ccbb7b8fad4e81e3379 0x66104
_cogl_texture_pixmap_x11_update /lib64/libcogl.so.11
96f709cfd3fe851395649feeda7d4dd459e3ca60
67f4899c1db4d10dd1558ccbb7b8fad4e81e3379 0x666ad
_cogl_texture_pixmap_x11_get_texture /lib64/libcogl.so.11
6179db327fe5f11fb226532cabb471745b820c8f
67f4899c1db4d10dd1558ccbb7b8fad4e81e3379 0x66709
_cogl_texture_pixmap_x11_get_type /lib64/libcogl.so.11
ad318b56f9bf3c97e02782cfada93e8f37221c59
67f4899c1db4d10dd1558ccbb7b8fad4e81e3379 0x437d9
cogl_pipeline_set_layer_texture /lib64/libcogl.so.11
ba1ae932f4a148b027fd73337e04d05fbae9862e
c043a38bda0d5dc29bb15a1e211273a4ec3dea5d 0x33eb2 set_texture_on_actor
/lib64/libmutter.so.0 47169c9a5b07212ae0061e199a81ca87080a2e4c
c043a38bda0d5dc29bb15a1e211273a4ec3dea5d 0x34008 set_texture
/lib64/libmutter.so.0 6647294c524f089a0c77389826b0a954c997c085
c043a38bda0d5dc29bb15a1e211273a4ec3dea5d 0x3491f meta_background_actor_update
/lib64/libmutter.so.0 184cb323b2f3eaf40fc3b375371bdf1393e6882a
c043a38bda0d5dc29bb15a1e211273a4ec3dea5d 0x3352a meta_compositor_process_event
/lib64/libmutter.so.0 5c8e84a4b7a1c62daf4be566f862cf325d9b1926
c043a38bda0d5dc29bb15a1e211273a4ec3dea5d 0x45367 event_callback
/lib64/libmutter.so.0 11cf28c10df323150560c808d8bf75e7ed72e0c8
c043a38bda0d5dc29bb15a1e211273a4ec3dea5d 0x8f476 filter_func
/lib64/libmutter.so.0 7bfd96ce0e83046b4b4da64b6d99cf1d3ce823d6
1c54a46d2f8de1beadccfa39550b5eef67ab6bc0 0x4a901 gdk_event_apply_filters
/lib64/libgdk-3.so.0 a28856cf0bdff41c2ad87be20d4186aeea868a26
1c54a46d2f8de1beadccfa39550b5eef67ab6bc0 0x4aad7 _gdk_x11_display_queue_events
/lib64/libgdk-3.so.0 50da1079f5dfea096a6ddfd4caca8af2b76726e4
1c54a46d2f8de1beadccfa39550b5eef67ab6bc0 0x20511 gdk_display_get_event
/lib64/libgdk-3.so.0 457cc16f8850789e7b3830330439fcf89b9a418b
1c54a46d2f8de1beadccfa39550b5eef67ab6bc0 0x4a812 gdk_event_source_dispatch
/lib64/libgdk-3.so.0 d2af43c4e5d993f84766ffa06ddb024ac500e725
9442c0d3ccde3c8dbc81f858e03246a133f086d6 0x47a55 g_main_context_dispatch
/lib64/libglib-2.0.so.0 d4b6d4f2836ef32bd9d5847446bdcc7c19cfa379
9442c0d3ccde3c8dbc81f858e03246a133f086d6 0x47d88 g_main_context_iterate.isra.24
/lib64/libglib-2.0.so.0 ba0d551b7f0614ded38071cba2b37e156703e7f2
9442c0d3ccde3c8dbc81f858e03246a133f086d6 0x48182 g_main_loop_run
/lib64/libglib-2.0.so.0 97ad0c44e2f6c8d6c6037025add5aa29f54a351c
c043a38bda0d5dc29bb15a1e211273a4ec3dea5d 0x53467 meta_run /lib64/libmutter.so.0
0e5cc7fe0eb8f1fbe596e745f6fb64c36c5455ed
b7584e5ed0db7d29ef55ff77ab8344f06b0c3f94 0x1e2c main /usr/bin/gnome-shell
bd96fec6192e77e3dbc72e49eae3be6a52f6ef62

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: fix i_mapping and f_mapping initialization in drm_open in error path

2013-04-02 Thread Michal Hocko

On Mon 01-04-13 13:14:50, Ilija Hadzic wrote:
 
 
 On Sun, 31 Mar 2013, Michal Hocko wrote:
 
 On Sat 30-03-13 18:26:53, Ilija Hadzic wrote:
 This looks a bit like a hack and it doesn't look right,
 conceptually. If the call fails, it should restore things as if
 nothing has ever happened and overwriting old_mapping is not going to
 do the trick.
 
 OK, I thought this is what the patch does as it falls back to
 inode-i_data which is the default mapping for all inodes or it uses
 what used to be in device mapping.
 
 I am obviously not familiar with the drm code but it feels a bit strange
 that the device mapping can be different than inode's resp. file's one
 
 The reason for this is explained in commit message associated with
 949c4a34.
 
 In summary, the device's mapping is that of the inode associated with the
 first opener. Before 949c4a34, subsequent openers would have to come in
 through exactly the same inode that the first opener came in
 (otherwise the open call would fail). So if a user did something
 like: start X, remove /dev/dri/cardN file, mknod the same file
 again, the applications started after such an action would stop
 working. Also, using the GPU from chroot-ed environment was not
 possible if there was another opener from different root.

Oh, I see. Thanks for the clarification.

 The 949c4a34, removed this restriction, but introduced a problem
 with VmWare GPU drivers, which fdb40a08. However, fdb40a08
 introduced the bug that you have reported.
 
 The problem that I have with your proposed fix is that if the first
 opener fails, it can set the device's mapping to that of the inode
 that was never used and never opened (and could even be removed
 later down the road).

Makes sense.

 and even more confusing that inode and file are saved separately.
 
 
 I was trying to quickly get out the patch that was safe in terms of
 introducing new breakage. So the conservative thing to do (without
 having to think through all possible scenarios) was to restore each
 of the three pointers from their own temporary variable. Thinking
 about it, you are probably right that file descriptor's and inode's
 mapping pointer are equal when open call is entered so we could use
 one variable. However, you still need a separate variable to store
 the device's mapping pointer because that one can be different.

Right.

 Attached is a v2 of the patch, for reference. I would appreciate if
 the original reporter or you tested it in lieu of your proposed
 patch and let me know if it fixes your issue.

OK, this is a call for Marco. I have attached this bug to our bugzilla
as well (just for reference:
https://bugzilla.novell.com/show_bug.cgi?id=807850)

 
 -- Ilija

 From 7e3c832158e2552e5e106a588e2b9e61c35b68f2 Mon Sep 17 00:00:00 2001
 From: Ilija Hadzic ihad...@research.bell-labs.com
 Date: Sat, 30 Mar 2013 18:20:35 -0400
 Subject: [PATCH] drm: correctly restore mappings if drm_open fails
 
 If first drm_open fails, the error-handling path will
 incorrectly restore inode's mapping to NULL. This can
 cause the crash later on. Fix by separately storing
 away mapping pointers that drm_open can touch and
 restore each from its own respective variable if the
 call fails.
 
 Reference:
 http://lists.freedesktop.org/archives/dri-devel/2013-March/036564.html
 
 v2: use one variable to store file and inode mapping
 since they are the same at the function entry; also
 fix spelling mistakes in commit message.
 
 Reported-by: Marco Munderloh mund...@tnt.uni-hannover.de
 Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
 Cc: Michal Hocko mho...@suse.cz
 Cc: sta...@vger.kernel.org

Feel free to add
Reviewed-by: Michal Hocko mho...@suse.cz

Thanks!

 Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
 ---
  drivers/gpu/drm/drm_fops.c |6 --
  1 files changed, 4 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
 index 13fdcd1..429e07d 100644
 --- a/drivers/gpu/drm/drm_fops.c
 +++ b/drivers/gpu/drm/drm_fops.c
 @@ -123,6 +123,7 @@ int drm_open(struct inode *inode, struct file *filp)
   int retcode = 0;
   int need_setup = 0;
   struct address_space *old_mapping;
 + struct address_space *old_imapping;
  
   minor = idr_find(drm_minors_idr, minor_id);
   if (!minor)
 @@ -137,6 +138,7 @@ int drm_open(struct inode *inode, struct file *filp)
   if (!dev-open_count++)
   need_setup = 1;
   mutex_lock(dev-struct_mutex);
 + old_imapping = inode-i_mapping;
   old_mapping = dev-dev_mapping;
   if (old_mapping == NULL)
   dev-dev_mapping = inode-i_data;
 @@ -159,8 +161,8 @@ int drm_open(struct inode *inode, struct file *filp)
  
  err_undo:
   mutex_lock(dev-struct_mutex);
 - filp-f_mapping = old_mapping;
 - inode-i_mapping = old_mapping;
 + filp-f_mapping = old_imapping;
 + inode-i_mapping = old_imapping;
   iput(container_of(dev-dev_mapping, struct inode, i_data));

Re: [PATCH] drm/exynos: change the method for getting the interrupt resource of FIMD

2013-04-02 Thread Inki Dae

Applied. :)

Thanks,
Inki Dae


2013/4/2 Vikas Sajjan sajjan.li...@gmail.com

 Hi Mr. Inki Dae,

 Can you please review this patch.?

 On Wed, Mar 13, 2013 at 4:22 PM, Vikas Sajjan vikas.saj...@linaro.org
 wrote:
  Replaces the platform_get_resource() for IORESOURCE_IRQ with
  platform_get_resource_byname().
  Both in exynos4 and exynos5, FIMD IP has 3 interrupts in the order:
 fifo,
  vsync, and lcd_sys.
  But The FIMD driver expects the vsync interrupt to be mentioned as the
  1st parameter in the FIMD DT node. So to meet this expectation of the
  driver, the FIMD DT node was forced to be made by keeping vsync as the
  1st paramter.
  For example in exynos4, the FIMD DT node has interrupt numbers
  mentioned as 11, 1 11, 0 11, 2 keeping vsync as the 1st paramter.
 
  This patch fixes the above mentioned hack of re-ordering of the
  FIMD interrupt numbers by getting interrupt resource of FIMD by using
  platform_get_resource_byname().
 
  Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
  ---
   drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
 
  diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
  index 1ea173a..cd79d38 100644
  --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
  +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
  @@ -945,7 +945,7 @@ static int fimd_probe(struct platform_device *pdev)
  return -ENXIO;
  }
 
  -   res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
  +   res = platform_get_resource_byname(pdev, IORESOURCE_IRQ,
 vsync);
  if (!res) {
  dev_err(dev, irq request failed.\n);
  return -ENXIO;
  --
  1.7.9.5
 
  --
  To unsubscribe from this list: send the line unsubscribe linux-media in
  the body of a message to majord...@vger.kernel.org
  More majordomo info at  http://vger.kernel.org/majordomo-info.html
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-intel-next

Hi Dave,

So I've figured we should get drm-next for 3.10 started ;-)

Highlights:
- Imre's for_each_sg_pages rework (now also with the stolen mem backed
  case fixed with a hack) plus the drm prime sg list coalescing patch from
  Rahul Sharma. I have some follow-up cleanups pending, already acked by
  Andrew Morton.
- Some prep-work for the crazy no-pch/display-less platform by Ben.
- Some vlv patches, by far not all (Jesse et al).
- Clean up the HDMI/SDVO #define confusion (Paulo)
- gen2-4 vblank fixes from Ville.
- Unclaimed register warning fixes for hsw (Paulo). More still to come ...
- Complete pageflips which have been stuck in a gpu hang, should prevent
  stuck gl compositors (Ville).
- pm patches for vt-switchless resume (Jesse). Note that the i915 enabling
  is not (yet) included, that took a bit longer to settle. PM patches are
  acked by Rafael Wysocki.
- Minor fixlets all over from various people.

All together it's been pretty quiet thus far.

Cheers, Daniel


The following changes since commit a937536b868b8369b98967929045f1df54234323:

  Linux 3.9-rc3 (2013-03-17 15:59:32 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-next-2013-03-23

for you to fetch changes up to e3dff585508636c8d2915cc1595e04f16ccd66ba:

  drm/i915: Implement WaSwitchSolVfFArbitrationPriority (2013-03-23 12:18:06 
+0100)


Ben Widawsky (9):
  drm/i915: Created a sized object error dump
  drm/i915: exclude CCID for platforms without it
  drm/i915: Capture current context on error
  drm/i915: Remove unused file arg from execbuf
  drm/i915: Remove unneeded dev argument
  drm/i915: Move num_pipes to intel info
  drm/i915: Introduce GEN7_FEATURES for device info
  drm/i915: Correct sandybrige overclocking
  drm/i915: Implement WaSwitchSolVfFArbitrationPriority

Chris Wilson (1):
  drm/i915: Resurrect ring kicking for semaphores, selectively

Damien Lespiau (1):
  drm/i915: Remove platforms in the preliminary_hw_support description

Daniel Vetter (4):
  drm/i915: gen2 has no tv out support
  Merge tag 'v3.9-rc3' into drm-intel-next-queued
  style nit: Align function parameter continuation properly.
  drm/i915: fixup pd vs pt confusion in gen6 ppgtt code

Imre Deak (5):
  drm: handle compact dma scatter lists in drm_clflush_sg()
  drm/i915: set dummy page for stolen objects
  drm/i915: handle walking compact dma scatter lists
  drm/i915: create compact dma scatter lists for gem objects
  drm/i915: use for_each_sg_page for setting up the gtt ptes

Jani Nikula (2):
  drm/i915: add \n to the end of sysfs attributes
  drm/i915: reduce power in the ilk rc6 enable error message

Jesse Barnes (18):
  PM: make VT switching to the suspend console optional v3
  fb: add support for drivers not needing VT switch at suspend/resume time
  drm/i915: don't restore LVDS enable state blindly v2
  drm/i915: remove disabled memset of framebuffer from intel_fb
  drm/i915: don't init LVDS on VLV
  drm/i915: VLV has force wake
  drm/i915/dp: don't use ILK paths on VLV
  drm/i915: use gen6 stolen check on VLV
  drm/i915/dp: add pre-PCH eDP checking to DP detect for VLV
  drm/i915: allow force wake at init time on VLV v2
  drm/i915: don't use plane pipe select on VLV
  drm/i915: add media well to VLV force wake routines v2
  drm/i915: use VLV DIP routines on VLV v2
  drm/i915: add more VLV IDs
  drm/i915: fix WaDisablePSDDualDispatchEnable on VLV v2
  drm/i915: set conservative clock gating values on VLV v2
  drm/i915: DSPFW and BLC regs are in the display offset range
  drm/i915: VLV doesn't have HDMI on port C

Kees Cook (2):
  drm/i915: use simple attribute in debugfs routines
  drm/i915: clarify reasoning for the access_ok call

Mihnea Dobrescu-Balaur (1):
  gpu: don't cast kzalloc() return value

Mika Kuoppala (1):
  drm/i915: remove obsolete obj assignment in page flip

Paulo Zanoni (19):
  drm/i915: use HAS_DDI on intel_hdmi.c and intel_display.c
  drm/i915: wait_event_timeout's timeout is in jiffies
  drm/i915: add aux_ch_ctl_reg to struct intel_dp
  drm/i915: rename sdvox_reg to hdmi_reg on HDMI context
  drm/i915: create functions for the unclaimed register checks
  drm/i915: use FPGA_DBG for the unclaimed register checks
  drm/i915: clear the FPGA_DBG_RM_NOCLAIM bit at driver init
  drm/i915: clarify confusion between SDVO and HDMI registers
  drm/i915: unify the definitions of the HDMI/SDVO register
  drm/i915: remove duplicated SDVO/HDMI bit definitions
  drm/i915: rename some HDMI bit definitions
  drm/i915: disable sound first on intel_disable_ddi
  drm/i915: capture the correct cursor registers on IVB
  drm/i915: there's no DSPSIZE register on gen4+
  drm/i915: there's no

[Bug 62756] Rendering errors on rv790 with llvm and unigine heaven 3.0

https://bugs.freedesktop.org/show_bug.cgi?id=62756

--- Comment #3 from Andy Furniss li...@andyfurniss.entadsl.com ---
Created attachment 77308
  -- https://bugs.freedesktop.org/attachment.cgi?id=77308action=edit
heaven regressed more with current heads

The recent changes to llvm and mesa have regressed heaven more.

Still OK with R600_LLVM=0, and other games are not affected.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 61182] r600g causes KWin crashes with kernel 3.8

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #23 from ogjers...@gmail.com ---
I can confirm now that downgrading mesa-dri-drivers to 9.0.1-1 (as packaged by
Fedora) fixes the problem.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: fix i_mapping and f_mapping initialization in drm_open in error path

Thanks for testing. Other issues are probably unrelated, so I'll send the
last version of the patch to Dave.

-- Ilija

On Tue, Apr 2, 2013 at 6:36 AM, Marco Munderloh mund...@tnt.uni-hannover.de
 wrote:

 Attached is a v2 of the patch, for reference. I would appreciate if the
 original reporter or you tested it in lieu of your proposed patch and let
 me know if it fixes your
 issue.


 The patch works for me. echo 3  /proc/sys/vm/drop_caches as well as rmmod
 radeon do not end up in a crash anymore. However, I have still no clue why
 one of these makes drm_open to fail. On rmmod radeon I get the following
 log messages. If don't know if the 'unpin not necessary' has anything to do
 with it.

 [drm] radeon: finishing device.
 radeon :01:00.0: 88024e526c00 unpin not necessary
 radeon :01:00.0: 88024f2f6000 unpin not necessary
 radeon :01:00.0: 88024f2f6000 unpin not necessary
 [TTM] Finalizing pool allocator
 [TTM] Finalizing DMA pool allocator
 [TTM] Zone  kernel: Used memory at exit: 0 kiB
 [TTM] Zone   dma32: Used memory at exit: 0 kiB
 [drm] radeon: ttm finalized
 vga_switcheroo: disabled
 [drm] Module unloaded

 By the way, sometimes my r8169 ethernet controller does not survive
 suspend/hibernation (does not detect link). rmmod/modprobe helps. I don't
 know if this is related.


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] gma500: Make VGA and HDMI connector hotpluggable

On Sun, Mar 31, 2013 at 1:38 PM, Kero k...@chello.nl wrote:
 From: Kero van Gelder k...@chello.nl

 Both VGA and HDMI connectors are available on my Asus EeePC X101CH.
 This patch will cause output to be shown on either when plugged in.
 For both, it shows the leftmost 800x600, of the 1024x600 on LVDS.

 Signed-off-by: Kero van Gelder k...@chello.nl
 ---
 diff --git a/drivers/gpu/drm/gma500/cdv_intel_crt.c 
 b/drivers/gpu/drm/gma500/cdv_intel_crt.c
 index 8c17534..7b8386f 100644
 --- a/drivers/gpu/drm/gma500/cdv_intel_crt.c
 +++ b/drivers/gpu/drm/gma500/cdv_intel_crt.c
 @@ -276,6 +276,7 @@ void cdv_intel_crt_init(struct drm_device *dev,
 goto failed_connector;

 connector = psb_intel_connector-base;
 +   connector-polled = DRM_CONNECTOR_POLL_HPD;
 drm_connector_init(dev, connector,
 cdv_intel_crt_connector_funcs, DRM_MODE_CONNECTOR_VGA);

 diff --git a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c 
 b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
 index e223b50..464153d 100644
 --- a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
 +++ b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
 @@ -319,6 +319,7 @@ void cdv_hdmi_init(struct drm_device *dev,
 goto err_priv;

 connector = psb_intel_connector-base;
 +   connector-polled = DRM_CONNECTOR_POLL_HPD;
 encoder = psb_intel_encoder-base;
 drm_connector_init(dev, connector,
cdv_hdmi_connector_funcs,
 --

Your patch has been applied to:
https://github.com/patjak/drm-gma500.git gma500-next

We might also consider polling if this causes problems for people, but for now
this is fine. No biggie, but your tabs where converted to spaces so I recommend
running checkpatch.pl before submitting.

Thanks
Patrik Jakobsson
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 61182] r600g causes KWin crashes with kernel 3.8

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #24 from Alex Deucher ag...@yahoo.com ---
(In reply to comment #23)
 I can confirm now that downgrading mesa-dri-drivers to 9.0.1-1 (as packaged
 by Fedora) fixes the problem.

Can you bisect mesa?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drivers: gpu: drm: gma500: Replaced calls kzalloc memcpy with kmemdup

On Mon, Mar 11, 2013 at 8:46 PM, Alexandru Gheorghiu
gheorghiuan...@gmail.com wrote:
 Replaced calls kzalloc followed by memcpy with call to kmemdup.
 Patch found using coccinelle.

 Signed-off-by: Alexandru Gheorghiu gheorghiuan...@gmail.com
 ---
  drivers/gpu/drm/gma500/intel_bios.c |3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/gma500/intel_bios.c 
 b/drivers/gpu/drm/gma500/intel_bios.c
 index 403fffb..d349734 100644
 --- a/drivers/gpu/drm/gma500/intel_bios.c
 +++ b/drivers/gpu/drm/gma500/intel_bios.c
 @@ -218,12 +218,11 @@ static void parse_backlight_data(struct drm_psb_private 
 *dev_priv,
 bl_start = find_section(bdb, BDB_LVDS_BACKLIGHT);
 vbt_lvds_bl = (struct bdb_lvds_backlight *)(bl_start + 1) + p_type;

 -   lvds_bl = kzalloc(sizeof(*vbt_lvds_bl), GFP_KERNEL);
 +   lvds_bl = kmemdup(vbt_lvds_bl, sizeof(*vbt_lvds_bl), GFP_KERNEL);
 if (!lvds_bl) {
 dev_err(dev_priv-dev-dev, out of memory for backlight 
 data\n);
 return;
 }
 -   memcpy(lvds_bl, vbt_lvds_bl, sizeof(*vbt_lvds_bl));
 dev_priv-lvds_bl = lvds_bl;
  }

 --
 1.7.9.5

 --

Your patch has been applied to:
https://github.com/patjak/drm-gma500.git gma500-next

Thanks
Patrik Jakobsson
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] gma500: medfield: Fix possible NULL pointer dereference

On Sun, Feb 24, 2013 at 11:31 PM, Syam Sidhardhan
syamsidha...@gmail.com wrote:
 The use of pointer sender should be after the NULL check.

 Signed-off-by: Syam Sidhardhan s.s...@samsung.com
 ---
  drivers/gpu/drm/gma500/mdfld_dsi_output.c |7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_output.c 
 b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
 index 2d4ab48..3abf831 100644
 --- a/drivers/gpu/drm/gma500/mdfld_dsi_output.c
 +++ b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
 @@ -92,8 +92,8 @@ void mdfld_dsi_brightness_init(struct mdfld_dsi_config 
 *dsi_config, int pipe)
  {
 struct mdfld_dsi_pkg_sender *sender =
 mdfld_dsi_get_pkg_sender(dsi_config);
 -   struct drm_device *dev = sender-dev;
 -   struct drm_psb_private *dev_priv = dev-dev_private;
 +   struct drm_device *dev;
 +   struct drm_psb_private *dev_priv;
 u32 gen_ctrl_val;

 if (!sender) {
 @@ -101,6 +101,9 @@ void mdfld_dsi_brightness_init(struct mdfld_dsi_config 
 *dsi_config, int pipe)
 return;
 }

 +   dev = sender-dev;
 +   dev_priv = dev-dev_private;
 +
 /* Set default display backlight value to 85% (0xd8)*/
 mdfld_dsi_send_mcs_short(sender, write_display_brightness, 0xd8, 1,
 true);
 --
 1.7.9.5

Your patch has been applied to:
https://github.com/patjak/drm-gma500.git gma500-next

Thanks
Patrik Jakobsson
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 62226] Build Fails with LLVM

https://bugs.freedesktop.org/show_bug.cgi?id=62226

--- Comment #11 from Christian König deathsim...@vodafone.de ---
(In reply to comment #10)
 (In reply to comment #9)
  (In reply to comment #8)
   I am against this sort of patches.
   
  
  Can you explain why?
 
 Because you are working against aboll and me - we want to build as much
 '-shared' as possible (and also distributions [should] want to do so):
 http://lists.freedesktop.org/archives/mesa-dev/2013-March/036449.html
 http://lists.freedesktop.org/archives/mesa-dev/2013-March/036493.html
 
 Also this statement is wrong:
 This library was originally changed to a shared object to work around
 linker error in egl_static.so, but these appear to be fixed now.
 
 It was changed to be built '-shared' because there were and possibly be
 troubles with crashing egl things if r600 AND radeonsi were built together
 (see on #dri-devel from mid december 2012 [MrCooper, jobermayr])
 
 You should also see the conditional there. If it makes sense and is required
 (r600 AND radeonsi) it is shared. If it doesn't (r600 XOR radeonsi) it is
 static.

I don't think I like the general idea here, for most distributions driver size
doesn't matter so much, but on the other hand it is highly likely that we want
to have different version of this and other libs for r600 and radeonsi.

Christian.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: fix i_mapping and f_mapping initialization in drm_open in error path



Marco,

What makes you think that the crash after second modprobe is related to 
the mappings pointers in DRM module? Can you actually establish the 
correlation between these patches and the crash or you are just suspecting 
because your other bug had something to do with module removal/insertion?


If it's the latter, then you may want to open another bug report here 
https://bugs.freedesktop.org/ (use DRI for product and pick DRM/radeon for 
component) and have this issue tracked and addressed separately.


The divide error that your log shows apparently happens at this line
inside r6xx_remap_render_backend:

pipe_rb_ratio = rendering_pipe_num / req_rb_num;

I would suspect that req_rb_num somehow evaluates to zero at the second 
modprobe. That variable seems to be the derived of the last three 
arguments to r6xx_remap_render_backend. If I look at the caller 
(evergreen_gpu_init) the arguments that have the play here are all derived 
from the GPU's hardware registers (or are the constant for a given GPU 
device). So I suspect that the GPU driver leaves some state in GPU at 
module removal that later bites you.


-- Ilija

On Tue, 2 Apr 2013, Marco Munderloh wrote:


Hi Ilija,

Thanks for testing. Other issues are probably unrelated, so I'll send the 
last version of the patch to Dave.


I came across another problem which seems related. rmmod radeon works, 
however, modprobe radeon afterwards results in a crash (divide error), see 
attachment.


Best, Marco

On 02.04.2013 13:23, Ilija Hadzic wrote:


-- Ilija

On Tue, Apr 2, 2013 at 6:36 AM, Marco Munderloh 
mund...@tnt.uni-hannover.de mailto:mund...@tnt.uni-hannover.de wrote:


Attached is a v2 of the patch, for reference. I would appreciate if 
the original reporter or you tested it in lieu of your proposed patch and 
let me know if it

fixes your
issue.


The patch works for me. echo 3  /proc/sys/vm/drop_caches as well as 
rmmod radeon do not end up in a crash anymore. However, I have still no 
clue why one of these makes
drm_open to fail. On rmmod radeon I get the following log messages. If 
don't know if the 'unpin not necessary' has anything to do with it.


[drm] radeon: finishing device.
radeon :01:00.0: 88024e526c00 unpin not necessary
radeon :01:00.0: 88024f2f6000 unpin not necessary
radeon :01:00.0: 88024f2f6000 unpin not necessary
[TTM] Finalizing pool allocator
[TTM] Finalizing DMA pool allocator
[TTM] Zone  kernel: Used memory at exit: 0 kiB
[TTM] Zone   dma32: Used memory at exit: 0 kiB
[drm] radeon: ttm finalized
vga_switcheroo: disabled
[drm] Module unloaded

By the way, sometimes my r8169 ethernet controller does not survive 
suspend/hibernation (does not detect link). rmmod/modprobe helps. I don't 
know if this is related.





--
Dipl.-Ing. Marco Munderloh Mail: mund...@tnt.uni-hannover.de
Institut f?r Informationsverarbeitung (TNT) Phone: +49 511 762-19587
Leibniz Universitaet Hannover, Appelstr. 9a   Fax: +49 511 762- 5333
30167 Hannover, Germany Web: http://www.tnt.uni-hannover.de/~munderl
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: drop the coditional mutex

On Tue, Apr 02, 2013 at 03:30:58PM +0200, Sebastian Andrzej Siewior wrote:
 mutex_is_locked_by() checks the owner of the lock against current. This
 is done by accessing a private member of struct mutex which works on
 mainline but does not on RT.
 I did not figure out, why this lock-owner-check and the lock stealing
 flag is required. If the lock can not be acquire the lock (because it
 would deadlock) then it can return -1.
 The lock stealing makes actually no sense to me. If
 shrinker_no_lock_stealing is true then the same functions
 (i915_gem_purge(), i915_gem_shrink_all()) are called from
 i915_gem_object_create_mmap_offset() as from i915_gem_inactive_shrink().
 I haven't found a path in which i915_gem_inactive_shrink() is invoked
 from i915_gem_object_create_mmap_offset() that means there is no way
 shrinker_no_lock_stealing is true _and_ the lock is owned by the current
 process.

Every invocation of a memory allocation function can potentially recourse
into the shrinker callbacks. Since we currently protect almost all our gpu
buffer object state with one single lock, and we can also easily hold onto
tons of memory, we can easily OOM without that lock stealing trick.

The patch you're reverting here was added to work around spurious OOM when
trying to allocate sg tables, so this is real.

I fully realize that this is an awful hack and I'll burn on a pretty big
pyre for merging it. I also know that it doesn't really work if someone
else is trying to allocate while another thread is hogging our single
mutex. But without a replacement fix, this is nacked.

The no_lock_stealing hack is probably even worse, we use it to protect
critical section which are touching the gpu lru.

Long term we're working towards that goal (also for a bunch of other
reasons) and aim for more fine-grained locking, so that we can free memory
in smaller chunks. But that's gonna be a lot of work.

Cheers, Daniel


 Since I don't see why the i915 needs this hack while all other user do
 not I recommend to remove this hack and return -1 in case of a dead
 lock. Here is the patch.
 
 Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
 ---
  drivers/gpu/drm/i915/i915_drv.h |1 -
  drivers/gpu/drm/i915/i915_gem.c |   32 +++-
  2 files changed, 3 insertions(+), 30 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
 index 01769e2..47f28ee 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -724,7 +724,6 @@ struct i915_gem_mm {
   struct i915_hw_ppgtt *aliasing_ppgtt;
  
   struct shrinker inactive_shrinker;
 - bool shrinker_no_lock_stealing;
  
   /**
* List of objects currently involved in rendering.
 diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
 index 0e207e6..7949517 100644
 --- a/drivers/gpu/drm/i915/i915_gem.c
 +++ b/drivers/gpu/drm/i915/i915_gem.c
 @@ -1500,8 +1500,6 @@ static int i915_gem_object_create_mmap_offset(struct 
 drm_i915_gem_object *obj)
   if (obj-base.map_list.map)
   return 0;
  
 - dev_priv-mm.shrinker_no_lock_stealing = true;
 -
   ret = drm_gem_create_mmap_offset(obj-base);
   if (ret != -ENOSPC)
   goto out;
 @@ -1521,8 +1519,6 @@ static int i915_gem_object_create_mmap_offset(struct 
 drm_i915_gem_object *obj)
   i915_gem_shrink_all(dev_priv);
   ret = drm_gem_create_mmap_offset(obj-base);
  out:
 - dev_priv-mm.shrinker_no_lock_stealing = false;
 -
   return ret;
  }
  
 @@ -4368,19 +4364,6 @@ void i915_gem_release(struct drm_device *dev, struct 
 drm_file *file)
   spin_unlock(file_priv-mm.lock);
  }
  
 -static bool mutex_is_locked_by(struct mutex *mutex, struct task_struct *task)
 -{
 - if (!mutex_is_locked(mutex))
 - return false;
 -
 -#if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_MUTEXES)
 - return mutex-owner == task;
 -#else
 - /* Since UP may be pre-empted, we cannot assume that we own the lock */
 - return false;
 -#endif
 -}
 -
  static int
  i915_gem_inactive_shrink(struct shrinker *shrinker, struct shrink_control 
 *sc)
  {
 @@ -4391,18 +4374,10 @@ i915_gem_inactive_shrink(struct shrinker *shrinker, 
 struct shrink_control *sc)
   struct drm_device *dev = dev_priv-dev;
   struct drm_i915_gem_object *obj;
   int nr_to_scan = sc-nr_to_scan;
 - bool unlock = true;
   int cnt;
  
 - if (!mutex_trylock(dev-struct_mutex)) {
 - if (!mutex_is_locked_by(dev-struct_mutex, current))
 - return 0;
 -
 - if (dev_priv-mm.shrinker_no_lock_stealing)
 - return 0;
 -
 - unlock = false;
 - }
 + if (!mutex_trylock(dev-struct_mutex))
 + return -1;
  
   if (nr_to_scan) {
   nr_to_scan -= i915_gem_purge(dev_priv, nr_to_scan);
 @@ -4421,7 +4396,6 @@ i915_gem_inactive_shrink(struct shrinker *shrinker, 
 struct

Re: [PATCH] drm: fix i_mapping and f_mapping initialization in drm_open in error path

On Tue, Apr 2, 2013 at 9:31 AM, Ilija Hadzic
ihad...@research.bell-labs.com wrote:

Marco,

What makes you think that the crash after second modprobe is related to the
mappings pointers in DRM module? Can you actually establish the correlation
between these patches and the crash or you are just suspecting because your
other bug had something to do with module removal/insertion?

If it's the latter, then you may want to open another bug report here
https://bugs.freedesktop.org/ (use DRI for product and pick DRM/radeon for
component) and have this issue tracked and addressed separately.

The divide error that your log shows apparently happens at this line
inside r6xx_remap_render_backend:

pipe_rb_ratio = rendering_pipe_num / req_rb_num;

I would suspect that req_rb_num somehow evaluates to zero at the second
modprobe. That variable seems to be the derived of the last three arguments
to r6xx_remap_render_backend. If I look at the caller (evergreen_gpu_init)
the arguments that have the play here are all derived from the GPU's
hardware registers (or are the constant for a given GPU device). So I
suspect that the GPU driver leaves some state in GPU at module removal that
later bites you.

Newer kernels have a fix for this.
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f689e3acbd2e48cc4101e0af454193f81af4baaf

Alex

-- Ilija

On Tue, 2 Apr 2013, Marco Munderloh wrote:

Hi Ilija,

Thanks for testing. Other issues are probably unrelated, so I'll send the
last version of the patch to Dave.

I came across another problem which seems related. rmmod radeon works,
however, modprobe radeon afterwards results in a crash (divide error), see
attachment.

Best, Marco

On 02.04.2013 13:23, Ilija Hadzic wrote:

-- Ilija

On Tue, Apr 2, 2013 at 6:36 AM, Marco Munderloh
mund...@tnt.uni-hannover.de mailto:mund...@tnt.uni-hannover.de wrote:

Attached is a v2 of the patch, for reference. I would appreciate
if the original reporter or you tested it in lieu of your proposed patch and
let me know if it
fixes your
issue.

The patch works for me. echo 3 /proc/sys/vm/drop_caches as well as
rmmod radeon do not end up in a crash anymore. However, I have still no clue
why one of these makes
drm_open to fail. On rmmod radeon I get the following log messages.
If don't know if the 'unpin not necessary' has anything to do with it.

[drm] radeon: finishing device.
radeon :01:00.0: 88024e526c00 unpin not necessary
radeon :01:00.0: 88024f2f6000 unpin not necessary
radeon :01:00.0: 88024f2f6000 unpin not necessary
[TTM] Finalizing pool allocator
[TTM] Finalizing DMA pool allocator
[TTM] Zone kernel: Used memory at exit: 0 kiB
[TTM] Zone dma32: Used memory at exit: 0 kiB
[drm] radeon: ttm finalized
vga_switcheroo: disabled
[drm] Module unloaded

By the way, sometimes my r8169 ethernet controller does not survive
suspend/hibernation (does not detect link). rmmod/modprobe helps. I don't
know if this is related.

--
Dipl.-Ing. Marco Munderloh Mail: mund...@tnt.uni-hannover.de
Institut für Informationsverarbeitung (TNT) Phone: +49 511 762-19587
Leibniz Universitaet Hannover, Appelstr. 9a Fax: +49 511 762- 5333
30167 Hannover, Germany Web: http://www.tnt.uni-hannover.de/~munderl

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: correctly restore mappings if drm_open fails

If first drm_open fails, the error-handling path will
incorrectly restore inode's mapping to NULL. This can
cause the crash later on. Fix by separately storing
away mapping pointers that drm_open can touch and
restore each from its own respective variable if the
call fails.

Fixes: https://bugzilla.novell.com/show_bug.cgi?id=807850
(thanks to Michal Hocko for investigating investigating and
finding the root cause of the bug)

Reference:
http://lists.freedesktop.org/archives/dri-devel/2013-March/036564.html

v2: Use one variable to store file and inode mapping
since they are the same at the function entry.
Fix spelling mistakes in commit message.

v3: Add reference to the original bug report.

Reported-by: Marco Munderloh mund...@tnt.uni-hannover.de
Tested-by: Marco Munderloh mund...@tnt.uni-hannover.de
Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
Cc: Michal Hocko mho...@suse.cz
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/drm_fops.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 13fdcd1..429e07d 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -123,6 +123,7 @@ int drm_open(struct inode *inode, struct file *filp)
int retcode = 0;
int need_setup = 0;
struct address_space *old_mapping;
+   struct address_space *old_imapping;
 
minor = idr_find(drm_minors_idr, minor_id);
if (!minor)
@@ -137,6 +138,7 @@ int drm_open(struct inode *inode, struct file *filp)
if (!dev-open_count++)
need_setup = 1;
mutex_lock(dev-struct_mutex);
+   old_imapping = inode-i_mapping;
old_mapping = dev-dev_mapping;
if (old_mapping == NULL)
dev-dev_mapping = inode-i_data;
@@ -159,8 +161,8 @@ int drm_open(struct inode *inode, struct file *filp)
 
 err_undo:
mutex_lock(dev-struct_mutex);
-   filp-f_mapping = old_mapping;
-   inode-i_mapping = old_mapping;
+   filp-f_mapping = old_imapping;
+   inode-i_mapping = old_imapping;
iput(container_of(dev-dev_mapping, struct inode, i_data));
dev-dev_mapping = old_mapping;
mutex_unlock(dev-struct_mutex);
-- 
1.8.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/tilcdc: LCD panels clocks initialization and earlier backlight initialization

2013-04-02 Thread Rob Clark

On Tue, Apr 2, 2013 at 4:45 AM, Michal Bachraty
michal.bachr...@streamunlimited.com wrote:
 Hi Rob,

 On Monday, April 01, 2013 09:46:05 Rob Clark wrote:
 On Mon, Apr 1, 2013 at 7:31 AM, Hiremath, Vaibhav hvaib...@ti.com wrote:
  -Original Message-
  From: devicetree-discuss [mailto:devicetree-discuss-
  bounces+hvaibhav=ti@lists.ozlabs.org] On Behalf Of Michal Bachraty
  Sent: Thursday, March 28, 2013 11:02 PM
  To: dri-devel@lists.freedesktop.org; devicetree-
  disc...@lists.ozlabs.org
  Cc: robdcl...@gmail.com; k...@dominion.thruhere.net
  Subject: drm/tilcdc: LCD panels clocks initialization and earlier
  backlight initialization
 
  Hi,
 
  I'm trying to use tilcdc driver for KWH050TG08 LCD panel connected to
  AM335x
  processor (3.9 rc1 kernel). I have prepared DT bindings for that
  (listed
  bellow). I see fb0 device but I have no clocks going from cpu to LCD.
  My
  clocks for LCD seems not properly to be set ...
 
  virt_2500_ck   1   12500
 
  sys_clkin_ck8   19   2500
 
 dpll_disp_ck 0   12500
 
dpll_disp_m2_ck   0   12500
 
   lcd_gclk   0   12500
 
  and tilcdc_crtc is not called. I also set lcd_gclk to 300MHz, but I got
  same
  result. The question is there any way how to properly set clocks for
  LCD?
 
  Not sure  about the LCDC DRM driver, but I just tested clk_set_rate()
  For lcdc_gclk clock and it is working for me. I could able to set
  300MHz freq on my BeagleBone platform, with below code -

 fwiw, tilcdc drm driver won't set clocks until you do modeset, as it
 is setting them based on the requested pixel clock.  As opposed to
 setting it once at boot time.

 Michal, you may want to add 'drm.debug=7' in your bootargs, and send
 the bootlog.  That should set some light about whether it is even
 trying to modeset but failing, or some other issue.


 Yes, here it is:

Hmm, looks like tilcdc_crtc_update_clk() is not getting called.. and
in fact either tilcdc_crtc_mode_set() is not called or bails out early
(maybe _mode_valid() falis?)

I'd perhaps throw a few traces in tilcdc_crtc_mode_set() and see why
that is bailing out..

BR,
-R



 [3.098732] platform audio.11: Driver snd-soc-am33xx-s800 requests probe
 deferral
 [ 3.107280] TCP: cubic registered
 [3.110822] Initializing XFRM netlink socket
 [3.115844] NET: Registered protocol family 10
 [3.123212] NET: Registered protocol family 17
 [3.128064] NET: Registered protocol family 15
 [3.133176] Key type dns_resolver registered
 [3.137846] VFP support v0.3: implementor 41 architecture 3 part 30 variant
 c rev 3
 [3.146087] ThumbEE CPU extension supported.
 [3.150659] Registering SWP/SWPB emulation handler
 [3.160695] registered taskstats version 1
 [3.166007] [drm:tilcdc_drm_init], init
 [3.171117] pinctrl core: add 1 pinmux maps
 [3.175564] pinctrl-single 44e10800.pinmux: found group selector 6 for
 pinmux_lcd_pins
 [3.183957] pinctrl-single 44e10800.pinmux: request pin 59 (44e108ec) for
 lcd_panel.15
 [3.192312] pinctrl-single 44e10800.pinmux: request pin 57 (44e108e4) for
 lcd_panel.15
 [3.200662] pinctrl-single 44e10800.pinmux: request pin 56 (44e108e0) for
 lcd_panel.15
 [3.209010] pinctrl-single 44e10800.pinmux: request pin 58 (44e108e8) for
 lcd_panel.15
 [3.217321] pinctrl-single 44e10800.pinmux: request pin 55 (44e108dc) for
 lcd_panel.15
 [3.225666] pinctrl-single 44e10800.pinmux: request pin 54 (44e108d8) for
 lcd_panel.15
 [3.234012] pinctrl-single 44e10800.pinmux: request pin 53 (44e108d4) for
 lcd_panel.15
 [3.242359] pinctrl-single 44e10800.pinmux: request pin 52 (44e108d0) for
 lcd_panel.15
 [3.250708] pinctrl-single 44e10800.pinmux: request pin 51 (44e108cc) for
 lcd_panel.15
 [3.259052] pinctrl-single 44e10800.pinmux: request pin 50 (44e108c8) for
 lcd_panel.15
 [3.267362] pinctrl-single 44e10800.pinmux: request pin 49 (44e108c4) for
 lcd_panel.15
 [3.275710] pinctrl-single 44e10800.pinmux: request pin 48 (44e108c0) for
 lcd_panel.15
 [3.284057] pinctrl-single 44e10800.pinmux: request pin 47 (44e108bc) for
 lcd_panel.15
 [3.292404] pinctrl-single 44e10800.pinmux: request pin 46 (44e108b8) for
 lcd_panel.15
 [3.300748] pinctrl-single 44e10800.pinmux: request pin 45 (44e108b4) for
 lcd_panel.15
 [3.309091] pinctrl-single 44e10800.pinmux: request pin 44 (44e108b0) for
 lcd_panel.15
 [3.317404] pinctrl-single 44e10800.pinmux: request pin 43 (44e108ac) for
 lcd_panel.15
 [3.325751] pinctrl-single 44e10800.pinmux: request pin 42 (44e108a8) for
 lcd_panel.15
 [3.334098] pinctrl-single 44e10800.pinmux: request pin 41 (44e108a4) for
 lcd_panel.15
 [3.342445] pinctrl-single 44e10800.pinmux: request pin 40 (44e108a0) for
 lcd_panel.15
 [3.350794] pinctrl-single 44e10800.pinmux:

Re: [PATCH v2 2/3] mutex: add support for reservation style locks, v2

2013-04-02 Thread Maarten Lankhorst

Hey,

Thanks for reviewing.

Op 02-04-13 13:00, Peter Zijlstra schreef:
 On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
 +Reservation type mutexes
 +struct ticket_mutex {
 +extern int __must_check _mutex_reserve_lock(struct ticket_mutex *lock,
 That's two different names and two different forms of one (for a total
 of 3 variants) for the same scheme.

 FAIL...
It's been hard since I haven't seen anything similar in the kernel, I 
originally went with tickets
since that's what ttm originally called it, and tried to kill as many 
references as I could
when I noticed ticket mutexes already being taken.

I'll fix up the ticket_mutex - reservation_mutex, and mutex_reserve_* - 
reserve_mutex_*

 On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
 +mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow:
 +  Similar to mutex_reserve_lock, except it won't backoff with
 -EAGAIN.
 +  This is useful when mutex_reserve_lock failed with -EAGAIN, and you
 +  unreserved all reservation_locks so no deadlock can occur.
 +
 I don't particularly like these function names, with lock
 implementations the _slow post-fix is typically used for slow path
 implementations, not API type interfaces.
 I didn't intend for drivers to use the new calls directly, but rather through 
a wrapper,
for example by ttm_eu_reserve_buffers in drivers/gpu/drm/ttm/ttm_execbuf_util.c

 Also, is there anything in CS literature that comes close to this? I'd
 think the DBMS people would have something similar with their
 transactional systems. What do they call it?
I didn't study cs, but judging from your phrasing I guess you mean you want me 
to call it transaction_mutexes instead?

 Head hurts, needs more time to ponder. It would be good if someone else
 (this would probably be you maarten) would also consider this and
 explore
 this 'interesting' problem space :-)
My head too, evil priority stuff!

Hacky but pragmatical workaround for now: use a real mutex around all the 
reserve_mutex_lock* calls instead of a virtual lock.
It can be unlocked as soon as all locks have been taken, before any actual work 
is done.

It only slightly kills the point of having a reservation in the first place, 
but at least it won't break completely -rt completely for now.

~Maarten

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 62226] Build Fails with LLVM

https://bugs.freedesktop.org/show_bug.cgi?id=62226

Johannes Obermayr johannesoberm...@gmx.de changed:

   What|Removed |Added

 CC||mic...@daenzer.net

--- Comment #12 from Johannes Obermayr johannesoberm...@gmx.de ---
(In reply to comment #10)
 Also this statement is wrong:
 This library was originally changed to a shared object to work around
 linker error in egl_static.so, but these appear to be fixed now.
 
 It was changed to be built '-shared' because there were and possibly be
 troubles with crashing egl things if r600 AND radeonsi were built together
 (see on #dri-devel from mid december 2012 [MrCooper, jobermayr])
 
 You should also see the conditional there. If it makes sense and is required
 (r600 AND radeonsi) it is shared. If it doesn't (r600 XOR radeonsi) it is
 static.

Please test to make sure this works for your build configuration.

Tested-by: Michel Dänzer michel.daenzer at amd.com

@MrCooper: Can you confirm the runtime assertion issue has been fixed (radeon
AND radeonsi)?
http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-develhighlight_names=date=2012-12-07

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/3] mutex: add support for reservation style locks, v2

On Tue, Apr 2, 2013 at 1:00 PM, Peter Zijlstra a.p.zijls...@chello.nl wrote:
 Also, is there anything in CS literature that comes close to this? I'd
 think the DBMS people would have something similar with their
 transactional systems. What do they call it?

I've looked around a bit and in dbms row-locking land this seems to be
called the wound-wait deadlock avoidance algorithm. It's the same
approach where if you encounter an older ticket (there called
transaction timestamp) you drop all locked rows and retry (or abort)
the transaction. If you encounter a newer ticket when trying to grab a
lock simply do a blocking wait. So ticket/reservation in Maartens
patches is the analog of timestamp/transaction.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 62226] Build Fails with LLVM

https://bugs.freedesktop.org/show_bug.cgi?id=62226

Michel Dänzer mic...@daenzer.net changed:

   What|Removed |Added

 CC|mic...@daenzer.net  |

--- Comment #13 from Michel Dänzer mic...@daenzer.net ---
(In reply to comment #12)
 @MrCooper: Can you confirm the runtime assertion issue has been fixed
 (radeon AND radeonsi)?
 http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-
 develhighlight_names=date=2012-12-07

Ah no, I failed to test this properly. :( Thanks for the reminder Johannes.

[ I read bug reports on the lists ]

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 62976] UEFI + SUMO [6550D] freeze after loading radeon

https://bugs.freedesktop.org/show_bug.cgi?id=62976

--- Comment #4 from Alex Deucher ag...@yahoo.com ---
Created attachment 77331
  -- https://bugs.freedesktop.org/attachment.cgi?id=77331action=edit
Possible fix

Does this patch help?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 43655] Latest radeon dri driver on HD6950 with GRUB set GRUB_GFXPAYLOAD_LINUX=keep put the display in a flickering state

https://bugs.freedesktop.org/show_bug.cgi?id=43655

--- Comment #25 from Alex Deucher ag...@yahoo.com ---
Created attachment 77332
  -- https://bugs.freedesktop.org/attachment.cgi?id=77332action=edit
possible fix

Does this patch help?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 62976] UEFI + SUMO [6550D] freeze after loading radeon

https://bugs.freedesktop.org/show_bug.cgi?id=62976

--- Comment #5 from David Heidelberger d.ok...@gmail.com ---
3.9.0-rc5, with patch. Boot successfull, first time :)

Thank you!

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

radeonsi tiling dilema

So i am facing a dilema regarding tiling on radeonsi. Given that we now
have a fixed table of tiling mode this put more pressure on the kernel
userspace api. I see either 2 solutions.

Enforce kernel to set at fixed index in the table best tiling mode for
given gpu for given format, such as DEPTH32_2D_4AA at index 4, or
COLOR_SCANOUT_2D at index 13 ... that way kernel can still adapt the tile
mode array value. Note that this match the design behind the tile mode
index being that there is a limited number of useful tile mode combination
and for each surface format  (depth/color/macro tile/micro/tile) there is a
best one.

Second solution is to add an ioctl to compute mipmap information in kernel
(pitch alignment slice size ...) based on format, size of the surface.

Some might argue that we could just export the table content to userspace,
but that would loose information and possibly froze the tile mode table
forever as API. The information we loose is what index match to prefered
surface format/type combination. And the tile mode might be considered API
as if kernel ever change what userspace expect then we might break some
userspace.


Thought, idea ?

Cheers,
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 61182] r600g causes KWin crashes with kernel 3.8

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #25 from ogjers...@gmail.com ---
Not without some instructions, I have never done that before.

And, I must admit, I also downgraded llvm-libs, mesa-dri-filesystem and
mesa-libxatracker. I think I had to because of dependences.

I guess I will have to build from source in that case?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 62889] ColorTiling results in glitches on Radeon HD 7970 + Glamor

https://bugs.freedesktop.org/show_bug.cgi?id=62889

--- Comment #8 from Alexander von Gluck kallis...@unixzen.com ---
Thanks for the input.

I disabled colortiling and installed xfce.. success!

It seems like Gnome 3.6 won't work unless color tiling is enabled. I double
checked the gnome session logs and don't see the previously mentioned error
anymore.. just a blank desktop wallpaper across both monitors.  I erased the
gnome config files in .local without any success.

I ran a glxinfo from .xinit, and it does confirm that Gallium is in use.
(attached)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 62889] ColorTiling results in glitches on Radeon HD 7970 + Glamor

https://bugs.freedesktop.org/show_bug.cgi?id=62889

--- Comment #9 from Alexander von Gluck kallis...@unixzen.com ---
Created attachment 77335
  -- https://bugs.freedesktop.org/attachment.cgi?id=77335action=edit
glxinfo-nocolortile

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 62889] ColorTiling results in glitches on Radeon HD 7970 + Glamor

https://bugs.freedesktop.org/show_bug.cgi?id=62889

--- Comment #10 from Alexander von Gluck kallis...@unixzen.com ---
Created attachment 77336
  -- https://bugs.freedesktop.org/attachment.cgi?id=77336action=edit
gnome-session --debug output nocolortile

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: radeonsi tiling dilema

On Tue, Apr 2, 2013 at 2:13 PM, Jerome Glisse j.gli...@gmail.com wrote:

 So i am facing a dilema regarding tiling on radeonsi. Given that we now
 have a fixed table of tiling mode this put more pressure on the kernel
 userspace api. I see either 2 solutions.

 Enforce kernel to set at fixed index in the table best tiling mode for
 given gpu for given format, such as DEPTH32_2D_4AA at index 4, or
 COLOR_SCANOUT_2D at index 13 ... that way kernel can still adapt the tile
 mode array value. Note that this match the design behind the tile mode
 index being that there is a limited number of useful tile mode combination
 and for each surface format  (depth/color/macro tile/micro/tile) there is a
 best one.
 Second solution is to add an ioctl to compute mipmap information in kernel
 (pitch alignment slice size ...) based on format, size of the surface.


Well that one can also be slightly modified to not strictly enfore index
association with surface format/type preference.



 Some might argue that we could just export the table content to userspace,
 but that would loose information and possibly froze the tile mode table
 forever as API. The information we loose is what index match to prefered
 surface format/type combination. And the tile mode might be considered API
 as if kernel ever change what userspace expect then we might break some
 userspace.


 Thought, idea ?

 Cheers,
 Jerome

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 62756] Rendering errors on rv790 with llvm and unigine heaven 3.0

https://bugs.freedesktop.org/show_bug.cgi?id=62756

--- Comment #5 from vincent v...@ovi.com ---
No, I don't receive mail from bugzilla until someone add me manually to the cc
list (dont know what to do to fix that though)

I'm aware of the regression with latest HEAD, I'm working on a fix.
r600g still adds CF_ALU on its own which break CF_CLAUSE address natively
encoded by llvm.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: radeonsi tiling dilema

On Tue, Apr 2, 2013 at 2:13 PM, Jerome Glisse j.gli...@gmail.com wrote:
 So i am facing a dilema regarding tiling on radeonsi. Given that we now have
 a fixed table of tiling mode this put more pressure on the kernel userspace
 api. I see either 2 solutions.

 Enforce kernel to set at fixed index in the table best tiling mode for given
 gpu for given format, such as DEPTH32_2D_4AA at index 4, or COLOR_SCANOUT_2D
 at index 13 ... that way kernel can still adapt the tile mode array value.
 Note that this match the design behind the tile mode index being that there
 is a limited number of useful tile mode combination and for each surface
 format  (depth/color/macro tile/micro/tile) there is a best one.

 Second solution is to add an ioctl to compute mipmap information in kernel
 (pitch alignment slice size ...) based on format, size of the surface.

 Some might argue that we could just export the table content to userspace,
 but that would loose information and possibly froze the tile mode table
 forever as API. The information we loose is what index match to prefered
 surface format/type combination. And the tile mode might be considered API
 as if kernel ever change what userspace expect then we might break some
 userspace.


 Thought, idea ?

If it helps any, the tiling information for the GB_TILE_MODE register
settings and index locations come from a table provided by the
hardware team during bring up and barring any typos in transcribing
the information, never really changes.

Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[git pull] drm fixes

2013-04-02 Thread Dave Airlie


Hi Linus,

two core fixes, both regressions, along with some intel and some nouveau 
fixes for regressions and oopses.

Dave.

The following changes since commit 2dc958fa2fe6987e7ab106bd97029a09a82fcd8d:

  ipc: set msg back to -EAGAIN if copy wasn't performed (2013-04-02 10:09:01 
-0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to a8ec3a662921220fc058ed6f7f3674697876d218:

  drm: correctly restore mappings if drm_open fails (2013-04-03 06:44:38 +1000)


Adam Jackson (1):
  drm/i915: Be sure to turn hsync/vsync back on at crt enable (v2)

Daniel Vetter (2):
  drm/i915: duct-tape locking when eDP init fails
  drm: don't unlock in the addfb error paths

Dave Airlie (2):
  Merge branch 'drm-intel-fixes' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-next
  Merge branch 'drm-nouveau-fixes-3.9' of 
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next

Ilija Hadzic (1):
  drm: correctly restore mappings if drm_open fails

Lauri Kasanen (1):
  drm/i915: Fix build failure

Maarten Lankhorst (2):
  drm/nouveau: fix handling empty channel list in ioctl's
  drm/nouveau: fix NULL ptr dereference from nv50_disp_intr()

 drivers/gpu/drm/drm_crtc.c |  2 --
 drivers/gpu/drm/drm_fops.c |  6 +++--
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  2 +-
 drivers/gpu/drm/i915/intel_crt.c   | 40 +-
 drivers/gpu/drm/i915/intel_dp.c|  3 +++
 drivers/gpu/drm/nouveau/nouveau_abi16.c| 18 --
 drivers/gpu/drm/nouveau/nouveau_drm.c  | 32 +++-
 drivers/gpu/drm/nouveau/nouveau_drm.h  |  2 +-
 8 files changed, 56 insertions(+), 49 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 62756] Rendering errors on rv790 with llvm and unigine heaven 3.0

https://bugs.freedesktop.org/show_bug.cgi?id=62756

--- Comment #6 from Andy Furniss adf.li...@gmail.com ---
(In reply to comment #5)
 No, I don't receive mail from bugzilla until someone add me manually to the
 cc list (dont know what to do to fix that though)

drivers/gallium/r600 bugs get sent to the dri-devel list.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: radeonsi tiling dilema

On Tue, Apr 2, 2013 at 4:32 PM, Alex Deucher alexdeuc...@gmail.com wrote:

 On Tue, Apr 2, 2013 at 2:13 PM, Jerome Glisse j.gli...@gmail.com wrote:
  So i am facing a dilema regarding tiling on radeonsi. Given that we now
 have
  a fixed table of tiling mode this put more pressure on the kernel
 userspace
  api. I see either 2 solutions.
 
  Enforce kernel to set at fixed index in the table best tiling mode for
 given
  gpu for given format, such as DEPTH32_2D_4AA at index 4, or
 COLOR_SCANOUT_2D
  at index 13 ... that way kernel can still adapt the tile mode array
 value.
  Note that this match the design behind the tile mode index being that
 there
  is a limited number of useful tile mode combination and for each surface
  format  (depth/color/macro tile/micro/tile) there is a best one.
 
  Second solution is to add an ioctl to compute mipmap information in
 kernel
  (pitch alignment slice size ...) based on format, size of the surface.
 
  Some might argue that we could just export the table content to
 userspace,
  but that would loose information and possibly froze the tile mode table
  forever as API. The information we loose is what index match to prefered
  surface format/type combination. And the tile mode might be considered
 API
  as if kernel ever change what userspace expect then we might break some
  userspace.
 
 
  Thought, idea ?

 If it helps any, the tiling information for the GB_TILE_MODE register
 settings and index locations come from a table provided by the
 hardware team during bring up and barring any typos in transcribing
 the information, never really changes.

 Alex


Still sounds like you likely want to update those given gap there is inside
them.

Patch set for solution 1:
http://people.freedesktop.org/~glisse/si2d-sol1/

Cheers,
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 61182] r600g causes KWin crashes with kernel 3.8

https://bugs.freedesktop.org/show_bug.cgi?id=61182

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

 CC||ranki...@googlemail.com

--- Comment #26 from Alex Deucher ag...@yahoo.com ---
*** Bug 61822 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 01/10] drm/radeon: UVD doesn't needs VM on SI

Signed-off-by: Christian König deathsim...@vodafone.de
---
 drivers/gpu/drm/radeon/radeon_cs.c |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index 70d3824..7d66e01 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -241,15 +241,15 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, 
void *data)
return -EINVAL;
}
 
+   if (radeon_cs_get_ring(p, ring, priority))
+   return -EINVAL;
+
/* we only support VM on SI+ */
-   if ((p-rdev-family = CHIP_TAHITI) 
-   ((p-cs_flags  RADEON_CS_USE_VM) == 0)) {
+   if ((p-rdev-asic-ring[p-ring].cs_parse == NULL) 
+  ((p-cs_flags  RADEON_CS_USE_VM) == 0)) {
DRM_ERROR(VM required on SI+!\n);
return -EINVAL;
}
-
-   if (radeon_cs_get_ring(p, ring, priority))
-   return -EINVAL;
}
 
/* deal with non-vm */
-- 
1.7.9.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: UVD support for RV710-SI

Hi everyone,

the following patchset implements the kernel side of UVD support for the radeon 
hardware generations RV710-SI.

The R6xx and RS780/RS880 chipset generations are currently not supported, but 
might be added in the future.

The newest firmware can be found here: from 
http://people.freedesktop.org/~agd5f/radeon_ucode/

A matching patch implementing the necessary userspace side will follow in just 
a minute on the mesa devel list.

Cheers,
Christian.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 03/10] drm/radeon: add pm callback for setting uvd clocks

From: Alex Deucher alexander.deuc...@amd.com

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Signed-off-by: Christian König deathsim...@vodafone.de
---
 drivers/gpu/drm/radeon/radeon.h |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 3f5572d..eafb66a6 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1312,6 +1312,7 @@ struct radeon_asic {
int (*get_pcie_lanes)(struct radeon_device *rdev);
void (*set_pcie_lanes)(struct radeon_device *rdev, int lanes);
void (*set_clock_gating)(struct radeon_device *rdev, int 
enable);
+   int (*set_uvd_clocks)(struct radeon_device *rdev, u32 vclk, u32 
dclk);
} pm;
/* pageflipping */
struct {
@@ -1878,6 +1879,7 @@ void radeon_ring_write(struct radeon_ring *ring, uint32_t 
v);
 #define radeon_get_pcie_lanes(rdev) (rdev)-asic-pm.get_pcie_lanes((rdev))
 #define radeon_set_pcie_lanes(rdev, l) (rdev)-asic-pm.set_pcie_lanes((rdev), 
(l))
 #define radeon_set_clock_gating(rdev, e) 
(rdev)-asic-pm.set_clock_gating((rdev), (e))
+#define radeon_set_uvd_clocks(rdev, v, d) 
(rdev)-asic-pm.set_uvd_clocks((rdev), (v), (d))
 #define radeon_set_surface_reg(rdev, r, f, p, o, s) 
((rdev)-asic-surface.set_reg((rdev), (r), (f), (p), (o), (s)))
 #define radeon_clear_surface_reg(rdev, r) 
((rdev)-asic-surface.clear_reg((rdev), (r)))
 #define radeon_bandwidth_update(rdev) 
(rdev)-asic-display.bandwidth_update((rdev))
-- 
1.7.9.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 04/10] drm/radeon: add radeon_atom_get_clock_dividers helper

Signed-off-by: Christian König deathsim...@vodafone.de
---
 drivers/gpu/drm/radeon/radeon.h  |5 ++
 drivers/gpu/drm/radeon/radeon_atombios.c |  107 ++
 drivers/gpu/drm/radeon/radeon_mode.h |   23 +++
 3 files changed, 135 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index eafb66a6..c1a3c1f 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -205,6 +205,11 @@ void radeon_pm_suspend(struct radeon_device *rdev);
 void radeon_pm_resume(struct radeon_device *rdev);
 void radeon_combios_get_power_modes(struct radeon_device *rdev);
 void radeon_atombios_get_power_modes(struct radeon_device *rdev);
+int radeon_atom_get_clock_dividers(struct radeon_device *rdev,
+  u8 clock_type,
+  u32 clock,
+  bool strobe_mode,
+  struct atom_clock_dividers *dividers);
 void radeon_atom_set_voltage(struct radeon_device *rdev, u16 voltage_level, u8 
voltage_type);
 void rs690_pm_info(struct radeon_device *rdev);
 extern int rv6xx_get_temp(struct radeon_device *rdev);
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c 
b/drivers/gpu/drm/radeon/radeon_atombios.c
index f22eb57..8c1779c 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -2654,6 +2654,113 @@ void radeon_atombios_get_power_modes(struct 
radeon_device *rdev)
rdev-pm.current_vddc = 0;
 }
 
+union get_clock_dividers {
+   struct _COMPUTE_MEMORY_ENGINE_PLL_PARAMETERS v1;
+   struct _COMPUTE_MEMORY_ENGINE_PLL_PARAMETERS_V2 v2;
+   struct _COMPUTE_MEMORY_ENGINE_PLL_PARAMETERS_V3 v3;
+   struct _COMPUTE_MEMORY_ENGINE_PLL_PARAMETERS_V4 v4;
+   struct _COMPUTE_MEMORY_ENGINE_PLL_PARAMETERS_V5 v5;
+};
+
+int radeon_atom_get_clock_dividers(struct radeon_device *rdev,
+  u8 clock_type,
+  u32 clock,
+  bool strobe_mode,
+  struct atom_clock_dividers *dividers)
+{
+   union get_clock_dividers args;
+   int index = GetIndexIntoMasterTable(COMMAND, ComputeMemoryEnginePLL);
+   u8 frev, crev;
+
+   memset(args, 0, sizeof(args));
+   memset(dividers, 0, sizeof(struct atom_clock_dividers));
+
+   if (!atom_parse_cmd_header(rdev-mode_info.atom_context, index, frev, 
crev))
+   return -EINVAL;
+
+   switch (crev) {
+   case 1:
+   /* r4xx, r5xx */
+   args.v1.ucAction = clock_type;
+   args.v1.ulClock = cpu_to_le32(clock);   /* 10 khz */
+
+   atom_execute_table(rdev-mode_info.atom_context, index, 
(uint32_t *)args);
+
+   dividers-post_div = args.v1.ucPostDiv;
+   dividers-fb_div = args.v1.ucFbDiv;
+   dividers-enable_post_div = true;
+   break;
+   case 2:
+   case 3:
+   /* r6xx, r7xx, evergreen, ni */
+   if (rdev-family = CHIP_RV770) {
+   args.v2.ucAction = clock_type;
+   args.v2.ulClock = cpu_to_le32(clock);   /* 10 khz */
+
+   atom_execute_table(rdev-mode_info.atom_context, index, 
(uint32_t *)args);
+
+   dividers-post_div = args.v2.ucPostDiv;
+   dividers-fb_div = le16_to_cpu(args.v2.usFbDiv);
+   dividers-ref_div = args.v2.ucAction;
+   if (rdev-family == CHIP_RV770) {
+   dividers-enable_post_div = 
(le32_to_cpu(args.v2.ulClock)  (1  24)) ?
+   true : false;
+   dividers-vco_mode = 
(le32_to_cpu(args.v2.ulClock)  (1  25)) ? 1 : 0;
+   } else
+   dividers-enable_post_div = (dividers-fb_div  
1) ? true : false;
+   } else {
+   if (clock_type == COMPUTE_ENGINE_PLL_PARAM) {
+   args.v3.ulClock.ulComputeClockFlag = clock_type;
+   args.v3.ulClock.ulClockFreq = 
cpu_to_le32(clock);   /* 10 khz */
+
+   
atom_execute_table(rdev-mode_info.atom_context, index, (uint32_t *)args);
+
+   dividers-post_div = args.v3.ucPostDiv;
+   dividers-enable_post_div = (args.v3.ucCntlFlag 

+
ATOM_PLL_CNTL_FLAG_PLL_POST_DIV_EN) ? true : false;
+   dividers-enable_dithen = (args.v3.ucCntlFlag 
+  
ATOM_PLL_CNTL_FLAG_FRACTION_DISABLE) ? false : true;
+   dividers-fb_div = 
le16_to_cpu(args.v3.ulFbDiv.usFbDiv);
+

[PATCH 05/10] drm/radeon: add set_uvd_clocks callback for ON/LN/TN (v4)

From: Alex Deucher alexander.deuc...@amd.com

v2: write clk registers only once!
v3: update cg scratch register properly
v4: add TN support

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Signed-off-by: Christian König deathsim...@vodafone.de
---
 drivers/gpu/drm/radeon/evergreen.c   |   47 ++
 drivers/gpu/drm/radeon/evergreend.h  |   10 
 drivers/gpu/drm/radeon/radeon_asic.c |2 ++
 drivers/gpu/drm/radeon/radeon_asic.h |1 +
 4 files changed, 60 insertions(+)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 18b66ff..bdd3d34 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -84,6 +84,53 @@ void evergreen_tiling_fields(unsigned tiling_flags, unsigned 
*bankw,
}
 }
 
+static int sumo_set_uvd_clock(struct radeon_device *rdev, u32 clock,
+ u32 cntl_reg, u32 status_reg)
+{
+   int r, i;
+   struct atom_clock_dividers dividers;
+
+r = radeon_atom_get_clock_dividers(rdev, COMPUTE_ENGINE_PLL_PARAM,
+  clock, false, dividers);
+   if (r)
+   return r;
+
+   WREG32_P(cntl_reg, dividers.post_div, 
~(DCLK_DIR_CNTL_EN|DCLK_DIVIDER_MASK));
+
+   for (i = 0; i  100; i++) {
+   if (RREG32(status_reg)  DCLK_STATUS)
+   break;
+   mdelay(10);
+   }
+   if (i == 100)
+   return -ETIMEDOUT;
+
+   return 0;
+}
+
+int sumo_set_uvd_clocks(struct radeon_device *rdev, u32 vclk, u32 dclk)
+{
+   int r = 0;
+   u32 cg_scratch = RREG32(CG_SCRATCH1);
+
+   r = sumo_set_uvd_clock(rdev, vclk, CG_VCLK_CNTL, CG_VCLK_STATUS);
+   if (r)
+   goto done;
+   cg_scratch = 0x;
+   cg_scratch |= vclk / 100; /* Mhz */
+
+   r = sumo_set_uvd_clock(rdev, dclk, CG_DCLK_CNTL, CG_DCLK_STATUS);
+   if (r)
+   goto done;
+   cg_scratch = 0x;
+   cg_scratch |= (dclk / 100)  16; /* Mhz */
+
+done:
+   WREG32(CG_SCRATCH1, cg_scratch);
+
+   return r;
+}
+
 void evergreen_fix_pci_max_read_req_size(struct radeon_device *rdev)
 {
u16 ctl, v;
diff --git a/drivers/gpu/drm/radeon/evergreend.h 
b/drivers/gpu/drm/radeon/evergreend.h
index c5d873e..b6491a3 100644
--- a/drivers/gpu/drm/radeon/evergreend.h
+++ b/drivers/gpu/drm/radeon/evergreend.h
@@ -53,6 +53,16 @@
 #define RCU_IND_INDEX  0x100
 #define RCU_IND_DATA   0x104
 
+/* fusion uvd clocks */
+#define CG_DCLK_CNTL0x610
+#   define DCLK_DIVIDER_MASK0x7f
+#   define DCLK_DIR_CNTL_EN (1  8)
+#define CG_DCLK_STATUS  0x614
+#   define DCLK_STATUS  (1  0)
+#define CG_VCLK_CNTL0x618
+#define CG_VCLK_STATUS  0x61c
+#defineCG_SCRATCH1 0x820
+
 #define GRBM_GFX_INDEX 0x802C
 #defineINSTANCE_INDEX(x)   ((x)  0)
 #defineSE_INDEX(x) ((x)  16)
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
b/drivers/gpu/drm/radeon/radeon_asic.c
index a7a7b2b..d3992d9 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -1373,6 +1373,7 @@ static struct radeon_asic sumo_asic = {
.get_pcie_lanes = NULL,
.set_pcie_lanes = NULL,
.set_clock_gating = NULL,
+   .set_uvd_clocks = sumo_set_uvd_clocks,
},
.pflip = {
.pre_page_flip = evergreen_pre_page_flip,
@@ -1744,6 +1745,7 @@ static struct radeon_asic trinity_asic = {
.get_pcie_lanes = NULL,
.set_pcie_lanes = NULL,
.set_clock_gating = NULL,
+   .set_uvd_clocks = sumo_set_uvd_clocks,
},
.pflip = {
.pre_page_flip = evergreen_pre_page_flip,
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h 
b/drivers/gpu/drm/radeon/radeon_asic.h
index 515db96..37f28a3 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -459,6 +459,7 @@ extern void evergreen_pm_prepare(struct radeon_device 
*rdev);
 extern void evergreen_pm_finish(struct radeon_device *rdev);
 extern void sumo_pm_init_profile(struct radeon_device *rdev);
 extern void btc_pm_init_profile(struct radeon_device *rdev);
+int sumo_set_uvd_clocks(struct radeon_device *rdev, u32 vclk, u32 dclk);
 extern void evergreen_pre_page_flip(struct radeon_device *rdev, int crtc);
 extern u32 evergreen_page_flip(struct radeon_device *rdev, int crtc, u64 
crtc_base);
 extern void evergreen_post_page_flip(struct radeon_device *rdev, int crtc);
--

[PATCH 08/10] drm/radeon: add set_uvd_clocks callback for r7xx v3