Device Driver Interface of WiLink Solution

From OMAPpedia

(Difference between revisions)
Jump to: navigation, search
m (Hardware Interface and MUX mode configuration)
m (Added the permissions required for BT/FM/GPS)
 
(43 intermediate revisions not shown)
Line 1: Line 1:
-
== Introduction ==
+
== Hardware Interface and MUX mode configuration ==
-
Generally used OMAP and Connectivity combinations are OMAP3 and WL127x (as in Zoom2, Zoom3 devices) or OMAP4 and WL128x (as in Blaze devices). However, few customers and internal TI teams need combinations OMAP3 + WL128x and OMAP4 + WL127x.
+
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.
-
The following hints should help in case you have combination of devices and not making use of the devices on-board.
+
-
For on-board devices, i.e Zoom2/3(with WL127x), Blaze(with WL128x) and Panda (with WL127x) - The relevant releases for the board
+
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.
-
should get Bluetooth, FM work '''out of the box'''.
+
-
There are multiple WiLink devices that can be supported on multiple OMAP platforms. Below list provides combination of platforms available:
+
The mux-mode configurations of these hardware interfaces can be configured via the OMAP MUX framework supported by the BSP as follows:
-
* OMAP3 + 1271 + 5500 (default for OMAP3)
+
-
* OMAP3 + 1283
+
-
* OMAP4 + 1283 (default for OMAP4)
+
-
* OMAP4 + 1271
+
-
== Porting shared transport solution ==
 
-
Shared Transport driver is a line discipline driver, which acts a generic transport for Bluetooth, FM and GPS (in case of WL128x).
 
-
Each such protocol drivers have a register, unregister mechanism with the shared transport driver and upon registration can do a
 
-
write concurrently, and shared transport would queue up the data and would send it over UART.
 
-
Upon receiving protocol specific data, shared transport would interpret the data and forward it to protocol driver via callbacks.
 
-
Shared transport driver is also a platform device driver and hence any platform which has a WL127x/WL128x device and wants to make use of this driver, need to have an entry of adding the platform device in their architecture specific board file.
+
Example 1: On Zoom3 the N-Shut-Down line is connected to GPIO 109.
-
 
+
-
Illustration:-
+
<pre>
<pre>
-
/* wl128x BT, FM, GPS connectivity chip */
+
In file arch/arm/mach-omap2/board-zoom3.c you would find the following entry:
-
struct ti_st_plat_data wilink_pdata = {
+
         omap_mux_init_gpio(109, OMAP_PIN_OUTPUT);
-
        .nshutdown_gpio = 55,
+
-
        .dev_name = "/dev/ttyO1",
+
-
        .flow_cntrl = 1,
+
-
         .baud_rate = 3000000,
+
-
};
+
-
static struct platform_device wl128x_device = {
+
-
        .name          = "kim",
+
-
        .id            = -1,
+
-
        .dev.platform_data = &wilink_pdata,
+
-
};
+
</pre>
</pre>
-
and in one of the architecture init functions, perform :-
+
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''.
-
platform_device_register(&wl128x_device);
+
-
== Hardware Interface and MUX mode configuration ==
+
Example 2: On OMAP3SDP/Blaze's x-loader, the McBSP1 is connected to the BT-PCM lines.
-
The WiLink Connectivity chip's BT/FM/GPS IPs are interfaced with the application processor(OMAP) by UARTs. A GPIO line called "nShutDown" acts as the chip enable line for the connectivity chip.
+
-
Apart from this the connectivity chip is interfaced to BT core via PCM lines (mcbsp if OMAP) and the FM core via i2S(or PCM).
+
-
The BT-PCM lines carry the voice data during call scenario, and 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 done via the OMAP MUX framework supported by the BSP
 
<pre>
<pre>
-
Example: On Zoom3 where the N-Shut-Down line is connected to GPIO 109.
+
In file board/omap4430sdp/omap4430sdp.c of the ''u-boot'' source code, you will find entries which look like:
-
In file arch/arm/mach-omap2/board-zoom3.c you would find an entry,
+
 
