Message-ID: <854009.90562.qm@web94910.mail.in2.yahoo.com>
Date:	Wed, 24 Mar 2010 23:12:32 +0530 (IST)
From:	Pavan Savoy <pavan_savoy@...oo.co.in>
To:	Marcel Holtmann <marcel@...tmann.org>
Cc:	Greg KH <gregkh@...e.de>, PavanSavoy <pavan_savoy@...com>,
	"alan@...rguk.ukuu.org.uk" <alan@...rguk.ukuu.org.uk>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module

--- On Wed, 24/3/10, Marcel Holtmann <marcel@...tmann.org> wrote:

> From: Marcel Holtmann <marcel@...tmann.org>
> Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module
> To: "Pavan Savoy" <pavan_savoy@...oo.co.in>
> Cc: "Greg KH" <gregkh@...e.de>, "PavanSavoy" <pavan_savoy@...com>, "alan@...rguk.ukuu.org.uk" <alan@...rguk.ukuu.org.uk>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
> Date: Wednesday, 24 March, 2010, 10:45 PM
> Hi Pavan,
> 
> > > > > > I wanted to somehow put this in
> staging
> > > because then
> > > > > it would probably have a thorough
> architectural
> > > review
> > > > > process.
> > > > > > Some details about this driver - 
> > > > > > 
> > > > > > 1. This driver will be used by
> > > Bluetooth-BlueZ/FM-V4L2
> > > > > and GPS (probably character device
> driver) using
> > > the
> > > > > EXPORTED symbols
> (-register/_unregister).
> > > > > > 
> > > > > > 2. Much like the hciattach daemon
> which
> > > maintains
> > > > > N_HCI bluetooth line discipline, this
> driver will
> > > also have
> > > > > a User-Space  N_TI_WL Init manager
> (UIM)
> > > maintaining
> > > > > the Line discipline.
> > > > > 
> > > > > can you explain why you think this is
> needed and
> > > we can not
> > > > > interface
> > > > > this directly. If it is a serial port,
> what
> > > protocol does
> > > > > it talk?
> > > > 
> > > > Illustration: The BT driver on top of this
> ST driver,
> > > would create a hci0 interface, when someone does
> an DEVUP on
> > > that interface, the BT driver would then do a
> st-register -
> > > which in-turn would ask the hciattach-like daemon
> to install
> > > the line discipline for it via the sysfs entry.
> > > > The same concept goes for FM-V4L2 and GPS
> character
> > > driver.
> > > > 
> > > > The core of the problem is we cannot
> > > ask/install/ldisc_put for a line discipline from
> kernel
> > > space.
> > > 
> > > so let us get the facts straight here. The device
> in
> > > question is using a
> > > serial port to connect to the host and then
> multiplexing
> > > BT, FM and GPS
> > > over it. My question again, what protocol does it
> talk.
> > 
> > Ok, On TTY/4-wire UART, BT talks standard HCI, and
> HCI-LL for power management as in hci_ll.c/hciattach_ti.c
> which is already upstream.
> > 
> > And in a very similar way, FM talks over what is known
> as "channel 8" and GPS over "channel 9", Although these are
> not standard.
> > 
> > So, basically data going/coming to/out of chip is 
> > 1,2,3,4 - HCI 
> > 30,31,32,33 for HCI-LL
> > 8 - FM
> > 9 - GPS.
> > 
> > So consider this an extension of hci_ll/hci_ldisc but
> only more features to accomodate the FM and GPS.
> 
> So why are we not making the hci_ll into a generic driver
> that can
> register besides Bluetooth also FM and GPS.
> 
> Then we can attach that driver to the TTY via line
> discipline on boot
> and let the LL part handle the power management.
> 

Well hci_ll is tied up with hci_ldisc, we might not even want BT/FM on system, may be just GPS (like we have for 1 version of chip).
In that case GPS directly uses the ST line discipline.

Also few other things like firmware download, a chance for the ldisc driver to be platform device, to take in chip enable GPIOs, is sort of appropriate for a new driver isn't it ?


> Registration of Bluetooth device, FM and GPS nodes are done
> via RFKILL
> that the LL driver exports.
> 
> > > Also why not just install the line discipline and
> then
> > > control the
> > > subdevices via RFKILL?
> > 
> > The chip side PM would be fine, and is being done so,
> st_kim.c creates the rfkill entries, and controls them
> locally, also allows applications to control them.
> > But ldisc can't be install upon boot, because UART
> clks would be used up for no reason at all.
> > (say on a mobile phone, how many times in a day - do
> we actually use BT/FM or GPS - so UART needs to be most
> often idle, and ldisc should be installed only upon
> requirement)
> 
> I think the driver should make sure it doesn't use the UART
> clocks if in
> deep sleep. This has nothing to do with installing the line
> discipline
> on boot via a userspace tool.
> 
> You do the power management for the hci_ll driver already
> today. So why
> can't we do the same in this driver?
> 

Correct, However that piece of Android code, as far as I have seen it depends on bunch of interfaces provided by the UART driver.
This ldisc on other hand doesn't can work on 8250 driver or with complicated ones like the omap-serial which provides such interfaces to shut off UART clks as and when required.

> Another way to view this is that the LL driver has to
> create a virtual
> bus for Bluetooth, FM and GPS devices. However RFKILL might
> be a bit
> more suitable and simpler.
> 

Currently rfkill provided is just sort of an extension, but really it just depends on what protocol (bt, fm, GPS) is being ST_registered, the relevant chip_enable gpio is picked up from platform_device entry in arch/XX/board-YY.c and enabled.

> Regards
> 
> Marcel
> 
> 
> --
> 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/
> 


      The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/
--
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