Thread (18 messages) 18 messages, 5 authors, 2014-09-05

[RFC PATCH 1/1] drivers: introduce ARM SBSA generic UART driver

From: andre.przywara@arm.com (Andre Przywara)
Date: 2014-09-05 14:28:09
Also in: linux-serial, lkml


On 02/09/14 20:34, Arnd Bergmann wrote:
On Tuesday 02 September 2014 12:38:23 Rob Herring wrote:
quoted
On Tue, Sep 2, 2014 at 8:48 AM, Arnd Bergmann [off-list ref] wrote:
quoted
On Tuesday 02 September 2014 08:20:53 Rob Herring wrote:
quoted
quoted
quoted
This alone is not okay. There is no such implementation of hardware.
But the SBSA explicitly allows this. I don't know of any vendor who just
implements the subset, but I've been told that this has been asked for.
To use baudrate as an example, that must be configurable somehow
either with pl011 registers or in a vendor specific way. I suppose you
could do an actual implementation with all those things hardcoded in
the design, but that seems unlikely.
Why does the baudrate need to be configurable? I think it's completely
reasonable to specify a console port that has a fixed (as in the
OS must not care) rate, and that can be implemented either as a UART
with a programmable rate or as a set of registers that directly talks
to a remote system management device over whatever hardware protocol
they choose.
Sure. It is also completely reasonable that baudrate is configurable
and vendors can implement it however they choose since the SBSA does
not specify it. IIRC, the enabling and disabling bits are not
specified either.

Not having configurability is simply one variation on possible
implementations.
It's not obvious to me though that we are served better by a
pl011 driver that allows any possible subset of the features,
rather than having the existing driver for pl011, and a new driver
for the sbsa subset, which then won't allow any of the optional
features.

Yes, there is some duplication, but a driver for this kind of
dumb console port should be doable in very little code, at
least less than the proposed implementation.
I see your point, but as long as this means to introduce another serial
prefix I would rather avoid it.
As said in the other mail, I think the integration into PL011 does not
look too bad, so we can discuss again this when I post the code later.

Cheers,
Andre.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help