Device Driver Interface of WiLink Solution

From OMAPpedia

Revision as of 18:05, 1 August 2011 by A0460803 (Talk | contribs)
Jump to: navigation, search

Contents

Hardware Interface and MUX mode configuration

The WiLink connectivity chip's BT, FM and GPS IPs are interfaced with the application processor (OMAP) through UARTs. A GPIO line called nShutDown acts as the chip enable line for the connectivity chip.

Also, the connectivity chip is interfaced to BT core via PCM lines (mcbsp if OMAP) and to the FM core via i2S (or PCM). The BT-PCM lines carry the voice data during a call scenario. The FM i2S lines can be used for FM Rx audio (digital) or FM Tx audio.

The mux-mode configurations of these hardware interfaces can be configured via the OMAP MUX framework supported by the BSP as follows:


Example 1: On Zoom3 the N-Shut-Down line is connected to GPIO 109.

In file arch/arm/mach-omap2/board-zoom3.c you would find the following entry:
        omap_mux_init_gpio(109, OMAP_PIN_OUTPUT);

The configuration can be done in x-loader or u-boot. Note that the configuration may not take place in u-boot if it is already being done in x-loader.


Example 2: On OMAP3SDP/Blaze's x-loader, the McBSP1 is connected to the BT-PCM lines.

In file board/omap4430sdp/omap4430sdp.c of the ''u-boot'' source code, you will find entries which look like:

        MV(CP(ABE_MCBSP1_DX),   (OFF_EN | OFF_OUT_PTD | M0)) /* abe_mcbsp1_dx */ \
        MV(CP(ABE_MCBSP1_FSX),  (IEN | OFF_EN | OFF_PD | OFF_IN | M0)) /* abe_mcbsp1_fsx */ \
and
        MV(CP(ABE_MCBSP1_DX),   (OFF_EN | OFF_OUT_PTD | M0)) /* abe_mcbsp1_dx */ \
        MV(CP(ABE_MCBSP1_FSX),  (IEN | OFF_EN | OFF_PD | OFF_IN | M0)) /* abe_mcbsp1_fsx */ \

Example 3: On OMAP4SDP/Blaze, the OMAP UART2 is connected to the BT-HCI-UART.

        MV(CP(UART2_CTS),       (PTU | IEN | M0)) /* uart2_cts */ \
        MV(CP(UART2_RTS),       (M0)) /* uart2_rts */ \
        MV(CP(UART2_RX),        (IEN | M0)) /* uart2_rx */ \
        MV(CP(UART2_TX),        (M0)) /* uart2_tx */ \

Note: Since there lacks a standard way to configure the hardware interfaces, please look into relevant BSP or contact the email ID mentioned below.

BTWILINK driver

BTWILINK driver (in drivers/bluetooth/btwilink.c) provides the bluetooth connectivity. The driver makes use of the shared transport driver; which talks to the bluetooth core on the WiLink chipsets.

Enable this driver either as a module or as a built-in component along with necessary bluetooth functionality in the kernel.

Similar to the TI ST driver, this is also a platform device driver. Hence, to be included it requires a relevant platform device registration, which can be achieved as follows:

static struct platform_device btwilink_device = {
       .name = "btwilink",
       .id = -1,
};

The inclusion of btwilink_device in one of the architecture specific init functions would enable the Bluetooth driver for WiLink chipsets. Include the following line in one of the architecture/platform specific init functions:

platform_device_register(&btwilink_device);

User Space components

An utility known as UIM is critical for the shared transport (TI_ST) driver to work. (Meaning, without UIM, TI_ST will not work.) Most line disciplines, if not all, require a user-space daemon to open the UART. Installing the line discipline thereby gives control to the line discipline driver.

You can obtain UIM from:

http://git.omapzoom.org/?p=platform/hardware/ti/wpan.git;a=summary .

The latest can be found at the Gingerbread branch. It's named uim-sysfs. Follow this link to get it:

http://git.omapzoom.org/?p=platform/hardware/ti/wpan.git;a=tree;f=ti_st/uim-sysfs;h=12ce6bafd461474ad90d41a0b9523a94534e4c0a;hb=refs/heads/gingerbread

UIM needs to be run at boot since some Linux flavors may require Bluetooth or GPS to be turned on at boot.

To do so (run at boot time), have the UIM entry in one of your rc.S files. Alternatively, you can specify a special udev rule based on the platform driver in addition to the device "kim" [Need Modification].

For Android, the following entry in the init.rc should suffice:

service uim /system/bin/uim-sysfs
    user root
    group media bluetooth
    oneshot

Android Solution1 - FM Radio GUI Application, Services on TI FM Stack

TI Android FM Radio solution provides an implementation of FM Radio GUI and Services for Android OS. This solution uses TI FM Stack interface (/dev/tifm) to communicate to WL12xx device over Shared Transport driver.

All GUI and Services source code and their integration docs can be found under the following GIT: [1]

Android Solution2 - FM Radio GUI Application, Services on FM V4L2 Stack

This is a work in Progress.... check back later. This solution also provides Android FM Radio implementation with FM Radio GUI and Services for Android OS, but using a different FM Stack interface (/dev/radio0) that is V4l2 standard compliant.

Setting up the Firmware

All three connectivities -- Bluetooth, FM and GPS -- require their own firmware files. The Bluetooth firmware core file is used earlier (first) than the other cores in WiLink.

The latest firmware files are available on this site:

https://gforge.ti.com/gf/project/wilink_drivers/

Shared Transport driver uses the firmware class sub-system to download firmware files. Hence the firmware ".bts" files should be placed in /system/etc/firmware/ for Android and /lib/firmware/ for Ubuntu.

On Boot Check

Since there are many versions of the drivers floating around and a lot needs to be done to get them all working fine, checking a few things as mentioned below will ensure that the porting effort went well :

Enabling Profiles on Android

Important Notes

The platform data and its structure constantly, inevitably change. Hence, before adding the platform device, make sure that the platform data matches in type and structure to the platform data defined in the file: include/linux/ti_wilink_st.h.

Support Contacts

If you have any questions, doubts or suggestions please send them to: WCG Leads.

Back to Connectivity Home Page

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox