On Wed, Mar 02, 2016 at 10:14:02PM -0300, Andre Guedes wrote:
Quoting Daniel Leung (2016-03-01 21:04:02)
The peripherals utilizing UART were required to register their ownThis is actually a nice improvement on the UART API since it moves the
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
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.
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.