All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara@arm.com>
To: Russell King <linux@arm.linux.org.uk>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jslaby@suse.cz>
Cc: rob.herring@linaro.org, Arnd Bergmann <arnd@arndb.de>,
	linux-arm-kernel@lists.infradead.org,
	linux-serial@vger.kernel.org,
	Suravee Suthikulanit <suravee.suthikulpanit@amd.com>,
	Graeme Gregory <graeme.gregory@linaro.org>
Subject: Re: [RFC PATCH 00/10] drivers: PL011: add SBSA subset support
Date: Mon, 29 Sep 2014 16:27:33 +0100	[thread overview]
Message-ID: <54297A65.2020906@arm.com> (raw)
In-Reply-To: <1411129283-17219-1-git-send-email-andre.przywara@arm.com>

Hi,

(ping)

On 19/09/14 13:21, Andre Przywara wrote:
> (This version has still issues, but I'd like to have feedback on
> the general feasibility of this approach before wasting even more
> time on debugging).
> 
> The ARM Server Base System Architecture[1] document describes a
> generic UART which is a subset of the PL011 UART.
> It lacks DMA support, baud rate control and modem status line
> control, among other things.
> The idea is to move the UART initialization and setup into the
> firmware (which does this job today already) and let the kernel just
> use the UART for sending and receiving characters.
> 
> This patchset is an attempt to integrate support for this UART subset
> into the existing PL011 driver - basically by refactoring some
> functions and providing a new uart_ops structure for it. It also has
> a separate probe function to be not dependent on AMBA/PrimeCell.
> Beside the obvious effect of code sharing it has the advantage of not
> introducing another serial device prefix, so it can go with ttyAMA,
> which seems to be pretty common.

Is there any opinion on this patchset? Is this approach of integrating
the SBSA UART support in the PL011 driver a promising way?
Or do we look for a separate driver - which could not go with ttyAMA?

Grateful for any comments,
Andre

> 
> There is still one issue in bringing up the UART. On the PL011 we
> send a dummy character via the loopback facility with the FIFOs
> disabled to get things going, but both FIFO control and loopback are
> outside of the SBSA spec. I consider this loopback approach a kludge
> anyway, but am struggling to find a better way of fixing this due to
> my lack of understanding of the TTY/serial layer.
> If someone with more wisdom could enlighten me, I would be grateful.
> 
> 
> Patch 1/10 contains a bug fix which applies to the PL011 part also,
> it should be considered regardless of the rest of the series.
> Patch 2-7 refactor some PL011 functions by splitting them up into
> smaller pieces, so that most the code can be reused later by the SBSA
> part.
> Patch 8 and 9 introduce two new properties for the vendor structure,
> this is for SBSA functionality which cannot be controlled by
> separate uart_ops members only.
> Patch 10 then finally drops in the SBSA specific code, by providing
> a new uart_ops, vendor struct and probe function for it.
> 
> Please have a look and tell me whether this SBSA driver approach has
> any future.
> 
> Regards,
> Andre
> 
> Andre Przywara (10):
>   drivers: PL011: avoid potential unregister_driver call
>   drivers: PL011: refactor pl011_startup()
>   drivers: PL011: refactor pl011_shutdown()
>   drivers: PL011: refactor pl011_set_termios()
>   drivers: PL011: refactor pl011_probe()
>   drivers: PL011: replace UART_MIS reading with _RIS & _IMSC
>   drivers: PL011: move cts_event workaround into separate function
>   drivers: PL011: allow avoiding UART enabling/disabling
>   drivers: PL011: allow to supply fixed option string
>   drivers: PL011: add support for the ARM SBSA generic UART
> 
>  .../devicetree/bindings/serial/arm_sbsa_uart.txt   |    9 +
>  drivers/tty/serial/amba-pl011.c                    |  509 ++++++++++++++------
>  2 files changed, 380 insertions(+), 138 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt
> 

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 00/10] drivers: PL011: add SBSA subset support
Date: Mon, 29 Sep 2014 16:27:33 +0100	[thread overview]
Message-ID: <54297A65.2020906@arm.com> (raw)
In-Reply-To: <1411129283-17219-1-git-send-email-andre.przywara@arm.com>

Hi,

(ping)

On 19/09/14 13:21, Andre Przywara wrote:
> (This version has still issues, but I'd like to have feedback on
> the general feasibility of this approach before wasting even more
> time on debugging).
> 
> The ARM Server Base System Architecture[1] document describes a
> generic UART which is a subset of the PL011 UART.
> It lacks DMA support, baud rate control and modem status line
> control, among other things.
> The idea is to move the UART initialization and setup into the
> firmware (which does this job today already) and let the kernel just
> use the UART for sending and receiving characters.
> 
> This patchset is an attempt to integrate support for this UART subset
> into the existing PL011 driver - basically by refactoring some
> functions and providing a new uart_ops structure for it. It also has
> a separate probe function to be not dependent on AMBA/PrimeCell.
> Beside the obvious effect of code sharing it has the advantage of not
> introducing another serial device prefix, so it can go with ttyAMA,
> which seems to be pretty common.

Is there any opinion on this patchset? Is this approach of integrating
the SBSA UART support in the PL011 driver a promising way?
Or do we look for a separate driver - which could not go with ttyAMA?

Grateful for any comments,
Andre

> 
> There is still one issue in bringing up the UART. On the PL011 we
> send a dummy character via the loopback facility with the FIFOs
> disabled to get things going, but both FIFO control and loopback are
> outside of the SBSA spec. I consider this loopback approach a kludge
> anyway, but am struggling to find a better way of fixing this due to
> my lack of understanding of the TTY/serial layer.
> If someone with more wisdom could enlighten me, I would be grateful.
> 
> 
> Patch 1/10 contains a bug fix which applies to the PL011 part also,
> it should be considered regardless of the rest of the series.
> Patch 2-7 refactor some PL011 functions by splitting them up into
> smaller pieces, so that most the code can be reused later by the SBSA
> part.
> Patch 8 and 9 introduce two new properties for the vendor structure,
> this is for SBSA functionality which cannot be controlled by
> separate uart_ops members only.
> Patch 10 then finally drops in the SBSA specific code, by providing
> a new uart_ops, vendor struct and probe function for it.
> 
> Please have a look and tell me whether this SBSA driver approach has
> any future.
> 
> Regards,
> Andre
> 
> Andre Przywara (10):
>   drivers: PL011: avoid potential unregister_driver call
>   drivers: PL011: refactor pl011_startup()
>   drivers: PL011: refactor pl011_shutdown()
>   drivers: PL011: refactor pl011_set_termios()
>   drivers: PL011: refactor pl011_probe()
>   drivers: PL011: replace UART_MIS reading with _RIS & _IMSC
>   drivers: PL011: move cts_event workaround into separate function
>   drivers: PL011: allow avoiding UART enabling/disabling
>   drivers: PL011: allow to supply fixed option string
>   drivers: PL011: add support for the ARM SBSA generic UART
> 
>  .../devicetree/bindings/serial/arm_sbsa_uart.txt   |    9 +
>  drivers/tty/serial/amba-pl011.c                    |  509 ++++++++++++++------
>  2 files changed, 380 insertions(+), 138 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt
> 

  parent reply	other threads:[~2014-09-29 15:28 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-19 12:21 [RFC PATCH 00/10] drivers: PL011: add SBSA subset support Andre Przywara
2014-09-19 12:21 ` Andre Przywara
2014-09-19 12:21 ` [RFC PATCH 01/10] drivers: PL011: avoid potential unregister_driver call Andre Przywara
2014-09-19 12:21   ` Andre Przywara
2014-09-19 12:21 ` [RFC PATCH 02/10] drivers: PL011: refactor pl011_startup() Andre Przywara
2014-09-19 12:21   ` Andre Przywara
2014-09-19 12:21 ` [RFC PATCH 03/10] drivers: PL011: refactor pl011_shutdown() Andre Przywara
2014-09-19 12:21   ` Andre Przywara
2014-09-19 12:21 ` [RFC PATCH 04/10] drivers: PL011: refactor pl011_set_termios() Andre Przywara
2014-09-19 12:21   ` Andre Przywara
2014-09-19 12:21 ` [RFC PATCH 05/10] drivers: PL011: refactor pl011_probe() Andre Przywara
2014-09-19 12:21   ` Andre Przywara
2014-09-19 12:40   ` Russell King - ARM Linux
2014-09-19 12:40     ` Russell King - ARM Linux
2014-09-19 12:21 ` [RFC PATCH 06/10] drivers: PL011: replace UART_MIS reading with _RIS & _IMSC Andre Przywara
2014-09-19 12:21   ` Andre Przywara
2014-09-19 12:21 ` [RFC PATCH 07/10] drivers: PL011: move cts_event workaround into separate function Andre Przywara
2014-09-19 12:21   ` Andre Przywara
2014-09-19 12:21 ` [RFC PATCH 08/10] drivers: PL011: allow avoiding UART enabling/disabling Andre Przywara
2014-09-19 12:21   ` Andre Przywara
2014-09-19 12:21 ` [RFC PATCH 09/10] drivers: PL011: allow to supply fixed option string Andre Przywara
2014-09-19 12:21   ` Andre Przywara
2014-09-19 12:21 ` [RFC PATCH 10/10] drivers: PL011: add support for the ARM SBSA generic UART Andre Przywara
2014-09-19 12:21   ` Andre Przywara
2014-09-29 15:27 ` Andre Przywara [this message]
2014-09-29 15:27   ` [RFC PATCH 00/10] drivers: PL011: add SBSA subset support Andre Przywara
2014-09-30 10:11 ` Graeme Gregory
2014-09-30 10:11   ` Graeme Gregory

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=54297A65.2020906@arm.com \
    --to=andre.przywara@arm.com \
    --cc=arnd@arndb.de \
    --cc=graeme.gregory@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jslaby@suse.cz \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=rob.herring@linaro.org \
    --cc=suravee.suthikulpanit@amd.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.