* Re: linux DMA capabilities in MV64460
From: Phil Nitschke @ 2006-03-09 8:02 UTC (permalink / raw)
To: Adrian Cox; +Cc: linuxppc-embedded
In-Reply-To: <1141857378.28095.22.camel@localhost.localdomain>
On Wed, 2006-03-08 at 22:36 +0000, Adrian Cox wrote:
> On Mon, 2006-03-06 at 14:39 +1030, Phil Nitschke wrote:
> > How is a DMA controlled (from a device driver writer's perspective) when
> > a third-party (i.e. in the bridge) DMA controller needs to do the work
> > to get the data from a PCI Target into main memory?
> >
> > What kernel API should be provided by the DMA Controller Driver?
>
> There is no current API for this in the kernel, but there are some
> proposals. From Intel, we have I/OAT, which targets network operations:
> http://lkml.org/lkml/2006/3/3/219
>
> There's some overlap with the ADMA feature set, which is intended to
> accelerate RAID operations:
> http://lkml.org/lkml/2006/2/2/442
>
Thanks, Adrian, these are the sorts of APIs I was asking about. At a
quick glance, they look a little "bleeding edge" for my comfort zone.
(And not an exact match for what I'm trying to do...) Nonetheless, I'll
take a closer look at them.
Thanks,
--
Phil Nitschke <Phil.Nitschke@avalon.com.au>
Avalon Systems Pty Ltd
^ permalink raw reply
* RE: [PATCH] Fix MPC8548CDS rebooting procedure
From: Haruki Dai-r35557 @ 2006-03-09 4:16 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
> Sent: Wednesday, March 08, 2006 9:14 PM
> To: Haruki Dai-r35557
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] Fix MPC8548CDS rebooting procedure
>=20
>=20
> On Mar 8, 2006, at 1:24 PM, Haruki Dai-r35557 wrote:
>=20
> >> -----Original Message-----
> >> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> >> Sent: Wednesday, March 08, 2006 12:33 PM
> >> To: Haruki Dai-r35557
> >> Cc: linuxppc-dev@ozlabs.org
> >> Subject: Re: [PATCH] Fix MPC8548CDS rebooting procedure
> >>
> >>
> >> On Mar 8, 2006, at 11:22 AM, Haruki Dai-r35557 wrote:
> >>
> >>> This patch fixes the MPC8548 CDS rebooting procedure.
> >>> Without this patche, issuing reboot from shell doesn't reboot the=20
> >>> machine.
> >>>
> >>> Signed-off-by: Dai Haruki <dai.haruki@freescale.com>
> >>
> >> Dai, I'm avoid taking patches for 85xx that effect new=20
> functionality. =20
> >> If you want change this to work with arch/powerpc and make=20
> it a run=20
> >> time check for 8548.
> >
> > Hi Kumar, what kind of new feature is affected by this bug=20
> fix? 8548=20
> > requires reboot to set the hardware reset bits. The mpc85xx_restart
> > () is
> > not ported to arch/powerpc yet. Which portion of the=20
> arch/powerpc code=20
> > should be modified in order to restart the machine correctly?
> > And how do you want me to do run time check? Check SVR?
>=20
> Restart has never worked properly on the 85xx boards from=20
> freescale since they never provided a reasonable way to reset=20
> the systems in software. So I consider this new=20
> functionality at this point.
>=20
> The powerpc.git tree has an=20
> arch/powerpc/platforms/85xx/misc.c that has a mpc85xx_restart() in it.
Thanks. I didn't work on the powerpc.git tree. I will submit the patch
based on the powerpc.git tree.
>=20
> As for run time checking, yes use something like SVR or PVR=20
> to determine the feature. In this case its probably best to=20
> using something like PVR and check for E500r1. I imagine=20
> 8540, 8541, 8555, 8560 don't support this feature (all=20
> e500r1), but all future 8548 and newer parts will (e500r2, etc.)
OK. I will modify it as you suggest.=20
regards,
Dai.
>=20
> - kumar
>=20
^ permalink raw reply
* Re: [PATCH] Fix MPC8548CDS rebooting procedure
From: Kumar Gala @ 2006-03-09 3:13 UTC (permalink / raw)
To: Haruki Dai-r35557; +Cc: linuxppc-dev
In-Reply-To: <18AEF66AFDF06F4CAAA1D419D000FD332ECDEA@az33exm24.fsl.freescale.net>
On Mar 8, 2006, at 1:24 PM, Haruki Dai-r35557 wrote:
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak@kernel.crashing.org]
>> Sent: Wednesday, March 08, 2006 12:33 PM
>> To: Haruki Dai-r35557
>> Cc: linuxppc-dev@ozlabs.org
>> Subject: Re: [PATCH] Fix MPC8548CDS rebooting procedure
>>
>>
>> On Mar 8, 2006, at 11:22 AM, Haruki Dai-r35557 wrote:
>>
>>> This patch fixes the MPC8548 CDS rebooting procedure.
>>> Without this patche, issuing reboot from shell doesn't reboot the
>>> machine.
>>>
>>> Signed-off-by: Dai Haruki <dai.haruki@freescale.com>
>>
>> Dai, I'm avoid taking patches for 85xx that effect new
>> functionality. If you want change this to work with
>> arch/powerpc and make it a run time check for 8548.
>
> Hi Kumar, what kind of new feature is affected by this bug fix? 8548
> requires reboot to set the hardware reset bits. The mpc85xx_restart
> () is
> not ported to arch/powerpc yet. Which portion of the arch/powerpc code
> should be modified in order to restart the machine correctly?
> And how do you want me to do run time check? Check SVR?
Restart has never worked properly on the 85xx boards from freescale
since they never provided a reasonable way to reset the systems in
software. So I consider this new functionality at this point.
The powerpc.git tree has an arch/powerpc/platforms/85xx/misc.c that
has a mpc85xx_restart() in it.
As for run time checking, yes use something like SVR or PVR to
determine the feature. In this case its probably best to using
something like PVR and check for E500r1. I imagine 8540, 8541, 8555,
8560 don't support this feature (all e500r1), but all future 8548 and
newer parts will (e500r2, etc.)
- kumar
^ permalink raw reply
* Re: please pull powerpc-merge.git
From: Paul Mackerras @ 2006-03-09 0:55 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, torvalds
In-Reply-To: <20060308080816.GA16866@suse.de>
Olaf Hering writes:
> On Wed, Mar 08, Paul Mackeras wrote:
>
> > powerpc: incorrect rmo_top handling in prom_init
>
> I would leave this one out. It gives the false impression that ibook1
> works ok, while later it will likely eat your filesystem. Its not a
> regression in that sense because 2.6.15 was also broken and noone
> complained.
Ben H and I agree that the fix makes sense and is correct and should
go in for 2.6.16. Your iBook crashes are a separate problem.
Paul.
^ permalink raw reply
* [Patch] Fix compile error for ML300/403
From: Grant Likely @ 2006-03-08 23:07 UTC (permalink / raw)
To: linuxppc-embedded list, Matt Porter, Paul Mackerras
Fix compile error due to changes in ppc_sys.c. This is needed in the
powerpc.git tree
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
commit 75ec8a6ff8410c30f459e5e1c924ce811f8b1e25
tree 87f29c44458d2966bf208f9ea25432b26faa2eb5
parent 126dddf2535520cbeafb7069ce092b80beb8558a
author Grant Likely <grant.likely@secretlab.ca> Wed, 08 Mar 2006 16:03:56 -=
0700
committer <grant@weasley-twins.(none)> Wed, 08 Mar 2006 16:03:56 -0700
arch/ppc/platforms/4xx/virtex.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/ppc/platforms/4xx/virtex.h b/arch/ppc/platforms/4xx/virte=
x.h
index 2a2a65c..4d893ef 100644
--- a/arch/ppc/platforms/4xx/virtex.h
+++ b/arch/ppc/platforms/4xx/virtex.h
@@ -27,7 +27,7 @@
/* Device type enumeration for platform bus definitions */
#ifndef __ASSEMBLY__
enum ppc_sys_devices {
- VIRTEX_UART, VIRTEX_FB,
+ VIRTEX_UART, VIRTEX_FB, NUM_PPC_SYS_DEVS,
};
#endif
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 399-0195
^ permalink raw reply related
* Re: linux DMA capabilities in MV64460
From: Adrian Cox @ 2006-03-08 22:36 UTC (permalink / raw)
To: Phil.Nitschke; +Cc: linuxppc-embedded
In-Reply-To: <kwlkvomcxp.fsf@lamorak.int.avalon.com.au>
On Mon, 2006-03-06 at 14:39 +1030, Phil Nitschke wrote:
> How is a DMA controlled (from a device driver writer's perspective) when
> a third-party (i.e. in the bridge) DMA controller needs to do the work
> to get the data from a PCI Target into main memory?
>
> What kernel API should be provided by the DMA Controller Driver?
There is no current API for this in the kernel, but there are some
proposals. From Intel, we have I/OAT, which targets network operations:
http://lkml.org/lkml/2006/3/3/219
There's some overlap with the ADMA feature set, which is intended to
accelerate RAID operations:
http://lkml.org/lkml/2006/2/2/442
--
Adrian Cox <adrian@humboldt.co.uk>
^ permalink raw reply
* [PATCH] Fix platform_notify functions marked __init
From: Adrian Cox @ 2006-03-08 22:10 UTC (permalink / raw)
To: linuxppc-dev
While adding USB support to an MV64360 based board this week, I
discovered that all MV64x60 boards in the kernel have platform_notify
functions marked with __init. This causes an oops if a device is added
after boot.
The patch below removes the __init markers. I do not have all these
boards to test on, but the change seems very unlikely to break anything
else.
Signed-off-by: Adrian Cox <adrian@humboldt.co.uk>
diff --git a/arch/ppc/platforms/cpci690.c b/arch/ppc/platforms/cpci690.c
index 6ca7bca..ad1a21e 100644
--- a/arch/ppc/platforms/cpci690.c
+++ b/arch/ppc/platforms/cpci690.c
@@ -290,7 +290,7 @@ cpci690_fixup_mpsc_pdata(struct platform
pdata->brg_clk_freq = cpci690_get_bus_freq();
}
-static int __init
+static int
cpci690_platform_notify(struct device *dev)
{
static struct {
diff --git a/arch/ppc/platforms/ev64260.c b/arch/ppc/platforms/ev64260.c
index ffde8f6..fea4cf8 100644
--- a/arch/ppc/platforms/ev64260.c
+++ b/arch/ppc/platforms/ev64260.c
@@ -416,7 +416,7 @@ ev64260_fixup_mpsc_pdata(struct platform
return;
}
-static int __init
+static int
ev64260_platform_notify(struct device *dev)
{
static struct {
diff --git a/arch/ppc/platforms/ev64360.c b/arch/ppc/platforms/ev64360.c
index b9d844f..e8cc999 100644
--- a/arch/ppc/platforms/ev64360.c
+++ b/arch/ppc/platforms/ev64360.c
@@ -300,7 +300,7 @@ ev64360_fixup_eth_pdata(struct platform_
}
#endif
-static int __init
+static int
ev64360_platform_notify(struct device *dev)
{
static struct {
diff --git a/arch/ppc/platforms/hdpu.c b/arch/ppc/platforms/hdpu.c
index 50039a2..c79e589 100644
--- a/arch/ppc/platforms/hdpu.c
+++ b/arch/ppc/platforms/hdpu.c
@@ -354,7 +354,7 @@ static void __init hdpu_fixup_cpustate_p
}
#endif
-static int __init hdpu_platform_notify(struct device *dev)
+static int hdpu_platform_notify(struct device *dev)
{
static struct {
char *bus_id;
diff --git a/arch/ppc/platforms/katana.c b/arch/ppc/platforms/katana.c
index 6e58e30..b655e53 100644
--- a/arch/ppc/platforms/katana.c
+++ b/arch/ppc/platforms/katana.c
@@ -598,7 +598,7 @@ katana_fixup_mv64xxx_pdata(struct platfo
}
#endif
-static int __init
+static int
katana_platform_notify(struct device *dev)
{
static struct {
diff --git a/arch/ppc/platforms/radstone_ppc7d.c b/arch/ppc/platforms/radstone_ppc7d.c
index 872c0a3..d5c3e92 100644
--- a/arch/ppc/platforms/radstone_ppc7d.c
+++ b/arch/ppc/platforms/radstone_ppc7d.c
@@ -712,7 +712,7 @@ ppc7d_fixup_i2c_pdata(struct platform_de
}
#endif
-static int __init ppc7d_platform_notify(struct device *dev)
+static int ppc7d_platform_notify(struct device *dev)
{
static struct {
char *bus_id;
--
Adrian Cox <adrian@humboldt.co.uk>
^ permalink raw reply related
* Re: Yosemite board ala, PPC405EP
From: David Hawkins @ 2006-03-08 21:33 UTC (permalink / raw)
To: Jeff.Fellin; +Cc: linuxppc-embedded
In-Reply-To: <OF983EDDB6.1E8E12C2-ON8525712B.00750324@teal.com>
> Sorry, I was confused. I have a PPC405EP. not a Yosemite board.
Ok, sorry then, I can't help.
Take a look at the Denx web site, they have a bunch of
BDI2000 configuration files, I'm not sure whether they
have a 405EP, but take a look.
Dave
^ permalink raw reply
* Re: Yosemite board ala, PPC405EP
From: Jeff.Fellin @ 2006-03-08 21:18 UTC (permalink / raw)
To: dwh; +Cc: linuxppc-embedded
Sorry, I was confused. I have a PPC405EP. not a Yosemite board.
Jeff Fellin
RFL Electronics
Jeff.Fellin@rflelect.com
973 334-3100, x 327
David Hawkins
<dwh@ovro.caltech To: Jeff.Fellin@rflelect.com
.edu> cc: linuxppc-embedded@ozlabs.org
Subject: Re: Yosemite board ala, PPC405EP
03/08/2006 15:27
Jeff.Fellin@rflelect.com wrote:
> I have been using an Albatron BDI for a PPC405GP board in a project.
> According to the documentation I've read the Yosemite board is identical
> register wise to the 405GP, except for two sets of EMAC registers.
>
> My problem is when I use the Albatron BDI using the register definitions
> for the 405GP, the BDI cannot communicate with the 405EP.
>
> Anyone have experience with usingg the BDI for the PPC 405EP?
Hey Jeff,
Can you please clarify;
Are you using a Yosemite board (440EP) or are you using a 405EP board
(which is *not* the Yosemite board)?
If you are using the Yosemite board, then I have one here,
and my BDI2000 just arrived. I haven't had a chance to test
the BDI2000, but I can let you know the results when I do.
Dave
^ permalink raw reply
* Re: Yosemite board ala, PPC405EP
From: David Hawkins @ 2006-03-08 20:27 UTC (permalink / raw)
To: Jeff.Fellin; +Cc: linuxppc-embedded
In-Reply-To: <OFFBE09E88.DB8A5C68-ON8525712B.006C3D78@teal.com>
Jeff.Fellin@rflelect.com wrote:
> I have been using an Albatron BDI for a PPC405GP board in a project.
> According to the documentation I've read the Yosemite board is identical
> register wise to the 405GP, except for two sets of EMAC registers.
>
> My problem is when I use the Albatron BDI using the register definitions
> for the 405GP, the BDI cannot communicate with the 405EP.
>
> Anyone have experience with usingg the BDI for the PPC 405EP?
Hey Jeff,
Can you please clarify;
Are you using a Yosemite board (440EP) or are you using a 405EP board
(which is *not* the Yosemite board)?
If you are using the Yosemite board, then I have one here,
and my BDI2000 just arrived. I haven't had a chance to test
the BDI2000, but I can let you know the results when I do.
Dave
^ permalink raw reply
* Re: Yosemite board ala, PPC405EP
From: Eugene Surovegin @ 2006-03-08 20:21 UTC (permalink / raw)
To: Jeff.Fellin; +Cc: linuxppc-embedded
In-Reply-To: <OFFBE09E88.DB8A5C68-ON8525712B.006C3D78@teal.com>
On Wed, Mar 08, 2006 at 02:45:54PM -0500, Jeff.Fellin@rflelect.com wrote:
>
> I have been using an Albatron BDI for a PPC405GP board in a project.
> According to the documentation I've read the Yosemite board is identical
> register wise to the 405GP, except for two sets of EMAC registers.
>
> My problem is when I use the Albatron BDI using the register definitions
> for the 405GP, the BDI cannot communicate with the 405EP.
>
> Anyone have experience with usingg the BDI for the PPC 405EP?
AFAIK, Yosemite is 440EP, not 405EP. And 440EP is quite different from
405GP.
--
Eugene
^ permalink raw reply
* Yosemite board ala, PPC405EP
From: Jeff.Fellin @ 2006-03-08 19:45 UTC (permalink / raw)
To: linuxppc-embedded
I have been using an Albatron BDI for a PPC405GP board in a project.
According to the documentation I've read the Yosemite board is identical
register wise to the 405GP, except for two sets of EMAC registers.
My problem is when I use the Albatron BDI using the register definitions
for the 405GP, the BDI cannot communicate with the 405EP.
Anyone have experience with usingg the BDI for the PPC 405EP?
Thank you in advance for you help.
Jeff Fellin
RFL Electronics
Jeff.Fellin@rflelect.com
973 334-3100, x 327
^ permalink raw reply
* [PATCH] add a raw dump command to xmon
From: Olaf Hering @ 2006-03-08 19:40 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
Dump a stream of rawbytes with a new 'dr' command.
Produces less output and it is simpler to feed the output to scripts.
Also, dr has no dumpsize limits.
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/xmon/xmon.c | 30 ++++++++++++++++++++++++++++++
1 files changed, 30 insertions(+)
Index: linux-2.6.16-rc5-olh/arch/powerpc/xmon/xmon.c
===================================================================
--- linux-2.6.16-rc5-olh.orig/arch/powerpc/xmon/xmon.c
+++ linux-2.6.16-rc5-olh/arch/powerpc/xmon/xmon.c
@@ -191,6 +191,7 @@ Commands:\n\
di dump instructions\n\
df dump float values\n\
dd dump double values\n\
+ dr dump stream of raw bytes\n\
e print exception information\n\
f flush cache\n\
la lookup symbol+offset of specified address\n\
@@ -1938,6 +1939,28 @@ bsesc(void)
return c;
}
+static void xmon_rawdump (unsigned long adrs, long ndump)
+{
+ long n, m, r, nr;
+ unsigned char temp[16];
+
+ for (n = ndump; n > 0;) {
+ r = n < 16? n: 16;
+ nr = mread(adrs, temp, r);
+ adrs += nr;
+ for (m = 0; m < r; ++m) {
+ if (m < nr)
+ printf("%.2x", temp[m]);
+ else
+ printf("%s", fault_chars[fault_type]);
+ }
+ n -= r;
+ if (nr < r)
+ break;
+ }
+ printf("\n");
+}
+
#define isxdigit(c) (('0' <= (c) && (c) <= '9') \
|| ('a' <= (c) && (c) <= 'f') \
|| ('A' <= (c) && (c) <= 'F'))
@@ -1960,6 +1983,13 @@ dump(void)
nidump = MAX_DUMP;
adrs += ppc_inst_dump(adrs, nidump, 1);
last_cmd = "di\n";
+ } else if (c == 'r') {
+ scanhex(&ndump);
+ if (ndump == 0)
+ ndump = 64;
+ xmon_rawdump(adrs, ndump);
+ adrs += ndump;
+ last_cmd = "dr\n";
} else {
scanhex(&ndump);
if (ndump == 0)
^ permalink raw reply
* RE: [PATCH] Fix MPC8548CDS rebooting procedure
From: Haruki Dai-r35557 @ 2006-03-08 19:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
> Sent: Wednesday, March 08, 2006 12:33 PM
> To: Haruki Dai-r35557
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] Fix MPC8548CDS rebooting procedure
>=20
>=20
> On Mar 8, 2006, at 11:22 AM, Haruki Dai-r35557 wrote:
>=20
> > This patch fixes the MPC8548 CDS rebooting procedure.
> > Without this patche, issuing reboot from shell doesn't reboot the=20
> > machine.
> >
> > Signed-off-by: Dai Haruki <dai.haruki@freescale.com>
>=20
> Dai, I'm avoid taking patches for 85xx that effect new=20
> functionality. If you want change this to work with=20
> arch/powerpc and make it a run time check for 8548.
Hi Kumar, what kind of new feature is affected by this bug fix? 8548
requires reboot to set the hardware reset bits. The mpc85xx_restart() is
not ported to arch/powerpc yet. Which portion of the arch/powerpc code
should be modified in order to restart the machine correctly?=20
And how do you want me to do run time check? Check SVR?=20
Dai=20
>=20
> - kumar
>=20
> > ---
> >
> > arch/ppc/syslib/ppc85xx_setup.c | 5 +++++
> > 1 files changed, 5 insertions(+), 0 deletions(-)
> >
> > 8f095006923385c3546165b0e10d73d3e057c120
> > diff --git a/arch/ppc/syslib/ppc85xx_setup.c=20
> > b/arch/ppc/syslib/ppc85xx_setup.c index e4dda43..45b1b2b 100644
> > --- a/arch/ppc/syslib/ppc85xx_setup.c
> > +++ b/arch/ppc/syslib/ppc85xx_setup.c
> > @@ -115,6 +115,11 @@ mpc85xx_early_serial_map(void) void =20
> > mpc85xx_restart(char *cmd) {
> > +#ifdef CONFIG_MPC8548
> > + volatile unsigned int *rstcr;
> > + u32 *pMem =3D (u32*) ioremap((BOARD_CCSRBAR + 0xe00b0),0x100);
> > + *pMem =3D 0x2; /* Set HRESET_REQ flag */ #endif
> > local_irq_disable();
> > abort();
> > }
> > --
> > 1.2.4
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
>=20
>=20
^ permalink raw reply
* Re: [PATCH] Fix MPC8548CDS rebooting procedure
From: Kumar Gala @ 2006-03-08 18:33 UTC (permalink / raw)
To: Haruki Dai-r35557; +Cc: linuxppc-dev
In-Reply-To: <18AEF66AFDF06F4CAAA1D419D000FD332ECDA6@az33exm24.fsl.freescale.net>
On Mar 8, 2006, at 11:22 AM, Haruki Dai-r35557 wrote:
> This patch fixes the MPC8548 CDS rebooting procedure.
> Without this patche, issuing reboot from shell doesn't reboot the
> machine.
>
> Signed-off-by: Dai Haruki <dai.haruki@freescale.com>
Dai, I'm avoid taking patches for 85xx that effect new
functionality. If you want change this to work with arch/powerpc and
make it a run time check for 8548.
- kumar
> ---
>
> arch/ppc/syslib/ppc85xx_setup.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> 8f095006923385c3546165b0e10d73d3e057c120
> diff --git a/arch/ppc/syslib/ppc85xx_setup.c
> b/arch/ppc/syslib/ppc85xx_setup.c
> index e4dda43..45b1b2b 100644
> --- a/arch/ppc/syslib/ppc85xx_setup.c
> +++ b/arch/ppc/syslib/ppc85xx_setup.c
> @@ -115,6 +115,11 @@ mpc85xx_early_serial_map(void)
> void
> mpc85xx_restart(char *cmd)
> {
> +#ifdef CONFIG_MPC8548
> + volatile unsigned int *rstcr;
> + u32 *pMem = (u32*) ioremap((BOARD_CCSRBAR + 0xe00b0),0x100);
> + *pMem = 0x2; /* Set HRESET_REQ flag */
> +#endif
> local_irq_disable();
> abort();
> }
> --
> 1.2.4
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH] Fix MPC8548CDS rebooting procedure
From: Haruki Dai-r35557 @ 2006-03-08 17:22 UTC (permalink / raw)
To: linuxppc-dev
This patch fixes the MPC8548 CDS rebooting procedure.
Without this patche, issuing reboot from shell doesn't reboot the
machine.=20
Signed-off-by: Dai Haruki <dai.haruki@freescale.com>
---
arch/ppc/syslib/ppc85xx_setup.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
8f095006923385c3546165b0e10d73d3e057c120
diff --git a/arch/ppc/syslib/ppc85xx_setup.c
b/arch/ppc/syslib/ppc85xx_setup.c
index e4dda43..45b1b2b 100644
--- a/arch/ppc/syslib/ppc85xx_setup.c
+++ b/arch/ppc/syslib/ppc85xx_setup.c
@@ -115,6 +115,11 @@ mpc85xx_early_serial_map(void)
void
mpc85xx_restart(char *cmd)
{
+#ifdef CONFIG_MPC8548
+ volatile unsigned int *rstcr;
+ u32 *pMem =3D (u32*) ioremap((BOARD_CCSRBAR + 0xe00b0),0x100);
+ *pMem =3D 0x2; /* Set HRESET_REQ flag */
+#endif
local_irq_disable();
abort();
}
--=20
1.2.4
^ permalink raw reply related
* RE: Stable Linux kernel 2.6 for MPC8XX
From: Fillod Stephane @ 2006-03-08 14:29 UTC (permalink / raw)
To: Laurent Lagrange, linuxppc-embedded
>I would want to use a linux kernel 2.6 on a custom MPC8xx board.
>Which stable kernel release must or can I use ?
http://www.denx.de/wiki/bin/view/Know/Linux24vs26
--=20
SF
^ permalink raw reply
* Stable Linux kernel 2.6 for MPC8XX
From: Laurent Lagrange @ 2006-03-08 14:32 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <000201c63c44$14a9c1b0$5201a8c0@GEG2400>
Hello,
I would want to use a linux kernel 2.6 on a custom MPC8xx board.
Which stable kernel release must or can I use ?
Thanks
Laurent
^ permalink raw reply
* Re: linux DMA capabilities in MV64460
From: Phil Nitschke @ 2006-03-08 14:02 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Brian Waite
In-Reply-To: <200603060821.29220.brian@waitefamily.us>
>>>>> "BW" == Brian Waite <brian@waitefamily.us> writes:
>> I'm now looking seriously (and reluctantly!) at writing a DMA
>> Controller Driver to supplement these functions, and I've started
>> the process of getting an NDA from Marvell, so I can get their
>> User Manual (and errata!).
BW> You won't get very far without the user manual, then I think you
BW> will find it pretty easy to write the driver with the frameworks
BW> already in the kernel.
>> Can someone point me in the right direction to get me started? I
>> need to come up the learning curve to find out where to start.
>>
>> How is a DMA controlled (from a device driver writer's
>> perspective) when a third-party (i.e. in the bridge) DMA
>> controller needs to do the work to get the data from a PCI Target
>> into main memory?
>>
>> What kernel API should be provided by the DMA Controller Driver?
BW> My first guess would be to follow something like
BW> Documentation/DMA-API.txt and Documentation/DMA-mapping.txt
I can't see how trying to match those DMA functions would work.
The dma_map_xxx() functions and friends appear to be invoked from
driver interrupt handlers, which are either responding to an interrupt
from a PCI Target which wants to commence a bus-mastered DMA to/from
main memory, or responding to a second interrupt to say the interrupt
is complete.
In my case, my driver receives one interrupt from a PCI Target which
cannot perform a DMA, and I presumably have to use an alternative API
(i.e. my "new" set of ("DMA Controller") driver functions) to get the
platform DMA controller to fetch the data and wake (interrupt) me once
complete. Right?
>> Any documentation, examples, similar device drivers, etc, would
>> be appreciated. TIA,
BW> You could look to followup that by groking
BW> arch/ppc/kernel/dma-mapping.c
OK.
BW> Finally, arch/ppc/syslib ppc4xx_dma.c seems to show an example
BW> of a low level driver.
OK, so suppose I write a bunch of functions, like this:
mv64x60_disable_dma();
mv64x60_disable_dma_interrupt();
mv64x60_enable_dma();
mv64x60_enable_dma_interrupt();
mv64x60_get_dma_status();
mv64x60_init_dma_channel();
... etc,
then how do these get called; directly from my other driver?
(I could not see any place that the ppc4xx_ dma functions were being
called, i.e. they don't seem to dovetail into some higher level kernel
API...?)
BW> I didn't notice any platform dma controllers like MAG
BW> reccommended, but that should be a better way to go.
Perhaps Mark was talking about ppc4xx_dma.c and ppc4xx_sgdma.c ?
Sorry if I'm too slow on the uptake. Thanks for your input,
--
Phil
^ permalink raw reply
* bdi2000 config file
From: Mustafa Çayır @ 2006-03-08 10:09 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
Are thare any guide about generating bdi2000 config file ?
I'm working on board MVME6100. are there bdi2000 config file of this =
board? Or, anyone has a bdi2000 config file of a board that has marvell =
64360 bridge?
thanks .
^ permalink raw reply
* Re: How to quickly write cleanmarkers to jffs2 partitions?
From: David Jander @ 2006-03-08 8:38 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1141647684.23522.7.camel@linpc041.aimsys.nl>
On Monday 06 March 2006 13:21, Jaap-Jan Boor wrote:
> On Fri, 2006-03-03 at 10:08 +0100, Mathieu Deschamps wrote:
> > Hi,
> >
> > "When preparing a flash partition for JFFS2, it is recommended to put
> > cleanmarkers to the erased blocks.
> > This might be done my means of "-j" option of the "flash_eraseall" MTD
> > utility. Otherwise, JFFS2 will re-erase the blocks
> > which contain all 0xFF and have no cleanmarker. This is an unneeded
> > wasting of time."
> >
> > Source : http://www.linux-mtd.infradead.org/faq/jffs2.html
> >
> > does this may be relevant ?
>
> This is correct, however flash_eraseall does also (as it's
> name suggests, erase all flash blocks, which takes
> some time on NOR flash. If you 'know' the flash is erased,
> it's not needed.
> I used flash_eraseall to write the cleanmarkers, but without
> erasing blocks (and called that utility cleanmark)
Thanks to all for the suggestions.
Is "cleanmark" an open-source tool? Would you share it?
Greetings,
--
David Jander
^ permalink raw reply
* Re: please pull powerpc-merge.git
From: Olaf Hering @ 2006-03-08 8:08 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, torvalds
In-Reply-To: <17422.16982.705624.256207@cargo.ozlabs.ibm.com>
On Wed, Mar 08, Paul Mackeras wrote:
> powerpc: incorrect rmo_top handling in prom_init
I would leave this one out. It gives the false impression that ibook1
works ok, while later it will likely eat your filesystem. Its not a
regression in that sense because 2.6.15 was also broken and noone
complained.
^ permalink raw reply
* please pull powerpc-merge.git
From: Paul Mackerras @ 2006-03-08 2:32 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do a pull from
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc-merge.git
There is just one new commit - the one from me fixing some problems in
the syscall entry/exit path. There are 8 commits still there from the
last pull request.
Thanks,
Paul.
Benjamin Herrenschmidt:
powerpc: Fix old g5 issues with windfarm
powerpc: Fix windfarm_pm112 not starting all control loops
powerpc: Expose SMT and L1 icache snoop userland features
powerpc: incorrect rmo_top handling in prom_init
David Gibson:
powerpc: Fix incorrect pud_ERROR() message
Paul Mackerras:
powerpc: Fix might-sleep warning in program check exception handler
powerpc: Turn off verbose debug output in powermac platform functions
powerpc32: Fix timebase synchronization on 32-bit powermacs
powerpc: Fix various syscall/signal/swapcontext bugs
arch/powerpc/kernel/asm-offsets.c | 1
arch/powerpc/kernel/cputable.c | 9 ++
arch/powerpc/kernel/entry_32.S | 95 +++++++-------------------
arch/powerpc/kernel/entry_64.S | 94 ++++++--------------------
arch/powerpc/kernel/prom_init.c | 2 -
arch/powerpc/kernel/ptrace.c | 5 -
arch/powerpc/kernel/signal_32.c | 19 +----
arch/powerpc/kernel/signal_64.c | 9 --
arch/powerpc/kernel/systbl.S | 2 -
arch/powerpc/kernel/traps.c | 2 +
arch/powerpc/platforms/powermac/pfunc_base.c | 5 +
arch/powerpc/platforms/powermac/pfunc_core.c | 6 ++
arch/powerpc/platforms/powermac/smp.c | 2 -
arch/ppc/kernel/asm-offsets.c | 1
arch/ppc/kernel/entry.S | 95 +++++++-------------------
drivers/macintosh/windfarm_core.c | 7 ++
drivers/macintosh/windfarm_cpufreq_clamp.c | 8 ++
drivers/macintosh/windfarm_lm75_sensor.c | 32 ++++++---
drivers/macintosh/windfarm_max6690_sensor.c | 25 +++++--
drivers/macintosh/windfarm_pm112.c | 8 +-
include/asm-powerpc/cputable.h | 2 +
include/asm-powerpc/pgtable-4k.h | 2 -
include/asm-powerpc/thread_info.h | 8 +-
23 files changed, 163 insertions(+), 276 deletions(-)
^ permalink raw reply
* Re: signal/syscall/swapcontext fixes
From: David Woodhouse @ 2006-03-07 23:36 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17421.62535.805543.661898@cargo.ozlabs.ibm.com>
On Wed, 2006-03-08 at 07:59 +1100, Paul Mackerras wrote:
> David Woodhouse writes:
>
> > The 64-bit version (bl .save_nvgprs) is prettier than the 32-bit version
> > (doing it longhand), and they're still gratuitously different. We should
> > probably fix that.
>
> There's also the difference where ret_from_except in 32-bit does what
> ret_from_except_lite does in 64-bit, and the 32-bit
> ret_from_except_full is approximately the same as the 64-bit
> ret_from_except. :)
Oh yeah -- I remember that now :)
> > On a similar note, we should also do a ptrace stop when we deliver
> > signals, to ensure that the debugger gets a stop _on_ the first
> > instruction of the handler. Once upon a time there was a stop in
> > handle_rt_signal() and handle_signal(), but doing it that way gave a
> > _double_ stop when we ended up in a signal handler from sigsuspend(),
> > because the syscall stop you just fixed for ppc32 happened too.
>
> Do we have a fix for this for 2.6.16, or will we leave it until
> 2.6.17?
It's hardly a showstopper -- I suspect we can happily leave it for now.
Adding the stops back where they were isn't perfect, and I thought I had
a better plan when I removed them. Buggered if I can remember it now
though.
> > On a purely cosmetic note I'm not sure about this though -- it was
> > slightly easier to follow when it was more explicit:
> > - andi. r0,r9,(_TIF_SYSCALL_T_OR_A|_TIF_SINGLESTEP|_TIF_SIGPENDING|_TIF_NEED_RESCHED|_TIF_RESTOREALL|_TIF_SAVE_NVGPRS|_TIF_NOERROR|_TIF_RESTORE_SIGMASK)
> > + andi. r0,r9,(_TIF_SYSCALL_T_OR_A|_TIF_SINGLESTEP|_TIF_USER_WORK_MASK|_TIF_PERSYSCALL_MASK)
>
> I did it that way because we are clearing _TIF_PERSYSCALL_MASK further
> down. If we expand one we should expand both.
Yeah, I suppose you're right.
--
dwmw2
^ permalink raw reply
* double fec on adder875
From: Antonio Di Bacco @ 2006-03-07 22:59 UTC (permalink / raw)
To: linuxppc-embedded
I found a patch to "fec.c" in 2.4 on http://patchwork.ozlabs.org/linuxppc/ to
make work both the fecs on mpc875.
Anyone used it? The patch is from Jan Damborsky.
The patch is in state "REJECTED"!!
What is http://patchwork.ozlabs.org/linuxppc/? Something you can post patches
that will be part of the official kernel?
Bye,
Antonio.
^ 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