Re: [PATCH 58/74] media: uapi: Add CAMSS ISP statistics definition

[Bryan O'Donoghue <bryan.odonoghue@linaro.org>]

On 08/10/2026 12:23, Gjorgji Rosikopulos (Consultant) wrote:
>> +/* Number of bins in a Bayer histogram. */
>> +#define CAMSS_STATS_BHIST_BINS	1024
>> +
>> +/**
>> + * struct camss_stats_bhist - Bayer histogram
>> + *
>> + * Histogram of the luma of each 2x2 Bayer quad inside the histogram's region,
>> + * over CAMSS_STATS_BHIST_BINS equal bins spanning its input range. Quads
>> + * whose luma falls outside the input range are not counted.
>> + *
>> + * @header: block header; @header.type = CAMSS_STATS_AEC_BHIST
>> + * @bins:   number of quads per bin
>> + */
>> +struct camss_stats_bhist {
>> +	struct v4l2_isp_block_header header;
> I think that the whole format is not correct, having header is preventing address alignment
> of the buffer for the stats, as i have mentioned in the next patch copying the statistics
> on each frame is not correct, just to have generic statistics format in userspace.

Err no I'll disagree with you there.

Since we are introducing stats on the qcom side we get to be the first - 
or close to first - system to implement extensible self-describing stats 
which is the mirror to the params.

Extensible stats lands in 7.3 so IMO there's no reason not to use it.

Also I think its kind of a crap design to have extensible params but not 
extensible stats.

It should be all or nothing. I don't see a gigantic problem in copying 
in data and then looking at how to accommodate dma straight into the 
stats output with block alignments later.

The extensible header facilitates next-hopping anyway so userspace 
shouldn't have to change once we DMA to the aligned regions.

Also if that is not supported by extensible stats then it _should_ be 
supported by extensible stats - i.e. it should be possible to DMA 
directly into the output buffer and pad the blocks as much as you need.

---
bod