Hi Linus !
Here's the powerpc batch for this merge window.
Most of it is in arch/powerpc, a few powerpc specific drivers are hit
too, including removing one that has been unused (and unselectable in
Kconfig) for a long time (hdpuftrs), probably remains of a long dead
platform.
This time around,
On Thu, 20 May 2010 at 10:21:36 +0200 (CEST) Thomas Gleixner wrote:
On Thu, 20 May 2010, Michael Ellerman wrote:
On Wed, 2010-05-19 at 16:38 +0200, Thomas Gleixner wrote:
On Wed, 19 May 2010, Darren Hart wrote:
On 05/18/2010 06:25 PM, Michael Ellerman wrote:
On Tue, 2010-05-18
On Thu May 20 at 11:28:36 EST in 2010, Michael Ellerman wrote:
On Wed, 2010-05-19 at 07:16 -0700, Darren Hart wrote:
On 05/18/2010 06:25 PM, Michael Ellerman wrote:
On Tue, 2010-05-18 at 15:22 -0700, Darren Hart wrote:
On 05/18/2010 02:52 PM, Brian King wrote:
Is IRQF_NODELAY
On Fri, May 21, 2010 at 07:11:28PM +1000, Benjamin Herrenschmidt wrote:
Hi Linus !
Here's the powerpc batch for this merge window.
Most of it is in arch/powerpc, a few powerpc specific drivers are hit
too, including removing one that has been unused (and unselectable in
Kconfig) for a long time
On Fri, May 21, 2010 at 07:11:28PM +1000, Benjamin Herrenschmidt wrote:
[...]
Anton Vorontsov (3):
powerpc/85xx: Add eTSEC 2.0 support for P1020RDB boards
powerpc/85xx: Fix P1020RDB boot hang due USB2
powerpc/83xx: Add MCU LEDs support for MPC837xRDB and MPC8315RDB boards
On 05/20/2010 09:33 PM, hellohello wrote:
No, it shouldn't -- rx_bd_base is of type cbd_t *, so the multiplication
already happens as part of pointer arithmetic.
---Yes, you are right. I made a basic mistake.
But now I have another question.
The SMC1 params can be relocated to any offset of
On Fri, 2010-05-21 at 06:22 -0400, Josh Boyer wrote:
On Fri, May 21, 2010 at 07:11:28PM +1000, Benjamin Herrenschmidt wrote:
Hi Linus !
Here's the powerpc batch for this merge window.
Most of it is in arch/powerpc, a few powerpc specific drivers are hit
too, including removing one that
Wolfram Sang (4):
powerpc/pmac: Fix dangling pointers
i2c/mpc: Drop NO_IRQ
i2c/cpm: Drop NO_IRQ
i2c/ibm-iic: Drop NO_IRQ
Sorry for the confusion, but the other Ben (Dooks) has pushed those
NO_IRQ-thigies meanwhile.
--
Pengutronix e.K. |
P1021 is a dual e500v2 core based SOC with:
* 3 eTSECs (eTSEC1/3 RGMII, eTSEC2 SGMII on this board)
* 2 PCIe Controller
* 1 USB2.0 controller
* eSDHC, eSPI, I2C, DUART
* eLBC (NAND, BCSR, PMC0/1)
* Security Engine (SEC 3.3.2)
* Quicc Engine (QE)
Signed-off-by: Haiying Wang
+
+ if (machine_is(p1021_mds)) {
+#define MPC85xx_PMUXCR_OFFSET 0x60
+#define MPC85xx_PMUXCR_QE0 0x8000
+#define MPC85xx_PMUXCR_QE3 0x1000
+#define MPC85xx_PMUXCR_QE9 0x0040
+#define MPC85xx_PMUXCR_QE12
P1021 is a dual e500v2 core based SOC with:
* 3 eTSECs (eTSEC1/3 RGMII, eTSEC2 SGMII on this board)
* 2 PCIe Controller
* 1 USB2.0 controller
* eSDHC, eSPI, I2C, DUART
* eLBC (NAND, BCSR, PMC0/1)
* Security Engine (SEC 3.3.2)
* Quicc Engine (QE)
Signed-off-by: Haiying Wang
[resending to hit the list]
+ if (regs-gpr[0] == 0x1ebe
+ cpu_has_feature(CPU_FTR_REAL_LE)) {
+ regs-msr ^= MSR_LE;
+ goto instr_done;
+ }
regs-gpr[9] = regs-gpr[13];
+ regs-gpr[10]
On 05/20/2010 10:33 PM, hellohello wrote:
No, it shouldn't -- rx_bd_base is of type cbd_t *, so the multiplication
already happens as part of pointer arithmetic.
---Yes, you are right. I made a basic mistake.
But now I have another question.
The SMC1 params can be relocated to any offset of
Hello Moisés,
CTAG / Moisés Domínguez wrote:
Hi all,
I am trying to use MBX 3D engine driver of my ads5121. AFAIK, drivers were
built against same kernel as mine
i.e. 2.6.24.6 from LTIB? Kernel from Freescale's LTIB != vanilla 2.6.24.6
(number of patches vs vanilla kernel is more than 100)
On Fri, 2010-05-21 at 15:04 +0200, Wolfram Sang wrote:
Wolfram Sang (4):
powerpc/pmac: Fix dangling pointers
i2c/mpc: Drop NO_IRQ
i2c/cpm: Drop NO_IRQ
i2c/ibm-iic: Drop NO_IRQ
Sorry for the confusion, but the other Ben (Dooks) has pushed those
NO_IRQ-thigies
Newer kernels support dynamically allocating this parameter RAM. Older
kernels use whatever u-boot chose.
Why do you want to set it to a particular address?
There should be some code to set SMC1_BASE to the 0x87FC offset of the DPRAM,
whatever SMC1_BASE is fixed or dynamically allocated
Should I add these code to cpm_uart_core.c?
--dp_mem = cpm_dpram_addr(0x87fc);
--out_be16(dp_mem, SMC1_BASE);
Why are you mucking about with this code at all? SMCx serial certainly
works on every platform I've ever used, 8xx and 8xxx as well.
I have no interest on mucking about any
17 matches
Mail list logo
