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.


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.


Yes, couple were discussed, like creating a device node, and UIM would open device node, and ldisc driver then can do a fasync/SIGIO upon it - Sounds complex for a simplistic job.
Any more suggestion ?

requirement is the daemon should open/set-baud/and then TIOCSETD only upon requirement for either BT, FM or GPS.

Well, the idea is the driver isn't forgotten when this sort of thing happens.
Controversial (may be wrong) concepts like sending signal from kernel to user-space, parsing the script request via firmware class, creating a root kobject just to create a sysfs entry.



      The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/
--

[ message continues ]

Ok I had a brief dig

Making a driver able to say "and open me in this ldisc" is about ten
lines of code to the core tty layer if that.

There is one caveat - the actual ldisc attach method for an ldisc attach
isn't allowed to fail the attach. That's something we eventually need to
fix anyway.

Otherwise it doesn't look too scary and it would occur when the user
opened the file not when the device was created.

Alan
--

[ message continues ]

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.

Registration of Bluetooth device, FM and GPS nodes are done via RFKILL

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?

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.

Regards

Marcel


--

[ message continues ]