linux/drivers/gpu/drm/udl/udl_transfer.c

// SPDX-License-Identifier: GPL-2.0-only
/*
 * Copyright (C) 2012 Red Hat
 * based in parts on udlfb.c:
 * Copyright (C) 2009 Roberto De Ioris <[email protected]>
 * Copyright (C) 2009 Jaya Kumar <[email protected]>
 * Copyright (C) 2009 Bernie Thompson <[email protected]>
 */

#include <asm/unaligned.h>

#include "udl_drv.h"
#include "udl_proto.h"

#define MAX_CMD_PIXELS …

#define RLX_HEADER_BYTES …
#define MIN_RLX_PIX_BYTES …
#define MIN_RLX_CMD_BYTES …

#define RLE_HEADER_BYTES …
#define MIN_RLE_PIX_BYTES …
#define MIN_RLE_CMD_BYTES …

#define RAW_HEADER_BYTES …
#define MIN_RAW_PIX_BYTES …
#define MIN_RAW_CMD_BYTES …

static inline u16 pixel32_to_be16(const uint32_t pixel)
{ … }

static inline u16 get_pixel_val16(const uint8_t *pixel, int log_bpp)
{ … }

/*
 * Render a command stream for an encoded horizontal line segment of pixels.
 *
 * A command buffer holds several commands.
 * It always begins with a fresh command header
 * (the protocol doesn't require this, but we enforce it to allow
 * multiple buffers to be potentially encoded and sent in parallel).
 * A single command encodes one contiguous horizontal line of pixels
 *
 * The function relies on the client to do all allocation, so that
 * rendering can be done directly to output buffers (e.g. USB URBs).
 * The function fills the supplied command buffer, providing information
 * on where it left off, so the client may call in again with additional
 * buffers if the line will take several buffers to complete.
 *
 * A single command can transmit a maximum of 256 pixels,
 * regardless of the compression ratio (protocol design limit).
 * To the hardware, 0 for a size byte means 256
 *
 * Rather than 256 pixel commands which are either rl or raw encoded,
 * the rlx command simply assumes alternating raw and rl spans within one cmd.
 * This has a slightly larger header overhead, but produces more even results.
 * It also processes all data (read and write) in a single pass.
 * Performance benchmarks of common cases show it having just slightly better
 * compression than 256 pixel raw or rle commands, with similar CPU consumpion.
 * But for very rl friendly data, will compress not quite as well.
 */
static void udl_compress_hline16(
	const u8 **pixel_start_ptr,
	const u8 *const pixel_end,
	uint32_t *device_address_ptr,
	uint8_t **command_buffer_ptr,
	const uint8_t *const cmd_buffer_end, int log_bpp)
{ … }

/*
 * There are 3 copies of every pixel: The front buffer that the fbdev
 * client renders to, the actual framebuffer across the USB bus in hardware
 * (that we can only write to, slowly, and can never read), and (optionally)
 * our shadow copy that tracks what's been sent to that hardware buffer.
 */
int udl_render_hline(struct drm_device *dev, int log_bpp, struct urb **urb_ptr,
		     const char *front, char **urb_buf_ptr,
		     u32 byte_offset, u32 device_byte_offset,
		     u32 byte_width)
{ … }