Hello, are these patches merged yet? or are they on the queue for Linux
kernel 3.19?
And how they (shader/memory clocks) should be queried?
Thanks!
This platform_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: Wolfram Sang
---
Generated with coccinelle. SmPL file is in the introductory msg. The big
cleanup was pulled in this merge window. This series catches the bits fallen
through. The patches s
Generated with coccinelle. The big cleanup was pulled in this merge window.
This series catches the bits fallen through. The patches shall go in via the
subsystem trees. If possible for 3.19 to increase consistency I'd say, but you
decide, of course.
cocci-file used:
@match1@
declarer name module
-
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/20141221/a38483ec/attachment.html>
org/archives/dri-devel/attachments/20141221/8de15b13/attachment.html>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141221/6ddd1805/attachment.html>
Remove the function radeon_doorbell_free() that is not used anywhere.
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/gpu/drm/radeon/radeon.h|1 -
drivers/gpu/drm/radeon/radeon_device.c | 14
On 12/21/2014 05:57 PM, Christian König wrote:
>> There should be, but when the modules are compiled in, they are loaded based
>> on
>> link order only, if they are in the same group, and the groups are loaded by
>> a
>> pre-defined order.
> Is that really still up to date? I've seen effort to
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141221/fd5ce20e/attachment.html>
On !SMP systems spinlocks do not exist. Thus checking of they
are active will always fail.
Use
assert_spin_locked(lock);
instead of
BUG_ON(!spin_is_locked(lock));
to not BUG() on all UP systems.
Signed-off-by: Bruno Prémont
---
drivers/gpu/drm/omapdrm/omap_irq.c | 2 +-
1 file changed, 1 i
On !SMP systems spinlocks do not exist. Thus checking of they
are active will always fail.
Use
assert_spin_locked(lock);
instead of
BUG_ON(!spin_is_locked(lock));
to not BUG() on all UP systems.
Signed-off-by: Bruno Prémont
---
drivers/gpu/drm/msm/mdp/mdp_kms.c | 2 +-
1 file changed, 1 in
On !SMP systems spinlocks do not exist. Thus checking of they
are active will always fail.
Use
assert_spin_locked(lock);
instead of
BUG_ON(!spin_is_locked(lock));
to not BUG() on all UP systems.
Signed-off-by: Bruno Prémont
---
See also fdo bug #87552
drivers/gpu/drm/nouveau/core/core/eve
Am 21.12.2014 um 17:03 schrieb Oded Gabbay:
>
>
> On 12/21/2014 05:57 PM, Christian König wrote:
>>> There should be, but when the modules are compiled in, they are
>>> loaded based on
>>> link order only, if they are in the same group, and the groups are
>>> loaded by a
>>> pre-defined order.
>
> There should be, but when the modules are compiled in, they are loaded
> based on
> link order only, if they are in the same group, and the groups are
> loaded by a
> pre-defined order.
Is that really still up to date? I've seen effort to change that
something like 10+ years ago when Rusty re
We do not need to track the state of the IPU DI's clock flags by having
each display bridge calling back into imx-drm-core, and then back out
into ipuv3-crtc.c.
ipuv3-crtc can instead just scan the list of encoders to retrieve their
type, and build up a picture of which types of encoders are attac
On 12/21/2014 03:06 PM, Oded Gabbay wrote:
>
>
> On 12/21/2014 02:19 PM, Christian König wrote:
>> Am 21.12.2014 um 12:34 schrieb Oded Gabbay:
>>>
>>>
>>> On 12/21/2014 01:27 PM, Christian König wrote:
Am 20.12.2014 um 21:46 schrieb Oded Gabbay:
> When amdkfd and radeon are compiled in
On 12/21/2014 02:19 PM, Christian König wrote:
> Am 21.12.2014 um 12:34 schrieb Oded Gabbay:
>>
>>
>> On 12/21/2014 01:27 PM, Christian König wrote:
>>> Am 20.12.2014 um 21:46 schrieb Oded Gabbay:
When amdkfd and radeon are compiled inside the kernel image (not as
modules),
rade
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch]
> Sent: Thursday, December 18, 2014 19:21
> To: Thierry Reding
> Cc: Cheng, Yao; intel-gfx at lists.freedesktop.org; dri-
> devel at lists.freedesktop.org; Kelley, Sean V; Chehab, John;
> emil.l.velikov at gmail.c
is mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141221/bb15024c/attachment-0001.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141221/83aa312a/attachment.html>
On 12/21/2014 01:27 PM, Christian König wrote:
> Am 20.12.2014 um 21:46 schrieb Oded Gabbay:
>> When amdkfd and radeon are compiled inside the kernel image (not as modules),
>> radeon will load before amdkfd and will set *kfd2kgd to its interface
>> structure. Therefore, we must not set *kfd2kgd
Am 21.12.2014 um 12:34 schrieb Oded Gabbay:
>
>
> On 12/21/2014 01:27 PM, Christian König wrote:
>> Am 20.12.2014 um 21:46 schrieb Oded Gabbay:
>>> When amdkfd and radeon are compiled inside the kernel image (not as
>>> modules),
>>> radeon will load before amdkfd and will set *kfd2kgd to its int
On 12/20/2014 11:25 PM, Greg KH wrote:
> On Sat, Dec 20, 2014 at 10:46:12PM +0200, Oded Gabbay wrote:
>> When amdkfd and radeon are compiled inside the kernel image (not as modules),
>> radeon will load before amdkfd and will set *kfd2kgd to its interface
>> structure. Therefore, we must not set
./dix/stubmain.c:34
No locals.
quit
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141221/0afa8e93/attachment-0001.sig>
Am 20.12.2014 um 21:46 schrieb Oded Gabbay:
> When amdkfd and radeon are compiled inside the kernel image (not as modules),
> radeon will load before amdkfd and will set *kfd2kgd to its interface
> structure. Therefore, we must not set *kfd2kgd to NULL when amdkfd is loaded
> because it will overri
2014-12-21 3:46 GMT+01:00 Ben Skeggs :
> - Original Message -
>> From: "Rickard Strandqvist"
>> To: "David Airlie" , "Ben Skeggs" > redhat.com>
>> Cc: "Rickard Strandqvist" ,
>> "Alexandre Courbot" , "Ilia
>> Mirkin" , dri-devel at lists.freedesktop.org,
>> linux-kernel at vger.kernel.or
from Ernst Sjöstrand ---
I can also reproduce this. Radeon 6850.
--
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/20141
27 matches
Mail list logo
