diff options
author | Pavel Machek <pavel@ucw.cz> | 2010-04-03 07:00:37 +0200 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@suse.de> | 2010-05-11 11:35:54 -0700 |
commit | 3b7b31fa7df01576cc401dff512a6a84cb3753ed (patch) | |
tree | dd69c7d87fce564c3a1ad8fe8f9969ce9e41ff78 /drivers/staging/udlfb | |
parent | 593ef41c95c82a7c8d09c28db4893f4dd2ff0134 (diff) | |
download | kernel_samsung_tuna-3b7b31fa7df01576cc401dff512a6a84cb3753ed.zip kernel_samsung_tuna-3b7b31fa7df01576cc401dff512a6a84cb3753ed.tar.gz kernel_samsung_tuna-3b7b31fa7df01576cc401dff512a6a84cb3753ed.tar.bz2 |
Staging: udlfb: minor cleanups
This cleans up udlfb a tiny bit.
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Cc: Bernie Thompson <bernie@plugable.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'drivers/staging/udlfb')
-rw-r--r-- | drivers/staging/udlfb/udlfb.c | 58 |
1 files changed, 29 insertions, 29 deletions
diff --git a/drivers/staging/udlfb/udlfb.c b/drivers/staging/udlfb/udlfb.c index a78ade0..12444f2 100644 --- a/drivers/staging/udlfb/udlfb.c +++ b/drivers/staging/udlfb/udlfb.c @@ -58,17 +58,17 @@ static struct usb_device_id id_table[] = { MODULE_DEVICE_TABLE(usb, id_table); #ifndef CONFIG_FB_DEFERRED_IO -#warning message "kernel FB_DEFFERRED_IO option to support generic fbdev apps" +#warning Please set CONFIG_FB_DEFFERRED_IO option to support generic fbdev apps #endif #ifndef CONFIG_FB_SYS_IMAGEBLIT #ifndef CONFIG_FB_SYS_IMAGEBLIT_MODULE -#warning message "FB_SYS_* in kernel or module option to support fb console" +#warning Please set CONFIG_FB_SYS_IMAGEBLIT option to support fb console #endif #endif #ifndef CONFIG_FB_MODE_HELPERS -#warning message "kernel FB_MODE_HELPERS required. Expect build break" +#warning CONFIG_FB_MODE_HELPERS required. Expect build break #endif /* dlfb keeps a list of urbs for efficient bulk transfers */ @@ -366,32 +366,32 @@ static int dlfb_trim_hline(const u8 *bback, const u8 **bfront, int *width_bytes) } /* -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. -*/ + * 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 dlfb_compress_hline( const uint16_t **pixel_start_ptr, const uint16_t *const pixel_end, |