Message-ID: <AANLkTikrfwTaa5h1QoATs2kcdySWiy1XXQXcY+Bj+tf6@mail.gmail.com>
Date:	Wed, 15 Sep 2010 15:57:40 -0500
From:	Pavan Savoy <pavan_savoy@...y.com>
To:	pghatwork@...il.com
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, linus.walleij@...ricsson.com,
	linux-kernel@...r.kernel.org, linux-bluetooth@...r.kernel.org
Subject: Re: Request for input regarding new driver in MFD for
 GPS_Bluetooth_FM controller CG2900

Hi,

On Wed, Sep 15, 2010 at 5:14 AM, Par-Gunnar Hjalmdahl
<par-gunnar.p.hjalmdahl@...ricsson.com> 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 <pavan_savoy@...y.com>
>> 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
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists