Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6

    IBM Corp.

(c) 2005 Becky Bruce <becky.bruce at freescale.com>,

    Freescale Semiconductor, FSL SOC and 32-bit additions

(c) 2006 MontaVista Software, Inc.

    Flash chip node definition

   May 18, 2005: Rev 0.1 - Initial draft, no chapter III yet.

		};

	};

    g) Flash chip nodes

    Flash chips (Memory Technology Devices) are often used for solid state

    file systems on embedded devices.

    Required properties:

     - device_type : has to be "rom"

     - compatible : Should specify what this ROM device is compatible with

       (i.e. "onenand"). Currently, this is most likely to be "direct-mapped"

       (which corresponds to the MTD physmap mapping driver).

     - regs : Offset and length of the register set (or memory mapping) for

       the device.

    Recommended properties :

     - bank-width : Width of the flash data bus in bytes. Required

       for the NOR flashes (compatible == "direct-mapped" and others) ONLY.

     - partitions : Several pairs of 32-bit values where the first value is

       partition's offset from the start of the device and the second one is

       partition size in bytes with LSB used to signify a read only

       partititon (so, the parition size should always be an even number).

     - partition-names : The list of concatenated zero terminated strings

       representing the partition names.

   Example:

 	flash@ff000000 {

 		device_type = "rom";

 		compatible = "direct-mapped";

 		regs = <ff000000 01000000>;

 		bank-width = <4>;

 		partitions = <00000000 00f80000

 			      00f80000 00080001>;

 		partition-names = "fs\0firmware";

 	};

   More devices will be defined as this spec matures.

MPC52xx Device Tree Bindings

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

(c) 2006 Secret Lab Technologies Ltd

Grant Likely <grant.likely at secretlab.ca>

I - Introduction

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

Boards supported by the arch/powerpc architecture require device tree be

passed by the boot loader to the kernel at boot time.  The device tree

describes what devices are present on the board and how they are

connected.  The device tree can either be passed as a binary blob (as

described in Documentation/powerpc/booting-without-of.txt), or passed

by Open Firmare (IEEE 1275) compatible firmware using an OF compatible

client interface API.

This document specifies the requirements on the device-tree for mpc52xx

based boards.  These requirements are above and beyond the details

specified in either the OpenFirmware spec or booting-without-of.txt

All new mpc52xx-based boards are expected to match this document.  In

cases where this document is not sufficient to support a new board port,

this document should be updated as part of adding the new board support.

II - Philosophy

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

The core of this document is naming convention.  The whole point of

defining this convention is to reduce or eliminate the number of

special cases required to support a 52xx board.  If all 52xx boards

follow the same convention, then generic 52xx support code will work

rather than coding special cases for each new board.

This section tries to capture the thought process behind why the naming

convention is what it is.

1. Node names

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

There is strong convention/requirements already established for children

of the root node.  'cpus' describes the processor cores, 'memory'

describes memory, and 'chosen' provides boot configuration.  Other nodes

are added to describe devices attached to the processor local bus.

Following convention already established with other system-on-chip

processors, MPC52xx boards must have an 'soc5200' node as a child of the

root node.

The soc5200 node holds child nodes for all on chip devices.  Child nodes

are typically named after the configured function.  ie. the FEC node is

named 'ethernet', and a PSC in uart mode is named 'serial'.

2. device_type property

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

similar to the node name convention above; the device_type reflects the

configured function of a device.  ie. 'serial' for a uart and 'spi' for

an spi controller.  However, while node names *should* reflect the

configured function, device_type *must* match the configured function

exactly.

3. compatible property

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

Since device_type isn't enough to match devices to drivers, there also

needs to be a naming convention for the compatible property.  Compatible

is an list of device descriptions sorted from specific to generic.  For

the mpc52xx, the required format for each compatible value is

<chip>-<device>[-<mode>].  At the minimum, the list shall contain two

items; the first specifying the exact chip, and the second specifying

mpc52xx for the chip.

ie. ethernet on mpc5200b: compatible = "mpc5200b-ethernet\0mpc52xx-ethernet"

