linux-kernel - Re: [PATCH] RKISP1: correct histogram window size

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m3wma87s9x.fsf@t19.piap.pl>
Date: Thu, 22 May 2025 14:18:34 +0200
From: Krzysztof Hałasa <khalasa@...p.pl>
To: Paul Elder <paul.elder@...asonboard.com>
Cc: Laurent Pinchart <laurent.pinchart@...asonboard.com>,  Dafna Hirschfeld
 <dafna@...tmail.com>,  Mauro Carvalho Chehab <mchehab@...nel.org>,  Heiko
 Stuebner <heiko@...ech.de>,  linux-media@...r.kernel.org,
  linux-rockchip@...ts.infradead.org,
  linux-arm-kernel@...ts.infradead.org,  linux-kernel@...r.kernel.org,
  Jacopo Mondi <jacopo.mondi@...asonboard.com>,  Ondrej Jirman
 <megi@....cz>,  Tomi Valkeinen <tomi.valkeinen@...asonboard.com>,
  stefan.klug@...asonboard.com
Subject: Re: [PATCH] RKISP1: correct histogram window size

Paul Elder <paul.elder@...asonboard.com> writes:

>> > Setting "2", the same input scene:
>> > 32E12400: 15h
>> > 32E12414: 0 0 0 2194 1263 1096 1406 2528 5228 5052 4291 6354 8322 6943 13201 460522
>> > which sums to 518400 = 1920*1080/4.
>
> Yes, these look good (although I think you might've copy&pasted the wrong
> number for the sum)

Definitely :-)

> Oh? I would've expected 2^20-1 = 1048575 to be the magic number, but ok I
> suppose the hardware caps at 1048559 instead. It probably overflowed and that's
> why the sum is so low.

I don't know. It seems it counts all right until reaching this magic
1048559 = 0xFFFEF. Then it stops at this value and stays there.

>> > 32E12400: Dh
>> > 32E12414: 0 0 0 0 0 0 184 3059 11970 75298 114898 211444 429772 439922 400358 386695
>> > total = 2073600. But don't rely on it too much, the "1" has problems.
>
> That's interesting. My guess would be that in practice a divider of 1 would
> still work as long as you make sure that it doesn't overflow. Maybe the usage
> documentation was based on a rule-of-thumb.

I don't know. TBH I guess I haven't tested it with mainline kernel (and
RK1ISP driver), only with the NXP VVCAM driver. But with stepsize = 1
I was getting certain differences in total number of pixels (not big
ones and not always - maybe 10% of frames or so, or less). Without
reaching the magic value, I mean.

If if was simple cap at 1048559 we could correct it in software (up to
2 Mpixels) - there could only be one bin overflowing.
-- 
Krzysztof "Chris" Hałasa

Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa