rcar-vin: Update format alignment constraints
Commit Message
This change fixes two issues with the size constraints for buffers.
- There is no width alignment constraints for RGB formats. Prior to this
change they where treated as YUV and as a result was more restricted
then needed. Add a new check to different between the two.
- The minimum width and height supported is 5x2, not 2x4, this is an
artifact from the drivers soc-camera days. Fix this incorrect
assumption.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
---
drivers/media/platform/rcar-vin/rcar-v4l2.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
Comments
Hello!
On 26.11.2021 2:02, Niklas Söderlund wrote:
> This change fixes two issues with the size constraints for buffers.
>
> - There is no width alignment constraints for RGB formats. Prior to this
> change they where treated as YUV and as a result was more restricted
s/was/were/.
> then needed. Add a new check to different between the two.
Differ?
> - The minimum width and height supported is 5x2, not 2x4, this is an
> artifact from the drivers soc-camera days. Fix this incorrect
> assumption.
>
> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
[...]
MBR, Sergey
On 11/27/21 6:02 PM, Sergey Shtylyov wrote:
>> This change fixes two issues with the size constraints for buffers.
>>
>> - There is no width alignment constraints for RGB formats. Prior to this
>> change they where treated as YUV and as a result was more restricted
>
> s/was/were/.
... and s/where/were/ too. :-)
>> then needed. Add a new check to different between the two.
>
> Differ?
>
>> - The minimum width and height supported is 5x2, not 2x4, this is an
>> artifact from the drivers soc-camera days. Fix this incorrect
>> assumption.
>>
>> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> [...]
MBR, Sergey
On 29.11.2021 23:11, Sergey Shtylyov wrote:
> On 11/27/21 6:02 PM, Sergey Shtylyov wrote:
>
>>> This change fixes two issues with the size constraints for buffers.
>>>
>>> - There is no width alignment constraints for RGB formats. Prior to this
>>> change they where treated as YUV and as a result was more restricted
>>
>> s/was/were/.
Actually, scratch that -- I misread the sentence. :-/
But what doesn't rhyme is "as" -- are you sure it should be here?
> ... and s/where/were/ too. :-)
That one was correctly spotted... :-)
[...]
MBR, Sergey
On 30.11.2021 12:55, Sergey Shtylyov wrote:
>>>> This change fixes two issues with the size constraints for buffers.
>>>>
>>>> - There is no width alignment constraints for RGB formats. Prior to this
>>>> change they where treated as YUV and as a result was more restricted
>>>
>>> s/was/were/.
>
> Actually, scratch that -- I misread the sentence. :-/
> But what doesn't rhyme is "as" -- are you sure it should be here?
Hm... I re-read that again and now "as" makes sense but then s/was/were/
was a correct spotting too! :-)
>> ... and s/where/were/ too. :-)
>
> That one was correctly spotted... :-)
[...]
MBR, Sergey
@@ -179,20 +179,27 @@ static void rvin_format_align(struct rvin_dev *vin, struct v4l2_pix_format *pix)
break;
}
- /* HW limit width to a multiple of 32 (2^5) for NV12/16 else 2 (2^1) */
+ /* Hardware limits width alignment based on format. */
switch (pix->pixelformat) {
+ /* Multiple of 32 (2^5) for NV12/16. */
case V4L2_PIX_FMT_NV12:
case V4L2_PIX_FMT_NV16:
walign = 5;
break;
- default:
+ /* Multiple of 2 (2^1) for YUV. */
+ case V4L2_PIX_FMT_YUYV:
+ case V4L2_PIX_FMT_UYVY:
walign = 1;
break;
+ /* No multiple for RGB. */
+ default:
+ walign = 0;
+ break;
}
/* Limit to VIN capabilities */
- v4l_bound_align_image(&pix->width, 2, vin->info->max_width, walign,
- &pix->height, 4, vin->info->max_height, 2, 0);
+ v4l_bound_align_image(&pix->width, 5, vin->info->max_width, walign,
+ &pix->height, 2, vin->info->max_height, 0, 0);
pix->bytesperline = rvin_format_bytesperline(vin, pix);
pix->sizeimage = rvin_format_sizeimage(pix);