Re: [PATCH] drm/amd/display: don't print messages that contain %f in dml

[Rodrigo Siqueira]

On 10/24/22 06:04, Christian König wrote:
> Am 21.10.22 um 18:34 schrieb Hamza Mahfooz:
> > Unfortunately, printk() doesn't currently support the printing of %f
> > entries. So, print statements that contain "%f" should be removed.
> > However, since DC is used on other OSes that can still benefit from the
> > additional debugging information, we should instead remove the
> > problematic print statements at compile time.
> >
> > Reported-by: Jim Cromie <jim.cromie@xxxxxxxxx>
> > Signed-off-by: Hamza Mahfooz <hamza.mahfooz@xxxxxxx>
> > ---
> >   drivers/gpu/drm/amd/display/include/logger_types.h | 11 +++++++++--
> >   1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/include/logger_types.h 
> > b/drivers/gpu/drm/amd/display/include/logger_types.h
> > index 3bf08a60c45c..f80630adb5f0 100644
> > --- a/drivers/gpu/drm/amd/display/include/logger_types.h
> > +++ b/drivers/gpu/drm/amd/display/include/logger_types.h
> > @@ -30,6 +30,12 @@
> >   #define MAX_NAME_LEN 32
> > +#define __DC_LOG_IGNORE_FLOATS(fmt, args...)    \
> > +do {                        \
> > +    if (!strstr((fmt), "%f"))        \
> > +        pr_debug(fmt, ##args);        \
> > +} while (0)
>
> This is absolutely not sufficient.
>
> Linux drivers must be made for Linux, see the documentation about 
> porting drivers.
>
> So just disabling the debug messages won't work in this case. Either 
> completely remove or properly fix them.

Hi Christian,

We have been discussing and working on better solutions for dealing with 
 FPU code, and we have recently improved a lot in this area (e.g., we 
are isolating all FPU codes inside DML). However, we still have many 
other challenges, and improving the FPU support in the kernel is on our 
radar.

I know this patch does not represent the best solution for this problem 
yet, but it is one step to enable us to keep refining our FPU support 
while keeping all other ASICs working well. I see this patch as an ok 
trade-off to address some of the issues that we have now while enabling 
us to improve other areas.

Thanks
Siqueira

> Regards,
> Christian.
>
>
> > +
> >   #define DC_LOG_ERROR(...) DRM_ERROR(__VA_ARGS__)
> >   #define DC_LOG_WARNING(...) DRM_WARN(__VA_ARGS__)
> >   #define DC_LOG_DEBUG(...) DRM_DEBUG_KMS(__VA_ARGS__)
> > @@ -48,7 +54,8 @@
> >   #define DC_LOG_MST(...) DRM_DEBUG_KMS(__VA_ARGS__)
> >   #define DC_LOG_SCALER(...) pr_debug("[SCALER]:"__VA_ARGS__)
> >   #define DC_LOG_BIOS(...) pr_debug("[BIOS]:"__VA_ARGS__)
> > -#define DC_LOG_BANDWIDTH_CALCS(...) 
> > pr_debug("[BANDWIDTH_CALCS]:"__VA_ARGS__)
> > +#define DC_LOG_BANDWIDTH_CALCS(args...) \
> > +    __DC_LOG_IGNORE_FLOATS("[BANDWIDTH_CALCS]:" args)
> >   #define DC_LOG_BANDWIDTH_VALIDATION(...) DRM_DEBUG_KMS(__VA_ARGS__)
> >   #define DC_LOG_I2C_AUX(...) DRM_DEBUG_KMS(__VA_ARGS__)
> >   #define DC_LOG_SYNC(...) DRM_DEBUG_KMS(__VA_ARGS__)
> > @@ -57,7 +64,7 @@
> >   #define DC_LOG_DETECTION_EDID_PARSER(...) DRM_DEBUG_KMS(__VA_ARGS__)
> >   #define DC_LOG_DETECTION_DP_CAPS(...) DRM_DEBUG_KMS(__VA_ARGS__)
> >   #define DC_LOG_RESOURCE(...) DRM_DEBUG_KMS(__VA_ARGS__)
> > -#define DC_LOG_DML(...) pr_debug("[DML]:"__VA_ARGS__)
> > +#define DC_LOG_DML(args...) __DC_LOG_IGNORE_FLOATS("[DML]:" args)
> >   #define DC_LOG_EVENT_MODE_SET(...) DRM_DEBUG_KMS(__VA_ARGS__)
> >   #define DC_LOG_EVENT_DETECTION(...) DRM_DEBUG_KMS(__VA_ARGS__)
> >   #define DC_LOG_EVENT_LINK_TRAINING(...) DRM_DEBUG_KMS(__VA_ARGS__)