Request for input regarding new driver in MFD for GPS_Bluetooth_FMcontroller CG2900

[Par-Gunnar Hjalmdahl]

Hi,

Me and my colleagues here at ST-Ericsson SA are working on a Linux
driver for our connectivity combo chip CG2900
(http://www.stericsson.com/product/223489.jsp).
CG2900 is a controller containing GPS, Bluetooth, and FM radio (also
called GBF-controller), which can be connected to the platform using
UART or SPI as transport. The communication towards the different
functionalities is done via so-called HCI H:4 channels, where the
first byte in the message determines the channel being used for the
particular message. Channels 1, 2, 3, and 4 are used for Bluetooth
(Command, ACL, SCO, and Event) according to Bluetooth specification
while 8 is used for FM radio and 9 is used for GPS. There are also a
few other channels used for various debug purposes.

Since there are multiple functionalities we thought that a good place
to put this driver is as a MFD driver. I hope you agree?
As can be seen below there is also a driver for the BlueZ stack, cg2900_hci.

The architecture of the driver is as follows:
 - cg2900_core: Implements driver API. Keeps track of opened channels,
registered chip handlers, and transport used. When first user
registers it requests startup of chip. When last user deregisters it
requests shutdown of chip. Uses Bluetooth HCI Local Version
Information to determine chip connected.
 - cg2900_chip: Implements chip specific features for the CG2900.
Downloads patches and settings during chip startup.
 - stlc2690_chip: As cg2900_chip but for STLC2690 controller (BT/FM combo).
 - cg2900_uart: Registers as a driver for the TTY Line Discipline
N_HCI. When transport is opened from User Space, e.g. from hciattach,
it registers as transport to cg2900_core.
 - cg2900_spi: Registers to the SPI driver. When being probed it
registers as transport to cg2900_core.
 - cg2900_char_device: Exposes all channels as character devices so
they can be used by user space stacks.
 - cg2900_hci: Registers to BlueZ (i.e. not a MFD driver) and to the
CG2900 MFD driver. Acts as a connector for Bluetooth functionality
between BlueZ and CG2900 MFD driver.

The API as it is now contains functions for:
 - register
 - deregister
 - alloc_skb
 - write
 - reset
 - get_chip_revision

For a user the normal way to work would be:
 - Register to the driver. The user supplies a name to the channel for
look-up and a set of callbacks for receiving data and detecting reset.
The register function returns, if successful, a pointer to a device
structure used when calling the other functions.
 - Send data to the chip using the write function, supplying device
structure and sk_buffer.
 - Receive data from the chip through the read callback, which
supplies device structure and sk_buffer.
 - Perform reset of the chip of a lock-up is detected by the stack.
 - Deregister from the driver.

Compared to other MFD drivers there are some major differences:
 - The CG2900 driver does not use the MFD core functions, such as
mfd_add_devices, but that could be changed quite easily by replacing
register and deregister with users using the MFD device probe instead.
This could however collide with the next difference.
 - The CG2900 driver is made with freedom of choice and usage in mind.
It is possible to dynamically open and close channels and even
transports. This means that you could open a channel first from Kernel
space (using API), then it could be closed and another user could open
it from User space (using char dev). From what I've heard this is not
very popular among the Linux community, but I really like the way it
works. Note that any channel can only have one user at a time.

I know that there are also other HCI combo chips with Linux drivers,
e.g by TI. If there is a wish we could modify this driver from cg2900
to e.g. hci_combo and make it neutral inside cg2900_core from which
chip is actually being used. This way any manufacturer could use it as
a generic framework for their multifunction HCI combo devices.


So if you've been able to read through this long message I would like
you to think through and voice your opinion about what I've presented
above. Especially:
 - Shall I use the MFD functions instead of our own API?
 - Is it OK to dynamically use the channels either from Kernel or User space?
 - Would you prefer this to be a ST-Ericsson CG2900 chip driver only
or would you like an HCI-Combo framework where you could add your own
chips?

Best regards,

Pär-Gunnar Hjälmdahl
Senior Staff Engineer
ST-Ericsson SA
Lund, Sweden
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/