Merge branch 'perf/urgent' into perf/core, to pick up fixes

Jeff Garzik <jgarzik@pretzel.yyz.us>

Jens Axboe <axboe@suse.de>

Jens Osterkamp <Jens.Osterkamp@de.ibm.com>

John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>

John Stultz <johnstul@us.ibm.com>

<josh@joshtriplett.org> <josh@freedesktop.org>

<josh@joshtriplett.org> <josh@kernel.org>

- target-supply     : regulator for SATA target power

- phys              : reference to the SATA PHY node

- phy-names         : must be "sata-phy"

- ports-implemented : Mask that indicates which ports that the HBA supports

		      are available for software to use. Useful if PORTS_IMPL

		      is not programmed by the BIOS, which is true with

		      some embedded SOC's.

Required properties when using sub-nodes:

- #address-cells    : number of cells to encode an address

Optional properties:

- dual_emac_res_vlan	: Specifies VID to be used to segregate the ports

- mac-address		: See ethernet.txt file in the same directory

- phy_id		: Specifies slave phy id

- phy_id		: Specifies slave phy id (deprecated, use phy-handle)

- phy-handle		: See ethernet.txt file in the same directory

Slave sub-nodes:

- fixed-link		: See fixed-link.txt file in the same directory

			  Either the property phy_id, or the sub-node

			  fixed-link can be specified

Note: Exactly one of phy_id, phy-handle, or fixed-link must be specified.

Note: "ti,hwmods" field is used to fetch the base address and irq

resources from TI, omap hwmod data base during device registration.

using the SGDMA and MSGDMA soft DMA IP components. The driver uses the

platform bus to obtain component resources. The designs used to test this

driver were built for a Cyclone(R) V SOC FPGA board, a Cyclone(R) V FPGA board,

and tested with ARM and NIOS processor hosts seperately. The anticipated use

and tested with ARM and NIOS processor hosts separately. The anticipated use

cases are simple communications between an embedded system and an external peer

for status and simple configuration of the embedded system.

4.1) Transmit process

When the driver's transmit routine is called by the kernel, it sets up a

transmit descriptor by calling the underlying DMA transmit routine (SGDMA or

MSGDMA), and initites a transmit operation. Once the transmit is complete, an

MSGDMA), and initiates a transmit operation. Once the transmit is complete, an

interrupt is driven by the transmit DMA logic. The driver handles the transmit

completion in the context of the interrupt handling chain by recycling

resource required to send and track the requested transmit operation.

4.2) Receive process

The driver will post receive buffers to the receive DMA logic during driver

intialization. Receive buffers may or may not be queued depending upon the

initialization. Receive buffers may or may not be queued depending upon the

underlying DMA logic (MSGDMA is able queue receive buffers, SGDMA is not able

to queue receive buffers to the SGDMA receive logic). When a packet is

received, the DMA logic generates an interrupt. The driver handles a receive

LCO is a technique for efficiently computing the outer checksum of an

 encapsulated datagram when the inner checksum is due to be offloaded.

The ones-complement sum of a correctly checksummed TCP or UDP packet is

 equal to the sum of the pseudo header, because everything else gets

 'cancelled out' by the checksum field.  This is because the sum was

 equal to the complement of the sum of the pseudo header, because everything

 else gets 'cancelled out' by the checksum field.  This is because the sum was

 complemented before being written to the checksum field.

More generally, this holds in any case where the 'IP-style' ones complement

 checksum is used, and thus any checksum that TX Checksum Offload supports.

That is, if we have set up TX Checksum Offload with a start/offset pair, we

 know that _after the device has filled in that checksum_, the ones

 know that after the device has filled in that checksum, the ones

 complement sum from csum_start to the end of the packet will be equal to

 _whatever value we put in the checksum field beforehand_.  This allows us

 to compute the outer checksum without looking at the payload: we simply

 stop summing when we get to csum_start, then add the 16-bit word at

 (csum_start + csum_offset).

 the complement of whatever value we put in the checksum field beforehand.

 This allows us to compute the outer checksum without looking at the payload:

 we simply stop summing when we get to csum_start, then add the complement of

 the 16-bit word at (csum_start + csum_offset).

Then, when the true inner checksum is filled in (either by hardware or by

 skb_checksum_help()), the outer checksum will become correct by virtue of

 the arithmetic.