drivers:misc: sources for Init manager module
in [Kernel]
|
From: Marcel Holtmann on 24 Mar 2010 17:00 Hi Pavan, > > > 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 ? to be quite honest, I can't see how that can be accepted right now. It looks wrong on too many levels. 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/
From: Marcel Holtmann on 24 Mar 2010 17:00 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. that is what I am saying. Lets take the hci_ll driver out of it and create some sort of LL subsystem. Then the TI Bluetooth driver just uses LL and doesn't have to use hci_ldisc framework. Don't be afraid of taking hci_ll out of the Bluetooth part and make it a "subdriver" of your LL driver/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 ? I don't see a problem with it in general. However having some more details would help here to give clearer directions. > > 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. That sounds just like an excuse. We should be able to abstract this properly and make it work for Android and generic devices. > > 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. If possible please share some more details about the protocol in use and the platform architecture of the chip. I think you are trying to make this more complicated than it has to be. 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/
From: Pavan Savoy on 24 Mar 2010 17:10 Marcel, --- On Thu, 25/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: "Alan Cox" <alan(a)lxorguk.ukuu.org.uk>, "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: Thursday, 25 March, 2010, 2:24 AM > Hi Pavan, > > > > > 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 ? > > to be quite honest, I can't see how that can be accepted > right now. It > looks wrong on too many levels. Sigh - So to save power, and open/install tty-ldisc only when required, the sysfs entry was introduced. So now I guess I have 2 options :- 1. Fix the UART/LDISC upon boot by the daemon, get away with the sysfs entry + signaling altogether. 2. find a better way of telling the user-space daemon to open/install the line discipline. - So any suggestions on option 2 ? like some event mechanism which is simple and clean ? While we are at it, I will send across the BT driver too which makes use of this LDISC. > > Regards > > Marcel > > > 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 17:50 --- On Thu, 25/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: "Savoy, Pavan" <pavan_savoy(a)ti.com> > Cc: "Pavan Savoy" <pavan_savoy(a)yahoo.co.in>, "Greg KH" <gregkh(a)suse.de>, "alan(a)lxorguk.ukuu.org.uk" <alan(a)lxorguk.ukuu.org.uk>, "Deosthali, Amey" <adeosthali(a)ti.com>, "Alathur, Pramodh" <pramodh_ag(a)ti.com> > Date: Thursday, 25 March, 2010, 3:05 AM > Hi Pavan, > > > Find enclosed the design document, where in figure-1 > pretty much explains the different protocols for FM, GPS, BT > and HCI-LL. > > just after quickly going through that document, I think you > should > create an actual ST bus. The ST line discipline should be > just one > transport driver for that bus. Since you clearly looking > into SPI and > other transports as well. Had planned a range of TTY drivers for SPI/SlimBus 'ala usb-serial device driver for that. And hence somehow assumed TTY line discipline should be enough. SPI/SlimBus I tend to agree, their device nodes in user space is not used, and settings like bus freq, CPOL/CPHA are all set via drivers (for spi atleast). Even after doing that, what about the requirement of opening an tty device upon request from BT or FM when chip is on UART ? > > And then the bus can export Bluetooth, FM and GPS devices. > And we can > have separate drivers for these devices. Hnm, Any such example drivers to look around ? > You might wanna pick a different name than ST to not make > ST > Microelectronics unhappy and next time they call their next > thing TI ;) I had called it SHUART for some reason earlier, Yep point to be considered. Thanks, > Regards > > Marcel > > > 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/
First
|
Prev
|
Pages: 1 2 3 4 5 6 Prev: [PATCH] vt6655: CGI/CSI confusion in device_ioctl() Next: drivers:misc: sources for ST core |