MT6573 Linux Device Model Customer Document [0.1 ed.]

Citation preview

LY M R ED yu IA .li@ T E tin K C no O mo NF bil ID e.c EN om T I US AL EO N

Linux Device Document

Version: Release date:

Model

Customer

0.1 2011-04-15

© 2008 - 2011 MediaTek Inc. This document contains information that is proprietary to MediaTek Inc. Unauthorized reproduction or disclosure of this information in whole or in part is strictly prohibited.

FO

Specifications are subject to change without notice.

LY

MT6573 Confidential B

M R ED yu IA .li@ T E tin K C no O mo NF bil ID e.c EN om T I US AL EO N

Document Revision History

Revision

FO

0.1

Date

Author

2010-01-21

CC Hwang

MediaTek Confidential

Description Initial Draft

© 2011 MediaTek Inc.

This document contains information that is proprietary to MediaTek Inc. Unauthorized reproduction or disclosure of this information in whole or in part is strictly prohibited.

Page 2 of 10

LY

MT6573 Confidential B

M R ED yu IA .li@ T E tin K C no O mo NF bil ID e.c EN om T I US AL EO N

Table of Contents

Document Revision History .................................................................................................................. 2 Table of Contents................................................................................................................................... 3 1

Introduction................................................................................................................................... 4 1.1 1.2

2

Design..............................................................................................Error! Bookmark not defined.5 2.1 2.2

3

Architecture........................................................................................................................... 5 Device/Driver Matching Process ........................................Error! Bookmark not defined.5

Platform Bus ...................................................................................Error! Bookmark not defined.6 3.1 3.2

4

Software Environment .......................................................................................................... 4 Functionality.......................................................................................................................... 4

Platform Device ..................................................................Error! Bookmark not defined.6 Platform Driver....................................................................Error! Bookmark not defined.6

Module Initialization Sequence .....................................................Error! Bookmark not defined.8

FO

Lists of Tables and Figures

MediaTek Confidential

© 2011 MediaTek Inc.

This document contains information that is proprietary to MediaTek Inc. Unauthorized reproduction or disclosure of this information in whole or in part is strictly prohibited.

Page 3 of 10

Introduction

1.1

Software Environment

M R ED yu IA .li@ T E tin K C no O mo NF bil ID e.c EN om T I US AL EO N

1

LY

MT6573 Confidential B

Driver discussed in this document is designed based on Linux Kernel 2.6.35 and Android 2.3.

1.2

Functionality

FO

By reading this document, you can understand how to register a new device driver to the Linux device model and how to control module initialization sequence for proper operation of the driver.

MediaTek Confidential

© 2011 MediaTek Inc.

This document contains information that is proprietary to MediaTek Inc. Unauthorized reproduction or disclosure of this information in whole or in part is strictly prohibited.

Page 4 of 10

Architecture

2.1

Architecture

M R ED yu IA .li@ T E tin K C no O mo NF bil ID e.c EN om T I US AL EO N

2

LY

MT6573 Confidential B

From BSP’s point of view, the entire system is composed of three parts: busses, drivers, and devices as below.

There are several busses in Linux, such as USB and I2C. For every bus, there may be several devices and drivers attached to it. The drivers serve the need of the matching devices and make Linux capable of operating on the devices correctly. The matching process will occur when a driver or a device is registered to the bus, which will be explained later.

2.2

Device/Driver Matching Process

FO

When a device or a driver is registered with the specified bus, the device/driver matching process occurs. When a device is registered to the bus, all the drivers on the bus will be scanned to see whether there are matching drivers that can serve the newly added device, vice versa. For every bus, there’s a matching function attached to it. The matching function will be used to scan all the devices/drivers for the first step. The matching rules are different for different busses, such as the name or the capability of the device/driver. If a matching device/driver is found, then the probing function of the driver will be used to verify that the specified device hardware actually exists and check whether the required resource can be acquired from the system so that the driver can service the device properly. After this, the driver can start servicing the device.

MediaTek Confidential

© 2011 MediaTek Inc.

This document contains information that is proprietary to MediaTek Inc. Unauthorized reproduction or disclosure of this information in whole or in part is strictly prohibited.

Page 5 of 10

FO

M R ED yu IA .li@ T E tin K C no O mo NF bil ID e.c EN om T I US AL EO N

LY

MT6573 Confidential B

MediaTek Confidential

© 2011 MediaTek Inc.

This document contains information that is proprietary to MediaTek Inc. Unauthorized reproduction or disclosure of this information in whole or in part is strictly prohibited.

Page 6 of 10

Platform Bus

M R ED yu IA .li@ T E tin K C no O mo NF bil ID e.c EN om T I US AL EO N

3

LY

MT6573 Confidential B

Platform bus is a pseudo-bus in Linux and is used to connect devices on busses with minimal infrastructure, like those used to integrate peripherals on many system-on-chip processors, which is extensively used in Linux package provided by Mediatek. The matching function of platform bus matches platform devices and platform drivers by name.

3.1

Platform device

