The downstream code from which this was derived didn't ever run through
this 'switch' block with non-AFBC formats, but the upstream code does --
we use this function to probe whether a given format is supported.
Demote the warning to eliminate this sort of warning seen on every
boot:
[drm] unsupported AFBC format[3231564e]
And make it warn more than once, because if we *actually* care to see
what formats we're probing/rejecting and for what reasons, we probably
care about more than just the first message.
Drop the comment, because one of the two *is* commonly reachable.
And lastly, drop the unreachable return; we'd do better to let the
compiler complain if we start hitting this unexpectedly.
Signed-off-by: Brian Norris <[email protected]>
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index fa1f4ee6d195..aab77eb6caa3 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -316,13 +316,10 @@ static int vop_convert_afbc_format(uint32_t format)
case DRM_FORMAT_RGB565:
case DRM_FORMAT_BGR565:
return AFBC_FMT_RGB565;
- /* either of the below should not be reachable */
default:
- DRM_WARN_ONCE("unsupported AFBC format[%08x]\n", format);
+ DRM_DEBUG_KMS("unsupported AFBC format[%08x]\n", format);
return -EINVAL;
}
-
- return -EINVAL;
}
static uint16_t scl_vop_cal_scale(enum scale_mode mode, uint32_t src,
--
2.38.1.273.g43a17bfeac-goog
On Mon, 31 Oct 2022 10:16:01 -0700, Brian Norris wrote:
> The downstream code from which this was derived didn't ever run through
> this 'switch' block with non-AFBC formats, but the upstream code does --
> we use this function to probe whether a given format is supported.
>
> Demote the warning to eliminate this sort of warning seen on every
> boot:
>
> [...]
Applied, thanks!
[1/1] drm/rockchip: vop: Quiet always-warning AFBC log
commit: 582212ee1611f77e0360d249f11c0f703ed723dc
Best regards,
--
Heiko Stuebner <[email protected]>