* 30 bits DMA and ppc
From: Benjamin Herrenschmidt @ 2005-10-30 4:03 UTC (permalink / raw)
To: bcm43xx-dev; +Cc: linuxppc-dev list
Hi !
I was thinking about the best ways to deal with the 30 bits limitation
of the Broadcom chips for DMA on PowerMacs. No emergency there, we still
need to have a working bcm43xx driver and the developpement can be done
with <= 1Gb of RAM, but it will have to be addressed at one point as we
are getting closer to something that is useable :)
I will not implement something like GFP_DMA, I think. It just sucks too
much...
However, what I can do is have the architecture code reserve a pool of
memory at boot if the machine main RAM is bigger than 1Gb, to use for
bounce-buffering. On the G5 with more than 2Gb, this is even easier
since I already have to blow away a 16Mb page for use by the IOMMU, but
the IOMMU only uses 2Mb in there, so I have about 14Mb that I could
re-use for that. On 32 bits machine, I can just reserve something early
during boot.
Now, how to actually make use of that pool. One way is to hack something
specific inside the bcm43xx driver. The pool can then be easily cut in
regions: the descriptor rings buffers, and 2 pools, one for Rx and one
for Tx. The allocation inside of those pools can be done as simple ring
buffer too due to the inherently ordered processing of packets.
However, the above would require arch specific hacks, and would only
work for one card in the system (too bad if you plug a cardbus one).
Another possibility that might be more interesting is to use swiotlb.
This is a somewhat generic bounce-buffering implementation of the DMA
mapping routines that is used by ia64 and x86_64 when no IOMMU is
available. It will automatically do nothing if the address fits the DMA
mask so it shouldn't add much overhead to other drivers and would "make
things work" transparently. In addition, for G5s with more than 2Gb of
RAM (which have an iommu), I could modify the iommu code to take into
account the DMA mask when allocating DMA virtual space. (The later would
have a slight risk of failure, but I doubt it will happen in practice,
as it would mean one has more than 1Gb of pending DMA at a given point
in time).
I tend to prefer the later solution ...
Anybody with strong disagreement with using swiotlb on PPC ? The choice
of wether to allocate RAM for it at boot and how much can be done per
platform and based on the amount of real RAM (for example, on pmac, I
suppose I would only allocate some if the physical RAM is more than 1Gb
since that's the limitation of those Broadcom chips and I don't see any
other potential user for it).
Besides, it may end up being useful for some crappy embedded stuffs (no
name here :)
Ben.
^ permalink raw reply
* ayuda
From: Doug Carrillo @ 2005-10-30 0:26 UTC (permalink / raw)
To: linuxppc-dev
Hola, tengo una G3 PPC, deseo instalar linux
Cual distribucion me sirve?
_________________________________________________________________
MSN Amor: busca tu ½ naranja http://latam.msn.com/amor/
^ permalink raw reply
* Re: use of phy_connect() in drivers/net/gianfar.c ?
From: Matthew McClintock @ 2005-10-30 0:38 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Jeff Garzik, linuxppc-dev
In-Reply-To: <20051029204032.BA111353A42@atlas.denx.de>
Hello Wolfgang,
As far as I understand there are patches in the -mm tree with contain
the updates for the Gianfar driver. The issue is due to a
synchronization issue with the new PHY abstraction layer that was added.
I know Andy will not be back at his computer until Monday, you can wait
until then or look for the patch in the -mm tree.
Regards,
Matthew
On Sat, 2005-10-29 at 13:40 -0700, Wolfgang Denk wrote:
> Hello,
>
> this commit in the 2.6.14 tree is breaking drivers/net/gianfar.c for
> me:
>
> Commit: bb40dcbb0fcebe1df08ba261483fcc38b307d063
> Author: Andy Fleming <afleming@freescale.com> 2005-09-24
> 04:54:21
> Committer: Jeff Garzik <jgarzik@pobox.com> 2005-09-24
> 04:54:21
> Parent: acc4b985a6f8f22a0e826692894a4af234764001 ([PATCH]
> orinoco: Bump version to 0.15rc3.)
> Child: 8cee0cd5bec53b78dd3c43a73b27821a688133e6 ([netdrvr]
> delete CONFIG_PHYCONTROL)
>
> [netdrvr gianfar] use new phy layer
>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
> Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
>
> I get:
>
> drivers/net/gianfar.c: In function `init_phy':
> drivers/net/gianfar.c:410: error: structure has no member named
> `bus_id'
>
>
> Am I missing something?
>
> Best regards,
>
> Wolfgang Denk
>
> --
> Software Engineering: Embedded and Realtime Systems, Embedded Linux
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> In C we had to code our own bugs, in C++ we can inherit them.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH 1/3] PPC 44x EMAC driver: add 440SPe support
From: Jeff Garzik @ 2005-10-29 22:07 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: netdev, linuxppc-embedded
In-Reply-To: <20051029194314.GB1865@gate.ebshome.net>
applied 1-3
^ permalink raw reply
* use of phy_connect() in drivers/net/gianfar.c ?
From: Wolfgang Denk @ 2005-10-29 20:40 UTC (permalink / raw)
To: Andy Fleming, Jeff Garzik; +Cc: linuxppc-dev
Hello,
this commit in the 2.6.14 tree is breaking drivers/net/gianfar.c for
me:
Commit: bb40dcbb0fcebe1df08ba261483fcc38b307d063
Author: Andy Fleming <afleming@freescale.com> 2005-09-24 04:54:21
Committer: Jeff Garzik <jgarzik@pobox.com> 2005-09-24 04:54:21
Parent: acc4b985a6f8f22a0e826692894a4af234764001 ([PATCH] orinoco: Bump version to 0.15rc3.)
Child: 8cee0cd5bec53b78dd3c43a73b27821a688133e6 ([netdrvr] delete CONFIG_PHYCONTROL)
[netdrvr gianfar] use new phy layer
Signed-off-by: Andy Fleming <afleming@freescale.com>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
I get:
drivers/net/gianfar.c: In function `init_phy':
drivers/net/gianfar.c:410: error: structure has no member named `bus_id'
Am I missing something?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
In C we had to code our own bugs, in C++ we can inherit them.
^ permalink raw reply
* [PATCH 3/3] PPC 4xx EMAC driver: fix VSC8201 PHY initialization
From: Eugene Surovegin @ 2005-10-29 19:47 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linuxppc-embedded
* MII registers must override strap pins
* disable "echo" mode to make 10/HDX work (Franz Sirl)
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
---
drivers/net/ibm_emac/ibm_emac_phy.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ibm_emac/ibm_emac_phy.c b/drivers/net/ibm_emac/ibm_emac_phy.c
index a27e49c..67935dd 100644
--- a/drivers/net/ibm_emac/ibm_emac_phy.c
+++ b/drivers/net/ibm_emac/ibm_emac_phy.c
@@ -236,12 +236,16 @@ static struct mii_phy_def genmii_phy_def
};
/* CIS8201 */
+#define MII_CIS8201_10BTCSR 0x16
+#define TENBTCSR_ECHO_DISABLE 0x2000
#define MII_CIS8201_EPCR 0x17
#define EPCR_MODE_MASK 0x3000
#define EPCR_GMII_MODE 0x0000
#define EPCR_RGMII_MODE 0x1000
#define EPCR_TBI_MODE 0x2000
#define EPCR_RTBI_MODE 0x3000
+#define MII_CIS8201_ACSR 0x1c
+#define ACSR_PIN_PRIO_SELECT 0x0004
static int cis8201_init(struct mii_phy *phy)
{
@@ -269,6 +273,14 @@ static int cis8201_init(struct mii_phy *
}
phy_write(phy, MII_CIS8201_EPCR, epcr);
+
+ /* MII regs override strap pins */
+ phy_write(phy, MII_CIS8201_ACSR,
+ phy_read(phy, MII_CIS8201_ACSR) | ACSR_PIN_PRIO_SELECT);
+
+ /* Disable TX_EN -> CRS echo mode, otherwise 10/HDX doesn't work */
+ phy_write(phy, MII_CIS8201_10BTCSR,
+ phy_read(phy, MII_CIS8201_10BTCSR) | TENBTCSR_ECHO_DISABLE);
return 0;
}
^ permalink raw reply related
* [PATCH 2/3] PPC 44x EMAC driver: add 440GR support
From: Eugene Surovegin @ 2005-10-29 19:45 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, sr, linuxppc-embedded
Add PowerPC 440GR support
Signed-off-by: Stefan Roese <sr@denx.de>
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
---
drivers/net/Kconfig | 2 +-
drivers/net/ibm_emac/ibm_emac.h | 3 ++-
drivers/net/ibm_emac/ibm_emac_core.c | 7 ++++---
drivers/net/ibm_emac/ibm_emac_mal.h | 2 +-
4 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 6d4f9ce..97760c1 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1203,7 +1203,7 @@ config IBM_EMAC_RX_SKB_HEADROOM
config IBM_EMAC_PHY_RX_CLK_FIX
bool "PHY Rx clock workaround"
- depends on IBM_EMAC && (405EP || 440GX || 440EP)
+ depends on IBM_EMAC && (405EP || 440GX || 440EP || 440GR)
help
Enable this if EMAC attached to a PHY which doesn't generate
RX clock if there is no link, if this is the case, you will
diff --git a/drivers/net/ibm_emac/ibm_emac.h b/drivers/net/ibm_emac/ibm_emac.h
index d3166da..644edbf 100644
--- a/drivers/net/ibm_emac/ibm_emac.h
+++ b/drivers/net/ibm_emac/ibm_emac.h
@@ -26,7 +26,8 @@
/* This is a simple check to prevent use of this driver on non-tested SoCs */
#if !defined(CONFIG_405GP) && !defined(CONFIG_405GPR) && !defined(CONFIG_405EP) && \
!defined(CONFIG_440GP) && !defined(CONFIG_440GX) && !defined(CONFIG_440SP) && \
- !defined(CONFIG_440EP) && !defined(CONFIG_NP405H) && !defined(CONFIG_440SPE)
+ !defined(CONFIG_440EP) && !defined(CONFIG_NP405H) && !defined(CONFIG_440SPE) && \
+ !defined(CONFIG_440GR)
#error "Unknown SoC. Please, check chip user manual and make sure EMAC defines are OK"
#endif
diff --git a/drivers/net/ibm_emac/ibm_emac_core.c b/drivers/net/ibm_emac/ibm_emac_core.c
index 48239e1..eb7d694 100644
--- a/drivers/net/ibm_emac/ibm_emac_core.c
+++ b/drivers/net/ibm_emac/ibm_emac_core.c
@@ -87,10 +87,11 @@ MODULE_LICENSE("GPL");
*/
static u32 busy_phy_map;
-#if defined(CONFIG_IBM_EMAC_PHY_RX_CLK_FIX) && (defined(CONFIG_405EP) || defined(CONFIG_440EP))
+#if defined(CONFIG_IBM_EMAC_PHY_RX_CLK_FIX) && \
+ (defined(CONFIG_405EP) || defined(CONFIG_440EP) || defined(CONFIG_440GR))
/* 405EP has "EMAC to PHY Control Register" (CPC0_EPCTL) which can help us
* with PHY RX clock problem.
- * 440EP has more sane SDR0_MFR register implementation than 440GX, which
+ * 440EP/440GR has more sane SDR0_MFR register implementation than 440GX, which
* also allows controlling each EMAC clock
*/
static inline void EMAC_RX_CLK_TX(int idx)
@@ -100,7 +101,7 @@ static inline void EMAC_RX_CLK_TX(int id
#if defined(CONFIG_405EP)
mtdcr(0xf3, mfdcr(0xf3) | (1 << idx));
-#else /* CONFIG_440EP */
+#else /* CONFIG_440EP || CONFIG_440GR */
SDR_WRITE(DCRN_SDR_MFR, SDR_READ(DCRN_SDR_MFR) | (0x08000000 >> idx));
#endif
diff --git a/drivers/net/ibm_emac/ibm_emac_mal.h b/drivers/net/ibm_emac/ibm_emac_mal.h
index fb6dfe1..2a2d3b2 100644
--- a/drivers/net/ibm_emac/ibm_emac_mal.h
+++ b/drivers/net/ibm_emac/ibm_emac_mal.h
@@ -32,7 +32,7 @@
* reflect the fact that 40x and 44x have slightly different MALs. --ebs
*/
#if defined(CONFIG_405GP) || defined(CONFIG_405GPR) || defined(CONFIG_405EP) || \
- defined(CONFIG_440EP) || defined(CONFIG_NP405H)
+ defined(CONFIG_440EP) || defined(CONFIG_440GR) || defined(CONFIG_NP405H)
#define MAL_VERSION 1
#elif defined(CONFIG_440GP) || defined(CONFIG_440GX) || defined(CONFIG_440SP) || \
defined(CONFIG_440SPE)
^ permalink raw reply related
* [PATCH 1/3] PPC 44x EMAC driver: add 440SPe support
From: Eugene Surovegin @ 2005-10-29 19:43 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linuxppc-embedded
For some reason, the hardware designers made the polarity of one bit
in the 440SPe's PHY interface register the opposite of all other PPC
440 chips. To handle this, abstract our access to this bit and do the
right thing based on the configured CPU type.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
---
drivers/net/ibm_emac/ibm_emac.h | 21 ++++++++++++++++++++-
drivers/net/ibm_emac/ibm_emac_core.c | 13 +++++++------
drivers/net/ibm_emac/ibm_emac_mal.h | 3 ++-
3 files changed, 29 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ibm_emac/ibm_emac.h b/drivers/net/ibm_emac/ibm_emac.h
index 28c476f..d3166da 100644
--- a/drivers/net/ibm_emac/ibm_emac.h
+++ b/drivers/net/ibm_emac/ibm_emac.h
@@ -26,7 +26,7 @@
/* This is a simple check to prevent use of this driver on non-tested SoCs */
#if !defined(CONFIG_405GP) && !defined(CONFIG_405GPR) && !defined(CONFIG_405EP) && \
!defined(CONFIG_440GP) && !defined(CONFIG_440GX) && !defined(CONFIG_440SP) && \
- !defined(CONFIG_440EP) && !defined(CONFIG_NP405H)
+ !defined(CONFIG_440EP) && !defined(CONFIG_NP405H) && !defined(CONFIG_440SPE)
#error "Unknown SoC. Please, check chip user manual and make sure EMAC defines are OK"
#endif
@@ -246,6 +246,25 @@ struct emac_regs {
#define EMAC_STACR_PCDA_SHIFT 5
#define EMAC_STACR_PRA_MASK 0x1f
+/*
+ * For the 440SPe, AMCC inexplicably changed the polarity of
+ * the "operation complete" bit in the MII control register.
+ */
+#if defined(CONFIG_440SPE)
+static inline int emac_phy_done(u32 stacr)
+{
+ return !(stacr & EMAC_STACR_OC);
+};
+#define EMAC_STACR_START EMAC_STACR_OC
+
+#else /* CONFIG_440SPE */
+static inline int emac_phy_done(u32 stacr)
+{
+ return stacr & EMAC_STACR_OC;
+};
+#define EMAC_STACR_START 0
+#endif /* !CONFIG_440SPE */
+
/* EMACx_TRTR */
#if !defined(CONFIG_IBM_EMAC4)
#define EMAC_TRTR_SHIFT 27
diff --git a/drivers/net/ibm_emac/ibm_emac_core.c b/drivers/net/ibm_emac/ibm_emac_core.c
index 943fbd1..48239e1 100644
--- a/drivers/net/ibm_emac/ibm_emac_core.c
+++ b/drivers/net/ibm_emac/ibm_emac_core.c
@@ -546,7 +546,7 @@ static int __emac_mdio_read(struct ocp_e
/* Wait for management interface to become idle */
n = 10;
- while (!(in_be32(&p->stacr) & EMAC_STACR_OC)) {
+ while (!emac_phy_done(in_be32(&p->stacr))) {
udelay(1);
if (!--n)
goto to;
@@ -556,11 +556,12 @@ static int __emac_mdio_read(struct ocp_e
out_be32(&p->stacr,
EMAC_STACR_BASE(emac_opb_mhz()) | EMAC_STACR_STAC_READ |
(reg & EMAC_STACR_PRA_MASK)
- | ((id & EMAC_STACR_PCDA_MASK) << EMAC_STACR_PCDA_SHIFT));
+ | ((id & EMAC_STACR_PCDA_MASK) << EMAC_STACR_PCDA_SHIFT)
+ | EMAC_STACR_START);
/* Wait for read to complete */
n = 100;
- while (!((r = in_be32(&p->stacr)) & EMAC_STACR_OC)) {
+ while (!emac_phy_done(r = in_be32(&p->stacr))) {
udelay(1);
if (!--n)
goto to;
@@ -594,7 +595,7 @@ static void __emac_mdio_write(struct ocp
/* Wait for management interface to be idle */
n = 10;
- while (!(in_be32(&p->stacr) & EMAC_STACR_OC)) {
+ while (!emac_phy_done(in_be32(&p->stacr))) {
udelay(1);
if (!--n)
goto to;
@@ -605,11 +606,11 @@ static void __emac_mdio_write(struct ocp
EMAC_STACR_BASE(emac_opb_mhz()) | EMAC_STACR_STAC_WRITE |
(reg & EMAC_STACR_PRA_MASK) |
((id & EMAC_STACR_PCDA_MASK) << EMAC_STACR_PCDA_SHIFT) |
- (val << EMAC_STACR_PHYD_SHIFT));
+ (val << EMAC_STACR_PHYD_SHIFT) | EMAC_STACR_START);
/* Wait for write to complete */
n = 100;
- while (!(in_be32(&p->stacr) & EMAC_STACR_OC)) {
+ while (!emac_phy_done(in_be32(&p->stacr))) {
udelay(1);
if (!--n)
goto to;
diff --git a/drivers/net/ibm_emac/ibm_emac_mal.h b/drivers/net/ibm_emac/ibm_emac_mal.h
index 15b0bda..fb6dfe1 100644
--- a/drivers/net/ibm_emac/ibm_emac_mal.h
+++ b/drivers/net/ibm_emac/ibm_emac_mal.h
@@ -34,7 +34,8 @@
#if defined(CONFIG_405GP) || defined(CONFIG_405GPR) || defined(CONFIG_405EP) || \
defined(CONFIG_440EP) || defined(CONFIG_NP405H)
#define MAL_VERSION 1
-#elif defined(CONFIG_440GP) || defined(CONFIG_440GX) || defined(CONFIG_440SP)
+#elif defined(CONFIG_440GP) || defined(CONFIG_440GX) || defined(CONFIG_440SP) || \
+ defined(CONFIG_440SPE)
#define MAL_VERSION 2
#else
#error "Unknown SoC, please check chip manual and choose MAL 'version'"
^ permalink raw reply related
* Re: Patches for 2.6.15
From: galak @ 2005-10-29 12:55 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Kumar Gala, linuxppc64-dev
In-Reply-To: <20051029180755.22de749b.sfr@canb.auug.org.au>
On Sat, 29 Oct 2005, Stephen Rothwell wrote:
> On Fri, 28 Oct 2005 13:49:26 -0500 Kumar Gala <kumar.gala@freescale.com> wrote:
> >
> > Can you merge this in:
> >
> > http://patchwork.ozlabs.org/linuxppc/patch?id=2931
>
> I can't find any use of mpc85xx_show_cpuinfo. Is there something subtle here?
No, you are correct. This was a bogus decleration before. I will kill
it and resend the patch.
- kumar
^ permalink raw reply
* Re: Patches for 2.6.15
From: Stephen Rothwell @ 2005-10-29 8:07 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <D45D980C-C3F8-4418-A159-6F10708C914A@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 359 bytes --]
On Fri, 28 Oct 2005 13:49:26 -0500 Kumar Gala <kumar.gala@freescale.com> wrote:
>
> Can you merge this in:
>
> http://patchwork.ozlabs.org/linuxppc/patch?id=2931
I can't find any use of mpc85xx_show_cpuinfo. Is there something subtle here?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [patch 38/43] Various powerpc 32bit ppc64 build fixes
From: Sven Luther @ 2005-10-29 6:27 UTC (permalink / raw)
To: Paul Mackerras; +Cc: akpm, linuxppc-dev, luther, linuxppc64-dev
In-Reply-To: <17251.2983.358202.164993@cargo.ozlabs.ibm.com>
On Sat, Oct 29, 2005 at 03:41:59PM +1000, Paul Mackerras wrote:
> Sven Luther writes:
>
> > +ifeq ($(CONFIG_6xx),y)
> > obj-$(CONFIG_PPC_PMAC) += pmac_pic.o pmac_setup.o pmac_time.o \
> > pmac_feature.o pmac_pci.o pmac_sleep.o \
> > pmac_low_i2c.o pmac_cache.o
> > +else
> > +obj-$(CONFIG_PPC_PMAC) += pmac_pic.o pmac_setup.o pmac_time.o \
> > + pmac_feature.o pmac_pci.o pmac_sleep.o \
> > + pmac_low_i2c.o
> > +endif
>
> This is a bit gross. How about:
Well, i sent to linuxppc-dev for comments too :)
> pmac-$(CONFIG_6xx) := pmac_cache.o
> obj-$(CONFIG_PPC_PMAC) += pmac_pic.o pmac_setup.o pmac_time.o \
> pmac_feature.o pmac_pci.o pmac_sleep.o \
> pmac_low_i2c.o $(pmac-y)
>
> Care to send a revised patch?
Sure, i will do so early next week.
Friendly,
Sven Luther
^ permalink raw reply
* Re: Patches for 2.6.15
From: Andrew Morton @ 2005-10-29 5:59 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, kumar.gala, linuxppc64-dev
In-Reply-To: <17251.3222.175214.996295@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> wrote:
>
> Andrew Morton writes:
>
> > I'll mail them all over.
>
> Got them, thanks. I'm going to drop 06, 12, 13, 18, 19, 20, 21, and
> 37 for now. The rest I have committed to the powerpc-merge tree.
>
> The reasons for dropping them are:
>
> 06 - need to discuss the specifics of the patch with Marcelo
> 12, 13 - going through netdev tree
> 18 - it seems there is still ongoing discussion about whether this is
> the best approach
> 19, 20, 21 - BenH's SMU stuff, which he told me he would rebase on
> top of the merge tree
> 37 - I want the patch done a little differently
OK, well I'll probably drop all those patches as well - hopefully all the
originators know what's going on and nothing will fall through a crack.
^ permalink raw reply
* Re: Patches for 2.6.15
From: Paul Mackerras @ 2005-10-29 5:45 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, kumar.gala, linuxppc64-dev
In-Reply-To: <20051028174029.24d4dbb9.akpm@osdl.org>
Andrew Morton writes:
> I'll mail them all over.
Got them, thanks. I'm going to drop 06, 12, 13, 18, 19, 20, 21, and
37 for now. The rest I have committed to the powerpc-merge tree.
The reasons for dropping them are:
06 - need to discuss the specifics of the patch with Marcelo
12, 13 - going through netdev tree
18 - it seems there is still ongoing discussion about whether this is
the best approach
19, 20, 21 - BenH's SMU stuff, which he told me he would rebase on
top of the merge tree
37 - I want the patch done a little differently
Regards,
Paul.
^ permalink raw reply
* Re: [patch 38/43] Various powerpc 32bit ppc64 build fixes
From: Paul Mackerras @ 2005-10-29 5:41 UTC (permalink / raw)
To: sven.luther; +Cc: akpm, linuxppc-dev, luther, linuxppc64-dev
In-Reply-To: <200510290047.j9T0lNNJ030117@shell0.pdx.osdl.net>
Sven Luther writes:
> +ifeq ($(CONFIG_6xx),y)
> obj-$(CONFIG_PPC_PMAC) += pmac_pic.o pmac_setup.o pmac_time.o \
> pmac_feature.o pmac_pci.o pmac_sleep.o \
> pmac_low_i2c.o pmac_cache.o
> +else
> +obj-$(CONFIG_PPC_PMAC) += pmac_pic.o pmac_setup.o pmac_time.o \
> + pmac_feature.o pmac_pci.o pmac_sleep.o \
> + pmac_low_i2c.o
> +endif
This is a bit gross. How about:
pmac-$(CONFIG_6xx) := pmac_cache.o
obj-$(CONFIG_PPC_PMAC) += pmac_pic.o pmac_setup.o pmac_time.o \
pmac_feature.o pmac_pci.o pmac_sleep.o \
pmac_low_i2c.o $(pmac-y)
Care to send a revised patch?
Paul.
^ permalink raw reply
* Re: [PATCH 2.6.14-rc5 1/1] : mv643xx_eth_pcidev - implements hotplug for the marvell gige functionality by probing the northbridge pci id.
From: Sven Luther @ 2005-10-29 5:37 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Andrew Morton, linuxppc-dev, Sven Luther
In-Reply-To: <17251.265.196352.234376@cargo.ozlabs.ibm.com>
On Sat, Oct 29, 2005 at 02:56:41PM +1000, Paul Mackerras wrote:
> Sven Luther writes:
>
> > +static struct pci_device_id pci_marvell_mv64360[] = {
> > + { PCI_DEVICE(PCI_VENDOR_ID_MARVELL, PCI_DEVICE_ID_MARVELL_MV64360) },
>
> Are there other devices in this northbridge whose drivers might also
> want to bind to this PCI id?
>
> What other devices does this northbridge contain?
Yep, Dale proposed to add :
+ { PCI_DEVICE(PCI_VENDOR_ID_MARVELL, PCI_DEVICE_ID_MARVELL_MV64460) },
Which i was about to resubmit the patch when i saw the commit, ... Err, no i
misunderstood your question.
Other devices, well, there is the interrupt controller, some dma engine and
the builtin sram, but nothing to my knowledge which would benefit from being
bound to the pci id.
Friendly,
Sven Luther
^ permalink raw reply
* Re: [PATCH 2.6.14-rc5 1/1] : mv643xx_eth_pcidev - implements hotplug for the marvell gige functionality by probing the northbridge pci id.
From: Paul Mackerras @ 2005-10-29 4:56 UTC (permalink / raw)
To: Sven Luther; +Cc: Andrew Morton, linuxppc-dev
In-Reply-To: <20051025075159.GA10316@localhost.localdomain>
Sven Luther writes:
> +static struct pci_device_id pci_marvell_mv64360[] = {
> + { PCI_DEVICE(PCI_VENDOR_ID_MARVELL, PCI_DEVICE_ID_MARVELL_MV64360) },
Are there other devices in this northbridge whose drivers might also
want to bind to this PCI id?
What other devices does this northbridge contain?
Paul.
^ permalink raw reply
* Re: [patch 13/43] Add MAINTAINER entry for the new PowerPC 4xx on-chip ethernet controller driver
From: Paul Mackerras @ 2005-10-29 3:24 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: Andrew Morton, linuxppc-dev, linuxppc64-dev
In-Reply-To: <20051029012413.GA1371@gate.ebshome.net>
Eugene Surovegin writes:
> Paul, drop this and the previous patch. They will go in through netdev
> tree and aren't affected by the ppc/ppc64 merge.
Sure, that makes it easier for me. :)
Paul.
^ permalink raw reply
* Re: [patch 13/43] Add MAINTAINER entry for the new PowerPC 4xx on-chip ethernet controller driver
From: Eugene Surovegin @ 2005-10-29 1:24 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Andrew Morton, linuxppc-dev, linuxppc64-dev
In-Reply-To: <200510290046.j9T0ks7c030026@shell0.pdx.osdl.net>
On Fri, Oct 28, 2005 at 05:46:24PM -0700, Andrew Morton wrote:
>
> From: Eugene Surovegin <ebs@ebshome.net>
>
> Add MAINTAINER entry for the new PPC4xx EMAC driver
Paul, drop this and the previous patch. They will go in through netdev
tree and aren't affected by the ppc/ppc64 merge.
--
Eugene
^ permalink raw reply
* [patch 43/43] ppc64 memory model depends on NUMA
From: akpm @ 2005-10-29 0:46 UTC (permalink / raw)
To: paulus; +Cc: akpm, linuxppc-dev, apw, jschopp, linuxppc64-dev
From: Andy Whitcroft <apw@shadowen.org>
Currently when we first select memory model (FLAT, DISCONTIG, SPARSE) then
select whether the machine is NUMA. However NUMA systems may not be FLAT.
This constraint it not honoured and we may configure a NUMA/FLAT system.
Reorder the configuration such that we choose NUMA first which allows us to
only list the memory models which are valid. We now default NUMA for known
NUMA systems. Note that this new order also matches that used in x86.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Joel Schopp <jschopp@austin.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
arch/ppc64/Kconfig | 11 ++++-------
1 files changed, 4 insertions(+), 7 deletions(-)
diff -puN arch/ppc64/Kconfig~ppc64-memory-model-depends-on-numa arch/ppc64/Kconfig
--- devel/arch/ppc64/Kconfig~ppc64-memory-model-depends-on-numa 2005-10-28 17:44:05.000000000 -0700
+++ devel-akpm/arch/ppc64/Kconfig 2005-10-28 17:44:05.000000000 -0700
@@ -245,6 +245,10 @@ config HMT
This option enables hardware multithreading on RS64 cpus.
pSeries systems p620 and p660 have such a cpu type.
+config NUMA
+ bool "NUMA support"
+ default y if SMP && PPC_PSERIES
+
config ARCH_SELECT_MEMORY_MODEL
def_bool y
@@ -260,9 +264,6 @@ config ARCH_DISCONTIGMEM_DEFAULT
def_bool y
depends on ARCH_DISCONTIGMEM_ENABLE
-config ARCH_FLATMEM_ENABLE
- def_bool y
-
config ARCH_SPARSEMEM_ENABLE
def_bool y
depends on ARCH_DISCONTIGMEM_ENABLE
@@ -285,10 +286,6 @@ config NODES_SPAN_OTHER_NODES
def_bool y
depends on NEED_MULTIPLE_NODES
-config NUMA
- bool "NUMA support"
- default y if DISCONTIGMEM || SPARSEMEM
-
config SCHED_SMT
bool "SMT (Hyperthreading) scheduler support"
depends on SMP
_
^ permalink raw reply
* [patch 42/43] ppc64: remove duplicate local variable in set_preferred_console
From: akpm @ 2005-10-29 0:46 UTC (permalink / raw)
To: paulus; +Cc: akpm, linuxppc-dev, olh, linuxppc64-dev
From: Olaf Hering <olh@suse.de>
remove duplicate local variable, saves 2 asm instructions.
Signed-off-by: Olaf Hering <olh@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
arch/ppc64/kernel/setup.c | 1 -
1 files changed, 1 deletion(-)
diff -puN arch/ppc64/kernel/setup.c~ppc64-remove-duplicate-local-variable-in-set_preferred_console arch/ppc64/kernel/setup.c
--- devel/arch/ppc64/kernel/setup.c~ppc64-remove-duplicate-local-variable-in-set_preferred_console 2005-10-28 17:44:05.000000000 -0700
+++ devel-akpm/arch/ppc64/kernel/setup.c 2005-10-28 17:44:05.000000000 -0700
@@ -881,7 +881,6 @@ static int __init set_preferred_console(
if (reg && compat && (strcmp(compat, "hvterm-protocol") == 0)) {
/* Host Virtual Serial Interface */
- int offset;
switch (reg[0]) {
case 0x30000000:
offset = 0;
_
^ permalink raw reply
* [patch 41/43] ppc64: change name of target file during make install
From: akpm @ 2005-10-29 0:46 UTC (permalink / raw)
To: paulus; +Cc: akpm, linuxppc-dev, olh, linuxppc64-dev
From: Olaf Hering <olh@suse.de>
'make install' creates a /boot/zImage[.vmode] file when the defconfig is used.
It uses the second arg as file content, which is the vmlinux, and the 5th
arg as file name, which is the BOOTIMAGE name.
A comment in an earlier patch to install.sh states that yaboot can not load
a zImage+initrd combo. This was true in kernel 2.6.5 because it did use
bi_recs to pass the initrd info. But this concept was always broken.
Register r3 holds the initrd address and r4 holds the initrd size. This
works with all kernel versions. The current code in main.c leaves r3 and
r4 alone, so the kernel should be able to see and use the memory range with
the initrd content.
If one wants to rerun mkinitrd, it is currently hard to get the uname -r
value for the installed zImage. Without this info, mkinitrd can not know
what modules to use. This would be fixable by including the /proc/version
output of the new kernel. But it is simpler to just use the plain vmlinux.
So all this patch does is to write to /boot/vmlinux instead to /boot/zImage
Signed-off-by: Olaf Hering <olh@suse.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
arch/ppc64/boot/install.sh | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -puN arch/ppc64/boot/install.sh~ppc64-change-name-of-target-file-during-make-install arch/ppc64/boot/install.sh
--- devel/arch/ppc64/boot/install.sh~ppc64-change-name-of-target-file-during-make-install 2005-10-28 17:44:05.000000000 -0700
+++ devel-akpm/arch/ppc64/boot/install.sh 2005-10-28 17:44:05.000000000 -0700
@@ -28,7 +28,7 @@ if [ -x /sbin/${CROSS_COMPILE}installker
# Default install
# this should work for both the pSeries zImage and the iSeries vmlinux.sm
-image_name=`basename $5`
+image_name=`basename $2`
if [ -f $4/$image_name ]; then
mv $4/$image_name $4/$image_name.old
_
^ permalink raw reply
* [patch 40/43] ppc64: reenable make install with defconfig
From: akpm @ 2005-10-29 0:46 UTC (permalink / raw)
To: paulus; +Cc: akpm, linuxppc-dev, olh, linuxppc64-dev
From: Olaf Hering <olh@suse.de>
'make ARCH=ppc64 O=../O install' does not work with the defconfig.
CONFIG_PPC_BPA is part of it, but the BPA bootimage variable is wrong:
make[2]: *** No rule to make target `zImage', needed by `install'. Stop.
Signed-off-by: Olaf Hering <olh@suse.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
arch/ppc64/Makefile | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -puN arch/ppc64/Makefile~ppc64-reenable-make-install-with-defconfig arch/ppc64/Makefile
--- devel/arch/ppc64/Makefile~ppc64-reenable-make-install-with-defconfig 2005-10-28 17:44:05.000000000 -0700
+++ devel-akpm/arch/ppc64/Makefile 2005-10-28 17:44:05.000000000 -0700
@@ -103,7 +103,7 @@ $(boottargets-y): vmlinux
bootimage-$(CONFIG_PPC_PSERIES) := $(boot)/zImage
bootimage-$(CONFIG_PPC_PMAC) := vmlinux
bootimage-$(CONFIG_PPC_MAPLE) := $(boot)/zImage
-bootimage-$(CONFIG_PPC_BPA) := zImage
+bootimage-$(CONFIG_PPC_BPA) := $(boot)/zImage
bootimage-$(CONFIG_PPC_ISERIES) := vmlinux
BOOTIMAGE := $(bootimage-y)
install: vmlinux
_
^ permalink raw reply
* [patch 39/43] ppc64: compile nls_cp437 and nls_iso8859_1 into the kernel in defconfig
From: akpm @ 2005-10-29 0:46 UTC (permalink / raw)
To: paulus; +Cc: akpm, linuxppc-dev, olh, linuxppc64-dev
From: Olaf Hering <olh@suse.de>
compile nls_cp437 and nls_iso8859_1 into the kernel in defconfig. This is
already enabled in pSeries_defconfig.
Reason: if one just boots the new shiny zImage and the root filesystem is
on a filesystem not readable by yaboot (like jfs, raid or lvm) upgrading
the bootloader will fail because the FAT bootpartition can not be mounted.
Signed-off-by: Olaf Hering <olh@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
arch/ppc64/defconfig | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff -puN arch/ppc64/defconfig~ppc64-compile-nls_cp437-and-nls_iso8859_1-into-the-kernel-in-defconfig arch/ppc64/defconfig
--- devel/arch/ppc64/defconfig~ppc64-compile-nls_cp437-and-nls_iso8859_1-into-the-kernel-in-defconfig 2005-10-28 17:44:05.000000000 -0700
+++ devel-akpm/arch/ppc64/defconfig 2005-10-28 17:44:05.000000000 -0700
@@ -1318,7 +1318,7 @@ CONFIG_MSDOS_PARTITION=y
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
-CONFIG_NLS_CODEPAGE_437=m
+CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_CODEPAGE_737=m
CONFIG_NLS_CODEPAGE_775=m
CONFIG_NLS_CODEPAGE_850=m
@@ -1342,7 +1342,7 @@ CONFIG_NLS_ISO8859_8=m
CONFIG_NLS_CODEPAGE_1250=m
CONFIG_NLS_CODEPAGE_1251=m
CONFIG_NLS_ASCII=m
-CONFIG_NLS_ISO8859_1=m
+CONFIG_NLS_ISO8859_1=y
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_3=m
CONFIG_NLS_ISO8859_4=m
_
^ permalink raw reply
* [patch 38/43] Various powerpc 32bit ppc64 build fixes
From: akpm @ 2005-10-29 0:46 UTC (permalink / raw)
To: paulus; +Cc: akpm, linuxppc-dev, luther, linuxppc64-dev
From: Sven Luther <sven.luther@wanadoo.fr>
Find here attached two small build fixes for the 32bit ppc64 kernels. I
know the support for those kernels will soon go away, and debian is not
using them anymore, but until then it is nice to not have it broken, since
other users may need it.
Signed-off-by: Sven Luther <luther@debian.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
arch/ppc/boot/simple/misc-prep.c | 2 ++
arch/ppc/platforms/Makefile | 6 ++++++
2 files changed, 8 insertions(+)
diff -puN arch/ppc/boot/simple/misc-prep.c~various-powerpc-32bit-ppc64-build-fixes arch/ppc/boot/simple/misc-prep.c
--- devel/arch/ppc/boot/simple/misc-prep.c~various-powerpc-32bit-ppc64-build-fixes 2005-10-28 17:44:04.000000000 -0700
+++ devel-akpm/arch/ppc/boot/simple/misc-prep.c 2005-10-28 17:44:04.000000000 -0700
@@ -152,9 +152,11 @@ load_kernel(unsigned long load_addr, int
hold_residual->VitalProductData.Reserved5 = 0xdeadbeef;
}
+#if defined(CONFIG_6xx)
/* Now go and clear out the BATs and ensure that our MSR is
* correct .*/
disable_6xx_mmu();
+#endif
/* Make r3 be a pointer to the residual data. */
return (unsigned long)hold_residual;
diff -puN arch/ppc/platforms/Makefile~various-powerpc-32bit-ppc64-build-fixes arch/ppc/platforms/Makefile
--- devel/arch/ppc/platforms/Makefile~various-powerpc-32bit-ppc64-build-fixes 2005-10-28 17:44:04.000000000 -0700
+++ devel-akpm/arch/ppc/platforms/Makefile 2005-10-28 17:44:04.000000000 -0700
@@ -9,9 +9,15 @@ obj-$(CONFIG_APUS) += apus_setup.o
ifeq ($(CONFIG_APUS),y)
obj-$(CONFIG_PCI) += apus_pci.o
endif
+ifeq ($(CONFIG_6xx),y)
obj-$(CONFIG_PPC_PMAC) += pmac_pic.o pmac_setup.o pmac_time.o \
pmac_feature.o pmac_pci.o pmac_sleep.o \
pmac_low_i2c.o pmac_cache.o
+else
+obj-$(CONFIG_PPC_PMAC) += pmac_pic.o pmac_setup.o pmac_time.o \
+ pmac_feature.o pmac_pci.o pmac_sleep.o \
+ pmac_low_i2c.o
+endif
obj-$(CONFIG_PPC_CHRP) += chrp_setup.o chrp_time.o chrp_pci.o \
chrp_pegasos_eth.o
ifeq ($(CONFIG_PPC_CHRP),y)
_
^ permalink raw reply
* [patch 37/43] ppc64: make dma_addr_t 64 bits
From: akpm @ 2005-10-29 0:46 UTC (permalink / raw)
To: paulus; +Cc: akpm, sfr, boutcher, linuxppc-dev, linuxppc64-dev
From: Stephen Rothwell <sfr@canb.auug.org.au>
There has been a need expressed for dma_addr_t to be 64 bits on PPC64.
This patch does that. I have built it for pSeries and iSeries and booted a
virtual only iSeries partition.
Signed-off-by: Anton Blanchard <anton@samba.org>
Acked-by: Dave Boutcher <boutcher@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
include/asm-ppc64/scatterlist.h | 2 +-
include/asm-ppc64/types.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff -puN include/asm-ppc64/scatterlist.h~ppc64-make-dma_addr_t-64-bits include/asm-ppc64/scatterlist.h
--- devel/include/asm-ppc64/scatterlist.h~ppc64-make-dma_addr_t-64-bits 2005-10-28 17:44:04.000000000 -0700
+++ devel-akpm/include/asm-ppc64/scatterlist.h 2005-10-28 17:44:04.000000000 -0700
@@ -19,7 +19,7 @@ struct scatterlist {
unsigned int length;
/* For TCE support */
- u32 dma_address;
+ dma_addr_t dma_address;
u32 dma_length;
};
diff -puN include/asm-ppc64/types.h~ppc64-make-dma_addr_t-64-bits include/asm-ppc64/types.h
--- devel/include/asm-ppc64/types.h~ppc64-make-dma_addr_t-64-bits 2005-10-28 17:44:04.000000000 -0700
+++ devel-akpm/include/asm-ppc64/types.h 2005-10-28 17:44:04.000000000 -0700
@@ -63,7 +63,7 @@ typedef unsigned long u64;
typedef __vector128 vector128;
-typedef u32 dma_addr_t;
+typedef u64 dma_addr_t;
typedef u64 dma64_addr_t;
typedef struct {
_
^ 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