On Wed, Mar 02, 2016 at 10:14:02PM -0300, Andre Guedes wrote:
Hi Daniel,
Quoting Daniel Leung (2016-03-01 21:04:02)
The peripherals utilizing UART were required to register their own ISR rountines. This means that all those peripherals drivers need to know which IRQ line is attached to a UART controller, and all the other config values required to register a ISR. This causes scalibility issue as every board and peripherals have to define those values.
Another reason for this patch is to support virtual serial ports. Virtual serial ports do not have physical interrupt lines to attach, and thus would not work.
This patch adds a simple callback mechanism, which calls a function when UART interrupts are triggered. The low level plumbing still needs to be done by the peripheral drivers, as these drivers may need to access low level capability of UART to function correctly. This simply moves the interrupt setup into the UART drivers themselves. By doing this, the peripheral drivers do not need to know all the config values to properly setup the interrupts and attaching the ISR. One drawback is that this adds to the interrupt latency.
This is actually a nice improvement on the UART API since it moves the burden of registering the ISR from the user layer to the driver layer, which is the right place, IMO.
Actually, the UART API is very low level when we compare it with other APIs such as SPI and I2C. For instance, the UART API exposes functions to manipulate the FIFOs and check for interrupt flags. Is there any plan to add higher level APIs such as "transmit the characters from this buffer and call this callback once the transmission finishes" or "read 10 characters into this buffer and call this callback once it is done"?
This is something I have thought about, but there is no concrete plan.
Is there anything particular you are looking for? Use cases would be a good start. This helps me to understand what needs to be done.
