Zero-Start Driver Development, linux Driver (28, Frameebuffer Driver Framework)

Keywords: Mobile Attribute

frame

1. Register a framebuffer class.

2. Register a main device number, because the number of FBS is usually relatively small, so the old interface can be used to unify the registration.

3. Implement a general fops for registration in 2. Note that this is a general one, and the special architecture in the general one still needs to invoke the operation interface for special fb registration. (See below)

4. Provide a unified registration and uninstallation interface.

5. Register and uninstall provide some attribute s operation interfaces for some parameters that can be set in application layer, such as resolution, bpp, display mode, etc.

6. Realize the corresponding show and store interface in 5.

7. Basically all store s need to check the parameters of application layer settings, and after passing, call the specific settings function for each fb registration. This function is to write the parameters to the real hardware register.

 

static const struct file_operations fb_fops = {
	.owner =	THIS_MODULE,
	.read =		fb_read,            /* Universal does nothing, and if a particular architecture is implemented, the architecture's own is preferred. */
	.write =	fb_write,           /* Universal Write-Display Memory, if a particular architecture is implemented, preferring the architecture's own */
	.unlocked_ioctl = fb_ioctl,
#ifdef CONFIG_COMPAT
	.compat_ioctl = fb_compat_ioctl,
#endif
	.mmap =		fb_mmap,
	.open =		fb_open,
	.release =	fb_release,
#ifdef HAVE_ARCH_FB_UNMAPPED_AREA
	.get_unmapped_area = get_fb_unmapped_area,
#endif
#ifdef CONFIG_FB_DEFERRED_IO
	.fsync =	fb_deferred_io_fsync,
#endif
	.llseek =	default_llseek,
};

 

 

drive

1. Data and drivers are usually separated by using a platform bus or device tree.

2. Write probe, remote function, etc.

3.probe implements hardware initialization, parameter calculation conversion, resource mapping, interrupt application and so on.

4. Implement some hardware-related functions in fb_ops. Refer to Samsung Platform below.

 

 

The functions set here are mainly called when the real hardware parameters need to be updated for the settings in attribute s.

static struct fb_ops s3c_fb_ops = {
	.owner		= THIS_MODULE,
	.fb_check_var	= s3c_fb_check_var,
	.fb_set_par	= s3c_fb_set_par,
	.fb_blank	= s3c_fb_blank,
	.fb_setcolreg	= s3c_fb_setcolreg,
	.fb_fillrect	= cfb_fillrect,
	.fb_copyarea	= cfb_copyarea,
	.fb_imageblit	= cfb_imageblit,
	.fb_pan_display	= s3c_fb_pan_display,
	.fb_ioctl	= s3c_fb_ioctl,
};

 

This is created in sysfs at registration time, using

/* When cmap is added back in it should be a binary attribute
 * not a text one. Consideration should also be given to converting
 * fbdev to use configfs instead of sysfs */
static struct device_attribute device_attrs[] = {
	__ATTR(bits_per_pixel, S_IRUGO|S_IWUSR, show_bpp, store_bpp),
	__ATTR(blank, S_IRUGO|S_IWUSR, show_blank, store_blank),
	__ATTR(console, S_IRUGO|S_IWUSR, show_console, store_console),
	__ATTR(cursor, S_IRUGO|S_IWUSR, show_cursor, store_cursor),
	__ATTR(mode, S_IRUGO|S_IWUSR, show_mode, store_mode),
	__ATTR(modes, S_IRUGO|S_IWUSR, show_modes, store_modes),
	__ATTR(pan, S_IRUGO|S_IWUSR, show_pan, store_pan),
	__ATTR(virtual_size, S_IRUGO|S_IWUSR, show_virtual, store_virtual),
	__ATTR(name, S_IRUGO, show_name, NULL),
	__ATTR(stride, S_IRUGO, show_stride, NULL),
	__ATTR(rotate, S_IRUGO|S_IWUSR, show_rotate, store_rotate),
	__ATTR(state, S_IRUGO|S_IWUSR, show_fbstate, store_fbstate),
#ifdef CONFIG_FB_BACKLIGHT
	__ATTR(bl_curve, S_IRUGO|S_IWUSR, show_bl_curve, store_bl_curve),
#endif
};

 

 

Posted by dreamline on Wed, 23 Jan 2019 17:09:13 -0800