Return-Path: MIME-Version: 1.0 Reply-To: pghatwork@gmail.com In-Reply-To: References: <20100910143813.4af0a3ce@lxorguk.ukuu.org.uk> Date: Wed, 15 Sep 2010 12:14:17 +0200 Message-ID: Subject: Re: Request for input regarding new driver in MFD for GPS_Bluetooth_FM controller CG2900 From: Par-Gunnar Hjalmdahl To: Pavan Savoy Cc: Alan Cox , linus.walleij@stericsson.com, linux-kernel@vger.kernel.org, linux-bluetooth@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-bluetooth-owner@vger.kernel.org List-ID: 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 > 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