* Re: [PATCH 2/4]: powerpc/cell spidernet low watermark patch.
From: Linas Vepstas @ 2006-08-22 0:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: arnd, netdev, jklewis, linux-kernel, linuxppc-dev, Jens.Osterkamp,
David Miller
In-Reply-To: <1155962022.5803.68.camel@localhost.localdomain>
On Sat, Aug 19, 2006 at 02:33:42PM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2006-08-18 at 18:45 -0500, Linas Vepstas wrote:
> > On Fri, Aug 18, 2006 at 06:29:42PM -0500, linas wrote:
> > >
> > > I don't understand what you are saying. If I call the transmit
> > > queue cleanup code from the poll() routine, nothing hapens,
> > > because the kernel does not call the poll() routine often
> > > enough. I've stated this several times.
> >
> > OK, Arnd gave me a clue stick. I need to call the (misnamed)
> > netif_rx_schedule() from the tx interrupt in order to get
> > this to work. That makes sense, and its easy, I'll send the
> > revised patch.. well, not tonight, but shortly.
>
> You might not want to call it all the time though... You need some
> interrupt mitigation and thus a timer that calls netif_rx_schedule()
> might be of some use still...
Well, again, the whole point of a low-watermark interrupt is to
get zero of them when the system is working correctly; they're
self-mitigating by design.
-------------
Anyway, I tried the suggestion, but am getting less-than-ideal
results.
To recap: my original patch did this:
spider_interrupt_handler(struct whatever *) {
...
if (tx_interrupt)
schedule_work (tx_cleanup_handler)
}
which David Miller objected to. Once I understood the why
(sorry for not getting it right away), I then replaced the
above with the below, which is what I think everyone wanted:
spider_interrupt_handler(struct whatever *) {
...
if (tx_interrupt)
netif_rx_schedule(netdev);
}
spidernet_poll(stuct whatever *) {
tx_cleanup_handler(txring);
// rx_stuff too ...
}
I was expecting this to be a no-op from the performance
point of view. Instead, I get a fairly dramatic (11%) slowdown:
the first patch runs in the 785-805 Mbits/sec range, while
the second patch runs in the 705-715 Mbits/sec range.
I am surprised, ad don't understand why this would be so.
For the record, the alternate patch is below.
----
Index: linux-2.6.18-rc2/drivers/net/spider_net.c
===================================================================
--- linux-2.6.18-rc2.orig/drivers/net/spider_net.c 2006-08-21 16:59:33.000000000 -0500
+++ linux-2.6.18-rc2/drivers/net/spider_net.c 2006-08-21 17:15:28.000000000 -0500
@@ -1087,6 +1090,8 @@ spider_net_poll(struct net_device *netde
int packets_to_do, packets_done = 0;
int no_more_packets = 0;
+ spider_net_cleanup_tx_ring(card);
+
packets_to_do = min(*budget, netdev->quota);
while (packets_to_do) {
@@ -1495,16 +1500,16 @@ spider_net_interrupt(int irq, void *ptr,
if (!status_reg)
return IRQ_NONE;
- if (status_reg & SPIDER_NET_RXINT ) {
+ if (status_reg & SPIDER_NET_RXINT) {
spider_net_rx_irq_off(card);
netif_rx_schedule(netdev);
}
- if (status_reg & SPIDER_NET_TXINT ) {
- spider_net_cleanup_tx_ring(card);
- netif_wake_queue(netdev);
- }
- if (status_reg & SPIDER_NET_ERRINT )
+ /* Call rx_schedule from the tx interrupt, so that NAPI poll runs. */
+ if (status_reg & SPIDER_NET_TXINT)
+ netif_rx_schedule(netdev);
+
+ if (status_reg & SPIDER_NET_ERRINT)
spider_net_handle_error_irq(card, status_reg);
/* clear interrupt sources */
^ permalink raw reply
* Re: [RFC] HOWTO use NAPI to reduce TX interrupts
From: Roland Dreier @ 2006-08-22 0:29 UTC (permalink / raw)
To: David Miller
Cc: akpm, arnd, netdev, jklewis, linux-kernel, linuxppc-dev,
Jens.Osterkamp, jgarzik, shemminger
In-Reply-To: <20060821.165616.107936004.davem@davemloft.net>
David> Don't touch interrupts until both RX and TX queue work is
David> fullydepleted. You seem to have this notion that RX and TX
David> interrupts are seperate. They aren't, even if your device
David> can generate those events individually. Whatever interrupt
David> you get, you shut down all interrupt sources and schedule
David> the ->poll(). Then ->poll() does something like:
This is a digression from spidernet, but what if a device is able to
generate separate MSIs for TX and RX? Some people from IBM have
suggested that it is beneficial for throughput to handle TX work and
RX work for IP-over-InfiniBand in parallel on separate CPUs, and
handling everything through the ->poll() method would defeat this.
- R.
^ permalink raw reply
* Re: [PATCH 2/4]: powerpc/cell spidernet low watermark patch.
From: David Miller @ 2006-08-22 0:30 UTC (permalink / raw)
To: linas; +Cc: arnd, jklewis, linux-kernel, linuxppc-dev, netdev, Jens.Osterkamp
In-Reply-To: <20060822001311.GK5427@austin.ibm.com>
From: linas@austin.ibm.com (Linas Vepstas)
Date: Mon, 21 Aug 2006 19:13:11 -0500
> @@ -1495,16 +1500,16 @@ spider_net_interrupt(int irq, void *ptr,
> if (!status_reg)
> return IRQ_NONE;
>
> - if (status_reg & SPIDER_NET_RXINT ) {
> + if (status_reg & SPIDER_NET_RXINT) {
> spider_net_rx_irq_off(card);
> netif_rx_schedule(netdev);
> }
> - if (status_reg & SPIDER_NET_TXINT ) {
> - spider_net_cleanup_tx_ring(card);
> - netif_wake_queue(netdev);
> - }
>
> - if (status_reg & SPIDER_NET_ERRINT )
> + /* Call rx_schedule from the tx interrupt, so that NAPI poll runs. */
> + if (status_reg & SPIDER_NET_TXINT)
> + netif_rx_schedule(netdev);
> +
> + if (status_reg & SPIDER_NET_ERRINT)
This should be:
if ((status_reg & (SPIDET_NET_RXINT | SPIDET_NET_TXINT))) {
spider_net_rx_and_tx_irq_off(card);
netif_rx_schedule();
}
^ permalink raw reply
* Re: [RFC] HOWTO use NAPI to reduce TX interrupts
From: David Miller @ 2006-08-22 0:32 UTC (permalink / raw)
To: rdreier
Cc: akpm, arnd, netdev, jklewis, linux-kernel, linuxppc-dev,
Jens.Osterkamp, jgarzik, shemminger
In-Reply-To: <adaac5x3966.fsf@cisco.com>
From: Roland Dreier <rdreier@cisco.com>
Date: Mon, 21 Aug 2006 17:29:05 -0700
> This is a digression from spidernet, but what if a device is able to
> generate separate MSIs for TX and RX? Some people from IBM have
> suggested that it is beneficial for throughput to handle TX work and
> RX work for IP-over-InfiniBand in parallel on separate CPUs, and
> handling everything through the ->poll() method would defeat this.
The TX work is so incredibly cheap, relatively speaking, compared
to the full input packet processing path that the RX side runs
that I see no real benefit.
In fact, you might even get better locality due to the way the
locking can be performed if TX reclaim runs inside of ->poll()
^ permalink raw reply
* I'm trying the 860hdlc driver for linux 2.4. Could you help me?
From: Ju Chulmin @ 2006-08-22 2:59 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 328 bytes --]
Hello, I'm newbie.
I'm writing the HDLC driver for mpc860.
And, I try to find the best to do. The time frame is very short.
Before preceeding, I surfed the goole group, and found the web link
contained, but link is broken.
If anyone have the driver, could you share it with me?
Thank you.
Freelancer Linux developer.
J.C.
[-- Attachment #2: Type: text/html, Size: 506 bytes --]
^ permalink raw reply
* Re: [PATCH] windfarm_smu_sat.c: simplify around i2c_add_driver()
From: Benjamin Herrenschmidt @ 2006-08-22 3:27 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: Andrew Morton, linuxppc-dev
In-Reply-To: <20060821232223.GB5220@martell.zuzino.mipt.ru>
On Tue, 2006-08-22 at 03:22 +0400, Alexey Dobriyan wrote:
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Oops ... :)
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> drivers/macintosh/windfarm_smu_sat.c | 7 +------
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> --- a/drivers/macintosh/windfarm_smu_sat.c
> +++ b/drivers/macintosh/windfarm_smu_sat.c
> @@ -397,12 +397,7 @@ static int wf_sat_detach(struct i2c_clie
>
> static int __init sat_sensors_init(void)
> {
> - int err;
> -
> - err = i2c_add_driver(&wf_sat_driver);
> - if (err < 0)
> - return err;
> - return 0;
> + return i2c_add_driver(&wf_sat_driver);
> }
>
> static void __exit sat_sensors_exit(void)
^ permalink raw reply
* Re: Take 2: [RFC] Debugging with a HW probe.
From: Milton Miller @ 2006-08-22 6:04 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <E1G9jpY-0004Nv-2d@kmac.watson.ibm.com>
On Aug 14, 2006, at 5:16 AM, Jimi Xenidis jimix at watson.ibm.com
wrote:
> A rework of the original patch, some on and off list comments had
> suggested that this be a generic service, and to make it very hard
> to unintentionally turn it on. I fact we should make sure that the
> feature is indeed turned off.
>
> Any suggestions on how to operate on the HID bits of all CPUs based on
> the value of the config _and_ 'hw_probe_enabled' would be welcom.
>
> I'd also like to wait for Olof's:
> http://ozlabs.org/pipermail/linuxppc-dev/2006-August/025024.html
> patch to make it to the tree (or not).
>
> Signed-off-by: Jimi Xenidis <jimix at watson.ibm.com>
[sorry for the list archive patch munging]
> ---
> diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
> index e29ef77..bc4cdf9 100644
> --- a/arch/powerpc/Kconfig.debug
> +++ b/arch/powerpc/Kconfig.debug
> @@ -61,6 +61,17 @@ config KGDB_CONSOLE
> over the gdb stub.
> If unsure, say N.
>
> +config ENABLE_HW_PROBE
> + bool "Allow instructions that contact a hardware probe
> (dangerous)"
> + depends on PPC64
Not having this depend on DEBUGGER but in the middle of things that do
will
get you scorn from the auto-indenting police.
Since we can only call this from xmon, should it depend on XMON (and be
placed after that)?
> + help
> + If you enable this AND you add "hwprobe" to the cmdline, the
> + processor will enable instructions that contact the hardware
> + probe. These instructions ca be used in all processor modes
can
> + _including_ user mode and are only useful for kernel
not sure this _highlighting_ is used elsewhere in Kconfig help ...
Should we mention that a hardware probe is required to continue
exectuion?
In other words, its not just contact, but signal and wait for a hw
probe?
> + development and debugging. DO NOT enable this unless you
> + plan to use it.
> +
> config XMON
> bool "Include xmon kernel debugger"
> depends on DEBUGGER && !PPC_ISERIES
> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
> index bf2005b..02c5b83 100644
> --- a/arch/powerpc/kernel/prom.c
> +++ b/arch/powerpc/kernel/prom.c
> @@ -68,6 +68,9 @@ int __initdata iommu_is_off;
> int __initdata iommu_force_on;
> unsigned long tce_alloc_start, tce_alloc_end;
> #endif
> +#ifdef CONFIG_ENABLE_HW_PROBE
> +int hw_probe_enabled;
> +#endif
>
> typedef u32 cell_t;
>
> @@ -693,6 +696,11 @@ #ifdef CONFIG_PPC64
> if (of_get_flat_dt_prop(node, "linux,iommu-force-on", NULL) !=
> NULL)
> iommu_force_on = 1;
> #endif
> +#ifdef CONFIG_HW_PROBE_ENABLE
> + if (of_get_flat_dt_prop(node, "linux,hw-probe-enable", NULL)
> != NULL) {
> + hw_probe_enabled = 1;
> + DBG("HW Probe will be enabled\n");
> +#endif
No. [see next comment]
>
> /* mem=x on the command line is the preferred mechanism */
> lprop = of_get_flat_dt_prop(node, "linux,memory-limit", NULL);
> diff --git a/arch/powerpc/kernel/prom_init.c
> b/arch/powerpc/kernel/prom_init.c
> index 90972ef..26428de 100644
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -587,6 +587,14 @@ #ifdef CONFIG_PPC64
> RELOC(iommu_force_on) = 1;
> }
> #endif
> +#ifdef CONFIG_HW_PROBE_ENABLE
> + opt = strstr(RELOC(prom_cmd_line), RELOC("hwprobe"));
> + if (opt) {
> + prom_printf("WARNING! HW Probe will be activated!\n");
> + prom_setprop(_prom->chosen, "/chosen",
> + "linux,hw-probe-enable", NULL, 0);
> + }
> +#endif
> }
Please, PLEASE do NOT do this.
prom_init.c is only used by one of the many flat device tree generators,
namely the open-firmware client. Adding a property like this requires
us
to update all the other clients.
And there is no reason to parse it this early.
Instead, parse it from the command line like the other early parsing.
I thing a generic early_param would be fine. However, xmon_init is an
early_parm in setup-common, so if you really require it before the first
call, then you could parse it next to mem= at the bottom of
early_init_dt_scan_chosen.
Which .h is hw_probe_enabled in? (none?)
>
> #ifdef CONFIG_PPC_PSERIES
> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
> index 179b10c..51a1e4e 100644
> --- a/arch/powerpc/xmon/xmon.c
> +++ b/arch/powerpc/xmon/xmon.c
> @@ -189,7 +189,12 @@ #endif
> dd dump double values\n\
> dr dump stream of raw bytes\n\
> e print exception information\n\
> - f flush cache\n\
> + f flush cache\n"
> +#ifdef CONFIG_ENABLE_HW_PROBE
> + "\
> + H Contact hardware probe, if available\n"
> +#endif
> + "\
While this style does keep the lines aligned in the source, it adds
veritcal
almost-whitespace. And I notice a different choice was made at the
bottom.
> la lookup symbol+offset of specified address\n\
> ls lookup address of specified symbol\n\
> m examine/change memory\n\
> @@ -217,6 +222,18 @@ #endif
> zh halt\n"
> ;
>
> +#ifdef CONFIG_ENABLE_HW_PROBE
> +/* try to keep this funtion from being inlined so its easier to move
> + * around the ATTN instruction */
> +extern int hw_probe_enabled;
> +static noinline void xmon_hw_probe(void)
> +{
> + if (!hw_probe_enabled)
> + return;
> + ATTN();
> +}
> +#endif
> +
> static struct pt_regs *xmon_regs;
>
> static inline void sync(void)
> @@ -819,6 +836,11 @@ #endif /* CONFIG_SMP */
> if (cpu_cmd())
> return 0;
> break;
> +#ifdef CONFIG_ENABLE_HW_PROBE
> + case 'H':
> + xmon_hw_probe();
> + break;
> +#endif
> case 'z':
> bootcmds();
> break;
> diff --git a/include/asm-powerpc/reg.h b/include/asm-powerpc/reg.h
> index cf73475..478097e 100644
> --- a/include/asm-powerpc/reg.h
> +++ b/include/asm-powerpc/reg.h
> @@ -207,6 +207,13 @@ #define SPRN_EAR 0x11A /* External
> Addr
> #define SPRN_HASH1 0x3D2 /* Primary Hash Address
> Register */
> #define SPRN_HASH2 0x3D3 /* Secondary Hash Address
> Resgister */
> #define SPRN_HID0 0x3F0 /* Hardware Implementation
> Register 0 */
> +#ifdef __ASSEMBLY__
> +#define HID0_QATTN (1<<35) /* Sup. Proc. attn insn all
> threads */
> +#define HID0_ATTN (1<<32) /* Sup. Proc. attn insn */
> +#else
> +#define HID0_QATTN (1UL<<35) /* Sup. Proc. attn insn all
> threads */
> +#define HID0_ATTN (1UL<<32) /* Sup. Proc. attn insn */
> +#endif
> #define HID0_EMCP (1<<31) /* Enable Machine Check pin */
> #define HID0_EBA (1<<29) /* Enable Bus Address Parity */
> #define HID0_EBD (1<<28) /* Enable Bus Data Parity */
> @@ -641,6 +648,13 @@ extern void ppc64_runlatch_off(void);
> extern unsigned long scom970_read(unsigned int address);
> extern void scom970_write(unsigned int address, unsigned long value);
>
> +/*
> + * Support Processor Attention Instruction instroduced in POWER
> + * architecture processors as of RS64, tho may not be supported by
> + * POWER 3.
> + */
> +#define ATTN() asm volatile("attn; nop")
> +
Fairly certian POWER3 does NOT implement this, but I don't have book IV
handy.
Does one of the processors require the nop ?
> #else
> #define ppc64_runlatch_on()
> #define ppc64_runlatch_off()
>
milton
^ permalink raw reply
* Re: Take 2: [RFC] Debugging with a HW probe.
From: Michael Ellerman @ 2006-08-22 7:13 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <aa3478a76dd7fb5bff781350a7538fb0@bga.com>
[-- Attachment #1: Type: text/plain, Size: 2684 bytes --]
On Tue, 2006-08-22 at 01:04 -0500, Milton Miller wrote:
> On Aug 14, 2006, at 5:16 AM, Jimi Xenidis jimix at watson.ibm.com
> > @@ -693,6 +696,11 @@ #ifdef CONFIG_PPC64
> > if (of_get_flat_dt_prop(node, "linux,iommu-force-on", NULL) !=
> > NULL)
> > iommu_force_on = 1;
> > #endif
> > +#ifdef CONFIG_HW_PROBE_ENABLE
> > + if (of_get_flat_dt_prop(node, "linux,hw-probe-enable", NULL)
> > != NULL) {
> > + hw_probe_enabled = 1;
> > + DBG("HW Probe will be enabled\n");
> > +#endif
>
> No. [see next comment]
>
> >
> > /* mem=x on the command line is the preferred mechanism */
> > lprop = of_get_flat_dt_prop(node, "linux,memory-limit", NULL);
> > diff --git a/arch/powerpc/kernel/prom_init.c
> > b/arch/powerpc/kernel/prom_init.c
> > index 90972ef..26428de 100644
> > --- a/arch/powerpc/kernel/prom_init.c
> > +++ b/arch/powerpc/kernel/prom_init.c
> > @@ -587,6 +587,14 @@ #ifdef CONFIG_PPC64
> > RELOC(iommu_force_on) = 1;
> > }
> > #endif
> > +#ifdef CONFIG_HW_PROBE_ENABLE
> > + opt = strstr(RELOC(prom_cmd_line), RELOC("hwprobe"));
> > + if (opt) {
> > + prom_printf("WARNING! HW Probe will be activated!\n");
> > + prom_setprop(_prom->chosen, "/chosen",
> > + "linux,hw-probe-enable", NULL, 0);
> > + }
> > +#endif
> > }
>
> Please, PLEASE do NOT do this.
>
> prom_init.c is only used by one of the many flat device tree generators,
> namely the open-firmware client. Adding a property like this requires
> us
> to update all the other clients.
>
> And there is no reason to parse it this early.
>
> Instead, parse it from the command line like the other early parsing.
>
> I thing a generic early_param would be fine. However, xmon_init is an
> early_parm in setup-common, so if you really require it before the first
> call, then you could parse it next to mem= at the bottom of
> early_init_dt_scan_chosen.
What Milton said, we learnt that the hard way with kexec :)
Except that we don't do mem= in early_init_dt_scan_chosen anymore (get a
newer kernel Milton!).
The early_param parsing is done very early, and the xmon= parsing does
not jump into xmon, it waits until a little later before doing it. So an
early_param should be fine, ie. it will be parsed before xmon ever runs.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] uninorth: Add module param 'aperture' for aperture size
From: Benjamin Herrenschmidt @ 2006-08-22 7:25 UTC (permalink / raw)
To: Michel Dänzer; +Cc: linuxppc-dev
In-Reply-To: <1156176559.16513.78.camel@thor.lorrainebruecke.local>
On Mon, 2006-08-21 at 18:09 +0200, Michel Dänzer wrote:
> In contrast to most if not all PC BIOSes, OpenFirmware (OF) on PowerMacs with
> UniNorth bridges does not allow changing the aperture size. The size set up by
> OF is usually 16 MB, which is too low for graphics intensive environments.
> Hence, add a module parameter that allows changing the aperture size at driver
> initialization time. When the parameter is not specified, the default is still
> to leave the size unchanged, usually as set up by OF.
The right fix is to allow changing it by the driver ... can't we do it
such that AGPSize will work & change it ? The firmware doesn't actually
configure it at all I suspect... those 16M are basically
what the HW comes up with as a default setting (unless the firmware runs
some diagnostics and sets it as a result of these). It's basically
expected that we set it ourselves and a module option doesn't seem like
a terribly good idea to me...
Maybe we should just have the driver default to something more sensible
in addition to what AGPSize comes from userland ? like 64M ?
Ben.
^ permalink raw reply
* ioremap() fails for >64 MB
From: Phil Nitschke @ 2006-08-22 7:41 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I have 2 GB memory on a 7448 processor, and want to reserve a huge chunk
of it at boot-time, then ioremap() it into the kernel space inside a
device driver. So far I've succeeded with 64 MB, but can't go any
higher, as mm/vmalloc.c tells me: "allocation failed: out of vmalloc
space - use vmalloc=<size> to increase size."
So I tried adding a vmalloc line to the kernel command line as follows:
Kernel cmd line: root=/dev/nfs rw mem=1920M vmalloc=1024M nfsroot=...
After booting the processor, here is my memory arrangement:
bash-3.00# cat /proc/meminfo
MemTotal: 1943232 kB
MemFree: 1910508 kB
...
HighTotal: 1179648 kB
HighFree: 1154608 kB
LowTotal: 763584 kB
LowFree: 755900 kB
...
VmallocTotal: 145024 kB
VmallocUsed: 65944 kB
VmallocChunk: 78972 kB
After inserting my device driver module (which ioremap()s 64 MB),
meminfo is as follows:
bash-3.00# cat /proc/meminfo
MemTotal: 1943232 kB
MemFree: 1916512 kB
...
HighTotal: 1179648 kB
HighFree: 1160748 kB
LowTotal: 763584 kB
LowFree: 755764 kB
...
VmallocTotal: 145024 kB
VmallocUsed: 133568 kB
VmallocChunk: 10364 kB
So the vmalloc=<size> argument has made no difference. What do I need
to do to make this work?
TIA,
--
Phil
bash-3.00# uname -a
Linux arty9 2.6.16-pmppc744x #211 Fri Aug 18 19:03:36 CST 2006 ppc ppc
ppc GNU/Linux
^ permalink raw reply
* Re: [PATCH 0/6] Sizing zones and holes in an architecture independent manner V9
From: Mel Gorman @ 2006-08-22 8:38 UTC (permalink / raw)
To: Keith Mannthey
Cc: akpm, tony.luck, linuxppc-dev, ak, bob.picco,
Linux Kernel Mailing List, Linux Memory Management List
In-Reply-To: <a762e240608211152x5d4f11f0wd26f7e3d75d38e0a@mail.gmail.com>
On Mon, 21 Aug 2006, Keith Mannthey wrote:
> On 8/21/06, Mel Gorman <mel@csn.ul.ie> wrote:
>> This is V9 of the patchset to size zones and memory holes in an
>> architecture-independent manner. It booted successfully on 5 different
>> machines (arches were x86, x86_64, ppc64 and ia64) in a number of different
>> configurations and successfully built a kernel. If it fails on any machine,
>> booting with loglevel=8 and the console log should tell me what went wrong.
>>
>
> I am wondering why this new api didn't cleanup the pfn_to_nid code
> path as well. Arches are left to still keep another set of
> nid-start-end info around. We are sending info like
>
pfn_to_nid() is used at runtime and the early_node_map[] is deleted by
then. As this step, I only want to get the initialisation correct. What
can be replaced is the architecture-specific early_pfn_to_nid() function
which I did for power and x86.
> add_active_range(unsigned int nid, unsigned long start_pfn, unsigned
> long end_pfn)
>
> With this info making a common pnf_to_nid seems to be of intrest so we
> don't have to keep redundant information in both generic and arch
> specific data structures.
>
To implement a common one of interest, the array would have to be
converted to a linked list at the end of boot so it could be modified by
memory hot-add, then pfn_to_nid() would walk the linked list rather than
the existing array. pfn_valid() would probably be replaced as well.
However, this is going to be slower (if more accurate in some cases) than
the existing pfn_valid() and so I would treat it as a separate issue.
> Are you intending the hot-add memory code path to call add_active_range or
> ???
>
Not at this time. I want to make sure the memory initialisation is right
before dealing with additional complications.
> Thanks,
> Keith
>
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: ioremap() fails for >64 MB
From: Alex Zeffertt @ 2006-08-22 8:50 UTC (permalink / raw)
To: Phil.Nitschke; +Cc: linuxppc-embedded
In-Reply-To: <1156232469.26041.19.camel@caxton.int.avalon.com.au>
Phil Nitschke wrote:
> Hi all,
>
> I have 2 GB memory on a 7448 processor, and want to reserve a huge chunk
> of it at boot-time, then ioremap() it into the kernel space inside a
> device driver. So far I've succeeded with 64 MB, but can't go any
> higher, as mm/vmalloc.c tells me: "allocation failed: out of vmalloc
> space - use vmalloc=<size> to increase size."
>
I remember reading in Linux Device Drivers that you can use the bigphysarea
patch to allocate large memory, as long as you do it at boot time. It seems
it's been ported to 2.6 too:
http://lwn.net/Articles/111132/
Alex
^ permalink raw reply
* Re: PPC beginner questions
From: David H. Lynch Jr. @ 2006-08-22 8:53 UTC (permalink / raw)
To: Wade Maxfield; +Cc: ppc
In-Reply-To: <45a1b53e0608210651s4f5de382w77e092463dbbf5b7@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2994 bytes --]
Wade Maxfield wrote:
>
> I'm new to the PPC and I have a few questions. I have written a
> driver in the past for the X86 family, using i/o ports, but it was
> kernel 2.0 and i/o ports are not mmu handled.
> I've been looking through the archive and I am slowly growing more
> confused.
The PPC MMU is pretty simple compared to the x86.
Basically the MMU unit is a peice of hardware that maps "virtual"
addresses to "physical" addresses.
Its use is enabled/disabled by two bits in the PPC Machine Status
register - 1 for instructions, 1 for data.
The MMU itself is basically a 64 entry lookup table. Virtual address
X corresponds to physical address Y.
When a request is made for an address that is not in the 64 entry
MMU table things become more complex
- an exception is generated and code inside Linux searches its
tables to find the correct entry to stuff into the MMU.
NORMALLY there is no correspondence between physical addresses and
virtual ones. But it is possible (and might be useful for debugging) to
stuff an entry
where physical=virtual. If you look inside head_4xx.S for
CONFIG_SERIAL_TEXT_DEBUG or something like that you should see how to do it.
However manually stuffed entries in the MMU will eventually get
blown away. I spent a week trying to trace a problem caused by that down.
>
> We are using Xilinx with PPC built in.
>
> The PPC has a memory management unit. All of the IP we've added is
> mapped to physical addresses.
>
> 1. Can I access the memory the peripherasl are mapped to directly
> within the driver without going through functions?
> if NOT, then Do I use
> 1. ioremap(),
Once you have done the ioremap(), you can use the address returned
exactly the way you would have used the physical address previously.
> 2. request_mem_region(),
> 3. request_region()
> 4. something else?
>
> 2. Are there any gotcha's with the ppc 405 that Xilinx uses that I
> should know about?
Are you doing board bringup ?
If you are not bringing up a new board - then the big gotcha's
should already be covered.
If you are doing board bringup - I would recommend following the
existing xilinx packages closely.
>
>
> thanks,
> wade
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
[-- Attachment #2: Type: text/html, Size: 4574 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] uninorth: Add module param 'aperture' for aperture size
From: Michel Dänzer @ 2006-08-22 8:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, davej
In-Reply-To: <1156231536.21752.100.camel@localhost.localdomain>
On Tue, 2006-08-22 at 17:25 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2006-08-21 at 18:09 +0200, Michel Dänzer wrote:
>
> > In contrast to most if not all PC BIOSes, OpenFirmware (OF) on PowerMacs with
> > UniNorth bridges does not allow changing the aperture size. The size set up by
> > OF is usually 16 MB, which is too low for graphics intensive environments.
> > Hence, add a module parameter that allows changing the aperture size at driver
> > initialization time. When the parameter is not specified, the default is still
> > to leave the size unchanged, usually as set up by OF.
>
> The right fix is to allow changing it by the driver ... can't we do it
> such that AGPSize will work & change it ?
Not sure, but it seems like the aperture size is fixed at backend
initialization time, i.e. in the driver's probe hook.
> It's basically expected that we set it ourselves and a module option
> doesn't seem like a terribly good idea to me...
Well, wasn't it you who suggested this? :)
> Maybe we should just have the driver default to something more sensible
> in addition to what AGPSize comes from userland ? like 64M ?
Might be a good idea.
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
From: Stefan Richter @ 2006-08-22 8:58 UTC (permalink / raw)
To: Bill Fink; +Cc: linux1394-devel, linuxppc-dev
In-Reply-To: <20060819201849.5e8d6e6c.billfink@mindspring.com>
Bill Fink wrote:
>> > on my desktop PowerMac systems, I need a "sleep 2"
>> > before the modprobe for sbp2, to get my Firewire disks to work
>> > properly.
[...]
> First of all this was on a somewhat older 2.6.11.8 kernel without
> any hotplug (I'll probably be trying this again soon with a newer
> 2.6.15-rc5 kernel). And I was actually booting off this Firewire
> disk. Without the pause I would get:
[...]
> Then it wouldn't be able to mount the root filesystem, which would
> be followed shortly by a kernel panic.
>
> If I put the "sleep 2" before the "modprobe sbp2" then everything
> works. There's a message about initializing SCSI emulation for SBP-2,
> followed by the discovery of the Firewire disk and the creation of
> the sda device, which then allows the successful mounting of the
> root filesystem.
>
> Here's the full linuxrc nash script from the initrd for the working case:
>
> #!/bin/nash
>
> mount -t proc /proc /proc
> setquiet
> echo Mounted /proc filesystem
> echo Mounting sysfs
> mount -t sysfs none /sys
> echo "Loading ieee1394.ko module"
> insmod /lib/ieee1394.ko
> echo "Loading ohci1394.ko module"
> insmod /lib/ohci1394.ko
> sleep 2
> echo "Loading raw1394.ko module"
> insmod /lib/raw1394.ko
> echo "Loading sbp2.ko module"
> insmod /lib/sbp2.ko
> echo Creating block devices
> mkdevices /dev
> echo Creating root device
> mkrootdev /dev/root
> umount /sys
> echo 0x0100 > /proc/sys/kernel/real-root-dev
> echo Mounting root filesystem
> mount -o defaults --ro -t ext3 /dev/root /sysroot
> pivot_root /sysroot /sysroot/initrd
> umount /initrd/proc
>
> The disk is an 80 GB LaCie Firewire disk, reported by the kernel as:
[...]
OK. Mounting the root FS from a FireWire disk is a somewhat different
matter from normal hotplug. I can see why you need the few seconds pause
between when ohci1394 is loaded and when sbp2 is loaded. With this
pause, it is very likely that ieee1394 was able to discover and scan the
disk's node before sbp2 is loaded. AFAIU, "insmod sbp2" will therefore
not only load the sbp2 code but will also execute sbp2's device probe
routine (i.e. SBP-2 login, creation of the SCSI device, SCSI inquiry,
and attachment of the sd driver to it) before "insmod sbp2" exits.
Another approach would be to put a basically complete hotplug userland
into the initrd and then wait for the disk with the root FS to appear.
(The disk is e.g. known by its FireWire GUID.) Then you wouldn't need
the hardcoded pause to wait until after the SBP-2 disk made its
configuration ROM available and ieee1394 scanned it.
BTW, a few improvements WRT device recognition went into nearly each of
the Linux releases since 2.6.11. I think they are not relevant to most
or all LaCie disks though.
Discovery of SBP-2 devices will always remain an asynchronous
non-deterministic process anyway. But this is true for all SCSI
transports and interconnects. It's just that most other SCSI
interconnect drivers' initialization routines hold off until they fully
scanned their bus --- which makes sense at least for SCSI interconnects
which are not hotplug capable.
Recently there were patches sent to the Linux SCSI mailinglist that add
optional asynchronous and parallelized bus scanning to all of these
traditional drivers too. Emphasis lies on parallelized since this is
primarily meant to speed up the boot process of systems with many SCSI
buses. There is also a callback to notify the system when all buses are
done with scanning in order to know when to proceed with mounting of
filesystems. I have not yet looked into if this can sensibly used in
sbp2. I also didn't watch the merge status of these SCSI patches.
--
Stefan Richter
-=====-=-==- =--- =-==-
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [PATCH] Add adder87x board support to 2.6.x
From: Bryan O'Donoghue @ 2006-08-22 9:23 UTC (permalink / raw)
To: Bryan O'Donoghue; +Cc: linuxppc-embedded
In-Reply-To: <20060821204320.GD16290@mag.az.mvista.com>
Mark A. Greer wrote:
> Bryan,
>
> If you're not already on the linuxppc-dev mailing list, you should be.
> The 'ppc' tree is deprecated and all new work should be happening in the
> 'powerpc' tree (as in arch/powerpc).
Ah... I saw recent activity in the ppc tree and assumed it was still the
place to do 8xx development.
> The odds of this being accepted are slim but either way, you should read
> the mail archive and get involved in the powerpc migration.
>
> Mark
No worries Mark, perhaps the thing to do is to do a board port based on
the powerpc tree instead.
Bryan
--
Quidquid latine dictum sit, altum sonatur.
- Whatever is said in Latin sounds profound.
^ permalink raw reply
* Re: [PATCH 3/6] POWERPC: move the generic cpm2 stuff to the powerpc
From: Vitaly Bordug @ 2006-08-22 10:02 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <44DE1FA1.2040604@ru.mvista.com>
On Sat, 12 Aug 2006 22:36:17 +0400
Sergei Shtylyov wrote:
> Hello.
>
> Vitaly Bordug wrote:
> > This moves the cpm2 common code and PIC stuff to the powerpc. Most
> > of the files were just copied from ppc/, with minor tuning to make
> > it compile, and, subsequently, work.
> >
> > Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
>
> [...]
>
> > diff --git a/include/asm-ppc/cpm2.h b/include/asm-ppc/cpm2.h
> > index f6a7ff0..876974e 100644
> > --- a/include/asm-ppc/cpm2.h
> > +++ b/include/asm-ppc/cpm2.h
> [...]
> > @@ -1186,7 +1190,7 @@ #define PC3_DIRC1 (PC3_TXDAT)
> > #define FCC_MEM_OFFSET(x) (CPM_FCC_SPECIAL_BASE + (x*128))
> > #define FCC1_MEM_OFFSET FCC_MEM_OFFSET(0)
> > #define FCC2_MEM_OFFSET FCC_MEM_OFFSET(1)
> > -#define FCC2_MEM_OFFSET FCC_MEM_OFFSET(2)
> > +#define FCC3_MEM_OFFSET FCC_MEM_OFFSET(2)
> >
> > #endif /* __CPM2__ */
> > #endif /* __KERNEL__ */
>
> Alas, this last hunk doesn't apply to powerpc.git. Shouldn't it
> be in some other patch instead?
This whole patch series depends on the fs_enet PALification series, that
is accepted to netdev tree at least, according to the last mail from Andrew Morton.
Hence, it will be auto-fixed shortly. Next time I'll submit the preceding stuff
as well to prevent confusion.
>
> WBR, Sergei
>
>
^ permalink raw reply
* [PATCH ] powerpc: Add tsi108/9 and non standard mpic support
From: Zang Roy-r61911 @ 2006-08-22 10:07 UTC (permalink / raw)
To: Paul Mackerras, Benjamin Herrenschmidt
Cc: linuxppc-dev list, Yang Xin-Xin-r48390, Alexandre.Bounine
The patch adds new hardware information table for mpic. This=20
enables mpic code to deal with mpic controller with=20
hardware behavior difference.
CONFIG_MPIC_WEIRD is introduced in the code.
If a board with non standard mpic controller, it can select the
CONFIG_MPIC_WEIRD with board and add its hardware information
in the array mpic_infos.
TSI108/109 PIC takes the first index of weird hardware information=20
table:) . The table can be extended. The Tsi108/109 PIC looks like=20
standard OpenPIC but, in fact, is different in registers mapping and
behavior.
The patch does not affect the behavior of standard mpic.
CONFIG_MPIC_WEIRD
excludes the weird mpic code when building standard mpic.
=20
Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>=20
---
arch/powerpc/Kconfig | 8 +-
arch/powerpc/sysdev/Makefile | 1=20
arch/powerpc/sysdev/mpic.c | 187
+++++++++++++++++++++++++++++-------------
include/asm-powerpc/mpic.h | 114 ++++++++++++++++++++++++++
4 files changed, 252 insertions(+), 58 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index abb325e..c88b647 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -440,11 +440,15 @@ config U3_DART
default n
=20
config MPIC
- depends on PPC_PSERIES || PPC_PMAC || PPC_MAPLE || PPC_CHRP \
- || MPC7448HPC2
+ depends on PPC_PSERIES || PPC_PMAC || PPC_MAPLE || PPC_CHRP
bool
default y
=20
+config MPIC_WEIRD
+ depends on MPC7448HPC2
+ bool
+ default y
+=09
config PPC_RTAS
bool
default n
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index cebfae2..8ae887b 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -3,6 +3,7 @@ EXTRA_CFLAGS +=3D -mno-minimal-toc
endif
=20
obj-$(CONFIG_MPIC) +=3D mpic.o
+obj-$(CONFIG_MPIC_WEIRD) +=3D mpic.o
obj-$(CONFIG_PPC_INDIRECT_PCI) +=3D indirect_pci.o
obj-$(CONFIG_PPC_MPC106) +=3D grackle.o
obj-$(CONFIG_BOOKE) +=3D dcr.o
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 6e0281a..78e0515 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -54,6 +54,55 @@ #define distribute_irqs (0)
#endif
#endif
=20
+#ifdef CONFIG_MPIC_WEIRD
+static u32 mpic_infos[][INDEX_MPIC_WEIRD_END] =3D {
+ [0] =3D { /* Tsi108/109 PIC */
+ TSI108_GREG_BASE,
+ TSI108_GREG_FEATURE_0,
+ TSI108_GREG_GLOBAL_CONF_0,
+ TSI108_GREG_VENDOR_ID,
+ TSI108_GREG_IPI_VECTOR_PRI_0,
+ TSI108_GREG_IPI_STRIDE,
+ TSI108_GREG_SPURIOUS,
+ TSI108_GREG_TIMER_FREQ,
+
+ TSI108_TIMER_BASE,
+ TSI108_TIMER_STRIDE,
+ TSI108_TIMER_CURRENT_CNT,
+ TSI108_TIMER_BASE_CNT,
+ TSI108_TIMER_VECTOR_PRI,
+ TSI108_TIMER_DESTINATION,
+
+ TSI108_CPU_BASE,
+ TSI108_CPU_STRIDE,
+ TSI108_CPU_IPI_DISPATCH_0,
+ TSI108_CPU_IPI_DISPATCH_STRIDE,
+ TSI108_CPU_CURRENT_TASK_PRI,
+ TSI108_CPU_WHOAMI,
+ TSI108_CPU_INTACK,
+ TSI108_CPU_EOI,
+
+ TSI108_IRQ_BASE,
+ TSI108_IRQ_STRIDE,
+ TSI108_IRQ_VECTOR_PRI,
+ TSI108_VECPRI_VECTOR_MASK,
+ TSI108_VECPRI_POLARITY_POSITIVE,
+ TSI108_VECPRI_POLARITY_NEGATIVE,
+ TSI108_VECPRI_SENSE_LEVEL,
+ TSI108_VECPRI_SENSE_EDGE,
+ TSI108_VECPRI_POLARITY_MASK,
+ TSI108_VECPRI_SENSE_MASK,
+ TSI108_IRQ_DESTINATION
+ },
+};
+#endif
+
+#ifdef CONFIG_MPIC_WEIRD
+#define MPIC_INFO(name) mpic->hw_set[INDEX_##name]
+#else
+#define MPIC_INFO(name) MPIC_##name
+#endif
+
/*
* Register accessor functions
*/
@@ -80,7 +129,8 @@ static inline void _mpic_write(unsigned=20
static inline u32 _mpic_ipi_read(struct mpic *mpic, unsigned int ipi)
{
unsigned int be =3D (mpic->flags & MPIC_BIG_ENDIAN) !=3D 0;
- unsigned int offset =3D MPIC_GREG_IPI_VECTOR_PRI_0 + (ipi * 0x10);
+ unsigned int offset =3D MPIC_INFO(GREG_IPI_VECTOR_PRI_0) +
+ (ipi * MPIC_INFO(GREG_IPI_STRIDE));
=20
if (mpic->flags & MPIC_BROKEN_IPI)
be =3D !be;
@@ -89,7 +139,8 @@ static inline u32 _mpic_ipi_read(struct=20
=20
static inline void _mpic_ipi_write(struct mpic *mpic, unsigned int ipi,
u32 value)
{
- unsigned int offset =3D MPIC_GREG_IPI_VECTOR_PRI_0 + (ipi * 0x10);
+ unsigned int offset =3D MPIC_INFO(GREG_IPI_VECTOR_PRI_0) +
+ (ipi * MPIC_INFO(GREG_IPI_STRIDE));
=20
_mpic_write(mpic->flags & MPIC_BIG_ENDIAN, mpic->gregs, offset,
value);
}
@@ -120,7 +171,7 @@ static inline u32 _mpic_irq_read(struct=20
unsigned int idx =3D src_no & mpic->isu_mask;
=20
return _mpic_read(mpic->flags & MPIC_BIG_ENDIAN,
mpic->isus[isu],
- reg + (idx * MPIC_IRQ_STRIDE));
+ reg + (idx * MPIC_INFO(IRQ_STRIDE)));
}
=20
static inline void _mpic_irq_write(struct mpic *mpic, unsigned int
src_no,
@@ -130,7 +181,7 @@ static inline void _mpic_irq_write(struc
unsigned int idx =3D src_no & mpic->isu_mask;
=20
_mpic_write(mpic->flags & MPIC_BIG_ENDIAN, mpic->isus[isu],
- reg + (idx * MPIC_IRQ_STRIDE), value);
+ reg + (idx * MPIC_INFO(IRQ_STRIDE)), value);
}
=20
#define mpic_read(b,r) _mpic_read(mpic->flags &
MPIC_BIG_ENDIAN,(b),(r))
@@ -156,8 +207,8 @@ static void __init mpic_test_broken_ipi(
{
u32 r;
=20
- mpic_write(mpic->gregs, MPIC_GREG_IPI_VECTOR_PRI_0,
MPIC_VECPRI_MASK);
- r =3D mpic_read(mpic->gregs, MPIC_GREG_IPI_VECTOR_PRI_0);
+ mpic_write(mpic->gregs, MPIC_INFO(GREG_IPI_VECTOR_PRI_0),
MPIC_VECPRI_MASK);
+ r =3D mpic_read(mpic->gregs, MPIC_INFO(GREG_IPI_VECTOR_PRI_0));
=20
if (r =3D=3D le32_to_cpu(MPIC_VECPRI_MASK)) {
printk(KERN_INFO "mpic: Detected reversed IPI
registers\n");
@@ -394,8 +445,8 @@ static inline struct mpic * mpic_from_ir
/* Send an EOI */
static inline void mpic_eoi(struct mpic *mpic)
{
- mpic_cpu_write(MPIC_CPU_EOI, 0);
- (void)mpic_cpu_read(MPIC_CPU_WHOAMI);
+ mpic_cpu_write(MPIC_INFO(CPU_EOI), 0);
+ (void)mpic_cpu_read(MPIC_INFO(CPU_WHOAMI));
}
=20
#ifdef CONFIG_SMP
@@ -419,8 +470,8 @@ static void mpic_unmask_irq(unsigned int
=20
DBG("%p: %s: enable_irq: %d (src %d)\n", mpic, mpic->name, irq,
src);
=20
- mpic_irq_write(src, MPIC_IRQ_VECTOR_PRI,
- mpic_irq_read(src, MPIC_IRQ_VECTOR_PRI) &
+ mpic_irq_write(src, MPIC_INFO(IRQ_VECTOR_PRI),
+ mpic_irq_read(src, MPIC_INFO(IRQ_VECTOR_PRI)) &
~MPIC_VECPRI_MASK);
/* make sure mask gets to controller before we return to user */
do {
@@ -428,7 +479,7 @@ static void mpic_unmask_irq(unsigned int
printk(KERN_ERR "mpic_enable_irq timeout\n");
break;
}
- } while(mpic_irq_read(src, MPIC_IRQ_VECTOR_PRI) &
MPIC_VECPRI_MASK);
+ } while(mpic_irq_read(src, MPIC_INFO(IRQ_VECTOR_PRI)) &
MPIC_VECPRI_MASK);=09
}
=20
static void mpic_mask_irq(unsigned int irq)
@@ -439,8 +490,8 @@ static void mpic_mask_irq(unsigned int i
=20
DBG("%s: disable_irq: %d (src %d)\n", mpic->name, irq, src);
=20
- mpic_irq_write(src, MPIC_IRQ_VECTOR_PRI,
- mpic_irq_read(src, MPIC_IRQ_VECTOR_PRI) |
+ mpic_irq_write(src, MPIC_INFO(IRQ_VECTOR_PRI),
+ mpic_irq_read(src, MPIC_INFO(IRQ_VECTOR_PRI)) |
MPIC_VECPRI_MASK);
=20
/* make sure mask gets to controller before we return to user */
@@ -449,7 +500,7 @@ static void mpic_mask_irq(unsigned int i
printk(KERN_ERR "mpic_enable_irq timeout\n");
break;
}
- } while(!(mpic_irq_read(src, MPIC_IRQ_VECTOR_PRI) &
MPIC_VECPRI_MASK));
+ } while(!(mpic_irq_read(src, MPIC_INFO(IRQ_VECTOR_PRI)) &
MPIC_VECPRI_MASK));
}
=20
static void mpic_end_irq(unsigned int irq)
@@ -560,24 +611,32 @@ static void mpic_set_affinity(unsigned i
=20
cpus_and(tmp, cpumask, cpu_online_map);
=20
- mpic_irq_write(src, MPIC_IRQ_DESTINATION,
+ mpic_irq_write(src, MPIC_INFO(IRQ_DESTINATION),
mpic_physmask(cpus_addr(tmp)[0]));=09
}
=20
+#ifdef CONFIG_MPIC_WEIRD
+static unsigned int mpic_type_to_vecpri(struct mpic *mpic, unsigned int
type)
+#else
static unsigned int mpic_type_to_vecpri(unsigned int type)
+#endif
{
/* Now convert sense value */
switch(type & IRQ_TYPE_SENSE_MASK) {
case IRQ_TYPE_EDGE_RISING:
- return MPIC_VECPRI_SENSE_EDGE |
MPIC_VECPRI_POLARITY_POSITIVE;
+ return MPIC_INFO(VECPRI_SENSE_EDGE) |
+ MPIC_INFO(VECPRI_POLARITY_POSITIVE);
case IRQ_TYPE_EDGE_FALLING:
case IRQ_TYPE_EDGE_BOTH:
- return MPIC_VECPRI_SENSE_EDGE |
MPIC_VECPRI_POLARITY_NEGATIVE;
+ return MPIC_INFO(VECPRI_SENSE_EDGE) |
+ MPIC_INFO(VECPRI_POLARITY_NEGATIVE);
case IRQ_TYPE_LEVEL_HIGH:
- return MPIC_VECPRI_SENSE_LEVEL |
MPIC_VECPRI_POLARITY_POSITIVE;
+ return MPIC_INFO(VECPRI_SENSE_LEVEL) |
+ MPIC_INFO(VECPRI_POLARITY_POSITIVE);
case IRQ_TYPE_LEVEL_LOW:
default:
- return MPIC_VECPRI_SENSE_LEVEL |
MPIC_VECPRI_POLARITY_NEGATIVE;
+ return MPIC_INFO(VECPRI_SENSE_LEVEL) |
+ MPIC_INFO(VECPRI_POLARITY_NEGATIVE);
}
}
=20
@@ -609,13 +668,18 @@ static int mpic_set_irq_type(unsigned in
vecpri =3D MPIC_VECPRI_POLARITY_POSITIVE |
MPIC_VECPRI_SENSE_EDGE;
else
+#ifdef CONFIG_MPIC_WEIRD
+ vecpri =3D mpic_type_to_vecpri(mpic, flow_type);
+#else
vecpri =3D mpic_type_to_vecpri(flow_type);
+#endif=09
=20
- vold =3D mpic_irq_read(src, MPIC_IRQ_VECTOR_PRI);
- vnew =3D vold & ~(MPIC_VECPRI_POLARITY_MASK |
MPIC_VECPRI_SENSE_MASK);
+ vold =3D mpic_irq_read(src, MPIC_INFO(IRQ_VECTOR_PRI));
+ vnew =3D vold & ~(MPIC_INFO(VECPRI_POLARITY_MASK) |=20
+ MPIC_INFO(VECPRI_SENSE_MASK));
vnew |=3D vecpri;
if (vold !=3D vnew)
- mpic_irq_write(src, MPIC_IRQ_VECTOR_PRI, vnew);
+ mpic_irq_write(src, MPIC_INFO(IRQ_VECTOR_PRI), vnew);
=20
return 0;
}
@@ -797,18 +861,23 @@ #endif /* CONFIG_SMP */
mpic->isu_size =3D isu_size;
mpic->irq_count =3D irq_count;
mpic->num_sources =3D 0; /* so far */
+=09
+#ifdef CONFIG_MPIC_WEIRD
+ mpic->hw_set =3D mpic_infos[MPIC_GET_MOD_ID(flags)];
+#endif
=20
/* Map the global registers */
- mpic->gregs =3D ioremap(phys_addr + MPIC_GREG_BASE, 0x1000);
- mpic->tmregs =3D mpic->gregs + ((MPIC_TIMER_BASE - MPIC_GREG_BASE)
>> 2);
+ mpic->gregs =3D ioremap(phys_addr + MPIC_INFO(GREG_BASE), 0x1000);
+ mpic->tmregs =3D mpic->gregs +
+ ((MPIC_INFO(TIMER_BASE) - MPIC_INFO(GREG_BASE))
>> 2);
BUG_ON(mpic->gregs =3D=3D NULL);
=20
/* Reset */
if (flags & MPIC_WANTS_RESET) {
- mpic_write(mpic->gregs, MPIC_GREG_GLOBAL_CONF_0,
- mpic_read(mpic->gregs,
MPIC_GREG_GLOBAL_CONF_0)
+ mpic_write(mpic->gregs, MPIC_INFO(GREG_GLOBAL_CONF_0),
+ mpic_read(mpic->gregs,
MPIC_INFO(GREG_GLOBAL_CONF_0))
| MPIC_GREG_GCONF_RESET);
- while( mpic_read(mpic->gregs, MPIC_GREG_GLOBAL_CONF_0)
+ while( mpic_read(mpic->gregs,
MPIC_INFO(GREG_GLOBAL_CONF_0))
& MPIC_GREG_GCONF_RESET)
mb();
}
@@ -817,7 +886,7 @@ #endif /* CONFIG_SMP */
* MPICs, num sources as well. On ISU MPICs, sources are counted
* as ISUs are added
*/
- reg =3D mpic_read(mpic->gregs, MPIC_GREG_FEATURE_0);
+ reg =3D mpic_read(mpic->gregs, MPIC_INFO(GREG_FEATURE_0));
mpic->num_cpus =3D ((reg & MPIC_GREG_FEATURE_LAST_CPU_MASK)
>> MPIC_GREG_FEATURE_LAST_CPU_SHIFT) + 1;
if (isu_size =3D=3D 0)
@@ -826,16 +895,16 @@ #endif /* CONFIG_SMP */
=20
/* Map the per-CPU registers */
for (i =3D 0; i < mpic->num_cpus; i++) {
- mpic->cpuregs[i] =3D ioremap(phys_addr + MPIC_CPU_BASE +
- i * MPIC_CPU_STRIDE, 0x1000);
+ mpic->cpuregs[i] =3D ioremap(phys_addr +
MPIC_INFO(CPU_BASE) +
+ i * MPIC_INFO(CPU_STRIDE),
0x1000);
BUG_ON(mpic->cpuregs[i] =3D=3D NULL);
}
=20
/* Initialize main ISU if none provided */
if (mpic->isu_size =3D=3D 0) {
mpic->isu_size =3D mpic->num_sources;
- mpic->isus[0] =3D ioremap(phys_addr + MPIC_IRQ_BASE,
- MPIC_IRQ_STRIDE *
mpic->isu_size);
+ mpic->isus[0] =3D ioremap(phys_addr + MPIC_INFO(IRQ_BASE),
+ MPIC_INFO(IRQ_STRIDE) *
mpic->isu_size);
BUG_ON(mpic->isus[0] =3D=3D NULL);
}
mpic->isu_shift =3D 1 + __ilog2(mpic->isu_size - 1);
@@ -879,7 +948,8 @@ void __init mpic_assign_isu(struct mpic=20
=20
BUG_ON(isu_num >=3D MPIC_MAX_ISU);
=20
- mpic->isus[isu_num] =3D ioremap(phys_addr, MPIC_IRQ_STRIDE *
mpic->isu_size);
+ mpic->isus[isu_num] =3D ioremap(phys_addr,
+ MPIC_INFO(IRQ_STRIDE) *
mpic->isu_size);
if ((isu_first + mpic->isu_size) > mpic->num_sources)
mpic->num_sources =3D isu_first + mpic->isu_size;
}
@@ -904,14 +974,16 @@ void __init mpic_init(struct mpic *mpic)
printk(KERN_INFO "mpic: Initializing for %d sources\n",
mpic->num_sources);
=20
/* Set current processor priority to max */
- mpic_cpu_write(MPIC_CPU_CURRENT_TASK_PRI, 0xf);
+ mpic_cpu_write(MPIC_INFO(CPU_CURRENT_TASK_PRI), 0xf);
=20
/* Initialize timers: just disable them all */
for (i =3D 0; i < 4; i++) {
mpic_write(mpic->tmregs,
- i * MPIC_TIMER_STRIDE +
MPIC_TIMER_DESTINATION, 0);
+ i * MPIC_INFO(TIMER_STRIDE) +
+ MPIC_INFO(TIMER_DESTINATION), 0);
mpic_write(mpic->tmregs,
- i * MPIC_TIMER_STRIDE +
MPIC_TIMER_VECTOR_PRI,
+ i * MPIC_INFO(TIMER_STRIDE) +=20
+ MPIC_INFO(TIMER_VECTOR_PRI),
MPIC_VECPRI_MASK |
(MPIC_VEC_TIMER_0 + i));
}
@@ -940,21 +1012,23 @@ void __init mpic_init(struct mpic *mpic)
(8 << MPIC_VECPRI_PRIORITY_SHIFT);
=09
/* init hw */
- mpic_irq_write(i, MPIC_IRQ_VECTOR_PRI, vecpri);
- mpic_irq_write(i, MPIC_IRQ_DESTINATION,
+ mpic_irq_write(i, MPIC_INFO(IRQ_VECTOR_PRI), vecpri);
+ mpic_irq_write(i, MPIC_INFO(IRQ_DESTINATION),
1 << hard_smp_processor_id());
}
=09
/* Init spurrious vector */
- mpic_write(mpic->gregs, MPIC_GREG_SPURIOUS, MPIC_VEC_SPURRIOUS);
+ mpic_write(mpic->gregs, MPIC_INFO(GREG_SPURIOUS),
MPIC_VEC_SPURRIOUS);
=20
- /* Disable 8259 passthrough */
- mpic_write(mpic->gregs, MPIC_GREG_GLOBAL_CONF_0,
- mpic_read(mpic->gregs, MPIC_GREG_GLOBAL_CONF_0)
+ /* Disable 8259 passthrough, if supported */
+#ifndef CONFIG_MPIC_WEIRD
+ mpic_write(mpic->gregs, MPIC_INFO(GREG_GLOBAL_CONF_0),
+ mpic_read(mpic->gregs, MPIC_INFO(GREG_GLOBAL_CONF_0))
| MPIC_GREG_GCONF_8259_PTHROU_DIS);
+#endif
=20
/* Set current processor priority to 0 */
- mpic_cpu_write(MPIC_CPU_CURRENT_TASK_PRI, 0);
+ mpic_cpu_write(MPIC_INFO(CPU_CURRENT_TASK_PRI), 0);
}
=20
void __init mpic_set_clk_ratio(struct mpic *mpic, u32 clock_ratio)
@@ -997,9 +1071,9 @@ void mpic_irq_set_priority(unsigned int=20
mpic_ipi_write(src - MPIC_VEC_IPI_0,
reg | (pri <<
MPIC_VECPRI_PRIORITY_SHIFT));
} else {
- reg =3D mpic_irq_read(src, MPIC_IRQ_VECTOR_PRI)
+ reg =3D mpic_irq_read(src, MPIC_INFO(IRQ_VECTOR_PRI))
& ~MPIC_VECPRI_PRIORITY_MASK;
- mpic_irq_write(src, MPIC_IRQ_VECTOR_PRI,
+ mpic_irq_write(src, MPIC_INFO(IRQ_VECTOR_PRI),
reg | (pri <<
MPIC_VECPRI_PRIORITY_SHIFT));
}
spin_unlock_irqrestore(&mpic_lock, flags);
@@ -1017,7 +1091,7 @@ unsigned int mpic_irq_get_priority(unsig
if (is_ipi)
reg =3D mpic_ipi_read(src =3D MPIC_VEC_IPI_0);
else
- reg =3D mpic_irq_read(src, MPIC_IRQ_VECTOR_PRI);
+ reg =3D mpic_irq_read(src, MPIC_INFO(IRQ_VECTOR_PRI));
spin_unlock_irqrestore(&mpic_lock, flags);
return (reg & MPIC_VECPRI_PRIORITY_MASK) >>
MPIC_VECPRI_PRIORITY_SHIFT;
}
@@ -1043,12 +1117,12 @@ #ifdef CONFIG_SMP
*/
if (distribute_irqs) {
for (i =3D 0; i < mpic->num_sources ; i++)
- mpic_irq_write(i, MPIC_IRQ_DESTINATION,
- mpic_irq_read(i, MPIC_IRQ_DESTINATION) |
msk);
+ mpic_irq_write(i, MPIC_INFO(IRQ_DESTINATION),
+ mpic_irq_read(i,
MPIC_INFO(IRQ_DESTINATION)) | msk);
}
=20
/* Set current processor priority to 0 */
- mpic_cpu_write(MPIC_CPU_CURRENT_TASK_PRI, 0);
+ mpic_cpu_write(MPIC_INFO(CPU_CURRENT_TASK_PRI), 0);
=20
spin_unlock_irqrestore(&mpic_lock, flags);
#endif /* CONFIG_SMP */
@@ -1058,7 +1132,7 @@ int mpic_cpu_get_priority(void)
{
struct mpic *mpic =3D mpic_primary;
=20
- return mpic_cpu_read(MPIC_CPU_CURRENT_TASK_PRI);
+ return mpic_cpu_read(MPIC_INFO(CPU_CURRENT_TASK_PRI));
}
=20
void mpic_cpu_set_priority(int prio)
@@ -1066,7 +1140,7 @@ void mpic_cpu_set_priority(int prio)
struct mpic *mpic =3D mpic_primary;
=20
prio &=3D MPIC_CPU_TASKPRI_MASK;
- mpic_cpu_write(MPIC_CPU_CURRENT_TASK_PRI, prio);
+ mpic_cpu_write(MPIC_INFO(CPU_CURRENT_TASK_PRI), prio);
}
=20
/*
@@ -1088,11 +1162,11 @@ void mpic_teardown_this_cpu(int secondar
=20
/* let the mpic know we don't want intrs. */
for (i =3D 0; i < mpic->num_sources ; i++)
- mpic_irq_write(i, MPIC_IRQ_DESTINATION,
- mpic_irq_read(i, MPIC_IRQ_DESTINATION) & ~msk);
+ mpic_irq_write(i, MPIC_INFO(IRQ_DESTINATION),
+ mpic_irq_read(i, MPIC_INFO(IRQ_DESTINATION)) &
~msk);
=20
/* Set current processor priority to max */
- mpic_cpu_write(MPIC_CPU_CURRENT_TASK_PRI, 0xf);
+ mpic_cpu_write(MPIC_INFO(CPU_CURRENT_TASK_PRI), 0xf);
=20
spin_unlock_irqrestore(&mpic_lock, flags);
}
@@ -1108,7 +1182,8 @@ #ifdef DEBUG_IPI
DBG("%s: send_ipi(ipi_no: %d)\n", mpic->name, ipi_no);
#endif
=20
- mpic_cpu_write(MPIC_CPU_IPI_DISPATCH_0 + ipi_no * 0x10,
+ mpic_cpu_write(MPIC_INFO(CPU_IPI_DISPATCH_0) +
+ ipi_no * MPIC_INFO(CPU_IPI_DISPATCH_STRIDE),
mpic_physmask(cpu_mask &
cpus_addr(cpu_online_map)[0]));
}
=20
@@ -1116,7 +1191,7 @@ unsigned int mpic_get_one_irq(struct mpi
{
u32 src;
=20
- src =3D mpic_cpu_read(MPIC_CPU_INTACK) & MPIC_VECPRI_VECTOR_MASK;
+ src =3D mpic_cpu_read(MPIC_INFO(CPU_INTACK)) &
MPIC_INFO(VECPRI_VECTOR_MASK);
#ifdef DEBUG_LOW
DBG("%s: get_one_irq(): %d\n", mpic->name, src);
#endif
diff --git a/include/asm-powerpc/mpic.h b/include/asm-powerpc/mpic.h
index eb241c9..faebdf2 100644
--- a/include/asm-powerpc/mpic.h
+++ b/include/asm-powerpc/mpic.h
@@ -41,6 +41,7 @@ #define MPIC_GREG_IPI_VECTOR_PRI_0 0x000
#define MPIC_GREG_IPI_VECTOR_PRI_1 0x000b0
#define MPIC_GREG_IPI_VECTOR_PRI_2 0x000c0
#define MPIC_GREG_IPI_VECTOR_PRI_3 0x000d0
+#define MPIC_GREG_IPI_STRIDE 0x10
#define MPIC_GREG_SPURIOUS 0x000e0
#define MPIC_GREG_TIMER_FREQ 0x000f0
=20
@@ -68,6 +69,7 @@ #define MPIC_CPU_IPI_DISPATCH_0 0x00040
#define MPIC_CPU_IPI_DISPATCH_1 0x00050
#define MPIC_CPU_IPI_DISPATCH_2 0x00060
#define MPIC_CPU_IPI_DISPATCH_3 0x00070
+#define MPIC_CPU_IPI_DISPATCH_STRIDE 0x00010
#define MPIC_CPU_CURRENT_TASK_PRI 0x00080
#define MPIC_CPU_TASKPRI_MASK 0x0000000f
#define MPIC_CPU_WHOAMI 0x00090
@@ -114,6 +116,103 @@ #define MPIC_VEC_TIMER_2 249
#define MPIC_VEC_TIMER_1 248
#define MPIC_VEC_TIMER_0 247
=20
+#ifdef CONFIG_MPIC_WEIRD
+/*
+ * Tsi108 implementation of MPIC has many differences from the original
one
+ */
+
+/*
+ * Global registers
+ */
+
+#define TSI108_GREG_BASE 0x00000
+#define TSI108_GREG_FEATURE_0 0x00000
+#define TSI108_GREG_GLOBAL_CONF_0 0x00004
+#define TSI108_GREG_VENDOR_ID 0x0000c
+#define TSI108_GREG_IPI_VECTOR_PRI_0 0x00204 /* Doorbell 0 */
+#define TSI108_GREG_IPI_STRIDE 0x0c
+#define TSI108_GREG_SPURIOUS 0x00010
+#define TSI108_GREG_TIMER_FREQ 0x00014
+
+/*
+ * Timer registers
+ */
+#define TSI108_TIMER_BASE 0x0030
+#define TSI108_TIMER_STRIDE 0x10
+#define TSI108_TIMER_CURRENT_CNT 0x00000
+#define TSI108_TIMER_BASE_CNT 0x00004
+#define TSI108_TIMER_VECTOR_PRI 0x00008
+#define TSI108_TIMER_DESTINATION 0x0000c
+
+/*
+ * Per-Processor registers
+ */
+#define TSI108_CPU_BASE 0x00300
+#define TSI108_CPU_STRIDE 0x00040
+#define TSI108_CPU_IPI_DISPATCH_0 0x00200
+#define TSI108_CPU_IPI_DISPATCH_STRIDE 0x00000
+#define TSI108_CPU_CURRENT_TASK_PRI 0x00000
+#define TSI108_CPU_WHOAMI 0xffffffff
+#define TSI108_CPU_INTACK 0x00004
+#define TSI108_CPU_EOI 0x00008
+
+/*
+ * Per-source registers
+ */
+#define TSI108_IRQ_BASE 0x00100
+#define TSI108_IRQ_STRIDE 0x00008
+#define TSI108_IRQ_VECTOR_PRI 0x00000
+#define TSI108_VECPRI_VECTOR_MASK 0x000000ff
+#define TSI108_VECPRI_POLARITY_POSITIVE 0x01000000
+#define TSI108_VECPRI_POLARITY_NEGATIVE 0x00000000
+#define TSI108_VECPRI_SENSE_LEVEL 0x02000000
+#define TSI108_VECPRI_SENSE_EDGE 0x00000000
+#define TSI108_VECPRI_POLARITY_MASK 0x01000000
+#define TSI108_VECPRI_SENSE_MASK 0x02000000
+#define TSI108_IRQ_DESTINATION 0x00004
+
+/* weird mpic variable index in the HW info array */
+enum MPIC_WEIRD_INDEX {
+ INDEX_GREG_BASE =3D 0, /* Offset of global registers from MPIC
base */
+ INDEX_GREG_FEATURE_0, /* FRR0 offset from base */
+ INDEX_GREG_GLOBAL_CONF_0, /* Global Config register offset from
base */
+ INDEX_GREG_VENDOR_ID, /* VID register offset from base */
+ INDEX_GREG_IPI_VECTOR_PRI_0, /* IPI Vector/Priority Registers
*/
+ INDEX_GREG_IPI_STRIDE, /* IPI Vector/Priority Registers
spacing */
+ INDEX_GREG_SPURIOUS, /* Spurious Vector Register */
+ INDEX_GREG_TIMER_FREQ, /* Global Timer Frequency Reporting
Register */
+
+ INDEX_TIMER_BASE, /* Global Timer Registers base
*/
+ INDEX_TIMER_STRIDE, /* Global Timer Registers
spacing */
+ INDEX_TIMER_CURRENT_CNT, /* Global Timer Current Count
Register */
+ INDEX_TIMER_BASE_CNT, /* Global Timer Base Count
Register */
+ INDEX_TIMER_VECTOR_PRI, /* Global Timer Vector/Priority
Register */
+ INDEX_TIMER_DESTINATION, /* Global Timer Destination
Register */
+
+ INDEX_CPU_BASE, /* Offset of cpu base */
+ INDEX_CPU_STRIDE, /* Cpu register spacing*/
+ INDEX_CPU_IPI_DISPATCH_0, /* IPI 0 Dispatch Command
Register */
+ INDEX_CPU_IPI_DISPATCH_STRIDE, /* IPI Dispatch spacing */
+ INDEX_CPU_CURRENT_TASK_PRI,/* Processor Current Task Priority
Register */
+ INDEX_CPU_WHOAMI, /* Who Am I Register */
+ INDEX_CPU_INTACK, /* Interrupt Acknowledge Register */
+ INDEX_CPU_EOI, /* End of Interrupt Register */
+
+ INDEX_IRQ_BASE, /* Interrupt registers base */
+ INDEX_IRQ_STRIDE, /* Interrupt registers spacing */
+ INDEX_IRQ_VECTOR_PRI, /* Interrupt Vector/Priority Register */
+ INDEX_VECPRI_VECTOR_MASK, /* Interrupt Vector Mask */
+ INDEX_VECPRI_POLARITY_POSITIVE, /* Interrupt Positive Polarity
bit */
+ INDEX_VECPRI_POLARITY_NEGATIVE, /* Interrupt Negative Polarity
bit */
+ INDEX_VECPRI_SENSE_LEVEL, /* Interrupt Level Sense bit */
+ INDEX_VECPRI_SENSE_EDGE, /* Interrupt edge Sense bit */
+ INDEX_VECPRI_POLARITY_MASK, /* Interrupt Polarity mask */
+ INDEX_VECPRI_SENSE_MASK, /* Interrupt sense mask */
+ INDEX_IRQ_DESTINATION, /* Interrupt Destination Register */
+ INDEX_MPIC_WEIRD_END /* Size of the hw info array */
+};
+#endif
+
#ifdef CONFIG_MPIC_BROKEN_U3
/* Fixup table entry */
struct mpic_irq_fixup
@@ -170,6 +269,11 @@ #endif
volatile u32 __iomem *tmregs;
volatile u32 __iomem *cpuregs[MPIC_MAX_CPUS];
volatile u32 __iomem *isus[MPIC_MAX_ISU];
+=09
+#ifdef CONFIG_MPIC_WEIRD
+ /* Pointer to HW info array */
+ u32 *hw_set;
+#endif
=20
/* link */
struct mpic *next;
@@ -189,6 +293,16 @@ #define MPIC_BROKEN_IPI
0x00000008
/* MPIC wants a reset */
#define MPIC_WANTS_RESET 0x00000010
=20
+#ifdef CONFIG_MPIC_WEIRD
+/* Spurious vector requires EOI */
+#define MPIC_SPV_EOI 0x00000020
+/* MPIC HW modification ID */
+#define MPIC_MOD_ID_MASK 0x00000f00
+#define MPIC_MOD_ID(val) (((val) << 8) &
MPIC_MOD_ID_MASK)
+#define MPIC_GET_MOD_ID(flags) (((flags) & MPIC_MOD_ID_MASK) >>
8)
+#define MPIC_ID_TSI108 0 /* Tsi108/109 PIC */
+#endif
+
/* Allocate the controller structure and setup the linux irq descs
* for the range if interrupts passed in. No HW initialization is
* actually performed.
--=20
1.4.0
^ permalink raw reply related
* Re: [PATCH 6/6] [RFC] POWERPC: generic CPM2 peripherals rehaul with cpm2_map mechanism
From: Vitaly Bordug @ 2006-08-22 10:13 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <44DE379C.5030901@ru.mvista.com>
On Sun, 13 Aug 2006 00:18:36 +0400
Sergei Shtylyov wrote:
> Hello.
>
> Vitaly Bordug wrote:
>
> > Incorporating the new way of cpm2 immr access, introduced in the
> > previous patch, into CPM2 peripheral devices (fs_enet and
> > cpm_uart). Both ppc and powerpc approved working( real actions
> > taken in powerpc only, ppc just has a wrapper to keep init stuff
> > consistent).
>
> > Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
>
> Hm, I got 4 rejects here. :-/
>
> > diff --git a/arch/ppc/platforms/mpc8272ads_setup.c
> > b/arch/ppc/platforms/mpc8272ads_setup.c index 2a35fe2..d5d36c3
> > 100644 --- a/arch/ppc/platforms/mpc8272ads_setup.c
> > +++ b/arch/ppc/platforms/mpc8272ads_setup.c
> > @@ -103,7 +103,7 @@ static struct fs_platform_info mpc82xx_e
> > },
> > };
> >
> > -static void init_fcc1_ioports(void)
> > +static void init_fcc1_ioports(struct fs_platform_info*)
> > {
> > struct io_port *io;
> > u32 tempval;
>
> This one get rejected as well.
>
> > diff --git a/arch/ppc/platforms/mpc866ads_setup.c
> > b/arch/ppc/platforms/mpc866ads_setup.c index e12cece..5f130dc 100644
> > --- a/arch/ppc/platforms/mpc866ads_setup.c
> > +++ b/arch/ppc/platforms/mpc866ads_setup.c
> [...]
> > @@ -194,7 +194,7 @@ static void setup_scc1_ioports(void)
> >
> > }
> >
> > -static void setup_smc1_ioports(void)
> > +static void setup_smc1_ioports(struct fs_uart_platform_info*)
> > {
> > immap_t *immap = (immap_t *) IMAP_ADDR;
> > unsigned *bcsr_io;
>
> And this one...
>
> > diff --git a/arch/ppc/platforms/mpc885ads_setup.c
> > b/arch/ppc/platforms/mpc885ads_setup.c index 5dfa4e6..bf388ed 100644
> > --- a/arch/ppc/platforms/mpc885ads_setup.c
> > +++ b/arch/ppc/platforms/mpc885ads_setup.c
> [...]
> > @@ -315,7 +315,7 @@ static void __init mpc885ads_fixup_scc_e
> > mpc885ads_fixup_enet_pdata(pdev, fsid_scc1 + pdev->id - 1);
> > }
> >
> > -static void setup_smc1_ioports(void)
> > +static void setup_smc1_ioports(struct fs_uart_platform_info*)
> > {
> > immap_t *immap = (immap_t *) IMAP_ADDR;
> > unsigned *bcsr_io;
>
> And this...
>
> > diff --git a/include/asm-ppc/cpm2.h b/include/asm-ppc/cpm2.h
> > index bd6623a..220cc2d 100644
> > --- a/include/asm-ppc/cpm2.h
> > +++ b/include/asm-ppc/cpm2.h
> > @@ -1196,5 +1196,58 @@ #define FCC1_MEM_OFFSET FCC_MEM_OFFSET(0
> > #define FCC2_MEM_OFFSET FCC_MEM_OFFSET(1)
> > #define FCC3_MEM_OFFSET FCC_MEM_OFFSET(2)
> >
> > +/* Clocks and GRG's */
> > +
> > +enum cpm_clk_dir {
> > + CPM_CLK_RX,
> > + CPM_CLK_TX,
> > + CPM_CLK_RTX
> > +};
> > +
> > +enum cpm_clk_target {
> > + CPM_CLK_SCC1,
> > + CPM_CLK_SCC2,
> > + CPM_CLK_SCC3,
> > + CPM_CLK_SCC4,
> > + CPM_CLK_FCC1,
> > + CPM_CLK_FCC2,
> > + CPM_CLK_FCC3
> > +};
> > +
> > +enum cpm_clk {
> > + CPM_CLK_NONE = 0,
> > + CPM_BRG1, /* Baud Rate Generator 1 */
> > + CPM_BRG2, /* Baud Rate Generator 2 */
> > + CPM_BRG3, /* Baud Rate Generator 3 */
> > + CPM_BRG4, /* Baud Rate Generator 4 */
> > + CPM_BRG5, /* Baud Rate Generator 5 */
> > + CPM_BRG6, /* Baud Rate Generator 6 */
> > + CPM_BRG7, /* Baud Rate Generator 7 */
> > + CPM_BRG8, /* Baud Rate Generator 8 */
> > + CPM_CLK1, /* Clock 1 */
> > + CPM_CLK2, /* Clock 2 */
> > + CPM_CLK3, /* Clock 3 */
> > + CPM_CLK4, /* Clock 4 */
> > + CPM_CLK5, /* Clock 5 */
> > + CPM_CLK6, /* Clock 6 */
> > + CPM_CLK7, /* Clock 7 */
> > + CPM_CLK8, /* Clock 8 */
> > + CPM_CLK9, /* Clock 9 */
> > + CPM_CLK10, /* Clock 10 */
> > + CPM_CLK11, /* Clock 11 */
> > + CPM_CLK12, /* Clock 12 */
> > + CPM_CLK13, /* Clock 13 */
> > + CPM_CLK14, /* Clock 14 */
> > + CPM_CLK15, /* Clock 15 */
> > + CPM_CLK16, /* Clock 16 */
> > + CPM_CLK17, /* Clock 17 */
> > + CPM_CLK18, /* Clock 18 */
> > + CPM_CLK19, /* Clock 19 */
> > + CPM_CLK20, /* Clock 20 */
> > + CPM_CLK_DUMMY
> > +};
> > +
> > +extern int cpm2_clk_setup(enum cpm_clk_target target, int clock,
> > int mode); +
> > #endif /* __CPM2__ */
> > #endif /* __KERNEL__ */
>
> And this file refuses to be patched altogether...
> With these rejects fixed, everything seems fine, though.
The same note - the mis-sync because preceding fs_enet overhaul and update are missing before the stuff above.
Taking into accordance Kumar's opinion to put this on hold until the next kernel release, the whole thing should settle down pretty shortly hereby before upstream merge. Meanwhile, we'll catch up the issues and scrub
the code in general. Hopefully, with netdev things merged, we'll get back to the only powerpc.git base which will simplify following them up.
>
> WBR, Sergei
>
>
^ permalink raw reply
* RE: ML40X, ppc 405 crash
From: alva @ 2006-08-22 10:52 UTC (permalink / raw)
To: 'Wade Maxfield', 'ppc'
In-Reply-To: <45a1b53e0608211434n2c61167i8952ab8737f102cc@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 8053 bytes --]
So can u access your NFS mapped partition? If you can access every FILEs
on the partition, running updatedb ought to index the NFS partition
also. Then “locate fixdep” is just to find the local indexed database
and display the matched result --- I just don’t understand the problem.
Please state more what have you done in order to let us help you.
-----Original Message-----
From: linuxppc-embedded-bounces+vows_siu=yahoo.com.hk@ozlabs.org
[mailto:linuxppc-embedded-bounces+vows_siu=yahoo.com.hk@ozlabs.org] On
Behalf Of Wade Maxfield
Sent: Tuesday, August 22, 2006 5:34 AM
To: ppc
Subject: ML40X, ppc 405 crash
I was running NFS on ML40X. I did a "updatedb" and then immediately,
"locate fixdep"
I got the following crash
root@ml403:/home/moduletest# updatedb
locate fixdep
eth0: Could not transmit buffer.
eth0: Could not transmit buffer.
eth0: Could not transmit buffer.
Oops: kernel access of bad area, sig: 11 [#1]
PREEMPT
NIP: C01D0F74 LR: C01D0910 SP: C28B1930 REGS: c28b1880 TRAP: 0300 Not
tainted
MSR: 00029030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00000004, DSISR: 00800000
TASK = c0b034c0[5097] 'frcode' THREAD: c28b0000
Last syscall: 234
GPR00: 00000000 C28B1930 C0B034C0 C35E3200 C03CC380 C276E810 000005E8
C3CE8880
GPR08: 00000002 00000000 C3CE890C 00000000 33003599 10018E04 100C3208
C02DCE08
GPR16: C00DB1CC C02DCE08 00000002 0000000A C28B1DF8 C02E0000 C02A0000
C3A30940
GPR24: 00000000 00000000 00000000 C3A30940 00000000 C35E3200 C3CE8880
C03A8800
NIP [c01d0f74] pfifo_fast_dequeue+0x40/0x74
LR [c01d0910] qdisc_restart+0x30/0x2b4
Call trace:
[c01c1e94] dev_queue_xmit+0x264/0x318
[c01dd8dc] ip_finish_output+0x140/0x2cc
[c01dddb0] ip_queue_xmit+0x348/0x53c
[c01ef628] tcp_transmit_skb+0x324/0x7f8
[c01f05fc] tcp_write_xmit+0x14c/0x31c
[c01ed360] __tcp_data_snd_check+0xc8/0xfc
[c01ed9a4] tcp_rcv_established+0x2c0/0x8ac
[c01f7250] tcp_v4_do_rcv+0x184/0x374
[c01f7d9c] tcp_v4_rcv+0x95c/0xa4c
[c01da000] ip_local_deliver+0x120/0x298
[c01da86c] ip_rcv+0x400/0x508
[c01c2614] netif_receive_skb+0x24c/0x2fc
[c01c276c] process_backlog+0xa8/0x1a0
[c01c2908] net_rx_action+0xa4/0x1cc
[c001bef4] ___do_softirq+0x7c/0x114
Kernel panic - not syncing: Aiee, killing interrupt handler!
<0>Rebooting in 180 seconds..
------------------------------------------------------------------------
------------------------------------------------------------------------
-----
Here is the kernel build and boot information. (I use the demo compact
flash disk image shipped with the ml403 as an intermediate. I've not yet
been able to get a small enough build to fit on 412 meg using your
tools.)
Linux version 2.6.10_mvl401-ml40x (HYPERLINK
"mailto:root@localhost.localdomain"root@localhost.localdomain) (gcc
version 3.4.3 (MontaV
ista 3.4.3-25.0.107.0601076 2006-07-21)) #1 Fri Aug 18 14:43:45 CDT 2006
Xilinx ML40x Reference System (Virtex-4 FX)
Port by MontaVista Software, Inc. (HYPERLINK
"mailto:source@mvista.com"source@mvista.com)
Built 1 zonelists
Kernel command line: console=ttyS0,115200 ip=on root=/dev/xsysace2 rw
Xilinx INTC #0 at 0xD1000FC0 mapped to 0xFDFFEFC0
PID hash table entries: 512 (order: 9, 8192 bytes)
hr_time_init: arch_to_nsec = 6990506, nsec_to_arch = 1288490158
Console: colour dummy device 80x25
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 61824k available (2244k kernel code, 640k data, 140k init, 0k
highmem)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
spawn_desched_task(00000000)
desched cpu_callback 3/00000000
ksoftirqd started up.
desched cpu_callback 2/00000000
desched thread 0 started up.
NET: Registered protocol family 16
Registering platform device 'xilinx_emac.0'. Parent at platform
Registering platform device 'xilinx_fb.0'. Parent at platform
Registering platform device 'xilinx_sysace.0'. Parent at platform
Registering platform device 'xilinx_iic.0'. Parent at platform
Registering platform device 'xilinx_gpio.0'. Parent at platform
Registering platform device 'xilinx_gpio.1'. Parent at platform
Registering platform device 'xilinx_gpio.2'. Parent at platform
Registering platform device 'xilinx_ps2.0'. Parent at platform
Registering platform device 'xilinx_ps2.1'. Parent at platform
Installing knfsd (copyright (C) 1996 HYPERLINK
"mailto:okir@monad.swb.de"okir@monad.swb.de).
Console: switching to colour frame buffer device 80x30
xgpio #0 at 0x90000000 mapped to 0xC505C000
xgpio #1 at 0x90001000 mapped to 0xC505E000
xgpio #2 at 0x90002000 mapped to 0xC5060000
xilinx_ps2 #0 at 0xA9000000 mapped to 0xC5062000
xilinx_ps2 #1 at 0xA9001000 mapped to 0xC5064000
Serial: 8250/16550 driver $Revision: 1.90 $ 5 ports, IRQ sharing
disabled
Registering platform device 'serial8250'. Parent at platform
ttyS0 at MMIO 0x0 (irq = 9) is a 16450
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
loop: loaded (max 8 devices)
elevator: using anticipatory as default io scheduler
System ACE at 0xCF000000 mapped to 0xC5066000, irq=3, 500472KB
xsysace: xsysace1 xsysace2
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
NET: Registered protocol family 24
xemac 0: using fifo mode.
eth0: Xilinx EMAC #0 at 0x60000000 mapped to 0xC5068000, irq=0
i2c /dev entries driver
xilinx_iic.0 #0 at 0xA8000000 mapped to 0xC506E000, irq=6
mice: PS/2 mouse device common for all mice
atkbd.c: keyboard reset failed on xilinxps2/serio0
atkbd.c: keyboard reset failed on xilinxps2/serio1
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 8192)
NET: Registered protocol family 1
NET: Registered protocol family 17
Sending DHCP requests ., OK
IP-Config: Got DHCP answer from HYPERLINK "http://0.0.0.0"0.0.0.0, my
address is HYPERLINK "http://172.17.6.49"172.17.6.49
IP-Config: Complete:
device=eth0, addr=HYPERLINK "http://172.17.6.49" 172.17.6.49,
mask=HYPERLINK "http://255.255.254.0"255.255.254.0, gw=HYPERLINK
"http://172.17.7.254"172.17.7.254,
host=HYPERLINK "http://172.17.6.49"172.17.6.49, domain=HYPERLINK
"http://precisiondrilling.com" precisiondrilling.com, nis-domain=(none),
bootserver=HYPERLINK "http://0.0.0.0"0.0.0.0, rootserver=HYPERLINK
"http://0.0.0.0"0.0.0.0, rootpath=
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 140k init
INIT: version 2.78 booting
Activating swap...
Checking all file systems...
fsck 1.27 (8-Mar-2002)
Calculating module dependencies... depmod: QM_MODULES: Function not
implemented
done.
Loading modules:
modprobe: QM_MODULES: Function not implemented
Mounting local filesystems...
nothing was mounted
Cleaning: /etc/network/ifstate.
Setting up IP spoofing protection: rp_filter.
Disable TCP/IP Explicit Congestion Notification: done.
Configuring network interfaces: done.
Starting portmap daemon: portmap.
Starting dhcpcd on eth0
Running ntpdate to synchronize clock.
Cleaning: /tmp /var/lock /var/rundhcpcd[775]: dhcpConfig: ioctl
SIOCADDRT: File exists
.
INIT: Entering runlevel: 3
Starting kernel log daemon: klogd.
Starting system log daemon: syslogd.
Hostname: ml403.
Creating barrier for shutdown
Starting X11 session for user 'linux'
Welcome to the ML403 Evaluation Board
(C) 2004 Xilinx, Inc - Systems Engineering Group
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.11.4/424 - Release Date:
2006/8/21
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.11.4/424 - Release Date:
2006/8/21
[-- Attachment #2: Type: text/html, Size: 11821 bytes --]
^ permalink raw reply
* Re: [PATCH 4/6] POWERPC: add support of mpc8560 eval board
From: Vitaly Bordug @ 2006-08-22 11:03 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <6A1F08CA-2FAE-4BE6-82BF-30F35053483C@freescale.com>
On Thu, 17 Aug 2006 15:04:11 -0500
Andy Fleming wrote:
>
> On Aug 11, 2006, at 19:10, Vitaly Bordug wrote:
>
>
> >
> > diff --git a/arch/powerpc/boot/dts/mpc8560ads.dts b/arch/powerpc/
> > boot/dts/mpc8560ads.dts
> > new file mode 100644
> > index 0000000..f6ccb99
> > --- /dev/null
> > +++ b/arch/powerpc/boot/dts/mpc8560ads.dts
> > @@ -0,0 +1,310 @@
> >
> > +
> > + ethernet@24000 {
> > + device_type = "network";
> > + model = "TSEC";
> > + compatible = "gianfar";
> > + reg = <24000 1000>;
> > + address = [ 00 00 0C 00 00 FD ];
> > + interrupts = <d 0 e 0 12 0>;
>
> Your sense values are wrong here. Should be "2"
> ie - interrupts = <d 2 e 2 12 2>;
>
Here and below:
those were derived from the original dts's an since it worked "as it is" I didn't fairly care atm.
It is clear, that the spec itself is 100% non-contradictory and consistent, so my main concern was to make-it-work. And, those stuff seems not to be taken into account (may be wrong `tho, haven't really looked into,
Ben ?
)
>
> > + interrupt-parent = <40000>;
> > + phy-handle = <2452000>;
> > + };
> > +
> > + ethernet@25000 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + device_type = "network";
> > + model = "TSEC";
> > + compatible = "gianfar";
> > + reg = <25000 1000>;
> > + address = [ 00 00 0C 00 01 FD ];
> > + interrupts = <13 0 14 0 18 0>;
>
>
> Here, too
>
ditto
> > + pic@40000 {
> > + linux,phandle = <40000>;
> > + interrupt-controller;
> > + #address-cells = <0>;
> > + #interrupt-cells = <2>;
> > + reg = <40000 20100>;
> > + built-in;
> > + device_type = "mpic";
>
> This is wrong. It should be "open-pic";
>
I am recalling nogo with open-pic here... I agree with Segher, we'll make this 100% clear and follow that
further.
> > + };
> > +
> > + cpm@e0000000 {
>
> I'm going to leave this to others to discuss, since I'm not a CPM
> expert. But you may want to double-check your interrupt sense
> values, and make sure the encodings are right.
>
>
I am completely open to the comments here..
And my guess is that the irq thing should be clarified and re-synced
with spec. All I can say currently - it works for me so may be used at least as reference
for the stuff alike. If the cpm2 description got settle down, I'll update the spec in relevance
and hope to make other inconsistencies (irq-related, obsoleted stuff etc. ) addressed.
> > diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/
> > platforms/85xx/Kconfig
> > index 454fc53..3d440de 100644
> > --- a/arch/powerpc/platforms/85xx/Kconfig
> > +++ b/arch/powerpc/platforms/85xx/Kconfig
> > @@ -11,6 +11,12 @@ config MPC8540_ADS
> > help
> > This option enables support for the MPC 8540 ADS board
> >
> > +config MPC8560_ADS
> > + bool "Freescale MPC8560 ADS"
> > + select DEFAULT_UIMAGE
> > + help
> > + This option enables support for the MPC 8560 ADS board
> > +
>
>
> If at all possible, I think that the 8560 shouldn't be a config
> option. It's just an 85xx ADS, and use the dts to distinguish. But
> keeping separate defconfigs seems like a good idea.
>
>
Agreed.
>
> > diff --git a/arch/powerpc/platforms/85xx/mpc8540_ads.h b/arch/
> > powerpc/platforms/85xx/mpc8540_ads.h
> > index c0d56d2..670abaf 100644
> > --- a/arch/powerpc/platforms/85xx/mpc8540_ads.h
> > +++ b/arch/powerpc/platforms/85xx/mpc8540_ads.h
> > @@ -6,6 +6,10 @@
> > * Maintainer: Kumar Gala <kumar.gala@freescale.com>
> > *
> > * Copyright 2004 Freescale Semiconductor Inc.
> > + *
> > + * 2006 (c) MontaVista Software, Inc.
> > + * Vitaly Bordug <vbordug@ru.mvista.com>
> > + * Merged to arch/powerpc
> > *
> > * 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
> > @@ -24,10 +28,10 @@ #define BCSR_ADDR
> > ((uint)0xf8000000) #define BCSR_SIZE ((uint)(32 *
> > 1024))
> >
> > /* PCI interrupt controller */
> > -#define PIRQA MPC85xx_IRQ_EXT1
> > -#define PIRQB MPC85xx_IRQ_EXT2
> > -#define PIRQC MPC85xx_IRQ_EXT3
> > -#define PIRQD MPC85xx_IRQ_EXT4
> > +#define PIRQA 49
> > +#define PIRQB 50
> > +#define PIRQC 51
> > +#define PIRQD 52
>
>
> Wha?! I can't imagine any reason this change would be acceptable.
> Especially since your patch needs to apply against a tree with the
> new irq code, which doesn't need such hard-coded values. We get
> them from the dts.
>
>
Tend to be cleanup_miss, the same as note below.
> > diff --git a/arch/powerpc/platforms/85xx/mpc8560_ads.h b/arch/
> > powerpc/platforms/85xx/mpc8560_ads.h
>
> This file should be able to go away, now, and get merged with
> mpc8540_ads.h. While we're at it, mpc8540_ads.h should become
> mpc85xx_ads.h
>
>
> > diff --git a/arch/powerpc/platforms/85xx/mpc85xx.h b/arch/powerpc/
> > platforms/85xx/mpc85xx.h
> > index b44db62..4fe613e 100644
> > --- a/arch/powerpc/platforms/85xx/mpc85xx.h
> > +++ b/arch/powerpc/platforms/85xx/mpc85xx.h
> > @@ -16,3 +16,4 @@
> >
> > extern void mpc85xx_restart(char *);
> > extern int add_bridge(struct device_node *dev);
> > +extern void mpc85xx_pcibios_fixup(void);
>
> Why is this being "exported"?
>
To make it compile :) will be fixed in the reordering in the next respin.
> > diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ads.c b/arch/
> > powerpc/platforms/85xx/mpc85xx_ads.c
> > index d0cfcdb..974e035 100644
> > --- a/arch/powerpc/platforms/85xx/mpc85xx_ads.c
> > +++ b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
> > @@ -4,6 +4,10 @@
> > * Maintained by Kumar Gala (see MAINTAINERS for contact
> > information) *
> > * Copyright 2005 Freescale Semiconductor Inc.
> > + *
> > + * 2006 (c) MontaVista Software, Inc.
> > + * Vitaly Bordug <vbordug@ru.mvista.com>
> > + * Merged to arch/powerpc
>
> This comment is confusing. This file was already "merged".
> Regardless, I believe there's a general policy against putting
> change logs in the header.
>
The last line is extra here - copy-paste thing. I added the upper line to make it clear that though I've created the file(s) in powerpc/, that is only "merge" thing, which is not quite right for this particular file, sorry about that.
>
> >
> > @@ -47,19 +59,19 @@ static u_char mpc85xx_ads_openpic_initse
> > MPC85XX_INTERNAL_IRQ_SENSES,
> > 0x0, /* External 0: */
> > #if defined(CONFIG_PCI)
> > - (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext
> > 1: PCI slot 0 */
> > - (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext
> > 2: PCI slot 1 */
> > - (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext
> > 3: PCI slot 2 */
> > - (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext
> > 4: PCI slot 3 */
> > + IRQ_TYPE_LEVEL_LOW, /* Ext 1: PCI slot 0 */
> > + IRQ_TYPE_LEVEL_LOW, /* Ext 2: PCI slot 1 */
> > + IRQ_TYPE_LEVEL_LOW, /* Ext 3: PCI slot 2 */
> > + IRQ_TYPE_LEVEL_LOW, /* Ext 4: PCI slot 3 */
> > #else
> > 0x0, /* External 1: */
> > 0x0, /* External 2: */
> > 0x0, /* External 3: */
> > 0x0, /* External 4: */
> > #endif
> > - (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /*
> > External 5: PHY */
> > + IRQ_TYPE_LEVEL_LOW, /* External 5: PHY */
> > 0x0, /* External 6: */
> > - (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /*
> > External 7: PHY */
> > + IRQ_TYPE_LEVEL_LOW, /* External 7: PHY */
> > 0x0, /* External 8: */
> > 0x0, /* External 9: */
> > 0x0, /* External 10: */
>
>
> This isn't how interrupt senses are supposed to be done now. They
> should be gotten from the device tree. This whole array can be
> deleted.
>
>
Here and below about PCI irq stuff - OK.
> > @@ -74,40 +86,109 @@ #ifdef CONFIG_PCI
> > int
> > mpc85xx_map_irq(struct pci_dev *dev, unsigned char idsel,
> > unsigned char pin)
> > {
>
> This whole function can be deleted.
>
> > + struct device_node * pci_OF;
> > + struct irq_map_of_mask {
> > + unsigned int idsel_msk;
> > + unsigned int slot_msk;
> > + unsigned int offset_irqs_msk;
> > + unsigned int line_msk;
> > + } *ip;
> > + int i;
> > + struct irq_of_table_s {
> > + struct {
> > + unsigned int idsel;
> > + unsigned int slot;
> > + unsigned int offset_irqs;
> > + unsigned int line;
> > + unsigned int parent;
> > + unsigned int table_item;
> > + unsigned int ext_irqs;
> > + } idsel[1];
> > + }* irq_of_table;
> > +
> > +
> > + pci_OF = of_find_node_by_type(NULL, "pci");
> > + if (pci_OF) {
> > + unsigned long max_idsel = 0;
> > + unsigned long min_idsel = 0xffffffff;
> > + unsigned long irqs_per_slot = 0;
> > + unsigned int idsel_ = 0;
> > + unsigned int line;
> > + unsigned int* irq;
> > + unsigned int ip_len;
> > + unsigned int irq_table_len;
> > + unsigned int irq_len;
> > +
> > + ip = (struct irq_map_of_mask*)get_property(pci_OF,
> > "interrupt- map-mask", &ip_len);
> > +
> > + irq_of_table = (struct
> > irq_of_table_s*)get_property(pci_OF, "interrupt-map",
> > &irq_table_len); +
> > + irq = (unsigned int*)get_property(pci_OF,
> > "interrupts", &irq_len); +
> > + if (ip && irq_of_table && irq && ip_len &&
> > irq_table_len && irq_len ) {
> > + for (i=0;
> > i<irq_table_len/sizeof(irq_of_table->idsel[0]); i++) {
> > + line = irq_of_table->idsel[i].line
> > & ip->line_msk;
> > + idsel_ =
> > (irq_of_table->idsel[i].idsel & ip->idsel_msk) >> 11; +
> > + irqs_per_slot = (line >
> > irqs_per_slot) ? line : irqs_per_slot;
> > + min_idsel = (idsel_ <
> > min_idsel) ? idsel_ : min_idsel;
> > + max_idsel = (idsel_ >
> > max_idsel) ? idsel_ : max_idsel;
> > + }
> > +
> > + do {
> > + char pci_irq_table[max_idsel -
> > min_idsel + 1][irqs_per_slot]; +
> > + memset(&pci_irq_table[0][0], 0,
> > sizeof(pci_irq_table));
> > + for (i =
> > irq_table_len/sizeof(irq_of_table->idsel[0]) - 1;
> > i>=0; i--) {
> > + idsel_ =
> > (irq_of_table->idsel[i].idsel & ip->idsel_msk) >> 11; +
> > + line =
> > irq_of_table->idsel[i].line & ip->line_msk;
> > + pci_irq_table[idsel_ -
> > min_idsel][line-1] =
> > +
> > irq_of_table->idsel[i].table_item;
> > + }
> > +
> > + return PCI_IRQ_TABLE_LOOKUP;
> > + } while(0);
> > + } else {
> > + printk(KERN_INFO "%s: device tree
> > ERROR\n",__func__);
> > + return -1;
> > + }
> > + } else {
> > + static char pci_irq_table[][4] =
> > + /*
> > + * This is little evil, but works around the
> > fact
> > + * that revA boards have IDSEL starting at 18
> > + * and others boards (older) start at 12
> > + *
> > + * PCI IDSEL/INTPIN->INTLINE
> > + * A B C D
> > + */
> > + {
> > + {PIRQA, PIRQB, PIRQC, PIRQD}, /*
> > IDSEL 2 */
> > + {PIRQD, PIRQA, PIRQB, PIRQC},
> > + {PIRQC, PIRQD, PIRQA, PIRQB},
> > + {PIRQB, PIRQC, PIRQD, PIRQA}, /*
> > IDSEL 5 */
> > + {0, 0, 0, 0}, /* -- */
> > + {0, 0, 0, 0}, /* -- */
> > + {0, 0, 0, 0}, /* -- */
> > + {0, 0, 0, 0}, /* -- */
> > + {0, 0, 0, 0}, /* -- */
> > + {0, 0, 0, 0}, /* -- */
> > + {PIRQA, PIRQB, PIRQC, PIRQD}, /*
> > IDSEL 12 */
> > + {PIRQD, PIRQA, PIRQB, PIRQC},
> > + {PIRQC, PIRQD, PIRQA, PIRQB},
> > + {PIRQB, PIRQC, PIRQD, PIRQA}, /*
> > IDSEL 15 */
> > + {0, 0, 0, 0}, /* -- */
> > + {0, 0, 0, 0}, /* -- */
> > + {PIRQA, PIRQB, PIRQC, PIRQD}, /*
> > IDSEL 18 */
> > + {PIRQD, PIRQA, PIRQB, PIRQC},
> > + {PIRQC, PIRQD, PIRQA, PIRQB},
> > + {PIRQB, PIRQC, PIRQD, PIRQA}, /*
> > IDSEL 21 */
> > + };
> > +
> > + const long min_idsel = 2, max_idsel = 21,
> > irqs_per_slot = 4;
> > + return PCI_IRQ_TABLE_LOOKUP;
> > + }
>
>
> Is there some reason you reimplemented code that already exists for
> mapping PCI interrupts? Delete this function, and instead add:
>
> void __init
> mpc85xx_pcibios_fixup(void)
> {
> struct pci_dev *dev = NULL;
>
> for_each_pci_dev(dev)
> pci_read_irq_line(dev);
> }
>
> Hm. I see you added that function to pci.c. Anyway, you don't need
> the map_irq function anymore
>
>
>
> > + mpic_set_default_senses(mpic1,
> > + mpc85xx_ads_openpic_initsenses,
> > +
> > sizeof(mpc85xx_ads_openpic_initsenses)); +
>
> No. We have parse_and_map to handle this.
>
> > mpic_init(mpic1);
> > + of_node_put(np);
>
> Are we definitely supposed to release the of nodes after we call
> init? Actually, it looks like you can put that after mpic_alloc().
> mpic_alloc() grabs a reference, so we don't need it after that.
>
Looks like true, but I'll double-check this anyway.
>
> >
> > /*
> > * Setup the architecture
> > */
>
> There should probably be an #ifdef CONFIG_CPM2 here
>
ok
> > +static void init_fcc_ioports(void)
>
> ...
>
>
>
> > diff --git a/include/asm-powerpc/mpc85xx.h b/include/asm-powerpc/
> > mpc85xx.h
>
> This file really needs to be cleaned up. Most of the stuff in here
> can go.
>
My guess to separate the "cleanup_obsolete" and "add_new_stuff" in some ways, it it does not prevent stuff from work. Note that there are still a lot of confusion with ppc/powerpc header mix. So "cleanup" patch should be carefully tested with both ppc and powerpc. I am aware that mpc85xx.h exist in both instances, these are just generic thoughts.
Thanks for the comments and review.
> Andy
>
>
^ permalink raw reply
* Re: [PATCH 4/6] POWERPC: add support of mpc8560 eval board
From: Vitaly Bordug @ 2006-08-22 11:13 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <6A1F08CA-2FAE-4BE6-82BF-30F35053483C@freescale.com>
On Thu, 17 Aug 2006 15:04:11 -0500
Andy Fleming wrote:
>
> On Aug 11, 2006, at 19:10, Vitaly Bordug wrote:
>
>
> >
> > diff --git a/arch/powerpc/boot/dts/mpc8560ads.dts b/arch/powerpc/
> > boot/dts/mpc8560ads.dts
> > new file mode 100644
> > index 0000000..f6ccb99
> > --- /dev/null
> > +++ b/arch/powerpc/boot/dts/mpc8560ads.dts
> > @@ -0,0 +1,310 @@
> >
> > +
> > + ethernet@24000 {
> > + device_type = "network";
> > + model = "TSEC";
> > + compatible = "gianfar";
> > + reg = <24000 1000>;
> > + address = [ 00 00 0C 00 00 FD ];
> > + interrupts = <d 0 e 0 12 0>;
>
> Your sense values are wrong here. Should be "2"
> ie - interrupts = <d 2 e 2 12 2>;
>
Here and below:
those were derived from the original dts's an since it worked "as it is" I didn't fairly care atm.
It is clear, that the spec itself is 100% non-contradictory and consistent, so my main concern was to make-it-work. And, those stuff seems not to be taken into account (may be wrong `tho, haven't really looked into,
Ben ?
)
>
> > + interrupt-parent = <40000>;
> > + phy-handle = <2452000>;
> > + };
> > +
> > + ethernet@25000 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + device_type = "network";
> > + model = "TSEC";
> > + compatible = "gianfar";
> > + reg = <25000 1000>;
> > + address = [ 00 00 0C 00 01 FD ];
> > + interrupts = <13 0 14 0 18 0>;
>
>
> Here, too
>
ditto
> > + pic@40000 {
> > + linux,phandle = <40000>;
> > + interrupt-controller;
> > + #address-cells = <0>;
> > + #interrupt-cells = <2>;
> > + reg = <40000 20100>;
> > + built-in;
> > + device_type = "mpic";
>
> This is wrong. It should be "open-pic";
>
I am recalling nogo with open-pic here... I agree with Segher, we'll make this 100% clear and follow that
further.
> > + };
> > +
> > + cpm@e0000000 {
>
> I'm going to leave this to others to discuss, since I'm not a CPM
> expert. But you may want to double-check your interrupt sense
> values, and make sure the encodings are right.
>
>
I am completely open to the comments here..
And my guess is that the irq thing should be clarified and re-synced
with spec. All I can say currently - it works for me so may be used at least as reference
for the stuff alike. If the cpm2 description got settle down, I'll update the spec in relevance
and hope to make other inconsistencies (irq-related, obsoleted stuff etc. ) addressed.
> > diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/
> > platforms/85xx/Kconfig
> > index 454fc53..3d440de 100644
> > --- a/arch/powerpc/platforms/85xx/Kconfig
> > +++ b/arch/powerpc/platforms/85xx/Kconfig
> > @@ -11,6 +11,12 @@ config MPC8540_ADS
> > help
> > This option enables support for the MPC 8540 ADS board
> >
> > +config MPC8560_ADS
> > + bool "Freescale MPC8560 ADS"
> > + select DEFAULT_UIMAGE
> > + help
> > + This option enables support for the MPC 8560 ADS board
> > +
>
>
> If at all possible, I think that the 8560 shouldn't be a config
> option. It's just an 85xx ADS, and use the dts to distinguish. But
> keeping separate defconfigs seems like a good idea.
>
>
Agreed.
>
> > diff --git a/arch/powerpc/platforms/85xx/mpc8540_ads.h b/arch/
> > powerpc/platforms/85xx/mpc8540_ads.h
> > index c0d56d2..670abaf 100644
> > --- a/arch/powerpc/platforms/85xx/mpc8540_ads.h
> > +++ b/arch/powerpc/platforms/85xx/mpc8540_ads.h
> > @@ -6,6 +6,10 @@
> > * Maintainer: Kumar Gala <kumar.gala@freescale.com>
> > *
> > * Copyright 2004 Freescale Semiconductor Inc.
> > + *
> > + * 2006 (c) MontaVista Software, Inc.
> > + * Vitaly Bordug <vbordug@ru.mvista.com>
> > + * Merged to arch/powerpc
> > *
> > * 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
> > @@ -24,10 +28,10 @@ #define BCSR_ADDR
> > ((uint)0xf8000000) #define BCSR_SIZE ((uint)(32 *
> > 1024))
> >
> > /* PCI interrupt controller */
> > -#define PIRQA MPC85xx_IRQ_EXT1
> > -#define PIRQB MPC85xx_IRQ_EXT2
> > -#define PIRQC MPC85xx_IRQ_EXT3
> > -#define PIRQD MPC85xx_IRQ_EXT4
> > +#define PIRQA 49
> > +#define PIRQB 50
> > +#define PIRQC 51
> > +#define PIRQD 52
>
>
> Wha?! I can't imagine any reason this change would be acceptable.
> Especially since your patch needs to apply against a tree with the
> new irq code, which doesn't need such hard-coded values. We get
> them from the dts.
>
>
Tend to be cleanup_miss, the same as note below.
> > diff --git a/arch/powerpc/platforms/85xx/mpc8560_ads.h b/arch/
> > powerpc/platforms/85xx/mpc8560_ads.h
>
> This file should be able to go away, now, and get merged with
> mpc8540_ads.h. While we're at it, mpc8540_ads.h should become
> mpc85xx_ads.h
>
>
> > diff --git a/arch/powerpc/platforms/85xx/mpc85xx.h b/arch/powerpc/
> > platforms/85xx/mpc85xx.h
> > index b44db62..4fe613e 100644
> > --- a/arch/powerpc/platforms/85xx/mpc85xx.h
> > +++ b/arch/powerpc/platforms/85xx/mpc85xx.h
> > @@ -16,3 +16,4 @@
> >
> > extern void mpc85xx_restart(char *);
> > extern int add_bridge(struct device_node *dev);
> > +extern void mpc85xx_pcibios_fixup(void);
>
> Why is this being "exported"?
>
To make it compile :) will be fixed in the reordering in the next respin.
> > diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ads.c b/arch/
> > powerpc/platforms/85xx/mpc85xx_ads.c
> > index d0cfcdb..974e035 100644
> > --- a/arch/powerpc/platforms/85xx/mpc85xx_ads.c
> > +++ b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
> > @@ -4,6 +4,10 @@
> > * Maintained by Kumar Gala (see MAINTAINERS for contact
> > information) *
> > * Copyright 2005 Freescale Semiconductor Inc.
> > + *
> > + * 2006 (c) MontaVista Software, Inc.
> > + * Vitaly Bordug <vbordug@ru.mvista.com>
> > + * Merged to arch/powerpc
>
> This comment is confusing. This file was already "merged".
> Regardless, I believe there's a general policy against putting
> change logs in the header.
>
The last line is extra here - copy-paste thing. I added the upper line to make it clear that though I've created the file(s) in powerpc/, that is only "merge" thing, which is not quite right for this particular file, sorry about that.
>
> >
> > @@ -47,19 +59,19 @@ static u_char mpc85xx_ads_openpic_initse
> > MPC85XX_INTERNAL_IRQ_SENSES,
> > 0x0, /* External 0: */
> > #if defined(CONFIG_PCI)
> > - (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext
> > 1: PCI slot 0 */
> > - (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext
> > 2: PCI slot 1 */
> > - (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext
> > 3: PCI slot 2 */
> > - (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext
> > 4: PCI slot 3 */
> > + IRQ_TYPE_LEVEL_LOW, /* Ext 1: PCI slot 0 */
> > + IRQ_TYPE_LEVEL_LOW, /* Ext 2: PCI slot 1 */
> > + IRQ_TYPE_LEVEL_LOW, /* Ext 3: PCI slot 2 */
> > + IRQ_TYPE_LEVEL_LOW, /* Ext 4: PCI slot 3 */
> > #else
> > 0x0, /* External 1: */
> > 0x0, /* External 2: */
> > 0x0, /* External 3: */
> > 0x0, /* External 4: */
> > #endif
> > - (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /*
> > External 5: PHY */
> > + IRQ_TYPE_LEVEL_LOW, /* External 5: PHY */
> > 0x0, /* External 6: */
> > - (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /*
> > External 7: PHY */
> > + IRQ_TYPE_LEVEL_LOW, /* External 7: PHY */
> > 0x0, /* External 8: */
> > 0x0, /* External 9: */
> > 0x0, /* External 10: */
>
>
> This isn't how interrupt senses are supposed to be done now. They
> should be gotten from the device tree. This whole array can be
> deleted.
>
>
Here and below about PCI irq stuff - OK.
> > @@ -74,40 +86,109 @@ #ifdef CONFIG_PCI
> > int
> > mpc85xx_map_irq(struct pci_dev *dev, unsigned char idsel,
> > unsigned char pin)
> > {
>
> This whole function can be deleted.
>
> > + struct device_node * pci_OF;
> > + struct irq_map_of_mask {
> > + unsigned int idsel_msk;
> > + unsigned int slot_msk;
> > + unsigned int offset_irqs_msk;
> > + unsigned int line_msk;
> > + } *ip;
> > + int i;
> > + struct irq_of_table_s {
> > + struct {
> > + unsigned int idsel;
> > + unsigned int slot;
> > + unsigned int offset_irqs;
> > + unsigned int line;
> > + unsigned int parent;
> > + unsigned int table_item;
> > + unsigned int ext_irqs;
> > + } idsel[1];
> > + }* irq_of_table;
> > +
> > +
> > + pci_OF = of_find_node_by_type(NULL, "pci");
> > + if (pci_OF) {
> > + unsigned long max_idsel = 0;
> > + unsigned long min_idsel = 0xffffffff;
> > + unsigned long irqs_per_slot = 0;
> > + unsigned int idsel_ = 0;
> > + unsigned int line;
> > + unsigned int* irq;
> > + unsigned int ip_len;
> > + unsigned int irq_table_len;
> > + unsigned int irq_len;
> > +
> > + ip = (struct irq_map_of_mask*)get_property(pci_OF,
> > "interrupt- map-mask", &ip_len);
> > +
> > + irq_of_table = (struct
> > irq_of_table_s*)get_property(pci_OF, "interrupt-map",
> > &irq_table_len); +
> > + irq = (unsigned int*)get_property(pci_OF,
> > "interrupts", &irq_len); +
> > + if (ip && irq_of_table && irq && ip_len &&
> > irq_table_len && irq_len ) {
> > + for (i=0;
> > i<irq_table_len/sizeof(irq_of_table->idsel[0]); i++) {
> > + line = irq_of_table->idsel[i].line
> > & ip->line_msk;
> > + idsel_ =
> > (irq_of_table->idsel[i].idsel & ip->idsel_msk) >> 11; +
> > + irqs_per_slot = (line >
> > irqs_per_slot) ? line : irqs_per_slot;
> > + min_idsel = (idsel_ <
> > min_idsel) ? idsel_ : min_idsel;
> > + max_idsel = (idsel_ >
> > max_idsel) ? idsel_ : max_idsel;
> > + }
> > +
> > + do {
> > + char pci_irq_table[max_idsel -
> > min_idsel + 1][irqs_per_slot]; +
> > + memset(&pci_irq_table[0][0], 0,
> > sizeof(pci_irq_table));
> > + for (i =
> > irq_table_len/sizeof(irq_of_table->idsel[0]) - 1;
> > i>=0; i--) {
> > + idsel_ =
> > (irq_of_table->idsel[i].idsel & ip->idsel_msk) >> 11; +
> > + line =
> > irq_of_table->idsel[i].line & ip->line_msk;
> > + pci_irq_table[idsel_ -
> > min_idsel][line-1] =
> > +
> > irq_of_table->idsel[i].table_item;
> > + }
> > +
> > + return PCI_IRQ_TABLE_LOOKUP;
> > + } while(0);
> > + } else {
> > + printk(KERN_INFO "%s: device tree
> > ERROR\n",__func__);
> > + return -1;
> > + }
> > + } else {
> > + static char pci_irq_table[][4] =
> > + /*
> > + * This is little evil, but works around the
> > fact
> > + * that revA boards have IDSEL starting at 18
> > + * and others boards (older) start at 12
> > + *
> > + * PCI IDSEL/INTPIN->INTLINE
> > + * A B C D
> > + */
> > + {
> > + {PIRQA, PIRQB, PIRQC, PIRQD}, /*
> > IDSEL 2 */
> > + {PIRQD, PIRQA, PIRQB, PIRQC},
> > + {PIRQC, PIRQD, PIRQA, PIRQB},
> > + {PIRQB, PIRQC, PIRQD, PIRQA}, /*
> > IDSEL 5 */
> > + {0, 0, 0, 0}, /* -- */
> > + {0, 0, 0, 0}, /* -- */
> > + {0, 0, 0, 0}, /* -- */
> > + {0, 0, 0, 0}, /* -- */
> > + {0, 0, 0, 0}, /* -- */
> > + {0, 0, 0, 0}, /* -- */
> > + {PIRQA, PIRQB, PIRQC, PIRQD}, /*
> > IDSEL 12 */
> > + {PIRQD, PIRQA, PIRQB, PIRQC},
> > + {PIRQC, PIRQD, PIRQA, PIRQB},
> > + {PIRQB, PIRQC, PIRQD, PIRQA}, /*
> > IDSEL 15 */
> > + {0, 0, 0, 0}, /* -- */
> > + {0, 0, 0, 0}, /* -- */
> > + {PIRQA, PIRQB, PIRQC, PIRQD}, /*
> > IDSEL 18 */
> > + {PIRQD, PIRQA, PIRQB, PIRQC},
> > + {PIRQC, PIRQD, PIRQA, PIRQB},
> > + {PIRQB, PIRQC, PIRQD, PIRQA}, /*
> > IDSEL 21 */
> > + };
> > +
> > + const long min_idsel = 2, max_idsel = 21,
> > irqs_per_slot = 4;
> > + return PCI_IRQ_TABLE_LOOKUP;
> > + }
>
>
> Is there some reason you reimplemented code that already exists for
> mapping PCI interrupts? Delete this function, and instead add:
>
> void __init
> mpc85xx_pcibios_fixup(void)
> {
> struct pci_dev *dev = NULL;
>
> for_each_pci_dev(dev)
> pci_read_irq_line(dev);
> }
>
> Hm. I see you added that function to pci.c. Anyway, you don't need
> the map_irq function anymore
>
>
>
> > + mpic_set_default_senses(mpic1,
> > + mpc85xx_ads_openpic_initsenses,
> > +
> > sizeof(mpc85xx_ads_openpic_initsenses)); +
>
> No. We have parse_and_map to handle this.
>
> > mpic_init(mpic1);
> > + of_node_put(np);
>
> Are we definitely supposed to release the of nodes after we call
> init? Actually, it looks like you can put that after mpic_alloc().
> mpic_alloc() grabs a reference, so we don't need it after that.
>
Looks like true, but I'll double-check this anyway.
>
> >
> > /*
> > * Setup the architecture
> > */
>
> There should probably be an #ifdef CONFIG_CPM2 here
>
ok
> > +static void init_fcc_ioports(void)
>
> ...
>
>
>
> > diff --git a/include/asm-powerpc/mpc85xx.h b/include/asm-powerpc/
> > mpc85xx.h
>
> This file really needs to be cleaned up. Most of the stuff in here
> can go.
>
My guess to separate the "cleanup_obsolete" and "add_new_stuff" in some ways, it it does not prevent stuff from work. Note that there are still a lot of confusion with ppc/powerpc header mix. So "cleanup" patch should be carefully tested with both ppc and powerpc. I am aware that mpc85xx.h exist in both instances, these are just generic thoughts.
Thanks for the comments and review.
> Andy
>
>
^ permalink raw reply
* Re: Take 2: [RFC] Debugging with a HW probe.
From: Jimi Xenidis @ 2006-08-22 12:12 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <aa3478a76dd7fb5bff781350a7538fb0@bga.com>
On Aug 22, 2006, at 2:04 AM, Milton Miller wrote:
>
> On Aug 14, 2006, at 5:16 AM, Jimi Xenidis jimix at watson.ibm.com
> wrote:
>>
>> Signed-off-by: Jimi Xenidis <jimix at watson.ibm.com>
>
> [sorry for the list archive patch munging]
>
>> ---
>> diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
>> index e29ef77..bc4cdf9 100644
>> --- a/arch/powerpc/Kconfig.debug
>> +++ b/arch/powerpc/Kconfig.debug
>> @@ -61,6 +61,17 @@ config KGDB_CONSOLE
>> over the gdb stub.
>> If unsure, say N.
>>
>> +config ENABLE_HW_PROBE
>> + bool "Allow instructions that contact a hardware probe
>> (dangerous)"
>> + depends on PPC64
>
> Not having this depend on DEBUGGER but in the middle of things that
> do will
> get you scorn from the auto-indenting police.
ACK
>
> Since we can only call this from xmon, should it depend on XMON
> (and be
> placed after that)?
If the HW probe is available, XMON will use it.
However, enabling the HW probe also means that I can (as a developer)
insert ATTN() anywhere in my code and have the probe stop there. I
even have kernels where BUG() contains ATTN(), but thats another patch.
>
>> + help
>> + If you enable this AND you add "hwprobe" to the cmdline,
>> the
>> + processor will enable instructions that contact the
>> hardware
>> + probe. These instructions ca be used in all processor
>> modes
>
> can
ACK
>
>> + _including_ user mode and are only useful for kernel
>
> not sure this _highlighting_ is used elsewhere in Kconfig help ...
I was looking for an example and found "_will not boot_" in this very
file.
>
> Should we mention that a hardware probe is required to continue
> exectuion?
> In other words, its not just contact, but signal and wait for a hw
> probe?
Hows this?
If you enable this AND you add "hwprobe" to the cmdline, the
processor will enable instructions that signal and wait for
the hardware probe, _stopping_ the processor. These
instructions can be used in all processor modes _including_
user mode and are only useful for kernel development and
debugging. DO NOT enable this unless you plan to use it. If
you DO NOT have a hardware probe, answer N.
[snip]
>> --- a/arch/powerpc/kernel/prom_init.c
>> +++ b/arch/powerpc/kernel/prom_init.c
>> @@ -587,6 +587,14 @@ #ifdef CONFIG_PPC64
>> RELOC(iommu_force_on) = 1;
>> }
>> #endif
>> +#ifdef CONFIG_HW_PROBE_ENABLE
>> + opt = strstr(RELOC(prom_cmd_line), RELOC("hwprobe"));
>> + if (opt) {
>> + prom_printf("WARNING! HW Probe will be activated!
>> \n");
>> + prom_setprop(_prom->chosen, "/chosen",
>> + "linux,hw-probe-enable", NULL, 0);
>> + }
>> +#endif
>> }
>
> Please, PLEASE do NOT do this.
Ok, I won't. I somehow missed "early_param()" that should do just fine.
>
> Which .h is hw_probe_enabled in? (none?)
Correct, this RFC is to get valuable feedback (thank you), the
setting the global is the current goal, I'm waiting for some other
patches from other people to get in before we start going after HID
bits that this global, may or may not be part of.
>
>>
>> #ifdef CONFIG_PPC_PSERIES
>> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
>> index 179b10c..51a1e4e 100644
>> --- a/arch/powerpc/xmon/xmon.c
>> +++ b/arch/powerpc/xmon/xmon.c
>> @@ -189,7 +189,12 @@ #endif
>> dd dump double values\n\
>> dr dump stream of raw bytes\n\
>> e print exception information\n\
>> - f flush cache\n\
>> + f flush cache\n"
>> +#ifdef CONFIG_ENABLE_HW_PROBE
>> + "\
>> + H Contact hardware probe, if available\n"
>> +#endif
>> + "\
>
> While this style does keep the lines aligned in the source, it adds
> veritcal
> almost-whitespace.
Are you expressing "dislike"?
> And I notice a different choice was made at the bottom.
I borrowed from the CONFIG_SMP above and avoided putting '"' in col 0
but am happy to compress.
[snip]
>> @@ -641,6 +648,13 @@ extern void ppc64_runlatch_off(void);
>> extern unsigned long scom970_read(unsigned int address);
>> extern void scom970_write(unsigned int address, unsigned long
>> value);
>>
>> +/*
>> + * Support Processor Attention Instruction instroduced in POWER
>> + * architecture processors as of RS64, tho may not be supported by
>> + * POWER 3.
>> + */
>> +#define ATTN() asm volatile("attn; nop")
>> +
>
>
> Fairly certian POWER3 does NOT implement this, but I don't have
> book IV handy.
The book4 mentions "BPUBKT" and when asked no one could give a
definite answerm, I figured I'd try an see at some point. Having
said that, you give me a s/Fairly/Absolutely/ and its GONE!
> Does one of the processors require the nop ?
The nop is there so that once in the probe, depending on your probe
interface, you can easily skip it by adding 4 to the PC knowing you
would get a nop. This is not entirely necessary but some processor/
probes have a PC and a "next PC". I have had little experience with
this probe and wanted to make sure I had something to set both to if
it was needed.
Thanks for your feedback.
-JX
^ permalink raw reply
* RE: Gianfar eth driver on 8540 ppc - for 2.4 and 2.6 : different outputs - i have made some progress.
From: Prashant Yendigeri @ 2006-08-22 12:18 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <OF3EFEEE4F.C1FFA5F2-ON652571CD.00345D42-652571CD.003481A2@lntinfotech.com>
[-- Attachment #1: Type: text/plain, Size: 7342 bytes --]
Hi,
Finally i have reached a position, where the PHY is detected . Now i am
using kernel version 2.6.14.4 and the gianfar_driver and phy driver seem
to be ok
But my problem now is after the PHY is detected (correctly) I don't get
messages like Speed, Full or half duplex, link is up etc.
This means that the driver is not completely up, right ?
What might be the problem ?
I am loading gianfar driver as a loadable module, but the marvell and
generic phy driver are built into the kernel.
This is my output :
/ # ifconfig eth0 172.28.8.254 up
eth0: PHY is Marvell 88E1101/88E1111 (1410c62)
But after this no output, like Speed, etc.
I checked the code, this info is in a function , gfar_phy_change which
inturn is setup in a PHY change work queue called INIT_WORK. All of this
code is in
drivers/net/gianfar.c
Regards,
-prashant
Prashant Yendigeri <Prashant.Yendigeri@lntinfotech.com>
Sent by:
linuxppc-embedded-bounces+prashant.yendigeri=lntinfotech.com@ozlabs.org
08/17/2006 03:03 PM
To
Ho Jeffrey-r26191 <r26191@freescale.com>
cc
linuxppc-embedded@ozlabs.org
Subject
RE: Gianfar eth driver on 8540 ppc - for 2.4 and 2.6 : different outputs
Hi,
This is what i am getting from u-boot print messages :
U-Boot 1.1.0(pq3-20040423-r1) (May 5 2006 - 08:56:54)
Freescale PowerPC
Core: E500, Version: 2.0, (0x80200020)
System: 8540, Version: 2.0, (0x80300020)
Clocks: CPU: 660 MHz, CCB: 264 MHz, DDR: 132 MHz, LBC: 66 MHz
L1 D-cache 32KB, L1 I-cache 32KB enabled.
Board: Freescale EVAL8540 Board
CPU: 660 MHz
CCB: 264 MHz
DDR: 132 MHz
LBC: 66 MHz
L1 D-cache 32KB, L1 I-cache 32KB enabled.
I2C: ready
DRAM: 256 MB
FLASH: 8 MB
L2 cache enabled: 256KB
In: serial
Out: serial
Err: serial
Net: Freescale ENET0: PHY is Marvell 88E1011S (1410c62)
Freescale ENET1: PHY is Marvell 88E1011S (1410c62)
Freescale ENET2: PHY is Intel LXT971A (1378e2)
Freescale ENET0, Freescale ENET1, Freescale ENET2
Hit any key to stop autoboot: 0
MPC8540EVAL=>
MPC8540EVAL=>
This seems to me it is a old board from GDATECH . Data sheet not available
for this.
-prashant
Ho Jeffrey-r26191 <r26191@freescale.com>
08/12/2006 06:32 AM
To
"'Prashant Yendigeri'" <Prashant.Yendigeri@lntinfotech.com>, Kumar Gala
<galak@kernel.crashing.org>
cc
linuxppc-embedded@ozlabs.org
Subject
RE: Gianfar eth driver on 8540 ppc - for 2.4 and 2.6 : different outputs
Hi
>>>>[ 34.041809] 0:00 not found
SIOCSIFFLAGS: No[ 34.044526] eth0: Could not attach to PHY
such device
SIOCSIFFLAGS: No such device
>>>>> eth0: PHY is Generic MII (ffffffff)
_______________________________________________________
Can you quickly check if you have the right phy id written in your
platform file for your board?
Regards,
Jeffrey Ho
Freescale Semiconductor HK Ltd
________________________________
From:
linuxppc-embedded-bounces+r26191=freescale.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+r26191=freescale.com@ozlabs.org] On
Behalf Of Prashant Yendigeri
Sent: Friday, August 11, 2006 7:21 PM
To: Kumar Gala
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Gianfar eth driver on 8540 ppc - for 2.4 and
2.6 : different outputs
Hi,
Downloaded 2.6.16.26 and booted up and got this :
/ # ifconfig eth0 172.28.8.254 up
[ 34.034596] 0:00 not found
[ 34.037330] eth0: Could not attach to PHY
[ 34.041809] 0:00 not found
SIOCSIFFLAGS: No[ 34.044526] eth0: Could not attach to
PHY
such device
SIOCSIFFLAGS: No such device
I had enabled all the PHY devices in .config and also
tried only with Marvell phy enabled.
Kernel boot messages :
[ 2.296555] Gianfar MII Bus: probed
[ 2.301789] eth0: Gianfar Ethernet Controller Version
1.2, 00:01:af:07:9b:8a
[ 2.309039] eth0: Running with NAPI disabled
[ 2.313307] eth0: 64/64 RX/TX BD ring size
[ 2.318498] eth1: Gianfar Ethernet Controller Version
1.2, 00:00:00:00:72:6f
[ 2.325738] eth1: Running with NAPI disabled
[ 2.330006] eth1: 64/64 RX/TX BD ring size
[ 2.335198] eth2: Gianfar Ethernet Controller Version
1.2, 6f:74:3d:2f:64:65
[ 2.342377] eth2: Running with NAPI disabled
[ 2.346662] eth2: 64/64 RX/TX BD ring size
[ 2.351586] Marvell 88E1101: Registered new driver
[ 2.357010] Davicom DM9161E: Registered new driver
[ 2.362443] Davicom DM9131: Registered new driver
[ 2.367775] Cicada Cis8204: Registered new driver
[ 2.373136] LXT970: Registered new driver
[ 2.377794] LXT971: Registered new driver
[ 2.382461] QS6612: Registered new driver
Regards,
Prashant
Kumar Gala <galak@kernel.crashing.org>
08/11/2006 09:40 AM
To
Prashant Yendigeri
<Prashant.Yendigeri@lntinfotech.com>
cc
linuxppc-embedded@ozlabs.org
Subject
Re: Gianfar eth driver on 8540 ppc - for
2.4 and 2.6 : different outputs
On Aug 10, 2006, at 6:18 AM, Prashant Yendigeri wrote:
>
> Hi,
>
> The gianfar driver of 2.6.12 and 2.4.20 give different
outputs on
> the same PPC 8540 board.
>
> What could be the reason ?
>
> Output on 2.4.20 :
> /root # ifconfig eth0 172.28.8.254 up
> eth0: PHY is Marvell 88E1011S (1410c62)
> eth0: Auto-negotiation done
> eth0: Half Duplex
> eth0: Speed 10BT
> eth0: Link is up
>
> Output on 2.6.12
> / # ifconfig eth0 172.28.8.254 up
> eth0: PHY is Generic MII (ffffffff)
It looks like your 2.6.12 kernel isn't handling the PHY
correctly.
I'd recommend upgrading to something newer which has the
phylib
(can't remember which 2.6 that went into).
- kumar
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
______________________________________________________________________
[-- Attachment #2: Type: text/html, Size: 17108 bytes --]
^ permalink raw reply
* RE: Gianfar eth driver on 8540 ppc - for 2.4 and 2.6 : different outputs - i have made some progress.
From: Prashant Yendigeri @ 2006-08-22 12:54 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <OF4994B4A2.853A7058-ON652571D2.0042D6D3-652571D2.0043A270@lntinfotech.com>
[-- Attachment #1: Type: text/plain, Size: 8065 bytes --]
Hi,
I made a small change in arch/ppc/platforms/85xx/mpc8540*c . I changed the
phyid value of TSEC1 to 4 and TSEC2 to 5. And it started working.
-Prashant
Prashant Yendigeri <Prashant.Yendigeri@lntinfotech.com>
Sent by:
linuxppc-embedded-bounces+prashant.yendigeri=lntinfotech.com@ozlabs.org
08/22/2006 05:48 PM
To
linuxppc-embedded@ozlabs.org
cc
Subject
RE: Gianfar eth driver on 8540 ppc - for 2.4 and 2.6 : different outputs -
i have made some progress.
Hi,
Finally i have reached a position, where the PHY is detected . Now i am
using kernel version 2.6.14.4 and the gianfar_driver and phy driver seem
to be ok
But my problem now is after the PHY is detected (correctly) I don't get
messages like Speed, Full or half duplex, link is up etc.
This means that the driver is not completely up, right ?
What might be the problem ?
I am loading gianfar driver as a loadable module, but the marvell and
generic phy driver are built into the kernel.
This is my output :
/ # ifconfig eth0 172.28.8.254 up
eth0: PHY is Marvell 88E1101/88E1111 (1410c62)
But after this no output, like Speed, etc.
I checked the code, this info is in a function , gfar_phy_change which
inturn is setup in a PHY change work queue called INIT_WORK. All of this
code is in
drivers/net/gianfar.c
Regards,
-prashant
Prashant Yendigeri <Prashant.Yendigeri@lntinfotech.com>
Sent by:
linuxppc-embedded-bounces+prashant.yendigeri=lntinfotech.com@ozlabs.org
08/17/2006 03:03 PM
To
Ho Jeffrey-r26191 <r26191@freescale.com>
cc
linuxppc-embedded@ozlabs.org
Subject
RE: Gianfar eth driver on 8540 ppc - for 2.4 and 2.6 : different outputs
Hi,
This is what i am getting from u-boot print messages :
U-Boot 1.1.0(pq3-20040423-r1) (May 5 2006 - 08:56:54)
Freescale PowerPC
Core: E500, Version: 2.0, (0x80200020)
System: 8540, Version: 2.0, (0x80300020)
Clocks: CPU: 660 MHz, CCB: 264 MHz, DDR: 132 MHz, LBC: 66 MHz
L1 D-cache 32KB, L1 I-cache 32KB enabled.
Board: Freescale EVAL8540 Board
CPU: 660 MHz
CCB: 264 MHz
DDR: 132 MHz
LBC: 66 MHz
L1 D-cache 32KB, L1 I-cache 32KB enabled.
I2C: ready
DRAM: 256 MB
FLASH: 8 MB
L2 cache enabled: 256KB
In: serial
Out: serial
Err: serial
Net: Freescale ENET0: PHY is Marvell 88E1011S (1410c62)
Freescale ENET1: PHY is Marvell 88E1011S (1410c62)
Freescale ENET2: PHY is Intel LXT971A (1378e2)
Freescale ENET0, Freescale ENET1, Freescale ENET2
Hit any key to stop autoboot: 0
MPC8540EVAL=>
MPC8540EVAL=>
This seems to me it is a old board from GDATECH . Data sheet not available
for this.
-prashant
Ho Jeffrey-r26191 <r26191@freescale.com>
08/12/2006 06:32 AM
To
"'Prashant Yendigeri'" <Prashant.Yendigeri@lntinfotech.com>, Kumar Gala
<galak@kernel.crashing.org>
cc
linuxppc-embedded@ozlabs.org
Subject
RE: Gianfar eth driver on 8540 ppc - for 2.4 and 2.6 : different outputs
Hi
>>>>[ 34.041809] 0:00 not found
SIOCSIFFLAGS: No[ 34.044526] eth0: Could not attach to PHY
such device
SIOCSIFFLAGS: No such device
>>>>> eth0: PHY is Generic MII (ffffffff)
_______________________________________________________
Can you quickly check if you have the right phy id written in your
platform file for your board?
Regards,
Jeffrey Ho
Freescale Semiconductor HK Ltd
________________________________
From:
linuxppc-embedded-bounces+r26191=freescale.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+r26191=freescale.com@ozlabs.org] On
Behalf Of Prashant Yendigeri
Sent: Friday, August 11, 2006 7:21 PM
To: Kumar Gala
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Gianfar eth driver on 8540 ppc - for 2.4 and
2.6 : different outputs
Hi,
Downloaded 2.6.16.26 and booted up and got this :
/ # ifconfig eth0 172.28.8.254 up
[ 34.034596] 0:00 not found
[ 34.037330] eth0: Could not attach to PHY
[ 34.041809] 0:00 not found
SIOCSIFFLAGS: No[ 34.044526] eth0: Could not attach to
PHY
such device
SIOCSIFFLAGS: No such device
I had enabled all the PHY devices in .config and also tried
only with Marvell phy enabled.
Kernel boot messages :
[ 2.296555] Gianfar MII Bus: probed
[ 2.301789] eth0: Gianfar Ethernet Controller Version
1.2, 00:01:af:07:9b:8a
[ 2.309039] eth0: Running with NAPI disabled
[ 2.313307] eth0: 64/64 RX/TX BD ring size
[ 2.318498] eth1: Gianfar Ethernet Controller Version
1.2, 00:00:00:00:72:6f
[ 2.325738] eth1: Running with NAPI disabled
[ 2.330006] eth1: 64/64 RX/TX BD ring size
[ 2.335198] eth2: Gianfar Ethernet Controller Version
1.2, 6f:74:3d:2f:64:65
[ 2.342377] eth2: Running with NAPI disabled
[ 2.346662] eth2: 64/64 RX/TX BD ring size
[ 2.351586] Marvell 88E1101: Registered new driver
[ 2.357010] Davicom DM9161E: Registered new driver
[ 2.362443] Davicom DM9131: Registered new driver
[ 2.367775] Cicada Cis8204: Registered new driver
[ 2.373136] LXT970: Registered new driver
[ 2.377794] LXT971: Registered new driver
[ 2.382461] QS6612: Registered new driver
Regards,
Prashant
Kumar Gala <galak@kernel.crashing.org>
08/11/2006 09:40 AM
To
Prashant Yendigeri
<Prashant.Yendigeri@lntinfotech.com>
cc
linuxppc-embedded@ozlabs.org
Subject
Re: Gianfar eth driver on 8540 ppc - for
2.4 and 2.6 : different outputs
On Aug 10, 2006, at 6:18 AM, Prashant Yendigeri wrote:
>
> Hi,
>
> The gianfar driver of 2.6.12 and 2.4.20 give different
outputs on
> the same PPC 8540 board.
>
> What could be the reason ?
>
> Output on 2.4.20 :
> /root # ifconfig eth0 172.28.8.254 up
> eth0: PHY is Marvell 88E1011S (1410c62)
> eth0: Auto-negotiation done
> eth0: Half Duplex
> eth0: Speed 10BT
> eth0: Link is up
>
> Output on 2.6.12
> / # ifconfig eth0 172.28.8.254 up
> eth0: PHY is Generic MII (ffffffff)
It looks like your 2.6.12 kernel isn't handling the PHY
correctly.
I'd recommend upgrading to something newer which has the
phylib
(can't remember which 2.6 that went into).
- kumar
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
______________________________________________________________________
______________________________________________________________________
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
______________________________________________________________________
[-- Attachment #2: Type: text/html, Size: 18503 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