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,