* 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: 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: 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: 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
* 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: 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
* 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: 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: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: [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 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: 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() 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: 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: [patch 14/44] generic hweight{64,32,16,8}()
From: Akinobu Mita @ 2006-02-02 12:50 UTC (permalink / raw)
To: Andi Kleen
Cc: linux-mips, linux-ia64, Ian Molton, Michael Tokarev,
David Howells, linuxppc-dev, Greg Ungerer, sparclinux,
Miles Bader, Yoshinori Sato, Hirokazu Takata, linuxsh-dev,
Linus Torvalds, Ivan Kokshaysky, Richard Henderson, Chris Zankel,
dev-etrax, ultralinux, linux-m68k, linux-kernel,
linuxsh-shmedia-dev, linux390, Russell King, parisc-linux
In-Reply-To: <200602011124.29423.ak@suse.de>
On Wed, Feb 01, 2006 at 11:24:27AM +0100, Andi Kleen wrote:
> On Wednesday 01 February 2006 10:26, Michael Tokarev wrote:
> > Andi Kleen wrote:
> > > On Wednesday 01 February 2006 10:02, Akinobu Mita wrote:
> > >
> > >>+static inline unsigned int hweight32(unsigned int w)
> > []
> > > How large are these functions on x86? Maybe it would be better to not inline them,
> > > but put it into some C file out of line.
> >
> > hweight8 47 bytes
> > hweight16 76 bytes
> > hweight32 97 bytes
> > hweight64 56 bytes (NOT inlining hweight32)
> > hweight64 197 bytes (inlining hweight32)
> >
> > Those are when compiled as separate non-inlined functions,
> > with pushl %ebp and ret.
>
> This would argue for moving them out of line.
This patch will put hweight*() into lib/hweight.c
Index: 2.6-git/include/asm-generic/bitops/hweight.h
===================================================================
--- 2.6-git.orig/include/asm-generic/bitops/hweight.h
+++ 2.6-git/include/asm-generic/bitops/hweight.h
@@ -1,54 +1,9 @@
#ifndef _ASM_GENERIC_BITOPS_HWEIGHT_H_
#define _ASM_GENERIC_BITOPS_HWEIGHT_H_
-#include <asm/types.h>
-
-/**
- * hweightN - returns the hamming weight of a N-bit word
- * @x: the word to weigh
- *
- * The Hamming Weight of a number is the total number of bits set in it.
- */
-
-static inline unsigned int hweight32(unsigned int w)
-{
- unsigned int res = (w & 0x55555555) + ((w >> 1) & 0x55555555);
- res = (res & 0x33333333) + ((res >> 2) & 0x33333333);
- res = (res & 0x0F0F0F0F) + ((res >> 4) & 0x0F0F0F0F);
- res = (res & 0x00FF00FF) + ((res >> 8) & 0x00FF00FF);
- return (res & 0x0000FFFF) + ((res >> 16) & 0x0000FFFF);
-}
-
-static inline unsigned int hweight16(unsigned int w)
-{
- unsigned int res = (w & 0x5555) + ((w >> 1) & 0x5555);
- res = (res & 0x3333) + ((res >> 2) & 0x3333);
- res = (res & 0x0F0F) + ((res >> 4) & 0x0F0F);
- return (res & 0x00FF) + ((res >> 8) & 0x00FF);
-}
-
-static inline unsigned int hweight8(unsigned int w)
-{
- unsigned int res = (w & 0x55) + ((w >> 1) & 0x55);
- res = (res & 0x33) + ((res >> 2) & 0x33);
- return (res & 0x0F) + ((res >> 4) & 0x0F);
-}
-
-static inline unsigned long hweight64(__u64 w)
-{
-#if BITS_PER_LONG == 32
- return hweight32((unsigned int)(w >> 32)) + hweight32((unsigned int)w);
-#elif BITS_PER_LONG == 64
- u64 res;
- res = (w & 0x5555555555555555ul) + ((w >> 1) & 0x5555555555555555ul);
- res = (res & 0x3333333333333333ul) + ((res >> 2) & 0x3333333333333333ul);
- res = (res & 0x0F0F0F0F0F0F0F0Ful) + ((res >> 4) & 0x0F0F0F0F0F0F0F0Ful);
- res = (res & 0x00FF00FF00FF00FFul) + ((res >> 8) & 0x00FF00FF00FF00FFul);
- res = (res & 0x0000FFFF0000FFFFul) + ((res >> 16) & 0x0000FFFF0000FFFFul);
- return (res & 0x00000000FFFFFFFFul) + ((res >> 32) & 0x00000000FFFFFFFFul);
-#else
-#error BITS_PER_LONG not defined
-#endif
-}
+extern unsigned int hweight32(unsigned int w);
+extern unsigned int hweight16(unsigned int w);
+extern unsigned int hweight8(unsigned int w);
+extern unsigned long hweight64(__u64 w);
#endif /* _ASM_GENERIC_BITOPS_HWEIGHT_H_ */
Index: 2.6-git/lib/Makefile
===================================================================
--- 2.6-git.orig/lib/Makefile
+++ 2.6-git/lib/Makefile
@@ -5,7 +5,7 @@
lib-y := errno.o ctype.o string.o vsprintf.o cmdline.o \
bust_spinlocks.o rbtree.o radix-tree.o dump_stack.o \
idr.o div64.o int_sqrt.o bitmap.o extable.o prio_tree.o \
- sha1.o
+ sha1.o hweight.o
lib-y += kobject.o kref.o kobject_uevent.o klist.o
Index: 2.6-git/lib/hweight.c
===================================================================
--- /dev/null
+++ 2.6-git/lib/hweight.c
@@ -0,0 +1,54 @@
+#include <linux/module.h>
+#include <asm/types.h>
+
+/**
+ * hweightN - returns the hamming weight of a N-bit word
+ * @x: the word to weigh
+ *
+ * The Hamming Weight of a number is the total number of bits set in it.
+ */
+
+unsigned int hweight32(unsigned int w)
+{
+ unsigned int res = (w & 0x55555555) + ((w >> 1) & 0x55555555);
+ res = (res & 0x33333333) + ((res >> 2) & 0x33333333);
+ res = (res & 0x0F0F0F0F) + ((res >> 4) & 0x0F0F0F0F);
+ res = (res & 0x00FF00FF) + ((res >> 8) & 0x00FF00FF);
+ return (res & 0x0000FFFF) + ((res >> 16) & 0x0000FFFF);
+}
+EXPORT_SYMBOL(hweight32);
+
+unsigned int hweight16(unsigned int w)
+{
+ unsigned int res = (w & 0x5555) + ((w >> 1) & 0x5555);
+ res = (res & 0x3333) + ((res >> 2) & 0x3333);
+ res = (res & 0x0F0F) + ((res >> 4) & 0x0F0F);
+ return (res & 0x00FF) + ((res >> 8) & 0x00FF);
+}
+EXPORT_SYMBOL(hweight16);
+
+unsigned int hweight8(unsigned int w)
+{
+ unsigned int res = (w & 0x55) + ((w >> 1) & 0x55);
+ res = (res & 0x33) + ((res >> 2) & 0x33);
+ return (res & 0x0F) + ((res >> 4) & 0x0F);
+}
+EXPORT_SYMBOL(hweight8);
+
+unsigned long hweight64(__u64 w)
+{
+#if BITS_PER_LONG == 32
+ return hweight32((unsigned int)(w >> 32)) + hweight32((unsigned int)w);
+#elif BITS_PER_LONG == 64
+ u64 res;
+ res = (w & 0x5555555555555555ul) + ((w >> 1) & 0x5555555555555555ul);
+ res = (res & 0x3333333333333333ul) + ((res >> 2) & 0x3333333333333333ul);
+ res = (res & 0x0F0F0F0F0F0F0F0Ful) + ((res >> 4) & 0x0F0F0F0F0F0F0F0Ful);
+ res = (res & 0x00FF00FF00FF00FFul) + ((res >> 8) & 0x00FF00FF00FF00FFul);
+ res = (res & 0x0000FFFF0000FFFFul) + ((res >> 16) & 0x0000FFFF0000FFFFul);
+ return (res & 0x00000000FFFFFFFFul) + ((res >> 32) & 0x00000000FFFFFFFFul);
+#else
+#error BITS_PER_LONG not defined
+#endif
+}
+EXPORT_SYMBOL(hweight64);
^ permalink raw reply
* Accessing the CPM2 on an MPC82xx : CPM_MAP_ADDR or cpm2_immr ?
From: Laurent Pinchart @ 2006-02-02 13:58 UTC (permalink / raw)
To: linuxppc-embedded
Hi everybody,
I noticed that the CPM2 module is accessed both through CPM_MAP_ADDR (physical
address) and cpm2_immr (ioremap()ed address). For instance, the fec_enet
driver configures the IO ports using (cpm2_map_t*)CPM_MAP_ADDR.
What's the correct way to access the CPM2 module ? Does ioremap() map
CPM_MAP_ADDR to itself so that both ways are correct ?
Laurent Pinchart
^ permalink raw reply
* Re: Accessing the CPM2 on an MPC82xx : CPM_MAP_ADDR or cpm2_immr ?
From: Vitaly Bordug @ 2006-02-02 14:07 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-embedded
In-Reply-To: <200602021458.26623.laurent.pinchart@tbox.biz>
On Thu, 2 Feb 2006 14:58:26 +0100
Laurent Pinchart <laurent.pinchart@tbox.biz> wrote:
> Hi everybody,
>
> I noticed that the CPM2 module is accessed both through CPM_MAP_ADDR (physical
> address) and cpm2_immr (ioremap()ed address). For instance, the fec_enet
> driver configures the IO ports using (cpm2_map_t*)CPM_MAP_ADDR.
>
Mentioned driver is deprecated.
> What's the correct way to access the CPM2 module ? Does ioremap() map
> CPM_MAP_ADDR to itself so that both ways are correct ?
>
Even direct cpm2_immr usage is not a good thing, but I cannot tell more without knowing your concerns. Can you please describe what you are planning to implement, prolly we can advice how to do that proper way.
> Laurent Pinchart
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: [CFT] Don't use ASYNC_* nor SERIAL_IO_* with serial_core
From: Hirokazu Takata @ 2006-02-02 14:10 UTC (permalink / raw)
To: rmk+lkml; +Cc: pfg, linux-mips, takata, linux-kernel, linuxppc-dev
In-Reply-To: <20060202102721.GE5034@flint.arm.linux.org.uk>
On m32r,
compile and boot test: OK
Thank you.
-- Takata
From: Russell King <rmk+lkml@arm.linux.org.uk>
Date: Thu, 02 Feb 2006 10:27:21 +0000
> 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.
...
> > drivers/serial/m32r_sio.c | 2 +-
> > 18 files changed, 32 insertions(+), 51 deletions(-)
...
> > +++ b/arch/mips/cobalt/setup.c
> > 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: Matt Porter @ 2006-02-02 14:21 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-embedded, Jenkins, Clive
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 ?
ioread*be()/iowrite*be() can be used for this. Since the generic
big endian accessors became a standard thing a little while back,
all the PPC on-chip drivers should move to that. It's just a matter
of time.
-Matt
^ permalink raw reply
* Re: [patch 14/44] generic hweight{64,32,16,8}()
From: Gabriel Paubert @ 2006-02-02 1:26 UTC (permalink / raw)
To: Akinobu Mita
Cc: linux-mips, linux-m68k, linux-ia64, Ian Molton, Andi Kleen,
David Howells, linuxppc-dev, Greg Ungerer, sparclinux,
Miles Bader, Yoshinori Sato, Hirokazu Takata, linuxsh-dev,
Linus Torvalds, Ivan Kokshaysky, Richard Henderson, Chris Zankel,
dev-etrax, ultralinux, linux-kernel, linuxsh-shmedia-dev,
linux390, Russell King, parisc-linux
In-Reply-To: <20060201090325.905071000@localhost.localdomain>
On Wed, Feb 01, 2006 at 06:02:38PM +0900, Akinobu Mita wrote:
>
> This patch introduces the C-language equivalents of the functions below:
>
> unsigned int hweight32(unsigned int w);
> unsigned int hweight16(unsigned int w);
> unsigned int hweight8(unsigned int w);
> unsigned long hweight64(__u64 w);
>
> In include/asm-generic/bitops/hweight.h
>
> This code largely copied from:
> include/linux/bitops.h
>
> Signed-off-by: Akinobu Mita <mita@miraclelinux.com>
> include/asm-generic/bitops/hweight.h | 54 +++++++++++++++++++++++++++++++++++
> 1 files changed, 54 insertions(+)
>
> Index: 2.6-git/include/asm-generic/bitops/hweight.h
> ===================================================================
> --- /dev/null
> +++ 2.6-git/include/asm-generic/bitops/hweight.h
> @@ -0,0 +1,54 @@
> +#ifndef _ASM_GENERIC_BITOPS_HWEIGHT_H_
> +#define _ASM_GENERIC_BITOPS_HWEIGHT_H_
> +
> +#include <asm/types.h>
> +
> +/**
> + * hweightN - returns the hamming weight of a N-bit word
> + * @x: the word to weigh
> + *
> + * The Hamming Weight of a number is the total number of bits set in it.
> + */
> +
> +static inline unsigned int hweight32(unsigned int w)
> +{
> + unsigned int res = (w & 0x55555555) + ((w >> 1) & 0x55555555);
> + res = (res & 0x33333333) + ((res >> 2) & 0x33333333);
> + res = (res & 0x0F0F0F0F) + ((res >> 4) & 0x0F0F0F0F);
> + res = (res & 0x00FF00FF) + ((res >> 8) & 0x00FF00FF);
> + return (res & 0x0000FFFF) + ((res >> 16) & 0x0000FFFF);
> +}
The first step can be implemented slightly better:
unsigned int res = w-((w>>1)&0x55555555);
as I found once on the web[1].
Several of the following steps can also be simplified
by omitting the masking when the result can't possibly
cause a carry to propagate too far.
This might also have a non negligible impact
on code size.
> +
> +static inline unsigned int hweight16(unsigned int w)
> +{
> + unsigned int res = (w & 0x5555) + ((w >> 1) & 0x5555);
> + res = (res & 0x3333) + ((res >> 2) & 0x3333);
> + res = (res & 0x0F0F) + ((res >> 4) & 0x0F0F);
> + return (res & 0x00FF) + ((res >> 8) & 0x00FF);
> +}
> +
> +static inline unsigned int hweight8(unsigned int w)
> +{
> + unsigned int res = (w & 0x55) + ((w >> 1) & 0x55);
> + res = (res & 0x33) + ((res >> 2) & 0x33);
> + return (res & 0x0F) + ((res >> 4) & 0x0F);
> +}
> +
> +static inline unsigned long hweight64(__u64 w)
> +{
> +#if BITS_PER_LONG == 32
> + return hweight32((unsigned int)(w >> 32)) + hweight32((unsigned int)w);
> +#elif BITS_PER_LONG == 64
> + u64 res;
> + res = (w & 0x5555555555555555ul) + ((w >> 1) & 0x5555555555555555ul);
> + res = (res & 0x3333333333333333ul) + ((res >> 2) & 0x3333333333333333ul);
> + res = (res & 0x0F0F0F0F0F0F0F0Ful) + ((res >> 4) & 0x0F0F0F0F0F0F0F0Ful);
> + res = (res & 0x00FF00FF00FF00FFul) + ((res >> 8) & 0x00FF00FF00FF00FFul);
> + res = (res & 0x0000FFFF0000FFFFul) + ((res >> 16) & 0x0000FFFF0000FFFFul);
> + return (res & 0x00000000FFFFFFFFul) + ((res >> 32) & 0x00000000FFFFFFFFul);
> +#else
> +#error BITS_PER_LONG not defined
> +#endif
> +}
> +
> +#endif /* _ASM_GENERIC_BITOPS_HWEIGHT_H_ */
>
Regards,
Gabriel
[1] It might be better to write the first line
unsigned res = w - ((w&0xaaaaaaaa)>>1);
but I can never remember what the C standard guarantess about
right shifts values (very little IIRC). I believe that it will
work properly on all architectures that GCC supports, however,
and that it will help on many.
^ permalink raw reply
* Re: Yosemite/440EP why are readl()/ioread32() setup to readlittle-endian?
From: Matt Porter @ 2006-02-02 14:37 UTC (permalink / raw)
To: Jenkins, Clive, Peter Korsgaard, Kumar Gala, linuxppc-embedded
In-Reply-To: <20060202094641.GB12810@gate.ebshome.net>
On Thu, Feb 02, 2006 at 01:46:41AM -0800, Eugene Surovegin wrote:
> 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.
I mentioned the BE iomap variants that are being used on some non-pci
parisc devices already. I'll give a partial example of something that
is non-pci yet "arch-independent".
Take a non-pci EHCI core (yes, I know it's little endian by definition
but suspend reality for a second). You can create an arch-independent
EHCI driver that uses the platform bus by using the iomap accessors.
Since these cores are licensed every day by XYZ startups for their
latest "gee-whiz" SoC, it reasons that you'll see the same core on
multiple licensable SoC architectures. I've seen one such thing
on MIPS.
We also know that major semiconductor companies do the same thing
for their peripherals in some cases. They're just as willing to
buy somebody else's USB core, for example. So, having a BE
non-pci device cross platform isn't a stretch.
Take a look at drivers/scsi/53c700.{c,h}. That generic driver
is why BE iomap accessors were added. It's in the process of
being shared between parisc and m68k.
-Matt
^ permalink raw reply
* Re: Yosemite/440EP why are readl()/ioread32() setuptoreadlittle-endian?
From: Matt Porter @ 2006-02-02 14:39 UTC (permalink / raw)
To: Jenkins, Clive; +Cc: linuxppc-embedded
In-Reply-To: <35786B99AB3FDC45A8215724617919736D921E@gbrwgceumf01.eu.xerox.net>
On Thu, Feb 02, 2006 at 11:26:22AM -0000, Jenkins, Clive wrote:
> 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:
As I pointed out, there are such alternatives. The iomap interface
provides what you need.
-Matt
^ permalink raw reply
* RE: [patch 10/44] generic fls64()
From: Rune Torgersen @ 2006-02-02 15:05 UTC (permalink / raw)
To: Akinobu Mita, linux-kernel
Cc: linux-mips, linux-ia64, Ian Molton, David Howells, linuxppc-dev,
Greg Ungerer, sparclinux, Miles Bader, Linus Torvalds,
Yoshinori Sato, Hirokazu Takata, linuxsh-dev, linux-m68k,
Ivan Kokshaysky, Richard Henderson, Chris Zankel, dev-etrax,
ultralinux, Andi Kleen, linuxsh-shmedia-dev, linux390,
Russell King, parisc-linux
> From: Akinobu Mita
> Sent: Wednesday, February 01, 2006 03:03
> +static inline int fls64(__u64 x)
> +{
> + __u32 h =3D x >> 32;
> + if (h)
> + return fls(x) + 32;
Shouldn't this be return fls(h) + 32; ??
^^^
> + return fls(x);
> +}
> +
> +#endif /* _ASM_GENERIC_BITOPS_FLS64_H_ */
>=20
> --
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>=20
>=20
^ permalink raw reply
* Re: Accessing the CPM2 on an MPC82xx : CPM_MAP_ADDR or cpm2_immr ?
From: Laurent Pinchart @ 2006-02-02 15:42 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded
In-Reply-To: <20060202170753.2a805189@vitb.ru.mvista.com>
> > I noticed that the CPM2 module is accessed both through CPM_MAP_ADDR
> > (physical address) and cpm2_immr (ioremap()ed address). For instance, the
> > fec_enet driver configures the IO ports using (cpm2_map_t*)CPM_MAP_ADDR.
>
> Mentioned driver is deprecated.
It has been replaced by drivers/net/fs_enet, right ? The new driver doesn't
support the LXT971/LXT971A PHY chipsets yet, so I'm still using the old one.
> > What's the correct way to access the CPM2 module ? Does ioremap() map
> > CPM_MAP_ADDR to itself so that both ways are correct ?
>
> Even direct cpm2_immr usage is not a good thing, but I cannot tell more
> without knowing your concerns. Can you please describe what you are
> planning to implement, prolly we can advice how to do that proper way.
I'm currently just hacking IDMA transfers to make sure the signals we plan to
use on a custom design work as expected. I will later work on the USB host
controller driver.
The new fs_enet driver internally maps CPM_MAP_ADDR. Should every driver
create an internal CPM mapping ? Why was the old fec_enet driver able to
access the CPM through CPM_MAP_ADDR without ioremap()ing it first ?
Laurent Pinchart
^ permalink raw reply
* Is /sys/.../power/state supported ?
From: Giuliano Pochini @ 2006-02-02 15:45 UTC (permalink / raw)
To: linuxppc-dev
echo 3 > /sys/pci.../power/state does nothing on my machine.
I have a PMac dual-G4 MDD, linux 2.6.14 and of course
CONFIG_PM and debug are enabled. It writes nothing in the
logs and the value it reads from any device/power/state is
always 0, no matter what I wrote into it. I wonder if it is
supposed to work, or if it not supported yet... or maybe if
I'm missing something.
--
Giuliano.
^ 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