All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara@linaro.org>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Bhupinder Thakur <bhupinder.thakur@linaro.org>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Julien Grall <julien.grall@arm.com>,
	Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 2/3 v3] xen: Add support for initializing 16550 UART using ACPI
Date: Fri, 24 Nov 2017 15:11:03 +0000	[thread overview]
Message-ID: <52648a98-b098-0f05-836d-b9cd4c0920e6@linaro.org> (raw)
In-Reply-To: <20171124135040.GD16160@localhost.localdomain>

Hi,

(answering to both Konrad and Bhupinder ...)

On 24/11/17 13:50, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 24, 2017 at 05:09:11PM +0530, Bhupinder Thakur wrote:
>> Currently, Xen supports only DT based initialization of 16550 UART.
>> This patch adds support for initializing 16550 UART using ACPI SPCR table.
> 
> Can you provide the link to the spec you are using. I am wondering
> if I am looking at some older one.
> 
>>
>> Signed-off-by: Bhupinder Thakur <bhupinder.thakur@linaro.org>
>> ---
>> Changes since v2:
>> - renamed UART_MAX_REG to UART_NUM_REGS
>> - aligned some assignment statements
>> - some coding style changes
>>
>> CC: Andrew Cooper <andrew.cooper3@citrix.com>
>> CC: George Dunlap <George.Dunlap@eu.citrix.com>
>> CC: Ian Jackson <ian.jackson@eu.citrix.com>
>> CC: Jan Beulich <jbeulich@suse.com>
>> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> CC: Stefano Stabellini <sstabellini@kernel.org>
>> CC: Tim Deegan <tim@xen.org>
>> CC: Wei Liu <wei.liu2@citrix.com>
>> CC: Julien Grall <julien.grall@arm.com>
>>
>>  xen/drivers/char/ns16550.c  | 67 +++++++++++++++++++++++++++++++++++++++++++++
>>  xen/include/xen/8250-uart.h |  1 +
>>  2 files changed, 68 insertions(+)
>>
>> diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
>> index c5dfc1e..af4712f 100644
>> --- a/xen/drivers/char/ns16550.c
>> +++ b/xen/drivers/char/ns16550.c
>> @@ -29,6 +29,10 @@
>>  #ifdef CONFIG_X86
>>  #include <asm/fixmap.h>
>>  #endif
>> +#ifdef CONFIG_ACPI
>> +#include <xen/acpi.h>
>> +#endif
>> +
>>  
>>  /*
>>   * Configure serial port with a string:
>> @@ -1565,6 +1569,69 @@ DT_DEVICE_START(ns16550, "NS16550 UART", DEVICE_SERIAL)
>>  DT_DEVICE_END
>>  
>>  #endif /* HAS_DEVICE_TREE */
>> +
>> +#if defined(CONFIG_ACPI) && defined(CONFIG_ARM)
> 
> I would remove the CONFIG_ARM as the spec says it is possible to use
> this on ARM _and_ x86 hardware.

I was thinking the same. Originally the SPCR was x86 only.

> But I guess you can't as ACPI_DEVICE_START is defined to be only
> on ARM?

We could move the #ifdef there.

