Hello Andy,

Thanks for your feedback.

On 2/11/22 12:10, Andy Shevchenko wrote:

[snip]

quoted

+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;

quoted

+		if (xb == 0 && start_offset)
+			start = start_offset;

This is invariant to the loop, can be moved out.

quoted

+		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]

quoted

+	/*
+	 * 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.

quoted

+	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.

quoted

+	/*
+	 * 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.

quoted

+	 * 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 :)

quoted

+	if (!src32)
+		return;

...

quoted

+	/*
+	 * 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