Re: Request for input regarding new driver in MFD for GPS_Bluetooth_FM controller CG2900

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <pavan_savoy@xxxxxxxx>
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux