Merge with rsync://rsync.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6.git

S: D-91080 Uttenreuth

S: Germany

N: Jaya Kumar

E: jayalk@intworks.biz

W: http://www.intworks.biz

D: Arc monochrome LCD framebuffer driver, x86 reboot fixups

S: Gurgaon, India

S: Kuala Lumpur, Malaysia

N: Gabor Kuti

M: seasons@falcon.sch.bme.hu

M: seasons@makosteszta.sote.hu

D: bug fixes, documentation, minor hackery

N: James Morris

E: jmorris@intercode.com.au

E: jmorris@redhat.com

W: http://www.intercode.com.au/jmorris/

D: Netfilter, Linux Security Modules (LSM).

D: Netfilter, Linux Security Modules (LSM), SELinux, IPSec,

D: Crypto API, general networking, miscellaneous.

S: PO Box 707

S: Spit Junction NSW 2088

S: Australia

X!Iinclude/linux/device.h

-->

!Edrivers/base/driver.c

!Edrivers/base/class_simple.c

!Edrivers/base/core.c

!Edrivers/base/firmware_class.c

!Edrivers/base/transport_class.c

platform_data: Platform data specific to the device.

	       Example:  for devices on custom boards, as typical of embedded

	       and SOC based hardware, Linux often uses platform_data to point

	       to board-specific structures describing devices and how they

	       are wired.  That can include what ports are available, chip

	       variants, which GPIO pins act in what additional roles, and so

	       on.  This shrinks the "Board Support Packages" (BSPs) and

	       minimizes board-specific #ifdefs in drivers.

current_state: Current power state of the device.

saved_state:   Pointer to saved state of the device. This is usable by

        char                    * name;

        struct bus_type         * bus;

        rwlock_t                lock;

        atomic_t                refcount;

        list_t                  bus_list;

        struct completion	unloaded;

        struct kobject		kobj;

        list_t                  devices;

        struct driver_dir_entry dir;

        struct module		*owner;

        int     (*probe)        (struct device * dev);

        int     (*remove)       (struct device * dev);

        int     (*suspend)      (struct device * dev, pm_message_t state, u32 level);

        int     (*resume)       (struct device * dev, u32 level);

        void    (*release)      (struct device_driver * drv);

};

static struct device_driver eepro100_driver = {

       .name		= "eepro100",

       .bus		= &pci_bus_type,

       .devclass	= &ethernet_devclass,	/* when it's implemented */

       .probe		= eepro100_probe,

       .remove		= eepro100_remove,

       .driver	       = {

		.name		= "eepro100",

		.bus		= &pci_bus_type,

		.devclass	= &ethernet_devclass,	/* when it's implemented */

		.probe		= eepro100_probe,

		.remove		= eepro100_remove,

		.suspend	= eepro100_suspend,

	int	(*probe)	(struct device * dev);

probe is called to verify the existence of a certain type of

hardware. This is called during the driver binding process, after the

bus has verified that the device ID of a device matches one of the

device IDs supported by the driver. 

This callback only verifies that there actually is supported hardware

present. It may allocate a driver-specific structure, but it should

not do any initialization of the hardware itself. The device-specific

structure may be stored in the device's driver_data field. 

	int	(*init)		(struct device * dev);

init is called during the binding stage. It is called after probe has

successfully returned and the device has been registered with its

class. It is responsible for initializing the hardware.

The probe() entry is called in task context, with the bus's rwsem locked

and the driver partially bound to the device.  Drivers commonly use

container_of() to convert "dev" to a bus-specific type, both in probe()

and other routines.  That type often provides device resource data, such

as pci_dev.resource[] or platform_device.resources, which is used in

addition to dev->platform_data to initialize the driver.

This callback holds the driver-specific logic to bind the driver to a

given device.  That includes verifying that the device is present, that

it's a version the driver can handle, that driver data structures can

be allocated and initialized, and that any hardware can be initialized.

Drivers often store a pointer to their state with dev_set_drvdata().

When the driver has successfully bound itself to that device, then probe()

returns zero and the driver model code will finish its part of binding

the driver to that device.

A driver's probe() may return a negative errno value to indicate that

the driver did not bind to this device, in which case it should have

released all reasources it allocated.

	int 	(*remove)	(struct device * dev);

remove is called to dissociate a driver with a device. This may be

remove is called to unbind a driver from a device. This may be

called if a device is physically removed from the system, if the

driver module is being unloaded, or during a reboot sequence. 

driver module is being unloaded, during a reboot sequence, or

in other cases.

It is up to the driver to determine if the device is present or

not. It should free any resources allocated specifically for the

Intel 830M/845G/852GM/855GM/865G/915G Framebuffer driver

================================================================

A. Introduction

	This is a framebuffer driver for various Intel 810/815 compatible

graphics devices.  These would include:

	Intel 830M

	Intel 810E845G

	Intel 852GM

	Intel 855GM

	Intel 865G

	Intel 915G

B.  List of available options

   a. "video=intelfb"

	enables the intelfb driver

	Recommendation: required

   b. "mode=<xres>x<yres>[-<bpp>][@<refresh>]"

	select mode

	Recommendation: user preference

	(default = 1024x768-32@70)

   c. "vram=<value>"

	select amount of system RAM in MB to allocate for the video memory

	if not enough RAM was already allocated by the BIOS.

	Recommendation: 1 - 4 MB.

	(default = 4 MB)

   d. "voffset=<value>"

        select at what offset in MB of the logical memory to allocate the

	framebuffer memory.  The intent is to avoid the memory blocks

	used by standard graphics applications (XFree86). Depending on your

        usage, adjust the value up or down, (0 for maximum usage, 63/127 MB

        for the least amount).  Note, an arbitrary setting may conflict

        with XFree86.

	Recommendation: do not set

	(default = 48 MB)

   e. "accel"

	enable text acceleration.  This can be enabled/reenabled anytime

	by using 'fbset -accel true/false'.

	Recommendation: enable

	(default = set)

   f. "hwcursor"

	enable cursor acceleration.

	Recommendation: enable

	(default = set)

   g. "mtrr"

	enable MTRR.  This allows data transfers to the framebuffer memory

	to occur in bursts which can significantly increase performance.

	Not very helpful with the intel chips because of 'shared memory'.

	Recommendation: set

	(default = set)

   h. "fixed"

	disable mode switching.

	Recommendation: do not set

	(default = not set)

   The binary parameters can be unset with a "no" prefix, example "noaccel".

   The default parameter (not named) is the mode.

C. Kernel booting

Separate each option/option-pair by commas (,) and the option from its value

with an equals sign (=) as in the following:

video=i810fb:option1,option2=value2

Sample Usage

------------

In /etc/lilo.conf, add the line:

append="video=intelfb:800x600-32@75,accel,hwcursor,vram=8"

This will initialize the framebuffer to 800x600 at 32bpp and 75Hz. The

framebuffer will use 8 MB of System RAM. hw acceleration of text and cursor

will be enabled.

D.  Module options

	The module parameters are essentially similar to the kernel

parameters. The main difference is that you need to include a Boolean value

(1 for TRUE, and 0 for FALSE) for those options which don't need a value.

Example, to enable MTRR, include "mtrr=1".

Sample Usage

------------

Using the same setup as described above, load the module like this:

	modprobe intelfb mode=800x600-32@75 vram=8 accel=1 hwcursor=1

Or just add the following to /etc/modprobe.conf

	options intelfb mode=800x600-32@75 vram=8 accel=1 hwcursor=1

and just do a

	modprobe intelfb

E.  Acknowledgment:

	1.  Geert Uytterhoeven - his excellent howto and the virtual

                                 framebuffer driver code made this possible.

	2.  Jeff Hartmann for his agpgart code.

	3.  David Dawes for his original kernel 2.4 code.

	4.  The X developers.  Insights were provided just by reading the

	    XFree86 source code.

	5.  Antonino A. Daplas for his inspiring i810fb driver.

	6.  Andrew Morton for his kernel patches maintenance.

###########################

Sylvain