drm/vc4: Add CTM support
Subsystems (3)
PATCH v4 1/2 drm/vc4: Add CTM support
The hardware has a single block for applying a CTM prior to gamma lut. It can be fed with pixels from one of our CRTC at a time and uses a matrix with S0.9 scalars. Use private atomic state to reject attempts from userland to apply CTM for more than one CRTC at a time and reject matrices with scalars that we can't approximate without integer bits.
---
Eric, I removed your r-b since there were a bunch more changes.
v4: Handle CTM disabling in check
Don't use drm_atomic_get_private_obj_state in commit Fix S31.32 -> S0.9 conversion
Squashed in Erics fixup series:
Don't take the CTM lock unless a CTM change is happening (Eric) Lock across changes to the CTM (Eric)
Handle allocation failure in out CTM priv state (Eric) Move CTM object init before FBDEV setup (Eric)
Clean up the CTM private object manager on unload (Eric)
v3: New in the series.
drivers/gpu/drm/vc4/vc4_crtc.c | 5 + drivers/gpu/drm/vc4/vc4_drv.c | 3 + drivers/gpu/drm/vc4/vc4_drv.h | 4 + drivers/gpu/drm/vc4/vc4_kms.c | 204 ++++++++++++++++++++++++++++++++++++++++- 4 files changed, 215 insertions(+), 1 deletion(-)
drivers/gpu/drm/vc4/vc4_crtc.c +5 -0
@@ -1018,6 +1018,11 @@ static int vc4_crtc_bind(struct device *dev, struct device *master, void *data)drm_mode_crtc_set_gamma_size (crtc,ARRAY_SIZE (vc4_crtc->lut_r));drm_crtc_enable_color_mgmt (crtc,0 , false, crtc->gamma_size); +/* We support CTM, but only for one CRTC at a time. It's therefore +* implemented as private driver state in vc4_kms, not here. +*/ +drm_crtc_enable_color_mgmt (crtc,0 , true, crtc->gamma_size); +/* Set up some arbitrary number of planes. We're not limited * by a set number of physical registers, just the space in * the HVS (16k) and how small an plane can be (28 bytes).
drivers/gpu/drm/vc4/vc4_drv.c +3 -0
@@ -320,6 +320,7 @@ static void vc4_drm_unbind(struct device *dev) {struct platform_device *pdev =to_platform_device (dev);struct drm_device *drm =platform_get_drvdata (pdev); +struct vc4_dev *vc4 =to_vc4_dev (drm);drm_dev_unregister (drm);
@@ -327,6 +328,8 @@ static void vc4_drm_unbind(struct device *dev)drm_mode_config_cleanup (drm); +drm_atomic_private_obj_fini (&vc4->ctm_manager); +drm_dev_unref (drm); }
drivers/gpu/drm/vc4/vc4_drv.h +4 -0
@@ -10,6 +10,7 @@#include <drm/drmP.h> #include <drm/drm_encoder.h> #include <drm/drm_gem_cma_helper.h> +#include <drm/drm_atomic.h> #include "uapi/drm/vc4_drm.h"
@@ -193,6 +194,9 @@ struct vc4_dev { } hangcheck;struct semaphore async_modeset; + +struct drm_modeset_lock ctm_state_lock; +struct drm_private_obj ctm_manager; }; static inline struct vc4_dev *
drivers/gpu/drm/vc4/vc4_kms.c +203 -1
236 lines not on this page · raw message
Signature · 6 lines
2.14.1 _______________________________________________ dri-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dri-devel
PATCH v4 2/2 drm/vc4: Add CTM registers to debugfs
Now that we set the OLED* registers to do CTM, it's helpful to have them in the register dump.
---
v4: new in the series.
drivers/gpu/drm/vc4/vc4_hvs.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/gpu/drm/vc4/vc4_hvs.c +4 -0
@@ -58,6 +58,10 @@ static const struct {HVS_REG (SCALER_DISPSTAT2 ),HVS_REG (SCALER_DISPBASE2 ),HVS_REG (SCALER_DISPALPHA2 ), +HVS_REG (SCALER_OLEDOFFS ), +HVS_REG (SCALER_OLEDCOEF0 ), +HVS_REG (SCALER_OLEDCOEF1 ), + HVS_REG(SCALER_OLEDCOEF2), };void vc4_hvs_dump_state (struct drm_device *dev)
Signature · 6 lines
2.14.1 _______________________________________________ dri-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dri-devel
Quoted 5 lines · Stefan Schake
The hardware has a single block for applying a CTM prior to gamma lut. It can be fed with pixels from one of our CRTC at a time and uses a matrix with S0.9 scalars. Use private atomic state to reject attempts from userland to apply CTM for more than one CRTC at a time and reject matrices with scalars that we can't approximate without integer bits.
Looks good! I think you got all the transition cases we were concerned about before.
Reviewed and applied these two to drm-misc-next. Thanks!
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel