Merge branch 'fix' of git://git.kernel.org/pub/scm/linux/kernel/git/ycmiao/pxa-linux-2.6

What:		/sys/firmware/sfi/tables/

Date:		May 2010

Contact:	Len Brown <lenb@kernel.org>

Description:

		SFI defines a number of small static memory tables

		so the kernel can get platform information from firmware.

		The tables are defined in the latest SFI specification:

		http://simplefirmware.org/documentation

		While the tables are used by the kernel, user-space

		can observe them this way:

		# cd /sys/firmware/sfi/tables

		# cat $TABLENAME > $TABLENAME.bin

they are entirely deprecated.  Some ports already do not provide these

as it is impossible to correctly support them.

			Handling Errors

DMA address space is limited on some architectures and an allocation

failure can be determined by:

- checking if dma_alloc_coherent returns NULL or dma_map_sg returns 0

- checking the returned dma_addr_t of dma_map_single and dma_map_page

  by using dma_mapping_error():

	dma_addr_t dma_handle;

	dma_handle = dma_map_single(dev, addr, size, direction);

	if (dma_mapping_error(dev, dma_handle)) {

		/*

		 * reduce current DMA mapping usage,

		 * delay and try again later or

		 * reset driver.

		 */

	}

Networking drivers must call dev_kfree_skb to free the socket buffer

and return NETDEV_TX_OK if the DMA mapping fails on the transmit hook

(ndo_start_xmit). This means that the socket buffer is just dropped in

the failure case.

SCSI drivers must return SCSI_MLQUEUE_HOST_BUSY if the DMA mapping

fails in the queuecommand hook. This means that the SCSI subsystem

passes the command to the driver again later.

		Optimizing Unmap State Space Consumption

On many platforms, dma_unmap_{single,page}() is simply a nop.

1) Struct scatterlist requirements.

   Struct scatterlist must contain, at a minimum, the following

   members:

	struct page *page;

	unsigned int offset;

	unsigned int length;

   The base address is specified by a "page+offset" pair.

   Previous versions of struct scatterlist contained a "void *address"

   field that was sometimes used instead of page+offset.  As of Linux

   2.5., page+offset is always used, and the "address" field has been

   deleted.

2) More to come...

			Handling Errors

DMA address space is limited on some architectures and an allocation

failure can be determined by:

- checking if dma_alloc_coherent returns NULL or dma_map_sg returns 0

- checking the returned dma_addr_t of dma_map_single and dma_map_page

  by using dma_mapping_error():

	dma_addr_t dma_handle;

	dma_handle = dma_map_single(dev, addr, size, direction);

	if (dma_mapping_error(dev, dma_handle)) {

		/*

		 * reduce current DMA mapping usage,

		 * delay and try again later or

		 * reset driver.

		 */

	}

   Don't invent the architecture specific struct scatterlist; just use

   <asm-generic/scatterlist.h>. You need to enable

   CONFIG_NEED_SG_DMA_LENGTH if the architecture supports IOMMUs

   (including software IOMMU).

2) ARCH_KMALLOC_MINALIGN

   Architectures must ensure that kmalloc'ed buffer is

   DMA-safe. Drivers and subsystems depend on it. If an architecture

   isn't fully DMA-coherent (i.e. hardware doesn't ensure that data in

   the CPU cache is identical to data in main memory),

   ARCH_KMALLOC_MINALIGN must be set so that the memory allocator

   makes sure that kmalloc'ed buffer doesn't share a cache line with

   the others. See arch/arm/include/asm/cache.h as an example.

   Note that ARCH_KMALLOC_MINALIGN is about DMA memory alignment

   constraints. You don't need to worry about the architecture data

   alignment constraints (e.g. the alignment constraints about 64-bit

   objects).

			   Closing

	ftp.??.kernel.org:/pub/linux/kernel/...

	?? == your country code, such as "us", "uk", "fr", etc.

	http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git

Linux kernel mailing list:

	linux-kernel@vger.kernel.org

	[mail majordomo@vger.kernel.org to subscribe]

Kernel Janitor:

	http://janitor.kernelnewbies.org/

GIT, Fast Version Control System:

	http://git-scm.com/

			APEI Error INJection

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

EINJ provides a hardware error injection mechanism

It is very useful for debugging and testing of other APEI and RAS features.

To use EINJ, make sure the following are enabled in your kernel

configuration:

CONFIG_DEBUG_FS

CONFIG_ACPI_APEI

CONFIG_ACPI_APEI_EINJ

The user interface of EINJ is debug file system, under the

directory apei/einj. The following files are provided.

- available_error_type

  Reading this file returns the error injection capability of the

  platform, that is, which error types are supported. The error type

  definition is as follow, the left field is the error type value, the

  right field is error description.

    0x00000001	Processor Correctable

    0x00000002	Processor Uncorrectable non-fatal

    0x00000004	Processor Uncorrectable fatal

    0x00000008  Memory Correctable

    0x00000010  Memory Uncorrectable non-fatal

    0x00000020  Memory Uncorrectable fatal

    0x00000040	PCI Express Correctable

    0x00000080	PCI Express Uncorrectable fatal

    0x00000100	PCI Express Uncorrectable non-fatal

    0x00000200	Platform Correctable

    0x00000400	Platform Uncorrectable non-fatal

    0x00000800	Platform Uncorrectable fatal

  The format of file contents are as above, except there are only the

  available error type lines.

- error_type

  This file is used to set the error type value. The error type value

  is defined in "available_error_type" description.

- error_inject

  Write any integer to this file to trigger the error

  injection. Before this, please specify all necessary error

  parameters.

- param1

  This file is used to set the first error parameter value. Effect of

  parameter depends on error_type specified. For memory error, this is

  physical memory address.

- param2

  This file is used to set the second error parameter value. Effect of

  parameter depends on error_type specified. For memory error, this is

  physical memory address mask.

For more information about EINJ, please refer to ACPI specification

version 4.0, section 17.5.

  of the s3c2410 GPIO system, please read the Samsung provided

  data-sheet/users manual to find out the complete list.

  See Documentation/arm/Samsung/GPIO.txt for the core implemetation.

GPIOLIB

-------

  listed below will be removed (they may be marked as __deprecated

  in the near future).

  - s3c2410_gpio_getpin

  - s3c2410_gpio_setpin

  The following functions now either have a s3c_ specific variant

  or are merged into gpiolib. See the definitions in

  arch/arm/plat-samsung/include/plat/gpio-cfg.h:

  s3c2410_gpio_setpin()		gpio_set_value() or gpio_direction_output()

  s3c2410_gpio_getpin()		gpio_get_value() or gpio_direction_input()

  s3c2410_gpio_getirq()		gpio_to_irq()

  s3c2410_gpio_cfgpin()		s3c_gpio_cfgpin()

  s3c2410_gpio_getcfg()		s3c_gpio_getcfg()

  s3c2410_gpio_pullup()		s3c_gpio_setpull()

GPIOLIB conversion

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

If you need to convert your board or driver to use gpiolib from the exiting

s3c2410 api, then here are some notes on the process.

1) If your board is exclusively using an GPIO, say to control peripheral

   power, then it will require to claim the gpio with gpio_request() before

   it can use it.

   It is recommended to check the return value, with at least WARN_ON()

   during initialisation.

2) The s3c2410_gpio_cfgpin() can be directly replaced with s3c_gpio_cfgpin()

   as they have the same arguments, and can either take the pin specific

   values, or the more generic special-function-number arguments.

3) s3c2410_gpio_pullup() changs have the problem that whilst the 

   s3c2410_gpio_pullup(x, 1) can be easily translated to the

   s3c_gpio_setpull(x, S3C_GPIO_PULL_NONE), the s3c2410_gpio_pullup(x, 0)

   are not so easy.

   The s3c2410_gpio_pullup(x, 0) case enables the pull-up (or in the case

   of some of the devices, a pull-down) and as such the new API distinguishes

   between the UP and DOWN case. There is currently no 'just turn on' setting

   which may be required if this becomes a problem.

4) s3c2410_gpio_setpin() can be replaced by gpio_set_value(), the old call

   does not implicitly configure the relevant gpio to output. The gpio

   direction should be changed before using gpio_set_value().

5) s3c2410_gpio_getpin() is replaceable by gpio_get_value() if the pin

   has been set to input. It is currently unknown what the behaviour is

   when using gpio_get_value() on an output pin (s3c2410_gpio_getpin

   would return the value the pin is supposed to be outputting).

6) s3c2410_gpio_getirq() should be directly replacable with the

   gpio_to_irq() call.

The s3c2410_gpio and gpio_ calls have always operated on the same gpio

numberspace, so there is no problem with converting the gpio numbering

between the calls.

Headers

  eg S3C2410_GPA(0) or S3C2410_GPF(1). These defines are used to tell

  the GPIO functions which pin is to be used.

  With the conversion to gpiolib, there is no longer a direct conversion

  from gpio pin number to register base address as in earlier kernels. This

  is due to the number space required for newer SoCs where the later

  GPIOs are not contiguous.

Configuring a pin

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

   which would turn GPA(0) into the lowest Address line A0, and set

   GPE(8) to be connected to the SDIO/MMC controller's SDDAT1 line.

   The s3c_gpio_cfgpin() call is a functional replacement for this call.

Reading the current configuration

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

  The return value will be from the same set of values which can be

  passed to s3c2410_gpio_cfgpin().

  The s3c_gpio_getcfg() call should be a functional replacement for

  this call.

Configuring a pull-up resistor

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

  Where the to value is zero to set the pull-up off, and 1 to enable

  the specified pull-up. Any other values are currently undefined.

  The s3c_gpio_setpull() offers similar functionality, but with the

  ability to encode whether the pull is up or down. Currently there

  is no 'just on' state, so up or down must be selected.

Getting the state of a PIN

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

  This will return either zero or non-zero. Do not count on this

  function returning 1 if the pin is set.

  This call is now implemented by the relevant gpiolib calls, convert

  your board or driver to use gpiolib.

Setting the state of a PIN

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

  Which sets the given pin to the value. Use 0 to write 0, and 1 to

  set the output to 1.

  This call is now implemented by the relevant gpiolib calls, convert

  your board or driver to use gpiolib.

Getting the IRQ number associated with a PIN

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

  Note, not all pins have an IRQ.

  This call is now implemented by the relevant gpiolib calls, convert

  your board or driver to use gpiolib.

Authour

-------