[PATCH] Revert "libcamera: rkisp1: Eliminate hard-coded resizer limits"

[Quentin Schulz]

Hi Laurent,

On 4/22/25 12:07 PM, Laurent Pinchart wrote:
> Hi Quentin,
> 
> Thank you for the patch.
> 
> On Thu, Apr 03, 2025 at 08:09:00PM +0200, Quentin Schulz wrote:
>> From: Quentin Schulz <quentin.schulz at cherry.de>
>>
>> This reverts commit e85c7ddd38ce8456ab01c2a73baf9e788f6a462e.
>>
>> Linux kernel predating 6.4 (specifically commit 7cfb35d3a800 ("media:
>> rkisp1: Implement ENUM_FRAMESIZES") do not have the ioctl in rkisp1
>> driver required to dynamically query the resizer limits.
>>
>> Because of that, maxResolution and minResolution are both {0, 0}
>> (default value for Size objects) which means filterSensorResolution()
>> will create an entry for the sensor in sensorSizesMap_ but because the
>> sensor resolution cannot fit inside the min and max resolution of the
>> rkisp1, no size is put into this entry in sensorSizesMap_.
>> On the next call to filterSensorResolution(),
>> sensorSizesMap_.find(sensor) will return the entry but when attempting
>> to call back() on iter->second, it'll trigger an assert because the size
>> array is empty.
>>
>> Linux kernel 6.1 is supported until December 2027, so it seems premature
>> to get rid of those hard-coded resizer limits before this happens.
> 
> You noticed our secret plan to push people towards mainline :-)
> 

And I can only regret airing this plan publicly as it is a good one ;) 
To be fair, the only product we have that currently needs this patch 
will have its kernel updated and not require this patch anymore. So, 
soon not a problem for me anymore :)

> Jokes aside, we do our best to support older kernels. I won't commit to
> supporting v6.1 on all platforms until end of 2027 (or worse, until the
> end of the CIP support, which will be in 2033) if it would make our life
> much harder, but in this specific case the effort is low.
> 

Why I sent the revert is to let people know that this could be enough to 
get libcamera to work on those old(er) kernels. It's always nice to see 
some patches available, even if they may not be merged because upstream 
has a specific policy.

I understand your position as supporting multiple kernel versions simply 
doesn't scale well and possibly hinder "innovation" in the code :)

>> Let's keep the hard-coded resizer limits by default, they can still be
>> queried if necessary.
> 
> They will always be queried if the ENUM_FRAMESIZES ioctl is implemented,
> so I would write this as
> 
> Let's restore the hard-coded resizer limits as fallbacks, limits are
> still queried from the driver on recent enough kernels.
> 

I think the point is "the hard-coded resizer limits [...] can still be 
queried if necessary", reading between the lines meaning ENUM_FRAMESIZES 
ioctl being implemented will make hard-coded resizer limits unnecessary, 
thus, not queried.

Your suggestion works for me, I could/would add "actual" before the 
second "limits" but eh, doesn't matter much.

[...]

>>   /*
>> - * \todo Remove the hardcoded formats once all users will have migrated to a
>> - * recent enough kernel.
>> + * \todo Remove the hardcoded resolutions and formats once all users will have
>> + * migrated to a recent enough kernel.
> 
> We can now be a bit more precise:
> 
>   * \todo Remove the hardcoded resolutions and formats once kernels older than
>   * v6.4 will stop receiving LTS support (scheduled for December 2027 for v6.1).
> 
> I can make those small changes when applying the patch if you're fine
> with them.
> 
> Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> 

Works for me!

Thanks!

Quentin