From: James S. <jsi...@tr...> - 2001-12-18 19:58:17
|
Here you go Russell. This is what I have come up with so far for making the serial layer work for both theinput layer and the tty layer. The new serial design After much toying with the various ideas and Russell King's code I have formed the start of what to do. The basic idea is simple. To create a serial core where we can register a device interface to a specific port. This gives use the power to do things like have a serial console without a tty on port 1, input interface on port 2, and a tty interface on port 3. Here are the ideas I have come up with to deal with this. 1) We need to break up what we setup. The primary this we want to do are: I. Register and setup hardware ports in a device independent way. The function to do this is int uart_register_port(struct uart_port *port); II. The next step is to register the various device interfaces i.e tty, input etc. This function sets up devfs, minor numbers etc. It has nothing to do with the hardware. int uart_register_driver(struct uart_driver *uart); III. The final step is when a device is detected that we map it to a specific port. For example if the bus detects a modem then it would only make sense to map the struct uart_driver that represents the tty interface to the port that the modem wants to use. int uart_register_device(struct uart_driver *reg,struct uart_port *port); 2) The structures to represent the hardware and device interfaces. Now with the data we want to have data structs that define the hardware state and be able to change that state. We also want to make those structs visible to the higher level device interface layers. The second set of data is the device layer structs. We don't want them visible to the lower layers. Only the specific device interface would have access to it. At present we have the following data structs: I. struct uart_port. This struct represents a serial port. All the data in it defines the current hardware state. Both low level and device level use this data. II. struct uart_ops. This structure describes all the operations that can be done on the physical hardware. It is apart of struct uart_port. III. struct uart_driver. The data here presents the device interface used to represent the hardware. This struct should be interface independent. A void field would be added to this struct which could be cast in the higher device level. That data field would depend on the device interface. ------------------------------------------------------------------------------ . --- |o_o | |:_/ | Give Micro$oft the Bird!!!! // \ \ Use Linux!!!! (| | ) /'_ _/`\ ___)=(___/ |
From: Russell K. - A. L. <li...@ar...> - 2001-12-19 11:59:09
|
(Could you please ensure that your mails are wrapped at less than the 80th column please to save me the bother of doing this for you?) On Tue, Dec 18, 2001 at 11:57:43AM -0800, James Simmons wrote: > III. The final step is when a device is detected that we map it to a > specific port. For example if the bus detects a modem then it > would only make sense to map the struct uart_driver that > represents the tty interface to the port that the modem wants > to use. Are you proposing here that any ports should not be attached to any drivers until something is detected on the other end? If so, are you sure this is a good idea? To give an instance, if I were to connect two machines together using the serial ports, both of which are running this serial driver, how would they know that they had been connected, and more imporantly that they shouldn't use a keyboard driver? > 2) The structures to represent the hardware and device interfaces. Now > with the data we want to have data structs that define the hardware > state and be able to change that state. How is this different from what we already provide in the uart-based drivers? It appears that you've described the current setup in I and II rather well. > III. struct uart_driver. The data here presents the device interface > used to represent the hardware. This struct should be interface > independent. > > A void field would be added to this struct which could be cast > in the higher device level. That data field would depend on the > device interface. Hmm, untyped data pointers. Ewww. |
From: James S. <jsi...@tr...> - 2001-12-23 05:37:58
|
> (Could you please ensure that your mails are wrapped at less than the > 80th column please to save me the bother of doing this for you?) Sorry. My mailer has troubles with placing text files in the body of a email. > On Tue, Dec 18, 2001 at 11:57:43AM -0800, James Simmons wrote: > > III. The final step is when a device is detected that we map it to a > > specific port. For example if the bus detects a modem then it > > would only make sense to map the struct uart_driver that > > represents the tty interface to the port that the modem wants > > to use. > > Are you proposing here that any ports should not be attached to any drivers > until something is detected on the other end? > > If so, are you sure this is a good idea? To give an instance, if I were > to connect two machines together using the serial ports, both of which are > running this serial driver, how would they know that they had been connected, > and more imporantly that they shouldn't use a keyboard driver? Hm. That depends on the hardware and/or hardware setup. For example on the iPAQ one serial port is used just for the touchscreen. The other for IR and the first serial can be used for serial console/tty stuff or a stowaway keyboard. With the stowaway keyboard it sends a signal. So here we have smarter hardware. So fixed port are easy. The second class is using the bus like the PCI/PNP layer to find out what got attached. Then we have the total dumb serial port. In this case if we can't figure if anything is attached or if something attaches and we don't know what it is then prehaps we should default to using the tty layer. Or better yet let the user load the right modules. > > 2) The structures to represent the hardware and device interfaces. Now > > with the data we want to have data structs that define the hardware > > state and be able to change that state. > > How is this different from what we already provide in the uart-based drivers? > It appears that you've described the current setup in I and II rather well. Their is no difference. I based these ideas on what you have done. Your low level setup is perfect from what I can see. Well except for touching struct uart_info. I still need to figure a cheap way to send data from the low level to the user uart_driver level. Most likely I will add a rx_char and tx_char function to struct uart_driver. Also maybe a shutdown or connect function? > > III. struct uart_driver. The data here presents the device interface > > used to represent the hardware. This struct should be interface > > independent. > > > > A void field would be added to this struct which could be cast > > in the higher device level. That data field would depend on the > > device interface. > > Hmm, untyped data pointers. Ewww. Well the higher data structures are a bit messer to deal with. We have: struct uart_state; struct uart_info; struct uart_driver; Every type of serial device would make use of struct uart_driver. Now struct uart_state and struct uart_info are heavly related to the TTY layer. So in the case of a TTY device was would have the void data field in struct uart_driver point to most likely struct uart_info. |
From: Russell K. - A. L. <li...@ar...> - 2001-12-23 09:27:54
|
On Sat, Dec 22, 2001 at 09:37:09PM -0800, James Simmons wrote: > Hm. That depends on the hardware and/or hardware setup. For example on > the iPAQ one serial port is used just for the touchscreen. It's actually used for a microcontroller which handles the touchscreen and many other things (like power management). > The other for IR Forget that port - the sa1100_ir driver is far superiour for driving it. > and the first serial can be used for serial console/tty stuff or a > stowaway keyboard. With the stowaway keyboard it sends a signal. So here > we have smarter hardware. So fixed port are easy. > The second class is using the bus like the PCI/PNP layer to find out > what got attached. This sounds a somewhat Microsofty solution. Do we really want the kernel sending stuff like 'AT' commands at various baud rates to the connected machine, which might be waiting for you to "press any key" after changing the floppy? > Then we have the total dumb serial port. In this case if we can't > figure if anything is attached or if something attaches and we don't know > what it is then prehaps we should default to using the tty layer. Or > better yet let the user load the right modules. Your only connection to the machine is over this serial port. How do you load the modules if you're not connected to the machine? > Their is no difference. I based these ideas on what you have done. Your low > level setup is perfect from what I can see. Well except for touching > struct uart_info. I still need to figure a cheap way to send data from the > low level to the user uart_driver level. Most likely I will add a rx_char > and tx_char function to struct uart_driver. I'd rather see a generic buffering layer between the serial low level and upper levels (and do away with the tty flip buffers). I think that will separate it sufficiently. Also, I don't see an easy way to get rid of uart_info from the low level drivers - its used for many things, including maintaining correct locking on SMP. > Also maybe a shutdown or connect function? Erm, don't we have 'startup' and 'shutdown' functions already? > Well the higher data structures are a bit messer to deal with. We have: > > struct uart_state; > struct uart_info; > struct uart_driver; > > Every type of serial device would make use of struct uart_driver. Now > struct uart_state and struct uart_info are heavly related to the TTY > layer. So in the case of a TTY device was would have the void data field > in struct uart_driver point to most likely struct uart_info. Uh oh, I really don't like this. So we're going to have 'n' ports with 'n' struct uart_driver entries? This sounds like needless bloat. Please tell me you weren't seriously considering that! |
From: James S. <jsi...@tr...> - 2001-12-26 23:43:59
|
> It's actually used for a microcontroller which handles the touchscreen and > many other things (like power management). True. The driver for the "touchscreen" does alot of things. > > The second class is using the bus like the PCI/PNP layer to find out > > what got attached. > > This sounds a somewhat Microsofty solution. Do we really want the kernel > sending stuff like 'AT' commands at various baud rates to the connected > machine, which might be waiting for you to "press any key" after changing > the floppy? I never said anything about sending AT commands. For example in serial_8250_pci.c you have serial_pci_guess_board. Knowing that we have a modem means we can only use a TTY interface for that port. Unless the device is hotpluggable. A input interface wouldn't make sense if we have a modem. If it is possible to see what type of device we have we can use that to determine what interface userland can have. > > Then we have the total dumb serial port. In this case if we can't > > figure if anything is attached or if something attaches and we don't know > > what it is then prehaps we should default to using the tty layer. Or > > better yet let the user load the right modules. > > Your only connection to the machine is over this serial port. How do you > load the modules if you're not connected to the machine? Okay. For the worst case we have the device map a struct uart_driver for the TTY layer to every port. > > Their is no difference. I based these ideas on what you have done. Your low > > level setup is perfect from what I can see. Well except for touching > > struct uart_info. I still need to figure a cheap way to send data from the > > low level to the user uart_driver level. Most likely I will add a rx_char > > and tx_char function to struct uart_driver. > > I'd rather see a generic buffering layer between the serial low level and > upper levels (and do away with the tty flip buffers). I think that will > separate it sufficiently. Hm. I have no problem with that. As long as removing the flip buffers don't break the other TTY drivers. > Also, I don't see an easy way to get rid of uart_info from the low level > drivers - its used for many things, including maintaining correct locking > on SMP. > > > Also maybe a shutdown or connect function? > > Erm, don't we have 'startup' and 'shutdown' functions already? I mean add functions to struct uart_driver to detect when a device has been attached or detached depending if the hardware can support it. > > Well the higher data structures are a bit messer to deal with. We have: > > > > struct uart_state; > > struct uart_info; > > struct uart_driver; > > > > Every type of serial device would make use of struct uart_driver. Now > > struct uart_state and struct uart_info are heavly related to the TTY > > layer. So in the case of a TTY device was would have the void data field > > in struct uart_driver point to most likely struct uart_info. > > Uh oh, I really don't like this. So we're going to have 'n' ports with > 'n' struct uart_driver entries? This sounds like needless bloat. > > Please tell me you weren't seriously considering that! No. A one to one mapping between struct uart_driver and a port. |
From: Andrew E. M. <an...@is...> - 2001-12-27 07:20:51
|
James Simmons wrote: > > > > The second class is using the bus like the PCI/PNP layer to find out > > > what got attached. > > > > This sounds a somewhat Microsofty solution. Do we really want the kernel > > sending stuff like 'AT' commands at various baud rates to the connected > > machine, which might be waiting for you to "press any key" after changing > > the floppy? > > I never said anything about sending AT commands. Though I hate to point this out, there is a spec for a serial PnP protocol, It doesn't confuse modems or terminals, as it twiddles the RTS/CTS lines. Yes, Microsoft developed it. Microsoft serial mice should supoort it. -- Andrew E. Mileski Ottawa, Canada |
From: Vojtech P. <vo...@su...> - 2001-12-27 11:02:55
|
On Thu, Dec 27, 2001 at 02:20:39AM -0500, Andrew E. Mileski wrote: > > > > The second class is using the bus like the PCI/PNP layer to find out > > > > what got attached. > > > > > > This sounds a somewhat Microsofty solution. Do we really want the kernel > > > sending stuff like 'AT' commands at various baud rates to the connected > > > machine, which might be waiting for you to "press any key" after changing > > > the floppy? > > > > I never said anything about sending AT commands. > > Though I hate to point this out, there is a spec for a serial PnP protocol, > It doesn't confuse modems or terminals, as it twiddles the RTS/CTS lines. It confuses serial UPSes. Some of them switch the computer off during the PnPCom evaluation. ;) > Yes, Microsoft developed it. Microsoft serial mice should supoort it. Actually, they don't. They ignore the line twiddling and just send the PnP string at powerup (when DTR comes up for long enough to provide power to the mouse controller chip.) Most later serial modems do support the PnPCom evaluation, though. Actually almost any serial device can be identified quite well, but I don't think this should be done inside the kernel. -- Vojtech Pavlik SuSE Labs |
From: Andrew E. M. <an...@is...> - 2001-12-27 14:22:23
|
Vojtech Pavlik wrote: > > Actually almost any serial device can be identified quite well, but I > don't think this should be done inside the kernel. I agree, as serial devices tend not to be essential to booting as are most PCI ones. Hence, most ISA PnP and PCMCIA/PC CARD are detected in user space ... though a kernel "helper" driver is not out of line should one be necessary. -- Andrew E. Mileski Ottawa, Canada |
From: Russell K. - A. L. <li...@ar...> - 2001-12-27 14:27:02
|
On Thu, Dec 27, 2001 at 09:22:11AM -0500, Andrew E. Mileski wrote: > I agree, as serial devices tend not to be essential to booting as are > most PCI ones. Hence, most ISA PnP and PCMCIA/PC CARD are detected > in user space ... though a kernel "helper" driver is not out of line > should one be necessary. Actually, all serial ports are detected by in-kernel code, apart from PCMCIA, which uses cardmgr to bind the serial_cs driver with the card (but serial_cs still works out where the serial ports are). User space does get some say in the matter via setserial, but that is currently only used as an admin tool. |
From: Vojtech P. <vo...@su...> - 2001-12-27 09:38:30
|
On Wed, Dec 26, 2001 at 03:43:29PM -0800, James Simmons wrote: > > This sounds a somewhat Microsofty solution. Do we really want the kernel > > sending stuff like 'AT' commands at various baud rates to the connected > > machine, which might be waiting for you to "press any key" after changing > > the floppy? > > I never said anything about sending AT commands. For example in > serial_8250_pci.c you have serial_pci_guess_board. Knowing that we have > a modem means we can only use a TTY interface for that port. Unless the > device is hotpluggable. A input interface wouldn't make sense if we have > a modem. If it is possible to see what type of device we have we can use > that to determine what interface userland can have. And in case we can't figure out in the kernel in a simple way (like the first two serial ports on a Sun are keyboard and mouse) we simply make it a tty, let the userland talk to it, decide what it sees there and then tell the kernel back. What do you think? -- Vojtech Pavlik SuSE Labs |