On 2021-11-16 15:10, Alex Deucher wrote:
> On Tue, Nov 16, 2021 at 3:09 AM Christian König
> wrote:
>>
>> Am 16.11.21 um 09:00 schrieb Lang Yu:
>>> On Tue, Nov 16, 2021 at 08:14:08AM +0100, Christian KKKnig wrote:
Am 16.11.21 um 04:27 schrieb Lang Yu:
> On Mon, Nov 15, 2021 at 01:04:15PM
On Tue, Nov 16, 2021 at 3:09 AM Christian König
wrote:
>
> Am 16.11.21 um 09:00 schrieb Lang Yu:
> > On Tue, Nov 16, 2021 at 08:14:08AM +0100, Christian KKKnig wrote:
> >> Am 16.11.21 um 04:27 schrieb Lang Yu:
> >>> On Mon, Nov 15, 2021 at 01:04:15PM +0100, Michel DDDnzer wrote:
> [SNIP]
> >>
Am 16.11.21 um 09:00 schrieb Lang Yu:
On Tue, Nov 16, 2021 at 08:14:08AM +0100, Christian KKKnig wrote:
Am 16.11.21 um 04:27 schrieb Lang Yu:
On Mon, Nov 15, 2021 at 01:04:15PM +0100, Michel DDDnzer wrote:
[SNIP]
Though a single call to dce_v*_0_crtc_do_set_base() will
only pin the BO, I foun
On Tue, Nov 16, 2021 at 08:14:08AM +0100, Christian KKKnig wrote:
> Am 16.11.21 um 04:27 schrieb Lang Yu:
> > On Mon, Nov 15, 2021 at 01:04:15PM +0100, Michel DDDnzer wrote:
> > > [SNIP]
> > > > Though a single call to dce_v*_0_crtc_do_set_base() will
> > > > only pin the BO, I found it will be unp
Am 16.11.21 um 04:27 schrieb Lang Yu:
On Mon, Nov 15, 2021 at 01:04:15PM +0100, Michel DDDnzer wrote:
[SNIP]
Though a single call to dce_v*_0_crtc_do_set_base() will
only pin the BO, I found it will be unpinned in next call to
dce_v*_0_crtc_do_set_base().
Yeah, that's the normal case when the
On 2021-11-15 12:31, Lang Yu wrote:
> On Mon, Nov 15, 2021 at 10:49:39AM +0100, Michel DDDnzer wrote:
>> On 2021-11-15 10:04, Lang Yu wrote:
>>> On Mon, Nov 15, 2021 at 09:38:47AM +0100, Michel DDDnzer wrote:
On 2021-11-15 07:41, Lang Yu wrote:
> On Fri, Nov 12, 2021 at 05:10:27PM +0100, M
On 2021-11-15 10:04, Lang Yu wrote:
> On Mon, Nov 15, 2021 at 09:38:47AM +0100, Michel DDDnzer wrote:
>> On 2021-11-15 07:41, Lang Yu wrote:
>>> On Fri, Nov 12, 2021 at 05:10:27PM +0100, Michel DDDnzer wrote:
On 2021-11-12 16:03, Christian König wrote:
> Am 12.11.21 um 15:30 schrieb Michel
On 2021-11-15 07:41, Lang Yu wrote:
> On Fri, Nov 12, 2021 at 05:10:27PM +0100, Michel DDDnzer wrote:
>> On 2021-11-12 16:03, Christian König wrote:
>>> Am 12.11.21 um 15:30 schrieb Michel Dänzer:
On 2021-11-12 15:29, Michel Dänzer wrote:
> On 2021-11-12 13:47, Christian König wrote:
>
Am 12.11.21 um 17:10 schrieb Michel Dänzer:
On 2021-11-12 16:03, Christian König wrote:
Am 12.11.21 um 15:30 schrieb Michel Dänzer:
On 2021-11-12 15:29, Michel Dänzer wrote:
On 2021-11-12 13:47, Christian König wrote:
Anyway this unfortunately turned out to be work for Harray and Nicholas. In
On 2021-11-12 16:03, Christian König wrote:
> Am 12.11.21 um 15:30 schrieb Michel Dänzer:
>> On 2021-11-12 15:29, Michel Dänzer wrote:
>>> On 2021-11-12 13:47, Christian König wrote:
Anyway this unfortunately turned out to be work for Harray and Nicholas.
In detail it's about this bug re
Am 12.11.21 um 15:30 schrieb Michel Dänzer:
On 2021-11-12 15:29, Michel Dänzer wrote:
On 2021-11-12 13:47, Christian König wrote:
Anyway this unfortunately turned out to be work for Harray and Nicholas. In
detail it's about this bug report here:
https://bugzilla.kernel.org/show_bug.cgi?id=
On 2021-11-12 15:29, Michel Dänzer wrote:
> On 2021-11-12 13:47, Christian König wrote:
>>
>> Anyway this unfortunately turned out to be work for Harray and Nicholas. In
>> detail it's about this bug report here:
>> https://bugzilla.kernel.org/show_bug.cgi?id=214621
>>
>> Lang was able to reprodu
On 2021-11-12 13:47, Christian König wrote:
>
> Anyway this unfortunately turned out to be work for Harray and Nicholas. In
> detail it's about this bug report here:
> https://bugzilla.kernel.org/show_bug.cgi?id=214621
>
> Lang was able to reproduce the issue and narrow it down to the pin in
>
Hi guys,
Am 10.11.21 um 14:26 schrieb Daniel Vetter:
[SNIP]
stack depot, not stuff it into a string. stack depot is a lot more
efficient and capturing backtraces, since it de-dupes and hashes and all
you need is a pointer iirc. linux/stackdepot.h for interface, I think we
recently gained a few m
On Wed, Nov 10, 2021 at 11:18:02AM +0100, Christian König wrote:
> Am 08.11.21 um 15:59 schrieb Daniel Vetter:
> > On Mon, Nov 08, 2021 at 08:44:24AM +0100, Christian König wrote:
> > > Am 05.11.21 um 19:13 schrieb Daniel Vetter:
> > > > On Thu, Nov 04, 2021 at 12:44:34PM -0400, Harry Wentland wrot
Am 08.11.21 um 15:59 schrieb Daniel Vetter:
On Mon, Nov 08, 2021 at 08:44:24AM +0100, Christian König wrote:
Am 05.11.21 um 19:13 schrieb Daniel Vetter:
On Thu, Nov 04, 2021 at 12:44:34PM -0400, Harry Wentland wrote:
+Nick
It looks to be the old drm_plane_state->fb holds that reference. See
On Mon, Nov 08, 2021 at 08:44:24AM +0100, Christian König wrote:
> Am 05.11.21 um 19:13 schrieb Daniel Vetter:
> > On Thu, Nov 04, 2021 at 12:44:34PM -0400, Harry Wentland wrote:
> > > +Nick
> > >
> > > It looks to be the old drm_plane_state->fb holds that reference. See
> > > dm_plane_helper_cle
Am 05.11.21 um 19:13 schrieb Daniel Vetter:
On Thu, Nov 04, 2021 at 12:44:34PM -0400, Harry Wentland wrote:
+Nick
It looks to be the old drm_plane_state->fb holds that reference. See
dm_plane_helper_cleanup_fb() in amdgpu_dm.c.
Yup plane state holds reference for its entire existing (well
On Thu, Nov 04, 2021 at 12:44:34PM -0400, Harry Wentland wrote:
> +Nick
>
> It looks to be the old drm_plane_state->fb holds that reference. See
> dm_plane_helper_cleanup_fb() in amdgpu_dm.c.
Yup plane state holds reference for its entire existing (well this holds
in general as design principle
On Thu, Nov 04, 2021 at 12:44:34PM -0400, Harry Wentland wrote:
> +Nick
>
> It looks to be the old drm_plane_state->fb holds that reference. See
> dm_plane_helper_cleanup_fb() in amdgpu_dm.c.
BTW looks like you have a possible leak during fb init;
amdgpu_display_framebuffer_init() grabs the refs
+Nick
It looks to be the old drm_plane_state->fb holds that reference. See
dm_plane_helper_cleanup_fb() in amdgpu_dm.c.
Harry
On 2021-11-04 08:51, Christian König wrote:
> Hi guys,
>
> adding the usual suspects which might know that of hand: When we do a KMS
> page flip, who keeps the referen
Hi guys,
adding the usual suspects which might know that of hand: When we do a
KMS page flip, who keeps the reference to the BO while it is scanned out?
We are running into warning backtraces from TTM which look more than odd.
Thanks,
Christian.
22 matches
Mail list logo