These patches add support for the GE IMP3A. This board (based on a Freescale
P2020) uses some support for FPGA logic common with the PPC9A and other 86xx
based boards, so this support has been moved out of the 86xx directory. A
config option (GE_FPGA) has been added to reduce churn on dependant dri
Move the GE GPIO and PIC drivers to allow these to be used by non-86xx
boards.
Signed-off-by: Martyn Welch
---
arch/powerpc/platforms/86xx/Kconfig |3 +
arch/powerpc/platforms/86xx/Makefile |7 +-
arch/powerpc/platforms/86xx/gef_gpio.c | 171
arch/powerpc
Initial board support for the GE IMP3A, a 3U compactPCI card with a p2020
processor.
Signed-off-by: Martyn Welch
---
arch/powerpc/boot/dts/ge_imp3a.dts | 254 ++
arch/powerpc/configs/ge_imp3a_defconfig | 256 ++
arch/powerpc/platform
On Sun, Feb 05, 2012 at 04:13:48PM +, Russell King - ARM Linux wrote:
> It's not quite correct, because OMAP4 has issues in this area as well
> (which does select IRQ_DOMAIN but can be without OF.) The result is
> an oops from irq_domain_add() because domain->ops is NULL.
> The right solutio
On Mon, 6 Feb 2012, Timur Tabi wrote:
> Add a defintion of register PAMUBYPENR (offset 0x604) to the global
> utilities structure.
>
> PAMUBYPENR is the PAMU bypass enable register. It contains control
> bits for enabling bypass mode on each PAMU.
>
> Signed-off-by: Timur Tabi
> ---
> arch/po
Kumar Gala wrote:
> What code will use this? Once such code exists, have this patch in that
> patch series.
Isn't this patch harmless? I'm not adding any code, and there already are
plenty of fields defined in that struct that aren't used anywhere.
The register is for the PAMU driver, which is
On 01/27/2012 10:36 PM, Grant Likely :
> The 'hint' used to try and line up irq numbers with hw irq numbers is
> rather a hack and not very useful. Now that /proc/interrupts also outputs
> the hwirq number, it is even less useful to keep around the 'hint' heuristic.
>
> This patch removes it.
Gr
I've revisited my testing, and found I was wrong about the packets
getting stuck in the FEC queue. The packets are getting stuck in the
bestcomm.
I generate a timestamp for each skb's ip_hdr->id at the beginning of
mpc52xx_fec_start_xmit, and for each skb retrieved from the bestcomm.
Typically t
Hello,
Using the mainline kernel & p1010rdb.dts, fsl_pq_mdio_probe returns busy
on my P1010RDB when first probing the MDIO during kernel boot. On the
console, the error is reported as:
"fsl-pq_mdio: probe of ffe24000.mdio failed with error -16"
I have determined that the failure occurs in