-
        omap_mux_init_gpio(109, OMAP_PIN_OUTPUT);
+
-
</pre>
+
-
The configurations can also be done in the u-boot
+
-
<pre>
+
-
Example: On OMAP3SDP/Blaze, the McBSP1 is connected to the BT-PCM lines,
+
-
In file board/omap4430sdp/omap4430sdp.c of the u-boot source code, you would find entries such as,
+
         MV(CP(ABE_MCBSP1_DX),  (OFF_EN | OFF_OUT_PTD | M0)) /* abe_mcbsp1_dx */ \
         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 */ \
         MV(CP(ABE_MCBSP1_FSX),  (IEN | OFF_EN | OFF_PD | OFF_IN | M0)) /* abe_mcbsp1_fsx */ \
Line 61: Line 27:
         MV(CP(ABE_MCBSP1_DX),  (OFF_EN | OFF_OUT_PTD | M0)) /* abe_mcbsp1_dx */ \
         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 */ \
         MV(CP(ABE_MCBSP1_FSX),  (IEN | OFF_EN | OFF_PD | OFF_IN | M0)) /* abe_mcbsp1_fsx */ \
 +
</pre>
-
Example: On OMAP4SDP/Blaze, the OMAP UART2 is connected to the BT-HCI-UART
+
Example 3: On OMAP4SDP/Blaze, the OMAP UART2 is connected to the BT-HCI-UART.
 +
 
 +
<pre>
         MV(CP(UART2_CTS),      (PTU | IEN | M0)) /* uart2_cts */ \
         MV(CP(UART2_CTS),      (PTU | IEN | M0)) /* uart2_cts */ \
         MV(CP(UART2_RTS),      (M0)) /* uart2_rts */ \
         MV(CP(UART2_RTS),      (M0)) /* uart2_rts */ \
Line 68: Line 37:
         MV(CP(UART2_TX),        (M0)) /* uart2_tx */ \
         MV(CP(UART2_TX),        (M0)) /* uart2_tx */ \
