Merge branch 'linus' into perf/core

#include <linux/module.h>

#include <linux/moduleparam.h>

#include <linux/skbuff.h>

#include <linux/slab.h>

#include <linux/timer.h>

#include <linux/connector.h>

What is imacfb?

What is efifb?

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

This is a generic EFI platform driver for Intel based Apple computers.

Imacfb is only for EFI booted Intel Macs.

efifb is only for EFI booted Intel Macs.

Supported Hardware

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

How to use it?

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

Imacfb does not have any kind of autodetection of your machine.

efifb does not have any kind of autodetection of your machine.

You have to add the following kernel parameters in your elilo.conf:

	Macbook :

		video=imacfb:macbook

		video=efifb:macbook

	MacMini :

		video=imacfb:mini

		video=efifb:mini

	Macbook Pro 15", iMac 17" :

		video=imacfb:i17

		video=efifb:i17

	Macbook Pro 17", iMac 20" :

		video=imacfb:i20

		video=efifb:i20

--

Edgar Hucek <gimli@dark-green.com>

	mount -t 9p `namespace`/acme /mnt/9 -o trans=unix,uname=$USER

For server running on QEMU host with virtio transport:

	mount -t 9p -o trans=virtio <mount_tag> /mnt/9

where mount_tag is the tag associated by the server to each of the exported

mount points. Each 9P export is seen by the client as a virtio device with an

associated "mount_tag" property. Available mount tags can be

seen by reading /sys/bus/virtio/drivers/9pnet_virtio/virtio<n>/mount_tag files.

OPTIONS

=======

			fd   	- used passed file descriptors for connection

                                (see rfdno and wfdno)

			virtio	- connect to the next virtio channel available

				(from lguest or KVM with trans_virtio module)

				(from QEMU with trans_virtio module)

			rdma	- connect to a specified RDMA channel

  uname=name	user name to attempt mount as on the remote server.  The

  port=n	port to connect to on the remote server

  noextend	force legacy mode (no 9p2000.u semantics)

  noextend	force legacy mode (no 9p2000.u or 9p2000.L semantics)

  version=name	Select 9P protocol version. Valid options are:

			9p2000          - Legacy mode (same as noextend)

			9p2000.u        - Use 9P2000.u protocol

			9p2000.L        - Use 9P2000.L protocol

  dfltuid	attempt to mount as a particular uid

       STMicroelectronics 10/100/1000 Synopsys Ethernet driver

Copyright (C) 2007-2010  STMicroelectronics Ltd

Author: Giuseppe Cavallaro <peppe.cavallaro@st.com>

This is the driver for the MAC 10/100/1000 on-chip Ethernet controllers

(Synopsys IP blocks); it has been fully tested on STLinux platforms.

Currently this network device driver is for all STM embedded MAC/GMAC

(7xxx SoCs).

DWC Ether MAC 10/100/1000 Universal version 3.41a and DWC Ether MAC 10/100

Universal version 4.0 have been used for developing the first code

implementation.

Please, for more information also visit: www.stlinux.com

1) Kernel Configuration

The kernel configuration option is STMMAC_ETH:

 Device Drivers ---> Network device support ---> Ethernet (1000 Mbit) --->

 STMicroelectronics 10/100/1000 Ethernet driver (STMMAC_ETH)

2) Driver parameters list:

	debug: message level (0: no output, 16: all);

	phyaddr: to manually provide the physical address to the PHY device;

	dma_rxsize: DMA rx ring size;

	dma_txsize: DMA tx ring size;

	buf_sz: DMA buffer size;

	tc: control the HW FIFO threshold;

	tx_coe: Enable/Disable Tx Checksum Offload engine;

	watchdog: transmit timeout (in milliseconds);

	flow_ctrl: Flow control ability [on/off];

	pause: Flow Control Pause Time;

	tmrate: timer period (only if timer optimisation is configured).

3) Command line options

Driver parameters can be also passed in command line by using:

	stmmaceth=dma_rxsize:128,dma_txsize:512

4) Driver information and notes

4.1) Transmit process

The xmit method is invoked when the kernel needs to transmit a packet; it sets

the descriptors in the ring and informs the DMA engine that there is a packet

ready to be transmitted.

Once the controller has finished transmitting the packet, an interrupt is

triggered; So the driver will be able to release the socket buffers.

By default, the driver sets the NETIF_F_SG bit in the features field of the

net_device structure enabling the scatter/gather feature.

4.2) Receive process

When one or more packets are received, an interrupt happens. The interrupts

are not queued so the driver has to scan all the descriptors in the ring during

the receive process.

This is based on NAPI so the interrupt handler signals only if there is work to be

done, and it exits.

Then the poll method will be scheduled at some future point.

The incoming packets are stored, by the DMA, in a list of pre-allocated socket

buffers in order to avoid the memcpy (Zero-copy).

4.3) Timer-Driver Interrupt

