hi, Guillaume
Thank you very much. the kernel I'm using is linux-2.6.21 (for the
target system), actually I have also read 2.6.30 source code, but I
didn't find the change, and I think the problem was caused by fault
configuration of the PORTC io-port. The commit you mentioned haven't
applied
On Fri, 14 Aug 2009 22:27:39 +0800
Baojun Wang wrote:
> I need to configure CPM2 PORTC pin (PC9) for external interrupt, when I
> read the MPC8555ERM.pdf and cpm2-pic.c, I find that PC9 interrupt number is
> 56, and I request the IRQ in this way:
>
> hw_irq = 56;
> virq = irq_create_mappin
Ben,
This breaks the boot on 8572. I don't know why yet (and I'm probably
not going to figure it out before I go home, because, frankly, it's
late on a Friday afternoon and I need a glass of wine or, perhaps, a
beer).
Kumar and I will poke into this more and let you know what we find out
This patch adds QE buffer descriptors mode support for the
spi_mpc8xxx driver, and as a side effect we now support CPM1
and CPM2 SPI controllers.
That means that today we support almost all MPC SPI controllers:
- MPC834x-style controllers (support PIO mode only);
- CPM1 and CPM2 controllers (supp
Soon there will be more flags introduced in subsequent patches, so
let's turn qe_mode into flags.
Also introduce mpc8xxx_spi_strmode() and print current SPI mode.
Signed-off-by: Anton Vorontsov
---
drivers/spi/spi_mpc8xxx.c | 30 +++---
include/linux/fsl_devices.h |
We'll add more steps soon, so get rid of the duplication.
Signed-off-by: Anton Vorontsov
---
drivers/spi/spi_mpc8xxx.c | 56 +++-
1 files changed, 24 insertions(+), 32 deletions(-)
diff --git a/drivers/spi/spi_mpc8xxx.c b/drivers/spi/spi_mpc8xxx.c
index
This patch fixes the following warning:
CC drivers/spi/spi_mpc8xxx.o
spi_mpc8xxx.c: In function 'of_mpc8xxx_spi_probe':
spi_mpc8xxx.c:681: warning: 'ret' may be used uninitialized in this function
Signed-off-by: Anton Vorontsov
---
drivers/spi/spi_mpc8xxx.c |1 +
1 files changed, 1
This is needed to avoid ugly #ifdefs in drivers.
QE/CPM UDC and MPC8xxx SPI drivers will benefit from this change.
Signed-off-by: Anton Vorontsov
---
arch/powerpc/include/asm/cpm.h | 44
arch/powerpc/include/asm/qe.h | 11 +-
2 files changed
The bits are generic to CPM devices, so let's move them to the
common header file, so drivers won't need to privately reintroduce
another bunch of the same bits (as we can't include cpm2.h header
together with cpm1.h).
Signed-off-by: Anton Vorontsov
---
arch/powerpc/include/asm/cpm.h | 16 +++
struct mcc defined in both immap_qe.h and immap_cpm2.h, so they will
conflic when included in a single file. The mcc struct is easy to deal
with, since it isn't used in any driver (yet), so let's just rename QE
version to qe_mcc.
The ucb_ctlr is a bit trickier, since it is used by fsl_qe_udc drive
When cpm2.h included into spi_mpc8xxx driver, the SPI defines
in the header conflict with defines in the driver.
We don't need them in the header file, so remove them. Plus
remove "struct spi", we'll use a better version in the driver.
Signed-off-by: Anton Vorontsov
---
arch/powerpc/include/asm
Hi all,
Here are some patches that add DMA support for spi_mpc8xxx driver,
which means that we now support QE BD mode and SPI on CPM1 and CPM2
chips.
QE BD mode and CPM2 SPI support were tested on real hardware, CPM1
was only compile tested (though I belive it will work :-).
Thanks,
--
Anton V
On Fri, 2009-08-14 at 12:49 -0700, David Miller wrote:
> From: Benjamin Herrenschmidt
> Date: Fri, 14 Aug 2009 17:56:40 +1000
>
> > On Thu, 2009-08-13 at 16:40 +0100, Catalin Marinas wrote:
> >> On Thu, 2009-08-13 at 13:01 +1000, Michael Ellerman wrote:
> >> > We don't actually want kmemleak to t
On Aug 12, 2009, at 8:34 AM, Paul Gortmaker wrote:
From: Liang Li
There is 8MB flash, 8kB EEPROM and 128MB SDRAM on the sbc834x
local bus, so add a localbus node in DTS with MTD partitions.
The recent U-boot commit fe613cdd4eb moves u-boot to the beginning
of flash, hence the legacy label on
On Aug 12, 2009, at 8:34 AM, Paul Gortmaker wrote:
With flash partition entries in the DTS file, MTD might as well
be enabled in the defconfig. In a similar vein, enable USB and
enough related options (SCSI/ext2/ext3) so that a user can read
and write to a generic USB flash drive as well.
Als
On Aug 12, 2009, at 8:34 AM, Paul Gortmaker wrote:
From: Liang Li
Since only one of the SoC USB devices is brought out to a physical
connector on the board, remove the 2nd (USB-DR) node from the DTS.
Having it present and USB enabled will cause a hang at boot.
Signed-off-by: Liang Li
Signed
On Aug 12, 2009, at 8:34 AM, Paul Gortmaker wrote:
From: Liang Li
Allows interrupts to occur on the sbc834x. Currently PCI devices
get assigned an incorrect IRQ and so the interrupt count never
increases. This was tested with the 82546GB based dual port E1000
PCI-X NIC which uses two distinct
On Aug 14, 2009, at 9:36 AM, Paul Gortmaker wrote:
From: Liang Li
The existing fsl_rstcr_restart function is not applicable to the
mpc8560. The Global Utilities Block on this earlier CPU doesn't have
the control/reset register at 0xe00b0. This implements a board
specific reset function that
On Aug 14, 2009, at 11:13 AM, Paul Gortmaker wrote:
The earlier mpc8560 CPUs don't have the RSTCR at 0xe00b0
in the GUTS. The generic reboot code uses this tag to
determine if it should be using the RSTCR for reboot, so
remove it from the board definition.
Signed-off-by: Paul Gortmaker
---
a
On Aug 7, 2009, at 10:35 AM, Poonam Aggrwal wrote:
Adds P2020RDB basic support in linux.
Overview of P2020RDB platform
- DDR
DDR2 1G
- NOR Flash
16MByte
- NAND Flash
32MByte
- 3 Ethernet interfaces
1) etSEC1
On Aug 14, 2009, at 11:13 AM, Paul Gortmaker wrote:
Some CPU, like the MPC8560 don't have a RSTCR in the Global
Utilities Block. These boards will implement their own reboot
call, and not use this code, so we should only warn about the
absence of the GUTS RSTCR when the default reboot code is
From: Benjamin Herrenschmidt
Date: Fri, 14 Aug 2009 17:56:40 +1000
> On Thu, 2009-08-13 at 16:40 +0100, Catalin Marinas wrote:
>> On Thu, 2009-08-13 at 13:01 +1000, Michael Ellerman wrote:
>> > We don't actually want kmemleak to track the lmb allocations, so we
>> > pass min_count as 0. However t
Ben's recent patches are missing the CONFIG_ prefix to
PPC_STD_MMU_32, which results in not properly flushing hash
entries. On 8641, this showed up as a platform that would boot,
but deny logins.
Signed-off-by: Becky Bruce
---
arch/powerpc/include/asm/tlb.h |2 +-
1 files changed, 1 inserti
On Thu, 30 Jul 2009 15:33:21 -0700
Mike Mason wrote:
> This is the first of three patches that implement a bit field that
> PCI Express device drivers can use to indicate they need a
> fundamental reset during error recovery.
>
> By default, the EEH framework on powerpc does what's known as a "h
The earlier mpc8560 CPUs don't have the RSTCR at 0xe00b0
in the GUTS. The generic reboot code uses this tag to
determine if it should be using the RSTCR for reboot, so
remove it from the board definition.
Signed-off-by: Paul Gortmaker
---
arch/powerpc/boot/dts/sbc8560.dts |1 -
1 files chan
Some CPU, like the MPC8560 don't have a RSTCR in the Global
Utilities Block. These boards will implement their own reboot
call, and not use this code, so we should only warn about the
absence of the GUTS RSTCR when the default reboot code is used.
Signed-off-by: Paul Gortmaker
---
arch/powerpc/
hi, list:
I need to configure CPM2 PORTC pin (PC9) for external interrupt, when I
read the MPC8555ERM.pdf and cpm2-pic.c, I find that PC9 interrupt number is
56, and I request the IRQ in this way:
hw_irq = 56;
virq = irq_create_mapping(cpm2_host, hw_irq);
reqeust_irq(virq, ...);
I can
On Aug 14, 2009, at 9:43 AM, Paul Gortmaker wrote:
Kumar Gala wrote:
On Aug 13, 2009, at 6:06 PM, Paul Gortmaker wrote:
From: Liang Li
The existing fsl_rstcr_restart function fails to reset the sbc8560
board. This implements a board specific reset function that uses
the RCR(Reset Control Re
Kumar Gala wrote:
On Aug 13, 2009, at 6:06 PM, Paul Gortmaker wrote:
From: Liang Li
The existing fsl_rstcr_restart function fails to reset the sbc8560
board. This implements a board specific reset function that uses
the RCR(Reset Control Register) of the board's EPLD to do a reset.
Signed-o
From: Liang Li
The existing fsl_rstcr_restart function is not applicable to the
mpc8560. The Global Utilities Block on this earlier CPU doesn't have
the control/reset register at 0xe00b0. This implements a board
specific reset function that uses the RCR(Reset Control Register) of
the sbc8560's E
On Fri, 2009-08-14 at 13:29 +0200, Guennadi Liakhovetski wrote:
> but since they are quite long, in short, in them a patch has been
> discussed, that allowed to re-use an MMC driver, used on some MFDs, on
> SuperH SoCs. The patch was taking the "easy route" of adding the
> possibility to use the
Dear "Olivier Croset",
In message you wrote:
>
> While browsing the web, I found the following message with the same kind of
> errors:
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-03/msg08159.html
>
> It is said that "the sata is only supported up to 2.6.25.7". Is it true for
> all Po
> > > 2. A low-power state where the guest indicates it doesn't need the
> > > CPU (and can be put in low power state) but doesn't want to give up
> > > its allocated cpu share. IOW, no visible configuration changes.
> > >
> > > So, in any case we would probably want more than one states.
> >
>
On Fri, 14 Aug 2009, Benjamin Herrenschmidt wrote:
> On Thu, 2009-08-13 at 16:59 +0800, Li Yang-R58472 wrote:
> > >Now, I know there is at least one person on earth
> > >contemplating sharing some drivers between PPC and ARM. I
> > >won't tell much more at this stage, but it makes sense in the
Hello everybody,
I'm working on a custom board with a Freescale 8347 CPU and a Silicon Image
SIL3512 SATA controller, which is on the PCI bus.
SATA is working with 2.6.22 but no more with 2.6.30.4. I tried different
parameters in the kernel configuration with no success. I got the following
outpu
On Thu, 2009-08-13 at 16:59 +0800, Li Yang-R58472 wrote:
> >Now, I know there is at least one person on earth
> >contemplating sharing some drivers between PPC and ARM. I
> >won't tell much more at this stage, but it makes sense in the
> >grand scheme of things to see SoC vendors put similar IO
On Fri, 2009-08-14 at 17:56 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2009-08-13 at 16:40 +0100, Catalin Marinas wrote:
> > On Thu, 2009-08-13 at 13:01 +1000, Michael Ellerman wrote:
> > > We don't actually want kmemleak to track the lmb allocations, so we
> > > pass min_count as 0. However te
On Thu, 2009-08-13 at 16:40 +0100, Catalin Marinas wrote:
> On Thu, 2009-08-13 at 13:01 +1000, Michael Ellerman wrote:
> > We don't actually want kmemleak to track the lmb allocations, so we
> > pass min_count as 0. However telling kmemleak about lmb allocations
> > allows it to scan that memory fo
38 matches
Mail list logo
