From: Andre Przywara <andre.przywara@arm.com>
To: Rob Herring <robherring2@gmail.com>, Arnd Bergmann <arnd@arndb.de>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Russell King <linux@arm.linux.org.uk>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
LKML <linux-kernel@vger.kernel.org>,
"linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>,
Jiri Slaby <jslaby@suse.cz>
Subject: Re: [RFC PATCH 1/1] drivers: introduce ARM SBSA generic UART driver
Date: Fri, 05 Sep 2014 15:37:18 +0100 [thread overview]
Message-ID: <5409CA9E.2060807@arm.com> (raw)
In-Reply-To: <CAL_JsqKGbSd5BymnFhT8KBjbBCPO8wsrHhG9Qn20c7mrrxTDDA@mail.gmail.com>
Hi Rob,
On 02/09/14 18:38, Rob Herring wrote:
> On Tue, Sep 2, 2014 at 8:48 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Tuesday 02 September 2014 08:20:53 Rob Herring wrote:
>>>>>
>>>>> 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.
But this would be a different driver for a different hardware then and
not covered by the SBSA version - so to some degree not our problem ;-)
I don't see how we could really cover this problem for every possibly
upcoming implementation.
If I got the spec correctly, then exposing the baudrate setting for SBSA
hardware is not meaningful in the sense of the spec.
If you want to go with a configurable UART complying to the spec, you'd
probably use a full featured PL011.
> IIRC, the enabling and disabling bits are not
> specified either.
Correct, also the FIFO is always on and the word format is fixed to 8n1.
Regards,
Andre.
>
> Not having configurability is simply one variation on possible implementations.
>
> Rob
>
WARNING: multiple messages have this Message-ID (diff)
From: andre.przywara@arm.com (Andre Przywara)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 1/1] drivers: introduce ARM SBSA generic UART driver
Date: Fri, 05 Sep 2014 15:37:18 +0100 [thread overview]
Message-ID: <5409CA9E.2060807@arm.com> (raw)
In-Reply-To: <CAL_JsqKGbSd5BymnFhT8KBjbBCPO8wsrHhG9Qn20c7mrrxTDDA@mail.gmail.com>
Hi Rob,
On 02/09/14 18:38, Rob Herring wrote:
> On Tue, Sep 2, 2014 at 8:48 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Tuesday 02 September 2014 08:20:53 Rob Herring wrote:
>>>>>
>>>>> 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.
But this would be a different driver for a different hardware then and
not covered by the SBSA version - so to some degree not our problem ;-)
I don't see how we could really cover this problem for every possibly
upcoming implementation.
If I got the spec correctly, then exposing the baudrate setting for SBSA
hardware is not meaningful in the sense of the spec.
If you want to go with a configurable UART complying to the spec, you'd
probably use a full featured PL011.
> IIRC, the enabling and disabling bits are not
> specified either.
Correct, also the FIFO is always on and the word format is fixed to 8n1.
Regards,
Andre.
>
> Not having configurability is simply one variation on possible implementations.
>
> Rob
>
next prev parent reply other threads:[~2014-09-05 14:38 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-29 16:13 [RFC PATCH 0/1] ARM SBSA UART driver Andre Przywara
2014-08-29 16:13 ` Andre Przywara
2014-08-29 16:13 ` [RFC PATCH 1/1] drivers: introduce ARM SBSA generic " Andre Przywara
2014-08-29 16:13 ` Andre Przywara
2014-08-29 18:59 ` Arnd Bergmann
2014-08-29 18:59 ` Arnd Bergmann
2014-08-29 23:10 ` Andre Przywara
2014-08-29 23:10 ` Andre Przywara
2014-09-02 19:51 ` Arnd Bergmann
2014-09-02 19:51 ` Arnd Bergmann
2014-09-05 14:11 ` Andre Przywara
2014-09-05 14:11 ` Andre Przywara
2014-09-05 14:11 ` Andre Przywara
2014-09-02 3:06 ` Rob Herring
2014-09-02 3:06 ` Rob Herring
2014-09-02 10:06 ` Andre Przywara
2014-09-02 10:06 ` Andre Przywara
2014-09-02 10:46 ` Mark Rutland
2014-09-02 10:46 ` Mark Rutland
2014-09-02 10:46 ` Mark Rutland
2014-09-02 13:20 ` Rob Herring
2014-09-02 13:20 ` Rob Herring
2014-09-02 13:48 ` Arnd Bergmann
2014-09-02 13:48 ` Arnd Bergmann
2014-09-02 17:38 ` Rob Herring
2014-09-02 17:38 ` Rob Herring
2014-09-02 19:34 ` Arnd Bergmann
2014-09-02 19:34 ` Arnd Bergmann
2014-09-05 14:27 ` Andre Przywara
2014-09-05 14:27 ` Andre Przywara
2014-09-05 14:37 ` Andre Przywara [this message]
2014-09-05 14:37 ` Andre Przywara
2014-09-02 18:19 ` Peter Hurley
2014-09-02 18:19 ` Peter Hurley
2014-09-05 14:44 ` Andre Przywara
2014-09-05 14:44 ` Andre Przywara
2014-09-05 15:24 ` Peter Hurley
2014-09-05 15:24 ` Peter Hurley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5409CA9E.2060807@arm.com \
--to=andre.przywara@arm.com \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=jslaby@suse.cz \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=robherring2@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.