Platform devices are devices that typically appear as autonomous entities in the system, such as controllers integrated into system-on-chip platforms. struct platform_device { const char *name; u32 id; struct device dev; u32 num_resources struct resource *resource };

Platform device holds a pointer to the resource array and the number of elements in the resource array. The resource may be an IRQ line, a section of memory, etc. Sometimes the fields in platform device may not be enough for device initialization. In this case, platform data in dev field is a good candidate for additional device information carrier. The following is an example: struct platform_device android_usb_device = { .name = “android_usb”, .id = -1, .dev = { .platform_data = &android_usb_pdata, }

FO

struct android_usb_platform_data android_usb_pdata = { .vendor_id = 0x0bb4, .product_id = 0x0001, .product_name = “Android Phone”, .manufacturer_name = “MediaTek”, .serial_number = “MT123456789”, };

MediaTek Confidential

© 2011 MediaTek Inc.

This document contains information that is proprietary to MediaTek Inc. Unauthorized reproduction or disclosure of this information in whole or in part is strictly prohibited.

Page 7 of 10

M R ED yu IA .li@ T E tin K C no O mo NF bil ID e.c EN om T I US AL EO N

struct android_usb_platform_data { /* USB device descriptor fields*/ __u16 vendor_id;

LY

MT6573 Confidential B

/* Default product ID. */ __u16 product_id;

/* Product ID when adb is enabled. */ __u16 adb_product_id; __u16 version;

char *product_name; char *manufacturer_name; char *serial_number;

/* number of LUNS for mass storage function */ int nluns;

};

Platform data of arbitrary type can be used to attach device information to platform device as shown. Another example is UART, which demonstrates the usage of resource.

FO

static struct resource mt6573_resource_uart1[] = { { .start = UART1_BASE, .end = UART1_BASE + MT6573_UART_SIZE – 1, .flags = IORESOURCE_MEM, }, { .start = MT6573_UART1_IRQ_LINE, .flags = IORESOURCE_IRQ, }, }

static struct platform_device mt6573_device_uart[] = { { .name = “mt6573-uart”, .id = 0, .num_resources = ARRAY_SIZE(mt6573_resource_uart1), .resource = mt6573_resource_uart1, }, };

MediaTek Confidential

© 2011 MediaTek Inc.

This document contains information that is proprietary to MediaTek Inc. Unauthorized reproduction or disclosure of this information in whole or in part is strictly prohibited.

Page 8 of 10

LY

MT6573 Confidential B

M R ED yu IA .li@ T E tin K C no O mo NF bil ID e.c EN om T I US AL EO N

As shown in UART example, resources are divided into two types: memory and IRQ line, which indicates the memory section and IRQ line used by the module. Also note that the id field indicates the device instance number, or -1 if device instance number is not used. After the associated resources and platform data are assigned, register the platform device to platform bus through int platform_device_register(struct platform_device *pdev); int platform_add_devices(struct platform_device **pdevs, int ndev);

3.2

Platform driver

Platform drivers follow the standard driver model convention and many of them are the same. struct platform_driver { int (*probe)(struct platform_device *); int (*remove)(struct platform_device *); void (*shutdown)(struct platform_device *); int (*suspend)(struct platform_device *, pm_message_t state); int (*suspend_late)(struct platform_device *, pm_message_t state); int (*resume_early)(struct platform_device *); int (*resume)(struct platform_device *); struct device_driver driver; };

The probing function is used when a match is found on device/driver registration to the bus to verify the existence of the device hardware. To register the platform driver, use

FO

int platform_driver_register(struct platform_driver * drv)

MediaTek Confidential

© 2011 MediaTek Inc.

This document contains information that is proprietary to MediaTek Inc. Unauthorized reproduction or disclosure of this information in whole or in part is strictly prohibited.

Page 9 of 10

Module Initialization Sequence

M R ED yu IA .li@ T E tin K C no O mo NF bil ID e.c EN om T I US AL EO N

4

LY

MT6573 Confidential B

In fact, a device/driver can co-operate correctly only after probing, and the module initialization sequence emphasizes on the sequence which the probing functions are called, not the module initialization function itself. In the design of ALPS, driver registration is done in driver module initialization function, which is distributed among all the device drivers, and all the device registration is put in a common place, that is, mt6573_board_init in alps/mediatek/platform/mt6573/kernel/core/mt6573_devs.c to control the probing sequence of all the platform device/driver in the system. On the basic knowledge developed in the previous sections, it is clear that the probing function will be called when a match between a device and a driver is found. To make the claim that mt6573_board_init can control the probing sequence valid, all the platform drivers must be registered before mt6573_board_init is called. And the probing sequence will be the controlled by the device registration sequence. Also note that to reduce footprint, data that is unnecessary after initialization should be put at module initialization function, not in probing function. Only data that is needed at runtime should be put in probing function.

FO

To postpone driver probing to a later time, either postpone device registration or driver registration will do.

MediaTek Confidential

© 2011 MediaTek Inc.

This document contains information that is proprietary to MediaTek Inc. Unauthorized reproduction or disclosure of this information in whole or in part is strictly prohibited.

Page 10 of 10