Device Driver Interface of WiLink Solution
From OMAPpedia
(→User Space components) |
(→Android Solution1 - FM Radio GUI Application, Services on TI FM Stack) |
||
| Line 91: | Line 91: | ||
All GUI and Services source code and their integration docs can be found under the following GIT: | All GUI and Services source code and their integration docs can be found under the following GIT: | ||
| - | + | :http://git.omapzoom.org/?p=platform/hardware/ti/wpan.git;a=tree;f=fmradio/legacy_FMGUI;h=1958f63febc69848a943ac34586afd44ad615784;hb=gingerbread | |
== Android Solution2 - FM Radio GUI Application, Services on FM V4L2 Stack == | == Android Solution2 - FM Radio GUI Application, Services on FM V4L2 Stack == | ||
Revision as of 18:08, 1 August 2011
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:
The latest can be found at the Gingerbread branch. It's named uim-sysfs. Follow this link to get it:
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:
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:
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 :
- 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.
- 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.
- 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.
- Similarily, the directory /sys/devices/platform/btwilink should exist. If this does then the hci0 interface can be checked using the command $hciconfig -a.
- The FM driver initialization can be confirmed by checking the device node /dev/radio0.
- The GPS driver initialization can be confirmed by checking the device node /dev/tigps.
Enabling Profiles on Android
- GAP - Generic Access Profile:
- 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.
- A2DP - Audio Streaming via Bluetooth:
- 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.
- AVRCP - Audio Video Remote Control Profile:
- This requires the uInput to be enabled in the kernel; Issue make menuconfig for more details.
- HFP/HSP - Head Set and Hands Free (In-Call operation):
- 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.
- HID:
- On connection to a Bluetooth Keyboard or Mouse, the HID functionality should work out of the box.
- PBAP/OPP:
- Since Android provides them, object push and Vcard listing should also work out of box.
- FTP:
- There are 3rd party applications, like BlueFTP, that are available from Android App Market. They should work without any modifications upon installation.
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.
