This MSI driver can be used on 83xx/85xx/86xx board.
In this driver, virtual interrupt host and chip were
setup. There are 256 MSI interrupts in this host, Every 32
MSI interrupts cascaded to one IPIC/MPIC interrupt.
The chip was treated as edge sensitive and some necessary
functions were
Hi all,
Today's linux-next merge of the powerpc got a conflict in
include/asm-powerpc/mmu-44x.h between commit
dbc0b98a9feb95a65275d9937d815a3bd4300103 (ppc: Export tlb_44x_hwater for
KVM) in the kvm tree and commit d04ceb3fc294ea2c4f538a04343f3a473953a3b0
([POWERPC] Move phys_addr_t definition
Matt,
On Saturday 19 April 2008 14:02, Matt Sealey wrote:
Grant Likely wrote:
On Fri, Apr 18, 2008 at 12:11 PM, Matt Sealey [EMAIL PROTECTED] wrote:
Juergen Beisert wrote:
BTW, is anyone trying to shepherd this driver into the ALSA tree? Its
out of my area of expertise and
On Sun, 2008-04-20 at 22:27 +1000, Paul Mackerras wrote:
Marvin writes:
will this be the end of life for all the PReP's ? I remember a patch posted
some month ago, but didn't heard anything since then. Any news? Or just let
it die quietly?
No, I'm still planning on getting PReP
[1/5] makes the driver reject SQ WRs if the QP is not in RTS
[2/5] bumps a lot of tracing into higher debug_levels
[3/5] removes the mr_largepage parameter
[4/5] changes some bool-ish module parms into actual bools,
also updates some descriptions
[5/5] bumps the version number to 0026
...as required by IB Spec, C10-29.
Signed-off-by: Joachim Fenkes [EMAIL PROTECTED]
---
drivers/infiniband/hw/ehca/ehca_classes.h |1 +
drivers/infiniband/hw/ehca/ehca_qp.c |3 +++
drivers/infiniband/hw/ehca/ehca_reqs.c|5 +
3 files changed, 9 insertions(+), 0
Signed-off-by: Joachim Fenkes [EMAIL PROTECTED]
---
drivers/infiniband/hw/ehca/ehca_irq.c|2 +-
drivers/infiniband/hw/ehca/ehca_main.c | 14 ++--
drivers/infiniband/hw/ehca/ehca_mrmw.c | 16 ++
drivers/infiniband/hw/ehca/ehca_qp.c | 12
Always enable large page support; didn't seem to cause problems for anyone.
Signed-off-by: Joachim Fenkes [EMAIL PROTECTED]
---
drivers/infiniband/hw/ehca/ehca_main.c | 22 +++---
1 files changed, 3 insertions(+), 19 deletions(-)
diff --git
Signed-off-by: Joachim Fenkes [EMAIL PROTECTED]
---
drivers/infiniband/hw/ehca/ehca_main.c | 37 +++
1 files changed, 18 insertions(+), 19 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_main.c
b/drivers/infiniband/hw/ehca/ehca_main.c
index
Signed-off-by: Joachim Fenkes [EMAIL PROTECTED]
---
drivers/infiniband/hw/ehca/ehca_main.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_main.c
b/drivers/infiniband/hw/ehca/ehca_main.c
index 45fe35a..6504897 100644
---
* Stephen Rothwell [EMAIL PROTECTED] wrote:
Hi all,
Today's linux-next merge of the x86-latest tree got a conflict in
include/asm-powerpc/bitops.h between commit
cd008c0f03f3d451e5fbd108b8e74079d402be64 (generic: implement __fls on
all 64-bit archs) from the x86-latest tree and commit
On Sat, Apr 19, 2008 at 06:25:13PM +0200, Andreas Schwab wrote:
Current versions of gdb require a working implementation of
PTRACE_GETSIGINFO for proper watchpoint support. Since struct siginfo
contains pointers it must be converted when passed to a 32-bit debugger.
Roland just posted a patch
On Monday 21 April 2008 10:04, Joachim Fenkes wrote:
+ if (unlikely(my_qp-state != IB_QPS_RTS)) {
+ ehca_err(qp-device, QP not in RTS state qpn=%x, qp-qp_num);
+ return -EINVAL;
+ }
Myself, I'm not very happy with using EINVAL, but I can't think of a more
Hi all,
Today's linux-next merge of the x86-latest tree got a conflict in
include/asm-powerpc/bitops.h between commit
cd008c0f03f3d451e5fbd108b8e74079d402be64 (generic: implement __fls on
all 64-bit archs) from the x86-latest tree and commit
9f264be6101c42cb9e471c58322fb83a5cde1461 ([POWERPC]
On Mon, 2008-04-21 at 12:03 +1000, Benjamin Herrenschmidt wrote:
On Fri, 2008-04-18 at 15:33 +1000, Tony Breeds wrote:
As the pacas are statically initialised increasing NR_CPUS beyond 128,
means that any additional pacas will be empty ... which is bad.
This patch adds the required
On Mon, 2008-04-21 at 19:05 +1000, Michael Ellerman wrote:
Tony, you should NAK Ben tomorrow after lunch if you know what I
mean :)
Should I hide ? :-)
You must NEVER manipulate kernel globals from prom_init.c. The fact
that
prom_init is linked with the kernel is an accident which may
Benjamin Herrenschmidt wrote:
Yes you're right. Early at the pci initialization are errors of the allocation
for pi ressources.
And that are exactly the ressources failing later, so that pci initialization
seem to be the reason for my problem.
Was there any simple solution (e.g. just somehow
Alexander van Heukelum writes:
Powerpc would pick up an optimized version via this chain: generic fls64
-
powerpc __fls -- __ilog2 -- asm (PPC_CNTLZL %0,%1 : =r (lz) : r
(x)).
Why wouldn't powerpc continue to use the fls64 that I have in there
now?
However, the generic version of fls64
Ingo Molnar writes:
Paul, do you agree with those generic bitops changes? Just in case it's
Well, it looks OK, but I'm sure people are going to get confused with
fls vs. fls64 vs. __fls all being subtly different. I'd say it's
worth putting a little file in the Documentation directory to
On Monday 21 April 2008, Laurent Pinchart wrote:
Is there any chance they will got to 2.6.26?
I'm not sure. I didn't have the time to look at it myself, but I am
under the impression that the powerpc folks are tired of having to wait
for me and may push it to Linus through their
Hello.
Christian Ehrhardt wrote:
Cheers,
Ben.
For comparison I defined DEBUG in the good kernel (arch=ppc) and that is
what the initialization prints (pci ...:0a:1 is the secondary head of
the same graphic card an it's not an issue if thats not allocated):
good case:
PCI: Probing PCI
On Mon, Apr 21, 2008 at 2:43 AM, Sascha Hauer [EMAIL PROTECTED] wrote:
On Fri, Apr 18, 2008 at 09:10:04AM -0700, Grant Likely wrote:
Update dts files to current format
From: Grant Likely [EMAIL PROTECTED]
Signed-off-by: Grant Likely [EMAIL PROTECTED]
---
Bartlomiej Sieka wrote:
Board-specific defconfigs based on current mpc5200_defconfig, archival
lite5200_defconfig, and [cm5200|motionpro|tqm5200]_defconfig from the
linux-2.6-denx tree. Kernels build using these defconfigs were verified
to boot with root filesystem mounted over NFS on
2008/4/18 Anton Vorontsov [EMAIL PROTECTED]:
GTM stands for General-purpose Timers Module and able to generate
timer{1,2,3,4} interrupts. These timers are used by the drivers that
need time precise interrupts (like for USB transactions scheduling for
the Freescale USB Host controller as
Sergei Shtylyov wrote:
Hello.
Christian Ehrhardt wrote:
Cheers,
Ben.
For comparison I defined DEBUG in the good kernel (arch=ppc) and that
is what the initialization prints (pci ...:0a:1 is the secondary head
of the same graphic card an it's not an issue if thats not allocated):
[...]
On Fri, Apr 18, 2008 at 1:09 PM, Anton Vorontsov
[EMAIL PROTECTED] wrote:
This is needed to access QE GPIOs via Linux GPIO API.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
diff --git a/Documentation/powerpc/booting-without-of.txt
b/Documentation/powerpc/booting-without-of.txt
On Mon, 21 Apr 2008 15:36:06 +0200, Gabriel Paubert [EMAIL PROTECTED]
said:
On Mon, Apr 21, 2008 at 03:07:13PM +0200, Alexander van Heukelum wrote:
On Mon, 21 Apr 2008 22:13:06 +1000, Paul Mackerras [EMAIL PROTECTED]
said:
Alexander van Heukelum writes:
Powerpc would pick up an
On Mon, Apr 21, 2008 at 08:08:39AM -0600, Grant Likely wrote:
On Fri, Apr 18, 2008 at 1:09 PM, Anton Vorontsov
[EMAIL PROTECTED] wrote:
- split and export __par_io_config_pin() out of par_io_config_pin(), so we
could use the prefixed version with GPIO LIB API;
- rename struct port_regs
On Mon, Apr 21, 2008 at 08:03:31AM -0600, Grant Likely wrote:
2008/4/18 Anton Vorontsov [EMAIL PROTECTED]:
GTM stands for General-purpose Timers Module and able to generate
timer{1,2,3,4} interrupts. These timers are used by the drivers that
need time precise interrupts (like for USB
On Fri, Apr 18, 2008 at 1:09 PM, Anton Vorontsov
[EMAIL PROTECTED] wrote:
- split and export __par_io_config_pin() out of par_io_config_pin(), so we
could use the prefixed version with GPIO LIB API;
- rename struct port_regs to qe_pio_regs, and place it into qe.h;
- rename #define
On Mon, Apr 21, 2008 at 06:33:13PM +0400, Anton Vorontsov wrote:
[...]
+static int __init qe_add_gpiochips(void)
+{
+ int ret;
+ struct device_node *np;
+
+ for_each_compatible_node(np, NULL, fsl,qe-pario-bank) {
+ struct qe_gpio_chip
On Mon, Apr 21, 2008 at 8:49 AM, Anton Vorontsov
[EMAIL PROTECTED] wrote:
Should this really be a arch_initcall()? Would it be better for
platforms needing it to call it explicitly from one of the platform's
machine_arch_initcall()? Otherwise it gets called for all platforms
in a
Christian Ehrhardt wrote:
+else {
+printk(KERN_ERR%s - continue with start 0x%0lx on %p\n, __func__,
(this-end + 1), this-sibling);
+}
new-start = this-end + 1;
this = this-sibling;
And here. Yet it's not clear why you call resource's 'end' 'start'...
On Apr 19, 2008, at 1:14 PM, Grant Likely wrote:
On Sat, Apr 19, 2008 at 9:52 AM, Kumar Gala
[EMAIL PROTECTED] wrote:
We have a board port in arch/powerpc so we dont need this one
anymore.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
Personally, I'd rather not do the piecemeal removal of
This patch adds basic endpoint support to the 4xx PCIe driver.
This is done by checking the device_type property of the PCIe
device node (pci for root-complex and pci-endpoint for endpoint
configuration).
Note: Currently we map a fixed 64MByte window to PLB address 0 (SDRAM).
This should
Hi Rick,
You might try v1.00a of the xps_ll_temac core. There are a couple of
issues with v1.00b (posted previously on this list) that may (or may
not) be causing the problem you see.
Thanks for the answer... but I can't figure out how to revert to 1.00a. Is
the option accessible from xps ?
I am using a recent DENX git tree. I want to enable debugging in prom_parse.c.
When I do that, I see link warnings like:
WARNING: drivers/net/ibm_newemac/ibm_newemac.o(.data+0x6e0): Section mismatch
in reference from the variable emac_of_bus_notifier to the function
Hello, I wrote:
Ah, that's what happens -- BAR0 in functions 0/1 takes up the whole
265 MiB of the PCI memory space (128+128), so no place is left for other
memory BARs.
What's interesting, the Sequoia/Rainier board user manual says that PCI
memory is 0x8000 thru 0xbfff (i.e.
+static inline void gtm_ack_timer16(struct gtm_timer *tmr, u16
events)
+{
+ out_be16(tmr-gtevr, events);
+}
Drop 'inline' and expect gcc to do the right thing.
Not sure about newer gccs, but older complained about defined but not
used functions w/o inline keyword. I'm almost sure
Also, why is bank encoded in compatible? Do the different banks
have different register interfaces?
Yes, they could. For example, interrupt pins are bank-specific.
In what way? If different banks just have different IRQ #s,
there are easier ways to express this.
Segher
On Mon, Apr 21, 2008 at 08:58:09AM -0600, Grant Likely wrote:
On Mon, Apr 21, 2008 at 8:49 AM, Anton Vorontsov
[EMAIL PROTECTED] wrote:
Should this really be a arch_initcall()? Would it be better for
platforms needing it to call it explicitly from one of the platform's
The easiest way is to edit the .mhs by hand.
Steve
-Original Message-
From: [EMAIL PROTECTED]
[mailto:linuxppc-dev-
[EMAIL PROTECTED] On Behalf Of
Guillaume Dargaud
Sent: Monday, April 21, 2008 9:16 AM
To: Rick Moleres; linuxppc-dev@ozlabs.org
Subject: Re: Xilinx network trouble
Grant Likely wrote:
On Mon, Apr 21, 2008 at 7:57 AM, Bartlomiej Sieka [EMAIL PROTECTED] wrote:
Bartlomiej Sieka wrote:
Board-specific defconfigs based on current mpc5200_defconfig, archival
lite5200_defconfig, and [cm5200|motionpro|tqm5200]_defconfig from the
linux-2.6-denx tree. Kernels
On Mon, Apr 21, 2008 at 10:55 AM, Bartlomiej Sieka [EMAIL PROTECTED] wrote:
Grant Likely wrote:
On Mon, Apr 21, 2008 at 7:57 AM, Bartlomiej Sieka [EMAIL PROTECTED]
wrote:
Bartlomiej Sieka wrote:
Board-specific defconfigs based on current mpc5200_defconfig, archival
Juergen Beisert wrote:
Please don't forget what Sylvian said about this driver: I also completely
skipped the 5200 (not B) support ... and your own I think it should be left
noted here that the CCR size changed from 16 bits to 32 bits from 5200 to
5200B in order to reduce confusion.. Its not
On Mon, 21 Apr 2008 12:02:25 -0400
Steven A. Falco [EMAIL PROTECTED] wrote:
I am using a recent DENX git tree. I want to enable debugging in
prom_parse.c.
When I do that, I see link warnings like:
I already sent a patch a month and a half ago to clean all these
warnings up. It never got
I2C parameters freq_m and freq_n are assigned default in the code
but if those properties are not found in the open firmware description
the init returns an error = the code now uses the default
values if the properties are not found.
Signed-off-by: Remi Machet ([EMAIL PROTECTED])
---
This is
On Apr 19, 2008, at 6:07 AM, Gerhard Pircher wrote:
Original-Nachricht
Datum: Thu, 17 Apr 2008 21:57:05 -0500 (CDT)
Von: Kumar Gala [EMAIL PROTECTED]
An: Paul Mackerras [EMAIL PROTECTED]
CC: linuxppc-dev@ozlabs.org
Betreff: [PATCH] [POWERPC] Port fixmap from x86 and use for
On Apr 19, 2008, at 7:18 AM, Paul Mackerras wrote:
Kumar Gala writes:
[POWERPC] 85xx: Add support for relocatble kernel (and booting at
non-
zero)
Should be OK to go though probably not in the first batch. I want to
look through it carefully again since it's touching code that is
common
On Fri, Apr 18, 2008 at 01:34:29PM +0200, Laurent Pinchart wrote:
Scott Wood was concerned in
http://patchwork.ozlabs.org/linuxppc/patch?id=17490 that the gpio lib might
be an unnecessary burden for memory-constraint platforms. Should we keep two
mdio bitbang drivers, one with direct access
On Mon, Apr 21, 2008 at 10:36:48AM -0700, Remi Machet wrote:
I2C parameters freq_m and freq_n are assigned default in the code
but if those properties are not found in the open firmware description
the init returns an error = the code now uses the default
values if the properties are not
Added support to allow an 85xx kernel to be run from a non-zero physical
address (useful for cooperative asymmetric multiprocessing situations and
kdump). The support can be configured at compile time by setting
CONFIG_PAGE_OFFSET, CONFIG_KERNEL_START, and CONFIG_PHYSICAL_START as
desired.
On Mon, Apr 21, 2008 at 10:25:09AM -0500, Kumar Gala wrote:
On Apr 19, 2008, at 1:14 PM, Grant Likely wrote:
On Sat, Apr 19, 2008 at 9:52 AM, Kumar Gala
[EMAIL PROTECTED] wrote:
We have a board port in arch/powerpc so we dont need this one
anymore.
Signed-off-by: Kumar Gala [EMAIL
On Mon, Apr 21, 2008 at 10:37:14AM -0700, Remi Machet wrote:
If one of the devices of the mv64x60 init fails, the remaining
devices are not initialized = This patch change the code to
display an error and continue the initialization.
Signed-off-by: Remi Machet ([EMAIL PROTECTED])
---
On Mon, Apr 21, 2008 at 08:03:31AM -0600, Grant Likely wrote:
+r) Freescale General-purpose Timers Module
+
+Required properties:
+ - compatible : should be fsl,gtm (fsl,qe-gtm in addition for QE
+ GTMs or fsl,cpm2-gtm for CPM2 GTMs).
I don't
If one of the devices of the mv64x60 init fails, the remaining
devices are not initialized = This patch changes the code to
display an error and continue the initialization.
Signed-off-by: Remi Machet ([EMAIL PROTECTED])
---
Integrated the few format changes requested by Dale in the
previous
On Mon, Apr 21, 2008 at 11:46:12AM -0700, Remi Machet wrote:
If one of the devices of the mv64x60 init fails, the remaining
devices are not initialized = This patch changes the code to
display an error and continue the initialization.
Signed-off-by: Remi Machet ([EMAIL PROTECTED])
Acked
603 CPUs have the same issue that some 750 CPUs have in that they can crash
in funny ways if a store from an FPU register instruction is executed on a
register that has never been initialized since power on. This patch fixes
it by making sure all FP registers have been properly initialized at
On Monday 21 April 2008, Anton Vorontsov wrote:
From: J. Random Hacker
Subject: [POWERPC] cleanup board initialization code
This patch removes vast amount of machine_arch_initcall()s that were
used to solely initialize some hardware, like this:
qe_add_gpio_chips();
fsl_gtm_init();
603 CPUs have the same issue that some 750 CPUs have in that they can crash
in funny ways if a store from an FPU register instruction is executed on a
register that has never been initialized since power on. This patch fixes
it by making sure all FP registers have been properly initialized at
On Mon, Apr 21, 2008 at 02:57:47PM -0500, Kumar Gala wrote:
603 CPUs have the same issue that some 750 CPUs have in that they can crash
in funny ways if a store from an FPU register instruction is executed on a
register that has never been initialized since power on. This patch fixes
it by
On Apr 21, 2008, at 3:19 PM, Gabriel Paubert wrote:
On Mon, Apr 21, 2008 at 02:57:47PM -0500, Kumar Gala wrote:
603 CPUs have the same issue that some 750 CPUs have in that they
can crash
in funny ways if a store from an FPU register instruction is
executed on a
register that has never been
The MPSC driver and prpmc2800.dts have been modified to
use property 'cell-index' as the serial port number but
the early serial console driver for the mv64x60 has not
been modified to use this new property.
Signed-off-by: Remi Machet ([EMAIL PROTECTED])
---
arch/powerpc/sysdev/mv64x60_udbg.c
On Mon, 2008-04-21 at 13:55 +0200, Christian Ehrhardt wrote:
Benjamin Herrenschmidt wrote:
Yes you're right. Early at the pci initialization are errors of the
allocation for pi ressources.
And that are exactly the ressources failing later, so that pci
initialization seem to be the
On Mon, Apr 21, 2008 at 10:41 AM, Anton Vorontsov
[EMAIL PROTECTED] wrote:
On Mon, Apr 21, 2008 at 08:58:09AM -0600, Grant Likely wrote:
Its not great. It has a boot time impact for every platform compiled
into the kernel. The problem gets worse every time another block of
code uses
On Mon, Apr 21, 2008 at 3:10 PM, Segher Boessenkool
[EMAIL PROTECTED] wrote:
Speaking of making it obvious, is it time to put a #warning in some
prominent arch/ppc header?
The last time arch/ppc built for me (a few days ago), it got
535 warnings. I don't think anyone would notice one
On Mon, 2008-04-21 at 16:54 +0200, Stefan Roese wrote:
--
- As suggested by Benjamin Herrenschmidt, don't determine endpoint mode
by looking at the already configured PCIe port state, but evaluate
the device_type property instead. This makes it possible for boards
without
_GLOBAL(__setup_cpu_603)
- b setup_common_caches
+ mflrr4
+BEGIN_FTR_SECTION
+ bl __init_fpu_registers
+END_FTR_SECTION_IFCLR(CPU_FTR_FPU_UNAVAILABLE)
+ bl __init_fpu_registers
+ bl setup_common_caches
+ mtlrr4
+ blr
The last time arch/ppc built for me (a few days ago), it got
535 warnings. I don't think anyone would notice one more.
Also, whoever doesn't yet know arch/ppc will be going away
has been living under a rock for the last two years.
You say that as if it is an uncommon living condition.
Oh
On Mon, Apr 21, 2008 at 02:02:56PM -0700, Remi Machet wrote:
The MPSC driver and prpmc2800.dts have been modified to
use property 'cell-index' as the serial port number but
the early serial console driver for the mv64x60 has not
been modified to use this new property.
Signed-off-by: Remi
On Mon, Apr 21, 2008 at 01:01:12PM -0700, David Brownell wrote:
On Monday 21 April 2008, Anton Vorontsov wrote:
From: J. Random Hacker
Subject: [POWERPC] cleanup board initialization code
This patch removes vast amount of machine_arch_initcall()s that were
used to solely initialize
On Apr 21, 2008, at 4:22 PM, Benjamin Herrenschmidt wrote:
_GLOBAL(__setup_cpu_603)
- b setup_common_caches
+ mflrr4
+BEGIN_FTR_SECTION
+ bl __init_fpu_registers
+END_FTR_SECTION_IFCLR(CPU_FTR_FPU_UNAVAILABLE)
+ bl __init_fpu_registers
+ bl
On Mon, Apr 21, 2008 at 03:05:25PM -0600, Grant Likely wrote:
On Fri, Apr 18, 2008 at 1:10 PM, Anton Vorontsov
[EMAIL PROTECTED] wrote:
This is patch adds board file, device tree, and defconfig for the new
board, made by Freescale Semiconductor Inc. and Logic Product Development.
On Mon, 2008-04-21 at 17:04 -0500, Kumar Gala wrote:
On Apr 21, 2008, at 4:22 PM, Benjamin Herrenschmidt wrote:
_GLOBAL(__setup_cpu_603)
- b setup_common_caches
+ mflrr4
+BEGIN_FTR_SECTION
+ bl __init_fpu_registers
+END_FTR_SECTION_IFCLR(CPU_FTR_FPU_UNAVAILABLE)
On Monday 21 April 2008, Anton Vorontsov wrote:
On Mon, Apr 21, 2008 at 01:01:12PM -0700, David Brownell wrote:
The way other platforms do this is to hav SOC-specific
init code, and have board-specific initcalls call the
relevant SOC-specific setup.
I don't know about other platforms
On Apr 21, 2008, at 5:12 PM, Benjamin Herrenschmidt wrote:
On Mon, 2008-04-21 at 17:04 -0500, Kumar Gala wrote:
On Apr 21, 2008, at 4:22 PM, Benjamin Herrenschmidt wrote:
_GLOBAL(__setup_cpu_603)
- b setup_common_caches
+ mflrr4
+BEGIN_FTR_SECTION
+ bl
On Mon, Apr 21, 2008 at 12:39 PM, Scott Wood [EMAIL PROTECTED] wrote:
On Mon, Apr 21, 2008 at 08:03:31AM -0600, Grant Likely wrote:
+r) Freescale General-purpose Timers Module
+
+Required properties:
+ - compatible : should be fsl,gtm (fsl,qe-gtm in addition for
On Sat, 2008-02-23 at 08:27 +1100, Benjamin Herrenschmidt wrote:
On Fri, 2008-02-22 at 09:32 +0100, Stefan Roese wrote:
405EX(r) has SDR0_MFR[E0CS/E1CS] set after reset. This selects
the internal loopback mode. Clear these bits so that both EMACs
don't use loopback mode as default.
Kumar Gala writes:
Once again I want to go through it carefully and understand how it all
works, and in particular understand things like the way it ensures
that the base address for the kmap region is aligned to a 4M boundary
so all the kmap ptes are in a single page (assuming it does
From: Stefan Roese [EMAIL PROTECTED]
This fixes the jumbo frame support on EMAC V4 systems. Now the correct
bit is set depending on the EMAC version configured.
Tested on Kilauea (405EX) and Canyonlands (460EX).
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
Signed-off-by: Benjamin Herrenschmidt
From: Stefan Roese [EMAIL PROTECTED]
On some 4xx PPC's (e.g. 460EX/GT), the rx channel number is a multiple
of 8 (e.g. 8 for EMAC1, 16 for EMAC2), but enabling in MAL_RXCASR needs
the divided by 8 value for the bitmask.
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
Signed-off-by: Benjamin
From: Josh Boyer [EMAIL PROTECTED]
This patch fixes several section mismatch warnings in the
ibm_newemac driver similar to:
WARNING: vmlinux.o(.devinit.text+0x3a04): Section mismatch in reference from
the function emac_probe() to the function .devexit.text:tah_detach()
The function __devinit
From: Josh Boyer [EMAIL PROTECTED]
Convert ibm_newemac to use the of_device_is_available function when checking
for unused/unwired EMACs. We leave the current check for an unused property
to maintain backwards compatibility for older device trees. Newer device
trees should simply use the
From: Valentine Barshak [EMAIL PROTECTED]
The PowerPC 440GX Taishan board fails to reset EMAC3 (reset timeout error)
if there's no link. Because of that it fails to find PHY chip. The older
ibm_emac
driver had a workaround for that: the EMAC_CLK_INTERNAL/EMAC_CLK_EXTERNAL
macros,
which toggle
From: Valentine Barshak [EMAIL PROTECTED]
This patch adds ibm_newemac PHY clock workaround for 440EP/440GR EMAC
attached to a PHY which doesn't generate RX clock if there is no link.
The code is based on the previous ibm_emac driver stuff. The 440EP/440GR
allows controlling each EMAC clock
Commit d04ceb3fc294ea2c4f538a04343f3a473953a3b0 moved phys_addr_t definitions
to include/asm-powerpc/types.h. However, arch/ppc 440 builds had a duplicate
definition in include/asm-ppc/mmu.h that caused the build to fail.
This removes the duplicate definition in arch/ppc.
Signed-off-by: Josh
Commit 0119536cd314ef95553604208c25bc35581f7f0a added an assembly version
of strncmp to PowerPC. However, it changed a common header file between
arch/ppc and arch/powerpc without adding strncmp to arch/ppc. This fixes
that omission so that arch/ppc links again.
Signed-off-by: Josh Boyer [EMAIL
On Mon, Apr 21, 2008 at 11:25:29PM +0200, Segher Boessenkool wrote:
The last time arch/ppc built for me (a few days ago), it got
535 warnings.
Heh.
I don't think anyone would notice one more.
Well, it wouldn't be one more, it'd be one per file that includes the
header. If we choose
This fixes radeonfb to not truncate 64 bits resources on 32 bits
platforms. Unfortunately, there are still issues with addresses
returned to userspace via struct fb_fix_screeninfo. This will
have to be dealt with separately.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
This fixes aty128fb to not truncate 64 bits resources on 32 bits
platforms. Unfortunately, there are still issues with addresses
returned to userspace via struct fb_fix_screeninfo. This will
have to be dealt with separately.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
This fixes atyfb to not truncate 64 bits resources on 32 bits
platforms. Unfortunately, there are still issues with addresses
returned to userspace via struct fb_fix_screeninfo. This will
have to be dealt with separately.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
As the pacas are statically initialised increasing NR_CPUS beyond 128,
means that any additional pacas will be empty ... which is bad.
This patch adds the required functionality to fill in any excess pacas
at runtime.
Signed-off-by: Tony Breeds [EMAIL PROTECTED]
---
arch/powerpc/kernel/paca.c
With NR_CPUS=1024
textdata bss dec hex filename
137 1704032 0 1704169 1a00e9 arch/powerpc/kernel/paca.o :Before
121 1179744 524288 1704153 1a00d9 arch/powerpc/kernel/paca.o :After
Now that we're not staatically allocating the paca, we don't need the
NR_STATIC_PACAS
Currently all iSeries secondary CPU's spin directly on the cpu_start in thier
paca. Make them spin on the global __secondary_hold_spinloop, until after the
pacas have been initialised.
Signed-off-by: Tony Breeds [EMAIL PROTECTED]
---
arch/powerpc/platforms/iseries/exception.S | 27
Hi Tony,
On Tue, 22 Apr 2008 13:30:06 +1000 (EST) Tony Breeds [EMAIL PROTECTED] wrote:
+void __init initialise_pacas(void)
+{
+ int cpu;
+ unsigned long kernel_toc = (unsigned long)(__toc_start) + 0x8000UL;
This line could do with a comment saying what it is doing ...
+++
Hi Tony,
On Tue, 22 Apr 2008 13:30:06 +1000 (EST) Tony Breeds [EMAIL PROTECTED] wrote:
Currently all iSeries secondary CPU's spin directly on the cpu_start in thier
paca. Make them spin on the global __secondary_hold_spinloop, until after the
pacas have been initialised.
Signed-off-by:
On Mon, 2008-04-21 at 18:01 +0800, Jin Zhengxiong wrote:
Hi, Michael,
Thank you very much for you input, please see my inline answer.
No worries.
+static int fsl_msi_reserve_dt_hwirqs(struct fsl_msi *msi)
+{
+ int i, len;
+ const u32 *p;
+
+ p = of_get_property(msi-of_node,
On Tuesday 22 April 2008, Benjamin Herrenschmidt wrote:
On Sat, 2008-02-23 at 08:27 +1100, Benjamin Herrenschmidt wrote:
On Fri, 2008-02-22 at 09:32 +0100, Stefan Roese wrote:
405EX(r) has SDR0_MFR[E0CS/E1CS] set after reset. This selects
the internal loopback mode. Clear these bits so
-Original Message-
From: Michael Ellerman [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 22, 2008 12:35 PM
To: Jin Zhengxiong
Cc: linuxppc-dev list; Gala Kumar
Subject: RE: [PATCH 1/3] MSI driver for Freescale 83xx/85xx/86xx cpu
On Mon, 2008-04-21 at 18:01 +0800, Jin
On Monday 21 April 2008, Benjamin Herrenschmidt wrote:
On Mon, 2008-04-21 at 16:54 +0200, Stefan Roese wrote:
--
- As suggested by Benjamin Herrenschmidt, don't determine endpoint mode
by looking at the already configured PCIe port state, but evaluate
the device_type
1 - 100 of 101 matches
Mail list logo
