Hi Bryan, On Fri, May 8, 2026 at 11:19 AM Bryan O'Donoghue <[email protected]> wrote: > > On 07/05/2026 23:49, Loic Poulain wrote: > > Add the uapi header camss-config.h defining the ISP parameter > > structures used by the CAMSS Offline Processing Engine (OPE) driver. > > This includes structures for white balance, chroma enhancement and > > color correction configuration. > > > > Signed-off-by: Loic Poulain <[email protected]> > > --- > > include/uapi/linux/camss-config.h | 115 > > ++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 115 insertions(+) > > > > diff --git a/include/uapi/linux/camss-config.h > > b/include/uapi/linux/camss-config.h > > new file mode 100644 > > index > > 0000000000000000000000000000000000000000..665406969e66927e8bce83afaa9a3aae53ba2803 > > --- /dev/null > > +++ b/include/uapi/linux/camss-config.h > > @@ -0,0 +1,115 @@ > > +/* SPDX-License-Identifier: GPL-2.0-only WITH Linux-syscall-note */ > > +/* > > + * Qualcomm CAMSS ISP parameters UAPI > > + * > > + * Uses the generic V4L2 extensible ISP parameters buffer format defined in > > + * <uapi/linux/media/v4l2-isp.h>. > > + * > > + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries. > > + */ > > + > > +#ifndef _UAPI_LINUX_CAMSS_CONFIG_H > > +#define _UAPI_LINUX_CAMSS_CONFIG_H > > + > > +#include <linux/types.h> > > +#include <linux/media/v4l2-isp.h> > > +/** > > + * enum camss_params_block_type - CAMSS ISP parameter block identifiers > > + * > > + * Each value identifies one ISP processing block. The value is placed in > > + * the @type field of &struct v4l2_isp_params_block_header. > > + */ > > +enum camss_params_block_type { > > + CAMSS_PARAMS_WB_GAIN = 1, > > + CAMSS_PARAMS_CHROMA_ENHAN = 2, > > + CAMSS_PARAMS_COLOR_CORRECT = 3, > > + CAMSS_PARAMS_MAX, > > +}; > > + > > +/** > > + * struct camss_params_wb_gain - White Balance gains > > + * > > + * @header: generic block header; @header.type = CAMSS_PARAMS_WB_GAIN > > + * @g_gain: green channel gain (15uQ10) > > + * @b_gain: blue channel gain (15uQ10) > > + * @r_gain: red channel gain (15uQ10) > > + */ > > +struct camss_params_wb_gain { > > + struct v4l2_isp_params_block_header header; > > + __u16 g_gain; > > + __u16 b_gain; > > + __u16 r_gain; > > + __u16 _pad; > > +} __aligned(8); > > + > > +/** > > + * struct camss_params_chroma_enhan - RGB to YUV colour matrix > > + * > > + * Implements the CLC_CHROMA_ENHAN pipeline module. All coefficients are > > + * signed 12-bit fixed-point Q3.8 (range roughly -8.0 to +7.996). > > + * > > + * Luma (Y) row of the matrix: > > + * @luma_v0: R-to-Y coefficient (12sQ8, e.g. 0x04d = 0.299) > > + * @luma_v1: G-to-Y coefficient (12sQ8, e.g. 0x096 = 0.587) > > + * @luma_v2: B-to-Y coefficient (12sQ8, e.g. 0x01d = 0.114) > > + * @luma_k: Y output offset (9s, 0 = no offset) > > + * > > + * Chroma (Cb) row: > > + * @coeff_ap: Cb positive coefficient (12sQ8, e.g. 0x0e6 = 0.886) > > + * @coeff_am: Cb negative coefficient (12sQ8, e.g. 0xfb3 = -0.338) > > + * @kcb: Cb output offset (11s, 128 = +128) > > + * > > + * Chroma (Cr) row: > > + * @coeff_cp: Cr positive coefficient (12sQ8, e.g. 0x0b3 = 0.701) > > + * @coeff_cm: Cr negative coefficient (12sQ8, e.g. 0xfe3 = -0.114) > > + * @coeff_dp: Cr positive coefficient (12sQ8) > > + * @coeff_dm: Cr negative coefficient (12sQ8) > > + * @kcr: Cr output offset (11s, 128 = +128) > > + * > > + * @header: generic block header; @header.type = CAMSS_PARAMS_CHROMA_ENHAN > > + */ > > +struct camss_params_chroma_enhan { > > + struct v4l2_isp_params_block_header header; > > + __u16 luma_v0; > > + __u16 luma_v1; > > + __u16 luma_v2; > > + __u16 luma_k; > > + __u16 coeff_ap; > > + __u16 coeff_am; > > + __u16 coeff_cp; > > + __u16 coeff_cm; > > + __u16 coeff_dp; > > + __u16 coeff_dm; > > + __u16 kcb; > > + __u16 kcr; > > +} __aligned(8); > > + > > +/** > > + * struct camss_params_color_correct - colour correction matrix > > + * > > + * signed 12-bit fixed-point (Qm) > > + * > > + * Out_ch0 (g) = A0*G+B0*B+C0*R + K0 > > + * Out_ch1 (b) = A1*G+B1*B+C1*R + K1 > > + * Out_ch2 (r) = A2*G+B2*B+C2*R + K2 > > + * > > + * m = 0x0 - Coefficients are signed 12sQ7 numbers > > + * m = 0x1 - Coefficients are signed 12sQ8 numbers > > + * m = 0x2 - Coefficients are signed 12sQ9 numbers > > + * m = 0x3 - Coefficients are signed 12sQ10 numbers > > + */ > > +struct camss_params_color_correct { > > + struct v4l2_isp_params_block_header header; > > + __u16 a[3]; > > + __u16 b[3]; > > + __u16 c[3]; > > + __u16 k[3]; > > + __u16 m; > > +} __aligned(8); > > + > > +#define CAMSS_PARAMS_MAX_PAYLOAD \ > > + (sizeof(struct camss_params_wb_gain) +\ > > + sizeof(struct camss_params_chroma_enhan) +\ > > + sizeof(struct camss_params_color_correct)) > > + > > +#endif /* _UAPI_LINUX_CAMSS_CONFIG_H */ > > > > -- > > 2.34.1 > > > > I think this should instead be the comprehensive list from HFI I > published recently. > > There's no point in circumscribing it and HFI is way more widely > available than OPE - so if there are adaptations to be done it should be > on the OPE side not the HFI/IPE side.
Thanks a lot for pointing this out. Here’s what I plan to do in the next version, please let me know if this raises any concerns: - params_wb_gain: I will align this with your version by adding the missing fields (G/B/R offsets). On OPE, gains are expressed as 15uQ10, while the HFI uses 12uQ10. Given the wider integer range in OPE, I’m not sure the full range is actually needed. Would it be acceptable to keep the extended range even if it may not be fully used by the HFI, or should we restrict it to match the HFI limits? - camss_params_color_correct: This can be fully aligned with your proposed version. - camss_params_chroma_enhan: This corresponds to color space conversion (RGB to YUV). I don’t see an equivalent in the HFI-based proposal, so I plan to keep the current implementation, while restructuring it (e.g., using vectors/matrices) to better match the style of the other parameter blocks. Regards, Loic
