* [PATCH 6/7] [POWERPC] mpc85xx_mds: reset UCC ethernet properly
From: Anton Vorontsov @ 2007-09-25 14:35 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070925143126.GA30013@localhost.localdomain>
Apart from that the current code doesn't compile it's also
meaningless with regard to the MPC8568E-MDS' BCSR.
This patch used to reset UCCs properly.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 28 ++++++++++++++++------------
1 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index c379286..5de409b 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -107,18 +107,22 @@ static void __init mpc85xx_mds_setup_arch(void)
}
if (bcsr_regs) {
- u8 bcsr_phy;
-
- /* Reset the Ethernet PHY */
- bcsr_phy = in_be8(&bcsr_regs[9]);
- bcsr_phy &= ~0x20;
- out_be8(&bcsr_regs[9], bcsr_phy);
-
- udelay(1000);
-
- bcsr_phy = in_be8(&bcsr_regs[9]);
- bcsr_phy |= 0x20;
- out_be8(&bcsr_regs[9], bcsr_phy);
+#define BCSR_UCC1_GETH_EN (0x1 << 7)
+#define BCSR_UCC2_GETH_EN (0x1 << 7)
+#define BCSR_UCC1_MODE_MSK (0x3 << 4)
+#define BCSR_UCC2_MODE_MSK (0x3 << 0)
+
+ /* Turn off UCC1 & UCC2 */
+ clrbits8(&bcsr_regs[8], BCSR_UCC1_GETH_EN);
+ clrbits8(&bcsr_regs[9], BCSR_UCC2_GETH_EN);
+
+ /* Mode is RGMII, all bits clear */
+ clrbits8(&bcsr_regs[11], BCSR_UCC1_MODE_MSK |
+ BCSR_UCC2_MODE_MSK);
+
+ /* Turn UCC1 & UCC2 on */
+ setbits8(&bcsr_regs[8], BCSR_UCC1_GETH_EN);
+ setbits8(&bcsr_regs[9], BCSR_UCC2_GETH_EN);
iounmap(bcsr_regs);
}
--
1.5.0.6
^ permalink raw reply related
* [PATCH 7/7] [POWERPC][SPI] spi_mpc83xx: allow use on MPC85xx
From: Anton Vorontsov @ 2007-09-25 14:35 UTC (permalink / raw)
To: linuxppc-dev; +Cc: spi-devel-general
In-Reply-To: <20070925143126.GA30013@localhost.localdomain>
MPC85xx's QE SPI controller is almost the same comparing to MPC83xx.
Thus lets use that driver. Tested to work in loopback mode.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/spi/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index b915711..14f0d0d 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -125,7 +125,7 @@ config SPI_MPC52xx_PSC
config SPI_MPC83xx
tristate "Freescale MPC83xx SPI controller"
- depends on SPI_MASTER && PPC_83xx && EXPERIMENTAL
+ depends on SPI_MASTER && (PPC_83xx || PPC_85xx) && EXPERIMENTAL
select SPI_BITBANG
help
This enables using the Freescale MPC83xx SPI controller in master
--
1.5.0.6
^ permalink raw reply related
* Re: [PATCH 1/5] PowerPC: Move of_device allocation into of_device.[ch]
From: Arnd Bergmann @ 2007-09-25 14:27 UTC (permalink / raw)
To: linuxppc-dev
Cc: Thomas Klein, Jan-Bernd Themann, Paul Mackerras, Joachim Fenkes,
LKML, Christoph Raisch, Paul Mackerras, Stefan Roscher
In-Reply-To: <200709251411.27755.fenkes@de.ibm.com>
On Tuesday 25 September 2007, Joachim Fenkes wrote:
> Extract generic of_device allocation code from of_platform_device_create()
> and move it into of_device.[ch], called of_device_alloc(). Also, there's =
now
> of_device_free() which puts the device node.
>=20
> Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
> ---
> =A0include/asm-powerpc/of_device.h =A0 | =A0 =A04 ++
> =A0include/linux/of_device.h =A0 =A0 =A0 =A0 | =A0 =A05 ++
> =A0arch/powerpc/kernel/of_device.c =A0 | =A0 80 +++++++++++++++++++++++++=
++++++++++++
> =A0arch/powerpc/kernel/of_platform.c | =A0 70 +--------------------------=
=2D----
> =A04 files changed, 91 insertions(+), 68 deletions(-)
>=20
Sorry I didn't review the patches earlier when you sent them in private.
The patch looks good to me, especially since you did exactly what I
suggested ;-)
Maybe the description should have another sentence in it about what
the change is good for. You have that in the 0/5 mail, but that does
not go into the changelog, so the information gets lost in the process.
Arnd <><
^ permalink raw reply
* Re: [PATCH 2/5] ibmebus: Remove bus match/probe/remove functions
From: Arnd Bergmann @ 2007-09-25 14:29 UTC (permalink / raw)
To: linuxppc-dev
Cc: Thomas Klein, Jan-Bernd Themann, Paul Mackerras, Joachim Fenkes,
LKML, Christoph Raisch, Paul Mackerras, Stefan Roscher
In-Reply-To: <200709251411.54465.fenkes@de.ibm.com>
On Tuesday 25 September 2007, Joachim Fenkes wrote:
> ibmebus_{,un}register_driver() are replaced by dummy functions because
> ibmebus is temporarily unusable in this transitional state.
>=20
> Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
> ---
> =A0arch/powerpc/kernel/ibmebus.c | =A0199 ++-----------------------------=
=2D---------
> =A01 files changed, 6 insertions(+), 193 deletions(-)
>=20
Great diffstat!
The description makes it sound like a git-bisect would get broken
by this patch, which should never happen. If the patch indeed
ends up with a broken kernel, it would be better to merge it with
the later patch that fixes the code again.
Arnd <><
^ permalink raw reply
* Re: [PATCH 3/5] ibmebus: Add device creation and bus probing based on of_device
From: Arnd Bergmann @ 2007-09-25 14:39 UTC (permalink / raw)
To: linuxppc-dev
Cc: Thomas Klein, Jan-Bernd Themann, Paul Mackerras, Joachim Fenkes,
LKML, Christoph Raisch, Paul Mackerras, Stefan Roscher
In-Reply-To: <200709251412.27896.fenkes@de.ibm.com>
On Tuesday 25 September 2007, Joachim Fenkes wrote:
> The devtree root is now searched for devices matching a built-in whitelist
> during boot, so these devices appear on the bus from the beginning. It is
> still possible to manually add/remove devices to/from the bus by using the
> probe/remove sysfs interface. Also, when a device driver registers itself,
> the devtree is matched against its matchlist.
>
> Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
> ---
> arch/powerpc/kernel/ibmebus.c | 97 ++++++++++++++++++++++++++++++++++-------
> 1 files changed, 81 insertions(+), 16 deletions(-)
>
> diff --git a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c
> index cc80f84..c506e0d 100644
> --- a/arch/powerpc/kernel/ibmebus.c
> +++ b/arch/powerpc/kernel/ibmebus.c
> @@ -51,6 +51,15 @@ static struct device ibmebus_bus_device = { /* fake "parent" device */
>
> struct bus_type ibmebus_bus_type;
>
> +/* These devices will automatically be added to the bus during init */
> +static struct of_device_id builtin_matches[] = {
> + { .name = "lhca" },
> + { .compatible = "IBM,lhca" },
> + { .name = "lhea" },
> + { .compatible = "IBM,lhea" },
> + {},
> +};
> +
Hmm, do you have devices that only have the matching name property
but not the compatible property? If not, I'd suggest only looking
for compatible, so you have less chance of false positives.
> +static int ibmebus_create_device(struct device_node *dn)
> +{
> + struct of_device *dev;
> + int ret;
> +
> + dev = of_device_alloc(dn, NULL, &ibmebus_bus_device);
> + if (!dev)
> + return -ENOMEM;
> +
> + dev->dev.bus = &ibmebus_bus_type;
> + dev->dev.archdata.dma_ops = &ibmebus_dma_ops;
> +
> + ret = of_device_register(dev);
> + if (ret) {
> + of_device_free(dev);
> + return ret;
> + }
> +
> + return 0;
> +}
nice!
> @@ -219,9 +276,9 @@ static ssize_t ibmebus_store_probe(struct bus_type *bus,
> }
>
> if ((dn = of_find_node_by_path(path))) {
> -/* dev = ibmebus_register_device_node(dn); */
> + rc = ibmebus_create_device(dn);
> of_node_put(dn);
> - rc = IS_ERR(dev) ? PTR_ERR(dev) : count;
> + rc = rc ? rc : count;
the last line looks a bit silly. Maybe instead do
rc = ibmebus_create_device(dn);
of_node_put(dn);
}
kfree(path);
if (rc)
return rc;
return count;
}
^ permalink raw reply
* Re: [PATCH 7/7] [POWERPC][SPI] spi_mpc83xx: allow use on MPC85xx
From: Peter Korsgaard @ 2007-09-25 14:48 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, spi-devel-general
In-Reply-To: <20070925143531.GG5323@localhost.localdomain>
>>>>> "Anton" == Anton Vorontsov <avorontsov@ru.mvista.com> writes:
Hi,
Anton> config SPI_MPC83xx
Anton> tristate "Freescale MPC83xx SPI controller"
Anton> - depends on SPI_MASTER && PPC_83xx && EXPERIMENTAL
Anton> + depends on SPI_MASTER && (PPC_83xx || PPC_85xx) && EXPERIMENTAL
Anton> select SPI_BITBANG
Anton> help
Anton> This enables using the Freescale MPC83xx SPI controller in master
Please also update the help text.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 4/5] ibmebus: Move to of_device and of_platform_driver, match eHCA and eHEA drivers
From: Arnd Bergmann @ 2007-09-25 14:42 UTC (permalink / raw)
To: linuxppc-dev
Cc: Thomas Klein, Jan-Bernd Themann, Paul Mackerras, Joachim Fenkes,
LKML, Christoph Raisch, Paul Mackerras, Stefan Roscher
In-Reply-To: <200709251412.59904.fenkes@de.ibm.com>
On Tuesday 25 September 2007, Joachim Fenkes wrote:
> Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
This is missing a description, but the patch looks good.
Arnd <><
^ permalink raw reply
* [PATCH v2 7/7] [POWERPC][SPI] spi_mpc83xx: allow use on MPC85xx
From: Anton Vorontsov @ 2007-09-25 15:02 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev, spi-devel-general
In-Reply-To: <874phiol7j.fsf@macbook.be.48ers.dk>
On Tue, Sep 25, 2007 at 04:48:00PM +0200, Peter Korsgaard wrote:
> >>>>> "Anton" == Anton Vorontsov <avorontsov@ru.mvista.com> writes:
>
> Hi,
>
> Anton> config SPI_MPC83xx
> Anton> tristate "Freescale MPC83xx SPI controller"
> Anton> - depends on SPI_MASTER && PPC_83xx && EXPERIMENTAL
> Anton> + depends on SPI_MASTER && (PPC_83xx || PPC_85xx) && EXPERIMENTAL
> Anton> select SPI_BITBANG
> Anton> help
> Anton> This enables using the Freescale MPC83xx SPI controller in master
>
> Please also update the help text.
Oops. Thanks, fixed.
- - - -
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Subject: [PATCH v2] [POWERPC][SPI] spi_mpc83xx: allow use on MPC85xx
MPC85xx's QE SPI controller is almost the same comparing to MPC83xx.
Thus lets use that driver. Tested to work in loopback mode.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/spi/Kconfig | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index b915711..7a7a42c 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -124,16 +124,17 @@ config SPI_MPC52xx_PSC
Controller in master SPI mode.
config SPI_MPC83xx
- tristate "Freescale MPC83xx SPI controller"
- depends on SPI_MASTER && PPC_83xx && EXPERIMENTAL
+ tristate "Freescale MPC83xx/MPC85xx SPI controller"
+ depends on SPI_MASTER && (PPC_83xx || PPC_85xx) && EXPERIMENTAL
select SPI_BITBANG
help
- This enables using the Freescale MPC83xx SPI controller in master
- mode.
+ This enables using the Freescale MPC83xx/MPC85xx SPI controller in
+ master mode.
Note, this driver uniquely supports the SPI controller on the MPC83xx
- family of PowerPC processors. The MPC83xx uses a simple set of shift
- registers for data (opposed to the CPM based descriptor model).
+ and MPC85xx family of PowerPC processors. The MPC83xx/MPC85xx uses a
+ simple set of shift registers for data (opposed to the CPM based
+ descriptor model).
config SPI_OMAP_UWIRE
tristate "OMAP1 MicroWire"
--
1.5.0.6
^ permalink raw reply related
* Re: [spi-devel-general] [PATCH 7/7] [POWERPC][SPI] spi_mpc83xx: allow use on MPC85xx
From: Kumar Gala @ 2007-09-25 15:04 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, spi-devel-general
In-Reply-To: <20070925143531.GG5323@localhost.localdomain>
On Sep 25, 2007, at 9:35 AM, Anton Vorontsov wrote:
> MPC85xx's QE SPI controller is almost the same comparing to MPC83xx.
> Thus lets use that driver. Tested to work in loopback mode.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> drivers/spi/Kconfig | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index b915711..14f0d0d 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -125,7 +125,7 @@ config SPI_MPC52xx_PSC
>
> config SPI_MPC83xx
> tristate "Freescale MPC83xx SPI controller"
> - depends on SPI_MASTER && PPC_83xx && EXPERIMENTAL
> + depends on SPI_MASTER && (PPC_83xx || PPC_85xx) && EXPERIMENTAL
> select SPI_BITBANG
> help
> This enables using the Freescale MPC83xx SPI controller in master
Should that really be just PPC_83xx || QUICC_ENGINE?
- k
^ permalink raw reply
* Re: [PATCH4/4] [POWERPC] Fix cpm_uart driver
From: Scott Wood @ 2007-09-25 15:11 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linux-kernel, linuxppc-embedded
In-Reply-To: <46F8FA5F.3050907@scram.de>
On Tue, Sep 25, 2007 at 02:09:03PM +0200, Jochen Friedrich wrote:
> In cpm_uart_core.c, the operation "pinfo->rx_bd_base - DPRAM_BASE" is
> used to calculate the DPRAM offset. So DPRAM_BASE must be relative to
> dpram_vbase in commproc.c as well. However, cpm_uart_cpm1.h uses cpmp in
> commproc.c to initialize DPRAM_BASE.
>
> On ARCH=ppc, cpmp is a physical address with 1:1 virtual mapping ("well
> known address"). On ARC=powerpc, this is an address obtained by
> ioremap(), however it's a different ioremap() call than dpram_vbase is
> obtained from, so noone can guarantee
> cpmp is always the same as dpram_vbase even on ARCH=powerpc.
I have patches submitted in which they're from the same ioremap, but
I agree that using cpm_dpram_addr(0) is a more robust way.
-Scott
^ permalink raw reply
* Re: [spi-devel-general] [PATCH 7/7] [POWERPC][SPI] spi_mpc83xx: allow use on MPC85xx
From: Anton Vorontsov @ 2007-09-25 15:18 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, spi-devel-general
In-Reply-To: <16E78F0E-B57B-4084-887E-5D2F9C1D0331@kernel.crashing.org>
On Tue, Sep 25, 2007 at 10:04:41AM -0500, Kumar Gala wrote:
>
> On Sep 25, 2007, at 9:35 AM, Anton Vorontsov wrote:
>
>> MPC85xx's QE SPI controller is almost the same comparing to MPC83xx.
>> Thus lets use that driver. Tested to work in loopback mode.
>>
>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>> ---
>> drivers/spi/Kconfig | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
>> index b915711..14f0d0d 100644
>> --- a/drivers/spi/Kconfig
>> +++ b/drivers/spi/Kconfig
>> @@ -125,7 +125,7 @@ config SPI_MPC52xx_PSC
>>
>> config SPI_MPC83xx
>> tristate "Freescale MPC83xx SPI controller"
>> - depends on SPI_MASTER && PPC_83xx && EXPERIMENTAL
>> + depends on SPI_MASTER && (PPC_83xx || PPC_85xx) && EXPERIMENTAL
>> select SPI_BITBANG
>> help
>> This enables using the Freescale MPC83xx SPI controller in master
>
> Should that really be just PPC_83xx || QUICC_ENGINE?
Well, I thought about that. By now I'm unsure if every QE
implementation will be compatible with further ones. So far
I've tested this driver on MPC8323 and MPC8568. If we'll see
more and more compatible QE SPI controllers, of course we
may just do || QUICC_ENGINE.
PPC_83xx || PPC_85xx
PPC_83xx || QUICC_ENGINE
Today first option saves us four bytes. ;-)
^ permalink raw reply
* Re: PaSemi DMA API for Linux
From: Olof Johansson @ 2007-09-25 15:22 UTC (permalink / raw)
To: Samuel Zahnd; +Cc: linuxppc-embedded
In-Reply-To: <005401c7ff6f$d24ea290$4c0112ac@scsad.scs.ch>
On Tue, Sep 25, 2007 at 02:30:13PM +0200, Samuel Zahnd wrote:
> Hi embedded people,
>
> we have a PaSemi (PA6T-1682) CPU is use with Linux and CFE. I wonder if
> anybody has experience with the DMA engine of the device. Some examples or
> an API would be particularly usefull.
The network driver uses the DMA engine, besides that there's not much
example code out there.
The DMA has alot of features, just what are you looking to do? Just DMA
copy offload, or other functions?
-Olof
^ permalink raw reply
* Re: jffs2 file system on MPC8272ADS
From: Scott Wood @ 2007-09-25 15:23 UTC (permalink / raw)
To: Nethra; +Cc: linuxppc-embedded
In-Reply-To: <12873633.post@talk.nabble.com>
On Mon, Sep 24, 2007 at 11:01:55PM -0700, Nethra wrote:
[snip]
> Header CRC failed on REF_PRISTINE node at 0x0063b24c: Read 0xffffffff,
> calculated 0x44660075
> Node totlen on flash (0xffffffff) != totlen from node ref (0x000002b4)
> Header CRC failed on REF_PRISTINE node at 0x0063b500: Read 0xffffffff,
> calculated 0x44660075
> Node totlen on flash (0xffffffff) != totlen from node ref (0x000002c8)
> Header CRC failed on REF_PRISTINE node at 0x0063b7c8: Read 0xffffffff,
> calculated 0x44660075
>
> are they debug messages or warnings...?
They are errors.
> # CONFIG_MTD_MAP_BANK_WIDTH_1 is not set
> # CONFIG_MTD_MAP_BANK_WIDTH_2 is not set
> CONFIG_MTD_MAP_BANK_WIDTH_4=y
> # CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
> # CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
> # CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
> # CONFIG_MTD_CFI_I1 is not set
> CONFIG_MTD_CFI_I2=y
> # CONFIG_MTD_CFI_I4 is not set
> # CONFIG_MTD_CFI_I8 is not set
[snip]
> #
> # Mapping drivers for chip access
> #
> # CONFIG_MTD_COMPLEX_MAPPINGS is not set
> CONFIG_MTD_PHYSMAP=y
> CONFIG_MTD_PHYSMAP_START=0xFC000000
> CONFIG_MTD_PHYSMAP_LEN=0x4000000CONFIG_MTD_PHYSMAP_BANKWIDTH=4
> # CONFIG_MTD_MULTI_PHYSMAP is not set
> # CONFIG_MTD_SBC8240 is not set
> CONFIG_MTD_PQ2FADS=y
> # CONFIG_MTD_PLATRAM is not set
Are you using a non-standard flash SIMM? The one that comes with the
board (that I've seen, at least) have interleave 4, and are mapped at
0xfe000000.
Was it the physmap driver or the pq2fads driver that found the flash?
Which kernel are you using, and are you using arch/ppc or arch/powerpc?
-Scott
^ permalink raw reply
* Re: MPC8560 CPM2 SCC(UART) Driver CPM_UART_CONSOLE
From: Scott Wood @ 2007-09-25 15:43 UTC (permalink / raw)
To: Deepak Gaur; +Cc: linuxppc-dev
In-Reply-To: <20070925104704.M46195@cdotd.ernet.in>
On Tue, Sep 25, 2007 at 05:33:59PM +0630, Deepak Gaur wrote:
> I am writing a kernel module which is required to parse the characters received from a
> device attached to MPC8560 SCC2 (UART slave mode) on serial interface. This SCC is
> required to be configured for single-buffer, character based operation. Moreover on
> another SCC (SCC1 UART master mode) the board debug interface(console) is connected.
>
> While trying to figure out CPM UART device driver interface available in file
> drivers/serial/cpm_uart/cpm_uart_core.c for my kernel module I found that some of the
> functions are available when CPM_UART_CONSOLE is enabled.
>
> My doubt is regarding status of this flag for my hardware setup. Should this flag be
> enabled or not. If it is required to be enabled for supporting SCC1 then how SCC2 will
> be handled?
That flag should only be set on the actual console. What is it that you
need to do with the other port that the driver won't currently do?
-Scott
^ permalink raw reply
* Re: MPC8560 CPM2 SCC(UART) Driver CPM_UART_CONSOLE
From: Vitaly Bordug @ 2007-09-25 15:59 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070925104704.M46195@cdotd.ernet.in>
Hello Deepak,
On Tue, 25 Sep 2007 17:33:59 +0630
Deepak Gaur wrote:
> Hi all,
>
> I am writing a kernel module which is required to parse the characters received from a
> device attached to MPC8560 SCC2 (UART slave mode) on serial interface. This SCC is
> required to be configured for single-buffer, character based operation. Moreover on
> another SCC (SCC1 UART master mode) the board debug interface(console) is connected.
>
> While trying to figure out CPM UART device driver interface available in file
> drivers/serial/cpm_uart/cpm_uart_core.c for my kernel module I found that some of the
> functions are available when CPM_UART_CONSOLE is enabled.
>
> My doubt is regarding status of this flag for my hardware setup. Should this flag be
> enabled or not. If it is required to be enabled for supporting SCC1 then how SCC2 will
> be handled?
>
well, console is normally initialized early, before actual uart driver, that's why those bits are hidden
behind CPM_UART_CONSOLE.
I suppose you'll just have to get SCC2 uart to work and use ttyCPM1... or if you application is more specific, write another driver
using cpm_uart_core.c as a reference. But I would not recommend using CPM_UART_CONSOLE stuff - it's pretty restricted and assumes very early triggering, with plenty of stuff not initialized.
> As I am a novice in this area , I shall be grateful if you please guide me in
> understanding this driver code.
>
> with regards,
>
> Deepak Gaur
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Sincerely, Vitaly
^ permalink raw reply
* Re: jffs2 file system on MPC8272ADS board
From: Vitaly Bordug @ 2007-09-25 16:22 UTC (permalink / raw)
To: Nethra; +Cc: linuxppc-dev
In-Reply-To: <12873530.post@talk.nabble.com>
[-- Attachment #1: Type: text/plain, Size: 2592 bytes --]
Hello Nethra,
On Mon, 24 Sep 2007 22:47:38 -0700 (PDT)
Nethra wrote:
>
> hi everyone,
>
> I m using custom board similar to MPC8272ADS board...
>
> 1) For the first time it boots up properly in case if we overwrite any
> existing binaries using nfs mounted file system on the board, after
> rebooting it displays fallowing message...
>
> Further such events for this erase block will not be printed
> Eep. Child "null" (ino #1346) of dir ino #3 doesn't exist!
> Eep. Child "autocomm" (ino #463) of dir ino #461 doesn't exist!
> Eep. Child "calibration" (ino #464) of dir ino #461 doesn't exist!
> Eep. Child "coredsp_driver.ko" (ino #939) of dir ino #336 doesn't exist!
> Inode #1307 was a directory with children - removing those too...
> Inode #564 was a directory with children - removing those too...
> Inode #565 was a directory with children - removing those too...
> Inode #1112 was a directory with children - removing those too...
> Inode #1115 was a directory with children - removing those too...
> Inode #1118 was a directory with children - removing those too...
> Inode #1123 was a directory with children - removing those too...
>
> after this board boots up properly....but it not be having overwritten files
>
Have you created jffs2 file system on flash prior to mounting it?
> 2) while booting up for the first time itself it will display the falowing
> message..
>
> modprobe: FATAL: Could not load
> /lib/modules/2.6.10_mvl401-8272ads/modules.dep: No such file or dire
> ctory
>
> but after this also board boots up properly
>
You are missing modules.dep, since haven't run depmod. Issue in from target and it will get cured.
> 3) when board is running properly in between it starts printing on console
> repeatedly...
>
Do the proper MTD partitions setup, erase the partition and create jffs2 filesystem on it.
If after all those steps you're still getting output, that is prolly flakey flash.
> Header CRC failed on REF_PRISTINE node at 0x00638a6c: Read 0xffffffff,
> calculated 0x44660075
> Node totlen on flash (0xffffffff) != totlen from node ref (0x00000254)
> Header CRC failed on REF_PRISTINE node at 0x00638cc0: Read 0xffffffff,
> calculated 0x44660075
[...]
> and
>
> file system is created using fallowing command..
>
> mkfs.jffs2 -r RFS_NEW/ -e 0x20000 -o /tftpboot/jffs2_img -b
>
I am recalling playing with the options upper also cured the jffs2 warnings (not as many as yours but anyway)
> do we need padding or not..?
I'd say that we do not. but it depends
--
Vitaly
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 4/7] [POWERPC] QE pario: support for MPC85xx layout
From: Kim Phillips @ 2007-09-25 16:41 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20070925143440.GD5323@localhost.localdomain>
On Tue, 25 Sep 2007 18:34:40 +0400
Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> 8 bytes padding required to match MPC85xx registers layout.
<sigh>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Reviewed-by: Kim Phillips <kim.phillips@freescale.com>
Kim
^ permalink raw reply
* RE: EBC peripheral, access causing Machine Check
From: Dave Cogley @ 2007-09-25 16:44 UTC (permalink / raw)
To: 'Josh Boyer'; +Cc: linuxppc-embedded
In-Reply-To: <20070924184210.484d39b3@vader.jdub.homelinux.org>
[-- Attachment #1: Type: text/plain, Size: 1781 bytes --]
Yes I thought it might be a problem with the TLB. Where does the TLB
initialization take place in the Linux kernel? I am able to access any
other peripherals on the chip as there TLB entries appear to be properly
allocated. I am remapping the physical address for all peripherals that I am
working with. I have attached the driver code for reference.
Dave
-----Original Message-----
From: Josh Boyer [mailto:jwboyer@jdub.homelinux.org]
Sent: Monday, September 24, 2007 4:42 PM
To: Dave Cogley
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: EBC peripheral, access causing Machine Check
On Mon, 24 Sep 2007 12:19:01 -0700
"Dave Cogley" <dcogley@uslinc.com> wrote:
> Good Afternoon,
>
>
>
> I am using an AMCC 440EPx processor with an FPGA peripheral attached to
the
> EBC. I am doing the entire bank configuration in the u-boot boot loader
> before Linux is loaded. I can directly read and write registers using
> memory read and write (md, nm) within area 0xC0000000 to 0xC000FFFF direct
> memory I/O within the context of u-boot without any faults. When I
attempt
> to access any register in area 0xC000000 within the context of my Linux
> device driver I get a Machine Check fault (attached text) which appears to
> be an access permission violation. I am currently running the DENX ELDK
> 2.6.19.2 platform that was specific to the "Sequoia" platform.
>
>
>
> I have configured the EBC access permissions and control resisters as
> follows for bank 1:
>
>
>
> PB1CR: 0xC003C000
>
> PB1AP: 0x80040380
You need proper TLB entries set up before you can access things. Linux
discards the MMU settings that U-Boot does. So your driver needs to call
ioremap on the physical address.
Other than that, we can't help you much without your driver code.
josh
[-- Attachment #2: banjodecoder.tar.gz --]
[-- Type: application/x-gzip, Size: 4159 bytes --]
^ permalink raw reply
* Re: [spi-devel-general] [PATCH 7/7] [POWERPC][SPI] spi_mpc83xx: allow use on MPC85xx
From: David Brownell @ 2007-09-25 16:58 UTC (permalink / raw)
To: galak, avorontsov; +Cc: spi-devel-general, linuxppc-dev
In-Reply-To: <20070925151819.GA6757@localhost.localdomain>
> >> - depends on SPI_MASTER && PPC_83xx && EXPERIMENTAL
> >> + depends on SPI_MASTER && (PPC_83xx || PPC_85xx) && EXPERIMENTAL
> >
> > Should that really be just PPC_83xx || QUICC_ENGINE?
>
> Well, I thought about that. By now I'm unsure if every QE
> implementation will be compatible with further ones.
How many other QE implementations exist? Is that sort of
gratuitous breakage something Freescale makes a habit of?
> So far
> I've tested this driver on MPC8323 and MPC8568. If we'll see
> more and more compatible QE SPI controllers, of course we
> may just do || QUICC_ENGINE.
>
> PPC_83xx || PPC_85xx
> PPC_83xx || QUICC_ENGINE
>
> Today first option saves us four bytes. ;-)
It'd be good if someone would look at the relevant docs.
I'll wait for a PPC signoff before I forward this for
merge with SPI stuff...
_ Dave
^ permalink raw reply
* Book-E watchdog driver questions
From: Mike Nuss @ 2007-09-25 16:59 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I have a PPC440EPx and I am testing out the builtin watchdog. I have a
couple of questions:
Is there a reason that booke_wdt.c does not specify a MODULE_LICENSE?
>From the copyright notice at the top it appears to be GPL. As written,
it taints the kernel.
Also, if I test out the driver by killing my process that's doing the
pinging, I get a kernel panic:
Bad trap at PC: c0009268, MSR: 29000, vector=1022 Tainted: P
Oops: Exception in kernel mode, sig: 5 [#1]
NIP: C0009268 LR: C00092C4 CTR: C002F6E4
REGS: c02d7f50 TRAP: 1022 Tainted: P (2.6.21-rc4-ts-1-ppc)
MSR: 00029000 <EE,ME> CR: 24D12582 XER: 00000000
TASK = c02809d0[0] 'swapper' THREAD: c029c000
GPR00: 00000000 C029DF90 C02809D0 00000000 C0008294 00000000 00072951
00000000
GPR08: 00002D0F C02D9800 22044288 00000000 00005196 00000000 0FFB2C00
00000001
GPR16: 007FFF23 00000000 00800000 FFFFFFFF 007FFF00 0FFAE6A0 00000000
00000001
GPR24: 00000000 007FFE70 C02D8000 C02D0000 C02E0000 C029C028 00000010
C029C000
NIP [C0009268] cpu_idle+0x64/0xd0
LR [C00092C4] cpu_idle+0xc0/0xd0
Call Trace:
[C029DF90] [C00092C4] cpu_idle+0xc0/0xd0 (unreliable)
[C029DFB0] [C00012B4] rest_init+0x28/0x38
[C029DFC0] [C029E720] start_kernel+0x220/0x29c
[C029DFF0] [C0000200] skpinv+0x1a8/0x1e4
Instruction dump:
38000010 7d20e828 7d290378 7d20e92d 40a2fff4 801f0028 393c9800 700b0008
40820064 80090030 3bc00010 2f800000 <419e0060> 7c00e828 7c00f078 7c00e92d
Bad trap at PC: c0003408, MSR: 21000, vector=1022 Tainted: P
Oops: Exception in kernel mode, sig: 5 [#2]
NIP: C0003408 LR: C0002100 CTR: 00000000
REGS: c02d7f50 TRAP: 1022 Tainted: P (2.6.21-rc4-ts-1-ppc)
MSR: 00021000 <ME> CR: 44D12522 XER: 00000000
TASK = c02809d0[0] 'swapper' THREAD: c029c000
GPR00: 08000000 C02D7DD0 C02809D0 C02D7DE0 00000001 00000001 00000000
00004000
GPR08: C02D0000 C0002100 00021002 C0003408 C0280B80 00000000 0FFB2C00
00000001
GPR16: 007FFF23 00000000 00800000 FFFFFFFF 007FFF00 0FFAE6A0 00000000
00000001
GPR24: 00000000 007FFE70 C02D8000 C02D0000 C02E0000 00000000 00000005
C02D7F50
NIP [C0003408] timer_interrupt+0x0/0x224
LR [C0002100] ret_from_except+0x0/0x18
Call Trace:
Instruction dump:
7d0b4378 7d635b78 4e800020 3d20c02d 800950bc 7c1603a6 7d4c42e6 3d20c02e
3d60c02d 9149f384 914b50b4 4e800020 <7c0802a6> 9421ffc0 be810010 90010044
Kernel panic - not syncing: Attempted to kill the idle task!
Rebooting in 180 seconds..Bad trap at PC: c00066b8, MSR: 21000,
vector=1022 Tainted: P
Oops: Exception in kernel mode, sig: 5 [#3]
NIP: C00066B8 LR: C0002100 CTR: 00033C76
REGS: c02d7f50 TRAP: 1022 Tainted: P (2.6.21-rc4-ts-1-ppc)
MSR: 00021000 <ME> CR: 44D12588 XER: 00000000
TASK = c02809d0[0] 'swapper' THREAD: c029c000
GPR00: 00182000 C02D7CF0 C02809D0 C02D7D00 00000001 00000001 00000000
00000030
GPR08: C02DB2E4 C0002100 00021002 C00066B8 C0280B80 00000000 0FFB2C00
00000001
GPR16: 007FFF23 00000000 00800000 FFFFFFFF 007FFF00 0FFAE6A0 00000000
00000001
GPR24: 00000000 007FFE70 C02D8000 C02D0000 00487AB0 00003311 C0290000
C02D0000
NIP [C00066B8] do_IRQ+0x0/0xb8
LR [C0002100] ret_from_except+0x0/0x18
Call Trace:
Instruction dump:
7fc3f378 3880000a 48073311 4bfffea0 3d20c024 38a97e9c 4bffff30 3c80c024
38847e84 7fc3f378 48073321 4bffff08 <7c0802a6> 9421fff0 90010014 bfc10008
Bad trap at PC: c00066b8, MSR: 21000, vector=1022 Tainted: P
Oops: Exception in kernel mode, sig: 5 [#4]
NIP: C00066B8 LR: C0002100 CTR: 00000000
REGS: c02d7f50 TRAP: 1022 Tainted: P (2.6.21-rc4-ts-1-ppc)
MSR: 00021000 <ME> CR: 44D12522 XER: 00000000
TASK = c02809d0[0] 'swapper' THREAD: c029c000
GPR00: C0002810 C02D7DD0 C02809D0 C02D7DE0 00000001 00000001 00000000
00004000
GPR08: C02D0000 C0002100 00021002 C00066B8 C0280B80 00000000 0FFB2C00
00000001
GPR16: 007FFF23 00000000 00800000 FFFFFFFF 007FFF00 0FFAE6A0 00000000
00000001
GPR24: 00000000 007FFE70 C02D8000 C02D0000 00487AB0 00000000 00000005
C02D7F50
NIP [C00066B8] do_IRQ+0x0/0xb8
LR [C0002100] ret_from_except+0x0/0x18
Call Trace:
Instruction dump:
7fc3f378 3880000a 48073311 4bfffea0 3d20c024 38a97e9c 4bffff30 3c80c024
38847e84 7fc3f378 48073321 4bffff08 <7c0802a6> 9421fff0 90010014 bfc10008
Bad trap at PC: c00066b8, MSR: 21000, vector=1022 Tainted: P
Oops: Exception in kernel mode, sig: 5 [#5]
NIP: C00066B8 LR: C0002100 CTR: 00000000
REGS: c02d7f50 TRAP: 1022 Tainted: P (2.6.21-rc4-ts-1-ppc)
MSR: 00021000 <ME> CR: 44D12522 XER: 00000000
TASK = c02809d0[0] 'swapper' THREAD: c029c000
GPR00: C0002810 C02D7DD0 C02809D0 C02D7DE0 00000001 00000001 00000000
00004000
GPR08: C02D0000 C0002100 00021002 C00066B8 C0280B80 00000000 0FFB2C00
00000001
GPR16: 007FFF23 00000000 00800000 FFFFFFFF 007FFF00 0FFAE6A0 00000000
00000001
GPR24: 00000000 007FFE70 C02D8000 C02D0000 00487AB0 00000000 00000005
C02D7F50
NIP [C00066B8] do_IRQ+0x0/0xb8
LR [C0002100] ret_from_except+0x0/0x18
Call Trace:
Instruction dump:
7fc3f378 3880000a 48073311 4bfffea0 3d20c024 38a97e9c 4bffff30 3c80c024
38847e84 7fc3f378 48073321 4bffff08 <7c0802a6> 9421fff0 90010014 bfc10008
This goes on for a while until it eventually reboots. Is that the
expected behavior?
Mike
^ permalink raw reply
* Re: Book-E watchdog driver questions
From: Kumar Gala @ 2007-09-25 17:42 UTC (permalink / raw)
To: Mike Nuss; +Cc: PowerPC dev list
In-Reply-To: <46F93E54.5050203@gmail.com>
On Sep 25, 2007, at 11:59 AM, Mike Nuss wrote:
> Hi,
>
> I have a PPC440EPx and I am testing out the builtin watchdog. I have a
> couple of questions:
>
> Is there a reason that booke_wdt.c does not specify a MODULE_LICENSE?
>> From the copyright notice at the top it appears to be GPL. As
>> written,
> it taints the kernel.
Odd, no reason. I'll submit a patch for that.
> Also, if I test out the driver by killing my process that's doing the
> pinging, I get a kernel panic:
Its been a while since i've tried this. I'll try it out and see what
happens.
- k
^ permalink raw reply
* Re: [PATCH] add Altivec/VMX state to coredumps
From: Matt Sealey @ 2007-09-25 18:00 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <E4CA12E1-888D-4A8B-B687-02F9D2850E1F@kernel.crashing.org>
Kumar Gala wrote:
> On Sep 24, 2007, at 11:03 PM, Mark Nelson wrote:
>
>> Update dump_task_altivec() (that has so far never been put to use)
>> so that it dumps the Altivec/VMX registers (VR[0] - VR[31], VSCR
>> and VRSAVE) in the same format as the ptrace get_vrregs() and add
>> the appropriate glue typedefs and #defines to
>> include/asm-powerpc/elf.h for it to work.
>
> Is there some way to tell if the core dump has altivec registers
> state in it?
>
> I'm wondering how we distinguish a core dump w/altivec state vs one
> with SPE state.
Sheer number of registers saved?
Why not put the PVR in core dumps that'd make it all easier..
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Local bus binding
From: Scott Wood @ 2007-09-25 18:06 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev@ozlabs.org list
Segher,
Kumar said he wants an ack from you on the local bus node binding before
he applies it -- can you review this patch?
http://patchwork.ozlabs.org/linuxppc/patch?id=13591
Thanks,
Scott
^ permalink raw reply
* Re: Book-E watchdog driver questions
From: Mike Nuss @ 2007-09-25 18:18 UTC (permalink / raw)
To: Kumar Gala; +Cc: PowerPC dev list
In-Reply-To: <2A9ADFCB-2725-4156-BE66-4E55A4987E2D@kernel.crashing.org>
> > Is there a reason that booke_wdt.c does not specify a MODULE_LICENSE?
> >> From the copyright notice at the top it appears to be GPL. As
> >> written,
> > it taints the kernel.
>
> Odd, no reason. I'll submit a patch for that.
>
> > Also, if I test out the driver by killing my process that's doing the
> > pinging, I get a kernel panic:
>
> Its been a while since i've tried this. I'll try it out and see what
> happens.
I also found that GETBOOTSTATUS returns 0 after the reboot. Looking at
the source code I found the comment "XXX: something is clearing TSR" -
I take that to mean that the register is being cleared by something
before the module tries to read it? In my case U-Boot may be clearing
that - I can take a look.
Mike
^ permalink raw reply
* [patch 5/7] Use extended crashkernel command line on ppc64
From: Bernhard Walle @ 2007-09-25 18:23 UTC (permalink / raw)
To: kexec, akpm; +Cc: linux-arch, linuxppc-dev, linux-kernel
In-Reply-To: <20070925182257.900701776@strauss.suse.de>
This patch adapts the ppc64 code to use the generic parse_crashkernel()
function introduced in the generic patch of that series.
Signed-off-by: Bernhard Walle <bwalle@suse.de>
---
arch/powerpc/kernel/machine_kexec.c | 52 ++++++++++++++++++------------------
1 file changed, 26 insertions(+), 26 deletions(-)
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -61,45 +61,39 @@ NORET_TYPE void machine_kexec(struct kim
for(;;);
}
-static int __init early_parse_crashk(char *p)
+void __init reserve_crashkernel(void)
{
- unsigned long size;
-
- if (!p)
- return 1;
-
- size = memparse(p, &p);
+ unsigned long long crash_size, crash_base;
+ int ret;
- if (*p == '@')
- crashk_res.start = memparse(p + 1, &p);
- else
- crashk_res.start = KDUMP_KERNELBASE;
-
- crashk_res.end = crashk_res.start + size - 1;
-
- return 0;
-}
-early_param("crashkernel", early_parse_crashk);
+ /* this is necessary because of lmb_phys_mem_size() */
+ lmb_analyze();
-void __init reserve_crashkernel(void)
-{
- unsigned long size;
+ /* use common parsing */
+ ret = parse_crashkernel(boot_command_line, lmb_phys_mem_size(),
+ &crash_size, &crash_base);
+ if (ret == 0 && crash_size > 0) {
+ if (crash_base == 0)
+ crash_base = KDUMP_KERNELBASE;
+ crashk_res.start = crash_base;
+ } else {
+ /* handle the device tree */
+ crash_size = crashk_res.end - crashk_res.start + 1;
+ }
- if (crashk_res.start == 0)
+ if (crash_size == 0)
return;
/* We might have got these values via the command line or the
* device tree, either way sanitise them now. */
- size = crashk_res.end - crashk_res.start + 1;
-
if (crashk_res.start != KDUMP_KERNELBASE)
printk("Crash kernel location must be 0x%x\n",
KDUMP_KERNELBASE);
crashk_res.start = KDUMP_KERNELBASE;
- size = PAGE_ALIGN(size);
- crashk_res.end = crashk_res.start + size - 1;
+ crash_size = PAGE_ALIGN(crash_size);
+ crashk_res.end = crashk_res.start + crash_size - 1;
/* Crash kernel trumps memory limit */
if (memory_limit && memory_limit <= crashk_res.end) {
@@ -108,7 +102,13 @@ void __init reserve_crashkernel(void)
memory_limit);
}
- lmb_reserve(crashk_res.start, size);
+ printk(KERN_INFO "Reserving %ldMB of memory at %ldMB "
+ "for crashkernel (System RAM: %ldMB)\n",
+ (unsigned long)(crash_size >> 20),
+ (unsigned long)(crashk_res.start >> 20),
+ (unsigned long)(lmb_phys_mem_size() >> 20));
+
+ lmb_reserve(crashk_res.start, crash_size);
}
int overlaps_crashkernel(unsigned long start, unsigned long size)
--
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox