1. 02 5月, 2012 1 次提交
  2. 14 3月, 2012 1 次提交
  3. 10 2月, 2012 2 次提交
  4. 23 12月, 2011 1 次提交
  5. 28 11月, 2011 1 次提交
  6. 27 11月, 2011 1 次提交
  7. 27 9月, 2011 1 次提交
  8. 10 9月, 2011 4 次提交
  9. 29 6月, 2011 6 次提交
  10. 18 5月, 2011 1 次提交
    • O
      staging/mei: PCI device and char driver support. · ab841160
      Oren Weil 提交于
      contains module entries and PCI driver and char device
      definitions (using file_operations, pci_driver struts).
      
      The HW interface is exposed on PCI interface.
      PCI:
      	The MEI HW resources are memory map 32 bit registers
      	(Host and ME Status Registers and Data Registers)
      	and interrupt (shared, with Intel GFX on some chipsets
      	and USB2 controller on others).
      	The device is part of the chipsets and cannot be hotplugged.
      	The MEI device present is determined by BIOS configuration.
      
      Probe:
      	The driver starts the init MEI flow, that is explained
      	in the patch "MEI driver init flow" [06/10],
      	then schedules a timer that handles
      	timeouts and watchdog heartbeats.
      
      Remove:
      	The driver closes all connections and stops the watchdog.
      
      The driver expose char device that supports:
      	open, release, write, read, ioctl, poll.
      
      Open:
      	Upon open the driver allocates HOST data structure
      	on behalf of application which will resides in the file's
      	private data and assign a host ID number which
      	will identify messages between driver client instance
      	and MEI client.
      
      	The driver also checks readiness of the device. The number
      	of simultaneously opened instances is limited to 253.
      	(255 - (amthi + watchdog))
      
      Release:
      	In release the driver sends a Disconnect Command to
      	ME feature and clean all the data structs.
      
      IOCTL:
      	MEI adds new IOCTL: (IOCTL_MEI_CONNECT_CLIENT)
      	The IOCTL links the current file descriptor to ME feature.
      	This is done by sending MEI Bus command: 'hbm_client_connect_request'
      	to the ME and waiting for an answer :'hbm_client_connect_response'.
      	Upon answer reception the driver updates its and HOST data
      	structures in file structure to indicate that the file
      	descriptor is associated to ME feature.
      
      	Each ME feature is represented by UUID which is given as
      	an input parameter to the IOCTL, upon success connect command the
      	IOCTL will return the ME feature properties.
      	ME can reject CONNECT commands due to several reasons,
      	most common are:
      		Invalid UUID ME or feature does not exists in ME.
      		No More Connection allowed to this is feature,
      		usually only one connection is allowed.
      
      Write:
      	Upon write, the driver splits the user data into several MEI
      	messages up to 512 bytes each and sends it to the HW.
      	If the user wants to write data to AMTHI ME feature then the
      	drivers routes the messages through AMTHI queues.
      
      Read:
      	In read the driver checks is a connection exists to
      	current file descriptor and then wait until a data is available.
      	Message might be received (by interrupt from ME) in multiple chunks.
      	Only complete message is released to the application.
      Poll:
      	Nothing special here. Waiting for see if we have
      	data available for reading.
      Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: NItzhak Tzeel-Krupp <itzhak.tzeel-krupp@intel.com>
      Signed-off-by: NOren Weil <oren.jer.weil@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      ab841160