Linux Symposium
Contents
1. Although on big servers keeping track of the devices once they re discovered can be another matter At least in theory many ISA PnP implementations are buggy in practice 216 Linux Symposium tablished as yet 3 2 Embedded weirdness On embedded machines all the assumptions that are made on normal machines break down Embedded machines can and do have arbitrarily peculiar combinations of peripherals connected in a more or less ad hoc manner Often many of an embedded machine s pe ripherals are connected via an unconventional bus which provides no facilities for system atic scanning or probing of devices On the AOSLP this is true of both the on chip buses and the main external bus Devices can appear essentially anywhere within the CPU s phys ical address space Some times the address or other behaviour of a device is affected by a cus tom FPGA or other programmable logic device with its own control registers Device inter rupt lines introduce even more problems being routed in complex and arbitrary ways that are often controlled or masked by a board specific FPGA or CPLD Devices can sometimes have multiple dependencies on other devices for example on the eLAP audio is driven by the TI codec which is controlled and configured via the IC bus However the actual audio data is delivered to the codec via a serial connection to the on chip Codec Serial Interface CSI The CSI in turn depends on the2. Nearly all modern machines are based on PCI which like most modern buses is designed so that devices can be queried and configured in a standard way This makes it easy for the kernel to scan the PCI bus or buses determine what devices are present and their addresses and pass this information to the appropriate device drivers USB devices provide similar function ality as do PCMCIA and ISA PnP devices The few remaining devices including the PCI host bridge itself are usually standard to be found on all machines of this type and often nearly all machines of this architecture They can be found at well known addresses so the drivers for these devices simply hardcode this information On PCs non PnP ISA devices do introduce some problems In fact they demon strate a subset of the problems with embedded hardware that we will examine in the next sec tion Many non x86 machines make device discov ery even simpler with firmware support Open Firmware on IBM and Apple PowerPC ma chines and likewise its ancestor OpenPROM on Sun machines builds a tree with informa tion about each of the peripherals on the ma chine At boot time the kernel queries this in formation making a copy of the device tree which can later be used by drivers to find devices The ACPI BIOS found on recent Intel machines provides some similar infor mation although neither the ACPI implemen tations nor Linux s use of them is very well es
3. as we ll see a comprehensive better approach has yet to be implemented This method has some serious shortcomings The most obvious problems come with embed ded peripherals that are similar to ones also found in conventional machines For obvious reasons it is normal in this case to adapt the existing conventional driver for use in the em bedded machine Sometimes this has been done by adding ifdefs to the driver for the board specific code For example this has been done with the cs89x0 driver for the CrystalLAN CS8900 Ethernet chip This chip is used on some ISA cards but is also found on the Beech em bedded board another IBM reference board based on the 405LP Apart from the fact that ifdefs make the driver code ugly this clearly causes a problem if the embedded ma chine can also have a normal ISA or PCMCIA version of the device the kernel can t support both versions of the peripheral on the same ma chine Another method is to copy then modify the existing driver to make a version specific to a particular embedded machine The approach was taken for the arctic_enet driver for the Ethernet on the eLAP s debug sled The sled s Ethernet is based on an RTL8019 chip which is used in a number of ISA cards as well as several other embedded machines This method allows multiple versions of the de vice to be simultaneously supported but incurs the obvious maintenance problems of having several almost but
4. been work ing on board and device bringup for Linux on embedded PowerPC machines along with var ious bits of kernel infrastructure for cleanly supporting PowerPC 4xx and other system on chip CPUs He is also the author and main tainer of the orinoco driver for Prism II based 802 11b NICs In the past he has worked on ramfs as included in the ac kernel tree and esky a userspace implementation of check point resume Legal Statement This work represents the view of the author and does not necessarily represent the view of IBM IBM PowerPC PowerPC Architecture and pSeries are trademarks or registered trademarks of Interna tional Business Machines Corporation in the United States and or other countries Intel is a registered trademark of Intel Corporation in the United States other countries or both Linux is a registered trademark of Linus Torvalds Other company product and service names may be trademarks or service marks of others
5. includes a clock generation core that allows the clock frequency of the CPU core and also the PLB OPB and EBC buses to be altered dynamically The ra tios between the CPU and various bus frequen cies are not fixed so the chip can be adjusted differently for IO versus compute performance While a number of different CPUs allow the frequency to be changed while running the 405LP can change frequency exceptionally quickly microseconds which enables new power management techniques based on dy namically adjusting frequency based on work load and idle periods The 405LP can also op 222 e Linux Symposium erate at a variety of different voltages which can provide much greater power savings than just adjusting the frequency power consump tion varies roughly linearly with frequency and cubicly with voltage maximum frequency is roughly linear with voltage Another novel feature of the 405LP is that it can continue to operate albeit slowly in some cases while a voltage transition is in progress As well as supporting the 405LP s features the eLAP board has some extra power man agement features of its own A number of the on board devices such as the audio codec in clude the ability to power down some or all of their operations while not in use Other de vices such as the USB and SDIO chips can be powered down under the control of an FPGA register 5 2 Static power management We use the term static power management
6. 64M of M Systems Millennium Plus Disk on Chip APM Power management unit implements the CPU sleep suspend NAND flash with specialised controller states NB this is not related to the APM BIOS in PC laptops PCCF PCMCIA and Compact Flash controller Audio Codec Texas Instruments TLV320AIC23 stereo audio codec POB PLB to OPB bridge Battery ADC ADS7823 ADC monitoring battery voltage RTC Real Time Clock CPM Clock and Power Management unit SDIO Toshiba TC6380AF Secure Digital and SDIO inter CSI Codec Serial Interface interface to audio codec devices face DMAC DMA controller can DMA to from devices on both the PLB and SDRAM SDRAM controller OPB SLA Speech Label Accelerator hardware implementation EBC External Bus Controller of a particular speech recognition algorithm Ethernet MAC RTL8109 Ethernet controller TCPA Atmel AT97SC3201 TPM Frontlight Ctrl DS1050 LCD frontlight controller TDES Triple DES accelerator GPIO General Purpose IO interface TS Ctrl Semtech UR7HCT52_S840L touchscreen controller IIC 1C bus interface both master and slave capable UARTx _NS16550 compatible UARTs LED Ctrl BU8770KN tricolour LED driver UIC Universal Interrupt Controller LCDC LCD display controller USB Phillips ISP1161 USB interface includes both host controller and gadget side interface Figure 1 Block diagram of the eLAP 2 The PowerPC 405LP PDA refer ence design Most of the issues we discuss in this paper apply to many different embedded machines Howev
7. Reprinted from the Proceedings of the Linux Symposium July 23th 26th 2003 Ottawa Ontario Canada Conference Organizers Andrew J Hutton Steamballoon Inc Stephanie Donovan Linux Symposium C Craig Ross Linux Symposium Review Committee Alan Cox Red Hat Inc Andi Kleen SuSE GmbH Matthew Wilcox Hewlett Packard Gerrit Huizenga JBM Andrew J Hutton Steamballoon Inc C Craig Ross Linux Symposium Martin K Petersen Wild Open Source Inc Proceedings Formatting Team John W Lockhart Red Hat Inc Authors retain copyright to all submitted papers but have granted unlimited redistribution rights to all as a condition of submission Device discovery and power management in embedded systems David Gibson OzLabs IBM Linux Technology Center dwg aul ibm com Abstract This paper covers issues in device discovery and power management in embedded Linux systems In particular we focus on the IBM PowerPC 405LP a system on chip CPU designed for handheld applications and IBM s PDA reference design based upon it Peripher als in embedded systems are often connected in an ad hoc manner and are not on a bus which can be scanned or probed Thus the kernel must have knowledge of what devices are present built in at compile time We ex amine how the new unified device model pro vides a clean method for representing this in formation while allowing good re use of code from machine to machine
8. The 405LP includes a number of novel power management fea tures in particular the ability to very rapidly change CPU and bus frequencies We also ex amine how the device model provides a frame work for representing constraints the periph erals and their interconnections place upon al lowable frequencies and other information rel evant to power management 1 Introduction the device discov ery problem Device discovery is the process the kernel and its device drivers use to determine what pe ripheral devices are present in a machine and ols2003 gibson dropbear id au how to communicate with them Generally this means determining what IO addresses inter rupt lines and or other bus specific addresses and resources are associated with each device Usually there are a few peripherals that are present in every machine of a particular type Then there are optional devices that may or may not be installed in a particular machine Some of these may be added or removed only from one boot to the next and some may be hot pluggable added or removed while the ma chine is running The peripheral devices in an embedded ma chine often look very different to those in a conventional desktop or server Even when a similar peripheral is used differences in the way it is connected into the system can mean that it must be accessed and initialised quite differently Many assumptions that are made about devices in a normal machine cann
9. dentify the type of device This mim ics the vendor function pairs used to iden tify PCI and USB devices However in this case the ID values are not built into the de vice but are simply arbitrary values allocated in include asm ocp_ids h Drivers for the on chip peripherals register themselves when loaded using the ocp_register_ driver function and a table of OCP device from arch ppc platforms ibm405lp c struct ocp_def core_ocp __initdata vendor function index Arg pm vendor function index paddr irg pm vendor function index paddr irg pm vendor function paddr irg pm vendor function paddr irg pm vendor OCP_VENDOR_IBM OCP_FUNC_OPB 0 OCP_IRQ_NA OCP_CPM_NA OCP_VENDOR_IBM OCP_FUNC_16550 0 UARTO_IO_BASE UARTO_INT IBM_CPM_UARTO OCP_VENDOR_IBM OCP_FUNC_16550 1 UART1_IO_BASE UART1_INT IBM_CPM_UART1 OCP_VENDOR_IBM OCP_FUNC_IIC IICO_BASE I pD TICO IRO IBM_CPM_IICO OCP_VENDOR_IBM OCP_FUNC_GPIO GPIOO_BASE OCP_IROQ_NA F IBM_CPM_GPIOO OCP_VENDOR_INVALID Figure 2 OCP device table for 405LP Linux Symposium 2003 219 from include asm ocp h struct ocp_def unsigned int vendor unsigned int function int index phys_addr_t paddr int irq unsigned long pm void additions struct ocp_device st
10. e even more detailed information about the devices Since these constraints may well de pend on details of the hardware interconnects this is yet more information which the kernel must just know Again the unified device model provides an obvious framework in which to represent this information 4 discusses some methods for setting constraints within drivers A general approach to representing constraints in a way that is easily extensible to new boards is yet to be implemented and is likely to take consider able further investigation and development References 1 IBM Corporation PowerPC 405LP Embedded Processor User s Manual Preliminary 2002 2 IBM Corporation PowerPC 405GP Embedded Processor User s Manual Seventh Preliminary Edition 2000 3 IBM Corporation PowerNP NPe405H Network Processor User s Manual Preliminary 2002 4 a IBM and MontaVista Software Dynamic Power Management for Embedded Systems Version 1 0 http www research ibm com arl projects papers DPM_V1 1 pdf 2002 5 linuxppc_2_4 devel kemel tree bk ppc ppc bkbits net linuxppc_2_4 devel 6 linuxppc 2 4 kernel tree bk ppc ppc bkbits net linuxppc 2 4 7 PPCBoot homepage http ppcbhoot sourceforge net 224 e Linux Symposium About the author David Gibson is an employee of the IBM Linux Technology Center working from Canberra Australia Most recently he has
11. e slower On Board Peripheral bus OPB and the spe cial DCR bus The latter is used to implement Device Control Registers rather than using normal memory mapped IO some of the on chip devices use these special registers which are accessed using special machine instruc tions As shown the 405LP s peripherals in clude amongst other things an LCD controller a real time clock an C interface and two se rial ports Other 4xx chips can include devices such as Ethernet controllers HDLC interfaces PCI host bridges IDE and USB controllers The 405LP also includes a number of novel power management features which we ll ex amine in 5 In addition to the devices within the 405LP the eLAP includes 32MB of RAM 32MB of NOR Flash and a number of additional peripherals also shown in Figure 1 Most of these are con nected via a minimal bus driven by the 405LP s on chip External Bus Controller EBC unit An extra debug and development sled can be attached to the eLAP again shown in Figure 1 It includes an Ethernet controller the physi cal PCMCIA slot driven by the 405LP s PCCF core and the physical connectors for the USB host port and serial port Of course as well as the peripherals shown further devices can be attached via the PCMCIA and SDIO slots and the USB host interface 3 Current approaches 3 1 Conventional machines On normal server or workstation machines de vice discovery is mostly quite straightforward
12. er for simplicity we focus on one ex ample machine the PowerPC 405LP PDA ref erence design also known as the Embedded Linux Application Platform or eLAP As the name suggests this is a prototype reference de sign for a PDA based on the PowerPC 405LP CPU The IBM PowerPC 405LP is a CPU from the PowerPC 4xx family This series of CPUs is designed for system on chip embedded ap plications As the name suggests these proces sors are implementations of the PowerPC Ar chitecture however they have some notable differences from classic PPC CPUs as used in IBM pSeries servers and Apple worksta tions The 4xx CPUs operate at much lower clock rates and hence are cooler and cheaper although they are in the high end by embedded standards They have a much simpler MMU just a software loaded TLB and they have no Linux Symposium 2003 215 FPU More interestingly they include a num ber of peripheral devices built into the CPU die itself hence the term system on chip Different CPUs in the 4xx family are designed for different applications and have different collections of on chip peripherals The 405LP is designed for handheld battery powered ap plications Figure 1 shows a block diagram of the eLAP including the various built in peripherals of the 405LP The chip includes no less than three internal buses the high bandwidth Processor Local Bus PLB con nected directly to the CPU core th
13. es which are on a separate chip but which still can t be straightforwardly scanned or probed It seems worthwhile then to extend the idea of the OCP system to cover embedded devices more gener ally The Linux unified device model provides the obvious place to represent information about these devices at runtime it already provides the code for matching devices to drivers and its tree structure allows multiple buses with con figurable bridges between them to be repre sented It is not immediately clear how to represent everything that s needed in the device tree though While for many devices the physical address and IRQ number is all the informa tion that is needed some devices have mul tiple IRQs and or IO windows at discontinu ous addresses Some buses require different re source addresses for example many of the 4xx on chip devices need DCR numbers and I C devices need I C addresses rather than phys ical IO addresses Hence devices on differ ent buses are likely to need different wrappers around struct device providing different address information Even less obvious is how to represent devices with multiple connections such as the audio codec on the eLAP connected both the the C bus and to the CSI4 As yet the device model does not have a clear way to represent this Another as yet unanswered question is how the device information should be represented in the kernel image In fact we gain a little flex
14. escribing which bit in the CPM registers controls power to this periph eral Drivers can then use functions from the OCP subsystem to switch the device on and off Obviously for peripherals that are unique to a particular board it is also easy for the driver to directly control power to the device So far however little work has been done on the gen eral case where common devices may be pow ered on and off by board specific controls 5 4 Dynamic power management Dynamic power management DPM refers to dynamically adjusting CPU frequencies and voltage during operation This approach is quite new at least in Linux and very much un der development The details of the motiva tions and approaches to dynamic power man agement are outside the scope of this paper for more information see 4 IBM and Mon taVista software are collaborating on further development in this area DPM does introduces some new problems re lated to device information To work properly devices in operation may have to impose con straints on what frequency or other settings are allowed For example a device may require a certain amount of bus bandwidth and hence impose a minimum bus frequency or it may re quire interrupts to be handled without too high a latency and hence impose a minimum CPU frequency These constraint details are somewhat like the basic information about device interconnection that we have already examined but clearly re quir
15. for the process of suspending or sleeping a ma chine i e saving the machine s state while turning most or all of the machine off then restoring the state when the machine is pow ered on again This of course is normal in ev eryday laptops and handling this for embed ded machines is not a great deal different Embedded devices do introduce some extra complexities though On PC laptops the BIOS either APM or ACPI provides some support to the kernel on how to properly sus pend the machine indeed in the APM case the BIOS handles most of the work itself Em bedded machines on the other hand usually require the kernel to know how to suspend and resume the machine directly For example the suspend code for the eLAP knows how to use the 405LP s features to save the CPU state how to configure the RAM to enter self refresh mode how to use the board s FPGA registers to turn off the board and how to rebuild the state when the machine is resumed In addition static power management on all machines requires knowledge of what devices dependencies on each other are so they can be shut down and later restarted in the cor rect order this was one of the major moti vations for the creation of the unified device model Hence all the complexities of obtain ing detailed device information for embedded systems impact on static power management However static power management doesn t re ally add further difficulties bey
16. ibil ity if this information is removed from the ker nel proper by having it as a blob of data which is passed to the kernel by the bootstrap loader the shim between the firmware bootloader and the kernel proper which handles decompress ing the kernel and moving it to the correct ad dress in memory This has the advantage that on those machines which do have a reasonable sophisticated firmware or bootloader such as PPCBoot U Boot see 7 the device informa tion can be taken from there from include asm bootinfo h struct bi_record unsigned long tag unsigned long size unsigned long data 0 F define BI_FIRST 0x1010 define BI_LAST 0x1011 define BI_CMD_LINE 0x1012 define BI_BOOTLOADER_ID 0x1013 define BI_INITRD 0x1014 define BI_SYSMAP 0x1015 define BI_MACHTYPE 0x1016 define BI_MEMSIZE 0x1017 define BI_BOARD_INFO 0x1018 Figure 5 Boot info records On PPC systems there already exists a flexible method of passing data from the bootstrap to the kernel proper through boot info records The bootstrap passes to the kernel a list of bi_ record structures shown in Figure 5 Each 4Note that this is a different problem to multipath IO That deals with the case where a device can be accessed by any of several routes here we have devices that re quires several connections simultaneously Linux Symposium 2003 221 bi_recordisa blob of data with a length a
17. ible to completely avoid hardwired knowledge of boards in the kernel we do want to keep this information in as clean a way as possible Specifically we want to iso late the direct knowledge of board specific de tails to as small a section of the kernel as pos sible and we want to make it easy to add the details of new boards and their peripherals In this paper we generally assume that the ker nel must be configured for one particular type of embedded machine since this is the sim plest case Building a kernel which will sup port multiple machines is certainly possible and most of the methods we discuss can still be applied In this case the kernel need to in clude device information about all supported boards Early in boot the kernel will identify the machine it is running on by some ad hoc method and select which information to use on that basis Now we examine some of the existing meth Linux Symposium 2003 217 ods by which embedded devices are supported in the kernel 3 3 Hardcoded hacks The naive approach to handling embedded de vices that aren t on a conventional bus is to treat them all like the system devices on a PC or other conventional machine That is sim ply hardcode knowledge of the device into the relevant device driver or into the kernel initial isation code for the machine in question This approach is currently used for quite a number of embedded devices unsurprisingly since
18. mory Access Layer MAL The additions field is used to identify which MAL channels are associated with each EMAC another piece of information that the kernel has to just know The 2 5 version of the OCP system is in tegrated with the unified device model At bootup the OCP code registers an OCP bus_ type and one instance of it all the OCP de vices are registered as devices on this bus The ocp_device and ocp_driver structures become wrappers around the device model s device and device_driver structures 4 Future approaches As yet there is no really convenient and com prehensive way of dealing with embedded un probeable peripherals The OCP system is 3This ignores the distinction between the two on chip buses PLB and OPB We can get away with this because the POB is always enabled and has a fixed configuration so in practice we can ignore the distinction for the pur poses of device discovery 220 Linux Symposium probably the closest thing to such a system but it has significant limitations it only covers PPC 4xx on chip devices and its data structure is a flat table so it cannot represent peripherals behind a bus to bus bridge or other more com plex interconnections The fact that some peripherals are built into the CPU chip is interesting from a hardware point of view However for the purposes of de vice discovery there is little inherent difference between on chip devices and devic
19. nd tag the internal format of the information be ing determined by the tag some tag values are also shown in Figure 5 Currently this method is used for passing information such as the size of memory and the board and bootloader ver sions This system could be extended to pass an entire set of device information to the kernel there is no reason a particular bi_record couldn t contain a list of further bi_ records giving a tree structure A related question is how to represent the de vice information in the kernel source The sim plest approach would be to directly include the data structure used to represent the informa tion at boot time However that s likely to be quite inconvenient to edit and extend espe cially if the format includes length fields like bi_records or internal pointers It might be worthwhile then to create a device tree com piler a program used during the kernel build to take a text file describing the device layout and generate code or data to be included in the kernel image 5 Power management In a battery powered device such as the eLAP it is clearly important to minimise power con sumption The most obvious way to do this is to power down sections of the system when they are not in use Obviously this means that the kernel needs to know when a device is in use including when it is in use indirectly be cause another device relies on it The topics of power management and device disco
20. nif icant rewrites before reaching its present form The initial implementation in the 1inuxppc_ 2_4 devel BK tree had a number of seri ous design and interface problems It was then rewritten in 2 5 based on the new Linux uni fied device model and using the PCI subsys tem as a reference This version is considerably cleaner but still contains some poorly thought out elements in particular some things have been copied from PCI which make little sense in their new context It has now been rewrit ten again by Benjamin Herrenschmidt in the linuxppc 2 4 BK tree This latest rewrite is conceptually similar to the 2 5 version but considerably simpler and cleaner This final version still needs to be forward ported to 2 5 re introducing the integration with the unified device model For each CPU with OCP devices there is a ta ble of definitions like that in Figure 2 This is found in a C file specific to the particular CPU along with any initialisation or support code for that CPU The example in Figure 2 doesn t in clude all the 405LP s on chip devices since not all the drivers have been adapted to use the OCP infrastructure yet The table con sists of ocp_def structures shown in Fig ure 3 At boot time the OCP system scans the core_ocp table to produce a list of OCP de vices present making an ocp_device struc ture also in Figure 3 for each to keep track of it at runtime The vendor and function fields between them i
21. not quite identical drivers present in the kernel The situation is aggra vated as more embedded machines are sup ported The fundamental problem with this approach is that there are many more types of embed ded machine than there are of normal ma chines Indeed there is often only one domi nant type of conventional machine per archi tecture PC for x86 CHRP for PowerPC Sun server workstation for SPARC etc With the large number of different types of embedded machine direct hardcoding quickly becomes messy there is a lot of duplicated code and it is inconvenient to add new machines and pe ripherals 3 4 The OCP subsystem Since we can t entirely avoid hardcoded infor mation the obvious approach to isolating the messiness is to encode information about de vices into a data structure which is statically compiled into the kernel but parsed to provide data to the drivers at runtime This solution is conceptually similar to using device informa tion from firmware except that the device tree is supplied by the kernel itself rather than read at boot time The OCP subsystem standing for On Chip Peripheral is a partial implementation of this approach It only covers the on chip devices on PPC 4xx chips and is quite limited in the sorts of device information it can represent but it iss still a substantial improvement over hardcoded drivers 218 Linux Symposium The subsystem has been through several sig
22. on chip DMA con troller to supply data from RAM Sometimes machines also have a more conven tional bus such as PCI or PCMCIA but it may have to be accessed via a bridge which is not configured in the same way as one would ex pect on a conventional machine Worst of all there are dozens or hundreds of different types of embedded machine each with its own com pletely different set of devices and connections Under these circumstances it is tempting to turn to each board s firmware to provide in formation about which devices are present Unfortunately the firmware on most embed ded machines is very primitive providing little more than a boot loader Usually it will provide a few useful pieces of information such as the amount of RAM on the system or the board revision but it certainly won t give compre hensive device information Furthermore what information the firmware does provide usually can t be used without already knowing some thing about the machine in question since em bedded firmwares are almost as varied as em bedded machines themselves Since embedded machines can and do break any assumption one might care to make about how devices are attached there is no magical way that the kernel can detect what devices are present So the only approach is to have the kernel just know the device setup for a par ticular board by building the knowledge into the kernel at compile time Although it is imposs
23. ond those we have already discussed for device discovery 5 3 Peripheral power management We use the term peripheral power management to refer to disabling and powering down pe ripheral devices when they are not in use This is often relatively straightforward since it can be handled directly by the driver for the device in question This also delegates the question of when the device is in use to the driver Sometimes it is sufficient to enable power to the device when it is open and disable it when closed other times more fine grained control of the power is desirable e g to take advan tage of idle periods When the device depends on other devices be ing enabled the situation is a little more com plex However the driver will generally know what the other devices are and their drivers so it is usually quite simple to create an ad hoc in terface whereby one driver can ask the other to enable the device it requires Difficulties do arise where power to one de vice is controlled by another for example the 4xx on chip devices are controlled by a cen tral clock and power management unit CPM Similarly many boards have devices which are powered on and off by board specific FPGA registers Linux Symposium 2003 223 The 4xx CPM has a simple interface allow ing the OCP subsystem to support peripheral power management quite easily The pm field in the OCP device definitions see Figures 2 amp 3 is a mask d
24. ot be made in embedded machines and the hard ware and firmware of embedded machines gen erally provides much less assistance to the ker nel for device discovery All these things re quire different approaches to device discovery to be used 214 e Linux Symposium PowerPC 405LP PDA Reference Design eLAP Debug Sled 405LP oo pm 32MB SDRAM Buffi PCMCIA uffers E l External Bus 3 A Ethernet MAC KI Ethernet EE 1 USB Gadget y a USB Host 1 i AA SDIO I i LED Ctrl Tricolour LED ae FPGA 1 Buttons 1 baa i i 32MB NOR Flash TCPA i i TAA H LCD Panel roog oooi e an Battery ADC Frontlight Ctrl Frontlight ip J i i Touchpanel 7 sia a a csi ii Audio Codec Speakers ral HHH 3 3 i Microphone g E Why Line in out 3 g UART1 Li TS Ctrl a g ii gg ii UARTO i RS232 8 iij 2 8 i A g GPIO iii E Pe 11 iale CL OPB aad External connection iit GEE Exiernal Bus i ijji 12C Bus 7 Physical device Male ge DCR Bus PowerPC 405 HEE Other connection Z Socket Core n EA Interrupt Line J MDOC
25. ruct list_head link char name 80 const struct ocp_def def void drvdata struct ocp_driver driver u32 current_state Figure 3 OCP device structure from drivers i2c i2c ibm_iic c static struct ocp_device_id ibm_iic_ids vendor OCP_ANY_ID function OCP_FUNC_IIC vendor OCP_VENDOR_INVALID static struct ocp_driver ibm_iic_driver name jic id_table ibm_iic_ids probe iic_probe remove iic_remove ocp_register_driver amp ibm_iic_ driver Figure 4 OCP driver registration for the IIC driver IDs like that shown in Figure 4 This again is analogous to a PCI driver The OCP subsys tem matches the driver against the list of OCP devices calling the driver s probe routine for each relevant device The index field is used to distinguish be tween multiple devices of the same type The paddr and irq fields unsurprisingly give the device s physical base address on PPC all IO is memory mapped and its IRQ line The pm field is used for power management we ll look at it in 5 3 Finally the additions field is a hack used to supply extra device specific information It is not needed for any of the devices on the 405LP but it is used on some other chips for example some 4xx CPUs such as the 405GP and NPe405H in clude one or more Ethernet MAC controller EMAC units These make use of a spe cialised DMA controller known as the Me
26. very are therefore related device discov ery is about providing exactly the sort of in formation about the interconnection of devices that effective power management requires As yet the integration of power management techniques with detailed device information is very much a work in progress even on con ventional systems and doubly so on embedded machines So we can only give an overview here of what the major issues are most of the hard cases remain to be investigated let alone implemented Again we will use the eLAP as our example the 405LP s power management features intro duce some new and largely unsolved prob lems in providing device information for power management So we first examine these fea tures then in 5 2 5 3 and 85 4 we examine several different methods of reducing power consumption and the device information prob lems they introduce 5 1 eLAP power management features The 405LP CPU is designed especially for low power operation and as such it has some novel and interesting power management features Most of the on chip peripherals can be pow ered on and off under software control Some also provide more detailed power control to al low power savings when only parts of the pe ripheral are in use or when it is in use inter mittently It also allows for several methods of saving the CPU state while shutting down the chip as a whole i e sleep modes More interestingly the 405LP
Download Pdf Manuals
Related Search