The idea here is that most drivers will match to the most generic field

in the compatible list (mpc52xx-*), but can also test the more specific

field for enabling bug fixes or extra features.

Modal devices, like PSCs, also append the configured function to the

end of the compatible field.  ie. A PSC in i2s mode would specify

"mpc52xx-psc-i2s", not "mpc52xx-i2s".  This convention is chosen to

avoid naming conflicts with non-psc devices providing the same

function.  For example, "mpc52xx-spi" and "mpc52xx-psc-spi" describe

the mpc5200 simple spi device and a PSC spi mode respectively.

If the soc device is more generic and present on other SOCs, the

compatible property can specify the more generic device type also.

ie. mscan: compatible = "mpc5200-mscan\0mpc52xx-mscan\0fsl,mscan";

At the time of writing, exact chip may be either 'mpc5200' or

'mpc5200b'.

Device drivers should always try to match as generically as possible.

III - Structure

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

The device tree for an mpc52xx board follows the structure defined in

booting-without-of.txt with the following additional notes:

0) the root node

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

Typical root description node; see booting-without-of

1) The cpus node

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

The cpus node follows the basic layout described in booting-without-of.

The bus-frequency property holds the XLB bus frequency

The clock-frequency property holds the core frequency

2) The memory node

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

Typical memory description node; see booting-without-of.

3) The soc5200 node

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

This node describes the on chip SOC peripherals.  Every mpc52xx based

board will have this node, and as such there is a common naming

convention for SOC devices.

Required properties:

name			type		description

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

device_type		string		must be "soc"

ranges			int		should be <0 baseaddr baseaddr+10000>

reg			int		must be <baseaddr 10000>

Recommended properties:

name			type		description

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

compatible		string		should be "<chip>-soc\0mpc52xx-soc"

					ie. "mpc5200b-soc\0mpc52xx-soc"

#interrupt-cells	int		must be <3>.  If it is not defined

					here then it must be defined in every

					soc device node.

bus-frequency		int		IPB bus frequency in HZ.  Clock rate

					used by most of the soc devices.

					Defining it here avoids needing it

					added to every device node.

4) soc5200 child nodes

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

Any on chip SOC devices available to Linux must appear as soc5200 child nodes.

Note: in the tables below, '*' matches all <chip> values.  ie.

*-pic would translate to "mpc5200-pic\0mpc52xx-pic"

Required soc5200 child nodes:

name		device_type		compatible	Description

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

cdm@<addr>	cdm			*-cmd		Clock Distribution

pic@<addr>	interrupt-controller	*-pic		need an interrupt

							controller to boot

bestcomm@<addr>	dma-controller		*-bestcomm	52xx pic also requires

							the bestcomm device

Recommended soc5200 child nodes; populate as needed for your board

name		device_type	compatible	Description

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

gpt@<addr>	gpt		*-gpt		General purpose timers

rtc@<addr>	rtc		*-rtc		Real time clock

mscan@<addr>	mscan		*-mscan		CAN bus controller

pci@<addr>	pci		*-pci		PCI bridge

serial@<addr>	serial		*-psc-uart	PSC in serial mode

i2s@<addr>	i2s		*-psc-i2s	PSC in i2s mode

ac97@<addr>	ac97		*-psc-ac97	PSC in ac97 mode

spi@<addr>	spi		*-psc-spi	PSC in spi mode

irda@<addr>	irda		*-psc-irda	PSC in IrDA mode

spi@<addr>	spi		*-spi		MPC52xx spi device

ethernet@<addr>	network		*-fec		MPC52xx ethernet device

ata@<addr>	ata		*-ata		IDE ATA interface

i2c@<addr>	i2c		*-i2c		I2C controller

usb@<addr>	usb-ohci-be	*-ohci,ohci-be	USB controller

xlb@<addr>	xlb		*-xlb		XLB arbritrator

IV - Extra Notes

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

1. Interrupt mapping

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

The mpc52xx pic driver splits hardware IRQ numbers into two levels.  The

split reflects the layout of the PIC hardware itself, which groups

interrupts into one of three groups; CRIT, MAIN or PERP.  Also, the

