* Re: snd-aoa status update / automatic driver loading
From: Eddy Petrişor @ 2006-05-25 7:21 UTC (permalink / raw)
To: Johannes Berg, linuxppc-dev list, debian-powerpc
In-Reply-To: <20060523154137.GA3205@spring.luon.net>
T24gNS8yMy8wNiwgU2pvZXJkIFNpbW9ucyA8c2pvZXJkQHNwcmluZy5sdW9uLm5ldD4gd3JvdGU6
Cj4gT24gRnJpLCBNYXkgMTksIDIwMDYgYXQgMTE6MjA6MjlQTSArMTAwMCwgUGF1bCBDb2xsaW5z
IHdyb3RlOgo+ID4gSm9oYW5uZXMgQmVyZyA8am9oYW5uZXNAc2lwc29sdXRpb25zLm5ldD4gd3Jp
dGVzOgo+ID4KPiA+ID4gT24gVGh1LCAyMDA2LTA1LTE4IGF0IDEwOjI1ICswMzAwLCBFZGR5IFBl
dHJpPz9vciB3cm90ZToKPiA+ID4KPiA+ID4+IEFueSBjaGFuY2UgZm9yIDUsMiA/IFdoYXQgaXMg
bmVlZGVkIGZvciBpdD8gQ29kZWMgb25seT8KPiA+ID4KPiA+ID4gSSBkb24ndCBrbm93LiBJZiB5
b3UgdHJ5IGxvYWRpbmcgdGhlIG1vZHVsZXMsIHRoZSBrZXJuZWwgd2lsbCB0ZWxsIHlvdQo+ID4g
PiBzb21ldGhpbmcgYWJvdXQgYW4gdW5oYW5kbGVkIGxheW91dCBpZC4gQWx0ZXJuYXRpdmVseSwg
eW91IGNhbiBmaW5kIHRoZQo+ID4gPiBsYXlvdXQtaWQgZmlsZSBpbiB5b3VyIC9wcm9jL2Rldmlj
ZS10cmVlLyBhbmQgdGVsbCBtZSB0aGUgbnVtYmVyIGluIGl0Lgo+ID4gPiBUaGUgcmVzdCBJIGNh
biBmaWd1cmUgb3V0Lgo+Cj4gSSB3YW50ZWQgdG8gdGVzdCBvbiBteSBQb3dlckJvb2s1LDIuIFVo
Zm9ydHVuYXRlbHkgaSBjYW4ndCBmaW5kIG5vIGxheW91dC1pZAo+IGZpbGUgZm9yIHRoZSBzb3Vu
ZCBkZXZpY2Ugb3IgYW55IG90aGVyIGxheW91dC1pZCBmaWxlIGZvciB0aGF0IG1hdHRlcjoKClNh
bWUgbWFjaGluZSBoZXJlOyBJIGhhdmUgY2xvbmVkIHRoZSBhb2EgcmVwbyBhbmQgIm1hZGUiIGl0
LgpJbnNtb2QgZGlkbid0IHdvcmsgb24gYW55IG90aGVyIG1vZHVsZSBidXQgdGhlIHRoZSBzb3Vu
ZGJ1cywgYW5kCnJlc3VsdGVkIGluIGEgbWlzc2luZyBzeW1ib2wuCgpUaGlzIGlzIG9uIGEgMi4x
Ni4xNyBrZXJuZWwKCgotLSAKUmVnYXJkcywKRWRkeVAKPT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09CiJJbWFnaW5hdGlvbiBpcyBtb3JlIGltcG9ydGFudCB0aGFu
IGtub3dsZWRnZSIgQS5FaW5zdGVpbgo=
^ permalink raw reply
* Re: RE: delay programming
From: hangtoo @ 2006-05-25 7:10 UTC (permalink / raw)
To: li yang-r58472; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 998 bytes --]
hi,
yes,you are right.the usleep didn't give out accurate delay.so I make a delay funtion to fix it.
thank you for you help.:)
regards
tony
That depends on how accurate you want. Sleep() functions can't be too accurate
for Linux schedule characteristic. To get best accuracy, you can use hardware
timer. udelay() is a choice which reduces the overall system performance.
Best Regards,
Leo
> -----Original Message-----
> From: linuxppc-embedded-bounces+leoli=freescale.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+leoli=freescale.com@ozlabs.org] On Behalf
> Of tony
> Sent: Wednesday, May 24, 2006 5:24 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: delay programming
>
>
> hi all
> I want to delay 1ms in the program,
> does usleep(1000) works accurate?
> any good idea?
>
> regards
> tony
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[-- Attachment #2: Type: text/html, Size: 1839 bytes --]
^ permalink raw reply
* Re: [Fwd: Re: via-pmu runs device_power_down in atomic context]
From: Benjamin Herrenschmidt @ 2006-05-25 5:53 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, johannes, stern, cpufreq
In-Reply-To: <1148535984.13249.253.camel@localhost.localdomain>
On Thu, 2006-05-25 at 15:46 +1000, Benjamin Herrenschmidt wrote:
> > This requirement to keep interrupts off in there breaks things again and
> > again and again and again. And this time: again.
>
> Where else ?
>
> If you look at this function it's _designed_ for interrupts off ! the
> driver suspend have the option of deferring their suspend() callback
> until after irqs have been turned off (needed for legacy stuff afaik but
> rarely used) and the sysdev's are very low level things whose suspend
> and resume callbacks should be called after that point as well.
BTW. The root of the problem with cpufreq is it's upside down design :)
Well, not all of it, but the fact that it registers a sysdev. It's not
the "midlayer" (ugh) business to register devices and hook things like
PM events to pass them down to actual drivers. It should be the cpufreq
drivers themselves that attach to the device model in a way or another
and "instanciate" the ability to control the cpu frequency, passing
along their struct device.
The driver itself should pick the right type of "device" to attach to
(sysdev's are just weird beast and were a bad idea in the first place
since they aren't even struct device).
But then, iirc, that's because we also did the cpu stuff in sysfs upside
down too ... :)
Now, wether the cpufreq notifier might end up calling things that will
sleep or not ... hrm... that's an interesting issue. Part of the problem
is that because cpufreq is a sysdev, it will be called so late in the
suspend process, pretty much everything else is asleep. So I'm quite
confident that things attaching to the cpufreq notifiers other than bits
of cpufreq itself are likely to break anyway. Is it documented anywhere
that registering a cpufreq notifier might cause it to be called in
atomic context or very later in the suspend process (possibly after the
interrupt controller hs been put down) ?
Yes it's messy, no I don't have a miracle solution, but I think here the
proper way to fix it in the long run is for cpufreq not to be a sysdev
or anything like that and to stop trying to do the suspend/resume thing
for the drivers. Drivers are in charge, they get to create the device of
whatever type it is and get the suspend/resume events whenever they are
sent. cpufreq can then provide maybe "helpers" to help work out what to
do at suspend and/or resume time but with the knowledge that for some
drivers maybe, this will happen in atomic context.
Ben.
^ permalink raw reply
* Re: [Fwd: Re: via-pmu runs device_power_down in atomic context]
From: Benjamin Herrenschmidt @ 2006-05-25 5:46 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, johannes, stern, cpufreq
In-Reply-To: <20060524223658.6fc797f5.akpm@osdl.org>
> This requirement to keep interrupts off in there breaks things again and
> again and again and again. And this time: again.
Where else ?
If you look at this function it's _designed_ for interrupts off ! the
driver suspend have the option of deferring their suspend() callback
until after irqs have been turned off (needed for legacy stuff afaik but
rarely used) and the sysdev's are very low level things whose suspend
and resume callbacks should be called after that point as well.
Ben.
^ permalink raw reply
* Re: [Fwd: Re: via-pmu runs device_power_down in atomic context]
From: Benjamin Herrenschmidt @ 2006-05-25 5:44 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, Johannes Berg, Alan Stern, cpufreq
In-Reply-To: <1148534398.13249.246.camel@localhost.localdomain>
> No. If we call device_power_down with interrupts enabled, very bad
> things will happen. This powermac code is very carefully crafted to do
> things in a strict order and it's along those lines that the callbacks
> in the device model were initially defined. Now, people who don't
> understand shit about how to make power management reliable may have
> broken things around, but the powermac implementation is right there.
To be more precise, sysdev suspend is supposed to happen with irq offs
(it's specifically designed to handle legacy things, interrupt
controllers, ec...). Thus cpufreq suspend/resume need to assume that
it's being called in that context or be made something else than a
sysdev...
Regarding the possible down() if we walk through the irq_off device
list, well, that's indeed annoying, we probably need to pass a "no_lock"
argument. Never hit that one since as I told you, there are really few
if not no drivers using this facility of deferring suspend to after
interrupts are disabled. Also, the down there is harmless as in no
normal circumstances should it ever turn into a schedule() (there should
be no contention possible that late in the suspend process).
Ben.
^ permalink raw reply
* Re: [Fwd: Re: via-pmu runs device_power_down in atomic context]
From: Andrew Morton @ 2006-05-25 5:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, johannes, stern, cpufreq
In-Reply-To: <1148534398.13249.246.camel@localhost.localdomain>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
>
> > Here, pmac has gone and unilaterally decided that device_power_down() is
> > atomic, even though device_power_down() _already_ calls suspend_device(),
> > which does down(). So I'd say you've gone and found a via-pmu bug here.
>
> No. Look at the implementation (and the comment) in device_power_down().
> It's designed to be called with irqs off... Of course, somebody changed
> the locking in there and it's indeed ending up calling suspend_device()
> for devices on the irq_off list which calls down ... bad bad... that's
> another bug in the drivers/power/* to add to an already long list.
> Fortunately, very few (if any) devics rely on this irq_off list. But
> sysdev's do.
uh-huh.
> > A way of shutting up the warning would be to use an atomic notifier, but
> > it'll still be buggy. Better would be to teach pmac_suspend_devices() not
> > to assume things which aren't true ;)
>
> No. If we call device_power_down with interrupts enabled, very bad
> things will happen. This powermac code is very carefully crafted to do
> things in a strict order and it's along those lines that the callbacks
> in the device model were initially defined. Now, people who don't
> understand shit about how to make power management reliable may have
> broken things around, but the powermac implementation is right there.
>
This requirement to keep interrupts off in there breaks things again and
again and again and again. And this time: again.
It looks like we (again) have to live with it in which case conversion to
an atomic notifier is probably needed. That may break other things though.
Alan would know.
^ permalink raw reply
* Re: [Fwd: Re: via-pmu runs device_power_down in atomic context]
From: Benjamin Herrenschmidt @ 2006-05-25 5:19 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, Johannes Berg, Alan Stern, cpufreq
In-Reply-To: <20060524215917.230af218.akpm@osdl.org>
> Here, pmac has gone and unilaterally decided that device_power_down() is
> atomic, even though device_power_down() _already_ calls suspend_device(),
> which does down(). So I'd say you've gone and found a via-pmu bug here.
No. Look at the implementation (and the comment) in device_power_down().
It's designed to be called with irqs off... Of course, somebody changed
the locking in there and it's indeed ending up calling suspend_device()
for devices on the irq_off list which calls down ... bad bad... that's
another bug in the drivers/power/* to add to an already long list.
Fortunately, very few (if any) devics rely on this irq_off list. But
sysdev's do.
> A way of shutting up the warning would be to use an atomic notifier, but
> it'll still be buggy. Better would be to teach pmac_suspend_devices() not
> to assume things which aren't true ;)
No. If we call device_power_down with interrupts enabled, very bad
things will happen. This powermac code is very carefully crafted to do
things in a strict order and it's along those lines that the callbacks
in the device model were initially defined. Now, people who don't
understand shit about how to make power management reliable may have
broken things around, but the powermac implementation is right there.
Ben.
^ permalink raw reply
* Re: [Fwd: Re: via-pmu runs device_power_down in atomic context]
From: Andrew Morton @ 2006-05-25 4:59 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Johannes Berg, Alan Stern, cpufreq
In-Reply-To: <1148531830.13249.237.camel@localhost.localdomain>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> -------- Forwarded Message --------
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> To: Johannes Berg <johannes@sipsolutions.net>
> Cc: linuxppc-dev list <linuxppc-dev@ozlabs.org>, Michael Hanselmann
> <linux-kernel@hansmi.ch>, cpufreq@lists.linux.org.uk
> Subject: Re: via-pmu runs device_power_down in atomic context
> Date: Thu, 25 May 2006 12:28:15 +1000
>
> On Wed, 2006-05-24 at 10:01 +0200, Johannes Berg wrote:
> > Hey,
> >
> > Everytime I suspend my powerbook, I see the following trace:
> >
> > [10655.887546] BUG: sleeping function called from invalid context at include/linux/rwsem.h:43
> > [10655.887558] in_atomic():0, irqs_disabled():1
> > [10655.887562] Call Trace:
> > [10655.887565] [C581BD20] [C00081E8] show_stack+0x50/0x190 (unreliable)
> > [10655.887582] [C581BD50] [C0023BB0] __might_sleep+0xcc/0xe8
> > [10655.887592] [C581BD60] [C0038290] blocking_notifier_call_chain+0x2c/0xc0
> > [10655.887606] [C581BD80] [C01E90C0] cpufreq_suspend+0x130/0x148
> > [10655.887616] [C581BDB0] [C019D9E8] sysdev_suspend+0x10c/0x300
> > [10655.887627] [C581BDF0] [C01A3888] device_power_down+0x74/0xac
> > [10655.887636] [C581BE10] [C01B1264] pmac_suspend_devices+0x98/0x188
> > [10655.887643] [C581BE30] [C01B18F0] pmu_ioctl+0x59c/0xbc0
> > [10655.887649] [C581BED0] [C008E898] do_ioctl+0x80/0x84
> > [10655.887660] [C581BEE0] [C008E928] vfs_ioctl+0x8c/0x48c
> > [10655.887666] [C581BF10] [C008ED68] sys_ioctl+0x40/0x74
> > [10655.887673] [C581BF40] [C000F3A4] ret_from_syscall+0x0/0x38
> >
> > The might_sleep() comes from down_read() and this happens because
> > blocking_notifier_call_chain calls it, it is also commented to run in
> > process context so this is all proper.
>
> device_power_down should be called with interrupts off, thus the PMU
> driver is fine. It's a misnamed function, it calls the sysdev's suspend
> and those should be called with irq off. I think the problem is more due
> to some cpufreq or notifier change that somebody done to recent kernels
> and that added some might_sleep.... I wonder why.
>
> Andrew, what's up there ? What is this new
> "blocking_notifier_call_chain" thing ? notifiers use to not use
> semaphores and not be blocking... at least powermac implementation of
> cpufreq relies on that.
notifiers used to be racy too - we just waddled across them without any
locking.
Alan made a best-effort conversion of callers, and there have been a few
problems.
Here, pmac has gone and unilaterally decided that device_power_down() is
atomic, even though device_power_down() _already_ calls suspend_device(),
which does down(). So I'd say you've gone and found a via-pmu bug here.
A way of shutting up the warning would be to use an atomic notifier, but
it'll still be buggy. Better would be to teach pmac_suspend_devices() not
to assume things which aren't true ;)
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 3/10] Powerpc: Add tsi108 common function
From: Zang Roy-r61911 @ 2006-05-25 4:20 UTC (permalink / raw)
To: Kumar Gala, Benjamin Herrenschmidt
Cc: linuxppc-dev list, Yang Xin-Xin-r48390, Paul Mackerras,
Alexandre.Bounine
> Can the PCI use indirect like used on most other PPC platforms.
Now , I was confirmed that we cannot switch to it.
Reason for that is our need for the machine check exception handling for PCI Config reads.
Tsi108/109 does not have HW mechanism to ignore Master Abort during Config read and return all ones.
We have to provide our routine with .fixup section to be able process failed PCI Config reads (Master Abort on PCI).
The indirect method relies on the HW mechanism.
Another question that appeared around machine check handling was calling of tsi108_clear_pci_cfg_error() function.
We have it to clean errors reported during PCI bus probe. We may skip it (and PCI block still be operational) but
this will block error reporting mechanism because the PCI block only records the first detected error.
So we decided it may be better to keep error reporting active by cleaning errors that we expect during PCI enumeration.
I do not see any harm here because I will provide our own machine check handler in my board support file according to
Ben's suggestion.
Roy
>
> > +int
> > +tsi108_direct_write_config(struct pci_bus *bus, unsigned
> int devfunc,
> > + int offset, int len, u32 val)
> > +{
> > + volatile unsigned char *cfg_addr;
> > +
> > + cfg_addr = (unsigned char *)(tsi_mk_config_addr(bus->number,
> > +
> devfunc, offset) |
> > + (offset & 0x03));
> > +
> > +#ifdef TSI108_PCI_DEBUG
> > + printk("PCI CFG write : ");
> > + printk("%d:0x%x:0x%x ", bus->number, devfunc, offset);
> > + printk("%d ADDR=0x%08x ", len, (uint) cfg_addr);
> > + printk("data = 0x%08x\n", val);
> > +#endif
> > +
> > + switch (len) {
> > + case 1:
> > + out_8((u8 *) cfg_addr, val);
> > + break;
> > + case 2:
> > + out_le16((u16 *) cfg_addr, val);
> > + break;
> > + default:
> > + out_le32((u32 *) cfg_addr, val);
> > + break;
> > + }
> > +
> > + return PCIBIOS_SUCCESSFUL;
> > +}
> > +
^ permalink raw reply
* Re: via-pmu runs device_power_down in atomic context
From: Benjamin Herrenschmidt @ 2006-05-25 2:28 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, cpufreq
In-Reply-To: <1148457661.11734.9.camel@johannes>
On Wed, 2006-05-24 at 10:01 +0200, Johannes Berg wrote:
> Hey,
>
> Everytime I suspend my powerbook, I see the following trace:
>
> [10655.887546] BUG: sleeping function called from invalid context at include/linux/rwsem.h:43
> [10655.887558] in_atomic():0, irqs_disabled():1
> [10655.887562] Call Trace:
> [10655.887565] [C581BD20] [C00081E8] show_stack+0x50/0x190 (unreliable)
> [10655.887582] [C581BD50] [C0023BB0] __might_sleep+0xcc/0xe8
> [10655.887592] [C581BD60] [C0038290] blocking_notifier_call_chain+0x2c/0xc0
> [10655.887606] [C581BD80] [C01E90C0] cpufreq_suspend+0x130/0x148
> [10655.887616] [C581BDB0] [C019D9E8] sysdev_suspend+0x10c/0x300
> [10655.887627] [C581BDF0] [C01A3888] device_power_down+0x74/0xac
> [10655.887636] [C581BE10] [C01B1264] pmac_suspend_devices+0x98/0x188
> [10655.887643] [C581BE30] [C01B18F0] pmu_ioctl+0x59c/0xbc0
> [10655.887649] [C581BED0] [C008E898] do_ioctl+0x80/0x84
> [10655.887660] [C581BEE0] [C008E928] vfs_ioctl+0x8c/0x48c
> [10655.887666] [C581BF10] [C008ED68] sys_ioctl+0x40/0x74
> [10655.887673] [C581BF40] [C000F3A4] ret_from_syscall+0x0/0x38
>
> The might_sleep() comes from down_read() and this happens because
> blocking_notifier_call_chain calls it, it is also commented to run in
> process context so this is all proper.
device_power_down should be called with interrupts off, thus the PMU
driver is fine. It's a misnamed function, it calls the sysdev's suspend
and those should be called with irq off. I think the problem is more due
to some cpufreq or notifier change that somebody done to recent kernels
and that added some might_sleep.... I wonder why.
Andrew, what's up there ? What is this new
"blocking_notifier_call_chain" thing ? notifiers use to not use
semaphores and not be blocking... at least powermac implementation of
cpufreq relies on that.
> However, it obviously isn't run at process context. Looking why, I see
> this in via-pmu.c:
> /* We can now disable MSR_EE. This code of course works properly only
> * on UP machines... For SMP, if we ever implement sleep, we'll have to
> * stop the "other" CPUs way before we do all that stuff.
> */
> local_irq_disable();
>
> /* Broadcast power down irq
> * This isn't that useful in most cases (only directly wired devices can
> * use this but still... This will take care of sysdev's as well, so
> * we exit from here with local irqs disabled and PIC off.
> */
> ret = device_power_down(PMSG_SUSPEND);
>
> Apparently this was a deliberate decision.
>
> So the question is: which is correct? I can test and submit a patch to
> fix the issue at either end; if cpufreq is wrong I'd move from a
> blocking_ to an atomic_notifier_call_chain, if via-pmu.c is wrong I'd
> call device_power_down earlier...
>
> johannes
^ permalink raw reply
* Re: pmppc7448/mv64x60 DMA from PCI to memory
From: Phil Nitschke @ 2006-05-25 0:21 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-embedded
In-Reply-To: <20060524205216.GB11130@mag.az.mvista.com>
On Wed, 2006-05-24 at 13:52 -0700, Mark A. Greer wrote:
> On Wed, May 24, 2006 at 11:53:54AM +0930, Phil Nitschke wrote:
> > On Tue, 2006-05-23 at 16:54 -0700, Mark A. Greer wrote:
> >
> > > You say that you don't see any PCI traffic. Does that mean you
> > > have a PCI analyzer and that you are sure that its set up correctly?
> >
> > I don't have a PCI analyzer, however the JTAG used to program the PCI
> > device has been configured to display 4 K samples of PCI bus signals
> > (about 20 microsecs?) around the time of an interrupt which results in
> > the DMA being requested. Since my last post, I have managed to see some
> > traffic, but the PCI STOP# line is asserted, so I'm not seeing any data
> > being read. I'll investigate further...
It turns out that the PCI device firmware was not responding correctly
to MRL and MRM (memory read multiple) PCI commands, but was working for
MR... Fixed now, and DMA from PCI is working. Just looking at byte
order today.
> > OK. I also note there are several cases where this is used in
> > mv64x60.c:
> >
> > for (i=0; i<3; i++)
> >
> > Why is 3 used in these loops, and not some other constant like
> > MV64360_xxxxx_WINDOWS (which are usually 4, not 3)?
>
> Different things. The "i<3;" are when looping through windows that are
> related to a struct pci_controller's mem_resource.
OK.
> > > > Do I need to add
> > > > tests to my source and destination regions, to determine if they
> > > > cross one of the 512 MB regions, and hence will require a
> > > > different CSx line (and thus the DMA will need to be broken into
> > > > two transactions), or does kernel already take care to ensure
> > > > allocated regions will not cross these boundaries?
> > >
> > > No. You need to do what's appropriate for the hardware that you are
> > > essentially writing a driver for. YOU are supposed to know what the
> > > limitations of your hardware are.
> >
> > OK, I know how my hardware is configured, but when trying to write a
> > generic driver, perhaps I need to have the mv64x60.c code remember the
> > CSx barriers, e.g. in the mv64x60_chip_info, so the IDMA engine can
> > access it. Do you think this would be possible/beneficial?
>
> No. Just set up and enable an IDMA window to access all of pci mem space
> and be done with it.
No, this is different. The patch I posted does map all the PCI mem
space as you've suggested. The problem I'm trying to avoid is if the
IDMA engine tries to transfer data from this PCI mem region into a
buffer that crosses one of the DRAM address windows (and hence uses
different CSn lines). Then the transfer needs to be broken into two
separate DMAs. But if this information is not stored in the chip info,
how is the DMA driver to know where the memory boundaries are (except by
reading the already programmed windows and deducing these boundaries)?
> I didn't go through this in great detail but it looks like you have
> the right idea (IMHO). Although, I don't know why you didn't just
> use windows 4-7 for the idma->pci mappings and leave the idma->mem code
> alone.
Two reasons (however flaky). The lower 4 windows have an upper 32-bit
address register, so it is better to leave these for users (lucky
bastards!) that have more than 4 GB address space. Secondly, the IDMA
supports the address override feature (which I was trying to use in
desperation when nothing was working for me), wherein the transaction
target interface, attributes and upper 32-bit address are taken from
BAR1, BAR2 or BAR3. So I thought it would be better to leave these
alone.
--
Phil
^ permalink raw reply
* [PATCH] Fix oprofile support for e500 in arch/powerpc
From: Andy Fleming @ 2006-05-24 22:57 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
Fixed a compile error in building the 85xx support with oprofile, and in
the process cleaned up some issues with the fsl_booke performance monitor
code.
Signed-off-by: Andy Fleming <afleming@freescale.com>
* Reorganized FSL Book-E performance monitoring code so that the 7450
wouldn't be built if the e500 was, and cleaned it up so it was more
self-contained.
* Added a cpu_setup function for FSL Book-E. The original
cpu_setup function prototype had no arguments, assuming that
the reg_setup function would copy the required information into
variables which represented the registers. This was silly for
e500, since it has 1 register per counter (rather than 3 for
all counters), so the code has been restructured to have
cpu_setup take the current counter config array as an argument,
with op_powerpc_setup() invoking op_powerpc_cpu_setup() through
on_each_cpu(), and op_powerpc_cpu_setup() invoking the
model-specific cpu_setup function with an argument. The
argument is ignored on all other platforms at present.
* Fixed a confusing line where a trinary operator only had two
arguments
---
arch/powerpc/kernel/Makefile | 1
arch/powerpc/kernel/perfmon_fsl_booke.c | 222 ----------------------------
arch/powerpc/kernel/pmc.c | 2
arch/powerpc/oprofile/Makefile | 2
arch/powerpc/oprofile/common.c | 10 +
arch/powerpc/oprofile/op_model_7450.c | 2
arch/powerpc/oprofile/op_model_fsl_booke.c | 170 +++++++++++++++++----
arch/powerpc/oprofile/op_model_power4.c | 2
arch/powerpc/oprofile/op_model_rs64.c | 2
include/asm-powerpc/oprofile_impl.h | 87 +++++++++++
include/asm-powerpc/pmc.h | 13 --
11 files changed, 234 insertions(+), 279 deletions(-)
delete mode 100644 arch/powerpc/kernel/perfmon_fsl_booke.c
a53f64aff10cd90f1813fa316d89703c13419db3
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 803858e..a08c348 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -38,7 +38,6 @@ obj-$(CONFIG_6xx) += idle_6xx.o l2cr_6x
obj-$(CONFIG_TAU) += tau_6xx.o
obj32-$(CONFIG_SOFTWARE_SUSPEND) += swsusp_32.o
obj32-$(CONFIG_MODULES) += module_32.o
-obj-$(CONFIG_E500) += perfmon_fsl_booke.o
ifeq ($(CONFIG_PPC_MERGE),y)
diff --git a/arch/powerpc/kernel/perfmon_fsl_booke.c b/arch/powerpc/kernel/perfmon_fsl_booke.c
deleted file mode 100644
index 32455df..0000000
--- a/arch/powerpc/kernel/perfmon_fsl_booke.c
+++ /dev/null
@@ -1,222 +0,0 @@
-/* kernel/perfmon_fsl_booke.c
- * Freescale Book-E Performance Monitor code
- *
- * Author: Andy Fleming
- * Copyright (c) 2004 Freescale Semiconductor, Inc
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- */
-
-#include <linux/errno.h>
-#include <linux/sched.h>
-#include <linux/kernel.h>
-#include <linux/mm.h>
-#include <linux/stddef.h>
-#include <linux/unistd.h>
-#include <linux/ptrace.h>
-#include <linux/slab.h>
-#include <linux/user.h>
-#include <linux/a.out.h>
-#include <linux/interrupt.h>
-#include <linux/config.h>
-#include <linux/init.h>
-#include <linux/module.h>
-#include <linux/prctl.h>
-
-#include <asm/pgtable.h>
-#include <asm/uaccess.h>
-#include <asm/system.h>
-#include <asm/io.h>
-#include <asm/reg.h>
-#include <asm/xmon.h>
-#include <asm/pmc.h>
-
-static inline u32 get_pmlca(int ctr);
-static inline void set_pmlca(int ctr, u32 pmlca);
-
-static inline u32 get_pmlca(int ctr)
-{
- u32 pmlca;
-
- switch (ctr) {
- case 0:
- pmlca = mfpmr(PMRN_PMLCA0);
- break;
- case 1:
- pmlca = mfpmr(PMRN_PMLCA1);
- break;
- case 2:
- pmlca = mfpmr(PMRN_PMLCA2);
- break;
- case 3:
- pmlca = mfpmr(PMRN_PMLCA3);
- break;
- default:
- panic("Bad ctr number\n");
- }
-
- return pmlca;
-}
-
-static inline void set_pmlca(int ctr, u32 pmlca)
-{
- switch (ctr) {
- case 0:
- mtpmr(PMRN_PMLCA0, pmlca);
- break;
- case 1:
- mtpmr(PMRN_PMLCA1, pmlca);
- break;
- case 2:
- mtpmr(PMRN_PMLCA2, pmlca);
- break;
- case 3:
- mtpmr(PMRN_PMLCA3, pmlca);
- break;
- default:
- panic("Bad ctr number\n");
- }
-}
-
-void init_pmc_stop(int ctr)
-{
- u32 pmlca = (PMLCA_FC | PMLCA_FCS | PMLCA_FCU |
- PMLCA_FCM1 | PMLCA_FCM0);
- u32 pmlcb = 0;
-
- switch (ctr) {
- case 0:
- mtpmr(PMRN_PMLCA0, pmlca);
- mtpmr(PMRN_PMLCB0, pmlcb);
- break;
- case 1:
- mtpmr(PMRN_PMLCA1, pmlca);
- mtpmr(PMRN_PMLCB1, pmlcb);
- break;
- case 2:
- mtpmr(PMRN_PMLCA2, pmlca);
- mtpmr(PMRN_PMLCB2, pmlcb);
- break;
- case 3:
- mtpmr(PMRN_PMLCA3, pmlca);
- mtpmr(PMRN_PMLCB3, pmlcb);
- break;
- default:
- panic("Bad ctr number!\n");
- }
-}
-
-void set_pmc_event(int ctr, int event)
-{
- u32 pmlca;
-
- pmlca = get_pmlca(ctr);
-
- pmlca = (pmlca & ~PMLCA_EVENT_MASK) |
- ((event << PMLCA_EVENT_SHIFT) &
- PMLCA_EVENT_MASK);
-
- set_pmlca(ctr, pmlca);
-}
-
-void set_pmc_user_kernel(int ctr, int user, int kernel)
-{
- u32 pmlca;
-
- pmlca = get_pmlca(ctr);
-
- if(user)
- pmlca &= ~PMLCA_FCU;
- else
- pmlca |= PMLCA_FCU;
-
- if(kernel)
- pmlca &= ~PMLCA_FCS;
- else
- pmlca |= PMLCA_FCS;
-
- set_pmlca(ctr, pmlca);
-}
-
-void set_pmc_marked(int ctr, int mark0, int mark1)
-{
- u32 pmlca = get_pmlca(ctr);
-
- if(mark0)
- pmlca &= ~PMLCA_FCM0;
- else
- pmlca |= PMLCA_FCM0;
-
- if(mark1)
- pmlca &= ~PMLCA_FCM1;
- else
- pmlca |= PMLCA_FCM1;
-
- set_pmlca(ctr, pmlca);
-}
-
-void pmc_start_ctr(int ctr, int enable)
-{
- u32 pmlca = get_pmlca(ctr);
-
- pmlca &= ~PMLCA_FC;
-
- if (enable)
- pmlca |= PMLCA_CE;
- else
- pmlca &= ~PMLCA_CE;
-
- set_pmlca(ctr, pmlca);
-}
-
-void pmc_start_ctrs(int enable)
-{
- u32 pmgc0 = mfpmr(PMRN_PMGC0);
-
- pmgc0 &= ~PMGC0_FAC;
- pmgc0 |= PMGC0_FCECE;
-
- if (enable)
- pmgc0 |= PMGC0_PMIE;
- else
- pmgc0 &= ~PMGC0_PMIE;
-
- mtpmr(PMRN_PMGC0, pmgc0);
-}
-
-void pmc_stop_ctrs(void)
-{
- u32 pmgc0 = mfpmr(PMRN_PMGC0);
-
- pmgc0 |= PMGC0_FAC;
-
- pmgc0 &= ~(PMGC0_PMIE | PMGC0_FCECE);
-
- mtpmr(PMRN_PMGC0, pmgc0);
-}
-
-void dump_pmcs(void)
-{
- printk("pmgc0: %x\n", mfpmr(PMRN_PMGC0));
- printk("pmc\t\tpmlca\t\tpmlcb\n");
- printk("%8x\t%8x\t%8x\n", mfpmr(PMRN_PMC0),
- mfpmr(PMRN_PMLCA0), mfpmr(PMRN_PMLCB0));
- printk("%8x\t%8x\t%8x\n", mfpmr(PMRN_PMC1),
- mfpmr(PMRN_PMLCA1), mfpmr(PMRN_PMLCB1));
- printk("%8x\t%8x\t%8x\n", mfpmr(PMRN_PMC2),
- mfpmr(PMRN_PMLCA2), mfpmr(PMRN_PMLCB2));
- printk("%8x\t%8x\t%8x\n", mfpmr(PMRN_PMC3),
- mfpmr(PMRN_PMLCA3), mfpmr(PMRN_PMLCB3));
-}
-
-EXPORT_SYMBOL(init_pmc_stop);
-EXPORT_SYMBOL(set_pmc_event);
-EXPORT_SYMBOL(set_pmc_user_kernel);
-EXPORT_SYMBOL(set_pmc_marked);
-EXPORT_SYMBOL(pmc_start_ctr);
-EXPORT_SYMBOL(pmc_start_ctrs);
-EXPORT_SYMBOL(pmc_stop_ctrs);
-EXPORT_SYMBOL(dump_pmcs);
diff --git a/arch/powerpc/kernel/pmc.c b/arch/powerpc/kernel/pmc.c
index e6fb194..63b79dc 100644
--- a/arch/powerpc/kernel/pmc.c
+++ b/arch/powerpc/kernel/pmc.c
@@ -72,7 +72,7 @@ int reserve_pmc_hardware(perf_irq_t new_
}
pmc_owner_caller = __builtin_return_address(0);
- perf_irq = new_perf_irq ? : dummy_perf;
+ perf_irq = new_perf_irq ? new_perf_irq : dummy_perf;
out:
spin_unlock(&pmc_owner_lock);
diff --git a/arch/powerpc/oprofile/Makefile b/arch/powerpc/oprofile/Makefile
index f5f9859..ef0dda3 100644
--- a/arch/powerpc/oprofile/Makefile
+++ b/arch/powerpc/oprofile/Makefile
@@ -9,4 +9,4 @@ DRIVER_OBJS := $(addprefix ../../../driv
oprofile-y := $(DRIVER_OBJS) common.o backtrace.o
oprofile-$(CONFIG_PPC64) += op_model_rs64.o op_model_power4.o
oprofile-$(CONFIG_FSL_BOOKE) += op_model_fsl_booke.o
-oprofile-$(CONFIG_PPC32) += op_model_7450.o
+oprofile-$(CONFIG_6xx) += op_model_7450.o
diff --git a/arch/powerpc/oprofile/common.c b/arch/powerpc/oprofile/common.c
index 5b1de7e..b2cb8b1 100644
--- a/arch/powerpc/oprofile/common.c
+++ b/arch/powerpc/oprofile/common.c
@@ -33,6 +33,11 @@ static void op_handle_interrupt(struct p
model->handle_interrupt(regs, ctr);
}
+static void op_powerpc_cpu_setup(void *dummy)
+{
+ model->cpu_setup(ctr);
+}
+
static int op_powerpc_setup(void)
{
int err;
@@ -46,7 +51,7 @@ static int op_powerpc_setup(void)
model->reg_setup(ctr, &sys, model->num_counters);
/* Configure the registers on all cpus. */
- on_each_cpu(model->cpu_setup, NULL, 0, 1);
+ on_each_cpu(op_powerpc_cpu_setup, NULL, 0, 1);
return 0;
}
@@ -138,7 +143,8 @@ #ifdef CONFIG_PPC64
case PPC_OPROFILE_POWER4:
model = &op_model_power4;
break;
-#else
+#endif
+#ifdef CONFIG_6xx
case PPC_OPROFILE_G4:
model = &op_model_7450;
break;
diff --git a/arch/powerpc/oprofile/op_model_7450.c b/arch/powerpc/oprofile/op_model_7450.c
index e0491c3..169316d 100644
--- a/arch/powerpc/oprofile/op_model_7450.c
+++ b/arch/powerpc/oprofile/op_model_7450.c
@@ -81,7 +81,7 @@ static void pmc_stop_ctrs(void)
/* Configures the counters on this CPU based on the global
* settings */
-static void fsl7450_cpu_setup(void *unused)
+static void fsl7450_cpu_setup(struct op_counter_config *ctr)
{
/* freeze all counters */
pmc_stop_ctrs();
diff --git a/arch/powerpc/oprofile/op_model_fsl_booke.c b/arch/powerpc/oprofile/op_model_fsl_booke.c
index 93d63e6..f5234d2 100644
--- a/arch/powerpc/oprofile/op_model_fsl_booke.c
+++ b/arch/powerpc/oprofile/op_model_fsl_booke.c
@@ -32,42 +32,152 @@ static unsigned long reset_value[OP_MAX_
static int num_counters;
static int oprofile_running;
-static inline unsigned int ctr_read(unsigned int i)
+static void init_pmc_stop(int ctr)
{
- switch(i) {
- case 0:
- return mfpmr(PMRN_PMC0);
- case 1:
- return mfpmr(PMRN_PMC1);
- case 2:
- return mfpmr(PMRN_PMC2);
- case 3:
- return mfpmr(PMRN_PMC3);
- default:
- return 0;
- }
-}
+ u32 pmlca = (PMLCA_FC | PMLCA_FCS | PMLCA_FCU |
+ PMLCA_FCM1 | PMLCA_FCM0);
+ u32 pmlcb = 0;
-static inline void ctr_write(unsigned int i, unsigned int val)
-{
- switch(i) {
+ switch (ctr) {
case 0:
- mtpmr(PMRN_PMC0, val);
+ mtpmr(PMRN_PMLCA0, pmlca);
+ mtpmr(PMRN_PMLCB0, pmlcb);
break;
case 1:
- mtpmr(PMRN_PMC1, val);
+ mtpmr(PMRN_PMLCA1, pmlca);
+ mtpmr(PMRN_PMLCB1, pmlcb);
break;
case 2:
- mtpmr(PMRN_PMC2, val);
+ mtpmr(PMRN_PMLCA2, pmlca);
+ mtpmr(PMRN_PMLCB2, pmlcb);
break;
case 3:
- mtpmr(PMRN_PMC3, val);
+ mtpmr(PMRN_PMLCA3, pmlca);
+ mtpmr(PMRN_PMLCB3, pmlcb);
break;
default:
- break;
+ panic("Bad ctr number!\n");
}
}
+static void set_pmc_event(int ctr, int event)
+{
+ u32 pmlca;
+
+ pmlca = get_pmlca(ctr);
+
+ pmlca = (pmlca & ~PMLCA_EVENT_MASK) |
+ ((event << PMLCA_EVENT_SHIFT) &
+ PMLCA_EVENT_MASK);
+
+ set_pmlca(ctr, pmlca);
+}
+
+static void set_pmc_user_kernel(int ctr, int user, int kernel)
+{
+ u32 pmlca;
+
+ pmlca = get_pmlca(ctr);
+
+ if(user)
+ pmlca &= ~PMLCA_FCU;
+ else
+ pmlca |= PMLCA_FCU;
+
+ if(kernel)
+ pmlca &= ~PMLCA_FCS;
+ else
+ pmlca |= PMLCA_FCS;
+
+ set_pmlca(ctr, pmlca);
+}
+
+static void set_pmc_marked(int ctr, int mark0, int mark1)
+{
+ u32 pmlca = get_pmlca(ctr);
+
+ if(mark0)
+ pmlca &= ~PMLCA_FCM0;
+ else
+ pmlca |= PMLCA_FCM0;
+
+ if(mark1)
+ pmlca &= ~PMLCA_FCM1;
+ else
+ pmlca |= PMLCA_FCM1;
+
+ set_pmlca(ctr, pmlca);
+}
+
+static void pmc_start_ctr(int ctr, int enable)
+{
+ u32 pmlca = get_pmlca(ctr);
+
+ pmlca &= ~PMLCA_FC;
+
+ if (enable)
+ pmlca |= PMLCA_CE;
+ else
+ pmlca &= ~PMLCA_CE;
+
+ set_pmlca(ctr, pmlca);
+}
+
+static void pmc_start_ctrs(int enable)
+{
+ u32 pmgc0 = mfpmr(PMRN_PMGC0);
+
+ pmgc0 &= ~PMGC0_FAC;
+ pmgc0 |= PMGC0_FCECE;
+
+ if (enable)
+ pmgc0 |= PMGC0_PMIE;
+ else
+ pmgc0 &= ~PMGC0_PMIE;
+
+ mtpmr(PMRN_PMGC0, pmgc0);
+}
+
+static void pmc_stop_ctrs(void)
+{
+ u32 pmgc0 = mfpmr(PMRN_PMGC0);
+
+ pmgc0 |= PMGC0_FAC;
+
+ pmgc0 &= ~(PMGC0_PMIE | PMGC0_FCECE);
+
+ mtpmr(PMRN_PMGC0, pmgc0);
+}
+
+static void dump_pmcs(void)
+{
+ printk("pmgc0: %x\n", mfpmr(PMRN_PMGC0));
+ printk("pmc\t\tpmlca\t\tpmlcb\n");
+ printk("%8x\t%8x\t%8x\n", mfpmr(PMRN_PMC0),
+ mfpmr(PMRN_PMLCA0), mfpmr(PMRN_PMLCB0));
+ printk("%8x\t%8x\t%8x\n", mfpmr(PMRN_PMC1),
+ mfpmr(PMRN_PMLCA1), mfpmr(PMRN_PMLCB1));
+ printk("%8x\t%8x\t%8x\n", mfpmr(PMRN_PMC2),
+ mfpmr(PMRN_PMLCA2), mfpmr(PMRN_PMLCB2));
+ printk("%8x\t%8x\t%8x\n", mfpmr(PMRN_PMC3),
+ mfpmr(PMRN_PMLCA3), mfpmr(PMRN_PMLCB3));
+}
+
+static void fsl_booke_cpu_setup(struct op_counter_config *ctr)
+{
+ int i;
+
+ /* freeze all counters */
+ pmc_stop_ctrs();
+
+ for (i = 0;i < num_counters;i++) {
+ init_pmc_stop(i);
+
+ set_pmc_event(i, ctr[i].event);
+
+ set_pmc_user_kernel(i, ctr[i].user, ctr[i].kernel);
+ }
+}
static void fsl_booke_reg_setup(struct op_counter_config *ctr,
struct op_system_config *sys,
@@ -77,23 +187,14 @@ static void fsl_booke_reg_setup(struct o
num_counters = num_ctrs;
- /* freeze all counters */
- pmc_stop_ctrs();
-
/* Our counters count up, and "count" refers to
* how much before the next interrupt, and we interrupt
* on overflow. So we calculate the starting value
* which will give us "count" until overflow.
* Then we set the events on the enabled counters */
- for (i = 0; i < num_counters; ++i) {
+ for (i = 0; i < num_counters; ++i)
reset_value[i] = 0x80000000UL - ctr[i].count;
- init_pmc_stop(i);
-
- set_pmc_event(i, ctr[i].event);
-
- set_pmc_user_kernel(i, ctr[i].user, ctr[i].kernel);
- }
}
static void fsl_booke_start(struct op_counter_config *ctr)
@@ -105,8 +206,8 @@ static void fsl_booke_start(struct op_co
for (i = 0; i < num_counters; ++i) {
if (ctr[i].enabled) {
ctr_write(i, reset_value[i]);
- /* Set Each enabled counterd to only
- * count when the Mark bit is not set */
+ /* Set each enabled counter to only
+ * count when the Mark bit is *not* set */
set_pmc_marked(i, 1, 0);
pmc_start_ctr(i, 1);
} else {
@@ -177,6 +278,7 @@ static void fsl_booke_handle_interrupt(s
struct op_powerpc_model op_model_fsl_booke = {
.reg_setup = fsl_booke_reg_setup,
+ .cpu_setup = fsl_booke_cpu_setup,
.start = fsl_booke_start,
.stop = fsl_booke_stop,
.handle_interrupt = fsl_booke_handle_interrupt,
diff --git a/arch/powerpc/oprofile/op_model_power4.c b/arch/powerpc/oprofile/op_model_power4.c
index 4c2beab..08cbf10 100644
--- a/arch/powerpc/oprofile/op_model_power4.c
+++ b/arch/powerpc/oprofile/op_model_power4.c
@@ -96,7 +96,7 @@ static inline int mmcra_must_set_sample(
return 0;
}
-static void power4_cpu_setup(void *unused)
+static void power4_cpu_setup(struct op_counter_config *ctr)
{
unsigned int mmcr0 = mmcr0_val;
unsigned long mmcra = mmcra_val;
diff --git a/arch/powerpc/oprofile/op_model_rs64.c b/arch/powerpc/oprofile/op_model_rs64.c
index 042f8f4..19c5ee0 100644
--- a/arch/powerpc/oprofile/op_model_rs64.c
+++ b/arch/powerpc/oprofile/op_model_rs64.c
@@ -102,7 +102,7 @@ static void rs64_reg_setup(struct op_cou
/* XXX setup user and kernel profiling */
}
-static void rs64_cpu_setup(void *unused)
+static void rs64_cpu_setup(struct op_counter_config *ctr)
{
unsigned int mmcr0;
diff --git a/include/asm-powerpc/oprofile_impl.h b/include/asm-powerpc/oprofile_impl.h
index 5b33994..07a10e5 100644
--- a/include/asm-powerpc/oprofile_impl.h
+++ b/include/asm-powerpc/oprofile_impl.h
@@ -42,7 +42,7 @@ struct op_powerpc_model {
void (*reg_setup) (struct op_counter_config *,
struct op_system_config *,
int num_counters);
- void (*cpu_setup) (void *);
+ void (*cpu_setup) (struct op_counter_config *);
void (*start) (struct op_counter_config *);
void (*stop) (void);
void (*handle_interrupt) (struct pt_regs *,
@@ -121,7 +121,90 @@ #endif
break;
}
}
-#endif /* !CONFIG_FSL_BOOKE */
+#else /* CONFIG_FSL_BOOKE */
+static inline u32 get_pmlca(int ctr)
+{
+ u32 pmlca;
+
+ switch (ctr) {
+ case 0:
+ pmlca = mfpmr(PMRN_PMLCA0);
+ break;
+ case 1:
+ pmlca = mfpmr(PMRN_PMLCA1);
+ break;
+ case 2:
+ pmlca = mfpmr(PMRN_PMLCA2);
+ break;
+ case 3:
+ pmlca = mfpmr(PMRN_PMLCA3);
+ break;
+ default:
+ panic("Bad ctr number\n");
+ }
+
+ return pmlca;
+}
+
+static inline void set_pmlca(int ctr, u32 pmlca)
+{
+ switch (ctr) {
+ case 0:
+ mtpmr(PMRN_PMLCA0, pmlca);
+ break;
+ case 1:
+ mtpmr(PMRN_PMLCA1, pmlca);
+ break;
+ case 2:
+ mtpmr(PMRN_PMLCA2, pmlca);
+ break;
+ case 3:
+ mtpmr(PMRN_PMLCA3, pmlca);
+ break;
+ default:
+ panic("Bad ctr number\n");
+ }
+}
+
+static inline unsigned int ctr_read(unsigned int i)
+{
+ switch(i) {
+ case 0:
+ return mfpmr(PMRN_PMC0);
+ case 1:
+ return mfpmr(PMRN_PMC1);
+ case 2:
+ return mfpmr(PMRN_PMC2);
+ case 3:
+ return mfpmr(PMRN_PMC3);
+ default:
+ return 0;
+ }
+}
+
+static inline void ctr_write(unsigned int i, unsigned int val)
+{
+ switch(i) {
+ case 0:
+ mtpmr(PMRN_PMC0, val);
+ break;
+ case 1:
+ mtpmr(PMRN_PMC1, val);
+ break;
+ case 2:
+ mtpmr(PMRN_PMC2, val);
+ break;
+ case 3:
+ mtpmr(PMRN_PMC3, val);
+ break;
+ default:
+ break;
+ }
+}
+
+
+#endif /* CONFIG_FSL_BOOKE */
+
extern void op_powerpc_backtrace(struct pt_regs * const regs, unsigned int depth);
diff --git a/include/asm-powerpc/pmc.h b/include/asm-powerpc/pmc.h
index 07d6a42..8588be6 100644
--- a/include/asm-powerpc/pmc.h
+++ b/include/asm-powerpc/pmc.h
@@ -32,18 +32,5 @@ #ifdef CONFIG_PPC64
void power4_enable_pmcs(void);
#endif
-#ifdef CONFIG_FSL_BOOKE
-void init_pmc_stop(int ctr);
-void set_pmc_event(int ctr, int event);
-void set_pmc_user_kernel(int ctr, int user, int kernel);
-void set_pmc_marked(int ctr, int mark0, int mark1);
-void pmc_start_ctr(int ctr, int enable);
-void pmc_start_ctrs(int enable);
-void pmc_stop_ctrs(void);
-void dump_pmcs(void);
-
-extern struct op_powerpc_model op_model_fsl_booke;
-#endif
-
#endif /* __KERNEL__ */
#endif /* _POWERPC_PMC_H */
--
1.3.0
^ permalink raw reply related
* RE: question about linux with Xilinx ML-403
From: Ming Liu @ 2006-05-24 22:32 UTC (permalink / raw)
To: rick.moleres; +Cc: linuxppc-embedded
In-Reply-To: <689CB232690D8D4E97DA6C76DA098E6C025946F6@XCO-EXCHVS1.xlnx.xilinx.com>
Dear Rick,
Yes. I have downloaded the linuxppc-2.4 kernel. There is really the temac
support. Thanks a lot for your information.
Also. MontaVista will release the pro 4.0 based on 2.6 in the end of this
month. I think in this version, Temac will be included. Temac will be more
popularly supported in the following versions, I think.
Regards
Ming
>From: "Rick Moleres" <rick.moleres@xilinx.com>
>To: "Ming Liu" <eemingliu@hotmail.com>, "rick.moleres"
<rick.moleres@xilinx.com>
>CC: <linuxppc-embedded@ozlabs.org>
>Subject: RE: question about linux with Xilinx ML-403
>Date: Wed, 24 May 2006 12:52:02 -0600
>
>
>Ming,
>
>Another option for you may be to get MontaVista's latest linuxppc-2.4
kernel tree from source.mvista.com (using rsync), which I believe has the
xilinx_gige directory and menuconfig entries.
>
>-Rick
>
>-----Original Message-----
>From: Ming Liu [mailto:eemingliu@hotmail.com]
>Sent: Wednesday, May 24, 2006 12:36 PM
>To: rick.moleres
>Cc: linuxppc-embedded@ozlabs.org
>Subject: RE: question about linux with Xilinx ML-403
>
>Dear Rick,
>OK. I will try that. However I cannot promise to finish this very soon
>because I am a novice. :) I will let you know if there is any result.
>
>Thanks for your method.
>
>BR
>Ming
>
>
> >From: "Rick Moleres" <rick.moleres@xilinx.com>
> >To: "Ming Liu" <eemingliu@hotmail.com>, "rick.moleres"
><rick.moleres@xilinx.com>
> >CC: <linuxppc-embedded@ozlabs.org>
> >Subject: RE: question about linux with Xilinx ML-403
> >Date: Wed, 24 May 2006 10:25:10 -0600
> >
> >
> >
> >Ming,
> >
> >
> >
> >
> >
> > >Our best recommendation is to use the drivers/net/xilinx_enet
directory
> >
> > >for the temac driver and just enable the Xilinx 10/100 Ethernet in
> >
> > >menuconfig.
> >
> >
> >
> >I am not so clear with this. Do you mean that I just copy the source
> >code
> >
> >in the directory of xilinx_gige generated by EDK into the directory of
> >
> >xilinx_enet in linux2.4.20, and then enable the Xilinx 10/100 ethernet
> >in
> >
> >the menuconfig? Can this method realize the 1000M ethernet? The source
> >code
> >
> >file names for Temac (xtemac_xxx.c or .h) are different with the ones
> >for
> >
> >emac (xemac_xxx.c or .h). Can the xtemac files be recognized by the
> >linux
> >
> >kernel?
> >
> >
> >
> >Right - you would need to copy the xtemac* files and the Makefile over,
> >and would have to change the Makefile to make sure it produces
> >xilinx_enet.o instead of xilinx_gige.o. We haven't tried this, but we
> >don't think there's any reason this shouldn't work. Can you let us know
> >how it goes?
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>_________________________________________________________________
>免费下载 MSN Explorer: http://explorer.msn.com/lccn/
>
>
>
_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
^ permalink raw reply
* Re: pmppc7448/mv64x60 DMA from PCI to memory
From: Mark A. Greer @ 2006-05-24 20:52 UTC (permalink / raw)
To: Phil Nitschke; +Cc: linuxppc-embedded
In-Reply-To: <1148437434.4876.64.camel@lamorak.int.avalon.com.au>
On Wed, May 24, 2006 at 11:53:54AM +0930, Phil Nitschke wrote:
> On Tue, 2006-05-23 at 16:54 -0700, Mark A. Greer wrote:
>
> > You say that you don't see any PCI traffic. Does that mean you
> > have a PCI analyzer and that you are sure that its set up correctly?
>
> I don't have a PCI analyzer, however the JTAG used to program the PCI
> device has been configured to display 4 K samples of PCI bus signals
> (about 20 microsecs?) around the time of an interrupt which results in
> the DMA being requested. Since my last post, I have managed to see some
> traffic, but the PCI STOP# line is asserted, so I'm not seeing any data
> being read. I'll investigate further...
OK
> > If so, then you have something botched in your IDMA->PCI window setup
>
> Quite possibly. The patch below shows how I've set this window up. It
> is not intended as a 'final' piece of code, so please forgive the magic
> numbers. Could you review this for me?
Sure.
> > or in the pgming of the DMA itself (e.g., in your descriptor(s)).
>
> Well the memory to memory DMA is working OK. I just didn't know what
> the correct procedure was for determining the bus address of the FIFO.
> For example, this mapping returns a dma handle which does not work:
>
> fifo_dma_handle = pci_map_single(dev, my_card.bar1+fifo_address[0],
> FIFO_SIZE, PCI_DMA_FROMDEVICE);
>
> Whereas without DMA I would just use this:
> ioread32_rep(my_card.bar1 + fifo_address[0], buf, 6);
>
> Was I misguided in trying to use pci_map_single in this way?
Yes. Use pci_map_single() to map an already allocated, physically
contiguous memory buffer not pci memory. Try pci_iomap() instead.
You should read Documentation/DMA-API.txt & DMA-mapping.txt thoroughly
then look at the many pci drivers that already exist as examples.
> > Also, set the SrcHold bit [3] of the channel control reg (low).
> > If its really a FIFO, you are--or will be once you get your windows
> > and descriptors set up correctly--reading the FIFO once then
> > incrementing past it.
>
> I can either address it as a FIFO, or as a memory range. I can read
> from any address in the range and it returns the "next FIFO value".
> Anyway, I've tried both src address hold settings...
OK
> > > For this scenario, can anyone tell me:
> > > * Should I be using the same src address as that reported via
> > > the 'lspci' command - this _is_ the PCI bus address, isn't it?
> >
> > "man lspci" (read up on the '-b' option)
>
> I cannot see any difference with the '-b' flag. Maybe that is the way
> of things on my architecture?
That probably means that your pci io & mem space are mapped at the same
addrs in pci io & mem space and phys cpu space. If that's not the case,
something may be wrong.
> > > * Looking through mv64x60.c in the 2.6.16 kernel, I note that 4
> > > of the 8 possible IDMA address windows are configured (for each
> > > of the 512 MB DRAM on our processor card).
> >
> > No they aren't. They're configured (or not) according to the setup info
> > that you pass in.
>
> OK. I also note there are several cases where this is used in
> mv64x60.c:
>
> for (i=0; i<3; i++)
>
> Why is 3 used in these loops, and not some other constant like
> MV64360_xxxxx_WINDOWS (which are usually 4, not 3)?
Different things. The "i<3;" are when looping through windows that are
related to a struct pci_controller's mem_resource. From the definition
of pci_controller:
struct resource mem_resources[3];
> > > Do I need to add
> > > tests to my source and destination regions, to determine if they
> > > cross one of the 512 MB regions, and hence will require a
> > > different CSx line (and thus the DMA will need to be broken into
> > > two transactions), or does kernel already take care to ensure
> > > allocated regions will not cross these boundaries?
> >
> > No. You need to do what's appropriate for the hardware that you are
> > essentially writing a driver for. YOU are supposed to know what the
> > limitations of your hardware are.
>
> OK, I know how my hardware is configured, but when trying to write a
> generic driver, perhaps I need to have the mv64x60.c code remember the
> CSx barriers, e.g. in the mv64x60_chip_info, so the IDMA engine can
> access it. Do you think this would be possible/beneficial?
No. Just set up and enable an IDMA window to access all of pci mem space
and be done with it.
> Thanks again,
>
> --
> Phil
>
> Here is the patch to configure IDMA to PCI window(s):
>
> --- linux-2.6.16/arch/ppc/syslib/mv64x60.c 2006-03-20
> 16:23:29.000000000 +1030
> +++ linux-2.6.16-patched/arch/ppc/syslib/mv64x60.c 2006-05-23
> 16:33:52.000000000 +0930
> @@ -535,6 +581,7 @@
> mv64x60_config_pci_params(bh->hose_a, &si->pci_0);
>
> mv64x60_config_cpu2pci_windows(bh, &si->pci_0, 0);
> + mv64x60_config_idma2pci_windows(bh, &si->pci_0, 0);
> mv64x60_config_pci2mem_windows(bh, bh->hose_a,
> &si->pci_0, 0,
> mem_windows);
> bh->ci->set_pci2regs_window(bh, bh->hose_a, 0,
> @@ -548,6 +595,7 @@
> mv64x60_config_pci_params(bh->hose_b, &si->pci_1);
>
> mv64x60_config_cpu2pci_windows(bh, &si->pci_1, 1);
> + mv64x60_config_idma2pci_windows(bh, &si->pci_1, 1);
> mv64x60_config_pci2mem_windows(bh, bh->hose_b,
> &si->pci_1, 1,
> mem_windows);
> bh->ci->set_pci2regs_window(bh, bh->hose_b, 1,
> @@ -1136,6 +1188,42 @@
> bh->ci->disable_window_32bit(bh, win_tab[bus][i
> +1]);
> }
>
> +static u32 idma_tab_xtra[MV64x60_CPU2MEM_WINDOWS] __initdata = {
> + MV64x60_IDMA2MEM_0_WIN, MV64x60_IDMA2MEM_1_WIN,
> + MV64x60_IDMA2MEM_2_WIN, MV64x60_IDMA2MEM_3_WIN,
> +};
> +
> +void __init
> +mv64x60_config_idma2pci_windows(struct mv64x60_handle *bh,
> + struct mv64x60_pci_info *pi, u32 bus)
> +{
> + u32 attributes, unit_id;
> + int i;
> +
> + /* Target Unit IDs: PCI0 = 3, PCI1 = 4. */
> + unit_id = bus ? 0x4 : 0x3;
> + /* 0x1d == No swap data, PCI-X NS attribute asserted, PCI memory
> + * space, PCIx_REQ64n asserted according to requested data size.
> */
> + attributes = (0x1d << 8) | unit_id;
> +
> + for (i=0; i<3; i++)
> + if (pi->pci_mem[i].size > 0) {
> + mv64x60_set_32bit_window(bh, idma_tab_xtra[i],
> + pi->pci_mem[i].cpu_base,
> pi->pci_mem[i].size,
> + attributes);
> + bh->ci->enable_window_32bit(bh,
> idma_tab_xtra[i]);
> + /* Give idma r/w access to PCI memory region */
> + mv64x60_set_bits(bh,
> MV64360_IDMA2MEM_ACC_PROT_0,
> + (0x3 << (i << 1)));
> + mv64x60_set_bits(bh,
> MV64360_IDMA2MEM_ACC_PROT_1,
> + (0x3 << (i << 1)));
> + mv64x60_set_bits(bh,
> MV64360_IDMA2MEM_ACC_PROT_2,
> + (0x3 << (i << 1)));
> + mv64x60_set_bits(bh,
> MV64360_IDMA2MEM_ACC_PROT_3,
> + (0x3 << (i << 1)));
> + }
> +}
> +
> /*
>
> *****************************************************************************
> *
> @@ -2220,8 +2311,8 @@
> };
>
> static u32 idma_tab[MV64x60_CPU2MEM_WINDOWS] __initdata = {
> - MV64x60_IDMA2MEM_0_WIN, MV64x60_IDMA2MEM_1_WIN,
> - MV64x60_IDMA2MEM_2_WIN, MV64x60_IDMA2MEM_3_WIN,
> + MV64x60_IDMA2MEM_4_WIN, MV64x60_IDMA2MEM_5_WIN,
> + MV64x60_IDMA2MEM_6_WIN, MV64x60_IDMA2MEM_7_WIN,
> };
>
> static u32 dram_selects[MV64x60_CPU2MEM_WINDOWS] __initdata =
> @@ -2285,13 +2376,13 @@
>
> /* Give idma r/w access to memory region */
> mv64x60_set_bits(bh,
> MV64360_IDMA2MEM_ACC_PROT_0,
> - (0x3 << (i << 1)));
> + (0x3 << ((i+4) << 1)));
> mv64x60_set_bits(bh,
> MV64360_IDMA2MEM_ACC_PROT_1,
> - (0x3 << (i << 1)));
> + (0x3 << ((i+4) << 1)));
> mv64x60_set_bits(bh,
> MV64360_IDMA2MEM_ACC_PROT_2,
> - (0x3 << (i << 1)));
> + (0x3 << ((i+4) << 1)));
> mv64x60_set_bits(bh,
> MV64360_IDMA2MEM_ACC_PROT_3,
> - (0x3 << (i << 1)));
> + (0x3 << ((i+4) << 1)));
> }
> }
I didn't go through this in great detail but it looks like you have
the right idea (IMHO). Although, I don't know why you didn't just
use windows 4-7 for the idma->pci mappings and leave the idma->mem code
alone.
Mark
^ permalink raw reply
* Re: VME driver problem on MVME6100
From: Xavier Grave @ 2006-05-24 19:44 UTC (permalink / raw)
To: Konstantin Boyanov; +Cc: linuxppc-embedded
In-Reply-To: <929bf310605241005q1987845di@mail.gmail.com>
Hi,
Perhaps the size of the window you want is too big ?
I have only experience with MVME5100 and 5500 so I can only guess that.
xavier
Le mercredi 24 mai 2006 à 19:05 +0200, Konstantin Boyanov a écrit :
> Hi there,
>
> These days I'm trying to "bring up" a VME driver on a Motorola SBC but
> I'm getting in some troubles.
> Actually there are no problems with the driver itself, methinks, it
> loads correctly and everithing seems to be fine.
> But when I try to create an outbound window, in order to "talk" some
> other boards in the crate I get this:
>
> __ioremap(): phys addr 01000000 is RAM lr d100be34
> mode 0
> vmedrv: No memory for outbound window
> testout: VME_IOCTL_SET_OUTBOUND failed. Errno = 12
>
> I'm not sure I understand all of this anyways... Except that there is
> no sufficient memory to map for the outbound window.
> That's what this test is supposed to do is to open the appropriate
> devices for the VME bus (in this case /dev/vme_m[0-7]), configure the
> outbound windows from 0 through 6 (the 7th is reserved) and then
> verifies that data can be read through these outbound windows.
> I'm using an VME driver downloaded from vmelinux.org and here is the
> source of the test program I'm trying to run ->
> http://www-zeuthen.desy.de/~boyanov/testOutWindow.txt
>
> I'm sorry for the newb question, but any ideas what is going wrong?
> Thank you.
>
> Kind regards,
> Konstantin Boyanov
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Can't get CoralP drivers to work
From: Wolfgang Denk @ 2006-05-24 19:57 UTC (permalink / raw)
To: jourdan; +Cc: linuxppc-embedded
In-Reply-To: <3799.194.3.133.184.1148489640.squirrel@webmail.enib.fr>
In message <3799.194.3.133.184.1148489640.squirrel@webmail.enib.fr> you wrote:
>
> I have a MPC8260 processor card with a Coral-P evaluation board (rev 4.0).
> My system do not have keyboard nor mouse (i use the serial console).
>
> I use linux kernel 2.4.25 & 2.6.9.
We have instructions on our web site; did you read these?
> I'm trying to get the framebuffer driver to work. During the boot the
> driver loads fine but the monitor remains blank (no video signal). If i
> try to `cat /dev/urandom > /dev/fb/0` nothing happens.
Are you using devfs? Don't! Use /dev/fb0
> I compiled an Xserver (Release 6.9), and the x11 drivers for the coralp.
> When I start X, it says that it can not open tty0 (indeed it doesn't
> exists).
Well, you got an error message (tty0 cannot be opened), you verified
that it is valid (tty0 does not exist), so fix the problem...
> For kernel 2.6.9 :
Can't comment on Coreal-P on 2.6.x
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
War is never imperative.
-- McCoy, "Balance of Terror", stardate 1709.2
^ permalink raw reply
* Re: Question about IRQs on MPC8540
From: Kumar Gala @ 2006-05-24 19:40 UTC (permalink / raw)
To: Travis B. Sawyer; +Cc: linuxppc-embedded
In-Reply-To: <4474B4F7.9000204@broadcom.com>
On May 24, 2006, at 2:33 PM, Travis B. Sawyer wrote:
> I sent this to Kumar, should have sent directly to the list...
I guess I'll reply to both :)
> I'm porting our kernel base from 2.4->2.6 for our boards and an ODM
> board.
> The ODM board is board that is based off of the 8540 ADS.
>
> I'm having a bit of a problem understanding what went on btw 2.6.12
> and
> 2.6.16.16 wrt
> the 85xx interrupts.
>
> For example, in 2.6.12 I had external interrupts as follows:
> {0, MPC85xx_IRQ_EXT2, MPC85xx_IRQ_EXT3, 0}, /* The bridge */
> {MPC85xx_IRQ_EXT2, MPC85xx_IRQ_EXT3, 0, 0}, /*
> Cardbus */
> {MPC85xx_IRQ_EXT6, 0, 0, 0}, /* IDSEL 18
> -- QE */
> {MPC85xx_IRQ_EXT5, 0, 0, 0}, /* neo2 FE */
> {MPC85xx_IRQ_EXT9, 0, 0, 0}, /* neo3 FE
> egress */
> {MPC85xx_IRQ_EXT10, 0, 0, 0}, /* neo3 FE
> ingress IDSEL 21 */
> Where ext2 was 98, ext3 was 99, etc.
>
> With the newer 2.6.16.16 kernel, I see
> ext2 is 50, ext3 51, etc.
>
> mpc85xx_map_irq: res: 0 for idsel 16 pin 1 0:16.0
> mpc85xx_map_irq: res: 0 for idsel 16 pin 1 0:16.1
> mpc85xx_map_irq: res: 54 for idsel 18 pin 1 0:18.0
> mpc85xx_map_irq: res: 53 for idsel 19 pin 1 0:19.0
> mpc85xx_map_irq: res: 50 for idsel 16 pin 2 1:1.0
> mpc85xx_map_irq: res: 51 for idsel 16 pin 3 1:1.1
This is because we most likely removed the offset that was added to
the IRQs. This is done via MPC85xx_OPENPIC_IRQ_OFFSET, its really
intended to reserve a range for CPM and/or i8259 interrupts. On a
normal 8540 board setting it to 0 is fine.
> The problem is that when the PCI device drivers request the irq, it
> fails.
> Sandburst Thin Driver 1.1.0 May 24 2006 loaded
> Support available from http://www.sandburst.com
> sbthin: sb/ife0 (241/0) at 0xea3e0000, device 19
> sbthin_init_one:sb/ife0 request irq failed with -38
what is the IRQ its trying to request?
> and
>
> Yenta: Using CSCINT to route CSC interrupts to PCI
> Yenta: Routing CardBus interrupts to PCI
> Yenta TI: socket 0000:01:01.0, mfunc 0x00001000, devctl 0x66
> Yenta: request_irq() in yenta_probe_cb_irq() failed!
> Yenta TI: socket 0000:01:01.0 no PCI interrupts. Fish. Please report.
> Yenta: no PCI IRQ, CardBus support disabled for this socket.
>
>
> Can you give me some pointers where to look? I've been scouring the
> changes and can't
> really put my finger on it.
What does your map_irq function look like?
- k
^ permalink raw reply
* Question about IRQs on MPC8540
From: Travis B. Sawyer @ 2006-05-24 19:33 UTC (permalink / raw)
To: linuxppc-embedded
I sent this to Kumar, should have sent directly to the list...
I'm porting our kernel base from 2.4->2.6 for our boards and an ODM board.
The ODM board is board that is based off of the 8540 ADS.
I'm having a bit of a problem understanding what went on btw 2.6.12 and
2.6.16.16 wrt
the 85xx interrupts.
For example, in 2.6.12 I had external interrupts as follows:
{0, MPC85xx_IRQ_EXT2, MPC85xx_IRQ_EXT3, 0}, /* The bridge */
{MPC85xx_IRQ_EXT2, MPC85xx_IRQ_EXT3, 0, 0}, /* Cardbus */
{MPC85xx_IRQ_EXT6, 0, 0, 0}, /* IDSEL 18 -- QE */
{MPC85xx_IRQ_EXT5, 0, 0, 0}, /* neo2 FE */
{MPC85xx_IRQ_EXT9, 0, 0, 0}, /* neo3 FE egress */
{MPC85xx_IRQ_EXT10, 0, 0, 0}, /* neo3 FE
ingress IDSEL 21 */
Where ext2 was 98, ext3 was 99, etc.
With the newer 2.6.16.16 kernel, I see
ext2 is 50, ext3 51, etc.
mpc85xx_map_irq: res: 0 for idsel 16 pin 1 0:16.0
mpc85xx_map_irq: res: 0 for idsel 16 pin 1 0:16.1
mpc85xx_map_irq: res: 54 for idsel 18 pin 1 0:18.0
mpc85xx_map_irq: res: 53 for idsel 19 pin 1 0:19.0
mpc85xx_map_irq: res: 50 for idsel 16 pin 2 1:1.0
mpc85xx_map_irq: res: 51 for idsel 16 pin 3 1:1.1
The problem is that when the PCI device drivers request the irq, it fails.
Sandburst Thin Driver 1.1.0 May 24 2006 loaded
Support available from http://www.sandburst.com
sbthin: sb/ife0 (241/0) at 0xea3e0000, device 19
sbthin_init_one:sb/ife0 request irq failed with -38
and
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket 0000:01:01.0, mfunc 0x00001000, devctl 0x66
Yenta: request_irq() in yenta_probe_cb_irq() failed!
Yenta TI: socket 0000:01:01.0 no PCI interrupts. Fish. Please report.
Yenta: no PCI IRQ, CardBus support disabled for this socket.
Can you give me some pointers where to look? I've been scouring the
changes and can't
really put my finger on it.
thanx in advance,
travis
^ permalink raw reply
* RE: question about linux with Xilinx ML-403
From: Rick Moleres @ 2006-05-24 18:52 UTC (permalink / raw)
To: Ming Liu, rick.moleres; +Cc: linuxppc-embedded
Ming,
Another option for you may be to get MontaVista's latest linuxppc-2.4 =
kernel tree from source.mvista.com (using rsync), which I believe has =
the xilinx_gige directory and menuconfig entries.
-Rick
-----Original Message-----
From: Ming Liu [mailto:eemingliu@hotmail.com]=20
Sent: Wednesday, May 24, 2006 12:36 PM
To: rick.moleres
Cc: linuxppc-embedded@ozlabs.org
Subject: RE: question about linux with Xilinx ML-403
Dear Rick,
OK. I will try that. However I cannot promise to finish this very soon=20
because I am a novice. :) I will let you know if there is any result.
Thanks for your method.
BR
Ming
>From: "Rick Moleres" <rick.moleres@xilinx.com>
>To: "Ming Liu" <eemingliu@hotmail.com>, "rick.moleres"=20
<rick.moleres@xilinx.com>
>CC: <linuxppc-embedded@ozlabs.org>
>Subject: RE: question about linux with Xilinx ML-403
>Date: Wed, 24 May 2006 10:25:10 -0600
>
>
>
>Ming,
>
>
>
>
>
> >Our best recommendation is to use the drivers/net/xilinx_enet =
directory
>
> >for the temac driver and just enable the Xilinx 10/100 Ethernet in
>
> >menuconfig.
>
>
>
>I am not so clear with this. Do you mean that I just copy the source
>code
>
>in the directory of xilinx_gige generated by EDK into the directory of
>
>xilinx_enet in linux2.4.20, and then enable the Xilinx 10/100 ethernet
>in
>
>the menuconfig? Can this method realize the 1000M ethernet? The source
>code
>
>file names for Temac (xtemac_xxx.c or .h) are different with the ones
>for
>
>emac (xemac_xxx.c or .h). Can the xtemac files be recognized by the
>linux
>
>kernel?
>
>
>
>Right - you would need to copy the xtemac* files and the Makefile over,
>and would have to change the Makefile to make sure it produces
>xilinx_enet.o instead of xilinx_gige.o. We haven't tried this, but we
>don't think there's any reason this shouldn't work. Can you let us =
know
>how it goes?
>
>
>
>
>
>
>
>
>
_________________________________________________________________
=C3=E2=B7=D1=CF=C2=D4=D8 MSN Explorer: http://explorer.msn.com/lccn/ =20
^ permalink raw reply
* RE: question about linux with Xilinx ML-403
From: Ming Liu @ 2006-05-24 18:36 UTC (permalink / raw)
To: rick.moleres; +Cc: linuxppc-embedded
In-Reply-To: <689CB232690D8D4E97DA6C76DA098E6C02594618@XCO-EXCHVS1.xlnx.xilinx.com>
Dear Rick,
OK. I will try that. However I cannot promise to finish this very soon
because I am a novice. :) I will let you know if there is any result.
Thanks for your method.
BR
Ming
>From: "Rick Moleres" <rick.moleres@xilinx.com>
>To: "Ming Liu" <eemingliu@hotmail.com>, "rick.moleres"
<rick.moleres@xilinx.com>
>CC: <linuxppc-embedded@ozlabs.org>
>Subject: RE: question about linux with Xilinx ML-403
>Date: Wed, 24 May 2006 10:25:10 -0600
>
>
>
>Ming,
>
>
>
>
>
> >Our best recommendation is to use the drivers/net/xilinx_enet directory
>
> >for the temac driver and just enable the Xilinx 10/100 Ethernet in
>
> >menuconfig.
>
>
>
>I am not so clear with this. Do you mean that I just copy the source
>code
>
>in the directory of xilinx_gige generated by EDK into the directory of
>
>xilinx_enet in linux2.4.20, and then enable the Xilinx 10/100 ethernet
>in
>
>the menuconfig? Can this method realize the 1000M ethernet? The source
>code
>
>file names for Temac (xtemac_xxx.c or .h) are different with the ones
>for
>
>emac (xemac_xxx.c or .h). Can the xtemac files be recognized by the
>linux
>
>kernel?
>
>
>
>Right - you would need to copy the xtemac* files and the Makefile over,
>and would have to change the Makefile to make sure it produces
>xilinx_enet.o instead of xilinx_gige.o. We haven't tried this, but we
>don't think there's any reason this shouldn't work. Can you let us know
>how it goes?
>
>
>
>
>
>
>
>
>
_________________________________________________________________
免费下载 MSN Explorer: http://explorer.msn.com/lccn/
^ permalink raw reply
* Re: Can't get CoralP drivers to work
From: Dan Malek @ 2006-05-24 18:31 UTC (permalink / raw)
To: jourdan; +Cc: linuxppc-embedded
In-Reply-To: <3799.194.3.133.184.1148489640.squirrel@webmail.enib.fr>
On May 24, 2006, at 12:54 PM, jourdan@enib.fr wrote:
> I have a MPC8260 processor card with a Coral-P evaluation board
> (rev 4.0).
Are you sure?
The 8260 does not have a PCI bus and the Coral-P
is a PCI card :-)
Good Luck.
-- Dan
^ permalink raw reply
* Re: Help Needed: floating point used in kernel (task=c0398410, pc=3184)
From: Carlos Munoz @ 2006-05-24 18:03 UTC (permalink / raw)
To: Roger Larsson; +Cc: linuxppc-embedded
In-Reply-To: <200605240850.24333.roger.larsson@norran.net>
Roger Larsson wrote:
>On onsdag 24 maj 2006 08.12, sandeep malik wrote:
>
>
>>Hi All...
>>
>> I am trying to run an application compiled with gcc toolchain gcc--3.4.3
>>and glibc -2.3.4 on PPC 8325 board running Linux 2.6.11....but some how I
>>am getting following error....
>>
>> floating point used in kernel (task=c0398410, pc=3184)
>> floating point used in kernel (task=c0398410, pc=3184)
>> floating point used in kernel (task=c0398410, pc=3184)
>> floating point used in kernel (task=c0398410, pc=3184)
>> floating point used in kernel (task=c0398410, pc=3184)
>> floating point used in kernel (task=c0398410, pc=3184)
>>
>> I was suspecting this error might be because the hardware is not
>>supporting floating point operations and hence i tried a simple program in
>>which I intentionally did some floating point operation but that program
>>was running as expected.
>>
>>
>No, the warning is more serious than that.
>
>Linux does not save floating point registers when entering kernel.
>It might even optimize not to store/reload when doing a context switch.
>
>If your kernel module is using floating point in your kernel code.
>It will probably work on a processor not having floating point but will
>break in mysterious ways on one supporting hardware floating point.
>
>Do not use floating point in kernel. If you still have to you must take
>extremely care.
> Turn off kernel preemption.
> Save FP registers.
> Do your stuff.
> Reload FP registers.
> Turn on preemption.
>But the question is why would you have to?
>Simple calculations can be done in fixed point, and complex calculations
>does not belong in the kernel.
>
>/RogerL
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
Hi Sandeep,
I had the same problem as you. The processor I was using didn't have fp
support, so what I did was link the kernel with the gcc library and I
got it to work. However, as Roger said it would break on processors with
fp support. In the long run I looked at the floating point calculations
(log2 in my case) and was able to do the same math with fixed point.
Can you post the floating point calculations you need to do ? Someone
here might be able to do the same using fix point.
Thanks,
Carlos
^ permalink raw reply
* [PATCH] ppc32 CPM_UART: various fixes for pq2 uart users
From: Vitaly Bordug @ 2006-05-24 17:40 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-embedded
This fixes various odd things that missed update together with cpm_uart
platform_device move. Unified resources names, restructurisation, etc.
Also, addressed issue with recent phys/virt translation rework. Being
cache-coherent, CPM2's do alloc_bootmem() for the console stuff, and it was
used to treat console buffer descriptor mapping 1:1 (as in CPM1 case),
which is definitely wrong.
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
---
arch/ppc/platforms/mpc8272ads_setup.c | 10 +++++-----
arch/ppc/syslib/pq2_devices.c | 16 ++++++++--------
arch/ppc/syslib/pq2_sys.c | 8 ++++----
drivers/serial/cpm_uart/cpm_uart_core.c | 8 +++++---
drivers/serial/cpm_uart/cpm_uart_cpm2.c | 2 +-
5 files changed, 23 insertions(+), 21 deletions(-)
diff --git a/arch/ppc/platforms/mpc8272ads_setup.c b/arch/ppc/platforms/mpc8272ads_setup.c
index e62b757..abb7154 100644
--- a/arch/ppc/platforms/mpc8272ads_setup.c
+++ b/arch/ppc/platforms/mpc8272ads_setup.c
@@ -279,11 +279,11 @@ static int mpc8272ads_platform_notify(st
static const struct platform_notify_dev_map dev_map[] = {
{
.bus_id = "fsl-cpm-fcc",
- .rtn = mpc8272ads_fixup_enet_pdata
+ .rtn = mpc8272ads_fixup_enet_pdata,
},
{
.bus_id = "fsl-cpm-scc:uart",
- .rtn = mpc
+ .rtn = mpc8272ads_fixup_uart_pdata,
},
{
.bus_id = NULL
@@ -335,15 +335,15 @@ struct platform_device* early_uart_get_p
struct platform_device* pdev = NULL;
if(index) { /*assume SCC4 here*/
pdev = &ppc_sys_platform_devices[MPC82xx_CPM_SCC4];
- pinfo = &mpc8272<F12>_uart_pdata[1];
+ pinfo = &mpc8272_uart_pdata[fsid_scc4_uart];
} else { /*over SCC1*/
pdev = &ppc_sys_platform_devices[MPC82xx_CPM_SCC1];
- pinfo = &mpc8272_uart_pdata[0];
+ pinfo = &mpc8272_uart_pdata[fsid_scc1_uart];
}
pinfo->uart_clk = bd->bi_intfreq;
pdev->dev.platform_data = pinfo;
- ppc_sys_fixup_mem_resource(pdev, IMAP_ADDR);
+ ppc_sys_fixup_mem_resource(pdev, CPM_MAP_ADDR);
return NULL;
}
diff --git a/arch/ppc/syslib/pq2_devices.c b/arch/ppc/syslib/pq2_devices.c
index 0636aed..8692d00 100644
--- a/arch/ppc/syslib/pq2_devices.c
+++ b/arch/ppc/syslib/pq2_devices.c
@@ -121,13 +121,13 @@ struct platform_device ppc_sys_platform_
.num_resources = 3,
.resource = (struct resource[]) {
{
- .name = "scc_mem",
+ .name = "regs",
.start = 0x11A00,
.end = 0x11A1F,
.flags = IORESOURCE_MEM,
},
{
- .name = "scc_pram",
+ .name = "pram",
.start = 0x8000,
.end = 0x80ff,
.flags = IORESOURCE_MEM,
@@ -145,13 +145,13 @@ struct platform_device ppc_sys_platform_
.num_resources = 3,
.resource = (struct resource[]) {
{
- .name = "scc_mem",
+ .name = "regs",
.start = 0x11A20,
.end = 0x11A3F,
.flags = IORESOURCE_MEM,
},
{
- .name = "scc_pram",
+ .name = "pram",
.start = 0x8100,
.end = 0x81ff,
.flags = IORESOURCE_MEM,
@@ -169,13 +169,13 @@ struct platform_device ppc_sys_platform_
.num_resources = 3,
.resource = (struct resource[]) {
{
- .name = "scc_mem",
+ .name = "regs",
.start = 0x11A40,
.end = 0x11A5F,
.flags = IORESOURCE_MEM,
},
{
- .name = "scc_pram",
+ .name = "pram",
.start = 0x8200,
.end = 0x82ff,
.flags = IORESOURCE_MEM,
@@ -193,13 +193,13 @@ struct platform_device ppc_sys_platform_
.num_resources = 3,
.resource = (struct resource[]) {
{
- .name = "scc_mem",
+ .name = "regs",
.start = 0x11A60,
.end = 0x11A7F,
.flags = IORESOURCE_MEM,
},
{
- .name = "scc_pram",
+ .name = "pram",
.start = 0x8300,
.end = 0x83ff,
.flags = IORESOURCE_MEM,
diff --git a/arch/ppc/syslib/pq2_sys.c b/arch/ppc/syslib/pq2_sys.c
index 433b0fa..fee8948 100644
--- a/arch/ppc/syslib/pq2_sys.c
+++ b/arch/ppc/syslib/pq2_sys.c
@@ -139,13 +139,13 @@ struct ppc_sys_spec ppc_sys_specs[] = {
.ppc_sys_name = "8272",
.mask = 0x0000ff00,
.value = 0x00000c00,
- .num_devices = 11,
+ .num_devices = 12,
.device_list = (enum ppc_sys_devices[])
{
MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_SCC1,
- MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3, MPC82xx_CPM_SMC1,
- MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
- MPC82xx_CPM_USB, MPC82xx_SEC1,
+ MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3, MPC82xx_CPM_SCC4,
+ MPC82xx_CPM_SMC1, MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI,
+ MPC82xx_CPM_I2C, MPC82xx_CPM_USB, MPC82xx_SEC1,
},
},
/* below is a list of the 8280 family of processors */
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c b/drivers/serial/cpm_uart/cpm_uart_core.c
index 969f949..5cba59a 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -1164,14 +1164,16 @@ static int __init cpm_uart_console_setup
struct fs_uart_platform_info *pdata;
struct platform_device* pdev = early_uart_get_pdev(co->index);
- port =
- (struct uart_port *)&cpm_uart_ports[cpm_uart_port_map[co->index]];
- pinfo = (struct uart_cpm_port *)port;
if (!pdev) {
pr_info("cpm_uart: console: compat mode\n");
/* compatibility - will be cleaned up */
cpm_uart_init_portdesc();
+ }
+ port =
+ (struct uart_port *)&cpm_uart_ports[cpm_uart_port_map[co->index]];
+ pinfo = (struct uart_cpm_port *)port;
+ if (!pdev) {
if (pinfo->set_lineif)
pinfo->set_lineif(pinfo);
} else {
diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm2.c b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
index 4b2de08..cdba128 100644
--- a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
+++ b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
@@ -213,7 +213,7 @@ int cpm_uart_allocbuf(struct uart_cpm_po
L1_CACHE_ALIGN(pinfo->tx_nrfifos * pinfo->tx_fifosize);
if (is_con) {
mem_addr = alloc_bootmem(memsz);
- dma_addr = mem_addr;
+ dma_addr = virt_to_bus(mem_addr);
}
else
mem_addr = dma_alloc_coherent(NULL, memsz, &dma_addr,
^ permalink raw reply related
* Can't get CoralP drivers to work
From: jourdan @ 2006-05-24 16:54 UTC (permalink / raw)
To: linuxppc-embedded
Hello
I have a MPC8260 processor card with a Coral-P evaluation board (rev 4.0).
My system do not have keyboard nor mouse (i use the serial console).
I use linux kernel 2.4.25 & 2.6.9.
For kernel 2.4.25 :
I'm trying to get the framebuffer driver to work. During the boot the
driver loads fine but the monitor remains blank (no video signal). If i
try to `cat /dev/urandom > /dev/fb/0` nothing happens.
I compiled an Xserver (Release 6.9), and the x11 drivers for the coralp.
When I start X, it says that it can not open tty0 (indeed it doesn't
exists).
For kernel 2.6.9 :
When I start X, it complains about virtual terminals but doesn't stop. It
loads the x11_mb86290 driver then stop because it can't find a valid
framebuffer driver. Is it mandatory to have the mb86290fb driver worknig
in order to get the x11_mb86290 driver ?
I guess it just a configuration problem but I can figure it out. I added
the support for virtual terminals in my kernel (X seems to need it) but I
don't have ttyN entries in /dev. If I add them manually, they can not be
opened.
Thanks for your help.
^ permalink raw reply
* VME driver problem on MVME6100
From: Konstantin Boyanov @ 2006-05-24 17:05 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]
Hi there,
These days I'm trying to "bring up" a VME driver on a Motorola SBC but I'm
getting in some troubles.
Actually there are no problems with the driver itself, methinks, it loads
correctly and everithing seems to be fine.
But when I try to create an outbound window, in order to "talk" some other
boards in the crate I get this:
__ioremap(): phys addr 01000000 is RAM lr d100be34
mode 0
vmedrv: No memory for outbound window
testout: VME_IOCTL_SET_OUTBOUND failed. Errno = 12
I'm not sure I understand all of this anyways... Except that there is no
sufficient memory to map for the outbound window.
That's what this test is supposed to do is to open the appropriate devices
for the VME bus (in this case /dev/vme_m[0-7]), configure the outbound
windows from 0 through 6 (the 7th is reserved) and then verifies that data
can be read through these outbound windows.
I'm using an VME driver downloaded from vmelinux.org and here is the source
of the test program I'm trying to run ->
http://www-zeuthen.desy.de/~boyanov/testOutWindow.txt<http://www-zeuthen.desy.de/%7Eboyanov/testOutWindow.txt>
I'm sorry for the newb question, but any ideas what is going wrong?
Thank you.
Kind regards,
Konstantin Boyanov
[-- Attachment #2: Type: text/html, Size: 1544 bytes --]
^ 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