and wondered what __ioremap_at() is used for? It's nowhere defined.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Paul Mackerras <hidden> Date: 2000-09-19 03:59:02
Geert Uytterhoeven writes:
[snip]
+extern void *__ioremap_at(unsigned long phys, unsigned long size,
+ unsigned long flags);
and wondered what __ioremap_at() is used for? It's nowhere defined.
Ah, did that leak into the patch? It didn't need to go in but it
doesn't hurt I guess.
What I am intending to do is to map the I/O space of all the PCI host
bridges in consecutive areas beginning at some address such as
0xff000000, with some amount of space such as 64kB or 1MB per bridge,
whatever is appropriate. Then we adjust the I/O port numbers in the
pci_dev structures by adding on host_bridge_nr * space_per_bridge. As
a side effect, isa_io_base (which is really pci_io_base) becomes a
constant.
To do this we need a version of ioremap which takes a virtual address
as well as a physical address. This is what __ioremap_at was intended
to be. I got as far as duplicating the __ioremap declaration before
deciding that I needed to think about it a bit more. :-)
Specifically I need some input from people working on 8xx and prep
systems as to whether this idea will cause any problems. It may make
it more difficult to use a BAT to map I/O regions. I notice that prep
still uses isa_io_base = 0x80000000 and maps the whole 256MB starting
at 0x80000000 with a BAT.
Paul.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel Lanners <hidden> Date: 2000-09-19 05:56:26
Hi Paul,
On 19 Sep, this message from Paul Mackerras echoed through cyberspace:
What I am intending to do is to map the I/O space of all the PCI host
bridges in consecutive areas beginning at some address such as
0xff000000, with some amount of space such as 64kB or 1MB per bridge,
whatever is appropriate. Then we adjust the I/O port numbers in the
pci_dev structures by adding on host_bridge_nr * space_per_bridge. As
a side effect, isa_io_base (which is really pci_io_base) becomes a
constant.
Good idea. Keep in mind however, that not all bridges reserve the same
amount of space for IO. So you either need to cope with that, or chose
smaller, fixed-size regions, and be prepared to squeeze all devices into
that space. Which shouldn't be a problem, since I can't see why someone
would want to access something larger than a few bytes via IO...
Michel
-------------------------------------------------------------------------
Michel Lanners | " Read Philosophy. Study Art.
23, Rue Paul Henkes | Ask Questions. Make Mistakes.
L-1710 Luxembourg |
email mlan@cpu.lu |
http://www.cpu.lu/~mlan | Learn Always. "
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Dan Malek <hidden> Date: 2000-09-19 14:28:19
Paul Mackerras wrote:
What I am intending to do is to map the I/O space of all the PCI host
bridges in consecutive areas beginning at some address such as
0xff000000,
Hmmm.....
To do this we need a version of ioremap which takes a virtual address
as well as a physical address.
Hmmm.....
Specifically I need some input from people working on 8xx and prep
systems as to whether this idea will cause any problems.
OK. On the 8xx, I currently rely on the effect that ioremap will
map virt->phys 1:1 before the kernel VM is initialized. Often this
is space above 0xf0000000. Since I understand what you are trying to
do, I can probably change this will little effort. This brings up
another question....what happens if you ioremap before VM is set up?
Mapping through BATs usually covers most of this, but more processors
arriving (the IBM 4xx) don't have BATs either so we rely on page
tables of some sort.
The PReP machines (and I thought most systems) flip back and forth
between VM not/enabled during start up, and have a few things like
UARTs mapped 1:1 virt->phys (at least for debug).
In general, I like what you are doing because I am struggling to
find a better I/O mapping solution for some of these embedded
processors. In particular I need a bus_to_virt() (or whatever we
call it) that can work on mapped addresses. I was thinking about
fixing some virtual address ranges so I could do this more easily,
and you are sort of doing the same.
..... It may make
it more difficult to use a BAT to map I/O regions. I notice that prep
still uses isa_io_base = 0x80000000 and maps the whole 256MB starting
at 0x80000000 with a BAT.
Yes, that is a pretty nice feature......
I'm thinking.....(I'm thinking that Matt Porter should provide some
insight....he is used to working with Linux/PPC on systems with a
dozen or so PCI bridges....and likes it :-).
-- Dan
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Roman Zippel <hidden> Date: 2000-09-19 18:31:24
Hi,
OK. On the 8xx, I currently rely on the effect that ioremap will
map virt->phys 1:1 before the kernel VM is initialized.
I'm curious, what needs ioremap before the VM is ready?
Mapping through BATs usually covers most of this, but more processors
arriving (the IBM 4xx) don't have BATs either so we rely on page
tables of some sort.
Shouldn't it be possible, to add such stuff directly to the hash table
and add the official mapping later?
BTW the whole mm stuff really needs a big cleanup, but I don't really want
to touch it, as I could only test this on my APUS machine, which has only
the CPU in common with the other machines.
bye, Roman
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Dan Malek <hidden> Date: 2000-09-19 20:09:18
Roman Zippel wrote:
I'm curious, what needs ioremap before the VM is ready?
The IMMR (internal memory map to almost everything in the chip)
has to be mapped to provide access to a variety of bits for
initialization. On some boards, the board control/status register
has to be mapped and configured.
I hope people don't forget that this is done on other platforms
with BATs as well, it just isn't as obvious as the 4xx/8xx.
Shouldn't it be possible, to add such stuff directly to the hash table
and add the official mapping later?
In many cases (and certainly the 8xx) the mapping done early is assumed
to be the address used throughout the life of the system. Using one
set of mapping early, and then something else later is quite confusing
when you have global pointers like immr, you have to update internal
processor registers when it changes, and internal devices that you
previously initialized use the old value.
BTW the whole mm stuff really needs a big cleanup,
Heh...This quote has been in e-mail messages for years :-).
I don't think we need lots of changes, but it should continue to
evolve into something more efficient.
-- Dan
--
I like MMUs because I don't have a real life.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Roman Zippel <hidden> Date: 2000-09-19 23:42:35
Hi,
quoted
Shouldn't it be possible, to add such stuff directly to the hash table
and add the official mapping later?
In many cases (and certainly the 8xx) the mapping done early is assumed
to be the address used throughout the life of the system. Using one
set of mapping early, and then something else later is quite confusing
when you have global pointers like immr, you have to update internal
processor registers when it changes, and internal devices that you
previously initialized use the old value.
Fixed addresses shouldn't be that much of a problem. Either you allocate
them somewhere after VMALLOC_END or you adjust VMALLOC_START. I think
currently the first is done. Anyway, IMO the map_page() call can IMO be
delayed, we would only need a C implementation from parts hashtable.S,
what might be usefull for other stuff as well.
quoted
BTW the whole mm stuff really needs a big cleanup,
Heh...This quote has been in e-mail messages for years :-).
I don't think we need lots of changes, but it should continue to
evolve into something more efficient.
Something I would like to throw out first is mem_pieces.c. It can be
replaced now with the new bootmem stuff, but that would reqire to find
some piece unused piece of memory for the bootmem map, everything else can
then be nicely done with bootmem.
Most of the functions in mem_pieces.c are also in bootmem.c now, except
mem_pieces_sort()/mem_pieces_coalesce(). But the funny thing here is,
these two functions are only called by get_mem_prop(), which is only
called by pmac_find_end_of_memory(), which then is completly confused, if
doesn't find a single piece of memory starting at zero.
I could do the generic part, but I simply don't know all the machine
specific details, besides what I can read/guess from the source (I'm
already responsible for all the bugs in the m68k implementation, so I have
some experience with it. :) )
bye, Roman
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Dan Malek <hidden> Date: 2000-09-20 00:10:13
Roman Zippel wrote:
Fixed addresses shouldn't be that much of a problem.
They are no problem today....It would be nice if it stayed that way :-).
.... we would only need a C implementation from parts hashtable.S,
what might be usefull for other stuff as well.
Except only the 7xx (601?, 604) use the hastable. It's not a generic
MMU place.
Something I would like to throw out first is mem_pieces.c....
... pmac_find_end_of_memory(), which then is completly confused,
I am usually confused by this point, too :-). I then just tip-toe
away thinking there are better places I can spend my time.
-- Dan
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Roman Zippel <hidden> Date: 2000-09-20 17:18:57
Hi,
Except only the 7xx (601?, 604) use the hastable. It's not a generic
MMU place.
Hmm, I think I have to order some new documentation. :-)
What are some important cpus I should look into (except 60x)?
bye, Roman
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Dan Malek <hidden> Date: 2000-09-20 18:11:40
Roman Zippel wrote:
Hmm, I think I have to order some new documentation. :-)
What are some important cpus I should look into (except 60x)?
None of the embedded PowerPCs use a hash table, and the Book E
processors don't either. We avoid using the hash table when given
the option, like 603s. The "hardware assist" and subsequent hash
table is a PITA for Linux VM, and Cort has documented the performance
benefits of not using it.
-- Dan
--
I like MMUs because I don't have a real life.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Roman Zippel <hidden> Date: 2000-09-20 20:22:54
Hi,
On Wed, 20 Sep 2000, Dan Malek wrote:
None of the embedded PowerPCs use a hash table, and the Book E
processors don't either. We avoid using the hash table when given
the option, like 603s. The "hardware assist" and subsequent hash
table is a PITA for Linux VM, and Cort has documented the performance
benefits of not using it.
Oh, I forgot about that part. On m68k we have special init functions for
that, which use alloc_bootmem_low_pages(). It maybe should be splitted for
ppc too, so that we have a special (and very simple) remap function, that
is only used during very early initialization and all the mem_init_done
checks could be removed.
bye, Roman
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/