<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
<!-- This component and the accompanying materials are made available under the terms of the License 
"Eclipse Public License v1.0" which accompanies this distribution, 
and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
<!-- Initial Contributors:
    Nokia Corporation - initial contribution.
Contributors: 
-->
<!DOCTYPE concept
  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
<concept id="GUID-3722B946-07CF-4AEA-B228-E50642D6B5BE" xml:lang="en"><title>Register Access Implementation Guide</title><shortdesc>Describes the implementation of the Register Access platform
service.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
<p>A ASSP hardware register is a physical interface to an item of
hardware which contains values, such as bit fields, for controlling
ASSP features.</p>
<section id="GUID-514E76B0-009C-48D4-935C-FBE48FDD3631-GENID-1-2-1-10-1-5-1-8-1-1-9-1-4-1-3-2"><title>ASSP</title><p> An ASSP (Application Specific Standard Product) is a class of
integrated circuit. Different ASSPs have different architectures and
instructions sets. The <xref href="GUID-66BB033A-3386-3913-9A25-EF3867D42C2C.dita"><apiname>AsspRegister</apiname></xref> class provides device driver writers with a simple interface to
access ASSP registers. Hardware implementers must provide the specified
functionality on a given platform and ASSP by writing the appropriate
machine instructions. </p></section>
<section id="GUID-DBEB025D-B457-493B-A052-274801C21B1E"><title>Pre-requisites</title><p>Before the implementing a register access implementation, the
following must be decided:</p><ul>
<li><p>The area in memory to which the registers are mapped. The start
of this memory region is known as the base address.</p></li>
<li><p>The location of each register in terms of an offset from the
base address.</p></li>
</ul><p>The above information will be present in a specific header
file which is used by any device driver that uses this API. This header
file also contains other information required to access the registers,
such as:</p><ul>
<li><p>constants for bit field offsets</p></li>
<li><p>bit field values</p></li>
</ul></section>
<section id="GUID-CF41655A-5B14-47C4-811A-C9F9352B0688"><title>Implementation</title><p>To provide register access, hardware implementers need to implement
the <xref href="GUID-66BB033A-3386-3913-9A25-EF3867D42C2C.dita"><apiname>AsspRegister</apiname></xref> class. </p><p>Generic access to a register is provided in the form of three
operations on a hardware register: read, write and modify. All these
functions can be called in any context. </p><p>Symbian platform provides
the class header and inline implementations of the 8, 16 and 32-bit
wide functions. You must implement all the register modify functions
and all functions to access 64-bit wide registers. You may also need
to replace the inline 8, 16 and 32-bit wide register read and write
functions if the ASSP contains write-only registers. </p> <p>You must
implement these functions atomically so that there is no possibility
of another thread or interrupt service routine accessing the contents
of the register before the function returns. Where you cannot implement
the function with a single machine instruction you must disable interrupts
during the register operation (if you are working with a single core
architecture) or wrap a spinlock around the register operation (if
you are working with a multicore architecture). </p> <p>There are
three cases in which you must enforce atomicity with interrupt disabled
or use of spinlocks. </p> <ul>
<li id="GUID-3D835089-4626-584F-9FB1-EBD9CBF7A8D0"><p>The modify operations
involve reading the register, taking a local copy, changing the local
copy and writing it back to the register and cannot be performed with
a single machine instruction. </p> </li>
<li id="GUID-939FFD27-60EB-5465-95B7-A3654FBB5941"><p>Operations on
write-only registers involve maintaining a copy of the current contents
of the register within the <xref href="GUID-66BB033A-3386-3913-9A25-EF3867D42C2C.dita"><apiname>AsspRegister</apiname></xref> class. All write and modify operations therefore cannot be performed
with a single machine instruction. </p> </li>
<li id="GUID-26D38D30-DFF3-5DCD-8163-157A228C50D6"><p>Some architectures
contain 64-bit registers. In this case, 64-bit operations involve
at least two machine instructions. </p> </li>
</ul><p>Baseport implementations of the Register Access platform service
come in the form of a ASSP library (or DLL). To avoid the need for
each device driver which uses the ASSP register class having to specify
a baseport specific library file corresponding to the ASSP library,
the name of the baseport specific library file should instead be included
in a file used to define other variant specific settings such as the
CPU core type, the memory model and the name of the variant. Each
baseport will have a file called <filepath>variant.mmh</filepath>,
where <codeph>variant</codeph> is the name of the baseport to be used.
An example of this being used in a <filepath>variant.mmh</filepath> file is:</p><codeblock xml:space="preserve">#if defined(__USING_BASPORT__)
library   VariantTarget(basport_name,assp_library)
#endif
</codeblock><note>baseport_name is the name of the variant and assp_library
is the name of the ASSP specific library file.</note><p>In order to
specify which baseport assp register set up is to be used in the client
projects for this baseport, the following line is included in the
MMP file of those projects</p><codeblock xml:space="preserve">#define __USING_BASEPORT___</codeblock></section>
</conbody><related-links>
<link href="http://developer.symbian.org/main/documentation/reference/s3/pdk/GUID-16AED228-539F-4BF7-A7FD-9A01FF1A9A84.html.dita">
<linktext>SMP - Locking</linktext></link>
</related-links></concept>