Re: Problem with PCI bus rescan on 460EX
Hello Kenji-san,
Kenji Kaneshige wrote:
Felix Radensky wrote:
Hello Kenji-san,
Kenji Kaneshige wrote:
I'm not sure, but I guess pci_setup_bridge() didn't update IO
base/limit
and Mem base/limit of the bridge (:00:02.0) because of the
following
lines.
static void pci_setup_bridge(struct pci_bus *bus)
{
struct pci_dev *bridge = bus-self;
struct resource *res;
struct pci_bus_region region;
u32 l, bu, lu, io_upper16;
if (pci_is_enabled(bridge))
===
return;===
dev_info(bridge-dev, PCI bridge to [bus %02x-%02x]\n,
bus-secondary, bus-subordinate);
...
It seems the bridge was already enabled by
pci_assign_unassigned_resources()
at boot time. Does removing those lines make any change?
Yes, with these lines removed bridge memory window is properly
allocated.
These lines are to prevent updating IO or memory windows when there are
some devices working behind the bridge. So please note that removing
these lines is just for debugging.
For some reason bridge memory is disabled, but if I enable it via
setpci, and
also enable device memory, then everything works fine. If the system
is booted
when device behind the bridge is plugged in, bridge memory is enabled.
Maybe because of the following lines, I guess.
void pci_enable_bridges(struct pci_bus *bus)
{
struct pci_dev *dev;
int retval;
list_for_each_entry(dev, bus-devices, bus_list) {
if (dev-subordinate) {
if (!pci_is_enabled(dev)) {===
retval = pci_enable_device(dev);===
pci_set_master(dev);===
}
...
Yes, but removing this check is not enough. The bridge is enabled after
first scan, but it's
memory is disabled. So simply calling pci_enable_device() will not
help, it will return without
enabling memory. I had to call pci_disable_device() before
pci_enable_device() to make things
work.
One possible cause is that pcibios_enable_device() for the bridge didn't
return any error even though it didn't work properly (ex. cannot access
to the command register, and so on) on your platform when there is no
device behind the bridge. But it is just my guess.
Should pcibios_enable_device() return an error if it fails to enable
bridge memory ?
Thanks.
Felix.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Patch 1/1] PPC64-HWBKPT: Implement hw-breakpoints for PPC64
On Fri, Mar 12, 2010 at 05:19:36PM +1100, Benjamin Herrenschmidt wrote:
Index: linux-2.6.ppc64_test/arch/powerpc/include/asm/hw_breakpoint.h
===
--- /dev/null
+++ linux-2.6.ppc64_test/arch/powerpc/include/asm/hw_breakpoint.h
@@ -0,0 +1,54 @@
+#ifndef_PPC64_HW_BREAKPOINT_H
+#define_PPC64_HW_BREAKPOINT_H
+
+#ifdef __KERNEL__
+#define__ARCH_HW_BREAKPOINT_H
+#ifdef CONFIG_PPC64
+
+struct arch_hw_breakpoint {
+ u8 len; /* length of the target symbol */
I don't understand the usage of the word symbol above, can you
explain ?
The word symbol, here, carries a meaning similar to what is derived from
its usage in the word kernel data symbols - although it is
used to store lengths for both kernel and user-space breakpoints.
Since the desired length of the breakpoint is typically determined by the
size of the symbol (variable) being monitored (not exceeding 8-Bytes),
the comment was such. I shall change it to a more descriptive one, such as
length of the target kernel/user data symbol if you prefer that.
+ int type;
+ unsigned long address;
+};
+
+#include linux/kdebug.h
+#include asm/reg.h
+#include asm/system.h
+
+/* Total number of available HW breakpoint registers */
+#define HBP_NUM 1
+
+struct perf_event;
+struct pmu;
+struct perf_sample_data;
+
+#define HW_BREAKPOINT_ALIGN 0x7
+/* Maximum permissible length of any HW Breakpoint */
+#define HW_BREAKPOINT_LEN 0x8
That's a lot of server-only hard wired assumptions... I suppose the
DABR emulation of BookE will catch but do you intend to provide
proper BookE support at some stage ?
Yes, I intend to extend support for Book-E sometime soon during which
the above code would have to be either a) enclosed inside #ifdef PPC64
or b) a new header file for BookE debug register definitions are used
(guess Shaggy's code would have many of them done already).
+static inline void hw_breakpoint_disable(void)
+{
+ set_dabr(0);
+}
How much of these set_dabr() I see here are going to interact with
ptrace ? Is there some exclusion going on between ptrace and perf
event use of the DABR or none at all ? Or are you replacing the ptrace
bits ?
This set_dabr() in hw_breakpoint_disable() is to be called only once during
machine_kexec() [which I realise is missing in the patch...will add that]
and will not conflict with ptrace.
The other set_dabr() in arch_uninstall_hw_breakpoint() will perform the
actual debug register write, while the ptrace_getset_debugreg() requests
are routed through them (via the hw-breakpoint interfaces for arbitration as
shown below) and are designed to not conflict with each other.
ptrace_set_debugreg()--register_user_hw_breakpoint()
...
(sched)--perf_event_task_sched_inout()---arch_uninstall_hw_breakpoint()
In short, an existing ptrace request will not be overwritten/replaced to
accommodate a new kernel/user-space request (which will fail because of DABR
unavailability).
+/*
+ * Install a perf counter breakpoint.
+ *
+ * We seek a free debug address register and use it for this
+ * breakpoint.
+ *
+ * Atomic: we hold the counter-ctx-lock and we only handle variables
+ * and registers local to this cpu.
+ */
+int arch_install_hw_breakpoint(struct perf_event *bp)
+{
+ struct arch_hw_breakpoint *info = counter_arch_bp(bp);
+ struct perf_event **slot = __get_cpu_var(bp_per_reg);
+
+ if (!*slot)
+ *slot = bp;
+ else {
+ WARN_ONCE(1, Can't find any breakpoint slot);
+ return -EBUSY;
+ }
+
+ set_dabr(info-address | info-type | DABR_TRANSLATION);
+ return 0;
+}
Under which circumstances will the upper layer call that more than
once ? If it's a legit thing to do, then the WARN_ONCE() is a heavy
hammer here. I wouldn't even printk or only pr_debug() if it's
really worth it.
Or is that something that should just not happen ?
I don't really see when this can happen in PPC64 with one DABR. The slot
reservation mechanism wouldn't allow this to happen and the code is here
since it got inherited from x86.
I shall remove the check and hence the WARN_ONCE.
I would also use this coding style which is more compact and avoids
the horrible (!*slot) :
/* Check if the slot is busy */
if (*slot)
return -EBUSY;
set_dabr(...);
+/*
+ * Uninstall the breakpoint contained in the given counter.
+ *
+ * First we search the debug address register it uses and then we disable
+ * it.
+ *
+ * Atomic: we hold the counter-ctx-lock and we only handle variables
+ * and registers local to this cpu.
+ */
+void arch_uninstall_hw_breakpoint(struct perf_event *bp)
+{
+ struct perf_event **slot = __get_cpu_var(bp_per_reg);
+
+ if (*slot == bp)
+ *slot = NULL;
+ else {
+ WARN_ONCE(1,
Re: [PATCH] [V2] Add non-Virtex5 support for LL TEMAC driver
John Linn wrote:
This patch adds support for using the LL TEMAC Ethernet driver on
non-Virtex 5 platforms by adding support for accessing the Soft DMA
registers as if they were memory mapped instead of solely through the
DCR's (available on the Virtex 5).
The patch also updates the driver so that it runs on the MicroBlaze.
The changes were tested on the PowerPC 440, PowerPC 405, and the
MicroBlaze platforms.
Which git-tree have you tested on? (Of course microblaze)
Michal
Signed-off-by: John Tyner jty...@cs.ucr.edu
Signed-off-by: John Linn john.l...@xilinx.com
---
V2 - Incorporated comments from Grant and added more logic to allow the driver
to work on MicroBlaze.
drivers/net/Kconfig |1 -
drivers/net/ll_temac.h | 17 +-
drivers/net/ll_temac_main.c | 124 ++-
3 files changed, 113 insertions(+), 29 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 9b6efe1..5402105 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2443,7 +2443,6 @@ config MV643XX_ETH
config XILINX_LL_TEMAC
tristate Xilinx LL TEMAC (LocalLink Tri-mode Ethernet MAC) driver
select PHYLIB
- depends on PPC_DCR_NATIVE
help
This driver supports the Xilinx 10/100/1000 LocalLink TEMAC
core used in Xilinx Spartan and Virtex FPGAs
diff --git a/drivers/net/ll_temac.h b/drivers/net/ll_temac.h
index 1af66a1..915aa34 100644
--- a/drivers/net/ll_temac.h
+++ b/drivers/net/ll_temac.h
@@ -5,8 +5,11 @@
#include linux/netdevice.h
#include linux/of.h
#include linux/spinlock.h
+
+#ifdef CONFIG_PPC_DCR
#include asm/dcr.h
#include asm/dcr-regs.h
+#endif
/* packet size info */
#define XTE_HDR_SIZE 14 /* size of Ethernet header */
@@ -290,8 +293,12 @@ This option defaults to enabled (set) */
#define TX_CONTROL_CALC_CSUM_MASK 1
+/* Align the IP data in the packet on word boundaries as MicroBlaze
+ * needs it.
+ */
+
#define XTE_ALIGN 32
-#define BUFFER_ALIGN(adr) ((XTE_ALIGN - ((u32) adr)) % XTE_ALIGN)
+#define BUFFER_ALIGN(adr) ((34 - ((u32) adr)) % XTE_ALIGN)
#define MULTICAST_CAM_TABLE_NUM 4
@@ -335,9 +342,15 @@ struct temac_local {
struct mii_bus *mii_bus;/* MII bus reference */
int mdio_irqs[PHY_MAX_ADDR];/* IRQs table for MDIO bus */
- /* IO registers and IRQs */
+ /* IO registers, dma functions and IRQs */
void __iomem *regs;
+ void __iomem *sdma_regs;
+#ifdef CONFIG_PPC_DCR
dcr_host_t sdma_dcrs;
+#endif
+ u32 (*dma_in)(struct temac_local *, int);
+ void (*dma_out)(struct temac_local *, int, u32);
+
int tx_irq;
int rx_irq;
int emac_num;
diff --git a/drivers/net/ll_temac_main.c b/drivers/net/ll_temac_main.c
index a18e348..9aedf9b 100644
--- a/drivers/net/ll_temac_main.c
+++ b/drivers/net/ll_temac_main.c
@@ -20,9 +20,6 @@
* or rx, so this should be okay.
*
* TODO:
- * - Fix driver to work on more than just Virtex5. Right now the driver
- * assumes that the locallink DMA registers are accessed via DCR
- * instructions.
* - Factor out locallink DMA code into separate driver
* - Fix multicast assignment.
* - Fix support for hardware checksumming.
@@ -115,17 +112,86 @@ void temac_indirect_out32(struct temac_local *lp, int
reg, u32 value)
temac_iow(lp, XTE_CTL0_OFFSET, CNTLREG_WRITE_ENABLE_MASK | reg);
}
+/**
+ * temac_dma_in32 - Memory mapped DMA read, this function expects a
+ * register input that is based on DCR word addresses which
+ * are then converted to memory mapped byte addresses
+ */
static u32 temac_dma_in32(struct temac_local *lp, int reg)
{
- return dcr_read(lp-sdma_dcrs, reg);
+ return in_be32((u32 *)(lp-sdma_regs + (reg 2)));
}
+/**
+ * temac_dma_out32 - Memory mapped DMA read, this function expects a
+ * register input that is based on DCR word addresses which
+ * are then converted to memory mapped byte addresses
+ */
static void temac_dma_out32(struct temac_local *lp, int reg, u32 value)
{
+ out_be32((u32 *)(lp-sdma_regs + (reg 2)), value);
+}
+
+/* DMA register access functions can be DCR based or memory mapped.
+ * The PowerPC 440 is DCR based, the PowerPC 405 and MicroBlaze are both
+ * memory mapped.
+ */
+#ifdef CONFIG_PPC_DCR
+
+/**
+ * temac_dma_dcr_in32 - DCR based DMA read
+ */
+static u32 temac_dma_dcr_in(struct temac_local *lp, int reg)
+{
+ return dcr_read(lp-sdma_dcrs, reg);
+}
+
+/**
+ * temac_dma_dcr_out32 - DCR based DMA write
+ */
+static void temac_dma_dcr_out(struct temac_local *lp, int reg, u32 value)
+{
dcr_write(lp-sdma_dcrs, reg, value);
}
/**
+ * temac_dcr_setup - If the DMA is DCR based, then setup the address and
+ * I/O functions
+ */
+static int temac_dcr_setup(struct temac_local *lp, struct of_device *op,
+ struct device_node *np)
+{
+ unsigned int dcrs;
+
+ /* setup the dcr address mapping
Re: Problem with PCI bus rescan on 460EX
Felix Radensky wrote:
Hello Kenji-san,
Kenji Kaneshige wrote:
Felix Radensky wrote:
Hello Kenji-san,
Kenji Kaneshige wrote:
I'm not sure, but I guess pci_setup_bridge() didn't update IO
base/limit
and Mem base/limit of the bridge (:00:02.0) because of the
following
lines.
static void pci_setup_bridge(struct pci_bus *bus)
{
struct pci_dev *bridge = bus-self;
struct resource *res;
struct pci_bus_region region;
u32 l, bu, lu, io_upper16;
if (pci_is_enabled(bridge))
===
return;===
dev_info(bridge-dev, PCI bridge to [bus %02x-%02x]\n,
bus-secondary, bus-subordinate);
...
It seems the bridge was already enabled by
pci_assign_unassigned_resources()
at boot time. Does removing those lines make any change?
Yes, with these lines removed bridge memory window is properly
allocated.
These lines are to prevent updating IO or memory windows when there are
some devices working behind the bridge. So please note that removing
these lines is just for debugging.
For some reason bridge memory is disabled, but if I enable it via
setpci, and
also enable device memory, then everything works fine. If the system
is booted
when device behind the bridge is plugged in, bridge memory is enabled.
Maybe because of the following lines, I guess.
void pci_enable_bridges(struct pci_bus *bus)
{
struct pci_dev *dev;
int retval;
list_for_each_entry(dev, bus-devices, bus_list) {
if (dev-subordinate) {
if (!pci_is_enabled(dev)) {===
retval = pci_enable_device(dev);===
pci_set_master(dev);===
}
...
Yes, but removing this check is not enough. The bridge is enabled after
first scan, but it's
memory is disabled. So simply calling pci_enable_device() will not
help, it will return without
enabling memory. I had to call pci_disable_device() before
pci_enable_device() to make things
work.
One possible cause is that pcibios_enable_device() for the bridge didn't
return any error even though it didn't work properly (ex. cannot access
to the command register, and so on) on your platform when there is no
device behind the bridge. But it is just my guess.
Should pcibios_enable_device() return an error if it fails to enable
bridge memory ?
I think the device is expected to be ready to work if pci_enable_device()
returns without error. So I think pci_enable_device() should return an
error if it fails to enable the device (device is not ready to work). In
this case, detecting your bridge's failure seems PPC specific to me. So I
thought pcibios_enable_device() was the right to return an error. If
pcibios_enable_device() returned an error, pci_dev-enable_cnt would
decremented by pci_enable_device() (like pci_disable_device() does) and
this problem would not happen.
On the other hand, as Ben suggested, handling this by specific hot-plug
driver would be one of the other candidate to fix the problem.
Thanks,
Kenji Kaneshige
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problem with PCI bus rescan on 460EX
Hello, Kenji-san I think the device is expected to be ready to work if pci_enable_device() returns without error. So I think pci_enable_device() should return an error if it fails to enable the device (device is not ready to work). In this case, detecting your bridge's failure seems PPC specific to me. So I thought pcibios_enable_device() was the right to return an error. If pcibios_enable_device() returned an error, pci_dev-enable_cnt would decremented by pci_enable_device() (like pci_disable_device() does) and this problem would not happen. As far as I can see on 460EX pcibios_enable_device() just calls pci_enable_resources() which does not return any error for my bridge, although it doesn't find any memory or I/O resource it can enable. Do you think it is correct behavior ? Another question is whether by bridge behaves correctly when no device is connected to it. As you can see in dmesg output I've sent earlier pci :00:02.0: bridge window [mem 0x-0x000f] pci :00:02.0: bridge window [mem 0x-0x000f 64bit pref] and later PCI code disables these memory windows pci :00:02.0: disabling bridge window [mem 0xd-0xd000f pref] to [bus 01-01] (unused) pci :00:02.0: disabling bridge window [mem 0xd-0xd000f] to [bus 01-01] (unused) BTW, there's no problem accessing PCI_COMMAND register, as bus mastering is enabled in the bridge. On the other hand, as Ben suggested, handling this by specific hot-plug driver would be one of the other candidate to fix the problem. I'm not opposed to this idea, it's just that this bridge worked in an older system based on linux-2.6.22 and patched fakephp driver was used for hotplug. There's existing userspace software that I don't really want to modify heavily. But I'll do that if generic PCI rescan cannot be fixed. Thanks a lot for your help. Felix. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] [V2] Add non-Virtex5 support for LL TEMAC driver
-Original Message-
From: Michal Simek [mailto:michal.si...@petalogix.com]
Sent: Monday, March 15, 2010 2:40 AM
To: John Linn
Cc: net...@vger.kernel.org; linuxppc-...@ozlabs.org;
grant.lik...@secretlab.ca;
jwbo...@linux.vnet.ibm.com; john.willi...@petalogix.com; John Tyner
Subject: Re: [PATCH] [V2] Add non-Virtex5 support for LL TEMAC driver
John Linn wrote:
This patch adds support for using the LL TEMAC Ethernet driver on
non-Virtex 5 platforms by adding support for accessing the Soft DMA
registers as if they were memory mapped instead of solely through
the
DCR's (available on the Virtex 5).
The patch also updates the driver so that it runs on the MicroBlaze.
The changes were tested on the PowerPC 440, PowerPC 405, and the
MicroBlaze platforms.
Which git-tree have you tested on? (Of course microblaze)
It was tested on the Xilinx tree for MicroBlaze which is based on the
mainline and the Petalogix tree as DMA was needed. I tried to build
against the mainline head but got errors with the DMA routines. I guess
it's possible that it was a configuration issue there as I didn't dig
real deep.
I tested the PowerPC against the head of mainline.
Thanks,
John
Michal
Signed-off-by: John Tyner jty...@cs.ucr.edu
Signed-off-by: John Linn john.l...@xilinx.com
---
V2 - Incorporated comments from Grant and added more logic to allow
the driver
to work on MicroBlaze.
drivers/net/Kconfig |1 -
drivers/net/ll_temac.h | 17 +-
drivers/net/ll_temac_main.c | 124
++-
3 files changed, 113 insertions(+), 29 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 9b6efe1..5402105 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2443,7 +2443,6 @@ config MV643XX_ETH
config XILINX_LL_TEMAC
tristate Xilinx LL TEMAC (LocalLink Tri-mode Ethernet MAC)
driver
select PHYLIB
- depends on PPC_DCR_NATIVE
help
This driver supports the Xilinx 10/100/1000 LocalLink TEMAC
core used in Xilinx Spartan and Virtex FPGAs
diff --git a/drivers/net/ll_temac.h b/drivers/net/ll_temac.h
index 1af66a1..915aa34 100644
--- a/drivers/net/ll_temac.h
+++ b/drivers/net/ll_temac.h
@@ -5,8 +5,11 @@
#include linux/netdevice.h
#include linux/of.h
#include linux/spinlock.h
+
+#ifdef CONFIG_PPC_DCR
#include asm/dcr.h
#include asm/dcr-regs.h
+#endif
/* packet size info */
#define XTE_HDR_SIZE 14 /* size of
Ethernet header */
@@ -290,8 +293,12 @@ This option defaults to enabled (set) */
#define TX_CONTROL_CALC_CSUM_MASK 1
+/* Align the IP data in the packet on word boundaries as MicroBlaze
+ * needs it.
+ */
+
#define XTE_ALIGN 32
-#define BUFFER_ALIGN(adr) ((XTE_ALIGN - ((u32) adr)) % XTE_ALIGN)
+#define BUFFER_ALIGN(adr) ((34 - ((u32) adr)) % XTE_ALIGN)
#define MULTICAST_CAM_TABLE_NUM 4
@@ -335,9 +342,15 @@ struct temac_local {
struct mii_bus *mii_bus;/* MII bus reference */
int mdio_irqs[PHY_MAX_ADDR];/* IRQs table for MDIO bus */
- /* IO registers and IRQs */
+ /* IO registers, dma functions and IRQs */
void __iomem *regs;
+ void __iomem *sdma_regs;
+#ifdef CONFIG_PPC_DCR
dcr_host_t sdma_dcrs;
+#endif
+ u32 (*dma_in)(struct temac_local *, int);
+ void (*dma_out)(struct temac_local *, int, u32);
+
int tx_irq;
int rx_irq;
int emac_num;
diff --git a/drivers/net/ll_temac_main.c
b/drivers/net/ll_temac_main.c
index a18e348..9aedf9b 100644
--- a/drivers/net/ll_temac_main.c
+++ b/drivers/net/ll_temac_main.c
@@ -20,9 +20,6 @@
* or rx, so this should be okay.
*
* TODO:
- * - Fix driver to work on more than just Virtex5. Right now the
driver
- * assumes that the locallink DMA registers are accessed via DCR
- * instructions.
* - Factor out locallink DMA code into separate driver
* - Fix multicast assignment.
* - Fix support for hardware checksumming.
@@ -115,17 +112,86 @@ void temac_indirect_out32(struct temac_local
*lp, int reg, u32 value)
temac_iow(lp, XTE_CTL0_OFFSET, CNTLREG_WRITE_ENABLE_MASK | reg);
}
+/**
+ * temac_dma_in32 - Memory mapped DMA read, this function expects a
+ * register input that is based on DCR word addresses which
+ * are then converted to memory mapped byte addresses
+ */
static u32 temac_dma_in32(struct temac_local *lp, int reg)
{
- return dcr_read(lp-sdma_dcrs, reg);
+ return in_be32((u32 *)(lp-sdma_regs + (reg 2)));
}
+/**
+ * temac_dma_out32 - Memory mapped DMA read, this function expects
a
+ * register input that is based on DCR word addresses which
+ * are then converted to memory mapped byte addresses
+ */
static void temac_dma_out32(struct temac_local *lp, int reg, u32
value)
{
+ out_be32((u32 *)(lp-sdma_regs + (reg 2)), value);
+}
+
Re: [PATCH] [V2] Add non-Virtex5 support for LL TEMAC driver
John Linn wrote:
-Original Message-
From: Michal Simek [mailto:michal.si...@petalogix.com]
Sent: Monday, March 15, 2010 2:40 AM
To: John Linn
Cc: net...@vger.kernel.org; linuxppc-...@ozlabs.org;
grant.lik...@secretlab.ca;
jwbo...@linux.vnet.ibm.com; john.willi...@petalogix.com; John Tyner
Subject: Re: [PATCH] [V2] Add non-Virtex5 support for LL TEMAC driver
John Linn wrote:
This patch adds support for using the LL TEMAC Ethernet driver on
non-Virtex 5 platforms by adding support for accessing the Soft DMA
registers as if they were memory mapped instead of solely through
the
DCR's (available on the Virtex 5).
The patch also updates the driver so that it runs on the MicroBlaze.
The changes were tested on the PowerPC 440, PowerPC 405, and the
MicroBlaze platforms.
Which git-tree have you tested on? (Of course microblaze)
It was tested on the Xilinx tree for MicroBlaze which is based on the
mainline and the Petalogix tree as DMA was needed. I tried to build
against the mainline head but got errors with the DMA routines. I guess
it's possible that it was a configuration issue there as I didn't dig
real deep.
New dma api is in for-linus branch.
I tested it on that version and I am seeing some weird things. :-(
Access to bad area. I will try your tree.
The second thing which I see is in ll_temac_recv function.
On the following line is read a packet length which could be 0-16k.
length = cur_p-app4 0x3FFF;
But allocated skb has max size XTE_MAX_JUMBO_FRAME_SIZE + XTE_ALIGN.
What happen if driver get packet greater than 9kB?
I got it (I don't know how) but skb_put has one checking mechanism which
will cal skb_over_panic which caused panic.
That's why I think that will be good always to check that length is less
than XTE_MAX_JUMBO_FRAME_SIZE + XTE_ALIGN.
What do you think?
Thanks,
Michal
I tested the PowerPC against the head of mainline.
Thanks,
John
Michal
Signed-off-by: John Tyner jty...@cs.ucr.edu
Signed-off-by: John Linn john.l...@xilinx.com
---
V2 - Incorporated comments from Grant and added more logic to allow
the driver
to work on MicroBlaze.
drivers/net/Kconfig |1 -
drivers/net/ll_temac.h | 17 +-
drivers/net/ll_temac_main.c | 124
++-
3 files changed, 113 insertions(+), 29 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 9b6efe1..5402105 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2443,7 +2443,6 @@ config MV643XX_ETH
config XILINX_LL_TEMAC
tristate Xilinx LL TEMAC (LocalLink Tri-mode Ethernet MAC)
driver
select PHYLIB
- depends on PPC_DCR_NATIVE
help
This driver supports the Xilinx 10/100/1000 LocalLink TEMAC
core used in Xilinx Spartan and Virtex FPGAs
diff --git a/drivers/net/ll_temac.h b/drivers/net/ll_temac.h
index 1af66a1..915aa34 100644
--- a/drivers/net/ll_temac.h
+++ b/drivers/net/ll_temac.h
@@ -5,8 +5,11 @@
#include linux/netdevice.h
#include linux/of.h
#include linux/spinlock.h
+
+#ifdef CONFIG_PPC_DCR
#include asm/dcr.h
#include asm/dcr-regs.h
+#endif
/* packet size info */
#define XTE_HDR_SIZE 14 /* size of
Ethernet header */
@@ -290,8 +293,12 @@ This option defaults to enabled (set) */
#define TX_CONTROL_CALC_CSUM_MASK 1
+/* Align the IP data in the packet on word boundaries as MicroBlaze
+ * needs it.
+ */
+
#define XTE_ALIGN 32
-#define BUFFER_ALIGN(adr) ((XTE_ALIGN - ((u32) adr)) % XTE_ALIGN)
+#define BUFFER_ALIGN(adr) ((34 - ((u32) adr)) % XTE_ALIGN)
#define MULTICAST_CAM_TABLE_NUM 4
@@ -335,9 +342,15 @@ struct temac_local {
struct mii_bus *mii_bus;/* MII bus reference */
int mdio_irqs[PHY_MAX_ADDR];/* IRQs table for MDIO bus */
- /* IO registers and IRQs */
+ /* IO registers, dma functions and IRQs */
void __iomem *regs;
+ void __iomem *sdma_regs;
+#ifdef CONFIG_PPC_DCR
dcr_host_t sdma_dcrs;
+#endif
+ u32 (*dma_in)(struct temac_local *, int);
+ void (*dma_out)(struct temac_local *, int, u32);
+
int tx_irq;
int rx_irq;
int emac_num;
diff --git a/drivers/net/ll_temac_main.c
b/drivers/net/ll_temac_main.c
index a18e348..9aedf9b 100644
--- a/drivers/net/ll_temac_main.c
+++ b/drivers/net/ll_temac_main.c
@@ -20,9 +20,6 @@
* or rx, so this should be okay.
*
* TODO:
- * - Fix driver to work on more than just Virtex5. Right now the
driver
- * assumes that the locallink DMA registers are accessed via DCR
- * instructions.
* - Factor out locallink DMA code into separate driver
* - Fix multicast assignment.
* - Fix support for hardware checksumming.
@@ -115,17 +112,86 @@ void temac_indirect_out32(struct temac_local
*lp, int reg, u32 value)
temac_iow(lp, XTE_CTL0_OFFSET, CNTLREG_WRITE_ENABLE_MASK | reg);
}
+/**
+ * temac_dma_in32 - Memory mapped DMA read, this function expects a
+ * register input that
RE: [PATCH] [V2] Add non-Virtex5 support for LL TEMAC driver
-Original Message-
From: Michal Simek [mailto:michal.si...@petalogix.com]
Sent: Monday, March 15, 2010 8:40 AM
To: John Linn
Cc: net...@vger.kernel.org; linuxppc-...@ozlabs.org;
grant.lik...@secretlab.ca;
jwbo...@linux.vnet.ibm.com; john.willi...@petalogix.com; John Tyner
Subject: Re: [PATCH] [V2] Add non-Virtex5 support for LL TEMAC driver
John Linn wrote:
-Original Message-
From: Michal Simek [mailto:michal.si...@petalogix.com]
Sent: Monday, March 15, 2010 2:40 AM
To: John Linn
Cc: net...@vger.kernel.org; linuxppc-...@ozlabs.org;
grant.lik...@secretlab.ca;
jwbo...@linux.vnet.ibm.com; john.willi...@petalogix.com; John Tyner
Subject: Re: [PATCH] [V2] Add non-Virtex5 support for LL TEMAC
driver
John Linn wrote:
This patch adds support for using the LL TEMAC Ethernet driver on
non-Virtex 5 platforms by adding support for accessing the Soft
DMA
registers as if they were memory mapped instead of solely through
the
DCR's (available on the Virtex 5).
The patch also updates the driver so that it runs on the
MicroBlaze.
The changes were tested on the PowerPC 440, PowerPC 405, and the
MicroBlaze platforms.
Which git-tree have you tested on? (Of course microblaze)
It was tested on the Xilinx tree for MicroBlaze which is based on
the
mainline and the Petalogix tree as DMA was needed. I tried to build
against the mainline head but got errors with the DMA routines. I
guess
it's possible that it was a configuration issue there as I didn't
dig
real deep.
New dma api is in for-linus branch.
I tested it on that version and I am seeing some weird things. :-(
Access to bad area. I will try your tree.
The second thing which I see is in ll_temac_recv function.
On the following line is read a packet length which could be 0-16k.
length = cur_p-app4 0x3FFF;
But allocated skb has max size XTE_MAX_JUMBO_FRAME_SIZE + XTE_ALIGN.
What happen if driver get packet greater than 9kB?
I got it (I don't know how) but skb_put has one checking mechanism
which
will cal skb_over_panic which caused panic.
That's the whole reason for that panic to me and when I got it in the
past and looked it up it made sense to me. I personally don't see a
good reason to check for it in the driver since the kernel catches it,
but maybe others do.
Thanks,
John
That's why I think that will be good always to check that length is
less
than XTE_MAX_JUMBO_FRAME_SIZE + XTE_ALIGN.
What do you think?
Thanks,
Michal
I tested the PowerPC against the head of mainline.
Thanks,
John
Michal
Signed-off-by: John Tyner jty...@cs.ucr.edu
Signed-off-by: John Linn john.l...@xilinx.com
---
V2 - Incorporated comments from Grant and added more logic to
allow
the driver
to work on MicroBlaze.
drivers/net/Kconfig |1 -
drivers/net/ll_temac.h | 17 +-
drivers/net/ll_temac_main.c | 124
++-
3 files changed, 113 insertions(+), 29 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 9b6efe1..5402105 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2443,7 +2443,6 @@ config MV643XX_ETH
config XILINX_LL_TEMAC
tristate Xilinx LL TEMAC (LocalLink Tri-mode Ethernet MAC)
driver
select PHYLIB
- depends on PPC_DCR_NATIVE
help
This driver supports the Xilinx 10/100/1000 LocalLink TEMAC
core used in Xilinx Spartan and Virtex FPGAs
diff --git a/drivers/net/ll_temac.h b/drivers/net/ll_temac.h
index 1af66a1..915aa34 100644
--- a/drivers/net/ll_temac.h
+++ b/drivers/net/ll_temac.h
@@ -5,8 +5,11 @@
#include linux/netdevice.h
#include linux/of.h
#include linux/spinlock.h
+
+#ifdef CONFIG_PPC_DCR
#include asm/dcr.h
#include asm/dcr-regs.h
+#endif
/* packet size info */
#define XTE_HDR_SIZE 14 /* size of
Ethernet header */
@@ -290,8 +293,12 @@ This option defaults to enabled (set) */
#define TX_CONTROL_CALC_CSUM_MASK 1
+/* Align the IP data in the packet on word boundaries as
MicroBlaze
+ * needs it.
+ */
+
#define XTE_ALIGN 32
-#define BUFFER_ALIGN(adr) ((XTE_ALIGN - ((u32) adr)) % XTE_ALIGN)
+#define BUFFER_ALIGN(adr) ((34 - ((u32) adr)) % XTE_ALIGN)
#define MULTICAST_CAM_TABLE_NUM 4
@@ -335,9 +342,15 @@ struct temac_local {
struct mii_bus *mii_bus;/* MII bus reference */
int mdio_irqs[PHY_MAX_ADDR];/* IRQs table for MDIO bus */
- /* IO registers and IRQs */
+ /* IO registers, dma functions and IRQs */
void __iomem *regs;
+ void __iomem *sdma_regs;
+#ifdef CONFIG_PPC_DCR
dcr_host_t sdma_dcrs;
+#endif
+ u32 (*dma_in)(struct temac_local *, int);
+ void (*dma_out)(struct temac_local *, int, u32);
+
int tx_irq;
int rx_irq;
int emac_num;
diff --git a/drivers/net/ll_temac_main.c
b/drivers/net/ll_temac_main.c
index a18e348..9aedf9b 100644
Re: [PATCH] [V2] Add non-Virtex5 support for LL TEMAC driver
John Linn wrote:
-Original Message-
From: Michal Simek [mailto:michal.si...@petalogix.com]
Sent: Monday, March 15, 2010 8:40 AM
To: John Linn
Cc: net...@vger.kernel.org; linuxppc-...@ozlabs.org;
grant.lik...@secretlab.ca;
jwbo...@linux.vnet.ibm.com; john.willi...@petalogix.com; John Tyner
Subject: Re: [PATCH] [V2] Add non-Virtex5 support for LL TEMAC driver
John Linn wrote:
-Original Message-
From: Michal Simek [mailto:michal.si...@petalogix.com]
Sent: Monday, March 15, 2010 2:40 AM
To: John Linn
Cc: net...@vger.kernel.org; linuxppc-...@ozlabs.org;
grant.lik...@secretlab.ca;
jwbo...@linux.vnet.ibm.com; john.willi...@petalogix.com; John Tyner
Subject: Re: [PATCH] [V2] Add non-Virtex5 support for LL TEMAC
driver
John Linn wrote:
This patch adds support for using the LL TEMAC Ethernet driver on
non-Virtex 5 platforms by adding support for accessing the Soft
DMA
registers as if they were memory mapped instead of solely through
the
DCR's (available on the Virtex 5).
The patch also updates the driver so that it runs on the
MicroBlaze.
The changes were tested on the PowerPC 440, PowerPC 405, and the
MicroBlaze platforms.
Which git-tree have you tested on? (Of course microblaze)
It was tested on the Xilinx tree for MicroBlaze which is based on
the
mainline and the Petalogix tree as DMA was needed. I tried to build
against the mainline head but got errors with the DMA routines. I
guess
it's possible that it was a configuration issue there as I didn't
dig
real deep.
New dma api is in for-linus branch.
I tested it on that version and I am seeing some weird things. :-(
Access to bad area. I will try your tree.
The second thing which I see is in ll_temac_recv function.
On the following line is read a packet length which could be 0-16k.
length = cur_p-app4 0x3FFF;
But allocated skb has max size XTE_MAX_JUMBO_FRAME_SIZE + XTE_ALIGN.
What happen if driver get packet greater than 9kB?
I got it (I don't know how) but skb_put has one checking mechanism
which
will cal skb_over_panic which caused panic.
That's the whole reason for that panic to me and when I got it in the
past and looked it up it made sense to me. I personally don't see a
good reason to check for it in the driver since the kernel catches it,
but maybe others do.
yes, kernel is checking it but caused panic which ends in fault in
kernel and caused kernel crash. :-( This could be a good reason to check
it in driver. I don't want to reset the board when ll_temac gets longer
packet, do you?
I have seen the second type of fault which caused kernel access to bad
area (+ kernel panic). Have you done any iperf tests or flood ping?
Thanks,
Michal
Thanks,
John
That's why I think that will be good always to check that length is
less
than XTE_MAX_JUMBO_FRAME_SIZE + XTE_ALIGN.
What do you think?
Thanks,
Michal
I tested the PowerPC against the head of mainline.
Thanks,
John
Michal
Signed-off-by: John Tyner jty...@cs.ucr.edu
Signed-off-by: John Linn john.l...@xilinx.com
---
V2 - Incorporated comments from Grant and added more logic to
allow
the driver
to work on MicroBlaze.
drivers/net/Kconfig |1 -
drivers/net/ll_temac.h | 17 +-
drivers/net/ll_temac_main.c | 124
++-
3 files changed, 113 insertions(+), 29 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 9b6efe1..5402105 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2443,7 +2443,6 @@ config MV643XX_ETH
config XILINX_LL_TEMAC
tristate Xilinx LL TEMAC (LocalLink Tri-mode Ethernet MAC)
driver
select PHYLIB
- depends on PPC_DCR_NATIVE
help
This driver supports the Xilinx 10/100/1000 LocalLink TEMAC
core used in Xilinx Spartan and Virtex FPGAs
diff --git a/drivers/net/ll_temac.h b/drivers/net/ll_temac.h
index 1af66a1..915aa34 100644
--- a/drivers/net/ll_temac.h
+++ b/drivers/net/ll_temac.h
@@ -5,8 +5,11 @@
#include linux/netdevice.h
#include linux/of.h
#include linux/spinlock.h
+
+#ifdef CONFIG_PPC_DCR
#include asm/dcr.h
#include asm/dcr-regs.h
+#endif
/* packet size info */
#define XTE_HDR_SIZE 14 /* size of
Ethernet header */
@@ -290,8 +293,12 @@ This option defaults to enabled (set) */
#define TX_CONTROL_CALC_CSUM_MASK 1
+/* Align the IP data in the packet on word boundaries as
MicroBlaze
+ * needs it.
+ */
+
#define XTE_ALIGN 32
-#define BUFFER_ALIGN(adr) ((XTE_ALIGN - ((u32) adr)) % XTE_ALIGN)
+#define BUFFER_ALIGN(adr) ((34 - ((u32) adr)) % XTE_ALIGN)
#define MULTICAST_CAM_TABLE_NUM 4
@@ -335,9 +342,15 @@ struct temac_local {
struct mii_bus *mii_bus;/* MII bus reference */
int mdio_irqs[PHY_MAX_ADDR];/* IRQs table for MDIO bus */
- /* IO registers and IRQs */
+ /* IO registers, dma functions and IRQs */
void __iomem *regs;
+ void __iomem *sdma_regs;
+#ifdef
RE: [PATCH] [V2] Add non-Virtex5 support for LL TEMAC driver
-Original Message- From: linuxppc-dev-bounces+stephen=neuendorffer.n...@lists.ozlabs.org [mailto:linuxppc-dev- bounces+stephen=neuendorffer.n...@lists.ozlabs.org] On Behalf Of John Linn Sent: Friday, March 12, 2010 5:06 PM To: net...@vger.kernel.org; linuxppc-...@ozlabs.org; grant.lik...@secretlab.ca; jwbo...@linux.vnet.ibm.com Cc: michal.si...@petalogix.com; John Tyner; John Linn; john.willi...@petalogix.com Subject: [PATCH] [V2] Add non-Virtex5 support for LL TEMAC driver This patch adds support for using the LL TEMAC Ethernet driver on non-Virtex 5 platforms by adding support for accessing the Soft DMA registers as if they were memory mapped instead of solely through the DCR's (available on the Virtex 5). The patch also updates the driver so that it runs on the MicroBlaze. The changes were tested on the PowerPC 440, PowerPC 405, and the MicroBlaze platforms. Signed-off-by: John Tyner jty...@cs.ucr.edu Signed-off-by: John Linn john.l...@xilinx.com --- V2 - Incorporated comments from Grant and added more logic to allow the driver to work on MicroBlaze. drivers/net/Kconfig |1 - drivers/net/ll_temac.h | 17 +- drivers/net/ll_temac_main.c | 124 ++- 3 files changed, 113 insertions(+), 29 deletions(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 9b6efe1..5402105 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -2443,7 +2443,6 @@ config MV643XX_ETH config XILINX_LL_TEMAC tristate Xilinx LL TEMAC (LocalLink Tri-mode Ethernet MAC) driver select PHYLIB - depends on PPC_DCR_NATIVE help This driver supports the Xilinx 10/100/1000 LocalLink TEMAC core used in Xilinx Spartan and Virtex FPGAs diff --git a/drivers/net/ll_temac.h b/drivers/net/ll_temac.h index 1af66a1..915aa34 100644 --- a/drivers/net/ll_temac.h +++ b/drivers/net/ll_temac.h @@ -5,8 +5,11 @@ #include linux/netdevice.h #include linux/of.h #include linux/spinlock.h + +#ifdef CONFIG_PPC_DCR #include asm/dcr.h #include asm/dcr-regs.h +#endif /* packet size info */ #define XTE_HDR_SIZE 14 /* size of Ethernet header */ @@ -290,8 +293,12 @@ This option defaults to enabled (set) */ #define TX_CONTROL_CALC_CSUM_MASK 1 +/* Align the IP data in the packet on word boundaries as MicroBlaze + * needs it. + */ + #define XTE_ALIGN 32 -#define BUFFER_ALIGN(adr) ((XTE_ALIGN - ((u32) adr)) % XTE_ALIGN) +#define BUFFER_ALIGN(adr) ((34 - ((u32) adr)) % XTE_ALIGN) Is '34' really XTE_ALIGN + 2? (I really have no idea it just looks like a suspicious change.) Steve This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] [V2] Add non-Virtex5 support for LL TEMAC driver
-Original Message- From: Stephen Neuendorffer Sent: Monday, March 15, 2010 11:03 AM To: John Linn; net...@vger.kernel.org; linuxppc-...@ozlabs.org; grant.lik...@secretlab.ca; jwbo...@linux.vnet.ibm.com Cc: michal.si...@petalogix.com; John Tyner; john.willi...@petalogix.com Subject: RE: [PATCH] [V2] Add non-Virtex5 support for LL TEMAC driver -Original Message- From: linuxppc-dev-bounces+stephen=neuendorffer.n...@lists.ozlabs.org [mailto:linuxppc-dev- bounces+stephen=neuendorffer.n...@lists.ozlabs.org] On Behalf Of John Linn Sent: Friday, March 12, 2010 5:06 PM To: net...@vger.kernel.org; linuxppc-...@ozlabs.org; grant.lik...@secretlab.ca; jwbo...@linux.vnet.ibm.com Cc: michal.si...@petalogix.com; John Tyner; John Linn; john.willi...@petalogix.com Subject: [PATCH] [V2] Add non-Virtex5 support for LL TEMAC driver This patch adds support for using the LL TEMAC Ethernet driver on non-Virtex 5 platforms by adding support for accessing the Soft DMA registers as if they were memory mapped instead of solely through the DCR's (available on the Virtex 5). The patch also updates the driver so that it runs on the MicroBlaze. The changes were tested on the PowerPC 440, PowerPC 405, and the MicroBlaze platforms. Signed-off-by: John Tyner jty...@cs.ucr.edu Signed-off-by: John Linn john.l...@xilinx.com --- V2 - Incorporated comments from Grant and added more logic to allow the driver to work on MicroBlaze. drivers/net/Kconfig |1 - drivers/net/ll_temac.h | 17 +- drivers/net/ll_temac_main.c | 124 ++- 3 files changed, 113 insertions(+), 29 deletions(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 9b6efe1..5402105 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -2443,7 +2443,6 @@ config MV643XX_ETH config XILINX_LL_TEMAC tristate Xilinx LL TEMAC (LocalLink Tri-mode Ethernet MAC) driver select PHYLIB - depends on PPC_DCR_NATIVE help This driver supports the Xilinx 10/100/1000 LocalLink TEMAC core used in Xilinx Spartan and Virtex FPGAs diff --git a/drivers/net/ll_temac.h b/drivers/net/ll_temac.h index 1af66a1..915aa34 100644 --- a/drivers/net/ll_temac.h +++ b/drivers/net/ll_temac.h @@ -5,8 +5,11 @@ #include linux/netdevice.h #include linux/of.h #include linux/spinlock.h + +#ifdef CONFIG_PPC_DCR #include asm/dcr.h #include asm/dcr-regs.h +#endif /* packet size info */ #define XTE_HDR_SIZE 14 /* size of Ethernet header */ @@ -290,8 +293,12 @@ This option defaults to enabled (set) */ #define TX_CONTROL_CALC_CSUM_MASK 1 +/* Align the IP data in the packet on word boundaries as MicroBlaze + * needs it. + */ + #define XTE_ALIGN 32 -#define BUFFER_ALIGN(adr) ((XTE_ALIGN - ((u32) adr)) % XTE_ALIGN) +#define BUFFER_ALIGN(adr) ((34 - ((u32) adr)) % XTE_ALIGN) Is '34' really XTE_ALIGN + 2? (I really have no idea it just looks like a suspicious change.) Steve Valid point that it is XTE_ALIGN + 2. As the comment says, it aligns the IP data in the packet. -- John This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/perf_events: Implement perf_arch_fetch_caller_regs for powerpc
This implements a powerpc version of perf_arch_fetch_caller_regs. It's implemented in assembly because that way we can be sure there isn't a stack frame for perf_arch_fetch_caller_regs. If it was in C, gcc might or might not create a stack frame for it, which would affect the number of levels we have to skip. Should we put this comment in the code as well? Mikey It's not ifdef'd because it is only 14 instructions long. With this, we see results from perf record -e lock:lock_acquire like this: # Samples: 24878 # # Overhead Command Shared Object Symbol # .. . .. # 14.99%perf [kernel.kallsyms] [k] ._raw_spin_lock | --- ._raw_spin_lock | |--25.00%-- .alloc_fd | (nil) | | | |--50.00%-- .anon_inode_getfd | | .sys_perf_event_open | | syscall_exit | | syscall | | create_counter | | __cmd_record | | run_builtin | | main | | 0xfd2e704 | | 0xfd2e8c0 | | (nil) ... etc. Signed-off-by: Paul Mackerras pau...@samba.org --- arch/powerpc/include/asm/asm-compat.h |2 ++ arch/powerpc/kernel/misc.S| 20 2 files changed, 22 insertions(+) diff --git a/arch/powerpc/include/asm/asm-compat.h b/arch/powerpc/include/asm /asm-compat.h index c1b475a..a9b91ed 100644 --- a/arch/powerpc/include/asm/asm-compat.h +++ b/arch/powerpc/include/asm/asm-compat.h @@ -28,6 +28,7 @@ #define PPC_LLARX(t, a, b, eh) PPC_LDARX(t, a, b, eh) #define PPC_STLCXstringify_in_c(stdcx.) #define PPC_CNTLZL stringify_in_c(cntlzd) +#define PPC_LR_STKOFF16 /* Move to CR, single-entry optimized version. Only available * on POWER4 and later. @@ -51,6 +52,7 @@ #define PPC_STLCXstringify_in_c(stwcx.) #define PPC_CNTLZL stringify_in_c(cntlzw) #define PPC_MTOCRF stringify_in_c(mtcrf) +#define PPC_LR_STKOFF4 #endif diff --git a/arch/powerpc/kernel/misc.S b/arch/powerpc/kernel/misc.S index 2d29752..4459500 100644 --- a/arch/powerpc/kernel/misc.S +++ b/arch/powerpc/kernel/misc.S @@ -127,3 +127,23 @@ _GLOBAL(__setup_cpu_power7) _GLOBAL(__restore_cpu_power7) /* place holder */ blr + +/* + * Get a minimal set of registers for our caller's nth caller. + * r3 = regs pointer, r5 = n. + */ +_GLOBAL(perf_arch_fetch_caller_regs) + mr r6,r1 + cmpwi r5,0 + mflrr4 + ble 2f + mtctr r5 +1: PPC_LL r6,0(r6) + bdnz1b + PPC_LL r4,PPC_LR_STKOFF(r6) +2: PPC_LL r7,0(r6) + PPC_LL r7,PPC_LR_STKOFF(r7) + PPC_STL r6,GPR1-STACK_FRAME_OVERHEAD(r3) + PPC_STL r4,_NIP-STACK_FRAME_OVERHEAD(r3) + PPC_STL r7,_LINK-STACK_FRAME_OVERHEAD(r3) + blr ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/perf_events: Implement perf_arch_fetch_caller_regs for powerpc
On Mon, Mar 15, 2010 at 04:46:15PM +1100, Paul Mackerras wrote: This implements a powerpc version of perf_arch_fetch_caller_regs. It's implemented in assembly because that way we can be sure there isn't a stack frame for perf_arch_fetch_caller_regs. If it was in C, gcc might or might not create a stack frame for it, which would affect the number of levels we have to skip. It's not ifdef'd because it is only 14 instructions long. With this, we see results from perf record -e lock:lock_acquire like this: # Samples: 24878 # # Overhead Command Shared Object Symbol # .. . .. # 14.99%perf [kernel.kallsyms] [k] ._raw_spin_lock | --- ._raw_spin_lock | |--25.00%-- .alloc_fd | (nil) | | | |--50.00%-- .anon_inode_getfd | | .sys_perf_event_open | | syscall_exit | | syscall | | create_counter | | __cmd_record | | run_builtin | | main | | 0xfd2e704 | | 0xfd2e8c0 | | (nil) ... etc. Signed-off-by: Paul Mackerras pau...@samba.org Cool! --- arch/powerpc/include/asm/asm-compat.h |2 ++ arch/powerpc/kernel/misc.S| 20 2 files changed, 22 insertions(+) diff --git a/arch/powerpc/include/asm/asm-compat.h b/arch/powerpc/include/asm/asm-compat.h index c1b475a..a9b91ed 100644 --- a/arch/powerpc/include/asm/asm-compat.h +++ b/arch/powerpc/include/asm/asm-compat.h @@ -28,6 +28,7 @@ #define PPC_LLARX(t, a, b, eh) PPC_LDARX(t, a, b, eh) #define PPC_STLCXstringify_in_c(stdcx.) #define PPC_CNTLZL stringify_in_c(cntlzd) +#define PPC_LR_STKOFF16 /* Move to CR, single-entry optimized version. Only available * on POWER4 and later. @@ -51,6 +52,7 @@ #define PPC_STLCXstringify_in_c(stwcx.) #define PPC_CNTLZL stringify_in_c(cntlzw) #define PPC_MTOCRF stringify_in_c(mtcrf) +#define PPC_LR_STKOFF4 #endif diff --git a/arch/powerpc/kernel/misc.S b/arch/powerpc/kernel/misc.S index 2d29752..4459500 100644 --- a/arch/powerpc/kernel/misc.S +++ b/arch/powerpc/kernel/misc.S @@ -127,3 +127,23 @@ _GLOBAL(__setup_cpu_power7) _GLOBAL(__restore_cpu_power7) /* place holder */ blr + +/* + * Get a minimal set of registers for our caller's nth caller. + * r3 = regs pointer, r5 = n. + */ +_GLOBAL(perf_arch_fetch_caller_regs) + mr r6,r1 + cmpwi r5,0 + mflrr4 + ble 2f + mtctr r5 +1: PPC_LL r6,0(r6) + bdnz1b + PPC_LL r4,PPC_LR_STKOFF(r6) +2: PPC_LL r7,0(r6) + PPC_LL r7,PPC_LR_STKOFF(r7) + PPC_STL r6,GPR1-STACK_FRAME_OVERHEAD(r3) + PPC_STL r4,_NIP-STACK_FRAME_OVERHEAD(r3) + PPC_STL r7,_LINK-STACK_FRAME_OVERHEAD(r3) + blr ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/4] Some typo fixing
I have fixed some typos. Thomas Weber (4): Fix typo: [Ss]ytem = [Ss]ystem Fix typo: udpate = update Fix typo: paramters = parameters Fix typo: orginal = original Documentation/cgroups/cgroups.txt |2 +- Documentation/kbuild/kconfig.txt|2 +- Documentation/sysfs-rules.txt |2 +- Documentation/trace/events.txt |8 drivers/acpi/osl.c |4 ++-- drivers/ata/ata_piix.c |2 +- drivers/firewire/ohci.c |2 +- drivers/gpu/drm/drm_bufs.c |2 +- drivers/infiniband/hw/ipath/ipath_iba6110.c |2 +- drivers/infiniband/hw/ipath/ipath_iba6120.c |4 ++-- drivers/infiniband/hw/ipath/ipath_iba7220.c |2 +- drivers/isdn/hisax/hfc4s8s_l1.c |2 +- drivers/macintosh/windfarm_pm81.c |2 +- drivers/media/dvb/dvb-usb/friio-fe.c|2 +- drivers/net/smsc911x.c |4 ++-- drivers/pci/hotplug/cpqphp_core.c |2 +- drivers/pci/pci.c |2 +- drivers/ps3/ps3-sys-manager.c |2 +- drivers/regulator/core.c|2 +- drivers/s390/char/sclp_cpi_sys.c|2 +- drivers/scsi/bfa/include/defs/bfa_defs_cee.h|2 +- drivers/scsi/bfa/include/defs/bfa_defs_status.h |4 ++-- drivers/spi/spi_mpc8xxx.c |2 +- drivers/staging/iio/Documentation/overview.txt |2 +- drivers/staging/rt2860/rtmp.h |2 +- drivers/staging/rtl8187se/r8180_core.c |4 ++-- drivers/staging/rtl8187se/r8180_dm.c|2 +- drivers/staging/rtl8187se/r8185b_init.c |2 +- drivers/virtio/virtio_pci.c |2 +- fs/jfs/jfs_dmap.c |2 +- kernel/cgroup.c |2 +- mm/page_alloc.c |2 +- net/wimax/op-rfkill.c |2 +- sound/pci/emu10k1/emu10k1_main.c|2 +- 34 files changed, 42 insertions(+), 42 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/4] Some typo fixing
On 03/15/10 13:55, Thomas Weber wrote: I have fixed some typos. Acked-by: Randy Dunlap rdun...@xenotime.net Jiri, can you merge these, please, unless someone objects (?). Thomas Weber (4): Fix typo: [Ss]ytem = [Ss]ystem Fix typo: udpate = update Fix typo: paramters = parameters Fix typo: orginal = original Documentation/cgroups/cgroups.txt |2 +- Documentation/kbuild/kconfig.txt|2 +- Documentation/sysfs-rules.txt |2 +- Documentation/trace/events.txt |8 drivers/acpi/osl.c |4 ++-- drivers/ata/ata_piix.c |2 +- drivers/firewire/ohci.c |2 +- drivers/gpu/drm/drm_bufs.c |2 +- drivers/infiniband/hw/ipath/ipath_iba6110.c |2 +- drivers/infiniband/hw/ipath/ipath_iba6120.c |4 ++-- drivers/infiniband/hw/ipath/ipath_iba7220.c |2 +- drivers/isdn/hisax/hfc4s8s_l1.c |2 +- drivers/macintosh/windfarm_pm81.c |2 +- drivers/media/dvb/dvb-usb/friio-fe.c|2 +- drivers/net/smsc911x.c |4 ++-- drivers/pci/hotplug/cpqphp_core.c |2 +- drivers/pci/pci.c |2 +- drivers/ps3/ps3-sys-manager.c |2 +- drivers/regulator/core.c|2 +- drivers/s390/char/sclp_cpi_sys.c|2 +- drivers/scsi/bfa/include/defs/bfa_defs_cee.h|2 +- drivers/scsi/bfa/include/defs/bfa_defs_status.h |4 ++-- drivers/spi/spi_mpc8xxx.c |2 +- drivers/staging/iio/Documentation/overview.txt |2 +- drivers/staging/rt2860/rtmp.h |2 +- drivers/staging/rtl8187se/r8180_core.c |4 ++-- drivers/staging/rtl8187se/r8180_dm.c|2 +- drivers/staging/rtl8187se/r8185b_init.c |2 +- drivers/virtio/virtio_pci.c |2 +- fs/jfs/jfs_dmap.c |2 +- kernel/cgroup.c |2 +- mm/page_alloc.c |2 +- net/wimax/op-rfkill.c |2 +- sound/pci/emu10k1/emu10k1_main.c|2 +- 34 files changed, 42 insertions(+), 42 deletions(-) Thanks. -- ~Randy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] sysdev: the cpu probe/release attributes should be sysdev_class_attributes
This fixes these warnings:
drivers/base/cpu.c:264: warning: initialization from incompatible pointer type
drivers/base/cpu.c:265: warning: initialization from incompatible pointer type
Cc: Andi Kleen a...@firstfloor.org
Signed-off-by: Stephen Rothwell s...@canb.auug.org.au
---
drivers/base/cpu.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
Hi Greg,
Could you pleas send this on to Linuse as this is now a bug in mainline.
Thanks.
diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index 7036e8e..b5242e1 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -79,24 +79,24 @@ void unregister_cpu(struct cpu *cpu)
}
#ifdef CONFIG_ARCH_CPU_PROBE_RELEASE
-static ssize_t cpu_probe_store(struct sys_device *dev,
- struct sysdev_attribute *attr,
- const char *buf,
+static ssize_t cpu_probe_store(struct sysdev_class *class,
+ struct sysdev_class_attribute *attr,
+ const char *buf,
size_t count)
{
return arch_cpu_probe(buf, count);
}
-static ssize_t cpu_release_store(struct sys_device *dev,
- struct sysdev_attribute *attr,
- const char *buf,
+static ssize_t cpu_release_store(struct sysdev_class *class,
+struct sysdev_class_attribute *attr,
+const char *buf,
size_t count)
{
return arch_cpu_release(buf, count);
}
-static SYSDEV_ATTR(probe, S_IWUSR, NULL, cpu_probe_store);
-static SYSDEV_ATTR(release, S_IWUSR, NULL, cpu_release_store);
+static SYSDEV_CLASS_ATTR(probe, S_IWUSR, NULL, cpu_probe_store);
+static SYSDEV_CLASS_ATTR(release, S_IWUSR, NULL, cpu_release_store);
#endif /* CONFIG_ARCH_CPU_PROBE_RELEASE */
#else /* ... !CONFIG_HOTPLUG_CPU */
--
1.7.0
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] sysdev: the cpu probe/release attributes should be sysdev_class_attributes
On Tue, Mar 16, 2010 at 10:33:32AM +1100, Stephen Rothwell wrote: This fixes these warnings: drivers/base/cpu.c:264: warning: initialization from incompatible pointer type drivers/base/cpu.c:265: warning: initialization from incompatible pointer type Cc: Andi Kleen a...@firstfloor.org Signed-off-by: Stephen Rothwell s...@canb.auug.org.au --- drivers/base/cpu.c | 16 1 files changed, 8 insertions(+), 8 deletions(-) Hi Greg, Could you pleas send this on to Linuse as this is now a bug in mainline. Will do, thanks so much for fixing this up correctly. greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 05/11] swiotlb: add swiotlb_set_default_size()
On Fri, 12 Mar 2010 20:12:40 +0100 Albert Herranz albert_herr...@yahoo.es wrote: The current SWIOTLB code uses a default of 64MB for the IO TLB area. This size can be influenced using a kernel command line parameter swiotlb. Unfortunately, the parsing of the kernel command line is done _after_ the swiotlb is initialized on some architectures. This patch adds a new function swiotlb_set_default_size() which can be used before swiotlb_init() to indicate the desired IO TLB area size in bytes. This will be used later to implement a smaller IO TLB on the Nintendo Wii video game console which just comes with 24MB + 64MB of RAM. CC: linuxppc-dev@lists.ozlabs.org CC: linux-ker...@vger.kernel.org CC: x...@kernel.org CC: linux-i...@vger.kernel.org Signed-off-by: Albert Herranz albert_herr...@yahoo.es --- include/linux/swiotlb.h |2 ++ lib/swiotlb.c | 20 2 files changed, 22 insertions(+), 0 deletions(-) Please fix the powerpc swiotlb initialization instead. Calling swiotlb_init() before parsing kernel parameters sounds wrong. Any reasons why you can't fix it? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 04/11] swiotlb: support NOT_COHERENT_CACHE PowerPC platforms
On Fri, 12 Mar 2010 20:12:39 +0100 Albert Herranz albert_herr...@yahoo.es wrote: The current SWIOTLB code does not support NOT_COHERENT_CACHE platforms. This patch adds support for NOT_COHERENT_CACHE platforms to SWIOTLB by adding two platform specific functions swiotlb_dma_sync_page() and swiotlb_dma_sync() which can be used to explicitly manage cache coherency. On PowerPC these functions are mapped to their corresponding __dma_sync_page() and __dma_sync() functions. On other architectures using SWIOTLB these functions are optimized out. This will be used later to support SWIOTLB on the Nintendo Wii video game console. CC: linuxppc-dev@lists.ozlabs.org CC: linux-ker...@vger.kernel.org CC: x...@kernel.org CC: linux-i...@vger.kernel.org Signed-off-by: Albert Herranz albert_herr...@yahoo.es --- arch/ia64/include/asm/swiotlb.h| 10 ++ arch/powerpc/include/asm/swiotlb.h |3 +++ arch/x86/include/asm/swiotlb.h | 10 ++ lib/swiotlb.c | 30 -- 4 files changed, 47 insertions(+), 6 deletions(-) Why can't you use dma_sync_single_* instead of inventing new swiotlb sync functions? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 04/11] swiotlb: support NOT_COHERENT_CACHE PowerPC platforms
On Tue, 16 Mar 2010 10:54:40 +0900 FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp wrote: On Fri, 12 Mar 2010 20:12:39 +0100 Albert Herranz albert_herr...@yahoo.es wrote: The current SWIOTLB code does not support NOT_COHERENT_CACHE platforms. This patch adds support for NOT_COHERENT_CACHE platforms to SWIOTLB by adding two platform specific functions swiotlb_dma_sync_page() and swiotlb_dma_sync() which can be used to explicitly manage cache coherency. On PowerPC these functions are mapped to their corresponding __dma_sync_page() and __dma_sync() functions. On other architectures using SWIOTLB these functions are optimized out. This will be used later to support SWIOTLB on the Nintendo Wii video game console. CC: linuxppc-dev@lists.ozlabs.org CC: linux-ker...@vger.kernel.org CC: x...@kernel.org CC: linux-i...@vger.kernel.org Signed-off-by: Albert Herranz albert_herr...@yahoo.es --- arch/ia64/include/asm/swiotlb.h| 10 ++ arch/powerpc/include/asm/swiotlb.h |3 +++ arch/x86/include/asm/swiotlb.h | 10 ++ lib/swiotlb.c | 30 -- 4 files changed, 47 insertions(+), 6 deletions(-) Why can't you use dma_sync_single_* instead of inventing new swiotlb sync functions? If we want to make swiotlb generic (make on any architectures), we need to handle more cache issues here, I think. So it's better to have more generic ways instead of adding hooks to some archs. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/perf_events: Implement perf_arch_fetch_caller_regs for powerpc
On Mon, Mar 15, 2010 at 10:04:54PM +0100, Frederic Weisbecker wrote: On Mon, Mar 15, 2010 at 04:46:15PM +1100, Paul Mackerras wrote: 14.99%perf [kernel.kallsyms] [k] ._raw_spin_lock | --- ._raw_spin_lock | |--25.00%-- .alloc_fd | (nil) | | | |--50.00%-- .anon_inode_getfd | | .sys_perf_event_open | | syscall_exit | | syscall | | create_counter | | __cmd_record | | run_builtin | | main | | 0xfd2e704 | | 0xfd2e8c0 | | (nil) ... etc. Signed-off-by: Paul Mackerras pau...@samba.org Cool! By the way, I notice that gcc tends to inline the tracing functions, which means that by going up 2 stack frames we miss some of the functions. For example, for the lock:lock_acquire event, we have _raw_spin_lock() - lock_acquire() - trace_lock_acquire() - perf_trace_lock_acquire() - perf_trace_templ_lock_acquire() - perf_fetch_caller_regs() - perf_arch_fetch_caller_regs(). But in the ppc64 kernel binary I just built, gcc inlined trace_lock_acquire in lock_acquire, and perf_trace_templ_lock_acquire in perf_trace_lock_acquire. Given that perf_fetch_caller_regs is explicitly inlined, going up two levels from perf_fetch_caller_regs gets us to _raw_spin_lock, whereas I think you intended it to get us to trace_lock_acquire. I'm not sure what to do about that - any thoughts? Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Linux Priority Levels
Hi, I need a deeper understanding of priorities of linux processes and threads, especially on Linux PPC. I have done some good reading, but found no material to be complete and therefore I am raising a few questions below. 1) In Linux processes have a static priority level 0, with nice values -20 to +19. Then it has RT priority levels 1 - 99. My question is, do the nice values apply to all processes or do they apply only to priority 0? 2) How many total priority levels does the kernel have? On one hand, -20 is the highest priority, on the other hand +99 is the highest. How do these values converge? Please help me to answer these and depending on the reply I would shoot more questions. In case you have a comprehensive reading material to refer, please advise. Thanks, Ajay. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Linux Priority Levels
I need a deeper understanding of priorities of linux processes and threads, especially on Linux PPC. I have done some good reading, but found no material to be complete and therefore I am raising a few questions below. 1) In Linux processes have a static priority level 0, with nice values -20 to +19. Then it has RT priority levels 1 - 99. My question is, do the nice values apply to all processes or do they apply only to priority 0? 2) How many total priority levels does the kernel have? On one hand, -20 is the highest priority, on the other hand +99 is the highest. How do these values converge? Please help me to answer these and depending on the reply I would shoot more questions. In case you have a comprehensive reading material to refer, please advise. man sched_setscheduler has a good description of these levels and how RT and non RT processes interact. Mikey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problem with PCI bus rescan on 460EX
Felix Radensky wrote: Hello, Kenji-san I think the device is expected to be ready to work if pci_enable_device() returns without error. So I think pci_enable_device() should return an error if it fails to enable the device (device is not ready to work). In this case, detecting your bridge's failure seems PPC specific to me. So I thought pcibios_enable_device() was the right to return an error. If pcibios_enable_device() returned an error, pci_dev-enable_cnt would decremented by pci_enable_device() (like pci_disable_device() does) and this problem would not happen. As far as I can see on 460EX pcibios_enable_device() just calls pci_enable_resources() which does not return any error for my bridge, although it doesn't find any memory or I/O resource it can enable. Do you think it is correct behavior ? Another question is whether by bridge behaves correctly when no device is connected to it. As you can see in dmesg output I've sent earlier pci :00:02.0: bridge window [mem 0x-0x000f] pci :00:02.0: bridge window [mem 0x-0x000f 64bit pref] and later PCI code disables these memory windows pci :00:02.0: disabling bridge window [mem 0xd-0xd000f pref] to [bus 01-01] (unused) pci :00:02.0: disabling bridge window [mem 0xd-0xd000f] to [bus 01-01] (unused) I misunderstood the problem. My understanding was memory resource was not enabled even though Linux set the Memory Space bit in the command register. But it was not correct. The bridge memory window was marked unused and Linux didn't try to set Memory Space bit in the command register. Current my understanding is as follows. Please correct me if I'm still misunderstanding something. 1) Your BIOS doesn't assign any resource to the bridge if its child PCI hot-plug slot is not occupied. 2) At the boot time, pci_assign_unassigned_resources() try to assign memory resouces to the bridge using pci_bus_assign_resource(), but it was disabled because there are no devices require memory resource. 3) And then pci_assign_unassigned_resouces() calls pci_enable_bridge(), but Memory Space bit in the command register was not set because no memory resource are assigned to the bridge. At the same time, pci_dev-enable_cnt was incremented. 4) At the rescan time, pci_setup_bridge() and pci_enable_bridge() doesn't work because the bridge is already marked enabled (i.e. pci_dev-enable_cnt is not zero). I don't have any concrete idea how to fix that so far, but I can say my idea (pcibios_enable_device() should return an error) was wrong. BTW, on my PCI hotplug capable system (SHPC and PCIe), I/O and Memory windows of the bridge are assigned by BIOS regardless of whether hotplug slot(s) behind the bridge is occupied or not. Maybe that is the reason why I have never encountered this problem before. Thanks, Kenji Kaneshige BTW, there's no problem accessing PCI_COMMAND register, as bus mastering is enabled in the bridge. On the other hand, as Ben suggested, handling this by specific hot-plug driver would be one of the other candidate to fix the problem. I'm not opposed to this idea, it's just that this bridge worked in an older system based on linux-2.6.22 and patched fakephp driver was used for hotplug. There's existing userspace software that I don't really want to modify heavily. But I'll do that if generic PCI rescan cannot be fixed. Thanks a lot for your help. Felix. -- To unsubscribe from this list: send the line unsubscribe linux-pci in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 05/11] swiotlb: add swiotlb_set_default_size()
FUJITA Tomonori wrote: On Fri, 12 Mar 2010 20:12:40 +0100 Albert Herranz albert_herr...@yahoo.es wrote: The current SWIOTLB code uses a default of 64MB for the IO TLB area. This size can be influenced using a kernel command line parameter swiotlb. Unfortunately, the parsing of the kernel command line is done _after_ the swiotlb is initialized on some architectures. This patch adds a new function swiotlb_set_default_size() which can be used before swiotlb_init() to indicate the desired IO TLB area size in bytes. This will be used later to implement a smaller IO TLB on the Nintendo Wii video game console which just comes with 24MB + 64MB of RAM. CC: linuxppc-dev@lists.ozlabs.org CC: linux-ker...@vger.kernel.org CC: x...@kernel.org CC: linux-i...@vger.kernel.org Signed-off-by: Albert Herranz albert_herr...@yahoo.es --- include/linux/swiotlb.h |2 ++ lib/swiotlb.c | 20 2 files changed, 22 insertions(+), 0 deletions(-) Please fix the powerpc swiotlb initialization instead. Calling swiotlb_init() before parsing kernel parameters sounds wrong. Any reasons why you can't fix it? I think that this would be better asked by a PowerPC maintainer. Ben? If this is really a problem the swiotlb late init may be a solution too in this particular case. Thanks, Albert ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