Bestcomm dma engine has it's own set of interrupt sources which are

cascaded off of peripheral interrupt 0, which the driver interprets as a

fourth group, SDMA.

The interrupts property for device nodes using the mpc52xx pic consists

of three cells; <L1 L2 level>

    L1 := [CRIT=0, MAIN=1, PERP=2, SDMA=3]

    L2 := interrupt number; directly mapped from the value in the

          "ICTL PerStat, MainStat, CritStat Encoded Register"

    level := [LEVEL_HIGH=0, EDGE_RISING=1, EDGE_FALLING=2, LEVEL_LOW=3]

  Note: While already known devices can be added to the list of devices to be

        ignored, there will be no effect on then. However, if such a device

        disappears and then reappeares, it will then be ignored.

	disappears and then reappears, it will then be ignored.

  For example,

	"echo add 0.0.a000-0.0.accc, 0.0.af00-0.0.afff > /proc/cio_ignore"

  devices.

  The devices can be specified either by bus id (0.0.abcd) or, for 2.4 backward

  compatibilty, by the device number in hexadecimal (0xabcd or abcd).

  compatibility, by the device number in hexadecimal (0xabcd or abcd).

* /proc/s390dbf/cio_*/ (S/390 debug feature)

Overview of Document:

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

This document is intended to give an good overview of how to debug 

This document is intended to give a good overview of how to debug

Linux for s/390 & z/Architecture. It isn't intended as a complete reference & not a

tutorial on the fundamentals of C & assembly. It doesn't go into

390 IO in any detail. It is intended to complement the documents in the

------

1) The only requirement is that registers which are used

by the callee are saved, e.g. the compiler is perfectly

capible of using r11 for purposes other than a frame a

capable of using r11 for purposes other than a frame a

frame pointer if a frame pointer is not needed.

2) In functions with variable arguments e.g. printf the calling procedure 

is identical to one without variable arguments & the same number of 

instead if the code isn't compiled -g, as it is much faster:

objdump --disassemble-all --syms vmlinux > vmlinux.lst  

As hard drive space is valuble most of us use the following approach.

As hard drive space is valuable most of us use the following approach.

1) Look at the emitted psw on the console to find the crash address in the kernel.

2) Look at the file System.map ( in the linux directory ) produced when building 

the kernel to find the closest address less than the current PSW to find the

to a file & on the screen.

Q. What use is it ?

A. You can used it to find out what files a particular program opens.

A. You can use it to find out what files a particular program opens.

If you wanted to know does ping work but didn't have the source 

strace ping -c 1 127.0.0.1  

& then look at the man pages for each of the syscalls below,

