linux-serial.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ben Papps <ben.papps@oxsemi.com>
To: linux serial newsgroup <linux-serial@vger.kernel.org>
Subject: Hardware Flow Control on 16C950/954 (kernel 2.6.11)
Date: Thu, 04 Aug 2005 15:36:42 +0100	[thread overview]
Message-ID: <42F227FA.2060607@oxsemi.com> (raw)

Hi all,

I have found an issue concerning hardware flow control on the 16C950/954 
(specifically I am working on the OX16PCI954/952 devices) in Linux 2.6 
(Specifically the 2.6.11 kernel source (Fedora Core 3)). I have been 
looking at how I can get this small fix made in the kernel, and thought 
that I'd post the issue here first to see what other people think about it.

The short version...: In file 8250.c, in uart_config[], lines 223-229.

[PORT_16C950] = {
.name = “16C950/954”,
.fifo_size = 128,
.tx_loadsz = 128,
.fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
.flags = UART_CAP_FIFO,
}

They should be*:*

[PORT_16C950] = {
.name = “16C950/954”,
.fifo_size = 128,
.tx_loadsz = 128,
.fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
.flags = UART_CAP_FIFO *| UART_CAP_EFR | UART_CAP_SLEEP*,
}

These flags allow the enhanced register to be used, allowing flow 
control amongst other things.

The long version... also in 8250.c, considering the OX16PCI954 device.
The autoconfig routine calls the autoconfig_16550a routine, in which we 
find that the C95x chip has an EFR register. The autoconfig_16550a 
routine then calls the autoconfig_has_efr routine where up->capabilities 
is correctly set with UART_CAP_EFR and UART_CAP_SLEEP. On recognising 
the Oxford Semiconductor 16C950 devise autoconfig_has_efr returns to 
autoconfig_16550a which in turn returns to autoconfig..

 From line 879 to 888 in autoconfig the driver the checks the 
up->capabilities against the devices information in uart_config[]. This 
of course doesn't match, as shown above in the short version, and 
up->capabilities is reset with the values that are in uart_config[].

Without the EFR settings the set_termios routine is unable to assert the 
hardware flow control feature of the C950 uart.

The 16C954/950 entry in uart_config[] needs to have the UART_CAP_EFR and 
UART_CAP_SLEEP flags added to fix this bug.

I would appreciate any feedback on this.

Thanks,

Ben Papps


 
_____________________________
 
Ben Papps

Software Design Engineer
Oxford Semiconductor Ltd
25 Milton Park, Oxfordshire, OX14 4SH
 
Tel: 01235 824887


-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

                 reply	other threads:[~2005-08-04 14:36 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=42F227FA.2060607@oxsemi.com \
    --to=ben.papps@oxsemi.com \
    --cc=linux-serial@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).