All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC] ns16550: Add support for AUX regs usage on some ARC SoCs
Date: Thu, 22 Feb 2018 10:43:31 -0500	[thread overview]
Message-ID: <20180222154331.GT4311@bill-the-cat> (raw)
In-Reply-To: <20180221122605.8128-1-abrodkin@synopsys.com>

On Wed, Feb 21, 2018 at 03:26:05PM +0300, Alexey Brodkin wrote:
> Synopsys Data Fusion subsystem (DFSS) is targeted to deeply built-in
> use-cases and so to save some silicon area decision was made to
> escape usage of any busses and use instead directly wired to CPU
> peripherals. And one of those is DW APB UART.
> 
> Later DFSS became a part of larger and more complicated SoCs with
> some other peripherals connected via common buses but default UART
> is still used via ARC core's auxulary registers which are not mapped
> to "normal" address space and we use very special instructions to access
> them, thus we cannot simply reuse whatever accessor we have in 16550
> UART as of now.
> 
> Also we cannot just switch inb()/outb() to access ARC AUX regs always
> for DFSS because other peripherals have normal memory-mapped control
> registers and we need to use normal accessors for them.
> 
> Frankly I don't like a lot what I did here but otherwise if I create
> a special driver for this I'll need to reimplement
> ns16550_serial_ops.putc()/getc() which will be pure copy-paseted from
> ns16550.c because the only difference is only in
> ns16550_{read|write}b().
> 
> As mentioned above we cannot remap those auxiliary registers to
> normal memory address-space and thus we have to use very special
> accessors write_aux_reg()/read_aux_reg() that directly use special
> CPU intructions (namely LR/SR) for dealing with ARC AUX regs.
> 
> Also note here I just use a check for a particular SoC being selected
> (CONFIG_ARCH_DFSS will be introduced shortly) but that is done just for
> simplicity, otherwise it might be a slecial Kconfig option for NS16550
> or anything else.
> 
> I'd like to know what people think about possible colutions here.
> And as always any comments are much appreciated!
> 
> Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Tom Rini <trini@konsulko.com>
> Cc: Stefan Roese <sr@denx.de>
> ---
>  drivers/serial/ns16550.c | 11 +++++++++--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
> index 6f9ce689cfff..75f342f337f1 100644
> --- a/drivers/serial/ns16550.c
> +++ b/drivers/serial/ns16550.c
> @@ -13,6 +13,9 @@
>  #include <watchdog.h>
>  #include <linux/types.h>
>  #include <asm/io.h>
> +#ifdef CONFIG_ARCH_DFSS
> +#include <asm/arcregs.h>
> +#endif
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> @@ -53,7 +56,9 @@ DECLARE_GLOBAL_DATA_PTR;
>  
>  static inline void serial_out_shift(void *addr, int shift, int value)
>  {
> -#ifdef CONFIG_SYS_NS16550_PORT_MAPPED
> +#ifdef CONFIG_ARCH_DFSS
> +	write_aux_reg((int)addr, value);
> +#elif defined(CONFIG_SYS_NS16550_PORT_MAPPED)
>  	outb(value, (ulong)addr);
>  #elif defined(CONFIG_SYS_NS16550_MEM32) && !defined(CONFIG_SYS_BIG_ENDIAN)
>  	out_le32(addr, value);
> @@ -70,7 +75,9 @@ static inline void serial_out_shift(void *addr, int shift, int value)
>  
>  static inline int serial_in_shift(void *addr, int shift)
>  {
> -#ifdef CONFIG_SYS_NS16550_PORT_MAPPED
> +#ifdef CONFIG_ARCH_DFSS
> +	return read_aux_reg((int)addr);
> +#elif defined(CONFIG_SYS_NS16550_PORT_MAPPED)
>  	return inb((ulong)addr);
>  #elif defined(CONFIG_SYS_NS16550_MEM32) && !defined(CONFIG_SYS_BIG_ENDIAN)
>  	return in_le32(addr);

As always, thanks for the detailed explanation.  Yes, I think that of
the options, putting the details in read/write_aux_reg (and please make
sure read/write_aux_reg have a good function comment too) is the best
choice.  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180222/c738c4cb/attachment.sig>

  reply	other threads:[~2018-02-22 15:43 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-21 12:26 [U-Boot] [RFC] ns16550: Add support for AUX regs usage on some ARC SoCs Alexey Brodkin
2018-02-22 15:43 ` Tom Rini [this message]
2018-02-22 16:07   ` Alexey Brodkin
2018-02-22 16:20     ` Tom Rini
2018-02-22 16:17 ` Simon Glass
2018-02-22 16:23   ` Alexey Brodkin
2018-02-22 17:29     ` Simon Glass
2018-02-23 18:08       ` Alexey Brodkin
2018-02-23 20:59         ` Simon Glass
2018-03-02 21:51       ` Alexey Brodkin
2018-03-08 20:27         ` Simon Glass

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=20180222154331.GT4311@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /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.