( In fact this is sometimes easier than looking at some spagetti

( In fact this is sometimes easier than looking at some spaghetti

source which conditionally compiles for several architectures ).

Not everything that it throws out needs to make sense immediately.

Performance Debugging

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

gcc is capible of compiling in profiling code just add the -p option

gcc is capable of compiling in profiling code just add the -p option

to the CFLAGS, this obviously affects program size & performance.

This can be used by the gprof gnu profiling tool or the

gcov the gnu code coverage tool ( code coverage is a means of testing

To issue a command to a particular cpu try cpu <cpu number> e.g.

CPU 01 TR I R 2000.3000

If you are running on a guest with several cpus & you have a IO related problem

& cannot follow the flow of code but you know it isnt smp related.

& cannot follow the flow of code but you know it isn't smp related.

from the bash prompt issue

shutdown -h now or halt.

do a Q CPUS to find out how many cpus you have

our 3rd return address is 8001085A

as the 04B52002 looks suspiciously like rubbish it is fair to assume that the kernel entry routines

for the sake of optimisation dont set up a backchain.

for the sake of optimisation don't set up a backchain.

now look at System.map to see if the addresses make any sense.

TEST SUBCHANNEL ) we use this as the ID of the device we wish to talk to, the most

important of these instructions are START SUBCHANNEL ( to start IO ), TEST SUBCHANNEL ( to check

whether the IO completed successfully ), & HALT SUBCHANNEL ( to kill IO ), a subchannel

can have up to 8 channel paths to a device this offers redunancy if one is not available.

can have up to 8 channel paths to a device this offers redundancy if one is not available.

Device Number:

also they are made up of a CHPID ( Channel Path ID, the most significant 8 bits ) 

& another lsb 8 bits. These remain static even if more devices are inserted or removed

from the hardware, there is a 1 to 1 mapping between Subchannels & Device Numbers provided

devices arent inserted or removed.

devices aren't inserted or removed.

Channel Control Words:

CCWS are linked lists of instructions initially pointed to by an operation request block (ORB),

from which you receive an Interruption response block (IRB). If you get channel & device end 

status in the IRB without channel checks etc. your IO probably went okay. If you didn't you

probably need a doctor to examine the IRB & extended status word etc.

If an error occurs, more sophistocated control units have a facitity known as

If an error occurs, more sophisticated control units have a facility known as

concurrent sense this means that if an error occurs Extended sense information will

be presented in the Extended status word in the IRB if not you have to issue a

subsequent SENSE CCW command after the test subchannel. 

directory:

Adds directories to be searched for source if gdb cannot find the source.

(note it is a bit sensititive about slashes) 

(note it is a bit sensitive about slashes)

e.g. To add the root of the filesystem to the searchpath do

directory //

current working directory.

This is very useful in that a customer can mail a core dump to a technical support department

& the technical support department can reconstruct what happened.

Provided the have an identical copy of this program with debugging symbols compiled in & 

Provided they have an identical copy of this program with debugging symbols compiled in &

the source base of this build is available.

In short it is far more useful than something like a crash log could ever hope to be.

Linux/390 common device support (CDS) provides to allow for device specific

driver implementations on the IBM ESA/390 hardware platform. Those interfaces

intend to provide the functionality required by every device driver

implementaion to allow to drive a specific hardware device on the ESA/390

implementation to allow to drive a specific hardware device on the ESA/390

platform. Some of the interface routines are specific to Linux/390 and some

of them can be found on other Linux platforms implementations too.

Miscellaneous function prototypes, data declarations, and macro definitions

provides a unified view of the devices physically attached to the systems.

Though the ESA/390 hardware platform knows about a huge variety of different

peripheral attachments like disk devices (aka. DASDs), tapes, communication

controllers, etc. they can all by accessed by a well defined access method and

controllers, etc. they can all be accessed by a well defined access method and

they are presenting I/O completion a unified way : I/O interruptions. Every

single device is uniquely identified to the system by a so called subchannel,

where the ESA/390 architecture allows for 64k devices be attached.

The ccw_device_start() function returns :

      0 - successful completion or request successfully initiated

-EBUSY  - The device is currently processing a previous I/O request, or ther is

-EBUSY	- The device is currently processing a previous I/O request, or there is

          a status pending at the device.

-ENODEV - cdev is invalid, the device is not operational or the ccw_device is

          not online.

-EIO:       the common I/O layer terminated the request due to an error state

If the concurrent sense flag in the extended status word in the irb is set, the

field irb->scsw.count describes the numer of device specific sense bytes

field irb->scsw.count describes the number of device specific sense bytes

available in the extended control word irb->scsw.ecw[0]. No device sensing by

the device driver itself is required.

The device driver is allowed to issue the next ccw_device_start() call from

within its interrupt handler already. It is not required to schedule a

bottom-half, unless an non deterministically long running error recovery procedure

bottom-half, unless a non deterministically long running error recovery procedure

or similar needs to be scheduled. During I/O processing the Linux/390 generic

I/O device driver support has already obtained the IRQ lock, i.e. the handler

must not try to obtain it again when calling ccw_device_start() or we end in a

case all I/O interruptions are presented to the device driver until final

status is recognized.

If a device is able to recover from asynchronosly presented I/O errors, it can

If a device is able to recover from asynchronously presented I/O errors, it can

perform overlapping I/O using the DOIO_EARLY_NOTIFICATION flag. While some

devices always report channel-end and device-end together, with a single

interrupt, others present primary status (channel-end) when the channel is