All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
To: Russell King <rmk@arm.linux.org.uk>
Cc: Pantelis Antoniou <pantelis@embeddedalley.com>,
	Linux-MIPS <linux-mips@linux-mips.org>
Subject: Re: [PATCH] AMD Alchemy: claim UART memory range
Date: Mon, 04 Sep 2006 21:28:58 +0400	[thread overview]
Message-ID: <44FC625A.5050005@ru.mvista.com> (raw)
In-Reply-To: <20060830080157.GA17632@flint.arm.linux.org.uk>

Hello.

Russell King wrote:

>>>  BTW, can anybody enlighten me why 8250_au1x00.c came into being  
>>>at all?
>>>Its only function seems to register the UART platform devices, the  
>>>thing
>>>that is usually done in the board setup code, i. e. I'd rather have  
>>>it in arch/mips/au1000/common/platform.c (however, 8250.c should  
>>>have been able to filter out ports with UPIO_AU in case  
>>>CONFIG_SERIAL_8250_AU1X00 undefined)...

>>Seemed like a good idea at the moment to follow the already existing  
>>convention.

> Already existing convention is as per Sergei's mail actually - to have the
> platform device registration in arch/*.  The others which you thought were
> convention there (accent, boca, fourport, hub6, mca) are all for add-in
> cards and aren't architecture specific.

> Hence, they can't live in arch/*.

> So yes, 8250_au1x00.c breaks the established convention because it isn't
> an add-in card.

    Thanks for clarification.

    Now another question to Pantelis: IIUC, the Alchemy UART platform devices 
have UPF_SKIP_TEST set because of the Alchemy docs claiming that UARTs other 
than UART3 don't have MCR/MSR and only UART3 does have the full set of the 
modem control/status lines?  Were they indeed failing the loopback test for 
you? Asking because on DBAu1550 board all (enabled) UARTs do pass the loopback 
test if I get rid of this flag (however, Au1550 datasheet says MCR/MSR exists 
on all UARTs, just no modem pins exist on UART0, and only RTS-/CTS- pair on 
UART1 -- and the bits having no correspoding pins seem to be tied high 
internally).
    If I'm correct, the driver seems inconsistent in how it handles 
UART_BUG_NOMSR flag, only checking it when deciding whether to enable the 
modem status interrupts or not while actually it should have been checked in 
serial8250_set_mctrl() and check_modem_status() as well...
    It also looks like the driver doesn't use Alchemy UARTs to their full 
potential currently: UART3 has not only full set of modem lines, but also is 
capable of the auto flow control (UART1 on Au1550 also is).  (Making use of 
these features howewer are complicated by the auto flow control being only 
available in the late steppings of Au1500 and UART3 modem pins being 
multiplexed with GPIO...)

WBR, Sergei

PS: CCing linux-mips to keep people here informed. :-)

  parent reply	other threads:[~2006-09-04 17:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-04 18:47 [PATCH] AMD Alchemy: claim UART memory range Sergei Shtylyov
     [not found] ` <44F2E9F7.6030309@ru.mvista.com>
     [not found]   ` <F8D0F572-A68C-4343-A563-23D79BAB25AD@embeddedalley.com>
     [not found]     ` <20060830080157.GA17632@flint.arm.linux.org.uk>
2006-09-04 17:28       ` Sergei Shtylyov [this message]
2006-09-04 17:38         ` Pantelis Antoniou
2006-09-04 18:15           ` Sergei Shtylyov

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=44FC625A.5050005@ru.mvista.com \
    --to=sshtylyov@ru.mvista.com \
    --cc=linux-mips@linux-mips.org \
    --cc=pantelis@embeddedalley.com \
    --cc=rmk@arm.linux.org.uk \
    /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.