drivers:misc: sources for Init manager module
in [Kernel]
|
From: Alan Cox on 24 Mar 2010 13:30 > Isn't there a mechanism for the tty_set_ldisc to do what _open does ? > I mean there might be plenty of devices on UART which might not need /dev/tty at all ? i.e An App need not open for a ldisc to be installed. There is no mechanism to have an open tty without having an open file attached to it - and changing that would be very very non trivial. Plus you still need a way to tell the kernel you want the device in question active. That probably should get addressed some day but its not a quick fix up! Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pavan Savoy on 24 Mar 2010 13:40 --- On Wed, 24/3/10, Alan Cox <alan(a)lxorguk.ukuu.org.uk> wrote: > From: Alan Cox <alan(a)lxorguk.ukuu.org.uk> > Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module > To: "Pavan Savoy" <pavan_savoy(a)yahoo.co.in> > Cc: "Marcel Holtmann" <marcel(a)holtmann.org>, "Greg KH" <gregkh(a)suse.de>, "PavanSavoy" <pavan_savoy(a)ti.com>, "linux-kernel(a)vger.kernel.org" <linux-kernel(a)vger.kernel.org> > Date: Wednesday, 24 March, 2010, 10:56 PM > > Isn't there a mechanism for the > tty_set_ldisc to do what _open does ? > > I mean there might be plenty of devices on UART which > might not need /dev/tty at all ? i.e An App need not open > for a ldisc to be installed. > > There is no mechanism to have an open tty without having an > open file > attached to it - and changing that would be very very non > trivial. Plus > you still need a way to tell the kernel you want the device > in question > active. That probably should get addressed some day but its > not a quick > fix up! Which puts me back to square 1, the requirement is TTY device should be open, only when either BT, FM or GPS would want to use it. [with your patch one of the steps of installing ldisc would be reduced upon opening]. Now from kernel-space which is the first to get notification about requirement of BT/FM or GPS, I somehow have to communicate it to user-space, without the much disliked sysfs entry method. How do I tell the user-space when I want the TTY device to be opened ? Actually why do I even need a TTY device in this case - right ? ldisc driver can do the tty->ops->write and tty_read and put it up on different interfaces like eth0/hci0 or /dev/radio0 etc.. That would mean, a device can be on UART, a ldisc driver attached to it, and doesn't require a user-space daemon to maintain the device node. > > Alan > Your Mail works best with the New Yahoo Optimized IE8. Get it NOW! http://downloads.yahoo.com/in/internetexplorer/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on 24 Mar 2010 13:40 > Which puts me back to square 1, the requirement is TTY device should be open, only when either BT, FM or GPS would want to use it. > [with your patch one of the steps of installing ldisc would be reduced upon opening]. Perhaps but its up to you how you write your low level driver and how the ldisc indicates it wishes to be active (eg speed B0 is used to indicate 'no carrier' in many cases) > Actually why do I even need a TTY device in this case - right ? > ldisc driver can do the tty->ops->write and tty_read and put it up on different interfaces like eth0/hci0 or /dev/radio0 etc.. You don't need a tty if you are simply demuxing some kind of stream of bytes to/from the hardware and you gain nothing from the tty layer and user space interfaces such as control signal and speed setting. That may be even cleaner in your case as you can then then provide suitable links between your demux and the drivers attached to it indicating when they should be on or off. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pavan Savoy on 24 Mar 2010 13:50 --- On Wed, 24/3/10, Marcel Holtmann <marcel(a)holtmann.org> wrote: > From: Marcel Holtmann <marcel(a)holtmann.org> > Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module > To: "Pavan Savoy" <pavan_savoy(a)yahoo.co.in> > Cc: "Greg KH" <gregkh(a)suse.de>, "PavanSavoy" <pavan_savoy(a)ti.com>, "alan(a)lxorguk.ukuu.org.uk" <alan(a)lxorguk.ukuu.org.uk>, "linux-kernel(a)vger.kernel.org" <linux-kernel(a)vger.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(a)vger.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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pavan Savoy on 24 Mar 2010 14:50
--- On Wed, 24/3/10, Alan Cox <alan(a)lxorguk.ukuu.org.uk> wrote: > From: Alan Cox <alan(a)lxorguk.ukuu.org.uk> > Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module > To: "Pavan Savoy" <pavan_savoy(a)yahoo.co.in> > Cc: "Marcel Holtmann" <marcel(a)holtmann.org>, "Greg KH" <gregkh(a)suse.de>, "PavanSavoy" <pavan_savoy(a)ti.com>, "linux-kernel(a)vger.kernel.org" <linux-kernel(a)vger.kernel.org> > Date: Wednesday, 24 March, 2010, 11:09 PM > > Which puts me back to square 1, > the requirement is TTY device should be open, only when > either BT, FM or GPS would want to use it. > > [with your patch one of the steps of installing ldisc > would be reduced upon opening]. > > Perhaps but its up to you how you write your low level > driver and how the > ldisc indicates it wishes to be active (eg speed B0 is used > to indicate > 'no carrier' in many cases) > > > Actually why do I even need a TTY device in this case > - right ? > > ldisc driver can do the tty->ops->write and > tty_read and put it up on different interfaces like > eth0/hci0 or /dev/radio0 etc.. > > You don't need a tty if you are simply demuxing some kind > of stream of > bytes to/from the hardware and you gain nothing from the > tty layer and > user space interfaces such as control signal and speed > setting. > I still want to maintain this as a ldisc driver and the TTY layer is still required to be able to use this with different sort of serial drivers. example: We do a have a system here where both 8250/omap-serial co-exist creating their own device nodes (ttyS for 8250, ttyO for omap-serial) and I would want to be able to on boot suggest which serial driver to use, so I can open/install ldisc on ttyS or on ttyO. > That may be even cleaner in your case as you can then then > provide > suitable links between your demux and the drivers attached > to it > indicating when they should be on or off. And as Marcel suggested, can't really put in the PM/UART-clk shut off code in ldisc driver because few of these driver provide interfaces and few don't. So is there no way this can be accepted with the sysfs entry way of communication ? 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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |