* Re: Classic PPC specific ASM (CONFIG_6XX)
From: Jerome Glisse @ 2005-01-21 11:22 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc64-dev, linuxppc-dev
In-Reply-To: <20050120231442.GE2626@smtp.west.cox.net>
On Thu, 20 Jan 2005 16:14:42 -0700, Tom Rini <trini@kernel.crashing.org> wrote:
> On Wed, Jan 12, 2005 at 08:10:58PM +0100, Jerome Glisse wrote:
>
> > Wanted to know what is going on with CONFIG_6xx? You will use
> > my patch or do you have another better way ? :)
>
> Can you resend it please?
>
Here is another version (the previous one used ifdef to comment
out function call but i read somewhere that this doesn't follow
codeguideline). Anyway i think that my patch is a ugly hack.
Signed-off-by: Jerome Glisse <j.glisse@gmail.com>
best,
Jerome Glisse
diff -Naur linux/arch/ppc/boot/simple/misc-prep.c
linux-2.6.10/arch/ppc/boot/simple/misc-prep.c
--- linux/arch/ppc/boot/simple/misc-prep.c 2004-12-24 22:33:51.000000000 +0100
+++ linux-2.6.10/arch/ppc/boot/simple/misc-prep.c 2005-01-21
12:09:50.976426672 +0100
@@ -34,7 +34,11 @@
extern void serial_fixups(void);
extern struct bi_record *decompress_kernel(unsigned long load_addr,
int num_words, unsigned long cksum);
+#ifdef CONFIG_6XX
extern void disable_6xx_mmu(void);
+#elif
+void disable_6xx_mmu(void) {}
+#endif
extern unsigned long mpc10x_get_mem_size(void);
static void
^ permalink raw reply
* Re: [RFC] Option to disable mapping genrtc calls to ppc_md calls
From: Christoph Hellwig @ 2005-01-21 9:44 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev list
In-Reply-To: <41F04849.70506@mvista.com>
On Thu, Jan 20, 2005 at 05:09:45PM -0700, Mark A. Greer wrote:
> >In any case, as I wrote, the proper solution is to update genrtc to
> >define rtc_ops so that you get both a) and b), it shouldn't be hard to
> >update the archs using it.
> >
> >
>
> Yes but as I wrote, I don't have time right now.
You could have easily implemented it in the time you wasted arguing
here.
^ permalink raw reply
* Re: [RFC] Option to disable mapping genrtc calls to ppc_md calls
From: Geert Uytterhoeven @ 2005-01-21 9:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1106266338.18397.21.camel@gaston>
On Fri, 21 Jan 2005, Benjamin Herrenschmidt wrote:
> On Thu, 2005-01-20 at 17:09 -0700, Mark A. Greer wrote:
> > Yes but as I wrote, I don't have time right now.
>
> ... which is exactly my rant ... embedded companies never have time
> to do the right thing...
Because they have strict (paid for) deadlines, unlike the `we do it for
fun'-crowd led by Linus ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* USB Host Controller driver for ISP1362
From: s.deepak @ 2005-01-21 6:14 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1.1: Type: text/plain, Size: 669 bytes --]
Hi,
Anyone had worked on porting non PCI ISP 1362 host controller drivers to PPC processor?
We are using Philips ISP 1362 USB controller chip with ppc_405 processor in Non PCI platform.We are working on porting the standard ISP1362 host controller phci driver to our board on linux kernel 2.4.18.
We have made architecture specific changes to the hal driver provided by Philips and using the phci driver as if.
The host controller driver fails to assign the device address to the device and the RootHubStatusChange interrupt of ISP1362 seems to be always asserted.
Please provide me with some suggestions on this.
With Regards,
Deepak S
[-- Attachment #1.2: Type: text/html, Size: 1642 bytes --]
[-- Attachment #2: BitDefender.txt --]
[-- Type: text/plain, Size: 888 bytes --]
--
This message contains information from GDA Technologies Inc and affiliates, and is intended for the sole use of the individual and entity to whom it is addressed. It may contain information, including any attachments, that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended addressee, nor authorized to receive for the intended addressee, you are hereby notified that you may not use, copy, disclose or distribute to anyone the message or any information contained in the message. If you have received this electronic transmission in error, please notify the sender immediately by a "reply to sender only" message and destroy all electronic and hard copies of the communication, including attachments.
This message was scanned for spam and viruses by BitDefender.
For more information please visit http://linux.bitdefender.com/
^ permalink raw reply
* Re: [RFC] Option to disable mapping genrtc calls to ppc_md calls
From: Benjamin Herrenschmidt @ 2005-01-21 0:12 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev list
In-Reply-To: <41F04849.70506@mvista.com>
On Thu, 2005-01-20 at 17:09 -0700, Mark A. Greer wrote:
> Yes but as I wrote, I don't have time right now.
... which is exactly my rant ... embedded companies never have time
to do the right thing...
Ben.
^ permalink raw reply
* Re: [RFC] Option to disable mapping genrtc calls to ppc_md calls
From: Mark A. Greer @ 2005-01-21 0:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1106265672.5387.14.camel@gaston>
Benjamin Herrenschmidt wrote:
>On Thu, 2005-01-20 at 16:54 -0700, Mark A. Greer wrote:
>
>
>
>>Choosing a) give you more flexibility within PPC but is PPC only;
>>choosing b) is generic but assumes its the only rtc chip that will be
>>used by whatever kernel binary its put in.
>>
>>I chose b) and to reuse the genrtc code. In a sane world, reusing code
>>is considered a good thing...
>>
>>Its obvious that you and Tom prefer a). That's fine but if I switch to
>>a), I know the first comment I'll get when I post the driver to lmkl
>>will be, "Why would you make this ppc-specific when you could have made
>>it generic?" Will you and Tom then defend that decision for me?
>>
>>Also, this is not board-specific as you and Tom have tried to suggest.
>>Assuming I change the #ifdef in rtc.h to remove the option as I think
>>Tom and I are agreeing upon, you select the i2c algo/adapter, the
>>i2c/rtc client and its there. Where are the "gross hacks for every board"?
>>
>>
>
>Because it makes things like CONFIG_PPC_MULTIPLATFORM impossible, which
>means you end up with a CONFIG_* mess.
>
/me feels the anger... :)
>
>I consider that more important than re-using code.
>
Okay, it shall be so.
>
>In any case, as I wrote, the proper solution is to update genrtc to
>define rtc_ops so that you get both a) and b), it shouldn't be hard to
>update the archs using it.
>
>
Yes but as I wrote, I don't have time right now.
Mark
^ permalink raw reply
* Re: [RFC] Option to disable mapping genrtc calls to ppc_md calls
From: Benjamin Herrenschmidt @ 2005-01-21 0:01 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev list
In-Reply-To: <41F0449C.5020603@mvista.com>
On Thu, 2005-01-20 at 16:54 -0700, Mark A. Greer wrote:
> Choosing a) give you more flexibility within PPC but is PPC only;
> choosing b) is generic but assumes its the only rtc chip that will be
> used by whatever kernel binary its put in.
>
> I chose b) and to reuse the genrtc code. In a sane world, reusing code
> is considered a good thing...
>
> Its obvious that you and Tom prefer a). That's fine but if I switch to
> a), I know the first comment I'll get when I post the driver to lmkl
> will be, "Why would you make this ppc-specific when you could have made
> it generic?" Will you and Tom then defend that decision for me?
>
> Also, this is not board-specific as you and Tom have tried to suggest.
> Assuming I change the #ifdef in rtc.h to remove the option as I think
> Tom and I are agreeing upon, you select the i2c algo/adapter, the
> i2c/rtc client and its there. Where are the "gross hacks for every board"?
Because it makes things like CONFIG_PPC_MULTIPLATFORM impossible, which
means you end up with a CONFIG_* mess.
I consider that more important than re-using code.
In any case, as I wrote, the proper solution is to update genrtc to
define rtc_ops so that you get both a) and b), it shouldn't be hard to
update the archs using it.
Ben.
^ permalink raw reply
* Re: [RFC] Option to disable mapping genrtc calls to ppc_md calls
From: Mark A. Greer @ 2005-01-20 23:56 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
In-Reply-To: <20050120234708.GF2626@smtp.west.cox.net>
Tom Rini wrote:
>I don't know how we talked past eachother, but it would look exactly
>like it did in your patch. The only thing is that you don't ask the
>user, you make use of what the user told you already. This is a nice
>new feature of the 2.6 kconfig system. This is what I'm asking you to
>change from your first patch.
>
I don't know how we talked past each other either but as I wrote that
last email, I realized that was what you had already suggested. My bad
& my apologies.
Mark
^ permalink raw reply
* Re: [RFC] Option to disable mapping genrtc calls to ppc_md calls
From: Mark A. Greer @ 2005-01-20 23:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1106259956.18397.10.camel@gaston>
Benjamin Herrenschmidt wrote:
>
>The patch is going backward since it disables the ability to have
>runtime selection of the RTC chip.
>
Its only "backwards" from a narrow PPC point of view. Without a major
rewrite of the rtc infrastructure, these are the choices:
a) Make a ppc-only solution using ppc_md.xxx.
b) Make a generic solution either by writing an entire driver
duplicating code that's in genrtc (e.g., ds1302) or interface to the
bottom of genrtc (e.g., my rtc code). The only limitation is that you
can't select different rtc chips at runtime.
Choosing a) give you more flexibility within PPC but is PPC only;
choosing b) is generic but assumes its the only rtc chip that will be
used by whatever kernel binary its put in.
I chose b) and to reuse the genrtc code. In a sane world, reusing code
is considered a good thing...
Its obvious that you and Tom prefer a). That's fine but if I switch to
a), I know the first comment I'll get when I post the driver to lmkl
will be, "Why would you make this ppc-specific when you could have made
it generic?" Will you and Tom then defend that decision for me?
Also, this is not board-specific as you and Tom have tried to suggest.
Assuming I change the #ifdef in rtc.h to remove the option as I think
Tom and I are agreeing upon, you select the i2c algo/adapter, the
i2c/rtc client and its there. Where are the "gross hacks for every board"?
Mark
^ permalink raw reply
* Re: [RFC] Option to disable mapping genrtc calls to ppc_md calls
From: Tom Rini @ 2005-01-20 23:47 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <41F03CEA.2030703@mvista.com>
On Thu, Jan 20, 2005 at 04:21:14PM -0700, Mark A. Greer wrote:
> Tom Rini wrote:
>
> >Why ask the user for something you know he wants? If they've selected
> >GENRTC and are using the board, they'll probably want GENRTC to work.
> >It's exactly what you described except the user won't have to know about
> >anything going on.
>
> If that's the way you want to go then it should depend on having the rtc
> "driver" selected and rtc.h should look something like:
I don't know how we talked past eachother, but it would look exactly
like it did in your patch. The only thing is that you don't ask the
user, you make use of what the user told you already. This is a nice
new feature of the 2.6 kconfig system. This is what I'm asking you to
change from your first patch.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [RFC] Option to disable mapping genrtc calls to ppc_md calls
From: Mark A. Greer @ 2005-01-20 23:21 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
In-Reply-To: <20050120225321.GB2626@smtp.west.cox.net>
Tom Rini wrote:
>So you're saying that using the hook directly isn't a different hook? I
>suppose we can agree to disagree, since it's not relevant really :)
>
Well, I could have not used genrtc at all and duplicated the code like
others have (e.g., ds1302 and ip27-rtc.c) but I chose to reuse code
that's already there and debugged. Chosing to interface to genrtc
instead of ppc_md.xxx is chosing to have it work on a wider variety of
platforms over flexibility within one particular type of platform. Pros
and cons to each.
>It can't work on PPC/MULTIPLATFORM as that's a kernel with multiple rtc
>chips in one binary (pmac, todc for prep, chrp?).
>
The point I was making is there there is nothing precluding a kernel
that runs on several boards from using it as long as that's the rtc chip
on all the platforms Its already clear that if there are different rtc
chips, it won't work.
>
>Why ask the user for something you know he wants? If they've selected
>GENRTC and are using the board, they'll probably want GENRTC to work.
>It's exactly what you described except the user won't have to know about
>anything going on.
>
If that's the way you want to go then it should depend on having the rtc
"driver" selected and rtc.h should look something like:
#if defined(CONFIG_I2C_<rtc_driver_a>) || defined(CONFIG_<rtc_driver_b> ...
For now, it would only have to be #ifdef CONFIG_xxx_M41T00
That's fine with me.
^ permalink raw reply
* Re: [RFC] Option to disable mapping genrtc calls to ppc_md calls
From: Tom Rini @ 2005-01-20 22:53 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <41F01A23.2090907@mvista.com>
On Thu, Jan 20, 2005 at 01:52:51PM -0700, Mark A. Greer wrote:
> Tom Rini wrote:
>
> >
> >I guess the problem I have is you're not providing a generic solution
> >(it won't work on PPC_MULTIPLATFORM), you're providing a different hook
> >for your board(s) :)
>
> Tom, again, [I think that] you are thinking the patch I submitted is
> trying to solve something that it isn't. I think we both agree that the
> current rtc architecture (or lack thereof) needs to be improved. And
> maybe the ARM way is the way to go. That's fine but that's not what the
> patch I submitted is trying to do.
So you're saying that using the hook directly isn't a different hook? I
suppose we can agree to disagree, since it's not relevant really :)
> The patch I submittted is only trying to be the most generic it can be
> with the rtc architecture that is there today. The patch will work on
> any architecture, even on PPC/MULTIPLATFORM. It is not only for my
It can't work on PPC/MULTIPLATFORM as that's a kernel with multiple rtc
chips in one binary (pmac, todc for prep, chrp?).
> >So until we get around to stealing arch/arm/common/rtctime.c, I'd rather
> >you used something like:
> >- arch/ppc/Kconfig (or where ever you add the board bits)
> > config PPC_DIFFERENT_GENRTC_HOOKS
> > default y if BOARD_A || BOARD_B
>
> Why? There is no reason do add in the 'if BOARD_A' stuff. I've added a
> simple option, if you want to use the m41t00 rtc--this is what I'm doing
> this for--select i2c and the correct i2c algo/adapter, select the m41t00
> i2c client, and [if on ppc] select the option to turn off
> include/asm-ppc/rtc.h. If its too hard to remember, it can be easily
> captured in a arch/ppc/configs/xxx_defconfig file. :)
Why ask the user for something you know he wants? If they've selected
GENRTC and are using the board, they'll probably want GENRTC to work.
It's exactly what you described except the user won't have to know about
anything going on.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Kernel booting issues on a MPC8270 board
From: annamaya @ 2005-01-20 22:49 UTC (permalink / raw)
To: linuxppc-embedded
I am trying to boot a mvista Linux Kernel ver. 2.4.20
on a MPC8270 board. I am using the embed_config() in
zImage to pass the board info since the bootloader is
not ppcboot. After the message, "Now booting the
kernel", the board just reboots, as if someone yanked
the reset line. I have BDI hooked up but it doesn't
seem to catch the reset point in the code. And I am
unable to trace this to anything in the code. Any
suggestions? Thanks in advance.
__________________________________
Do you Yahoo!?
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250
^ permalink raw reply
* Re: [RFC] Option to disable mapping genrtc calls to ppc_md calls
From: Benjamin Herrenschmidt @ 2005-01-20 22:27 UTC (permalink / raw)
To: Dan Malek; +Cc: Tom Rini, linuxppc-dev list
In-Reply-To: <93780AB0-696D-11D9-81BE-003065F9B7DC@embeddededge.com>
On Tue, 2005-01-18 at 11:25 -0500, Dan Malek wrote:
> On Jan 18, 2005, at 11:15 AM, Tom Rini wrote:
>
> > On Mon, Jan 17, 2005 at 02:10:00PM -0700, Mark A. Greer wrote:
>
> >> There are 2 reasons to not use the ppc_md.get_rtc_time() et. al.
> >> interfaces:
> >> 1) They are called before the i2c driver is initialized and even
> >> loaded
> >> if its a module.
>
> There are three reasons. You don't want to use an I2c rtc clock at
> all in these functions because they get can get called from the
> clock interrupt to update the time in the rtc. If it does happen to
> work,
> it creates long latencies in the timer interrupt. If the i2c requires
> an
> interrupt, they system will crash or hang.
I have the same problem and I think the solution is to fix the clock
interrupt to not do this at interrupt time, but delay to a work queue
instead.
> A system using an I2C RTC should find some way to access the
> clock from application space as a standard I2C device and manage
> time/clock from the application, not from the kernel.
gack ?
Ben.
^ permalink raw reply
* Re: [RFC] Option to disable mapping genrtc calls to ppc_md calls
From: Benjamin Herrenschmidt @ 2005-01-20 22:25 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev list
In-Reply-To: <41EC29A8.1040703@mvista.com>
On Mon, 2005-01-17 at 14:10 -0700, Mark A. Greer wrote:
> All,
>
> I have a platform with an i2c rtc chip. Since much of the code for an
> rtc driver is already in drivers/char/genrtc.c, I would like to reuse
> that code and directly implement get_rtc_time(), et. al. in the rtc
> driver. The problem is that include/asm-ppc/rtc.h assumes that
> get_rtc_time(), et. al. should be mapped to ppc_md.get_rtc_time() et.
> al. To work around this, I made an option to turn off that assumption.
> The patch is included.
>
> There are 2 reasons to not use the ppc_md.get_rtc_time() et. al. interfaces:
> 1) They are called before the i2c driver is initialized and even loaded
> if its a module.
> 2) Its ppc-specific. Implementing get_rtc_time() et. al. directly makes
> it generic across all architectures.
>
> Is there a better way to do this?
The patch is going backward since it disables the ability to have
runtime selection of the RTC chip.
</me deletes some sarcastic comments about embedded companies not
caring about anything but gross hacks for every board>
^ permalink raw reply
* Re: Instruction Cache Parity Error / 2.6.10 on MPC8540
From: Clemens Koller @ 2005-01-20 17:03 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <611DB920-6AF8-11D9-A0BF-000393DBC2E8@freescale.com>
Hello, Kumar!
Thank you again for your help...
The inscription of the CPU says:
PPC8540 PX833LB
2L71V MSIA
QEAD0412
(Yes, there is a heatsink on it ;-)
root@PM854:/cdrom/crux/base$ cat /proc/cpuinfo
processor : 0
cpu : e500
revision : 2.0 (pvr 8020 0020)
bogomips : 823.29
Vendor : Freescale Semiconductor
Machine : mpc8540ads
clock : 825MHz
PVR : 0x80200020
SVR : 0x80300020
PLL setting : 0x5
Memory : 256 MB
I hope that this is current...
Where can I find more information about the SVR?
(I had a look to the Errata Sheets... but there is no
overview of the different silicons.)
Up to now, the Panic didn't appear again - I didn't
change anything yet...
I just try to setup a new system (CRUX) on the attached hdd.
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
Kumar Gala wrote:
> Clemens,
>
> I dont think there is really and debug to do with this. If this is
> happening consistently it suppose to be an faulty part. What rev of the
> silicon do you have (PVR, SVR)?
>
> - kumar
>
> On Jan 20, 2005, at 5:24 AM, Clemens Koller wrote:
>
>> Hello,
>>
>> Well, I made good progress with Kernel 2.6.10 on my target (PM854,
>> Microsys) which is very similar to the MPC8540_ads configuration.
>> But now, after working for several minutes, I ran into the following
>> Oops:
>>
>> -----8<-------------------------------------------------------------
>> root@PM854:~/openssh-3.9p1$ Machine check in kernel mode.
>> Caused by (from MCSR=40000000): Instruction Cache Parity Error
>> Oops: machine check, sig: 7 [#1]
>> PREEMPT
>> NIP: C00054F8 LR: C01F8348 SP: C0263E70 REGS: c0232f50 TRAP: 0202 Not
>> tainted
>> MSR: 00021000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
>> TASK = c0233720[0] 'swapper' THREAD: c0262000
>> Last syscall: 120
>> GPR00: C01F8348 C0263E70 C0233720 C0233720 C054C400 00000000 00000351
>> 00000000
>> GPR08: 00000000 00000003 C054C400 0000473A 0000AE53 00000000 10000700
>> 007FFF93
>> GPR16: 00000000 00000001 007FFF00 C02B0000 C02C0000 C0233884 3B9ACA00
>> C02B5C78
>> GPR24: 000000F4 C02B5C78 C0233720 C054C400 C02AED00 00000000 00000000
>> C0263E90
>> NIP [c00054f8] __switch_to+0x14/0x9c
>> LR [c01f8348] schedule+0x318/0x704
>> Call trace:
>> [c01f8348] schedule+0x318/0x704
>> [c00026c8] resume_kernel+0x38/0x5c
>> [c00039f8] cpu_idle+0x28/0x40
>> [c0001afc] rest_init+0x28/0x38
>> [c0264804] start_kernel+0x16c/0x1a4
>> [c0000364] skpinv+0x294/0x2d0
>> Kernel panic - not syncing: Attempted to kill the idle task!
>> <0>Rebooting in 180 seconds..
>> -----8<-------------------------------------------------------------
>>
>> Does this look familiar to anybody? Any ideas where to start
>> debugging?
>>
>> 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
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
^ permalink raw reply
* [PATCH] ibm_emac missed fix
From: Ralph Siemsen @ 2005-01-20 20:54 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 163 bytes --]
The following minor fix was posted here some months ago but hasn't found
its way in to 2.6.10 or current bk.
Signed-off-by: Ralph Siemsen <ralphs@netwinder.org>
[-- Attachment #2: emac.patch --]
[-- Type: text/plain, Size: 517 bytes --]
--- linux-2.6.10-orig/drivers/net/ibm_emac/ibm_emac_core.c 2005-01-20 15:45:28.576226303 -0500
+++ linux-2.6.10/drivers/net/ibm_emac/ibm_emac_core.c 2005-01-20 15:25:10.430674655 -0500
@@ -475,8 +479,9 @@
out_be32(&emacp->em0stacr, stacr);
- while (((stacr = in_be32(&emacp->em0stacr) & EMAC_STACR_OC) == 0)
- && (count++ < 5000))
+ count = 0;
+ while ((((stacr = in_be32(&emacp->em0stacr)) & EMAC_STACR_OC) == 0)
+ && (count++ < MDIO_DELAY))
udelay(1);
MDIO_DEBUG((" (count was %d)\n", count));
^ permalink raw reply
* Re: [RFC] Option to disable mapping genrtc calls to ppc_md calls
From: Mark A. Greer @ 2005-01-20 20:52 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
In-Reply-To: <20050119180841.GP28724@smtp.west.cox.net>
Tom Rini wrote:
>
>I guess the problem I have is you're not providing a generic solution
>(it won't work on PPC_MULTIPLATFORM), you're providing a different hook
>for your board(s) :)
>
Tom, again, [I think that] you are thinking the patch I submitted is
trying to solve something that it isn't. I think we both agree that the
current rtc architecture (or lack thereof) needs to be improved. And
maybe the ARM way is the way to go. That's fine but that's not what the
patch I submitted is trying to do.
The patch I submittted is only trying to be the most generic it can be
with the rtc architecture that is there today. The patch will work on
any architecture, even on PPC/MULTIPLATFORM. It is not only for my
boards, its for any board on any architecture. Also, it isn't a
different hook, its the same hook asm-ppc/rtc.c uses. The only thing it
doesn't work for is one kernel binary supporting more than one rtc
chip. So its about as generic as you can get given the rtc architecture
that is there today.
Also, this is not without precedent. drivers/char/ds1302.c, for
example, is a complete parallel as what I'm doing. The only difference
is that it [essentially] duplicated the code in genrtc and its not an
i2c device.
>
>Taking a look at arch/arm/common/rtctime.c again finally, it solves this
>problem rather elegantly. The board registers with the driver the
>rtc_ops to get at the chip.
>
That's nice... :)
>
>So until we get around to stealing arch/arm/common/rtctime.c, I'd rather
>you used something like:
>- arch/ppc/Kconfig (or where ever you add the board bits)
> config PPC_DIFFERENT_GENRTC_HOOKS
> default y if BOARD_A || BOARD_B
>
Why? There is no reason do add in the 'if BOARD_A' stuff. I've added a
simple option, if you want to use the m41t00 rtc--this is what I'm doing
this for--select i2c and the correct i2c algo/adapter, select the m41t00
i2c client, and [if on ppc] select the option to turn off
include/asm-ppc/rtc.h. If its too hard to remember, it can be easily
captured in a arch/ppc/configs/xxx_defconfig file. :)
>- include/asm-ppc/rtc.h : what you had, basically.
>
>
>
Mark
^ permalink raw reply
* Re: Input to the timerclk on the MPC8280
From: annamaya @ 2005-01-20 16:50 UTC (permalink / raw)
To: Hans Schillstrom; +Cc: linuxppc-embedded
In-Reply-To: <1106218826.7900.405.camel@hawk.allgon.net>
Hi again,
I was looking at the serial code for U-Boot and
noticed that in the version I have which is 1.1.1,
SMC's are using BRG 6 and BRG 7 and SCC's are using
BRG's 0 through 3. I am guesing that you fixed this in
a older version of U-Boot. I justed wanted you to know
that it looks like this has been fixed in the current
U-Boot code. Thanks for your help again.
--- Hans Schillstrom <hans.schillstrom@pwav.com>
wrote:
> Hi,
> I have the same problem on MPC8270,
> and solved it two parts in u-boot:
> - Setup you PC[26] to somtething else than TMCLK ex.
> g,p. I/O
> then you an automatic selecttion of BRG1 as
> source.
>
> - Write a proper value in BRGC1 and make shure that
> bit 16-17 is 0 for selection of CPM as clock
> source.
>
> and then you have to "move around the brgs" in
> (2.6.10)
> drivers/serial/cpm_uart/cpm_uart_cpm2.c
>
> I moved smc 1&2 to brg7 & 8
> scc1 to brg2 etc
> scc4 ext clk (48MHz for USB)
>
> void smc1_lineif(struct uart_cpm_port *pinfo)
> {
> volatile iop_cpm2_t *io = &cpm2_immr->im_ioport;
>
> /* SMC1 is only on port D */
> io->iop_ppard |= 0x00c00000;
> io->iop_pdird |= 0x00400000;
> io->iop_pdird &= ~0x00800000;
> io->iop_psord &= ~0x00c00000;
> #ifndef CONFIG_RCB8270
> /* Wire BRG1 to SMC1 */
> cpm2_immr->im_cpmux.cmx_smr &= 0x0f;
> pinfo->brg = 1;
> #else
> /* Wire BRG7 to SMC1 */
> cpm2_immr->im_cpmux.cmx_smr &= 0x0f;
> cpm2_immr->im_cpmux.cmx_smr |= 0x10; /* BRG
> 7 */
> pinfo->brg = 7;
> #endif
> }
>
> I guess you can do it in many ways ...
>
> Any one that knows why SMC1 & SMC2 gets the same BRG
> as SCC1 & SCC2
>
> Regards
> /Hans
>
> On Wed, 2005-01-19 at 23:08, annamaya wrote:
> > I've asked this question on this forum before but
> it
> > did not get answered. I tried asking the same
> question
> > in the U-Boot forum with no results. So, I am
> going to
> > try this again.
> >
> > According to section 4.1.2 on Page 4-4 in the
> MPC8280
> > User's Manual, one should be able to use a
> combination
> > of external clocks on Port C pins 25, 26, 27 and
> 29,
> > the CPM cloak and BRG1 to generate a 32KHz or a
> 4MHz
> > clock. I am unable to find any code in u-boot or
> any
> > other place that initializes any of these pins to
> be
> > external clocks. And as for BRG1, I believe it is
> > being used for the SMC clock.
> >
> > I am unable to understand how this is done. Can we
> > have a timerclk input WITHOUT an external clock
> > signal? Can I just use the CPM clock to generate
> this?
> > How is this being done in U-Boot now?
> >
> > Thanks much for your help. I really need an answer
> to
> > this.
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! Mail - now with 250MB free storage. Learn
> more.
> > http://info.mail.yahoo.com/mail_250
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> >
>
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
__________________________________
Do you Yahoo!?
Meet the all-new My Yahoo! - Try it today!
http://my.yahoo.com
^ permalink raw reply
* Re: consistent_alloc() on PPC
From: Matt Porter @ 2005-01-20 18:16 UTC (permalink / raw)
To: Sachin P; +Cc: Linuxppc-dev
In-Reply-To: <66164fbc05012008302fe3e542@mail.gmail.com>
On Thu, Jan 20, 2005 at 10:00:47PM +0530, Sachin P wrote:
> Hi,
> Thanks a lot to all of you for the help .
> The following is a more clearer version of the problem I am facing :
>
> 1.I am porting drivers from X86 (running Linux 2.4-20) to
> PPC platform running (Montevista Linux-2.4.20).
> 2.In wrapper function for DMA allocation, I am using
> consistent_alloc() to allocate the memory. This function gives me
> both the virtual-address as well as the dma-address.
> I pass both these values to the upper-level drivers.
> 3. However , once the upper-level drivers are done with the memory
> they call the wrapper function for free dma and pass only the dma
> address and not the virtual-address. However consistent_free()
> accepts only virtual-address.
> Hence I need a way to convert the dma address to the
> virtual-address.
All you need to do is cache the virtual address and the dma/phys
address for later use when calling consistent_free(). converting
random DMA/phys to virtual is a bad idea since you are going to
find multiple mappings. Cache the results in your driver...it's
trivial.
-Matt
^ permalink raw reply
* Re: [PATCH] raid6: altivec support
From: Tom Rini @ 2005-01-20 17:55 UTC (permalink / raw)
To: Paul Mackerras
Cc: linuxppc-dev list, Linus Torvalds, David Woodhouse,
Linux Kernel list, H. Peter Anvin
In-Reply-To: <16878.11077.556326.769738@cargo.ozlabs.ibm.com>
On Wed, Jan 19, 2005 at 08:41:25PM +1100, Paul Mackerras wrote:
> David Woodhouse writes:
>
> > Yeah.... I'm increasingly tempted to merge ppc32/ppc64 into one arch
> > like mips/parisc/s390. Or would that get vetoed on the basis that we
> > don't have all that horrid non-OF platform support in ppc64 yet, and
> > we're still kidding ourselves that all those embedded vendors will
> > either not notice ppc64 or will use OF?
>
> I'm going to insist that every new ppc64 platform supplies a device
> tree. They don't have to have OF but they do need to have the booter
> or wrapper supply a flattened device tree (which is just a few kB of
> binary data as far as the booter/wrapper is concerned). It doesn't
> have to include all the
*shurg*
It really is a great idea, but I think it will just move the ire from
(serial infos, IRQ table, ?) being in platforms/fooboard.[ch] to
platforms/fooboard.h or platforms/fooboard_bootinfos.h
So lets just hope ppc64 keeps getting ignored :)
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: consistent_alloc() on PPC
From: Sachin P @ 2005-01-20 16:30 UTC (permalink / raw)
To: Linuxppc-dev
In-Reply-To: <20050119075603.B448@home.com>
Hi,
Thanks a lot to all of you for the help .
The following is a more clearer version of the problem I am facing :
1.I am porting drivers from X86 (running Linux 2.4-20) to
PPC platform running (Montevista Linux-2.4.20).
2.In wrapper function for DMA allocation, I am using
consistent_alloc() to allocate the memory. This function gives me
both the virtual-address as well as the dma-address.
I pass both these values to the upper-level drivers.
3. However , once the upper-level drivers are done with the memory
they call the wrapper function for free dma and pass only the dma
address and not the virtual-address. However consistent_free()
accepts only virtual-address.
Hence I need a way to convert the dma address to the
virtual-address.
Regards
sachin
On Wed, 19 Jan 2005 07:56:03 -0700, Matt Porter
<mporter@kernel.crashing.org> wrote:
> On Wed, Jan 19, 2005 at 03:10:48PM +0100, Christoph Hellwig wrote:
> > On Wed, Jan 19, 2005 at 05:23:17PM +0530, Sachin P wrote:
> > > Hi ,
> > > I am facing some problems porting my drivers to the PPC platform . Am
> > > currently using consistent_alloc() and consistent_free() to
> > > allocate/free (non-cached) DMA ble memory.
> > > Is there any function/patch/macro, equivalent to
> > > phy_to_virt()/virt_to_phy() for memory returned by consistent_alloc()?
> >
> > Don't ever use concistant_alloc directly. Always use
> > dma_alloc_coherent() which will give you both virtual and bus address.
>
> He's obviously not talking about 2.6 since he's mentioning
> consistent_alloc(). I removed those PPC-specific APIs when I
> updated our DMA API implementation in 2.6.
>
> -Matt
>
^ permalink raw reply
* Re: Input to the timerclk on the MPC8280
From: Hans Schillstrom @ 2005-01-20 16:14 UTC (permalink / raw)
To: annamaya; +Cc: linuxppc-embedded
In-Reply-To: <20050120154704.62155.qmail@web53804.mail.yahoo.com>
Hi,
On Thu, 2005-01-20 at 16:47, annamaya wrote:
> Thanks a lot for the reply. I have some more questions
> on this. When and where in U-Boot do you set the value
> of BRGC1? Can I do this somewhere in board_init() or
> do I have to do it earlier, like in cpu_init?
I think misc_init_f(), is a good idea
rememer to enable it with CONFIG_MISC_INIT_F
> And I
> will have to set the values in the DIV16 and CD to
> produce an output of 4Mhz or 32Khz. Is that correct?
>
Yes
> BTW, how was this ever done on the MPC8260? I dont see
> any code in U-Boot for an 8260 board that does sothing
> similar?
>
I havn't seen it before....
> --- Hans Schillstrom <hans.schillstrom@pwav.com>
> wrote:
>
> > Hi,
> > I have the same problem on MPC8270,
> > and solved it two parts in u-boot:
> > - Setup you PC[26] to somtething else than TMCLK ex.
> > g,p. I/O
> > then you an automatic selecttion of BRG1 as
> > source.
> >
> > - Write a proper value in BRGC1 and make sure that
> > bit 16-17 is 0 for selection of CPM as clock
> > source.
> >
> > and then you have to "move around the brgs" in
> > (2.6.10)
> > drivers/serial/cpm_uart/cpm_uart_cpm2.c
> >
> > I moved smc 1&2 to brg7 & 8
> > scc1 to brg2 etc
> > scc4 ext clk (48MHz for USB)
> >
> > void smc1_lineif(struct uart_cpm_port *pinfo)
> > {
> > volatile iop_cpm2_t *io = &cpm2_immr->im_ioport;
> >
> > /* SMC1 is only on port D */
> > io->iop_ppard |= 0x00c00000;
> > io->iop_pdird |= 0x00400000;
> > io->iop_pdird &= ~0x00800000;
> > io->iop_psord &= ~0x00c00000;
> > #ifndef CONFIG_RCB8270
> > /* Wire BRG1 to SMC1 */
> > cpm2_immr->im_cpmux.cmx_smr &= 0x0f;
> > pinfo->brg = 1;
> > #else
> > /* Wire BRG7 to SMC1 */
> > cpm2_immr->im_cpmux.cmx_smr &= 0x0f;
> > cpm2_immr->im_cpmux.cmx_smr |= 0x10; /* BRG
> > 7 */
> > pinfo->brg = 7;
> > #endif
> > }
> >
> > I guess you can do it in many ways ...
> >
> > Any one that knows why SMC1 & SMC2 gets the same BRG
> > as SCC1 & SCC2
> >
> > Regards
> > /Hans
> >
> > On Wed, 2005-01-19 at 23:08, annamaya wrote:
> > > I've asked this question on this forum before but
> > it
> > > did not get answered. I tried asking the same
> > question
> > > in the U-Boot forum with no results. So, I am
> > going to
> > > try this again.
> > >
> > > According to section 4.1.2 on Page 4-4 in the
> > MPC8280
> > > User's Manual, one should be able to use a
> > combination
> > > of external clocks on Port C pins 25, 26, 27 and
> > 29,
> > > the CPM cloak and BRG1 to generate a 32KHz or a
> > 4MHz
> > > clock. I am unable to find any code in u-boot or
> > any
> > > other place that initializes any of these pins to
> > be
> > > external clocks. And as for BRG1, I believe it is
> > > being used for the SMC clock.
> > >
> > > I am unable to understand how this is done. Can we
> > > have a timerclk input WITHOUT an external clock
> > > signal? Can I just use the CPM clock to generate
> > this?
> > > How is this being done in U-Boot now?
> > >
> > > Thanks much for your help. I really need an answer
> > to
> > > this.
> > >
> > >
> > >
> > > __________________________________
> > > Do you Yahoo!?
> > > Yahoo! Mail - now with 250MB free storage. Learn
> > more.
> > > http://info.mail.yahoo.com/mail_250
> > > _______________________________________________
> > > Linuxppc-embedded mailing list
> > > Linuxppc-embedded@ozlabs.org
> > >
> >
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - Easier than ever with enhanced search. Learn more.
> http://info.mail.yahoo.com/mail_250
^ permalink raw reply
* Re: Input to the timerclk on the MPC8280
From: annamaya @ 2005-01-20 15:47 UTC (permalink / raw)
To: Hans Schillstrom; +Cc: linuxppc-embedded
In-Reply-To: <1106218826.7900.405.camel@hawk.allgon.net>
Thanks a lot for the reply. I have some more questions
on this. When and where in U-Boot do you set the value
of BRGC1? Can I do this somewhere in board_init() or
do I have to do it earlier, like in cpu_init? And I
will have to set the values in the DIV16 and CD to
produce an output of 4Mhz or 32Khz. Is that correct?
BTW, how was this ever done on the MPC8260? I dont see
any code in U-Boot for an 8260 board that does sothing
similar?
--- Hans Schillstrom <hans.schillstrom@pwav.com>
wrote:
> Hi,
> I have the same problem on MPC8270,
> and solved it two parts in u-boot:
> - Setup you PC[26] to somtething else than TMCLK ex.
> g,p. I/O
> then you an automatic selecttion of BRG1 as
> source.
>
> - Write a proper value in BRGC1 and make sure that
> bit 16-17 is 0 for selection of CPM as clock
> source.
>
> and then you have to "move around the brgs" in
> (2.6.10)
> drivers/serial/cpm_uart/cpm_uart_cpm2.c
>
> I moved smc 1&2 to brg7 & 8
> scc1 to brg2 etc
> scc4 ext clk (48MHz for USB)
>
> void smc1_lineif(struct uart_cpm_port *pinfo)
> {
> volatile iop_cpm2_t *io = &cpm2_immr->im_ioport;
>
> /* SMC1 is only on port D */
> io->iop_ppard |= 0x00c00000;
> io->iop_pdird |= 0x00400000;
> io->iop_pdird &= ~0x00800000;
> io->iop_psord &= ~0x00c00000;
> #ifndef CONFIG_RCB8270
> /* Wire BRG1 to SMC1 */
> cpm2_immr->im_cpmux.cmx_smr &= 0x0f;
> pinfo->brg = 1;
> #else
> /* Wire BRG7 to SMC1 */
> cpm2_immr->im_cpmux.cmx_smr &= 0x0f;
> cpm2_immr->im_cpmux.cmx_smr |= 0x10; /* BRG
> 7 */
> pinfo->brg = 7;
> #endif
> }
>
> I guess you can do it in many ways ...
>
> Any one that knows why SMC1 & SMC2 gets the same BRG
> as SCC1 & SCC2
>
> Regards
> /Hans
>
> On Wed, 2005-01-19 at 23:08, annamaya wrote:
> > I've asked this question on this forum before but
> it
> > did not get answered. I tried asking the same
> question
> > in the U-Boot forum with no results. So, I am
> going to
> > try this again.
> >
> > According to section 4.1.2 on Page 4-4 in the
> MPC8280
> > User's Manual, one should be able to use a
> combination
> > of external clocks on Port C pins 25, 26, 27 and
> 29,
> > the CPM cloak and BRG1 to generate a 32KHz or a
> 4MHz
> > clock. I am unable to find any code in u-boot or
> any
> > other place that initializes any of these pins to
> be
> > external clocks. And as for BRG1, I believe it is
> > being used for the SMC clock.
> >
> > I am unable to understand how this is done. Can we
> > have a timerclk input WITHOUT an external clock
> > signal? Can I just use the CPM clock to generate
> this?
> > How is this being done in U-Boot now?
> >
> > Thanks much for your help. I really need an answer
> to
> > this.
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! Mail - now with 250MB free storage. Learn
> more.
> > http://info.mail.yahoo.com/mail_250
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> >
>
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
__________________________________
Do you Yahoo!?
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250
^ permalink raw reply
* Re: Instruction Cache Parity Error / 2.6.10 on MPC8540
From: Kumar Gala @ 2005-01-20 15:31 UTC (permalink / raw)
To: Clemens Koller; +Cc: linuxppc-embedded
In-Reply-To: <41EF94DB.4090604@anagramm.de>
Clemens,
I dont think there is really and debug to do with this. If this is=20
happening consistently it suppose to be an faulty part. What rev of=20
the silicon do you have (PVR, SVR)?
- kumar
On Jan 20, 2005, at 5:24 AM, Clemens Koller wrote:
> Hello,
>
> Well, I made good progress with Kernel 2.6.10 on my target (PM854,
> Microsys) which is very similar to the MPC8540_ads configuration.
> But now, after working for several minutes, I ran into the following
> Oops:
>
> -----8<-------------------------------------------------------------
> root@PM854:~/openssh-3.9p1$ Machine check in kernel mode.
> Caused by (from MCSR=3D40000000): Instruction Cache Parity Error
> Oops: machine check, sig: 7 [#1]
> PREEMPT
> NIP: C00054F8 LR: C01F8348 SP: C0263E70 REGS: c0232f50 TRAP: 0202=A0=A0=
=A0=20
> Not
> tainted
> MSR: 00021000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
> TASK =3D c0233720[0] 'swapper' THREAD: c0262000
> Last syscall: 120
> GPR00: C01F8348 C0263E70 C0233720 C0233720 C054C400 00000000 00000351
> 00000000
> GPR08: 00000000 00000003 C054C400 0000473A 0000AE53 00000000 10000700
> 007FFF93
> GPR16: 00000000 00000001 007FFF00 C02B0000 C02C0000 C0233884 3B9ACA00
> C02B5C78
> GPR24: 000000F4 C02B5C78 C0233720 C054C400 C02AED00 00000000 00000000
> C0263E90
> NIP [c00054f8] __switch_to+0x14/0x9c
> LR [c01f8348] schedule+0x318/0x704
> Call trace:
> =A0 [c01f8348] schedule+0x318/0x704
> =A0 [c00026c8] resume_kernel+0x38/0x5c
> =A0 [c00039f8] cpu_idle+0x28/0x40
> =A0 [c0001afc] rest_init+0x28/0x38
> =A0 [c0264804] start_kernel+0x16c/0x1a4
> =A0 [c0000364] skpinv+0x294/0x2d0
> Kernel panic - not syncing: Attempted to kill the idle task!
> =A0 <0>Rebooting in 180 seconds..
> -----8<-------------------------------------------------------------
>
> Does this look familiar to anybody? Any ideas where to start
> debugging?
>
> 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
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ 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