* Re: RFC: Deprecating io_block_mapping
From: Eugene Surovegin @ 2005-05-26 6:20 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded, linuxppc-dev list
In-Reply-To: <80f48eb53b0f876138cde07a997791b6@embeddededge.com>
On Thu, May 26, 2005 at 02:00:11AM -0400, Dan Malek wrote:
>
> >Well, The PCI IO space base just need to be in a global that is
> >referenced by _IO_BASE, it works fine, no need to hard code a mapping.
>
> Sure you do. No one ioremap()s PCI IO space. It has to be hard wired
> somewhere.
Dan, you must be kidding. 44x ioremaps PCI IO space, 40x uses
io_block_mapping for that, but this is just brain-damaged and should
be fixed.
What is so special about PCI IO space that it must be "wired" ?
[snip]
> You are missing the point. The reason for io_block_mapping() isn't
> to allocate virtual space for someone, it's to _wire_ a space using an
> efficient mapping method so someone else can call ioremap() and
> get that wired access.
Wow, this is something new for me. So you are saying that
io_block_mapping() was supposed to be used with ioremap()?
Could you point me to the port which actually does this?
So far I only saw io_block_mapping() used as a short-cut way _NOT_ to
ioremap and get hard-coded v:p mapping and then use this knowledge to
access physical address directly without ever calling ioremap(). And
this is major source of problems.
Also, by this logic, if platform doesn't have BAT or CAMs or whatever,
which effectively prevents creating this "efficient mapping" and
hence stated purpose of io_block_mapping cannot be achieved,
io_block_mapping() should be eliminated on this platform, right?
--
Eugene
^ permalink raw reply
* Re: RFC: Deprecating io_block_mapping
From: Dan Malek @ 2005-05-26 6:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <1117057460.5076.19.camel@gaston>
On May 25, 2005, at 5:44 PM, Benjamin Herrenschmidt wrote:
> This is a VERY BAD habit. Just set KERNELBASE to 0x80000000 if you do
> that, an use io_block_mapping() dynamically the way I explained to
> alloc
> from the top of the address space.
Well, back when kernelbase was assumed in too many places
to be 0xc0000000, it was the only option.
> Well, The PCI IO space base just need to be in a global that is
> referenced by _IO_BASE, it works fine, no need to hard code a mapping.
Sure you do. No one ioremap()s PCI IO space. It has to be hard wired
somewhere.
> PCI memory space doesn't rely on any of this unless your platform code
> is really screwy
To take advantage of BAT or CAM mapping, you need to wire these
entries in conjunction with the way you have configured your PCI
bridges. You also have to set up the arrays so ioremap() will find
them.
> Ugh ? Can you explain why it "doesn't have the proper effect" ?
Because you need a way to wire a virtual address mapping to
a physical space before you have any way of allocating virtual space.
It's a chicken/egg problem, since ioremap_bot doesn't have a value
until someone has set it, and you don't know where to set it until
the board set up has determined the mapping from configuration
options.
> No. If you read properly, you'll see that it will _not_ initialize it
> if
> it is 0, because the test virt < ioremap_bot will never be true (both
> are unsigned long) before MMU_init() is called.
I think we are talking past each other. The reason for that code
in io_block_mapping() is so you can set multiple BAT/CAM entries,
and the lowest (smallest) wired virtual address becomes the base
of that space. This way, you can use io_block_mapping() to set
up BATs and CAMs, and get ioremap() to use them if set.
The io_block_mapping() has never been used to request
virtual space, it's purpose is to wire virtual address spaces so
others can use them. If all you are doing is requesting an
arbitrary virtual address to be allocated, just use ioremap().
> Damn. What I am saying is that it's plain wrong to mess around with the
> space between TASK_SIZE and KERNELBASE and we should tie them together.
Can we do that now? The reason it wasn't done in the past was because
of the Prep memory map, our PCI configuration, and assumptions of the
macros/functions that managed those spaces.
> I still don't see any reason why we couldn't have io_block_mappingt()
> use the ioremap_bot technique to "allocate" virtual space dynamically
> at
> the top of the address space. So far, none of your arguments
> contradicts
> that.
You are missing the point. The reason for io_block_mapping() isn't
to allocate virtual space for someone, it's to _wire_ a space using an
efficient mapping method so someone else can call ioremap() and
get that wired access. Based upon various configuration options,
the board set up functions call io_block_mapping() to set up these
spaces. Then, ioremap() just finds them in the BAT or CAM array
and says, "oh, it's a wired entry, I'll just compute the virtual address
and return that." Unless someone tells ioremap() there are BATs or
CAMs, it won't use them.
> I don't see how that would be changed/affected in any way by making
> io_block_mapping() capable of dynamically allocating it's virtual
> space...
Ugh. How do you know how much space is available? How do you
know what to wire using BATs or CAMs? Someone has to do that.
The io_block_mapping isn't a replacement to ioremap(), nor is
ioremap() a replacement for io_block_mapping(). They work together
to provide wired virtual address mapping. In essence,
io_block_mapping()
tells ioremap() about wired entries.
> .... but aim to change it so that it allocates it's virtual space
But, it can't. That's the whole purpose of the function, to determine
how much IO space can be mapped with BATs or CAMs, then to
remove that space from the vmalloc pool and wire it into a contiguous
space that can be covered by large mapping.
This is why it makes no sense to call io_block_mapping() with a zero
for a virtual address and ask it to allocate some arbitrary space.
> You can still eventually use an io_block_mapping() then to "optimize"
> the mappings to some critical HW resources (PIC ?), I just don't want
> thse v->p mapping to be hard coded.
What do you mean by "optimize"? The whole purpose here is to
force a mapping using a BAT or CAM. You can't do that with arbitrary
pages from vmalloc space. You have to force the alignment and
size of the space, and the only way to do that is by simply removing
from the top of the vmalloc pool and giving it to ioremap().
Thanks.
-- Dan
^ permalink raw reply
* adb caps patch
From: Hans Fugal @ 2005-05-26 3:34 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 542 bytes --]
I've revived a caps lock patch by Gregorio Gervas, and adapted it for
2.6. It works for me, hopefully it works for you too. I welcome
feedback.
http://www.xmission.com/~fugalh/capslock/
--
.O. Hans Fugal | De gustibus non disputandum est.
..O http://hans.fugal.net | Debian, vim, mutt, ruby, text, gpg
OOO | WindowMaker, gaim, UTF-8, RISC, JS Bach
---------------------------------------------------------------------
GnuPG Fingerprint: 6940 87C5 6610 567F 1E95 CB5E FC98 E8CD E0AA D460
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] ppc32: Fix cpufreq vs. sleep issue
From: Benjamin Herrenschmidt @ 2005-05-26 3:29 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev list, Linus Torvalds
Hi !
Recent kernel occasionally trigger a PMU timeout on some mac laptops,
typically on wakeup from sleep. This seem to be caused by either a too
big latency caused by the cpufreq switch on wakeup from sleep or by an
interrupt beeing lost due to the reset of the interrupt controller done
during wakeup.
This patch makes that code more robust by stopping PMU auto poll
activity around cpufreq changes on machines that use the PMU for such
changes (long latency switching involving a CPU hard reset and flush of
all caches) and by removing the reset of the open pic interrupt
controller on wakeup (that can cause the loss of an interrupt and Darwin
doesn't do it, so it must not be necessary).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/arch/ppc/platforms/pmac_cpufreq.c
===================================================================
--- linux-work.orig/arch/ppc/platforms/pmac_cpufreq.c 2005-05-18 12:00:28.000000000 +1000
+++ linux-work/arch/ppc/platforms/pmac_cpufreq.c 2005-05-26 10:35:03.000000000 +1000
@@ -271,6 +271,8 @@
#ifdef DEBUG_FREQ
printk(KERN_DEBUG "HID1, before: %x\n", mfspr(SPRN_HID1));
#endif
+ pmu_suspend();
+
/* Disable all interrupt sources on openpic */
pic_prio = openpic_get_priority();
openpic_set_priority(0xf);
@@ -345,6 +347,8 @@
debug_calc_bogomips();
#endif
+ pmu_resume();
+
preempt_enable();
return 0;
Index: linux-work/drivers/macintosh/via-pmu.c
===================================================================
--- linux-work.orig/drivers/macintosh/via-pmu.c 2005-05-18 12:00:28.000000000 +1000
+++ linux-work/drivers/macintosh/via-pmu.c 2005-05-26 10:38:04.000000000 +1000
@@ -2431,7 +2431,7 @@
/* Re-enable local CPU interrupts */
local_irq_enable();
- mdelay(100);
+ mdelay(10);
preempt_enable();
/* Re-enable clock spreading on some machines */
@@ -2559,7 +2559,9 @@
return ret;
}
- printk(KERN_DEBUG "HID1, before: %x\n", mfspr(SPRN_HID1));
+ /* Stop environment and ADB interrupts */
+ pmu_request(&req, NULL, 2, PMU_SET_INTR_MASK, 0);
+ pmu_wait_complete(&req);
/* Tell PMU what events will wake us up */
pmu_request(&req, NULL, 4, PMU_POWER_EVENTS, PMU_PWR_CLR_WAKEUP_EVENTS,
@@ -2621,8 +2623,6 @@
pmu_request(&req, NULL, 2, PMU_SET_INTR_MASK, pmu_intr_mask);
pmu_wait_complete(&req);
- printk(KERN_DEBUG "HID1, after: %x\n", mfspr(SPRN_HID1));
-
pmac_wakeup_devices();
return 0;
Index: linux-work/arch/ppc/syslib/open_pic.c
===================================================================
--- linux-work.orig/arch/ppc/syslib/open_pic.c 2005-05-18 12:00:28.000000000 +1000
+++ linux-work/arch/ppc/syslib/open_pic.c 2005-05-26 10:42:24.000000000 +1000
@@ -275,7 +275,7 @@
}
#endif
-#if defined(CONFIG_EPIC_SERIAL_MODE) || defined(CONFIG_PM)
+#if defined(CONFIG_EPIC_SERIAL_MODE)
static void openpic_reset(void)
{
openpic_setfield(&OpenPIC->Global.Global_Configuration0,
@@ -1007,8 +1007,6 @@
return 0;
}
- openpic_reset();
-
/* OpenPIC sometimes seem to need some time to be fully back up... */
do {
openpic_set_spurious(OPENPIC_VEC_SPURIOUS);
^ permalink raw reply
* Re: Reading DVDs on a Mac mini
From: Benjamin Herrenschmidt @ 2005-05-26 2:50 UTC (permalink / raw)
To: Tom Parker; +Cc: linuxppc-dev
In-Reply-To: <429517FF.2030400@tevp.net>
On Thu, 2005-05-26 at 02:27 +0200, Tom Parker wrote:
> Benjamin Herrenschmidt wrote:
> > On Mon, 2005-05-23 at 22:07 +0200, Tom Parker wrote:
> >>The version of libdvdread in use is 0.9.4 (the Debian 0.9.4-5
> >>libdvdread3 package).
>
> > Does the debian package of libdvdread contains the CSS stuff ?
>
> No it doesn't, but it does include a shell script to download it if
> you're living somewhere where libdvdcss is ok, and libdvdread will
> dynamically load libdvdcss if it exists. I'm using libdvdcss 1.2.8 (latest).
>
> > Have you tried booting OS X and playing the DVD once ? Maybe the drive
> > wants a zone to be set at least once, which MacOS does the first time
> > you play a DVD
>
> Had to reinstall OS X to test this, and yup, it wants a zone to be set.
> Returning back to Linux, some fiddling with regionset and some region 1
> and 2 DVDs lets me come to the following conclusions:
>
> 1) It's an RPC-2 DVD drive (i.e. evil, CSS-in-hardware drive), with the
> whole "5 changes and then it locks" policy.
> 2) It appears to be a really evil variant of RPC-2, in that if you've
> got a CSS-locked DVD in the drive, and you're set on a different region
> to the disk, you can't even get at the encrypted contents. The
> aforementioned read errors keep turning up, making libdvdcss useless.
> Or, this may just be an ide-cd bug with this drive...
> 3) If drive region == disc region, it plays DVDs fine.
>
> >>hdparm -i says the drive is a "MATSHITACD-RW CW-8124".
>
> If anyone happens to have an RPC-1 firmware for this drive, or fixes to
> ide-cd, I'd be most grateful! Some googling for the former is currently
> unhelpful.
Yah, I googled too and ended up with the same conclusion =P
Ben.
^ permalink raw reply
* RE: MPC860 CP / CPM Misbehaving
From: Martin, Tim @ 2005-05-26 0:32 UTC (permalink / raw)
To: 'linuxppc-embedded@ozlabs.org'
An update (and solution) to the problem I was having...Thanks to everyone
who sent me suggestions!
> I'm using a custom MPC860 based embedded board and having problems with
SCC1
> and SMC1 reception. I have SCC1 setup in ethernet mode, and SMC1 setup in
> UART mode. The general problem manifests itself as getting receive buffer
> descriptors (BDs) from the CPM with the OV bit set (bit 14 of the RxBD
> status/control field, "Overrun. Set when a receiver overrun occurs during
> reception").
I was apparently the victim of errata in the MPC860, possibly related to a
published errata CPU5 - Instruction MMU bug at page boundaries in show-all
mode.
Either one of the following fixed the problem, but I chose to stick with Fix
#2 since Fix #1 has some other errata associated with it for various MPC860
silicon versions.
Fix #1) Enable SIUMCR[DSHW] - Show address and data of all internal data
cycles. Not entirely clear why this would have helped, and there's errata
saying NOT to do this (e.g. SIU2)
Fix #2) Disable show all mode (per CPU5), in my case set ICTRL[ISCT_SER]=011
Core is fully serialized/no show cycles is performed for fetched
instructions.
Tim
^ permalink raw reply
* Re: Reading DVDs on a Mac mini
From: Tom Parker @ 2005-05-26 0:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1116891693.30513.3.camel@gaston>
Benjamin Herrenschmidt wrote:
> On Mon, 2005-05-23 at 22:07 +0200, Tom Parker wrote:
>>The version of libdvdread in use is 0.9.4 (the Debian 0.9.4-5
>>libdvdread3 package).
> Does the debian package of libdvdread contains the CSS stuff ?
No it doesn't, but it does include a shell script to download it if
you're living somewhere where libdvdcss is ok, and libdvdread will
dynamically load libdvdcss if it exists. I'm using libdvdcss 1.2.8 (latest).
> Have you tried booting OS X and playing the DVD once ? Maybe the drive
> wants a zone to be set at least once, which MacOS does the first time
> you play a DVD
Had to reinstall OS X to test this, and yup, it wants a zone to be set.
Returning back to Linux, some fiddling with regionset and some region 1
and 2 DVDs lets me come to the following conclusions:
1) It's an RPC-2 DVD drive (i.e. evil, CSS-in-hardware drive), with the
whole "5 changes and then it locks" policy.
2) It appears to be a really evil variant of RPC-2, in that if you've
got a CSS-locked DVD in the drive, and you're set on a different region
to the disk, you can't even get at the encrypted contents. The
aforementioned read errors keep turning up, making libdvdcss useless.
Or, this may just be an ide-cd bug with this drive...
3) If drive region == disc region, it plays DVDs fine.
>>hdparm -i says the drive is a "MATSHITACD-RW CW-8124".
If anyone happens to have an RPC-1 firmware for this drive, or fixes to
ide-cd, I'd be most grateful! Some googling for the former is currently
unhelpful.
Thanks,
Tom Parker
^ permalink raw reply
* [PATCH][PPC32] MPC834x BCSR_SIZE too small for use in a BAT
From: Randy Vinson @ 2005-05-26 0:01 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 515 bytes --]
Greetings,
The value of BCSR_SIZE (32K) in arch/ppc/platforms/83xx/mpc834x_sys.h
is too small for a BAT (min 128K). The size is used in an
io_block_mapping call to map the Board Control and Status Registers.
Since there are no current dependencies on the result of the
io_block_mapping call, it was removed as a solution to the problem
rather than increasing the value of BCSR_SIZE. If access to the BCSR
block is needed, it can easily be mapped via ioremap at the point of use.
Randy Vinson
[-- Attachment #2: bcsr.patch --]
[-- Type: text/plain, Size: 1858 bytes --]
MPC834x BCSR_SIZE too small for use in a BAT.
The call to io_block_mapping was creating an invalid BAT entry because
the value of BCSR_SIZE (32K) is too small to be used in a BAT (128K min).
This change removes the io_block_mapping call since these registers can
easily be mapped using ioremap at the point of use.
Signed-off-by: Randy Vinson <rvinson@mvista.com>
---
commit 269bcdbf0a9f000400052b2da38348733dbfe88f
tree d10f5c31c29228a00a1a7551e3e825b439bfc741
parent 1b981021e88c8c28dc6a22cb1a327d8dc9296473
author Randy Vinson <rvinson@linuxbox.(none)> Wed, 25 May 2005 16:14:40 -0700
committer Randy Vinson <rvinson@linuxbox.(none)> Wed, 25 May 2005 16:14:40 -0700
arch/ppc/platforms/83xx/mpc834x_sys.c | 1 -
arch/ppc/platforms/83xx/mpc834x_sys.h | 1 -
2 files changed, 2 deletions(-)
Index: arch/ppc/platforms/83xx/mpc834x_sys.c
===================================================================
--- 5eeefa658d7f9c13cd352994805ac3ead628b7e9/arch/ppc/platforms/83xx/mpc834x_sys.c (mode:100644)
+++ d10f5c31c29228a00a1a7551e3e825b439bfc741/arch/ppc/platforms/83xx/mpc834x_sys.c (mode:100644)
@@ -127,7 +127,6 @@
{
/* we steal the lowest ioremap addr for virt space */
io_block_mapping(VIRT_IMMRBAR, immrbar, 1024*1024, _PAGE_IO);
- io_block_mapping(BCSR_VIRT_ADDR, BCSR_PHYS_ADDR, BCSR_SIZE, _PAGE_IO);
}
int
Index: arch/ppc/platforms/83xx/mpc834x_sys.h
===================================================================
--- 5eeefa658d7f9c13cd352994805ac3ead628b7e9/arch/ppc/platforms/83xx/mpc834x_sys.h (mode:100644)
+++ d10f5c31c29228a00a1a7551e3e825b439bfc741/arch/ppc/platforms/83xx/mpc834x_sys.h (mode:100644)
@@ -26,7 +26,6 @@
#define VIRT_IMMRBAR ((uint)0xfe000000)
#define BCSR_PHYS_ADDR ((uint)0xf8000000)
-#define BCSR_VIRT_ADDR ((uint)0xfe100000)
#define BCSR_SIZE ((uint)(32 * 1024))
#ifdef CONFIG_PCI
^ permalink raw reply
* Re: RFC: PHY Abstraction Layer II
From: Kumar Gala @ 2005-05-25 23:00 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Netdev, David S. Miller, ML linuxppc-embedded
In-Reply-To: <30d87aabd768216ef8bee800f3e09b9e@freescale.com>
Jeff,
Where do we stand on this. Are there changes you feel need to be made?=20=
Some other issue? It would like to know what we need to do to get=20
this in post 2.6.12.
thanks
- kumar
On May 10, 2005, at 12:04 PM, Fleming Andy-afleming wrote:
>
>
> On Apr 17, 2005, at 08:00, James Chapman wrote:
>
> > Andy Fleming wrote:
> >> Ok, here's the new patch with changes suggested by James Chapman:
> >
> > I guess I still have questions about the way interrupts are used.
> >
> > Using an interrupt to schedule a work queue which then sets a=20
> variable
> > that is used by a timer seems odd. Why not do all the work in the=20
> work
> > queue and schedule it from the interrupt handler or timer?
>
> Ok, I've set up a new system for handling interrupts.=A0 There are now
> two "special" interrupt values, PHY_POLL, and PHY_IGNORE_INTERRUPT.=A0
> The first one is used to indicate that the PHY layer will poll the =
PHY
> for state changes, and won't enable interrupts.=A0 The second =
indicates
> that the PHY layer will neither poll, nor enable interrupts, and thus
> will allow the driver to handle interrupts.=A0 The PHY layer will =
still
> operate its state machine, though.
>
> The driver must insure a couple things:
>
> 1) It must set phydev->state to PHY_CHANGELINK
> 2) It must do that in a work queue (or other non-interrupt time)
>
> The first one tells the PHY layer that the link state changed (it has
> to grab a lock to do this).=A0 The second one is required in order to
> properly take the lock.
>
> >
> > Also, did you mean to leave the #if 0 code in davicom.c?
>
> For now.=A0 It worked around a problem some people were reporting, so =
I'd
> like to see if they report it again now that the code's out.=A0 If so,
> they have a fairly easy fix, and I can reinsert it (or at least
> reevaluate it) in the future.
>
> >
> > /james
>
> Andy
> <phy_05_09_2005.patch><ATT191442.txt>=
^ permalink raw reply
* Re: RFC: Deprecating io_block_mapping
From: Benjamin Herrenschmidt @ 2005-05-25 21:44 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <b9ca52306a8b84cc1e03ac72c65316cf@embeddededge.com>
> However, there are "holes" in the VM space that are completely
> unused, and this is a precious resource. The io_block_mapping()
> gives us the ability to stick things into those holes. Usually, we
> would configure a system with a 2G user space, then use
> io_block_mapping()
> to allocate the space between 0x80000000 and 0xc0000000.
This is a VERY BAD habit. Just set KERNELBASE to 0x80000000 if you do
that, an use io_block_mapping() dynamically the way I explained to alloc
from the top of the address space.
> The ioremap() isn't going to do this, unless we really make this
> smarter. On many systems, this was also the mapping for the
> PCI space, so things like virt_to_xxx() were based on the assumptions
> of this mapping. So, if a board port wanted to use the option of
> user task space configuration, it would have to also manage these
> fixed address spaces accordingly.
Well, The PCI IO space base just need to be in a global that is
referenced by _IO_BASE, it works fine, no need to hard code a mapping.
PCI memory space doesn't rely on any of this unless your platform code
is really screwy
> This is not as simple as making io_block_mapping() use ioremap VM
> space. We have to find a way of managing all of the free kernel VM
> space and ensuring all of the mapping APIs for IO know about and
> utilize all of this space.
I'm not sure I understand your last sentence. As I explained, all we
need is to add to io_block_mapping() the _ability_ to allocate via
ioremap_bot. (I agree that it's a bit early to _deprecate it
completely_). That way, I don't break any existing setup. Then, we can
start adapting platforms (and making sure new ones) use a proper
mecanism instead of hard coding v->p mappings.
> Then, you better get in line behind me for arguing for much better
> VM space management in general :-) Linux is horrible in this regard,
> and the replies I get are " ... for efficiency you have to know the use
> of the spaces and the proper APIs to manage them ..."
That is out of topic. I'm talking about a specific issue, you are making
vague generalities.
> But, no one would use that because it doesn't have the proper effect.
> If this could be done, we would already be using ioremap().
Ugh ? Can you explain why it "doesn't have the proper effect" ?
> > Dan's point about io_block_mapping() supposedly "initializing"
> > ioremap_bot is bogus, unless I misunderstood him.
>
> I never said that, but if you look at the code, it's exactly what it
> does :-)
No. If you read properly, you'll see that it will _not_ initialize it if
it is 0, because the test virt < ioremap_bot will never be true (both
are unsigned long) before MMU_init() is called.
> Any mappings done between the top of user space and bottom of
> the kernel are simply forced and ignored by any Linux VM. The
> io_block_mapping() is used to allocate BATs and CAMs and make
> them available for ioremap() of devices. It allows us to map various
> devices into the ioremap space, take advantage of the efficiency of
> BATs or large page mappings, and still have devices use the ioremap()
> to find them.
Damn. What I am saying is that it's plain wrong to mess around with the
space between TASK_SIZE and KERNELBASE and we should tie them together.
I still don't see any reason why we couldn't have io_block_mappingt()
use the ioremap_bot technique to "allocate" virtual space dynamically at
the top of the address space. So far, none of your arguments contradicts
that.
> As I keep saying, somehow you have to lay out the virtual to physical
> mapping of devices using the efficiency of BATs and CAMs, and still
> make the ioremap() interface work. The device driver just calls
> ioremap(),
> but if you have a smart board set up function, it can set up an
> efficient
> mapping using BATs or CAMs rather than 4k pages requiring TLB
> exceptions.
I don't see how that would be changed/affected in any way by making
io_block_mapping() capable of dynamically allocating it's virtual
space...
> We can either make ioremap() really complex with knowledge of all of
> these board configuration options so it can set up the BATs and CAMs,
> or we set it all up using some functions (like io_block_mapping) in the
> board set up and keep ioremap() a simple function.
I am not arguing that. Did you actually read my last mail ? I'm
effectively given up deprecating io_block_mapping() completely at this
point, but aim to change it so that it allocates it's virtual space
instead of hard-coding it using the ioremap_bot technique, which can
work at any time during boot, as early as you want.
> The current implementation of io_block_mapping does two very important
> functions. One is this set up of efficient mapping for ioremap(), and
> the
> other is to utilize the kernel VM space that isn't managed by Linux.
It isn't managed by Linux not because linux is bad, but because the
platforms do a stupid setup. Just move down KERNELBASE and linux will
happily manage that space for ioremap.
> We are currently moving lots of the code to make use of ioremap() rather
> than assuming prior mapping, which is a nice thing, but it's costing us
> in terms of performance and resource utilization.
You can still eventually use an io_block_mapping() then to "optimize"
the mappings to some critical HW resources (PIC ?), I just don't want
thse v->p mapping to be hard coded.
Ben.
^ permalink raw reply
* Re: make -j12 all fails in uImage target
From: Olaf Hering @ 2005-05-25 21:34 UTC (permalink / raw)
To: Tom Rini, linuxppc-dev, Sam Ravnborg
In-Reply-To: <20050206225323.GA16821@mars.ravnborg.org>
On Sun, Feb 06, Sam Ravnborg wrote:
> On Sun, Feb 06, 2005 at 02:51:31PM -0700, Tom Rini wrote:
> > On Sun, Feb 06, 2005 at 01:40:14PM +0100, Olaf Hering wrote:
> > > GZIP arch/ppc/boot/images/vmlinux.gz
> > > /bin/sh: line 1: arch/ppc/boot/images/vmlinux.bin: No such file or directory
> > > make[2]: *** [arch/ppc/boot/images/vmlinux.gz] Error 1
> > > make[1]: *** [uImage] Error 2
> > > make[1]: *** Waiting for unfinished jobs....
> > >
> > > also, one time that zImage.chrp was only 570K instead of the expected
> > > 1.4M, so netboot failed. But I got no build error.
> > > Any idea what dependency is missing?
> >
> > That is kinda odd. My thought is that arch/ppc/boot/ just isn't fully
> > safe for -j'ing. Sam, any ideas on how to debug this kinda problem?
>
> The problem is that the images/ sub directory is visited before the
> prerequisites are finished.
> I have no good way to debug this - I can see it based on the Makefile and
> the output Olaf included.
>
> Also the problem Olaf describe is just a cp of a half finished file.
>
>
> So the fix is to let the images/ directory depends on the rest of the
> directories.
>
> Something like this may do the trick:
>
> $(obj)/images: $(addprefix $(obj)/,$(subdir-y) $(bootdir-y))
> $(Q)$(MAKE) $(build)=$@
>
> And then delete the assignment of images to subdir-y
>
>
> Another solution would be to get rid on the images/ drectory and place
> outputfiles where they are being built.
I did it this way:
...
AS arch/ppc/boot/common/util.o
CC arch/ppc/boot/of1275/write.o
AR arch/ppc/boot/common/lib.a
AR arch/ppc/boot/of1275/lib.a
`arch/ppc/boot/images/vmlinux.gz.27631' -> `arch/ppc/boot/images/vmlinux.gz'
AR arch/ppc/boot/lib/lib.a
UIMAGE arch/ppc/boot/images/uImage
"mkimage" command not found - U-Boot images will not be built
Image: arch/ppc/boot/images/uImage not made
`arch/ppc/boot/images/vmlinux.gz.27676' -> `arch/ppc/boot/images/vmlinux.gz'
CC arch/ppc/boot/openfirmware/dummy.o
AS arch/ppc/boot/simple/head.o
AS arch/ppc/boot/simple/relocate.o
...
Index: linux-2.6.12-rc5-olh/scripts/Makefile.lib
===================================================================
--- linux-2.6.12-rc5-olh.orig/scripts/Makefile.lib
+++ linux-2.6.12-rc5-olh/scripts/Makefile.lib
@@ -1,3 +1,4 @@
+# vim: syntax=sh
# ===========================================================================
# kbuild: Generic definitions
# ===========================================================================
@@ -177,7 +178,7 @@ cmd_objcopy = $(OBJCOPY) $(OBJCOPYFLAGS)
# ---------------------------------------------------------------------------
quiet_cmd_gzip = GZIP $@
-cmd_gzip = gzip -f -9 < $< > $@
+cmd_gzip = gzip -f -9 < $< > $@.$$$$ ; mv -v $@.$$$$ $@
# ===========================================================================
# Generic stuff
^ permalink raw reply
* Re: 2.6.10 unable to mount a root fs on ramdisk
From: Shawn Jin @ 2005-05-25 17:48 UTC (permalink / raw)
To: John Otken, ppcembed
In-Reply-To: <4292A441.4080708@softadvances.com>
Hi John,
Thanks for your answer.
I did add these lines to the code. Actually it turned out that I was
so stupid that I didn't enable EXT2 filesystem support in the kernel.
That's why the kernel always complained unknown block.
-Shawn.
On 5/23/05, John Otken <jotken@softadvances.com> wrote:
> I had this problem with MV code on a Bamboo board. Look at
> platform_init() in ebony.c. Before the call to ibm44x_platform_init() ad=
d:
>=20
> /*
> * If we were passed in a board information, copy it into the
> * residual data area.
> */
> if (r3)
> __res =3D *(bd_t *)(r3 + KERNELBASE);
>=20
> /*
> * If the init RAM disk has been configured in, and there's a vali=
d
> * starting address for it, set it up.
> */
> if (r4) {
> initrd_start =3D r4 + KERNELBASE;
> initrd_end =3D r5 + KERNELBASE;
> }
>=20
> /* Copy the kernel command line arguments to a safe place. */
>=20
> if (r6) {
> *(char *) (r7 + KERNELBASE) =3D 0;
> strcpy(cmd_line, (char *) (r6 + KERNELBASE));
> }
^ permalink raw reply
* ª©¥Dªº¸Ü
From: ÀN©v¿« @ 2005-05-25 17:25 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 542 bytes --]
^ permalink raw reply
* Re: RFC: Deprecating io_block_mapping
From: Dan Malek @ 2005-05-25 16:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <1117004659.6395.103.camel@gaston>
On May 25, 2005, at 3:04 AM, Benjamin Herrenschmidt wrote:
>> Can one of you explain why this is necessary. I believe it I just
>> dont
>> understand. I think this is one of the abuses of io_block_mapping().
>> People, myself included, realize some of the caveats implied by
>> calling
>> io_block_mapping().
>
> Well, there are 2 different things here. io_block_mapping "moving"
> ioremap_bot, and my idea of having io_block_mapping "using" it...
It's more complicated than that. The basic Linux kernel VM map is
kernel_base (usually 0xc0000000), kernel text, kernel data, VM guard,
VM alloc space, then ioremap space.
However, there are "holes" in the VM space that are completely
unused, and this is a precious resource. The io_block_mapping()
gives us the ability to stick things into those holes. Usually, we
would configure a system with a 2G user space, then use
io_block_mapping()
to allocate the space between 0x80000000 and 0xc0000000.
The ioremap() isn't going to do this, unless we really make this
smarter. On many systems, this was also the mapping for the
PCI space, so things like virt_to_xxx() were based on the assumptions
of this mapping. So, if a board port wanted to use the option of
user task space configuration, it would have to also manage these
fixed address spaces accordingly.
This is not as simple as making io_block_mapping() use ioremap VM
space. We have to find a way of managing all of the free kernel VM
space and ensuring all of the mapping APIs for IO know about and
utilize all of this space.
> Now, my idea is that I dislike the io_block_mapping() interface because
> we have to provide the virtual address. Which means, it forces us to
> create hard coded v->p mappings, and I consider hard coding virtual
> addresses a bad thing (for lots of reasons, including the TASK_SIZE
> one).
Then, you better get in line behind me for arguing for much better
VM space management in general :-) Linux is horrible in this regard,
and the replies I get are " ... for efficiency you have to know the use
of the spaces and the proper APIs to manage them ..."
> Thus, I think we could "extend" io_block_mapping() to be able to take
> "0" for virt, and return a virtual address.
But, no one would use that because it doesn't have the proper effect.
If this could be done, we would already be using ioremap().
> Dan's point about io_block_mapping() supposedly "initializing"
> ioremap_bot is bogus, unless I misunderstood him.
I never said that, but if you look at the code, it's exactly what it
does :-)
Any mappings done between the top of user space and bottom of
the kernel are simply forced and ignored by any Linux VM. The
io_block_mapping() is used to allocate BATs and CAMs and make
them available for ioremap() of devices. It allows us to map various
devices into the ioremap space, take advantage of the efficiency of
BATs or large page mappings, and still have devices use the ioremap()
to find them.
As I keep saying, somehow you have to lay out the virtual to physical
mapping of devices using the efficiency of BATs and CAMs, and still
make the ioremap() interface work. The device driver just calls
ioremap(),
but if you have a smart board set up function, it can set up an
efficient
mapping using BATs or CAMs rather than 4k pages requiring TLB
exceptions.
We can either make ioremap() really complex with knowledge of all of
these board configuration options so it can set up the BATs and CAMs,
or we set it all up using some functions (like io_block_mapping) in the
board set up and keep ioremap() a simple function.
The current implementation of io_block_mapping does two very important
functions. One is this set up of efficient mapping for ioremap(), and
the
other is to utilize the kernel VM space that isn't managed by Linux.
We are currently moving lots of the code to make use of ioremap() rather
than assuming prior mapping, which is a nice thing, but it's costing us
in terms of performance and resource utilization.
Thanks.
-- Dan
^ permalink raw reply
* [PATCH] ppc32: Fix building MPC8555 CDS when CONFIG_PCI is disabled
From: Kumar Gala @ 2005-05-25 15:36 UTC (permalink / raw)
To: Andrew Morton; +Cc: shall, linux-kernel, linuxppc-embedded
The patch that introduced support for the VIA chipset broke building if
CONFIG_PCI is disabled.
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
commit 84a069e46b6b866b338e44529f505fddd7d31fbb
tree 362fd343e5b2c022b654da36742ce08b6a5ddca9
parent 7289356a6b3c0218f9ad6e85280c4f9cc121e371
author Kumar K. Gala <kumar.gala@freescale.com> Wed, 25 May 2005 10:32:53 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Wed, 25 May 2005 10:32:53 -0500
ppc/platforms/85xx/mpc85xx_cds_common.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
Index: arch/ppc/platforms/85xx/mpc85xx_cds_common.c
===================================================================
--- 12a426fa6a66d581ca2c5fca42457b3f3505af09/arch/ppc/platforms/85xx/mpc85xx_cds_common.c (mode:100644)
+++ 362fd343e5b2c022b654da36742ce08b6a5ddca9/arch/ppc/platforms/85xx/mpc85xx_cds_common.c (mode:100644)
@@ -439,9 +439,6 @@
printk("mpc85xx_cds_setup_arch\n");
- /* VIA IDE configuration */
- ppc_md.pcibios_fixup = mpc85xx_cds_pcibios_fixup;
-
#ifdef CONFIG_CPM2
cpm2_reset();
#endif
@@ -462,6 +459,9 @@
loops_per_jiffy = freq / HZ;
#ifdef CONFIG_PCI
+ /* VIA IDE configuration */
+ ppc_md.pcibios_fixup = mpc85xx_cds_pcibios_fixup;
+
/* setup PCI host bridges */
mpc85xx_setup_hose();
#endif
^ permalink raw reply
* Re: Newbie question about accessing memory in kernel space
From: David Bruce @ 2005-05-25 13:17 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20050525020004.CCA3A67A3F@ozlabs.org>
I was going down the same path as you are a year ago and had similar
issues. This book covers up to 2.4 but will probably answer future
issues you encounter:
http://www.xml.com/ldd/chapter/book/
The code in book:
http://examples.oreilly.com/linuxdrive2/
^ permalink raw reply
* Re: depmod.pl fails with "base directory does not match" (2_4_devel)
From: Alex Zeffertt @ 2005-05-25 12:26 UTC (permalink / raw)
To: Peter Gehirnforce; +Cc: linuxppc-embedded
In-Reply-To: <16216.1117022348@www12.gmx.net>
Use something like the following:
make INSTALL_MOD_PATH=/opt/eldk/ppc_6xx modules_install
Where /opt/eldk/ppc_6xx should be replaced with the base of your
target root filesystem.
Alex
On Wed, 25 May 2005 13:59:08 +0200 (MEST)
"Peter Gehirnforce" <Gehirnmann@gmx.de> wrote:
> Hi all,
>
> since now I used modules compiled into the kernel for ppc_6xx.
> for debugging I'd like to use dynamic loading, but when doing:
> make modules_install
> the depmod.pl fails with "base directory does not match
> ..../lib/modules" As far as I could find out, the modules get copied
> to the base /lib path, even with $PATH and $CROSS_COMPILE set
> correctly (I used compiled modules successfully).
> Whats wrong with my attempt? is there some cross-compile tool to do
> the job of depmod.pl?
>
> GM
>
> --
> 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail
> +++ GMX - die erste Adresse f_r Mail, Message, More +++
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* depmod.pl fails with "base directory does not match" (2_4_devel)
From: Peter Gehirnforce @ 2005-05-25 11:59 UTC (permalink / raw)
To: linuxppc-embedded
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 606 bytes --]
Hi all,
since now I used modules compiled into the kernel for ppc_6xx.
for debugging I'd like to use dynamic loading, but when doing:
make modules_install
the depmod.pl fails with "base directory does not match ..../lib/modules"
As far as I could find out, the modules get copied to the base /lib path,
even with $PATH and $CROSS_COMPILE set correctly (I used compiled modules
successfully).
Whats wrong with my attempt? is there some cross-compile tool to do the job
of depmod.pl?
GM
--
5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail
+++ GMX - die erste Adresse für Mail, Message, More +++
^ permalink raw reply
* Re: Newbie question about accessing memory in kernel space
From: Niklaus Giger @ 2005-05-25 11:35 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200505250158.33459.roger.larsson@norran.net>
Am Mittwoch, 25. Mai 2005 01.58 schrieb Roger Larsson:
> On Tuesday 24 May 2005 21.19, Niklaus Giger wrote:
> > Hi
> >
> > I am working on a custom PPC405 board where I have a 2.6.10 kernel with
> > RTAI patches (fusion) running.
> >
> > I am trying to access some custom CPLD chip hanging at 0x7D000000. In my
> > intial board (hcu3_map_io) I added a corresponding io_block_mapping.
> >
> > I can see the CPLD when I access the address via my Abatron BDI debugger.
> >
> > In a user space test program I did a
> > map_base = mmap((void *)target, nSize, PROT_READ | PROT_WRITE,
> > MAP_SHARED, fd, target);
> > and was able to access the CPLD, too.
>
> Via 'map_base' I guess?
>
> For kernel try
> virt_base=ioremap(target, nSize)
Thanks this fixed my problem.
> > In user and kernel space the procedure looks like this:
> > void sys_set_tick_control_register_value(uint16 value)
> > {
> > static uint16 *tickControlRegister = (uint16*)
> > HCU_TICK_CONTROL_REGISTER_ADDRESS;
>
> This indicates that you tries to read directly from an adress (no
> virt_base?) You might want to use __raw_readl instead (depending on bus
> endianess).
__raw_readl was not necessary.
Thanks for your help.
Best regards
Niklaus
^ permalink raw reply
* Re: Newbie question about accessing memory in kernel space
From: Niklaus Giger @ 2005-05-25 11:31 UTC (permalink / raw)
To: Matt Porter; +Cc: rtai, linuxppc-embedded
In-Reply-To: <20050524133123.A23084@cox.net>
Am Dienstag, 24. Mai 2005 22.31 schrieb Matt Porter:
> On Tue, May 24, 2005 at 09:19:28PM +0200, Niklaus Giger wrote:
> > Hi
> > Oops: kernel access of bad area, sig: 11 [#1]
>
> <snip>
>
> > What is wrong with my code?
>
> You mapped the device into user virtual address space. The TLB
> replacement code is unable to load a TLB entry for a page outside
> of kernel space...so you crash.
>
> Don't use io_block_map()...it allows you to shoot yourself in the
> foot very easily (as you just witnessed). Use ioremap() to map
> your device.
ioremap() fixed my problem.
Thanks a lot for your help.
Best regards
Niklaus
^ permalink raw reply
* Re: RFC: Deprecating io_block_mapping
From: Benjamin Herrenschmidt @ 2005-05-25 7:04 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <0015d371e12596fecdefd971b4fb1e5a@freescale.com>
> Can one of you explain why this is necessary. I believe it I just dont
> understand. I think this is one of the abuses of io_block_mapping().
> People, myself included, realize some of the caveats implied by calling
> io_block_mapping().
Well, there are 2 different things here. io_block_mapping "moving"
ioremap_bot, and my idea of having io_block_mapping "using" it...
So basically, the vmalloc/ioremap space starts at the end of the memory
linear mapping, and ends at ... ioremap_bot :)
This value is initially set to the "top" of the space useable for
vmalloc/ioremap. It's possible however to do "early" ioremap's (that is
before the vmalloc subsystem is initialized, and thus before we can
dynamically allocate virtual regions). In this case, ioremap just moves
ioremap_bot down and uses the space between the new and the previous
value.
In order to avoid having "block" mappings done by io_block_mapping()
collide with ioremap/vmalloc space, io_block_mapping() also has this bit
of code:
if (virt > KERNELBASE && virt < ioremap_bot)
ioremap_bot = ioremap_base = virt;
Which will "move down" ioremap_bot as well if a block mapping ends up in
the kernel area.
Now, my idea is that I dislike the io_block_mapping() interface because
we have to provide the virtual address. Which means, it forces us to
create hard coded v->p mappings, and I consider hard coding virtual
addresses a bad thing (for lots of reasons, including the TASK_SIZE
one).
Thus, I think we could "extend" io_block_mapping() to be able to take
"0" for virt, and return a virtual address. That would be 100%
compatible with existing code. When taking "0" for virt,
io_block_mapping would just allocate virtual space like early
ioremap_bot does, by moving ioremap_bot downward (with appropriate
aligment restrictions). By returning the actual virtual address used, it
makes possible for the caller to know it :)
That way, io_block_mapping() _can_ be used without hard coding virtual
addresses, which would then be documented as the "preferred" thing to
do, and would avoid some of the headaches.
Now, there may be a slight issue with when is ioremap_bot initialized...
It is in bss, so it is 0 by default (which isn't really suitable). It's
only initialized in MMU_init(). Thus there is a problem using it before
MMU_init(). Does that ever happen ? If it does, things are broken, since
the test "virt < ioremap_bot" will always be false anyway, and thus
io_block_mapping() will "fail" to move down ioremap_bot, thus
potentially letting the kernel allocate vmalloc/ioremap space that
overlap the block mapping.
Dan's point about io_block_mapping() supposedly "initializing"
ioremap_bot is bogus, unless I misunderstood him.
Ben.
^ permalink raw reply
* Re: RFC: Deprecating io_block_mapping
From: Kumar Gala @ 2005-05-25 6:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <1117000809.6395.92.camel@gaston>
>> Somewhere, at some point, prior to VM setup, we need to forcibly map
>> virtual to physical addresses. These are going to be "hard coded"
>> mappings, that's exactly how ioremap_bot is set. This is why
>> io_block_mapping was created in the first place. Somehow you have
>> to specify this mapping before you have a VM allocator to give it to
>> you. :-)
>
> No, you just need to have ioremap_bot (which is in fact "top" not
> "bottom", bad naming) initialized to something sane. This is currently
> done in MMU_init() but could probably be initialized statically
> instead.
> I do just that on ppc64 and thus can ioremap at any time without
> needing
> to allocate vmalloc space. The vmalloc space is automatically "cap'd"
> by
> ioremap_bot anyway.
Can one of you explain why this is necessary. I believe it I just dont
understand. I think this is one of the abuses of io_block_mapping().
People, myself included, realize some of the caveats implied by calling
io_block_mapping().
- kumar
^ permalink raw reply
* Re: RFC: Deprecating io_block_mapping
From: Pantelis Antoniou @ 2005-05-25 6:07 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <8818d51720e46592f49178f803ed2f0b@embeddededge.com>
Dan Malek wrote:
>
> On May 24, 2005, at 10:30 PM, Kumar Gala wrote:
>
>> I know what I've done in the past is either steal a BAT (83xx) or CAM
>> (85xx) entry and then free it up when a proper ioremap can be done later.
>
>
> This is even more of a hack than io_block_mapping() because it is often
> obscure and not documented. Several boards have done this in the past
> as well. It's "magic" that occurs, what seems to be minor code changes
> often cause this to break and makes debugging more complex :-)
>
>> No, as far as a can tell doing a quick glance if we drop
>> io_block_mapping than we can drop setup_io_mappings().
>
>
> We've got to have something to address the board unique requirements
> that are currently satisfied by this.
>
> There is a real problem that we have to solve. Some boards just need
> access to mapped hardware before the VM is set up. You can't just
> remove a feature or tell them their design is wrong. I don't think obscure
> mapping tricks are the solution, either.
>
> The only solution is to make ioremap() smart enough to properly use
> BATs and CAMs that are available to a processor. I suspect this is going
> to lead to a bunch of also undesirable configuration options to address
> the customizations necessary.
/me nods
>
> Thanks.
>
>
> -- Dan
>
Regards
Pantelis
^ permalink raw reply
* Re: RFC: Deprecating io_block_mapping
From: Benjamin Herrenschmidt @ 2005-05-25 6:00 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <1271e7dc7e42a99440e7925475b40547@embeddededge.com>
On Wed, 2005-05-25 at 01:49 -0400, Dan Malek wrote:
> On May 25, 2005, at 1:20 AM, Benjamin Herrenschmidt wrote:
>
> > Ok, that was my point... since init page tables can be loaded by it,
> > why
> > not make ioremap work that early and do the same ?
>
> Because you lose the efficiency of mapping with BATs or CAMs.
>
> > ... The problem is of
> > course allocating the pte pages but how does io_block_mapping() do on
> > CPUS without BAT/CAMs/whatever ?
>
> It just loads init's page tables directly.
>
> > We have the pgdir, but not the PTE pages...
>
> The PTE pages are allocated as they are needed. The PTE pages
> are there :-)
Well, you say "loads init's page tables directly"... well, init starts
with a pgdir, it needs to allocate PTE pages in order to "load" the page
tables with PTEs, thus my question, how does io_block_mapping does
this ? It use the bootmem allocator ? If yes, then that means we can
have ioremap working as well. I'm not completely arguing against
io_block_mapping() but I think it's abused, and thus looking into
encouraging different approaches.
> > No, we have a trick with ioremap_bot, we don't need to get vmalloc
> > space
> > for ioremap to work early.
>
> That's only if you have already done something to already allocate BATs
> or CAMs. On processors that don't have these, ioremap() would fail
> because it would think it has to allocate VM space.
The ioremap_bot trick works in whatever case provided MMU_init has been
called so ioremap_bot & ioremap_base are initialized. It would be fairly
easy to turn that into a static init though.
> > .... In fact, it would be nice to just have
> > io_block_mapping be able to "dynamically" allocate virtual space using
> > the same mecanism instead of beeing passed a virtual address. That
> > would
> > fix most of the problems with hard coded 1:1 mappings.
>
> I think we should make ioremap() smarter and have some board
> initialization that helps it by setting up BATs, CAMs, or unique page table
> mappings. There is also an interdependence between ioremap() and other IO
> initialization. In the past some of the fixed addressing was necessary
> due to assumptions built into IO setup, mapping functions, or macros. I
> don't know how much of this is still present.
It depends on the platform I suppose. There is still a few bits in PReP
that I can fix, I'm not sure about embedded.
> > Well, my problem is with hard-coded v:p mappings... If we can simply
> > have io_block_mapping take, for example, 0 for v (or -1) and use the
> > ioremap_bot trick to "allocate" virtual space, that would make me happy
> > (it needs to return the allocated address too).
>
> Somewhere, at some point, prior to VM setup, we need to forcibly map
> virtual to physical addresses. These are going to be "hard coded"
> mappings, that's exactly how ioremap_bot is set. This is why
> io_block_mapping was created in the first place. Somehow you have
> to specify this mapping before you have a VM allocator to give it to
> you. :-)
No, you just need to have ioremap_bot (which is in fact "top" not
"bottom", bad naming) initialized to something sane. This is currently
done in MMU_init() but could probably be initialized statically instead.
I do just that on ppc64 and thus can ioremap at any time without needing
to allocate vmalloc space. The vmalloc space is automatically "cap'd" by
ioremap_bot anyway.
> Even if you don't call it io_block_mapping(), you are going to need
> a function that does exactly this.
^ permalink raw reply
* Re: RFC: Deprecating io_block_mapping
From: Dan Malek @ 2005-05-25 5:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <1116998427.6395.86.camel@gaston>
On May 25, 2005, at 1:20 AM, Benjamin Herrenschmidt wrote:
> Ok, that was my point... since init page tables can be loaded by it,
> why
> not make ioremap work that early and do the same ?
Because you lose the efficiency of mapping with BATs or CAMs.
> ... The problem is of
> course allocating the pte pages but how does io_block_mapping() do on
> CPUS without BAT/CAMs/whatever ?
It just loads init's page tables directly.
> We have the pgdir, but not the PTE pages...
The PTE pages are allocated as they are needed. The PTE pages
are there :-)
> No, we have a trick with ioremap_bot, we don't need to get vmalloc
> space
> for ioremap to work early.
That's only if you have already done something to already allocate BATs
or CAMs. On processors that don't have these, ioremap() would fail
because
it would think it has to allocate VM space.
> .... In fact, it would be nice to just have
> io_block_mapping be able to "dynamically" allocate virtual space using
> the same mecanism instead of beeing passed a virtual address. That
> would
> fix most of the problems with hard coded 1:1 mappings.
I think we should make ioremap() smarter and have some board
initialization
that helps it by setting up BATs, CAMs, or unique page table mappings.
There is also an interdependence between ioremap() and other IO
initialization. In the past some of the fixed addressing was necessary
due
to assumptions built into IO setup, mapping functions, or macros. I
don't
know how much of this is still present.
> Well, my problem is with hard-coded v:p mappings... If we can simply
> have io_block_mapping take, for example, 0 for v (or -1) and use the
> ioremap_bot trick to "allocate" virtual space, that would make me happy
> (it needs to return the allocated address too).
Somewhere, at some point, prior to VM setup, we need to forcibly map
virtual to physical addresses. These are going to be "hard coded"
mappings, that's exactly how ioremap_bot is set. This is why
io_block_mapping was created in the first place. Somehow you have
to specify this mapping before you have a VM allocator to give it to
you. :-)
Even if you don't call it io_block_mapping(), you are going to need
a function that does exactly this.
Thanks.
-- Dan
^ 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