|
1 <?xml version="1.0" encoding="utf-8"?> |
|
2 <!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. --> |
|
3 <!-- This component and the accompanying materials are made available under the terms of the License |
|
4 "Eclipse Public License v1.0" which accompanies this distribution, |
|
5 and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". --> |
|
6 <!-- Initial Contributors: |
|
7 Nokia Corporation - initial contribution. |
|
8 Contributors: |
|
9 --> |
|
10 <!DOCTYPE concept |
|
11 PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> |
|
12 <concept id="GUID-95BD3650-08CB-407D-969E-DFDB39B2FEFC" xml:lang="en"><title>What is a Platform Service?</title><shortdesc>A platform service is an interface designed to make it |
|
13 quick, easy and inexpensive to integrate hardware into a mobile device.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody> |
|
14 <section id="GUID-F3ACE06A-E619-416A-BC4B-4AA4771404D2"><title>Platform |
|
15 Service</title> <p>A platform service is a set of defined functionality, |
|
16 usually providing an abstraction or encapsulation for functionality |
|
17 provided by hardware.</p><p>For example, a platform service may provide |
|
18 a standard interface for using a serial bus to send commands and data |
|
19 between integrated circuits on the base board. Another example would |
|
20 be providing a standard interface for Direct Memory Access (DMA) hardware |
|
21 for moving blocks of data from one block of memory locations to another |
|
22 or from a block of memory to a hardware device.</p><p>The platform |
|
23 service separates the functionality required by kernel, device driver |
|
24 and application processes from the specific hardware implementation. |
|
25 This means, for example, that a device driver can be written for a |
|
26 platform service that uses the published APIs, without needing to |
|
27 know the specifics of the actual hardware device/chipset.</p><fig id="GUID-D1D306BB-EFDD-4365-8259-39A4F4EB6AE3"> |
|
28 <title>Platform service</title> |
|
29 <image href="GUID-99637158-DE86-4BB4-98D4-3A3E64AB768F_d0e87314_href.png" placement="inline"/> |
|
30 </fig><p>The platform service is a consistent hardware interface at |
|
31 the bottom of the operating system platform software stack. In the |
|
32 past much of the logic and configuration required to enable a new |
|
33 piece of hardware was higher up in the operating system stack and |
|
34 that made it difficult to support new or variant hardware. The platform |
|
35 service architecture separates out the hardware specific interfaces |
|
36 and encapsulates them behind a standard set of platform service (client |
|
37 interface) APIs. </p><p>The platform service consists of :</p><ul> |
|
38 <li><p>Client Interface/Platform service APIs </p></li> |
|
39 <li><p>Implementation of the APIs:</p><ul> |
|
40 <li><p>Platform Independent Layer (PIL)/Framework/Generic implementation</p></li> |
|
41 <li><p>SHAI interface</p></li> |
|
42 <li><p>Platform Specific Layer (PSL)/SHAI Implementation/Hardware |
|
43 implementation</p></li> |
|
44 </ul></li> |
|
45 </ul><p>The PIL contains all the common functionality code such as |
|
46 maintaining a list of available channels for communication or holding |
|
47 the pending list of memory transfers to be processed by DMA when the |
|
48 hardware becomes available. Usually the PIL provides the implementation |
|
49 of the Client Interface APIs. This is sometimes referred to as the |
|
50 Framework.</p><p>The interface between the framework code and the |
|
51 PSL code is known as the Symbian Hardware Adaptation Interface (SHAI). |
|
52 The SHAI interface specifies how the PIL and PSL talk to each other |
|
53 (APIs, shared memory areas etc.)</p><p>The PSL consists of the specific |
|
54 code required to work with a particular piece of hardware. This means |
|
55 that supporting a new or variant chipset only requires the PSL to |
|
56 be amended or to have detection code to handle a particular piece |
|
57 of hardware. </p><p>Some Platform Services, such as GPIO, provide |
|
58 APIs that directly address the hardware, and so the PSL provides the |
|
59 client interface API implementation directly. For example, there is |
|
60 no GPIO PIL/framework.</p></section> |
|
61 <section id="GUID-15BD58D5-12D7-4871-9A98-940F39B95182"><title>Variations |
|
62 on platform service</title><p>Not all platform services are as simple |
|
63 as the diagram above suggests. Some platform services do not talk |
|
64 to hardware directly or at all, but provide a higher-level abstraction, |
|
65 often with further low-level platform services below them in the OS |
|
66 stack. For example, the Power Manager Policy platform service, provides |
|
67 APIs to control power management policy, but does not interface with |
|
68 any hardware directly. In these cases there is either no PSL, or the |
|
69 PSL provides configuration specific responses to a generic PIL. For |
|
70 example, if a handset can be built in two variants, one with a hardware |
|
71 graphics accelerator and one without but with a software emulated |
|
72 graphics accelerator, then the PSL would be responsible for directing |
|
73 graphics requests either to the hardware, or to the software and returning |
|
74 the results back through the PIL to the client.</p><p>Some plaftorm |
|
75 services, for example TV-Out, may use additional platform services |
|
76 to output sound as well as providing hardware support for the TV-Out |
|
77 chipset.</p><p>Some platform services may share a piece of hardware, |
|
78 such as a radio chip. The chip may provide cellular telephony, WiFi, |
|
79 FM radio transmission and other features all on one chip, but there |
|
80 may be several separate platform services, each exposing an API for |
|
81 one particular technology.</p><p>Both the PIL and PSL may make calls |
|
82 to other OS components, including other platform services, for information |
|
83 such as Hardware Configuration, power status, and the availability |
|
84 of other services.</p></section> |
|
85 <section id="GUID-1D50AC84-89A3-4BA3-BB7F-032FF499E56D"><title>Why |
|
86 have a platform service</title><p>Platform services |
|
87 benefit both device creators and third party hardware/chipset developers |
|
88 since they specify a standard software interface between the operating |
|
89 system and standard functionality provided by hardware.</p><p>This |
|
90 means that it is possible for a device creator to easily integrate |
|
91 the best hardware for their device, and allows hardware creators to |
|
92 work to a standard interface that can be used across multiple devices |
|
93 and multiple customers.</p><p>As the platform service interface provides |
|
94 a consistent interface to functionality, it allows the device creator |
|
95 to concentrate on the core functionality and not worry about how the |
|
96 hardware will provide it. And since the interface is standard for |
|
97 each type of hardware component, each manufacturer can provide the |
|
98 information or code for the PSL comparatively easily for each additional |
|
99 variant they produce. So this means less code required from hardware |
|
100 manufacturers per hardware component, and a larger market as each |
|
101 new mobile device, from any device creator, can use that compliant |
|
102 hardware.</p><p>The platform services abstraction for hardware adaptation |
|
103 also means more common code that can be shared across the Symbian |
|
104 Foundation member community. This includes sharing PSL code with other |
|
105 hardware providers, and sharing code for device drivers and other |
|
106 higher-level components that need to use the platform services APIs. |
|
107 For example, if a device driver for a particular piece of hardware |
|
108 also needs to use a serial inter-IC bus (IIC) to send commands to |
|
109 that hardware, then it can use the IIC platform service APIs and re-use |
|
110 code that other components have already tested for using the IIC client |
|
111 interface APIs.</p><p>Platform services also allow the use of standardized |
|
112 test tools and test suites. Each new piece of hardware in a particular |
|
113 category (for example, camera, Bluetooth radio) has to comply with |
|
114 the SHAI interface (PIL/PSL interface). This means that an existing |
|
115 test suite that works with another camera module can be used to test |
|
116 that this new piece of hardware works. This reduces the time taken |
|
117 for testing and increases speed to market.</p></section> |
|
118 <section id="GUID-173DF644-98BC-415C-8DA5-5428FF560622"><title>Who |
|
119 uses the Platform Service?</title><ul> |
|
120 <li><p>Application developers, who need to use the functionality of |
|
121 a hardware device, but do not need to know the specific details of |
|
122 the hardware/hardware implementation. They use the client interface |
|
123 and need to know what the APIs are, and what order they must be called |
|
124 in and so on.</p></li> |
|
125 <li><p>Framework developers, who need to know how to implement each |
|
126 of the client interface APIs , and a description of the functionality |
|
127 required within the framework.</p></li> |
|
128 <li><p>Hardware Developers, who need to understand the hardware interface, |
|
129 and have to write or update the hardware implementation (PSL) to support |
|
130 their particular chipset/hardware.</p></li> |
|
131 </ul></section> |
|
132 <section id="GUID-84DAC762-23F9-4756-8D3A-EB03280E93CA"><title>Platform |
|
133 service client interface APIs</title><p>In general these are function |
|
134 calls, and associated enumerations. There are two main types of function |
|
135 call:<ul> |
|
136 <li><p>Synchronous</p></li> |
|
137 <li><p>Asynchronous</p></li> |
|
138 </ul></p><p>A synchronous function call from the client/device-driver |
|
139 waits for the platform service to process it and make any return value. |
|
140 The client thread waits for the synchronous call to complete.</p><p>An asynchronous function call asks the platform service to do something, |
|
141 but then execution of the client continues immediately. For example, |
|
142 this would be the case of any function that starts a long data transmission |
|
143 or receive process, such as streaming video. One of the standard components |
|
144 of an asynchronous function call is a way for the result to be communicated |
|
145 back to the client. Often this is done by a “callback function” where |
|
146 the client specifies a pointer to a function (and parameters) during |
|
147 the original call, and the platform service puts the callback on the |
|
148 Delayed Function Call (DFC) queue for the client when the platform |
|
149 service has completed the request. This may indicate “transfer completed” |
|
150 or “transfer failed, error code 123”, it may release a lock or other |
|
151 functionality defined by the author of the client.</p></section> |
|
152 </conbody><related-links> |
|
153 <link href="http://developer.symbian.org/wiki/index.php/Prop/SHAI.dita"> |
|
154 <linktext>Symbian Foundation SHAI page</linktext></link> |
|
155 </related-links></concept> |