* Re: [PATCH] powerpc: rework 4xx PTE access and TLB miss
From: Benjamin Herrenschmidt @ 2008-07-07 22:03 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20080707100627.4be05488@zod.rchland.ibm.com>
On Mon, 2008-07-07 at 10:06 -0400, Josh Boyer wrote:
> The setup is an tftp'd kernel via U-Boot using cuImage, nfsroot
> filesystem. Sequoia has an FPU, and CONFIG_PPC_FPU is set.
>
> I reverted this patch and used the latest powerpc-next branch and it
> boots fine.
>
> Seems something is wrong here still. I suspect the DSI handler
> changes, but I have no proof and haven't debugged it yet. Until we
> get it fixed, I don't feel overly comfortable putting it in the next
> branch. Which board and setup did you test with?
mambo and another board I don't remember which one precisely.
I'll have a look.
Cheers,
Ben.
^ permalink raw reply
* [PATCH v6] ibm_newemac: Parameterize EMAC Multicast Match Handling
From: Grant Erickson @ 2008-07-07 22:03 UTC (permalink / raw)
To: linuxppc-dev; +Cc: sr
In-Reply-To: <1215387012-6464-1-git-send-email-gerickson@nuovations.com>
Various instances of the EMAC core have varying: 1) number of address
match slots, 2) width of the registers for handling address match slots,
3) number of registers for handling address match slots and 4) base
offset for those registers.
As the driver stands today, it assumes that all EMACs have 4 IAHT and
GAHT 32-bit registers, starting at offset 0x30 from the register base,
with only 16-bits of each used for a total of 64 match slots.
The 405EX(r) and 460EX now use the EMAC4SYNC core rather than the EMAC4
core. This core has 8 IAHT and GAHT registers, starting at offset 0x80
from the register base, with ALL 32-bits of each used for a total of
256 match slots.
This adds a new compatible device tree entry "emac4sync" and a new,
related feature flag "EMAC_FTR_EMAC4SYNC" along with a series of macros
and inlines which supply the appropriate parameterized value based on
the presence or absence of the EMAC4SYNC feature.
The code has further been reworked where appropriate to use those macros
and inlines.
In addition, the register size passed to ioremap is now taken from the
device tree:
c4 for EMAC4SYNC cores
74 for EMAC4 cores
70 for EMAC cores
rather than sizeof (emac_regs).
Finally, the device trees have been updated with the appropriate compatible
entries and resource sizes.
This has been tested on an AMCC Haleakala board such that: 1) inbound
ICMP requests to 'haleakala.local' via MDNS from both Mac OS X 10.4.11
and Ubuntu 8.04 systems as well as 2) outbound ICMP requests from
'haleakala.local' to those same systems in the '.local' domain via MDNS
now work.
Signed-off-by: Grant Erickson <gerickson@nuovations.com>
---
arch/powerpc/boot/dts/canyonlands.dts | 8 +-
arch/powerpc/boot/dts/glacier.dts | 8 +-
arch/powerpc/boot/dts/haleakala.dts | 4 +-
arch/powerpc/boot/dts/katmai.dts | 2 +-
arch/powerpc/boot/dts/kilauea.dts | 8 +-
arch/powerpc/boot/dts/makalu.dts | 8 +-
arch/powerpc/boot/dts/rainier.dts | 4 +-
arch/powerpc/boot/dts/sequoia.dts | 4 +-
arch/powerpc/boot/dts/taishan.dts | 8 +-
drivers/net/ibm_newemac/core.c | 61 ++++++++++++++------
drivers/net/ibm_newemac/core.h | 83 ++++++++++++++++++++++++++-
drivers/net/ibm_newemac/debug.c | 52 +++++++++++++----
drivers/net/ibm_newemac/emac.h | 101 ++++++++++++++++++++++----------
13 files changed, 259 insertions(+), 92 deletions(-)
diff --git a/arch/powerpc/boot/dts/canyonlands.dts b/arch/powerpc/boot/dts/canyonlands.dts
index 3963412..8b82d47 100644
--- a/arch/powerpc/boot/dts/canyonlands.dts
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -264,7 +264,7 @@
EMAC0: ethernet@ef600e00 {
device_type = "network";
- compatible = "ibm,emac-460ex", "ibm,emac4";
+ compatible = "ibm,emac-460ex", "ibm,emac4sync";
interrupt-parent = <&EMAC0>;
interrupts = <0 1>;
#interrupt-cells = <1>;
@@ -272,7 +272,7 @@
#size-cells = <0>;
interrupt-map = </*Status*/ 0 &UIC2 10 4
/*Wake*/ 1 &UIC2 14 4>;
- reg = <ef600e00 70>;
+ reg = <ef600e00 c4>;
local-mac-address = [000000000000]; /* Filled in by U-Boot */
mal-device = <&MAL0>;
mal-tx-channel = <0>;
@@ -293,7 +293,7 @@
EMAC1: ethernet@ef600f00 {
device_type = "network";
- compatible = "ibm,emac-460ex", "ibm,emac4";
+ compatible = "ibm,emac-460ex", "ibm,emac4sync";
interrupt-parent = <&EMAC1>;
interrupts = <0 1>;
#interrupt-cells = <1>;
@@ -301,7 +301,7 @@
#size-cells = <0>;
interrupt-map = </*Status*/ 0 &UIC2 11 4
/*Wake*/ 1 &UIC2 15 4>;
- reg = <ef600f00 70>;
+ reg = <ef600f00 c4>;
local-mac-address = [000000000000]; /* Filled in by U-Boot */
mal-device = <&MAL0>;
mal-tx-channel = <1>;
diff --git a/arch/powerpc/boot/dts/glacier.dts b/arch/powerpc/boot/dts/glacier.dts
index 0f2fc07..8ffde9b 100644
--- a/arch/powerpc/boot/dts/glacier.dts
+++ b/arch/powerpc/boot/dts/glacier.dts
@@ -281,7 +281,7 @@
#size-cells = <0>;
interrupt-map = </*Status*/ 0 &UIC2 10 4
/*Wake*/ 1 &UIC2 14 4>;
- reg = <ef600e00 70>;
+ reg = <ef600e00 74>;
local-mac-address = [000000000000]; /* Filled in by U-Boot */
mal-device = <&MAL0>;
mal-tx-channel = <0>;
@@ -310,7 +310,7 @@
#size-cells = <0>;
interrupt-map = </*Status*/ 0 &UIC2 11 4
/*Wake*/ 1 &UIC2 15 4>;
- reg = <ef600f00 70>;
+ reg = <ef600f00 74>;
local-mac-address = [000000000000]; /* Filled in by U-Boot */
mal-device = <&MAL0>;
mal-tx-channel = <1>;
@@ -340,7 +340,7 @@
#size-cells = <0>;
interrupt-map = </*Status*/ 0 &UIC2 12 4
/*Wake*/ 1 &UIC2 16 4>;
- reg = <ef601100 70>;
+ reg = <ef601100 74>;
local-mac-address = [000000000000]; /* Filled in by U-Boot */
mal-device = <&MAL0>;
mal-tx-channel = <2>;
@@ -368,7 +368,7 @@
#size-cells = <0>;
interrupt-map = </*Status*/ 0 &UIC2 13 4
/*Wake*/ 1 &UIC2 17 4>;
- reg = <ef601200 70>;
+ reg = <ef601200 74>;
local-mac-address = [000000000000]; /* Filled in by U-Boot */
mal-device = <&MAL0>;
mal-tx-channel = <3>;
diff --git a/arch/powerpc/boot/dts/haleakala.dts b/arch/powerpc/boot/dts/haleakala.dts
index b5d95ac..d131c00 100644
--- a/arch/powerpc/boot/dts/haleakala.dts
+++ b/arch/powerpc/boot/dts/haleakala.dts
@@ -204,7 +204,7 @@
EMAC0: ethernet@ef600900 {
linux,network-index = <0>;
device_type = "network";
- compatible = "ibm,emac-405exr", "ibm,emac4";
+ compatible = "ibm,emac-405exr", "ibm,emac4sync";
interrupt-parent = <&EMAC0>;
interrupts = <0 1>;
#interrupt-cells = <1>;
@@ -212,7 +212,7 @@
#size-cells = <0>;
interrupt-map = </*Status*/ 0 &UIC0 18 4
/*Wake*/ 1 &UIC1 1d 4>;
- reg = <ef600900 70>;
+ reg = <ef600900 c4>;
local-mac-address = [000000000000]; /* Filled in by U-Boot */
mal-device = <&MAL0>;
mal-tx-channel = <0>;
diff --git a/arch/powerpc/boot/dts/katmai.dts b/arch/powerpc/boot/dts/katmai.dts
index cc2873a..c91bb66 100644
--- a/arch/powerpc/boot/dts/katmai.dts
+++ b/arch/powerpc/boot/dts/katmai.dts
@@ -206,7 +206,7 @@
compatible = "ibm,emac-440spe", "ibm,emac4";
interrupt-parent = <&UIC1>;
interrupts = <1c 4 1d 4>;
- reg = <10000800 70>;
+ reg = <10000800 74>;
local-mac-address = [000000000000];
mal-device = <&MAL0>;
mal-tx-channel = <0>;
diff --git a/arch/powerpc/boot/dts/kilauea.dts b/arch/powerpc/boot/dts/kilauea.dts
index 48c9a6e..bfae1b2 100644
--- a/arch/powerpc/boot/dts/kilauea.dts
+++ b/arch/powerpc/boot/dts/kilauea.dts
@@ -205,7 +205,7 @@
EMAC0: ethernet@ef600900 {
linux,network-index = <0>;
device_type = "network";
- compatible = "ibm,emac-405ex", "ibm,emac4";
+ compatible = "ibm,emac-405ex", "ibm,emac4sync";
interrupt-parent = <&EMAC0>;
interrupts = <0 1>;
#interrupt-cells = <1>;
@@ -213,7 +213,7 @@
#size-cells = <0>;
interrupt-map = </*Status*/ 0 &UIC0 18 4
/*Wake*/ 1 &UIC1 1d 4>;
- reg = <ef600900 70>;
+ reg = <ef600900 c4>;
local-mac-address = [000000000000]; /* Filled in by U-Boot */
mal-device = <&MAL0>;
mal-tx-channel = <0>;
@@ -233,7 +233,7 @@
EMAC1: ethernet@ef600a00 {
linux,network-index = <1>;
device_type = "network";
- compatible = "ibm,emac-405ex", "ibm,emac4";
+ compatible = "ibm,emac-405ex", "ibm,emac4sync";
interrupt-parent = <&EMAC1>;
interrupts = <0 1>;
#interrupt-cells = <1>;
@@ -241,7 +241,7 @@
#size-cells = <0>;
interrupt-map = </*Status*/ 0 &UIC0 19 4
/*Wake*/ 1 &UIC1 1f 4>;
- reg = <ef600a00 70>;
+ reg = <ef600a00 c4>;
local-mac-address = [000000000000]; /* Filled in by U-Boot */
mal-device = <&MAL0>;
mal-tx-channel = <1>;
diff --git a/arch/powerpc/boot/dts/makalu.dts b/arch/powerpc/boot/dts/makalu.dts
index 84cc5e7..895381f 100644
--- a/arch/powerpc/boot/dts/makalu.dts
+++ b/arch/powerpc/boot/dts/makalu.dts
@@ -205,7 +205,7 @@
EMAC0: ethernet@ef600900 {
linux,network-index = <0>;
device_type = "network";
- compatible = "ibm,emac-405ex", "ibm,emac4";
+ compatible = "ibm,emac-405ex", "ibm,emac4sync";
interrupt-parent = <&EMAC0>;
interrupts = <0 1>;
#interrupt-cells = <1>;
@@ -213,7 +213,7 @@
#size-cells = <0>;
interrupt-map = </*Status*/ 0 &UIC0 18 4
/*Wake*/ 1 &UIC1 1d 4>;
- reg = <ef600900 70>;
+ reg = <ef600900 c4>;
local-mac-address = [000000000000]; /* Filled in by U-Boot */
mal-device = <&MAL0>;
mal-tx-channel = <0>;
@@ -233,7 +233,7 @@
EMAC1: ethernet@ef600a00 {
linux,network-index = <1>;
device_type = "network";
- compatible = "ibm,emac-405ex", "ibm,emac4";
+ compatible = "ibm,emac-405ex", "ibm,emac4sync";
interrupt-parent = <&EMAC1>;
interrupts = <0 1>;
#interrupt-cells = <1>;
@@ -241,7 +241,7 @@
#size-cells = <0>;
interrupt-map = </*Status*/ 0 &UIC0 19 4
/*Wake*/ 1 &UIC1 1f 4>;
- reg = <ef600a00 70>;
+ reg = <ef600a00 c4>;
local-mac-address = [000000000000]; /* Filled in by U-Boot */
mal-device = <&MAL0>;
mal-tx-channel = <1>;
diff --git a/arch/powerpc/boot/dts/rainier.dts b/arch/powerpc/boot/dts/rainier.dts
index 6a8fa70..026c22c 100644
--- a/arch/powerpc/boot/dts/rainier.dts
+++ b/arch/powerpc/boot/dts/rainier.dts
@@ -263,7 +263,7 @@
#size-cells = <0>;
interrupt-map = </*Status*/ 0 &UIC0 18 4
/*Wake*/ 1 &UIC1 1d 4>;
- reg = <ef600e00 70>;
+ reg = <ef600e00 74>;
local-mac-address = [000000000000];
mal-device = <&MAL0>;
mal-tx-channel = <0>;
@@ -292,7 +292,7 @@
#size-cells = <0>;
interrupt-map = </*Status*/ 0 &UIC0 19 4
/*Wake*/ 1 &UIC1 1f 4>;
- reg = <ef600f00 70>;
+ reg = <ef600f00 74>;
local-mac-address = [000000000000];
mal-device = <&MAL0>;
mal-tx-channel = <1>;
diff --git a/arch/powerpc/boot/dts/sequoia.dts b/arch/powerpc/boot/dts/sequoia.dts
index 72d6756..8d66c99 100644
--- a/arch/powerpc/boot/dts/sequoia.dts
+++ b/arch/powerpc/boot/dts/sequoia.dts
@@ -278,7 +278,7 @@
#size-cells = <0>;
interrupt-map = </*Status*/ 0 &UIC0 18 4
/*Wake*/ 1 &UIC1 1d 4>;
- reg = <ef600e00 70>;
+ reg = <ef600e00 74>;
local-mac-address = [000000000000];
mal-device = <&MAL0>;
mal-tx-channel = <0>;
@@ -307,7 +307,7 @@
#size-cells = <0>;
interrupt-map = </*Status*/ 0 &UIC0 19 4
/*Wake*/ 1 &UIC1 1f 4>;
- reg = <ef600f00 70>;
+ reg = <ef600f00 74>;
local-mac-address = [000000000000];
mal-device = <&MAL0>;
mal-tx-channel = <1>;
diff --git a/arch/powerpc/boot/dts/taishan.dts b/arch/powerpc/boot/dts/taishan.dts
index e808e1c..f736d87 100644
--- a/arch/powerpc/boot/dts/taishan.dts
+++ b/arch/powerpc/boot/dts/taishan.dts
@@ -258,7 +258,7 @@
compatible = "ibm,emac-440gx", "ibm,emac4";
interrupt-parent = <&UIC1>;
interrupts = <1c 4 1d 4>;
- reg = <40000800 70>;
+ reg = <40000800 74>;
local-mac-address = [000000000000]; // Filled in by zImage
mal-device = <&MAL0>;
mal-tx-channel = <0>;
@@ -278,7 +278,7 @@
compatible = "ibm,emac-440gx", "ibm,emac4";
interrupt-parent = <&UIC1>;
interrupts = <1e 4 1f 4>;
- reg = <40000900 70>;
+ reg = <40000900 74>;
local-mac-address = [000000000000]; // Filled in by zImage
mal-device = <&MAL0>;
mal-tx-channel = <1>;
@@ -298,7 +298,7 @@
compatible = "ibm,emac-440gx", "ibm,emac4";
interrupt-parent = <&UIC2>;
interrupts = <0 4 1 4>;
- reg = <40000c00 70>;
+ reg = <40000c00 74>;
local-mac-address = [000000000000]; // Filled in by zImage
mal-device = <&MAL0>;
mal-tx-channel = <2>;
@@ -322,7 +322,7 @@
compatible = "ibm,emac-440gx", "ibm,emac4";
interrupt-parent = <&UIC2>;
interrupts = <2 4 3 4>;
- reg = <40000e00 70>;
+ reg = <40000e00 74>;
local-mac-address = [000000000000]; // Filled in by zImage
mal-device = <&MAL0>;
mal-tx-channel = <3>;
diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index 5d2108c..ed24a1d 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -363,25 +363,31 @@ static int emac_reset(struct emac_instance *dev)
static void emac_hash_mc(struct emac_instance *dev)
{
- struct emac_regs __iomem *p = dev->emacp;
- u16 gaht[4] = { 0 };
+ const int regs = EMAC_XAHT_REGS(dev);
+ u32 *gaht_base = emac_gaht_base(dev);
+ u32 gaht_temp[regs];
struct dev_mc_list *dmi;
+ int i;
DBG(dev, "hash_mc %d" NL, dev->ndev->mc_count);
+ memset(gaht_temp, 0, sizeof (gaht_temp));
+
for (dmi = dev->ndev->mc_list; dmi; dmi = dmi->next) {
- int bit;
+ int slot, reg, mask;
DBG2(dev, "mc %02x:%02x:%02x:%02x:%02x:%02x" NL,
dmi->dmi_addr[0], dmi->dmi_addr[1], dmi->dmi_addr[2],
dmi->dmi_addr[3], dmi->dmi_addr[4], dmi->dmi_addr[5]);
- bit = 63 - (ether_crc(ETH_ALEN, dmi->dmi_addr) >> 26);
- gaht[bit >> 4] |= 0x8000 >> (bit & 0x0f);
+ slot = EMAC_XAHT_CRC_TO_SLOT(dev, ether_crc(ETH_ALEN, dmi->dmi_addr));
+ reg = EMAC_XAHT_SLOT_TO_REG(dev, slot);
+ mask = EMAC_XAHT_SLOT_TO_MASK(dev, slot);
+
+ gaht_temp[reg] |= mask;
}
- out_be32(&p->gaht1, gaht[0]);
- out_be32(&p->gaht2, gaht[1]);
- out_be32(&p->gaht3, gaht[2]);
- out_be32(&p->gaht4, gaht[3]);
+
+ for (i = 0; i < regs; i++)
+ out_be32(gaht_base + i, gaht_temp[i]);
}
static inline u32 emac_iff2rmr(struct net_device *ndev)
@@ -398,7 +404,8 @@ static inline u32 emac_iff2rmr(struct net_device *ndev)
if (ndev->flags & IFF_PROMISC)
r |= EMAC_RMR_PME;
- else if (ndev->flags & IFF_ALLMULTI || ndev->mc_count > 32)
+ else if (ndev->flags & IFF_ALLMULTI ||
+ (ndev->mc_count > EMAC_XAHT_SLOTS(dev)))
r |= EMAC_RMR_PMME;
else if (ndev->mc_count > 0)
r |= EMAC_RMR_MAE;
@@ -542,7 +549,7 @@ static int emac_configure(struct emac_instance *dev)
/* Put some arbitrary OUI, Manuf & Rev IDs so we can
* identify this GPCS PHY later.
*/
- out_be32(&p->ipcr, 0xdeadbeef);
+ out_be32(&p->u1.emac4.ipcr, 0xdeadbeef);
} else
mr1 |= EMAC_MR1_MF_1000;
@@ -2015,10 +2022,10 @@ static int emac_get_regs_len(struct emac_instance *dev)
{
if (emac_has_feature(dev, EMAC_FTR_EMAC4))
return sizeof(struct emac_ethtool_regs_subhdr) +
- EMAC4_ETHTOOL_REGS_SIZE;
+ EMAC4_ETHTOOL_REGS_SIZE(dev);
else
return sizeof(struct emac_ethtool_regs_subhdr) +
- EMAC_ETHTOOL_REGS_SIZE;
+ EMAC_ETHTOOL_REGS_SIZE(dev);
}
static int emac_ethtool_get_regs_len(struct net_device *ndev)
@@ -2045,12 +2052,12 @@ static void *emac_dump_regs(struct emac_instance *dev, void *buf)
hdr->index = dev->cell_index;
if (emac_has_feature(dev, EMAC_FTR_EMAC4)) {
hdr->version = EMAC4_ETHTOOL_REGS_VER;
- memcpy_fromio(hdr + 1, dev->emacp, EMAC4_ETHTOOL_REGS_SIZE);
- return ((void *)(hdr + 1) + EMAC4_ETHTOOL_REGS_SIZE);
+ memcpy_fromio(hdr + 1, dev->emacp, EMAC4_ETHTOOL_REGS_SIZE(dev));
+ return ((void *)(hdr + 1) + EMAC4_ETHTOOL_REGS_SIZE(dev));
} else {
hdr->version = EMAC_ETHTOOL_REGS_VER;
- memcpy_fromio(hdr + 1, dev->emacp, EMAC_ETHTOOL_REGS_SIZE);
- return ((void *)(hdr + 1) + EMAC_ETHTOOL_REGS_SIZE);
+ memcpy_fromio(hdr + 1, dev->emacp, EMAC_ETHTOOL_REGS_SIZE(dev));
+ return ((void *)(hdr + 1) + EMAC_ETHTOOL_REGS_SIZE(dev));
}
}
@@ -2540,7 +2547,9 @@ static int __devinit emac_init_config(struct emac_instance *dev)
}
/* Check EMAC version */
- if (of_device_is_compatible(np, "ibm,emac4")) {
+ if (of_device_is_compatible(np, "ibm,emac4sync")) {
+ dev->features |= (EMAC_FTR_EMAC4 | EMAC_FTR_EMAC4SYNC);
+ } else if (of_device_is_compatible(np, "ibm,emac4")) {
dev->features |= EMAC_FTR_EMAC4;
if (of_device_is_compatible(np, "ibm,emac-440gx"))
dev->features |= EMAC_FTR_440GX_PHY_CLK_FIX;
@@ -2601,6 +2610,15 @@ static int __devinit emac_init_config(struct emac_instance *dev)
}
memcpy(dev->ndev->dev_addr, p, 6);
+ /* IAHT and GAHT filter parameterization */
+ if (emac_has_feature(dev, EMAC_FTR_EMAC4SYNC)) {
+ dev->xaht_slots_shift = EMAC4SYNC_XAHT_SLOTS_SHIFT;
+ dev->xaht_width_shift = EMAC4SYNC_XAHT_WIDTH_SHIFT;
+ } else {
+ dev->xaht_slots_shift = EMAC4_XAHT_SLOTS_SHIFT;
+ dev->xaht_width_shift = EMAC4_XAHT_WIDTH_SHIFT;
+ }
+
DBG(dev, "features : 0x%08x / 0x%08x\n", dev->features, EMAC_FTRS_POSSIBLE);
DBG(dev, "tx_fifo_size : %d (%d gige)\n", dev->tx_fifo_size, dev->tx_fifo_size_gige);
DBG(dev, "rx_fifo_size : %d (%d gige)\n", dev->rx_fifo_size, dev->rx_fifo_size_gige);
@@ -2672,7 +2690,8 @@ static int __devinit emac_probe(struct of_device *ofdev,
goto err_irq_unmap;
}
// TODO : request_mem_region
- dev->emacp = ioremap(dev->rsrc_regs.start, sizeof(struct emac_regs));
+ dev->emacp = ioremap(dev->rsrc_regs.start,
+ dev->rsrc_regs.end - dev->rsrc_regs.start + 1);
if (dev->emacp == NULL) {
printk(KERN_ERR "%s: Can't map device registers!\n",
np->full_name);
@@ -2884,6 +2903,10 @@ static struct of_device_id emac_match[] =
.type = "network",
.compatible = "ibm,emac4",
},
+ {
+ .type = "network",
+ .compatible = "ibm,emac4sync",
+ },
{},
};
diff --git a/drivers/net/ibm_newemac/core.h b/drivers/net/ibm_newemac/core.h
index 1683db9..70794cd 100644
--- a/drivers/net/ibm_newemac/core.h
+++ b/drivers/net/ibm_newemac/core.h
@@ -235,6 +235,10 @@ struct emac_instance {
u32 fifo_entry_size;
u32 mal_burst_size; /* move to MAL ? */
+ /* IAHT and GAHT filter parameterization */
+ u32 xaht_slots_shift;
+ u32 xaht_width_shift;
+
/* Descriptor management
*/
struct mal_descriptor *tx_desc;
@@ -309,6 +313,10 @@ struct emac_instance {
* Set if we need phy clock workaround for 440ep or 440gr
*/
#define EMAC_FTR_440EP_PHY_CLK_FIX 0x00000100
+/*
+ * The 405EX and 460EX contain the EMAC4SYNC core
+ */
+#define EMAC_FTR_EMAC4SYNC 0x00000200
/* Right now, we don't quite handle the always/possible masks on the
@@ -320,7 +328,8 @@ enum {
EMAC_FTRS_POSSIBLE =
#ifdef CONFIG_IBM_NEW_EMAC_EMAC4
- EMAC_FTR_EMAC4 | EMAC_FTR_HAS_NEW_STACR |
+ EMAC_FTR_EMAC4 | EMAC_FTR_EMAC4SYNC |
+ EMAC_FTR_HAS_NEW_STACR |
EMAC_FTR_STACR_OC_INVERT | EMAC_FTR_440GX_PHY_CLK_FIX |
#endif
#ifdef CONFIG_IBM_NEW_EMAC_TAH
@@ -342,6 +351,71 @@ static inline int emac_has_feature(struct emac_instance *dev,
(EMAC_FTRS_POSSIBLE & dev->features & feature);
}
+/*
+ * Various instances of the EMAC core have varying 1) number of
+ * address match slots, 2) width of the registers for handling address
+ * match slots, 3) number of registers for handling address match
+ * slots and 4) base offset for those registers.
+ *
+ * These macros and inlines handle these differences based on
+ * parameters supplied by the device structure which are, in turn,
+ * initialized based on the "compatible" entry in the device tree.
+ */
+
+#define EMAC4_XAHT_SLOTS_SHIFT 6
+#define EMAC4_XAHT_WIDTH_SHIFT 4
+
+#define EMAC4SYNC_XAHT_SLOTS_SHIFT 8
+#define EMAC4SYNC_XAHT_WIDTH_SHIFT 5
+
+#define EMAC_XAHT_SLOTS(dev) (1 << (dev)->xaht_slots_shift)
+#define EMAC_XAHT_WIDTH(dev) (1 << (dev)->xaht_width_shift)
+#define EMAC_XAHT_REGS(dev) (1 << ((dev)->xaht_slots_shift - \
+ (dev)->xaht_width_shift))
+
+#define EMAC_XAHT_CRC_TO_SLOT(dev, crc) \
+ ((EMAC_XAHT_SLOTS(dev) - 1) - \
+ ((crc) >> ((sizeof (u32) * BITS_PER_BYTE) - \
+ (dev)->xaht_slots_shift)))
+
+#define EMAC_XAHT_SLOT_TO_REG(dev, slot) \
+ ((slot) >> (dev)->xaht_width_shift)
+
+#define EMAC_XAHT_SLOT_TO_MASK(dev, slot) \
+ ((u32)(1 << (EMAC_XAHT_WIDTH(dev) - 1)) >> \
+ ((slot) & (u32)(EMAC_XAHT_WIDTH(dev) - 1)))
+
+static inline u32 *emac_xaht_base(struct emac_instance *dev)
+{
+ struct emac_regs __iomem *p = dev->emacp;
+ int offset;
+
+ /* The first IAHT entry always is the base of the block of
+ * IAHT and GAHT registers.
+ */
+ if (emac_has_feature(dev, EMAC_FTR_EMAC4SYNC))
+ offset = offsetof(struct emac_regs, u1.emac4sync.iaht1);
+ else
+ offset = offsetof(struct emac_regs, u0.emac4.iaht1);
+
+ return ((u32 *)((ptrdiff_t)p + offset));
+}
+
+static inline u32 *emac_gaht_base(struct emac_instance *dev)
+{
+ /* GAHT registers always come after an identical number of
+ * IAHT registers.
+ */
+ return (emac_xaht_base(dev) + EMAC_XAHT_REGS(dev));
+}
+
+static inline u32 *emac_iaht_base(struct emac_instance *dev)
+{
+ /* IAHT registers always come before an identical number of
+ * GAHT registers.
+ */
+ return (emac_xaht_base(dev));
+}
/* Ethtool get_regs complex data.
* We want to get not just EMAC registers, but also MAL, ZMII, RGMII, TAH
@@ -366,4 +440,11 @@ struct emac_ethtool_regs_subhdr {
u32 index;
};
+#define EMAC_ETHTOOL_REGS_VER 0
+#define EMAC_ETHTOOL_REGS_SIZE(dev) ((dev)->rsrc_regs.end - \
+ (dev)->rsrc_regs.start + 1)
+#define EMAC4_ETHTOOL_REGS_VER 1
+#define EMAC4_ETHTOOL_REGS_SIZE(dev) ((dev)->rsrc_regs.end - \
+ (dev)->rsrc_regs.start + 1)
+
#endif /* __IBM_NEWEMAC_CORE_H */
diff --git a/drivers/net/ibm_newemac/debug.c b/drivers/net/ibm_newemac/debug.c
index 86b756a..775c850 100644
--- a/drivers/net/ibm_newemac/debug.c
+++ b/drivers/net/ibm_newemac/debug.c
@@ -67,29 +67,55 @@ static void emac_desc_dump(struct emac_instance *p)
static void emac_mac_dump(struct emac_instance *dev)
{
struct emac_regs __iomem *p = dev->emacp;
+ const int xaht_regs = EMAC_XAHT_REGS(dev);
+ u32 *gaht_base = emac_gaht_base(dev);
+ u32 *iaht_base = emac_iaht_base(dev);
+ int emac4sync = emac_has_feature(dev, EMAC_FTR_EMAC4SYNC);
+ int n;
printk("** EMAC %s registers **\n"
"MR0 = 0x%08x MR1 = 0x%08x TMR0 = 0x%08x TMR1 = 0x%08x\n"
"RMR = 0x%08x ISR = 0x%08x ISER = 0x%08x\n"
- "IAR = %04x%08x VTPID = 0x%04x VTCI = 0x%04x\n"
- "IAHT: 0x%04x 0x%04x 0x%04x 0x%04x "
- "GAHT: 0x%04x 0x%04x 0x%04x 0x%04x\n"
- "LSA = %04x%08x IPGVR = 0x%04x\n"
- "STACR = 0x%08x TRTR = 0x%08x RWMR = 0x%08x\n"
- "OCTX = 0x%08x OCRX = 0x%08x IPCR = 0x%08x\n",
+ "IAR = %04x%08x VTPID = 0x%04x VTCI = 0x%04x\n",
dev->ofdev->node->full_name, in_be32(&p->mr0), in_be32(&p->mr1),
in_be32(&p->tmr0), in_be32(&p->tmr1),
in_be32(&p->rmr), in_be32(&p->isr), in_be32(&p->iser),
in_be32(&p->iahr), in_be32(&p->ialr), in_be32(&p->vtpid),
- in_be32(&p->vtci),
- in_be32(&p->iaht1), in_be32(&p->iaht2), in_be32(&p->iaht3),
- in_be32(&p->iaht4),
- in_be32(&p->gaht1), in_be32(&p->gaht2), in_be32(&p->gaht3),
- in_be32(&p->gaht4),
+ in_be32(&p->vtci)
+ );
+
+ if (emac4sync)
+ printk("MAR = %04x%08x MMAR = %04x%08x\n",
+ in_be32(&p->u0.emac4sync.mahr),
+ in_be32(&p->u0.emac4sync.malr),
+ in_be32(&p->u0.emac4sync.mmahr),
+ in_be32(&p->u0.emac4sync.mmalr)
+ );
+
+ for (n = 0; n < xaht_regs; n++)
+ printk("IAHT%02d = 0x%08x\n", n + 1, in_be32(iaht_base + n));
+
+ for (n = 0; n < xaht_regs; n++)
+ printk("GAHT%02d = 0x%08x\n", n + 1, in_be32(gaht_base + n));
+
+ printk("LSA = %04x%08x IPGVR = 0x%04x\n"
+ "STACR = 0x%08x TRTR = 0x%08x RWMR = 0x%08x\n"
+ "OCTX = 0x%08x OCRX = 0x%08x\n",
in_be32(&p->lsah), in_be32(&p->lsal), in_be32(&p->ipgvr),
in_be32(&p->stacr), in_be32(&p->trtr), in_be32(&p->rwmr),
- in_be32(&p->octx), in_be32(&p->ocrx), in_be32(&p->ipcr)
- );
+ in_be32(&p->octx), in_be32(&p->ocrx)
+ );
+
+ if (!emac4sync) {
+ printk("IPCR = 0x%08x\n",
+ in_be32(&p->u1.emac4.ipcr)
+ );
+ } else {
+ printk("REVID = 0x%08x TPC = 0x%08x\n",
+ in_be32(&p->u1.emac4sync.revid),
+ in_be32(&p->u1.emac4sync.tpc)
+ );
+ }
emac_desc_dump(dev);
}
diff --git a/drivers/net/ibm_newemac/emac.h b/drivers/net/ibm_newemac/emac.h
index 91cb096..0afc2cf 100644
--- a/drivers/net/ibm_newemac/emac.h
+++ b/drivers/net/ibm_newemac/emac.h
@@ -27,37 +27,80 @@
#include <linux/types.h>
-/* EMAC registers Write Access rules */
+/* EMAC registers Write Access rules */
struct emac_regs {
- u32 mr0; /* special */
- u32 mr1; /* Reset */
- u32 tmr0; /* special */
- u32 tmr1; /* special */
- u32 rmr; /* Reset */
- u32 isr; /* Always */
- u32 iser; /* Reset */
- u32 iahr; /* Reset, R, T */
- u32 ialr; /* Reset, R, T */
- u32 vtpid; /* Reset, R, T */
- u32 vtci; /* Reset, R, T */
- u32 ptr; /* Reset, T */
- u32 iaht1; /* Reset, R */
- u32 iaht2; /* Reset, R */
- u32 iaht3; /* Reset, R */
- u32 iaht4; /* Reset, R */
- u32 gaht1; /* Reset, R */
- u32 gaht2; /* Reset, R */
- u32 gaht3; /* Reset, R */
- u32 gaht4; /* Reset, R */
+ /* Common registers across all EMAC implementations. */
+ u32 mr0; /* Special */
+ u32 mr1; /* Reset */
+ u32 tmr0; /* Special */
+ u32 tmr1; /* Special */
+ u32 rmr; /* Reset */
+ u32 isr; /* Always */
+ u32 iser; /* Reset */
+ u32 iahr; /* Reset, R, T */
+ u32 ialr; /* Reset, R, T */
+ u32 vtpid; /* Reset, R, T */
+ u32 vtci; /* Reset, R, T */
+ u32 ptr; /* Reset, T */
+ union {
+ /* Registers unique to EMAC4 implementations */
+ struct {
+ u32 iaht1; /* Reset, R */
+ u32 iaht2; /* Reset, R */
+ u32 iaht3; /* Reset, R */
+ u32 iaht4; /* Reset, R */
+ u32 gaht1; /* Reset, R */
+ u32 gaht2; /* Reset, R */
+ u32 gaht3; /* Reset, R */
+ u32 gaht4; /* Reset, R */
+ } emac4;
+ /* Registers unique to EMAC4SYNC implementations */
+ struct {
+ u32 mahr; /* Reset, R, T */
+ u32 malr; /* Reset, R, T */
+ u32 mmahr; /* Reset, R, T */
+ u32 mmalr; /* Reset, R, T */
+ u32 rsvd0[4];
+ } emac4sync;
+ } u0;
+ /* Common registers across all EMAC implementations. */
u32 lsah;
u32 lsal;
- u32 ipgvr; /* Reset, T */
- u32 stacr; /* special */
- u32 trtr; /* special */
- u32 rwmr; /* Reset */
+ u32 ipgvr; /* Reset, T */
+ u32 stacr; /* Special */
+ u32 trtr; /* Special */
+ u32 rwmr; /* Reset */
u32 octx;
u32 ocrx;
- u32 ipcr;
+ union {
+ /* Registers unique to EMAC4 implementations */
+ struct {
+ u32 ipcr;
+ } emac4;
+ /* Registers unique to EMAC4SYNC implementations */
+ struct {
+ u32 rsvd1;
+ u32 revid;
+ u32 rsvd2[2];
+ u32 iaht1; /* Reset, R */
+ u32 iaht2; /* Reset, R */
+ u32 iaht3; /* Reset, R */
+ u32 iaht4; /* Reset, R */
+ u32 iaht5; /* Reset, R */
+ u32 iaht6; /* Reset, R */
+ u32 iaht7; /* Reset, R */
+ u32 iaht8; /* Reset, R */
+ u32 gaht1; /* Reset, R */
+ u32 gaht2; /* Reset, R */
+ u32 gaht3; /* Reset, R */
+ u32 gaht4; /* Reset, R */
+ u32 gaht5; /* Reset, R */
+ u32 gaht6; /* Reset, R */
+ u32 gaht7; /* Reset, R */
+ u32 gaht8; /* Reset, R */
+ u32 tpc; /* Reset, T */
+ } emac4sync;
+ } u1;
};
/*
@@ -73,12 +116,6 @@ struct emac_regs {
#define PHY_MODE_RTBI 7
#define PHY_MODE_SGMII 8
-
-#define EMAC_ETHTOOL_REGS_VER 0
-#define EMAC_ETHTOOL_REGS_SIZE (sizeof(struct emac_regs) - sizeof(u32))
-#define EMAC4_ETHTOOL_REGS_VER 1
-#define EMAC4_ETHTOOL_REGS_SIZE sizeof(struct emac_regs)
-
/* EMACx_MR0 */
#define EMAC_MR0_RXI 0x80000000
#define EMAC_MR0_TXI 0x40000000
^ permalink raw reply related
* Re: [PATCH v5] ibm_newemac: Parameterize EMAC Multicast Match Handling
From: Grant Erickson @ 2008-07-07 22:02 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <48727374.1010304@ru.mvista.com>
On 7/7/08 12:50 PM, Valentine Barshak wrote:
> Grant Erickson wrote:
>
> <snip>
>
>> - reg = <ef600a00 70>;
>> + reg = <ef600900 c4>;
>
> Should be reg = <ef600a00 c4>
>
> <snip>
>
>> - reg = <ef600a00 70>;
>> + reg = <ef600900 c4>;
>
> Should be reg = <ef600a00 c4>
Good catch; amended patch forthcoming.
Regards,
Grant
^ permalink raw reply
* Re: linux-next: scsi tree build failure
From: Benjamin Herrenschmidt @ 2008-07-07 22:00 UTC (permalink / raw)
To: Stephen Rothwell
Cc: James Bottomley, linuxppc-dev, linux-next, Paul Mackerras
In-Reply-To: <20080707222528.280f0b9e.sfr@canb.auug.org.au>
On Mon, 2008-07-07 at 22:25 +1000, Stephen Rothwell wrote:
> Hi James,
>
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
James, if you agree, I'll carry this commit in the powerpc tree along
with its dependencies (and your ack).
Cheers,
Ben.
> drivers/scsi/ibmvscsi/ibmvscsi.c: In function 'map_sg_data':
> drivers/scsi/ibmvscsi/ibmvscsi.c:431: error: 'FW_FEATURE_CMO' undeclared (first use in this function)
> drivers/scsi/ibmvscsi/ibmvscsi.c:431: error: (Each undeclared identifier is reported only once
> drivers/scsi/ibmvscsi/ibmvscsi.c:431: error: for each function it appears in.)
> drivers/scsi/ibmvscsi/ibmvscsi.c: In function 'ibmvscsi_queuecommand':
> drivers/scsi/ibmvscsi/ibmvscsi.c:750: error: 'FW_FEATURE_CMO' undeclared (first use in this function)
> drivers/scsi/ibmvscsi/ibmvscsi.c: In function 'send_mad_adapter_info':
> drivers/scsi/ibmvscsi/ibmvscsi.c:864: error: 'FW_FEATURE_CMO' undeclared (first use in this function)
> drivers/scsi/ibmvscsi/ibmvscsi.c: In function 'ibmvscsi_do_host_config':
> drivers/scsi/ibmvscsi/ibmvscsi.c:1412: error: 'FW_FEATURE_CMO' undeclared (first use in this function)
> drivers/scsi/ibmvscsi/ibmvscsi.c: At top level:
> drivers/scsi/ibmvscsi/ibmvscsi.c:1769: error: unknown field 'get_io_entitlement' specified in initializer
> drivers/scsi/ibmvscsi/ibmvscsi.c:1769: warning: missing braces around initializer
> drivers/scsi/ibmvscsi/ibmvscsi.c:1769: warning: (near initialization for 'ibmvscsi_driver.driver')
> drivers/scsi/ibmvscsi/ibmvscsi.c:1769: warning: initialization from incompatible pointer type
>
> Caused because commit 341b56db6804040aa9559e913865108424e3b18b ("[SCSI]
> ibmvscsi: driver enablement for CMO"), which was 15/16 in a series, has
> been merged before any of the other patches in the series. I have
> reverted that commit.
>
^ permalink raw reply
* Re: linux-next: manual merge of the powerpc tree
From: Daniel Walker @ 2008-07-07 21:13 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Bartlomiej Zolnierkiewicz, linuxppc-dev, linux-next,
Paul Mackerras, Andrew Morton
In-Reply-To: <20080707230717.10429faf.sfr@canb.auug.org.au>
On Mon, 2008-07-07 at 23:07 +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the powerpc tree got a conflict in
> drivers/macintosh/mediabay.c between commit
> 7ad963b103d3863b1161c59f3e65a435979804ed ("ide-pmac: media-bay support
> fixes (take 4)") from the ide tree and commit
> 9a24729d8aeef967eac7af71c6a69edc83d06558 ("macintosh/media bay: Convert
> semaphore to mutex") from the powerpc tree.
>
> I just applied the up/down -> mutex_unlock/mutex_lock change to the ide
> tree version.
It doesn't look like the IDE patches change the locking at all, so the
semaphore to mutex change should still be safe every with the IDE
changes.
>From an organizational prospective, I think it makes sense for the IDE
changes to go on top of the powerpc.git mediabay changes .. Since the
most current mediabay driver is in the powerpc.git AFAIK.
Daniel
^ permalink raw reply
* Re: powerpc/cell/cpufreq: add spu aware cpufreq governor
From: Dave Jones @ 2008-07-07 21:31 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Stephen Rothwell, cpufreq, linuxppc-dev, Jeremy Kerr, cbe-oss-dev
In-Reply-To: <200807071702.31240.arnd@arndb.de>
On Mon, Jul 07, 2008 at 05:02:30PM +0200, Arnd Bergmann wrote:
> From: Christian Krafft <krafft@de.ibm.com>
>
> This patch adds a cpufreq governor that takes the number of running spus
> into account. It's very similar to the ondemand governor, but not as complex.
> Instead of hacking spu load into the ondemand governor it might be easier to
> have cpufreq accepting multiple governors per cpu in future.
> Don't know if this is the right way, but it would keep the governors simple.
>
> Signed-off-by: Christian Krafft <krafft@de.ibm.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>
> Dave or other cpufreq people, can you take a look at this
> and add an Acked-by when you're happy?
It looks ok on a quick look through. I'm wondering about the multiple governors
thing though. This came up at last years power management summit, but no-one has
mentioned it since. I think it's possible we want to look at things like
this in the future, and not just for cell. I keep hearing mumblings about
future generations of x86's having dedicated coprocessors for certain tasks
that may benefit from the same thing.
> We have one prerequisite patch in the powerpc code (in spufs),
> so should it get merged through powerpc.git?
That's fine with me. Conflicts should be minimal if any at all,
I've got nothing queued up which touches that part of Kconfig/Makefile
One question I do have though, is how userspace scripts are supposed
to know they're to echo cbe_spu_governor into the relevant parts of
sysfs. I've not used anything with a cell. Do they expose the SPUs
as regular CPUs, or do they show up in a different part of the tree?
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply
* Re: [patch 0/6] Strong Access Ordering page attributes for POWER7
From: Joel Schopp @ 2008-07-07 21:23 UTC (permalink / raw)
To: Dave Kleikamp; +Cc: Andrew Morton, Linuxppc-dev, Paul Mackerras, linux-mm
In-Reply-To: <1215439540.16098.15.camel@norville.austin.ibm.com>
>> We haven't defined a user-visible feature bit (and besides, we're really
>> getting short on these...). This is becoming a bit of concern btw (the
>> running out of bits). Maybe we should start defining an AT_HWCAP2 for
>> powerpc and get libc updated to pick it up ?
>>
>
> Joel,
> Any thoughts?
Is it a required or optional feature of the 2.06 architecture spec? If it's required you could just use that. It doesn't solve the problem more generically if other archs decide to implement it though.
^ permalink raw reply
* Re: [Cbe-oss-dev] [patch 05/11] powerpc/cell: add spu aware cpufreq governor
From: Josh Boyer @ 2008-07-07 21:17 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Stephen Rothwell, cbe-oss-dev, linuxppc-dev
In-Reply-To: <200807072315.13666.arnd@arndb.de>
On Mon, 2008-07-07 at 23:15 +0200, Arnd Bergmann wrote:
> On Monday 07 July 2008, Josh Boyer wrote:
> > 0% probability of being spam.
> >
> > Full report:
> > No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.4
> > On Mon, 2008-07-07 at 16:59 +0200, Arnd Bergmann wrote:
> > > On Monday 07 July 2008, Stephen Rothwell wrote:
> > > > > +#define POLL_TIME 100000 /* in us */
> > > > ^
> > > > How about μ ?
> > >
> > > Not sure, how about µ instead? ;-)
> >
> > Erm... don't get it. You have identical characters here.
>
> That depends on the tool you use to look at it.
>
> Stephen wrote a Unicode character U+03BC from the Greek alphabet part of
> unicode, I wrote unicode character U+00B5 from the Latin-1 code page.
> In my mail client, latin-1 characters get rendered in the default font,
> but it has to change the font for less common scripts.
I thought Unicode was supposed to _improve_ stuff like that... ;)
josh
^ permalink raw reply
* Re: [PATCH] Power5,Power6 BSR driver
From: Sonny Rao @ 2008-07-07 21:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: sonnyrao, paulus, Nathan Lynch, linuxppc-dev
In-Reply-To: <1215406775.8970.57.camel@pasglop>
On Mon, Jul 07, 2008 at 02:59:35PM +1000, Benjamin Herrenschmidt wrote:
>
> > + cur->bsr_addr = reg[i * 2];
> > + cur->bsr_len = reg[i * 2 + 1];
>
> That's fishy... hand-reading of "reg" property without taking
> into account the parent's #size-cells/#address-cells... can't you
> use of_address_to_resource or something similar and carry a struct
> resource around instead ?
So, with this suggestion I looked at the resource API... not very well
documented, and I get the feeling like it's more for carving up a PCI
memory address range. In the case of the BSR, everything is already
partitioned (by hardware) so I don't see the point of using this API
here. Or am I missing something about it?
> In fact, same goes with the way you do num_bsr_devs = reg_len / 16.
>
> You should rather use -another- property of well known lenght, or
> get the #address/#size-cells of the parent and use those appropriately.
Well, I check to make sure the lengths are consistent with each other
right above there so we shouldn't walk off the end of anything, but I
will take a look at using #size-cells / #address-cells instead.
Thanks for the comments
Sonny
^ permalink raw reply
* Re: [Cbe-oss-dev] [patch 05/11] powerpc/cell: add spu aware cpufreq governor
From: Arnd Bergmann @ 2008-07-07 21:15 UTC (permalink / raw)
To: cbe-oss-dev; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <1215444942.20774.50.camel@weaponx>
On Monday 07 July 2008, Josh Boyer wrote:
> 0% probability of being spam.
>=20
> Full report:
> No, score=3D-2.6 required=3D5.0 tests=3DAWL,BAYES_00 autolearn=3Dham vers=
ion=3D3.2.4 =C2=A0
> On Mon, 2008-07-07 at 16:59 +0200, Arnd Bergmann wrote:
> > On Monday 07 July 2008, Stephen Rothwell wrote:
> > > > +#define POLL_TIME =C2=A0 =C2=A0100000 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0/* in us */
> > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 ^
> > > How about =CE=BC ?
> >=20
> > Not sure, how about =C2=B5 instead? ;-)
>=20
> Erm... don't get it. =C2=A0You have identical characters here.
That depends on the tool you use to look at it.
Stephen wrote a Unicode character U+03BC from the Greek alphabet part of
unicode, I wrote unicode character U+00B5 from the Latin-1 code page.
In my mail client, latin-1 characters get rendered in the default font,
but it has to change the font for less common scripts.
Arnd <><
^ permalink raw reply
* Re: [patch 1/6] mm: Allow architectures to define additional protection bits
From: Hugh Dickins @ 2008-07-07 21:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-mm, Andrew Morton, Dave Kleikamp, Paul Mackerras,
Linuxppc-dev
In-Reply-To: <1215409956.8970.82.camel@pasglop>
On Mon, 7 Jul 2008, Benjamin Herrenschmidt wrote:
> On Tue, 2008-07-01 at 13:54 +0000, Dave Kleikamp wrote:
> > On Tue, 2008-07-01 at 01:53 -0700, Andrew Morton wrote:
> > > On Wed, 18 Jun 2008 17:32:55 -0500 shaggy@linux.vnet.ibm.com wrote:
> > >
> > > > This patch allows architectures to define functions to deal with
> > > > additional protections bits for mmap() and mprotect().
> > > >
> > > > arch_calc_vm_prot_bits() maps additonal protection bits to vm_flags
> > > > arch_vm_get_page_prot() maps additional vm_flags to the vma's vm_page_prot
> > > > arch_validate_prot() checks for valid values of the protection bits
> > >
> > > It'd be simpler if Paul were to merge this. It doesn't conflict with
> > > any pending work.
> >
> > That works for me. Paul, I'll send you an updated patchset.
>
> Please, CC me as I'll handle this merge window.
>
> > > Acked-by: Andrew Morton <akpm@linux-foundation.org>
> > >
> > > > Note: vm_get_page_prot() is now pretty ugly.
> > >
> > > It is. But afacit it generates the same code for non-powerpc.
> > >
> > > > Suggestions?
> > >
> > > nfi. Let us rub the Hugh-summoning lamp.
>
> Didn't rub hard enough ? :-)
Sorry, Andrew got the wrong pantomime: I was appearing in Aladdin
a couple of years ago, but this year I'm the Sleeping Beauty.
(Did I hear a grumble of dissent from the back stalls?)
I don't find Dave's patch very handsome, but it gets the job done
so I'd better not carp. The ugliness in vm_get_page_prot is just
an inevitable consequence of growing beyond the traditional neat
pairing of VM_xxx flags with VM_MAYxxx flags, along with the way
that opaque pgprot_t type becomes occasionally tiresome, as such
opaque types do: I don't think there's a better way of handling
it than Dave has done.
There is a little inconsistency, that arch_calc_vm_prot_bits
and arch_vm_get_page_prot just handle the exceptional flag (SAO),
whereas arch_validate_prot handles all of them; but I don't feel
so strongly about that to suggest resubmission.
And regarding VM_SAO added to include/linux/mm.h in 3/6: although
it's odd to be weaving back and forth between arch-specific and
common, it's already the case that mman definitions and pgtable
definitions are arch-specific but mm.h common: I'm much happier
to have VM_SAO defined once there as Dave has it, than get into
arch-specific vm_flags.
Is someone going to be asking for PROT_WC shortly?
Hugh
>
> Cheers,
> Ben.
>
> > > > Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
> > > > ---
> > > >
> > > > include/linux/mman.h | 28 +++++++++++++++++++++++++++-
> > > > mm/mmap.c | 5 +++--
> > > > mm/mprotect.c | 2 +-
> > > > 3 files changed, 31 insertions(+), 4 deletions(-)
> > > >
> > > > Index: linux-2.6.26-rc5/include/linux/mman.h
> > > > ===================================================================
> > > > --- linux-2.6.26-rc5.orig/include/linux/mman.h
> > > > +++ linux-2.6.26-rc5/include/linux/mman.h
> > > > @@ -34,6 +34,31 @@ static inline void vm_unacct_memory(long
> > > > }
> > > >
> > > > /*
> > > > + * Allow architectures to handle additional protection bits
> > > > + */
> > > > +
> > > > +#ifndef arch_calc_vm_prot_bits
> > > > +#define arch_calc_vm_prot_bits(prot) 0
> > > > +#endif
> > > > +
> > > > +#ifndef arch_vm_get_page_prot
> > > > +#define arch_vm_get_page_prot(vm_flags) __pgprot(0)
> > > > +#endif
> > > > +
> > > > +#ifndef arch_validate_prot
> > > > +/*
> > > > + * This is called from mprotect(). PROT_GROWSDOWN and PROT_GROWSUP have
> > > > + * already been masked out.
> > > > + *
> > > > + * Returns true if the prot flags are valid
> > > > + */
> > > > +static inline int arch_validate_prot(unsigned long prot)
> > > > +{
> > > > + return (prot & ~(PROT_READ | PROT_WRITE | PROT_EXEC | PROT_SEM)) == 0;
> > > > +}
> > >
> > > Officially we should now have
> > >
> > > #define arch_validate_prot arch_validate_prot
> > >
> > > here.
> >
> > No problem.
> >
> > > > +#endif
> > > > +
> > > > +/*
> > > > * Optimisation macro. It is equivalent to:
> > > > * (x & bit1) ? bit2 : 0
> > > > * but this version is faster.
> > > > @@ -51,7 +76,8 @@ calc_vm_prot_bits(unsigned long prot)
> > > > {
> > > > return _calc_vm_trans(prot, PROT_READ, VM_READ ) |
> > > > _calc_vm_trans(prot, PROT_WRITE, VM_WRITE) |
> > > > - _calc_vm_trans(prot, PROT_EXEC, VM_EXEC );
> > > > + _calc_vm_trans(prot, PROT_EXEC, VM_EXEC) |
> > > > + arch_calc_vm_prot_bits(prot);
> > > > }
> > > >
> > > > /*
> > > > Index: linux-2.6.26-rc5/mm/mmap.c
> > > > ===================================================================
> > > > --- linux-2.6.26-rc5.orig/mm/mmap.c
> > > > +++ linux-2.6.26-rc5/mm/mmap.c
> > > > @@ -72,8 +72,9 @@ pgprot_t protection_map[16] = {
> > > >
> > > > pgprot_t vm_get_page_prot(unsigned long vm_flags)
> > > > {
> > > > - return protection_map[vm_flags &
> > > > - (VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)];
> > > > + return __pgprot(pgprot_val(protection_map[vm_flags &
> > > > + (VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)]) |
> > > > + pgprot_val(arch_vm_get_page_prot(vm_flags)));
> > > > }
> > > > EXPORT_SYMBOL(vm_get_page_prot);
> > > >
> > > > Index: linux-2.6.26-rc5/mm/mprotect.c
> > > > ===================================================================
> > > > --- linux-2.6.26-rc5.orig/mm/mprotect.c
> > > > +++ linux-2.6.26-rc5/mm/mprotect.c
> > > > @@ -239,7 +239,7 @@ sys_mprotect(unsigned long start, size_t
> > > > end = start + len;
> > > > if (end <= start)
> > > > return -ENOMEM;
> > > > - if (prot & ~(PROT_READ | PROT_WRITE | PROT_EXEC | PROT_SEM))
> > > > + if (!arch_validate_prot(prot))
> > > > return -EINVAL;
> > > >
> > > > reqprot = prot;
> > > >
> > > > --
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>
^ permalink raw reply
* Re: [Cbe-oss-dev] powerpc/cell/cpufreq: add spu aware cpufreq governor
From: Arnd Bergmann @ 2008-07-07 21:02 UTC (permalink / raw)
To: Eric Blossom
Cc: Dave Jones, Stephen Rothwell, cpufreq, linuxppc-dev, Jeremy Kerr,
cbe-oss-dev
In-Reply-To: <20080707171732.GC26603@comsec.com>
On Monday 07 July 2008, Eric Blossom wrote:
> I've got a basic question about this idea:
>=20
> Does it throttle only idle spus or is there a single control for
> the entire PPE + SPE complex?
There is one setting per socket, i.e. 8 SPUs and 1 PPU. In IBM speak,
that is slow mode, which would be C states in Intel speak.
There is also throttling (IBM), which can be applied to each core
seperately, and is the rough equivalent of T states in Intel terminology,
but it's almost useless for power saving purposes, so we don't do it
except for emergency (thermal overload) throttling.
> I can think of many situations in our code where at certain times we
> may only be able to keep N out of M spes occupied (because of how
> we've expressed our task-specific parallelism), but we're counting on
> the ones we're using running at full speed so that we can maintain our
> real-time throughput. =A0(Our application does real-time signal
> processing of continuously streaming data)
>=20
> Is there a way to disable the "throttling SPEs" feature short of
> configuring it out of the kernel?
By default, Linux always uses the "performance" governor, you have
to enable the spu aware governor manually to get the slow mode feature
in the first place.
Also, the idea of this code is to enter slow mode only if none of the
SPEs is constantly busy. As soon as you have a single thread hogging
one SPE, it will behave just like the performance governor, i.e.
do nothing.
Arnd <><
^ permalink raw reply
* Re: linux-next: kbuild tree build failure
From: Sam Ravnborg @ 2008-07-07 21:01 UTC (permalink / raw)
To: Roman Zippel; +Cc: Stephen Rothwell, linux-next, Paul Mackerras, linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0807071424240.6791@localhost.localdomain>
On Mon, Jul 07, 2008 at 06:13:55PM +0200, Roman Zippel wrote:
> Hi,
>
> On Mon, 7 Jul 2008, Stephen Rothwell wrote:
>
> > Hi Sam,
> >
> > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> >
> > arch/powerpc/platforms/cell/spu_base.c: In function '__spu_trap_data_seg':
> > arch/powerpc/platforms/cell/spu_base.c:194: error: duplicate case value
> > arch/powerpc/platforms/cell/spu_base.c:177: error: previously used here
>
> I guess there also has been a kconfig warning somewhere. :)
> I should have gone through all archs to test this, sorry about that.
> Luckily it's only powerpc that uses 64bit values. I would prefer to
> standardize on 32bit values, as it doesn't really make sense to expect
> from the user to input full 64bit values and it's easy to generate the
> full value in a header. This would also ease on any portability issues
> (kconfig is compiled with the host compiler not the target compiler).
>
> Below is a patch that fixes this for all archs (generated against the git
> tree). The powerpc parts need a more careful review, the rest isn't really
> critical.
>
> bye, Roman
Hi Roman.
>From your patch:
> config PINT3_ASSIGN
> hex "PINT3_ASSIGN"
> depends on PINTx_REASSIGN
> - default 0x02020303
> + default 0x2020303
But ths change actually decrease readability of the
value. Before we had 4x2 hex characters. But now we have 3x2 + 1x1.
Does this check really by us enough to warrant this?
I am aware that the check is implmented by:
+ str = strdup_type(def_sym->name, sym->type);
+ if (strcmp(str, def_sym->name)) {
+ prop_warn(prop,
+ "default for config symbol '%s'"
+ " should be %s", sym->name, str);
+ prop->expr->left.sym = sym_lookup(str, SYMBOL_CO
+ }
+ free(str);
break;
Could we soften this check a little maybe?
At least so we accept leading null's.
As for the patch in general I will await an ack from powerpc
before applying it.
Sam
^ permalink raw reply
* Re: indications for oprofile in compact mode
From: Josh Boyer @ 2008-07-07 20:37 UTC (permalink / raw)
To: torez; +Cc: linuxppc-dev
In-Reply-To: <487267D8.5010605@linux.vnet.ibm.com>
On Mon, 2008-07-07 at 14:00 -0500, torez wrote:
> plain text document attachment (Indications oprofile in compact
> mode.txt)
Please don't send patches at attachments.
> This patch allows Performance monitoring driver to detect when
> operating in PowerPC compliance mode.
And why is that needed? The reason should be included in the changelog
for the patch.
> use patch -p0 to apply.
This seems wrong. The patch looks like a -p1 to me.
You're missing your Signed-off-by line. See
Documentation/SubmittingPatches.
>
> ==========================================================================
> diff -urN linux-2.6.26-rc7.orig/arch/powerpc/kernel/cputable.c linux-2.6.26-rc7/arch/powerpc/kernel/cputable.c
> --- linux-2.6.26-rc7.orig/arch/powerpc/kernel/cputable.c 2008-07-07 11:37:40.000000000 -0500
> +++ linux-2.6.26-rc7/arch/powerpc/kernel/cputable.c 2008-07-07 11:27:09.000000000 -0500
> @@ -352,6 +352,7 @@
> .icache_bsize = 128,
> .dcache_bsize = 128,
> .machine_check = machine_check_generic,
> + .oprofile_cpu_type = "ppc64/compat-power5+",
> .platform = "power5+",
> },
> { /* Power6 */
> @@ -383,6 +384,7 @@
> .icache_bsize = 128,
> .dcache_bsize = 128,
> .machine_check = machine_check_generic,
> + .oprofile_cpu_type = "ppc64/compat-power6",
> .platform = "power6",
> },
> { /* 2.06-compliant processor, i.e. Power7 "architected" mode */
> @@ -394,6 +396,7 @@
> .icache_bsize = 128,
> .dcache_bsize = 128,
> .machine_check = machine_check_generic,
> + .oprofile_cpu_type = "ppc64/compat-power7",
> .platform = "power7",
> },
> { /* Power7 */
> @@ -1593,6 +1596,12 @@
> * from the real PVR with a new value obtained
> * using a logical PVR value, don't modify the
> * performance monitor fields.
> + * The performance monitor sub-system needs to have
> + * access to the values from the real PVR, but, at
> + * the same time it needs to be aware it may be running
> + * in compatibility mode. We we are changing the values
When ^ ?
> + * for the real PVR to those of the compatibility PVR,
> + * change the oprofile_cpu_type field as well.
You might want to change the original comment to not say "...don't
modify the performance monitor fields." Your addition explains why, but
it doesn't flow well with the original comment.
josh
^ permalink raw reply
* [PATCH] powerpc: Xilinx: PS2: Update Kconfig for new XPS PS2 driver
From: John Linn @ 2008-07-07 20:02 UTC (permalink / raw)
To: linuxppc-dev, linux-input; +Cc: dmitry.torokhov, Sadanand, John Linn
This patch is an incremental patch for the patch titled:
[V3] powerpc: Xilinx: PS2: Added new XPS PS2 driver. This patch
adds powerpc as a dependency for the driver.
Signed-off-by: Sadanand <sadanan@xilinx.com>
Signed-off-by: John Linn <john.linn@xilinx.com>
---
drivers/input/serio/Kconfig | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
index 0e62b39..683f495 100644
--- a/drivers/input/serio/Kconfig
+++ b/drivers/input/serio/Kconfig
@@ -192,7 +192,9 @@ config SERIO_RAW
config SERIO_XILINX_XPS_PS2
tristate "Xilinx XPS PS/2 Controller Support"
+ depends on PPC
help
- This driver supports XPS PS/2 IP from Xilinx EDK.
+ This driver supports XPS PS/2 IP from the Xilinx EDK on the
+ PowerPC platform.
endif
--
1.5.2.1
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.
^ permalink raw reply related
* Re: [patch 05/11] powerpc/cell: add spu aware cpufreq governor
From: Geoff Levand @ 2008-07-07 19:56 UTC (permalink / raw)
To: arnd; +Cc: Paul Mackerras, cbe-oss-dev, Christian Krafft, linuxppc-dev
In-Reply-To: <20080704190806.162475834@arndb.de>
arnd@arndb.de wrote:
> This patch adds a cpufreq governor that takes the number of running spus
> into account. It's very similar to the ondemand governor, but not as complex.
> Instead of hacking spu load into the ondemand governor it might be easier to
> have cpufreq accepting multiple governors per cpu in future.
> Don't know if this is the right way, but it would keep the governors simple.
I tried your current cell-2.6.git #cell_next branch with ps3_defconfig and
get these. ps3_defconfig has
CONFIG_CBE_CPUFREQ=m
CONFIG_CBE_CPUFREQ_SPU_GOVERNOR=m
I'm not sure if this patch is the one that introduced the problem though.
I guess we need to make an adjustment in the Kconfig. I'll be away the
rest of this week, and will look at it next week if you don't.
-Geoff
cell-2.6/arch/powerpc/platforms/cell/cbe_spu_governor.c: In function 'calc_freq':
cell-2.6/arch/powerpc/platforms/cell/cbe_spu_governor.c:53: warning: format '%d' expects type 'int', but argument 4 has type 'long unsigned int'
ERROR: ".cpufreq_register_governor" [arch/powerpc/platforms/cell/cbe_spu_governor.ko] undefined!
ERROR: ".__cpufreq_driver_target" [arch/powerpc/platforms/cell/cbe_spu_governor.ko] undefined!
ERROR: ".cpufreq_unregister_governor" [arch/powerpc/platforms/cell/cbe_spu_governor.ko] undefined!
ERROR: ".cpufreq_frequency_table_target" [arch/powerpc/platforms/cell/cbe-cpufreq.ko] undefined!
ERROR: ".cpufreq_register_driver" [arch/powerpc/platforms/cell/cbe-cpufreq.ko] undefined!
ERROR: ".cpufreq_frequency_table_verify" [arch/powerpc/platforms/cell/cbe-cpufreq.ko] undefined!
ERROR: ".cpufreq_frequency_table_get_attr" [arch/powerpc/platforms/cell/cbe-cpufreq.ko] undefined!
ERROR: ".cpufreq_notify_transition" [arch/powerpc/platforms/cell/cbe-cpufreq.ko] undefined!
ERROR: ".cpufreq_frequency_table_cpuinfo" [arch/powerpc/platforms/cell/cbe-cpufreq.ko] undefined!
ERROR: ".cbe_get_cpu_mic_tm_regs" [arch/powerpc/platforms/cell/cbe-cpufreq.ko] undefined!
ERROR: ".cbe_get_cpu_pmd_regs" [arch/powerpc/platforms/cell/cbe-cpufreq.ko] undefined!
ERROR: ".cpufreq_unregister_driver" [arch/powerpc/platforms/cell/cbe-cpufreq.ko] undefined!
ERROR: ".cpufreq_frequency_table_put_attr" [arch/powerpc/platforms/cell/cbe-cpufreq.ko] undefined!
^ permalink raw reply
* Re: azfs: initial submit of azfs, a non-buffered filesystem
From: Uli Luckas @ 2008-07-07 19:37 UTC (permalink / raw)
To: LKML; +Cc: linux-fsdevel, linuxppc-dev, Maxim Shchetynin, Arnd Bergmann
In-Reply-To: <20080707174230.63bc68cf@mercedes-benz.boeblingen.de.ibm.com>
On Monday, 7. July 2008, Maxim Shchetynin wrote:
> AZFS is a file system which keeps all files on memory mapped random
> access storage.
Hi Maxim,
do you mean "memory backed" instead of "memory mapped"?
regards
Uli
--
------- ROAD ...the handyPC Company - - - ) ) )
Uli Luckas
Software Development
ROAD GmbH
Bennigsenstr. 14 | 12159 Berlin | Germany
fon: +49 (30) 230069 - 64 | fax: +49 (30) 230069 - 69
url: www.road.de
Amtsgericht Charlottenburg: HRB 96688 B
Managing directors: Hans-Peter Constien, Hubertus von Streit
^ permalink raw reply
* Re: [PATCH v5] ibm_newemac: Parameterize EMAC Multicast Match Handling
From: Valentine Barshak @ 2008-07-07 19:50 UTC (permalink / raw)
To: Grant Erickson; +Cc: linuxppc-dev, sr
In-Reply-To: <1215387012-6464-1-git-send-email-gerickson@nuovations.com>
Grant Erickson wrote:
<snip>
> index 48c9a6e..799592d 100644
> --- a/arch/powerpc/boot/dts/kilauea.dts
> +++ b/arch/powerpc/boot/dts/kilauea.dts
> @@ -205,7 +205,7 @@
> EMAC0: ethernet@ef600900 {
> linux,network-index = <0>;
> device_type = "network";
> - compatible = "ibm,emac-405ex", "ibm,emac4";
> + compatible = "ibm,emac-405ex", "ibm,emac4sync";
> interrupt-parent = <&EMAC0>;
> interrupts = <0 1>;
> #interrupt-cells = <1>;
> @@ -213,7 +213,7 @@
> #size-cells = <0>;
> interrupt-map = </*Status*/ 0 &UIC0 18 4
> /*Wake*/ 1 &UIC1 1d 4>;
> - reg = <ef600900 70>;
> + reg = <ef600900 c4>;
> local-mac-address = [000000000000]; /* Filled in by U-Boot */
> mal-device = <&MAL0>;
> mal-tx-channel = <0>;
> @@ -233,7 +233,7 @@
> EMAC1: ethernet@ef600a00 {
> linux,network-index = <1>;
> device_type = "network";
> - compatible = "ibm,emac-405ex", "ibm,emac4";
> + compatible = "ibm,emac-405ex", "ibm,emac4sync";
> interrupt-parent = <&EMAC1>;
> interrupts = <0 1>;
> #interrupt-cells = <1>;
> @@ -241,7 +241,7 @@
> #size-cells = <0>;
> interrupt-map = </*Status*/ 0 &UIC0 19 4
> /*Wake*/ 1 &UIC1 1f 4>;
> - reg = <ef600a00 70>;
> + reg = <ef600900 c4>;
Should be reg = <ef600a00 c4>
<snip>
> --- a/arch/powerpc/boot/dts/makalu.dts
> +++ b/arch/powerpc/boot/dts/makalu.dts
> @@ -205,7 +205,7 @@
> EMAC0: ethernet@ef600900 {
> linux,network-index = <0>;
> device_type = "network";
> - compatible = "ibm,emac-405ex", "ibm,emac4";
> + compatible = "ibm,emac-405ex", "ibm,emac4sync";
> interrupt-parent = <&EMAC0>;
> interrupts = <0 1>;
> #interrupt-cells = <1>;
> @@ -213,7 +213,7 @@
> #size-cells = <0>;
> interrupt-map = </*Status*/ 0 &UIC0 18 4
> /*Wake*/ 1 &UIC1 1d 4>;
> - reg = <ef600900 70>;
> + reg = <ef600900 c4>;
> local-mac-address = [000000000000]; /* Filled in by U-Boot */
> mal-device = <&MAL0>;
> mal-tx-channel = <0>;
> @@ -233,7 +233,7 @@
> EMAC1: ethernet@ef600a00 {
> linux,network-index = <1>;
> device_type = "network";
> - compatible = "ibm,emac-405ex", "ibm,emac4";
> + compatible = "ibm,emac-405ex", "ibm,emac4sync";
> interrupt-parent = <&EMAC1>;
> interrupts = <0 1>;
> #interrupt-cells = <1>;
> @@ -241,7 +241,7 @@
> #size-cells = <0>;
> interrupt-map = </*Status*/ 0 &UIC0 19 4
> /*Wake*/ 1 &UIC1 1f 4>;
> - reg = <ef600a00 70>;
> + reg = <ef600900 c4>;
Should be reg = <ef600a00 c4>
Thanks,
Valentine.
^ permalink raw reply
* Re: Deputy maintainer for powerpc
From: Josh Boyer @ 2008-07-07 19:25 UTC (permalink / raw)
To: Kumar Gala
Cc: lkml List, linuxppc-dev list, Paul Mackerras, Andrew Morton,
Torvalds, Linus
In-Reply-To: <155B1079-39C4-4D15-B886-F904C424BC8C@kernel.crashing.org>
On Mon, 7 Jul 2008 09:44:31 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Jul 4, 2008, at 1:02 AM, Paul Mackerras wrote:
>
> > I'm going to be on vacation for the next two weeks, and it looks
> > highly likely that Linus will open the 2.6.27 merge window during that
> > time, so I'm appointing Ben Herrenschmidt as my deputy maintainer.
> > During the next two weeks, he'll be the person collecting together any
> > further powerpc-related commits that need to go upstream, and sending
> > pull requests to Linus as necessary.
> >
> > This is the start of a longer-term transition which will ultimately
> > result in me handing over the powerpc architecture maintainership to
> > Ben. Because of various work commitments, this will be a gradual
> > transition taking probably around 6 months.
> >
> > Paul.
>
> Ben, Do you have a tree that you'll be using to collect things in?
I hope it's the same tree for this merge window.
In the future, I hope the semantics of the various branches of the
new tree either stays the same, or comes with a detailed description of
what branch means what (assuming there is a new tree at some point).
josh
^ permalink raw reply
* flash driver
From: liran raz @ 2008-07-07 19:16 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2029 bytes --]
hi,
I'm trying to setup the kernel's (linux-2.6.24) flash driver.
Our flash is combined of 2 chips of S29GLN (spanion)
2 X 16 bits data chips connected to 32 bits data bus.
This flash is compatible with the AMD CFI.
I've configured the kernel to:
1. Detect flash chips by common flash interface (CFI) probe.
2. Support for AMD/Fujitsu flash chips
(The flash starts at absolute address 0xfc000000
& size is 0x4000000)
When the kernel starts I see the messages attached below,
which I think indicate that something might be wrong with
the detection of the flsah.
1. Is this correct ? - something is wrong with the flash detection?
2. Which device I need to use in order to read/write to
the flash? (I don't see any /flash device under /dev/ only:
/dev/mtd0 .. /dev/mtd3 & /dev/mtdblock0 .. /dev/mtdblock3)
Debug messages (DEBUG_CFI is defined):
physmap platform flash device: 04000000 at fc000000
Number of erase regions: 1
Primary Vendor Command Set: 0002 (AMD/Fujitsu Standard)
Primary Algorithm Table at 0040
Alternative Vendor Command Set: 0000 (None)
No Alternate Algorithm Table
Vcc Minimum: 2.7 V
Vcc Maximum: 3.6 V
No Vpp line
Typical byte/word write timeout: 128 \uffffs
Maximum byte/word write timeout: 1024 \uffffs
Typical full buffer write timeout: 128 \uffffs
Maximum full buffer write timeout: 4096 \uffffs
Typical block erase timeout: 1024 ms
Maximum block erase timeout: 16384 ms
Chip erase not supported
Device size: 0x2000000 bytes (32 MiB)
Flash Device Interface description: 0x0002
- supports x8 and x16 via BYTE# with asynchronous interface
Max. bytes in buffer write: 0x20
Number of Erase Block Regions: 1
Erase Region #0: BlockSize 0x20000 bytes, 256 blocks
physmap-flash.0: Found 2 x16 devices at 0x0 in 32-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
physmap-flash.0: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
of-flash: probe of fc000000.flash failed with error -16
Thanks,
Liran.
[-- Attachment #2: Type: text/html, Size: 2242 bytes --]
^ permalink raw reply
* Re: [patch 07/11] powerpc/dma: implement new dma_*map*_attrs() interfaces
From: Geoff Levand @ 2008-07-07 19:15 UTC (permalink / raw)
To: benh; +Cc: Mark Nelson, linuxppc-dev, Paul Mackerras, cbe-oss-dev
In-Reply-To: <1215408473.8970.69.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Fri, 2008-07-04 at 21:05 +0200, arnd@arndb.de wrote:
>> plain text document attachment
>> (0007-powerpc-dma-implement-new-dma_-map-_attrs-interfa.patch)
>> Update powerpc to use the new dma_*map*_attrs() interfaces. In doing so
>> update struct dma_mapping_ops to accept a struct dma_attrs and propagate
>> these changes through to all users of the code (generic IOMMU and the
>> 64bit DMA code, and the iseries and ps3 platform code).
>>
>> The old dma_*map_*() interfaces are reimplemented as calls to the
>> corresponding new interfaces.
>
> Geoff, I think the PS3 bits in this patch are ok but I'd like
> you to double-check and send your ack if you think they are.
I tested on PS3 with ps3_defconfig, and it works OK.
Acked-by: Geoff Levand <geoffrey.levand@am.sony.com>
>> Signed-off-by: Mark Nelson <markn@au1.ibm.com>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> ---
>> arch/powerpc/Kconfig | 1 +
>> arch/powerpc/kernel/dma_64.c | 34 ++++++---
>> arch/powerpc/kernel/ibmebus.c | 12 ++-
>> arch/powerpc/kernel/iommu.c | 11 ++-
>> arch/powerpc/platforms/iseries/iommu.c | 4 +-
>> arch/powerpc/platforms/ps3/system-bus.c | 17 +++--
>> include/asm-powerpc/dma-mapping.h | 116 +++++++++++++++++++++++--------
>> include/asm-powerpc/iommu.h | 12 ++-
>> 8 files changed, 144 insertions(+), 63 deletions(-)
^ permalink raw reply
* indications for oprofile in compact mode
From: torez @ 2008-07-07 19:00 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: Indications oprofile in compact mode.txt --]
[-- Type: text/plain, Size: 2041 bytes --]
This patch allows Performance monitoring driver to detect when
operating in PowerPC compliance mode.
use patch -p0 to apply.
==========================================================================
diff -urN linux-2.6.26-rc7.orig/arch/powerpc/kernel/cputable.c linux-2.6.26-rc7/arch/powerpc/kernel/cputable.c
--- linux-2.6.26-rc7.orig/arch/powerpc/kernel/cputable.c 2008-07-07 11:37:40.000000000 -0500
+++ linux-2.6.26-rc7/arch/powerpc/kernel/cputable.c 2008-07-07 11:27:09.000000000 -0500
@@ -352,6 +352,7 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.machine_check = machine_check_generic,
+ .oprofile_cpu_type = "ppc64/compat-power5+",
.platform = "power5+",
},
{ /* Power6 */
@@ -383,6 +384,7 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.machine_check = machine_check_generic,
+ .oprofile_cpu_type = "ppc64/compat-power6",
.platform = "power6",
},
{ /* 2.06-compliant processor, i.e. Power7 "architected" mode */
@@ -394,6 +396,7 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.machine_check = machine_check_generic,
+ .oprofile_cpu_type = "ppc64/compat-power7",
.platform = "power7",
},
{ /* Power7 */
@@ -1593,6 +1596,12 @@
* from the real PVR with a new value obtained
* using a logical PVR value, don't modify the
* performance monitor fields.
+ * The performance monitor sub-system needs to have
+ * access to the values from the real PVR, but, at
+ * the same time it needs to be aware it may be running
+ * in compatibility mode. We we are changing the values
+ * for the real PVR to those of the compatibility PVR,
+ * change the oprofile_cpu_type field as well.
*/
if (t->num_pmcs && !s->num_pmcs) {
t->cpu_name = s->cpu_name;
@@ -1603,6 +1612,8 @@
t->cpu_setup = s->cpu_setup;
t->cpu_restore = s->cpu_restore;
t->platform = s->platform;
+ if (t->oprofile_cpu_type == NULL)
+ t->oprofile_cpu_type = s->oprofile_cpu_type;
} else
*t = *s;
*PTRRELOC(&cur_cpu_spec) = &the_cpu_spec;
^ permalink raw reply
* Re: [PATCH] Add MPC5200B base board mvBC-P
From: Jon Smirl @ 2008-07-07 18:51 UTC (permalink / raw)
To: Grant Likely; +Cc: linux-ppc list, Andre Schwarz, David Gibson
In-Reply-To: <fa686aa40807070712x77ff7aben4cf51731bb4f5985@mail.gmail.com>
On 7/7/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Mon, Jul 7, 2008 at 1:49 AM, Andre Schwarz
> <andre.schwarz@matrix-vision.de> wrote:
> > David,
> >
> > thanks - removed "device_type" from the DMA controller.
> >
> > Which nodes actually require "device_type" and which don't ?
> >
> > Is there some general rule ?
>
>
> Segher, David;
>
> In OF, what is the purpose of device_type? From what I understand
> right now, each value of device_type claims a software interface that
> the device supports. So for example, device_type = "serial" means
> that firmware supports using the device as a serial port, correct?
> So, similarly, if OF did not have a driver for the device, then the
> presence a device_type property would be a bug, right?
>
> Does device_type indicated any other information other than firmware
> driver interface?
>
> I had an epiphany about device_type this weekend (and by epiphany, I
> mean realizing my own stupidity). If I'm correct about the above
> questions, then that would mean it is *always* a bug to have a
> device_type property in .dts file because there is no firmware
> interface. So, it seems to me that we shouldn't just be eliminating
> undefined device_type values, but also eliminate the ones that are
> defined in OF because .dts users do not support the firmware driver
> interface.
>
> Am I correct?
>
> The only situation where I can see it being appropriate to specify
> device_type is to work around older bindings that are ambiguous with
> their other properties.
I experimented with this on my own trees.
device_type = "serial";
Is current required on the boot console or it will disappear.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [Libhugetlbfs-devel] libbugetlbfs: Test case for powerpc huge_ptep_set_wrprotect() bug
From: Nishanth Aravamudan @ 2008-07-07 18:48 UTC (permalink / raw)
To: libhugetlbfs-devel, linuxppc-dev
In-Reply-To: <20080707071955.GA27709@yookeroo.seuss>
On 07.07.2008 [17:19:55 +1000], David Gibson wrote:
> Until very recently (in fact, even now in mainline) powerpc kernels
> had a bug in huge_ptep_set_wrprotect() which meant the 'huge' flag was
> not passed down to pte_update() and hpte_need_flush(). This meant the
> hash ptes for hugepages would not be correctly flushed on fork(),
> allowing the parent to pollute the child's mapping after the fork().
>
> This patch adds a testcase to libhugetlbfs for this behaviour, also
> doing some other checking of the COW semantics over a fork().
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied, thanks,
Nish
--
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH] [V3] powerpc: Xilinx: PS2: Added new XPS PS2 driver
From: Dmitry Torokhov @ 2008-07-07 18:45 UTC (permalink / raw)
To: John Linn; +Cc: Sadanand Mutyala, linux-input, linuxppc-dev
In-Reply-To: <20080707182711.7F7E012D0061@mail133-dub.bigfish.com>
On Mon, Jul 07, 2008 at 12:27:09PM -0600, John Linn wrote:
> Thanks Dmitry, appreciate the help.
>
> Powerpc dependencies in the Kconfig sound right. Sorry for not thinking
> that thru well across all architectures.
>
> Do you want me to spin the patch again?
>
Please send me incremental patch that implements proper Kconfig
dependencies and I will fold it all together on my side.
Thanks.
--
Dmitry
^ 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