Hi Simon,
On Thu, 2018-02-22 at 09:17 -0700, Simon Glass wrote:
Hi,
On 21 February 2018 at 05:26, Alexey Brodkin Alexey.Brodkin@synopsys.com 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(-)
I think a separate driver might be better, unless we want to make the read/write interface go through regmap or similar?
But in case of ARC's AUX regs portmap won't help because those AUX regs are couldn't be mapped - that a completely different address space and we may only access them via dedicated instructions (LR vs LD and SR vs ST).
-Alexey