* [PATCH v2] [02/10] pasemi_mac: Stop using the pci config space accessors for register read/writes
From: Olof Johansson @ 2007-08-23 18:13 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linuxppc-dev
In-Reply-To: <20070822141248.GC16830@lixom.net>
Move away from using the pci config access functions for simple register
access. Our device has all of the registers in the config space (hey,
from the hardware point of view it looks reasonable :-), so we need to
somehow get to it. Newer firmwares have it in the device tree such that
we can just get it and ioremap it there (in case it ever moves in future
products). For now, provide a hardcoded fallback for older firmwares.
Signed-off-by: Olof Johansson <olof@lixom.net>
---
Updated: Removed explicit inlines, cleaned up read functions, fixed
grammar.
Index: mainline/drivers/net/pasemi_mac.c
===================================================================
--- mainline.orig/drivers/net/pasemi_mac.c
+++ mainline/drivers/net/pasemi_mac.c
@@ -83,44 +83,35 @@ static struct pasdma_status *dma_status;
static unsigned int read_iob_reg(struct pasemi_mac *mac, unsigned int reg)
{
- unsigned int val;
-
- pci_read_config_dword(mac->iob_pdev, reg, &val);
- return val;
+ return in_le32(mac->iob_regs+reg);
}
static void write_iob_reg(struct pasemi_mac *mac, unsigned int reg,
unsigned int val)
{
- pci_write_config_dword(mac->iob_pdev, reg, val);
+ out_le32(mac->iob_regs+reg, val);
}
static unsigned int read_mac_reg(struct pasemi_mac *mac, unsigned int reg)
{
- unsigned int val;
-
- pci_read_config_dword(mac->pdev, reg, &val);
- return val;
+ return in_le32(mac->regs+reg);
}
static void write_mac_reg(struct pasemi_mac *mac, unsigned int reg,
unsigned int val)
{
- pci_write_config_dword(mac->pdev, reg, val);
+ out_le32(mac->regs+reg, val);
}
static unsigned int read_dma_reg(struct pasemi_mac *mac, unsigned int reg)
{
- unsigned int val;
-
- pci_read_config_dword(mac->dma_pdev, reg, &val);
- return val;
+ return in_le32(mac->dma_regs+reg);
}
static void write_dma_reg(struct pasemi_mac *mac, unsigned int reg,
unsigned int val)
{
- pci_write_config_dword(mac->dma_pdev, reg, val);
+ out_le32(mac->dma_regs+reg, val);
}
static int pasemi_get_mac_addr(struct pasemi_mac *mac)
@@ -585,7 +576,6 @@ static int pasemi_mac_clean_tx(struct pa
}
mac->tx->next_to_clean += count;
spin_unlock_irqrestore(&mac->tx->lock, flags);
-
netif_wake_queue(mac->netdev);
return count;
@@ -1076,6 +1066,73 @@ static int pasemi_mac_poll(struct net_de
}
}
+static void __iomem * __devinit map_onedev(struct pci_dev *p, int index)
+{
+ struct device_node *dn;
+ void __iomem *ret;
+
+ dn = pci_device_to_OF_node(p);
+ if (!dn)
+ goto fallback;
+
+ ret = of_iomap(dn, index);
+ if (!ret)
+ goto fallback;
+
+ return ret;
+fallback:
+ /* This is hardcoded and ugly, but we have some firmware versions
+ * that don't provide the register space in the device tree. Luckily
+ * they are at well-known locations so we can just do the math here.
+ */
+ return ioremap(0xe0000000 + (p->devfn << 12), 0x2000);
+}
+
+static int __devinit pasemi_mac_map_regs(struct pasemi_mac *mac)
+{
+ struct resource res;
+ struct device_node *dn;
+ int err;
+
+ mac->dma_pdev = pci_get_device(PCI_VENDOR_ID_PASEMI, 0xa007, NULL);
+ if (!mac->dma_pdev) {
+ dev_err(&mac->pdev->dev, "Can't find DMA Controller\n");
+ return -ENODEV;
+ }
+
+ mac->iob_pdev = pci_get_device(PCI_VENDOR_ID_PASEMI, 0xa001, NULL);
+ if (!mac->iob_pdev) {
+ dev_err(&mac->pdev->dev, "Can't find I/O Bridge\n");
+ return -ENODEV;
+ }
+
+ mac->regs = map_onedev(mac->pdev, 0);
+ mac->dma_regs = map_onedev(mac->dma_pdev, 0);
+ mac->iob_regs = map_onedev(mac->iob_pdev, 0);
+
+ if (!mac->regs || !mac->dma_regs || !mac->iob_regs) {
+ dev_err(&mac->pdev->dev, "Can't map registers\n");
+ return -ENODEV;
+ }
+
+ /* The dma status structure is located in the I/O bridge, and
+ * is cache coherent.
+ */
+ if (!dma_status) {
+ dn = pci_device_to_OF_node(mac->iob_pdev);
+ if (dn)
+ err = of_address_to_resource(dn, 1, &res);
+ if (!dn || err) {
+ /* Fallback for old firmware */
+ res.start = 0xfd800000;
+ res.end = res.start + 0x1000;
+ }
+ dma_status = __ioremap(res.start, res.end-res.start, 0);
+ }
+
+ return 0;
+}
+
static int __devinit
pasemi_mac_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
{
@@ -1104,21 +1161,6 @@ pasemi_mac_probe(struct pci_dev *pdev, c
mac->pdev = pdev;
mac->netdev = dev;
- mac->dma_pdev = pci_get_device(PCI_VENDOR_ID_PASEMI, 0xa007, NULL);
-
- if (!mac->dma_pdev) {
- dev_err(&pdev->dev, "Can't find DMA Controller\n");
- err = -ENODEV;
- goto out_free_netdev;
- }
-
- mac->iob_pdev = pci_get_device(PCI_VENDOR_ID_PASEMI, 0xa001, NULL);
-
- if (!mac->iob_pdev) {
- dev_err(&pdev->dev, "Can't find I/O Bridge\n");
- err = -ENODEV;
- goto out_put_dma_pdev;
- }
/* These should come out of the device tree eventually */
mac->dma_txch = index;
@@ -1161,12 +1203,9 @@ pasemi_mac_probe(struct pci_dev *pdev, c
dev->poll = pasemi_mac_poll;
dev->features = NETIF_F_HW_CSUM;
- /* The dma status structure is located in the I/O bridge, and
- * is cache coherent.
- */
- if (!dma_status)
- /* XXXOJN This should come from the device tree */
- dma_status = __ioremap(0xfd800000, 0x1000, 0);
+ err = pasemi_mac_map_regs(mac);
+ if (err)
+ goto out;
mac->rx_status = &dma_status->rx_sta[mac->dma_rxch];
mac->tx_status = &dma_status->tx_sta[mac->dma_txch];
@@ -1193,10 +1232,17 @@ pasemi_mac_probe(struct pci_dev *pdev, c
return err;
out:
- pci_dev_put(mac->iob_pdev);
-out_put_dma_pdev:
- pci_dev_put(mac->dma_pdev);
-out_free_netdev:
+ if (mac->iob_pdev)
+ pci_dev_put(mac->iob_pdev);
+ if (mac->dma_pdev)
+ pci_dev_put(mac->dma_pdev);
+ if (mac->dma_regs)
+ iounmap(mac->dma_regs);
+ if (mac->iob_regs)
+ iounmap(mac->iob_regs);
+ if (mac->regs)
+ iounmap(mac->regs);
+
free_netdev(dev);
out_disable_device:
pci_disable_device(pdev);
@@ -1220,6 +1266,10 @@ static void __devexit pasemi_mac_remove(
pci_dev_put(mac->dma_pdev);
pci_dev_put(mac->iob_pdev);
+ iounmap(mac->regs);
+ iounmap(mac->dma_regs);
+ iounmap(mac->iob_regs);
+
pci_set_drvdata(pdev, NULL);
free_netdev(netdev);
}
Index: mainline/drivers/net/pasemi_mac.h
===================================================================
--- mainline.orig/drivers/net/pasemi_mac.h
+++ mainline/drivers/net/pasemi_mac.h
@@ -52,6 +52,9 @@ struct pasemi_mac_rxring {
struct pasemi_mac {
struct net_device *netdev;
+ void __iomem *regs;
+ void __iomem *dma_regs;
+ void __iomem *iob_regs;
struct pci_dev *pdev;
struct pci_dev *dma_pdev;
struct pci_dev *iob_pdev;
^ permalink raw reply
* powersave-nap
From: Benedict, Michael @ 2007-08-23 20:03 UTC (permalink / raw)
To: linuxppc-embedded
I was curious what the common setting was for
/proc/sysctl/kernel/powersave-nap.
For what its worth, we are running an MPC8347 and we are not counting on
powersaving for our power or heat budget. We are not running off of
batteries and are much more concerned about responsiveness over power
saving.
>From what I have read, it seems that both nap and doze require "a couple
instructions" to wake up. If the responsiveness is the same, is there
any reason to use doze? Why is doze the default?
Thank you,
Michael
^ permalink raw reply
* Re: [PATCH 0/5] Remove unnecessary loops_per_jiffy initialization code
From: Jon Loeliger @ 2007-08-23 20:23 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
In-Reply-To: <1185560634.8055.170.camel@ld0161-tx32>
On Fri, 2007-07-27 at 13:23, Jon Loeliger wrote:
> This patch series removes lingering jiffies initialization
> code from several platforms. Note that the first patch in
> this series for the 86xx has been rebased to current top of
> Paul's repository and replaces an earlier version.
>
>
> arch/powerpc/platforms/52xx/lite5200.c | 13 ++-----------
> arch/powerpc/platforms/85xx/mpc85xx_ads.c | 13 -------------
> arch/powerpc/platforms/85xx/mpc85xx_cds.c | 13 -------------
> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 11 -----------
> arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 14 ++------------
> arch/powerpc/platforms/8xx/mpc86xads_setup.c | 14 --------------
> arch/powerpc/platforms/8xx/mpc885ads_setup.c | 14 --------------
> arch/powerpc/platforms/embedded6xx/holly.c | 12 ------------
> arch/powerpc/platforms/embedded6xx/prpmc2800.c | 7 -------
> 9 files changed, 4 insertions(+), 107 deletions(-)
Kumar,
Any reason why patches 1/5 and 2/5, for 86xx and 85xx respectively,
did not get applied and ushered upstream with the others?
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH 2/3] Consolidate XILINX_VIRTEX board support.
From: Robert Woodworth @ 2007-08-23 20:34 UTC (permalink / raw)
To: wolfgang.reissnegger; +Cc: Stephen Neuendorffer, linuxppc-embedded
In-Reply-To: <20070822005049.12FE46F8069@mail8-cpk.bigfish.com>
On Tue, 2007-08-21 at 17:53 -0700, wolfgang.reissnegger@xilinx.com
wrote:
> From: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
>
> Make support for Xilinx boards more generic, making it easier
> to add new boards. ML300 and ML403 now use this. Added
> CONFIG_XILINX_EMBED_CONFIG to do the consolidation, while still
> allowing boards not in the tree to avoid embed_config.
>
I like it!
This is exactly what I'll use for my custom board.
RJW
^ permalink raw reply
* Re: [PATCH 0/5] Remove unnecessary loops_per_jiffy initialization code
From: Kumar Gala @ 2007-08-23 20:47 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1187900581.28951.17.camel@ld0161-tx32>
On Aug 23, 2007, at 3:23 PM, Jon Loeliger wrote:
> On Fri, 2007-07-27 at 13:23, Jon Loeliger wrote:
>> This patch series removes lingering jiffies initialization
>> code from several platforms. Note that the first patch in
>> this series for the 86xx has been rebased to current top of
>> Paul's repository and replaces an earlier version.
>>
>>
>> arch/powerpc/platforms/52xx/lite5200.c | 13 ++-----------
>> arch/powerpc/platforms/85xx/mpc85xx_ads.c | 13 -------------
>> arch/powerpc/platforms/85xx/mpc85xx_cds.c | 13 -------------
>> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 11 -----------
>> arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 14 ++------------
>> arch/powerpc/platforms/8xx/mpc86xads_setup.c | 14 --------------
>> arch/powerpc/platforms/8xx/mpc885ads_setup.c | 14 --------------
>> arch/powerpc/platforms/embedded6xx/holly.c | 12 ------------
>> arch/powerpc/platforms/embedded6xx/prpmc2800.c | 7 -------
>> 9 files changed, 4 insertions(+), 107 deletions(-)
>
> Kumar,
>
> Any reason why patches 1/5 and 2/5, for 86xx and 85xx respectively,
> did not get applied and ushered upstream with the others?
No, I'm glad you said something cause I assumed paul grabbed them all.
I'll grab them in my tree once I beat paul into pulling the include
fixup changes.
- k
^ permalink raw reply
* Re: [PATCH 0/5] Remove unnecessary loops_per_jiffy initialization code
From: Jon Loeliger @ 2007-08-23 21:04 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <CF601BCB-6F43-4CE2-A70B-0790DDBB19F7@kernel.crashing.org>
On Thu, 2007-08-23 at 15:47, Kumar Gala wrote:
> > Any reason why patches 1/5 and 2/5, for 86xx and 85xx respectively,
> > did not get applied and ushered upstream with the others?
>
> No, I'm glad you said something cause I assumed paul grabbed them all.
>
> I'll grab them in my tree once I beat paul into pulling the include
> fixup changes.
>
> - k
OK, sounds good.
Thanks,
jdl
^ permalink raw reply
* c67x00 driver again.
From: Robertson, Joseph M. @ 2007-08-23 21:05 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2793 bytes --]
Hi all,
I think I am getting closer. With the c67x00 hcd driver do I need the usb-hcd to be running?
I think I missed a link somewhere. The driver loads, buts inserting a memstick does nothing.
I'm thinking I need to be connected to the core somehow. I have the usb-core as builtin.
Again its heavily custom 2.6.17.3 on a virtex-4 ppc. 2 usb ports wired out.
I had a meltdown yesterday so some of the prinks are different...
-----
c67x00 init.
c67x00 udc init.
c67x00 drv probing.
c67x00 before mem.
c67x00 before irq.
c67x00 before mem alloc.
c67x00 setup sies.
c67x00 before ll init.
c67x00 c67x00.0: USB OTG controller, p:0x43e00000, v:0xc5220000, irq:3
c67x00 c67x00_sie.0: Cypress C67X00 Host Controller
c67x00 c67x00_sie.0: new USB bus registered, assigned bus number 1
c67x00, hcd start.<6>usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
c67x00 c67x00_sie.1: Cypress C67X00 Host Controller
c67x00 c67x00_sie.1: new USB bus registered, assigned bus number 2
c67x00, hcd start.<6>usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usb-storage: usb_stor_exit() called
usb-storage: -- calling usb_deregister()
usbcore: deregistering driver usb-storage
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
-----
Thanks,
Joe Robertson
x8259
Joseph.Robertson@sanmina-sci.com
CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof.
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries), or any other person or entity.
[-- Attachment #2: Type: text/html, Size: 3399 bytes --]
^ permalink raw reply
* [RFC] xmon: setjmp / longjmp implementation problems
From: Florian Boelstler @ 2007-08-23 22:40 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
Hi,
I was hunting an ugly problem in the NuBus PowerMac port of Linux [1]
for a while now (that platform isn't included in mainline kernel and
still is based on 2.4 kernel series).
Linux was successfully built using gcc-3.3.5/binutils-2.15 so far.
Later toolchain versions (e.g. gcc-3.4.5/binutils-2.15) turned out to
break things during hardware detection on the NuBus.
Looking at the relevant code sections shows that the register probing
code is based on the setjmp/longjmp implementation [2] found in xmon.
Regarding the "ppc" platform that code almost matches at least up to
mainline kernel 2.6.20.1 [3].
On the "powerpc" platform the code did dramatically change [4].
I was extracting both implementations to a simple userspace application
to be able to easily try different compiler versions and optimization
levels.
Eventually I found out that the temporary solution is to build the
ppc-implementation using -O1 for gcc versions >3.3.5.
Since I found a comment by Paul in arch/ppc/xmon/setjmp.c: "NB this file
must be compiled with -O2.", I was wondering which toolchain versions
are/were used to compile xmon-enabled kernels for the ppc and powerpc
platform.
Since -O2 seems to be the default for 2.6 kernels as well, I am
wondering what gcc version is known to build a kernel with xmon support.
Are there are any known gcc versions, which are causing trouble with
xmon (actually its setjmp/longjmp implementation)?
Some details of toolchain tests follow:
"ppc" implementation:
When -O2 is used gcc-3.4.5 inlines static functions by default, which
turned out to be the first problem. Even when "static" is removed the
resulting program flow reflects an infinite loop (when longjumped
function returns).
I found out that -O1 with gcc-3.4.5 generates code, which resembles the
functionality of gcc-3.3.5 with -O2. I.e. a working version of
setjmp/longjmp. A segmentation fault occurs when no optimization level
is used.
With gcc-4.1.0 no successful working build was possible.
"powerpc" implementation:
The binary works with no optimization level, -O0 and -O1 with gcc-3.4.5.
Using -O2 turns the resulting code into an infinite loop again.
With gcc-4.1.0/binutils-2.16.1 only -O0 generated a useful binary.
Thanks for any suggestions!
Florian
[1] http://nubus-pmac.sf.net
[2]
http://nubus-pmac.cvs.sourceforge.net/nubus-pmac/linuxppc-2.4-nubus/arch/ppc/platforms/nbpmac_setup.c
Lines 162-194
[3] http://lxr.linux.no/source/arch/ppc/xmon/setjmp.c?a=ppc
[4] http://lxr.linux.no/source/arch/powerpc/xmon/setjmp.S?a=ppc
^ permalink raw reply
* [PATCH] powerpc: prom_init whitespace cleanup, typo fix.
From: Linas Vepstas @ 2007-08-23 23:09 UTC (permalink / raw)
To: Paul Mackerras; +Cc: ppc-dev
Whitespace cleanup: badly indented lines.
Typo in comment.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
---
Yeah, OK, so the patch is lame. Stuff caught my eye while reading code.
arch/powerpc/kernel/prom_init.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
Index: linux-2.6.22-git2/arch/powerpc/kernel/prom_init.c
===================================================================
--- linux-2.6.22-git2.orig/arch/powerpc/kernel/prom_init.c 2007-07-08 18:32:17.000000000 -0500
+++ linux-2.6.22-git2/arch/powerpc/kernel/prom_init.c 2007-08-23 17:27:37.000000000 -0500
@@ -1197,7 +1197,7 @@ static void __init prom_initialize_tce_t
if ((type[0] == 0) || (strstr(type, RELOC("pci")) == NULL))
continue;
- /* Keep the old logic in tack to avoid regression. */
+ /* Keep the old logic intact to avoid regression. */
if (compatible[0] != 0) {
if ((strstr(compatible, RELOC("python")) == NULL) &&
(strstr(compatible, RELOC("Speedwagon")) == NULL) &&
@@ -2224,7 +2224,7 @@ static void __init fixup_device_tree(voi
static void __init prom_find_boot_cpu(void)
{
- struct prom_t *_prom = &RELOC(prom);
+ struct prom_t *_prom = &RELOC(prom);
u32 getprop_rval;
ihandle prom_cpu;
phandle cpu_pkg;
@@ -2244,7 +2244,7 @@ static void __init prom_find_boot_cpu(vo
static void __init prom_check_initrd(unsigned long r3, unsigned long r4)
{
#ifdef CONFIG_BLK_DEV_INITRD
- struct prom_t *_prom = &RELOC(prom);
+ struct prom_t *_prom = &RELOC(prom);
if (r3 && r4 && r4 != 0xdeadbeef) {
unsigned long val;
@@ -2277,7 +2277,7 @@ unsigned long __init prom_init(unsigned
unsigned long pp,
unsigned long r6, unsigned long r7)
{
- struct prom_t *_prom;
+ struct prom_t *_prom;
unsigned long hdr;
unsigned long offset = reloc_offset();
@@ -2336,8 +2336,8 @@ unsigned long __init prom_init(unsigned
/*
* Copy the CPU hold code
*/
- if (RELOC(of_platform) != PLATFORM_POWERMAC)
- copy_and_flush(0, KERNELBASE + offset, 0x100, 0);
+ if (RELOC(of_platform) != PLATFORM_POWERMAC)
+ copy_and_flush(0, KERNELBASE + offset, 0x100, 0);
/*
* Do early parsing of command line
^ permalink raw reply
* Re: [PATCH] Move serial_dev_init to device_initcall()
From: Guennadi Liakhovetski @ 2007-08-23 23:21 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20070823002637.GA24332@lixom.net>
On Wed, 22 Aug 2007, Olof Johansson wrote:
> With the I/O space rewrite by BenH, the legacy_serial serial_dev_init()
> initcall is now called before I/O space is setup, but it's dependent on
> it being available.
>
> Since there's no way to make dependencies between initcalls, we'll just
> have to move it to device_initcall(). Yes, it's suboptimal but I'm not
> aware of any better solution at this time.
Do I understand it right, that with this change all UARTs, controlled by
legacy_serial will be initialized later, and that for example console
output will be first possible later? Maybe, if there is really no other
possibility for I/O space devices, we could have both calls
arch_initcall(serial_mem_dev_init);
device_initcall(serial_io_dev_init);
so, that at least MEMIO based UARTs could still initialize as before?
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: 2.6.23-rc3 broken on G5
From: Paul Mackerras @ 2007-08-23 23:33 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <jetzqvk9of.fsf@sykes.suse.de>
Andreas Schwab writes:
> That didn't change anything visibly.
OK, please try this one and let me know if it fixes it.
Paul.
diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
index a73d2d7..1ca87eb 100644
--- a/arch/powerpc/mm/slb.c
+++ b/arch/powerpc/mm/slb.c
@@ -89,7 +89,7 @@ void slb_flush_and_rebolt(void)
vflags = SLB_VSID_KERNEL | vmalloc_llp;
ksp_esid_data = mk_esid_data(get_paca()->kstack, 2);
- if ((ksp_esid_data & ESID_MASK) == PAGE_OFFSET) {
+ if ((ksp_esid_data & ESID_MASK) <= PAGE_OFFSET) {
ksp_esid_data &= ~SLB_ESID_V;
slb_shadow_clear(2);
} else {
^ permalink raw reply related
* Re: [PATCH 1/2] [POWERPC] Remove cmd_line from head*.S
From: Milton Miller @ 2007-08-23 23:17 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1A23DF12-65EB-4236-B78A-ADF1DDF0FFFD@kernel.crashing.org>
On Thu Aug 23 13:27:31 EST 2007, Kumar Gala wrote:
> On Aug 22, 2007, at 10:09 PM, Stephen Rothwell wrote:
>>
>> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
>> index 0028fe6..dc85005 100644
>> --- a/arch/powerpc/kernel/prom.c
>> +++ b/arch/powerpc/kernel/prom.c
>> @@ -60,6 +60,8 @@
>> #endif
>>
>>
>> +char cmd_line[COMMAND_LINE_SIZE];
>> +
>
> would this be better in setup-common.c?
>
I strongly agree with Kumar. It doesn't belong in prom.c
milton
^ permalink raw reply
* [PATCH 04/30] powerpc: Don't cast kmalloc return value in ibmebus.c
From: Jesper Juhl @ 2007-08-23 23:45 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: linuxppc-dev, Heiko J Schick, Joachim Fenkes, Paul Mackerras,
Jesper Juhl
In-Reply-To: <1554af80879a7ef2f78a4d654f23c248203500d9.1187912217.git.jesper.juhl@gmail.com>
kmalloc() returns a void pointer so there is absolutely no need to
cast it in ibmebus_chomp().
Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
---
arch/powerpc/kernel/ibmebus.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c
index 9a8c9af..9514e66 100644
--- a/arch/powerpc/kernel/ibmebus.c
+++ b/arch/powerpc/kernel/ibmebus.c
@@ -383,7 +383,8 @@ static int ibmebus_match_path(struct device *dev, void *data)
static char *ibmebus_chomp(const char *in, size_t count)
{
- char *out = (char*)kmalloc(count + 1, GFP_KERNEL);
+ char *out = kmalloc(count + 1, GFP_KERNEL);
+
if (!out)
return NULL;
--
1.5.2.2
^ permalink raw reply related
* Re: [PATCH] Move serial_dev_init to device_initcall()
From: Olof Johansson @ 2007-08-23 23:15 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.60.0708240117460.3246@poirot.grange>
On Fri, Aug 24, 2007 at 01:21:57AM +0200, Guennadi Liakhovetski wrote:
> On Wed, 22 Aug 2007, Olof Johansson wrote:
>
> > With the I/O space rewrite by BenH, the legacy_serial serial_dev_init()
> > initcall is now called before I/O space is setup, but it's dependent on
> > it being available.
> >
> > Since there's no way to make dependencies between initcalls, we'll just
> > have to move it to device_initcall(). Yes, it's suboptimal but I'm not
> > aware of any better solution at this time.
>
> Do I understand it right, that with this change all UARTs, controlled by
> legacy_serial will be initialized later, and that for example console
> output will be first possible later?
Yes, unfortunately. Unless they've got a udbg driver, since that
would give console output during early boot anyway (even without using
EARLY_DEBUG).
> Maybe, if there is really no other
> possibility for I/O space devices, we could have both calls
>
> arch_initcall(serial_mem_dev_init);
> device_initcall(serial_io_dev_init);
>
> so, that at least MEMIO based UARTs could still initialize as before?
That's quite a hack, I hope we can avoid it. Maybe Ben has some suggestion
on how to get the IO setup earlier instead.
-Olof
^ permalink raw reply
* Re: [PATCH 04/30] powerpc: Don't cast kmalloc return value in ibmebus.c
From: Joachim Fenkes @ 2007-08-24 0:37 UTC (permalink / raw)
To: Jesper Juhl
Cc: linuxppc-dev, Heiko J Schick, Paul Mackerras, Jesper Juhl,
Linux Kernel Mailing List
In-Reply-To: <91dcfc2a1b0be436d04f9bc45bb6f8657a8d6ff4.1187912217.git.jesper.juhl@gmail.com>
> kmalloc() returns a void pointer so there is absolutely no need to
> cast it in ibmebus_chomp().
>
> Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
Acked-By: Joachim Fenkes <fenkes@de.ibm.com>
^ permalink raw reply
* Re: [PATCH 05/20] bootwrapper: flatdevtree fixes
From: David Gibson @ 2007-08-24 1:01 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus
In-Reply-To: <46CDC86E.2070907@freescale.com>
On Thu, Aug 23, 2007 at 12:48:30PM -0500, Scott Wood wrote:
> David Gibson wrote:
> > Actually, no - sorry, that's the other problem with this, which I
> > forgot to mention. On real OF, the "name" property contains the
> > node's name *without the unit address*; that is, only the portion
> > before the '@'. So your getprop change does not match real OF
> > behaviour - and real OF behaviour will not do what you want for
> > dt_get_path().
>
> Ah, OK.
>
> > Actually, in any case, I don't think we want to implement get_path()
> > this way for real OF. Better to have get_path() itself as a callback:
> > on real OF I believe we can directly ask for the full path to a given
> > phandle, the get name based implementation can then be made specific
> > to the flat device tree.
> >
> > Or actually, I think we might be able to come up with a get_path()
> > implementation for flat tree that's less hideous than repeatedly
> > calling get_parent() which is an ugly, ugly operation on the flat tree
>
> It's likely to be ugly no matter what, though I'll try to come up with
> something slightly nicer. If I were doing this code from scratch, I'd
> probably liven the tree first and reflatten it to pass to the kernel.
Eh, probably not worth bothering doing an actual implementation at
this stage - I'll have to redo it for libfdt anyway.
> > (and will get worse with libfdt).
>
> Why is that?
flatdevtree uses some of the information it caches in the phandle
context stuff to remember who's the parent of a node. libfdt uses raw
offsets into the structure, so the *only* way to implement
get_parent() is to rescan the dt from the beginning, keeping track of
parents until reaching the given node.
> >>Plus, something might come along that needs to dynamically look for
> >>either name or something else. It's more flexible this way.
> >
> > Hrm... "something might come along" just seems contrived to me.
>
> Well, I generally prefer doing things the more flexible way in the
> absence of a good reason not to. OF returning the bare name is a good
> reason not to.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [patch 1/2] powerpc: rmb fix
From: Nick Piggin @ 2007-08-24 2:47 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <7dc0bb83644f4cd44b4810a99d0003a1@kernel.crashing.org>
On Thu, Aug 23, 2007 at 07:57:20PM +0200, Segher Boessenkool wrote:
> >>The powerpc kernel needs to have full sync insns in every I/O
> >>accessor in order to enforce all the ordering rules Linux demands.
> >>It's a bloody shame, but the alternative would be to make the
> >>barriers lots more expensive. A third alternative would be to
> >
> >Well lots more expensive compared to what you have now. But what
> >you have now is like having those expensive barriers between
> >*every* io access.
>
> Yeah. But I/O reads are very expensive anyway, and the barriers
> are used for more than just I/O ordering.
rmb() should only be used when IO ordering matters. smp_rmb() is
for regular ordering.
So doesn't the fact IO reads are very expensive anyway lend more
weight _to have_ the full IO ordering in rmb()?
> I/O writes are a different thing; ideally, they would use only
> eieio, if anything at all.
For IO to IO ordering, yes eieio would be ideal. I don't know that
there is really such a primitive for that in Linux. io_wmb().
> Maybe the tradeoff isn't optimal. The I/O primitives didn't have
> all those "sync"s in there before, they got added because some bad
> interaction with spinlocks was discovered, if my memory isn't failing
> me.
I think it may have been because IO ops are pretty strongly ordered
on x86, and it was thought that a fair amount of code was relying on
that. So the old primitives were made quite strongly ordered, and
new ones were added to avoid the overhead. Unfortunately, you can't
actually use the unordered ones unless you have working barrier
instructions. Hence why I think rmb() should be an IO barrier.
But I'm not pushing this too hard. You guys all know the gory ppc
details better than I, so I'll just leave it with you to work out
whether it is the right thing to do.
> >>have barrier ops that do not order everything, but just A vs. B
> >>for various choices of A and B (coherent accesses, MMIO accesses,
> >>etc.)
> >
> >The non-smp_ variant is supposed to order everything, AFAIK. Maybe
> >you could get more fancy and have PIO vs MMIO etc etc. but it looks
> >like this whole area is in a pretty sticky state anyway so let's
> >not think about that.
>
> *Thinking* about it is fun. Trying to get the code merged would be
> a different thing ;-)
;)
^ permalink raw reply
* Re: wmb vs mmiowb
From: Nick Piggin @ 2007-08-24 2:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-ia64, Jesse Barnes, linuxppc-dev
In-Reply-To: <alpine.LFD.0.999.0708230915000.30176@woody.linux-foundation.org>
On Thu, Aug 23, 2007 at 09:16:42AM -0700, Linus Torvalds wrote:
>
>
> On Thu, 23 Aug 2007, Nick Piggin wrote:
> >
> > Also, FWIW, there are some advantages of deferring the mmiowb thingy
> > until the point of unlock.
>
> And that is exactly what ppc64 does.
>
> But you're missing a big point: for 99.9% of all hardware, mmiowb() is a
> total no-op. So when you talk about "advantages", you're not talking about
> any *real* advantage, are you?
You're in a feisty mood today ;)
I guess on the 0.1% of hradware where it is not a noop, there might be a
real advantage... but that was just handwaving anyway. My real point was
that I'd like things to be more easily understandable.
I think we are agreed at this point that mmiowb without some form of CPU
synchronisation is a bug, and it is also not of the same type of barrier
that we normally think about in the kernel (it could be like a MPI style
rendezvous barrier between the CPU and the IO fabric). Anyway, point is
that device drivers seem to have enough on their plate already.
Look at bcm43xx, for example. Most of this guy's mmiowb()s are completely
wrong and should be wmb(). mmiowb() is only a wmb() on ppc because as I
said, ppc's spin_unlock does not order IOs like most other architectures.
On alpha, for example, spin_unlock does order IOs, so mmiowb is a noop,
and this is broken (non-sn2 ia64 should also be a noop here, because
their unlock orders IOs, but it seems that mmiowb semantics are so non
obvious that they either got it wrong themselves, or assumed device
drivers surely would).
^ permalink raw reply
* Re: wmb vs mmiowb
From: Nick Piggin @ 2007-08-24 3:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Jesse Barnes, linux-ia64, Linus Torvalds, linuxppc-dev
In-Reply-To: <1187886462.5972.17.camel@localhost.localdomain>
On Thu, Aug 23, 2007 at 06:27:42PM +0200, Benjamin Herrenschmidt wrote:
> On Thu, 2007-08-23 at 09:16 -0700, Linus Torvalds wrote:
> >
> > On Thu, 23 Aug 2007, Nick Piggin wrote:
> > >
> > > Also, FWIW, there are some advantages of deferring the mmiowb thingy
> > > until the point of unlock.
> >
> > And that is exactly what ppc64 does.
> >
> > But you're missing a big point: for 99.9% of all hardware, mmiowb() is a
> > total no-op. So when you talk about "advantages", you're not talking about
> > any *real* advantage, are you?
>
> I wonder whether it might be worth removing mmiowb and having all archs
> that matter do like ppc64 though... It's just yet another confusing
> barrier that most driver writers get wrong..
Only sn2 and powerpc really matter, actually (for different reasons).
All smp architectures other than powerpc appear to have barrier
instructions that order all memory operations, so IOs never leak
out of locking primitives. This is why powerpc wants a wmb (not
mmiowb) before spin_unlock to order IOs (pity about other locking
primitives).
And all platforms other than sn2 don't appear to reorder IOs after
they leave the CPU, so only sn2 needs to do the mmiowb thing before
spin_unlock.
^ permalink raw reply
* Re: wmb vs mmiowb
From: Nick Piggin @ 2007-08-24 3:12 UTC (permalink / raw)
To: Jesse Barnes; +Cc: linux-ia64, Linus Torvalds, linuxppc-dev
In-Reply-To: <200708230956.17049.jesse.barnes@intel.com>
On Thu, Aug 23, 2007 at 09:56:16AM -0700, Jesse Barnes wrote:
> On Thursday, August 23, 2007 12:27 am Benjamin Herrenschmidt wrote:
> > > Of course, the normal memory barrier would usually be a
> > > "spin_unlock()" or something like that, not a "wmb()". In fact, I
> > > don't think the powerpc implementation (as an example of this) will
> > > actually synchronize with anything *but* a spin_unlock().
> >
> > We are even more sneaky in the sense that we set a per-cpu flag on
> > any MMIO write and do the sync automatically in spin_unlock() :-)
>
> Yeah, that's a reasonable thing to do, and in fact I think there's code
> to do something similar when a task is switched out (this keeps user
> level drivers from having do mmiowb() type things).
It might be worth doing that and removing mmiowb completely. Or, if
that's too expensive, I'd like to see an API that is more explicitly
for keeping IOs inside critical sections.
> FWIW, I think I had an earlier version of the patch that used the name
> pioflush() or something similar, the only confusing thing about that
> name is that the primitive doesn't actually force I/Os down to the
> device level, just to the closest bridge.
Yeah, that's what I found when trying to think of a name ;) It is
like an intermediate-level flush for the platform code, but from the
POV of the driver writer, it is nothing of the sort ;)
^ permalink raw reply
* Problems on porting linux 2.6 to xilinx ML410
From: woyuzhilei @ 2007-08-24 3:11 UTC (permalink / raw)
To: grant.likely; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1444 bytes --]
Hey:
Recently I'm doing some project on Xilinx Ml410 evaluation board.The first step is porting linux 2.6 to ml410,but I got some problems on this,and my project cann't proceed,so I come to you for some help.
I use the linux kernel source tree download from http://git.secretlab.ca/git/linux-2.6-virtex.git (The latest one).Add the file the xparameters.h,xparameter_ml40x.h. Then add arch/ppc/platforms/4xx/xilinx_generic_ppc.c(Use the patch I get here),and change it's name to ml40x.c,then I make some necessay change of the configuration files to accept selecting a Ml40x type board.Then compile the kernel,and get the image file from arch/ppc/boot/images, (On kernel compiling,the only device driver I sellect is " 8250/16550 and compatible serial support ").After that I download the zImage.elf file to the target board,and run it.But there is no output from the serial port at all.Am I doing somthing wrong?I really don't know goes wrong.
Can anyone here help me with this?Any help from you is appreciated.Thank you very much!
woyuzhilei
2007-08-24
[-- Attachment #2: Type: text/html, Size: 3952 bytes --]
^ permalink raw reply
* Re: [PATCH v2] [02/10] pasemi_mac: Stop using the pci config space accessors for register read/writes
From: Stephen Rothwell @ 2007-08-24 4:05 UTC (permalink / raw)
To: Olof Johansson; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <20070823181310.GB31882@lixom.net>
[-- Attachment #1: Type: text/plain, Size: 593 bytes --]
On Thu, 23 Aug 2007 13:13:10 -0500 Olof Johansson <olof@lixom.net> wrote:
>
> out:
> - pci_dev_put(mac->iob_pdev);
> -out_put_dma_pdev:
> - pci_dev_put(mac->dma_pdev);
> -out_free_netdev:
> + if (mac->iob_pdev)
> + pci_dev_put(mac->iob_pdev);
> + if (mac->dma_pdev)
> + pci_dev_put(mac->dma_pdev);
It is not documented as such (as far as I can see), but pci_dev_put is
safe to call with NULL. And there are other places in the kernel that
explicitly use that fact.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Move serial_dev_init to device_initcall()
From: Benjamin Herrenschmidt @ 2007-08-24 4:59 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Guennadi Liakhovetski
In-Reply-To: <20070823231510.GA5619@lixom.net>
On Thu, 2007-08-23 at 18:15 -0500, Olof Johansson wrote:
> On Fri, Aug 24, 2007 at 01:21:57AM +0200, Guennadi Liakhovetski wrote:
> > On Wed, 22 Aug 2007, Olof Johansson wrote:
> >
> > > With the I/O space rewrite by BenH, the legacy_serial serial_dev_init()
> > > initcall is now called before I/O space is setup, but it's dependent on
> > > it being available.
> > >
> > > Since there's no way to make dependencies between initcalls, we'll just
> > > have to move it to device_initcall(). Yes, it's suboptimal but I'm not
> > > aware of any better solution at this time.
> >
> > Do I understand it right, that with this change all UARTs, controlled by
> > legacy_serial will be initialized later, and that for example console
> > output will be first possible later?
>
> Yes, unfortunately. Unless they've got a udbg driver, since that
> would give console output during early boot anyway (even without using
> EARLY_DEBUG).
Legacy ports should get udbg first.
> > Maybe, if there is really no other
> > possibility for I/O space devices, we could have both calls
> >
> > arch_initcall(serial_mem_dev_init);
> > device_initcall(serial_io_dev_init);
> >
> > so, that at least MEMIO based UARTs could still initialize as before?
>
> That's quite a hack, I hope we can avoid it. Maybe Ben has some suggestion
> on how to get the IO setup earlier instead.
IO space allocation now relies on get_vm_area() which can't be done too
early (not in setup_arch) which is why I allocate all PCI IO space at
PHB scanning time, which is a subsys initcall.
An option would be to do it from some other init call, but that's a bit
ugly. That means PCI would be split into setup_arch() setting up PHBs,
that initcall allocating the IO spaces, and later, the actual scan.
It would be tricky though as my current interface relies on pci_bus
structures. So you would also need to re-split that into a low-level
that works on the PHB and a high level version that works on the bus.
Is this really necessary ?
Ben.
^ permalink raw reply
* Re: [PATCH] Move serial_dev_init to device_initcall()
From: Olof Johansson @ 2007-08-24 4:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Guennadi Liakhovetski
In-Reply-To: <1187931578.5972.25.camel@localhost.localdomain>
On Fri, Aug 24, 2007 at 06:59:38AM +0200, Benjamin Herrenschmidt wrote:
> On Thu, 2007-08-23 at 18:15 -0500, Olof Johansson wrote:
> > On Fri, Aug 24, 2007 at 01:21:57AM +0200, Guennadi Liakhovetski wrote:
> > > On Wed, 22 Aug 2007, Olof Johansson wrote:
> > >
> > > > With the I/O space rewrite by BenH, the legacy_serial serial_dev_init()
> > > > initcall is now called before I/O space is setup, but it's dependent on
> > > > it being available.
> > > >
> > > > Since there's no way to make dependencies between initcalls, we'll just
> > > > have to move it to device_initcall(). Yes, it's suboptimal but I'm not
> > > > aware of any better solution at this time.
> > >
> > > Do I understand it right, that with this change all UARTs, controlled by
> > > legacy_serial will be initialized later, and that for example console
> > > output will be first possible later?
> >
> > Yes, unfortunately. Unless they've got a udbg driver, since that
> > would give console output during early boot anyway (even without using
> > EARLY_DEBUG).
>
> Legacy ports should get udbg first.
>
> > > Maybe, if there is really no other
> > > possibility for I/O space devices, we could have both calls
> > >
> > > arch_initcall(serial_mem_dev_init);
> > > device_initcall(serial_io_dev_init);
> > >
> > > so, that at least MEMIO based UARTs could still initialize as before?
> >
> > That's quite a hack, I hope we can avoid it. Maybe Ben has some suggestion
> > on how to get the IO setup earlier instead.
>
> IO space allocation now relies on get_vm_area() which can't be done too
> early (not in setup_arch) which is why I allocate all PCI IO space at
> PHB scanning time, which is a subsys initcall.
>
> An option would be to do it from some other init call, but that's a bit
> ugly. That means PCI would be split into setup_arch() setting up PHBs,
> that initcall allocating the IO spaces, and later, the actual scan.
>
> It would be tricky though as my current interface relies on pci_bus
> structures. So you would also need to re-split that into a low-level
> that works on the PHB and a high level version that works on the bus.
>
> Is this really necessary ?
No, that's what I'm hoping won't be, i.e. that it'll be fine to just
init serial ports slightly later. If people care about early output they
should use udbg anyway.
It'd be useful if people could at least test the patch on their systems.
I have only a few 32-bit ones with proper uarts, and none of them are
currently in a state where I can just throw a new kernel on them for
testing. :(
-Olof
^ permalink raw reply
* [PATCH] Remove barriers from the SLB shadow buffer update
From: Michael Neuling @ 2007-08-24 6:58 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
After talking to an IBM POWER hypervisor design and development (PHYP)
guy, there seems to be no need for memory barriers when updating the SLB
shadow buffer provided we only update it from the current CPU, which we
do.
Also, these guys see no need in the future for these barriers.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
Tested on PHYP and BML.
paulus: As you mentioned, this is 2.6.24 material.
arch/powerpc/kernel/entry_64.S | 8 ++++----
arch/powerpc/mm/slb.c | 6 ++----
2 files changed, 6 insertions(+), 8 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/entry_64.S
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/entry_64.S
+++ linux-2.6-ozlabs/arch/powerpc/kernel/entry_64.S
@@ -385,15 +385,15 @@ BEGIN_FTR_SECTION
oris r0,r6,(SLB_ESID_V)@h
ori r0,r0,(SLB_NUM_BOLTED-1)@l
- /* Update the last bolted SLB */
+ /* Update the last bolted SLB. No write barriers are needed
+ * here, provided we only update the current CPU's SLB shadow
+ * buffer.
+ */
ld r9,PACA_SLBSHADOWPTR(r13)
li r12,0
std r12,SLBSHADOW_STACKESID(r9) /* Clear ESID */
- eieio
std r7,SLBSHADOW_STACKVSID(r9) /* Save VSID */
- eieio
std r0,SLBSHADOW_STACKESID(r9) /* Save ESID */
- eieio
slbie r6
slbie r6 /* Workaround POWER5 < DD2.1 issue */
Index: linux-2.6-ozlabs/arch/powerpc/mm/slb.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/mm/slb.c
+++ linux-2.6-ozlabs/arch/powerpc/mm/slb.c
@@ -59,14 +59,12 @@ static inline void slb_shadow_update(uns
{
/*
* Clear the ESID first so the entry is not valid while we are
- * updating it.
+ * updating it. No write barriers are needed here, provided
+ * we only update the current CPU's SLB shadow buffer.
*/
get_slb_shadow()->save_area[entry].esid = 0;
- smp_wmb();
get_slb_shadow()->save_area[entry].vsid = mk_vsid_data(ea, flags);
- smp_wmb();
get_slb_shadow()->save_area[entry].esid = mk_esid_data(ea, entry);
- smp_wmb();
}
static inline void slb_shadow_clear(unsigned long entry)
^ 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