Instead of having the device that asynchronously notifies the frame receptions, the

driver configures a timer to generate an interrupt at regular intervals.

Based on the granularity of the timer, the frames that are received by the device

will experience different levels of latency. Some NICs have dedicated timer

device to perform this task. STMMAC can use either the RTC device or the TMU

channel 2  on STLinux platforms.

The timers frequency can be passed to the driver as parameter; when change it,

take care of both hardware capability and network stability/performance impact.

Several performance tests on STM platforms showed this optimisation allows to spare

the CPU while having the maximum throughput.

4.4) WOL

Wake up on Lan feature through Magic Frame is only supported for the GMAC

core.

4.5) DMA descriptors

Driver handles both normal and enhanced descriptors. The latter has been only

tested on DWC Ether MAC 10/100/1000 Universal version 3.41a.

4.6) Ethtool support

Ethtool is supported. Driver statistics and internal errors can be taken using:

ethtool -S ethX command. It is possible to dump registers etc.

4.7) Jumbo and Segmentation Offloading

Jumbo frames are supported and tested for the GMAC.

The GSO has been also added but it's performed in software.

LRO is not supported.

4.8) Physical

The driver is compatible with PAL to work with PHY and GPHY devices.

4.9) Platform information

Several information came from the platform; please refer to the

driver's Header file in include/linux directory.

struct plat_stmmacenet_data {

        int bus_id;

        int pbl;

        int has_gmac;

        void (*fix_mac_speed)(void *priv, unsigned int speed);

        void (*bus_setup)(unsigned long ioaddr);

#ifdef CONFIG_STM_DRIVERS

        struct stm_pad_config *pad_config;

#endif

        void *bsp_priv;

};

Where:

- pbl (Programmable Burst Length) is maximum number of

  beats to be transferred in one DMA transaction.

  GMAC also enables the 4xPBL by default.

- fix_mac_speed and bus_setup are used to configure internal target

  registers (on STM platforms);

- has_gmac: GMAC core is on board (get it at run-time in the next step);

- bus_id: bus identifier.

struct plat_stmmacphy_data {

        int bus_id;

        int phy_addr;

        unsigned int phy_mask;

        int interface;

        int (*phy_reset)(void *priv);

        void *priv;

};

Where:

- bus_id: bus identifier;

- phy_addr: physical address used for the attached phy device;

            set it to -1 to get it at run-time;

- interface: physical MII interface mode;

- phy_reset: hook to reset HW function.

TODO:

- Continue to make the driver more generic and suitable for other Synopsys

  Ethernet controllers used on other architectures (i.e. ARM).

- 10G controllers are not supported.

- MAC uses Normal descriptors and GMAC uses enhanced ones.

  This is a limit that should be reviewed. MAC could want to

  use the enhanced structure.

- Checksumming: Rx/Tx csum is done in HW in case of GMAC only.

- Review the timer optimisation code to use an embedded device that seems to be

  available in new chip generations.

- fsl,qe-num-snums: define how many serial number(SNUM) the QE can use for the

  threads.

Optional properties:

- fsl,firmware-phandle:

    Usage: required only if there is no fsl,qe-firmware child node

    Value type: <phandle>

    Definition: Points to a firmware node (see "QE Firmware Node" below)

        that contains the firmware that should be uploaded for this QE.

        The compatible property for the firmware node should say,

        "fsl,qe-firmware".

Recommended properties

- brg-frequency : the internal clock source frequency for baud-rate

  generators in Hz.

		reg = <0 c000>;

	};

     };

* QE Firmware Node

This node defines a firmware binary that is embedded in the device tree, for

the purpose of passing the firmware from bootloader to the kernel, or from

the hypervisor to the guest.

The firmware node itself contains the firmware binary contents, a compatible

property, and any firmware-specific properties.  The node should be placed

inside a QE node that needs it.  Doing so eliminates the need for a

fsl,firmware-phandle property.  Other QE nodes that need the same firmware

should define an fsl,firmware-phandle property that points to the firmware node

in the first QE node.

The fsl,firmware property can be specified in the DTS (possibly using incbin)

or can be inserted by the boot loader at boot time.

Required properties:

  - compatible

      Usage: required

      Value type: <string>

      Definition: A standard property.  Specify a string that indicates what

          kind of firmware it is.  For QE, this should be "fsl,qe-firmware".

   - fsl,firmware

      Usage: required

      Value type: <prop-encoded-array>, encoded as an array of bytes

      Definition: A standard property.  This property contains the firmware

          binary "blob".

Example:

	qe1@e0080000 {

		compatible = "fsl,qe";

		qe_firmware:qe-firmware {

			compatible = "fsl,qe-firmware";

			fsl,firmware = [0x70 0xcd 0x00 0x00 0x01 0x46 0x45 ...];

		};

		...

	};

	qe2@e0090000 {

		compatible = "fsl,qe";

		fsl,firmware-phandle = <&qe_firmware>;

		...

	};