All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com>
To: daniel@ffwll.ch
Cc: Leo Li <sunpeng.li@amd.com>,
	Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>,
	dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 7/7] drm/amd/display: Replace DRM private objects with subclassed DRM atomic state
Date: Fri, 7 Aug 2020 10:32:11 -0400	[thread overview]
Message-ID: <88c15278-9510-c7b9-76ff-62d425d721ed@amd.com> (raw)
In-Reply-To: <20200807085214.GP6419@phenom.ffwll.local>

On 2020-08-07 4:52 a.m., daniel@ffwll.ch wrote:
> On Thu, Jul 30, 2020 at 04:36:42PM -0400, Nicholas Kazlauskas wrote:
>> @@ -440,7 +431,7 @@ struct dm_crtc_state {
>>   #define to_dm_crtc_state(x) container_of(x, struct dm_crtc_state, base)
>>   
>>   struct dm_atomic_state {
>> -	struct drm_private_state base;
>> +	struct drm_atomic_state base;
>>   
>>   	struct dc_state *context;
> 
> Also curiosity: Can't we just embed dc_state here, instead of a pointer?
> Then it would become a lot more obvious that mostly this is a state object
> container like drm_atomic_state, but for the DC specific state structures.
> And we could look into moving the actual DC states into drm private states
> perhaps (if that helps with the code structure and overall flow).
> 
> Maybe as next steps.
> -Daniel
> 

It's the refcounting that's the problem with this stuff. I'd like to 
move DC to a model where we have no memory allocation/ownership but that 
might be a bit of a more long term plan at this point.

Same with dc_plane_state and dc_stream_state as well - these could exist 
on the DRM objects as long as they're not refcounted.

Regards,
Nicholas Kazlauskas
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com>
To: daniel@ffwll.ch
Cc: Leo Li <sunpeng.li@amd.com>,
	Harry Wentland <harry.wentland@amd.com>,
	Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>,
	dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 7/7] drm/amd/display: Replace DRM private objects with subclassed DRM atomic state
Date: Fri, 7 Aug 2020 10:32:11 -0400	[thread overview]
Message-ID: <88c15278-9510-c7b9-76ff-62d425d721ed@amd.com> (raw)
In-Reply-To: <20200807085214.GP6419@phenom.ffwll.local>

On 2020-08-07 4:52 a.m., daniel@ffwll.ch wrote:
> On Thu, Jul 30, 2020 at 04:36:42PM -0400, Nicholas Kazlauskas wrote:
>> @@ -440,7 +431,7 @@ struct dm_crtc_state {
>>   #define to_dm_crtc_state(x) container_of(x, struct dm_crtc_state, base)
>>   
>>   struct dm_atomic_state {
>> -	struct drm_private_state base;
>> +	struct drm_atomic_state base;
>>   
>>   	struct dc_state *context;
> 
> Also curiosity: Can't we just embed dc_state here, instead of a pointer?
> Then it would become a lot more obvious that mostly this is a state object
> container like drm_atomic_state, but for the DC specific state structures.
> And we could look into moving the actual DC states into drm private states
> perhaps (if that helps with the code structure and overall flow).
> 
> Maybe as next steps.
> -Daniel
> 

It's the refcounting that's the problem with this stuff. I'd like to 
move DC to a model where we have no memory allocation/ownership but that 
might be a bit of a more long term plan at this point.

Same with dc_plane_state and dc_stream_state as well - these could exist 
on the DRM objects as long as they're not refcounted.

Regards,
Nicholas Kazlauskas
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

  reply	other threads:[~2020-08-07 14:32 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-30 20:36 [PATCH 0/7] drm/amd/display: Drop DRM private objects from amdgpu_dm Nicholas Kazlauskas
2020-07-30 20:36 ` Nicholas Kazlauskas
2020-07-30 20:36 ` [PATCH 1/7] drm/amd/display: Store tiling_flags and tmz_surface on dm_plane_state Nicholas Kazlauskas
2020-07-30 20:36   ` Nicholas Kazlauskas
2020-08-05 21:04   ` Rodrigo Siqueira
2020-08-05 21:04     ` Rodrigo Siqueira
2020-08-07  8:24   ` daniel
2020-08-07  8:24     ` daniel
2020-07-30 20:36 ` [PATCH 2/7] drm/amd/display: Reset plane when tiling flags change Nicholas Kazlauskas
2020-07-30 20:36   ` Nicholas Kazlauskas
2020-07-30 20:50   ` Wu, Hersen
2020-07-30 20:50     ` Wu, Hersen
2020-08-05 21:11   ` Rodrigo Siqueira
2020-08-05 21:11     ` Rodrigo Siqueira
2020-08-06 18:18     ` Kazlauskas, Nicholas
2020-08-06 18:18       ` Kazlauskas, Nicholas
2020-07-30 20:36 ` [PATCH 3/7] drm/amd/display: Avoid using unvalidated tiling_flags and tmz_surface in prepare_planes Nicholas Kazlauskas
2020-07-30 20:36   ` Nicholas Kazlauskas
2020-08-05 21:12   ` Rodrigo Siqueira
2020-08-05 21:12     ` Rodrigo Siqueira
2020-08-07  8:30   ` daniel
2020-08-07  8:30     ` daniel
2020-08-07 14:29     ` Kazlauskas, Nicholas
2020-08-07 14:29       ` Kazlauskas, Nicholas
2020-08-10 12:25       ` Daniel Vetter
2020-08-10 12:25         ` Daniel Vetter
2020-08-10 12:30         ` Christian König
2020-08-10 12:30           ` Christian König
2020-08-10 12:32           ` Daniel Vetter
2020-08-10 12:32             ` Daniel Vetter
2020-08-11 13:42           ` Marek Olšák
2020-08-11 13:42             ` Marek Olšák
2020-08-12 13:54             ` Daniel Vetter
2020-08-12 13:54               ` Daniel Vetter
2020-08-17  6:23               ` Marek Olšák
2020-08-17  6:23                 ` Marek Olšák
2020-09-01  7:20                 ` Daniel Vetter
2020-09-01  7:20                   ` Daniel Vetter
2020-07-30 20:36 ` [PATCH 4/7] drm/amd/display: Use validated tiling_flags and tmz_surface in commit_tail Nicholas Kazlauskas
2020-07-30 20:36   ` Nicholas Kazlauskas
2020-08-05 21:15   ` Rodrigo Siqueira
2020-08-05 21:15     ` Rodrigo Siqueira
2020-07-30 20:36 ` [PATCH 5/7] drm/amd/display: Reset plane for anything that's not a FAST update Nicholas Kazlauskas
2020-07-30 20:36   ` Nicholas Kazlauskas
2020-07-30 20:51   ` Wu, Hersen
2020-07-30 20:51     ` Wu, Hersen
2020-08-05 20:45   ` Rodrigo Siqueira
2020-08-05 20:45     ` Rodrigo Siqueira
2020-08-06 18:27     ` Kazlauskas, Nicholas
2020-08-06 18:27       ` Kazlauskas, Nicholas
2020-08-07  8:34   ` daniel
2020-08-07  8:34     ` daniel
2020-08-07 14:26     ` Kazlauskas, Nicholas
2020-08-07 14:26       ` Kazlauskas, Nicholas
2020-08-10 12:30       ` Daniel Vetter
2020-08-10 12:30         ` Daniel Vetter
2020-07-30 20:36 ` [PATCH 6/7] drm/amd/display: Drop dm_determine_update_type_for_commit Nicholas Kazlauskas
2020-07-30 20:36   ` Nicholas Kazlauskas
2020-08-05 20:48   ` Rodrigo Siqueira
2020-08-05 20:48     ` Rodrigo Siqueira
2020-07-30 20:36 ` [PATCH 7/7] drm/amd/display: Replace DRM private objects with subclassed DRM atomic state Nicholas Kazlauskas
2020-07-30 20:36   ` Nicholas Kazlauskas
2020-08-05 20:37   ` Rodrigo Siqueira
2020-08-05 20:37     ` Rodrigo Siqueira
2020-08-06 14:25     ` Kazlauskas, Nicholas
2020-08-06 14:25       ` Kazlauskas, Nicholas
2020-08-07  8:40   ` daniel
2020-08-07  8:40     ` daniel
2020-08-07  8:52   ` daniel
2020-08-07  8:52     ` daniel
2020-08-07 14:32     ` Kazlauskas, Nicholas [this message]
2020-08-07 14:32       ` Kazlauskas, Nicholas
2020-08-10 12:34       ` Daniel Vetter
2020-08-10 12:34         ` Daniel Vetter
2020-08-07  8:29 ` [PATCH 0/7] drm/amd/display: Drop DRM private objects from amdgpu_dm daniel
2020-08-07  8:29   ` daniel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=88c15278-9510-c7b9-76ff-62d425d721ed@amd.com \
    --to=nicholas.kazlauskas@amd.com \
    --cc=Bhawanpreet.Lakha@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=sunpeng.li@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.