On Fri, May 20, 2016 at 09:09:52PM +0000, Andy Falanga (afalanga) wrote: > Hello, > > I'm writing a driver for a UART that, as is currently intended, will not > use interrupts. Why not? Doesn't sound like a "real" UART to me, what type of hardware is this exactly? > Everything I've found online about the serial core, and using the many > functions such as uart_*(), all assume that the UART is interrupt > driven. I will agree that this is probably the way it should be but I > don't have visibility into these decisions presently. It doesn't use > interrupts and I've got to implement a method for polling. Again, why? > Is there something in the serial core that does this? Poll the hardware, no. That's up to you, to deal with your broken hardware by wasting CPU resources, and power. Watch out for the power, you just ensured that your CPU will never be able to go to sleep, a very bad idea for any system :( > I see the poll*() > functions listed in Documentation/serial/driver, but these seem to be > relating to a console. There isn't a console at play in this case. The > expected usage is through minicom, or something similar. > uart_update_timeout(port,cflag,baud) seems to be relating with the > serial core and not with the hardware. (Is this true?) Am I simply > going to have to instrument some sort of rudimentary polling through > kernel timers or kernel threads? Yup. But I would push back on the crazy person who designed such a system. Really, UARTS have been around for a _VERY_ long time, people know how to design them properly, don't make mistakes that were solved way over a quarter of a century ago. good luck! greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
