(chunk_ib->va_start + chunk_ib->ib_bytes) >
> (u64)(m->it.last + 1) * AMDGPU_GPU_PAGE_SIZE) {
That won't work correctly if m->it.last == 0x ? Or is that not
possible?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
+ chunk_ib->ib_bytes) >
>> -(m->it.last + 1) * AMDGPU_GPU_PAGE_SIZE) {
>> +(it_last + 1) * AMDGPU_GPU_PAGE_SIZE) {
>
> Nice catch, but just adding a u64 case should do here as well. E.g:
>
> if ((chunk_ib->va_sta
From: Michel Dänzer <michel.daen...@amd.com>
Otherwise this can also prevent modesets e.g. for switching VTs, when
multiple monitors with different native resolutions are connected.
The depths must match though, so keep the != test for that.
Also update the DRM_DEBUG output to be slightl
From: Michel Dänzer
Otherwise this can also prevent modesets e.g. for switching VTs, when
multiple monitors with different native resolutions are connected.
The depths must match though, so keep the != test for that.
Also update the DRM_DEBUG output to be slightly more accurate, this
doesn't
On 17/03/17 08:13 PM, Ville Syrjälä wrote:
> On Fri, Mar 17, 2017 at 07:19:27PM +0900, Michel Dänzer wrote:
>> On 17/03/17 07:01 PM, Ville Syrjälä wrote:
>>> On Fri, Mar 17, 2017 at 06:01:41PM +0900, Michel Dänzer wrote:
>>>> On 16/03/17 07:09 PM, Ville Syrjälä wro
On 17/03/17 08:13 PM, Ville Syrjälä wrote:
> On Fri, Mar 17, 2017 at 07:19:27PM +0900, Michel Dänzer wrote:
>> On 17/03/17 07:01 PM, Ville Syrjälä wrote:
>>> On Fri, Mar 17, 2017 at 06:01:41PM +0900, Michel Dänzer wrote:
>>>> On 16/03/17 07:09 PM, Ville Syrjälä wro
On 17/03/17 07:01 PM, Ville Syrjälä wrote:
> On Fri, Mar 17, 2017 at 06:01:41PM +0900, Michel Dänzer wrote:
>> On 16/03/17 07:09 PM, Ville Syrjälä wrote:
>>> On Thu, Mar 16, 2017 at 06:55:53PM +0900, Michel Dänzer wrote:
>>>> From: Michel Dänzer <michel.dae
On 17/03/17 07:01 PM, Ville Syrjälä wrote:
> On Fri, Mar 17, 2017 at 06:01:41PM +0900, Michel Dänzer wrote:
>> On 16/03/17 07:09 PM, Ville Syrjälä wrote:
>>> On Thu, Mar 16, 2017 at 06:55:53PM +0900, Michel Dänzer wrote:
>>>> From: Michel Dänzer
>>>>
>
On 16/03/17 07:09 PM, Ville Syrjälä wrote:
> On Thu, Mar 16, 2017 at 06:55:53PM +0900, Michel Dänzer wrote:
>> From: Michel Dänzer <michel.daen...@amd.com>
>>
>> Otherwise this can also prevent modesets e.g. for switching VTs.
>>
>> FB_MISC_USER_EVENT
On 16/03/17 07:09 PM, Ville Syrjälä wrote:
> On Thu, Mar 16, 2017 at 06:55:53PM +0900, Michel Dänzer wrote:
>> From: Michel Dänzer
>>
>> Otherwise this can also prevent modesets e.g. for switching VTs.
>>
>> FB_MISC_USER_EVENT is set when the request originates
On 16/03/17 07:09 PM, Daniel Stone wrote:
> On 16 March 2017 at 09:55, Michel Dänzer <mic...@daenzer.net> wrote:
>> Otherwise this can also prevent modesets e.g. for switching VTs.
>>
>> FB_MISC_USER_EVENT is set when the request originates from userspace,
>> which
On 16/03/17 07:09 PM, Daniel Stone wrote:
> On 16 March 2017 at 09:55, Michel Dänzer wrote:
>> Otherwise this can also prevent modesets e.g. for switching VTs.
>>
>> FB_MISC_USER_EVENT is set when the request originates from userspace,
>> which is what we're i
From: Michel Dänzer <michel.daen...@amd.com>
Otherwise this can also prevent modesets e.g. for switching VTs.
FB_MISC_USER_EVENT is set when the request originates from userspace,
which is what we're interested in here according to the DRM_DEBUG
output.
Bugzilla: https://bugs.freedeskt
From: Michel Dänzer
Otherwise this can also prevent modesets e.g. for switching VTs.
FB_MISC_USER_EVENT is set when the request originates from userspace,
which is what we're interested in here according to the DRM_DEBUG
output.
Bugzilla: https://bugs.freedesktop.org/99841
Fixes: 865afb11949e
init in 4.11.
AMD folks, should this be addressed by fleshing out SI GDS support, or
by completely disabling GDS initialization for SI?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
init in 4.11.
AMD folks, should this be addressed by fleshing out SI GDS support, or
by completely disabling GDS initialization for SI?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On 10/03/17 08:46 PM, Ben Hutchings wrote:
> 3.16.42-rc1 review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Michel Dänzer <michel.daen...@amd.com>
>
> commit d74c67dd7800fc7aae381f272875c337f268806c upstream.
>
&g
On 10/03/17 08:46 PM, Ben Hutchings wrote:
> 3.16.42-rc1 review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Michel Dänzer
>
> commit d74c67dd7800fc7aae381f272875c337f268806c upstream.
>
> The crtc_h/vdisplay fields may
intervals the ioctl returns,
and which CRTCs are in vertical blank when it does. So it would be
useless for both timing and tearing prevention purposes, i.e. more or
less completely useless.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software e
intervals the ioctl returns,
and which CRTCs are in vertical blank when it does. So it would be
useless for both timing and tearing prevention purposes, i.e. more or
less completely useless.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software e
On 02/02/17 06:36 PM, Christian König wrote:
> Am 02.02.2017 um 07:09 schrieb Michel Dänzer:
>> [SNIP]
>> OTOH the people running the kernel aren't always the same people
>> building it, so the downside is that this would potentially delay
>> getting X86_PA
On 02/02/17 06:36 PM, Christian König wrote:
> Am 02.02.2017 um 07:09 schrieb Michel Dänzer:
>> [SNIP]
>> OTOH the people running the kernel aren't always the same people
>> building it, so the downside is that this would potentially delay
>> getting X86_PA
ch
> shuts it up for me, but not people that may actually want to run the kernel
> as a compromize.
This is fine with me as well.
Whichever way we end up going for this, it should be applied to the
radeon driver as well.
--
Earthling Michel Dänzer |
ch
> shuts it up for me, but not people that may actually want to run the kernel
> as a compromize.
This is fine with me as well.
Whichever way we end up going for this, it should be applied to the
radeon driver as well.
--
Earthling Michel Dänzer |
On 26/01/17 09:46 AM, Sinclair Yeh wrote:
> On Wed, Jan 25, 2017 at 10:49:33AM +0100, Christian König wrote:
>> Am 25.01.2017 um 10:25 schrieb Thomas Hellstrom:
>>> On 01/25/2017 09:21 AM, Michel Dänzer wrote:
>>>> From: Michel Dänzer <michel.daen...@amd.com>
On 26/01/17 09:46 AM, Sinclair Yeh wrote:
> On Wed, Jan 25, 2017 at 10:49:33AM +0100, Christian König wrote:
>> Am 25.01.2017 um 10:25 schrieb Thomas Hellstrom:
>>> On 01/25/2017 09:21 AM, Michel Dänzer wrote:
>>>> From: Michel Dänzer
>>>>
>>>>
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3846fd9b86001bea171943cc3bb9222cb6da6b42
Daniel, please take a look.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3846fd9b86001bea171943cc3bb9222cb6da6b42
Daniel, please take a look.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
From: Michel Dänzer <michel.daen...@amd.com>
The current caching state may not be tt_cached, even though the
placement contains TTM_PL_FLAG_CACHED, because placement can contain
multiple caching flags. Trying to swap out such a BO would trip up the
BUG_ON(ttm->caching_state !=
From: Michel Dänzer
The current caching state may not be tt_cached, even though the
placement contains TTM_PL_FLAG_CACHED, because placement can contain
multiple caching flags. Trying to swap out such a BO would trip up the
BUG_ON(ttm->caching_state != tt_cached);
in ttm_tt_swap
On 20/01/17 04:44 PM, Nils Holland wrote:
> On Fri, Jan 20, 2017 at 11:47:53AM +0900, Michel Dänzer wrote:
>> On 20/01/17 04:35 AM, Nils Holland wrote:
>>>
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c2016-12-11
>>> 20:17:54.0 +0100
On 20/01/17 04:44 PM, Nils Holland wrote:
> On Fri, Jan 20, 2017 at 11:47:53AM +0900, Michel Dänzer wrote:
>> On 20/01/17 04:35 AM, Nils Holland wrote:
>>>
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c2016-12-11
>>> 20:17:54.0 +0100
er works fine for me on my 32 bit
> kernel: All graphics output looks the way it's supposed to, even with
> full acceleration enabled - great!
>
> I'd suggest that it might be a good idea to put to apply the above
> patch or something similar to the official sources.
Indeed. Do y
er works fine for me on my 32 bit
> kernel: All graphics output looks the way it's supposed to, even with
> full acceleration enabled - great!
>
> I'd suggest that it might be a good idea to put to apply the above
> patch or something similar to the official sources.
Indeed. Do y
potentially trying to access the framebuffer at the most
inconvenient times). There's still ttm_fbdev_mmap, but I'm not sure
everything to make this fully work for userspace fbdev mappings is still
there.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
potentially trying to access the framebuffer at the most
inconvenient times). There's still ttm_fbdev_mmap, but I'm not sure
everything to make this fully work for userspace fbdev mappings is still
there.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
ertainly will get complains about
> that rather fast.
Suspect we already did:
https://bugs.freedesktop.org/show_bug.cgi?id=98915
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
ertainly will get complains about
> that rather fast.
Suspect we already did:
https://bugs.freedesktop.org/show_bug.cgi?id=98915
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
be more appropriate to return -ENOTSUPP rather
>> than 0.
Can't see how that would matter FWIW.
> Seems a bit overkill, but can't hurt. This is most likely a
> regression, probably introduced in
>
> commit f837297ad82480024d3ad08cd84f6670bcafa862
> Author: Michel Dänzer <michel.daen...@amd.com>
> Dat
directory
>>
>> Looks like vgem. Something like this should help:
>>
>> https://gist.github.com/dvdhrm/1bcdf4f3485aa1614a0198a7b90515e2
>>
>> I wonder whether it would be more appropriate to return -ENOTSUPP rather
>> than 0.
Can't see how that would
badc1a3379fb3211e5
https://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next=9305ee6fe52035f63d70d023235b792ba22107f0
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
badc1a3379fb3211e5
https://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next=9305ee6fe52035f63d70d023235b792ba22107f0
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
in Linus' tree soon:
https://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next=b0c80bd5d2e317f7596fe2badc1a3379fb3211e5
https://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next=9305ee6fe52035f63d70d023235b792ba22107f0
--
Earthling Michel Dänzer | http://ww
in Linus' tree soon:
https://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next=b0c80bd5d2e317f7596fe2badc1a3379fb3211e5
https://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next=9305ee6fe52035f63d70d023235b792ba22107f0
--
Earthling Michel Dänzer | http://ww
On 07.07.2016 16:43, Christian König wrote:
> Am 07.07.2016 um 05:32 schrieb Michel Dänzer:
>> On 06.07.2016 22:45, Tejun Heo wrote:
>>> On Wed, Jul 06, 2016 at 12:12:52PM +0900, Michel Dänzer wrote:
>>>
>>>> Not being very familiar with the workqueue API
On 07.07.2016 16:43, Christian König wrote:
> Am 07.07.2016 um 05:32 schrieb Michel Dänzer:
>> On 06.07.2016 22:45, Tejun Heo wrote:
>>> On Wed, Jul 06, 2016 at 12:12:52PM +0900, Michel Dänzer wrote:
>>>
>>>> Not being very familiar with the workqueue API
On 06.07.2016 22:45, Tejun Heo wrote:
> On Wed, Jul 06, 2016 at 12:12:52PM +0900, Michel Dänzer wrote:
>
>> Not being very familiar with the workqueue APIs, I'll describe how it's
>> supposed to work from a driver POV, which will hopefully help you guys
>> decide
On 06.07.2016 22:45, Tejun Heo wrote:
> On Wed, Jul 06, 2016 at 12:12:52PM +0900, Michel Dänzer wrote:
>
>> Not being very familiar with the workqueue APIs, I'll describe how it's
>> supposed to work from a driver POV, which will hopefully help you guys
>> decide
On 06.07.2016 06:06, Tejun Heo wrote:
> On Mon, Jul 04, 2016 at 12:58:32PM +0900, Michel Dänzer wrote:
>> On 02.07.2016 22:46, Tejun Heo wrote:
>>> On Sat, Jul 02, 2016 at 04:33:50PM +0530, Bhaktipriya Shridhar wrote:
>>>> alloc_workqueue replaces deprecated
On 06.07.2016 06:06, Tejun Heo wrote:
> On Mon, Jul 04, 2016 at 12:58:32PM +0900, Michel Dänzer wrote:
>> On 02.07.2016 22:46, Tejun Heo wrote:
>>> On Sat, Jul 02, 2016 at 04:33:50PM +0530, Bhaktipriya Shridhar wrote:
>>>> alloc_workqueue replaces deprecated
imit is unnecessary here.
>
> What are the involved work items?
drivers/gpu/drm/radeon/radeon_display.c:radeon_flip_work_func()
> Is it safe to run them concurrently?
Concurrently with what exactly?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
imit is unnecessary here.
>
> What are the involved work items?
drivers/gpu/drm/radeon/radeon_display.c:radeon_flip_work_func()
> Is it safe to run them concurrently?
Concurrently with what exactly?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On 07.06.2016 23:07, Gustavo Padovan wrote:
> From: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
>
> Replace the legacy drm_vblank_{on,off}() with the new helper functions.
>
> Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
Patches 6 & 8-10
On 07.06.2016 23:07, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Replace the legacy drm_vblank_{on,off}() with the new helper functions.
>
> Signed-off-by: Gustavo Padovan
Patches 6 & 8-10 are
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer |
> @@ -268,7 +268,7 @@ int amdgpu_crtc_page_flip(struct drm_crtc *crtc,
> return 0;
>
> vblank_cleanup:
> - drm_vblank_put(crtc->dev, amdgpu_crtc->crtc_id);
> + drm_crtc_vblank_put(_crtc->base);
Can just use crtc here instead of _crtc->base.
,
> return 0;
>
> vblank_cleanup:
> - drm_vblank_put(crtc->dev, amdgpu_crtc->crtc_id);
> + drm_crtc_vblank_put(_crtc->base);
Can just use crtc here instead of _crtc->base. Same for the
radeon patch.
--
Earthling Michel Dänzer |
tatic int dce_v8_0_pageflip_irq(struct amdgpu_device
> *adev,
>
> /* wakeup usersapce */
> if (works->event)
> - drm_send_vblank_event(adev->ddev, crtc_id, works->event);
> + drm_crtc_send_vblank_event(_crtc->base, works->event);
>
> spin_unl
/* wakeup usersapce */
> if (works->event)
> - drm_send_vblank_event(adev->ddev, crtc_id, works->event);
> + drm_crtc_send_vblank_event(_crtc->base, works->event);
>
> spin_unlock_irqrestore(>ddev->event_lock, flags);
>
>
This patch and patch 8 are
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On 12.04.2016 23:16, Greg Kroah-Hartman wrote:
> On Mon, Apr 11, 2016 at 11:26:00AM +0900, Michel Dänzer wrote:
>> On 11.04.2016 03:36, Greg Kroah-Hartman wrote:
>>> 4.4-stable review patch. If anyone has any objections, please let me know.
>>
>> A regressi
On 12.04.2016 23:16, Greg Kroah-Hartman wrote:
> On Mon, Apr 11, 2016 at 11:26:00AM +0900, Michel Dänzer wrote:
>> On 11.04.2016 03:36, Greg Kroah-Hartman wrote:
>>> 4.4-stable review patch. If anyone has any objections, please let me know.
>>
>> A regressi
On 12.04.2016 23:16, Greg Kroah-Hartman wrote:
> On Mon, Apr 11, 2016 at 11:26:00AM +0900, Michel Dänzer wrote:
>> On 11.04.2016 03:36, Greg Kroah-Hartman wrote:
>>> 4.4-stable review patch. If anyone has any objections, please let me know.
>>
>> A regressi
On 12.04.2016 23:16, Greg Kroah-Hartman wrote:
> On Mon, Apr 11, 2016 at 11:26:00AM +0900, Michel Dänzer wrote:
>> On 11.04.2016 03:36, Greg Kroah-Hartman wrote:
>>> 4.4-stable review patch. If anyone has any objections, please let me know.
>>
>> A regressi
bly the corresponding amdgpu commit as well).
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
bly the corresponding amdgpu commit as well).
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
bution on my part.
> This bug clearly has nothing to do with this series.
>
> But a better look has me wondering how all these gpus are syncing
> the framebuffer for direct access via cfb_imageblit and friends. I only see
> nouveau and intel gma even trying.
Probably no
bution on my part.
> This bug clearly has nothing to do with this series.
>
> But a better look has me wondering how all these gpus are syncing
> the framebuffer for direct access via cfb_imageblit and friends. I only see
> nouveau and intel gma even trying.
Probably no
On 23.01.2016 00:18, Ville Syrjälä wrote:
> On Fri, Jan 22, 2016 at 12:06:00PM +0900, Michel Dänzer wrote:
>>
>> [ Trimming KDE folks from Cc ]
>>
>> On 21.01.2016 19:09, Daniel Vetter wrote:
>>> On Thu, Jan 21, 2016 at 05:36:46PM +0900, Michel Dänzer wrote:
>
On 23.01.2016 00:18, Ville Syrjälä wrote:
> On Fri, Jan 22, 2016 at 12:06:00PM +0900, Michel Dänzer wrote:
>>
>> [ Trimming KDE folks from Cc ]
>>
>> On 21.01.2016 19:09, Daniel Vetter wrote:
>>> On Thu, Jan 21, 2016 at 05:36:46PM +0900, Michel Dänzer wrote:
>
[ Trimming KDE folks from Cc ]
On 21.01.2016 19:09, Daniel Vetter wrote:
> On Thu, Jan 21, 2016 at 05:36:46PM +0900, Michel Dänzer wrote:
>> On 21.01.2016 16:58, Daniel Vetter wrote:
>>>
>>> Can you please point me at the vblank on/off jump bug please?
>&g
On 21.01.2016 16:58, Daniel Vetter wrote:
> On Thu, Jan 21, 2016 at 03:41:27PM +0900, Michel Dänzer wrote:
>> On 21.01.2016 15:38, Michel Dänzer wrote:
>>> On 21.01.2016 14:31, Mario Kleiner wrote:
>>>> On 01/21/2016 04:43 AM, Michel Dänzer wrote:
>>>>
On 21.01.2016 16:58, Daniel Vetter wrote:
> On Thu, Jan 21, 2016 at 03:41:27PM +0900, Michel Dänzer wrote:
>> On 21.01.2016 15:38, Michel Dänzer wrote:
>>> On 21.01.2016 14:31, Mario Kleiner wrote:
>>>> On 01/21/2016 04:43 AM, Michel Dänzer wrote:
>>>>
[ Trimming KDE folks from Cc ]
On 21.01.2016 19:09, Daniel Vetter wrote:
> On Thu, Jan 21, 2016 at 05:36:46PM +0900, Michel Dänzer wrote:
>> On 21.01.2016 16:58, Daniel Vetter wrote:
>>>
>>> Can you please point me at the vblank on/off jump bug please?
>&g
On 21.01.2016 15:38, Michel Dänzer wrote:
> On 21.01.2016 14:31, Mario Kleiner wrote:
>> On 01/21/2016 04:43 AM, Michel Dänzer wrote:
>>> On 21.01.2016 05:32, Mario Kleiner wrote:
>>>>
>>>> So the problem is that AMDs hardware frame counters reset to
&g
On 21.01.2016 14:31, Mario Kleiner wrote:
> On 01/21/2016 04:43 AM, Michel Dänzer wrote:
>> On 21.01.2016 05:32, Mario Kleiner wrote:
>>>
>>> So the problem is that AMDs hardware frame counters reset to
>>> zero during a modeset. The old DRM code dealt with driv
f anybody has any ideas offhand...
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On 21.01.2016 15:38, Michel Dänzer wrote:
> On 21.01.2016 14:31, Mario Kleiner wrote:
>> On 01/21/2016 04:43 AM, Michel Dänzer wrote:
>>> On 21.01.2016 05:32, Mario Kleiner wrote:
>>>>
>>>> So the problem is that AMDs hardware frame counters reset to
&g
f anybody has any ideas offhand...
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On 21.01.2016 14:31, Mario Kleiner wrote:
> On 01/21/2016 04:43 AM, Michel Dänzer wrote:
>> On 21.01.2016 05:32, Mario Kleiner wrote:
>>>
>>> So the problem is that AMDs hardware frame counters reset to
>>> zero during a modeset. The old DRM code dealt with driv
none of the drivers do, either.
daenzer@kaveri|11:55:31> grep '#include "drm.h"' include/uapi/drm/*
include/uapi/drm/amdgpu_drm.h:#include "drm.h"
include/uapi/drm/radeon_drm.h:#include "drm.h"
Patches to convert the rest are pending.
--
Earthling Michel Dänzer
to include/uapi/drm/drm.h in that tree?
> and none of the drivers do, either.
daenzer@kaveri|11:55:31> grep '#include "drm.h"' include/uapi/drm/*
include/uapi/drm/amdgpu_drm.h:#include "drm.h"
include/uapi/drm/radeon_drm.h:#include "drm.h"
Patches to convert
a problem, you did not know how to debug it, but it already
> happened to pebolle at tiscali ... and yes, it was agpmode. That
> problem is clearly more common then you realize... So this should go
> in.
I agree with Christian, but at the very least, agpmode must not be
m
83
>
> . I had a problem, you did not know how to debug it, but it already
> happened to pebolle at tiscali ... and yes, it was agpmode. That
> problem is clearly more common then you realize... So this should go
> in.
I agree with Christian, but at the very least, agpmode must no
On 18.11.2015 17:51, Daniel Vetter wrote:
> On Wed, Nov 18, 2015 at 05:39:39PM +0900, Michel Dänzer wrote:
>> On 18.11.2015 01:29, Daniel Vetter wrote:
>>>
>>> And no, I have absolutely no idea why radeon is pulling some tricks here,
>>> whi
isplay so we need to offset the plane position in order for the active
>> pixel to be in the correct place.
>
> Nope, hot_x/y is just for virtual machines to indicate where the logical
> cursor position is within the cursor plane. It should have 2 effect on how
> someth
active pixel on the
>> display so we need to offset the plane position in order for the active
>> pixel to be in the correct place.
>
> Nope, hot_x/y is just for virtual machines to indicate where the logical
> cursor position is within the cursor plane. It should have 2 effect on h
On 18.11.2015 17:51, Daniel Vetter wrote:
> On Wed, Nov 18, 2015 at 05:39:39PM +0900, Michel Dänzer wrote:
>> On 18.11.2015 01:29, Daniel Vetter wrote:
>>>
>>> And no, I have absolutely no idea why radeon is pulling some tricks here,
>>> whi
gt;
> ..and same issue. And yes, it looks like an underflow to me. How can I
> debug reclocking / underflows?
Does radeon.disp_priority=2 help?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X develope
gt;
> ..and same issue. And yes, it looks like an underflow to me. How can I
> debug reclocking / underflows?
Does radeon.disp_priority=2 help?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X develope
On 28.10.2015 19:45, Luis Henriques wrote:
> On Tue, Oct 27, 2015 at 11:10:29AM +0900, Michel Dänzer wrote:
>> On 26.10.2015 22:42, Luis Henriques wrote:
>>> 3.16.7-ckt19 -stable review patch. If anyone has any objections, please
>>> let me know.
>>>
>>
On 28.10.2015 19:45, Luis Henriques wrote:
> On Tue, Oct 27, 2015 at 11:10:29AM +0900, Michel Dänzer wrote:
>> On 26.10.2015 22:42, Luis Henriques wrote:
>>> 3.16.7-ckt19 -stable review patch. If anyone has any objections, please
>>> let me know.
>>>
>>
een introduced between those.
>
> Well this looks like it might have something to do with it will
> attempt a build just before it.
> --
> commit 4281f46ef839050d2ef60348f661eb463c21cc2e
> Author: Michel Dänzer
> Date: Mon Sep 28 18:16:31 2015 +0900
>
> drm/radeon: Rest
een introduced between those.
>
> Well this looks like it might have something to do with it will
> attempt a build just before it.
> --
> commit 4281f46ef839050d2ef60348f661eb463c21cc2e
> Author: Michel Dänzer <michel.daen...@amd.com>
> Date: Mon Sep 28 18:16:31 2015
On 26.10.2015 22:42, Luis Henriques wrote:
> 3.16.7-ckt19 -stable review patch. If anyone has any objections, please let
> me know.
>
> --
>
> From: =TF-8?q?Michel Dänzer?=
>
> commit 4281f46ef839050d2ef60348f661eb463c21cc2e upstream.
>
On 26.10.2015 22:42, Luis Henriques wrote:
> 3.16.7-ckt19 -stable review patch. If anyone has any objections, please let
> me know.
>
> --
>
> From: =TF-8?q?Michel Dänzer?= <michel.daen...@amd.com>
>
> commit 4281f46ef839050d2ef60348f661eb463
n driver is built into the kernel (or loaded from the
initrd?), the attempt to load the firmware might take a long time to
time out.
Please provide more information about the symptoms, e.g. any dmesg
output etc.
--
Earthling Michel Dänzer | http://www.
the
initrd?), the attempt to load the firmware might take a long time to
time out.
Please provide more information about the symptoms, e.g. any dmesg
output etc.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa
the DPMS state to on again. You can avoid
that with something like "sleep 1 && xset dpms force off".
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
--
To unsubscribe fr
state to on again. You can avoid
that with something like sleep 1 xset dpms force off.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
--
To unsubscribe from this list: send the line unsubscribe
);
> adev->ip_block_enabled = NULL;
> adev->accel_working = false;
> /* free i2c buses */
>
The shortlog prefix of both your patches should be "drm/amdgpu:" instead
of "gpu/drm:". With that fixed, both are
Reviewed-by: Michel Dänze
-accel_working = false;
/* free i2c buses */
The shortlog prefix of both your patches should be drm/amdgpu: instead
of gpu/drm:. With that fixed, both are
Reviewed-by: Michel Dänzer michel.daen...@amd.com
--
Earthling Michel Dänzer | http://www.amd.com
Libre
201 - 300 of 366 matches
Mail list logo
