All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <ckoenig.leichtzumerken@gmail.com>
To: "Melissa Wen" <mwen@igalia.com>,
	"Christian König" <christian.koenig@amd.com>
Cc: sunpeng.li@amd.com, Qingqing Zhuo <qingqing.zhuo@amd.com>,
	Xinhui.Pan@amd.com, Rodrigo.Siqueira@amd.com,
	linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org,
	airlied@linux.ie, Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>,
	dri-devel@lists.freedesktop.org, daniel@ffwll.ch,
	Jasdeep Dhillon <jdhillon@amd.com>,
	alexander.deucher@amd.com, harry.wentland@amd.com
Subject: Re: [PATCH 1/2] drm/amd/display: detach fpu operations from dcn10_validate_bandwidth in calcs
Date: Mon, 28 Mar 2022 19:46:26 +0200	[thread overview]
Message-ID: <426855bc-9480-ad47-c362-f2a73c0c8ce9@gmail.com> (raw)
In-Reply-To: <20220328171738.iu5peqfcled2psv3@mail.igalia.com>

Am 28.03.22 um 19:17 schrieb Melissa Wen:
> On 03/28, Christian König wrote:
>> Am 26.03.22 um 21:24 schrieb Melissa Wen:
>>> dcn10_validate_bandwidth is only used on dcn10 files, but is declared in
>>> dcn_calcs files. Rename dcn10_* to dcn_* in calcs, remove DC_FP_* wrapper
>>> inside DML folder and create an specific dcn10_validate_bandwidth in
>>> dcn10_resources that calls dcn_validate_bandwidth and properly wraps that
>>> FPU function with DC_FP_* macro.
>>>
>>> Signed-off-by: Melissa Wen <mwen@igalia.com>
>>> ---
>>>    .../gpu/drm/amd/display/dc/dcn10/dcn10_resource.c  | 14 ++++++++++++++
>>>    .../gpu/drm/amd/display/dc/dml/calcs/dcn_calcs.c   |  5 +----
>>>    drivers/gpu/drm/amd/display/dc/inc/dcn_calcs.h     |  2 +-
>>>    3 files changed, 16 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
>>> index 4048908dd265..1587a060b55a 100644
>>> --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
>>> +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
>>> @@ -1141,6 +1141,20 @@ static void dcn10_destroy_resource_pool(struct resource_pool **pool)
>>>    	*pool = NULL;
>>>    }
>>> +static bool dcn10_validate_bandwidth(
>>> +		struct dc *dc,
>>> +		struct dc_state *context,
>>> +		bool fast_validate)
>>> +{
>>> +	bool voltage_supported;
>>> +
>>> +	DC_FP_START();
>>> +	voltage_supported = dcn_validate_bandwidth(dc, context, fast_validate);
>>> +	DC_FP_END();
>>> +
>>> +	return voltage_supported;
>>> +}
>>> +
>>>    static enum dc_status dcn10_validate_plane(const struct dc_plane_state *plane_state, struct dc_caps *caps)
>>>    {
>>>    	if (plane_state->format >= SURFACE_PIXEL_FORMAT_VIDEO_BEGIN
>>> diff --git a/drivers/gpu/drm/amd/display/dc/dml/calcs/dcn_calcs.c b/drivers/gpu/drm/amd/display/dc/dml/calcs/dcn_calcs.c
>>> index e447c74be713..c25023f7d604 100644
>>> --- a/drivers/gpu/drm/amd/display/dc/dml/calcs/dcn_calcs.c
>>> +++ b/drivers/gpu/drm/amd/display/dc/dml/calcs/dcn_calcs.c
>>> @@ -764,7 +764,7 @@ static unsigned int get_highest_allowed_voltage_level(uint32_t chip_family,
>>>    	return 4;
>>>    }
>>> -bool dcn10_validate_bandwidth(
>>> +bool dcn_validate_bandwidth(
>>>    		struct dc *dc,
>>>    		struct dc_state *context,
>>>    		bool fast_validate)
>>> @@ -790,7 +790,6 @@ bool dcn10_validate_bandwidth(
>>>    		dcn_bw_sync_calcs_and_dml(dc);
>>>    	memset(v, 0, sizeof(*v));
>>> -	DC_FP_START();
>>>    	v->sr_exit_time = dc->dcn_soc->sr_exit_time;
>>>    	v->sr_enter_plus_exit_time = dc->dcn_soc->sr_enter_plus_exit_time;
>>> @@ -1323,8 +1322,6 @@ bool dcn10_validate_bandwidth(
>>>    	bw_limit = dc->dcn_soc->percent_disp_bw_limit * v->fabric_and_dram_bandwidth_vmax0p9;
>>>    	bw_limit_pass = (v->total_data_read_bandwidth / 1000.0) < bw_limit;
>>> -	DC_FP_END();
>>> -
>>>    	PERFORMANCE_TRACE_END();
>>>    	BW_VAL_TRACE_FINISH();
>>> diff --git a/drivers/gpu/drm/amd/display/dc/inc/dcn_calcs.h b/drivers/gpu/drm/amd/display/dc/inc/dcn_calcs.h
>>> index 337c0161e72d..806f3041db14 100644
>>> --- a/drivers/gpu/drm/amd/display/dc/inc/dcn_calcs.h
>>> +++ b/drivers/gpu/drm/amd/display/dc/inc/dcn_calcs.h
>>> @@ -619,7 +619,7 @@ struct dcn_ip_params {
>>>    };
>>>    extern const struct dcn_ip_params dcn10_ip_defaults;
>>> -bool dcn10_validate_bandwidth(
>>> +bool dcn_validate_bandwidth(
>>>    		struct dc *dc,
>>>    		struct dc_state *context,
>>>    		bool fast_validate);
>> Just for the record: That's not really usual kernel coding style, but that's
>> not topic of this patch set.
> Yeah. I didn't change the code style to ease any version conflict management.
>> The series is Acked-by: Christian König <christian.koenig@amd.com>
> Thanks!
>> And it would be really nice if we could make the DC_FP_* macros somehow fail
>> in the dml folder.
> And if we include a kind of dc_assert_fp_disabled() in the dc_fpu_begin()
> (DC_FP_START) - more or less the reverse of dc_assert_fp_enabled(). Does
> it meet the `make the DC_FP_* macros somehow fail in the dml folder` ?
> It is not restricted to the dml folder, but I think it would work
> similarly... Does it make sense?

No, IIRC our display team even mentioned to me that those macros could 
potentially be used recursively.

What I mean here is that we somehow raise a compiler warning if somebody 
tries to use those defines inside the folder.

Maybe check of gcc supports hardware floating point or something like this.

Christian.

>
> Melissa
>
>> Thanks,
>> Christian.
>>
>>


WARNING: multiple messages have this Message-ID (diff)
From: "Christian König" <ckoenig.leichtzumerken@gmail.com>
To: "Melissa Wen" <mwen@igalia.com>,
	"Christian König" <christian.koenig@amd.com>
Cc: sunpeng.li@amd.com, Qingqing Zhuo <qingqing.zhuo@amd.com>,
	Xinhui.Pan@amd.com, Rodrigo.Siqueira@amd.com,
	linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org,
	airlied@linux.ie, Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>,
	dri-devel@lists.freedesktop.org,
	Jasdeep Dhillon <jdhillon@amd.com>,
	alexander.deucher@amd.com
Subject: Re: [PATCH 1/2] drm/amd/display: detach fpu operations from dcn10_validate_bandwidth in calcs
Date: Mon, 28 Mar 2022 19:46:26 +0200	[thread overview]
Message-ID: <426855bc-9480-ad47-c362-f2a73c0c8ce9@gmail.com> (raw)
In-Reply-To: <20220328171738.iu5peqfcled2psv3@mail.igalia.com>

Am 28.03.22 um 19:17 schrieb Melissa Wen:
> On 03/28, Christian König wrote:
>> Am 26.03.22 um 21:24 schrieb Melissa Wen:
>>> dcn10_validate_bandwidth is only used on dcn10 files, but is declared in
>>> dcn_calcs files. Rename dcn10_* to dcn_* in calcs, remove DC_FP_* wrapper
>>> inside DML folder and create an specific dcn10_validate_bandwidth in
>>> dcn10_resources that calls dcn_validate_bandwidth and properly wraps that
>>> FPU function with DC_FP_* macro.
>>>
>>> Signed-off-by: Melissa Wen <mwen@igalia.com>
>>> ---
>>>    .../gpu/drm/amd/display/dc/dcn10/dcn10_resource.c  | 14 ++++++++++++++
>>>    .../gpu/drm/amd/display/dc/dml/calcs/dcn_calcs.c   |  5 +----
>>>    drivers/gpu/drm/amd/display/dc/inc/dcn_calcs.h     |  2 +-
>>>    3 files changed, 16 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
>>> index 4048908dd265..1587a060b55a 100644
>>> --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
>>> +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
>>> @@ -1141,6 +1141,20 @@ static void dcn10_destroy_resource_pool(struct resource_pool **pool)
>>>    	*pool = NULL;
>>>    }
>>> +static bool dcn10_validate_bandwidth(
>>> +		struct dc *dc,
>>> +		struct dc_state *context,
>>> +		bool fast_validate)
>>> +{
>>> +	bool voltage_supported;
>>> +
>>> +	DC_FP_START();
>>> +	voltage_supported = dcn_validate_bandwidth(dc, context, fast_validate);
>>> +	DC_FP_END();
>>> +
>>> +	return voltage_supported;
>>> +}
>>> +
>>>    static enum dc_status dcn10_validate_plane(const struct dc_plane_state *plane_state, struct dc_caps *caps)
>>>    {
>>>    	if (plane_state->format >= SURFACE_PIXEL_FORMAT_VIDEO_BEGIN
>>> diff --git a/drivers/gpu/drm/amd/display/dc/dml/calcs/dcn_calcs.c b/drivers/gpu/drm/amd/display/dc/dml/calcs/dcn_calcs.c
>>> index e447c74be713..c25023f7d604 100644
>>> --- a/drivers/gpu/drm/amd/display/dc/dml/calcs/dcn_calcs.c
>>> +++ b/drivers/gpu/drm/amd/display/dc/dml/calcs/dcn_calcs.c
>>> @@ -764,7 +764,7 @@ static unsigned int get_highest_allowed_voltage_level(uint32_t chip_family,
>>>    	return 4;
>>>    }
>>> -bool dcn10_validate_bandwidth(
>>> +bool dcn_validate_bandwidth(
>>>    		struct dc *dc,
>>>    		struct dc_state *context,
>>>    		bool fast_validate)
>>> @@ -790,7 +790,6 @@ bool dcn10_validate_bandwidth(
>>>    		dcn_bw_sync_calcs_and_dml(dc);
>>>    	memset(v, 0, sizeof(*v));
>>> -	DC_FP_START();
>>>    	v->sr_exit_time = dc->dcn_soc->sr_exit_time;
>>>    	v->sr_enter_plus_exit_time = dc->dcn_soc->sr_enter_plus_exit_time;
>>> @@ -1323,8 +1322,6 @@ bool dcn10_validate_bandwidth(
>>>    	bw_limit = dc->dcn_soc->percent_disp_bw_limit * v->fabric_and_dram_bandwidth_vmax0p9;
>>>    	bw_limit_pass = (v->total_data_read_bandwidth / 1000.0) < bw_limit;
>>> -	DC_FP_END();
>>> -
>>>    	PERFORMANCE_TRACE_END();
>>>    	BW_VAL_TRACE_FINISH();
>>> diff --git a/drivers/gpu/drm/amd/display/dc/inc/dcn_calcs.h b/drivers/gpu/drm/amd/display/dc/inc/dcn_calcs.h
>>> index 337c0161e72d..806f3041db14 100644
>>> --- a/drivers/gpu/drm/amd/display/dc/inc/dcn_calcs.h
>>> +++ b/drivers/gpu/drm/amd/display/dc/inc/dcn_calcs.h
>>> @@ -619,7 +619,7 @@ struct dcn_ip_params {
>>>    };
>>>    extern const struct dcn_ip_params dcn10_ip_defaults;
>>> -bool dcn10_validate_bandwidth(
>>> +bool dcn_validate_bandwidth(
>>>    		struct dc *dc,
>>>    		struct dc_state *context,
>>>    		bool fast_validate);
>> Just for the record: That's not really usual kernel coding style, but that's
>> not topic of this patch set.
> Yeah. I didn't change the code style to ease any version conflict management.
>> The series is Acked-by: Christian König <christian.koenig@amd.com>
> Thanks!
>> And it would be really nice if we could make the DC_FP_* macros somehow fail
>> in the dml folder.
> And if we include a kind of dc_assert_fp_disabled() in the dc_fpu_begin()
> (DC_FP_START) - more or less the reverse of dc_assert_fp_enabled(). Does
> it meet the `make the DC_FP_* macros somehow fail in the dml folder` ?
> It is not restricted to the dml folder, but I think it would work
> similarly... Does it make sense?

No, IIRC our display team even mentioned to me that those macros could 
potentially be used recursively.

What I mean here is that we somehow raise a compiler warning if somebody 
tries to use those defines inside the folder.

Maybe check of gcc supports hardware floating point or something like this.

Christian.

>
> Melissa
>
>> Thanks,
>> Christian.
>>
>>


  reply	other threads:[~2022-03-28 17:46 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-26 20:24 [PATCH 0/2] remove DC_FP_* wrappers in dml files Melissa Wen
2022-03-26 20:24 ` Melissa Wen
2022-03-26 20:24 ` [PATCH 1/2] drm/amd/display: detach fpu operations from dcn10_validate_bandwidth in calcs Melissa Wen
2022-03-26 20:24   ` Melissa Wen
2022-03-28  6:55   ` Christian König
2022-03-28  6:55     ` Christian König
2022-03-28 17:17     ` Melissa Wen
2022-03-28 17:17       ` Melissa Wen
2022-03-28 17:17       ` Melissa Wen
2022-03-28 17:46       ` Christian König [this message]
2022-03-28 17:46         ` Christian König
2022-03-26 20:24 ` [PATCH 2/2] drm/amd/display: remove DC_FP_* wrapper from dml folder Melissa Wen
2022-03-26 20:24   ` Melissa Wen
2022-03-30 12:41 ` [PATCH 0/2] remove DC_FP_* wrappers in dml files Rodrigo Siqueira Jordao
2022-03-30 12:41   ` Rodrigo Siqueira Jordao
2022-03-30 14:15   ` Melissa Wen
2022-03-30 14:15     ` Melissa Wen
2022-03-30 14:15     ` Melissa Wen

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=426855bc-9480-ad47-c362-f2a73c0c8ce9@gmail.com \
    --to=ckoenig.leichtzumerken@gmail.com \
    --cc=Dmytro.Laktyushkin@amd.com \
    --cc=Rodrigo.Siqueira@amd.com \
    --cc=Xinhui.Pan@amd.com \
    --cc=airlied@linux.ie \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=harry.wentland@amd.com \
    --cc=jdhillon@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mwen@igalia.com \
    --cc=qingqing.zhuo@amd.com \
    --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.