>> +
>> +static int ns16550_init_acpi(struct ns16550 **puart)
>> +{
>> +    struct acpi_table_spcr *spcr;
>> +    int status;
> 
> hmm, not acpi_status ?
>> +    struct ns16550 *uart = &ns16550_com[0];
>> +
>> +    ns16550_init_common(uart);
> 
> I would move this below the error check below..
>> +
>> +    status = acpi_get_table(ACPI_SIG_SPCR, 0,
>> +                            (struct acpi_table_header **)&spcr);
>> +
>> +    if ( ACPI_FAILURE(status) )
>> +    {
>> +        printk("ns16550: Failed to get SPCR table\n");
>> +        return -EINVAL;
>> +    }
>> +
>> +    uart->baud      = BAUD_AUTO;
>> +    uart->data_bits = 8;
> 
> Are those two assumed from the ACPI spec?

I can't find a field for the number of data bits, so I assume it's
indeed fixed to 8.

> Wait a minute. The
> https://msdn.microsoft.com/en-us/library/windows/hardware/dn639132(v=vs.85).aspx
> has Baud Rate at Offset 58?

Yes, I see the same. We should use that table.
Just wondering what the Moonshot gives you in this table? Is it "7"?

>> +    uart->parity    = spcr->parity;

The Spec is a bit weird there, since it only specifies 0 as "No parity",
every other value is reserved.
Shall we check and bail out if !0 with an error message?

>> +    uart->stop_bits = spcr->stop_bits;

Again if you want to be strict you would need to check against the
specified values, which means only "1" is valid.

>> +    uart->io_base   = spcr->serial_port.address;

I think this needs to be checked against the address type, because we
assume 0 (MMIO) here for ARM, and I guess 1 (PIO) for x86?

If I understand the code correctly, we have some wild heuristics to
guess the address type at the moment?

#ifdef CONFIG_HAS_IOPORTS
    /* I/O ports are distinguished by their size (16 bits). */
    if ( uart->io_base >= 0x10000 )
#endif

I wonder if we should store this explicitly, since ACPI (and DT as well)
give us this information.

>> +    uart->irq       = spcr->interrupt;
> 
> You need to check if the 'Interrupt Type' field is set before
> you look at this?
> 
>> +    uart->reg_width = spcr->serial_port.bit_width / 8;

I am a bit confused about the SPCR field here. Shouldn't this be encoded
in the "Access Size" field instead?
"Register Bit Width: The size in bits of the given register. When
addressing a data structure, this field must be zero."
But I guess the Moonshot gives you 4 in here, but something else in
"Access Size"?

Cheers,
Andre.

>> +    uart->reg_shift = 0;
>> +    uart->io_size   = UART_NUM_REGS << uart->reg_shift;
>> +
>> +    irq_set_type(spcr->interrupt, spcr->interrupt_type);
> 
> Um, the spec has a whole bunch of other bits set in 'interrupt_type'?
> 
>> +
>> +    *puart = uart;
>> +
>> +    return 0;
>> +}
>> +
>> +static int __init ns16550_acpi_uart_init(const void *data)
>> +{
>> +    int ret;
>> +    struct ns16550 *uart;
>> +
>> +    ret = ns16550_init_acpi(&uart);
>> +    if ( ret )
>> +        return ret;
>> +
>> +    ns16550_vuart_init(uart);
>> +
>> +    ns16550_register_uart(uart);
>> +
>> +    return 0;
>> +}
>> +
>> +ACPI_DEVICE_START(ns16550c, "16550 COMPAT UART", DEVICE_SERIAL)
>> +        .class_type = ACPI_DBG2_16550_COMPATIBLE,
>> +        .init = ns16550_acpi_uart_init,
>> +ACPI_DEVICE_END
>> +ACPI_DEVICE_START(ns16550s, "16550 SUBSET UART", DEVICE_SERIAL)
>> +        .class_type = ACPI_DBG2_16550_SUBSET,
>> +        .init = ns16550_acpi_uart_init,
>> +ACPI_DEVICE_END
>> +
>> +#endif
>>  /*
>>   * Local variables:
>>   * mode: C
>> diff --git a/xen/include/xen/8250-uart.h b/xen/include/xen/8250-uart.h
>> index 5c3bac3..849a5c0 100644
>> --- a/xen/include/xen/8250-uart.h
>> +++ b/xen/include/xen/8250-uart.h
>> @@ -35,6 +35,7 @@
>>  #define UART_USR          0x1f    /* Status register (DW) */
>>  #define UART_DLL          0x00    /* divisor latch (ls) (DLAB=1) */
>>  #define UART_DLM          0x01    /* divisor latch (ms) (DLAB=1) */
>> +#define UART_NUM_REGS     (UART_USR + 1)
>>  
>>  /* Interrupt Enable Register */
>>  #define UART_IER_ERDAI    0x01    /* rx data recv'd       */
>> -- 
>> 2.7.4
>>
>>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2017-11-24 15:11 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-24 11:39 [PATCH 0/3 v3] xen: ACPI/SPCR based initialization of 8250 UART Bhupinder Thakur
2017-11-24 11:39 ` [PATCH 1/3 v3] xen: Refactor 16550 UART code Bhupinder Thakur
2017-11-24 13:37   ` Konrad Rzeszutek Wilk
2017-11-24 16:04   ` Julien Grall
2017-11-24 11:39 ` [PATCH 2/3 v3] xen: Add support for initializing 16550 UART using ACPI Bhupinder Thakur
2017-11-24 13:50   ` Konrad Rzeszutek Wilk
2017-11-24 15:11     ` Andre Przywara [this message]
2017-11-24 15:52       ` Julien Grall
2017-11-24 16:05   ` Julien Grall
2017-11-27 10:01   ` Jan Beulich
2017-11-24 11:39 ` [PATCH 3/3 v3] xen: Fix 16550 UART console for HP Moonshot (Aarch64) platform Bhupinder Thakur
2017-11-24 13:51   ` Konrad Rzeszutek Wilk
2017-11-27 10:06   ` Jan Beulich
2017-11-27 10:30     ` Julien Grall
2017-11-27 10:37       ` 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=52648a98-b098-0f05-836d-b9cd4c0920e6@linaro.org \
    --to=andre.przywara@linaro.org \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=bhupinder.thakur@linaro.org \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=julien.grall@arm.com \
    --cc=konrad.wilk@oracle.com \
    --cc=konrad@darnok.org \
    --cc=sstabellini@kernel.org \
    --cc=tim@xen.org \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /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.