</pre>
</pre>
-
''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 ==
+
'''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 at drivers/bluetooth/btwilink.c provides the bluetooth driver which 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.
+
== Shared Transport (ST) driver ==
 +
 
 +
TI_ST driver 'aka shared transport driver provides a line discipline driver, line discipline N_TI_WL value 22 to multiplex Bluetooth, FM, GPS and other short range wireless technologies interfaced over UART in WiLink connectivity chipsets.
 +
 
 +
The build for this driver is driven by the configuration option CONFIG_TI_ST and the driver sources are located at drivers/misc/ti-st/ directory.
 +
 
 +
To bind together line discipline and the protocol driver (Bluetooth, FM driver) data, TI_ST driver is probed as a platform device driver and require the platform device driver data to be initialized in the arch/XX/mach-XX.c board specific file.
 +
The platform device driver data can be populated according to latest information and documentation available at include/linux/ti_wilink_st.h for struct ti_st_plat_data{}.
 +
 
 +
<pre>
 +
struct ti_st_plat_data {
 +
        long nshutdown_gpio;
 +
        unsigned char dev_name[UART_DEV_NAME_LEN]; /* uart name */
 +
        unsigned char flow_cntrl; /* flow control flag */
 +
        unsigned long baud_rate;
 +
        < more members in actual structure .... >
 +
};
 +
</pre>
 +
 
 +
== 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.
 +
 
 +
Build for this driver is driven by the configuration option CONFIG_BT_WILINK.
 +
 
 +
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:
-
Similar to the TI ST driver, this is also a platform device driver and requires a relevant platform device registration,
 
<pre>
<pre>
static struct platform_device btwilink_device = {
static struct platform_device btwilink_device = {
Line 83: Line 75:
</pre>
</pre>
-
The above platform device along with addition in one of the architecture init functions, would enable the Bluetooth driver for WiLink chipsets.
+
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'':
 +
 
 +
<pre>
 +
platform_device_register(&btwilink_device);
 +
</pre>
== User Space components ==
== User Space components ==
-
A utility known as UIM is very much required for the shared transport [TI_ST] driver to be working.
 
-
Most line disciplines if not all require a user-space daemon to be opening the UART and installing the line discipline thereby giving out the control to the line discipline driver.
 
-
UIM can be found @ http://git.omapzoom.org/?p=platform/hardware/ti/wpan.git;a=summary
+
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.
-
The latest can be found at gingerbread branch by name uim-sysfs,
+
 
-
http://git.omapzoom.org/?p=platform/hardware/ti/wpan.git;a=tree;f=ti_st/uim-sysfs;h=12ce6bafd461474ad90d41a0b9523a94534e4c0a;hb=refs/heads/gingerbread
+
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].
 +
 
 +
Depending on hardware platform, permission for /dev/ttyxx interface to be mapped to bluetooth to be added in init.rc
 +
For Android, the following entry in the ''init.rc'' should suffice.
 +
 
 +
For OMAP4:
 +
<pre>
 +
# change permissions for Bluetooth/FM/GPS
 +
    chmod 0660 /sys/class/rfkill/rfkill0/state
 +
    chown bluetooth bluetooth /sys/class/rfkill/rfkill0/state
 +
    chmod 0660 /dev/ttyO4
 +
    chown bluetooth bluetooth /dev/ttyO1
 +
</pre>
-
UIM needs to be run at boot, Since linux flavors might require Bluetooth or GPS to be turned on at boot.
 
-
For this have the UIM entry in your either one of your rc.S files or you can have special udev rule based on the platform driver
 
-
addition of device "kim".
 
-
For Android, the following entry in init.rc should suffice,
 
<pre>
<pre>
Line 105: Line 117:
</pre>
</pre>
-
== firmware ==
+
Note:
-
Bluetooth, FM and GPS all require their own firmware files, with the Bluetooth firmware being required to be downloaded before any
+
-
of the other cores are made use of in WiLink.
+
-
https://gforge.ti.com/gf/project/wilink_drivers/ - Should point to the latest firmware files that are released.
+
-
Shared Transport driver uses the firmware class sub-system to download firmware and hence the firmware ".bts" files need to exist in '''/system/etc/firmware/''' for Android and '''/lib/firmware/''' for ubuntu.
+
1. UIM needs access to the UART connected to BT/FM/GPS/NFC and therefore it has  to be the owner/group of the UART.
-
== On boot check ==
+
2. The permission for the rfkill entry created by bluetooth kernel sub-system has to be added, which is accessed by bluedroid which belongs to group bluetooth.
-
Since there are many versions of the drivers floating around and a lot needs to be done to get them all working fine.
+
 
-
A few things below can be checked if the port went well.
+
== 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 :
<ul>
<ul>
-
<li> If you intend to build the TI ST driver, btwilink driver, FM and GPS drivers as modules, then
+
 
-
'''st_drv.ko, btwilink.ko, fm_drv.ko and gps_drv.ko''' should exist in the file-system [at "/" for Android]
+
<li> Check up on the following default config options available in the ".config" of your kernel build directory, If any of the options among '''CONFIG_TI_ST''', '''CONFIG_BT_WILINK''', '''CONFIG_RADIO_WL128X''' is "=m" then it would mean the relevant driver would be built as a module.
-
<li> The modules needs to be inserted manually if the UIM does not do the job at boot, and can be checked for by ''$lsmod''
+
If the above mentioned options are configured to be "=y" then it would be built-in to the kernel and you would not need to perform the next 2 steps.
-
<li> sysfs directory '''/sys/devices/platform/kim''' should exist with important entries like install, dev_name, baud_rate present.
+
<br>
-
These entries should also represent at which UART the WiLink is connected on platform.
+
<li> If you intended to build the following modules: TI ST driver, btwilink driver, FM and GPS, then make sure that the following kernel object files are present in the file-system (In the root "/" for Android.): '''st_drv.ko, btwilink.ko, fm_drv.ko and gps_drv.ko'''.
-
<li> '''/sys/devices/platform/btwilink''' should exist. If this does then the hci0 interface can be checked for by simple bluez commands such as ''$hciconfig -a''
+
<br>
-
<li> FM driver initialization can be confirmed by checking the device node '''''/dev/radio0'''''
+
<li> The above modules need to be inserted manually (with insmod) if the UIM does not do the job at boot. You can check that by doing a lising of the modules present. Use ''$lsmod'' to list the modules loaded.
-
<li> GPS driver initialization can be confirmed by checking the device node '''''/dev/tigps'''''
+
<br>
 +
<li> The directory ''sysfs'' should exist. The directory ''/sys/devices/platform/kim'' should also exist with the important entries like install, dev_name, baud_rate present. These entries should also represent at which UART the WiLink is connected for the platform.
 +
<br>
 +
<li> Similarily, the directory ''/sys/devices/platform/btwilink'' should exist. If this does then the hci0 interface can be checked using the command ''$hciconfig -a''.
 +
<br>
 +
<li> The process '''uim-sysfs''' should be running, this can be checked by peforming the '''$ps''' command. This would be started at system boot, because of the service entry uim.
 +
<br>
 +
<li> The ''FM driver'' initialization can be confirmed by checking the device node ('''''/dev/tifm''''' or '''''/dev/radio0''''' depending on the implementation).
 +
<br>
 +
<li> The ''GPS driver'' initialization can be confirmed by checking the device node '''''/dev/tigps'''''.
</ul>
</ul>
-
== Enabling profiles on Android ==
+
== Enabling Profiles on Android ==
 +
 
<ul>
<ul>
-
<li> GAP - Generic Access Profile<br>
+
 
-
Bluetooth-Settings under Wireless Setting menu of the Setting Application in Android, allows you to Scan, Pair and Connect to
+
<li> GAP - Generic Access Profile:<br>
-
devices, upon Scanning, the type of device is detected by Android and connection is made upon user's request.
+
:Bluetooth-Settings under Wireless Setting menu of the Setting Application in Android allows you to Scan, Pair and Connect to the devices. Upon scanning, the type of device is detected by Android and the connection is established upon the user's request.
-
<li> A2DP - Audio Streaming via Bluetooth<br>
+
 
-
This is one of those profiles, which has android has support for in its profile and is expected to work out of the box as
+
<li> A2DP - Audio Streaming via Bluetooth:<br>
-
soon as you have Bluetooth working. Apart from the baud-rate on UART no other factor should generally cause the A2DP
+
:Android supports this profile. As soon as you have Bluetooth working, this is expected to work ''out of the box''. On Android, apart from the baud-rate on UART no other factor should generally cause the A2DP profile to break.
-
profile to break on android.
+
 
-
<li> AVRCP - Audio Video Remote Control Profile<br>
+
<li> AVRCP - Audio Video Remote Control Profile:<br>
-
This requires the uInput to be enabled in the kernel - make menuconfig for more details.
+
:This requires the ''uInput'' to be enabled in the kernel; Issue ''make menuconfig'' for more details.
-
<li> HFP/HSP - Head Set and Hands Free (In-Call operation)<br>
+
 
-
While all other kind of bluetooth data goes over UART, this one goes over from the OMAP, to the BT via the McBSP.
+
<li> HFP/HSP - Head Set and Hands Free (In-Call operation):<br>
-
Different platforms have different configurations for the McBSP that has been interfaced with BT-PCM lines.
+
:While all other kind of Bluetooth data goes over UART, this one goes through the OMAP to the BT via the McBSP. Different platforms have different configurations for the McBSP that has been interfaced with BT-PCM lines. Even without the Modem, the BT-PCM lines are verified by streaming music and record voice from the BT-headset.
-
Even without the Modem, the BT-PCM lines are verified by streaming music and record voice from the BT-headset.
+
 
-
<li> HID <br>
+
<li>HID:<br>
-
On connection to a Bluetooth Keyboard or Mouse, the HID functionality should work out of the box.
+
:On connection to a Bluetooth Keyboard or Mouse, the HID functionality should work ''out of the box''.
-
<li> PBAP/OPP <br>
+
 
-
Object push, Vcard listing should also work out of box, since Android provides them
+
<li>PBAP/OPP:<br>
-
<li> FTP <br>
+
:Since Android provides them, ''object push'' and ''Vcard listing'' should also work ''out of box''.
-
3rd party applications like BlueFTP are available from Android App Market which should work without modifications upon installation.
+
 
 +
<li>FTP:<br>
 +
:There are 3rd party applications, called ''BlueFTP'', that are available from ''Android App Market'' that should work without any modifications upon installation.
 +
 
 +
<li>SPP:<br>
 +
:There are 3rd party applications, like ''BlueTerm'', that are available from ''Android App Market'' that should work without any modifications upon installation.
 +
 
</ul>
</ul>
 +
== Important Notes ==
== Important Notes ==
-
The platform data and its structure tend to keep changing, and hence before adding the platform device, please make sure
+
 
-
the platform data matches in type and structure of the platform data defined in include/linux/ti_wilink_st.h
+
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 ==
== Support Contacts ==
-
Write your queries to [mailto:wcg-leads@list.ti.com WCG Leads]
 
 +
If you have any questions, doubts or suggestions please send them to: [mailto:wcg-leads@list.ti.com WCG Leads].
 +
 +
[http://www.omappedia.org/wiki/OMAP_WiLink_Connectivity_Home Back to Connectivity Home Page]
-
[[Category:Porting]]
+
[[Category:Wilink]]

Latest revision as of 20:24, 20 February 2012

Contents

[edit] 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.


[edit] Shared Transport (ST) driver

TI_ST driver 'aka shared transport driver provides a line discipline driver, line discipline N_TI_WL value 22 to multiplex Bluetooth, FM, GPS and other short range wireless technologies interfaced over UART in WiLink connectivity chipsets.

The build for this driver is driven by the configuration option CONFIG_TI_ST and the driver sources are located at drivers/misc/ti-st/ directory.

To bind together line discipline and the protocol driver (Bluetooth, FM driver) data, TI_ST driver is probed as a platform device driver and require the platform device driver data to be initialized in the arch/XX/mach-XX.c board specific file. The platform device driver data can be populated according to latest information and documentation available at include/linux/ti_wilink_st.h for struct ti_st_plat_data{}.

struct ti_st_plat_data {
        long nshutdown_gpio;
        unsigned char dev_name[UART_DEV_NAME_LEN]; /* uart name */
        unsigned char flow_cntrl; /* flow control flag */
        unsigned long baud_rate;
        < more members in actual structure .... >
};

[edit] 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.

Build for this driver is driven by the configuration option CONFIG_BT_WILINK.

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);

[edit] 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].

Depending on hardware platform, permission for /dev/ttyxx interface to be mapped to bluetooth to be added in init.rc For Android, the following entry in the init.rc should suffice.

For OMAP4:

# change permissions for Bluetooth/FM/GPS
    chmod 0660 /sys/class/rfkill/rfkill0/state
    chown bluetooth bluetooth /sys/class/rfkill/rfkill0/state
    chmod 0660 /dev/ttyO4
    chown bluetooth bluetooth /dev/ttyO1


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

Note:

1. UIM needs access to the UART connected to BT/FM/GPS/NFC and therefore it has to be the owner/group of the UART.

2. The permission for the rfkill entry created by bluetooth kernel sub-system has to be added, which is accessed by bluedroid which belongs to group bluetooth.

[edit] 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.


[edit] 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 :

[edit] Enabling Profiles on Android


[edit] 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.


[edit] 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