Commit ae09f09e authored by Dave Airlie's avatar Dave Airlie
Browse files

Merge remote branch 'intel/drm-intel-next' of /ssd/git/drm-next into drm-core-next 

* 'intel/drm-intel-next' of /ssd/git/drm-next: (771 commits)
  drm/i915: Undo "Uncouple render/power ctx before suspending"
  drm/i915: Allow the application to choose the constant addressing mode
  drm/i915: dynamic render p-state support for Sandy Bridge
  drm/i915: Enable EI mode for RCx decision making on Sandybridge
  drm/i915/sdvo: Border and stall select became test bits in gen5
  drm/i915: Add Guess-o-matic for pageflip timestamping.
  drm/i915: Add support for precise vblank timestamping (v2)
  drm/i915: Add frame buffer compression on Sandybridge
  drm/i915: Add self-refresh support on Sandybridge
  drm/i915: Wait for vblank before unpinning old fb
  Revert "drm/i915: Avoid using PIPE_CONTROL on Ironlake"
  drm/i915: Pass clock limits down to PLL matcher
  drm/i915: Poll for seqno completion if IRQ is disabled
  drm/i915/ringbuffer: Make IRQ refcnting atomic
  agp/intel: Fix missed cached memory flags setting in i965_write_entry()
  drm/i915/sdvo: Only use the SDVO pin if it is in the valid range
  drm/i915: Enable RC6 autodownclocking on Sandybridge
  drm/i915: Terminate the FORCE WAKE after we have finished reading
  drm/i915/gtt: Clear the cachelines upon resume
  drm/i915: Restore GTT mapping first upon resume
  ...
parents 1d99e5c5 5909a77a

Documentation/ABI/testing/sysfs-bus-rbd

0 → 100644
+83 −0
Original line number Diff line number Diff line 
What:		/sys/bus/rbd/

Date:		November 2010

Contact:	Yehuda Sadeh <yehuda@hq.newdream.net>,

		Sage Weil <sage@newdream.net>

Description:



Being used for adding and removing rbd block devices.



Usage: <mon ip addr> <options> <pool name> <rbd image name> [snap name]



 $ echo "192.168.0.1 name=admin rbd foo" > /sys/bus/rbd/add



The snapshot name can be "-" or omitted to map the image read/write. A <dev-id>

will be assigned for any registered block device. If snapshot is used, it will

be mapped read-only.



Removal of a device:



  $ echo <dev-id> > /sys/bus/rbd/remove



Entries under /sys/bus/rbd/devices/<dev-id>/

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



client_id



	The ceph unique client id that was assigned for this specific session.



major



	The block device major number.



name



	The name of the rbd image.



pool



	The pool where this rbd image resides. The pool-name pair is unique

	per rados system.



size



	The size (in bytes) of the mapped block device.



refresh



	Writing to this file will reread the image header data and set

	all relevant datastructures accordingly.



current_snap



	The current snapshot for which the device is mapped.



create_snap



	Create a snapshot:



	 $ echo <snap-name> > /sys/bus/rbd/devices/<dev-id>/snap_create



rollback_snap



	Rolls back data to the specified snapshot. This goes over the entire

	list of rados blocks and sends a rollback command to each.



	 $ echo <snap-name> > /sys/bus/rbd/devices/<dev-id>/snap_rollback



snap_*



	A directory per each snapshot





Entries under /sys/bus/rbd/devices/<dev-id>/snap_<snap-name>

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



id



	The rados internal snapshot id assigned for this snapshot



size



	The size of the image when this snapshot was taken.

Documentation/ABI/testing/sysfs-platform-asus-laptop

+15 −1
Original line number Diff line number Diff line
@@ -47,6 +47,20 @@ Date: January 2007 
KernelVersion:	2.6.20

Contact:	"Corentin Chary" <corentincj@iksaif.net>

Description:

		Control the bluetooth device. 1 means on, 0 means off.

		Control the wlan device. 1 means on, 0 means off.

		This may control the led, the device or both.

Users:		Lapsus



What:		/sys/devices/platform/asus_laptop/wimax

Date:		October 2010

KernelVersion:	2.6.37

Contact:	"Corentin Chary" <corentincj@iksaif.net>

Description:

		Control the wimax device. 1 means on, 0 means off.



What:		/sys/devices/platform/asus_laptop/wwan

Date:		October 2010

KernelVersion:	2.6.37

Contact:	"Corentin Chary" <corentincj@iksaif.net>

Description:

		Control the wwan (3G) device. 1 means on, 0 means off.

Documentation/ABI/testing/sysfs-platform-eeepc-wmi

0 → 100644
+10 −0
Original line number Diff line number Diff line 
What:		/sys/devices/platform/eeepc-wmi/cpufv

Date:		Oct 2010

KernelVersion:	2.6.37

Contact:	"Corentin Chary" <corentincj@iksaif.net>

Description:

		Change CPU clock configuration (write-only).

		There are three available clock configuration:

		    * 0 -> Super Performance Mode

		    * 1 -> High Performance Mode

		    * 2 -> Power Saving Mode

Documentation/DocBook/sh.tmpl

+0 −4
Original line number Diff line number Diff line
@@ -79,10 +79,6 @@ 
      </sect2>

    </sect1>

  </chapter>

  <chapter id="clk">

    <title>Clock Framework Extensions</title>

!Iinclude/linux/sh_clk.h

  </chapter>

  <chapter id="mach">

    <title>Machine Specific Interfaces</title>

    <sect1 id="dreamcast">

Documentation/driver-model/interface.txt

deleted100644 → 0
+0 −129
Original line number Diff line number Diff line 


Device Interfaces



Introduction

~~~~~~~~~~~~



Device interfaces are the logical interfaces of device classes that correlate

directly to userspace interfaces, like device nodes. 

   

Each device class may have multiple interfaces through which you can 

access the same device. An input device may support the mouse interface, 

the 'evdev' interface, and the touchscreen interface. A SCSI disk would 

support the disk interface, the SCSI generic interface, and possibly a raw 

device interface. 



Device interfaces are registered with the class they belong to. As devices

are added to the class, they are added to each interface registered with

the class. The interface is responsible for determining whether the device

supports the interface or not. 





Programming Interface

~~~~~~~~~~~~~~~~~~~~~



struct device_interface {

	char			* name;

	rwlock_t		lock;

	u32			devnum;

	struct device_class	* devclass;



	struct list_head	node;

	struct driver_dir_entry	dir;



	int (*add_device)(struct device *);

	int (*add_device)(struct intf_data *);

};



int interface_register(struct device_interface *);

void interface_unregister(struct device_interface *);





An interface must specify the device class it belongs to. It is added

to that class's list of interfaces on registration.





Interfaces can be added to a device class at any time. Whenever it is

added, each device in the class is passed to the interface's

add_device callback. When an interface is removed, each device is

removed from the interface.





Devices

~~~~~~~

Once a device is added to a device class, it is added to each

interface that is registered with the device class. The class

is expected to place a class-specific data structure in 

struct device::class_data. The interface can use that (along with

other fields of struct device) to determine whether or not the driver

and/or device support that particular interface.





Data

~~~~



struct intf_data {

	struct list_head	node;

	struct device_interface	* intf;

	struct device 		* dev;

	u32			intf_num;

};



int interface_add_data(struct interface_data *);



The interface is responsible for allocating and initializing a struct 

intf_data and calling interface_add_data() to add it to the device's list

of interfaces it belongs to. This list will be iterated over when the device

is removed from the class (instead of all possible interfaces for a class).

This structure should probably be embedded in whatever per-device data 

structure the interface is allocating anyway.

   

Devices are enumerated within the interface. This happens in interface_add_data()

and the enumerated value is stored in the struct intf_data for that device. 



sysfs

~~~~~

Each interface is given a directory in the directory of the device

class it belongs to:



Interfaces get a directory in the class's directory as well:



   class/

   `-- input

       |-- devices

       |-- drivers

       |-- mouse

       `-- evdev



When a device is added to the interface, a symlink is created that points 

to the device's directory in the physical hierarchy:



   class/

   `-- input

       |-- devices

       |   `-- 1 -> ../../../root/pci0/00:1f.0/usb_bus/00:1f.2-1:0/

       |-- drivers

       |   `-- usb:usb_mouse -> ../../../bus/drivers/usb_mouse/

       |-- mouse

       |   `-- 1 -> ../../../root/pci0/00:1f.0/usb_bus/00:1f.2-1:0/

       `-- evdev

           `-- 1 -> ../../../root/pci0/00:1f.0/usb_bus/00:1f.2-1:0/





Future Plans

~~~~~~~~~~~~

A device interface is correlated directly with a userspace interface

for a device, specifically a device node. For instance, a SCSI disk

exposes at least two interfaces to userspace: the standard SCSI disk

interface and the SCSI generic interface. It might also export a raw

device interface. 



Many interfaces have a major number associated with them and each

device gets a minor number. Or, multiple interfaces might share one

major number, and each will receive a range of minor numbers (like in

the case of input devices).



These major and minor numbers could be stored in the interface

structure. Major and minor allocations could happen when the interface

is registered with the class, or via a helper function.

CRA Git | Maintained and supported by SUSTech CRA and CCSE