* Re: "transmit timed out" on FCC in MPC8260 => bug corrected
From: hubert.loewenguth @ 2006-03-24 11:44 UTC (permalink / raw)
To: Siju Viswanath K E; +Cc: Hunter, David, linuxppc-embedded
In-Reply-To: <1143193658.22246.20.camel@Blaze>
[-- Attachment #1.1: Type: text/plain, Size: 5744 bytes --]
Hi to the community.
I'm the man who has posted numerous questions about this problem of
fcc_enet timeout in ppc8260.
I just want to say that the 2.6 kernel doesn't solve the problem if you
have it on your board (I tried it, normally I have a 2.4-20 linux too).
I have search for this bug during a long time, and fortunatly, I 'm
happy to say you that finally, it is corrected since few days.
Special thanks to "Hunter, David" for having take in consideration my
problem, and proposing me some way of invastigations in this thread:
http://ozlabs.org/pipermail/linuxppc-embedded/2006-January/021842.html
In fact the solution comes from the new "MPC8260 PowerQUICC II Family
Reference Manual" fresescale has delivered 01/19/2006.
http://www.freescale.com/files/product/doc/MPC8260UM.pdf
They have added a very interesting paragraph about error handling in
ethernet mode:
/29.10.1.3 Adjusting Transmitter BD Handling
When a TXE event occurs, the TBPTR may already point beyond BDs still
marked as ready due to internal
pipelining. If the TBPTR is not adjusted, these BDs would be skipped
while still being marked as ready.
Software must determine if these BDs should be retransmitted or if they
should be skipped, depending on
the protocol and application needs. This requires the following steps:
1. From the current TBPTR value, search backwards over all (if any) BDs
still marked as ready to
find the first BD that has not been closed by the CPM. The search
process should stop if the BD to
be checked next is not ready or if it is the most recent BD marked as
ready by the CPU transmit
software. This is to avoid an endless loop in case the CPU software
fills the BD ring completely.
2. A) For skipping BDs, manually close all BDs from the BD just found up
to and including the BD
just before TBPTR. Leave the TBPTR value untouched.
B) For retransmitting BDs, change the TBPTR value to point to the BD
just found.
/
So, here is the correction I have done to the fcc-enet.c driver, and
wich I'am very satsify
I have tested it on my platform which was always entering in this
infernal timeout loop when there was successive plug/unplug during
important data transfert.
Thanks to some trace, I have seen that, as it is said in the new manual,
the error comes from the pipelining and a bad restart procedure in the
driver.
(I think it is the same restart procedure in the 2.6 kernel ??? to
verify ...)
With this correction, I have no more infernal timeout loop.
In fact, I replace the restart procedure in the fcc_enet_interrupt
method by this one, which respect the MPC8260 manual restart procedure:
if (must_restart) {
volatile cpm8260_t *cp;
/* Some transmit errors cause the transmitter to shut
* down. We now issue a restart transmit. Since the
* errors close the BD and update the pointers, the restart
* _should_ pick up without having to reset any of our
* pointers either. Also, To workaround 8260 device erratum
* CPM37, we must disable and then re-enable the transmitter
* following a Late Collision, Underrun, or Retry Limit error.
*/
// disable Transmitter
cep->fccp->fcc_gfmr &= ~FCC_GFMR_ENT;
udelay(10); /* wait a few microseconds just on principle */
#ifdef THALES_DEBUG_TRACE
printk("Thales restart debug trace :\n");
printk("first dirty tx %d, final dirty_tx %d, tbptr
%d\n",cbt_ptr2index(dev,first_bdp_dirty_tx),cbt_ptr2index(dev,cep->dirty_tx),tbptr_ptr2index(dev,ep->fen_genfcc.fcc_tbptr));
#endif
// RESTART TX command to the cpm
cp = cpmp;
cp->cp_cpcr = mk_cr_cmd(cep->fip->fc_cpmpage,
cep->fip->fc_cpmblock,0x0c, CPM_CR_RESTART_TX) | CPM_CR_FLG;
while (cp->cp_cpcr & CPM_CR_FLG);
// Adjusting Transmitter BD Handling
/* HLO : I do not search backwards from the current TBPTR value
to found skip BDs, but I directly
* adjust the tbptr value to the dirty_tx current value.
* In case of problemes occuring, change it and do like
indicated in 29.10.3 of MPC8260 manual
*/
ep->fen_genfcc.fcc_tbptr = __pa(cep->dirty_tx);
#ifdef THALES_DEBUG_TRACE
printk(" Thales workaround tbptr value adjusted :
%d\n",tbptr_ptr2index(dev,ep->fen_genfcc.fcc_tbptr));
#endif
// re-enable Transmitter
cep->fccp->fcc_gfmr |= FCC_GFMR_ENT;
}
I hope this correction will help you and the community.
Best regards
Siju Viswanath K E a écrit :
>Hi Denk,
> Thanks for the suggestion. I had a look at the source repository
>at projects/linuxppc_2_4_devel.git site. Outdated code doesnt seem to be
>the issue. My repository is patched upto
>"Patch by Wojciech Kromer, 06 Jan 2004" and later changes are only
>adding extra board support.
>
>regards,
>Siju Viswanath
>
>On Fri, 2006-03-24 at 13:21, Wolfgang Denk wrote:
>
>
>>In message <1143177651.22246.3.camel@Blaze> you wrote:
>>
>>
>>> I am using denk's linuxppc-2.4.20 . I am getting this problem of
>>>
>>>
>>Why don't you try using a more current version of the code? 2.4.20 is
>>*very* old, and *lots* of bugs and problems have been fixed since.
>>
>>It really does not make sense to spend effort on such old code.
>>
>>Best regards,
>>
>>Wolfgang Denk
>>
>>
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
[-- Attachment #1.2: Type: text/html, Size: 8250 bytes --]
[-- Attachment #2: hubert.loewenguth.vcf --]
[-- Type: text/x-vcard, Size: 285 bytes --]
begin:vcard
fn:Hubert Loewenguth
n:Loewenguth;Hubert
org:Thales Broadcast & Multimedia
adr:;;1 rue de l'hautil;Conflans Ste Honorine;;78700;France
email;internet:hubert.loewenguth@thales-bm.com
title:Software Engineer
tel;work:01-34-90-37-56
x-mozilla-html:TRUE
version:2.1
end:vcard
^ permalink raw reply
* Re: [PATCH] return to OF via trap, not exit
From: Segher Boessenkool @ 2006-03-24 12:13 UTC (permalink / raw)
To: Olaf Hering; +Cc: Michael Ellerman, linuxppc-dev
In-Reply-To: <20060323210357.GC24667@suse.de>
On 23-mrt-2006, at 22:03, Olaf Hering wrote:
> On Mon, Mar 06, Segher Boessenkool wrote:
>> That's better than always calling trap, sure. Is there any reason
>> you can't just do it on Macs though? Because the problem you're
>> trying
>> to work around only happens there.
>
> Maybe something like this? Only compile tested
That looks fine yes (if it runs ;-) ), thanks!
> Do not call prom exit prom_panic. It clears the screen and the exit
> message is lost.
> On some (or all?) pmacs it causes another crash when OF tries to
> print the
> date and time in its banner.
>
> Set of_platform earlier to catch more prom_panic() calls.
>
> Signed-off-by: Olaf Hering <olh@suse.de>
Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
^ permalink raw reply
* Re: [PATCH] powerpc: Kill machine numbers
From: Segher Boessenkool @ 2006-03-24 12:23 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linuxppc-dev, Paul Mackerras, Linux Kernel list, cbe-oss-dev
In-Reply-To: <200603240946.51793.arnd@arndb.de>
> One thing I have been wondering about is what should be the right way
> to check whether we're running on something based on the
> Cell Broadband Engine Architecture, if that is needed somewhere.
> My original idea was to make this the platform number, but this
> seems impractical now.
Just check the PVR? Either directly, or in the device tree.
It's not likely that there will be a million different CBEA
compliant CPUs any time soon ;-)
There really should be some other OF property in the CPU nodes
that tells us the CPU is CBEA, but I don't think we have one
right now :-(
Segher
^ permalink raw reply
* MTD physmap issues trying to map flash
From: Randy Smith @ 2006-03-24 13:32 UTC (permalink / raw)
To: linuxppc-embedded
Hello everyone,
I have been trying to get my flash memory to show up as an mtd device in
my 2.4.25 kernel and I get the following error:
physmap flash device: 0 at 0
__ioremap(): phys addr 00000000 is RAM lr c000f67c
Failed to ioremap
My hardware is based on the Icecube reference design but uses one
Spansion S29G128M-R2 16 MByte flash chip at physical address 0xff00000.
I am using u-boot 1.1.4 and the flash operates correctly in that
environment (after some tweaking). I am using a vanilla 2.4.25 linux
kernel from DENX's ELDK 3.1 and I have tried almost every incantation
regarding MTD configuration but no joy.
Some questions:
1. Does 2.4.25 expect the physmap_map structure to be populated by
u-boot and if so, where should I look in u-boot to make that happen?
2. I am assuming that this chip is CFI compliant and should show up
with that probing (and AMD support) enabled. Does it matter if turn on
both CFI and JEDEC probes? Or put another way, why should I have to
probe if this information is passed by u-boot, if it is?
3. How does the partitioning (command line) of the chip effect the
recognition of the chip?
4. What should I put in the physmap menuconfig line for the physical
address and size of the chip? I am using 0xff000000 and 0x01000000. Is
this correct and something else is broken?
5. Is there a patch to the kernel or u-boot that addresses this type of
failure?
Thanks,
Randy Smith
Software Engineer
ImageMap, Inc.
^ permalink raw reply
* Re: pci-x
From: Kumar Gala @ 2006-03-24 14:53 UTC (permalink / raw)
To: Carlos Mitidieri; +Cc: linuxppc-embedded
In-Reply-To: <200603241221.44576.carlos.mitidieri@sysgo.com>
On Mar 24, 2006, at 5:21 AM, Carlos Mitidieri wrote:
>
> On Thursday 23 March 2006 16:41, Kumar Gala wrote:
>>> Is there PCI-X support for the mpc8540ads?
>>
>> Yes. You have to make sure the board is setup (switches in the right
>> place) properly for it.
>
> Thank you for answering.
>
> Looking the manuals and schematics, I have changed the "config"
> switch in
> SW1, and now the PCI-X support is activated in the kernel at the
> system
> initialization. Nevertheless, when I plug a bridge board to the
> slot 0, I
> get the following messages:
>
> PCI: Probing PCI hardware
> PCI: Cannot allocate resource region 1 of PCI bridge 1
> PCI: bridge 1 resource 1 moved to 9ff00000..9fffffff
> PCI: Cannot allocate resource region 2 of PCI bridge 1
> PCI: bridge 1 resource 2 moved to 9fe00000..9fefffff
>
> Would you guess that this is a driver problem, or that my board
> setup is still
> incorrect?
That seems like a driver problem. Does lspci show your devices after
you boot? Also, what kernel ver are you using?
- k
^ permalink raw reply
* Re: pci-x
From: Carlos Mitidieri @ 2006-03-24 15:07 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <24661B8C-C4DF-4D9C-8F4A-F2E6600AFFE2@kernel.crashing.org>
On Friday 24 March 2006 15:53, Kumar Gala wrote:
> That seems like a driver problem. Does lspci show your devices after
> you boot? Also, what kernel ver are you using?
No, the device behind the bridge is not recognized, although the bridge itself
is. I am using kernel 2.6.15.
--
Carlos Mitidieri
SYSGO AG - Office Ulm
^ permalink raw reply
* Re: pci_dlpar.c & probe mode
From: John Rose @ 2006-03-24 16:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: External List
In-Reply-To: <1143160576.4257.51.camel@localhost.localdomain>
> I noticed that pcibios_add_pci_devices() test the platform type to
> decide wether to do a device-tree based probe or a direct PCI probe. Why
> can't it use ppc_md.probe_mode() like the rest of the PCI code does ?
I can't see a good reason either! :) I'll have a patch in two shakes of
a lamb's tail.
On a related note, I don't understand why devtree-based probe is only
desirable for the LPAR case (on pSeries).
Also, do we anticipate future probe modes for new platforms or
something? Adding such logic to ppc_md seems like mucho infrastructure
to answer a simple question (lpar or not). For exmaple, _machine gets
used all over the pmac code.
John
^ permalink raw reply
* [PATCH] powerpc: dynamic probe - use ppc_md.pci_probe_mode()
From: John Rose @ 2006-03-24 17:19 UTC (permalink / raw)
To: benh; +Cc: External List, Paul Mackerras
Change the dynamic PCI probe function for pSeries to use
ppc_md.pci_probe_mode() when appropriate.
Signed-off-by: John Rose <johnrose@austin.ibm.com>
---
As suggested by BenH. Tested on POWER5.
Thanks-
John
diff -puN arch/powerpc/platforms/pseries/pci_dlpar.c~use_probe_mode arch/powerpc/platforms/pseries/pci_dlpar.c
--- 2_6_cleanups/arch/powerpc/platforms/pseries/pci_dlpar.c~use_probe_mode 2006-03-24 09:57:08.000000000 -0600
+++ 2_6_cleanups-johnrose/arch/powerpc/platforms/pseries/pci_dlpar.c 2006-03-24 10:12:49.000000000 -0600
@@ -152,20 +152,26 @@ pcibios_pci_config_bridge(struct pci_dev
void
pcibios_add_pci_devices(struct pci_bus * bus)
{
- int slotno, num;
+ int slotno, num, mode;
struct pci_dev *dev;
struct device_node *dn = pci_bus_to_OF_node(bus);
eeh_add_device_tree_early(dn);
- if (_machine == PLATFORM_PSERIES_LPAR) {
+ mode = PCI_PROBE_NORMAL;
+ if (ppc_md.pci_probe_mode)
+ mode = ppc_md.pci_probe_mode(bus);
+
+ if (mode == PCI_PROBE_DEVTREE) {
+ printk("%s: jhr: new probe\n", __FUNCTION__);
/* use ofdt-based probe */
of_scan_bus(dn, bus);
if (!list_empty(&bus->devices)) {
pcibios_fixup_new_pci_devices(bus, 0);
pci_bus_add_devices(bus);
}
- } else {
+ } else if (mode == PCI_PROBE_NORMAL) {
+ printk("%s: jhr: old probe\n", __FUNCTION__);
/* use legacy probe */
slotno = PCI_SLOT(PCI_DN(dn->child)->devfn);
num = pci_scan_slot(bus, PCI_DEVFN(slotno, 0));
_
^ permalink raw reply
* [PATCH] powerpc: dynamic probe - use ppc_md.pci_probe_mode()
From: John Rose @ 2006-03-24 17:25 UTC (permalink / raw)
To: benh; +Cc: External List, Paul Mackerras
In-Reply-To: <1143220753.2567.22.camel@sinatra.austin.ibm.com>
Change the dynamic PCI probe function for pSeries to use
ppc_md.pci_probe_mode() when appropriate.
Signed-off-by: John Rose <johnrose@austin.ibm.com>
---
Actually - how about a version without debug prints!? Original change
suggested by BenH. Tested on POWER5.
Thanks-
John
diff -puN arch/powerpc/platforms/pseries/pci_dlpar.c~use_probe_mode arch/powerpc/platforms/pseries/pci_dlpar.c
--- 2_6_linus/arch/powerpc/platforms/pseries/pci_dlpar.c~use_probe_mode 2006-03-24 09:57:08.000000000 -0600
+++ 2_6_linus-johnrose/arch/powerpc/platforms/pseries/pci_dlpar.c 2006-03-24 11:26:23.000000000 -0600
@@ -152,20 +152,24 @@ pcibios_pci_config_bridge(struct pci_dev
void
pcibios_add_pci_devices(struct pci_bus * bus)
{
- int slotno, num;
+ int slotno, num, mode;
struct pci_dev *dev;
struct device_node *dn = pci_bus_to_OF_node(bus);
eeh_add_device_tree_early(dn);
- if (_machine == PLATFORM_PSERIES_LPAR) {
+ mode = PCI_PROBE_NORMAL;
+ if (ppc_md.pci_probe_mode)
+ mode = ppc_md.pci_probe_mode(bus);
+
+ if (mode == PCI_PROBE_DEVTREE) {
/* use ofdt-based probe */
of_scan_bus(dn, bus);
if (!list_empty(&bus->devices)) {
pcibios_fixup_new_pci_devices(bus, 0);
pci_bus_add_devices(bus);
}
- } else {
+ } else if (mode == PCI_PROBE_NORMAL) {
/* use legacy probe */
slotno = PCI_SLOT(PCI_DN(dn->child)->devfn);
num = pci_scan_slot(bus, PCI_DEVFN(slotno, 0));
_
^ permalink raw reply
* Re: [patch 06/13] powerpc: cell interrupt controller updates
From: Milton Miller @ 2006-03-24 17:43 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnd Bergmann, stk, linux-kernel, linuxppc-dev, Paul Mackerras,
hpenner, cbe-oss-dev
In-Reply-To: <20060323203521.862355000@dyn-9-152-242-103.boeblingen.de.ibm.com>
On Mar 22, 2006, at 5:00 PM, Arnd Bergmann wrote:
> static void spider_enable_irq(unsigned int irq)
> {
> + int nodeid = (irq / IIC_NODE_STRIDE) * 0x10;
> void __iomem *cfg = spider_get_irq_config(irq);
> irq = spider_get_nr(irq);
>
> - out_be32(cfg, in_be32(cfg) | 0x3107000eu);
> + out_be32(cfg, in_be32(cfg) | 0x3107000eu | nodeid);
> out_be32(cfg + 4, in_be32(cfg + 4) | 0x00020000u | irq);
> }
>
I just did a quick read of the code, but my first thought is what if
some other node id was previously set? Perhaps you should mask off
some bits before or'ing in the node id?
milton
^ permalink raw reply
* Re: [patch 06/13] powerpc: cell interrupt controller updates
From: Arnd Bergmann @ 2006-03-24 18:05 UTC (permalink / raw)
To: Milton Miller
Cc: stk, linux-kernel, linuxppc-dev, Paul Mackerras, hpenner,
Arnd Bergmann, cbe-oss-dev
In-Reply-To: <32140afe2349e8f1726d188eb85c780c@bga.com>
On Friday 24 March 2006 18:43, Milton Miller wrote:
> On Mar 22, 2006, at 5:00 PM, Arnd Bergmann wrote:
> > static void spider_enable_irq(unsigned int irq)
> > {
> > + int nodeid = (irq / IIC_NODE_STRIDE) * 0x10;
> > void __iomem *cfg = spider_get_irq_config(irq);
> > irq = spider_get_nr(irq);
> >
> > - out_be32(cfg, in_be32(cfg) | 0x3107000eu);
> > + out_be32(cfg, in_be32(cfg) | 0x3107000eu | nodeid);
> > out_be32(cfg + 4, in_be32(cfg + 4) | 0x00020000u | irq);
> > }
> >
>
> I just did a quick read of the code, but my first thought is what if
> some other node id was previously set? Perhaps you should mask off
> some bits before or'ing in the node id?
Good point. The firmware always sets nodeid zero (or the same one that
we set), but I can't see any reason why we should take that for granted.
Thanks,
Arnd <><
^ permalink raw reply
* Re: [PATCH] powerpc: legacy_serial loop cleanup
From: Hollis Blanchard @ 2006-03-24 18:26 UTC (permalink / raw)
To: linuxppc-dev, mikey; +Cc: michael
In-Reply-To: <20060324041727.F131267B56@ozlabs.org>
On Thursday 23 March 2006 22:17, Michael Neuling wrote:
> We only ever execute the loop once, so let's move it to a function
> making it more readable. Cleanup patch, no functional change.
I don't understand: it's only used once, so make it a function? Why not just
change the "while" to an "if"?
Regardless, two style issues:
- remove the plain "return"
- reduce indenting like so:
if (console < 0)
return;
struct legacy_serial_info *info = ...
> Signed-off-by: Michael Neuling <mikey@neuling.org>
> ---
> arch/powerpc/kernel/legacy_serial.c | 39
+++++++++++++++++++-----------------
> 1 files changed, 21 insertions(+), 18 deletions(-)
>
> Index: linux-2.6-linus/arch/powerpc/kernel/legacy_serial.c
> ===================================================================
> --- linux-2.6-linus.orig/arch/powerpc/kernel/legacy_serial.c
> +++ linux-2.6-linus/arch/powerpc/kernel/legacy_serial.c
> @@ -236,6 +236,26 @@ static int __init add_legacy_pci_port(st
> }
> #endif
>
> +static void __init setup_legacy_serial_console(int console)
> +{
> + if (console >= 0) {
> + struct legacy_serial_info *info =
> + &legacy_serial_infos[legacy_serial_console];
> + void __iomem *addr;
> +
> + if (info->taddr == 0)
> + return;
> + addr = ioremap(info->taddr, 0x1000);
> + if (addr == NULL)
> + return;
> + if (info->speed == 0)
> + info->speed = udbg_probe_uart_speed(addr, info->clock);
> + DBG("default console speed = %d\n", info->speed);
> + udbg_init_uart(addr, info->speed, info->clock);
> + }
> + return;
> +}
> +
> /*
> * This is called very early, as part of setup_system() or eventually
> * setup_arch(), basically before anything else in this file. This function
> @@ -319,24 +339,7 @@ void __init find_legacy_serial_ports(voi
>
> DBG("legacy_serial_console = %d\n", legacy_serial_console);
>
> - /* udbg is 64 bits only for now, that will change soon though ... */
> - while (legacy_serial_console >= 0) {
> - struct legacy_serial_info *info =
> - &legacy_serial_infos[legacy_serial_console];
> - void __iomem *addr;
> -
> - if (info->taddr == 0)
> - break;
> - addr = ioremap(info->taddr, 0x1000);
> - if (addr == NULL)
> - break;
> - if (info->speed == 0)
> - info->speed = udbg_probe_uart_speed(addr, info->clock);
> - DBG("default console speed = %d\n", info->speed);
> - udbg_init_uart(addr, info->speed, info->clock);
> - break;
> - }
> -
> + setup_legacy_serial_console(legacy_serial_console);
> DBG(" <- find_legacy_serial_port()\n");
> }
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* [PATCH] powerpc: fix spider-pic affinity setting
From: Arnd Bergmann @ 2006-03-24 18:46 UTC (permalink / raw)
To: linuxppc-dev
Cc: Arnd Bergmann, Paul Mackerras, linux-kernel, Milton Miller,
cbe-oss-dev
In-Reply-To: <200603241905.04356.arnd.bergmann@de.ibm.com>
As noticed by Milton Miller, setting the initial affinity in
spider-pic can go wrong if the target node field was not orinally
empty.
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
--- linus-2.6.orig/arch/powerpc/platforms/cell/spider-pic.c
+++ linus-2.6/arch/powerpc/platforms/cell/spider-pic.c
@@ -88,7 +88,7 @@ static void spider_enable_irq(unsigned i
void __iomem *cfg = spider_get_irq_config(irq);
irq = spider_get_nr(irq);
- out_be32(cfg, in_be32(cfg) | 0x3107000eu | nodeid);
+ out_be32(cfg, (in_be32(cfg) & ~0xf0)| 0x3107000eu | nodeid);
out_be32(cfg + 4, in_be32(cfg + 4) | 0x00020000u | irq);
}
^ permalink raw reply
* [PATCH] powerpc: use guarded ioremap for on-chip mappings
From: Arnd Bergmann @ 2006-03-24 18:47 UTC (permalink / raw)
To: linuxppc-dev
Cc: stk, linux-kernel, Milton Miller, Paul Mackerras, hpenner,
Arnd Bergmann, cbe-oss-dev
In-Reply-To: <1143152153.4257.28.camel@localhost.localdomain>
Subject: powerpc: use guarded ioremap for cell on-chip mappings
I'm not sure where the information came from, but I assumed
that doing cache-inhibited mappings for mmio regions was
sufficient.
It seems we also need the guarded bit set, like everyone
else, which is the default for ioremap.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
Index: linus-2.6/arch/powerpc/platforms/cell/interrupt.c
===================================================================
--- linus-2.6.orig/arch/powerpc/platforms/cell/interrupt.c
+++ linus-2.6/arch/powerpc/platforms/cell/interrupt.c
@@ -226,9 +226,7 @@ static int setup_iic_hardcoded(void)
regs += 0x20;
printk(KERN_INFO "IIC for CPU %d at %lx\n", cpu, regs);
- iic->regs = __ioremap(regs, sizeof(struct iic_regs),
- _PAGE_NO_CACHE);
-
+ iic->regs = ioremap(regs, sizeof(struct iic_regs));
iic->target_id = (nodeid << 4) + ((cpu & 1) ? 0xf : 0xe);
}
@@ -269,14 +267,12 @@ static int setup_iic(void)
}
iic = &per_cpu(iic, np[0]);
- iic->regs = __ioremap(regs[0], sizeof(struct iic_regs),
- _PAGE_NO_CACHE);
+ iic->regs = ioremap(regs[0], sizeof(struct iic_regs));
iic->target_id = ((np[0] & 2) << 3) + ((np[0] & 1) ? 0xf : 0xe);
printk("IIC for CPU %d at %lx mapped to %p\n", np[0], regs[0], iic->regs);
iic = &per_cpu(iic, np[1]);
- iic->regs = __ioremap(regs[2], sizeof(struct iic_regs),
- _PAGE_NO_CACHE);
+ iic->regs = ioremap(regs[2], sizeof(struct iic_regs));
iic->target_id = ((np[1] & 2) << 3) + ((np[1] & 1) ? 0xf : 0xe);
printk("IIC for CPU %d at %lx mapped to %p\n", np[1], regs[2], iic->regs);
Index: linus-2.6/arch/powerpc/platforms/cell/iommu.c
===================================================================
--- linus-2.6.orig/arch/powerpc/platforms/cell/iommu.c
+++ linus-2.6/arch/powerpc/platforms/cell/iommu.c
@@ -344,8 +344,8 @@ static int cell_map_iommu_hardcoded(int
/* node 0 */
iommu = &cell_iommus[0];
- iommu->mapped_base = __ioremap(0x20000511000, 0x1000, _PAGE_NO_CACHE);
- iommu->mapped_mmio_base = __ioremap(0x20000510000, 0x1000, _PAGE_NO_CACHE);
+ iommu->mapped_base = ioremap(0x20000511000, 0x1000);
+ iommu->mapped_mmio_base = ioremap(0x20000510000, 0x1000);
enable_mapping(iommu->mapped_base, iommu->mapped_mmio_base);
@@ -357,8 +357,8 @@ static int cell_map_iommu_hardcoded(int
/* node 1 */
iommu = &cell_iommus[1];
- iommu->mapped_base = __ioremap(0x30000511000, 0x1000, _PAGE_NO_CACHE);
- iommu->mapped_mmio_base = __ioremap(0x30000510000, 0x1000, _PAGE_NO_CACHE);
+ iommu->mapped_base = ioremap(0x30000511000, 0x1000);
+ iommu->mapped_mmio_base = ioremap(0x30000510000, 0x1000);
enable_mapping(iommu->mapped_base, iommu->mapped_mmio_base);
@@ -407,8 +407,8 @@ static int cell_map_iommu(void)
iommu->base = *base;
iommu->mmio_base = *mmio_base;
- iommu->mapped_base = __ioremap(*base, 0x1000, _PAGE_NO_CACHE);
- iommu->mapped_mmio_base = __ioremap(*mmio_base, 0x1000, _PAGE_NO_CACHE);
+ iommu->mapped_base = ioremap(*base, 0x1000);
+ iommu->mapped_mmio_base = ioremap(*mmio_base, 0x1000);
enable_mapping(iommu->mapped_base,
iommu->mapped_mmio_base);
Index: linus-2.6/arch/powerpc/platforms/cell/pervasive.c
===================================================================
--- linus-2.6.orig/arch/powerpc/platforms/cell/pervasive.c
+++ linus-2.6/arch/powerpc/platforms/cell/pervasive.c
@@ -203,7 +203,7 @@ found:
pr_debug("pervasive area for CPU %d at %lx, size %x\n",
cpu, real_address, size);
- p->regs = __ioremap(real_address, size, _PAGE_NO_CACHE);
+ p->regs = ioremap(real_address, size);
p->thread = thread;
return 0;
}
Index: linus-2.6/arch/powerpc/platforms/cell/spider-pic.c
===================================================================
--- linus-2.6.orig/arch/powerpc/platforms/cell/spider-pic.c
+++ linus-2.6/arch/powerpc/platforms/cell/spider-pic.c
@@ -159,7 +159,7 @@ void spider_init_IRQ_hardcoded(void)
for (node = 0; node < num_present_cpus()/2; node++) {
spiderpic = pics[node];
printk(KERN_DEBUG "SPIDER addr: %lx\n", spiderpic);
- spider_pics[node] = __ioremap(spiderpic, 0x800, _PAGE_NO_CACHE);
+ spider_pics[node] = ioremap(spiderpic, 0x800);
for (n = 0; n < IIC_NUM_EXT; n++) {
int irq = n + IIC_EXT_OFFSET + node * IIC_NODE_STRIDE;
get_irq_desc(irq)->handler = &spider_pic;
@@ -210,7 +210,7 @@ void spider_init_IRQ(void)
if ( n != 2)
printk("reg property with invalid number of elements \n");
- spider_pics[node] = __ioremap(spider_reg, 0x800, _PAGE_NO_CACHE);
+ spider_pics[node] = ioremap(spider_reg, 0x800);
printk("SPIDER addr: %lx with %i addr_cells mapped to %p\n",
spider_reg, n, spider_pics[node]);
^ permalink raw reply
* [PATCH] spufs: Fix endless protection fault on LS writes by SPE.
From: Arnd Bergmann @ 2006-03-24 18:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, Arnd Bergmann, cbe-oss-dev, linux-kernel
In-Reply-To: <20060323203423.620978000@dyn-9-152-242-103.boeblingen.de.ibm.com>
If an SPE attempts a DMA put to a local store after already doing
a get, the kernel must update the HW PTE to allow the write access.
This case was not being handled correctly.
From: Mike Kistler <mkistler@us.ibm.com>
Signed-off-by: Mike Kistler <mkistler@us.ibm.com>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
---
diff -ur linux-2.6.15/arch/powerpc/platforms/cell/spu_base.c linux-2.6.15.fixed/arch/powerpc/platforms/cell/spu_base.c
--- linux-2.6.15/arch/powerpc/platforms/cell/spu_base.c 2006-03-22 12:30:07.000000000 -0600
+++ linux-2.6.15.fixed/arch/powerpc/platforms/cell/spu_base.c 2006-03-22 10:21:26.000000000 -0600
@@ -486,14 +486,13 @@
ea = spu->dar;
dsisr = spu->dsisr;
- if (dsisr & MFC_DSISR_PTE_NOT_FOUND) {
+ if (dsisr & (MFC_DSISR_PTE_NOT_FOUND | MFC_DSISR_ACCESS_DENIED)) {
access = (_PAGE_PRESENT | _PAGE_USER);
access |= (dsisr & MFC_DSISR_ACCESS_PUT) ? _PAGE_RW : 0UL;
if (hash_page(ea, access, 0x300) != 0)
error |= CLASS1_ENABLE_STORAGE_FAULT_INTR;
}
- if ((error & CLASS1_ENABLE_STORAGE_FAULT_INTR) ||
- (dsisr & MFC_DSISR_ACCESS_DENIED)) {
+ if (error & CLASS1_ENABLE_STORAGE_FAULT_INTR) {
if ((ret = spu_handle_mm_fault(spu)) != 0)
error |= CLASS1_ENABLE_STORAGE_FAULT_INTR;
else
^ permalink raw reply
* [PATCH] powerpc: fix cell platform detection
From: Arnd Bergmann @ 2006-03-24 18:52 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, Linux Kernel list, cbe-oss-dev
In-Reply-To: <200603240946.51793.arnd@arndb.de>
All future firmware should have 'CBEA' in the compatible
property in order to tell us that we are running on the
cell platform, so check for that as well as the now
deprecated value we have been using so far.
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
---
This applies on top of the 'Kill machine numbers' patch
from Ben Herrenschmidt.
Index: linus-2.6/arch/powerpc/platforms/cell/setup.c
===================================================================
--- linus-2.6.orig/arch/powerpc/platforms/cell/setup.c
+++ linus-2.6/arch/powerpc/platforms/cell/setup.c
@@ -198,7 +198,14 @@ static void __init cell_init_early(void)
static int __init cell_probe(void)
{
unsigned long root = of_get_flat_dt_root();
- if (!of_flat_dt_is_compatible(root, "IBM,CPB"))
+
+ /*
+ * CPBW was used on early prototypes and will be removed.
+ * The correct identification is CBEA.
+ */
+ if (!of_flat_dt_is_compatible(root, "IBM,CPBW-1.0") &&
+ !of_flat_dt_is_compatible(root, "IBM,CBEA") &&
+ !of_flat_dt_is_compatible(root, "CBEA"))
return 0;
return 1;
^ permalink raw reply
* powerpc: fix hvc-rtas comments
From: Arnd Bergmann @ 2006-03-24 18:58 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, cbe-oss-dev, linux-kernel
In-Reply-To: <200603232336.19683.arnd@arndb.de>
As notice by Olof Johansson, the comment about module_exit
in hvc_rtas is rather confusing, so remove it.
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
---
Index: linus-2.6/drivers/char/hvc_rtas.c
===================================================================
--- linus-2.6.orig/drivers/char/hvc_rtas.c
+++ linus-2.6/drivers/char/hvc_rtas.c
@@ -119,7 +119,7 @@ static void __exit hvc_rtas_exit(void)
if (hvc_rtas_dev)
hvc_remove(hvc_rtas_dev);
}
-module_exit(hvc_rtas_exit); /* before drivers/char/hvc_console.c */
+module_exit(hvc_rtas_exit);
/* This will happen prior to module init. There is no tty at this time? */
static int hvc_rtas_console_init(void)
^ permalink raw reply
* Re: [PATCH] powerpc: Kill machine numbers
From: Olof Johansson @ 2006-03-24 18:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Paul Mackerras, Linux Kernel list
In-Reply-To: <1143187298.3710.3.camel@localhost.localdomain>
On Fri, Mar 24, 2006 at 07:01:38PM +1100, Benjamin Herrenschmidt wrote:
>
> > It would be very useful to print the ppc_md.name of the found machine
> > here, even without debugging enabled.
>
> Not sure ... without debugging enabled, it's likely that you won't see
> anything that early anyway :)
True, but it'd be in the dmesg, and get printed when the console comes up.
> > It's really weird that IBM chose to use "chrp" to describe a
> > PAPR-compliant platform. I guess it's for historical reasons, but it
> > sure isn't CHRP any more.
>
> Yup, I'm trying to get that changed in the architecture but even if I'm
> successful, we'll have to deal with existing machines.
Right, it was mostly a side comment.
> > > + is _not_ "chrp" as this will be matched by the kernel to be a
> > > + CHRP machine on 32 bits kernel or a pSeries on 64 bits kernels
> >
> > ...or a PAPR-compliant machine on 64-bit kernels.
> >
> > (Also, "xx-bit kernels", not "xx bits kernels").
>
> yeah yeah :) Thanks for the review anyway !
Hey, I couldn't find much technical issues, so I ended up reading your
comments and picking errors there instead. :-)
-Olof
^ permalink raw reply
* RE: memory with __get_free_pages and disabling caching
From: Kallol Biswas @ 2006-03-24 19:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
We have a little endian device on a PPC 440GX based system.
The descriptors need to be swapped. With E bit turned on we can save swapping time.
May be all the pages with _get_free_page already are mapped with large tlb entry.
How about making a window (ptes) like consistent memory?
-----Original Message-----
From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
Sent: Thursday, March 23, 2006 7:06 PM
To: Kallol Biswas
Cc: linuxppc-dev@ozlabs.org
Subject: Re: memory with __get_free_pages and disabling caching
On Thu, 2006-03-23 at 18:15 -0800, Kallol Biswas wrote:
> Hello,
> Is there an easy way to set page table attributes for the
> memory returned by __get_free_pages()?
>
> I need to be able to turn off caching and turn on E bit for these
> pages.
The Evil bit ? heh ! what are you trying to do ? here ... you can always create a virtual mapping to those pages with different attributes but that's nor recommended as some processors will shoke pretty badly if you end up with both cacheable and non-cacheable mappings for the same page.
However, it's not always possible to unmap the initial mapping since it's common to use things like large pages, BATs, large TLB entries etc... to map kernel memory..
> I tried to walk through the page tables data structures to get the
> pte, but it seems that the pmd is not present for the pages. If
> someone has done investigation on this before please send me a reply.
>
Kernel linear memory isn't necessarily mapped by the page tables. What are you trying to do and with what processor ?
Ben.
^ permalink raw reply
* Re: memory with __get_free_pages and disabling caching
From: Kumar Gala @ 2006-03-24 19:29 UTC (permalink / raw)
To: Kallol Biswas; +Cc: linuxppc-dev
In-Reply-To: <478F19F21671F04298A2116393EEC3D50A9C21@sjc1exm08.pmc_nt.nt.pmc-sierra.bc.ca>
On Mar 24, 2006, at 1:13 PM, Kallol Biswas wrote:
>
> We have a little endian device on a PPC 440GX based system.
> The descriptors need to be swapped. With E bit turned on we can
> save swapping time.
What's the device and what bus is it on? Are you writing a standard
kernel driver for it?
> May be all the pages with _get_free_page already are mapped with
> large tlb entry.
>
> How about making a window (ptes) like consistent memory?
>
> -----Original Message-----
> From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
> Sent: Thursday, March 23, 2006 7:06 PM
> To: Kallol Biswas
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: memory with __get_free_pages and disabling caching
>
> On Thu, 2006-03-23 at 18:15 -0800, Kallol Biswas wrote:
>> Hello,
>> Is there an easy way to set page table attributes for the
>> memory returned by __get_free_pages()?
>>
>> I need to be able to turn off caching and turn on E bit for these
>> pages.
>
> The Evil bit ? heh ! what are you trying to do ? here ... you can
> always create a virtual mapping to those pages with different
> attributes but that's nor recommended as some processors will shoke
> pretty badly if you end up with both cacheable and non-cacheable
> mappings for the same page.
> However, it's not always possible to unmap the initial mapping
> since it's common to use things like large pages, BATs, large TLB
> entries etc... to map kernel memory..
>
>> I tried to walk through the page tables data structures to get the
>> pte, but it seems that the pmd is not present for the pages. If
>> someone has done investigation on this before please send me a reply.
>>
> Kernel linear memory isn't necessarily mapped by the page tables.
> What are you trying to do and with what processor ?
>
>
>
> Ben.
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: pci_dlpar.c & probe mode
From: Benjamin Herrenschmidt @ 2006-03-24 21:48 UTC (permalink / raw)
To: John Rose; +Cc: External List
In-Reply-To: <1143217005.2567.12.camel@sinatra.austin.ibm.com>
On Fri, 2006-03-24 at 10:16 -0600, John Rose wrote:
> > I noticed that pcibios_add_pci_devices() test the platform type to
> > decide wether to do a device-tree based probe or a direct PCI probe. Why
> > can't it use ppc_md.probe_mode() like the rest of the PCI code does ?
>
> I can't see a good reason either! :) I'll have a patch in two shakes of
> a lamb's tail.
>
> On a related note, I don't understand why devtree-based probe is only
> desirable for the LPAR case (on pSeries).
I think it was dictated by a conservative approach .. it's necessary for
LPAR and we didn't want to change the behaviour on older machines...
besides, things like bare metal may not provide the PCI nodes in OF and
use the same code base.
> Also, do we anticipate future probe modes for new platforms or
> something? Adding such logic to ppc_md seems like mucho infrastructure
> to answer a simple question (lpar or not). For exmaple, _machine gets
> used all over the pmac code.
_machine is gone, see my last patch ... It's not only about lpar or
not .. on powermac, it's really a per-bus & per machine generation
decision wether to trust OF or not..
Ben.
^ permalink raw reply
* [PATCH] PCI Error Recovery: e1000 network device driver
From: Linas Vepstas @ 2006-03-24 22:00 UTC (permalink / raw)
To: Jeff Garzik, john.ronciak, jesse.brandeburg, jeffrey.t.kirsher
Cc: netdev, linux-pci, linux-kernel, linuxppc-dev
Jeff,
Can you please review and forward this patch upstream? A previous
version of this patch has been ack'ed by Jesse Brandeburg, one
of the e1000 maintainers.
--linas
[PATCH] PCI Error Recovery: e1000 network device driver
Various PCI bus errors can be signaled by newer PCI controllers. This
patch adds the PCI error recovery callbacks to the intel gigabit
ethernet e1000 device driver. The patch has been tested, and appears
to work well.
Signed-off-by: Linas Vepstas <linas@linas.org>
Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
----
drivers/net/e1000/e1000_main.c | 114 ++++++++++++++++++++++++++++++++++++++++-
1 files changed, 113 insertions(+), 1 deletion(-)
Index: linux-2.6.16-git6/drivers/net/e1000/e1000_main.c
===================================================================
--- linux-2.6.16-git6.orig/drivers/net/e1000/e1000_main.c 2006-03-23 15:48:01.000000000 -0600
+++ linux-2.6.16-git6/drivers/net/e1000/e1000_main.c 2006-03-24 15:14:40.431371705 -0600
@@ -226,6 +226,16 @@ static int e1000_resume(struct pci_dev *
static void e1000_netpoll (struct net_device *netdev);
#endif
+static pci_ers_result_t e1000_io_error_detected(struct pci_dev *pdev,
+ pci_channel_state_t state);
+static pci_ers_result_t e1000_io_slot_reset(struct pci_dev *pdev);
+static void e1000_io_resume(struct pci_dev *pdev);
+
+static struct pci_error_handlers e1000_err_handler = {
+ .error_detected = e1000_io_error_detected,
+ .slot_reset = e1000_io_slot_reset,
+ .resume = e1000_io_resume,
+};
static struct pci_driver e1000_driver = {
.name = e1000_driver_name,
@@ -235,8 +245,9 @@ static struct pci_driver e1000_driver =
/* Power Managment Hooks */
#ifdef CONFIG_PM
.suspend = e1000_suspend,
- .resume = e1000_resume
+ .resume = e1000_resume,
#endif
+ .err_handler = &e1000_err_handler,
};
MODULE_AUTHOR("Intel Corporation, <linux.nics@intel.com>");
@@ -3063,6 +3074,10 @@ e1000_update_stats(struct e1000_adapter
#define PHY_IDLE_ERROR_COUNT_MASK 0x00FF
+ /* Prevent stats update while adapter is being reset */
+ if (adapter->link_speed == 0)
+ return;
+
spin_lock_irqsave(&adapter->stats_lock, flags);
/* these counters are modified from e1000_adjust_tbi_stats,
@@ -4631,4 +4646,101 @@ e1000_netpoll(struct net_device *netdev)
}
#endif
+/**
+ * e1000_io_error_detected - called when PCI error is detected
+ * @pdev: Pointer to PCI device
+ * @state: The current pci conneection state
+ *
+ * This function is called after a PCI bus error affecting
+ * this device has been detected.
+ */
+static pci_ers_result_t e1000_io_error_detected(struct pci_dev *pdev, pci_channel_state_t state)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ struct e1000_adapter *adapter = netdev->priv;
+
+ netif_device_detach(netdev);
+
+ if (netif_running(netdev))
+ e1000_down(adapter);
+
+ /* Request a slot slot reset. */
+ return PCI_ERS_RESULT_NEED_RESET;
+}
+
+/**
+ * e1000_io_slot_reset - called after the pci bus has been reset.
+ * @pdev: Pointer to PCI device
+ *
+ * Restart the card from scratch, as if from a cold-boot. Implementation
+ * resembles the first-half of the e1000_resume routine.
+ */
+static pci_ers_result_t e1000_io_slot_reset(struct pci_dev *pdev)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ struct e1000_adapter *adapter = netdev->priv;
+
+ if (pci_enable_device(pdev)) {
+ printk(KERN_ERR "e1000: Cannot re-enable PCI device after reset.\n");
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+ pci_set_master(pdev);
+
+ pci_enable_wake(pdev, 3, 0);
+ pci_enable_wake(pdev, 4, 0); /* 4 == D3 cold */
+
+ /* Perform card reset only on one instance of the card */
+ if(0 != PCI_FUNC (pdev->devfn))
+ return PCI_ERS_RESULT_RECOVERED;
+
+ e1000_reset(adapter);
+ E1000_WRITE_REG(&adapter->hw, WUS, ~0);
+
+ return PCI_ERS_RESULT_RECOVERED;
+}
+
+/**
+ * e1000_io_resume - called when traffic can start flowing again.
+ * @pdev: Pointer to PCI device
+ *
+ * This callback is called when the error recovery driver tells us that
+ * its OK to resume normal operation. Implementation resembles the
+ * second-half of the e1000_resume routine.
+ */
+static void e1000_io_resume(struct pci_dev *pdev)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ struct e1000_adapter *adapter = netdev->priv;
+ uint32_t manc, swsm;
+
+ if(netif_running(netdev)) {
+ if (e1000_up(adapter)) {
+ printk("e1000: can't bring device back up after reset\n");
+ return;
+ }
+ }
+
+ netif_device_attach(netdev);
+
+ if(adapter->hw.mac_type >= e1000_82540 &&
+ adapter->hw.media_type == e1000_media_type_copper) {
+ manc = E1000_READ_REG(&adapter->hw, MANC);
+ manc &= ~(E1000_MANC_ARP_EN);
+ E1000_WRITE_REG(&adapter->hw, MANC, manc);
+ }
+
+ switch(adapter->hw.mac_type) {
+ case e1000_82573:
+ swsm = E1000_READ_REG(&adapter->hw, SWSM);
+ E1000_WRITE_REG(&adapter->hw, SWSM,
+ swsm | E1000_SWSM_DRV_LOAD);
+ break;
+ default:
+ break;
+ }
+
+ if(netif_running(netdev))
+ mod_timer(&adapter->watchdog_timer, jiffies);
+}
+
/* e1000_main.c */
^ permalink raw reply
* Diagnostic tool
From: Bizhan Gholikhamseh (bgholikh) @ 2006-03-24 22:05 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 320 bytes --]
Hi,
I am using PQIII Freescale cpu 8541 on a custom board.
Is anyone aware of diagnostics tool as a kernel module to test cpu,
memory and other hardware components that may be out there. This is
normally a test suit that will be used manufacturing for extensive HW
testing.
Thanks and Regards,
Bizhan
[-- Attachment #2: Type: text/html, Size: 790 bytes --]
^ permalink raw reply
* RE: memory with __get_free_pages and disabling caching
From: Paul Mackerras @ 2006-03-24 22:17 UTC (permalink / raw)
To: Kallol Biswas; +Cc: linuxppc-dev
In-Reply-To: <478F19F21671F04298A2116393EEC3D50A9C21@sjc1exm08.pmc_nt.nt.pmc-sierra.bc.ca>
Kallol Biswas writes:
> We have a little endian device on a PPC 440GX based system.
> The descriptors need to be swapped. With E bit turned on we can save
> swapping time.
Writing the descriptors with stwbrx should be just as fast as using
stw, and eliminates the need for a special mapping.
If you need it to be cache-inhibited, you should be using
dma_alloc_coherent() or pci_alloc_consistent().
Paul.
^ permalink raw reply
* RE: memory with __get_free_pages and disabling caching
From: Benjamin Herrenschmidt @ 2006-03-24 22:30 UTC (permalink / raw)
To: Kallol Biswas; +Cc: linuxppc-dev
In-Reply-To: <478F19F21671F04298A2116393EEC3D50A9C21@sjc1exm08.pmc_nt.nt.pmc-sierra.bc.ca>
On Fri, 2006-03-24 at 11:13 -0800, Kallol Biswas wrote:
> We have a little endian device on a PPC 440GX based system.
> The descriptors need to be swapped. With E bit turned on we can save swapping time.
>
> May be all the pages with _get_free_page already are mapped with large tlb entry.
>
> How about making a window (ptes) like consistent memory?
If you allocate with consistent allocator on 4xx, you should be able to
hack the PTEs to set the E bit, but I think it's not necessary. We've
been swapping descriptor for ages without any noticeable performance
loss since pretty much all network devices have little endian descriptor
rings :) Look into using the {ld,st}_le{16,32} inlines, they use the
native swapped load/store instructions of the CPU to store things in
little endian format. They shouldn't cost more or at least not
significantly more than normal load/stores.
Ben.
> -----Original Message-----
> From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
> Sent: Thursday, March 23, 2006 7:06 PM
> To: Kallol Biswas
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: memory with __get_free_pages and disabling caching
>
> On Thu, 2006-03-23 at 18:15 -0800, Kallol Biswas wrote:
> > Hello,
> > Is there an easy way to set page table attributes for the
> > memory returned by __get_free_pages()?
> >
> > I need to be able to turn off caching and turn on E bit for these
> > pages.
>
> The Evil bit ? heh ! what are you trying to do ? here ... you can always create a virtual mapping to those pages with different attributes but that's nor recommended as some processors will shoke pretty badly if you end up with both cacheable and non-cacheable mappings for the same page.
> However, it's not always possible to unmap the initial mapping since it's common to use things like large pages, BATs, large TLB entries etc... to map kernel memory..
>
> > I tried to walk through the page tables data structures to get the
> > pte, but it seems that the pmd is not present for the pages. If
> > someone has done investigation on this before please send me a reply.
> >
> Kernel linear memory isn't necessarily mapped by the page tables. What are you trying to do and with what processor ?
>
>
>
> Ben.
>
^ 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