>> Newer kernels support dynamically allocating this parameter RAM. Older
>> kernels use whatever u-boot chose.
I see.Thanks .
U-boot initialize SMC1 for the first time, and has set SMC1_BASE to the 0x87FC
offset of the DPRAM.
kernel 2.6.25 initialize SMC1 for the second time as well as w
>> 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 a
> 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 allocat
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_I
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 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 t
[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];
> + r
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
Signed-off-by: Yu Liu
>
> +
> + 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 0x
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
Signed-off-by: Yu Liu
> 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. |
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
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 t
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 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
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_
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
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,
18 matches
Mail list logo
