* Re: opening the serial port from userspace application
From: Vitaly Bordug @ 2006-02-02 11:45 UTC (permalink / raw)
To: bharathi kandimalla; +Cc: linuxppc-embedded
In-Reply-To: <20060201082419.53038.qmail@web50010.mail.yahoo.com>
On Wed, 1 Feb 2006 00:24:19 -0800 (PST)
bharathi kandimalla <bharthik2004@yahoo.com> wrote:
> Hi
> I am able to use the serialport uart drivers for the custom board with =
mpc860T=20
> which are available in the kernel 2.6.13 =20
> I am getting bootup messages like this
> ttyCPM0 at MMIO 0xfb000a80 (irq =3D 20) is a CPM UART
> ttyCPM1 at MMIO 0xfb000a90 (irq =3D 19) is a CPM UART
> ttyCPM2 at MMIO 0xfb000a00 (irq =3D 46) is a CPM UART
> ttyCPM3 at MMIO 0xfb000a20 (irq =3D 45) is a CPM UART =20
=46rom what I can see, you have misconfigured something. Dunno for certain, b=
ut 860T=20
might have 2 UARTs, when you have at least 4 enabled. Please enable in the =
kernel configuration only those which exist on your board.
> And after getting prompt
> cd /proc/dev/ =20
> cat drivers
> /dev/tty /dev/tty 5 0 system:/dev/tty
> /dev/console /dev/console 5 1 system:console
> /dev/ptmx /dev/ptmx 5 2 system
> ttyCPM /dev/ttyCPM 204 46-49 serial
> pty_slave /dev/pts 136 0-1048575 pty:slave
> pty_master /dev/ptm 128 0-1048575 pty:master=20
> I am using mknod command=20
> mknod /dev/ttyCPM0 c 204 46=20
> ln -sf console ttyCPM0=20
> mknod /dev/ttyCPM1 c 204 47
> mknod /dev/ttyCPM2 c 204 48
> mknod /dev/ttyCPM3 c 204 49 =20
> even I am not able to open the device from the user space application
> I want to write some data from the user space into the
> application
> But I am not able to open the device
> please help me out
> regards
> Bharathi=20
> =20
> =20
> =20
>=20
> =09
> ---------------------------------
> =20
> What are the most popular cars? Find out at Yahoo! Autos=20
--=20
Sincerely,=20
Vitaly
^ permalink raw reply
* RE: Yosemite/440EP why are readl()/ioread32() setuptoreadlittle-endian?
From: Jenkins, Clive @ 2006-02-02 11:26 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
I'm not sure all this fuss is justified in response to:
> What is the preferred way of accessing non-PCI devices then?
> Direct pointer access?
> Bye, Peter Korsgaard
Regardless of what standards or hardware might exist, I would be
happy if Linux provided alternatives to readl()... that converted
between big-endian and cpu-endian, so that I could write in my
driver, for example:
static inline my_readl(...)
{
#if (my interconnect is PCI or other little-endian)
return(readl(...));
#else
return(readl_be(...));
#endif
}
That must make my driver more portable in future circumstances.
Clive
-----Original Message-----
From: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Eugene
Surovegin
Sent: 02 February 2006 10:44
To: Jenkins, Clive
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Yosemite/440EP why are readl()/ioread32()
setuptoreadlittle-endian?
On Thu, Feb 02, 2006 at 10:28:05AM -0000, Jenkins, Clive wrote:
> And what about direct connection to the local bus of the processor
chip?
What about it? It's _chip_ specific. And the way your "generic" stuff=20
will be connected to it will be chip or even design specific (yeah, hw=20
guys sometime wire it in some weird way). I fail to see how you can=20
have _generic_ I/O accessors for this case.
> =20
> > So basically, you have no _real_ life examples, so I'm wondering why
> > people need this "arch-independent" non-PCI I/O accessors for=20
> > something which doesn't exist.
>=20
> I could draft a design of such an example, and I could realise that
> design
> by building it. But I don't want to spend the time and money doing it.
> Neither do I want to spend time researching _real_ examples.
> It is much easier to allow for obvious possibilities that _could_
exist
> and probably will exist if they don't already, than searching the
world.
It's not as easy as you might think :). It must be=20
arch/bus/device/board specific in the general case.=20
You can try _specifying_ semantics for such generic accessors and=20
_then_ we can discuss this and I will very likely give you _real_=20
world examples when they will not work.
> Why be PCI-centric now, when we have experienced no end of problems
> because Linux was x86-centric in the past?
Well, until there is another _standard_ bus which is used on=20
different archs, having _generic_ cross-arch I/O accessors doesn't=20
make any sense.
I don't understand your point about not being PCI specific. It's of no=20
relevance what you or I think about PCI and x86. I have ported several=20
"standard" bus drivers to chip specific interconnects (MIPS and PPC)=20
and in every case code was bus or even board specific. I'm pretty much=20
aware about problems and solutions. But this is not what is being=20
discussed here. Until there is _standard_ for such interconnects (like=20
PCI) everything else is just wishful thinking.
--=20
Eugene
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Yosemite/440EP why are readl()/ioread32() setup toreadlittle-endian?
From: Eugene Surovegin @ 2006-02-02 10:44 UTC (permalink / raw)
To: Jenkins, Clive; +Cc: linuxppc-embedded
In-Reply-To: <35786B99AB3FDC45A8215724617919736D921D@gbrwgceumf01.eu.xerox.net>
On Thu, Feb 02, 2006 at 10:28:05AM -0000, Jenkins, Clive wrote:
> And what about direct connection to the local bus of the processor chip?
What about it? It's _chip_ specific. And the way your "generic" stuff
will be connected to it will be chip or even design specific (yeah, hw
guys sometime wire it in some weird way). I fail to see how you can
have _generic_ I/O accessors for this case.
>
> > So basically, you have no _real_ life examples, so I'm wondering why
> > people need this "arch-independent" non-PCI I/O accessors for
> > something which doesn't exist.
>
> I could draft a design of such an example, and I could realise that
> design
> by building it. But I don't want to spend the time and money doing it.
> Neither do I want to spend time researching _real_ examples.
> It is much easier to allow for obvious possibilities that _could_ exist
> and probably will exist if they don't already, than searching the world.
It's not as easy as you might think :). It must be
arch/bus/device/board specific in the general case.
You can try _specifying_ semantics for such generic accessors and
_then_ we can discuss this and I will very likely give you _real_
world examples when they will not work.
> Why be PCI-centric now, when we have experienced no end of problems
> because Linux was x86-centric in the past?
Well, until there is another _standard_ bus which is used on
different archs, having _generic_ cross-arch I/O accessors doesn't
make any sense.
I don't understand your point about not being PCI specific. It's of no
relevance what you or I think about PCI and x86. I have ported several
"standard" bus drivers to chip specific interconnects (MIPS and PPC)
and in every case code was bus or even board specific. I'm pretty much
aware about problems and solutions. But this is not what is being
discussed here. Until there is _standard_ for such interconnects (like
PCI) everything else is just wishful thinking.
--
Eugene
^ permalink raw reply
* RE: Yosemite/440EP why are readl()/ioread32() setup toreadlittle-endian?
From: Jenkins, Clive @ 2006-02-02 10:28 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
> > On Thu, Feb 02, 2006 at 09:35:56AM -0000, Jenkins, Clive wrote:
> > A driver for some device that could be connected to (or plugged
into)
> > a variety of different platforms of different architecture.
> > A driver for a core that could be implemented within an FPGA on
> > multiple platforms.
> Well, this is all nice but I was wondering about _real_ examples.
> When you are talking about "connecting" or "plugging" you have to keep
> in mind actual bus interconnect. So far AFAIK PCI (and derivatives)=20
> are the only cross-arch bus.
Yes, I do realise that in most cases PCI is used for cross-arch
interconnect. But without knowing about all the relevant hardware in the
world, I couldn't say that there are no other cross-arch buses.
And what about direct connection to the local bus of the processor chip?
=20
> So basically, you have no _real_ life examples, so I'm wondering why=20
> people need this "arch-independent" non-PCI I/O accessors for=20
> something which doesn't exist.
I could draft a design of such an example, and I could realise that
design
by building it. But I don't want to spend the time and money doing it.
Neither do I want to spend time researching _real_ examples.
It is much easier to allow for obvious possibilities that _could_ exist
and probably will exist if they don't already, than searching the world.
Why be PCI-centric now, when we have experienced no end of problems
because Linux was x86-centric in the past?
> I think the reason why Linux doesn't have this stuff follows from the=20
> previous paragraph.
Clive
^ permalink raw reply
* Re: [CFT] Don't use ASYNC_* nor SERIAL_IO_* with serial_core
From: Russell King @ 2006-02-02 10:27 UTC (permalink / raw)
To: Linux Kernel List, linux-mips, linuxppc-dev, takata, pfg
In-Reply-To: <20060121211407.GA19984@dyn-67.arm.linux.org.uk>
Ping?
On Sat, Jan 21, 2006 at 09:14:07PM +0000, Russell King wrote:
> The serial_core layer has its own definitions for these, and I'd
> appreciate it if folk would use them instead of the old ASYNC_* and
> SERIAL_IO_* definitions.
>
> They're compatible _at the moment_ but I make no guarantees that they
> will stay that way. Hence, it's in your interest to ensure that you're
> using the correct definitions.
>
> MIPS, PPC seem to be the architectures which are stuck in the past on
> this issue, as is the M32R SIO driver.
>
> The ioc4_serial driver is worse. It assumes that it can set/clear
> ASYNC_CTS_FLOW in the uart_info flags field, which is private to
> serial_core. It also seems to set TTY_IO_ERROR followed by immediately
> clearing it (pointless), and then it writes to tty->alt_speed... which
> isn't used by the serial layer so is also pointless.
>
> So, here's a patch to fix some of this crap up. Please test and
> enjoy - I certainly didn't.
>
> arch/mips/cobalt/setup.c | 2 +-
> arch/mips/lasat/setup.c | 4 ++--
> arch/mips/mips-boards/atlas/atlas_setup.c | 4 ++--
> arch/mips/mips-boards/sead/sead_setup.c | 4 ++--
> arch/mips/mips-boards/sim/sim_setup.c | 4 ++--
> arch/mips/momentum/jaguar_atx/ja-console.c | 2 +-
> arch/mips/pmc-sierra/yosemite/setup.c | 2 +-
> arch/mips/sgi-ip32/ip32-setup.c | 13 ++++---------
> arch/ppc/platforms/4xx/bamboo.c | 4 ++--
> arch/ppc/platforms/4xx/bubinga.c | 4 ++--
> arch/ppc/platforms/4xx/ebony.c | 4 ++--
> arch/ppc/platforms/4xx/luan.c | 4 ++--
> arch/ppc/platforms/4xx/ocotea.c | 4 ++--
> arch/ppc/platforms/4xx/xilinx_ml300.c | 4 ++--
> arch/ppc/platforms/4xx/yucca.c | 4 ++--
> arch/ppc/platforms/spruce.c | 4 ++--
> drivers/serial/ioc4_serial.c | 14 --------------
> drivers/serial/m32r_sio.c | 2 +-
> 18 files changed, 32 insertions(+), 51 deletions(-)
>
> diff --git a/arch/mips/cobalt/setup.c b/arch/mips/cobalt/setup.c
> --- a/arch/mips/cobalt/setup.c
> +++ b/arch/mips/cobalt/setup.c
> @@ -139,7 +139,7 @@ void __init plat_setup(void)
> uart.type = PORT_UNKNOWN;
> uart.uartclk = 18432000;
> uart.irq = COBALT_SERIAL_IRQ;
> - uart.flags = STD_COM_FLAGS;
> + uart.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST;
> uart.iobase = 0xc800000;
> uart.iotype = UPIO_PORT;
>
> diff --git a/arch/mips/lasat/setup.c b/arch/mips/lasat/setup.c
> --- a/arch/mips/lasat/setup.c
> +++ b/arch/mips/lasat/setup.c
> @@ -134,8 +134,8 @@ void __init serial_init(void)
>
> memset(&s, 0, sizeof(s));
>
> - s.flags = STD_COM_FLAGS;
> - s.iotype = SERIAL_IO_MEM;
> + s.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST;
> + s.iotype = UPIO_MEM;
>
> if (mips_machtype == MACH_LASAT_100) {
> s.uartclk = LASAT_BASE_BAUD_100 * 16;
> diff --git a/arch/mips/mips-boards/atlas/atlas_setup.c b/arch/mips/mips-boards/atlas/atlas_setup.c
> --- a/arch/mips/mips-boards/atlas/atlas_setup.c
> +++ b/arch/mips/mips-boards/atlas/atlas_setup.c
> @@ -82,8 +82,8 @@ static void __init serial_init(void)
> #endif
> s.irq = ATLASINT_UART;
> s.uartclk = ATLAS_BASE_BAUD * 16;
> - s.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST | ASYNC_AUTO_IRQ;
> - s.iotype = SERIAL_IO_PORT;
> + s.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST | UPF_AUTO_IRQ;
> + s.iotype = UPIO_PORT;
> s.regshift = 3;
>
> if (early_serial_setup(&s) != 0) {
> diff --git a/arch/mips/mips-boards/sead/sead_setup.c b/arch/mips/mips-boards/sead/sead_setup.c
> --- a/arch/mips/mips-boards/sead/sead_setup.c
> +++ b/arch/mips/mips-boards/sead/sead_setup.c
> @@ -71,8 +71,8 @@ static void __init serial_init(void)
> #endif
> s.irq = MIPSCPU_INT_BASE + MIPSCPU_INT_UART0;
> s.uartclk = SEAD_BASE_BAUD * 16;
> - s.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST | ASYNC_AUTO_IRQ;
> - s.iotype = 0;
> + s.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST | UPF_AUTO_IRQ;
> + s.iotype = UPIO_PORT;
> s.regshift = 3;
>
> if (early_serial_setup(&s) != 0) {
> diff --git a/arch/mips/mips-boards/sim/sim_setup.c b/arch/mips/mips-boards/sim/sim_setup.c
> --- a/arch/mips/mips-boards/sim/sim_setup.c
> +++ b/arch/mips/mips-boards/sim/sim_setup.c
> @@ -88,8 +88,8 @@ static void __init serial_init(void)
> but poll for now */
> s.irq = 0;
> s.uartclk = BASE_BAUD * 16;
> - s.flags = ASYNC_BOOT_AUTOCONF | UPF_SKIP_TEST;
> - s.iotype = SERIAL_IO_PORT | ASYNC_SKIP_TEST;
> + s.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST;
> + s.iotype = UPIO_PORT;
> s.regshift = 0;
> s.timeout = 4;
>
> diff --git a/arch/mips/momentum/jaguar_atx/ja-console.c b/arch/mips/momentum/jaguar_atx/ja-console.c
> --- a/arch/mips/momentum/jaguar_atx/ja-console.c
> +++ b/arch/mips/momentum/jaguar_atx/ja-console.c
> @@ -93,7 +93,7 @@ static void inline ja_console_probe(void
> up.uartclk = JAGUAR_ATX_UART_CLK;
> up.regshift = 2;
> up.iotype = UPIO_MEM;
> - up.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST;
> + up.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST;
> up.line = 0;
>
> if (early_serial_setup(&up))
> diff --git a/arch/mips/pmc-sierra/yosemite/setup.c b/arch/mips/pmc-sierra/yosemite/setup.c
> --- a/arch/mips/pmc-sierra/yosemite/setup.c
> +++ b/arch/mips/pmc-sierra/yosemite/setup.c
> @@ -185,7 +185,7 @@ static void __init py_uart_setup(void)
> up.uartclk = TITAN_UART_CLK;
> up.regshift = 0;
> up.iotype = UPIO_MEM;
> - up.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST;
> + up.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST;
> up.line = 0;
>
> if (early_serial_setup(&up))
> diff --git a/arch/mips/sgi-ip32/ip32-setup.c b/arch/mips/sgi-ip32/ip32-setup.c
> --- a/arch/mips/sgi-ip32/ip32-setup.c
> +++ b/arch/mips/sgi-ip32/ip32-setup.c
> @@ -66,11 +66,6 @@ static inline void str2eaddr(unsigned ch
> #include <linux/tty.h>
> #include <linux/serial.h>
> #include <linux/serial_core.h>
> -extern int early_serial_setup(struct uart_port *port);
> -
> -#define STD_COM_FLAGS (ASYNC_SKIP_TEST)
> -#define BASE_BAUD (1843200 / 16)
> -
> #endif /* CONFIG_SERIAL_8250 */
>
> /* An arbitrary time; this can be decreased if reliability looks good */
> @@ -110,8 +105,8 @@ void __init plat_setup(void)
> o2_serial[0].type = PORT_16550A;
> o2_serial[0].line = 0;
> o2_serial[0].irq = MACEISA_SERIAL1_IRQ;
> - o2_serial[0].flags = STD_COM_FLAGS;
> - o2_serial[0].uartclk = BASE_BAUD * 16;
> + o2_serial[0].flags = UPF_SKIP_TEST;
> + o2_serial[0].uartclk = 1843200;
> o2_serial[0].iotype = UPIO_MEM;
> o2_serial[0].membase = (char *)&mace->isa.serial1;
> o2_serial[0].fifosize = 14;
> @@ -121,8 +116,8 @@ void __init plat_setup(void)
> o2_serial[1].type = PORT_16550A;
> o2_serial[1].line = 1;
> o2_serial[1].irq = MACEISA_SERIAL2_IRQ;
> - o2_serial[1].flags = STD_COM_FLAGS;
> - o2_serial[1].uartclk = BASE_BAUD * 16;
> + o2_serial[1].flags = UPF_SKIP_TEST;
> + o2_serial[1].uartclk = 1843200;
> o2_serial[1].iotype = UPIO_MEM;
> o2_serial[1].membase = (char *)&mace->isa.serial2;
> o2_serial[1].fifosize = 14;
> diff --git a/arch/ppc/platforms/4xx/bamboo.c b/arch/ppc/platforms/4xx/bamboo.c
> --- a/arch/ppc/platforms/4xx/bamboo.c
> +++ b/arch/ppc/platforms/4xx/bamboo.c
> @@ -332,8 +332,8 @@ bamboo_early_serial_map(void)
> port.irq = 0;
> port.uartclk = clocks.uart0;
> port.regshift = 0;
> - port.iotype = SERIAL_IO_MEM;
> - port.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST;
> + port.iotype = UPIO_MEM;
> + port.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST;
> port.line = 0;
>
> if (early_serial_setup(&port) != 0) {
> diff --git a/arch/ppc/platforms/4xx/bubinga.c b/arch/ppc/platforms/4xx/bubinga.c
> --- a/arch/ppc/platforms/4xx/bubinga.c
> +++ b/arch/ppc/platforms/4xx/bubinga.c
> @@ -97,8 +97,8 @@ bubinga_early_serial_map(void)
> port.irq = ACTING_UART0_INT;
> port.uartclk = uart_clock;
> port.regshift = 0;
> - port.iotype = SERIAL_IO_MEM;
> - port.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST;
> + port.iotype = UPIO_MEM;
> + port.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST;
> port.line = 0;
>
> if (early_serial_setup(&port) != 0) {
> diff --git a/arch/ppc/platforms/4xx/ebony.c b/arch/ppc/platforms/4xx/ebony.c
> --- a/arch/ppc/platforms/4xx/ebony.c
> +++ b/arch/ppc/platforms/4xx/ebony.c
> @@ -225,8 +225,8 @@ ebony_early_serial_map(void)
> port.irq = 0;
> port.uartclk = clocks.uart0;
> port.regshift = 0;
> - port.iotype = SERIAL_IO_MEM;
> - port.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST;
> + port.iotype = UPIO_MEM;
> + port.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST;
> port.line = 0;
>
> if (early_serial_setup(&port) != 0) {
> diff --git a/arch/ppc/platforms/4xx/luan.c b/arch/ppc/platforms/4xx/luan.c
> --- a/arch/ppc/platforms/4xx/luan.c
> +++ b/arch/ppc/platforms/4xx/luan.c
> @@ -279,8 +279,8 @@ luan_early_serial_map(void)
> port.irq = UART0_INT;
> port.uartclk = clocks.uart0;
> port.regshift = 0;
> - port.iotype = SERIAL_IO_MEM;
> - port.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST;
> + port.iotype = UPIO_MEM;
> + port.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST;
> port.line = 0;
>
> if (early_serial_setup(&port) != 0) {
> diff --git a/arch/ppc/platforms/4xx/ocotea.c b/arch/ppc/platforms/4xx/ocotea.c
> --- a/arch/ppc/platforms/4xx/ocotea.c
> +++ b/arch/ppc/platforms/4xx/ocotea.c
> @@ -248,8 +248,8 @@ ocotea_early_serial_map(void)
> port.irq = UART0_INT;
> port.uartclk = clocks.uart0;
> port.regshift = 0;
> - port.iotype = SERIAL_IO_MEM;
> - port.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST;
> + port.iotype = UPIO_MEM;
> + port.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST;
> port.line = 0;
>
> if (early_serial_setup(&port) != 0) {
> diff --git a/arch/ppc/platforms/4xx/xilinx_ml300.c b/arch/ppc/platforms/4xx/xilinx_ml300.c
> --- a/arch/ppc/platforms/4xx/xilinx_ml300.c
> +++ b/arch/ppc/platforms/4xx/xilinx_ml300.c
> @@ -95,8 +95,8 @@ ml300_early_serial_map(void)
> port.irq = old_ports[i].irq;
> port.uartclk = old_ports[i].baud_base * 16;
> port.regshift = old_ports[i].iomem_reg_shift;
> - port.iotype = SERIAL_IO_MEM;
> - port.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST;
> + port.iotype = UPIO_MEM;
> + port.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST;
> port.line = i;
>
> if (early_serial_setup(&port) != 0) {
> diff --git a/arch/ppc/platforms/4xx/yucca.c b/arch/ppc/platforms/4xx/yucca.c
> --- a/arch/ppc/platforms/4xx/yucca.c
> +++ b/arch/ppc/platforms/4xx/yucca.c
> @@ -305,8 +305,8 @@ yucca_early_serial_map(void)
> port.irq = UART0_INT;
> port.uartclk = clocks.uart0;
> port.regshift = 0;
> - port.iotype = SERIAL_IO_MEM;
> - port.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST;
> + port.iotype = UPIO_MEM;
> + port.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST;
> port.line = 0;
>
> if (early_serial_setup(&port) != 0) {
> diff --git a/arch/ppc/platforms/spruce.c b/arch/ppc/platforms/spruce.c
> --- a/arch/ppc/platforms/spruce.c
> +++ b/arch/ppc/platforms/spruce.c
> @@ -176,8 +176,8 @@ spruce_early_serial_map(void)
> memset(&serial_req, 0, sizeof(serial_req));
> serial_req.uartclk = uart_clk;
> serial_req.irq = UART0_INT;
> - serial_req.flags = ASYNC_BOOT_AUTOCONF;
> - serial_req.iotype = SERIAL_IO_MEM;
> + serial_req.flags = UPF_BOOT_AUTOCONF;
> + serial_req.iotype = UPIO_MEM;
> serial_req.membase = (u_char *)UART0_IO_BASE;
> serial_req.regshift = 0;
>
> diff --git a/drivers/serial/ioc4_serial.c b/drivers/serial/ioc4_serial.c
> --- a/drivers/serial/ioc4_serial.c
> +++ b/drivers/serial/ioc4_serial.c
> @@ -1717,11 +1717,9 @@ ioc4_change_speed(struct uart_port *the_
> }
>
> if (cflag & CRTSCTS) {
> - info->flags |= ASYNC_CTS_FLOW;
> port->ip_sscr |= IOC4_SSCR_HFC_EN;
> }
> else {
> - info->flags &= ~ASYNC_CTS_FLOW;
> port->ip_sscr &= ~IOC4_SSCR_HFC_EN;
> }
> writel(port->ip_sscr, &port->ip_serial_regs->sscr);
> @@ -1760,18 +1758,6 @@ static inline int ic4_startup_local(stru
>
> info = the_port->info;
>
> - if (info->tty) {
> - set_bit(TTY_IO_ERROR, &info->tty->flags);
> - clear_bit(TTY_IO_ERROR, &info->tty->flags);
> - if ((info->flags & ASYNC_SPD_MASK) == ASYNC_SPD_HI)
> - info->tty->alt_speed = 57600;
> - if ((info->flags & ASYNC_SPD_MASK) == ASYNC_SPD_VHI)
> - info->tty->alt_speed = 115200;
> - if ((info->flags & ASYNC_SPD_MASK) == ASYNC_SPD_SHI)
> - info->tty->alt_speed = 230400;
> - if ((info->flags & ASYNC_SPD_MASK) == ASYNC_SPD_WARP)
> - info->tty->alt_speed = 460800;
> - }
> local_open(port);
>
> /* set the speed of the serial port */
> diff --git a/drivers/serial/m32r_sio.c b/drivers/serial/m32r_sio.c
> --- a/drivers/serial/m32r_sio.c
> +++ b/drivers/serial/m32r_sio.c
> @@ -80,7 +80,7 @@
> #include <asm/serial.h>
>
> /* Standard COM flags */
> -#define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST)
> +#define STD_COM_FLAGS (UPF_BOOT_AUTOCONF | UPF_SKIP_TEST)
>
> /*
> * SERIAL_PORT_DFNS tells us about built-in ports that have no
> diff --git a/arch/mips/cobalt/setup.c b/arch/mips/cobalt/setup.c
> --- a/arch/mips/cobalt/setup.c
> +++ b/arch/mips/cobalt/setup.c
> @@ -139,7 +139,7 @@ void __init plat_setup(void)
> uart.type = PORT_UNKNOWN;
> uart.uartclk = 18432000;
> uart.irq = COBALT_SERIAL_IRQ;
> - uart.flags = STD_COM_FLAGS;
> + uart.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST;
> uart.iobase = 0xc800000;
> uart.iotype = UPIO_PORT;
>
> diff --git a/arch/mips/lasat/setup.c b/arch/mips/lasat/setup.c
> --- a/arch/mips/lasat/setup.c
> +++ b/arch/mips/lasat/setup.c
> @@ -134,8 +134,8 @@ void __init serial_init(void)
>
> memset(&s, 0, sizeof(s));
>
> - s.flags = STD_COM_FLAGS;
> - s.iotype = SERIAL_IO_MEM;
> + s.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST;
> + s.iotype = UPIO_MEM;
>
> if (mips_machtype == MACH_LASAT_100) {
> s.uartclk = LASAT_BASE_BAUD_100 * 16;
> diff --git a/arch/mips/mips-boards/atlas/atlas_setup.c b/arch/mips/mips-boards/atlas/atlas_setup.c
> --- a/arch/mips/mips-boards/atlas/atlas_setup.c
> +++ b/arch/mips/mips-boards/atlas/atlas_setup.c
> @@ -82,8 +82,8 @@ static void __init serial_init(void)
> #endif
> s.irq = ATLASINT_UART;
> s.uartclk = ATLAS_BASE_BAUD * 16;
> - s.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST | ASYNC_AUTO_IRQ;
> - s.iotype = SERIAL_IO_PORT;
> + s.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST | UPF_AUTO_IRQ;
> + s.iotype = UPIO_PORT;
> s.regshift = 3;
>
> if (early_serial_setup(&s) != 0) {
> diff --git a/arch/mips/mips-boards/sead/sead_setup.c b/arch/mips/mips-boards/sead/sead_setup.c
> --- a/arch/mips/mips-boards/sead/sead_setup.c
> +++ b/arch/mips/mips-boards/sead/sead_setup.c
> @@ -71,8 +71,8 @@ static void __init serial_init(void)
> #endif
> s.irq = MIPSCPU_INT_BASE + MIPSCPU_INT_UART0;
> s.uartclk = SEAD_BASE_BAUD * 16;
> - s.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST | ASYNC_AUTO_IRQ;
> - s.iotype = 0;
> + s.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST | UPF_AUTO_IRQ;
> + s.iotype = UPIO_PORT;
> s.regshift = 3;
>
> if (early_serial_setup(&s) != 0) {
> diff --git a/arch/mips/mips-boards/sim/sim_setup.c b/arch/mips/mips-boards/sim/sim_setup.c
> --- a/arch/mips/mips-boards/sim/sim_setup.c
> +++ b/arch/mips/mips-boards/sim/sim_setup.c
> @@ -88,8 +88,8 @@ static void __init serial_init(void)
> but poll for now */
> s.irq = 0;
> s.uartclk = BASE_BAUD * 16;
> - s.flags = ASYNC_BOOT_AUTOCONF | UPF_SKIP_TEST;
> - s.iotype = SERIAL_IO_PORT | ASYNC_SKIP_TEST;
> + s.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST;
> + s.iotype = UPIO_PORT;
> s.regshift = 0;
> s.timeout = 4;
>
> diff --git a/arch/mips/momentum/jaguar_atx/ja-console.c b/arch/mips/momentum/jaguar_atx/ja-console.c
> --- a/arch/mips/momentum/jaguar_atx/ja-console.c
> +++ b/arch/mips/momentum/jaguar_atx/ja-console.c
> @@ -93,7 +93,7 @@ static void inline ja_console_probe(void
> up.uartclk = JAGUAR_ATX_UART_CLK;
> up.regshift = 2;
> up.iotype = UPIO_MEM;
> - up.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST;
> + up.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST;
> up.line = 0;
>
> if (early_serial_setup(&up))
> diff --git a/arch/mips/pmc-sierra/yosemite/setup.c b/arch/mips/pmc-sierra/yosemite/setup.c
> --- a/arch/mips/pmc-sierra/yosemite/setup.c
> +++ b/arch/mips/pmc-sierra/yosemite/setup.c
> @@ -185,7 +185,7 @@ static void __init py_uart_setup(void)
> up.uartclk = TITAN_UART_CLK;
> up.regshift = 0;
> up.iotype = UPIO_MEM;
> - up.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST;
> + up.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST;
> up.line = 0;
>
> if (early_serial_setup(&up))
> diff --git a/arch/mips/sgi-ip32/ip32-setup.c b/arch/mips/sgi-ip32/ip32-setup.c
> --- a/arch/mips/sgi-ip32/ip32-setup.c
> +++ b/arch/mips/sgi-ip32/ip32-setup.c
> @@ -66,11 +66,6 @@ static inline void str2eaddr(unsigned ch
> #include <linux/tty.h>
> #include <linux/serial.h>
> #include <linux/serial_core.h>
> -extern int early_serial_setup(struct uart_port *port);
> -
> -#define STD_COM_FLAGS (ASYNC_SKIP_TEST)
> -#define BASE_BAUD (1843200 / 16)
> -
> #endif /* CONFIG_SERIAL_8250 */
>
> /* An arbitrary time; this can be decreased if reliability looks good */
> @@ -110,8 +105,8 @@ void __init plat_setup(void)
> o2_serial[0].type = PORT_16550A;
> o2_serial[0].line = 0;
> o2_serial[0].irq = MACEISA_SERIAL1_IRQ;
> - o2_serial[0].flags = STD_COM_FLAGS;
> - o2_serial[0].uartclk = BASE_BAUD * 16;
> + o2_serial[0].flags = UPF_SKIP_TEST;
> + o2_serial[0].uartclk = 1843200;
> o2_serial[0].iotype = UPIO_MEM;
> o2_serial[0].membase = (char *)&mace->isa.serial1;
> o2_serial[0].fifosize = 14;
> @@ -121,8 +116,8 @@ void __init plat_setup(void)
> o2_serial[1].type = PORT_16550A;
> o2_serial[1].line = 1;
> o2_serial[1].irq = MACEISA_SERIAL2_IRQ;
> - o2_serial[1].flags = STD_COM_FLAGS;
> - o2_serial[1].uartclk = BASE_BAUD * 16;
> + o2_serial[1].flags = UPF_SKIP_TEST;
> + o2_serial[1].uartclk = 1843200;
> o2_serial[1].iotype = UPIO_MEM;
> o2_serial[1].membase = (char *)&mace->isa.serial2;
> o2_serial[1].fifosize = 14;
> diff --git a/arch/ppc/platforms/4xx/bamboo.c b/arch/ppc/platforms/4xx/bamboo.c
> --- a/arch/ppc/platforms/4xx/bamboo.c
> +++ b/arch/ppc/platforms/4xx/bamboo.c
> @@ -332,8 +332,8 @@ bamboo_early_serial_map(void)
> port.irq = 0;
> port.uartclk = clocks.uart0;
> port.regshift = 0;
> - port.iotype = SERIAL_IO_MEM;
> - port.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST;
> + port.iotype = UPIO_MEM;
> + port.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST;
> port.line = 0;
>
> if (early_serial_setup(&port) != 0) {
> diff --git a/arch/ppc/platforms/4xx/bubinga.c b/arch/ppc/platforms/4xx/bubinga.c
> --- a/arch/ppc/platforms/4xx/bubinga.c
> +++ b/arch/ppc/platforms/4xx/bubinga.c
> @@ -97,8 +97,8 @@ bubinga_early_serial_map(void)
> port.irq = ACTING_UART0_INT;
> port.uartclk = uart_clock;
> port.regshift = 0;
> - port.iotype = SERIAL_IO_MEM;
> - port.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST;
> + port.iotype = UPIO_MEM;
> + port.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST;
> port.line = 0;
>
> if (early_serial_setup(&port) != 0) {
> diff --git a/arch/ppc/platforms/4xx/ebony.c b/arch/ppc/platforms/4xx/ebony.c
> --- a/arch/ppc/platforms/4xx/ebony.c
> +++ b/arch/ppc/platforms/4xx/ebony.c
> @@ -225,8 +225,8 @@ ebony_early_serial_map(void)
> port.irq = 0;
> port.uartclk = clocks.uart0;
> port.regshift = 0;
> - port.iotype = SERIAL_IO_MEM;
> - port.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST;
> + port.iotype = UPIO_MEM;
> + port.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST;
> port.line = 0;
>
> if (early_serial_setup(&port) != 0) {
> diff --git a/arch/ppc/platforms/4xx/luan.c b/arch/ppc/platforms/4xx/luan.c
> --- a/arch/ppc/platforms/4xx/luan.c
> +++ b/arch/ppc/platforms/4xx/luan.c
> @@ -279,8 +279,8 @@ luan_early_serial_map(void)
> port.irq = UART0_INT;
> port.uartclk = clocks.uart0;
> port.regshift = 0;
> - port.iotype = SERIAL_IO_MEM;
> - port.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST;
> + port.iotype = UPIO_MEM;
> + port.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST;
> port.line = 0;
>
> if (early_serial_setup(&port) != 0) {
> diff --git a/arch/ppc/platforms/4xx/ocotea.c b/arch/ppc/platforms/4xx/ocotea.c
> --- a/arch/ppc/platforms/4xx/ocotea.c
> +++ b/arch/ppc/platforms/4xx/ocotea.c
> @@ -248,8 +248,8 @@ ocotea_early_serial_map(void)
> port.irq = UART0_INT;
> port.uartclk = clocks.uart0;
> port.regshift = 0;
> - port.iotype = SERIAL_IO_MEM;
> - port.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST;
> + port.iotype = UPIO_MEM;
> + port.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST;
> port.line = 0;
>
> if (early_serial_setup(&port) != 0) {
> diff --git a/arch/ppc/platforms/4xx/xilinx_ml300.c b/arch/ppc/platforms/4xx/xilinx_ml300.c
> --- a/arch/ppc/platforms/4xx/xilinx_ml300.c
> +++ b/arch/ppc/platforms/4xx/xilinx_ml300.c
> @@ -95,8 +95,8 @@ ml300_early_serial_map(void)
> port.irq = old_ports[i].irq;
> port.uartclk = old_ports[i].baud_base * 16;
> port.regshift = old_ports[i].iomem_reg_shift;
> - port.iotype = SERIAL_IO_MEM;
> - port.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST;
> + port.iotype = UPIO_MEM;
> + port.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST;
> port.line = i;
>
> if (early_serial_setup(&port) != 0) {
> diff --git a/arch/ppc/platforms/4xx/yucca.c b/arch/ppc/platforms/4xx/yucca.c
> --- a/arch/ppc/platforms/4xx/yucca.c
> +++ b/arch/ppc/platforms/4xx/yucca.c
> @@ -305,8 +305,8 @@ yucca_early_serial_map(void)
> port.irq = UART0_INT;
> port.uartclk = clocks.uart0;
> port.regshift = 0;
> - port.iotype = SERIAL_IO_MEM;
> - port.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST;
> + port.iotype = UPIO_MEM;
> + port.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST;
> port.line = 0;
>
> if (early_serial_setup(&port) != 0) {
> diff --git a/arch/ppc/platforms/spruce.c b/arch/ppc/platforms/spruce.c
> --- a/arch/ppc/platforms/spruce.c
> +++ b/arch/ppc/platforms/spruce.c
> @@ -176,8 +176,8 @@ spruce_early_serial_map(void)
> memset(&serial_req, 0, sizeof(serial_req));
> serial_req.uartclk = uart_clk;
> serial_req.irq = UART0_INT;
> - serial_req.flags = ASYNC_BOOT_AUTOCONF;
> - serial_req.iotype = SERIAL_IO_MEM;
> + serial_req.flags = UPF_BOOT_AUTOCONF;
> + serial_req.iotype = UPIO_MEM;
> serial_req.membase = (u_char *)UART0_IO_BASE;
> serial_req.regshift = 0;
>
> diff --git a/drivers/serial/ioc4_serial.c b/drivers/serial/ioc4_serial.c
> --- a/drivers/serial/ioc4_serial.c
> +++ b/drivers/serial/ioc4_serial.c
> @@ -1717,11 +1717,9 @@ ioc4_change_speed(struct uart_port *the_
> }
>
> if (cflag & CRTSCTS) {
> - info->flags |= ASYNC_CTS_FLOW;
> port->ip_sscr |= IOC4_SSCR_HFC_EN;
> }
> else {
> - info->flags &= ~ASYNC_CTS_FLOW;
> port->ip_sscr &= ~IOC4_SSCR_HFC_EN;
> }
> writel(port->ip_sscr, &port->ip_serial_regs->sscr);
> @@ -1760,18 +1758,6 @@ static inline int ic4_startup_local(stru
>
> info = the_port->info;
>
> - if (info->tty) {
> - set_bit(TTY_IO_ERROR, &info->tty->flags);
> - clear_bit(TTY_IO_ERROR, &info->tty->flags);
> - if ((info->flags & ASYNC_SPD_MASK) == ASYNC_SPD_HI)
> - info->tty->alt_speed = 57600;
> - if ((info->flags & ASYNC_SPD_MASK) == ASYNC_SPD_VHI)
> - info->tty->alt_speed = 115200;
> - if ((info->flags & ASYNC_SPD_MASK) == ASYNC_SPD_SHI)
> - info->tty->alt_speed = 230400;
> - if ((info->flags & ASYNC_SPD_MASK) == ASYNC_SPD_WARP)
> - info->tty->alt_speed = 460800;
> - }
> local_open(port);
>
> /* set the speed of the serial port */
> diff --git a/drivers/serial/m32r_sio.c b/drivers/serial/m32r_sio.c
> --- a/drivers/serial/m32r_sio.c
> +++ b/drivers/serial/m32r_sio.c
> @@ -80,7 +80,7 @@
> #include <asm/serial.h>
>
> /* Standard COM flags */
> -#define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST)
> +#define STD_COM_FLAGS (UPF_BOOT_AUTOCONF | UPF_SKIP_TEST)
>
> /*
> * SERIAL_PORT_DFNS tells us about built-in ports that have no
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* Re: Yosemite/440EP why are readl()/ioread32() setup to readlittle-endian?
From: Eugene Surovegin @ 2006-02-02 9:46 UTC (permalink / raw)
To: Jenkins, Clive; +Cc: linuxppc-embedded
In-Reply-To: <35786B99AB3FDC45A8215724617919736D921C@gbrwgceumf01.eu.xerox.net>
On Thu, Feb 02, 2006 at 09:35:56AM -0000, Jenkins, Clive wrote:
> A driver for some device that could be connected to (or plugged into)
> a variety of different platforms of different architecture.
> A driver for a core that could be implemented within an FPGA on
> multiple platforms.
Well, this is all nice but I was wondering about _real_ examples.
When you are talking about "connecting" or "plugging" you have to keep
in mind actual bus interconnect. So far AFAIK PCI (and derivatives)
are the only cross-arch bus.
So basically, you have no _real_ life examples, so I'm wondering why
people need this "arch-independent" non-PCI I/O accessors for
something which doesn't exist.
I think the reason why Linux doesn't have this stuff follows from the
previous paragraph.
--
Eugene
^ permalink raw reply
* RE: Yosemite/440EP why are readl()/ioread32() setup to readlittle-endian?
From: Jenkins, Clive @ 2006-02-02 9:35 UTC (permalink / raw)
To: Eugene Surovegin, Peter Korsgaard; +Cc: linuxppc-embedded
A driver for some device that could be connected to (or plugged into)
a variety of different platforms of different architecture.
A driver for a core that could be implemented within an FPGA on
multiple platforms.
Clive
-----Original Message-----
From: Eugene Surovegin [mailto:ebs@ebshome.net]=20
Sent: 02 February 2006 09:08
To: Peter Korsgaard
Cc: Kumar Gala; linuxppc-embedded@ozlabs.org; Jenkins, Clive
Subject: Re: Yosemite/440EP why are readl()/ioread32() setup to
readlittle-endian?
On Thu, Feb 02, 2006 at 09:09:17AM +0100, Peter Korsgaard wrote:
> On 2/2/06, Kumar Gala <galak@kernel.crashing.org> wrote:
> > > What is the preferred way of accessing non-PCI devices then?
Direct
> > > pointer access?
> >
> > No direct pointer access is bad. On PPC You can use
> > in_be{8,16,32}/out_be{8,16,32}
>=20
> What about arch independent drivers? Are there any generic approach
> for this or do you have to stick to ugly #ifdefs to decide between
> in_be32/inl ?
I'm curious, could you give an example of such arch independent=20
driver?
--=20
Eugene
^ permalink raw reply
* Re: Yosemite/440EP why are readl()/ioread32() setup to readlittle-endian?
From: Eugene Surovegin @ 2006-02-02 9:08 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: Jenkins, Clive, linuxppc-embedded
In-Reply-To: <9305ca410602020009r4946d874qc52c2b27f715370f@mail.gmail.com>
On Thu, Feb 02, 2006 at 09:09:17AM +0100, Peter Korsgaard wrote:
> On 2/2/06, Kumar Gala <galak@kernel.crashing.org> wrote:
> > > What is the preferred way of accessing non-PCI devices then? Direct
> > > pointer access?
> >
> > No direct pointer access is bad. On PPC You can use
> > in_be{8,16,32}/out_be{8,16,32}
>
> What about arch independent drivers? Are there any generic approach
> for this or do you have to stick to ugly #ifdefs to decide between
> in_be32/inl ?
I'm curious, could you give an example of such arch independent
driver?
--
Eugene
^ permalink raw reply
* Re: Yosemite/440EP why are readl()/ioread32() setup to readlittle-endian?
From: Peter Korsgaard @ 2006-02-02 8:09 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded, Jenkins, Clive
In-Reply-To: <Pine.LNX.4.44.0602011851490.22854-100000@gate.crashing.org>
On 2/2/06, Kumar Gala <galak@kernel.crashing.org> wrote:
> > What is the preferred way of accessing non-PCI devices then? Direct
> > pointer access?
>
> No direct pointer access is bad. On PPC You can use
> in_be{8,16,32}/out_be{8,16,32}
What about arch independent drivers? Are there any generic approach
for this or do you have to stick to ugly #ifdefs to decide between
in_be32/inl ?
--
Bye, Peter Korsgaard
^ permalink raw reply
* problem with writing data to serialdriver form userspace
From: bharathi kandimalla @ 2006-02-02 5:57 UTC (permalink / raw)
To: jagadish, linuxppc-embedded@ozlabs.org, ram krishna
[-- Attachment #1: Type: text/plain, Size: 1353 bytes --]
Hi
I am able to use the serialport uart drivers for the custom board with mpc860T
which are available in the kernel 2.6.13
I am getting bootup messages like this
ttyCPM0 at MMIO 0xfb000a80 (irq = 20) is a CPM UART
ttyCPM1 at MMIO 0xfb000a90 (irq = 19) is a CPM UART
ttyCPM2 at MMIO 0xfb000a00 (irq = 46) is a CPM UART
ttyCPM3 at MMIO 0xfb000a20 (irq = 45) is a CPM UART
And after getting prompt
cd /proc/dev/
cat drivers
/dev/tty /dev/tty 5 0 system:/dev/tty
/dev/console /dev/console 5 1 system:console
/dev/ptmx /dev/ptmx 5 2 system
ttyCPM /dev/ttyCPM 204 46-49 serial
pty_slave /dev/pts 136 0-1048575 pty:slave
pty_master /dev/ptm 128 0-1048575 pty:master
I am using mknod command
mknod /dev/ttyCPM0 c 204 46
mknod /dev/ttyCPM1 c 204 47
mknod /dev/ttyCPM2 c 204 48
mknod /dev/ttyCPM3 c 204 49
even I am not able to open the device from the user space application
I want to write some data from the user space into the
application
But I am not able to open the device
please help me out
regards
bharathi
---------------------------------
Yahoo! Autos. Looking for a sweet ride? Get pricing, reviews, & more on new and used cars.
[-- Attachment #2: Type: text/html, Size: 2689 bytes --]
^ permalink raw reply
* Re: Yosemite/440EP why are readl()/ioread32() setup to readlittle-endian?
From: Matt Porter @ 2006-02-02 3:07 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded, Jenkins, Clive
In-Reply-To: <Pine.LNX.4.44.0602011851490.22854-100000@gate.crashing.org>
On Wed, Feb 01, 2006 at 06:54:09PM -0600, Kumar Gala wrote:
> On Wed, 1 Feb 2006, Peter Korsgaard wrote:
>
> > >>>>> "Matt" == Matt Porter <mporter@kernel.crashing.org> writes:
> >
> > Matt> read*/write* and ioread*/iowrite* generate outbound little
> > Matt> endian cycles on ALL arches, period. They are intended
> > Matt> only for PCI use and have generic names only because of
> > Matt> the assumption that "all the world is a PC".
> >
> > What is the preferred way of accessing non-PCI devices then? Direct
> > pointer access?
>
> No direct pointer access is bad. On PPC You can use
> in_be{8,16,32}/out_be{8,16,32}
Ack. Also, it should be pointed out that there are countless
examples of PPC drivers where this is done properly. 4xx, 83xx,
85xx, etc. on-chip peripherals all do this since they are
naturally BE registers.
-Matt
^ permalink raw reply
* Re: Yosemite/440EP why are readl()/ioread32() setup to readlittle-endian?
From: Kumar Gala @ 2006-02-02 0:54 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-embedded, Jenkins, Clive
In-Reply-To: <87wtgeeq8o.fsf@48ers.dk>
On Wed, 1 Feb 2006, Peter Korsgaard wrote:
> >>>>> "Matt" == Matt Porter <mporter@kernel.crashing.org> writes:
>
> Matt> read*/write* and ioread*/iowrite* generate outbound little
> Matt> endian cycles on ALL arches, period. They are intended
> Matt> only for PCI use and have generic names only because of
> Matt> the assumption that "all the world is a PC".
>
> What is the preferred way of accessing non-PCI devices then? Direct
> pointer access?
No direct pointer access is bad. On PPC You can use
in_be{8,16,32}/out_be{8,16,32}
- kumar
^ permalink raw reply
* Re: Yosemite/440EP why are readl()/ioread32() setup to readlittle-endian?
From: Peter Korsgaard @ 2006-02-01 21:14 UTC (permalink / raw)
To: Matt Porter; +Cc: Jenkins, Clive, linuxppc-embedded
In-Reply-To: <20060201104405.C16064@cox.net>
>>>>> "Matt" == Matt Porter <mporter@kernel.crashing.org> writes:
Matt> read*/write* and ioread*/iowrite* generate outbound little
Matt> endian cycles on ALL arches, period. They are intended
Matt> only for PCI use and have generic names only because of
Matt> the assumption that "all the world is a PC".
What is the preferred way of accessing non-PCI devices then? Direct
pointer access?
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: Yosemite/440EP why are readl()/ioread32() setup to readlittle-endian?
From: David Hawkins @ 2006-02-01 20:35 UTC (permalink / raw)
To: Jenkins, Clive; +Cc: linuxppc-embedded
In-Reply-To: <35786B99AB3FDC45A8215724617919736D921B@gbrwgceumf01.eu.xerox.net>
> I said this without looking up the example you cited.
> I agree now, the example is incorrect; and yes, file a bug
> report at oreilly!
Ok, I will.
> I think, from memory, that elsewhere in the book Rubini does
> say that readl()... are for the PCI bus, but cross-arch issues
> are only addressed in certain sections.
I didn't find anything that specifically mentioned their
use was for the PCI bus only. The endianness swapping
features of the pci_config_xxx functions are clearly
stated, but not the readl/writel. And of course the
example I refer to clearly uses those functions on the
PCI bus incorrectly.
But its still a great book.
> I always find out exactly what these macros do on the arch
> I am using, then I know where I stand. I find LXR (Google it if
> you don't know it) good for browsing the source of vanilla
> kernels. After finding out how and where it is done, I then
> double check the relevant files of the actual kernel I am using.
>
> ppc implementations of readl, writel, cpu_to_le32 use the byte-
> reversed load/store word instructions.
Ahh, very good advice. I think I read about LXR in one of
Freescale's app notes on porting Linux. I'll go take a look
on Google.
Thanks
Dave
^ permalink raw reply
* Re: Yosemite/440EP why are readl()/ioread32() setup to readlittle-endian?
From: Eugene Surovegin @ 2006-02-01 18:23 UTC (permalink / raw)
To: David Hawkins
In-Reply-To: <43E0FBFA.10103@ovro.caltech.edu>
On Wed, Feb 01, 2006 at 10:20:42AM -0800, David Hawkins wrote:
> Eugene Surovegin wrote:
> >On Wed, Feb 01, 2006 at 10:04:15AM -0800, David Hawkins wrote:
> >
> >>Matt,
> >>
> >>In the same vein as the readl()/writel() question, what
> >>are the assumptions regarding memcpy_toio and memcpy_fromio?
> >>
> >>If the memcpy_to/fromio operations are intended only
> >>for access to PCI devices, then they should also inherently
> >>perform little-endianness conversion. For the test driver
> >>I was working on, I did *not* find this the case, eg.
> >>I implemented the test driver read() and write() using the
> >>memcpy_to/fromio calls, and the data transfers occur
> >>in big-endian (well, 'native' mode, since I also test the
> >>same test driver with the PCI adapter in an x86 system).
> >>
> >>If memcpy_to/fromio can be used in a more general context,
> >>then I can see why they operate in native mode.
> >>
> >>Just looking for enlightenment.
> >
> >
> >This commands IIRC are intended for copying chunk of _bytes_. There
> >are no issues with endianess for bytes, e.g. they work just like
> >ordinary memcpy.
> >
>
> True, good point.
>
> I quite often implement a 'control' device to read/write/mmap PCI
> device registers. In that case, the registers are usually 32-bit, so
> if I wanted endian neutrality, I could either let the user-space
> app determine the endianness and act accordingly, or force the
> user-space app to always see little-endian registers by replacing
> memcpy_to/fromio calls with a loop over read;/writel,
You seem to assume that memcpy should do 32-bit reads/writes. Why not
16-bit ones? That's why memcpy cannot do any byte swapping, because it
can "theoretically" do 2 different types of it (16-bit and 32-bit),
which is obviously not specified in memcpy interface.
--
Eugene
^ permalink raw reply
* RE: Yosemite/440EP why are readl()/ioread32() setup to readlittle-endian?
From: Jenkins, Clive @ 2006-02-01 18:35 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
>>>p453 of his book has a PCI DMA example, where he uses the
>>>cpu_to_le32() macros inside calls writel().
>>>However, since these functions are internally implemented to
>>>perform LE operations, this example appears to be incorrect.
>>>Would you agree?
=20
>> No, I think it is correct.
I said this without looking up the example you cited.
I agree now, the example is incorrect; and yes, file a bug
report at oreilly!
I think, from memory, that elsewhere in the book Rubini does
say that readl()... are for the PCI bus, but cross-arch issues
are only addressed in certain sections.
I always find out exactly what these macros do on the arch
I am using, then I know where I stand. I find LXR (Google it if
you don't know it) good for browsing the source of vanilla
kernels. After finding out how and where it is done, I then
double check the relevant files of the actual kernel I am using.
ppc implementations of readl, writel, cpu_to_le32 use the byte-
reversed load/store word instructions.
Clive
^ permalink raw reply
* Re: Yosemite/440EP why are readl()/ioread32() setup to readlittle-endian?
From: David Hawkins @ 2006-02-01 18:20 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
In-Reply-To: <20060201181106.GA24138@gate.ebshome.net>
Eugene Surovegin wrote:
> On Wed, Feb 01, 2006 at 10:04:15AM -0800, David Hawkins wrote:
>
>>Matt,
>>
>>In the same vein as the readl()/writel() question, what
>>are the assumptions regarding memcpy_toio and memcpy_fromio?
>>
>>If the memcpy_to/fromio operations are intended only
>>for access to PCI devices, then they should also inherently
>>perform little-endianness conversion. For the test driver
>>I was working on, I did *not* find this the case, eg.
>>I implemented the test driver read() and write() using the
>>memcpy_to/fromio calls, and the data transfers occur
>>in big-endian (well, 'native' mode, since I also test the
>>same test driver with the PCI adapter in an x86 system).
>>
>>If memcpy_to/fromio can be used in a more general context,
>>then I can see why they operate in native mode.
>>
>>Just looking for enlightenment.
>
>
> This commands IIRC are intended for copying chunk of _bytes_. There
> are no issues with endianess for bytes, e.g. they work just like
> ordinary memcpy.
>
True, good point.
I quite often implement a 'control' device to read/write/mmap PCI
device registers. In that case, the registers are usually 32-bit, so
if I wanted endian neutrality, I could either let the user-space
app determine the endianness and act accordingly, or force the
user-space app to always see little-endian registers by replacing
memcpy_to/fromio calls with a loop over read;/writel, and in mmap
making sure to set the _PAGE_ENDIAN flag. Of course, making mmap
endian-neutral depends on the 440EP page flags, which say an
ARM might not have.
Thanks for the valuable feedback guys.
Dave
^ permalink raw reply
* Re: Yosemite/440EP why are readl()/ioread32() setup to readlittle-endian?
From: Eugene Surovegin @ 2006-02-01 18:11 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <43E0F81F.4050005@ovro.caltech.edu>
On Wed, Feb 01, 2006 at 10:04:15AM -0800, David Hawkins wrote:
> Matt,
>
> In the same vein as the readl()/writel() question, what
> are the assumptions regarding memcpy_toio and memcpy_fromio?
>
> If the memcpy_to/fromio operations are intended only
> for access to PCI devices, then they should also inherently
> perform little-endianness conversion. For the test driver
> I was working on, I did *not* find this the case, eg.
> I implemented the test driver read() and write() using the
> memcpy_to/fromio calls, and the data transfers occur
> in big-endian (well, 'native' mode, since I also test the
> same test driver with the PCI adapter in an x86 system).
>
> If memcpy_to/fromio can be used in a more general context,
> then I can see why they operate in native mode.
>
> Just looking for enlightenment.
This commands IIRC are intended for copying chunk of _bytes_. There
are no issues with endianess for bytes, e.g. they work just like
ordinary memcpy.
--
Eugene
^ permalink raw reply
* Re: Yosemite/440EP why are readl()/ioread32() setup to readlittle-endian?
From: David Hawkins @ 2006-02-01 18:04 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-embedded
In-Reply-To: <20060201104405.C16064@cox.net>
Matt,
In the same vein as the readl()/writel() question, what
are the assumptions regarding memcpy_toio and memcpy_fromio?
If the memcpy_to/fromio operations are intended only
for access to PCI devices, then they should also inherently
perform little-endianness conversion. For the test driver
I was working on, I did *not* find this the case, eg.
I implemented the test driver read() and write() using the
memcpy_to/fromio calls, and the data transfers occur
in big-endian (well, 'native' mode, since I also test the
same test driver with the PCI adapter in an x86 system).
If memcpy_to/fromio can be used in a more general context,
then I can see why they operate in native mode.
Just looking for enlightenment.
Cheers
Dave
^ permalink raw reply
* Re: Yosemite/440EP why are readl()/ioread32() setup to readlittle-endian?
From: David Hawkins @ 2006-02-01 17:53 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-embedded, Jenkins, Clive
In-Reply-To: <20060201104405.C16064@cox.net>
> The book implicitly focuses on x86 driver developers, that's
> why you don't get an explicit statement about this...
> "everything" is PCI in that world.
>
> read*/write* and ioread*/iowrite* generate outbound little
> endian cycles on ALL arches, period. They are intended
> only for PCI use and have generic names only because of
> the assumption that "all the world is a PC".
>
> Now, what it takes to to generate outbound little endian cycles
> varies. On some arches, it's just a store (native LE) on
> other arches, it's a reversed store (PPC), others still configure
> their PCI bridge hardware to do byte swapping in hardware (typically
> if their arch doesn't have a simple byte-swapping store like PPC).
>
> The example you cite on pg. 453 of Rubini looks broken for BE
> systems. It works on LE systems since cpu_to_le32() does nothing
> and writel is a simply dereference. That's pure luck. On PPC,
> for example, that would write a big endian bus_addr to the fictitious
> PCI device which is not what they want.
Great! An authoritive answer!
Re: endianness, even cooler on the 440EP, in your mmap()
implementation you can set the _PAGE_ENDIAN flag, and
user-space will see the PCI device in little endian
format. Fun stuff!
Thanks Matt.
Dave
^ permalink raw reply
* Re: Yosemite/440EP why are readl()/ioread32() setup to readlittle-endian?
From: Matt Porter @ 2006-02-01 17:44 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded, Jenkins, Clive
In-Reply-To: <43E0E9A7.4040508@ovro.caltech.edu>
On Wed, Feb 01, 2006 at 09:02:31AM -0800, David Hawkins wrote:
> Jenkins, Clive wrote:
> >>>>readl() and ioread32() read the registers in little-endian format!
> >>>
> >>>Correct. That's how it is implemented on all platforms. Think for
> >>>example of an pci device driver. Using these IO functions, the
> >>>driver will become platform independent, running without
> >>>modifications on little- and big-endian machines.
> >>
> >>I just stumbled across the section in Rubini 3rd Ed that mislead
> >>me into believing that the readl()/writel() were machine endianness
> >>dependent, i.e., LE on x86, BE on PPC.
> >
> >
> >>p453 of his book has a PCI DMA example, where he uses the
> >>cpu_to_le32() macros inside calls writel().
> >
> >
> >>However, since these functions are internally implemented to
> >>perform LE operations, this example appears to be incorrect.
> >
> >
> >>Would you agree?
> >
> >
> > No, I think it is correct.
> >
> > On most architectures readl() and writel() assume you are
> > accessing MMIO on the PCI bus, which is little-endian.
> > So these macros convert between the endian-ness of the CPU
> > and the endian-ness of the PCI bus.
> >
> > Clive
>
> Hey Clive,
>
> Right, but in the 440EP source, and probably on other PowerPC
> ports, readl() and writel() perform the endian conversion for
> you, so if you wrote an operation as
>
> writel(register_address, cpu_to_le32(data));
>
> you would get *two* little endian conversions, i.e., you
> would write the bytes in the wrong order.
>
> I haven't looked in the source for other big-endian architecures
> yet. I wonder if the ARM stuff is big, or little endian?
Both
> The original question came about while I was trying to read
> back PLX-9054 registers (a PCI-to-local bus bridge on a PCI
> adapter board).
Those regs are little endian since it's a PCI device. You
use the old read*/write* or new ioread*/iowrite* since it's
a PCI device.
> I search through the other drivers for the 440EP peripherals
> that are not on the PCI bus showed that the authors used
> the in_be32() and out_be32() calls. The comment at the top
> of this email indicates that the readl() and writel() are
> effectively 'reserved' for PCI accesses. I didn't get this
> impression from reading Rubini.
The book implicitly focuses on x86 driver developers, that's
why you don't get an explicit statement about this...
"everything" is PCI in that world.
read*/write* and ioread*/iowrite* generate outbound little
endian cycles on ALL arches, period. They are intended
only for PCI use and have generic names only because of
the assumption that "all the world is a PC".
Now, what it takes to to generate outbound little endian cycles
varies. On some arches, it's just a store (native LE) on
other arches, it's a reversed store (PPC), others still configure
their PCI bridge hardware to do byte swapping in hardware (typically
if their arch doesn't have a simple byte-swapping store like PPC).
The example you cite on pg. 453 of Rubini looks broken for BE
systems. It works on LE systems since cpu_to_le32() does nothing
and writel is a simply dereference. That's pure luck. On PPC,
for example, that would write a big endian bus_addr to the fictitious
PCI device which is not what they want.
-Matt
^ permalink raw reply
* Re: MPC8272ADS Hangs with gcc 4.0.0 and u-boot 1.1.4
From: Addison Baldwin @ 2006-02-01 17:27 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <af313df20602010926o305b24b6p555843ed96bbf491@mail.gmail.com>
Really sorry!
I sent this message to the wrong list.
I'll send it to the U-Boot.
Regards,
Addison Baldwin
On 2/1/06, Addison Baldwin <addison.baldwin@gmail.com> wrote:
> Hi developers
>
> I have a MPC8272ADS board, from Freescale. I'm using low-boot
> configuration (HRCW is 0x0E_74_B2_0A).
>
> I have ELDK 3.1 and ELDK 4.0 installed. I'm using U-Boot 1.1.4. When I
> compile U-Boot with GCC 3.3.3, the board works ok, but not with GCC
> 4.0.0. All the ethernet leds freeze turned on and the Run led too. It
> makes me thinking the board entered some loop state. Nothing appears
> at serial port.
>
> If anyone had this problem, or if anyone have such a configuration
> working (GCC 4 and U-Boot 1.1.4 with this board), any help will be
> very appreciated.
>
> Regards,
> Addison Baldwin
>
^ permalink raw reply
* MPC8272ADS Hangs with gcc 4.0.0 and u-boot 1.1.4
From: Addison Baldwin @ 2006-02-01 17:26 UTC (permalink / raw)
To: linuxppc-embedded
Hi developers
I have a MPC8272ADS board, from Freescale. I'm using low-boot
configuration (HRCW is 0x0E_74_B2_0A).
I have ELDK 3.1 and ELDK 4.0 installed. I'm using U-Boot 1.1.4. When I
compile U-Boot with GCC 3.3.3, the board works ok, but not with GCC
4.0.0. All the ethernet leds freeze turned on and the Run led too. It
makes me thinking the board entered some loop state. Nothing appears
at serial port.
If anyone had this problem, or if anyone have such a configuration
working (GCC 4 and U-Boot 1.1.4 with this board), any help will be
very appreciated.
Regards,
Addison Baldwin
^ permalink raw reply
* Re: Yosemite/440EP why are readl()/ioread32() setup to readlittle-endian?
From: David Hawkins @ 2006-02-01 17:02 UTC (permalink / raw)
To: Jenkins, Clive; +Cc: linuxppc-embedded
In-Reply-To: <35786B99AB3FDC45A8215724617919736D9217@gbrwgceumf01.eu.xerox.net>
Jenkins, Clive wrote:
>>>>readl() and ioread32() read the registers in little-endian format!
>>>
>>>Correct. That's how it is implemented on all platforms. Think for
>>>example of an pci device driver. Using these IO functions, the
>>>driver will become platform independent, running without
>>>modifications on little- and big-endian machines.
>>
>>I just stumbled across the section in Rubini 3rd Ed that mislead
>>me into believing that the readl()/writel() were machine endianness
>>dependent, i.e., LE on x86, BE on PPC.
>
>
>>p453 of his book has a PCI DMA example, where he uses the
>>cpu_to_le32() macros inside calls writel().
>
>
>>However, since these functions are internally implemented to
>>perform LE operations, this example appears to be incorrect.
>
>
>>Would you agree?
>
>
> No, I think it is correct.
>
> On most architectures readl() and writel() assume you are
> accessing MMIO on the PCI bus, which is little-endian.
> So these macros convert between the endian-ness of the CPU
> and the endian-ness of the PCI bus.
>
> Clive
Hey Clive,
Right, but in the 440EP source, and probably on other PowerPC
ports, readl() and writel() perform the endian conversion for
you, so if you wrote an operation as
writel(register_address, cpu_to_le32(data));
you would get *two* little endian conversions, i.e., you
would write the bytes in the wrong order.
I haven't looked in the source for other big-endian architecures
yet. I wonder if the ARM stuff is big, or little endian?
The original question came about while I was trying to read
back PLX-9054 registers (a PCI-to-local bus bridge on a PCI
adapter board).
I search through the other drivers for the 440EP peripherals
that are not on the PCI bus showed that the authors used
the in_be32() and out_be32() calls. The comment at the top
of this email indicates that the readl() and writel() are
effectively 'reserved' for PCI accesses. I didn't get this
impression from reading Rubini.
Thanks for you comments. Feel free to add more comments!
Cheers
Dave
^ permalink raw reply
* RE: Yosemite/440EP why are readl()/ioread32() setup to readlittle-endian?
From: Jenkins, Clive @ 2006-02-01 11:19 UTC (permalink / raw)
To: David Hawkins, Stefan Roese; +Cc: linuxppc-embedded
> >>readl() and ioread32() read the registers in little-endian format!
> >
> > Correct. That's how it is implemented on all platforms. Think for
> > example of an pci device driver. Using these IO functions, the
> > driver will become platform independent, running without
> > modifications on little- and big-endian machines.
>
> I just stumbled across the section in Rubini 3rd Ed that mislead
> me into believing that the readl()/writel() were machine endianness
> dependent, i.e., LE on x86, BE on PPC.
> p453 of his book has a PCI DMA example, where he uses the
> cpu_to_le32() macros inside calls writel().
> However, since these functions are internally implemented to
> perform LE operations, this example appears to be incorrect.
> Would you agree?
No, I think it is correct.
On most architectures readl() and writel() assume you are
accessing MMIO on the PCI bus, which is little-endian.
So these macros convert between the endian-ness of the CPU
and the endian-ness of the PCI bus.
Clive
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox