<?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-ADB848FD-317A-521C-9684-BBCF20358207" xml:lang="en"><title>Architecture</title><shortdesc>Describes the USB client architecture.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>

<p>Symbian platform provides access to USB client hardware through its USB

client driver. </p>

<p>The following diagram shows the USB client architecture. Devices can provide

more than one USB function. To better show the typical use, the diagram shows

the components in use with a phone that is configured as a combined

WHCM and OBEX peripheral. </p>

<fig id="GUID-8627CEA3-B570-5DA0-AE30-32C9AE08F041">

<image href="GUID-365283F1-54B4-519A-81EC-9B5018896DDE_d0e35432_href.png" placement="inline"/>

</fig>

<p>There are three main elements: </p>

<ul>

<li id="GUID-95956004-F78F-53E5-A2F3-693B48D344E8"><p>The user side interface

to the USB client driver. </p> </li>

<li id="GUID-6461280C-469F-5726-AE69-9A88ADCC95AB"><p>The USB client driver

LDD that provides the driver's logical channel. This is hardware independent. </p> </li>

<li id="GUID-FD47D854-620E-5E2A-9A59-79B4901477D2"><p>The PDD, or client controller,

that manages access to the USB client hardware. </p> </li>

</ul>

<section id="GUID-57BF46A0-0FE2-4074-87DF-A0C55AA29F1F"><title>User API</title> <p>The user side interface to the USB client

driver is provided by <xref href="GUID-B1E32178-3B7C-3B00-A0AF-62ECE40E8598.dita"><apiname>RDevUsbcClient</apiname></xref>. The user side interface

is implemented as a set of inline functions and means that there is no separate

user side library component. This is typically the case for device drivers. </p> </section>

<section id="GUID-2C341305-95E0-53C4-B4D5-1BB03CCB8C52"><title>USB client

driver (LDD)</title> <p>The USB client driver provides an interface to the

USB client device. The USB client driver is also referred to as a <i>channel</i> to

the USB client device; it may also be referred to as the USB logical device

driver. </p> <p>Each user component that requires a connection to the USB

client device opens a channel using the user side <xref href="GUID-B1E32178-3B7C-3B00-A0AF-62ECE40E8598.dita"><apiname>RDevUsbcClient</apiname></xref> class. </p> <p>A

channel supports only one USB interface. A channel (i.e. the USB LDD) can

be loaded as many times as needed; the decision is based on the number of

interfaces required. This can be done either in the same process or in a different

process depending on the relationship between the interfaces. </p> <p>If there

is more than one channel open on the USB client device, then they can all

share Control Endpoint 0 (Ep0). Each channel can make a request on this endpoint.

The other endpoints cannot be shared between channels; instead each endpoint

is used exclusively by one, and only one, channel. </p> <p>Each channel can

claim up to a maximum of <i>five</i> endpoints in addition to Ep0. Each endpoint

claimed on a channel is locally numbered from one and five. This number need

not correspond to the actual endpoint number of the hardware interface; this

number is called the logical endpoint number, and all transfer requests use

the logical number for the endpoint. A driver can, however, discover the physical

endpoint address of a logical endpoint by requesting the endpoint descriptor. </p> <p>A

channel can have asynchronous requests outstanding on one or more of its endpoints

simultaneously; this includes Ep0. As Ep0 can be shared between channels,

then the underlying USB Controller must manage multiple requests on this endpoint </p> </section>

<section id="GUID-660CC1A9-26B5-5869-ADC9-53196AF5F387"><title>USB client

controller (PDD)</title> <p>The USB client controller manages access to the

USB client hardware on behalf of all USB client drivers. It has a two layer

implementation: </p> <ul>

<li id="GUID-A90C62D9-60B0-5542-9D93-683A7C02EDB2"><p>a licensee product independent

layer that provides an API for the USB client driver. This is often referred

to as the Platform Independent Layer, and forms the 'upper' part of the USB

physical device driver (PDD). </p> </li>

<li id="GUID-4637A61F-A1D7-522A-B824-4603AF129442"><p>a layer that interfaces

with the hardware. This is often referred to as the Platform Specific Layer,

and forms the 'lower' part of the USB physical device driver (PDD). <i>It

is this part that needs porting effort</i>. </p> </li>

</ul> <p>The Platform Independent Layer contains, as far as possible, the

functionality that is defined in the USB specification. This includes the

‘Chapter 9’ device state handling and request processing. The Platform Specific

Layer contains only that functionality which cannot be abstracted and made

generic, because different USB Device Controller designs are programmed differently

and operate differently. </p> <p>The complete USB client controller (PDD)

is an instance of a <xref href="GUID-82FA9C04-0B7E-3FAD-9AAD-3A68E1E6A941.dita"><apiname>DUsbClientController</apiname></xref> derived class

and is implemented as a kernel extension named <filepath>usbcc.dll</filepath>. </p> <p>The

functionality of the Platform Independent Layer is provided by the base class <xref href="GUID-82FA9C04-0B7E-3FAD-9AAD-3A68E1E6A941.dita"><apiname>DUsbClientController</apiname></xref>.

This class also defines a large number of pure virtual functions that are

intended to provide the functionality that is not part of the USB specification,

but is specific to the USB Device Controller. Such functions typically implement

direct USB Device Controller hardware manipulation, register access, endpoint

FIFO loading/unloading etc. The platform specific layer provides the implementation

for these pure virtual functions by defining and implementing a device specific

class derived from <codeph>DUsbClientController</codeph>. </p> </section>

</conbody></concept>