Linux Kernel  3.7.1
 All Data Structures Namespaces Files Functions Variables Typedefs Enumerations Enumerator Macros Groups Pages
skeletonfb.c
Go to the documentation of this file.
1 /*
2  * linux/drivers/video/skeletonfb.c -- Skeleton for a frame buffer device
3  *
4  * Modified to new api Jan 2001 by James Simmons ([email protected])
5  *
6  * Created 28 Dec 1997 by Geert Uytterhoeven
7  *
8  *
9  * I have started rewriting this driver as a example of the upcoming new API
10  * The primary goal is to remove the console code from fbdev and place it
11  * into fbcon.c. This reduces the code and makes writing a new fbdev driver
12  * easy since the author doesn't need to worry about console internals. It
13  * also allows the ability to run fbdev without a console/tty system on top
14  * of it.
15  *
16  * First the roles of struct fb_info and struct display have changed. Struct
17  * display will go away. The way the new framebuffer console code will
18  * work is that it will act to translate data about the tty/console in
19  * struct vc_data to data in a device independent way in struct fb_info. Then
20  * various functions in struct fb_ops will be called to store the device
21  * dependent state in the par field in struct fb_info and to change the
22  * hardware to that state. This allows a very clean separation of the fbdev
23  * layer from the console layer. It also allows one to use fbdev on its own
24  * which is a bounus for embedded devices. The reason this approach works is
25  * for each framebuffer device when used as a tty/console device is allocated
26  * a set of virtual terminals to it. Only one virtual terminal can be active
27  * per framebuffer device. We already have all the data we need in struct
28  * vc_data so why store a bunch of colormaps and other fbdev specific data
29  * per virtual terminal.
30  *
31  * As you can see doing this makes the con parameter pretty much useless
32  * for struct fb_ops functions, as it should be. Also having struct
33  * fb_var_screeninfo and other data in fb_info pretty much eliminates the
34  * need for get_fix and get_var. Once all drivers use the fix, var, and cmap
35  * fbcon can be written around these fields. This will also eliminate the
36  * need to regenerate struct fb_var_screeninfo, struct fb_fix_screeninfo
37  * struct fb_cmap every time get_var, get_fix, get_cmap functions are called
38  * as many drivers do now.
39  *
40  * This file is subject to the terms and conditions of the GNU General Public
41  * License. See the file COPYING in the main directory of this archive for
42  * more details.
43  */
44 
45 #include <linux/module.h>
46 #include <linux/kernel.h>
47 #include <linux/errno.h>
48 #include <linux/string.h>
49 #include <linux/mm.h>
50 #include <linux/slab.h>
51 #include <linux/delay.h>
52 #include <linux/fb.h>
53 #include <linux/init.h>
54 #include <linux/pci.h>
55 
56  /*
57  * This is just simple sample code.
58  *
59  * No warranty that it actually compiles.
60  * Even less warranty that it actually works :-)
61  */
62 
63 /*
64  * Driver data
65  */
66 static char *mode_option __devinitdata;
67 
68 /*
69  * If your driver supports multiple boards, you should make the
70  * below data types arrays, or allocate them dynamically (using kmalloc()).
71  */
72 
73 /*
74  * This structure defines the hardware state of the graphics card. Normally
75  * you place this in a header file in linux/include/video. This file usually
76  * also includes register information. That allows other driver subsystems
77  * and userland applications the ability to use the same header file to
78  * avoid duplicate work and easy porting of software.
79  */
80 struct xxx_par;
81 
82 /*
83  * Here we define the default structs fb_fix_screeninfo and fb_var_screeninfo
84  * if we don't use modedb. If we do use modedb see xxxfb_init how to use it
85  * to get a fb_var_screeninfo. Otherwise define a default var as well.
86  */
87 static struct fb_fix_screeninfo xxxfb_fix __devinitdata = {
88  .id = "FB's name",
89  .type = FB_TYPE_PACKED_PIXELS,
90  .visual = FB_VISUAL_PSEUDOCOLOR,
91  .xpanstep = 1,
92  .ypanstep = 1,
93  .ywrapstep = 1,
94  .accel = FB_ACCEL_NONE,
95 };
96 
97  /*
98  * Modern graphical hardware not only supports pipelines but some
99  * also support multiple monitors where each display can have its
100  * its own unique data. In this case each display could be
101  * represented by a separate framebuffer device thus a separate
102  * struct fb_info. Now the struct xxx_par represents the graphics
103  * hardware state thus only one exist per card. In this case the
104  * struct xxx_par for each graphics card would be shared between
105  * every struct fb_info that represents a framebuffer on that card.
106  * This allows when one display changes it video resolution (info->var)
107  * the other displays know instantly. Each display can always be
108  * aware of the entire hardware state that affects it because they share
109  * the same xxx_par struct. The other side of the coin is multiple
110  * graphics cards that pass data around until it is finally displayed
111  * on one monitor. Such examples are the voodoo 1 cards and high end
112  * NUMA graphics servers. For this case we have a bunch of pars, each
113  * one that represents a graphics state, that belong to one struct
114  * fb_info. Their you would want to have *par point to a array of device
115  * states and have each struct fb_ops function deal with all those
116  * states. I hope this covers every possible hardware design. If not
117  * feel free to send your ideas at [email protected]
118  */
119 
120  /*
121  * If your driver supports multiple boards or it supports multiple
122  * framebuffers, you should make these arrays, or allocate them
123  * dynamically using framebuffer_alloc() and free them with
124  * framebuffer_release().
125  */
126 static struct fb_info info;
127 
128  /*
129  * Each one represents the state of the hardware. Most hardware have
130  * just one hardware state. These here represent the default state(s).
131  */
132 static struct xxx_par __initdata current_par;
133 
134 int xxxfb_init(void);
135 
150 static int xxxfb_open(struct fb_info *info, int user)
151 {
152  return 0;
153 }
154 
169 static int xxxfb_release(struct fb_info *info, int user)
170 {
171  return 0;
172 }
173 
210 static int xxxfb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
211 {
212  /* ... */
213  return 0;
214 }
215 
255 static int xxxfb_set_par(struct fb_info *info)
256 {
257  struct xxx_par *par = info->par;
258  /* ... */
259  return 0;
260 }
261 
284 static int xxxfb_setcolreg(unsigned regno, unsigned red, unsigned green,
285  unsigned blue, unsigned transp,
286  struct fb_info *info)
287 {
288  if (regno >= 256) /* no. of hw registers */
289  return -EINVAL;
290  /*
291  * Program hardware... do anything you want with transp
292  */
293 
294  /* grayscale works only partially under directcolor */
295  if (info->var.grayscale) {
296  /* grayscale = 0.30*R + 0.59*G + 0.11*B */
297  red = green = blue = (red * 77 + green * 151 + blue * 28) >> 8;
298  }
299 
300  /* Directcolor:
301  * var->{color}.offset contains start of bitfield
302  * var->{color}.length contains length of bitfield
303  * {hardwarespecific} contains width of DAC
304  * pseudo_palette[X] is programmed to (X << red.offset) |
305  * (X << green.offset) |
306  * (X << blue.offset)
307  * RAMDAC[X] is programmed to (red, green, blue)
308  * color depth = SUM(var->{color}.length)
309  *
310  * Pseudocolor:
311  * var->{color}.offset is 0 unless the palette index takes less than
312  * bits_per_pixel bits and is stored in the upper
313  * bits of the pixel value
314  * var->{color}.length is set so that 1 << length is the number of
315  * available palette entries
316  * pseudo_palette is not used
317  * RAMDAC[X] is programmed to (red, green, blue)
318  * color depth = var->{color}.length
319  *
320  * Static pseudocolor:
321  * same as Pseudocolor, but the RAMDAC is not programmed (read-only)
322  *
323  * Mono01/Mono10:
324  * Has only 2 values, black on white or white on black (fg on bg),
325  * var->{color}.offset is 0
326  * white = (1 << var->{color}.length) - 1, black = 0
327  * pseudo_palette is not used
328  * RAMDAC does not exist
329  * color depth is always 2
330  *
331  * Truecolor:
332  * does not use RAMDAC (usually has 3 of them).
333  * var->{color}.offset contains start of bitfield
334  * var->{color}.length contains length of bitfield
335  * pseudo_palette is programmed to (red << red.offset) |
336  * (green << green.offset) |
337  * (blue << blue.offset) |
338  * (transp << transp.offset)
339  * RAMDAC does not exist
340  * color depth = SUM(var->{color}.length})
341  *
342  * The color depth is used by fbcon for choosing the logo and also
343  * for color palette transformation if color depth < 4
344  *
345  * As can be seen from the above, the field bits_per_pixel is _NOT_
346  * a criteria for describing the color visual.
347  *
348  * A common mistake is assuming that bits_per_pixel <= 8 is pseudocolor,
349  * and higher than that, true/directcolor. This is incorrect, one needs
350  * to look at the fix->visual.
351  *
352  * Another common mistake is using bits_per_pixel to calculate the color
353  * depth. The bits_per_pixel field does not directly translate to color
354  * depth. You have to compute for the color depth (using the color
355  * bitfields) and fix->visual as seen above.
356  */
357 
358  /*
359  * This is the point where the color is converted to something that
360  * is acceptable by the hardware.
361  */
362 #define CNVT_TOHW(val,width) ((((val)<<(width))+0x7FFF-(val))>>16)
363  red = CNVT_TOHW(red, info->var.red.length);
364  green = CNVT_TOHW(green, info->var.green.length);
365  blue = CNVT_TOHW(blue, info->var.blue.length);
366  transp = CNVT_TOHW(transp, info->var.transp.length);
367 #undef CNVT_TOHW
368  /*
369  * This is the point where the function feeds the color to the hardware
370  * palette after converting the colors to something acceptable by
371  * the hardware. Note, only FB_VISUAL_DIRECTCOLOR and
372  * FB_VISUAL_PSEUDOCOLOR visuals need to write to the hardware palette.
373  * If you have code that writes to the hardware CLUT, and it's not
374  * any of the above visuals, then you are doing something wrong.
375  */
376  if (info->fix.visual == FB_VISUAL_DIRECTCOLOR ||
377  info->fix.visual == FB_VISUAL_TRUECOLOR)
378  write_{red|green|blue|transp}_to_clut();
379 
380  /* This is the point were you need to fill up the contents of
381  * info->pseudo_palette. This structure is used _only_ by fbcon, thus
382  * it only contains 16 entries to match the number of colors supported
383  * by the console. The pseudo_palette is used only if the visual is
384  * in directcolor or truecolor mode. With other visuals, the
385  * pseudo_palette is not used. (This might change in the future.)
386  *
387  * The contents of the pseudo_palette is in raw pixel format. Ie, each
388  * entry can be written directly to the framebuffer without any conversion.
389  * The pseudo_palette is (void *). However, if using the generic
390  * drawing functions (cfb_imageblit, cfb_fillrect), the pseudo_palette
391  * must be casted to (u32 *) _regardless_ of the bits per pixel. If the
392  * driver is using its own drawing functions, then it can use whatever
393  * size it wants.
394  */
395  if (info->fix.visual == FB_VISUAL_TRUECOLOR ||
396  info->fix.visual == FB_VISUAL_DIRECTCOLOR) {
397  u32 v;
398 
399  if (regno >= 16)
400  return -EINVAL;
401 
402  v = (red << info->var.red.offset) |
403  (green << info->var.green.offset) |
404  (blue << info->var.blue.offset) |
405  (transp << info->var.transp.offset);
406 
407  ((u32*)(info->pseudo_palette))[regno] = v;
408  }
409 
410  /* ... */
411  return 0;
412 }
413 
425 static int xxxfb_pan_display(struct fb_var_screeninfo *var,
426  struct fb_info *info)
427 {
428  /*
429  * If your hardware does not support panning, _do_ _not_ implement this
430  * function. Creating a dummy function will just confuse user apps.
431  */
432 
433  /*
434  * Note that even if this function is fully functional, a setting of
435  * 0 in both xpanstep and ypanstep means that this function will never
436  * get called.
437  */
438 
439  /* ... */
440  return 0;
441 }
442 
464 static int xxxfb_blank(int blank_mode, struct fb_info *info)
465 {
466  /* ... */
467  return 0;
468 }
469 
470 /* ------------ Accelerated Functions --------------------- */
471 
472 /*
473  * We provide our own functions if we have hardware acceleration
474  * or non packed pixel format layouts. If we have no hardware
475  * acceleration, we can use a generic unaccelerated function. If using
476  * a pack pixel format just use the functions in cfb_*.c. Each file
477  * has one of the three different accel functions we support.
478  */
479 
493 void xxxfb_fillrect(struct fb_info *p, const struct fb_fillrect *region)
494 {
495 /* Meaning of struct fb_fillrect
496  *
497  * @dx: The x and y corrdinates of the upper left hand corner of the
498  * @dy: area we want to draw to.
499  * @width: How wide the rectangle is we want to draw.
500  * @height: How tall the rectangle is we want to draw.
501  * @color: The color to fill in the rectangle with.
502  * @rop: The raster operation. We can draw the rectangle with a COPY
503  * of XOR which provides erasing effect.
504  */
505 }
506 
519 void xxxfb_copyarea(struct fb_info *p, const struct fb_copyarea *area)
520 {
521 /*
522  * @dx: The x and y coordinates of the upper left hand corner of the
523  * @dy: destination area on the screen.
524  * @width: How wide the rectangle is we want to copy.
525  * @height: How tall the rectangle is we want to copy.
526  * @sx: The x and y coordinates of the upper left hand corner of the
527  * @sy: source area on the screen.
528  */
529 }
530 
531 
544 void xxxfb_imageblit(struct fb_info *p, const struct fb_image *image)
545 {
546 /*
547  * @dx: The x and y coordinates of the upper left hand corner of the
548  * @dy: destination area to place the image on the screen.
549  * @width: How wide the image is we want to copy.
550  * @height: How tall the image is we want to copy.
551  * @fg_color: For mono bitmap images this is color data for
552  * @bg_color: the foreground and background of the image to
553  * write directly to the frmaebuffer.
554  * @depth: How many bits represent a single pixel for this image.
555  * @data: The actual data used to construct the image on the display.
556  * @cmap: The colormap used for color images.
557  */
558 
559 /*
560  * The generic function, cfb_imageblit, expects that the bitmap scanlines are
561  * padded to the next byte. Most hardware accelerators may require padding to
562  * the next u16 or the next u32. If that is the case, the driver can specify
563  * this by setting info->pixmap.scan_align = 2 or 4. See a more
564  * comprehensive description of the pixmap below.
565  */
566 }
567 
580 int xxxfb_cursor(struct fb_info *info, struct fb_cursor *cursor)
581 {
582 /*
583  * @set: Which fields we are altering in struct fb_cursor
584  * @enable: Disable or enable the cursor
585  * @rop: The bit operation we want to do.
586  * @mask: This is the cursor mask bitmap.
587  * @dest: A image of the area we are going to display the cursor.
588  * Used internally by the driver.
589  * @hot: The hot spot.
590  * @image: The actual data for the cursor image.
591  *
592  * NOTES ON FLAGS (cursor->set):
593  *
594  * FB_CUR_SETIMAGE - the cursor image has changed (cursor->image.data)
595  * FB_CUR_SETPOS - the cursor position has changed (cursor->image.dx|dy)
596  * FB_CUR_SETHOT - the cursor hot spot has changed (cursor->hot.dx|dy)
597  * FB_CUR_SETCMAP - the cursor colors has changed (cursor->fg_color|bg_color)
598  * FB_CUR_SETSHAPE - the cursor bitmask has changed (cursor->mask)
599  * FB_CUR_SETSIZE - the cursor size has changed (cursor->width|height)
600  * FB_CUR_SETALL - everything has changed
601  *
602  * NOTES ON ROPs (cursor->rop, Raster Operation)
603  *
604  * ROP_XOR - cursor->image.data XOR cursor->mask
605  * ROP_COPY - curosr->image.data AND cursor->mask
606  *
607  * OTHER NOTES:
608  *
609  * - fbcon only supports a 2-color cursor (cursor->image.depth = 1)
610  * - The fb_cursor structure, @cursor, _will_ always contain valid
611  * fields, whether any particular bitfields in cursor->set is set
612  * or not.
613  */
614 }
615 
627 void xxxfb_rotate(struct fb_info *info, int angle)
628 {
629 /* Will be deprecated */
630 }
631 
644 int xxxfb_sync(struct fb_info *info)
645 {
646  return 0;
647 }
648 
649  /*
650  * Frame buffer operations
651  */
652 
653 static struct fb_ops xxxfb_ops = {
654  .owner = THIS_MODULE,
655  .fb_open = xxxfb_open,
656  .fb_read = xxxfb_read,
657  .fb_write = xxxfb_write,
658  .fb_release = xxxfb_release,
659  .fb_check_var = xxxfb_check_var,
660  .fb_set_par = xxxfb_set_par,
661  .fb_setcolreg = xxxfb_setcolreg,
662  .fb_blank = xxxfb_blank,
663  .fb_pan_display = xxxfb_pan_display,
664  .fb_fillrect = xxxfb_fillrect, /* Needed !!! */
665  .fb_copyarea = xxxfb_copyarea, /* Needed !!! */
666  .fb_imageblit = xxxfb_imageblit, /* Needed !!! */
667  .fb_cursor = xxxfb_cursor, /* Optional !!! */
668  .fb_rotate = xxxfb_rotate,
669  .fb_sync = xxxfb_sync,
670  .fb_ioctl = xxxfb_ioctl,
671  .fb_mmap = xxxfb_mmap,
672 };
673 
674 /* ------------------------------------------------------------------------- */
675 
676  /*
677  * Initialization
678  */
679 
680 /* static int __init xxfb_probe (struct platform_device *pdev) -- for platform devs */
681 static int __devinit xxxfb_probe(struct pci_dev *dev,
682  const struct pci_device_id *ent)
683 {
684  struct fb_info *info;
685  struct xxx_par *par;
686  struct device *device = &dev->dev; /* or &pdev->dev */
687  int cmap_len, retval;
688 
689  /*
690  * Dynamically allocate info and par
691  */
692  info = framebuffer_alloc(sizeof(struct xxx_par), device);
693 
694  if (!info) {
695  /* goto error path */
696  }
697 
698  par = info->par;
699 
700  /*
701  * Here we set the screen_base to the virtual memory address
702  * for the framebuffer. Usually we obtain the resource address
703  * from the bus layer and then translate it to virtual memory
704  * space via ioremap. Consult ioport.h.
705  */
706  info->screen_base = framebuffer_virtual_memory;
707  info->fbops = &xxxfb_ops;
708  info->fix = xxxfb_fix; /* this will be the only time xxxfb_fix will be
709  * used, so mark it as __devinitdata
710  */
711  info->pseudo_palette = pseudo_palette; /* The pseudopalette is an
712  * 16-member array
713  */
714  /*
715  * Set up flags to indicate what sort of acceleration your
716  * driver can provide (pan/wrap/copyarea/etc.) and whether it
717  * is a module -- see FBINFO_* in include/linux/fb.h
718  *
719  * If your hardware can support any of the hardware accelerated functions
720  * fbcon performance will improve if info->flags is set properly.
721  *
722  * FBINFO_HWACCEL_COPYAREA - hardware moves
723  * FBINFO_HWACCEL_FILLRECT - hardware fills
724  * FBINFO_HWACCEL_IMAGEBLIT - hardware mono->color expansion
725  * FBINFO_HWACCEL_YPAN - hardware can pan display in y-axis
726  * FBINFO_HWACCEL_YWRAP - hardware can wrap display in y-axis
727  * FBINFO_HWACCEL_DISABLED - supports hardware accels, but disabled
728  * FBINFO_READS_FAST - if set, prefer moves over mono->color expansion
729  * FBINFO_MISC_TILEBLITTING - hardware can do tile blits
730  *
731  * NOTE: These are for fbcon use only.
732  */
733  info->flags = FBINFO_DEFAULT;
734 
735 /********************* This stage is optional ******************************/
736  /*
737  * The struct pixmap is a scratch pad for the drawing functions. This
738  * is where the monochrome bitmap is constructed by the higher layers
739  * and then passed to the accelerator. For drivers that uses
740  * cfb_imageblit, you can skip this part. For those that have a more
741  * rigorous requirement, this stage is needed
742  */
743 
744  /* PIXMAP_SIZE should be small enough to optimize drawing, but not
745  * large enough that memory is wasted. A safe size is
746  * (max_xres * max_font_height/8). max_xres is driver dependent,
747  * max_font_height is 32.
748  */
749  info->pixmap.addr = kmalloc(PIXMAP_SIZE, GFP_KERNEL);
750  if (!info->pixmap.addr) {
751  /* goto error */
752  }
753 
754  info->pixmap.size = PIXMAP_SIZE;
755 
756  /*
757  * FB_PIXMAP_SYSTEM - memory is in system ram
758  * FB_PIXMAP_IO - memory is iomapped
759  * FB_PIXMAP_SYNC - if set, will call fb_sync() per access to pixmap,
760  * usually if FB_PIXMAP_IO is set.
761  *
762  * Currently, FB_PIXMAP_IO is unimplemented.
763  */
764  info->pixmap.flags = FB_PIXMAP_SYSTEM;
765 
766  /*
767  * scan_align is the number of padding for each scanline. It is in bytes.
768  * Thus for accelerators that need padding to the next u32, put 4 here.
769  */
770  info->pixmap.scan_align = 4;
771 
772  /*
773  * buf_align is the amount to be padded for the buffer. For example,
774  * the i810fb needs a scan_align of 2 but expects it to be fed with
775  * dwords, so a buf_align = 4 is required.
776  */
777  info->pixmap.buf_align = 4;
778 
779  /* access_align is how many bits can be accessed from the framebuffer
780  * ie. some epson cards allow 16-bit access only. Most drivers will
781  * be safe with u32 here.
782  *
783  * NOTE: This field is currently unused.
784  */
785  info->pixmap.access_align = 32;
786 /***************************** End optional stage ***************************/
787 
788  /*
789  * This should give a reasonable default video mode. The following is
790  * done when we can set a video mode.
791  */
792  if (!mode_option)
793  mode_option = "640x480@60";
794 
795  retval = fb_find_mode(&info->var, info, mode_option, NULL, 0, NULL, 8);
796 
797  if (!retval || retval == 4)
798  return -EINVAL;
799 
800  /* This has to be done! */
801  if (fb_alloc_cmap(&info->cmap, cmap_len, 0))
802  return -ENOMEM;
803 
804  /*
805  * The following is done in the case of having hardware with a static
806  * mode. If we are setting the mode ourselves we don't call this.
807  */
808  info->var = xxxfb_var;
809 
810  /*
811  * For drivers that can...
812  */
813  xxxfb_check_var(&info->var, info);
814 
815  /*
816  * Does a call to fb_set_par() before register_framebuffer needed? This
817  * will depend on you and the hardware. If you are sure that your driver
818  * is the only device in the system, a call to fb_set_par() is safe.
819  *
820  * Hardware in x86 systems has a VGA core. Calling set_par() at this
821  * point will corrupt the VGA console, so it might be safer to skip a
822  * call to set_par here and just allow fbcon to do it for you.
823  */
824  /* xxxfb_set_par(info); */
825 
826  if (register_framebuffer(info) < 0) {
827  fb_dealloc_cmap(&info->cmap);
828  return -EINVAL;
829  }
830  printk(KERN_INFO "fb%d: %s frame buffer device\n", info->node,
831  info->fix.id);
832  pci_set_drvdata(dev, info); /* or platform_set_drvdata(pdev, info) */
833  return 0;
834 }
835 
836  /*
837  * Cleanup
838  */
839 /* static void __devexit xxxfb_remove(struct platform_device *pdev) */
840 static void __devexit xxxfb_remove(struct pci_dev *dev)
841 {
842  struct fb_info *info = pci_get_drvdata(dev);
843  /* or platform_get_drvdata(pdev); */
844 
845  if (info) {
847  fb_dealloc_cmap(&info->cmap);
848  /* ... */
849  framebuffer_release(info);
850  }
851 }
852 
853 #ifdef CONFIG_PCI
854 #ifdef CONFIG_PM
855 
862 static int xxxfb_suspend(struct pci_dev *dev, pm_message_t msg)
863 {
864  struct fb_info *info = pci_get_drvdata(dev);
865  struct xxxfb_par *par = info->par;
866 
867  /* suspend here */
868  return 0;
869 }
870 
877 static int xxxfb_resume(struct pci_dev *dev)
878 {
879  struct fb_info *info = pci_get_drvdata(dev);
880  struct xxxfb_par *par = info->par;
881 
882  /* resume here */
883  return 0;
884 }
885 #else
886 #define xxxfb_suspend NULL
887 #define xxxfb_resume NULL
888 #endif /* CONFIG_PM */
889 
890 static struct pci_device_id xxxfb_id_table[] = {
891  { PCI_VENDOR_ID_XXX, PCI_DEVICE_ID_XXX,
893  PCI_CLASS_MASK, 0 },
894  { 0, }
895 };
896 
897 /* For PCI drivers */
898 static struct pci_driver xxxfb_driver = {
899  .name = "xxxfb",
900  .id_table = xxxfb_id_table,
901  .probe = xxxfb_probe,
902  .remove = __devexit_p(xxxfb_remove),
903  .suspend = xxxfb_suspend, /* optional but recommended */
904  .resume = xxxfb_resume, /* optional but recommended */
905 };
906 
907 MODULE_DEVICE_TABLE(pci, xxxfb_id_table);
908 
909 int __init xxxfb_init(void)
910 {
911  /*
912  * For kernel boot options (in 'video=xxxfb:<options>' format)
913  */
914 #ifndef MODULE
915  char *option = NULL;
916 
917  if (fb_get_options("xxxfb", &option))
918  return -ENODEV;
919  xxxfb_setup(option);
920 #endif
921 
922  return pci_register_driver(&xxxfb_driver);
923 }
924 
925 static void __exit xxxfb_exit(void)
926 {
927  pci_unregister_driver(&xxxfb_driver);
928 }
929 #else /* non PCI, platform drivers */
930 #include <linux/platform_device.h>
931 /* for platform devices */
932 
933 #ifdef CONFIG_PM
934 
941 static int xxxfb_suspend(struct platform_device *dev, pm_message_t msg)
942 {
943  struct fb_info *info = platform_get_drvdata(dev);
944  struct xxxfb_par *par = info->par;
945 
946  /* suspend here */
947  return 0;
948 }
949 
956 static int xxxfb_resume(struct platform_dev *dev)
957 {
958  struct fb_info *info = platform_get_drvdata(dev);
959  struct xxxfb_par *par = info->par;
960 
961  /* resume here */
962  return 0;
963 }
964 #else
965 #define xxxfb_suspend NULL
966 #define xxxfb_resume NULL
967 #endif /* CONFIG_PM */
968 
969 static struct platform_device_driver xxxfb_driver = {
970  .probe = xxxfb_probe,
971  .remove = xxxfb_remove,
972  .suspend = xxxfb_suspend, /* optional but recommended */
973  .resume = xxxfb_resume, /* optional but recommended */
974  .driver = {
975  .name = "xxxfb",
976  },
977 };
978 
979 static struct platform_device *xxxfb_device;
980 
981 #ifndef MODULE
982  /*
983  * Setup
984  */
985 
986 /*
987  * Only necessary if your driver takes special options,
988  * otherwise we fall back on the generic fb_setup().
989  */
991 {
992  /* Parse user specified options (`video=xxxfb:') */
993 }
994 #endif /* MODULE */
995 
996 static int __init xxxfb_init(void)
997 {
998  int ret;
999  /*
1000  * For kernel boot options (in 'video=xxxfb:<options>' format)
1001  */
1002 #ifndef MODULE
1003  char *option = NULL;
1004 
1005  if (fb_get_options("xxxfb", &option))
1006  return -ENODEV;
1007  xxxfb_setup(option);
1008 #endif
1009  ret = platform_driver_register(&xxxfb_driver);
1010 
1011  if (!ret) {
1012  xxxfb_device = platform_device_register_simple("xxxfb", 0,
1013  NULL, 0);
1014 
1015  if (IS_ERR(xxxfb_device)) {
1016  platform_driver_unregister(&xxxfb_driver);
1017  ret = PTR_ERR(xxxfb_device);
1018  }
1019  }
1020 
1021  return ret;
1022 }
1023 
1024 static void __exit xxxfb_exit(void)
1025 {
1026  platform_device_unregister(xxxfb_device);
1027  platform_driver_unregister(&xxxfb_driver);
1028 }
1029 #endif /* CONFIG_PCI */
1030 
1031 /* ------------------------------------------------------------------------- */
1032 
1033 
1034  /*
1035  * Modularization
1036  */
1037 
1039 module_exit(xxxfb_exit);
1040 
1041 MODULE_LICENSE("GPL");