From: Aristeu Sergio Rozanski Filho <aris@mandriva.com>
To: "Björn Östby" <Bjorn.Ostby@combitech.se>
Cc: fbl@conectiva.com.br, linuxppc-embedded@ozlabs.org
Subject: Re: SCCx UART status on 8xx
Date: Mon, 20 Feb 2006 11:18:35 -0300 [thread overview]
Message-ID: <20060220141830.GA7228@oops.ghostprotocols.net> (raw)
In-Reply-To: <004B1D7A5257174C9044A1B7BD0E60ED0178CC4F@ratatosk.combitechsystems.com>
[-- Attachment #1: Type: text/plain, Size: 1994 bytes --]
On Mon, Feb 20, 2006 at 02:37:23PM +0100, Björn Östby wrote:
> Hello,
> I'm messing with a mpc823e based board trying to enable the SCC3 UART. I'm using the 2.4.25 denx linux_ppc kernel and I've got SMC1 for console and SMC2 up and running but I'm in desperate need of another rs232 port (which is on SCC3 on my board).
> Reading quite a lot of old posts on this mailing list got me confused whether the SCCx UART support in the kernel is ready to be used on 8xx or if there will take a large amount of hacking to get things going (reading the header of 8xx_io/uart.c got me wondering even more).
> Current situation is that I have enabled the SCC3 UART in the kernel, set the correct CTS, RTS and CD signal options and finally disabled the SPI which (on my board at least) can override the UART on the third SCC port. During boot up I get the standard output:
>
> >ttyS0 at 0x0280 is on SMC1 using BRG1
> >ttyS1 at 0x0380 is on SMC2 using BRG2
> >ttyS2 at 0x0200 is on SCC3 using BRG3
>
> Writing to ttyS0 and ttyS1 works fine (the result pop up in the receiving terminal) but when trying ttyS2 nothing happens. I've checked the Tx signal and it appears as if data is sent (the signal gets noisy when starting the write procedure). I may also add that restaring the write application causes the kernel to hang (for ttyS2 only of course).
>
> I've read some posts saying that Linux don't init other uart ports than the console port and that is the potential problem here, but it is unclear if this statement is true or not. I can also add to the problem description that my SMC2 port works fine for writing, but reading just hangs in the read() call. So, can anyone confirm any status on the SMCx and SCCx UART drivers for 2.4?
please try the two attached patches. the first one configures each SCC to
one BRG. the second one, makes use always of dpram memory. we're working on a
decent fix.
Marcelo: if you find the first one ok, you may apply it, but don't apply the
second
--
Aristeu
[-- Attachment #2: cpm_uart-configure_brgs_properly.patch --]
[-- Type: text/plain, Size: 1028 bytes --]
Index: stable/drivers/serial/cpm_uart/cpm_uart_cpm1.c
===================================================================
--- stable.orig/drivers/serial/cpm_uart/cpm_uart_cpm1.c 2006-02-17 17:11:37.000000000 -0200
+++ stable/drivers/serial/cpm_uart/cpm_uart_cpm1.c 2006-02-17 17:15:57.000000000 -0200
@@ -139,24 +139,31 @@
void scc1_lineif(struct uart_cpm_port *pinfo)
{
/* XXX SCC1: insert port configuration here */
+ cpmp->cp_sicr &= 0xFFFFFFC0;
pinfo->brg = 1;
}
void scc2_lineif(struct uart_cpm_port *pinfo)
{
/* XXX SCC2: insert port configuration here */
+ cpmp->cp_sicr &= 0xFFFFC0FF;
+ cpmp->cp_sicr |= 0x00000900;
pinfo->brg = 2;
}
void scc3_lineif(struct uart_cpm_port *pinfo)
{
/* XXX SCC3: insert port configuration here */
+ cpmp->cp_sicr &= 0xFFC0FFFF;
+ cpmp->cp_sicr |= 0x00140000;
pinfo->brg = 3;
}
void scc4_lineif(struct uart_cpm_port *pinfo)
{
/* XXX SCC4: insert port configuration here */
+ cpmp->cp_sicr &= 0xC0FFFFFF;
+ cpmp->cp_sicr |= 0x1BFFFFFF;
pinfo->brg = 4;
}
[-- Attachment #3: serial_alloc_bootmem.patch --]
[-- Type: text/plain, Size: 1131 bytes --]
Index: stable/drivers/serial/cpm_uart/cpm_uart_core.c
===================================================================
--- stable.orig/drivers/serial/cpm_uart/cpm_uart_core.c 2005-12-07 15:30:42.000000000 -0200
+++ stable/drivers/serial/cpm_uart/cpm_uart_core.c 2005-12-08 12:39:11.000000000 -0200
@@ -467,6 +467,7 @@
/* free interrupt handler */
free_irq(port->irq, port);
+#if 0
/* If the port is not the console, disable Rx and Tx. */
if (!(pinfo->flags & FLAG_CONSOLE)) {
/* Wait for all the BDs marked sent */
@@ -492,6 +493,7 @@
/* Shut them really down */
cpm_line_cr_cmd(line, CPM_CR_STOP_TX);
}
+#endif
}
static void cpm_uart_set_termios(struct uart_port *port,
@@ -896,7 +898,7 @@
pinfo->sccp->scc_gsmrl &= ~(SCC_GSMRL_ENR | SCC_GSMRL_ENT);
}
- ret = cpm_uart_allocbuf(pinfo, 0);
+ ret = cpm_uart_allocbuf(pinfo, 1);
if (ret)
return ret;
@@ -912,10 +914,12 @@
static void cpm_uart_release_port(struct uart_port *port)
{
+#if 0
struct uart_cpm_port *pinfo = (struct uart_cpm_port *)port;
if (!(pinfo->flags & FLAG_CONSOLE))
cpm_uart_freebuf(pinfo);
+#endif
}
/*
next prev parent reply other threads:[~2006-02-20 14:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-20 13:37 SCCx UART status on 8xx Björn Östby
2006-02-20 14:18 ` Aristeu Sergio Rozanski Filho [this message]
2006-03-11 22:17 ` Marcelo Tosatti
2006-02-20 20:15 ` Wolfgang Denk
2006-02-20 20:43 ` Dan Malek
-- strict thread matches above, loose matches on Subject: below --
2006-02-21 11:01 Björn Östby
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=20060220141830.GA7228@oops.ghostprotocols.net \
--to=aris@mandriva.com \
--cc=Bjorn.Ostby@combitech.se \
--cc=fbl@conectiva.com.br \
--cc=linuxppc-embedded@ozlabs.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).