Re: [RFC PATCH 0/3] UART slave device bus
On 22 August 2016 at 23:23, H. Nikolaus Schallerwrote: > Hi Sebastian, > >> Am 22.08.2016 um 22:39 schrieb Sebastian Reichel : >> >> Hi, >> >> On Sun, Aug 21, 2016 at 09:50:57AM +0200, H. Nikolaus Schaller wrote: Am 20.08.2016 um 15:34 schrieb One Thousand Gnomes : > What it is not about are UART/RS232 converters connected through USB or > virtual > serial ports created for WWAN modems (e.g. /dev/ttyACM, /dev/ttyHSO). Or > BT devices > connected through USB (even if they also run HCI protocol). It actually has to be about both because you will find the exact same device wired via USB SSIC/HSIC to a USB UART or via a classic UART. Not is it just about embedded boards. >>> >>> Not necessarily. >>> >>> We often have two interface options for exactly the sam sensor chips. They >>> can be connected >>> either through SPI or I2C. Which means that there is a core driver for the >>> chip and two different >>> transport glue components (see e.g. iio/accel/bmc150). >>> >>> This does not require I2C to be able to handle SPI or vice versa or provide >>> a common API. >> >> I don't understand this comparison. I2C and SPI are different >> protocols, > > Yes, they are different on protocol level, but on both you transfer blocks of > data from/to a slave device > which usually can be addressed. And for some chips they are just two slightly > alternative serial interfaces. > >> while native UART and USB-connected UART are both UART. > > I see what you mean, but kernel divides between directly connected UART and > USB-connected UART. > > drivers/usb/serial/ vs. drivers/tty/serial/ > > to implement two different groups of UARTs. Although on user space level they > are harmonized again. > This is why I compare with i2c and spi. But each such comparison is not > perfect. > > Anyways, to me it looks as if everybody wants to make the solution work for > usb-uarts as well > (although I still would like to see a real world use-case). I use a NFC reader attached to a PL2303 UART. It's a proof of concept solution but if I needed a finished product all it takes is to put the two pieces of PCB into a box with the USB connector sticking out. Or glue the PCB on the inside of a plastic part of a PC case. Thanks Michal
Re: [RFC PATCH 0/3] UART slave device bus
On 22 August 2016 at 23:23, H. Nikolaus Schaller wrote: > Hi Sebastian, > >> Am 22.08.2016 um 22:39 schrieb Sebastian Reichel : >> >> Hi, >> >> On Sun, Aug 21, 2016 at 09:50:57AM +0200, H. Nikolaus Schaller wrote: Am 20.08.2016 um 15:34 schrieb One Thousand Gnomes : > What it is not about are UART/RS232 converters connected through USB or > virtual > serial ports created for WWAN modems (e.g. /dev/ttyACM, /dev/ttyHSO). Or > BT devices > connected through USB (even if they also run HCI protocol). It actually has to be about both because you will find the exact same device wired via USB SSIC/HSIC to a USB UART or via a classic UART. Not is it just about embedded boards. >>> >>> Not necessarily. >>> >>> We often have two interface options for exactly the sam sensor chips. They >>> can be connected >>> either through SPI or I2C. Which means that there is a core driver for the >>> chip and two different >>> transport glue components (see e.g. iio/accel/bmc150). >>> >>> This does not require I2C to be able to handle SPI or vice versa or provide >>> a common API. >> >> I don't understand this comparison. I2C and SPI are different >> protocols, > > Yes, they are different on protocol level, but on both you transfer blocks of > data from/to a slave device > which usually can be addressed. And for some chips they are just two slightly > alternative serial interfaces. > >> while native UART and USB-connected UART are both UART. > > I see what you mean, but kernel divides between directly connected UART and > USB-connected UART. > > drivers/usb/serial/ vs. drivers/tty/serial/ > > to implement two different groups of UARTs. Although on user space level they > are harmonized again. > This is why I compare with i2c and spi. But each such comparison is not > perfect. > > Anyways, to me it looks as if everybody wants to make the solution work for > usb-uarts as well > (although I still would like to see a real world use-case). I use a NFC reader attached to a PL2303 UART. It's a proof of concept solution but if I needed a finished product all it takes is to put the two pieces of PCB into a box with the USB connector sticking out. Or glue the PCB on the inside of a plastic part of a PC case. Thanks Michal
Re: [RFC PATCH 0/3] UART slave device bus
> Either we'd have to call tty_port->rx a character at a time or > implement some temporary buffer. I don't think we want to call things > like BT receive code a byte at a time. This needs to be a layer > higher. flush_to_ldisc either needs to be duplicated to handle > tty_port->rx or generalized to call either tty_port->rx or ldisc > receive_buf. I'm not sure what to do about ldisc ref counting in the > latter case. You already have the buffer What I was trying to suggest was that instead of chars->buffer flush workqueue loop pushing data into the ldisc You can also do chars->buffer flush workqueue ->rx() [where flush_to_ldisc is just one implementation of ->rx] For byte by byte ports it really makes no difference (except you would be able to do processing without an ldisc), but for DMA devices it would give us a faster path for processing since the DMA completion event can simply fire a buffer a characters directly at the protocol handler where there are not latency concerns (ie it starts the new DMA and directly involves ->rx()) Alan
Re: [RFC PATCH 0/3] UART slave device bus
> Either we'd have to call tty_port->rx a character at a time or > implement some temporary buffer. I don't think we want to call things > like BT receive code a byte at a time. This needs to be a layer > higher. flush_to_ldisc either needs to be duplicated to handle > tty_port->rx or generalized to call either tty_port->rx or ldisc > receive_buf. I'm not sure what to do about ldisc ref counting in the > latter case. You already have the buffer What I was trying to suggest was that instead of chars->buffer flush workqueue loop pushing data into the ldisc You can also do chars->buffer flush workqueue ->rx() [where flush_to_ldisc is just one implementation of ->rx] For byte by byte ports it really makes no difference (except you would be able to do processing without an ldisc), but for DMA devices it would give us a faster path for processing since the DMA completion event can simply fire a buffer a characters directly at the protocol handler where there are not latency concerns (ie it starts the new DMA and directly involves ->rx()) Alan
Re: [RFC PATCH 0/3] UART slave device bus
On Thu, Aug 18, 2016 at 10:04 AM, One Thousand Gnomeswrote: >> No, the code should be fast as it is so simple. I assume there is some >> reason the tty buffering is more complex than just a circular buffer. > > I would suggest you read n_tty.c carefully and then it'll make a fair bit > of sense. It has to interlock multiple reader/writes with discipline > changes and flushes of pending data. At the same time a received > character may cause output changes including bytes to be queued for > transmit and the entire lot must not excessively recurse. > > It's fun and it took years to make work safely but basically you need to > handle a simultaneous ldisc change, config change, read of data from the > buffers, receive, transmit and the receive causing the transmit status to > change and maybe other transmits, that might have to be sent with > priority. It's fun 8) > > The good news is that nobody but n_tty and maybe n_irda cares on the rx > side. Every other ldisc consumes the bytes immediately. IRDA hasn't worked > for years anyway. > >> My best guess is because the tty layer has to buffer things for >> userspace and userspace can be slow to read? Do line disciplines make >> assumptions about the tty buffering? Is 4KB enough buffering? > > RTFS but to save you a bit of effort > > 1. 4K is not enough, 64K is not always sufficient, this is why we have > all the functionality you appear to want to re-invent already in the tty > buffer logic of the tty_port > 2. Only n_tty actually uses the tty_port layer buffering > 3. The ring buffer used for dumb uarts is entirely about latency limits > on low end processors and only used by some uarts anyway. > >> Also, the current receive implementation has no concept of blocking or >> timeout. Should the uart_dev_rx() function return when there's no more >> data or wait (with timeout) until all requested data is received? >> (Probably do all of them is my guess). > > Your rx routine needs to be able to run in IRQ context, not block and > complete in very very short time scales because on some hardware you have > exactly 9 bit times to recover the data byte and clear the IRQ done. > Serial really stretches some of the low end embedded processors running > at 56K/115200, and RS485 at 4Mbits even with 8 bytes of buffering is > pretty tight. Thus you need very fast buffers for just about any use case. > Dumb uarts you'll need to keep the existing ring buffer or similar > (moving to a kfifo would slightly improve performance I think) and queue > after. > >> >> - Convert a real driver/line discipline over to UART bus. >> > >> > That's going to be the real test, I recommend trying that as soon as >> > possible as it will show where the real pain points are :) > > The locking. It's taken ten years to debug the current line discipline > change locking. If you want to be able to switch stuff kernel side > however it's somewhat easier. > > The change should be > > Add tty_port->rx(uint8_t *data,uint8_t *flags, unsigned int len) > > The semantics of tty_port->rx are > > - You may not assume a tty is bound to this port > - You may be called in IRQ context, but are guaranteed not to get > parallel calls for the same port > - When you return the bytes you passed are history > > At that point you can set tty_port->rx to point to the > tty_flip_buffer_push() and everyone can use it. Slow ones will want to > queue to a ring buffer then do tty_port->rx (where we do the flush_buffer > now), fast ones will do the ->rx directly. Other than doing DMA, I did not find any examples of UARTs doing internal rx ring buffers. Most/all the non-DMA cases do tty_insert_flip_char directly in the ISR. The flow is insert a series of flags and characters as we process the receive status and then trigger a flush of the buffer at the end. That doesn't match up with what you are proposing for how tty_port->rx would work. That would change the receive ISR processing in all the drivers quite a bit. Either we'd have to call tty_port->rx a character at a time or implement some temporary buffer. I don't think we want to call things like BT receive code a byte at a time. This needs to be a layer higher. flush_to_ldisc either needs to be duplicated to handle tty_port->rx or generalized to call either tty_port->rx or ldisc receive_buf. I'm not sure what to do about ldisc ref counting in the latter case. Rob
Re: [RFC PATCH 0/3] UART slave device bus
On Thu, Aug 18, 2016 at 10:04 AM, One Thousand Gnomes wrote: >> No, the code should be fast as it is so simple. I assume there is some >> reason the tty buffering is more complex than just a circular buffer. > > I would suggest you read n_tty.c carefully and then it'll make a fair bit > of sense. It has to interlock multiple reader/writes with discipline > changes and flushes of pending data. At the same time a received > character may cause output changes including bytes to be queued for > transmit and the entire lot must not excessively recurse. > > It's fun and it took years to make work safely but basically you need to > handle a simultaneous ldisc change, config change, read of data from the > buffers, receive, transmit and the receive causing the transmit status to > change and maybe other transmits, that might have to be sent with > priority. It's fun 8) > > The good news is that nobody but n_tty and maybe n_irda cares on the rx > side. Every other ldisc consumes the bytes immediately. IRDA hasn't worked > for years anyway. > >> My best guess is because the tty layer has to buffer things for >> userspace and userspace can be slow to read? Do line disciplines make >> assumptions about the tty buffering? Is 4KB enough buffering? > > RTFS but to save you a bit of effort > > 1. 4K is not enough, 64K is not always sufficient, this is why we have > all the functionality you appear to want to re-invent already in the tty > buffer logic of the tty_port > 2. Only n_tty actually uses the tty_port layer buffering > 3. The ring buffer used for dumb uarts is entirely about latency limits > on low end processors and only used by some uarts anyway. > >> Also, the current receive implementation has no concept of blocking or >> timeout. Should the uart_dev_rx() function return when there's no more >> data or wait (with timeout) until all requested data is received? >> (Probably do all of them is my guess). > > Your rx routine needs to be able to run in IRQ context, not block and > complete in very very short time scales because on some hardware you have > exactly 9 bit times to recover the data byte and clear the IRQ done. > Serial really stretches some of the low end embedded processors running > at 56K/115200, and RS485 at 4Mbits even with 8 bytes of buffering is > pretty tight. Thus you need very fast buffers for just about any use case. > Dumb uarts you'll need to keep the existing ring buffer or similar > (moving to a kfifo would slightly improve performance I think) and queue > after. > >> >> - Convert a real driver/line discipline over to UART bus. >> > >> > That's going to be the real test, I recommend trying that as soon as >> > possible as it will show where the real pain points are :) > > The locking. It's taken ten years to debug the current line discipline > change locking. If you want to be able to switch stuff kernel side > however it's somewhat easier. > > The change should be > > Add tty_port->rx(uint8_t *data,uint8_t *flags, unsigned int len) > > The semantics of tty_port->rx are > > - You may not assume a tty is bound to this port > - You may be called in IRQ context, but are guaranteed not to get > parallel calls for the same port > - When you return the bytes you passed are history > > At that point you can set tty_port->rx to point to the > tty_flip_buffer_push() and everyone can use it. Slow ones will want to > queue to a ring buffer then do tty_port->rx (where we do the flush_buffer > now), fast ones will do the ->rx directly. Other than doing DMA, I did not find any examples of UARTs doing internal rx ring buffers. Most/all the non-DMA cases do tty_insert_flip_char directly in the ISR. The flow is insert a series of flags and characters as we process the receive status and then trigger a flush of the buffer at the end. That doesn't match up with what you are proposing for how tty_port->rx would work. That would change the receive ISR processing in all the drivers quite a bit. Either we'd have to call tty_port->rx a character at a time or implement some temporary buffer. I don't think we want to call things like BT receive code a byte at a time. This needs to be a layer higher. flush_to_ldisc either needs to be duplicated to handle tty_port->rx or generalized to call either tty_port->rx or ldisc receive_buf. I'm not sure what to do about ldisc ref counting in the latter case. Rob
Re: [RFC PATCH 0/3] UART slave device bus
Hi Alan, >> So you mean if I do "hciconfig hci0 down", then the uart-bus should >> "down" the tty and only on "hciconfig hci0 up" it should "up" the >> tty? I would expect a uart-bus slave-device takes control of the >> device ("up" it) on probe. It's hardwired anyway. > > Today you can switch stacks at runtime, you can switch between the kernel > stack and debug tools at runtime. Breaking that is a regression. actually that is not true. We have HCI User Channel since a long time that gives you raw access to the devices. And also kernel interfaces to do all vendor / debug tasks. Regards Marcel
Re: [RFC PATCH 0/3] UART slave device bus
Hi Alan, >> So you mean if I do "hciconfig hci0 down", then the uart-bus should >> "down" the tty and only on "hciconfig hci0 up" it should "up" the >> tty? I would expect a uart-bus slave-device takes control of the >> device ("up" it) on probe. It's hardwired anyway. > > Today you can switch stacks at runtime, you can switch between the kernel > stack and debug tools at runtime. Breaking that is a regression. actually that is not true. We have HCI User Channel since a long time that gives you raw access to the devices. And also kernel interfaces to do all vendor / debug tasks. Regards Marcel
Re: [RFC PATCH 0/3] UART slave device bus
> So you mean if I do "hciconfig hci0 down", then the uart-bus should > "down" the tty and only on "hciconfig hci0 up" it should "up" the > tty? I would expect a uart-bus slave-device takes control of the > device ("up" it) on probe. It's hardwired anyway. Today you can switch stacks at runtime, you can switch between the kernel stack and debug tools at runtime. Breaking that is a regression. > Also what should happen if old userspace use hciattach while > uart-bus slave-device doesn't have control over it? Do you You would either use the old hciattach in which case you wouldn't be able to manage it via a new API while attached, or the new API in which case you wouldn't be able to manage it via the old interface while it was being used directly. > Or do you suggest to register hci1 and one cannot use hci0? I guess > this breaks even more devices, as the device number changes. Device numbers are dynamic anyway. Plug a USB adapter in and if it beats your onboard adapter to registration then the order changes. > So yes, from your point of view there is a regression, just because > it's working automatically. So let's just not convert existing boards > with working hciattach based bluetooth devices. New devices can use >From a distribution point of view that would be a nightmare. > the uart-bus, as it's not a regression for them and Nokia N series > can also do it, since they have no working bluetooth at all at the > moment. The Nokia N series is a weird corner case. > > In many cases you'll also still need the tty interface to do > > things like firmware upgrades. > > I would expect the uart-slave driver to know how to do firmware > updates. Actually most bluetooth chips are initialized by uploading > a firmware to them. Usually no - you don't want a ton of kernel code for flashing adapters when they have built in firmware (similar issue for 3G modems) > And there are definitely uart drivers not caring about having a tty > device. Nokia's vendor driver for their bluetooth protocol contains > a custom omap-serial driver combined with the actual bluetooth > driver. There is nothing related to the tty framework. I think the > same would work for the other hardwired bluetooth chips perfectly > fine. That means having two different omap serial drivers to maintain which is not ideal. To me there are four different things 1. bluetooth devices "just work". That can be user space (eg it seems to just work on my Fedora boxes and bluetooth enumeration is being done via user space, or may be via kernel enumeration, or a mix. PPP is an existing example of this - serial port PPP is an ldisc but ports that are not UART like speak directly to the PPP layer as network adapters. 2. Sideband controls and power management, where we need to give the tty_port a child device and power it up/down properly and have the tty_port hooks to do so based upon the ldisc protocol state machine when talking stuff like NMEA or HCI. 3. The special case UART power saving features/hacks like GPIO snooping, again with the right hooks 4. Whether it's useful to be able to create a tty device in kernel and attach that to stuff with no userspace involved. All are independent. Alan
Re: [RFC PATCH 0/3] UART slave device bus
> So you mean if I do "hciconfig hci0 down", then the uart-bus should > "down" the tty and only on "hciconfig hci0 up" it should "up" the > tty? I would expect a uart-bus slave-device takes control of the > device ("up" it) on probe. It's hardwired anyway. Today you can switch stacks at runtime, you can switch between the kernel stack and debug tools at runtime. Breaking that is a regression. > Also what should happen if old userspace use hciattach while > uart-bus slave-device doesn't have control over it? Do you You would either use the old hciattach in which case you wouldn't be able to manage it via a new API while attached, or the new API in which case you wouldn't be able to manage it via the old interface while it was being used directly. > Or do you suggest to register hci1 and one cannot use hci0? I guess > this breaks even more devices, as the device number changes. Device numbers are dynamic anyway. Plug a USB adapter in and if it beats your onboard adapter to registration then the order changes. > So yes, from your point of view there is a regression, just because > it's working automatically. So let's just not convert existing boards > with working hciattach based bluetooth devices. New devices can use >From a distribution point of view that would be a nightmare. > the uart-bus, as it's not a regression for them and Nokia N series > can also do it, since they have no working bluetooth at all at the > moment. The Nokia N series is a weird corner case. > > In many cases you'll also still need the tty interface to do > > things like firmware upgrades. > > I would expect the uart-slave driver to know how to do firmware > updates. Actually most bluetooth chips are initialized by uploading > a firmware to them. Usually no - you don't want a ton of kernel code for flashing adapters when they have built in firmware (similar issue for 3G modems) > And there are definitely uart drivers not caring about having a tty > device. Nokia's vendor driver for their bluetooth protocol contains > a custom omap-serial driver combined with the actual bluetooth > driver. There is nothing related to the tty framework. I think the > same would work for the other hardwired bluetooth chips perfectly > fine. That means having two different omap serial drivers to maintain which is not ideal. To me there are four different things 1. bluetooth devices "just work". That can be user space (eg it seems to just work on my Fedora boxes and bluetooth enumeration is being done via user space, or may be via kernel enumeration, or a mix. PPP is an existing example of this - serial port PPP is an ldisc but ports that are not UART like speak directly to the PPP layer as network adapters. 2. Sideband controls and power management, where we need to give the tty_port a child device and power it up/down properly and have the tty_port hooks to do so based upon the ldisc protocol state machine when talking stuff like NMEA or HCI. 3. The special case UART power saving features/hacks like GPIO snooping, again with the right hooks 4. Whether it's useful to be able to create a tty device in kernel and attach that to stuff with no userspace involved. All are independent. Alan
Re: [RFC PATCH 0/3] UART slave device bus
On Mon, Aug 22, 2016 at 5:45 PM, One Thousand Gnomeswrote: > and if I look at the usermode crapfest on a lot of Android systems it > looks similar but with the notion of things like being able to describe > > - Use GPIO mode sleeping and assume first char is X to save power It's really nasty hardware design, or a software hack to solve a hardware problem: what should have been done is of course create a UART with an asynchronous low-power mode that can recieve a character and wake up the system at any time, handing over the wakeup character(s) to the driver. That is obviously the usecase they were designing for. But yeah, I guess we have to contain hacks like that. > - Power up, wait n ms, write, read, wait n ms, power down (which > has to be driven at the ldisc/user level as only the ldisc > understands transactions, or via ioctls (right now Android user > space tends to do hardcoded writes to /sys.. gpio to drive power This kind of abominational abuse of the GPIO sysfs ABI is partly why I've obsoleted it. The right abstraction is the fixed regulator with a GPIO line obviously, then some sequencing along the lines of what you can find in drivers/mmc/core/pwrseq* Unfortunately that sysfs ABI crept in during a window of time when GPIO was unmaintained and I am trying my best to contain and improve the situation. Yours, Linus Walleij
Re: [RFC PATCH 0/3] UART slave device bus
On Mon, Aug 22, 2016 at 5:45 PM, One Thousand Gnomes wrote: > and if I look at the usermode crapfest on a lot of Android systems it > looks similar but with the notion of things like being able to describe > > - Use GPIO mode sleeping and assume first char is X to save power It's really nasty hardware design, or a software hack to solve a hardware problem: what should have been done is of course create a UART with an asynchronous low-power mode that can recieve a character and wake up the system at any time, handing over the wakeup character(s) to the driver. That is obviously the usecase they were designing for. But yeah, I guess we have to contain hacks like that. > - Power up, wait n ms, write, read, wait n ms, power down (which > has to be driven at the ldisc/user level as only the ldisc > understands transactions, or via ioctls (right now Android user > space tends to do hardcoded writes to /sys.. gpio to drive power This kind of abominational abuse of the GPIO sysfs ABI is partly why I've obsoleted it. The right abstraction is the fixed regulator with a GPIO line obviously, then some sequencing along the lines of what you can find in drivers/mmc/core/pwrseq* Unfortunately that sysfs ABI crept in during a window of time when GPIO was unmaintained and I am trying my best to contain and improve the situation. Yours, Linus Walleij
Re: [RFC PATCH 0/3] UART slave device bus
+Dmitry to get his opinion on using serio. On Mon, Aug 22, 2016 at 10:24 AM, Arnd Bergmannwrote: > On Monday, August 22, 2016 8:38:23 AM CEST Rob Herring wrote: >> On Mon, Aug 22, 2016 at 7:37 AM, Arnd Bergmann wrote: >> > On Wednesday, August 17, 2016 8:14:42 PM CEST Rob Herring wrote: >> >> >> >> Before I spend more time on this, I'm looking mainly for feedback on the >> >> general direction and structure (the interface with the existing serial >> >> drivers in particular). >> > >> > Aside from the things that have already been mentioned in the discussion, >> > I wonder how this should relate to the drivers/input/serio framework. >> >> As I mentioned, I did investigate that route. > > Ok, sorry for missing that. > >> > My impression is that there is some overlap in what you want >> > to do here, and what serio does today as a line discipline on top >> > of a tty line discipline (and on top of other non-uart serial >> > connections), so we should look into whether the two can be unified >> > or not. Here is what I found so far: >> > >> > For all I can tell, serio is only used for drivers/input/ but could >> > easily be extended to other subsystems. It currently uses its own >> > binary ID matching between drivers and devices through user space >> > interfaces, though adding a DT binding for it would appear to be >> > a good idea regardless. >> > >> > It also has a bus_type already, and with some operations defined on >> > it. In particular, it has an "interrupt" method that is used to >> > notify the client driver when a byte is available (and pass >> > that byte along with it). This seems to be a useful addition to >> > what you have. Since it is based on sending single characters >> > both ways, transferring large amounts of data would be slower, >> > but the interface is somewhat simpler. In principle, both >> > character based and buffer based interfaces could coexist here >> > as they do in some other interfaces (e.g. smbus). >> >> Given that about the only things it really provided are the bus_type >> and associated boilerplate without much of a client interface, it >> seemed to me that creating a new subsystem first made more sense. Then >> we can convert serio to use the new subsystem. > > One possible downside of merging later is that we end up having to > support the existing user space ABI for serio that may not fit well > within whatever we come up with independently. > > I think there are two other valuable features provided by serio: > > - an existing set of drivers written to the API > - the implementation of the tty_ldisc I've looked at serio a bit more and was able to add in DT matching to it. It's a bit hacky to make it work with the ldisc as it gets the DT node from serio->dev.parent->parent (the parent is the tty and grandparent is the uart dev) and still requires inputattach to open the tty and set the ldisc. Otherwise, the mode for inputattach doesn't matter. So I plan to continue down this path. One thing I'm left wondering is serio essentially implements it's own async probing with connect()/disconnect(). Seems like it was because PS/2 port probing and resuming are slow. Is this still necessary or could be converted to use driver core async probing? That would make serio drivers look a bit more "normal". Rob
Re: [RFC PATCH 0/3] UART slave device bus
+Dmitry to get his opinion on using serio. On Mon, Aug 22, 2016 at 10:24 AM, Arnd Bergmann wrote: > On Monday, August 22, 2016 8:38:23 AM CEST Rob Herring wrote: >> On Mon, Aug 22, 2016 at 7:37 AM, Arnd Bergmann wrote: >> > On Wednesday, August 17, 2016 8:14:42 PM CEST Rob Herring wrote: >> >> >> >> Before I spend more time on this, I'm looking mainly for feedback on the >> >> general direction and structure (the interface with the existing serial >> >> drivers in particular). >> > >> > Aside from the things that have already been mentioned in the discussion, >> > I wonder how this should relate to the drivers/input/serio framework. >> >> As I mentioned, I did investigate that route. > > Ok, sorry for missing that. > >> > My impression is that there is some overlap in what you want >> > to do here, and what serio does today as a line discipline on top >> > of a tty line discipline (and on top of other non-uart serial >> > connections), so we should look into whether the two can be unified >> > or not. Here is what I found so far: >> > >> > For all I can tell, serio is only used for drivers/input/ but could >> > easily be extended to other subsystems. It currently uses its own >> > binary ID matching between drivers and devices through user space >> > interfaces, though adding a DT binding for it would appear to be >> > a good idea regardless. >> > >> > It also has a bus_type already, and with some operations defined on >> > it. In particular, it has an "interrupt" method that is used to >> > notify the client driver when a byte is available (and pass >> > that byte along with it). This seems to be a useful addition to >> > what you have. Since it is based on sending single characters >> > both ways, transferring large amounts of data would be slower, >> > but the interface is somewhat simpler. In principle, both >> > character based and buffer based interfaces could coexist here >> > as they do in some other interfaces (e.g. smbus). >> >> Given that about the only things it really provided are the bus_type >> and associated boilerplate without much of a client interface, it >> seemed to me that creating a new subsystem first made more sense. Then >> we can convert serio to use the new subsystem. > > One possible downside of merging later is that we end up having to > support the existing user space ABI for serio that may not fit well > within whatever we come up with independently. > > I think there are two other valuable features provided by serio: > > - an existing set of drivers written to the API > - the implementation of the tty_ldisc I've looked at serio a bit more and was able to add in DT matching to it. It's a bit hacky to make it work with the ldisc as it gets the DT node from serio->dev.parent->parent (the parent is the tty and grandparent is the uart dev) and still requires inputattach to open the tty and set the ldisc. Otherwise, the mode for inputattach doesn't matter. So I plan to continue down this path. One thing I'm left wondering is serio essentially implements it's own async probing with connect()/disconnect(). Seems like it was because PS/2 port probing and resuming are slow. Is this still necessary or could be converted to use driver core async probing? That would make serio drivers look a bit more "normal". Rob
Re: [RFC PATCH 0/3] UART slave device bus
Hi Alan, >>> That would still be a regression. Not everyone even uses the kernel >>> bluetooth stack. It would only return EBUSY if you had done an "up" >>> on it via the direct bluetooth stack. >> >> So it returns EBUSY when uart-bus is used. Since uart-bus is about >> hardwired devices that's basically always. > > That would only be when the bluetooth port in question was active via the > hardwired interface - which is not always. You choose to turn on/off > bluetooth interfaces. If you boot with an older user space you'd use > hciattach instead. > > In many cases you'll also still need the tty interface to do things like > firmware upgrades. actually for Bluetooth you don't. We dealt with all of this crazy vendor stuff and provided proper hooks in the Bluetooth subsystem to support. hciattach / btattach are just the hotplug trigger to attach the hardware. It is like plugging in an USB dongle into your USB port. That is how you have to see this. Killing the hciattach / btattach process is the unplug event. It is that simple. And if you can skip the hciattach / btattach step and use kernel serial bus with proper enumeration and driver binding, then the end result is that you get a hci0 Bluetooth interface. The same way as you would have gotten when calling hciattach / btattach. Meaning you then call hciconfig hci0 up (or let bluetoothd do it for you) and you have Bluetooth working. It worked this way since 2.4.6 kernel. The real power on is done via hciconfig hci0 up and not hciattach. The only difference is that since a long time now, kernel drivers can provide extra vendor hooks. And the kernel can internally and temporally power on the hardware if it has to do certain tasks. For example configuring the BD_ADDR, loading some patches or doing some audio configuration. Regards Marcel
Re: [RFC PATCH 0/3] UART slave device bus
Hi Alan, >>> That would still be a regression. Not everyone even uses the kernel >>> bluetooth stack. It would only return EBUSY if you had done an "up" >>> on it via the direct bluetooth stack. >> >> So it returns EBUSY when uart-bus is used. Since uart-bus is about >> hardwired devices that's basically always. > > That would only be when the bluetooth port in question was active via the > hardwired interface - which is not always. You choose to turn on/off > bluetooth interfaces. If you boot with an older user space you'd use > hciattach instead. > > In many cases you'll also still need the tty interface to do things like > firmware upgrades. actually for Bluetooth you don't. We dealt with all of this crazy vendor stuff and provided proper hooks in the Bluetooth subsystem to support. hciattach / btattach are just the hotplug trigger to attach the hardware. It is like plugging in an USB dongle into your USB port. That is how you have to see this. Killing the hciattach / btattach process is the unplug event. It is that simple. And if you can skip the hciattach / btattach step and use kernel serial bus with proper enumeration and driver binding, then the end result is that you get a hci0 Bluetooth interface. The same way as you would have gotten when calling hciattach / btattach. Meaning you then call hciconfig hci0 up (or let bluetoothd do it for you) and you have Bluetooth working. It worked this way since 2.4.6 kernel. The real power on is done via hciconfig hci0 up and not hciattach. The only difference is that since a long time now, kernel drivers can provide extra vendor hooks. And the kernel can internally and temporally power on the hardware if it has to do certain tasks. For example configuring the BD_ADDR, loading some patches or doing some audio configuration. Regards Marcel
Re: [RFC PATCH 0/3] UART slave device bus
Hi, > Am 23.08.2016 um 00:42 schrieb Sebastian Reichel: > >> I am not a specialist for such things, but I think you have three >> options to connect bluetooth: >> >> a) SoC-UART <-> BT-Chip-UART-port >> b) USB-UART (FT232, PL2303 etc.) <-> BT-Chip-UART-port >> c) USB <-> BT-Chip-USB-port (not UART involved at all) >> >> Case c) IMHO means you anyways need a special USB driver for the BT-Chip >> connected >> through USB and plugging it into a non-embedded USB port does not >> automatically >> show it as a tty interface. So you can't use it for testing the UART drivers. >> >> BTW: the Wi2Wi W2CBW003 chip comes in two firmware variants: one for UART and >> one for USB. So they are also not exchangeable. > > Yes, let's ignore option c). > I'm talking about UART only. If the > chip has native USB support, then that's a different driver. Exactly. > >> Variant b) is IMHO of no practical relevance (but I may be wrong) >> because it would mean to add some costly FT232 or PL2302 chip >> where a different firmware variant works with direct USB >> connection. > > Well for some chips there is not native USB support. But my scenario > was about development. Let's say I have a serial-chip and I want to > develop a driver for it. It would be nice if I can develop the > driver with a USB-UART Yes it would be nice, but is this a thing with significant practical relevance? Usually you have to write drivers for a complete device where the slave chip is already wired up to a SoC-UART. Sometimes you can get a bare chip where you can connect to an USB-UART. But someone has to design that piece of special hardware for you. If you are really lucky there is an evaluation board. And in that case I would use a RasPi or BeagleBone and tie up directly to some SoC-UART instead of using an intermediate USB-UART adapter. Because it is more close to timing relations to the final SoC based design. > and then use it on my embedded system. > > There are usb-serial devices, which could benefit from support > btw. I would find it really useful, if the Dangerous Prototype's > Bus Pirate would expose native /dev/i2c and /dev/spi and it's > based on FT232. Oh, that is an interesting device I didn't know yet. > >> So to me it looks as if you need to develop different low-level >> drivers anyways. > > No. You say, that option b) is irrelevant and assume, that every > serial chip also has native USB support. I just assume that b) is rarely used because there are alternatives. Although it would be a nice option. Anyways, while following the discussion this is not the most important facet of the overall topic. BR, Nikolaus signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [RFC PATCH 0/3] UART slave device bus
Hi, > Am 23.08.2016 um 00:42 schrieb Sebastian Reichel : > >> I am not a specialist for such things, but I think you have three >> options to connect bluetooth: >> >> a) SoC-UART <-> BT-Chip-UART-port >> b) USB-UART (FT232, PL2303 etc.) <-> BT-Chip-UART-port >> c) USB <-> BT-Chip-USB-port (not UART involved at all) >> >> Case c) IMHO means you anyways need a special USB driver for the BT-Chip >> connected >> through USB and plugging it into a non-embedded USB port does not >> automatically >> show it as a tty interface. So you can't use it for testing the UART drivers. >> >> BTW: the Wi2Wi W2CBW003 chip comes in two firmware variants: one for UART and >> one for USB. So they are also not exchangeable. > > Yes, let's ignore option c). > I'm talking about UART only. If the > chip has native USB support, then that's a different driver. Exactly. > >> Variant b) is IMHO of no practical relevance (but I may be wrong) >> because it would mean to add some costly FT232 or PL2302 chip >> where a different firmware variant works with direct USB >> connection. > > Well for some chips there is not native USB support. But my scenario > was about development. Let's say I have a serial-chip and I want to > develop a driver for it. It would be nice if I can develop the > driver with a USB-UART Yes it would be nice, but is this a thing with significant practical relevance? Usually you have to write drivers for a complete device where the slave chip is already wired up to a SoC-UART. Sometimes you can get a bare chip where you can connect to an USB-UART. But someone has to design that piece of special hardware for you. If you are really lucky there is an evaluation board. And in that case I would use a RasPi or BeagleBone and tie up directly to some SoC-UART instead of using an intermediate USB-UART adapter. Because it is more close to timing relations to the final SoC based design. > and then use it on my embedded system. > > There are usb-serial devices, which could benefit from support > btw. I would find it really useful, if the Dangerous Prototype's > Bus Pirate would expose native /dev/i2c and /dev/spi and it's > based on FT232. Oh, that is an interesting device I didn't know yet. > >> So to me it looks as if you need to develop different low-level >> drivers anyways. > > No. You say, that option b) is irrelevant and assume, that every > serial chip also has native USB support. I just assume that b) is rarely used because there are alternatives. Although it would be a nice option. Anyways, while following the discussion this is not the most important facet of the overall topic. BR, Nikolaus signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [RFC PATCH 0/3] UART slave device bus
Hi, On Tue, Aug 23, 2016 at 01:15:21AM +0100, One Thousand Gnomes wrote: > > > That would still be a regression. Not everyone even uses the kernel > > > bluetooth stack. It would only return EBUSY if you had done an "up" > > > on it via the direct bluetooth stack. > > > > So it returns EBUSY when uart-bus is used. Since uart-bus is about > > hardwired devices that's basically always. > > That would only be when the bluetooth port in question was active via the > hardwired interface - which is not always. You choose to turn on/off > bluetooth interfaces. If you boot with an older user space you'd use > hciattach instead. So you mean if I do "hciconfig hci0 down", then the uart-bus should "down" the tty and only on "hciconfig hci0 up" it should "up" the tty? I would expect a uart-bus slave-device takes control of the device ("up" it) on probe. It's hardwired anyway. Also what should happen if old userspace use hciattach while uart-bus slave-device doesn't have control over it? Do you suggest to implement some dummy code, that detects uart-bus already registered a hci device and returns success without doing anything? Then "hciconfig hci0 up" will fail, since the tty is already taken by hciattach. Or do you suggest to register hci1 and one cannot use hci0? I guess this breaks even more devices, as the device number changes. Also note, that there is a chance, that hci0 will go up by some script before hciattach has been called in your legacy userspace. Then it will also fail. So yes, from your point of view there is a regression, just because it's working automatically. So let's just not convert existing boards with working hciattach based bluetooth devices. New devices can use the uart-bus, as it's not a regression for them and Nokia N series can also do it, since they have no working bluetooth at all at the moment. > In many cases you'll also still need the tty interface to do > things like firmware upgrades. I would expect the uart-slave driver to know how to do firmware updates. Actually most bluetooth chips are initialized by uploading a firmware to them. And there are definitely uart drivers not caring about having a tty device. Nokia's vendor driver for their bluetooth protocol contains a custom omap-serial driver combined with the actual bluetooth driver. There is nothing related to the tty framework. I think the same would work for the other hardwired bluetooth chips perfectly fine. Note: I'm not in favour of merging uart and bluetooth drivers. This is really bad design. But it shows, that /dev/tty interface is not needed by in-kernel drivers. Of course tty is needed by userland drivers, but I expect, that those do not use the uart-bus. They already require all kind of hardware knowledge and don't work out-of-the-box anyway, so they do not gain from this framework. -- Sebastian signature.asc Description: PGP signature
Re: [RFC PATCH 0/3] UART slave device bus
Hi, On Tue, Aug 23, 2016 at 01:15:21AM +0100, One Thousand Gnomes wrote: > > > That would still be a regression. Not everyone even uses the kernel > > > bluetooth stack. It would only return EBUSY if you had done an "up" > > > on it via the direct bluetooth stack. > > > > So it returns EBUSY when uart-bus is used. Since uart-bus is about > > hardwired devices that's basically always. > > That would only be when the bluetooth port in question was active via the > hardwired interface - which is not always. You choose to turn on/off > bluetooth interfaces. If you boot with an older user space you'd use > hciattach instead. So you mean if I do "hciconfig hci0 down", then the uart-bus should "down" the tty and only on "hciconfig hci0 up" it should "up" the tty? I would expect a uart-bus slave-device takes control of the device ("up" it) on probe. It's hardwired anyway. Also what should happen if old userspace use hciattach while uart-bus slave-device doesn't have control over it? Do you suggest to implement some dummy code, that detects uart-bus already registered a hci device and returns success without doing anything? Then "hciconfig hci0 up" will fail, since the tty is already taken by hciattach. Or do you suggest to register hci1 and one cannot use hci0? I guess this breaks even more devices, as the device number changes. Also note, that there is a chance, that hci0 will go up by some script before hciattach has been called in your legacy userspace. Then it will also fail. So yes, from your point of view there is a regression, just because it's working automatically. So let's just not convert existing boards with working hciattach based bluetooth devices. New devices can use the uart-bus, as it's not a regression for them and Nokia N series can also do it, since they have no working bluetooth at all at the moment. > In many cases you'll also still need the tty interface to do > things like firmware upgrades. I would expect the uart-slave driver to know how to do firmware updates. Actually most bluetooth chips are initialized by uploading a firmware to them. And there are definitely uart drivers not caring about having a tty device. Nokia's vendor driver for their bluetooth protocol contains a custom omap-serial driver combined with the actual bluetooth driver. There is nothing related to the tty framework. I think the same would work for the other hardwired bluetooth chips perfectly fine. Note: I'm not in favour of merging uart and bluetooth drivers. This is really bad design. But it shows, that /dev/tty interface is not needed by in-kernel drivers. Of course tty is needed by userland drivers, but I expect, that those do not use the uart-bus. They already require all kind of hardware knowledge and don't work out-of-the-box anyway, so they do not gain from this framework. -- Sebastian signature.asc Description: PGP signature
Re: [RFC PATCH 0/3] UART slave device bus
> > That would still be a regression. Not everyone even uses the kernel > > bluetooth stack. It would only return EBUSY if you had done an "up" > > on it via the direct bluetooth stack. > > So it returns EBUSY when uart-bus is used. Since uart-bus is about > hardwired devices that's basically always. That would only be when the bluetooth port in question was active via the hardwired interface - which is not always. You choose to turn on/off bluetooth interfaces. If you boot with an older user space you'd use hciattach instead. In many cases you'll also still need the tty interface to do things like firmware upgrades. Alan
Re: [RFC PATCH 0/3] UART slave device bus
> > That would still be a regression. Not everyone even uses the kernel > > bluetooth stack. It would only return EBUSY if you had done an "up" > > on it via the direct bluetooth stack. > > So it returns EBUSY when uart-bus is used. Since uart-bus is about > hardwired devices that's basically always. That would only be when the bluetooth port in question was active via the hardwired interface - which is not always. You choose to turn on/off bluetooth interfaces. If you boot with an older user space you'd use hciattach instead. In many cases you'll also still need the tty interface to do things like firmware upgrades. Alan
Re: [RFC PATCH 0/3] UART slave device bus
Hi, On Mon, Aug 22, 2016 at 11:54:14PM +0100, One Thousand Gnomes wrote: > On Tue, 23 Aug 2016 00:00:17 +0200 > Pavel Machekwrote: > > > On Mon 2016-08-22 22:32:23, One Thousand Gnomes wrote: > > > > why would we even have it create a /dev/ttyX for these devices in the > > > > first place. Lets just not create an uevent for it and lets not create > > > > a dev_t for it. > > > > > > Because if you don't it's a regression. It's not permissible to break > > > existing userspace. > > > > Well... it would be good to do the right thing, at least in the places > > where we can. > > > > Yes, renumbering people's serials is bad, OTOH for new platforms it > > would be nice not to expose ttyS15 which can only return -EBUSY. > > That would still be a regression. Not everyone even uses the kernel > bluetooth stack. It would only return EBUSY if you had done an "up" > on it via the direct bluetooth stack. So it returns EBUSY when uart-bus is used. Since uart-bus is about hardwired devices that's basically always. Also I wonder how relevant your "I want to handle all UART stuff out of kernel" scenario is for uart-bus, which is about in-kernel UART drivers. -- Sebastian signature.asc Description: PGP signature
Re: [RFC PATCH 0/3] UART slave device bus
Hi, On Mon, Aug 22, 2016 at 11:54:14PM +0100, One Thousand Gnomes wrote: > On Tue, 23 Aug 2016 00:00:17 +0200 > Pavel Machek wrote: > > > On Mon 2016-08-22 22:32:23, One Thousand Gnomes wrote: > > > > why would we even have it create a /dev/ttyX for these devices in the > > > > first place. Lets just not create an uevent for it and lets not create > > > > a dev_t for it. > > > > > > Because if you don't it's a regression. It's not permissible to break > > > existing userspace. > > > > Well... it would be good to do the right thing, at least in the places > > where we can. > > > > Yes, renumbering people's serials is bad, OTOH for new platforms it > > would be nice not to expose ttyS15 which can only return -EBUSY. > > That would still be a regression. Not everyone even uses the kernel > bluetooth stack. It would only return EBUSY if you had done an "up" > on it via the direct bluetooth stack. So it returns EBUSY when uart-bus is used. Since uart-bus is about hardwired devices that's basically always. Also I wonder how relevant your "I want to handle all UART stuff out of kernel" scenario is for uart-bus, which is about in-kernel UART drivers. -- Sebastian signature.asc Description: PGP signature
Re: [RFC PATCH 0/3] UART slave device bus
Hi, On Mon, Aug 22, 2016 at 11:46:10PM +0100, One Thousand Gnomes wrote: > > It's not enough to automatically set a ldisc. There is also need for > > additional resouces. For example the Nokia bluetooth driver needs > > some extra GPIOs. The same is true for the in-tree hci_bcm, which > > misuses the platform_device exactly like Greg doesn't want it. > > This is one of those cases where ACPI gets it right. For the device tree > case you will also need to describe the GPIO lines as part of your power > management for that slave device. > > > I think the problem with line disciplines is, that they do > > not follow the Linux device model. UART slaves may have extra > > They follow it exactly. > > You have a tty_port which wraps a device, and has the lifetime of the > hardware and lives on busses and can support enumeration. > > You have a tty which is a file system object with a lifetime determined > by the use of the file handle, it's like any other file->private_data but > quite complex because we must comply with POSIX and historic Unix tty > behaviour. > > You have an ldisc, which is simply a modularisation of the current > protocol handler and is carefully engineered not to include any device > specific knowledge. That's how you make it scale and actually work sanely. I think the current support is far from sane for hardwired serial-based bluetooth devices. I open the serial device, set the line disector, set the vendor and maybe some other extra information and then do nothing, since the kernel handles everything for me. All of the information given to the kernel could be done automatically using the firmware information. Why should I care how my bluetooth device is connected? > > resources like gpios or regulators. > > Any resources belong to the tty_port or a child of the tty_port because > only it has the correct lifetime. And yes it's perfectly reasonable for > us to attach other resources to a tty_port or give it a child that is the > device the other end of the fixed link. Everything the DT describes > belongs hanging off the tty_port or a child thereof. Right we need a _child_, since we describe the other end of the fixed link. Adding random remote end resources to the tty_port looks like a huge hack. > We don't get this problem in ACPI space in general because as far as ACPI > is concerned the tty has a child device and the child device describes > its own power management so you just power the child on or off through > ACPI and ACPI describes power sanely. > > Eveything you have that is device specific belongs in the tty_port driver > for that hardware, or maybe shared library helpers if common. > > Everything you have which involves invoking device defined policy > according to protocol defined behaviour belongs in the ldisc. ACPI is not better in this regard. Have a look at drivers/bluetooth/hci_bcm.c and you will see a platform device providing the GPIOs, which is then accessed by the line discipline. > Unix has worked like this for well over 30 years and it works very > well as a model. TBH I don't think it does. Why should I need to tell the kernel something, that it could know automatically. Let's think about hci_bcm. The firmware tells the kernel, that some bluetooth device is connected to the uart port. The kernel ignores that information until the user also tells it, that the bluetooth chip is connected to some tty. If the kernel had done the right job, the user wouldn't even know, that bluetooth is connected via UART. -- Sebastian signature.asc Description: PGP signature
Re: [RFC PATCH 0/3] UART slave device bus
Hi, On Mon, Aug 22, 2016 at 11:46:10PM +0100, One Thousand Gnomes wrote: > > It's not enough to automatically set a ldisc. There is also need for > > additional resouces. For example the Nokia bluetooth driver needs > > some extra GPIOs. The same is true for the in-tree hci_bcm, which > > misuses the platform_device exactly like Greg doesn't want it. > > This is one of those cases where ACPI gets it right. For the device tree > case you will also need to describe the GPIO lines as part of your power > management for that slave device. > > > I think the problem with line disciplines is, that they do > > not follow the Linux device model. UART slaves may have extra > > They follow it exactly. > > You have a tty_port which wraps a device, and has the lifetime of the > hardware and lives on busses and can support enumeration. > > You have a tty which is a file system object with a lifetime determined > by the use of the file handle, it's like any other file->private_data but > quite complex because we must comply with POSIX and historic Unix tty > behaviour. > > You have an ldisc, which is simply a modularisation of the current > protocol handler and is carefully engineered not to include any device > specific knowledge. That's how you make it scale and actually work sanely. I think the current support is far from sane for hardwired serial-based bluetooth devices. I open the serial device, set the line disector, set the vendor and maybe some other extra information and then do nothing, since the kernel handles everything for me. All of the information given to the kernel could be done automatically using the firmware information. Why should I care how my bluetooth device is connected? > > resources like gpios or regulators. > > Any resources belong to the tty_port or a child of the tty_port because > only it has the correct lifetime. And yes it's perfectly reasonable for > us to attach other resources to a tty_port or give it a child that is the > device the other end of the fixed link. Everything the DT describes > belongs hanging off the tty_port or a child thereof. Right we need a _child_, since we describe the other end of the fixed link. Adding random remote end resources to the tty_port looks like a huge hack. > We don't get this problem in ACPI space in general because as far as ACPI > is concerned the tty has a child device and the child device describes > its own power management so you just power the child on or off through > ACPI and ACPI describes power sanely. > > Eveything you have that is device specific belongs in the tty_port driver > for that hardware, or maybe shared library helpers if common. > > Everything you have which involves invoking device defined policy > according to protocol defined behaviour belongs in the ldisc. ACPI is not better in this regard. Have a look at drivers/bluetooth/hci_bcm.c and you will see a platform device providing the GPIOs, which is then accessed by the line discipline. > Unix has worked like this for well over 30 years and it works very > well as a model. TBH I don't think it does. Why should I need to tell the kernel something, that it could know automatically. Let's think about hci_bcm. The firmware tells the kernel, that some bluetooth device is connected to the uart port. The kernel ignores that information until the user also tells it, that the bluetooth chip is connected to some tty. If the kernel had done the right job, the user wouldn't even know, that bluetooth is connected via UART. -- Sebastian signature.asc Description: PGP signature
Re: [RFC PATCH 0/3] UART slave device bus
Hi, On Mon, Aug 22, 2016 at 11:52:56PM +0100, One Thousand Gnomes wrote: > > There are usb-serial devices, which could benefit from support > > btw. I would find it really useful, if the Dangerous Prototype's > > Bus Pirate would expose native /dev/i2c and /dev/spi and it's > > based on FT232. > > That should just need an ldisc. Right, since it does not need any extra resources. Probably not the best example. > I2C and SPI should at this point be sane for hotplugging as needed > for an ldisc. I guess hotplugging support in the downstream kernel frameworks would be needed anyway with usb-serial being USB based. > And having an ldisc also has another nice effect. You can plug the bus > pirate into a remote machine, run an 8bit clean link over a pty/tty pair > half way around the world and get a local i2c/spi to the remote machine's > i2c/spi bus pirate ports and devices. Right. > It also means that if Bus Pirate 5 changes USB uart nothing breaks. And it means no auto-support. Which would be fine in case of Bus Pirate, since its mainly a developer device and some people may actually prefer the IMHO anoying serial interface. Let's forget that example. -- Sebastian signature.asc Description: PGP signature
Re: [RFC PATCH 0/3] UART slave device bus
Hi, On Mon, Aug 22, 2016 at 11:52:56PM +0100, One Thousand Gnomes wrote: > > There are usb-serial devices, which could benefit from support > > btw. I would find it really useful, if the Dangerous Prototype's > > Bus Pirate would expose native /dev/i2c and /dev/spi and it's > > based on FT232. > > That should just need an ldisc. Right, since it does not need any extra resources. Probably not the best example. > I2C and SPI should at this point be sane for hotplugging as needed > for an ldisc. I guess hotplugging support in the downstream kernel frameworks would be needed anyway with usb-serial being USB based. > And having an ldisc also has another nice effect. You can plug the bus > pirate into a remote machine, run an 8bit clean link over a pty/tty pair > half way around the world and get a local i2c/spi to the remote machine's > i2c/spi bus pirate ports and devices. Right. > It also means that if Bus Pirate 5 changes USB uart nothing breaks. And it means no auto-support. Which would be fine in case of Bus Pirate, since its mainly a developer device and some people may actually prefer the IMHO anoying serial interface. Let's forget that example. -- Sebastian signature.asc Description: PGP signature
Re: [RFC PATCH 0/3] UART slave device bus
> It's not enough to automatically set a ldisc. There is also need for > additional resouces. For example the Nokia bluetooth driver needs > some extra GPIOs. The same is true for the in-tree hci_bcm, which > misuses the platform_device exactly like Greg doesn't want it. This is one of those cases where ACPI gets it right. For the device tree case you will also need to describe the GPIO lines as part of your power management for that slave device. > I think the problem with line disciplines is, that they do > not follow the Linux device model. UART slaves may have extra They follow it exactly. You have a tty_port which wraps a device, and has the lifetime of the hardware and lives on busses and can support enumeration. You have a tty which is a file system object with a lifetime determined by the use of the file handle, it's like any other file->private_data but quite complex because we must comply with POSIX and historic Unix tty behaviour. You have an ldisc, which is simply a modularisation of the current protocol handler and is carefully engineered not to include any device specific knowledge. That's how you make it scale and actually work sanely. > resources like gpios or regulators. Any resources belong to the tty_port or a child of the tty_port because only it has the correct lifetime. And yes it's perfectly reasonable for us to attach other resources to a tty_port or give it a child that is the device the other end of the fixed link. Everything the DT describes belongs hanging off the tty_port or a child thereof. We don't get this problem in ACPI space in general because as far as ACPI is concerned the tty has a child device and the child device describes its own power management so you just power the child on or off through ACPI and ACPI describes power sanely. Eveything you have that is device specific belongs in the tty_port driver for that hardware, or maybe shared library helpers if common. Everything you have which involves invoking device defined policy according to protocol defined behaviour belongs in the ldisc. Unix has worked like this for well over 30 years and it works very well as a model. Alan
Re: [RFC PATCH 0/3] UART slave device bus
> It's not enough to automatically set a ldisc. There is also need for > additional resouces. For example the Nokia bluetooth driver needs > some extra GPIOs. The same is true for the in-tree hci_bcm, which > misuses the platform_device exactly like Greg doesn't want it. This is one of those cases where ACPI gets it right. For the device tree case you will also need to describe the GPIO lines as part of your power management for that slave device. > I think the problem with line disciplines is, that they do > not follow the Linux device model. UART slaves may have extra They follow it exactly. You have a tty_port which wraps a device, and has the lifetime of the hardware and lives on busses and can support enumeration. You have a tty which is a file system object with a lifetime determined by the use of the file handle, it's like any other file->private_data but quite complex because we must comply with POSIX and historic Unix tty behaviour. You have an ldisc, which is simply a modularisation of the current protocol handler and is carefully engineered not to include any device specific knowledge. That's how you make it scale and actually work sanely. > resources like gpios or regulators. Any resources belong to the tty_port or a child of the tty_port because only it has the correct lifetime. And yes it's perfectly reasonable for us to attach other resources to a tty_port or give it a child that is the device the other end of the fixed link. Everything the DT describes belongs hanging off the tty_port or a child thereof. We don't get this problem in ACPI space in general because as far as ACPI is concerned the tty has a child device and the child device describes its own power management so you just power the child on or off through ACPI and ACPI describes power sanely. Eveything you have that is device specific belongs in the tty_port driver for that hardware, or maybe shared library helpers if common. Everything you have which involves invoking device defined policy according to protocol defined behaviour belongs in the ldisc. Unix has worked like this for well over 30 years and it works very well as a model. Alan
Re: [RFC PATCH 0/3] UART slave device bus
Hi, On Tue, Aug 23, 2016 at 12:00:17AM +0200, Pavel Machek wrote: > On Mon 2016-08-22 22:32:23, One Thousand Gnomes wrote: > > > why would we even have it create a /dev/ttyX for these devices > > > in the first place. Lets just not create an uevent for it and > > > lets not create a dev_t for it. > > > > Because if you don't it's a regression. It's not permissible to break > > existing userspace. I guess there are three classes 1.) support for uart-slaves on new devices -> tty can be safely disabled, as it was never exposed 2.) support for uart-slaves on devices, which exported a useless tty (-> port could not be used from userspace without kernel modifications) [this is what N900 falls under] 3.) support for uart-slaves on devices, which could use hciattach or similar tools previously. I think these devices can't switch to the new API without a regression anyways. If the kernel already registered the bluetooth stuff hciattach will fail due to the -EBUSY (or whatever is returned). So from my point of view there is no real regression when we avoid exporting the tty at all. > Yes, renumbering people's serials is bad, OTOH for new platforms it > would be nice not to expose ttyS15 which can only return -EBUSY. No need to renumber, there is the serial mapping in DT. We can just export ttyS0, ttyS2 and ttyS3 (and skip ttyS1, which is used for hardwired serial device). > And we may want to do incompatible change at some point. People should > not have to use hciattach on n900 from now Don't worry, since platform_driver approach has been NAK'd by Greg, the N900 bluetooth driver can only proceed once this patchset has gone into the kernel. So N900 will never use hciattach. > on until end of time, just because we exposed USB port as ttyO1 in > past. USB port as ttyO1? > ...actually. I guess we should disable that ttyO1 in the device tree > for now, so nobody can start using it. As we currently have 2-3 people > in world who got that bluetooth to work with out-of-tree patches, > breakage should be quite acceptable :-). If you just disable ttyO1 in the N900's DT, you break runtime PM, since the kernel does not access disabled devices. We could add some kernel quirk, but who should use ttyO1 (which is btw named ttyS1 with 8251 based omap driver)? It's basically unusable from userspace. -- Sebastian signature.asc Description: PGP signature
Re: [RFC PATCH 0/3] UART slave device bus
Hi, On Tue, Aug 23, 2016 at 12:00:17AM +0200, Pavel Machek wrote: > On Mon 2016-08-22 22:32:23, One Thousand Gnomes wrote: > > > why would we even have it create a /dev/ttyX for these devices > > > in the first place. Lets just not create an uevent for it and > > > lets not create a dev_t for it. > > > > Because if you don't it's a regression. It's not permissible to break > > existing userspace. I guess there are three classes 1.) support for uart-slaves on new devices -> tty can be safely disabled, as it was never exposed 2.) support for uart-slaves on devices, which exported a useless tty (-> port could not be used from userspace without kernel modifications) [this is what N900 falls under] 3.) support for uart-slaves on devices, which could use hciattach or similar tools previously. I think these devices can't switch to the new API without a regression anyways. If the kernel already registered the bluetooth stuff hciattach will fail due to the -EBUSY (or whatever is returned). So from my point of view there is no real regression when we avoid exporting the tty at all. > Yes, renumbering people's serials is bad, OTOH for new platforms it > would be nice not to expose ttyS15 which can only return -EBUSY. No need to renumber, there is the serial mapping in DT. We can just export ttyS0, ttyS2 and ttyS3 (and skip ttyS1, which is used for hardwired serial device). > And we may want to do incompatible change at some point. People should > not have to use hciattach on n900 from now Don't worry, since platform_driver approach has been NAK'd by Greg, the N900 bluetooth driver can only proceed once this patchset has gone into the kernel. So N900 will never use hciattach. > on until end of time, just because we exposed USB port as ttyO1 in > past. USB port as ttyO1? > ...actually. I guess we should disable that ttyO1 in the device tree > for now, so nobody can start using it. As we currently have 2-3 people > in world who got that bluetooth to work with out-of-tree patches, > breakage should be quite acceptable :-). If you just disable ttyO1 in the N900's DT, you break runtime PM, since the kernel does not access disabled devices. We could add some kernel quirk, but who should use ttyO1 (which is btw named ttyS1 with 8251 based omap driver)? It's basically unusable from userspace. -- Sebastian signature.asc Description: PGP signature
Re: [RFC PATCH 0/3] UART slave device bus
> There are usb-serial devices, which could benefit from support > btw. I would find it really useful, if the Dangerous Prototype's > Bus Pirate would expose native /dev/i2c and /dev/spi and it's > based on FT232. That should just need an ldisc. I2C and SPI should at this point be sane for hotplugging as needed for an ldisc. And having an ldisc also has another nice effect. You can plug the bus pirate into a remote machine, run an 8bit clean link over a pty/tty pair half way around the world and get a local i2c/spi to the remote machine's i2c/spi bus pirate ports and devices. It also means that if Bus Pirate 5 changes USB uart nothing breaks. Alan
Re: [RFC PATCH 0/3] UART slave device bus
> There are usb-serial devices, which could benefit from support > btw. I would find it really useful, if the Dangerous Prototype's > Bus Pirate would expose native /dev/i2c and /dev/spi and it's > based on FT232. That should just need an ldisc. I2C and SPI should at this point be sane for hotplugging as needed for an ldisc. And having an ldisc also has another nice effect. You can plug the bus pirate into a remote machine, run an 8bit clean link over a pty/tty pair half way around the world and get a local i2c/spi to the remote machine's i2c/spi bus pirate ports and devices. It also means that if Bus Pirate 5 changes USB uart nothing breaks. Alan
Re: [RFC PATCH 0/3] UART slave device bus
On Tue, 23 Aug 2016 00:00:17 +0200 Pavel Machekwrote: > On Mon 2016-08-22 22:32:23, One Thousand Gnomes wrote: > > > why would we even have it create a /dev/ttyX for these devices in the > > > first place. Lets just not create an uevent for it and lets not create a > > > dev_t for it. > > > > Because if you don't it's a regression. It's not permissible to break > > existing userspace. > > Well... it would be good to do the right thing, at least in the places > where we can. > > Yes, renumbering people's serials is bad, OTOH for new platforms it > would be nice not to expose ttyS15 which can only return -EBUSY. That would still be a regression. Not everyone even uses the kernel bluetooth stack. It would only return EBUSY if you had done an "up" on it via the direct bluetooth stack. Alan
Re: [RFC PATCH 0/3] UART slave device bus
On Tue, 23 Aug 2016 00:00:17 +0200 Pavel Machek wrote: > On Mon 2016-08-22 22:32:23, One Thousand Gnomes wrote: > > > why would we even have it create a /dev/ttyX for these devices in the > > > first place. Lets just not create an uevent for it and lets not create a > > > dev_t for it. > > > > Because if you don't it's a regression. It's not permissible to break > > existing userspace. > > Well... it would be good to do the right thing, at least in the places > where we can. > > Yes, renumbering people's serials is bad, OTOH for new platforms it > would be nice not to expose ttyS15 which can only return -EBUSY. That would still be a regression. Not everyone even uses the kernel bluetooth stack. It would only return EBUSY if you had done an "up" on it via the direct bluetooth stack. Alan
Re: [RFC PATCH 0/3] UART slave device bus
Hi, On Mon, Aug 22, 2016 at 11:23:26PM +0200, H. Nikolaus Schaller wrote: > > Am 22.08.2016 um 22:39 schrieb Sebastian Reichel: > > > > Hi, > > > > On Sun, Aug 21, 2016 at 09:50:57AM +0200, H. Nikolaus Schaller wrote: > >>> Am 20.08.2016 um 15:34 schrieb One Thousand Gnomes > >>> : > What it is not about are UART/RS232 converters connected through USB or > virtual > serial ports created for WWAN modems (e.g. /dev/ttyACM, /dev/ttyHSO). Or > BT devices > connected through USB (even if they also run HCI protocol). > >>> > >>> It actually has to be about both because you will find the exact same > >>> device wired via USB SSIC/HSIC to a USB UART or via a classic UART. Not is > >>> it just about embedded boards. > >> > >> Not necessarily. > >> > >> We often have two interface options for exactly the sam sensor chips. They > >> can be connected > >> either through SPI or I2C. Which means that there is a core driver for the > >> chip and two different > >> transport glue components (see e.g. iio/accel/bmc150). > >> > >> This does not require I2C to be able to handle SPI or vice versa or > >> provide a common API. > > > > I don't understand this comparison. I2C and SPI are different > > protocols, > > Yes, they are different on protocol level, but on both you transfer blocks of > data from/to a slave device > which usually can be addressed. And for some chips they are just two slightly > alternative serial interfaces. > > > while native UART and USB-connected UART are both UART. > > I see what you mean, but kernel divides between directly connected UART and > USB-connected UART. > > drivers/usb/serial/ vs. drivers/tty/serial/ > > to implement two different groups of UARTs. Although on user space level they > are harmonized again. > This is why I compare with i2c and spi. But each such comparison is not > perfect. > > Anyways, to me it looks as if everybody wants to make the solution work for > usb-uarts as well > (although I still would like to see a real world use-case). > > > > >> And most Bluetooth devices I know have either UART or a direct > >> USB interface. So in the USB case there is no need to connect > >> it through some USB-UART bridge and treat it as an UART at all. > > > > I think having support for USB-UART dongles is useful for > > driver development and testing on non-embedded HW. > > Hm. I assume you mean the Bluetooth situation where both, embedded UART > connected chips and USB dongles are available. No. I mean I have some serial device, which is connected to the embedded UART, but I also have a standalone version. For driver development I can just use my standalone serial device, connect it to an USB-UART and develop the driver on non embedded HW. Then I can use the same driver on my embedded platform and it works, since it uses the same API. For e.g. I2C this works perfectly fine. I already did this with the I2C interface exposed on my notebook's VGA port. > I am not a specialist for such things, but I think you have three > options to connect bluetooth: > > a) SoC-UART <-> BT-Chip-UART-port > b) USB-UART (FT232, PL2303 etc.) <-> BT-Chip-UART-port > c) USB <-> BT-Chip-USB-port (not UART involved at all) > > Case c) IMHO means you anyways need a special USB driver for the BT-Chip > connected > through USB and plugging it into a non-embedded USB port does not > automatically > show it as a tty interface. So you can't use it for testing the UART drivers. > > BTW: the Wi2Wi W2CBW003 chip comes in two firmware variants: one for UART and > one for USB. So they are also not exchangeable. Yes, let's ignore option c). I'm talking about UART only. If the chip has native USB support, then that's a different driver. Note, that for more complex drivers it may become possible to use the same high-level driver via regmap at some point. Not sure if this kind of HW exists, though. > Variant b) is IMHO of no practical relevance (but I may be wrong) > because it would mean to add some costly FT232 or PL2302 chip > where a different firmware variant works with direct USB > connection. Well for some chips there is not native USB support. But my scenario was about development. Let's say I have a serial-chip and I want to develop a driver for it. It would be nice if I can develop the driver with a USB-UART and then use it on my embedded system. There are usb-serial devices, which could benefit from support btw. I would find it really useful, if the Dangerous Prototype's Bus Pirate would expose native /dev/i2c and /dev/spi and it's based on FT232. > So to me it looks as if you need to develop different low-level > drivers anyways. No. You say, that option b) is irrelevant and assume, that every serial chip also has native USB support. -- Sebastian signature.asc Description: PGP signature
Re: [RFC PATCH 0/3] UART slave device bus
Hi, On Mon, Aug 22, 2016 at 11:23:26PM +0200, H. Nikolaus Schaller wrote: > > Am 22.08.2016 um 22:39 schrieb Sebastian Reichel : > > > > Hi, > > > > On Sun, Aug 21, 2016 at 09:50:57AM +0200, H. Nikolaus Schaller wrote: > >>> Am 20.08.2016 um 15:34 schrieb One Thousand Gnomes > >>> : > What it is not about are UART/RS232 converters connected through USB or > virtual > serial ports created for WWAN modems (e.g. /dev/ttyACM, /dev/ttyHSO). Or > BT devices > connected through USB (even if they also run HCI protocol). > >>> > >>> It actually has to be about both because you will find the exact same > >>> device wired via USB SSIC/HSIC to a USB UART or via a classic UART. Not is > >>> it just about embedded boards. > >> > >> Not necessarily. > >> > >> We often have two interface options for exactly the sam sensor chips. They > >> can be connected > >> either through SPI or I2C. Which means that there is a core driver for the > >> chip and two different > >> transport glue components (see e.g. iio/accel/bmc150). > >> > >> This does not require I2C to be able to handle SPI or vice versa or > >> provide a common API. > > > > I don't understand this comparison. I2C and SPI are different > > protocols, > > Yes, they are different on protocol level, but on both you transfer blocks of > data from/to a slave device > which usually can be addressed. And for some chips they are just two slightly > alternative serial interfaces. > > > while native UART and USB-connected UART are both UART. > > I see what you mean, but kernel divides between directly connected UART and > USB-connected UART. > > drivers/usb/serial/ vs. drivers/tty/serial/ > > to implement two different groups of UARTs. Although on user space level they > are harmonized again. > This is why I compare with i2c and spi. But each such comparison is not > perfect. > > Anyways, to me it looks as if everybody wants to make the solution work for > usb-uarts as well > (although I still would like to see a real world use-case). > > > > >> And most Bluetooth devices I know have either UART or a direct > >> USB interface. So in the USB case there is no need to connect > >> it through some USB-UART bridge and treat it as an UART at all. > > > > I think having support for USB-UART dongles is useful for > > driver development and testing on non-embedded HW. > > Hm. I assume you mean the Bluetooth situation where both, embedded UART > connected chips and USB dongles are available. No. I mean I have some serial device, which is connected to the embedded UART, but I also have a standalone version. For driver development I can just use my standalone serial device, connect it to an USB-UART and develop the driver on non embedded HW. Then I can use the same driver on my embedded platform and it works, since it uses the same API. For e.g. I2C this works perfectly fine. I already did this with the I2C interface exposed on my notebook's VGA port. > I am not a specialist for such things, but I think you have three > options to connect bluetooth: > > a) SoC-UART <-> BT-Chip-UART-port > b) USB-UART (FT232, PL2303 etc.) <-> BT-Chip-UART-port > c) USB <-> BT-Chip-USB-port (not UART involved at all) > > Case c) IMHO means you anyways need a special USB driver for the BT-Chip > connected > through USB and plugging it into a non-embedded USB port does not > automatically > show it as a tty interface. So you can't use it for testing the UART drivers. > > BTW: the Wi2Wi W2CBW003 chip comes in two firmware variants: one for UART and > one for USB. So they are also not exchangeable. Yes, let's ignore option c). I'm talking about UART only. If the chip has native USB support, then that's a different driver. Note, that for more complex drivers it may become possible to use the same high-level driver via regmap at some point. Not sure if this kind of HW exists, though. > Variant b) is IMHO of no practical relevance (but I may be wrong) > because it would mean to add some costly FT232 or PL2302 chip > where a different firmware variant works with direct USB > connection. Well for some chips there is not native USB support. But my scenario was about development. Let's say I have a serial-chip and I want to develop a driver for it. It would be nice if I can develop the driver with a USB-UART and then use it on my embedded system. There are usb-serial devices, which could benefit from support btw. I would find it really useful, if the Dangerous Prototype's Bus Pirate would expose native /dev/i2c and /dev/spi and it's based on FT232. > So to me it looks as if you need to develop different low-level > drivers anyways. No. You say, that option b) is irrelevant and assume, that every serial chip also has native USB support. -- Sebastian signature.asc Description: PGP signature
Re: [RFC PATCH 0/3] UART slave device bus
Hi, On Mon, Aug 22, 2016 at 05:00:40PM -0500, Rob Herring wrote: > On Mon, Aug 22, 2016 at 3:00 PM, Sebastian Reichelwrote: > > Hi, > > > > On Mon, Aug 22, 2016 at 12:30:27PM -0500, Rob Herring wrote: > >> On Mon, Aug 22, 2016 at 12:02 PM, One Thousand Gnomes > >> wrote: > >> >> > I think there are two other valuable features provided by serio: > >> >> > > >> >> > - an existing set of drivers written to the API > >> >> > - the implementation of the tty_ldisc > >> >> > >> >> True, though I'd expect little of the data flow part of it to be reused. > >> > > >> > Then your design is broken. > >> > >> I'm talking about serio, not my design which I already said the > >> receive side at least needs work. > >> > >> The serio API for rx and tx is a single character at a time. I thought > >> we agreed that's not sufficient for things like BT. > >> > >> >> - a child of the uart node > >> >> - a reg property containing the line number if the parent has multiple > >> >> uarts (I'd expect this to rarely be used). > >> > > >> > That surprises me as for current x86 platforms it would be the norm, > >> > except that we use ACPI. > >> > >> Exactly, we're talking DT bindings here. Each port will be a separate > >> node otherwise things like serial aliases and stdout-path won't work > >> correctly. Compatible strings for 8250 uarts are for a single port. > >> But if you had h/w such that it has common and per port registers then > >> it may be a single node. I'm not aware of any example offhand (maybe > >> PPC CPM). But it doesn't matter as reg can handle this case just fine > >> if we need to. > > > > I would expect, that your imaginary example h/w also has one node > > per port using a mfd style h/w description: > > > > multi-uart-device { > > uart1 { > > child { }; > > }; > > uart2 { > > child { }; > > }; > > }; > > Yes, that is certainly possible too. That way aliases and stdout-path also works. I think I would just make one-node-per-uart-port mandatory and skip the reg part. Let's assume your imaginary example h/w would be and i2c master with two ports and some shared registers. Then it immidiatly becomes clear, that one wants to somehow expose two ports in the DT instead of using some port selection property (and reg would already be taken). > >> >> - baudrate and other line configuration (though I would expect the > >> >> slave driver to know all this and set it w/o DT. Also, we already have > >> >> a way to set baudrate in the parent node at least.) > > > > I'm not sure if every slave driver knows this. Maybe some generic > > slave drivers will come up, once we have the infrastructure. So > > it could be useful to have the settings as optional properties. > > OTOH it can also be done once it is needed. > > Yes, you could have devices that do autobaud detect and don't care > other than some max baudrate which could be limited by either the host > or device. Then you have others that are fixed or start at a fixed > baud and then switch. > > As for generic slaves, no doubt they will come up and I will be > nak'ing the generic slave bindings. The "generic slave" is already > supported via tty devices in userspace IMO. Ok I didn't meant that generic. I meant something like "I have a remote controller with specific protocol, baudrate is board specific". Anyways it can be discussed once needed -- Sebastian signature.asc Description: PGP signature
Re: [RFC PATCH 0/3] UART slave device bus
Hi, On Mon, Aug 22, 2016 at 05:00:40PM -0500, Rob Herring wrote: > On Mon, Aug 22, 2016 at 3:00 PM, Sebastian Reichel wrote: > > Hi, > > > > On Mon, Aug 22, 2016 at 12:30:27PM -0500, Rob Herring wrote: > >> On Mon, Aug 22, 2016 at 12:02 PM, One Thousand Gnomes > >> wrote: > >> >> > I think there are two other valuable features provided by serio: > >> >> > > >> >> > - an existing set of drivers written to the API > >> >> > - the implementation of the tty_ldisc > >> >> > >> >> True, though I'd expect little of the data flow part of it to be reused. > >> > > >> > Then your design is broken. > >> > >> I'm talking about serio, not my design which I already said the > >> receive side at least needs work. > >> > >> The serio API for rx and tx is a single character at a time. I thought > >> we agreed that's not sufficient for things like BT. > >> > >> >> - a child of the uart node > >> >> - a reg property containing the line number if the parent has multiple > >> >> uarts (I'd expect this to rarely be used). > >> > > >> > That surprises me as for current x86 platforms it would be the norm, > >> > except that we use ACPI. > >> > >> Exactly, we're talking DT bindings here. Each port will be a separate > >> node otherwise things like serial aliases and stdout-path won't work > >> correctly. Compatible strings for 8250 uarts are for a single port. > >> But if you had h/w such that it has common and per port registers then > >> it may be a single node. I'm not aware of any example offhand (maybe > >> PPC CPM). But it doesn't matter as reg can handle this case just fine > >> if we need to. > > > > I would expect, that your imaginary example h/w also has one node > > per port using a mfd style h/w description: > > > > multi-uart-device { > > uart1 { > > child { }; > > }; > > uart2 { > > child { }; > > }; > > }; > > Yes, that is certainly possible too. That way aliases and stdout-path also works. I think I would just make one-node-per-uart-port mandatory and skip the reg part. Let's assume your imaginary example h/w would be and i2c master with two ports and some shared registers. Then it immidiatly becomes clear, that one wants to somehow expose two ports in the DT instead of using some port selection property (and reg would already be taken). > >> >> - baudrate and other line configuration (though I would expect the > >> >> slave driver to know all this and set it w/o DT. Also, we already have > >> >> a way to set baudrate in the parent node at least.) > > > > I'm not sure if every slave driver knows this. Maybe some generic > > slave drivers will come up, once we have the infrastructure. So > > it could be useful to have the settings as optional properties. > > OTOH it can also be done once it is needed. > > Yes, you could have devices that do autobaud detect and don't care > other than some max baudrate which could be limited by either the host > or device. Then you have others that are fixed or start at a fixed > baud and then switch. > > As for generic slaves, no doubt they will come up and I will be > nak'ing the generic slave bindings. The "generic slave" is already > supported via tty devices in userspace IMO. Ok I didn't meant that generic. I meant something like "I have a remote controller with specific protocol, baudrate is board specific". Anyways it can be discussed once needed -- Sebastian signature.asc Description: PGP signature
Re: [RFC PATCH 0/3] UART slave device bus
> I now wonder if we can not just turn the ldisc into a bus. So we have a ldisc > bus that exposes devices that have no business of having a userspace > /dev/ttyX exposed. And our Bluetooth UART support just turns into a ldisc > driver on the ldisc bus. The ldisc and tty have the wrong object lifetime for a bus, but you can put the tty_port objects onto the bus, and it is those you need to instantiate the stack. The port exists for hardware lifetime, the tty and ldisc exist only while the port is "up". Alan
Re: [RFC PATCH 0/3] UART slave device bus
> I now wonder if we can not just turn the ldisc into a bus. So we have a ldisc > bus that exposes devices that have no business of having a userspace > /dev/ttyX exposed. And our Bluetooth UART support just turns into a ldisc > driver on the ldisc bus. The ldisc and tty have the wrong object lifetime for a bus, but you can put the tty_port objects onto the bus, and it is those you need to instantiate the stack. The port exists for hardware lifetime, the tty and ldisc exist only while the port is "up". Alan
Re: [RFC PATCH 0/3] UART slave device bus
On Mon 2016-08-22 22:32:23, One Thousand Gnomes wrote: > > why would we even have it create a /dev/ttyX for these devices in the first > > place. Lets just not create an uevent for it and lets not create a dev_t > > for it. > > Because if you don't it's a regression. It's not permissible to break > existing userspace. Well... it would be good to do the right thing, at least in the places where we can. Yes, renumbering people's serials is bad, OTOH for new platforms it would be nice not to expose ttyS15 which can only return -EBUSY. And we may want to do incompatible change at some point. People should not have to use hciattach on n900 from now on until end of time, just because we exposed USB port as ttyO1 in past. ...actually. I guess we should disable that ttyO1 in the device tree for now, so nobody can start using it. As we currently have 2-3 people in world who got that bluetooth to work with out-of-tree patches, breakage should be quite acceptable :-). Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [RFC PATCH 0/3] UART slave device bus
On Mon 2016-08-22 22:32:23, One Thousand Gnomes wrote: > > why would we even have it create a /dev/ttyX for these devices in the first > > place. Lets just not create an uevent for it and lets not create a dev_t > > for it. > > Because if you don't it's a regression. It's not permissible to break > existing userspace. Well... it would be good to do the right thing, at least in the places where we can. Yes, renumbering people's serials is bad, OTOH for new platforms it would be nice not to expose ttyS15 which can only return -EBUSY. And we may want to do incompatible change at some point. People should not have to use hciattach on n900 from now on until end of time, just because we exposed USB port as ttyO1 in past. ...actually. I guess we should disable that ttyO1 in the device tree for now, so nobody can start using it. As we currently have 2-3 people in world who got that bluetooth to work with out-of-tree patches, breakage should be quite acceptable :-). Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [RFC PATCH 0/3] UART slave device bus
Hi, On Mon, Aug 22, 2016 at 05:07:06PM -0400, Marcel Holtmann wrote: > >> Would it make sense then to define a DT binding that can cover these > >> four cases independent of the Linux usage: > >> > >> a) an existing tty line discipline matched to a tty port > >> b) a serio device using the N_MOUSE line discipline (which > >> happens to cover non-mouse devices these days) > > > > These two are the same basic thing > > > > port x expects ldisc y {with properties ...} > > > >> c) a uart_port slave attached directly to the uart (like in your > >> current code) > > > > c) needs to be a tty_port slave attached directly to a tty_port. > > Important detail, but as uart_port is just a subset of tty_port it's a > > trivial detail to the DT. > > > >> d) the same slave drivers using a new tty line discipline > > > > and this is also just a/b again. > > > > > > What use cases and connectivity do you need to describe. Looking at the > > ACPI platforms we have > > > > - the expected serial port configuration > > - the properties of the port (FIFO etc) > > - the power management for the port > > > > - the children of the port > > - the power management of the children (at a very simplistic abstracted > > level) > > > > So we want to be able to describe something like > > > > ttyS0 { > > baud: 1152008N1 > > protocol: bluetooth hci > > fixed: yes > > powermanagement: { ... } > > } > > we also need to know what Bluetooth vendor is there. Since we need > to match the vendor to the firmware loading and configuration. > > Additionally there might be PCM audio configurations that need to > be considered. Since we have to configure direct PCM interconnect > with the audio codec. It's not enough to automatically set a ldisc. There is also need for additional resouces. For example the Nokia bluetooth driver needs some extra GPIOs. The same is true for the in-tree hci_bcm, which misuses the platform_device exactly like Greg doesn't want it. > > and if I look at the usermode crapfest on a lot of Android systems it > > looks similar but with the notion of things like being able to describe > > > > - Use GPIO mode sleeping and assume first char is X to save power > > > > - Power up, wait n ms, write, read, wait n ms, power down (which > > has to be driven at the ldisc/user level as only the ldisc > > understands transactions, or via ioctls (right now Android user > > space tends to do hardcoded writes to /sys.. gpio to drive power > > > > - And a few variants thereof (power up on write, off on a timer > > etc) > > Actually the sad part about the Android mess is that we can fix it > for Bluetooth. We have HCI User Channel that allows to grab a HCI > device and assign it to Bluedroid stack on Android. So it would > work with whatever bus or whatever vendor is underneath. All this > hacking would go away. And we have used this successfully for > Intel based Android platforms. We know this works. > > > So I can imagine wanting to describe something like > > > > - The bluetooth HCI hardware is managed by gpio 11 (or UART DTR, > > or PMIC n etc) > > The uart can switch into GPIO mode and is gpio 15 > > > > or > > > > - Raise gpio 4 when writing, drop it after 50mS with no read/write > > > > Then the ldisc needs to make port->ops. calls for enabling/disabling low > > power mode and expected char, and the uarts that can do it need to > > implement the gpio/uart switching and any timers. > > I now wonder if we can not just turn the ldisc into a bus. So we > have a ldisc bus that exposes devices that have no business of > having a userspace /dev/ttyX exposed. And our Bluetooth UART > support just turns into a ldisc driver on the ldisc bus. > > One of the problems is that attaching the ldisc from userspace you > still need to figure out what /dev/ttyX you get assigned in the > end. And figure out which one is the Bluetooth UART. If we want > single images where things just work out of the box, we need to > get extra information for doing auto-detection. So some sort of > bus enumeration is key to make this work smoothly. I don't understand your propsoal. First you write, that no ttyX needs to be exported at all, then you need to figure out what ttyX got assigned in the end. I think the problem with line disciplines is, that they do not follow the Linux device model. UART slaves may have extra resources like gpios or regulators. The current workaround from the drivers is an additional platform device, which only is used as resource storage and accessed by the line discipline. I think having a proper slave devices would be better in the long run than adding more hacks to work around the problem of line discplines not being devices. It probably makes sense to make the API similar to the line discipline API, though. That way old code can be reused. -- Sebastian signature.asc Description: PGP signature
Re: [RFC PATCH 0/3] UART slave device bus
Hi, On Mon, Aug 22, 2016 at 05:07:06PM -0400, Marcel Holtmann wrote: > >> Would it make sense then to define a DT binding that can cover these > >> four cases independent of the Linux usage: > >> > >> a) an existing tty line discipline matched to a tty port > >> b) a serio device using the N_MOUSE line discipline (which > >> happens to cover non-mouse devices these days) > > > > These two are the same basic thing > > > > port x expects ldisc y {with properties ...} > > > >> c) a uart_port slave attached directly to the uart (like in your > >> current code) > > > > c) needs to be a tty_port slave attached directly to a tty_port. > > Important detail, but as uart_port is just a subset of tty_port it's a > > trivial detail to the DT. > > > >> d) the same slave drivers using a new tty line discipline > > > > and this is also just a/b again. > > > > > > What use cases and connectivity do you need to describe. Looking at the > > ACPI platforms we have > > > > - the expected serial port configuration > > - the properties of the port (FIFO etc) > > - the power management for the port > > > > - the children of the port > > - the power management of the children (at a very simplistic abstracted > > level) > > > > So we want to be able to describe something like > > > > ttyS0 { > > baud: 1152008N1 > > protocol: bluetooth hci > > fixed: yes > > powermanagement: { ... } > > } > > we also need to know what Bluetooth vendor is there. Since we need > to match the vendor to the firmware loading and configuration. > > Additionally there might be PCM audio configurations that need to > be considered. Since we have to configure direct PCM interconnect > with the audio codec. It's not enough to automatically set a ldisc. There is also need for additional resouces. For example the Nokia bluetooth driver needs some extra GPIOs. The same is true for the in-tree hci_bcm, which misuses the platform_device exactly like Greg doesn't want it. > > and if I look at the usermode crapfest on a lot of Android systems it > > looks similar but with the notion of things like being able to describe > > > > - Use GPIO mode sleeping and assume first char is X to save power > > > > - Power up, wait n ms, write, read, wait n ms, power down (which > > has to be driven at the ldisc/user level as only the ldisc > > understands transactions, or via ioctls (right now Android user > > space tends to do hardcoded writes to /sys.. gpio to drive power > > > > - And a few variants thereof (power up on write, off on a timer > > etc) > > Actually the sad part about the Android mess is that we can fix it > for Bluetooth. We have HCI User Channel that allows to grab a HCI > device and assign it to Bluedroid stack on Android. So it would > work with whatever bus or whatever vendor is underneath. All this > hacking would go away. And we have used this successfully for > Intel based Android platforms. We know this works. > > > So I can imagine wanting to describe something like > > > > - The bluetooth HCI hardware is managed by gpio 11 (or UART DTR, > > or PMIC n etc) > > The uart can switch into GPIO mode and is gpio 15 > > > > or > > > > - Raise gpio 4 when writing, drop it after 50mS with no read/write > > > > Then the ldisc needs to make port->ops. calls for enabling/disabling low > > power mode and expected char, and the uarts that can do it need to > > implement the gpio/uart switching and any timers. > > I now wonder if we can not just turn the ldisc into a bus. So we > have a ldisc bus that exposes devices that have no business of > having a userspace /dev/ttyX exposed. And our Bluetooth UART > support just turns into a ldisc driver on the ldisc bus. > > One of the problems is that attaching the ldisc from userspace you > still need to figure out what /dev/ttyX you get assigned in the > end. And figure out which one is the Bluetooth UART. If we want > single images where things just work out of the box, we need to > get extra information for doing auto-detection. So some sort of > bus enumeration is key to make this work smoothly. I don't understand your propsoal. First you write, that no ttyX needs to be exported at all, then you need to figure out what ttyX got assigned in the end. I think the problem with line disciplines is, that they do not follow the Linux device model. UART slaves may have extra resources like gpios or regulators. The current workaround from the drivers is an additional platform device, which only is used as resource storage and accessed by the line discipline. I think having a proper slave devices would be better in the long run than adding more hacks to work around the problem of line discplines not being devices. It probably makes sense to make the API similar to the line discipline API, though. That way old code can be reused. -- Sebastian signature.asc Description: PGP signature
Re: [RFC PATCH 0/3] UART slave device bus
On Mon, Aug 22, 2016 at 3:00 PM, Sebastian Reichelwrote: > Hi, > > On Mon, Aug 22, 2016 at 12:30:27PM -0500, Rob Herring wrote: >> On Mon, Aug 22, 2016 at 12:02 PM, One Thousand Gnomes >> wrote: >> >> > I think there are two other valuable features provided by serio: >> >> > >> >> > - an existing set of drivers written to the API >> >> > - the implementation of the tty_ldisc >> >> >> >> True, though I'd expect little of the data flow part of it to be reused. >> > >> > Then your design is broken. >> >> I'm talking about serio, not my design which I already said the >> receive side at least needs work. >> >> The serio API for rx and tx is a single character at a time. I thought >> we agreed that's not sufficient for things like BT. >> >> >> - a child of the uart node >> >> - a reg property containing the line number if the parent has multiple >> >> uarts (I'd expect this to rarely be used). >> > >> > That surprises me as for current x86 platforms it would be the norm, >> > except that we use ACPI. >> >> Exactly, we're talking DT bindings here. Each port will be a separate >> node otherwise things like serial aliases and stdout-path won't work >> correctly. Compatible strings for 8250 uarts are for a single port. >> But if you had h/w such that it has common and per port registers then >> it may be a single node. I'm not aware of any example offhand (maybe >> PPC CPM). But it doesn't matter as reg can handle this case just fine >> if we need to. > > I would expect, that your imaginary example h/w also has one node > per port using a mfd style h/w description: > > multi-uart-device { > uart1 { > child { }; > }; > uart2 { > child { }; > }; > }; Yes, that is certainly possible too. >> >> - baudrate and other line configuration (though I would expect the >> >> slave driver to know all this and set it w/o DT. Also, we already have >> >> a way to set baudrate in the parent node at least.) > > I'm not sure if every slave driver knows this. Maybe some generic > slave drivers will come up, once we have the infrastructure. So > it could be useful to have the settings as optional properties. > OTOH it can also be done once it is needed. Yes, you could have devices that do autobaud detect and don't care other than some max baudrate which could be limited by either the host or device. Then you have others that are fixed or start at a fixed baud and then switch. As for generic slaves, no doubt they will come up and I will be nak'ing the generic slave bindings. The "generic slave" is already supported via tty devices in userspace IMO. Rob
Re: [RFC PATCH 0/3] UART slave device bus
On Mon, Aug 22, 2016 at 3:00 PM, Sebastian Reichel wrote: > Hi, > > On Mon, Aug 22, 2016 at 12:30:27PM -0500, Rob Herring wrote: >> On Mon, Aug 22, 2016 at 12:02 PM, One Thousand Gnomes >> wrote: >> >> > I think there are two other valuable features provided by serio: >> >> > >> >> > - an existing set of drivers written to the API >> >> > - the implementation of the tty_ldisc >> >> >> >> True, though I'd expect little of the data flow part of it to be reused. >> > >> > Then your design is broken. >> >> I'm talking about serio, not my design which I already said the >> receive side at least needs work. >> >> The serio API for rx and tx is a single character at a time. I thought >> we agreed that's not sufficient for things like BT. >> >> >> - a child of the uart node >> >> - a reg property containing the line number if the parent has multiple >> >> uarts (I'd expect this to rarely be used). >> > >> > That surprises me as for current x86 platforms it would be the norm, >> > except that we use ACPI. >> >> Exactly, we're talking DT bindings here. Each port will be a separate >> node otherwise things like serial aliases and stdout-path won't work >> correctly. Compatible strings for 8250 uarts are for a single port. >> But if you had h/w such that it has common and per port registers then >> it may be a single node. I'm not aware of any example offhand (maybe >> PPC CPM). But it doesn't matter as reg can handle this case just fine >> if we need to. > > I would expect, that your imaginary example h/w also has one node > per port using a mfd style h/w description: > > multi-uart-device { > uart1 { > child { }; > }; > uart2 { > child { }; > }; > }; Yes, that is certainly possible too. >> >> - baudrate and other line configuration (though I would expect the >> >> slave driver to know all this and set it w/o DT. Also, we already have >> >> a way to set baudrate in the parent node at least.) > > I'm not sure if every slave driver knows this. Maybe some generic > slave drivers will come up, once we have the infrastructure. So > it could be useful to have the settings as optional properties. > OTOH it can also be done once it is needed. Yes, you could have devices that do autobaud detect and don't care other than some max baudrate which could be limited by either the host or device. Then you have others that are fixed or start at a fixed baud and then switch. As for generic slaves, no doubt they will come up and I will be nak'ing the generic slave bindings. The "generic slave" is already supported via tty devices in userspace IMO. Rob
Re: [RFC PATCH 0/3] UART slave device bus
On Monday, August 22, 2016 11:23:26 PM CEST H. Nikolaus Schaller wrote: > I see what you mean, but kernel divides between directly connected UART and > USB-connected UART. > > drivers/usb/serial/ vs. drivers/tty/serial/ That distinction purely exists for historic reasons. I'd argue that the former should actually go into drivers/tty/usb or similar. A long time ago, we commonly sorted device drivers by how they were attached to the system (as drivers/usb/serial/ and drivers/usb/storage still do), but almost everything is now sorted according to how it is used instead. Arnd
Re: [RFC PATCH 0/3] UART slave device bus
On Monday, August 22, 2016 11:23:26 PM CEST H. Nikolaus Schaller wrote: > I see what you mean, but kernel divides between directly connected UART and > USB-connected UART. > > drivers/usb/serial/ vs. drivers/tty/serial/ That distinction purely exists for historic reasons. I'd argue that the former should actually go into drivers/tty/usb or similar. A long time ago, we commonly sorted device drivers by how they were attached to the system (as drivers/usb/serial/ and drivers/usb/storage still do), but almost everything is now sorted according to how it is used instead. Arnd
Re: [RFC PATCH 0/3] UART slave device bus
> why would we even have it create a /dev/ttyX for these devices in the first > place. Lets just not create an uevent for it and lets not create a dev_t for > it. Because if you don't it's a regression. It's not permissible to break existing userspace. > Internally the setup stage does a hciconfig hci0 up and it is already > abstracted out that way. So there has been a lot of work in the Bluetooth > subsystem to allow for this. That part is really solved. So you'd create a kernel side tty struct and bind it to the tty_port on hci0 up and drop it on hci0 down ? Alan
Re: [RFC PATCH 0/3] UART slave device bus
> why would we even have it create a /dev/ttyX for these devices in the first > place. Lets just not create an uevent for it and lets not create a dev_t for > it. Because if you don't it's a regression. It's not permissible to break existing userspace. > Internally the setup stage does a hciconfig hci0 up and it is already > abstracted out that way. So there has been a lot of work in the Bluetooth > subsystem to allow for this. That part is really solved. So you'd create a kernel side tty struct and bind it to the tty_port on hci0 up and drop it on hci0 down ? Alan
Re: [RFC PATCH 0/3] UART slave device bus
Hi Sebastian, > Am 22.08.2016 um 22:39 schrieb Sebastian Reichel: > > Hi, > > On Sun, Aug 21, 2016 at 09:50:57AM +0200, H. Nikolaus Schaller wrote: >>> Am 20.08.2016 um 15:34 schrieb One Thousand Gnomes >>> : What it is not about are UART/RS232 converters connected through USB or virtual serial ports created for WWAN modems (e.g. /dev/ttyACM, /dev/ttyHSO). Or BT devices connected through USB (even if they also run HCI protocol). >>> >>> It actually has to be about both because you will find the exact same >>> device wired via USB SSIC/HSIC to a USB UART or via a classic UART. Not is >>> it just about embedded boards. >> >> Not necessarily. >> >> We often have two interface options for exactly the sam sensor chips. They >> can be connected >> either through SPI or I2C. Which means that there is a core driver for the >> chip and two different >> transport glue components (see e.g. iio/accel/bmc150). >> >> This does not require I2C to be able to handle SPI or vice versa or provide >> a common API. > > I don't understand this comparison. I2C and SPI are different > protocols, Yes, they are different on protocol level, but on both you transfer blocks of data from/to a slave device which usually can be addressed. And for some chips they are just two slightly alternative serial interfaces. > while native UART and USB-connected UART are both UART. I see what you mean, but kernel divides between directly connected UART and USB-connected UART. drivers/usb/serial/ vs. drivers/tty/serial/ to implement two different groups of UARTs. Although on user space level they are harmonized again. This is why I compare with i2c and spi. But each such comparison is not perfect. Anyways, to me it looks as if everybody wants to make the solution work for usb-uarts as well (although I still would like to see a real world use-case). > >> And most Bluetooth devices I know have either UART or a direct >> USB interface. So in the USB case there is no need to connect >> it through some USB-UART bridge and treat it as an UART at all. > > I think having support for USB-UART dongles is useful for > driver development and testing on non-embedded HW. Hm. I assume you mean the Bluetooth situation where both, embedded UART connected chips and USB dongles are available. I am not a specialist for such things, but I think you have three options to connect bluetooth: a) SoC-UART <-> BT-Chip-UART-port b) USB-UART (FT232, PL2303 etc.) <-> BT-Chip-UART-port c) USB <-> BT-Chip-USB-port (not UART involved at all) Case c) IMHO means you anyways need a special USB driver for the BT-Chip connected through USB and plugging it into a non-embedded USB port does not automatically show it as a tty interface. So you can't use it for testing the UART drivers. BTW: the Wi2Wi W2CBW003 chip comes in two firmware variants: one for UART and one for USB. So they are also not exchangeable. Variant b) is IMHO of no practical relevance (but I may be wrong) because it would mean to add some costly FT232 or PL2302 chip where a different firmware variant works with direct USB connection. So to me it looks as if you need to develop different low-level drivers anyways. BR, Nikolaus signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [RFC PATCH 0/3] UART slave device bus
Hi Sebastian, > Am 22.08.2016 um 22:39 schrieb Sebastian Reichel : > > Hi, > > On Sun, Aug 21, 2016 at 09:50:57AM +0200, H. Nikolaus Schaller wrote: >>> Am 20.08.2016 um 15:34 schrieb One Thousand Gnomes >>> : What it is not about are UART/RS232 converters connected through USB or virtual serial ports created for WWAN modems (e.g. /dev/ttyACM, /dev/ttyHSO). Or BT devices connected through USB (even if they also run HCI protocol). >>> >>> It actually has to be about both because you will find the exact same >>> device wired via USB SSIC/HSIC to a USB UART or via a classic UART. Not is >>> it just about embedded boards. >> >> Not necessarily. >> >> We often have two interface options for exactly the sam sensor chips. They >> can be connected >> either through SPI or I2C. Which means that there is a core driver for the >> chip and two different >> transport glue components (see e.g. iio/accel/bmc150). >> >> This does not require I2C to be able to handle SPI or vice versa or provide >> a common API. > > I don't understand this comparison. I2C and SPI are different > protocols, Yes, they are different on protocol level, but on both you transfer blocks of data from/to a slave device which usually can be addressed. And for some chips they are just two slightly alternative serial interfaces. > while native UART and USB-connected UART are both UART. I see what you mean, but kernel divides between directly connected UART and USB-connected UART. drivers/usb/serial/ vs. drivers/tty/serial/ to implement two different groups of UARTs. Although on user space level they are harmonized again. This is why I compare with i2c and spi. But each such comparison is not perfect. Anyways, to me it looks as if everybody wants to make the solution work for usb-uarts as well (although I still would like to see a real world use-case). > >> And most Bluetooth devices I know have either UART or a direct >> USB interface. So in the USB case there is no need to connect >> it through some USB-UART bridge and treat it as an UART at all. > > I think having support for USB-UART dongles is useful for > driver development and testing on non-embedded HW. Hm. I assume you mean the Bluetooth situation where both, embedded UART connected chips and USB dongles are available. I am not a specialist for such things, but I think you have three options to connect bluetooth: a) SoC-UART <-> BT-Chip-UART-port b) USB-UART (FT232, PL2303 etc.) <-> BT-Chip-UART-port c) USB <-> BT-Chip-USB-port (not UART involved at all) Case c) IMHO means you anyways need a special USB driver for the BT-Chip connected through USB and plugging it into a non-embedded USB port does not automatically show it as a tty interface. So you can't use it for testing the UART drivers. BTW: the Wi2Wi W2CBW003 chip comes in two firmware variants: one for UART and one for USB. So they are also not exchangeable. Variant b) is IMHO of no practical relevance (but I may be wrong) because it would mean to add some costly FT232 or PL2302 chip where a different firmware variant works with direct USB connection. So to me it looks as if you need to develop different low-level drivers anyways. BR, Nikolaus signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [RFC PATCH 0/3] UART slave device bus
Hi Alan, - a child of the uart node - a reg property containing the line number if the parent has multiple uarts (I'd expect this to rarely be used). >>> >>> That surprises me as for current x86 platforms it would be the norm, >>> except that we use ACPI. >> >> Exactly, we're talking DT bindings here. Each port will be a separate >> node otherwise things like serial aliases and stdout-path won't work >> correctly. Compatible strings for 8250 uarts are for a single port. >> But if you had h/w such that it has common and per port registers then >> it may be a single node. I'm not aware of any example offhand (maybe >> PPC CPM). But it doesn't matter as reg can handle this case just fine >> if we need to. > > For the tty side by the way here's a first RFC of one approach we could > take. This should (unless I missed anything) allow the core tty framework > to be used directly from a kernel created tty object rather than one > backed by a file. > > commit fcd072e755594f9c9c0533d45223f56f76e3d104 > Author: Alan> Date: Mon Aug 22 18:05:56 2016 +0100 > >[RFC] tty_port: allow a port to be opened with a tty that has no file > handle > >Let us create tty objects entirely in kernel space. Untested proposal to >show why all the ideas around rewriting half the uart stack are not needed. > >With this a kernel created non file backed tty object could be used to > handle >data, and set terminal modes. Not all ldiscs can cope with this as N_TTY in >particular has to work back to the fs/tty layer. > >The tty_port code is however otherwise clean of file handles as far as I > can >tell as is the low level tty port write path used by the ldisc, the >configuration low level interfaces and most of the ldiscs. > >Currently you don't have any exposure to see tty hangups because those are >built around the file layer. However a) it's a fixed port so you probably >don't care about that b) if you do we can add a callback and c) you almost >certainly don't want the userspace tear down/rebuild behaviour anyway. > >This should however be sufficient if we wanted for example to enumerate all >the bluetooth bound fixed ports via ACPI and make them directly available. > >It doesn't deal with the case of a user opening a port that's also kernel >opened and that would need some locking out (so it returned EBUSY if bound >to a kernel device of some kind). That needs resolving along with how you >"up" or "down" your new bluetooth device, or enumerate it while providing >the existing tty API to avoid regressions (and to debug). why would we even have it create a /dev/ttyX for these devices in the first place. Lets just not create an uevent for it and lets not create a dev_t for it. The Bluetooth power on (aka hciconfig hci0 up/down) is already solved with modern Intel and Broadcom UART drivers. Essentially we attach the ldisc and tell it which vendor it is. That is it. Everything else is done inside the kernel from that point on. So attaching the ldisc (via btattach tool) is similar to plugging in a dongle via USB. It runs that basic setup like firmware loading and configuration and then goes back into sleep mode. Only when powering the Bluetooth hciX device up (via bluetoothd or manually) it gets out of sleep mode. And the details for that are left up to the driver. Internally the setup stage does a hciconfig hci0 up and it is already abstracted out that way. So there has been a lot of work in the Bluetooth subsystem to allow for this. That part is really solved. Regards Marcel
Re: [RFC PATCH 0/3] UART slave device bus
Hi Alan, - a child of the uart node - a reg property containing the line number if the parent has multiple uarts (I'd expect this to rarely be used). >>> >>> That surprises me as for current x86 platforms it would be the norm, >>> except that we use ACPI. >> >> Exactly, we're talking DT bindings here. Each port will be a separate >> node otherwise things like serial aliases and stdout-path won't work >> correctly. Compatible strings for 8250 uarts are for a single port. >> But if you had h/w such that it has common and per port registers then >> it may be a single node. I'm not aware of any example offhand (maybe >> PPC CPM). But it doesn't matter as reg can handle this case just fine >> if we need to. > > For the tty side by the way here's a first RFC of one approach we could > take. This should (unless I missed anything) allow the core tty framework > to be used directly from a kernel created tty object rather than one > backed by a file. > > commit fcd072e755594f9c9c0533d45223f56f76e3d104 > Author: Alan > Date: Mon Aug 22 18:05:56 2016 +0100 > >[RFC] tty_port: allow a port to be opened with a tty that has no file > handle > >Let us create tty objects entirely in kernel space. Untested proposal to >show why all the ideas around rewriting half the uart stack are not needed. > >With this a kernel created non file backed tty object could be used to > handle >data, and set terminal modes. Not all ldiscs can cope with this as N_TTY in >particular has to work back to the fs/tty layer. > >The tty_port code is however otherwise clean of file handles as far as I > can >tell as is the low level tty port write path used by the ldisc, the >configuration low level interfaces and most of the ldiscs. > >Currently you don't have any exposure to see tty hangups because those are >built around the file layer. However a) it's a fixed port so you probably >don't care about that b) if you do we can add a callback and c) you almost >certainly don't want the userspace tear down/rebuild behaviour anyway. > >This should however be sufficient if we wanted for example to enumerate all >the bluetooth bound fixed ports via ACPI and make them directly available. > >It doesn't deal with the case of a user opening a port that's also kernel >opened and that would need some locking out (so it returned EBUSY if bound >to a kernel device of some kind). That needs resolving along with how you >"up" or "down" your new bluetooth device, or enumerate it while providing >the existing tty API to avoid regressions (and to debug). why would we even have it create a /dev/ttyX for these devices in the first place. Lets just not create an uevent for it and lets not create a dev_t for it. The Bluetooth power on (aka hciconfig hci0 up/down) is already solved with modern Intel and Broadcom UART drivers. Essentially we attach the ldisc and tell it which vendor it is. That is it. Everything else is done inside the kernel from that point on. So attaching the ldisc (via btattach tool) is similar to plugging in a dongle via USB. It runs that basic setup like firmware loading and configuration and then goes back into sleep mode. Only when powering the Bluetooth hciX device up (via bluetoothd or manually) it gets out of sleep mode. And the details for that are left up to the driver. Internally the setup stage does a hciconfig hci0 up and it is already abstracted out that way. So there has been a lot of work in the Bluetooth subsystem to allow for this. That part is really solved. Regards Marcel
Re: [RFC PATCH 0/3] UART slave device bus
Hi Alan, >> Would it make sense then to define a DT binding that can cover these >> four cases independent of the Linux usage: >> >> a) an existing tty line discipline matched to a tty port >> b) a serio device using the N_MOUSE line discipline (which >> happens to cover non-mouse devices these days) > > These two are the same basic thing > > port x expects ldisc y {with properties ...} > >> c) a uart_port slave attached directly to the uart (like in your >> current code) > > c) needs to be a tty_port slave attached directly to a tty_port. > Important detail, but as uart_port is just a subset of tty_port it's a > trivial detail to the DT. > >> d) the same slave drivers using a new tty line discipline > > and this is also just a/b again. > > > What use cases and connectivity do you need to describe. Looking at the > ACPI platforms we have > > - the expected serial port configuration > - the properties of the port (FIFO etc) > - the power management for the port > > - the children of the port > - the power management of the children (at a very simplistic abstracted > level) > > So we want to be able to describe something like > > ttyS0 { > baud: 1152008N1 > protocol: bluetooth hci > fixed: yes > powermanagement: { ... } > } we also need to know what Bluetooth vendor is there. Since we need to match the vendor to the firmware loading and configuration. Additionally there might be PCM audio configurations that need to be considered. Since we have to configure direct PCM interconnect with the audio codec. > and if I look at the usermode crapfest on a lot of Android systems it > looks similar but with the notion of things like being able to describe > > - Use GPIO mode sleeping and assume first char is X to save power > > - Power up, wait n ms, write, read, wait n ms, power down (which > has to be driven at the ldisc/user level as only the ldisc > understands transactions, or via ioctls (right now Android user > space tends to do hardcoded writes to /sys.. gpio to drive power > > - And a few variants thereof (power up on write, off on a timer > etc) Actually the sad part about the Android mess is that we can fix it for Bluetooth. We have HCI User Channel that allows to grab a HCI device and assign it to Bluedroid stack on Android. So it would work with whatever bus or whatever vendor is underneath. All this hacking would go away. And we have used this successfully for Intel based Android platforms. We know this works. > So I can imagine wanting to describe something like > > - The bluetooth HCI hardware is managed by gpio 11 (or UART DTR, > or PMIC n etc) > The uart can switch into GPIO mode and is gpio 15 > > or > > - Raise gpio 4 when writing, drop it after 50mS with no read/write > > Then the ldisc needs to make port->ops. calls for enabling/disabling low > power mode and expected char, and the uarts that can do it need to > implement the gpio/uart switching and any timers. I now wonder if we can not just turn the ldisc into a bus. So we have a ldisc bus that exposes devices that have no business of having a userspace /dev/ttyX exposed. And our Bluetooth UART support just turns into a ldisc driver on the ldisc bus. One of the problems is that attaching the ldisc from userspace you still need to figure out what /dev/ttyX you get assigned in the end. And figure out which one is the Bluetooth UART. If we want single images where things just work out of the box, we need to get extra information for doing auto-detection. So some sort of bus enumeration is key to make this work smoothly. Regards Marcel
Re: [RFC PATCH 0/3] UART slave device bus
Hi Alan, >> Would it make sense then to define a DT binding that can cover these >> four cases independent of the Linux usage: >> >> a) an existing tty line discipline matched to a tty port >> b) a serio device using the N_MOUSE line discipline (which >> happens to cover non-mouse devices these days) > > These two are the same basic thing > > port x expects ldisc y {with properties ...} > >> c) a uart_port slave attached directly to the uart (like in your >> current code) > > c) needs to be a tty_port slave attached directly to a tty_port. > Important detail, but as uart_port is just a subset of tty_port it's a > trivial detail to the DT. > >> d) the same slave drivers using a new tty line discipline > > and this is also just a/b again. > > > What use cases and connectivity do you need to describe. Looking at the > ACPI platforms we have > > - the expected serial port configuration > - the properties of the port (FIFO etc) > - the power management for the port > > - the children of the port > - the power management of the children (at a very simplistic abstracted > level) > > So we want to be able to describe something like > > ttyS0 { > baud: 1152008N1 > protocol: bluetooth hci > fixed: yes > powermanagement: { ... } > } we also need to know what Bluetooth vendor is there. Since we need to match the vendor to the firmware loading and configuration. Additionally there might be PCM audio configurations that need to be considered. Since we have to configure direct PCM interconnect with the audio codec. > and if I look at the usermode crapfest on a lot of Android systems it > looks similar but with the notion of things like being able to describe > > - Use GPIO mode sleeping and assume first char is X to save power > > - Power up, wait n ms, write, read, wait n ms, power down (which > has to be driven at the ldisc/user level as only the ldisc > understands transactions, or via ioctls (right now Android user > space tends to do hardcoded writes to /sys.. gpio to drive power > > - And a few variants thereof (power up on write, off on a timer > etc) Actually the sad part about the Android mess is that we can fix it for Bluetooth. We have HCI User Channel that allows to grab a HCI device and assign it to Bluedroid stack on Android. So it would work with whatever bus or whatever vendor is underneath. All this hacking would go away. And we have used this successfully for Intel based Android platforms. We know this works. > So I can imagine wanting to describe something like > > - The bluetooth HCI hardware is managed by gpio 11 (or UART DTR, > or PMIC n etc) > The uart can switch into GPIO mode and is gpio 15 > > or > > - Raise gpio 4 when writing, drop it after 50mS with no read/write > > Then the ldisc needs to make port->ops. calls for enabling/disabling low > power mode and expected char, and the uarts that can do it need to > implement the gpio/uart switching and any timers. I now wonder if we can not just turn the ldisc into a bus. So we have a ldisc bus that exposes devices that have no business of having a userspace /dev/ttyX exposed. And our Bluetooth UART support just turns into a ldisc driver on the ldisc bus. One of the problems is that attaching the ldisc from userspace you still need to figure out what /dev/ttyX you get assigned in the end. And figure out which one is the Bluetooth UART. If we want single images where things just work out of the box, we need to get extra information for doing auto-detection. So some sort of bus enumeration is key to make this work smoothly. Regards Marcel
Re: [RFC PATCH 0/3] UART slave device bus
Hi, On Sun, Aug 21, 2016 at 09:50:57AM +0200, H. Nikolaus Schaller wrote: > > Am 20.08.2016 um 15:34 schrieb One Thousand Gnomes > >: > >> What it is not about are UART/RS232 converters connected through USB or > >> virtual > >> serial ports created for WWAN modems (e.g. /dev/ttyACM, /dev/ttyHSO). Or > >> BT devices > >> connected through USB (even if they also run HCI protocol). > > > > It actually has to be about both because you will find the exact same > > device wired via USB SSIC/HSIC to a USB UART or via a classic UART. Not is > > it just about embedded boards. > > Not necessarily. > > We often have two interface options for exactly the sam sensor chips. They > can be connected > either through SPI or I2C. Which means that there is a core driver for the > chip and two different > transport glue components (see e.g. iio/accel/bmc150). > > This does not require I2C to be able to handle SPI or vice versa or provide a > common API. I don't understand this comparison. I2C and SPI are different protocols, while native UART and USB-connected UART are both UART. > And most Bluetooth devices I know have either UART or a direct > USB interface. So in the USB case there is no need to connect > it through some USB-UART bridge and treat it as an UART at all. I think having support for USB-UART dongles is useful for driver development and testing on non-embedded HW. -- Sebastian signature.asc Description: PGP signature
Re: [RFC PATCH 0/3] UART slave device bus
Hi, On Sun, Aug 21, 2016 at 09:50:57AM +0200, H. Nikolaus Schaller wrote: > > Am 20.08.2016 um 15:34 schrieb One Thousand Gnomes > > : > >> What it is not about are UART/RS232 converters connected through USB or > >> virtual > >> serial ports created for WWAN modems (e.g. /dev/ttyACM, /dev/ttyHSO). Or > >> BT devices > >> connected through USB (even if they also run HCI protocol). > > > > It actually has to be about both because you will find the exact same > > device wired via USB SSIC/HSIC to a USB UART or via a classic UART. Not is > > it just about embedded boards. > > Not necessarily. > > We often have two interface options for exactly the sam sensor chips. They > can be connected > either through SPI or I2C. Which means that there is a core driver for the > chip and two different > transport glue components (see e.g. iio/accel/bmc150). > > This does not require I2C to be able to handle SPI or vice versa or provide a > common API. I don't understand this comparison. I2C and SPI are different protocols, while native UART and USB-connected UART are both UART. > And most Bluetooth devices I know have either UART or a direct > USB interface. So in the USB case there is no need to connect > it through some USB-UART bridge and treat it as an UART at all. I think having support for USB-UART dongles is useful for driver development and testing on non-embedded HW. -- Sebastian signature.asc Description: PGP signature
Re: [RFC PATCH 0/3] UART slave device bus
Hi, On Mon, Aug 22, 2016 at 12:30:27PM -0500, Rob Herring wrote: > On Mon, Aug 22, 2016 at 12:02 PM, One Thousand Gnomes >wrote: > >> > I think there are two other valuable features provided by serio: > >> > > >> > - an existing set of drivers written to the API > >> > - the implementation of the tty_ldisc > >> > >> True, though I'd expect little of the data flow part of it to be reused. > > > > Then your design is broken. > > I'm talking about serio, not my design which I already said the > receive side at least needs work. > > The serio API for rx and tx is a single character at a time. I thought > we agreed that's not sufficient for things like BT. > > >> - a child of the uart node > >> - a reg property containing the line number if the parent has multiple > >> uarts (I'd expect this to rarely be used). > > > > That surprises me as for current x86 platforms it would be the norm, > > except that we use ACPI. > > Exactly, we're talking DT bindings here. Each port will be a separate > node otherwise things like serial aliases and stdout-path won't work > correctly. Compatible strings for 8250 uarts are for a single port. > But if you had h/w such that it has common and per port registers then > it may be a single node. I'm not aware of any example offhand (maybe > PPC CPM). But it doesn't matter as reg can handle this case just fine > if we need to. I would expect, that your imaginary example h/w also has one node per port using a mfd style h/w description: multi-uart-device { uart1 { child { }; }; uart2 { child { }; }; }; > >> - baudrate and other line configuration (though I would expect the > >> slave driver to know all this and set it w/o DT. Also, we already have > >> a way to set baudrate in the parent node at least.) I'm not sure if every slave driver knows this. Maybe some generic slave drivers will come up, once we have the infrastructure. So it could be useful to have the settings as optional properties. OTOH it can also be done once it is needed. > >> - other standard device properties for interrupt, gpios, regulators. > >> > >> Also to consider is whether muxing of multiple slaves is needed. It's > >> not anything I've seen come up, but it's not hard to imagine. I think > >> that can be considered later and shouldn't impact the initial binding > >> or infrastructure. > > > > You can describe the child of the serial device as a mux and the children > > of the mux as whatever so it comes out fine when you get to that point. > > Yes, that's what I had in mind. I guess it can be discussed, when it becomes relevant. Until then let's not open another topic. -- Sebastian signature.asc Description: PGP signature
Re: [RFC PATCH 0/3] UART slave device bus
Hi, On Mon, Aug 22, 2016 at 12:30:27PM -0500, Rob Herring wrote: > On Mon, Aug 22, 2016 at 12:02 PM, One Thousand Gnomes > wrote: > >> > I think there are two other valuable features provided by serio: > >> > > >> > - an existing set of drivers written to the API > >> > - the implementation of the tty_ldisc > >> > >> True, though I'd expect little of the data flow part of it to be reused. > > > > Then your design is broken. > > I'm talking about serio, not my design which I already said the > receive side at least needs work. > > The serio API for rx and tx is a single character at a time. I thought > we agreed that's not sufficient for things like BT. > > >> - a child of the uart node > >> - a reg property containing the line number if the parent has multiple > >> uarts (I'd expect this to rarely be used). > > > > That surprises me as for current x86 platforms it would be the norm, > > except that we use ACPI. > > Exactly, we're talking DT bindings here. Each port will be a separate > node otherwise things like serial aliases and stdout-path won't work > correctly. Compatible strings for 8250 uarts are for a single port. > But if you had h/w such that it has common and per port registers then > it may be a single node. I'm not aware of any example offhand (maybe > PPC CPM). But it doesn't matter as reg can handle this case just fine > if we need to. I would expect, that your imaginary example h/w also has one node per port using a mfd style h/w description: multi-uart-device { uart1 { child { }; }; uart2 { child { }; }; }; > >> - baudrate and other line configuration (though I would expect the > >> slave driver to know all this and set it w/o DT. Also, we already have > >> a way to set baudrate in the parent node at least.) I'm not sure if every slave driver knows this. Maybe some generic slave drivers will come up, once we have the infrastructure. So it could be useful to have the settings as optional properties. OTOH it can also be done once it is needed. > >> - other standard device properties for interrupt, gpios, regulators. > >> > >> Also to consider is whether muxing of multiple slaves is needed. It's > >> not anything I've seen come up, but it's not hard to imagine. I think > >> that can be considered later and shouldn't impact the initial binding > >> or infrastructure. > > > > You can describe the child of the serial device as a mux and the children > > of the mux as whatever so it comes out fine when you get to that point. > > Yes, that's what I had in mind. I guess it can be discussed, when it becomes relevant. Until then let's not open another topic. -- Sebastian signature.asc Description: PGP signature
Re: [RFC PATCH 0/3] UART slave device bus
> I'm talking about serio, not my design which I already said the > receive side at least needs work. > > The serio API for rx and tx is a single character at a time. I thought > we agreed that's not sufficient for things like BT. Yes. > > >> - a child of the uart node > >> - a reg property containing the line number if the parent has multiple > >> uarts (I'd expect this to rarely be used). > > > > That surprises me as for current x86 platforms it would be the norm, > > except that we use ACPI. > > Exactly, we're talking DT bindings here. Each port will be a separate > node otherwise things like serial aliases and stdout-path won't work > correctly. Compatible strings for 8250 uarts are for a single port. > But if you had h/w such that it has common and per port registers then > it may be a single node. I'm not aware of any example offhand (maybe > PPC CPM). But it doesn't matter as reg can handle this case just fine > if we need to. For the tty side by the way here's a first RFC of one approach we could take. This should (unless I missed anything) allow the core tty framework to be used directly from a kernel created tty object rather than one backed by a file. commit fcd072e755594f9c9c0533d45223f56f76e3d104 Author: AlanDate: Mon Aug 22 18:05:56 2016 +0100 [RFC] tty_port: allow a port to be opened with a tty that has no file handle Let us create tty objects entirely in kernel space. Untested proposal to show why all the ideas around rewriting half the uart stack are not needed. With this a kernel created non file backed tty object could be used to handle data, and set terminal modes. Not all ldiscs can cope with this as N_TTY in particular has to work back to the fs/tty layer. The tty_port code is however otherwise clean of file handles as far as I can tell as is the low level tty port write path used by the ldisc, the configuration low level interfaces and most of the ldiscs. Currently you don't have any exposure to see tty hangups because those are built around the file layer. However a) it's a fixed port so you probably don't care about that b) if you do we can add a callback and c) you almost certainly don't want the userspace tear down/rebuild behaviour anyway. This should however be sufficient if we wanted for example to enumerate all the bluetooth bound fixed ports via ACPI and make them directly available. It doesn't deal with the case of a user opening a port that's also kernel opened and that would need some locking out (so it returned EBUSY if bound to a kernel device of some kind). That needs resolving along with how you "up" or "down" your new bluetooth device, or enumerate it while providing the existing tty API to avoid regressions (and to debug). Alan diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c index 734a635..6210cff 100644 --- a/drivers/tty/tty_io.c +++ b/drivers/tty/tty_io.c @@ -855,7 +855,7 @@ static void tty_vhangup_session(struct tty_struct *tty) int tty_hung_up_p(struct file *filp) { - return (filp->f_op == _up_tty_fops); + return (filp && filp->f_op == _up_tty_fops); } EXPORT_SYMBOL(tty_hung_up_p); diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c index c3f9d93..606d9e5 100644 --- a/drivers/tty/tty_port.c +++ b/drivers/tty/tty_port.c @@ -335,7 +335,7 @@ EXPORT_SYMBOL(tty_port_lower_dtr_rts); * tty_port_block_til_ready- Waiting logic for tty open * @port: the tty port being opened * @tty: the tty device being bound - * @filp: the file pointer of the opener + * @filp: the file pointer of the opener or NULL * * Implement the core POSIX/SuS tty behaviour when opening a tty device. * Handles: @@ -369,7 +369,7 @@ int tty_port_block_til_ready(struct tty_port *port, tty_port_set_active(port, 1); return 0; } - if (filp->f_flags & O_NONBLOCK) { + if (filp == NULL || (filp->f_flags & O_NONBLOCK)) { /* Indicate we are open */ if (C_BAUD(tty)) tty_port_raise_dtr_rts(port);
Re: [RFC PATCH 0/3] UART slave device bus
> I'm talking about serio, not my design which I already said the > receive side at least needs work. > > The serio API for rx and tx is a single character at a time. I thought > we agreed that's not sufficient for things like BT. Yes. > > >> - a child of the uart node > >> - a reg property containing the line number if the parent has multiple > >> uarts (I'd expect this to rarely be used). > > > > That surprises me as for current x86 platforms it would be the norm, > > except that we use ACPI. > > Exactly, we're talking DT bindings here. Each port will be a separate > node otherwise things like serial aliases and stdout-path won't work > correctly. Compatible strings for 8250 uarts are for a single port. > But if you had h/w such that it has common and per port registers then > it may be a single node. I'm not aware of any example offhand (maybe > PPC CPM). But it doesn't matter as reg can handle this case just fine > if we need to. For the tty side by the way here's a first RFC of one approach we could take. This should (unless I missed anything) allow the core tty framework to be used directly from a kernel created tty object rather than one backed by a file. commit fcd072e755594f9c9c0533d45223f56f76e3d104 Author: Alan Date: Mon Aug 22 18:05:56 2016 +0100 [RFC] tty_port: allow a port to be opened with a tty that has no file handle Let us create tty objects entirely in kernel space. Untested proposal to show why all the ideas around rewriting half the uart stack are not needed. With this a kernel created non file backed tty object could be used to handle data, and set terminal modes. Not all ldiscs can cope with this as N_TTY in particular has to work back to the fs/tty layer. The tty_port code is however otherwise clean of file handles as far as I can tell as is the low level tty port write path used by the ldisc, the configuration low level interfaces and most of the ldiscs. Currently you don't have any exposure to see tty hangups because those are built around the file layer. However a) it's a fixed port so you probably don't care about that b) if you do we can add a callback and c) you almost certainly don't want the userspace tear down/rebuild behaviour anyway. This should however be sufficient if we wanted for example to enumerate all the bluetooth bound fixed ports via ACPI and make them directly available. It doesn't deal with the case of a user opening a port that's also kernel opened and that would need some locking out (so it returned EBUSY if bound to a kernel device of some kind). That needs resolving along with how you "up" or "down" your new bluetooth device, or enumerate it while providing the existing tty API to avoid regressions (and to debug). Alan diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c index 734a635..6210cff 100644 --- a/drivers/tty/tty_io.c +++ b/drivers/tty/tty_io.c @@ -855,7 +855,7 @@ static void tty_vhangup_session(struct tty_struct *tty) int tty_hung_up_p(struct file *filp) { - return (filp->f_op == _up_tty_fops); + return (filp && filp->f_op == _up_tty_fops); } EXPORT_SYMBOL(tty_hung_up_p); diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c index c3f9d93..606d9e5 100644 --- a/drivers/tty/tty_port.c +++ b/drivers/tty/tty_port.c @@ -335,7 +335,7 @@ EXPORT_SYMBOL(tty_port_lower_dtr_rts); * tty_port_block_til_ready- Waiting logic for tty open * @port: the tty port being opened * @tty: the tty device being bound - * @filp: the file pointer of the opener + * @filp: the file pointer of the opener or NULL * * Implement the core POSIX/SuS tty behaviour when opening a tty device. * Handles: @@ -369,7 +369,7 @@ int tty_port_block_til_ready(struct tty_port *port, tty_port_set_active(port, 1); return 0; } - if (filp->f_flags & O_NONBLOCK) { + if (filp == NULL || (filp->f_flags & O_NONBLOCK)) { /* Indicate we are open */ if (C_BAUD(tty)) tty_port_raise_dtr_rts(port);
Re: [RFC PATCH 0/3] UART slave device bus
On Mon, Aug 22, 2016 at 12:02 PM, One Thousand Gnomeswrote: >> > I think there are two other valuable features provided by serio: >> > >> > - an existing set of drivers written to the API >> > - the implementation of the tty_ldisc >> >> True, though I'd expect little of the data flow part of it to be reused. > > Then your design is broken. I'm talking about serio, not my design which I already said the receive side at least needs work. The serio API for rx and tx is a single character at a time. I thought we agreed that's not sufficient for things like BT. >> - a child of the uart node >> - a reg property containing the line number if the parent has multiple >> uarts (I'd expect this to rarely be used). > > That surprises me as for current x86 platforms it would be the norm, > except that we use ACPI. Exactly, we're talking DT bindings here. Each port will be a separate node otherwise things like serial aliases and stdout-path won't work correctly. Compatible strings for 8250 uarts are for a single port. But if you had h/w such that it has common and per port registers then it may be a single node. I'm not aware of any example offhand (maybe PPC CPM). But it doesn't matter as reg can handle this case just fine if we need to. >> - baudrate and other line configuration (though I would expect the >> slave driver to know all this and set it w/o DT. Also, we already have >> a way to set baudrate in the parent node at least.) >> - other standard device properties for interrupt, gpios, regulators. >> >> Also to consider is whether muxing of multiple slaves is needed. It's >> not anything I've seen come up, but it's not hard to imagine. I think >> that can be considered later and shouldn't impact the initial binding >> or infrastructure. > > You can describe the child of the serial device as a mux and the children > of the mux as whatever so it comes out fine when you get to that point. Yes, that's what I had in mind. Rob
Re: [RFC PATCH 0/3] UART slave device bus
On Mon, Aug 22, 2016 at 12:02 PM, One Thousand Gnomes wrote: >> > I think there are two other valuable features provided by serio: >> > >> > - an existing set of drivers written to the API >> > - the implementation of the tty_ldisc >> >> True, though I'd expect little of the data flow part of it to be reused. > > Then your design is broken. I'm talking about serio, not my design which I already said the receive side at least needs work. The serio API for rx and tx is a single character at a time. I thought we agreed that's not sufficient for things like BT. >> - a child of the uart node >> - a reg property containing the line number if the parent has multiple >> uarts (I'd expect this to rarely be used). > > That surprises me as for current x86 platforms it would be the norm, > except that we use ACPI. Exactly, we're talking DT bindings here. Each port will be a separate node otherwise things like serial aliases and stdout-path won't work correctly. Compatible strings for 8250 uarts are for a single port. But if you had h/w such that it has common and per port registers then it may be a single node. I'm not aware of any example offhand (maybe PPC CPM). But it doesn't matter as reg can handle this case just fine if we need to. >> - baudrate and other line configuration (though I would expect the >> slave driver to know all this and set it w/o DT. Also, we already have >> a way to set baudrate in the parent node at least.) >> - other standard device properties for interrupt, gpios, regulators. >> >> Also to consider is whether muxing of multiple slaves is needed. It's >> not anything I've seen come up, but it's not hard to imagine. I think >> that can be considered later and shouldn't impact the initial binding >> or infrastructure. > > You can describe the child of the serial device as a mux and the children > of the mux as whatever so it comes out fine when you get to that point. Yes, that's what I had in mind. Rob
Re: [RFC PATCH 0/3] UART slave device bus
> Would it make sense then to define a DT binding that can cover these > four cases independent of the Linux usage: > > a) an existing tty line discipline matched to a tty port > b) a serio device using the N_MOUSE line discipline (which >happens to cover non-mouse devices these days) These two are the same basic thing port x expects ldisc y {with properties ...} > c) a uart_port slave attached directly to the uart (like in your >current code) c) needs to be a tty_port slave attached directly to a tty_port. Important detail, but as uart_port is just a subset of tty_port it's a trivial detail to the DT. > d) the same slave drivers using a new tty line discipline and this is also just a/b again. What use cases and connectivity do you need to describe. Looking at the ACPI platforms we have - the expected serial port configuration - the properties of the port (FIFO etc) - the power management for the port - the children of the port - the power management of the children (at a very simplistic abstracted level) So we want to be able to describe something like ttyS0 { baud: 1152008N1 protocol: bluetooth hci fixed: yes powermanagement: { ... } } and if I look at the usermode crapfest on a lot of Android systems it looks similar but with the notion of things like being able to describe - Use GPIO mode sleeping and assume first char is X to save power - Power up, wait n ms, write, read, wait n ms, power down (which has to be driven at the ldisc/user level as only the ldisc understands transactions, or via ioctls (right now Android user space tends to do hardcoded writes to /sys.. gpio to drive power - And a few variants thereof (power up on write, off on a timer etc) So I can imagine wanting to describe something like - The bluetooth HCI hardware is managed by gpio 11 (or UART DTR, or PMIC n etc) The uart can switch into GPIO mode and is gpio 15 or - Raise gpio 4 when writing, drop it after 50mS with no read/write Then the ldisc needs to make port->ops. calls for enabling/disabling low power mode and expected char, and the uarts that can do it need to implement the gpio/uart switching and any timers. Alan
Re: [RFC PATCH 0/3] UART slave device bus
> Would it make sense then to define a DT binding that can cover these > four cases independent of the Linux usage: > > a) an existing tty line discipline matched to a tty port > b) a serio device using the N_MOUSE line discipline (which >happens to cover non-mouse devices these days) These two are the same basic thing port x expects ldisc y {with properties ...} > c) a uart_port slave attached directly to the uart (like in your >current code) c) needs to be a tty_port slave attached directly to a tty_port. Important detail, but as uart_port is just a subset of tty_port it's a trivial detail to the DT. > d) the same slave drivers using a new tty line discipline and this is also just a/b again. What use cases and connectivity do you need to describe. Looking at the ACPI platforms we have - the expected serial port configuration - the properties of the port (FIFO etc) - the power management for the port - the children of the port - the power management of the children (at a very simplistic abstracted level) So we want to be able to describe something like ttyS0 { baud: 1152008N1 protocol: bluetooth hci fixed: yes powermanagement: { ... } } and if I look at the usermode crapfest on a lot of Android systems it looks similar but with the notion of things like being able to describe - Use GPIO mode sleeping and assume first char is X to save power - Power up, wait n ms, write, read, wait n ms, power down (which has to be driven at the ldisc/user level as only the ldisc understands transactions, or via ioctls (right now Android user space tends to do hardcoded writes to /sys.. gpio to drive power - And a few variants thereof (power up on write, off on a timer etc) So I can imagine wanting to describe something like - The bluetooth HCI hardware is managed by gpio 11 (or UART DTR, or PMIC n etc) The uart can switch into GPIO mode and is gpio 15 or - Raise gpio 4 when writing, drop it after 50mS with no read/write Then the ldisc needs to make port->ops. calls for enabling/disabling low power mode and expected char, and the uarts that can do it need to implement the gpio/uart switching and any timers. Alan
Re: [RFC PATCH 0/3] UART slave device bus
> > I think there are two other valuable features provided by serio: > > > > - an existing set of drivers written to the API > > - the implementation of the tty_ldisc > > True, though I'd expect little of the data flow part of it to be reused. Then your design is broken. > - a child of the uart node > - a reg property containing the line number if the parent has multiple > uarts (I'd expect this to rarely be used). That surprises me as for current x86 platforms it would be the norm, except that we use ACPI. > - baudrate and other line configuration (though I would expect the > slave driver to know all this and set it w/o DT. Also, we already have > a way to set baudrate in the parent node at least.) > - other standard device properties for interrupt, gpios, regulators. > > Also to consider is whether muxing of multiple slaves is needed. It's > not anything I've seen come up, but it's not hard to imagine. I think > that can be considered later and shouldn't impact the initial binding > or infrastructure. You can describe the child of the serial device as a mux and the children of the mux as whatever so it comes out fine when you get to that point. Alan
Re: [RFC PATCH 0/3] UART slave device bus
> > I think there are two other valuable features provided by serio: > > > > - an existing set of drivers written to the API > > - the implementation of the tty_ldisc > > True, though I'd expect little of the data flow part of it to be reused. Then your design is broken. > - a child of the uart node > - a reg property containing the line number if the parent has multiple > uarts (I'd expect this to rarely be used). That surprises me as for current x86 platforms it would be the norm, except that we use ACPI. > - baudrate and other line configuration (though I would expect the > slave driver to know all this and set it w/o DT. Also, we already have > a way to set baudrate in the parent node at least.) > - other standard device properties for interrupt, gpios, regulators. > > Also to consider is whether muxing of multiple slaves is needed. It's > not anything I've seen come up, but it's not hard to imagine. I think > that can be considered later and shouldn't impact the initial binding > or infrastructure. You can describe the child of the serial device as a mux and the children of the mux as whatever so it comes out fine when you get to that point. Alan
Re: [RFC PATCH 0/3] UART slave device bus
On Mon, Aug 22, 2016 at 10:24 AM, Arnd Bergmannwrote: > On Monday, August 22, 2016 8:38:23 AM CEST Rob Herring wrote: >> On Mon, Aug 22, 2016 at 7:37 AM, Arnd Bergmann wrote: >> > On Wednesday, August 17, 2016 8:14:42 PM CEST Rob Herring wrote: >> >> >> >> Before I spend more time on this, I'm looking mainly for feedback on the >> >> general direction and structure (the interface with the existing serial >> >> drivers in particular). >> > >> > Aside from the things that have already been mentioned in the discussion, >> > I wonder how this should relate to the drivers/input/serio framework. >> >> As I mentioned, I did investigate that route. > > Ok, sorry for missing that. > >> > My impression is that there is some overlap in what you want >> > to do here, and what serio does today as a line discipline on top >> > of a tty line discipline (and on top of other non-uart serial >> > connections), so we should look into whether the two can be unified >> > or not. Here is what I found so far: >> > >> > For all I can tell, serio is only used for drivers/input/ but could >> > easily be extended to other subsystems. It currently uses its own >> > binary ID matching between drivers and devices through user space >> > interfaces, though adding a DT binding for it would appear to be >> > a good idea regardless. >> > >> > It also has a bus_type already, and with some operations defined on >> > it. In particular, it has an "interrupt" method that is used to >> > notify the client driver when a byte is available (and pass >> > that byte along with it). This seems to be a useful addition to >> > what you have. Since it is based on sending single characters >> > both ways, transferring large amounts of data would be slower, >> > but the interface is somewhat simpler. In principle, both >> > character based and buffer based interfaces could coexist here >> > as they do in some other interfaces (e.g. smbus). >> >> Given that about the only things it really provided are the bus_type >> and associated boilerplate without much of a client interface, it >> seemed to me that creating a new subsystem first made more sense. Then >> we can convert serio to use the new subsystem. > > One possible downside of merging later is that we end up having to > support the existing user space ABI for serio that may not fit well > within whatever we come up with independently. > > I think there are two other valuable features provided by serio: > > - an existing set of drivers written to the API > - the implementation of the tty_ldisc True, though I'd expect little of the data flow part of it to be reused. >> I agree we'll probably need a character at time interface, but for >> initial targets a buffer based interface is what's needed. > > I think what's more important than the 'character-at-a-time' interface > is the notification about new data. Maybe I missed how you handle that > today, but it seems that you can currently only handle polling > for data using a blocking read. What's there now I expect to change anyway. Probably will mirror the ldisc interface based on the discussion. >> > While serio is typically layered on top of tty-ldisc (on top of >> > tty_port, which is often on top of uart_port) or on top of >> > i8042/ps2 drivers, I suppose we could add another back-end on top >> > of uart_port directly to avoid the ldisc configuration in many >> > cases when using devicetree based setup. This should also address >> > the main concern that Alan raised about generality of the >> > subsystem: we'd always leave the option of either manual configuration >> > of the tty-ldisc (for any tty_port) or configuring on-chip devices >> > (using uart_port) directly through DT. Of course the same thing >> > can be done if we hook into tty_port rather than uart_port. >> >> There are also some uart drivers that register directly with serio. > > Right, I think this is done to have automatic probing for the keyboard, > rather than relying on the user space interface configuration. > >> I'm also thinking of using an ldisc backend as well as a way to move >> forward with the slave drivers while tty_port rework is being done. Of >> course that doesn't solve the fundamental problems with using an ldisc >> already. Going the tty_port route is going take some time to >> restructure things in the tty layer and require tree wide changes to >> tty drivers. > > Would it make sense then to define a DT binding that can cover these > four cases independent of the Linux usage: > > a) an existing tty line discipline matched to a tty port > b) a serio device using the N_MOUSE line discipline (which >happens to cover non-mouse devices these days) I agree with Alan these are the same. tty ldisc and tty ports are Linux concepts which shouldn't leak into DT. I've rejected bindings with "ttyBLAH" in them several times. Even if we did allow it, that sounds a half solution to me. Now if the binding is the same as (c) and there is some
Re: [RFC PATCH 0/3] UART slave device bus
On Mon, Aug 22, 2016 at 10:24 AM, Arnd Bergmann wrote: > On Monday, August 22, 2016 8:38:23 AM CEST Rob Herring wrote: >> On Mon, Aug 22, 2016 at 7:37 AM, Arnd Bergmann wrote: >> > On Wednesday, August 17, 2016 8:14:42 PM CEST Rob Herring wrote: >> >> >> >> Before I spend more time on this, I'm looking mainly for feedback on the >> >> general direction and structure (the interface with the existing serial >> >> drivers in particular). >> > >> > Aside from the things that have already been mentioned in the discussion, >> > I wonder how this should relate to the drivers/input/serio framework. >> >> As I mentioned, I did investigate that route. > > Ok, sorry for missing that. > >> > My impression is that there is some overlap in what you want >> > to do here, and what serio does today as a line discipline on top >> > of a tty line discipline (and on top of other non-uart serial >> > connections), so we should look into whether the two can be unified >> > or not. Here is what I found so far: >> > >> > For all I can tell, serio is only used for drivers/input/ but could >> > easily be extended to other subsystems. It currently uses its own >> > binary ID matching between drivers and devices through user space >> > interfaces, though adding a DT binding for it would appear to be >> > a good idea regardless. >> > >> > It also has a bus_type already, and with some operations defined on >> > it. In particular, it has an "interrupt" method that is used to >> > notify the client driver when a byte is available (and pass >> > that byte along with it). This seems to be a useful addition to >> > what you have. Since it is based on sending single characters >> > both ways, transferring large amounts of data would be slower, >> > but the interface is somewhat simpler. In principle, both >> > character based and buffer based interfaces could coexist here >> > as they do in some other interfaces (e.g. smbus). >> >> Given that about the only things it really provided are the bus_type >> and associated boilerplate without much of a client interface, it >> seemed to me that creating a new subsystem first made more sense. Then >> we can convert serio to use the new subsystem. > > One possible downside of merging later is that we end up having to > support the existing user space ABI for serio that may not fit well > within whatever we come up with independently. > > I think there are two other valuable features provided by serio: > > - an existing set of drivers written to the API > - the implementation of the tty_ldisc True, though I'd expect little of the data flow part of it to be reused. >> I agree we'll probably need a character at time interface, but for >> initial targets a buffer based interface is what's needed. > > I think what's more important than the 'character-at-a-time' interface > is the notification about new data. Maybe I missed how you handle that > today, but it seems that you can currently only handle polling > for data using a blocking read. What's there now I expect to change anyway. Probably will mirror the ldisc interface based on the discussion. >> > While serio is typically layered on top of tty-ldisc (on top of >> > tty_port, which is often on top of uart_port) or on top of >> > i8042/ps2 drivers, I suppose we could add another back-end on top >> > of uart_port directly to avoid the ldisc configuration in many >> > cases when using devicetree based setup. This should also address >> > the main concern that Alan raised about generality of the >> > subsystem: we'd always leave the option of either manual configuration >> > of the tty-ldisc (for any tty_port) or configuring on-chip devices >> > (using uart_port) directly through DT. Of course the same thing >> > can be done if we hook into tty_port rather than uart_port. >> >> There are also some uart drivers that register directly with serio. > > Right, I think this is done to have automatic probing for the keyboard, > rather than relying on the user space interface configuration. > >> I'm also thinking of using an ldisc backend as well as a way to move >> forward with the slave drivers while tty_port rework is being done. Of >> course that doesn't solve the fundamental problems with using an ldisc >> already. Going the tty_port route is going take some time to >> restructure things in the tty layer and require tree wide changes to >> tty drivers. > > Would it make sense then to define a DT binding that can cover these > four cases independent of the Linux usage: > > a) an existing tty line discipline matched to a tty port > b) a serio device using the N_MOUSE line discipline (which >happens to cover non-mouse devices these days) I agree with Alan these are the same. tty ldisc and tty ports are Linux concepts which shouldn't leak into DT. I've rejected bindings with "ttyBLAH" in them several times. Even if we did allow it, that sounds a half solution to me. Now if the binding is the same as (c) and there is some mapping of slave compatible
Re: [RFC PATCH 0/3] UART slave device bus
On Monday, August 22, 2016 11:28:02 AM CEST Marcel Holtmann wrote: > >>> My impression is that there is some overlap in what you want > >>> to do here, and what serio does today as a line discipline on top > >>> of a tty line discipline (and on top of other non-uart serial > >>> connections), so we should look into whether the two can be unified > >>> or not. Here is what I found so far: > >>> > >>> For all I can tell, serio is only used for drivers/input/ but could > >>> easily be extended to other subsystems. It currently uses its own > >>> binary ID matching between drivers and devices through user space > >>> interfaces, though adding a DT binding for it would appear to be > >>> a good idea regardless. > >>> > >>> It also has a bus_type already, and with some operations defined on > >>> it. In particular, it has an "interrupt" method that is used to > >>> notify the client driver when a byte is available (and pass > >>> that byte along with it). This seems to be a useful addition to > >>> what you have. Since it is based on sending single characters > >>> both ways, transferring large amounts of data would be slower, > >>> but the interface is somewhat simpler. In principle, both > >>> character based and buffer based interfaces could coexist here > >>> as they do in some other interfaces (e.g. smbus). > >> > >> Given that about the only things it really provided are the bus_type > >> and associated boilerplate without much of a client interface, it > >> seemed to me that creating a new subsystem first made more sense. Then > >> we can convert serio to use the new subsystem. > > > > One possible downside of merging later is that we end up having to > > support the existing user space ABI for serio that may not fit well > > within whatever we come up with independently. > > if we need any kind of userspace ABI to setup of Bluetooth > over UART devices, then we have failed. We want that the > special UARTs are identified via ACPI or DT and become an > enumeratable bus. So we can attach a driver to it. I was not referring to new devices here, only to the existing user space ABI that is used for serio (input) devices. If we have any tools relying on e.g. the 'serio' name for the sysfs path, using another name for the new bus_type may cause incompatibility when merging the two. Arnd
Re: [RFC PATCH 0/3] UART slave device bus
On Monday, August 22, 2016 11:28:02 AM CEST Marcel Holtmann wrote: > >>> My impression is that there is some overlap in what you want > >>> to do here, and what serio does today as a line discipline on top > >>> of a tty line discipline (and on top of other non-uart serial > >>> connections), so we should look into whether the two can be unified > >>> or not. Here is what I found so far: > >>> > >>> For all I can tell, serio is only used for drivers/input/ but could > >>> easily be extended to other subsystems. It currently uses its own > >>> binary ID matching between drivers and devices through user space > >>> interfaces, though adding a DT binding for it would appear to be > >>> a good idea regardless. > >>> > >>> It also has a bus_type already, and with some operations defined on > >>> it. In particular, it has an "interrupt" method that is used to > >>> notify the client driver when a byte is available (and pass > >>> that byte along with it). This seems to be a useful addition to > >>> what you have. Since it is based on sending single characters > >>> both ways, transferring large amounts of data would be slower, > >>> but the interface is somewhat simpler. In principle, both > >>> character based and buffer based interfaces could coexist here > >>> as they do in some other interfaces (e.g. smbus). > >> > >> Given that about the only things it really provided are the bus_type > >> and associated boilerplate without much of a client interface, it > >> seemed to me that creating a new subsystem first made more sense. Then > >> we can convert serio to use the new subsystem. > > > > One possible downside of merging later is that we end up having to > > support the existing user space ABI for serio that may not fit well > > within whatever we come up with independently. > > if we need any kind of userspace ABI to setup of Bluetooth > over UART devices, then we have failed. We want that the > special UARTs are identified via ACPI or DT and become an > enumeratable bus. So we can attach a driver to it. I was not referring to new devices here, only to the existing user space ABI that is used for serio (input) devices. If we have any tools relying on e.g. the 'serio' name for the sysfs path, using another name for the new bus_type may cause incompatibility when merging the two. Arnd
Re: [RFC PATCH 0/3] UART slave device bus
Hi Arnd, >>> My impression is that there is some overlap in what you want >>> to do here, and what serio does today as a line discipline on top >>> of a tty line discipline (and on top of other non-uart serial >>> connections), so we should look into whether the two can be unified >>> or not. Here is what I found so far: >>> >>> For all I can tell, serio is only used for drivers/input/ but could >>> easily be extended to other subsystems. It currently uses its own >>> binary ID matching between drivers and devices through user space >>> interfaces, though adding a DT binding for it would appear to be >>> a good idea regardless. >>> >>> It also has a bus_type already, and with some operations defined on >>> it. In particular, it has an "interrupt" method that is used to >>> notify the client driver when a byte is available (and pass >>> that byte along with it). This seems to be a useful addition to >>> what you have. Since it is based on sending single characters >>> both ways, transferring large amounts of data would be slower, >>> but the interface is somewhat simpler. In principle, both >>> character based and buffer based interfaces could coexist here >>> as they do in some other interfaces (e.g. smbus). >> >> Given that about the only things it really provided are the bus_type >> and associated boilerplate without much of a client interface, it >> seemed to me that creating a new subsystem first made more sense. Then >> we can convert serio to use the new subsystem. > > One possible downside of merging later is that we end up having to > support the existing user space ABI for serio that may not fit well > within whatever we come up with independently. if we need any kind of userspace ABI to setup of Bluetooth over UART devices, then we have failed. We want that the special UARTs are identified via ACPI or DT and become an enumeratable bus. So we can attach a driver to it. Regards Marcel
Re: [RFC PATCH 0/3] UART slave device bus
Hi Arnd, >>> My impression is that there is some overlap in what you want >>> to do here, and what serio does today as a line discipline on top >>> of a tty line discipline (and on top of other non-uart serial >>> connections), so we should look into whether the two can be unified >>> or not. Here is what I found so far: >>> >>> For all I can tell, serio is only used for drivers/input/ but could >>> easily be extended to other subsystems. It currently uses its own >>> binary ID matching between drivers and devices through user space >>> interfaces, though adding a DT binding for it would appear to be >>> a good idea regardless. >>> >>> It also has a bus_type already, and with some operations defined on >>> it. In particular, it has an "interrupt" method that is used to >>> notify the client driver when a byte is available (and pass >>> that byte along with it). This seems to be a useful addition to >>> what you have. Since it is based on sending single characters >>> both ways, transferring large amounts of data would be slower, >>> but the interface is somewhat simpler. In principle, both >>> character based and buffer based interfaces could coexist here >>> as they do in some other interfaces (e.g. smbus). >> >> Given that about the only things it really provided are the bus_type >> and associated boilerplate without much of a client interface, it >> seemed to me that creating a new subsystem first made more sense. Then >> we can convert serio to use the new subsystem. > > One possible downside of merging later is that we end up having to > support the existing user space ABI for serio that may not fit well > within whatever we come up with independently. if we need any kind of userspace ABI to setup of Bluetooth over UART devices, then we have failed. We want that the special UARTs are identified via ACPI or DT and become an enumeratable bus. So we can attach a driver to it. Regards Marcel
Re: [RFC PATCH 0/3] UART slave device bus
On Monday, August 22, 2016 8:38:23 AM CEST Rob Herring wrote: > On Mon, Aug 22, 2016 at 7:37 AM, Arnd Bergmannwrote: > > On Wednesday, August 17, 2016 8:14:42 PM CEST Rob Herring wrote: > >> > >> Before I spend more time on this, I'm looking mainly for feedback on the > >> general direction and structure (the interface with the existing serial > >> drivers in particular). > > > > Aside from the things that have already been mentioned in the discussion, > > I wonder how this should relate to the drivers/input/serio framework. > > As I mentioned, I did investigate that route. Ok, sorry for missing that. > > My impression is that there is some overlap in what you want > > to do here, and what serio does today as a line discipline on top > > of a tty line discipline (and on top of other non-uart serial > > connections), so we should look into whether the two can be unified > > or not. Here is what I found so far: > > > > For all I can tell, serio is only used for drivers/input/ but could > > easily be extended to other subsystems. It currently uses its own > > binary ID matching between drivers and devices through user space > > interfaces, though adding a DT binding for it would appear to be > > a good idea regardless. > > > > It also has a bus_type already, and with some operations defined on > > it. In particular, it has an "interrupt" method that is used to > > notify the client driver when a byte is available (and pass > > that byte along with it). This seems to be a useful addition to > > what you have. Since it is based on sending single characters > > both ways, transferring large amounts of data would be slower, > > but the interface is somewhat simpler. In principle, both > > character based and buffer based interfaces could coexist here > > as they do in some other interfaces (e.g. smbus). > > Given that about the only things it really provided are the bus_type > and associated boilerplate without much of a client interface, it > seemed to me that creating a new subsystem first made more sense. Then > we can convert serio to use the new subsystem. One possible downside of merging later is that we end up having to support the existing user space ABI for serio that may not fit well within whatever we come up with independently. I think there are two other valuable features provided by serio: - an existing set of drivers written to the API - the implementation of the tty_ldisc > I agree we'll probably need a character at time interface, but for > initial targets a buffer based interface is what's needed. I think what's more important than the 'character-at-a-time' interface is the notification about new data. Maybe I missed how you handle that today, but it seems that you can currently only handle polling for data using a blocking read. > > While serio is typically layered on top of tty-ldisc (on top of > > tty_port, which is often on top of uart_port) or on top of > > i8042/ps2 drivers, I suppose we could add another back-end on top > > of uart_port directly to avoid the ldisc configuration in many > > cases when using devicetree based setup. This should also address > > the main concern that Alan raised about generality of the > > subsystem: we'd always leave the option of either manual configuration > > of the tty-ldisc (for any tty_port) or configuring on-chip devices > > (using uart_port) directly through DT. Of course the same thing > > can be done if we hook into tty_port rather than uart_port. > > There are also some uart drivers that register directly with serio. Right, I think this is done to have automatic probing for the keyboard, rather than relying on the user space interface configuration. > I'm also thinking of using an ldisc backend as well as a way to move > forward with the slave drivers while tty_port rework is being done. Of > course that doesn't solve the fundamental problems with using an ldisc > already. Going the tty_port route is going take some time to > restructure things in the tty layer and require tree wide changes to > tty drivers. Would it make sense then to define a DT binding that can cover these four cases independent of the Linux usage: a) an existing tty line discipline matched to a tty port b) a serio device using the N_MOUSE line discipline (which happens to cover non-mouse devices these days) c) a uart_port slave attached directly to the uart (like in your current code) d) the same slave drivers using a new tty line discipline If we can handle all four, then at least we have some flexibility with moving around or merging the Linux implementation later. Arnd
Re: [RFC PATCH 0/3] UART slave device bus
On Monday, August 22, 2016 8:38:23 AM CEST Rob Herring wrote: > On Mon, Aug 22, 2016 at 7:37 AM, Arnd Bergmann wrote: > > On Wednesday, August 17, 2016 8:14:42 PM CEST Rob Herring wrote: > >> > >> Before I spend more time on this, I'm looking mainly for feedback on the > >> general direction and structure (the interface with the existing serial > >> drivers in particular). > > > > Aside from the things that have already been mentioned in the discussion, > > I wonder how this should relate to the drivers/input/serio framework. > > As I mentioned, I did investigate that route. Ok, sorry for missing that. > > My impression is that there is some overlap in what you want > > to do here, and what serio does today as a line discipline on top > > of a tty line discipline (and on top of other non-uart serial > > connections), so we should look into whether the two can be unified > > or not. Here is what I found so far: > > > > For all I can tell, serio is only used for drivers/input/ but could > > easily be extended to other subsystems. It currently uses its own > > binary ID matching between drivers and devices through user space > > interfaces, though adding a DT binding for it would appear to be > > a good idea regardless. > > > > It also has a bus_type already, and with some operations defined on > > it. In particular, it has an "interrupt" method that is used to > > notify the client driver when a byte is available (and pass > > that byte along with it). This seems to be a useful addition to > > what you have. Since it is based on sending single characters > > both ways, transferring large amounts of data would be slower, > > but the interface is somewhat simpler. In principle, both > > character based and buffer based interfaces could coexist here > > as they do in some other interfaces (e.g. smbus). > > Given that about the only things it really provided are the bus_type > and associated boilerplate without much of a client interface, it > seemed to me that creating a new subsystem first made more sense. Then > we can convert serio to use the new subsystem. One possible downside of merging later is that we end up having to support the existing user space ABI for serio that may not fit well within whatever we come up with independently. I think there are two other valuable features provided by serio: - an existing set of drivers written to the API - the implementation of the tty_ldisc > I agree we'll probably need a character at time interface, but for > initial targets a buffer based interface is what's needed. I think what's more important than the 'character-at-a-time' interface is the notification about new data. Maybe I missed how you handle that today, but it seems that you can currently only handle polling for data using a blocking read. > > While serio is typically layered on top of tty-ldisc (on top of > > tty_port, which is often on top of uart_port) or on top of > > i8042/ps2 drivers, I suppose we could add another back-end on top > > of uart_port directly to avoid the ldisc configuration in many > > cases when using devicetree based setup. This should also address > > the main concern that Alan raised about generality of the > > subsystem: we'd always leave the option of either manual configuration > > of the tty-ldisc (for any tty_port) or configuring on-chip devices > > (using uart_port) directly through DT. Of course the same thing > > can be done if we hook into tty_port rather than uart_port. > > There are also some uart drivers that register directly with serio. Right, I think this is done to have automatic probing for the keyboard, rather than relying on the user space interface configuration. > I'm also thinking of using an ldisc backend as well as a way to move > forward with the slave drivers while tty_port rework is being done. Of > course that doesn't solve the fundamental problems with using an ldisc > already. Going the tty_port route is going take some time to > restructure things in the tty layer and require tree wide changes to > tty drivers. Would it make sense then to define a DT binding that can cover these four cases independent of the Linux usage: a) an existing tty line discipline matched to a tty port b) a serio device using the N_MOUSE line discipline (which happens to cover non-mouse devices these days) c) a uart_port slave attached directly to the uart (like in your current code) d) the same slave drivers using a new tty line discipline If we can handle all four, then at least we have some flexibility with moving around or merging the Linux implementation later. Arnd
Re: [RFC PATCH 0/3] UART slave device bus
On Mon, Aug 22, 2016 at 7:37 AM, Arnd Bergmannwrote: > On Wednesday, August 17, 2016 8:14:42 PM CEST Rob Herring wrote: >> >> Before I spend more time on this, I'm looking mainly for feedback on the >> general direction and structure (the interface with the existing serial >> drivers in particular). > > Aside from the things that have already been mentioned in the discussion, > I wonder how this should relate to the drivers/input/serio framework. As I mentioned, I did investigate that route. > My impression is that there is some overlap in what you want > to do here, and what serio does today as a line discipline on top > of a tty line discipline (and on top of other non-uart serial > connections), so we should look into whether the two can be unified > or not. Here is what I found so far: > > For all I can tell, serio is only used for drivers/input/ but could > easily be extended to other subsystems. It currently uses its own > binary ID matching between drivers and devices through user space > interfaces, though adding a DT binding for it would appear to be > a good idea regardless. > > It also has a bus_type already, and with some operations defined on > it. In particular, it has an "interrupt" method that is used to > notify the client driver when a byte is available (and pass > that byte along with it). This seems to be a useful addition to > what you have. Since it is based on sending single characters > both ways, transferring large amounts of data would be slower, > but the interface is somewhat simpler. In principle, both > character based and buffer based interfaces could coexist here > as they do in some other interfaces (e.g. smbus). Given that about the only things it really provided are the bus_type and associated boilerplate without much of a client interface, it seemed to me that creating a new subsystem first made more sense. Then we can convert serio to use the new subsystem. I agree we'll probably need a character at time interface, but for initial targets a buffer based interface is what's needed. > While serio is typically layered on top of tty-ldisc (on top of > tty_port, which is often on top of uart_port) or on top of > i8042/ps2 drivers, I suppose we could add another back-end on top > of uart_port directly to avoid the ldisc configuration in many > cases when using devicetree based setup. This should also address > the main concern that Alan raised about generality of the > subsystem: we'd always leave the option of either manual configuration > of the tty-ldisc (for any tty_port) or configuring on-chip devices > (using uart_port) directly through DT. Of course the same thing > can be done if we hook into tty_port rather than uart_port. There are also some uart drivers that register directly with serio. I'm also thinking of using an ldisc backend as well as a way to move forward with the slave drivers while tty_port rework is being done. Of course that doesn't solve the fundamental problems with using an ldisc already. Going the tty_port route is going take some time to restructure things in the tty layer and require tree wide changes to tty drivers. Rob
Re: [RFC PATCH 0/3] UART slave device bus
On Mon, Aug 22, 2016 at 7:37 AM, Arnd Bergmann wrote: > On Wednesday, August 17, 2016 8:14:42 PM CEST Rob Herring wrote: >> >> Before I spend more time on this, I'm looking mainly for feedback on the >> general direction and structure (the interface with the existing serial >> drivers in particular). > > Aside from the things that have already been mentioned in the discussion, > I wonder how this should relate to the drivers/input/serio framework. As I mentioned, I did investigate that route. > My impression is that there is some overlap in what you want > to do here, and what serio does today as a line discipline on top > of a tty line discipline (and on top of other non-uart serial > connections), so we should look into whether the two can be unified > or not. Here is what I found so far: > > For all I can tell, serio is only used for drivers/input/ but could > easily be extended to other subsystems. It currently uses its own > binary ID matching between drivers and devices through user space > interfaces, though adding a DT binding for it would appear to be > a good idea regardless. > > It also has a bus_type already, and with some operations defined on > it. In particular, it has an "interrupt" method that is used to > notify the client driver when a byte is available (and pass > that byte along with it). This seems to be a useful addition to > what you have. Since it is based on sending single characters > both ways, transferring large amounts of data would be slower, > but the interface is somewhat simpler. In principle, both > character based and buffer based interfaces could coexist here > as they do in some other interfaces (e.g. smbus). Given that about the only things it really provided are the bus_type and associated boilerplate without much of a client interface, it seemed to me that creating a new subsystem first made more sense. Then we can convert serio to use the new subsystem. I agree we'll probably need a character at time interface, but for initial targets a buffer based interface is what's needed. > While serio is typically layered on top of tty-ldisc (on top of > tty_port, which is often on top of uart_port) or on top of > i8042/ps2 drivers, I suppose we could add another back-end on top > of uart_port directly to avoid the ldisc configuration in many > cases when using devicetree based setup. This should also address > the main concern that Alan raised about generality of the > subsystem: we'd always leave the option of either manual configuration > of the tty-ldisc (for any tty_port) or configuring on-chip devices > (using uart_port) directly through DT. Of course the same thing > can be done if we hook into tty_port rather than uart_port. There are also some uart drivers that register directly with serio. I'm also thinking of using an ldisc backend as well as a way to move forward with the slave drivers while tty_port rework is being done. Of course that doesn't solve the fundamental problems with using an ldisc already. Going the tty_port route is going take some time to restructure things in the tty layer and require tree wide changes to tty drivers. Rob
Re: [RFC PATCH 0/3] UART slave device bus
On Wednesday, August 17, 2016 8:14:42 PM CEST Rob Herring wrote: > > Before I spend more time on this, I'm looking mainly for feedback on the > general direction and structure (the interface with the existing serial > drivers in particular). Aside from the things that have already been mentioned in the discussion, I wonder how this should relate to the drivers/input/serio framework. My impression is that there is some overlap in what you want to do here, and what serio does today as a line discipline on top of a tty line discipline (and on top of other non-uart serial connections), so we should look into whether the two can be unified or not. Here is what I found so far: For all I can tell, serio is only used for drivers/input/ but could easily be extended to other subsystems. It currently uses its own binary ID matching between drivers and devices through user space interfaces, though adding a DT binding for it would appear to be a good idea regardless. It also has a bus_type already, and with some operations defined on it. In particular, it has an "interrupt" method that is used to notify the client driver when a byte is available (and pass that byte along with it). This seems to be a useful addition to what you have. Since it is based on sending single characters both ways, transferring large amounts of data would be slower, but the interface is somewhat simpler. In principle, both character based and buffer based interfaces could coexist here as they do in some other interfaces (e.g. smbus). While serio is typically layered on top of tty-ldisc (on top of tty_port, which is often on top of uart_port) or on top of i8042/ps2 drivers, I suppose we could add another back-end on top of uart_port directly to avoid the ldisc configuration in many cases when using devicetree based setup. This should also address the main concern that Alan raised about generality of the subsystem: we'd always leave the option of either manual configuration of the tty-ldisc (for any tty_port) or configuring on-chip devices (using uart_port) directly through DT. Of course the same thing can be done if we hook into tty_port rather than uart_port. Arnd
Re: [RFC PATCH 0/3] UART slave device bus
On Wednesday, August 17, 2016 8:14:42 PM CEST Rob Herring wrote: > > Before I spend more time on this, I'm looking mainly for feedback on the > general direction and structure (the interface with the existing serial > drivers in particular). Aside from the things that have already been mentioned in the discussion, I wonder how this should relate to the drivers/input/serio framework. My impression is that there is some overlap in what you want to do here, and what serio does today as a line discipline on top of a tty line discipline (and on top of other non-uart serial connections), so we should look into whether the two can be unified or not. Here is what I found so far: For all I can tell, serio is only used for drivers/input/ but could easily be extended to other subsystems. It currently uses its own binary ID matching between drivers and devices through user space interfaces, though adding a DT binding for it would appear to be a good idea regardless. It also has a bus_type already, and with some operations defined on it. In particular, it has an "interrupt" method that is used to notify the client driver when a byte is available (and pass that byte along with it). This seems to be a useful addition to what you have. Since it is based on sending single characters both ways, transferring large amounts of data would be slower, but the interface is somewhat simpler. In principle, both character based and buffer based interfaces could coexist here as they do in some other interfaces (e.g. smbus). While serio is typically layered on top of tty-ldisc (on top of tty_port, which is often on top of uart_port) or on top of i8042/ps2 drivers, I suppose we could add another back-end on top of uart_port directly to avoid the ldisc configuration in many cases when using devicetree based setup. This should also address the main concern that Alan raised about generality of the subsystem: we'd always leave the option of either manual configuration of the tty-ldisc (for any tty_port) or configuring on-chip devices (using uart_port) directly through DT. Of course the same thing can be done if we hook into tty_port rather than uart_port. Arnd
Re: [RFC PATCH 0/3] UART slave device bus
Hi Alan, >>> We do, today for bluetooth and other protocols just fine >> I think it works (even with user-space HCI daemon) because bluetooth HCI is >> slow (<300kByte/s). > > We do it for PPP over 3G modem as well. Modern 3G modems pretend to be > network devices, older ones didn't - and you are correct that in that > scenario we struggled (it's a lot better since Peter sorted the locking > out to be efficient). you have this backwards. Older 3G modems pretended to by Hayes compatible and pretended to be talking PPP. However PPP is terminated in the modem itself. It is not spoken over the 3GPP networks. These are purely IP. And yes, in theory there was a dialup in GSM, but I don't know of any users. Even early 9600 baud communication was RLP based. And for modern things like LTE it is IP all the way (including voice). What some modems still do today is pretend they are Ethernet devices. That is faked by the modem as well and mainly for some odd Windows crap. However many modern modems give you the raw IP stream. You just have to ask nicely. Regards Marcel
Re: [RFC PATCH 0/3] UART slave device bus
Hi Alan, >>> We do, today for bluetooth and other protocols just fine >> I think it works (even with user-space HCI daemon) because bluetooth HCI is >> slow (<300kByte/s). > > We do it for PPP over 3G modem as well. Modern 3G modems pretend to be > network devices, older ones didn't - and you are correct that in that > scenario we struggled (it's a lot better since Peter sorted the locking > out to be efficient). you have this backwards. Older 3G modems pretended to by Hayes compatible and pretended to be talking PPP. However PPP is terminated in the modem itself. It is not spoken over the 3GPP networks. These are purely IP. And yes, in theory there was a dialup in GSM, but I don't know of any users. Even early 9600 baud communication was RLP based. And for modern things like LTE it is IP all the way (including voice). What some modems still do today is pretend they are Ethernet devices. That is faked by the modem as well and mainly for some odd Windows crap. However many modern modems give you the raw IP stream. You just have to ask nicely. Regards Marcel
Re: [RFC PATCH 0/3] UART slave device bus
> When and how fast is the work queue scheduled? > And by which event? That depends upon the platform and how busy the machine is. The dumb uarts generally schedule it as soon as they've emptied the hardware. Some controllers it may be done off a timer, others off DMA completion events > > The workqueue involves the receive handler. > > This should be faster than if a driver directly processes incoming bytes? It is in cases like n_tty yes and more importantly the serial port can take another interrupt while the workqueue is running, so you won't drop bytes if you have flow control. > Or you have to assemble chunks into a frame, i.e. copy data around. You have to do a pass over the data anyway to remove any quoting in the framing for things like SLIP and PPP. > Both seems a waste of scarce cpu cycles in high-speed situations to me. The only case that I am aware of where there is a clear inefficiency is where the hardware is handling characters in big chunks with good buffering (eg DMA) and we are driving a protocol like PPP which simply wants to do one pass over the data and stuff it into the network stack. That one would be nice to fix with the port->rx suggestion I made. > Which might become the pitfall of the design because as I have described it > is an > essential part of processing UART based protocols. You seem to focus on > efficiently > buffering only but not about efficiently processing the queued data. There's a good reason for that - latency and throughput are not the same thing. We need good latency on the buffering but good throughput on the processing. Also if we fail to queue all the data reliably it doesn't matter how efficient the processing side is. > > We do, today for bluetooth and other protocols just fine > I think it works (even with user-space HCI daemon) because bluetooth HCI is > slow (<300kByte/s). We do it for PPP over 3G modem as well. Modern 3G modems pretend to be network devices, older ones didn't - and you are correct that in that scenario we struggled (it's a lot better since Peter sorted the locking out to be efficient). > Yes, but you should also take framing into account for a solution that helps > to implement > UART slave devices. That is my concern. I understand that I think anyway - you want to know the protocol state in order to do optimal power management. Use a GPIO edge and assume it's a '$', pick up via UART from the next byte, power the UART off the moment you see \n. Leave the power on if you seem to be out of sync so you can find a '$' and resync. If you have driver specific code for this your driver gets told when the line discipline changes so you can actually bury such logic in your low level driver and even hide what is going on from above. I've never had a problemw with what you are doing - just that it needs to b generic to be upstream, otherwise every serial driver would immediately develop thousands of lines of code for fifty differently wired and working phone and IoT devices. If the tty being open and normal tty operations are acceptable for the write/configuration side then the point I've been trying to make is you can't generically handle this at the uart layer. At the ldisc layer it would have a slightly higher latency but look something like (in an NMEA ldisc) /* We got newline, tell the port to go into low power mode directly or via whatever helpers it uses and to send us a '$' when it wakes back up if it can't send us the true char */ if (port->slave) { if (ch == '\n') port->slave->ops.lowpower(port, '$'); /* If we get a $ then wakey wakey */ if (ch == '$') port->slave->ops.lowpower(port, 0); } /* And if ops.lowpower is a no-op it all still works */ That also means that the port->slave-> method would be called in a workqueue so can do sensible stuff even on things like USB And the driver would presumably do something like name = find_slave_name(blah); /* From DeviceTree etc */ if (name) port->slave = request_tty_slave(name); (if you for some reason needed different behaviour knowledge at the slave level a tty ldisc change does notify the tty_port so we can do that too) Alan
Re: [RFC PATCH 0/3] UART slave device bus
> When and how fast is the work queue scheduled? > And by which event? That depends upon the platform and how busy the machine is. The dumb uarts generally schedule it as soon as they've emptied the hardware. Some controllers it may be done off a timer, others off DMA completion events > > The workqueue involves the receive handler. > > This should be faster than if a driver directly processes incoming bytes? It is in cases like n_tty yes and more importantly the serial port can take another interrupt while the workqueue is running, so you won't drop bytes if you have flow control. > Or you have to assemble chunks into a frame, i.e. copy data around. You have to do a pass over the data anyway to remove any quoting in the framing for things like SLIP and PPP. > Both seems a waste of scarce cpu cycles in high-speed situations to me. The only case that I am aware of where there is a clear inefficiency is where the hardware is handling characters in big chunks with good buffering (eg DMA) and we are driving a protocol like PPP which simply wants to do one pass over the data and stuff it into the network stack. That one would be nice to fix with the port->rx suggestion I made. > Which might become the pitfall of the design because as I have described it > is an > essential part of processing UART based protocols. You seem to focus on > efficiently > buffering only but not about efficiently processing the queued data. There's a good reason for that - latency and throughput are not the same thing. We need good latency on the buffering but good throughput on the processing. Also if we fail to queue all the data reliably it doesn't matter how efficient the processing side is. > > We do, today for bluetooth and other protocols just fine > I think it works (even with user-space HCI daemon) because bluetooth HCI is > slow (<300kByte/s). We do it for PPP over 3G modem as well. Modern 3G modems pretend to be network devices, older ones didn't - and you are correct that in that scenario we struggled (it's a lot better since Peter sorted the locking out to be efficient). > Yes, but you should also take framing into account for a solution that helps > to implement > UART slave devices. That is my concern. I understand that I think anyway - you want to know the protocol state in order to do optimal power management. Use a GPIO edge and assume it's a '$', pick up via UART from the next byte, power the UART off the moment you see \n. Leave the power on if you seem to be out of sync so you can find a '$' and resync. If you have driver specific code for this your driver gets told when the line discipline changes so you can actually bury such logic in your low level driver and even hide what is going on from above. I've never had a problemw with what you are doing - just that it needs to b generic to be upstream, otherwise every serial driver would immediately develop thousands of lines of code for fifty differently wired and working phone and IoT devices. If the tty being open and normal tty operations are acceptable for the write/configuration side then the point I've been trying to make is you can't generically handle this at the uart layer. At the ldisc layer it would have a slightly higher latency but look something like (in an NMEA ldisc) /* We got newline, tell the port to go into low power mode directly or via whatever helpers it uses and to send us a '$' when it wakes back up if it can't send us the true char */ if (port->slave) { if (ch == '\n') port->slave->ops.lowpower(port, '$'); /* If we get a $ then wakey wakey */ if (ch == '$') port->slave->ops.lowpower(port, 0); } /* And if ops.lowpower is a no-op it all still works */ That also means that the port->slave-> method would be called in a workqueue so can do sensible stuff even on things like USB And the driver would presumably do something like name = find_slave_name(blah); /* From DeviceTree etc */ if (name) port->slave = request_tty_slave(name); (if you for some reason needed different behaviour knowledge at the slave level a tty ldisc change does notify the tty_port so we can do that too) Alan
Re: [RFC PATCH 0/3] UART slave device bus
> Am 21.08.2016 um 19:09 schrieb One Thousand Gnomes >: > >> Let me ask a question about your centralized and pre-cooked buffering >> approach. >> >> As far as I see, even then the kernel API must notify the driver at the >> right moment >> that a new block has arrived. Right? > > The low level driver queues words (data byte, flag byte) > The buffer processing workqueue picks those bytes from the queue and > atomically empties the queue When and how fast is the work queue scheduled? And by which event? > The workqueue involves the receive handler. This should be faster than if a driver directly processes incoming bytes? > >> But how does the kernel API know how long such a block is? > > It's as long as the data that has arrived in that time. Which means the work queue handler have to decide if it is enough for a frame to decode and if not, wait a little until more arrives. Or you have to assemble chunks into a frame, i.e. copy data around. Both seems a waste of scarce cpu cycles in high-speed situations to me. > >> Usually there is a start byte/character, sometimes a length indicator, then >> payload data, >> some checksum and finally a stop byte/character. For NMEA it is $, no >> length, * and \r\n. >> For other serial protocols it might be AT, no length, and \r. Or something >> different. >> HCI seems to use 2 byte op-code or 1 byte event code and 1 byte parameter >> length. > > It doesn't look for any kind of protocol block headers. Which might become the pitfall of the design because as I have described it is an essential part of processing UART based protocols. You seem to focus on efficiently buffering only but not about efficiently processing the queued data. > The routine > invoked by the work queue does any frame recovery. > >> So I would even conclude that you usually can't even use DMA based UART >> receive >> processing for arbitrary and not well-defined protocols. Or have to assume >> that the > > We do, today for bluetooth and other protocols just fine I think it works (even with user-space HCI daemon) because bluetooth HCI is slow (<300kByte/s). > - it's all about > data flows not about framing in the protocol sense. Yes, but you should also take framing into account for a solution that helps to implement UART slave devices. That is my concern. BR, Nikolaus
Re: [RFC PATCH 0/3] UART slave device bus
> Am 21.08.2016 um 19:09 schrieb One Thousand Gnomes > : > >> Let me ask a question about your centralized and pre-cooked buffering >> approach. >> >> As far as I see, even then the kernel API must notify the driver at the >> right moment >> that a new block has arrived. Right? > > The low level driver queues words (data byte, flag byte) > The buffer processing workqueue picks those bytes from the queue and > atomically empties the queue When and how fast is the work queue scheduled? And by which event? > The workqueue involves the receive handler. This should be faster than if a driver directly processes incoming bytes? > >> But how does the kernel API know how long such a block is? > > It's as long as the data that has arrived in that time. Which means the work queue handler have to decide if it is enough for a frame to decode and if not, wait a little until more arrives. Or you have to assemble chunks into a frame, i.e. copy data around. Both seems a waste of scarce cpu cycles in high-speed situations to me. > >> Usually there is a start byte/character, sometimes a length indicator, then >> payload data, >> some checksum and finally a stop byte/character. For NMEA it is $, no >> length, * and \r\n. >> For other serial protocols it might be AT, no length, and \r. Or something >> different. >> HCI seems to use 2 byte op-code or 1 byte event code and 1 byte parameter >> length. > > It doesn't look for any kind of protocol block headers. Which might become the pitfall of the design because as I have described it is an essential part of processing UART based protocols. You seem to focus on efficiently buffering only but not about efficiently processing the queued data. > The routine > invoked by the work queue does any frame recovery. > >> So I would even conclude that you usually can't even use DMA based UART >> receive >> processing for arbitrary and not well-defined protocols. Or have to assume >> that the > > We do, today for bluetooth and other protocols just fine I think it works (even with user-space HCI daemon) because bluetooth HCI is slow (<300kByte/s). > - it's all about > data flows not about framing in the protocol sense. Yes, but you should also take framing into account for a solution that helps to implement UART slave devices. That is my concern. BR, Nikolaus
Re: [RFC PATCH 0/3] UART slave device bus
> Let me ask a question about your centralized and pre-cooked buffering > approach. > > As far as I see, even then the kernel API must notify the driver at the right > moment > that a new block has arrived. Right? The low level driver queues words (data byte, flag byte) The buffer processing workqueue picks those bytes from the queue and atomically empties the queue The workqueue involves the receive handler. > But how does the kernel API know how long such a block is? It's as long as the data that has arrived in that time. > Usually there is a start byte/character, sometimes a length indicator, then > payload data, > some checksum and finally a stop byte/character. For NMEA it is $, no length, > * and \r\n. > For other serial protocols it might be AT, no length, and \r. Or something > different. > HCI seems to use 2 byte op-code or 1 byte event code and 1 byte parameter > length. It doesn't look for any kind of protocol block headers. The routine invoked by the work queue does any frame recovery. > So I would even conclude that you usually can't even use DMA based UART > receive > processing for arbitrary and not well-defined protocols. Or have to assume > that the We do, today for bluetooth and other protocols just fine - it's all about data flows not about framing in the protocol sense. Alan
Re: [RFC PATCH 0/3] UART slave device bus
> Let me ask a question about your centralized and pre-cooked buffering > approach. > > As far as I see, even then the kernel API must notify the driver at the right > moment > that a new block has arrived. Right? The low level driver queues words (data byte, flag byte) The buffer processing workqueue picks those bytes from the queue and atomically empties the queue The workqueue involves the receive handler. > But how does the kernel API know how long such a block is? It's as long as the data that has arrived in that time. > Usually there is a start byte/character, sometimes a length indicator, then > payload data, > some checksum and finally a stop byte/character. For NMEA it is $, no length, > * and \r\n. > For other serial protocols it might be AT, no length, and \r. Or something > different. > HCI seems to use 2 byte op-code or 1 byte event code and 1 byte parameter > length. It doesn't look for any kind of protocol block headers. The routine invoked by the work queue does any frame recovery. > So I would even conclude that you usually can't even use DMA based UART > receive > processing for arbitrary and not well-defined protocols. Or have to assume > that the We do, today for bluetooth and other protocols just fine - it's all about data flows not about framing in the protocol sense. Alan
Re: [RFC PATCH 0/3] UART slave device bus
> Am 20.08.2016 um 15:34 schrieb One Thousand Gnomes >: >> What it is not about are UART/RS232 converters connected through USB or >> virtual >> serial ports created for WWAN modems (e.g. /dev/ttyACM, /dev/ttyHSO). Or BT >> devices >> connected through USB (even if they also run HCI protocol). > > It actually has to be about both because you will find the exact same > device wired via USB SSIC/HSIC to a USB UART or via a classic UART. Not is > it just about embedded boards. Not necessarily. We often have two interface options for exactly the sam sensor chips. They can be connected either through SPI or I2C. Which means that there is a core driver for the chip and two different transport glue components (see e.g. iio/accel/bmc150). This does not require I2C to be able to handle SPI or vice versa or provide a common API. And most Bluetooth devices I know have either UART or a direct USB interface. So in the USB case there is no need to connect it through some USB-UART bridge and treat it as an UART at all. BR, Nikolaus
Re: [RFC PATCH 0/3] UART slave device bus
> Am 20.08.2016 um 15:22 schrieb One Thousand Gnomes >: > > On Fri, 19 Aug 2016 19:42:37 +0200 > "H. Nikolaus Schaller" wrote: > >>> Am 19.08.2016 um 13:06 schrieb One Thousand Gnomes >>> : >>> If possible, please do a callback for every character that arrives. And not only if the rx buffer becomes full, to give the slave driver a chance to trigger actions almost immediately after every character. This probably runs in interrupt context and can happen often. >>> >>> We don't realistically have the clock cycles to do that on a low end >>> embedded processor handling high speed I/O. >> >> well, if we have a low end embedded processor and high-speed I/O, then >> buffering the data before processing doesn't help either since processing >> still will eat up clock cycles. > > Of course it helps. You are out of the IRQ handler within the 9 serial > clocks, so you can take another interrupt and grab the next byte. You > will also get benefits from processing the bytes further in blocks, if there are benefits from processing blocks. That depends on the specific protocol. My proposal can still check and then place byte by byte in a buffer and almost immediately return from interrupt. Until a block is completed and then trigger processing outside of the interrupt context. > and if you get too far behind you'll make the flow control limit. > > You've also usually got multiple cores these days - although not on the > very low end quite often. Indeed. But low-end rarely has really high-speed requirements and then should also run Linux. If it goes to performance limits, probably some assembler code will be used. And UART is inherently slow compared to SPI or USB or Ethernet. > >> The question is if this is needed at all. If we have a bluetooth stack with >> HCI the >> fastest UART interface I am aware of is running at 3 Mbit/s. 10 bits incl. >> framing >> means 300kByte/s equiv. 3µs per byte to process. Should be enough to decide >> if the byte should go to a buffer or not, check checksums, or discard and >> move >> the protocol engine to a different state. This is what I assume would be >> done in >> a callback. No processing needing some ms per frame. > > That depends on the processor - remember people run Linux on low end CPUs > including those embedded in an FPGA not just high end PC and ARM class > devices. > > The more important question is - purely for the receive side of things - > is a callback which guarantees to be called "soon" after the bytes arrive > sufficient. > > If it is then almost no work is needed on the receive side to allow pure > kernel code to manage recevied data directly because the current > buffering support throughout the receive side is completely capable of > providing those services without a tty structure, and to anything which > can have a tty attached. Let me ask a question about your centralized and pre-cooked buffering approach. As far as I see, even then the kernel API must notify the driver at the right moment that a new block has arrived. Right? But how does the kernel API know how long such a block is? Usually there is a start byte/character, sometimes a length indicator, then payload data, some checksum and finally a stop byte/character. For NMEA it is $, no length, * and \r\n. For other serial protocols it might be AT, no length, and \r. Or something different. HCI seems to use 2 byte op-code or 1 byte event code and 1 byte parameter length. So this means each protocol has a different block format. How can centralized solution manage such differently formatted blocks? IMHO it can't without help from the device specific slave device driver. Which must therefore be able to see every byte to decide into which category it goes. Which brings us back to the every-byte-interrupt-context callback. This is different from well formatted protocols like SPI or I2C or Ethernet etc. where the controller decodes the frame boundaries and DMA can store the payload data and an interrupt occurs for every received block. So I would even conclude that you usually can't even use DMA based UART receive processing for arbitrary and not well-defined protocols. Or have to assume that the protocol is 100% request-response based and a timeout can tell that no more data will be received - until a new request has been sent. > > Doesn't solve transmit or configuration but it's one step that needs no > additional real work and re-invention. > > Alan BR, Nikolaus
Re: [RFC PATCH 0/3] UART slave device bus
> Am 20.08.2016 um 15:34 schrieb One Thousand Gnomes > : >> What it is not about are UART/RS232 converters connected through USB or >> virtual >> serial ports created for WWAN modems (e.g. /dev/ttyACM, /dev/ttyHSO). Or BT >> devices >> connected through USB (even if they also run HCI protocol). > > It actually has to be about both because you will find the exact same > device wired via USB SSIC/HSIC to a USB UART or via a classic UART. Not is > it just about embedded boards. Not necessarily. We often have two interface options for exactly the sam sensor chips. They can be connected either through SPI or I2C. Which means that there is a core driver for the chip and two different transport glue components (see e.g. iio/accel/bmc150). This does not require I2C to be able to handle SPI or vice versa or provide a common API. And most Bluetooth devices I know have either UART or a direct USB interface. So in the USB case there is no need to connect it through some USB-UART bridge and treat it as an UART at all. BR, Nikolaus
Re: [RFC PATCH 0/3] UART slave device bus
> Am 20.08.2016 um 15:22 schrieb One Thousand Gnomes > : > > On Fri, 19 Aug 2016 19:42:37 +0200 > "H. Nikolaus Schaller" wrote: > >>> Am 19.08.2016 um 13:06 schrieb One Thousand Gnomes >>> : >>> If possible, please do a callback for every character that arrives. And not only if the rx buffer becomes full, to give the slave driver a chance to trigger actions almost immediately after every character. This probably runs in interrupt context and can happen often. >>> >>> We don't realistically have the clock cycles to do that on a low end >>> embedded processor handling high speed I/O. >> >> well, if we have a low end embedded processor and high-speed I/O, then >> buffering the data before processing doesn't help either since processing >> still will eat up clock cycles. > > Of course it helps. You are out of the IRQ handler within the 9 serial > clocks, so you can take another interrupt and grab the next byte. You > will also get benefits from processing the bytes further in blocks, if there are benefits from processing blocks. That depends on the specific protocol. My proposal can still check and then place byte by byte in a buffer and almost immediately return from interrupt. Until a block is completed and then trigger processing outside of the interrupt context. > and if you get too far behind you'll make the flow control limit. > > You've also usually got multiple cores these days - although not on the > very low end quite often. Indeed. But low-end rarely has really high-speed requirements and then should also run Linux. If it goes to performance limits, probably some assembler code will be used. And UART is inherently slow compared to SPI or USB or Ethernet. > >> The question is if this is needed at all. If we have a bluetooth stack with >> HCI the >> fastest UART interface I am aware of is running at 3 Mbit/s. 10 bits incl. >> framing >> means 300kByte/s equiv. 3µs per byte to process. Should be enough to decide >> if the byte should go to a buffer or not, check checksums, or discard and >> move >> the protocol engine to a different state. This is what I assume would be >> done in >> a callback. No processing needing some ms per frame. > > That depends on the processor - remember people run Linux on low end CPUs > including those embedded in an FPGA not just high end PC and ARM class > devices. > > The more important question is - purely for the receive side of things - > is a callback which guarantees to be called "soon" after the bytes arrive > sufficient. > > If it is then almost no work is needed on the receive side to allow pure > kernel code to manage recevied data directly because the current > buffering support throughout the receive side is completely capable of > providing those services without a tty structure, and to anything which > can have a tty attached. Let me ask a question about your centralized and pre-cooked buffering approach. As far as I see, even then the kernel API must notify the driver at the right moment that a new block has arrived. Right? But how does the kernel API know how long such a block is? Usually there is a start byte/character, sometimes a length indicator, then payload data, some checksum and finally a stop byte/character. For NMEA it is $, no length, * and \r\n. For other serial protocols it might be AT, no length, and \r. Or something different. HCI seems to use 2 byte op-code or 1 byte event code and 1 byte parameter length. So this means each protocol has a different block format. How can centralized solution manage such differently formatted blocks? IMHO it can't without help from the device specific slave device driver. Which must therefore be able to see every byte to decide into which category it goes. Which brings us back to the every-byte-interrupt-context callback. This is different from well formatted protocols like SPI or I2C or Ethernet etc. where the controller decodes the frame boundaries and DMA can store the payload data and an interrupt occurs for every received block. So I would even conclude that you usually can't even use DMA based UART receive processing for arbitrary and not well-defined protocols. Or have to assume that the protocol is 100% request-response based and a timeout can tell that no more data will be received - until a new request has been sent. > > Doesn't solve transmit or configuration but it's one step that needs no > additional real work and re-invention. > > Alan BR, Nikolaus
Re: [RFC PATCH 0/3] UART slave device bus
> A single one is already difficult... And some scenarios need to shield the > UART > from user space (currently there is always one /dev/tty per UART - unless the > UART is completely disabled). That bit is already covered and one or two devices support this because they have things like 3 serial ports but one cannot be used if some other feature is enabled. You simply keep a private counter and return -EBUSY in the port->activate() method if needed. That is sufficient to share a UART with the tty layer when you have a contended resource, but not to borrow the UART and re-use the stack which is what is needed in this case. (You can even steal a UART this way by doing a hangup on it and then once it drops out of use taking it over and ensuring the EBUSY behaviour) > > Some ideas where it might be needed: > * bluetooth HCI over UART > * a weird GPS device whose power state can only reliably be detected by > monitoring data activity > * other chips (microcontrollers) connected through UART - similar to I2C > slave devices > * it potentially could help to better implement IrDA (although that is mostly > legacy) > > What it is not about are UART/RS232 converters connected through USB or > virtual > serial ports created for WWAN modems (e.g. /dev/ttyACM, /dev/ttyHSO). Or BT > devices > connected through USB (even if they also run HCI protocol). It actually has to be about both because you will find the exact same device wired via USB SSIC/HSIC to a USB UART or via a classic UART. Not is it just about embedded boards. A current PC class device will usually have bluetooth connected via a UART where both components are on board. The same for GPS (or more accurately location services as it's usually more than just a GPS nowdays). There may also be onboard WWAN modems and other widgets wired this way. In the PC case the power relationship and connectivity is usually described via ACPI and that often means the kernel simply doesn't know how to manage the power states besides telling the modem, GPS. etc to turn itself on and off via normal ACPI power descriptions. Those may well call OpRegion handlers so it's all abstracted nicely and generic, but rather more invisible to the OS than DT describing pmic and/or gpio setings for the device. Todays low end Intel x86 PC has multiple DMA accelerated low power 16x50 compatible UARTS on die along with multiple channels of I2C and SPI. Things like Android and PC tablet devices with sensors have pretty much converged the old divide between a desktop/laptop/tablet PC and an 'embedded' board. Alan
Re: [RFC PATCH 0/3] UART slave device bus
> A single one is already difficult... And some scenarios need to shield the > UART > from user space (currently there is always one /dev/tty per UART - unless the > UART is completely disabled). That bit is already covered and one or two devices support this because they have things like 3 serial ports but one cannot be used if some other feature is enabled. You simply keep a private counter and return -EBUSY in the port->activate() method if needed. That is sufficient to share a UART with the tty layer when you have a contended resource, but not to borrow the UART and re-use the stack which is what is needed in this case. (You can even steal a UART this way by doing a hangup on it and then once it drops out of use taking it over and ensuring the EBUSY behaviour) > > Some ideas where it might be needed: > * bluetooth HCI over UART > * a weird GPS device whose power state can only reliably be detected by > monitoring data activity > * other chips (microcontrollers) connected through UART - similar to I2C > slave devices > * it potentially could help to better implement IrDA (although that is mostly > legacy) > > What it is not about are UART/RS232 converters connected through USB or > virtual > serial ports created for WWAN modems (e.g. /dev/ttyACM, /dev/ttyHSO). Or BT > devices > connected through USB (even if they also run HCI protocol). It actually has to be about both because you will find the exact same device wired via USB SSIC/HSIC to a USB UART or via a classic UART. Not is it just about embedded boards. A current PC class device will usually have bluetooth connected via a UART where both components are on board. The same for GPS (or more accurately location services as it's usually more than just a GPS nowdays). There may also be onboard WWAN modems and other widgets wired this way. In the PC case the power relationship and connectivity is usually described via ACPI and that often means the kernel simply doesn't know how to manage the power states besides telling the modem, GPS. etc to turn itself on and off via normal ACPI power descriptions. Those may well call OpRegion handlers so it's all abstracted nicely and generic, but rather more invisible to the OS than DT describing pmic and/or gpio setings for the device. Todays low end Intel x86 PC has multiple DMA accelerated low power 16x50 compatible UARTS on die along with multiple channels of I2C and SPI. Things like Android and PC tablet devices with sensors have pretty much converged the old divide between a desktop/laptop/tablet PC and an 'embedded' board. Alan
Re: [RFC PATCH 0/3] UART slave device bus
On Fri, 19 Aug 2016 19:42:37 +0200 "H. Nikolaus Schaller"wrote: > > Am 19.08.2016 um 13:06 schrieb One Thousand Gnomes > > : > > > >> If possible, please do a callback for every character that arrives. > >> And not only if the rx buffer becomes full, to give the slave driver > >> a chance to trigger actions almost immediately after every character. > >> This probably runs in interrupt context and can happen often. > > > > We don't realistically have the clock cycles to do that on a low end > > embedded processor handling high speed I/O. > > well, if we have a low end embedded processor and high-speed I/O, then > buffering the data before processing doesn't help either since processing > still will eat up clock cycles. Of course it helps. You are out of the IRQ handler within the 9 serial clocks, so you can take another interrupt and grab the next byte. You will also get benefits from processing the bytes further in blocks, and if you get too far behind you'll make the flow control limit. You've also usually got multiple cores these days - although not on the very low end quite often. > The question is if this is needed at all. If we have a bluetooth stack with > HCI the > fastest UART interface I am aware of is running at 3 Mbit/s. 10 bits incl. > framing > means 300kByte/s equiv. 3µs per byte to process. Should be enough to decide > if the byte should go to a buffer or not, check checksums, or discard and move > the protocol engine to a different state. This is what I assume would be done > in > a callback. No processing needing some ms per frame. That depends on the processor - remember people run Linux on low end CPUs including those embedded in an FPGA not just high end PC and ARM class devices. The more important question is - purely for the receive side of things - is a callback which guarantees to be called "soon" after the bytes arrive sufficient. If it is then almost no work is needed on the receive side to allow pure kernel code to manage recevied data directly because the current buffering support throughout the receive side is completely capable of providing those services without a tty structure, and to anything which can have a tty attached. Doesn't solve transmit or configuration but it's one step that needs no additional real work and re-invention. Alan
Re: [RFC PATCH 0/3] UART slave device bus
On Fri, 19 Aug 2016 19:42:37 +0200 "H. Nikolaus Schaller" wrote: > > Am 19.08.2016 um 13:06 schrieb One Thousand Gnomes > > : > > > >> If possible, please do a callback for every character that arrives. > >> And not only if the rx buffer becomes full, to give the slave driver > >> a chance to trigger actions almost immediately after every character. > >> This probably runs in interrupt context and can happen often. > > > > We don't realistically have the clock cycles to do that on a low end > > embedded processor handling high speed I/O. > > well, if we have a low end embedded processor and high-speed I/O, then > buffering the data before processing doesn't help either since processing > still will eat up clock cycles. Of course it helps. You are out of the IRQ handler within the 9 serial clocks, so you can take another interrupt and grab the next byte. You will also get benefits from processing the bytes further in blocks, and if you get too far behind you'll make the flow control limit. You've also usually got multiple cores these days - although not on the very low end quite often. > The question is if this is needed at all. If we have a bluetooth stack with > HCI the > fastest UART interface I am aware of is running at 3 Mbit/s. 10 bits incl. > framing > means 300kByte/s equiv. 3µs per byte to process. Should be enough to decide > if the byte should go to a buffer or not, check checksums, or discard and move > the protocol engine to a different state. This is what I assume would be done > in > a callback. No processing needing some ms per frame. That depends on the processor - remember people run Linux on low end CPUs including those embedded in an FPGA not just high end PC and ARM class devices. The more important question is - purely for the receive side of things - is a callback which guarantees to be called "soon" after the bytes arrive sufficient. If it is then almost no work is needed on the receive side to allow pure kernel code to manage recevied data directly because the current buffering support throughout the receive side is completely capable of providing those services without a tty structure, and to anything which can have a tty attached. Doesn't solve transmit or configuration but it's one step that needs no additional real work and re-invention. Alan
Re: [RFC PATCH 0/3] UART slave device bus
Am 19.08.2016 um 19:50 schrieb H. Nikolaus Schaller: > Hi, > >> Am 19.08.2016 um 09:49 schrieb Oleksij Rempel: >> >> Hallo Nikolaus, >> >> do i understand it correctly. This driver is to make kind of interchip >> communication and represent uart as a bus to allow use this bus from >> multiple kernel driver or expose it to user space? > > The idea for UART slave devices is to handle devices connected on an > embedded board to an UART port in kernel. Currently most such devices > are just passed through to some /dev/tty and handled by user-space daemons. > > So it is not necessarily about multiple kernel drivers to use the same UART, > although > that could also be required. > > A single one is already difficult... And some scenarios need to shield the > UART > from user space (currently there is always one /dev/tty per UART - unless the > UART is completely disabled). > > Some ideas where it might be needed: > * bluetooth HCI over UART > * a weird GPS device whose power state can only reliably be detected by > monitoring data activity > * other chips (microcontrollers) connected through UART - similar to I2C > slave devices > * it potentially could help to better implement IrDA (although that is mostly > legacy) > > What it is not about are UART/RS232 converters connected through USB or > virtual > serial ports created for WWAN modems (e.g. /dev/ttyACM, /dev/ttyHSO). Or BT > devices > connected through USB (even if they also run HCI protocol). Ah... ok. thank you for explanation. I was thinking it is going in similar direction with my project - use SPI for communication between two SoCs. It is based on SSI32 protocol from Bosch. In case it is going to this direction: Master implementation for linux side (tested on Banana Pi and iMX6): https://github.com/olerem/linux-2.6/commits/bpi-spi-variant2-2016.07.26.2 Slave implementation for stm32f303 (tested on f3 discovery): https://github.com/olerem/libopencm3-examples/commits/ssi32-2016.08.17.1 protocol decoder for logic analyzer (sigrok): https://github.com/olerem/libsigrokdecode/commits/ssi32_dec-2016.08.11 >> Correct? >> >> Am 19.08.2016 um 09:29 schrieb H. Nikolaus Schaller: >>> Hi, >>> Am 19.08.2016 um 07:21 schrieb Sebastian Reichel : Hi, On Thu, Aug 18, 2016 at 06:08:24PM -0500, Rob Herring wrote: > On Thu, Aug 18, 2016 at 3:29 PM, Sebastian Reichel > wrote: >> Thanks for going forward and implementing this. I also started, >> but was far from a functional state. >> >> On Wed, Aug 17, 2016 at 08:14:42PM -0500, Rob Herring wrote: >>> Currently, devices attached via a UART are not well supported in >>> the kernel. The problem is the device support is done in tty line >>> disciplines, various platform drivers to handle some sideband, and >>> in userspace with utilities such as hciattach. >>> >>> There have been several attempts to improve support, but they suffer >>> from >>> still being tied into the tty layer and/or abusing the platform bus. >>> This >>> is a prototype to show creating a proper UART bus for UART devices. It >>> is >>> tied into the serial core (really struct uart_port) below the tty layer >>> in order to use existing serial drivers. >>> >>> This is functional with minimal testing using the loopback driver and >>> pl011 (w/o DMA) UART under QEMU (modified to add a DT node for the slave >>> device). It still needs lots of work and polish. >>> >>> TODOs: >>> - Figure out the port locking. mutex plus spinlock plus refcounting? I'm >>> hoping all that complexity is from the tty layer and not needed here. >>> - Split out the controller for uart_ports into separate driver. Do we >>> see >>> a need for controller drivers that are not standard serial drivers? >>> - Implement/test the removal paths >>> - Fix the receive callbacks for more than character at a time (i.e. DMA) >>> - Need better receive buffering than just a simple circular buffer or >>> perhaps a different receive interface (e.g. direct to client buffer)? >>> - Test with other UART drivers >>> - Convert a real driver/line discipline over to UART bus. >>> >>> Before I spend more time on this, I'm looking mainly for feedback on the >>> general direction and structure (the interface with the existing serial >>> drivers in particular). >> >> I had a look at the uart_dev API: >> >> int uart_dev_config(struct uart_device *udev, int baud, int parity, int >> bits, int flow); >> int uart_dev_connect(struct uart_device *udev); >> >> The flow control configuration should be done separately. e.g.: >> uart_dev_flow_control(struct uart_device *udev, bool enable); > > No objection, but out of curiosity, why? Nokia's bluetooth uart protocol disables flow control during speed
Re: [RFC PATCH 0/3] UART slave device bus
Am 19.08.2016 um 19:50 schrieb H. Nikolaus Schaller: > Hi, > >> Am 19.08.2016 um 09:49 schrieb Oleksij Rempel : >> >> Hallo Nikolaus, >> >> do i understand it correctly. This driver is to make kind of interchip >> communication and represent uart as a bus to allow use this bus from >> multiple kernel driver or expose it to user space? > > The idea for UART slave devices is to handle devices connected on an > embedded board to an UART port in kernel. Currently most such devices > are just passed through to some /dev/tty and handled by user-space daemons. > > So it is not necessarily about multiple kernel drivers to use the same UART, > although > that could also be required. > > A single one is already difficult... And some scenarios need to shield the > UART > from user space (currently there is always one /dev/tty per UART - unless the > UART is completely disabled). > > Some ideas where it might be needed: > * bluetooth HCI over UART > * a weird GPS device whose power state can only reliably be detected by > monitoring data activity > * other chips (microcontrollers) connected through UART - similar to I2C > slave devices > * it potentially could help to better implement IrDA (although that is mostly > legacy) > > What it is not about are UART/RS232 converters connected through USB or > virtual > serial ports created for WWAN modems (e.g. /dev/ttyACM, /dev/ttyHSO). Or BT > devices > connected through USB (even if they also run HCI protocol). Ah... ok. thank you for explanation. I was thinking it is going in similar direction with my project - use SPI for communication between two SoCs. It is based on SSI32 protocol from Bosch. In case it is going to this direction: Master implementation for linux side (tested on Banana Pi and iMX6): https://github.com/olerem/linux-2.6/commits/bpi-spi-variant2-2016.07.26.2 Slave implementation for stm32f303 (tested on f3 discovery): https://github.com/olerem/libopencm3-examples/commits/ssi32-2016.08.17.1 protocol decoder for logic analyzer (sigrok): https://github.com/olerem/libsigrokdecode/commits/ssi32_dec-2016.08.11 >> Correct? >> >> Am 19.08.2016 um 09:29 schrieb H. Nikolaus Schaller: >>> Hi, >>> Am 19.08.2016 um 07:21 schrieb Sebastian Reichel : Hi, On Thu, Aug 18, 2016 at 06:08:24PM -0500, Rob Herring wrote: > On Thu, Aug 18, 2016 at 3:29 PM, Sebastian Reichel > wrote: >> Thanks for going forward and implementing this. I also started, >> but was far from a functional state. >> >> On Wed, Aug 17, 2016 at 08:14:42PM -0500, Rob Herring wrote: >>> Currently, devices attached via a UART are not well supported in >>> the kernel. The problem is the device support is done in tty line >>> disciplines, various platform drivers to handle some sideband, and >>> in userspace with utilities such as hciattach. >>> >>> There have been several attempts to improve support, but they suffer >>> from >>> still being tied into the tty layer and/or abusing the platform bus. >>> This >>> is a prototype to show creating a proper UART bus for UART devices. It >>> is >>> tied into the serial core (really struct uart_port) below the tty layer >>> in order to use existing serial drivers. >>> >>> This is functional with minimal testing using the loopback driver and >>> pl011 (w/o DMA) UART under QEMU (modified to add a DT node for the slave >>> device). It still needs lots of work and polish. >>> >>> TODOs: >>> - Figure out the port locking. mutex plus spinlock plus refcounting? I'm >>> hoping all that complexity is from the tty layer and not needed here. >>> - Split out the controller for uart_ports into separate driver. Do we >>> see >>> a need for controller drivers that are not standard serial drivers? >>> - Implement/test the removal paths >>> - Fix the receive callbacks for more than character at a time (i.e. DMA) >>> - Need better receive buffering than just a simple circular buffer or >>> perhaps a different receive interface (e.g. direct to client buffer)? >>> - Test with other UART drivers >>> - Convert a real driver/line discipline over to UART bus. >>> >>> Before I spend more time on this, I'm looking mainly for feedback on the >>> general direction and structure (the interface with the existing serial >>> drivers in particular). >> >> I had a look at the uart_dev API: >> >> int uart_dev_config(struct uart_device *udev, int baud, int parity, int >> bits, int flow); >> int uart_dev_connect(struct uart_device *udev); >> >> The flow control configuration should be done separately. e.g.: >> uart_dev_flow_control(struct uart_device *udev, bool enable); > > No objection, but out of curiosity, why? Nokia's bluetooth uart protocol disables flow control during speed changes. >> int uart_dev_tx(struct uart_device