attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130627/d1d78111/attachment.html>
t available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130627/635f49cc/attachment.pgp>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130627/f2fa9cf1/attachment.html>
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/20130627/c02aa336/attachment.html>
On Thu, Jun 27, 2013 at 01:48:16PM +0200, Maarten Lankhorst wrote:
> This adds support for a generic reservations framework that can be
> hooked up to ttm and dma-buf and allows easy sharing of reservations
> across devices.
>
> The idea is that a dma-buf and ttm object both will get a pointer
> t
On Thu, Jun 27, 2013 at 01:48:17PM +0200, Maarten Lankhorst wrote:
> This commit converts the source of the val_seq counter to
> the ww_mutex api. The reservation objects are converted later,
> because there is still a lockdep splat in nouveau that has to
> resolved first.
>
> Signed-off-by: Maart
On Thu, Jun 27, 2013 at 01:48:19PM +0200, Maarten Lankhorst wrote:
> Now that the code is compatible in semantics, flip the switch.
> Use ww_mutex instead of the homegrown implementation.
>
> ww_mutex uses -EDEADLK to signal that the caller has to back off,
> and -EALREADY to indicate this buffer
On Thu, Jun 27, 2013 at 01:48:23PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/radeon_object.c | 23 ---
> drivers/gpu/drm/radeon/radeon_object.h | 22 +-
> 2 files changed,
On Thu, Jun 27, 2013 at 01:48:26PM +0200, Maarten Lankhorst wrote:
> Try to use lockdep_assert_held or other alternatives where possible.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/radeon_object.c | 8 ++--
> drivers/gpu/drm/radeon/radeon_o
).
--
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/20130627/3b9d5c9b/attachment.html>
> "AD" == Alex Deucher writes:
AD> Nope. 6xx and APUs do not require ucode. only 7xx+ dGPUs.
Does that mean that APUs do not require *any* ucode blobs?
Or just that they do not require updated or additional blobs
for the new functionality like DPM?
-JimC
--
James Cloos OpenPGP:
On Thu, Jun 27, 2013 at 6:19 PM, James Cloos wrote:
>> "AD" == Alex Deucher writes:
>
> AD> Nope. 6xx and APUs do not require ucode. only 7xx+ dGPUs.
>
> Does that mean that APUs do not require *any* ucode blobs?
>
> Or just that they do not require updated or additional blobs
> for the new
On Thu, Jun 27, 2013 at 9:12 AM, Andy Furniss wrote:
> Alex Deucher wrote:
>>
>> On Wed, Jun 26, 2013 at 9:21 AM, wrote:
>>>
>>> From: Alex Deucher
>>>
>>> These are the radeon patches for 3.11. Some of these patches
>>> are huge so, it might be easier to review things here:
>>> http://cgit.fr
From: Alex Deucher
Hi Dave,
This is the pull request for radeon for 3.11. Highlights include:
- Support for CIK (Sea Islands) asics: 3D, compute, UVD
- DPM (Dynamic Power Management) support for 6xx-SI
- ASPM support for 6xx-SI
- Assorted bug fixes
DPM is disabled by default for now until it
Thanks for the work the whole thing seems to work fine on my RV770, although I
cannot really say if does anything as I found no way to query the current clk
or voltage?! There is one little gripe though, the rest of the code uses
DRM_INFO() for printing whereas this series uses plain printk() re
[Daniel Vetter]
> The buttons might do something fancy behind the scenes (kernel or
> userspace), so can you please also check whether directly changing
> the backlight values in /sys/class/backlight works correctly?
There is full brightness when I set the value of max_brightness into
the brightne
Hello.
I have cloned Linus' tree, then pulled from
git://people.freedesktop.org/~agd5f/linux and built the kernel.
However, I forgot to install the now-required radeon/TURKS_smc.bin
firmware file. The result is an ugly lockdep trace (please ignore Sony
firmware bug):
[ 39.693862] radeon :16
Hi,
> This patch should fix your issue :
>
> http://people.freedesktop.org/~glisse/0001-radeon-do-no-schedule-thermal-work-if-dpm-is-not-ena.patch
>
yes, that seems to do the trick (but I can not be 100% sure, since I
only saw the warning once).
>
> Cheers,
> Jerome
Best regards,
Julian
201 - 218 of 218 matches
Mail list logo
