Hello Andy,
Thanks for your feedback.
On 2/11/22 12:10, Andy Shevchenko wrote:
[snip]
>> +static void drm_fb_gray8_to_mono_reversed_line(u8 *dst, const u8 *src,
>> unsigned int pixels,
>> + unsigned int start_offset,
>> unsigned int end_len)
>> +{
>> + unsigned int xb, i;
>> +
>> + for (xb = 0; xb < pixels; xb++) {
>> + unsigned int start = 0, end = 8;
>> + u8 byte = 0x00;
>
>> + if (xb == 0 && start_offset)
>> + start = start_offset;
>
> This is invariant to the loop, can be moved out.
>
>> + if (xb == pixels - 1 && end_len)
>> + end = end_len;
>
> Ditto. However it may require to factor out the following loop to a helper.
>
Not sure I'm following, it's not invariant since it depends on the
loop iterator value. It only applies to the first and last pixels.
[snip]
>> + /*
>> + * The reversed mono destination buffer contains 1 bit per pixel
>> + * and destination scanlines have to be in multiple of 8 pixels.
>> + */
>> + if (!dst_pitch)
>> + dst_pitch = DIV_ROUND_UP(linepixels, 8);
>
> round_up() ?
>
But it's not a round up operation but a div and round up.
>> + WARN_ONCE(dst_pitch % 8 != 0, "dst_pitch is not a multiple of 8\n");
>
>
> I would move this to the if conditional, i.e.
>
> if (dst_pitch)
> WARN_ONCE(dst_pitch % 8 != 0, "dst_pitch is not a multiple of
> 8\n");
> else
> dst_pitch = round_up(linepixels, 8);
>
No, because we always need to div and round up. The warning is just printed to
let know that the dst pitch is not a multiple of 8 as it should be. So callers
could be fixed.
>> + /*
>> + * The cma memory is write-combined so reads are uncached.
>
> CMA
>
Yes, this bug me too. But other format helpers (e.g: drm_fb_xrgb8888_to_rgb565
and drm_fb_xrgb8888_to_gray8) had this comment with CMA in lower case. So did
the same for consistency.
>> + * Speed up by fetching one line at a time.
>> + *
>> + * Also, format conversion from XR24 to reversed monochrome
>> + * are done line-by-line but are converted to 8-bit grayscale
>> + * as an intermediate step.
>> + *
>> + * Allocate a buffer to be used for both copying from the cma
>> + * memory and to store the intermediate grayscale line pixels.
>> + */
>> + src32 = kmalloc(len_src32 + linepixels, GFP_KERNEL);
>
> size_add() ?
>
I wasn't familiar with this macro and git grep returned nothing. Then I noticed
that it is fairly new, introduced in commit a66866cff71c ("overflow: Implement
size_t saturating arithmetic helpers").
git tag --contains a66866cff71c | head -1
next-20220207
So I can't really use it since isn't yet in the latest drm-misc-next base tag :)
>> + if (!src32)
>> + return;
>
> ...
>
>> + /*
>> + * For damage handling, it is possible that only parts of the source
>> + * buffer is copied and this could lead to start and end pixels that
>> + * are not aligned to multiple of 8.
>> + *
>> + * Calculate if the start and end pixels are not aligned and set the
>> + * offsets for the reversed mono line conversion function to adjust.
>> + */
>> + start_offset = clip->x1 % 8;
>> + end_len = clip->x2 % 8;
>
> ALIGN() ?
>
But we don't want to align here but to know what's the start and end if is
not aligned since that would mean converting to mono in the middle of a byte.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
