* RE: [PATCH] Handle I-TLB Error and Miss separately on 8xx
From: Joakim Tjernlund @ 2005-01-19 19:58 UTC (permalink / raw)
To: Dan Malek; +Cc: Tom Rini, Linuxppc-Embedded@Ozlabs. Org
In-Reply-To: <3AACC857-6A49-11D9-9943-003065F9B7DC@embeddededge.com>
> On Jan 19, 2005, at 1:06 PM, Joakim Tjernlund wrote:
>
> > 8MB pages for user space? Isn't that a bit big?
>
> Just for kernel space. I think eliminating lots of TLB updates for the
> kernel will be one of the easiest ways to get a boost of performance
> in this area. This way, system calls or interrupts won't pollute the
> TLB
> for the application, which can then just continue to run without having
> to reload the TLB after such events.
I see, similar to the pinned TLBs in 8xx but without the "pin"
This would include vmalloc space and ioremapped space as well?
>
> Part of my graduate work years ago was MMU overhead with various
> page sizes and replacement algorithms. Increase page sizes from
> something like 1K to 8M made a difference you could measure, but
> the difference between 1K to 32K made little difference. Of course,
> you can always write some application that just trashes the TLB and
> proves any improvement incorrect, but that would also trash caches and
> other system resources. I'll always contend that if you can measure
> the difference between a 4K and 16K page, something else is grossly
> wrong with the system in general and you should be looking for
> performance problems elsewhere.
hmm, did you measure this on a 8xx with that have few TLBs?
I havn't done any measurements, it just seemed like a good idea for
systems with few TLBs and lots of RAM.
Jocke
^ permalink raw reply
* ISP1362 USB host controller with an MPC880
From: Jordan, Kyle @ 2005-01-19 20:28 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I am currently looking into using the ISP1362 as a host
controller on a Freescale (Motorola) MPC880 running Linux 2.4.23. I
have noticed posts where others have also use this part with the MPC880.
I was wondering if anyone could let me know what driver they were using
and where I could possibly obtain it. If anyone could also tell me if
they were successful using this driver, I would greatly appreciate it.
Thanks,
Kyle Jordan
^ permalink raw reply
* Re: [linux-usb-devel] USB host on Freescale MPC880
From: Wells, Charles @ 2005-01-19 20:55 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: linuxppc-embedded
Pantelis,
>I have a fairly hacked over version of the original USB host driver
that works for 87x/88x.
>
>Are you interested?
I would be interested in seeing this code as well.
Regards,
Charlie
^ permalink raw reply
* Re: [PATCH] ppc32: pmac sleep support update
From: Andreas Schwab @ 2005-01-19 21:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Andrew Morton, linuxppc-dev list, Linus Torvalds
In-Reply-To: <1106100264.4534.135.camel@gaston>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>> With all your patches applied I'm getting an oops during wakeup inside
>> pci_bus_read_config_word on my iBook/G3. Call trace: pci_set_master,
>> pci_device_resume, resume_device, dpm_resume, device_resume,
>> pmac_wakeup_devices, pmu_ioctl, sys_ioctl.
>
> It would be useful to get some more infos, what is the actual oops text
> (what error), and if you could add some printk's to figure out what is
> the culprit PCI device, that would be useful as well...
I was unable to reproduce the exact oops I got yesterday. Now I'm getting
a heap of oopses scrolling by, ending with a panic due to killing
interrupt handler, without any way to capture them.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Input to the timerclk on the MPC8280
From: annamaya @ 2005-01-19 22:08 UTC (permalink / raw)
To: linuxppc-embedded
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
^ permalink raw reply
* Re: TZ variable setting for denx 2.4.20
From: annamaya @ 2005-01-19 22:11 UTC (permalink / raw)
To: Robin, linuxppc-embedded, Linuxppc-embedded
In-Reply-To: <4229EDFB.2040402@india.tejasnetworks.com>
I am not sure what hapenned to the SPI driver that was
out there for the 8xx that I wrote a long time ago. I
know that it was working fine then. I do have a
version now that works great. I'll try and make it
available somewhere real soon. But this one's only for
the 2.4 kernel and not the 2.6 kernel.
--- Robin <robin@india.tejasnetworks.com> wrote:
> Hi all,
> I am trying to find a way of setting TZ environment
> variable with DST
> support for southern hemisphere countries. Its
> giving a strange problem.
> In southern hemisphere countries, DST starts around
> Oct and ends around
> March. The DST time seems to be applicable from Oct
> until Dec31,19:00hrs.
> Then it reverts back to standard time.
>
> For northern hemisphere countries, its working
> perfectly.(Here DST starts
> around March and ends around Oct. There is no year
> crossing DST period.)
>
> I am sending the system timezone at various times..
>
> bash> export TZ="xxx5:30yyy4:30,M10.1.1,M2.1.1"
> bash> date 10010159
> Mon Oct 1 01:59:00 xxx 2001
> bash> date
> Mon Oct 1 01:59:47 xxx 2001
> bash> date
> Mon Oct 1 03:00:10 yyy 2001
> bash> date 12311900
> Mon Dec 31 19:00:00 yyy 2001
> bash> date 12311959
> Mon Dec 31 18:59:00 xxx 2001 <----------- problem.
> It should have
> reverted to xxx only in feb.
>
> Please give me some idea for setting time zone for
> southern hemisphere
> countries.
>
> I am using 2.4.20 linux kernel from denx.I am
> running date command from
> busybox version 0.6 which in is using strftime. The
> processor is ppc860T.
>
> Regards,
> Robin Mathew
>
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
>
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
^ permalink raw reply
* Re: [PATCH] ppc32: pmac sleep support update
From: Benjamin Herrenschmidt @ 2005-01-19 22:44 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev list
In-Reply-To: <1106142344.26551.517.camel@hades.cambridge.redhat.com>
On Wed, 2005-01-19 at 13:45 +0000, David Woodhouse wrote:
> On Tue, 2005-01-18 at 12:32 +1100, Benjamin Herrenschmidt wrote:
> > This patch updates the PowerMac sleep support. The ability to sleep is now broken
> > into 2 different flags, one, "may sleep" is set for all motherboards that we know
> > how to put to sleep and wakeup. It gets turned into "can sleep" upon a call from
> > the video driver indicating the ability to wakeup the video card.
>
> Why do it like this? Drivers already have the ability to veto sleep
> requests, surely?
But they don't, besides, you may just not have a driver for the card
(that is things like offb don't register as a pci_driver, etc...)
It's a mecanism that can/will be improved in the future, but for now,
it suits my needs perfectly.
Ben.
^ permalink raw reply
* Re: [PATCH] ppc32: pmac sleep support update
From: Benjamin Herrenschmidt @ 2005-01-19 22:57 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Andrew Morton, linuxppc-dev list, Linus Torvalds
In-Reply-To: <jemzv584yw.fsf@sykes.suse.de>
On Wed, 2005-01-19 at 22:49 +0100, Andreas Schwab wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>
> >> With all your patches applied I'm getting an oops during wakeup inside
> >> pci_bus_read_config_word on my iBook/G3. Call trace: pci_set_master,
> >> pci_device_resume, resume_device, dpm_resume, device_resume,
> >> pmac_wakeup_devices, pmu_ioctl, sys_ioctl.
> >
> > It would be useful to get some more infos, what is the actual oops text
> > (what error), and if you could add some printk's to figure out what is
> > the culprit PCI device, that would be useful as well...
>
> I was unable to reproduce the exact oops I got yesterday. Now I'm getting
> a heap of oopses scrolling by, ending with a panic due to killing
> interrupt handler, without any way to capture them.
Even when building xmon into the kernel ?
Ben.
^ permalink raw reply
* Re: FW: cpm_spi.c under kernel 2.6
From: Wolfgang Denk @ 2005-01-19 23:02 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
In-Reply-To: <200501191947.16167.david.jander@protonic.nl>
In message <200501191947.16167.david.jander@protonic.nl> you wrote:
>
> In u-boot there are two 8xx-SPI-drivers, one software and one in hardware, and
...
> I am starting to figure out the best way of fixing that mess. Is anyone busy
> with the same task?
You have better chances for a useful reply if you ask on the
U-Boot-Users mailing list instead.
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
In theory, there is no difference between theory and practice. In
practice, however, there is.
^ permalink raw reply
* Re: ISP1362 USB host controller with an MPC880
From: Wolfgang Denk @ 2005-01-19 23:05 UTC (permalink / raw)
To: Jordan, Kyle; +Cc: linuxppc-embedded
In-Reply-To: <C0170D0AF1277849A4B4518034F855DD0F90C6@aiexchange.ai.aiinet.com>
In message <C0170D0AF1277849A4B4518034F855DD0F90C6@aiexchange.ai.aiinet.com> you wrote:
>
> I am currently looking into using the ISP1362 as a host
> controller on a Freescale (Motorola) MPC880 running Linux 2.4.23. I
> have noticed posts where others have also use this part with the MPC880.
> I was wondering if anyone could let me know what driver they were using
> and where I could possibly obtain it. If anyone could also tell me if
> they were successful using this driver, I would greatly appreciate it.
See the linuxppc_2_4_devel module on our CVS server. Our driver for
the ISP1362 has been tested for host function (memory stick, USB
modem, USB-serial adapter, USB network adapter), device function
(network device) and as gadget driver (communicating with Windows PC
using RNDIS drivers).
The code is stable.
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
Crash programs fail because they are based on the theory that, with
nine women pregnant, you can get a baby a month. - Wernher von Braun
^ permalink raw reply
* Re: [PATCH] raid6: altivec support
From: Benjamin Herrenschmidt @ 2005-01-19 23:22 UTC (permalink / raw)
To: David Woodhouse
Cc: linuxppc-dev list, Linus Torvalds, H. Peter Anvin,
Linux Kernel list
In-Reply-To: <1106120622.10851.42.camel@baythorne.infradead.org>
On Wed, 2005-01-19 at 07:43 +0000, David Woodhouse wrote:
> On Wed, 2005-01-19 at 15:11 +1100, Benjamin Herrenschmidt wrote:
> > We should probably "backport" that simplification to ppc32...
>
> 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?
Oh well... i've though about it too, and decided that I was not ready to
try it. For one, the problem you mention, with the pile of embedded
junk. I made the design decision to define an OF client interface as the
standard & mandatory entry mecanism to the ppc64 kernel (except legacy
iSeries of course, but I don't want that to multiply). That or the
kexec-like entrypoint passing a flattened device-tree in.
Also, there are other significant differences in other areas. At this
point, I think the differences are bigger than the common code.
What would be interesting would be to proceed incrementally, having a
directory somewhere to put the "common" ppc/ppc64 code, and slowly
moving things there.
Ben.
^ permalink raw reply
* Re: [PATCH] raid6: altivec support
From: Benjamin Herrenschmidt @ 2005-01-19 23:25 UTC (permalink / raw)
To: David Woodhouse
Cc: H. Peter Anvin, Linux Kernel list, linuxppc-dev list,
Linus Torvalds, Paul Mackerras
In-Reply-To: <1106146083.26551.526.camel@hades.cambridge.redhat.com>
On Wed, 2005-01-19 at 14:48 +0000, David Woodhouse wrote:
> On Wed, 2005-01-19 at 08:45 -0600, Kumar Gala wrote:
> > We did talk about looking at using some work Ben did in ppc64 with OF
> > in ppc32. John Masters was looking into this, but I havent heard much
> > from him on it lately.
> >
> > The firmware interface on the ppc32 embedded side is some what broken
> > in my mind.
>
> The binary structure which changes every few weeks and which is shared
> between the bootloader and the kernel? Yeah, "somewhat broken" is one
> way of putting it :)
>
> The ARM kernel does it a lot better with tag,value pairs.
And ppc64 adds a flattened device-tree format, even better imho :)
Ben.
^ permalink raw reply
* Narrowed it down - RE: Linux 2.6-10.rc3 8xx: Only 3 characters are printed well in __in it start_kernel() upon kernel booting
From: Povolotsky, Alexander @ 2005-01-20 0:22 UTC (permalink / raw)
To: 'linuxppc-embedded@ozlabs.org'
Here is my software "debugging tool", which allowed me to disable writing
throgh printk()
to the log buffer - until I want it to be enabled
by using this "tool" I've performed some investigation
(however inconclusive - so opinions and suggestions are welcomed).
/* ... linux/init/main.c ...*/
...
+ unsigned long disable_printk = 1;
extern char *linux_banner;
...
__in it start_kernel(...)
...
disable_printk = 0;
printk("Alex\n");
vfs_caches_init_early();
mem_init();
...
*************************************************
/* ... kernel/printk.c ... */
...
DECLARE_WAIT_QUEUE_HEAD(log_wait);
+ extern unsigned long disable_printk ;
...
asmlinkage int printk(const char *fmt, ...)
{
va_list args;
int r;
+ if (disable_printk) return 0;
va_start(args, fmt);
...
**************************************************
I was "sliding down" those two statements:
disable_printk = 0;
printk("Alex\n");
down to cosole_init() and further down beyond it,
while I could see "Ale" in - I was moving it further down ...
To double check, couple times I would do just
disable_printk = 0;
without
printk("Alex\n");
then I have seen once:
"Con"
and moving further down:
"Den"
which I think is from: "Dentry cache hash table entries ..."
But I can not see my output when do it
just before
vfs_caches_init_early();
but it is very close to
mem_init();
so I am not sure, which is the culprit ...
Should I put some delay between those two (what is the best way to do it ?)
Thanks,
Best regards,
Alex
^ permalink raw reply
* Re: [PATCH] ppc32: pmac sleep support update
From: Andreas Schwab @ 2005-01-20 0:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Andrew Morton, linuxppc-dev list, Linus Torvalds
In-Reply-To: <1106175427.5326.21.camel@gaston>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> Even when building xmon into the kernel ?
Doh! I didn't think of that. This is what I get from xmon:
<2>kernel BUG in unlock_page at mm/filemap.c:430!
vector: 700 at pc = c003f098, lr = c0041654
msr = 29032, sp = e71b1c80 [e71b1bd0]
current = e7bbec70, pid = 2915, comm = syslogd
c0041654 = generic_file_buffered_write
Last kernel messages:
radeonfb: switching to D0 state...
HID1, after: 70000044
cpufreq: resume failed to assert current frequency is what timing core thinks it is.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] ppc32: pmac sleep support update
From: Benjamin Herrenschmidt @ 2005-01-20 1:01 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Andrew Morton, linuxppc-dev list, Linus Torvalds
In-Reply-To: <jehdld7wx0.fsf@sykes.suse.de>
On Thu, 2005-01-20 at 01:43 +0100, Andreas Schwab wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>
> > Even when building xmon into the kernel ?
>
> Doh! I didn't think of that. This is what I get from xmon:
>
> <2>kernel BUG in unlock_page at mm/filemap.c:430!
> vector: 700 at pc = c003f098, lr = c0041654
> msr = 29032, sp = e71b1c80 [e71b1bd0]
> current = e7bbec70, pid = 2915, comm = syslogd
>
> c0041654 = generic_file_buffered_write
>
> Last kernel messages:
>
> radeonfb: switching to D0 state...
> HID1, after: 70000044
> cpufreq: resume failed to assert current frequency is what timing core thinks it is.
Weird ... Can you try without cpufreq built in the kernel ? Also what is
the exact CPU revision ? I think you are just experiencing memory
corruption...
Ben.
^ permalink raw reply
* Re: [PATCH] ppc32: pmac sleep support update
From: Andreas Schwab @ 2005-01-20 1:34 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1106182915.5294.57.camel@gaston>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>> cpufreq: resume failed to assert current frequency is what timing core thinks it is.
>
> Weird ... Can you try without cpufreq built in the kernel ?
I think this message is unrelated to the problem, it occurs with all
kernels so far.
> Also what is the exact CPU revision ?
It's a 750FX revision 1.18.
> I think you are just experiencing memory corruption...
Yes, I agree, I get completely different crashes whenever I use a slightly
different kernel.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] ppc32: pmac sleep support update
From: Benjamin Herrenschmidt @ 2005-01-20 2:23 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev list
In-Reply-To: <jed5w0993z.fsf@sykes.suse.de>
On Thu, 2005-01-20 at 02:34 +0100, Andreas Schwab wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>
> >> cpufreq: resume failed to assert current frequency is what timing core thinks it is.
> >
> > Weird ... Can you try without cpufreq built in the kernel ?
>
> I think this message is unrelated to the problem, it occurs with all
> kernels so far.
>
> > Also what is the exact CPU revision ?
>
> It's a 750FX revision 1.18.
>
> > I think you are just experiencing memory corruption...
>
> Yes, I agree, I get completely different crashes whenever I use a slightly
> different kernel.
It would be interesting to hack around pmac_cache.S and see if you get
it more reliable ...
Ben.
^ permalink raw reply
* Re: [Lists-linux-kernel-news] Re: [PATCH] raid6: altivec support
From: Jon Masters @ 2005-01-20 7:40 UTC (permalink / raw)
To: benh; +Cc: hpa, linux-kernel, linuxppc-dev, torvalds, paulus, dwmw2
In-Reply-To: <1106177129.5327.43.camel@gaston>
[excuse formatting, adhoc connectivity]
Ben writes:
> And ppc64 adds a flattened device-tree format, even better imho :)
This is exactly what I was looking at - pulling that in to ppc32, helps
with stuff like kexec too. Like everything else, it helps to have people
moaning at me to make me get on with it :-) I'll see if I can't spend a
few hours on the plane and ressurrect this instead of window gazing.
Jon.
^ permalink raw reply
* [PATCH] sysrq for ibook
From: Joerg Dorchain @ 2005-01-20 10:26 UTC (permalink / raw)
Cc: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1949 bytes --]
Hi,
I am somehow missing the sysrq-feature with the iBook keyboard. As there
is no F13=sysrq on it, IMHO it might be an idea to emulate it via Fn+esc.
Bye,
Joerg
--- adbhid.c.sysrq 2005-01-19 18:57:30.000000000 +0100
+++ adbhid.c 2005-01-19 20:09:15.873421184 +0100
@@ -67,13 +67,16 @@
/* Some special keys */
#define ADB_KEY_DEL 0x33
+#define ADB_KEY_ESC 0x35
#define ADB_KEY_CMD 0x37
#define ADB_KEY_CAPSLOCK 0x39
#define ADB_KEY_FN 0x3f
+#define ADB_KEY_SYSRQ 0x69
#define ADB_KEY_FWDEL 0x75
#define ADB_KEY_POWER_OLD 0x7e
#define ADB_KEY_POWER 0x7f
+
u8 adb_to_linux_keycodes[128] = {
/* 0x00 */ KEY_A, /* 30 */
/* 0x01 */ KEY_S, /* 31 */
@@ -221,6 +224,7 @@
#define FLAG_FN_KEY_PRESSED 0x00000001
#define FLAG_POWER_FROM_FN 0x00000002
#define FLAG_EMU_FWDEL_DOWN 0x00000004
+#define FLAG_EMU_SYSRQ_DOWN 0x00000008
static struct adbhid *adbhid[16];
@@ -329,6 +333,12 @@
keycode = ADB_KEY_FWDEL;
break;
}
+ /* Emulate Fn+esc = sysreq */
+ if (ahid->flags & FLAG_EMU_SYSRQ_DOWN) {
+ ahid->flags &= ~FLAG_EMU_SYSRQ_DOWN;
+ keycode = ADB_KEY_SYSRQ;
+ break;
+ }
} else
ahid->flags |= FLAG_FN_KEY_PRESSED;
/* Swallow the key press */
@@ -343,6 +353,23 @@
ahid->flags |= FLAG_EMU_FWDEL_DOWN;
}
break;
+ case ADB_KEY_ESC:
+ /* Emulate Fn+esc = left alt+sysreq */
+ if (ahid->flags & FLAG_FN_KEY_PRESSED) {
+ keycode = ADB_KEY_SYSRQ;
+ input_regs(&ahid->input, regs);
+ if (up_flag) {
+ ahid->flags &= ~FLAG_EMU_SYSRQ_DOWN;
+ /* Warning: Hack to avoid twisted fingers ...*/
+ input_report_key(&ahid->input, KEY_LEFTALT, 0);
+ } else {
+ ahid->flags |= FLAG_EMU_SYSRQ_DOWN;
+ /* Warning: Hack to avoid twisted fingers ...*/
+ input_report_key(&ahid->input, KEY_LEFTALT, 1);
+ }
+ input_sync(&ahid->input);
+ }
+ break;
#endif /* CONFIG_PPC_PMAC */
}
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: nvram driver not possible as a module
From: Guido Guenther @ 2005-01-20 9:55 UTC (permalink / raw)
To: Joerg Dorchain; +Cc: linuxppc-dev list
In-Reply-To: <20050119101448.GA1374@Redstar.dorchain.net>
Hi Joerg,
On Wed, Jan 19, 2005 at 11:14:48AM +0100, Joerg Dorchain wrote:
> KConfig says CONFIG_NVRAM is possible as a module. Loading the module
> fails because of an unknown symbol __alloc_bootmem. __alloc_bootmem is
> marked __init. The obvious workaround is to compile the driver not as a
> module, but how can this get really fixed?
Does this help:
--- linux-2.6.9.orig/arch/ppc/platforms/pmac_nvram.c 2004-10-18 23:53:51.000000000 +0200
+++ linux-2.6.9/arch/ppc/platforms/pmac_nvram.c 2004-10-25 09:53:15.000000000 +0200
@@ -488,7 +488,7 @@
printk(KERN_ERR "nvram: no address\n");
return;
}
- nvram_image = alloc_bootmem(NVRAM_SIZE);
+ nvram_image = kmalloc(NVRAM_SIZE, GFP_KERNEL);
if (nvram_image == NULL) {
printk(KERN_ERR "nvram: can't allocate ram image\n");
return;
Cheers,
-- Guido
^ permalink raw reply
* Re: nvram driver not possible as a module
From: Joerg Dorchain @ 2005-01-20 10:50 UTC (permalink / raw)
To: Guido Guenther; +Cc: linuxppc-dev list
In-Reply-To: <20050120095546.GD5810@bogon.ms20.nix>
[-- Attachment #1: Type: text/plain, Size: 537 bytes --]
On Thu, Jan 20, 2005 at 10:55:46AM +0100, Guido Guenther wrote:
> Hi Joerg,
> On Wed, Jan 19, 2005 at 11:14:48AM +0100, Joerg Dorchain wrote:
> > KConfig says CONFIG_NVRAM is possible as a module. Loading the module
> > fails because of an unknown symbol __alloc_bootmem. __alloc_bootmem is
> > marked __init. The obvious workaround is to compile the driver not as a
> > module, but how can this get really fixed?
> Does this help:
[...]
Most likely, if there wasn't a specific reason to use bootmem.
I'll try tonight.
Thanks,
Joerg
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH]PPC4XX Dma fixes, burst and sg improvements
From: Colin Wernham @ 2005-01-20 10:55 UTC (permalink / raw)
To: linuxppc-dev, mporter; +Cc: linuxppc-embedded
I have DMA fixes and improvements to the following PPC4XX files [2.6.10]:
ppc4xx_dma.h
ppc4xx_dma.c
ppc4xx_sgdma.c
The fixes/improvements are:
1) Added the missing ppc4xx_clr_dma_status() function,
2) Adding new functions to support enabling/disabling and setting burst
modes,
3) FIX: ppc4xx_get_channel_config() now memcpy's the existing channel
config before doing anything, otherwise it returns some uninitialised
fields.
4) FIX: ppc4xx_get_dma_sgl_residue() now masks out the non-count fields
when getting the count_left value. There are still problems with this
function, though.
5) FIX: ppc4xx_alloc_dma_handle() initialises the psgl pointer to NULL
to cope with the case where the dma_alloc_coherent fails.
6) ppc4xx_alloc_dma_handle() now copies the control count register
settings for burst mode into the sgl list sgl_control so that all
scatter/gather entries added later will keep the burst mode settings.
7) For scatter/gather dma the current implementation will interrupt
after every scatter/gather dma operation. To allow for only interrupting
on the very last scatter/gather, I've added a new 'int_on_final_sg'
field to the ppc_dma_ch_t structure which is used in
ppc4xx_add_dma_sgl() to mask out the interrupt settings on the previous
scatter/gather entry in the list. IMPORTANT NOTE: All users will have to
set or clear this new field when using ppc4xx_init_dma_channel() with
this patch!
Additional Comment:
I also noticed that the ppc4xx_alloc_dma_handle() function includes the
structure sgl_list_info_t within the dma region allocated for the sgl
table/list. Ideally, this structure should have it's own dma alloc, and
a pointer to the sgl table/list region, since the sgl table MUST be
quad-word aligned for the 440GX DMA controller, otherwise the dma will
immediately fail with an error (Address Alignment Error, annoyingly the
exact cause of DMA errors are not indicated anywhere). It is probably
luck that the existing sgl_list_info_t makes the following sgl
table/list quad-word aligned.
Signed-off-by: Colin P Wernham <cwernham@airspan.com>
=====================================================================
--- linux-2.6.10/include/asm-ppc/ppc4xx_dma.h 2004-12-24
21:35:01.000000000 +0000
+++ linux-current/include/asm-ppc/ppc4xx_dma.h 2005-01-19
10:59:55.000000000 +0000
@@ -137,9 +137,10 @@ extern unsigned long DMA_MODE_WRITE, DMA
#define DMA_TCE_ENABLE (1<<(8-DMA_CR_OFFSET))
#define SET_DMA_TCE(x) (((x)&0x1)<<(8-DMA_CR_OFFSET))
-#define DMA_DEC (1<<(2) /* Address Decrement */
+#define DMA_DEC (1<<(2)) /* Address Decrement */
#define SET_DMA_DEC(x) (((x)&0x1)<<2)
#define GET_DMA_DEC(x) (((x)&DMA_DEC)>>2)
+
/*
* Transfer Modes
@@ -244,6 +245,14 @@ typedef uint32_t sgl_handle_t;
#define DMA_SG2 (1<<5)
#define DMA_SG3 (1<<4)
+/* DMA Channel Count Register */
+#define DMA_CTC_BTEN (1<<23) /* Burst Enable/Disable bit */
+#define DMA_CTC_BSIZ_MSK (3<<21) /* Mask of the Burst size bits */
+#define DMA_CTC_BSIZ_2 (0)
+#define DMA_CTC_BSIZ_4 (1<<21)
+#define DMA_CTC_BSIZ_8 (2<<21)
+#define DMA_CTC_BSIZ_16 (3<<21)
+
/*
* DMA SG Command Register
*/
@@ -482,6 +491,7 @@ typedef struct {
char td; /* transfer direction */
#endif
+ char int_on_final_sg;/* for scatter/gather - only interrupt on last sg */
} ppc_dma_ch_t;
/*
@@ -545,6 +555,9 @@ extern int ppc4xx_delete_dma_sgl_element
extern int ppc4xx_alloc_dma_handle(sgl_handle_t *, unsigned int,
unsigned int);
extern void ppc4xx_free_dma_handle(sgl_handle_t);
extern int ppc4xx_get_dma_status(void);
+extern int ppc4xx_enable_burst(unsigned int);
+extern int ppc4xx_disable_burst(unsigned int);
+extern int ppc4xx_set_burst_size(unsigned int, unsigned int);
extern void ppc4xx_set_src_addr(int dmanr, phys_addr_t src_addr);
extern void ppc4xx_set_dst_addr(int dmanr, phys_addr_t dst_addr);
extern void ppc4xx_enable_dma(unsigned int dmanr);
=====================================================================
--- linux-2.6.10/arch/ppc/syslib/ppc4xx_dma.c 2004-12-24
21:35:40.000000000 +0000
+++ linux-current/arch/ppc/syslib/ppc4xx_dma.c 2005-01-19
15:34:30.000000000 +0000
@@ -512,6 +512,8 @@ ppc4xx_get_channel_config(unsigned int d
return DMA_STATUS_BAD_CHANNEL;
}
+ memcpy(p_dma_ch, &dma_channels[dmanr], sizeof (ppc_dma_ch_t));
+
#if DCRN_POL > 0
polarity = mfdcr(DCRN_POL);
#else
@@ -604,6 +606,84 @@ ppc4xx_get_peripheral_width(unsigned int
return (GET_DMA_PW(control));
}
+/*
+ * Clears the channel status bits
+ */
+int
+ppc4xx_clr_dma_status(unsigned int dmanr)
+{
+ if (dmanr >= MAX_PPC4xx_DMA_CHANNELS) {
+ printk(KERN_ERR "ppc4xx_clr_dma_status: bad channel: %d\n", dmanr);
+ return DMA_STATUS_BAD_CHANNEL;
+ }
+ mtdcr(DCRN_DMASR, ((u32)DMA_CH0_ERR | (u32)DMA_CS0 | (u32)DMA_TS0) >>
dmanr);
+ return DMA_STATUS_GOOD;
+}
+
+/*
+ * Enables the burst on the channel (BTEN bit in the control/count
register)
+ * Note:
+ * For scatter/gather dma, this function MUST be called before the
+ * ppc4xx_alloc_dma_handle() func as the chan count register is copied
into the
+ * sgl list and used as each sgl element is added.
+ */
+int
+ppc4xx_enable_burst(unsigned int dmanr)
+{
+ unsigned int ctc;
+ if (dmanr >= MAX_PPC4xx_DMA_CHANNELS) {
+ printk(KERN_ERR "ppc4xx_enable_burst: bad channel: %d\n", dmanr);
+ return DMA_STATUS_BAD_CHANNEL;
+ }
+ ctc = mfdcr(DCRN_DMACT0 + (dmanr * 0x8)) | DMA_CTC_BTEN;
+ mtdcr(DCRN_DMACT0 + (dmanr * 0x8), ctc);
+ return DMA_STATUS_GOOD;
+}
+/*
+ * Disables the burst on the channel (BTEN bit in the control/count
register)
+ * Note:
+ * For scatter/gather dma, this function MUST be called before the
+ * ppc4xx_alloc_dma_handle() func as the chan count register is copied
into the
+ * sgl list and used as each sgl element is added.
+ */
+int
+ppc4xx_disable_burst(unsigned int dmanr)
+{
+ unsigned int ctc;
+ if (dmanr >= MAX_PPC4xx_DMA_CHANNELS) {
+ printk(KERN_ERR "ppc4xx_disable_burst: bad channel: %d\n", dmanr);
+ return DMA_STATUS_BAD_CHANNEL;
+ }
+ ctc = mfdcr(DCRN_DMACT0 + (dmanr * 0x8)) &~ DMA_CTC_BTEN;
+ mtdcr(DCRN_DMACT0 + (dmanr * 0x8), ctc);
+ return DMA_STATUS_GOOD;
+}
+/*
+ * Sets the burst size (number of peripheral widths) for the channel
+ * (BSIZ bits in the control/count register))
+ * must be one of:
+ * DMA_CTC_BSIZ_2
+ * DMA_CTC_BSIZ_4
+ * DMA_CTC_BSIZ_8
+ * DMA_CTC_BSIZ_16
+ * Note:
+ * For scatter/gather dma, this function MUST be called before the
+ * ppc4xx_alloc_dma_handle() func as the chan count register is copied
into the
+ * sgl list and used as each sgl element is added.
+ */
+int
+ppc4xx_set_burst_size(unsigned int dmanr, unsigned int bsize)
+{
+ unsigned int ctc;
+ if (dmanr >= MAX_PPC4xx_DMA_CHANNELS) {
+ printk(KERN_ERR "ppc4xx_set_burst_size: bad channel: %d\n", dmanr);
+ return DMA_STATUS_BAD_CHANNEL;
+ }
+ ctc = mfdcr(DCRN_DMACT0 + (dmanr * 0x8)) &~ DMA_CTC_BSIZ_MSK;
+ ctc |= (bsize & DMA_CTC_BSIZ_MSK);
+ mtdcr(DCRN_DMACT0 + (dmanr * 0x8), ctc);
+ return DMA_STATUS_GOOD;
+}
EXPORT_SYMBOL(ppc4xx_init_dma_channel);
EXPORT_SYMBOL(ppc4xx_get_channel_config);
@@ -622,3 +702,7 @@ EXPORT_SYMBOL(ppc4xx_get_dma_residue);
EXPORT_SYMBOL(ppc4xx_enable_dma_interrupt);
EXPORT_SYMBOL(ppc4xx_disable_dma_interrupt);
EXPORT_SYMBOL(ppc4xx_get_dma_status);
+EXPORT_SYMBOL(ppc4xx_clr_dma_status);
+EXPORT_SYMBOL(ppc4xx_enable_burst);
+EXPORT_SYMBOL(ppc4xx_disable_burst);
+EXPORT_SYMBOL(ppc4xx_set_burst_size);
=====================================================================
--- linux-2.6.10/arch/ppc/syslib/ppc4xx_sgdma.c 2004-12-24
21:35:18.000000000 +0000
+++ linux-current/arch/ppc/syslib/ppc4xx_sgdma.c 2005-01-19
15:07:47.000000000 +0000
@@ -120,6 +120,12 @@ ppc4xx_add_dma_sgl(sgl_handle_t handle,
psgl->ptail = psgl->phead;
psgl->ptail_dma = psgl->phead_dma;
} else {
+ if(p_dma_ch->int_on_final_sg) {
+ /* mask out all dma interrupts, except error, on tail
+ before adding new tail. */
+ psgl->ptail->control_count &=
+ ~(SG_TCI_ENABLE | SG_ETI_ENABLE);
+ }
psgl->ptail->next = psgl->ptail_dma + sizeof(ppc_sgl_t);
psgl->ptail++;
psgl->ptail_dma += sizeof(ppc_sgl_t);
@@ -217,7 +223,7 @@ ppc4xx_get_dma_sgl_residue(sgl_handle_t
}
sgl_addr = (ppc_sgl_t *) __va(mfdcr(DCRN_ASG0 + (psgl->dmanr * 0x8)));
- count_left = mfdcr(DCRN_DMACT0 + (psgl->dmanr * 0x8));
+ count_left = mfdcr(DCRN_DMACT0 + (psgl->dmanr * 0x8)) & SG_COUNT_MASK;
if (!sgl_addr) {
printk("ppc4xx_get_dma_sgl_residue: sgl addr register is null\n");
@@ -351,10 +357,11 @@ ppc4xx_delete_dma_sgl_element(sgl_handle
int
ppc4xx_alloc_dma_handle(sgl_handle_t * phandle, unsigned int mode,
unsigned int dmanr)
{
- sgl_list_info_t *psgl;
+ sgl_list_info_t *psgl=NULL;
dma_addr_t dma_addr;
ppc_dma_ch_t *p_dma_ch = &dma_channels[dmanr];
uint32_t sg_command;
+ uint32_t ctc_settings;
void *ret;
if (dmanr >= MAX_PPC4xx_DMA_CHANNELS) {
@@ -412,6 +419,11 @@ ppc4xx_alloc_dma_handle(sgl_handle_t * p
mtdcr(DCRN_ASGC, sg_command);
psgl->sgl_control = SG_ERI_ENABLE | SG_LINK;
+ /* keep control count register settings */
+ ctc_settings = mfdcr(DCRN_DMACT0 + (dmanr * 0x8))
+ & (DMA_CTC_BSIZ_MSK | DMA_CTC_BTEN); /*burst mode settings*/
+ psgl->sgl_control |= ctc_settings;
+
if (p_dma_ch->int_enable) {
if (p_dma_ch->tce_enable)
psgl->sgl_control |= SG_TCI_ENABLE;
=====================================================================
^ permalink raw reply
* Re: Input to the timerclk on the MPC8280
From: Hans Schillstrom @ 2005-01-20 11:00 UTC (permalink / raw)
To: annamaya; +Cc: linuxppc-embedded
In-Reply-To: <20050119220819.24822.qmail@web53805.mail.yahoo.com>
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
^ permalink raw reply
* Instruction Cache Parity Error / 2.6.10 on MPC8540
From: Clemens Koller @ 2005-01-20 11:24 UTC (permalink / raw)
To: linuxppc-embedded
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
^ 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