* Re: MPC85xx DMA support for Kernel 2.6?
From: Murray.Jensen @ 2005-07-01 8:36 UTC (permalink / raw)
To: Clemens Koller; +Cc: linuxppc-embedded
In-Reply-To: <42C4F6C4.1070908@anagramm.de>
On Fri, 01 Jul 2005 09:54:44 +0200, Clemens Koller writes:
>Is there any interest to publish this and the other patches
>and get it into 2.6 if not already planned?
Well, I'd certainly be interested. Cheers!
Murray...
--
Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853
Internet: Murray.Jensen@csiro.au
To the extent permitted by law, CSIRO does not represent, warrant and/or
guarantee that the integrity of this communication has been maintained or
that the communication is free of errors, virus, interception or interference.
The information contained in this e-mail may be confidential or privileged.
Any unauthorised use or disclosure is prohibited. If you have received this
e-mail in error, please delete it immediately and notify Murray Jensen on
+61 3 9662 7763. Thank you.
^ permalink raw reply
* Re: MPC85xx DMA support for Kernel 2.6?
From: Clemens Koller @ 2005-07-01 7:54 UTC (permalink / raw)
To: Murray.Jensen; +Cc: linuxppc-embedded
In-Reply-To: <931.1120150666@gerd>
Hi, Murray!
Hello, Jason!
Thank you very much! It seems like you saved my holiday! :-)))
I will have a look and see what I can find there.
Is there any interest to publish this and the other patches
and get it into 2.6 if not already planned?
Best regards,
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
Murray.Jensen@csiro.au wrote:
> On Thu, 30 Jun 2005 17:56:30 +0200, Clemens Koller writes:
>
>>But is there any code available for recycling?
>
>
> Jason McMullan has some code for mpc85xx dma here:
>
> http://www.evillabs.net/~gus/patches/mpc85xx_dma.patch
>
> Looks like it wouldn't take much to get it working. Cheers!
> Murray...
> --
> Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763
> Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853
> Internet: Murray.Jensen@csiro.au
>
> To the extent permitted by law, CSIRO does not represent, warrant and/or
> guarantee that the integrity of this communication has been maintained or
> that the communication is free of errors, virus, interception or interference.
>
> The information contained in this e-mail may be confidential or privileged.
> Any unauthorised use or disclosure is prohibited. If you have received this
> e-mail in error, please delete it immediately and notify Murray Jensen on
> +61 3 9662 7763. Thank you.
>
^ permalink raw reply
* Re: MPC85xx DMA support for Kernel 2.6?
From: Clemens Koller @ 2005-07-01 7:47 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <427c70958bb995dad4fbad2e6ff121bc@embeddededge.com>
Hi, Dan!
Dan Malek wrote:
> Before you start, just make sure such a thing is really a performance
> enhancement. Yes, the DMA does run in parallel with the core, but often
> the overhead of the set up and clean up interrupt is more code and time
> that if you just copied the data in a loop. If possible, integrate the DMA
> processing into other driver work, clean up a previous DMA the next time
> the driver needs to use it, not with a separate completion handler.
Well... thanks. But the CPU is intended to do image processing while
data comes in. And currently, when I access (memcopy) the SRAM on my
Local Bus via UPM I cannot get it to generate bursts yet, so I hope the
DMA will speed up those things, too.
Greets,
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
^ permalink raw reply
* Re: [PATCH] 8xx: map_page() skip pinned region and tlbie debugging aid
From: Pantelis Antoniou @ 2005-07-01 7:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linux-ppc-embedded
In-Reply-To: <1120174169.31924.55.camel@gaston>
Benjamin Herrenschmidt wrote:
> On Thu, 2005-06-30 at 14:05 -0400, Dan Malek wrote:
>
>>On Jun 29, 2005, at 7:31 PM, Benjamin Herrenschmidt wrote:
>>
>>
>>> - The debate between Dan and me here is about the semantics of
>>>io_block_mapping().
>>
>>My point of discussion is this function needs to be much smarter than
>>simply allocating a virtual address space. We need to track the calls
>>so that we can "grow" previous spaces. A single io_block_mapping()
>>should not always allocate a new BAT, CAM or otherwise wired entry.
>>It has to know the alignment, size and amount of resource available.
>>For example, if an io_block_mapping() requests a 4M space, and it
>>isn't possible to wire such a size, we still need to keep track of that
>>such that a subsequent 4M request is combined into a space that
>>can be wired with an 8M entry. We need to make it smart enough
>>to coalesce the spaces to maximize the use of the available and
>>minimal mapping resources. If io_block_mapping() is just a simple
>>functions that decrements a pointer and sets a value in a register,
>>then you have already required the caller to know everything about
>>the mapping details, so why bother performing "hidden" arithmetic
>>that is likely to be known by the caller? If we are going to change
>>this
>
>
> Everyting ... but the virtual address, which is quite a bit :) My
> problem is really with virtual addresses beeing hard coded, which makes
> things complicated every time we try to do something with the kenrel
> virtual space. But ....
>
>
>>let's make it tru
>>y useful, so it understands the capabilities of the
>>processor, optimizes the resources, and keeps generic mapping
>>information so ioremap() doesn't care if it is mapped by BATs, CAMs,
>>or large pages.
>
>
> ... I do agree that making it even smarter so it can coalesce block
> mappings with the same attributes would be "interesting".
>
> Ben.
>
>
Let me pop in here.
My remote heap allocator has these properties, i.e. it can
coalesce adjucent areas if they are of the same "key".
Back to the depths which I now reside...
Regards
Pantelis
^ permalink raw reply
* ¶l¥óµª¸ß
From: @ 2005-07-01 5:12 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 1318 bytes --]
^ permalink raw reply
* Re: [patch 1/1] Audit return code : drivers/macintosh/apm_emu.c
From: Benjamin Herrenschmidt @ 2005-07-01 0:51 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, domen, clucas
In-Reply-To: <20050701102741.50361e86.sfr@canb.auug.org.au>
On Fri, 2005-07-01 at 10:27 +1000, Stephen Rothwell wrote:
> On Fri, 01 Jul 2005 00:03:50 +0200 domen@coderock.org wrote:
> >
> > From: Christophe Lucas <clucas@rotomalug.org>
> >
> >
> > Audit return codes (and handle failure correctly) for misc_register.
>
> This patch was rejected against arch/i386/kernel/apm.c since the driver
> can still do useful things even if the misc_register fails. (I don't know
> if this is true for the ppc emulation, just a note).
Yes same for ppc, we still have the /proc entry which is useful.
Ben.
^ permalink raw reply
* Re: [patch 1/1] Audit return code : drivers/macintosh/apm_emu.c
From: Stephen Rothwell @ 2005-07-01 0:27 UTC (permalink / raw)
To: domen; +Cc: clucas, linuxppc-dev
In-Reply-To: <20050630220349.966609000@>
[-- Attachment #1: Type: text/plain, Size: 508 bytes --]
On Fri, 01 Jul 2005 00:03:50 +0200 domen@coderock.org wrote:
>
> From: Christophe Lucas <clucas@rotomalug.org>
>
>
> Audit return codes (and handle failure correctly) for misc_register.
This patch was rejected against arch/i386/kernel/apm.c since the driver
can still do useful things even if the misc_register fails. (I don't know
if this is true for the ppc emulation, just a note).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: eth0 autonegotation 8260
From: Wolfgang Denk @ 2005-06-30 23:54 UTC (permalink / raw)
To: Samuel Osorio Calvo; +Cc: linuxppc-embedded
In-Reply-To: <s2c4339f.015@scms1.sc.signaal.nl>
Dear Samuel,
in message <s2c4339f.015@scms1.sc.signaal.nl> you wrote:
>
...
> clocks and MDIO pins. I took changes somebody made with DENX's 2.4.18 and
> ported them to 2.4.25, probably forgeting something in the way....may be
> something related to interrupts interfaces has changed since then???
Ummm.... did you by chance try the currnt code in CVS, which is
2.4.25 based? I am not aware of any problems in that area, at least
not on the boards we use for regular testing.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Anyone who isn't confused here doesn't really know what's going on.
^ permalink raw reply
* Re: [PATCH] 8xx: map_page() skip pinned region and tlbie debugging aid
From: Benjamin Herrenschmidt @ 2005-06-30 23:29 UTC (permalink / raw)
To: Dan Malek; +Cc: linux-ppc-embedded
In-Reply-To: <f39d04caf822fc8e66fa3bb25606f08f@embeddededge.com>
On Thu, 2005-06-30 at 14:05 -0400, Dan Malek wrote:
> On Jun 29, 2005, at 7:31 PM, Benjamin Herrenschmidt wrote:
>
> > - The debate between Dan and me here is about the semantics of
> > io_block_mapping().
>
> My point of discussion is this function needs to be much smarter than
> simply allocating a virtual address space. We need to track the calls
> so that we can "grow" previous spaces. A single io_block_mapping()
> should not always allocate a new BAT, CAM or otherwise wired entry.
> It has to know the alignment, size and amount of resource available.
> For example, if an io_block_mapping() requests a 4M space, and it
> isn't possible to wire such a size, we still need to keep track of that
> such that a subsequent 4M request is combined into a space that
> can be wired with an 8M entry. We need to make it smart enough
> to coalesce the spaces to maximize the use of the available and
> minimal mapping resources. If io_block_mapping() is just a simple
> functions that decrements a pointer and sets a value in a register,
> then you have already required the caller to know everything about
> the mapping details, so why bother performing "hidden" arithmetic
> that is likely to be known by the caller? If we are going to change
> this
Everyting ... but the virtual address, which is quite a bit :) My
problem is really with virtual addresses beeing hard coded, which makes
things complicated every time we try to do something with the kenrel
virtual space. But ....
> let's make it tru
> y useful, so it understands the capabilities of the
> processor, optimizes the resources, and keeps generic mapping
> information so ioremap() doesn't care if it is mapped by BATs, CAMs,
> or large pages.
... I do agree that making it even smarter so it can coalesce block
mappings with the same attributes would be "interesting".
Ben.
^ permalink raw reply
* Re: eth0 autonegotation 8260
From: Ricardo Scop @ 2005-06-30 23:15 UTC (permalink / raw)
To: Samuel Osorio Calvo, markc, linuxppc-embedded
In-Reply-To: <s2c4339f.015@scms1.sc.signaal.nl>
Hi, Samuel
On Thursday 30 June 2005 13:01, Samuel Osorio Calvo wrote:
> First of all , thanks to all who replied,
>
> It is definetely related to interrupts since starting the target withou=
t
> the eth wire plugged enables me to login into the board. Of course, wit=
hout
> network connectivity......and whenever the wire is connected ->the boar=
d
> freezes again (no message, no panic, nothing....).
Well, some fcc-related interrupt is problably ocurring, then. You should=20
attach a BDI2000 to continue debugging, or at least put some printk in=20
fcc_enet code to see which interrupts are ocurring and what happens then.
>
> The boot process seems everything ok, the request_irq returns ok for b=
oth
> the mii and the fcc. I am not using a commercial board and some tuning =
were
> made to the kernel to adjust to the hardware configuration, mainly cloc=
ks
> and MDIO pins. I took changes somebody made with DENX's 2.4.18 and port=
ed
> them to 2.4.25, probably forgeting something in the way....may be somet=
hing
> related to interrupts interfaces has changed since then???
Yes, many things may have happened, but we don't know what because we don=
't=20
have your ported code...
HTH,
-Scop.
=2Eo.
=2E.o
ooo (http://www.catb.org/hacker-emblem/)
^ permalink raw reply
* [patch 1/1] Audit return code : drivers/macintosh/apm_emu.c
From: domen @ 2005-06-30 22:03 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, domen, Christophe Lucas
From: Christophe Lucas <clucas@rotomalug.org>
Audit return codes (and handle failure correctly) for misc_register.
Signed-off-by: Christophe Lucas <clucas@rotomalug.org>
Signed-off-by: Domen Puncer <domen@coderock.org>
---
apm_emu.c | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
Index: quilt/drivers/macintosh/apm_emu.c
===================================================================
--- quilt.orig/drivers/macintosh/apm_emu.c
+++ quilt/drivers/macintosh/apm_emu.c
@@ -515,19 +515,24 @@ static struct miscdevice apm_device = {
static int __init apm_emu_init(void)
{
+ int ret;
struct proc_dir_entry *apm_proc;
if (sys_ctrler != SYS_CTRLER_PMU) {
printk(KERN_INFO "apm_emu: Requires a machine with a PMU.\n");
return -ENODEV;
}
-
+
+ ret = misc_register(&apm_device);
+ if (ret) {
+ printk(KERN_WARNING "apm_emu: Unable to register misc device.\n");
+ return ret;
+ }
+
apm_proc = create_proc_info_entry("apm", 0, NULL, apm_emu_get_info);
if (apm_proc)
apm_proc->owner = THIS_MODULE;
- misc_register(&apm_device);
-
pmu_register_sleep_notifier(&apm_sleep_notifier);
printk(KERN_INFO "apm_emu: APM Emulation %s initialized.\n", driver_version);
--
^ permalink raw reply
* Re: PPC bn_div_words routine rewrite
From: David Ho @ 2005-06-30 22:22 UTC (permalink / raw)
To: openssl-dev, linuxppc-embedded
In-Reply-To: <4dd15d1805063003587276af7e@mail.gmail.com>
The reason I had to redo this routine, in case anyone is wondering, is
because ssh-keygen segfaults when this assembly routine returns junk
to the BN_div_word function. On a ppc, if you issue the command
ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_key -N ""
The program craps out when it tries to write the public key in ascii decima=
l.
Regards,
David=20
On 6/30/05, David Ho <davidkwho@gmail.com> wrote:
> Hi all,
>=20
> This is a rewrite of the bn_div_words routine for the PowerPC arch,
> tested on a MPC8xx processor.
> I initially thought there is maybe a small mistake in the code that
> requires a one-liner change but it turns out I have to redo the
> routine.
> I guess this routine is not called very often as I see that most other
> routines are hand-crafted, whereas this routine is compiled from a C
> function that apparently has not gone through a whole lot of testing.
>=20
> I wrote a C function to confirm correctness of the code.
>=20
> unsigned long div_words (unsigned long h,
> unsigned long l,
> unsigned long d)
> {
> unsigned long i_h; /* intermediate dividend */
> unsigned long i_q; /* quotient of i_h/d */
> unsigned long i_r; /* remainder of i_h/d */
>=20
> unsigned long i_cntr;
> unsigned long i_carry;
>=20
> unsigned long ret_q; /* return quotient */
>=20
> /* cannot divide by zero */
> if (d =3D=3D 0) return 0xffffffff;
>=20
> /* do simple 32-bit divide */
> if (h =3D=3D 0) return l/d;
>=20
> i_q =3D h/d;
> i_r =3D h - (i_q*d);
> ret_q =3D i_q;
>=20
> i_cntr =3D 32;
>=20
> while (i_cntr--)
> {
> i_carry =3D (l & 0x80000000) ? 1:0;
> l =3D l << 1;
>=20
> i_h =3D (i_r << 1) | i_carry;
> i_q =3D i_h/d;
> i_r =3D i_h - (i_q*d);
>=20
> ret_q =3D (ret_q << 1) | i_q;
> }
>=20
> return ret_q;
> }
>=20
>=20
> Then I handcrafted the routine in PPC assembly.
> The result is a 26 line assembly that is easy to understand and
> predictable as opposed to a 81liner that I am still trying to
> decipher...
> If anyone is interested in incorporating this routine to the openssl
> code I'll be happy to assist.
> At this point I think I will be taking a bit of a break from this 3
> day debugging/fixing marathon.
>=20
> Regards,
> David Ho
>=20
>=20
> #
> # Handcrafted version of bn_div_words
> #
> # r3 =3D h
> # r4 =3D l
> # r5 =3D d
>=20
> cmplwi 0,r5,0 # compare r5 and 0
> bc BO_IF_NOT,CR0_EQ,.Lppcasm_div1 # proceed if d!=3D0
> li r3,-1 # d=3D0 return -1
> bclr BO_ALWAYS,CR0_LT
> .Lppcasm_div1:
> cmplwi 0,r3,0 # compare r3 and 0
> bc BO_IF_NOT,CR0_EQ,.Lppcasm_div2 # proceed if h !=3D 0
> divwu r3,r4,r5 # ret_q =3D l/d
> bclr BO_ALWAYS,CR0_LT # return result in r3
> .Lppcasm_div2:
> divwu r9,r3,r5 # i_q =3D h/d
> mullw r10,r9,r5 # i_r =3D h - (i_q*d)
> subf r10,r10,r3
> mr r3,r9 # req_q =3D i_q
> .Lppcasm_set_ctr:
> li r12,32 # ctr =3D bitsizeof(d)
> mtctr r12
> .Lppcasm_div_loop:
> addc r4,r4,r4 # l =3D l << 1 -> i_carry
> adde r11,r10,r10 # i_h =3D (i_r << 1) | i_carry
> divwu r9,r11,r5 # i_q =3D i_h/d
> mullw r10,r9,r5 # i_r =3D i_h - (i_q*d)
> subf r10,r10,r11
> add r3,r3,r3 # ret_q =3D ret_q << 1 | i_q
> add r3,r3,r9
> bc BO_dCTR_NZERO,CR0_EQ,.Lppcasm_div_loop
> .Lppc_div_end:
> bclr BO_ALWAYS,CR0_LT # return result in r3
> .long 0x00000000
>
^ permalink raw reply
* ppc_htab.c and ppc7447A performance monitor registers
From: Ron Bianco @ 2005-06-30 21:29 UTC (permalink / raw)
To: Linuxppc-Embedded; +Cc: cort
Hi all,
( referring to kernel source as of 2.6.11 )
Among other things, Cort Dougan has provided support for usage of the
performance counters in 604 type cores via: /proc/ppc_htab.
This is great, but the required cpu feature: CPU_FTR_604_PERF_MON is not in
the list for the 7447 ppc family.
I guess there are differences related to the performance counter registers
and the monitor control registers between the the 604 core types and 7447,
but I haven't had time to research it.
I was wondering if anyone has upgraded: cputable.c and ppc_htab.c for use
with ppc types, other than 604, that have performance monitor registers and
if such code is publically available?
regards, Ron
^ permalink raw reply
* Re: MPC85xx DMA support for Kernel 2.6?
From: Dan Malek @ 2005-06-30 18:52 UTC (permalink / raw)
To: Clemens Koller; +Cc: linuxppc-embedded
In-Reply-To: <42C4162E.4030602@anagramm.de>
On Jun 30, 2005, at 11:56 AM, Clemens Koller wrote:
> *Sigh*... no holiday for me this summer .-(
Before you start, just make sure such a thing is really a performance
enhancement. Yes, the DMA does run in parallel with the core, but often
the overhead of the set up and clean up interrupt is more code and time
that if you just copied the data in a loop. If possible, integrate the
DMA
processing into other driver work, clean up a previous DMA the next time
the driver needs to use it, not with a separate completion handler.
Thanks.
-- Dan
^ permalink raw reply
* Re: [RFC][PATCH] ppc misusing NTP's time_offset value
From: Tom Rini @ 2005-06-30 17:41 UTC (permalink / raw)
To: john stultz; +Cc: Andrew Morton, lkml, linuxppc-dev
In-Reply-To: <1120082751.24889.120.camel@cog.beaverton.ibm.com>
On Wed, Jun 29, 2005 at 03:05:51PM -0700, john stultz wrote:
> Hey everyone,
>
> As part of my timeofday rework, I've been looking at the NTP code and I
> noticed that the PPC architecture is apparently misusing the NTP's
> time_offset (it is a terrible name!) value as some form of timezone
> offset. This could cause problems when time_offset changed by the NTP
> code.
>
> This patch changes the PPC code so it uses a more clear local variable:
> timezone_offset.
>
> Could a PPC maintainer verify this is correct?
As mentioned by Mikael, it's odd that this problem came up, since i
guess the wrong patch made it in. Andrew, please grab this if you
haven't already. Thanks.
Acked-by: Tom Rini <trini@kernel.crashing.org>
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [PATCH] 8xx: map_page() skip pinned region and tlbie debugging aid
From: Dan Malek @ 2005-06-30 18:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linux-ppc-embedded
In-Reply-To: <1120087888.31924.19.camel@gaston>
On Jun 29, 2005, at 7:31 PM, Benjamin Herrenschmidt wrote:
> - The debate between Dan and me here is about the semantics of
> io_block_mapping().
My point of discussion is this function needs to be much smarter than
simply allocating a virtual address space. We need to track the calls
so that we can "grow" previous spaces. A single io_block_mapping()
should not always allocate a new BAT, CAM or otherwise wired entry.
It has to know the alignment, size and amount of resource available.
For example, if an io_block_mapping() requests a 4M space, and it
isn't possible to wire such a size, we still need to keep track of that
such that a subsequent 4M request is combined into a space that
can be wired with an 8M entry. We need to make it smart enough
to coalesce the spaces to maximize the use of the available and
minimal mapping resources. If io_block_mapping() is just a simple
functions that decrements a pointer and sets a value in a register,
then you have already required the caller to know everything about
the mapping details, so why bother performing "hidden" arithmetic
that is likely to be known by the caller? If we are going to change
this,
let's make it truly useful, so it understands the capabilities of the
processor, optimizes the resources, and keeps generic mapping
information so ioremap() doesn't care if it is mapped by BATs, CAMs,
or large pages.
Thanks.
-- Dan
^ permalink raw reply
* Re: PCC440GX custom board configuration
From: Eugene Surovegin @ 2005-06-30 17:54 UTC (permalink / raw)
To: David Grab; +Cc: linuxppc-embedded
In-Reply-To: <003101c57d66$9de20a20$f201a8c0@SN7606>
On Thu, Jun 30, 2005 at 01:26:52PM +0200, David Grab wrote:
> Hello,
>
> i have a custom PPC 440 GX board which should run linux 2.6.11.6 kernel. I
> initialized the board with u-boot getting boot console on UART1 to start the
> kernel with bootm command.
>
> Hardware details:
> PPC 440 GX CPU
> 2 * 256 MB RAM
> 2 * 8 MB Flash
> EM Marvin RTC V3020 (seems not supported by linux?)
>
> Now i want to configure Linux to match my custom board. I ported my board
> based on ocotea board configuration files and excluded all the stuff i don?t
> need. My kernel seems to load but get stuck on calibrating delay loop and
> loops between update_proces_times and __delay (at address 0xC0003400) until
> it reboots. Seems like i didn?t match the BogoMips calculation. Actually i
> don?t use the RTC (i comment out all TODC functions). I think this cause the
> problem. So what i have to do to boot without RTC or has someone my RTC
> running with linux?
Most likely, you have incorrectly setup serial console, so you don't
see any messages. Then some other error happens and kernel panics,
it'll wait for 3min and then reboots. Try accessing printk buffer
through BDI or other hw debugger.
Also, RTC isn't required for Linux ti run.
--
Eugene
^ permalink raw reply
* Re: [PATCH] 8xx: map_page() skip pinned region and tlbie debugging aid
From: Dan Malek @ 2005-06-30 17:49 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-ppc-embedded
In-Reply-To: <20050629171906.GD4262@logos.cnet>
On Jun 29, 2005, at 1:19 PM, Marcelo Tosatti wrote:
> What do you mean "everyone should use ioremap() to map them"?
All software needs to invoke some kind of mapping function such
as ioremap() in the case of drivers or functions that access
peripherals.
You should not assume someone has done the mapping for you,
as we did in the past for some optimizations.
> Once the physical->virtual mapping for device IO space are set
> with io_block_mapping() (or with ioremap() for dynamic virtual
> addresses), why would you want to ioremap() the physical address
> again???
You shouldn't know that io_block_mapping() has done anything
for you. It is intended to be used as an optimization, not as a
replacement for ioremap(). The ioremap() function needs to be smart
enough to detect these optimizations and return efficient mappings
if that was done. If a platform decides to not use these optimizations
(which is sometimes beneficial for debugging), your software using
ioremap() should still work just fine.
> PS: I've had a quick try at converting the IMMAP to use
> ioremap instead (and have that dynamic virtual address stored
> in a pointer), changed drivers to use that pointer instead of
> hardcoded "IMMAP". Didnt work immediately :) Its not that the
> idea?
Yes, and we have done lots of this in the 82xx/83xx/85xx cpm2
drivers in 2.6. In fact, in 2.6 it has to be done.
Thanks.
-- Dan
^ permalink raw reply
* Re: MPC85xx DMA support for Kernel 2.6?
From: Murray.Jensen @ 2005-06-30 16:57 UTC (permalink / raw)
To: Clemens Koller; +Cc: linuxppc-embedded
In-Reply-To: <42C4162E.4030602@anagramm.de>
On Thu, 30 Jun 2005 17:56:30 +0200, Clemens Koller writes:
>But is there any code available for recycling?
Jason McMullan has some code for mpc85xx dma here:
http://www.evillabs.net/~gus/patches/mpc85xx_dma.patch
Looks like it wouldn't take much to get it working. Cheers!
Murray...
--
Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853
Internet: Murray.Jensen@csiro.au
To the extent permitted by law, CSIRO does not represent, warrant and/or
guarantee that the integrity of this communication has been maintained or
that the communication is free of errors, virus, interception or interference.
The information contained in this e-mail may be confidential or privileged.
Any unauthorised use or disclosure is prohibited. If you have received this
e-mail in error, please delete it immediately and notify Murray Jensen on
+61 3 9662 7763. Thank you.
^ permalink raw reply
* Re: eth0 autonegotation 8260
From: Samuel Osorio Calvo @ 2005-06-30 16:01 UTC (permalink / raw)
To: markc, linuxppc-embedded
First of all , thanks to all who replied,
It is definetely related to interrupts since starting the target without =
the eth wire plugged enables me to login into the board. Of course, =
without network connectivity......and whenever the wire is connected ->the =
board freezes again (no message, no panic, nothing....).
The boot process seems everything ok, the request_irq returns ok for both =
the mii and the fcc. I am not using a commercial board and some tuning =
were made to the kernel to adjust to the hardware configuration, mainly =
clocks and MDIO pins. I took changes somebody made with DENX's 2.4.18 and =
ported them to 2.4.25, probably forgeting something in the way....may be =
something related to interrupts interfaces has changed since then???=20
Any feedback will be higly wellcome,
Samuel.
Unclassified.
>>> "Mark Chambers" <markc@mail.com> 06/30/05 04:04PM >>>
>We are using a 8260 processor with ELDK 3.1.1, kernel 2.4.25 patched =
with
lck1. We have configured the kernel with USE_MDIO >and LXT971.
>The problem we face is that the boot process stops after displaying the
configuration of the card:
>eth0: config: autonegotiation on, 100FDX,...
>and after the board seems to freeze.
>
>Can anybody provide some feedback on how to check what can be misconfigure=
d
or where to look for the error???
Check that the interrupt from the LXT971 is configured correctly.
The code is probably waiting for this interrupt to tell it that negotiation=
is complete
Mark Chambers
^ permalink raw reply
* Re: MPC85xx DMA support for Kernel 2.6?
From: Clemens Koller @ 2005-06-30 15:56 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <658739DB-540F-4AFC-80DC-BBF0C2AD70F4@freescale.com>
Hi, Kumar...
> I'm not aware of anyone work on such a thing.
*Sigh*... no holiday for me this summer .-(
> I'd be more than happy
> to accept patches for it. I know several of us have written some APIs
> on top of the DMA for 85xx. Those however are non-standard APIs.
But is there any code available for recycling?
Are there any Freescale-FAE's with some snippets?
(Hello, world!)
I am about to start more or less from scratch and re-invent the wheel.
> What APIs exist for general purpose DMA engines? Last time I looked at
> this problem nothing really existed.
:-) I was wondering about that, too...
Maybe we can get some basics from this one:
Linux/Documentation/DMA-API.txt
And, well, code from:
asm-ppc/ppc4xx_dma.h
arch/ppc/syslib/ppc4xx_sgdma.c
and from the pci.h subsystem.
Hmm... and there is the factor that it's difficult to get
resources in my project for all that. :-(((
Best greets,
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
^ permalink raw reply
* Re: MPC85xx DMA support for Kernel 2.6?
From: Kumar Gala @ 2005-06-30 15:30 UTC (permalink / raw)
To: Clemens Koller; +Cc: linuxppc-embedded
In-Reply-To: <42C40BD0.8040408@anagramm.de>
On Jun 30, 2005, at 10:12 AM, Clemens Koller wrote:
> Hello!
>
> I am planning to use DMA/burst access for copying large chunks of data
> (100MBytes) from the Local Bus (UPM accessed SRAM) to System Memory
> (DDR)
> as fast as possible (200MBytes/s). (As you can guess, that's a
> framegrabber).
>
> As far as I have seen, the DMA engines of the MPC85xx (fsl-dma) are
> not
> supported in the classical way (dma_request(), free_dma()) in the
> kernel 2.6.x.
> The memory allocators in arch/ppc/dma-mapping.c seem to be usable,
> but there is no valuable dma support yet (true?).
>
> I can program the DMA Controllers in my MPC8540 on my own to
> achieve what I want
> but it would be great to get/produce/stick with as much cross-
> platform reusable
> code as possible.
>
> Is there any ongoing work to put DMA support for the mpc85xx and
> similar
> devices into the kernel? Is there any ongoing work in this area
> or is somebody working with the fsl-dma and can publish some code and
> share some ideas?
I'm not aware of anyone work on such a thing. I'd be more than happy
to accept patches for it. I know several of us have written some
APIs on top of the DMA for 85xx. Those however are non-standard APIs.
What APIs exist for general purpose DMA engines? Last time I looked
at this problem nothing really existed.
- kumar
^ permalink raw reply
* MPC85xx DMA support for Kernel 2.6?
From: Clemens Koller @ 2005-06-30 15:12 UTC (permalink / raw)
To: linuxppc-embedded
Hello!
I am planning to use DMA/burst access for copying large chunks of data
(100MBytes) from the Local Bus (UPM accessed SRAM) to System Memory (DDR)
as fast as possible (200MBytes/s). (As you can guess, that's a framegrabber).
As far as I have seen, the DMA engines of the MPC85xx (fsl-dma) are not
supported in the classical way (dma_request(), free_dma()) in the kernel 2.6.x.
The memory allocators in arch/ppc/dma-mapping.c seem to be usable,
but there is no valuable dma support yet (true?).
I can program the DMA Controllers in my MPC8540 on my own to achieve what I want
but it would be great to get/produce/stick with as much cross-platform reusable
code as possible.
Is there any ongoing work to put DMA support for the mpc85xx and similar
devices into the kernel? Is there any ongoing work in this area
or is somebody working with the fsl-dma and can publish some code and
share some ideas?
Best greets,
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
^ permalink raw reply
* Re: eth0 autonegotation 8260
From: Alex Zeffertt @ 2005-06-30 15:06 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20050630153233.42a63bda.ajz@cambridgebroadband.com>
>
> On a similar note... I've noticed that the fcc_enet driver does not appear to
> detect when the link goes down, or re-autonegotiate when it comes back up. I
> wonder if anybody has a fix for this?
>
> PS I too am using the ELDK 3.1.1 linux-2.4.25 kernel, but with a PM828 devel
> board.
Sorry all, I think I've spotted the problem now. From fcc_enet.c:
/* Some boards don't have the MDIRQ line connected (PM826 is such a board) */
Alex
^ permalink raw reply
* Re: eth0 autonegotation 8260
From: aris @ 2005-06-30 14:11 UTC (permalink / raw)
To: Samuel Osorio Calvo; +Cc: linuxppc-embedded
In-Reply-To: <s2c4153f.011@scms1.sc.signaal.nl>
> First of all sorry if this answer has been answered before, I have looked into the archives and did not find the answer.
>
> We are using a 8260 processor with ELDK 3.1.1, kernel 2.4.25 patched with lck1. We have configured the kernel with USE_MDIO and LXT971.
> The problem we face is that the boot process stops after displaying the configuration of the card:
> eth0: config: autonegotiation on, 100FDX,...
> and after the board seems to freeze.
>
> Following the code, I located the error in the startup command of the LXT971, concretely in the line setting the autonegotiation:
> {mk_mii_write(MII_REG_CR, 0x1200), NULL}, /* autonegotiate */
I have the same here but it doesn't freezes, it just doesn't works :).
(maybe it "freezes" because next step depends on the eth like RARP?)
I digged into LXT971 datasheet and 0x1200 appears to be correct. I was thinking
in add an module option to manually set it (and thus avoiding the need to use
ethtool). Any MII guru around to help us on this?
--
Aristeu
^ 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