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
Hi,
On Wed, Sep 15, 2010 at 5:14 AM, Par-Gunnar Hjalmdahl
<[email protected]> wrote:
> Hi Pavan,
>
> Thanks for your comments and sorry for me taking time to answer your mail.
> See below for answers.
>
>>
>> ok bit more of information ....
>> We don;t use the hciattach, instead we have our own daemon which opens
>> up the UART and installs the line discipline (not N_HCI, but similar
>> one called N_SHARED) when the hciconfig hci0 up happens or even when
>> /dev/radio0 (FM V4L2 device) happens or when generic GPS character
>> device (/dev/tigps) happens...
>
> :-) We also have our own user space application for opening the UART
> and setting the line disc since we don't want to depend completely on
> hciattach, which contains more than we need, and also misses stuff
> that we want to do towards our specific controller. I just used it as
> an example since that is the common BlueZ way to open the Bluetooth
> transport.
Ok, yes currently we communicate with user-space daemon over rfkill,
we can probably use UDEV events to communicate opening/installation of
ldisc or closing of UART.
>>
>> There is non-mailine driver which gets modified to get into mainline @
>> http://git.omapzoom.org/?p=kernel/omap.git;a=tree;f=drivers/misc/ti-
>> st;h=028ff4a739d7b59b94d0c613b5ef510ff338b65d;hb=refs/heads/p-android-
>> omap-2.6.32
>>
>> feel free to have a look at it...
>> Yes our solution too works with BlueZ and non-exactly a MFD driver but
>> it is a simple platform device driver .. by looks of things the driver
>> can run as is for your chip too .. (except for the firmware search and
>> download part .. may be...).
>
> Your code is in a lot of ways similar to ours (which is not so strange
> since you address the same market with your chip as we do with ours),
> but there are several differences that would at least for now make it
> impossible for us to use your driver. When we post our first patches
> (which will hopefully be in a few days) you can see for yourself. But
> I don't think there is a simple way for us to re-use your driver.
Humn, I kind of thought may be we can have a same driver for 2
different types of chips.
>>
>> and note when we would want to support SPI transport for the same, we
>> plan a SPI-TTY driver ('ala usb-serial) where-in we can install this
>> N_TI_WL line discipline on that /dev/ttySPI0 device, and the SPI
>> related stuff to be handled by the spi-tty.c which registers itself as
>> a tty_device and a tty_driver ....
>
> Our SPI usage will be a bit different, where we don't use TTY for our
> driver. We will use the SPI directly instead.
>
Ok, I was intending towards the SPI usage of our driver when we move to SPI.
>> regards,
>> Pavan
>>
>> On Fri, Sep 10, 2010 at 2:07 PM, Pavan Savoy <[email protected]>
>> wrote:
>> > Can you directly make use of the ti-st driver which is currently
>> staged?
>> > It has _EXACTLY_ the same thing.... which is REALLY REALLY surprising
>> !!!
>
> :-) As I said earlier this is quite natural since both TI and
> ST-Ericsson address the same market segments.
yes...
> /P-G
>
Hi Pavan,
Thanks for your comments and sorry for me taking time to answer your mail.
See below for answers.
>
> ok bit more of information ....
> We don;t use the hciattach, instead we have our own daemon which opens
> up the UART and installs the line discipline (not N_HCI, but similar
> one called N_SHARED) when the hciconfig hci0 up happens or even when
> /dev/radio0 (FM V4L2 device) happens or when generic GPS character
> device (/dev/tigps) happens...
:-) We also have our own user space application for opening the UART
and setting the line disc since we don't want to depend completely on
hciattach, which contains more than we need, and also misses stuff
that we want to do towards our specific controller. I just used it as
an example since that is the common BlueZ way to open the Bluetooth
transport.
>
> There is non-mailine driver which gets modified to get into mainline @
> http://git.omapzoom.org/?p=kernel/omap.git;a=tree;f=drivers/misc/ti-
> st;h=028ff4a739d7b59b94d0c613b5ef510ff338b65d;hb=refs/heads/p-android-
> omap-2.6.32
>
> feel free to have a look at it...
> Yes our solution too works with BlueZ and non-exactly a MFD driver but
> it is a simple platform device driver .. by looks of things the driver
> can run as is for your chip too .. (except for the firmware search and
> download part .. may be...).
Your code is in a lot of ways similar to ours (which is not so strange
since you address the same market with your chip as we do with ours),
but there are several differences that would at least for now make it
impossible for us to use your driver. When we post our first patches
(which will hopefully be in a few days) you can see for yourself. But
I don't think there is a simple way for us to re-use your driver.
>
> and note when we would want to support SPI transport for the same, we
> plan a SPI-TTY driver ('ala usb-serial) where-in we can install this
> N_TI_WL line discipline on that /dev/ttySPI0 device, and the SPI
> related stuff to be handled by the spi-tty.c which registers itself as
> a tty_device and a tty_driver ....
Our SPI usage will be a bit different, where we don't use TTY for our
driver. We will use the SPI directly instead.
>
> regards,
> Pavan
>
> On Fri, Sep 10, 2010 at 2:07 PM, Pavan Savoy <[email protected]>
> wrote:
> > Can you directly make use of the ti-st driver which is currently
> staged?
> > It has _EXACTLY_ the same thing.... which is REALLY REALLY surprising
> !!!
:-) As I said earlier this is quite natural since both TI and
ST-Ericsson address the same market segments.
/P-G
ok bit more of information ....
We don;t use the hciattach, instead we have our own daemon which opens
up the UART and installs the line discipline (not N_HCI, but similar
one called N_SHARED) when the hciconfig hci0 up happens or even when
/dev/radio0 (FM V4L2 device) happens or when generic GPS character
device (/dev/tigps) happens...
There is non-mailine driver which gets modified to get into mainline @
http://git.omapzoom.org/?p=kernel/omap.git;a=tree;f=drivers/misc/ti-st;h=028ff4a739d7b59b94d0c613b5ef510ff338b65d;hb=refs/heads/p-android-omap-2.6.32
feel free to have a look at it...
Yes our solution too works with BlueZ and non-exactly a MFD driver but
it is a simple platform device driver .. by looks of things the driver
can run as is for your chip too .. (except for the firmware search and
download part .. may be...).
and note when we would want to support SPI transport for the same, we
plan a SPI-TTY driver ('ala usb-serial) where-in we can install this
N_TI_WL line discipline on that /dev/ttySPI0 device, and the SPI
related stuff to be handled by the spi-tty.c which registers itself as
a tty_device and a tty_driver ....
regards,
Pavan
On Fri, Sep 10, 2010 at 2:07 PM, Pavan Savoy <[email protected]> wrote:
> Can you directly make use of the ti-st driver which is currently staged?
> It has _EXACTLY_ the same thing.... which is REALLY REALLY surprising !!!
>
> On Fri, Sep 10, 2010 at 8:38 AM, Alan Cox <[email protected]> wrote:
>>> - Is it OK to dynamically use the channels either from Kernel or User space?
>>
>> Quite a few devices do this. In most cases it makes no sense to burden
>> the user with channel management so its only natural that opening the tty
>> or direct interfaces should "just work"
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
Can you directly make use of the ti-st driver which is currently staged?
It has _EXACTLY_ the same thing.... which is REALLY REALLY surprising !!!
On Fri, Sep 10, 2010 at 8:38 AM, Alan Cox <[email protected]> wrote:
>> - Is it OK to dynamically use the channels either from Kernel or User space?
>
> Quite a few devices do this. In most cases it makes no sense to burden
> the user with channel management so its only natural that opening the tty
> or direct interfaces should "just work"
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> - Is it OK to dynamically use the channels either from Kernel or User space?
Quite a few devices do this. In most cases it makes no sense to burden
the user with channel management so its only natural that opening the tty
or direct interfaces should "just work"