Merge branch 'x86-platform-for-linus' of...

CE4100 I2C

----------

CE4100 has one PCI device which is described as the I2C-Controller. This

PCI device has three PCI-bars, each bar contains a complete I2C

controller. So we have a total of three independent I2C-Controllers

which share only an interrupt line.

The driver is probed via the PCI-ID and is gathering the information of

attached devices from the devices tree.

Grant Likely recommended to use the ranges property to map the PCI-Bar

number to its physical address and to use this to find the child nodes

of the specific I2C controller. This were his exact words:

       Here's where the magic happens.  Each entry in

       ranges describes how the parent pci address space

       (middle group of 3) is translated to the local

       address space (first group of 2) and the size of

       each range (last cell).  In this particular case,

       the first cell of the local address is chosen to be

       1:1 mapped to the BARs, and the second is the

       offset from be base of the BAR (which would be

       non-zero if you had 2 or more devices mapped off

       the same BAR)

       ranges allows the address mapping to be described

       in a way that the OS can interpret without

       requiring custom device driver code.

This is an example which is used on FalconFalls:

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

	i2c-controller@b,2 {

		#address-cells = <2>;

		#size-cells = <1>;

		compatible = "pci8086,2e68.2",

				"pci8086,2e68",

				"pciclass,ff0000",

				"pciclass,ff00";

		reg = <0x15a00 0x0 0x0 0x0 0x0>;

		interrupts = <16 1>;

		/* as described by Grant, the first number in the group of

		* three is the bar number followed by the 64bit bar address

		* followed by size of the mapping. The bar address

		* requires also a valid translation in parents ranges

		* property.

		*/

		ranges = <0 0   0x02000000 0 0xdffe0500 0x100

			  1 0   0x02000000 0 0xdffe0600 0x100

			  2 0   0x02000000 0 0xdffe0700 0x100>;

		i2c@0 {

			#address-cells = <1>;

			#size-cells = <0>;

			compatible = "intel,ce4100-i2c-controller";

			/* The first number in the reg property is the

			* number of the bar

			*/

			reg = <0 0 0x100>;

			/* This I2C controller has no devices */

		};

		i2c@1 {

			#address-cells = <1>;

			#size-cells = <0>;

			compatible = "intel,ce4100-i2c-controller";

			reg = <1 0 0x100>;

			/* This I2C controller has one gpio controller */

			gpio@26 {

				#gpio-cells = <2>;

				compatible = "ti,pcf8575";

				reg = <0x26>;

				gpio-controller;

			};

		};

		i2c@2 {

			#address-cells = <1>;

			#size-cells = <0>;

			compatible = "intel,ce4100-i2c-controller";

			reg = <2 0 0x100>;

			gpio@26 {

				#gpio-cells = <2>;

				compatible = "ti,pcf8575";

				reg = <0x26>;

				gpio-controller;

			};

		};

	};

 Motorola mc146818 compatible RTC

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

Required properties:

  - compatible : "motorola,mc146818"

  - reg : should contain registers location and length.

Optional properties:

  - interrupts : should contain interrupt.

  - interrupt-parent : interrupt source phandle.

  - ctrl-reg : Contains the initial value of the control register also

    called "Register B".

  - freq-reg : Contains the initial value of the frequency register also

    called "Regsiter A".

"Register A" and "B" are usually initialized by the firmware (BIOS for

instance). If this is not done, it can be performed by the driver.

ISA Example:

	rtc@70 {

	         compatible = "motorola,mc146818";

	         interrupts = <8 3>;

	         interrupt-parent = <&ioapic1>;

	         ctrl-reg = <2>;

	         freq-reg = <0x26>;

	         reg = <1 0x70 2>;

	 };

CE4100 Device Tree Bindings

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

The CE4100 SoC uses for in core peripherals the following compatible

format: <vendor>,<chip>-<device>.

Many of the "generic" devices like HPET or IO APIC have the ce4100

name in their compatible property because they first appeared in this

SoC.

The CPU node

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

	cpu@0 {

		device_type = "cpu";

		compatible = "intel,ce4100";

		reg = <0>;

		lapic = <&lapic0>;

	};

The reg property describes the CPU number. The lapic property points to

the local APIC timer.

The SoC node

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

This node describes the in-core peripherals. Required property:

  compatible = "intel,ce4100-cp";

The PCI node

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

This node describes the PCI bus on the SoC. Its property should be

  compatible = "intel,ce4100-pci", "pci";

If the OS is using the IO-APIC for interrupt routing then the reported

interrupt numbers for devices is no longer true. In order to obtain the

correct interrupt number, the child node which represents the device has

to contain the interrupt property. Besides the interrupt property it has

to contain at least the reg property containing the PCI bus address and

compatible property according to "PCI Bus Binding Revision 2.1".

Interrupt chips

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

* Intel I/O Advanced Programmable Interrupt Controller (IO APIC)

  Required properties:

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

     compatible = "intel,ce4100-ioapic";

     #interrupt-cells = <2>;

  Device's interrupt property:

     interrupts = <P S>;

  The first number (P) represents the interrupt pin which is wired to the

  IO APIC. The second number (S) represents the sense of interrupt which

  should be configured and can be one of:

    0 - Edge Rising

    1 - Level Low

    2 - Level High

    3 - Edge Falling

* Local APIC

  Required property:

     compatible = "intel,ce4100-lapic";

Timers

------

* High Precision Event Timer (HPET)

  Required property:

     compatible = "intel,ce4100-hpet";