date:20160125

[PATCH] drm/radeon: only init fbdev if we have connectors

2016-01-25 Thread Mike Lothian

Is something similar required for AMDGPU too?

On Mon, 25 Jan 2016 at 23:06 Rob Clark  wrote:

> This fixes an issue that was noticed on an optimus/prime laptop with
> a kernel that was old enough to not support the integrated intel gfx
> (which was driving all the outputs), but did have support for the
> discrete radeon gpu.  The end result was not falling back to VESA and
> leaving the user with a black screen.
>
> (Plus it is kind of silly to create an framebuffer device if there
> are no outputs hooked up to the gpu.)
>
> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/radeon/radeon_display.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c
> b/drivers/gpu/drm/radeon/radeon_display.c
> index 1eca0ac..f8e776c 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -1670,8 +1670,10 @@ int radeon_modeset_init(struct radeon_device *rdev)
> /* setup afmt */
> radeon_afmt_init(rdev);
>
> -   radeon_fbdev_init(rdev);
> -   drm_kms_helper_poll_init(rdev->ddev);
> +   if (!list_empty(&rdev->ddev->mode_config.connector_list)) {
> +   radeon_fbdev_init(rdev);
> +   drm_kms_helper_poll_init(rdev->ddev);
> +   }
>
> /* do pm late init */
> ret = radeon_pm_late_init(rdev);
> --
> 2.5.0
>
> ___
> 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/20160125/42fc5cfb/attachment-0001.html>

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

2016-01-25 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #76 from Julian  ---
(In reply to Ioannis Panagiotopoulos from comment #75)
> Also tried this since I have the same problem, compiled the new_smc branch,
> installed the kernel and the firmware, however the problem persists if I
> boot it without radeon.dpm=0.

What card do you have?

You can try this as well: download and move the hawaii_k_smc.bin firmware image
into /lib/firmware/radeon and rename it to hawaii_smc.bin (backup or delete the
existing file). Boot into your normal unpatched Kernel and see if it works.
That's what I'm doing right now and it works for me.

Just keep in mind that this might break your Linux install if it doesn't work
(so having a live USB/CD and the backuped firmware file is handy).

-- 
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/20160125/db5f8fe0/attachment.html>

linux-4.4 bisected: kwin5 stuck on kde5 loading screen with radeon

2016-01-25 Thread Daniel Vetter

On Mon, Jan 25, 2016 at 10:42 PM, Mario Kleiner
 wrote:
>>
>>> Now the patch i want to try next to fix the drm_vblank_pre/post_modeset
>>> regression in Linux 4.4/4.5 is to add a ...
>>>
>>> if ((diff > 1) && vblank->inmodeset) diff = 1;
>>>
>>> ... to the bottom of drm_update_vblank_count(). That should hopefully
>>> restore the pre/post_modeset behavior as close to the original behavior
>>> as
>>> possible. As a side effect it would also prevent the counter jump caused
>>> by
>>> redundant calls to drm_vblank_off().
>>
>>
>> Hm, can we just frob pre/post_modeset only with some checks? I'd like to
>> not put that kind of "I have no idea about my hw state" hacks into the new
>> helpers. Otherwise not even atomic drivers can start to gain WARN_ONs to
>> enforce correct usage, which would be a real bummer imo.
>> -Daniel
>>
>
> We could check for only (vblank->inmodeset & 0x2) to only apply it to the
> legacy pre/post path, trusting that the drm_vblank_off/on path will be made
> robust in a different way, e.g., by the stuff discussed above and careful
> implementation in each kms driver that uses those. Atm. radeon doesn't use
> off/on, so your enablement patch set can make sure it does the right thing
> from the beginning.
>
> rockchip-kms may need similar treatment to radeon to avoid redundant calls.
>
> Btw. how the patch to drm_update_vblank_count() close to the bottom would
> actually look is more like:
>
> if ((diff > 1) &&
> ((vblank->inmodeset & 0x2) || (flags & DRM_CALLED_FROM_VBLIRQ)))
>  diff = 1;

Yeah I think that should work as a short-term fix for radoen. When you
do that, can you pls do a second patch to give the magic 0x2 and 0x1
some meaning? Otherwise this is super-hard to understand code ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] gpu: drm: amd: amdkfd: Remove unnecessary cast in kfree

2016-01-25 Thread Amitoj Kaur Chawla

Remove an unnecassary cast in the argument to kfree.

Found using Coccinelle. The semantic patch used to find this is as follows:

//
@@
type T;
expression *f;
@@

- kfree((T *)(f));
+ kfree(f);
//

Signed-off-by: Amitoj Kaur Chawla 
---
 drivers/gpu/drm/amd/amdkfd/kfd_process.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index 9be0070..a902ae0 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -194,7 +194,7 @@ static void kfd_process_wq_release(struct work_struct *work)

kfree(p);

-   kfree((void *)work);
+   kfree(work);
 }

 static void kfd_process_destroy_delayed(struct rcu_head *rcu)
-- 
1.9.1

[Bug 93866] Tonga: Weston-drm direct scan out corruption

2016-01-25 Thread bugzilla-dae...@freedesktop.org

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

Andy Furniss  changed:

   What|Removed |Added

 Attachment #121287|text/plain  |image/jpeg
  mime type||

-- 
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/20160125/980c20d5/attachment.html>

[Bug 93866] Tonga: Weston-drm direct scan out corruption

2016-01-25 Thread bugzilla-dae...@freedesktop.org

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

Bug ID: 93866
Summary: Tonga: Weston-drm direct scan out corruption
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: DRM/AMDgpu
Assignee: dri-devel at lists.freedesktop.org
Reporter: adf.lists at gmail.com

Created attachment 121287
--> https://bugs.freedesktop.org/attachment.cgi?id=121287&action=edit
external picture showing corruption

Testing both release and git wayland/weston on R9285.

Using weston-launch from fbcon so it uses weston-drm.

Apart from https://bugs.freedesktop.org/show_bug.cgi?id=93740 which can be
worked around, rendering is good when compositing.

If I run something that allows weston to enable direct scanout there is slight
corruption. kodi and mpv are the only ways I know to do this.

If I do something that changes back yo compositing the corruption goes, taking
a screen shot/recording or zooming in will all "fix" the corruption.

I am inferring direct scan out is happening as I can't change transparency +
the man page for weston-drm says it will be used where possible.

Tried going back in time with mesa to see if it ever worked, but I started
hitting places where either weston wouldn't start or I always got compositing
so no corruption but I could change transparency.

--
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/20160125/d8c8809f/attachment.html>

1 2 >

1 - 100 of 101 matches

Mail list logo