diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/i2c/busses/i2c-i801 | 60 | ||||
| -rw-r--r-- | Documentation/i2c/busses/i2c-parport | 15 | ||||
| -rw-r--r-- | Documentation/i2c/busses/i2c-piix4 | 2 | ||||
| -rw-r--r-- | Documentation/i2c/busses/i2c-viapro | 7 | ||||
| -rw-r--r-- | Documentation/i2c/porting-clients | 6 | ||||
| -rw-r--r-- | Documentation/i2c/smbus-protocol | 2 | ||||
| -rw-r--r-- | Documentation/i2c/writing-clients | 58 | ||||
| -rw-r--r-- | Documentation/powerpc/booting-without-of.txt | 4 | ||||
| -rw-r--r-- | Documentation/powerpc/mpc52xx-device-tree-bindings.txt | 183 |
9 files changed, 259 insertions, 78 deletions
diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801 index 3db69a086c41..c34f0db78a30 100644 --- a/Documentation/i2c/busses/i2c-i801 +++ b/Documentation/i2c/busses/i2c-i801 @@ -48,14 +48,9 @@ following: The SMBus controller is function 3 in device 1f. Class 0c05 is SMBus Serial Controller. -If you do NOT see the 24x3 device at function 3, and you can't figure out -any way in the BIOS to enable it, - The ICH chips are quite similar to Intel's PIIX4 chip, at least in the SMBus controller. -See the file i2c-piix4 for some additional information. - Process Call Support -------------------- @@ -74,6 +69,61 @@ SMBus 2.0 Support The 82801DB (ICH4) and later chips support several SMBus 2.0 features. + +Hidden ICH SMBus +---------------- + +If your system has an Intel ICH south bridge, but you do NOT see the +SMBus device at 00:1f.3 in lspci, and you can't figure out any way in the +BIOS to enable it, it means it has been hidden by the BIOS code. Asus is +well known for first doing this on their P4B motherboard, and many other +boards after that. Some vendor machines are affected as well. + +The first thing to try is the "i2c_ec" ACPI driver. It could be that the +SMBus was hidden on purpose because it'll be driven by ACPI. If the +i2c_ec driver works for you, just forget about the i2c-i801 driver and +don't try to unhide the ICH SMBus. Even if i2c_ec doesn't work, you +better make sure that the SMBus isn't used by the ACPI code. Try loading +the "fan" and "thermal" drivers, and check in /proc/acpi/fan and +/proc/acpi/thermal_zone. If you find anything there, it's likely that +the ACPI is accessing the SMBus and it's safer not to unhide it. Only +once you are certain that ACPI isn't using the SMBus, you can attempt +to unhide it. + +In order to unhide the SMBus, we need to change the value of a PCI +register before the kernel enumerates the PCI devices. This is done in +drivers/pci/quirks.c, where all affected boards must be listed (see +function asus_hides_smbus_hostbridge.) If the SMBus device is missing, +and you think there's something interesting on the SMBus (e.g. a +hardware monitoring chip), you need to add your board to the list. + +The motherboard is identified using the subvendor and subdevice IDs of the +host bridge PCI device. Get yours with "lspci -n -v -s 00:00.0": + +00:00.0 Class 0600: 8086:2570 (rev 02) + Subsystem: 1043:80f2 + Flags: bus master, fast devsel, latency 0 + Memory at fc000000 (32-bit, prefetchable) [size=32M] + Capabilities: [e4] #09 [2106] + Capabilities: [a0] AGP version 3.0 + +Here the host bridge ID is 2570 (82865G/PE/P), the subvendor ID is 1043 +(Asus) and the subdevice ID is 80f2 (P4P800-X). You can find the symbolic +names for the bridge ID and the subvendor ID in include/linux/pci_ids.h, +and then add a case for your subdevice ID at the right place in +drivers/pci/quirks.c. Then please give it very good testing, to make sure +that the unhidden SMBus doesn't conflict with e.g. ACPI. + +If it works, proves useful (i.e. there are usable chips on the SMBus) +and seems safe, please submit a patch for inclusion into the kernel. + +Note: There's a useful script in lm_sensors 2.10.2 and later, named +unhide_ICH_SMBus (in prog/hotplug), which uses the fakephp driver to +temporarily unhide the SMBus without having to patch and recompile your +kernel. It's very convenient if you just want to check if there's +anything interesting on your hidden ICH SMBus. + + ********************** The lm_sensors project gratefully acknowledges the support of Texas Instruments in the initial development of this driver. diff --git a/Documentation/i2c/busses/i2c-parport b/Documentation/i2c/busses/i2c-parport index 77b995dfca22..dceaba1ad930 100644 --- a/Documentation/i2c/busses/i2c-parport +++ b/Documentation/i2c/busses/i2c-parport @@ -19,6 +19,7 @@ It currently supports the following devices: * (type=4) Analog Devices ADM1032 evaluation board * (type=5) Analog Devices evaluation boards: ADM1025, ADM1030, ADM1031 * (type=6) Barco LPT->DVI (K5800236) adapter + * (type=7) One For All JP1 parallel port adapter These devices use different pinout configurations, so you have to tell the driver what you have, using the type module parameter. There is no @@ -157,3 +158,17 @@ many more, using /dev/velleman. http://home.wanadoo.nl/hihihi/libk8005.htm http://struyve.mine.nu:8080/index.php?block=k8000 http://sourceforge.net/projects/libk8005/ + + +One For All JP1 parallel port adapter +------------------------------------- + +The JP1 project revolves around a set of remote controls which expose +the I2C bus their internal configuration EEPROM lives on via a 6 pin +jumper in the battery compartment. More details can be found at: + +http://www.hifi-remote.com/jp1/ + +Details of the simple parallel port hardware can be found at: + +http://www.hifi-remote.com/jp1/hardware.shtml diff --git a/Documentation/i2c/busses/i2c-piix4 b/Documentation/i2c/busses/i2c-piix4 index 921476333235..7cbe43fa2701 100644 --- a/Documentation/i2c/busses/i2c-piix4 +++ b/Documentation/i2c/busses/i2c-piix4 @@ -6,7 +6,7 @@ Supported adapters: Datasheet: Publicly available at the Intel website * ServerWorks OSB4, CSB5, CSB6 and HT-1000 southbridges Datasheet: Only available via NDA from ServerWorks - * ATI IXP southbridges IXP200, IXP300, IXP400 + * ATI IXP200, IXP300, IXP400 and SB600 southbridges Datasheet: Not publicly available * Standard Microsystems (SMSC) SLC90E66 (Victory66) southbridge Datasheet: Publicly available at the SMSC website http://www.smsc.com diff --git a/Documentation/i2c/busses/i2c-viapro b/Documentation/i2c/busses/i2c-viapro index 25680346e0ac..775f489e86f6 100644 --- a/Documentation/i2c/busses/i2c-viapro +++ b/Documentation/i2c/busses/i2c-viapro @@ -13,6 +13,9 @@ Supported adapters: * VIA Technologies, Inc. VT8235, VT8237R, VT8237A, VT8251 Datasheet: available on request and under NDA from VIA + * VIA Technologies, Inc. CX700 + Datasheet: available on request and under NDA from VIA + Authors: Kyösti Mälkki <kmalkki@cc.hut.fi>, Mark D. Studebaker <mdsxyz123@yahoo.com>, @@ -44,6 +47,7 @@ Your lspci -n listing must show one of these : device 1106:3227 (VT8237R) device 1106:3337 (VT8237A) device 1106:3287 (VT8251) + device 1106:8324 (CX700) If none of these show up, you should look in the BIOS for settings like enable ACPI / SMBus or even USB. @@ -51,3 +55,6 @@ enable ACPI / SMBus or even USB. Except for the oldest chips (VT82C596A/B, VT82C686A and most probably VT8231), this driver supports I2C block transactions. Such transactions are mainly useful to read from and write to EEPROMs. + +The CX700 additionally appears to support SMBus PEC, although this driver +doesn't implement it yet. diff --git a/Documentation/i2c/porting-clients b/Documentation/i2c/porting-clients index f03c2a02f806..ca272b263a92 100644 --- a/Documentation/i2c/porting-clients +++ b/Documentation/i2c/porting-clients @@ -129,6 +129,12 @@ Technical changes: structure, those name member should be initialized to a driver name string. i2c_driver itself has no name member anymore. +* [Driver model] Instead of shutdown or reboot notifiers, provide a + shutdown() method in your driver. + +* [Power management] Use the driver model suspend() and resume() + callbacks instead of the obsolete pm_register() calls. + Coding policy: * [Copyright] Use (C), not (c), for copyright. diff --git a/Documentation/i2c/smbus-protocol b/Documentation/i2c/smbus-protocol index 09f5e5ca4927..8a653c60d25a 100644 --- a/Documentation/i2c/smbus-protocol +++ b/Documentation/i2c/smbus-protocol @@ -97,7 +97,7 @@ SMBus Write Word Data ===================== This is the opposite operation of the Read Word Data command. 16 bits -of data is read from a device, from a designated register that is +of data is written to a device, to the designated register that is specified through the Comm byte. S Addr Wr [A] Comm [A] DataLow [A] DataHigh [A] P diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients index 3a057c8e5507..fbcff96f4ca1 100644 --- a/Documentation/i2c/writing-clients +++ b/Documentation/i2c/writing-clients @@ -21,20 +21,26 @@ The driver structure Usually, you will implement a single driver structure, and instantiate all clients from it. Remember, a driver structure contains general access -routines, a client structure specific information like the actual I2C -address. +routines, and should be zero-initialized except for fields with data you +provide. A client structure holds device-specific information like the +driver model device node, and its I2C address. static struct i2c_driver foo_driver = { .driver = { .name = "foo", }, - .attach_adapter = &foo_attach_adapter, - .detach_client = &foo_detach_client, - .command = &foo_command /* may be NULL */ + .attach_adapter = foo_attach_adapter, + .detach_client = foo_detach_client, + .shutdown = foo_shutdown, /* optional */ + .suspend = foo_suspend, /* optional */ + .resume = foo_resume, /* optional */ + .command = foo_command, /* optional */ } -The name field must match the driver name, including the case. It must not -contain spaces, and may be up to 31 characters long. +The name field is the driver name, and must not contain spaces. It +should match the module name (if the driver can be compiled as a module), +although you can use MODULE_ALIAS (passing "foo" in this example) to add +another name for the module. All other fields are for call-back functions which will be explained below. @@ -43,11 +49,18 @@ below. Extra client data ================= -The client structure has a special `data' field that can point to any -structure at all. You can use this to keep client-specific data. You +Each client structure has a special `data' field that can point to any +structure at all. You should use this to keep device-specific data, +especially in drivers that handle multiple I2C or SMBUS devices. You do not always need this, but especially for `sensors' drivers, it can be very useful. + /* store the value */ + void i2c_set_clientdata(struct i2c_client *client, void *data); + + /* retrieve the value */ + void *i2c_get_clientdata(struct i2c_client *client); + An example structure is below. struct foo_data { @@ -493,6 +506,33 @@ by `__init_data'. Hose functions and structures can be removed after kernel booting (or module loading) is completed. +Power Management +================ + +If your I2C device needs special handling when entering a system low +power state -- like putting a transceiver into a low power mode, or +activating a system wakeup mechanism -- do that in the suspend() method. +The resume() method should reverse what the suspend() method does. + +These are standard driver model calls, and they work just like they +would for any other driver stack. The calls can sleep, and can use +I2C messaging to the device being suspended or resumed (since their +parent I2C adapter is active when these calls are issued, and IRQs +are still enabled). + + +System Shutdown +=============== + +If your I2C device needs special handling when the system shuts down +or reboots (including kexec) -- like turning something off -- use a +shutdown() method. + +Again, this is a standard driver model call, working just like it +would for any other driver stack: the calls can sleep, and can use +I2C messaging. + + Command function ================ diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt index 33994271cb3b..3b514672b80e 100644 --- a/Documentation/powerpc/booting-without-of.txt +++ b/Documentation/powerpc/booting-without-of.txt @@ -1334,6 +1334,9 @@ platforms are moved over to use the flattened-device-tree model. fsl-usb2-mph compatible controllers. Either this property or "port0" (or both) must be defined for "fsl-usb2-mph" compatible controllers. + - dr_mode : indicates the working mode for "fsl-usb2-dr" compatible + controllers. Can be "host", "peripheral", or "otg". Default to + "host" if not defined for backward compatibility. Recommended properties : - interrupts : <a b> where a is the interrupt number and b is a @@ -1367,6 +1370,7 @@ platforms are moved over to use the flattened-device-tree model. #size-cells = <0>; interrupt-parent = <700>; interrupts = <26 1>; + dr_mode = "otg"; phy = "ulpi"; }; diff --git a/Documentation/powerpc/mpc52xx-device-tree-bindings.txt b/Documentation/powerpc/mpc52xx-device-tree-bindings.txt index 69f016f02bb0..e59fcbbe338c 100644 --- a/Documentation/powerpc/mpc52xx-device-tree-bindings.txt +++ b/Documentation/powerpc/mpc52xx-device-tree-bindings.txt @@ -1,7 +1,7 @@ -MPC52xx Device Tree Bindings +MPC5200 Device Tree Bindings ---------------------------- -(c) 2006 Secret Lab Technologies Ltd +(c) 2006-2007 Secret Lab Technologies Ltd Grant Likely <grant.likely at secretlab.ca> ********** DRAFT *********** @@ -20,11 +20,11 @@ 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 +This document specifies the requirements on the device-tree for mpc5200 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 +All new mpc5200-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. @@ -32,26 +32,26 @@ 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 +special cases required to support a 5200 board. If all 5200 boards +follow the same convention, then generic 5200 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 -------------- +1. 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. +processors, 5200 device trees should use the name 'soc5200' for the +parent node of on chip devices, and the root node should be its parent. -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'. +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 ----------------------- @@ -66,28 +66,47 @@ exactly. 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. +the mpc5200, the required format for each compatible value is +<chip>-<device>[-<mode>]. The OS should be able to match a device driver +to the device based solely on the compatible value. If two drivers +match on the compatible list; the 'most compatible' driver should be +selected. + +The split between the MPC5200 and the MPC5200B leaves a bit of a +connundrum. How should the compatible property be set up to provide +maximum compatability information; but still acurately describe the +chip? For the MPC5200; the answer is easy. Most of the SoC devices +originally appeared on the MPC5200. Since they didn't exist anywhere +else; the 5200 compatible properties will contain only one item; +"mpc5200-<device>". + +The 5200B is almost the same as the 5200, but not quite. It fixes +silicon bugs and it adds a small number of enhancements. Most of the +devices either provide exactly the same interface as on the 5200. A few +devices have extra functions but still have a backwards compatible mode. +To express this infomation as completely as possible, 5200B device trees +should have two items in the compatible list; +"mpc5200b-<device>\0mpc5200-<device>". It is *strongly* recommended +that 5200B device trees follow this convention (instead of only listing +the base mpc5200 item). + +If another chip appear on the market with one of the mpc5200 SoC +devices, then the compatible list should include mpc5200-<device>. + +ie. ethernet on mpc5200: compatible = "mpc5200-ethernet" + ethernet on mpc5200b: compatible = "mpc5200b-ethernet\0mpc5200-ethernet" 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 +"mpc5200-psc-i2s", not "mpc5200-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 +function. For example, "mpc5200-spi" and "mpc5200-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"; +ie. mscan: compatible = "mpc5200-mscan\0fsl,mscan"; At the time of writing, exact chip may be either 'mpc5200' or 'mpc5200b'. @@ -96,7 +115,7 @@ 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 +The device tree for an mpc5200 board follows the structure defined in booting-without-of.txt with the following additional notes: 0) the root node @@ -115,7 +134,7 @@ Typical memory description node; see booting-without-of. 3) The soc5200 node ------------------- -This node describes the on chip SOC peripherals. Every mpc52xx based +This node describes the on chip SOC peripherals. Every mpc5200 based board will have this node, and as such there is a common naming convention for SOC devices. @@ -125,71 +144,111 @@ name type description device_type string must be "soc" ranges int should be <0 baseaddr baseaddr+10000> reg int must be <baseaddr 10000> +compatible string mpc5200: "mpc5200-soc" + mpc5200b: "mpc5200b-soc\0mpc5200-soc" +system-frequency int Fsystem frequency; source of all + other clocks. +bus-frequency int IPB bus frequency in HZ. Clock rate + used by most of the soc devices. +#interrupt-cells int must be <3>. 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. +model string Exact model of the chip; + ie: model="fsl,mpc5200" +revision string Silicon revision of chip + ie: revision="M08A" + +The 'model' and 'revision' properties are *strongly* recommended. Having +them presence acts as a bit of a safety net for working around as yet +undiscovered bugs on one version of silicon. For example, device drivers +can use the model and revision properties to decide if a bug fix should +be turned on. 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" +Note: The tables below show the value for the mpc5200. A mpc5200b device +tree should use the "mpc5200b-<device>\0mpc5200-<device> form. Required soc5200 child nodes: name device_type compatible Description ---- ----------- ---------- ----------- -cdm@<addr> cdm *-cmd Clock Distribution -pic@<addr> interrupt-controller *-pic need an interrupt +cdm@<addr> cdm mpc5200-cmd Clock Distribution +pic@<addr> interrupt-controller mpc5200-pic need an interrupt controller to boot -bestcomm@<addr> dma-controller *-bestcomm 52xx pic also requires - the bestcomm device +bestcomm@<addr> dma-controller mpc5200-bestcomm 5200 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> sound *-psc-i2s PSC in i2s mode -ac97@<addr> sound *-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 +name device_type compatible Description +---- ----------- ---------- ----------- +gpt@<addr> gpt mpc5200-gpt General purpose timers +rtc@<addr> rtc mpc5200-rtc Real time clock +mscan@<addr> mscan mpc5200-mscan CAN bus controller +pci@<addr> pci mpc5200-pci PCI bridge +serial@<addr> serial mpc5200-psc-uart PSC in serial mode +i2s@<addr> sound mpc5200-psc-i2s PSC in i2s mode +ac97@<addr> sound mpc5200-psc-ac97 PSC in ac97 mode +spi@<addr> spi mpc5200-psc-spi PSC in spi mode +irda@<addr> irda mpc5200-psc-irda PSC in IrDA mode +spi@<addr> spi mpc5200-spi MPC5200 spi device +ethernet@<addr> network mpc5200-fec MPC5200 ethernet device +ata@<addr> ata mpc5200-ata IDE ATA interface +i2c@<addr> i2c mpc5200-i2c I2C controller +usb@<addr> usb-ohci-be mpc5200-ohci,ohci-be USB controller +xlb@<addr> xlb mpc5200-xlb XLB arbritrator + +Important child node properties +name type description +---- ---- ----------- +cell-index int When multiple devices are present, is the + index of the device in the hardware (ie. There + are 6 PSC on the 5200 numbered PSC1 to PSC6) + PSC1 has 'cell-index = <0>' + PSC4 has 'cell-index = <3>' + +5) General Purpose Timer nodes (child of soc5200 node) +On the mpc5200 and 5200b, GPT0 has a watchdog timer function. If the board +design supports the internal wdt, then the device node for GPT0 should +include the empty property 'has-wdt'. + +6) PSC nodes (child of soc5200 node) +PSC nodes can define the optional 'port-number' property to force assignment +order of serial ports. For example, PSC5 might be physically connected to +the port labeled 'COM1' and PSC1 wired to 'COM1'. In this case, PSC5 would +have a "port-number = <0>" property, and PSC1 would have "port-number = <1>". + +PSC in i2s mode: The mpc5200 and mpc5200b PSCs are not compatible when in +i2s mode. An 'mpc5200b-psc-i2s' node cannot include 'mpc5200-psc-i2s' in the +compatible field. IV - Extra Notes ================ 1. Interrupt mapping -------------------- -The mpc52xx pic driver splits hardware IRQ numbers into two levels. The +The mpc5200 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 +The interrupts property for device nodes using the mpc5200 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] + +2. Shared registers +------------------- +Some SoC devices share registers between them. ie. the i2c devices use +a single clock control register, and almost all device are affected by +the port_config register. Devices which need to manipulate shared regs +should look to the parent SoC node. The soc node is responsible +for arbitrating all shared register access. |