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-EBF4F1F1-F76B-455B-B8EE-B7965CF0717E" xml:lang="en"><title>The LDD/PDD

    13 Model</title><shortdesc>This document describes how device drivers are implemented as logical

    14 device drivers (LDDs) and physical device drivers (PDDs).</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>

    15 <section id="GUID-4549DF88-EEB0-4CF2-BC93-A234E3ED553F">             <p>Device

    16 driver DLLs come in two types - the logical device driver (LDD), and the physical

    17 device driver (PDD). Typically, a single LDD supports functionality common

    18 to a class of hardware devices, whereas a PDD supports a specific member of

    19 that class. This means that the generic code in the LDD only needs to be written

    20 once, and the same user-side API can be used for all variants of a device. </p> <p>Many

    21 PDDs may be associated with a single LDD. For example, there is a single serial

    22 communications LDD (<filepath>ECOMM.LDD</filepath>) which is used with all

    23 UARTs. This LDD provides buffering and flow control functions that are required

    24 with all types of UART. On a particular hardware platform, this LDD will be

    25 accompanied by one or more PDDs, which support the different types of UART

    26 present. A single PDD can support more than one UART of the same type; separate

    27 PDDs are only required for UARTs with different programming interfaces. Typically,

    28 the PDD is kept as small as possible. </p> <p>Only LDDs communicate with user-side

    29 code; PDDs communicate only with the corresponding LDD, with the variant or

    30 kernel extensions, and with the hardware itself. Device drivers provide their

    31 interface for user side applications by implementing a class derived from

    32 the Kernel API <xref href="GUID-6FBFA078-8253-3E24-B1F8-5F75E86C3066.dita"><apiname>RBusLogicalChannel</apiname></xref>. The functions of the

    33 derived class form a thin layer over the functions defined in <codeph>RBusLogicalChannel</codeph> and

    34 are commonly implemented inline and published in a header file. However, if

    35 the API functions need to do more complex tasks, then they can be implemented

    36 in their own DLL. The kernel also provides a API <xref href="GUID-92BAC78E-8ACF-3952-8E77-CCF93ED3BDC9.dita"><apiname>RDevice</apiname></xref>,

    37 which enables user side code to get information about a device. </p> <p>The

    38 following diagram shows the general idea: </p><fig id="GUID-CB291406-75EC-572E-8A21-280A5F0A6B9E">

    39 <title>              Device driver LDD/PDD model            </title>

    40 <image href="GUID-6EB38F10-849D-5763-96A0-A0A108982D67_d0e63496_href.png" placement="inline"/>

    41 </fig><p>To make porting to particular hardware platforms easier, some drivers

    42 make a further logical split in their PDD code between a platform-independent

    43 layer (PIL), which contains code that is common to all the hardware platforms

    44 that the driver could be deployed on, and a platform-specific layer (PSL),

    45 which contains code such as the reading and writing of hardware-specific registers. </p> <p>Depending

    46 on the device or the type of device to access, this split between LDD and

    47 PDD may not be necessary; the device driver may simply consist of an LDD alone. </p> 

    48    </section>

    49 </conbody></concept>