[patch 2/3] Add missing DATA_DATA in powerpc
Newer asm-generic/vmlinux.lds.h provides a DATA_DATA macro which defines the
content of what is normally referred to by *(.data). It permits adding more
"subsections" (declared by gcc with the section attribute or in assembly), which
will be linked in the .data section.
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
CC: linuxppc-dev@ozlabs.org
--
arch/powerpc/kernel/vmlinux.lds.S |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: linux-2.6-lttng/arch/powerpc/kernel/vmlinux.lds.S
===
--- linux-2.6-lttng.orig/arch/powerpc/kernel/vmlinux.lds.S 2007-07-11
11:55:48.0 -0400
+++ linux-2.6-lttng/arch/powerpc/kernel/vmlinux.lds.S 2007-07-11
15:48:42.0 -0400
@@ -174,7 +174,9 @@
}
#else
.data : {
- *(.data .data.rel* .toc1)
+ DATA_DATA
+ *(.data.rel*)
+ *(.toc1)
*(.branch_lt)
}
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Powerpc - Include pagemap.h in asm/powerpc/tlb.h
Powerpc - Include pagemap.h in asm/powerpc/tlb.h
Fixes this powerpc build error in 2.6.22-rc6-mm1 for powerpc 64 :
In file included from include2/asm/tlb.h:60,
from /home/compudj/git/linux-2.6-lttng/arch/powerpc/mm/init_64.
c:56:
/home/compudj/git/linux-2.6-lttng/include/asm-generic/tlb.h: In function 'tlb_fl
ush_mmu':
/home/compudj/git/linux-2.6-lttng/include/asm-generic/tlb.h:76: error: implicit
declaration of function 'release_pages'
/home/compudj/git/linux-2.6-lttng/include/asm-generic/tlb.h: In function 'tlb_re
move_page':
/home/compudj/git/linux-2.6-lttng/include/asm-generic/tlb.h:105: error: implicit
declaration of function 'page_cache_release'
make[2]: *** [arch/powerpc/mm/init_64.o] Error 1
release_pages is declared in linux/pagemap.h, but cannot be included in
linux/swap.h because of a sparc related comment:
/* only sparc can not include linux/pagemap.h in this file
* so leave page_cache_release and release_pages undeclared... */
#define free_page_and_swap_cache(page) \
page_cache_release(page)
#define free_pages_and_swap_cache(pages, nr) \
release_pages((pages), (nr), 0);
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
CC: linuxppc-dev@ozlabs.org
CC: Paul Mackerras <[EMAIL PROTECTED]>
---
include/asm-powerpc/tlb.h |2 ++
1 file changed, 2 insertions(+)
Index: linux-2.6-lttng/include/asm-powerpc/tlb.h
===
--- linux-2.6-lttng.orig/include/asm-powerpc/tlb.h 2007-07-13
11:30:54.0 -0400
+++ linux-2.6-lttng/include/asm-powerpc/tlb.h 2007-07-13 11:31:22.0
-0400
@@ -23,6 +23,8 @@
#include
#endif
+#include
+
struct mmu_gather;
#define tlb_start_vma(tlb, vma)do { } while (0)
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] crash in 2.6.22-git2 sysctl_set_parent()
[EMAIL PROTECTED] (Linas Vepstas) writes:
> This is a patch (& bug report) for a crash in sysctl_set_parent()
> in 2.6.22-git2.
>
> Problem: 2.6.22-git2 crashes with a stack trace
> [c1d0fb00] c0067b4c .sysctl_set_parent+0x48/0x7c
> [c1d0fb90] c0069b40 .register_sysctl_table+0x7c/0xf4
> [c1d0fc30] c065e710 .devinet_init+0x88/0xb0
> [c1d0fcc0] c065db74 .ip_rt_init+0x17c/0x32c
> [c1d0fd70] c065deec .ip_init+0x10/0x34
> [c1d0fdf0] c065e898 .inet_init+0x160/0x3dc
> [c1d0fea0] c0630bc4 .kernel_init+0x204/0x3c8
>
> A bit of poking around makes it clear what the problem is:
> In sysctl_set_parent(), the for loop
>
>for (; table->ctl_name || table->procname; table++) {
>
> walks off the end of the table, and into garbage. Basically,
> this for-loop iterator expects all table arrays to be
> "null terminated". However, net/ipv4/devinet.c statically
> declares an array that is not null-terminated. The patch
> below fixes that; it works for me. Its somewhat conservative;
> if one wishes to assume that the compiler will always zero out
> the empty parts of the structure, then this pach can be shrunk
> to one line: +ctl_table devinet_root_dir[3];
>
> Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
>
>
> I tried to audit some of the code to see where else there
> might be similar badly-formed static declarations. This is hard,
> as there's a lot of code. Most seems fine.
Right. I believe I performed a similar audit not to long ago
when everything was converted to C99 initializers and everything
was fine then.
> net/core/neighbour.c |4
> net/ipv4/devinet.c |7 ++-
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> Index: linux-2.6.22-git2/net/ipv4/devinet.c
> ===
> --- linux-2.6.22-git2.orig/net/ipv4/devinet.c 2007-07-13 14:23:21.0
> -0500
> +++ linux-2.6.22-git2/net/ipv4/devinet.c 2007-07-13 14:24:15.0 -0500
> @@ -1424,7 +1424,7 @@ static struct devinet_sysctl_table {
> ctl_table devinet_dev[2];
> ctl_table devinet_conf_dir[2];
> ctl_table devinet_proto_dir[2];
> - ctl_table devinet_root_dir[2];
> + ctl_table devinet_root_dir[3];
> } devinet_sysctl = {
> .devinet_vars = {
> DEVINET_SYSCTL_COMPLEX_ENTRY(FORWARDING, "forwarding",
> @@ -1493,8 +1493,13 @@ static struct devinet_sysctl_table {
> .data = &ipv4_devconf.loop,
> .maxlen = sizeof(int),
> .mode = 0644,
> + .child = 0x0,
> .proc_handler = &proc_dointvec,
> },
Where did this entry above in devinet_sysctl come from?
> + {
> + .ctl_name = 0,
> + .procname = 0,
> + },
I probably would have just done:
+ {},
> },
> };
>
What added the additional entry to devinet_root_dir? I don't see that
in Linus' tree?
The result may be fine but if it isn't named in a per network device
manner we are adding duplicate entries to the root /proc/sys directory
which is wrong.
Actually come to think of it I am concerned that someone added a
settable entry into /proc/sys/ it should at least be in /proc/sys/net/
where it won't conflict with other uses of that directory. Especially
as things like network devices have user controlled names.
Eric
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] crash in 2.6.22-git2 sysctl_set_parent()
Hi,
I'm totally confuzed by this patch ...
On 7/14/07, Linas Vepstas <[EMAIL PROTECTED]> wrote:
>
> This is a patch (& bug report) for a crash in sysctl_set_parent()
> in 2.6.22-git2.
Are you sure you saw this crash on 22-git2 (Linus' tree) ???
> Problem: 2.6.22-git2 crashes with a stack trace
> [c1d0fb00] c0067b4c .sysctl_set_parent+0x48/0x7c
> [c1d0fb90] c0069b40 .register_sysctl_table+0x7c/0xf4
> [c1d0fc30] c065e710 .devinet_init+0x88/0xb0
> [c1d0fcc0] c065db74 .ip_rt_init+0x17c/0x32c
> [c1d0fd70] c065deec .ip_init+0x10/0x34
> [c1d0fdf0] c065e898 .inet_init+0x160/0x3dc
> [c1d0fea0] c0630bc4 .kernel_init+0x204/0x3c8
Please post the full dmesg output, if possible.
> A bit of poking around makes it clear what the problem is:
> In sysctl_set_parent(), the for loop
>
>for (; table->ctl_name || table->procname; table++) {
Yup, but note that the "table" there is a struct ctl_table * ...
> walks off the end of the table, and into garbage. Basically,
> this for-loop iterator expects all table arrays to be
> "null terminated". However, net/ipv4/devinet.c statically
> declares an array that is not null-terminated.
Whereas the "not null-terminated" array you're talking about
in devinet.c is a struct devinet_sysctl_table, whose *members*
are ctl_table structs.
Also note that all those members have already been declared
as arrays: struct ctl_table xxx[2]; *precisely* because the
second element (which is left un-initialized, hence will get
zeroed-out being static) is what will protect us from running
out into garbage in sysctl_set_parent().
> The patch
> below fixes that; it works for me.
Now I'm even more confuzed ...
> Its somewhat conservative;
> if one wishes to assume that the compiler will always zero out
> the empty parts of the structure,
You can always safely assume that.
Off-topic, but note that unintialized static variables being automagically
initialized to zero / NULL is guaranteed by C (the language) itself, so
nothing left in the hands of compiler implementations here. [6.7.8:10]
> then this pach can be shrunk
> to one line: + ctl_table devinet_root_dir[3];
But that's pointless. It was already [2] for the reason I mentioned.
> Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
> [...]
> net/core/neighbour.c |4
> net/ipv4/devinet.c |7 ++-
> 2 files changed, 10 insertions(+), 1 deletion(-)
Weirder. diffstat does not match the patch ...
> Index: linux-2.6.22-git2/net/ipv4/devinet.c
> ===
> --- linux-2.6.22-git2.orig/net/ipv4/devinet.c 2007-07-13 14:23:21.0
> -0500
> +++ linux-2.6.22-git2/net/ipv4/devinet.c2007-07-13 14:24:15.0
> -0500
> @@ -1424,7 +1424,7 @@ static struct devinet_sysctl_table {
> ctl_table devinet_dev[2];
> ctl_table devinet_conf_dir[2];
> ctl_table devinet_proto_dir[2];
> - ctl_table devinet_root_dir[2];
> + ctl_table devinet_root_dir[3];
> } devinet_sysctl = {
> .devinet_vars = {
> DEVINET_SYSCTL_COMPLEX_ENTRY(FORWARDING, "forwarding",
> @@ -1493,8 +1493,13 @@ static struct devinet_sysctl_table {
And Linus' latest -git doesn't even have this stuff at line 1493.
> .data = &ipv4_devconf.loop,
> .maxlen = sizeof(int),
> .mode = 0644,
> + .child = 0x0,
> .proc_handler = &proc_dointvec,
> },
> + {
> + .ctl_name = 0,
> + .procname = 0,
> + },
> },
> };
Well, as I said, I'm totally confuzed ...
Satyam
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
On Fri, 2007-07-13 at 16:19 +0200, Arnd Bergmann wrote: > I'm pretty sure that no ppc64 machine needs alias resolution in the kernel, > although some are VIPT. Last time we discussed this, Segher explained it > to me, but I don't remember which way Cell does it. IIRC, it automatically > flushes cache lines that are accessed through aliases. Ah yes, I remember reading about this automatic flushing thing. I don't know how the caches actually work on most of our PPC's, but the fact is, we don't have aliasing issues, so I can safely ignore it for a bit longer :-) There are some aliasing issues with the instruction cache specifically on some 4xx models but that's irrelevant to this discussion (and I think we handle them elsewhere anyway). Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
On Fri, 2007-07-13 at 09:02 -0400, James Bottomley wrote:
> On Wed, 2007-07-04 at 15:22 +0200, Geert Uytterhoeven wrote:
> > + kaddr = kmap_atomic(sgpnt->page, KM_USER0);
> > + if (!kaddr)
> > + return -1;
> > + len = sgpnt->length;
> > + if ((req_len + len) > buflen) {
> > + active = 0;
> > + len = buflen - req_len;
> > + }
> > + memcpy(kaddr + sgpnt->offset, buf + req_len,
> > len);
> > + kunmap_atomic(kaddr, KM_USER0);
>
> This isn't a SCSI objection, but this sequence appears several times in
> this driver. It's wrong for a non-PIPT architecture (and I believe the
> PS3 is VIPT) because you copy into the kernel alias for the page, which
> dirties the line in the cache of that alias (the user alias cache line
> was already invalidated). However, unless you flush the kernel alias to
> main memory, the user could read stale data. The way this is supposed
> to be done is to do a
Nah, we have no cache aliasing on ppc, at least not that matter here and
not on cell.
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] crash in 2.6.22-git2 sysctl_set_parent()
From: [EMAIL PROTECTED] (Linas Vepstas)
Date: Fri, 13 Jul 2007 15:05:15 -0500
>
> This is a patch (& bug report) for a crash in sysctl_set_parent()
> in 2.6.22-git2.
>
> Problem: 2.6.22-git2 crashes with a stack trace
> [c1d0fb00] c0067b4c .sysctl_set_parent+0x48/0x7c
> [c1d0fb90] c0069b40 .register_sysctl_table+0x7c/0xf4
> [c1d0fc30] c065e710 .devinet_init+0x88/0xb0
> [c1d0fcc0] c065db74 .ip_rt_init+0x17c/0x32c
> [c1d0fd70] c065deec .ip_init+0x10/0x34
> [c1d0fdf0] c065e898 .inet_init+0x160/0x3dc
> [c1d0fea0] c0630bc4 .kernel_init+0x204/0x3c8
>
> A bit of poking around makes it clear what the problem is:
> In sysctl_set_parent(), the for loop
>
>for (; table->ctl_name || table->procname; table++) {
>
> walks off the end of the table, and into garbage. Basically,
> this for-loop iterator expects all table arrays to be
> "null terminated". However, net/ipv4/devinet.c statically
> declares an array that is not null-terminated. The patch
> below fixes that; it works for me. Its somewhat conservative;
> if one wishes to assume that the compiler will always zero out
> the empty parts of the structure, then this pach can be shrunk
> to one line: +ctl_table devinet_root_dir[3];
>
> Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Thanks for tracking this down, I'll apply your patch.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: hvc_iseries not working
On Fri, Jul 13, 2007 at 07:05:40PM +0200, Olaf Hering wrote: Hi Olaf, > 2.6.21 arch/powerpc/configs/iseries_defconfig works on an i825 with v5r4 > 2.6.22 arch/powerpc/configs/iseries_defconfig does not. But it works on > a i820 with v5r3. > 2.6.22 boots ok with CONFIG_VIOCONS Rats! Can you send me the complete dmesg and .config for each kernel. I'll poke at this whne I get to work on Monday. Yours Tony linux.conf.auhttp://linux.conf.au/ || http://lca2008.linux.org.au/ Jan 28 - Feb 02 2008 The Australian Linux Technical Conference! ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix Tsi108 ethernet driver performance
Scott Wood wrote: > Wouldn't this cause latencies of up to a second in responding to > received packets? I'd think that would be considered excessive. > > And shouldn't NAPI be reducing the RX interrupt load anyway? Sorry, I missed that you reduced the interval to 20 ms. Still, a bit on the high side, and a source of wasted CPU cycles when the network isn't heavily loaded. How much of a difference in CPU usage did you see with this patch? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix Tsi108 ethernet driver performance
Alexandre Bounine wrote: > -/* If the RX ring has run out of memory, try periodically > - * to allocate some more, as otherwise poll would never > - * get called (apart from the initial end-of-queue condition). > - * > - * This is called once per second (by default) from the thread. > +/* tsi108_check_rxring() is used to periodically check if the RX ring > has > + * pending frames that have not been reported by RX interrupt (due to > interrupt > + * moderation). It is called with CHECK_RX_INTERVAL timer interval. Wouldn't this cause latencies of up to a second in responding to received packets? I'd think that would be considered excessive. And shouldn't NAPI be reducing the RX interrupt load anyway? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Weird oopses with 2.6.22-rc7 [SOLVED]
On Fri, 13 Jul 2007, Christian Kujau wrote: > Ah, this seem to have fixed http://lkml.org/lkml/2007/7/8/21 and really > looks promising, I'll try 2.6.22-git2 now. for the record: running 2.6.22-git3 now and the Oopses went away ;) thanks, Christian. -- BOFH excuse #352: The cables are not the same length. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Fix Tsi108 ethernet driver performance
From: Alexandre Bounine <[EMAIL PROTECTED]>
This patch improves performance of the Tsi108 Ethernet driver by
changing interrupt handling
for frame receive path. It reduces number of interrupts generated for
received frames and therefore lowers CPU utilization by the device
driver.
Signed-off-by: Alexandre Bounine <[EMAIL PROTECTED]>
---
diff -Nurp linux-2.6.22-hpc2/drivers/net/tsi108_eth.c
linux-2.6.22-tun/drivers/net/tsi108_eth.c
--- linux-2.6.22-hpc2/drivers/net/tsi108_eth.c 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.22-tun/drivers/net/tsi108_eth.c 2007-07-12
16:55:50.0 -0400
@@ -58,6 +58,7 @@
#define MII_READ_DELAY 1 /* max link wait time in msec */
#define TSI108_RXRING_LEN 256
+#define TSI108_RX_INT_FREQ32
/* NOTE: The driver currently does not support receiving packets
* larger than the buffer size, so don't decrease this (unless you
@@ -69,8 +70,10 @@
#define TSI108_TX_INT_FREQ64
-/* Check the phy status every half a second. */
-#define CHECK_PHY_INTERVAL (HZ/2)
+/* Timer interval to check the RX queue status */
+#define CHECK_RX_INTERVAL (HZ/50)
+/* Timer interval to check the PHY status */
+#define CHECK_PHY_INTERVAL (CHECK_RX_INTERVAL * 10)
static int tsi108_init_one(struct platform_device *pdev);
static int tsi108_ether_remove(struct platform_device *pdev);
@@ -104,6 +107,7 @@ struct tsi108_prv_data {
unsigned int txfree;
unsigned int phy_ok;/* The PHY is currently powered
on. */
+ unsigned int phy_chk_count;
/* PHY status (duplex is 1 for half, 2 for full,
* so that the default 0 indicates that neither has
@@ -823,7 +827,10 @@ static int tsi108_refill_rx(struct net_d
*/
data->rxring[rx].blen = TSI108_RX_SKB_SIZE;
- data->rxring[rx].misc = TSI108_RX_OWN | TSI108_RX_INT;
+ if (rx % TSI108_RX_INT_FREQ)
+ data->rxring[rx].misc = TSI108_RX_OWN;
+ else
+ data->rxring[rx].misc = TSI108_RX_OWN |
TSI108_RX_INT;
data->rxhead = (data->rxhead + 1) % TSI108_RXRING_LEN;
data->rxfree++;
@@ -973,24 +980,22 @@ static void tsi108_rx_int(struct net_dev
}
}
-/* If the RX ring has run out of memory, try periodically
- * to allocate some more, as otherwise poll would never
- * get called (apart from the initial end-of-queue condition).
- *
- * This is called once per second (by default) from the thread.
+/* tsi108_check_rxring() is used to periodically check if the RX ring
has
+ * pending frames that have not been reported by RX interrupt (due to
interrupt
+ * moderation). It is called with CHECK_RX_INTERVAL timer interval.
*/
static void tsi108_check_rxring(struct net_device *dev)
{
struct tsi108_prv_data *data = netdev_priv(dev);
+ unsigned int rx = data->rxtail;
- /* A poll is scheduled, as opposed to caling tsi108_refill_rx
-* directly, so as to keep the receive path single-threaded
-* (and thus not needing a lock).
-*/
-
- if (netif_running(dev) && data->rxfree < TSI108_RXRING_LEN / 4)
+ /* Schedule a poll (if required) */
+ if (netif_running(dev) &&
+ 0 == (data->rxring[rx].misc & TSI108_RX_OWN)) {
+ data->rxpending = 1;
tsi108_rx_int(dev);
+ }
}
static void tsi108_tx_int(struct net_device *dev)
@@ -1295,6 +1300,7 @@ static void tsi108_init_phy(struct net_d
printk(KERN_DEBUG "PHY_STAT reg contains %08x\n", phyval);
data->phy_ok = 1;
+ data->phy_chk_count = 0;
data->init_media = 1;
spin_unlock_irqrestore(&phy_lock, flags);
}
@@ -1664,9 +1670,12 @@ static void tsi108_timed_checker(unsigne
struct net_device *dev = (struct net_device *)dev_ptr;
struct tsi108_prv_data *data = netdev_priv(dev);
- tsi108_check_phy(dev);
+ /* We assume that RX queue is checked more often than PHY status
*/
+ if (data->phy_chk_count++ == 0)
+ tsi108_check_phy(dev);
tsi108_check_rxring(dev);
- mod_timer(&data->timer, jiffies + CHECK_PHY_INTERVAL);
+ data->phy_chk_count %= (CHECK_PHY_INTERVAL/CHECK_RX_INTERVAL);
+ mod_timer(&data->timer, jiffies + CHECK_RX_INTERVAL);
}
static int tsi108_ether_init(void)
---
Important Notice: This message is intended for the use of the individual to
whom it is addressed and may contain information which is privileged,
confidential and/or exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, or is not the employee or agent
responsible for delivering the message to the intended recipient, you are
hereby notified that any dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this communication
in error, please notify the sender immediately by telephone or return e-mail
and
Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
On Fri, 13 Jul 2007, James Bottomley wrote:
> On Fri, 2007-07-13 at 17:10 +0200, Geert Uytterhoeven wrote:
> > On Fri, 13 Jul 2007, Arnd Bergmann wrote:
> > > On Friday 13 July 2007, James Bottomley wrote:
> > > > > IC.
> > > > >
> > > > > - flush_kernel_dcache_page() is a no-op on ppc64
> > > > > (ARCH_HAS_FLUSH_KERNEL_DCACHE_PAGE is defined on parisc only).
> > > > >
> > > > > - For reference, drivers/scsi/ipr.c (another ppc64 driver) just uses
> > > > > a plain
> > > > > kmap/memcpy/kunmap sequence
> > > > >
> > > > > So what should I do?
> > > >
> > > > Ask someone who knows the architecture ... Anton, Paulus or Benh ... I'm
> > > > fairly certain PPC is VIPT and will need some kind of alias
> > > > resolution ... perhaps its associative enough not to let the aliases be
> > > > a problem.
> > >
> > > I'm pretty sure that no ppc64 machine needs alias resolution in the
> > > kernel,
> > > although some are VIPT. Last time we discussed this, Segher explained it
> > > to me, but I don't remember which way Cell does it. IIRC, it automatically
> > > flushes cache lines that are accessed through aliases.
> >
> > Thanks for confirming!
> >
> > > It's probably a good idea to have the flush_kernel_dcache_page() in there
> > > anyway, if only to serve as an example for people that copy it into
> > > architecture-independent drivers, same as what we do for the
> > > k{,un}map_atomic() that is also not required on ppc64.
> >
> > Now my next question: why should I add it, if currently no single driver in
> > mainline calls flush_kernel_dcache_page()?
> >
> > `git grep' finds it in the following files only:
> > Documentation/cachetlb.txt
> > arch/parisc/kernel/cache.c
> > arch/parisc/kernel/pacache.S
> > include/asm-parisc/cacheflush.h
> > include/linux/highmem.h
>
> It's a recent addition to the API ... the previous way of doing it was
> flush_dcache_page() but that's expensive and flushes all the user
> aliases. Since you know in this case there are no current user aliases
> and you only need to flush the kernel alias, flush_kernel_dcache_page()
> was introduced as the cheaper alternative.
Ah, that explains it. flush_dcache_page() is used in some drivers.
I'll update my patches. Thanks for the comments!
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone:+32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: [EMAIL PROTECTED]
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] crash in 2.6.22-git2 sysctl_set_parent()
This is a patch (& bug report) for a crash in sysctl_set_parent()
in 2.6.22-git2.
Problem: 2.6.22-git2 crashes with a stack trace
[c1d0fb00] c0067b4c .sysctl_set_parent+0x48/0x7c
[c1d0fb90] c0069b40 .register_sysctl_table+0x7c/0xf4
[c1d0fc30] c065e710 .devinet_init+0x88/0xb0
[c1d0fcc0] c065db74 .ip_rt_init+0x17c/0x32c
[c1d0fd70] c065deec .ip_init+0x10/0x34
[c1d0fdf0] c065e898 .inet_init+0x160/0x3dc
[c1d0fea0] c0630bc4 .kernel_init+0x204/0x3c8
A bit of poking around makes it clear what the problem is:
In sysctl_set_parent(), the for loop
for (; table->ctl_name || table->procname; table++) {
walks off the end of the table, and into garbage. Basically,
this for-loop iterator expects all table arrays to be
"null terminated". However, net/ipv4/devinet.c statically
declares an array that is not null-terminated. The patch
below fixes that; it works for me. Its somewhat conservative;
if one wishes to assume that the compiler will always zero out
the empty parts of the structure, then this pach can be shrunk
to one line: + ctl_table devinet_root_dir[3];
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
I tried to audit some of the code to see where else there
might be similar badly-formed static declarations. This is hard,
as there's a lot of code. Most seems fine.
net/core/neighbour.c |4
net/ipv4/devinet.c |7 ++-
2 files changed, 10 insertions(+), 1 deletion(-)
Index: linux-2.6.22-git2/net/ipv4/devinet.c
===
--- linux-2.6.22-git2.orig/net/ipv4/devinet.c 2007-07-13 14:23:21.0
-0500
+++ linux-2.6.22-git2/net/ipv4/devinet.c2007-07-13 14:24:15.0
-0500
@@ -1424,7 +1424,7 @@ static struct devinet_sysctl_table {
ctl_table devinet_dev[2];
ctl_table devinet_conf_dir[2];
ctl_table devinet_proto_dir[2];
- ctl_table devinet_root_dir[2];
+ ctl_table devinet_root_dir[3];
} devinet_sysctl = {
.devinet_vars = {
DEVINET_SYSCTL_COMPLEX_ENTRY(FORWARDING, "forwarding",
@@ -1493,8 +1493,13 @@ static struct devinet_sysctl_table {
.data = &ipv4_devconf.loop,
.maxlen = sizeof(int),
.mode = 0644,
+ .child = 0x0,
.proc_handler = &proc_dointvec,
},
+ {
+ .ctl_name = 0,
+ .procname = 0,
+ },
},
};
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Help required for porting ISP1362 usb device driver
Hello, Vikram! Vikram Kone schrieb: > Hi.. > I'm a linux newbie and im working on porting the USB driver ISP1362 by > Philips on to my Freescale ppc board. Please don't crosspost. Please don't write HTML. > I dont know how to do this... so if any of you can tell me how to do > this step by step, i would be very grateful to you > > Few details.. > I'm running RHEL with kernel 2.4.21 on a PC (i386 machine) > Target Machine is MPC8548 CDS by Free scale (ppc architecture) running > kernel version 2.6.11 Did you try something like: http://www.freescale.com/files/32bit/doc/app_note/AN3094.pdf?fsrch=1 I think it's one of these "step by step" things. (You should consider moving up to the latest Kernel which is 2.6.22.1 as of today. Nobody fixes bugs on that old kernel.) > I do have a ppc tool chain, if that helps. What tool chain? > but i dont know how to use it Did you read the documentation? What problem do you have? > P.S. I downloaded the deive driver and host controller drivers from > sourceforge.net and both of them seem to work for 2.6.6 kernel for i386 > arch .. Fine! > P.P.S : Wolfgang ??!1 Can you help me out... I went through the archives > on the list and seems thatu answered many Qs on this driver. But i didnt > find any post specifcally for my problem..so Sorry, my crystal ball is broken. You didn't tell us any details about your problem. > This e-mail may contain confidential and privileged material for the > sole use of the intended recipient. Any review, use, distribution or > disclosure by others is strictly prohibited. If you are not the intended > recipient (or authorized to receive for the recipient), please contact > the sender by reply e-mail and delete all copies of this message. Oops... If I am not the intended recipient, please: > /dev/null my mail. Regards, -- Clemens Koller __ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.22 flash boot
Hello. Marc Leeman wrote: > With the release of the 2.6.22, our boards didn't boot anymore. I traced > the change back to 2.6.21-git10/2.6.21-git11. > The reason they didn't boot was that the kernel didn't detect the flash > where the root filesystem is stored on. The boards boot without an > initrd, directly from flash. > A file was removed (rom.c) and mentioned as obsolete in the ChangeLog. [...] > Am I missing something here? It's been removed as conflicting with the new of_device probing code. You can either register the "rom" device explicitly in your platform code, or put it on some bus below the ones specified to of_platform_device_probe() -- by your platform code again... WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/5] Kconfig cleanup
Jon Loeliger <[EMAIL PROTECTED]> wrote: X-Provags-ID: V01U2FsdGVkX18a539ZiXmAXeY+eK9MdUjOkwfvlvR4PUC8vLN hv7FFOkt1BgOy18T2Tf8fQgBcT+SMke7QjZMwzOtjX3HPEZzfI I86h59GhTM7GU39vE50ww== > Hmmm... Shouldn't this sort of change come > with an update to the 8641 defconfig too? Yes, good point. This updates the various defconfig files that are impacted by the changes, and applied cleanly against the latest powerpc.git again. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/5] move embedded6xx into multiplatform
Jon Loeliger <[EMAIL PROTECTED]> wrote: X-Provags-ID: V01U2FsdGVkX1+SaCCegn5lQjYmfKX51SjCTUcB54DR70XKrhI hmGM1tKApkuJUhU1N/m27xBNFkgSrryBjxIoSP8aSjI4iolGnU P+lfBacQBsWXTPdYoWsBw== > Hmmm... Shouldn't this sort of change come > with an update to the 8641 defconfig too? Content-Disposition: inline; filename=embedded6xx-multi.diff The various embedded 6xx systems can easily coexist in one kernel together with the other 6xx based systems, so there is no strict reason to keep them separate. This also fixes a problem introduced in one earlier patch, where the embedded 74xx based systems could not automatically select altivec any more. Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]> --- Index: linux-2.6/arch/powerpc/platforms/Kconfig === --- linux-2.6.orig/arch/powerpc/platforms/Kconfig +++ linux-2.6/arch/powerpc/platforms/Kconfig @@ -12,10 +12,6 @@ config PPC_MULTIPLATFORM RS/6000 machine, an Apple machine, or a PReP, CHRP, Maple or Cell-based machine. -config EMBEDDED6xx - bool "Embedded 6xx/7xx/7xxx-based board" - depends on PPC32 && (BROKEN||BROKEN_ON_SMP) - config PPC_82xx bool "Freescale 82xx" depends on 6xx Index: linux-2.6/arch/powerpc/platforms/embedded6xx/Kconfig === --- linux-2.6.orig/arch/powerpc/platforms/embedded6xx/Kconfig +++ linux-2.6/arch/powerpc/platforms/embedded6xx/Kconfig @@ -1,9 +1,10 @@ -choice - prompt "Machine Type" - depends on EMBEDDED6xx +config EMBEDDED6xx + bool "Embedded 6xx/7xx/7xxx-based boards" + depends on PPC32 && (BROKEN||BROKEN_ON_SMP) && PPC_MULTIPLATFORM config LINKSTATION bool "Linkstation / Kurobox(HG) from Buffalo" + depends on EMBEDDED6xx select MPIC select FSL_SOC select PPC_UDBG_16550 if SERIAL_8250 @@ -18,6 +19,7 @@ config LINKSTATION config MPC7448HPC2 bool "Freescale MPC7448HPC2(Taiga)" + depends on EMBEDDED6xx select TSI108_BRIDGE select DEFAULT_UIMAGE select PPC_UDBG_16550 @@ -28,6 +30,7 @@ config MPC7448HPC2 config PPC_HOLLY bool "PPC750GX/CL with TSI10x bridge (Hickory/Holly)" + depends on EMBEDDED6xx select TSI108_BRIDGE select PPC_UDBG_16550 select WANT_DEVICE_TREE @@ -38,13 +41,13 @@ config PPC_HOLLY config PPC_PRPMC2800 bool "Motorola-PrPMC2800" + depends on EMBEDDED6xx select MV64X60 select NOT_COHERENT_CACHE select WANT_DEVICE_TREE select CPU_7450 help This option enables support for the Motorola PrPMC2800 board -endchoice config TSI108_BRIDGE bool Index: linux-2.6/arch/powerpc/configs/holly_defconfig === --- linux-2.6.orig/arch/powerpc/configs/holly_defconfig +++ linux-2.6/arch/powerpc/configs/holly_defconfig @@ -1,9 +1,32 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.22-rc2 -# Thu May 31 11:25:44 2007 +# Linux kernel version: 2.6.22-rc7 +# Fri Jul 13 20:05:39 2007 # # CONFIG_PPC64 is not set + +# +# Processor support +# +CONFIG_6xx=y +# CONFIG_PPC_85xx is not set +# CONFIG_PPC_8xx is not set +# CONFIG_40x is not set +# CONFIG_44x is not set +# CONFIG_E200 is not set +# CONFIG_PPC_CPU_SELECTION is not set +# CONFIG_CPU_601 is not set +# CONFIG_CPU_603e is not set +CONFIG_CPU_750=y +# CONFIG_CPU_7400 is not set +# CONFIG_CPU_7450 is not set +CONFIG_PPC_MCPU="-mcpu=750" +CONFIG_PPC_FPU=y +CONFIG_ALTIVEC=y +CONFIG_PPC_STD_MMU=y +CONFIG_PPC_STD_MMU_32=y +# CONFIG_PPC_MM_SLICES is not set +# CONFIG_SMP is not set CONFIG_PPC32=y CONFIG_PPC_MERGE=y CONFIG_MMU=y @@ -25,28 +48,8 @@ CONFIG_PPC_UDBG_16550=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_DEFAULT_UIMAGE is not set - -# -# Processor support -# -CONFIG_CLASSIC32=y -# CONFIG_PPC_82xx is not set -# CONFIG_PPC_83xx is not set -# CONFIG_PPC_85xx is not set -# CONFIG_PPC_86xx is not set -# CONFIG_PPC_8xx is not set -# CONFIG_40x is not set -# CONFIG_44x is not set -# CONFIG_E200 is not set -CONFIG_6xx=y -CONFIG_PPC_FPU=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set -# CONFIG_ALTIVEC is not set -CONFIG_PPC_STD_MMU=y -CONFIG_PPC_STD_MMU_32=y -# CONFIG_PPC_MM_SLICES is not set -# CONFIG_SMP is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # @@ -136,14 +139,21 @@ CONFIG_DEFAULT_IOSCHED="anticipatory" # # Platform support # -# CONFIG_PPC_MULTIPLATFORM is not set -CONFIG_EMBEDDED6xx=y -# CONFIG_APUS is not set +CONFIG_PPC_MULTIPLATFORM=y +# CONFIG_PPC_82xx is not set +# CONFIG_PPC_83xx is not set +# CONFIG_PPC_86xx is not set +CONFIG_CLASSIC32=y +# CONFIG_PPC_CHRP is not set # CONFIG_PPC_MPC52xx is not set # CONFIG_PPC_MPC5200 is not set +# CONFIG_PPC_EFIKA is not set +# CONFIG_PPC_LITE5200 is not set +# CONFIG_PPC_PMAC is not set # CONFIG
[PATCH 5/5] move 83xx into multiplatform
Jon Loeliger <[EMAIL PROTECTED]> wrote: X-Provags-ID: V01U2FsdGVkX183KEAUKHXvruCYhaaV52OzolDzOwR8U/cVbZz RqqlZgNmQVzTnk6PKfA2exuU2PW9QK2JcOV9grQhnden9S/eQ3 4u2xKjwqyFO/YMrW3bvyA== > Hmmm... Shouldn't this sort of change come > with an update to the 8641 defconfig too? Content-Disposition: inline; filename=83xx-multi.diff MPC83xx based machines don't need their own kernel, but can run one that is shared with the other 6xx compatible machines, so we should allow that in Kconfig. Cc: Kumar Gala <[EMAIL PROTECTED]> Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]> --- Index: linux-2.6/arch/powerpc/platforms/83xx/Kconfig === --- linux-2.6.orig/arch/powerpc/platforms/83xx/Kconfig +++ linux-2.6/arch/powerpc/platforms/83xx/Kconfig @@ -1,10 +1,13 @@ -choice - prompt "83xx Board Type" - depends on PPC_83xx - default MPC834x_MDS +config PPC_83xx + bool "Freescale 83xx based boards" + depends on 6xx + select FSL_SOC + select 83xx + select WANT_DEVICE_TREE config MPC8313_RDB bool "Freescale MPC8313 RDB" + depends on PPC_83xx select DEFAULT_UIMAGE select CPU_603e help @@ -12,6 +15,7 @@ config MPC8313_RDB config MPC832x_MDS bool "Freescale MPC832x MDS" + depends on PPC_83xx select DEFAULT_UIMAGE select QUICC_ENGINE select CPU_603e @@ -20,6 +24,7 @@ config MPC832x_MDS config MPC832x_RDB bool "Freescale MPC832x RDB" + depends on PPC_83xx select DEFAULT_UIMAGE select QUICC_ENGINE select CPU_603e @@ -28,6 +33,7 @@ config MPC832x_RDB config MPC834x_MDS bool "Freescale MPC834x MDS" + depends on PPC_83xx select DEFAULT_UIMAGE select CPU_603e help @@ -40,6 +46,7 @@ config MPC834x_MDS config MPC834x_ITX bool "Freescale MPC834x ITX" + depends on PPC_83xx select DEFAULT_UIMAGE select CPU_603e help @@ -50,14 +57,13 @@ config MPC834x_ITX config MPC836x_MDS bool "Freescale MPC836x MDS" + depends on PPC_83xx select DEFAULT_UIMAGE select QUICC_ENGINE select CPU_603e help This option enables support for the MPC836x MDS Processor Board. -endchoice - config PPC_MPC831x bool select PPC_UDBG_16550 Index: linux-2.6/arch/powerpc/platforms/Kconfig === --- linux-2.6.orig/arch/powerpc/platforms/Kconfig +++ linux-2.6/arch/powerpc/platforms/Kconfig @@ -16,13 +16,6 @@ config PPC_82xx bool "Freescale 82xx" depends on 6xx -config PPC_83xx - bool "Freescale 83xx" - depends on 6xx - select FSL_SOC - select 83xx - select WANT_DEVICE_TREE - endchoice config CLASSIC32 Index: linux-2.6/arch/powerpc/configs/mpc8313_rdb_defconfig === --- linux-2.6.orig/arch/powerpc/configs/mpc8313_rdb_defconfig +++ linux-2.6/arch/powerpc/configs/mpc8313_rdb_defconfig @@ -1,9 +1,33 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.22-rc7 -# Sun Jul 1 23:56:55 2007 +# Fri Jul 13 20:00:52 2007 # # CONFIG_PPC64 is not set + +# +# Processor support +# +CONFIG_6xx=y +# CONFIG_PPC_85xx is not set +# CONFIG_PPC_8xx is not set +# CONFIG_40x is not set +# CONFIG_44x is not set +# CONFIG_E200 is not set +# CONFIG_PPC_CPU_SELECTION is not set +# CONFIG_CPU_601 is not set +CONFIG_CPU_603e=y +# CONFIG_CPU_750 is not set +# CONFIG_CPU_7400 is not set +# CONFIG_CPU_7450 is not set +CONFIG_PPC_MCPU="-mcpu=603e" +CONFIG_83xx=y +CONFIG_PPC_FPU=y +CONFIG_ALTIVEC=y +CONFIG_PPC_STD_MMU=y +CONFIG_PPC_STD_MMU_32=y +# CONFIG_PPC_MM_SLICES is not set +# CONFIG_SMP is not set CONFIG_PPC32=y CONFIG_PPC_MERGE=y CONFIG_MMU=y @@ -25,28 +49,8 @@ CONFIG_PPC_UDBG_16550=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y CONFIG_DEFAULT_UIMAGE=y - -# -# Processor support -# -# CONFIG_CLASSIC32 is not set -# CONFIG_PPC_82xx is not set -CONFIG_PPC_83xx=y -# CONFIG_PPC_85xx is not set -# CONFIG_PPC_86xx is not set -# CONFIG_PPC_8xx is not set -# CONFIG_40x is not set -# CONFIG_44x is not set -# CONFIG_E200 is not set -CONFIG_6xx=y -CONFIG_83xx=y -CONFIG_PPC_FPU=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set -CONFIG_PPC_STD_MMU=y -CONFIG_PPC_STD_MMU_32=y -# CONFIG_PPC_MM_SLICES is not set -# CONFIG_SMP is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # @@ -135,11 +139,19 @@ CONFIG_DEFAULT_IOSCHED="anticipatory" # # Platform support # +CONFIG_PPC_MULTIPLATFORM=y +# CONFIG_PPC_82xx is not set +CONFIG_CLASSIC32=y +# CONFIG_PPC_CHRP is not set # CONFIG_PPC_MPC52xx is not set # CONFIG_PPC_MPC5200 is not set +# CONFIG_PPC_EFIKA is not set +# CONFIG_PPC_LITE5200 is not set +# CONFIG_PPC_PMAC is not set # CONFIG_PPC_CELL is not set # CONFIG_PPC_CELL_NATIVE is not
[PATCH 1/5] autoselect optimal -mcpu= flag by platform
Jon Loeliger <[EMAIL PROTECTED]> wrote: X-Provags-ID: V01U2FsdGVkX1+BoY6XjUrGly1rWyOZxsXD2wcNMyeBnkUMy7/ aE+cggJKYpJ3rKZ1wc9pqTY5IFAoNnY8dtj7q9qT51Y7DKTlnv RU/QVHeYEEj4zJk1aarlw== > Hmmm... Shouldn't this sort of change come > with an update to the 8641 defconfig too? Content-Disposition: inline; filename=advanced-cpusel.diff We can choose the -mcpu= gcc flags for compiling the kernel based on the platform that we build for. In case of multiplatform kernels, this chooses a setting for a common subset. When using a platform type that can use different CPUs, a new option CONFIG_PPC_CPU_SELECTION can be enabled to select more specifically which CPUs the kernel will be able to run on. This replaces the CONFIG_POWER4_ONLY option with an much more generic approach. Also, when CONFIG_PPC_CPU_SELECTION is set, it is now possible to select a CPU to tune for by means of the -mtune= option. I tried to be very careful when coding the specific rules into the Kconfig language, but it would be good to have a few people sanity-checking them. Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]> Index: linux-2.6/arch/powerpc/platforms/4xx/Kconfig === --- linux-2.6.orig/arch/powerpc/platforms/4xx/Kconfig +++ linux-2.6/arch/powerpc/platforms/4xx/Kconfig @@ -87,6 +87,7 @@ endmenu # 40x specific CPU modules, selected based on the board above. config NP405H bool + select CPU_405 #depends on ASH # OAK doesn't exist but wanted to keep this around for any future 403GCX boards @@ -94,6 +95,7 @@ config 403GCX bool #depends on OAK select IBM405_ERR51 + select CPU_403 config 405GP bool @@ -102,19 +104,23 @@ config 405GP config 405EP bool + select CPU_405 config 405GPR bool + select CPU_405 config VIRTEX_II_PRO bool select IBM405_ERR77 select IBM405_ERR51 + select CPU_405 config STB03xxx bool select IBM405_ERR77 select IBM405_ERR51 + select CPU_405 # 40x errata/workaround config symbols, selected by the CPU models above @@ -168,20 +174,25 @@ config 440EP bool select PPC_FPU select IBM440EP_ERR42 + select CPU_440 config 440GP bool select IBM_NEW_EMAC_ZMII + select CPU_440 config 440GX bool + select CPU_440 config 440SP bool + select CPU_440 config 440A bool depends on 440GX + select CPU_440 default y # 44x errata/workaround config symbols, selected by the CPU models above Index: linux-2.6/arch/powerpc/platforms/52xx/Kconfig === --- linux-2.6.orig/arch/powerpc/platforms/52xx/Kconfig +++ linux-2.6/arch/powerpc/platforms/52xx/Kconfig @@ -25,12 +25,14 @@ config PPC_EFIKA select RTAS_PROC select PPC_MPC52xx select PPC_NATIVE + select CPU_603e default n config PPC_LITE5200 bool "Freescale Lite5200 Eval Board" depends on PPC_MULTIPLATFORM && PPC32 select PPC_MPC5200 + select CPU_603e default n Index: linux-2.6/arch/powerpc/platforms/82xx/Kconfig === --- linux-2.6.orig/arch/powerpc/platforms/82xx/Kconfig +++ linux-2.6/arch/powerpc/platforms/82xx/Kconfig @@ -10,6 +10,7 @@ config MPC82xx_ADS select 8272 select 8260 select FSL_SOC + select CPU_603e help This option enables support for the MPC8272 ADS board Index: linux-2.6/arch/powerpc/platforms/83xx/Kconfig === --- linux-2.6.orig/arch/powerpc/platforms/83xx/Kconfig +++ linux-2.6/arch/powerpc/platforms/83xx/Kconfig @@ -6,6 +6,7 @@ choice config MPC8313_RDB bool "Freescale MPC8313 RDB" select DEFAULT_UIMAGE + select CPU_603e help This option enables support for the MPC8313 RDB board. @@ -13,6 +14,7 @@ config MPC832x_MDS bool "Freescale MPC832x MDS" select DEFAULT_UIMAGE select QUICC_ENGINE + select CPU_603e help This option enables support for the MPC832x MDS evaluation board. @@ -20,12 +22,14 @@ config MPC832x_RDB bool "Freescale MPC832x RDB" select DEFAULT_UIMAGE select QUICC_ENGINE + select CPU_603e help This option enables support for the MPC8323 RDB board. config MPC834x_MDS bool "Freescale MPC834x MDS" select DEFAULT_UIMAGE + select CPU_603e help This option enables support for the MPC 834x MDS evaluation board. @@ -37,6 +41,7 @@ config MPC834x_MDS config MPC834x_ITX bool "Freescale MPC834x ITX" select DEFAULT_UIMAGE + select CPU_603e help This option enables support for the MPC 834x ITX evalua
[PATCH 4/5] linkstation: fix multiplatform build
Jon Loeliger <[EMAIL PROTECTED]> wrote: X-Provags-ID: V01U2FsdGVkX19mfbfAMECjK3Yc4qnJalet5VRz84KpvPei34h Js67aIi1Jyt+C01bLuMxs+l5L4KLJuYYiIXI6fjXdktExWZ2WR fI/xi0tOHQX8AN87t62WA== > Hmmm... Shouldn't this sort of change come > with an update to the 8641 defconfig too? Content-Disposition: inline; filename=ls-fix-uart.diff The ls_uart file accidentally includes two headers from asm-ppc that are no longer needed but cause a broken build in some configurations. Kill the includes to fix the build. Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]> diff --git a/arch/powerpc/platforms/embedded6xx/ls_uart.c b/arch/powerpc/platforms/embedded6xx/ls_uart.c index d0bee9f..3b023b0 100644 --- a/arch/powerpc/platforms/embedded6xx/ls_uart.c +++ b/arch/powerpc/platforms/embedded6xx/ls_uart.c @@ -4,8 +4,6 @@ #include #include #include -#include -#include #include #include -- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/5] move 86xx into multiplatform
Jon Loeliger <[EMAIL PROTECTED]> wrote: X-Provags-ID: V01U2FsdGVkX18q0hUeUuMqOEeLWhKFlJn74HxEidaqOcemeHV ERKD3Oa64b/U3Jbpg7ScqVjTea/vrQYQQ9h6BX663cqWFlw9cZ acZ0zSjq49Kqfby7nRUgQ== > Hmmm... Shouldn't this sort of change come > with an update to the 8641 defconfig too? Content-Disposition: inline; filename=86xx-multi.diff MPC86xx based machines don't need their own kernel, but can run one that is shared with the other 6xx compatible machines, so we should allow that in Kconfig. Cc: Kumar Gala <[EMAIL PROTECTED]> Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]> --- Kumar, I don't remember if you still had objections to merging 86xx annd 83xx into multiplatform after our last discussion. Please Ack or Nack the two patches. Index: linux-2.6/arch/powerpc/platforms/86xx/Kconfig === --- linux-2.6.orig/arch/powerpc/platforms/86xx/Kconfig +++ linux-2.6/arch/powerpc/platforms/86xx/Kconfig @@ -1,18 +1,20 @@ -choice - prompt "86xx Board Type" - depends on PPC_86xx - default MPC8641_HPCN +config PPC_86xx + bool "Freescale 86xx based boards" + depends on 6xx + select FSL_SOC + select ALTIVEC + help + The Freescale E600 SoCs have 74xx cores. config MPC8641_HPCN bool "Freescale MPC8641 HPCN" + depends on PPC_86xx select PPC_I8259 select DEFAULT_UIMAGE select CPU_7450 help This option enables support for the MPC8641 HPCN board. -endchoice - config MPC8641 bool select PPC_INDIRECT_PCI Index: linux-2.6/arch/powerpc/platforms/Kconfig === --- linux-2.6.orig/arch/powerpc/platforms/Kconfig +++ linux-2.6/arch/powerpc/platforms/Kconfig @@ -23,13 +23,6 @@ config PPC_83xx select 83xx select WANT_DEVICE_TREE -config PPC_86xx - bool "Freescale 86xx" - depends on 6xx - select FSL_SOC - select ALTIVEC - help - The Freescale E600 SoCs have 74xx cores. endchoice config CLASSIC32 Index: linux-2.6/arch/powerpc/configs/mpc8641_hpcn_defconfig === --- linux-2.6.orig/arch/powerpc/configs/mpc8641_hpcn_defconfig +++ linux-2.6/arch/powerpc/configs/mpc8641_hpcn_defconfig @@ -1,9 +1,33 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.22-rc7 -# Sun Jul 1 23:57:00 2007 +# Fri Jul 13 20:08:07 2007 # # CONFIG_PPC64 is not set + +# +# Processor support +# +CONFIG_6xx=y +# CONFIG_PPC_85xx is not set +# CONFIG_PPC_8xx is not set +# CONFIG_40x is not set +# CONFIG_44x is not set +# CONFIG_E200 is not set +# CONFIG_PPC_CPU_SELECTION is not set +# CONFIG_CPU_601 is not set +# CONFIG_CPU_603e is not set +# CONFIG_CPU_750 is not set +# CONFIG_CPU_7400 is not set +CONFIG_CPU_7450=y +CONFIG_PPC_MCPU="-mcpu=7450" +CONFIG_PPC_FPU=y +CONFIG_ALTIVEC=y +CONFIG_PPC_STD_MMU=y +CONFIG_PPC_STD_MMU_32=y +# CONFIG_PPC_MM_SLICES is not set +CONFIG_SMP=y +CONFIG_NR_CPUS=2 CONFIG_PPC32=y CONFIG_PPC_MERGE=y CONFIG_MMU=y @@ -25,29 +49,8 @@ CONFIG_GENERIC_TBSYNC=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y CONFIG_DEFAULT_UIMAGE=y - -# -# Processor support -# -# CONFIG_CLASSIC32 is not set -# CONFIG_PPC_82xx is not set -# CONFIG_PPC_83xx is not set -# CONFIG_PPC_85xx is not set -CONFIG_PPC_86xx=y -# CONFIG_PPC_8xx is not set -# CONFIG_40x is not set -# CONFIG_44x is not set -# CONFIG_E200 is not set -CONFIG_6xx=y -CONFIG_PPC_FPU=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set -CONFIG_ALTIVEC=y -CONFIG_PPC_STD_MMU=y -CONFIG_PPC_STD_MMU_32=y -# CONFIG_PPC_MM_SLICES is not set -CONFIG_SMP=y -CONFIG_NR_CPUS=2 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # @@ -133,11 +136,20 @@ CONFIG_DEFAULT_IOSCHED="deadline" # # Platform support # +CONFIG_PPC_MULTIPLATFORM=y +# CONFIG_PPC_82xx is not set +# CONFIG_PPC_83xx is not set +CONFIG_CLASSIC32=y +# CONFIG_PPC_CHRP is not set # CONFIG_PPC_MPC52xx is not set # CONFIG_PPC_MPC5200 is not set +# CONFIG_PPC_EFIKA is not set +# CONFIG_PPC_LITE5200 is not set +# CONFIG_PPC_PMAC is not set # CONFIG_PPC_CELL is not set # CONFIG_PPC_CELL_NATIVE is not set # CONFIG_PQ2ADS is not set +CONFIG_PPC_86xx=y CONFIG_MPC8641_HPCN=y CONFIG_MPC8641=y CONFIG_MPIC=y @@ -150,6 +162,7 @@ CONFIG_PPC_I8259=y # CONFIG_PPC_INDIRECT_IO is not set # CONFIG_GENERIC_IOMAP is not set # CONFIG_CPU_FREQ is not set +# CONFIG_TAU is not set # CONFIG_CPM2 is not set # @@ -168,6 +181,7 @@ CONFIG_PREEMPT_BKL=y CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_MISC is not set CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y +# CONFIG_KEXEC is not set # CONFIG_IRQ_ALL_CPUS is not set CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_ARCH_POPULATES_NODE_MAP=y @@ -196,7 +210,6 @@ CONFIG_GENERIC_ISA_DMA=y CONFIG_PPC_INDIRECT_PCI=y CONFIG_PPC_INDIRECT_PCI_BE=y CONFIG_FSL_SOC=y -CONFIG_FSL_PCIE=y CONFIG_PCI=y CONFIG_PCI_DOMAINS=y
2.6.22 flash boot
With the release of the 2.6.22, our boards didn't boot anymore. I traced
the change back to 2.6.21-git10/2.6.21-git11.
The reason they didn't boot was that the kernel didn't detect the flash
where the root filesystem is stored on. The boards boot without an
initrd, directly from flash.
A file was removed (rom.c) and mentioned as obsolete in the ChangeLog.
att'd is the patch to restore the file against 2.6.22 since restoring
this file allow the boards to boot again (i.e. detect mtdblocks as
rootfilesystem).
Am I missing something here?
Judging by the dts files, a number of other boards seem to be using a
similar flash configuration as I do.
--
greetz, marc
That's your plan? Wile E. Coyote would come up with a better plan
than that!
Crichton - Throne for a Loss
chiana 2.6.18-4-ixp4xx #1 Tue Mar 27 18:01:56 BST 2007 GNU/Linux
---
arch/powerpc/sysdev/Makefile |1 +
arch/powerpc/sysdev/rom.c| 32
2 files changed, 33 insertions(+)
Index: linux-2.6.22/arch/powerpc/sysdev/Makefile
===
--- linux-2.6.22.orig/arch/powerpc/sysdev/Makefile
+++ linux-2.6.22/arch/powerpc/sysdev/Makefile
@@ -30,6 +30,7 @@
# Temporary hack until we have migrated to asm-powerpc
ifeq ($(ARCH),powerpc)
+obj-$(CONFIG_MTD) += rom.o
obj-$(CONFIG_CPM2) += cpm2_common.o cpm2_pic.o
obj-$(CONFIG_8xx) += mpc8xx_pic.o commproc.o
obj-$(CONFIG_UCODE_PATCH) += micropatch.o
Index: linux-2.6.22/arch/powerpc/sysdev/rom.c
===
--- /dev/null
+++ linux-2.6.22/arch/powerpc/sysdev/rom.c
@@ -0,0 +1,32 @@
+/*
+ * ROM device registration
+ *
+ * (C) 2006 MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+
+#include
+#include
+#include
+
+static int __init powerpc_flash_init(void)
+{
+ struct device_node *node = NULL;
+
+ /*
+ * Register all the devices which type is "rom"
+ */
+ while ((node = of_find_node_by_type(node, "rom")) != NULL) {
+ if (node->name == NULL) {
+ printk(KERN_WARNING "powerpc_flash_init: found 'rom' "
+"device, but with no name, skipping...\n");
+ continue;
+ }
+ of_platform_device_create(node, node->name, NULL);
+ }
+ return 0;
+}
+
+arch_initcall(powerpc_flash_init);
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Help required for porting ISP1362 usb device driver
On Thu, Jul 12, 2007 at 03:57:32PM -0700, Vikram Kone wrote: > >Hi.. >I'm a linux newbie and im working on porting the USB driver ISP1362 by >Philips on to my Freescale ppc board. >I dont know how to do this... so if any of you can tell me how to do this >step by step, i would be very grateful to you Try posting this question on the kernel newbies mailing list http://kernelnewbies.org/MailingList ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Use resource_size_t for serial port IO addresses
On Fri, 2007-07-13 at 12:02 -0700, Andrew Morton wrote: > On Fri, 13 Jul 2007 09:02:16 -0500 > Josh Boyer <[EMAIL PROTECTED]> wrote: > > > This is a resend of a patch David sent out on May 7. Without it, the > > PowerPC 44x port in 2.6.22 and on is broken. I've rebased it off of > > Linus' current tree. Please consider pushing this soon. > > > > josh > > > > > > At present, various parts of the serial code use unsigned long to > > define resource addresses. This is a problem, because some 32-bit > > platforms have physical addresses larger than 32-bits, and have mmio > > serial uarts located above the 4GB point. > > > > This patch changes the type of mapbase in both struct uart_port and > > struct plat_serial8250_port to resource_size_t, which can be > > configured to be 64 bits on such platforms. The mapbase in > > serial_struct can't safely be changed, because that structure is user > > visible. > > This is something we should do, but I have recollections of Russell > identifying problems with this patch, or at least an earlier version of it? I can't recall myself if there were problems or not. I thought David had worked that out with Russell, but I could be mistaken. > > Signed-off-by: David Gibson <[EMAIL PROTECTED]> > > This should have had Signed-off-by:you as well. Oops, for the rebase I suppose, yes. Is the one below enough or do you want me to resubmit? Signed-off-by: Josh Boyer <[EMAIL PROTECTED]> josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Use resource_size_t for serial port IO addresses
On Fri, 13 Jul 2007 09:02:16 -0500 Josh Boyer <[EMAIL PROTECTED]> wrote: > This is a resend of a patch David sent out on May 7. Without it, the > PowerPC 44x port in 2.6.22 and on is broken. I've rebased it off of > Linus' current tree. Please consider pushing this soon. > > josh > > > At present, various parts of the serial code use unsigned long to > define resource addresses. This is a problem, because some 32-bit > platforms have physical addresses larger than 32-bits, and have mmio > serial uarts located above the 4GB point. > > This patch changes the type of mapbase in both struct uart_port and > struct plat_serial8250_port to resource_size_t, which can be > configured to be 64 bits on such platforms. The mapbase in > serial_struct can't safely be changed, because that structure is user > visible. This is something we should do, but I have recollections of Russell identifying problems with this patch, or at least an earlier version of it? > Signed-off-by: David Gibson <[EMAIL PROTECTED]> This should have had Signed-off-by:you as well. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: questions about mpc82xx_ads and porting to other, similar, platform
On Fri, Jul 13, 2007 at 11:51:15AM +0300, Alexandros Kostopoulos wrote: > I am trying to port kernel 2.6.22.1 to my own platform, which incorporates > an mpc8275 chip. I'm using platform code for mpc82xx_ads as a template (is > this right in the first place?). I have a couple of questions: I suggest waiting until I can get my 8xx/82xx patchset out (which should happen early next week... it would have been earlier if I hadn't gotten distracted trying to get PCI to work right). It addresses the things you point out. > 1. mpc82xx_ads.c uses init_scc_ioports function to initialize the scc > uarts. However, this function is only used by the code in > arch/powerpc/sysdev/fsl_soc.c, and spefically in fs_enet_of_init(), > which is used to initialize the ethernet driver and not the cpm_uart > driver. On the other hand, cpm_uart_of_init() function seems to be the > one that initializes the uarts in cpm, and actually makes use of the > device-id, model, rx-clock and tx-clock properties of the scc nodes in > OF tree. So, AFAICT, init_scc_ioports should not be there, since it > won't be actually called at all (although I have not actually tested > this - I haven't yet managed to boot the kernel). Instead, > cpm_uart_of_init should take care of everything, except for the pport > initialization, which is done in u-boot anyway (at least in my case). > Any thoughts on this? All such port configuration callbacks are removed in my patchset; the bootloader and/or platform code is responsible for setting it up. > 2. I have also some questions regarding the device tree. Why are there two > nodes regarding the interrupt controller in there? There are two interrupt controllers on the mpc8272ads: one for PCI, and another for everything else. > and in the top level node, what does this property means: reg = > ; It means the device tree is buggy. It should say . > Finally, in the memory node, the reg property defines a second mem > region, (f450 f4500020). What is this? More device tree brokenness. It's the board control and status register block, which has nothing to do with memory. > maybe a special memory mapped peripheral of this board? If I have a > board with many mem configurations (e.g. it uses a DIMM SDRAM what can > be changed), what value should I place in the mem node? I have to > change dts every time I insert a new DIMM? No, u-boot or the bootwrapper should fill in the memory size. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] OProfile - Enable SPU switch notification to detect currently active SPU tasks
From: Maynard Johnson <[EMAIL PROTECTED]>
This patch adds to the capability of spu_switch_event_register so that the
caller is also notified of currently active SPU tasks. It also exports
spu_switch_event_register and spu_switch_event_unregister.
Signed-off-by: Maynard Johnson <[EMAIL PROTECTED]>
Signed-off-by: Carl Love <[EMAIL PROTECTED]>
Signed-off-by: Bob Nelson <[EMAIL PROTECTED]>
Acked-by: Arnd Bergmann <[EMAIL PROTECTED]>
Acked-by: Paul Mackerras <[EMAIL PROTECTED]>
---
We would like this patch included in -mm and 2.6.23.
Index: powerpc.git/arch/powerpc/platforms/cell/spufs/sched.c
===
--- powerpc.git.orig/arch/powerpc/platforms/cell/spufs/sched.c
+++ powerpc.git/arch/powerpc/platforms/cell/spufs/sched.c
@@ -204,21 +204,50 @@ static void spu_remove_from_active_list(
static BLOCKING_NOTIFIER_HEAD(spu_switch_notifier);
-static void spu_switch_notify(struct spu *spu, struct spu_context *ctx)
+void spu_switch_notify(struct spu *spu, struct spu_context *ctx)
{
blocking_notifier_call_chain(&spu_switch_notifier,
ctx ? ctx->object_id : 0, spu);
}
+static void notify_spus_active(void)
+{
+ int node;
+
+ /*
+* Wake up the active spu_contexts.
+*
+* When the awakened processes see their "notify_active" flag is set,
+* they will call spu_switch_notify();
+*/
+ for (node = 0; node < MAX_NUMNODES; node++) {
+ struct spu *spu;
+ mutex_lock(&spu_prio->active_mutex[node]);
+ list_for_each_entry(spu, &spu_prio->active_list[node], list) {
+ struct spu_context *ctx = spu->ctx;
+ set_bit(SPU_SCHED_NOTIFY_ACTIVE, &ctx->sched_flags);
+ mb();
+ wake_up_all(&ctx->stop_wq);
+ }
+ mutex_unlock(&spu_prio->active_mutex[node]);
+ }
+}
+
int spu_switch_event_register(struct notifier_block * n)
{
- return blocking_notifier_chain_register(&spu_switch_notifier, n);
+ int ret;
+ ret = blocking_notifier_chain_register(&spu_switch_notifier, n);
+ if (!ret)
+ notify_spus_active();
+ return ret;
}
+EXPORT_SYMBOL_GPL(spu_switch_event_register);
int spu_switch_event_unregister(struct notifier_block * n)
{
return blocking_notifier_chain_unregister(&spu_switch_notifier, n);
}
+EXPORT_SYMBOL_GPL(spu_switch_event_unregister);
/**
* spu_bind_context - bind spu context to physical spu
Index: powerpc.git/arch/powerpc/platforms/cell/spufs/spufs.h
===
--- powerpc.git.orig/arch/powerpc/platforms/cell/spufs/spufs.h
+++ powerpc.git/arch/powerpc/platforms/cell/spufs/spufs.h
@@ -53,6 +53,11 @@ enum spuctx_execution_state {
SPUCTX_UTIL_MAX
};
+/* ctx->sched_flags */
+enum {
+ SPU_SCHED_NOTIFY_ACTIVE,
+};
+
struct spu_context {
struct spu *spu; /* pointer to a physical SPU */
struct spu_state csa; /* SPU context save area. */
@@ -231,6 +236,7 @@ void spu_acquire_saved(struct spu_contex
int spu_activate(struct spu_context *ctx, unsigned long flags);
void spu_deactivate(struct spu_context *ctx);
void spu_yield(struct spu_context *ctx);
+void spu_switch_notify(struct spu *spu, struct spu_context *ctx);
void spu_set_timeslice(struct spu_context *ctx);
void spu_update_sched_info(struct spu_context *ctx);
void __spu_update_sched_info(struct spu_context *ctx);
Index: powerpc.git/arch/powerpc/platforms/cell/spufs/run.c
===
--- powerpc.git.orig/arch/powerpc/platforms/cell/spufs/run.c
+++ powerpc.git/arch/powerpc/platforms/cell/spufs/run.c
@@ -18,15 +18,17 @@ void spufs_stop_callback(struct spu *spu
wake_up_all(&ctx->stop_wq);
}
-static inline int spu_stopped(struct spu_context *ctx, u32 * stat)
+static inline int spu_stopped(struct spu_context *ctx, u32 *stat)
{
struct spu *spu;
u64 pte_fault;
*stat = ctx->ops->status_read(ctx);
- if (ctx->state != SPU_STATE_RUNNABLE)
- return 1;
+
spu = ctx->spu;
+ if (ctx->state != SPU_STATE_RUNNABLE ||
+ test_bit(SPU_SCHED_NOTIFY_ACTIVE, &ctx->sched_flags))
+ return 1;
pte_fault = spu->dsisr &
(MFC_DSISR_PTE_NOT_FOUND | MFC_DSISR_ACCESS_DENIED);
return (!(*stat & SPU_STATUS_RUNNING) || pte_fault ||
spu->class_0_pending) ?
@@ -124,7 +126,7 @@ out:
return ret;
}
-static int spu_run_init(struct spu_context *ctx, u32 * npc)
+static int spu_run_init(struct spu_context *ctx, u32 *npc)
{
if (ctx->flags & SPU_CREATE_ISOLATE) {
unsigned long runcntl;
@@ -154,8 +156,8 @@ static int spu_run_init(struct spu_conte
return 0;
}
-static int spu_run_fini(struct spu_context *ctx, u32 * npc
Re: [PATCH 3/4] pm: Handle HID0_SLEEP in the TLF_NAPPING hack.
Paul Mackerras wrote: > Scott Wood writes: > > >>The e300 core (and probably most other 6xx chips) can only come out of >>sleep mode with an interrupt. However, interrupts are logically disabled >>by the power management layer. > > > On powerbooks it's typically a hard reset rather than an interrupt. > Is it possible to use a hard reset on e300-based systems? The 8313 can do this (see the deep sleep portion of the 83xx PM patch that I posted), but others can't. Even on the 8313, it's not always desireable to use deep sleep, due to limited wakeup sourcers, higher latency, etc. > Also, if you use an interrupt, presumably the cpu has to do something > to clear the interrupt condition. What would that be? The caller's MSR[EE] is cleared in power_save_6xx_restore, so the interrupt won't happen again until the PM code re-enables MSR[EE]. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] PS3 improved video mode autodetection for HDMI/DVI
> > Since 720p is a broadcast mode, I can't make it default to fullscreen, as a > > part of the image will fall off on most monitors. > Do you have any info from the EDID block that would tell you whether the > monitor displays the full picture (typical of flat panels) or not ? That's not always true anyway. My 1680x1050 panel, for instance, displays 1080i/p and 720p as stretched images with the edges slightly off the screen. It's great for TV, but *really* irritating with the PS3! Cheers, Ralf. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] Kconfig cleanup revisited
On Fri, Jul 13, 2007 at 11:54:34AM +0200, Arnd Bergmann wrote: > On Friday 13 July 2007, Mark A. Greer wrote: > > I really like what you've done here, thanks. > > > > The patches don't apply straight up so what other patches do these go > > on top of? > > They are meant to apply on top of powerpc.git. Yep, me too. > I found now that > the first patch has a trivial reject against the for-2.6.23 branch, > but works fine for the master branch. Hrm, I'm on master and it doesn't apply but its minor so NBD. > Should I resend? Not for me but Paul might appreciate it. :) Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2.6.21-rt2] PowerPC: revert fix for threaded fasteoi IRQ handlers
Hello. Thomas Gleixner wrote: >>Now that the -rt patch has been first release in the broken-out version, >>let me tell you that the following 3 patches in the series can be just >>annihilated: >>preempt-irqs-ppc-ack-irq-fixups.patch >>preempt-irqs-ppc-fix-b5.patch >>preempt-irqs-ppc-fix-more-fasteoi.patch >>as all that the latter two are doing is undoing the former one. > Really ? I know for quite a while. Just reminding. :-) > We kept some of those files to document contributions. Go read back on > the LKML archives, where we were accused more than once not to keep > track of these things. Yeah, I figured that out. This case is somewhat special though since the patch that started this should't even have been there in the firts place. > They can be folded together and fixed up, one thing after the other > please. OK, no hurry. :-) > tglx WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
hvc_iseries not working
2.6.21 arch/powerpc/configs/iseries_defconfig works on an i825 with v5r4 2.6.22 arch/powerpc/configs/iseries_defconfig does not. But it works on a i820 with v5r3. 2.6.22 boots ok with CONFIG_VIOCONS It gets up to this point: vio_bus_init: processing c000fbfff570 vio_bus_init: processing c000fbfff6b0 vio_bus_init: processing c000fbfff7f0 vio_bus_init: processing c000fbfff930 vio_bus_init: processing c000fbfffa70 vio_bus_init: processing c000fbfffbb0 audit: initializing netlink socket (disabled) audit(1184327881.720:1): initialized io scheduler noop registered io scheduler anticipatory registered (default) io scheduler deadline registered io scheduler cfq registered viopath: opening connection to partition 0, setting sinst 32778, tinst 32769 hvc: hosting partition 0 vio_register_driver: driver hvc_console registering Generic RTC Driver v1.07 RAMDISK driver initialized: 16 RAM disks of 65536K size 1024 blo with ppc64_defconfig it looks like that: audit: initializing netlink socket (disabled) audit(1184326841.030:1): initialized VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 512 (order 0, 4096 bytes) io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) pci_hotplug: PCI Hot Plug PCI Core version: 0.5 rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1 rpadlpar_io_init: partition not DLPAR capable HVSI: registered 0 devices viopath: opening connection to partition 0, setting sinst 32774, tinst 32769 hvc: hosting partition 0 vio_register_driver: driver hvc_console registering Generic RTC Driver v1.07 Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
On Fri, Jul 13 2007, Geert Uytterhoeven wrote:
> > It's probably a good idea to have the flush_kernel_dcache_page() in there
> > anyway, if only to serve as an example for people that copy it into
> > architecture-independent drivers, same as what we do for the
> > k{,un}map_atomic() that is also not required on ppc64.
>
> Now my next question: why should I add it, if currently no single driver in
> mainline calls flush_kernel_dcache_page()?
>
> `git grep' finds it in the following files only:
> Documentation/cachetlb.txt
> arch/parisc/kernel/cache.c
> arch/parisc/kernel/pacache.S
> include/asm-parisc/cacheflush.h
> include/linux/highmem.h
Not many drivers fiddle around with stuff like this, it's usually hidden
behind the dma api or in helpers.
--
Jens Axboe
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/5] move 86xx into multiplatform
On Thu, 2007-07-12 at 16:02, Arnd Bergmann wrote: > MPC86xx based machines don't need their own kernel, > but can run one that is shared with the other 6xx > compatible machines, so we should allow that > in Kconfig. > > Cc: Kumar Gala <[EMAIL PROTECTED]> > Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]> > --- > > Kumar, I don't remember if you still had objections > to merging 86xx annd 83xx into multiplatform after > our last discussion. > Please Ack or Nack the two patches. Hmmm... Shouldn't this sort of change come with an update to the 8641 defconfig too? jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
On Fri, 2007-07-13 at 17:10 +0200, Geert Uytterhoeven wrote:
> On Fri, 13 Jul 2007, Arnd Bergmann wrote:
> > On Friday 13 July 2007, James Bottomley wrote:
> > > > IC.
> > > >
> > > > - flush_kernel_dcache_page() is a no-op on ppc64
> > > > (ARCH_HAS_FLUSH_KERNEL_DCACHE_PAGE is defined on parisc only).
> > > >
> > > > - For reference, drivers/scsi/ipr.c (another ppc64 driver) just uses a
> > > > plain
> > > > kmap/memcpy/kunmap sequence
> > > >
> > > > So what should I do?
> > >
> > > Ask someone who knows the architecture ... Anton, Paulus or Benh ... I'm
> > > fairly certain PPC is VIPT and will need some kind of alias
> > > resolution ... perhaps its associative enough not to let the aliases be
> > > a problem.
> >
> > I'm pretty sure that no ppc64 machine needs alias resolution in the kernel,
> > although some are VIPT. Last time we discussed this, Segher explained it
> > to me, but I don't remember which way Cell does it. IIRC, it automatically
> > flushes cache lines that are accessed through aliases.
>
> Thanks for confirming!
>
> > It's probably a good idea to have the flush_kernel_dcache_page() in there
> > anyway, if only to serve as an example for people that copy it into
> > architecture-independent drivers, same as what we do for the
> > k{,un}map_atomic() that is also not required on ppc64.
>
> Now my next question: why should I add it, if currently no single driver in
> mainline calls flush_kernel_dcache_page()?
>
> `git grep' finds it in the following files only:
> Documentation/cachetlb.txt
> arch/parisc/kernel/cache.c
> arch/parisc/kernel/pacache.S
> include/asm-parisc/cacheflush.h
> include/linux/highmem.h
It's a recent addition to the API ... the previous way of doing it was
flush_dcache_page() but that's expensive and flushes all the user
aliases. Since you know in this case there are no current user aliases
and you only need to flush the kernel alias, flush_kernel_dcache_page()
was introduced as the cheaper alternative.
James
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
On Fri, 13 Jul 2007, Arnd Bergmann wrote:
> On Friday 13 July 2007, James Bottomley wrote:
> > > IC.
> > >
> > > � - flush_kernel_dcache_page() is a no-op on ppc64
> > > � � (ARCH_HAS_FLUSH_KERNEL_DCACHE_PAGE is defined on parisc only).
> > >
> > > � - For reference, drivers/scsi/ipr.c (another ppc64 driver) just uses a
> > > plain
> > > � � kmap/memcpy/kunmap sequence
> > >
> > > So what should I do?
> >
> > Ask someone who knows the architecture ... Anton, Paulus or Benh ... I'm
> > fairly certain PPC is VIPT and will need some kind of alias
> > resolution ... perhaps its associative enough not to let the aliases be
> > a problem.
>
> I'm pretty sure that no ppc64 machine needs alias resolution in the kernel,
> although some are VIPT. Last time we discussed this, Segher explained it
> to me, but I don't remember which way Cell does it. IIRC, it automatically
> flushes cache lines that are accessed through aliases.
Thanks for confirming!
> It's probably a good idea to have the flush_kernel_dcache_page() in there
> anyway, if only to serve as an example for people that copy it into
> architecture-independent drivers, same as what we do for the
> k{,un}map_atomic() that is also not required on ppc64.
Now my next question: why should I add it, if currently no single driver in
mainline calls flush_kernel_dcache_page()?
`git grep' finds it in the following files only:
Documentation/cachetlb.txt
arch/parisc/kernel/cache.c
arch/parisc/kernel/pacache.S
include/asm-parisc/cacheflush.h
include/linux/highmem.h
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone:+32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: [EMAIL PROTECTED]
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
On Fri, Jul 13 2007, Geert Uytterhoeven wrote:
> On Fri, 13 Jul 2007, Jens Axboe wrote:
> > On Fri, Jul 13 2007, James Bottomley wrote:
> > > On Wed, 2007-07-04 at 15:22 +0200, Geert Uytterhoeven wrote:
> > > > + kaddr = kmap_atomic(sgpnt->page, KM_USER0);
> > > > + if (!kaddr)
> > > > + return -1;
> > > > + len = sgpnt->length;
> > > > + if ((req_len + len) > buflen) {
> > > > + active = 0;
> > > > + len = buflen - req_len;
> > > > + }
> > > > + memcpy(kaddr + sgpnt->offset, buf + req_len,
> > > > len);
> > > > + kunmap_atomic(kaddr, KM_USER0);
> > >
> > > This isn't a SCSI objection, but this sequence appears several times in
> > > this driver. It's wrong for a non-PIPT architecture (and I believe the
> > > PS3 is VIPT) because you copy into the kernel alias for the page, which
> > > dirties the line in the cache of that alias (the user alias cache line
> > > was already invalidated). However, unless you flush the kernel alias to
> > > main memory, the user could read stale data. The way this is supposed
> > > to be done is to do a
> > >
> > > flush_kernel_dcache_page(kaddr)
> > >
> > > before doing the kunmap.
> > >
> > > Otherwise it looks OK from the SCSI point of view.
>
> kmap() just returns page_address() on ppc64, as there's no highmem.
> kunmap() is a no-op.
>
> So technically I could just use page_address() directly, but Christoph wanted
> me to keep the kmap()/kunmap() sequence because it's considered a good
> practice.
If you have the kmap sequence there, put the flush in as well. People
copy code, you know... Or put a big comment explaining why it isn't
needed.
> > Well, even worse is that fact that it's using KM_USER0 from interrupt
> > context.
>
> So should I replace it by e.g. KM_IRQ0?
> I'm not so familiar with these parts, and I couldn't find what these values
> really mean.
You corrupt data, using KM_USER0 from interrupt context. So it's a big
flaw right now. Use KM_IRQ0 for code where interrupts are always
disabled.
--
Jens Axboe
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] Update mpc7448hpc2 device tree to be compatible fortsi109 chip
> > On Fri, 2007-07-13 at 11:58 +0800, Zang Roy-r61911 wrote: > > From: Roy Zang <[EMAIL PROTECTED]> > > > > Update mpc7448hpc2 device tree to be compatible for tsi109 chip. > > Are there any actual changes in the drivers or platform files for > tsi109? No! > I seem to recall that Linux treated tsi108 and tsi109 > identically at the moment. Your are right! > > If there are changes coming that differentiate tsi109 and > tsi108, please > CC me on those so I can update the Holly board as well. I will :-) Roy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
On Friday 13 July 2007, James Bottomley wrote:
>
> > IC.
> >
> > - flush_kernel_dcache_page() is a no-op on ppc64
> > (ARCH_HAS_FLUSH_KERNEL_DCACHE_PAGE is defined on parisc only).
> >
> > - For reference, drivers/scsi/ipr.c (another ppc64 driver) just uses a
> > plain
> > kmap/memcpy/kunmap sequence
> >
> > So what should I do?
>
> Ask someone who knows the architecture ... Anton, Paulus or Benh ... I'm
> fairly certain PPC is VIPT and will need some kind of alias
> resolution ... perhaps its associative enough not to let the aliases be
> a problem.
I'm pretty sure that no ppc64 machine needs alias resolution in the kernel,
although some are VIPT. Last time we discussed this, Segher explained it
to me, but I don't remember which way Cell does it. IIRC, it automatically
flushes cache lines that are accessed through aliases.
It's probably a good idea to have the flush_kernel_dcache_page() in there
anyway, if only to serve as an example for people that copy it into
architecture-independent drivers, same as what we do for the
k{,un}map_atomic() that is also not required on ppc64.
Arnd <><
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Use resource_size_t for serial port IO addresses
This is a resend of a patch David sent out on May 7. Without it, the
PowerPC 44x port in 2.6.22 and on is broken. I've rebased it off of
Linus' current tree. Please consider pushing this soon.
josh
At present, various parts of the serial code use unsigned long to
define resource addresses. This is a problem, because some 32-bit
platforms have physical addresses larger than 32-bits, and have mmio
serial uarts located above the 4GB point.
This patch changes the type of mapbase in both struct uart_port and
struct plat_serial8250_port to resource_size_t, which can be
configured to be 64 bits on such platforms. The mapbase in
serial_struct can't safely be changed, because that structure is user
visible.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
---
drivers/serial/8250.c|5 +++--
drivers/serial/8250_early.c | 16 +---
drivers/serial/serial_core.c |9 +
include/linux/serial_8250.h |2 +-
include/linux/serial_core.h |2 +-
5 files changed, 19 insertions(+), 15 deletions(-)
--- linux-2.6.orig/include/linux/serial_core.h
+++ linux-2.6/include/linux/serial_core.h
@@ -284,7 +284,7 @@ struct uart_port {
const struct uart_ops *ops;
unsigned intcustom_divisor;
unsigned intline; /* port index */
- unsigned long mapbase;/* for ioremap */
+ resource_size_t mapbase;/* for ioremap */
struct device *dev; /* parent device */
unsigned char hub6; /* this should be in
the 8250 driver */
unsigned char unused[3];
--- linux-2.6.orig/drivers/serial/serial_core.c
+++ linux-2.6/drivers/serial/serial_core.c
@@ -626,7 +626,7 @@ static int uart_get_info(struct uart_sta
tmp.hub6= port->hub6;
tmp.io_type = port->iotype;
tmp.iomem_reg_shift = port->regshift;
- tmp.iomem_base = (void *)port->mapbase;
+ tmp.iomem_base = (void *)(unsigned long)port->mapbase;
if (copy_to_user(retinfo, &tmp, sizeof(*retinfo)))
return -EFAULT;
@@ -1666,10 +1666,11 @@ static int uart_line_info(char *buf, str
return 0;
mmio = port->iotype >= UPIO_MEM;
- ret = sprintf(buf, "%d: uart:%s %s%08lX irq:%d",
+ ret = sprintf(buf, "%d: uart:%s %s%08llX irq:%d",
port->line, uart_type(port),
mmio ? "mmio:0x" : "port:",
- mmio ? port->mapbase : (unsigned long) port->iobase,
+ mmio ? (unsigned long long)port->mapbase
+: (unsigned long long) port->iobase,
port->irq);
if (port->type == PORT_UNKNOWN) {
@@ -2063,7 +2064,7 @@ uart_report_port(struct uart_driver *drv
case UPIO_TSI:
case UPIO_DWAPB:
snprintf(address, sizeof(address),
-"MMIO 0x%lx", port->mapbase);
+"MMIO 0x%llx", (unsigned long long)port->mapbase);
break;
default:
strlcpy(address, "*unknown*", sizeof(address));
--- linux-2.6.orig/drivers/serial/8250_early.c
+++ linux-2.6/drivers/serial/8250_early.c
@@ -145,8 +145,9 @@ static int __init parse_options(struct e
port->mapbase = simple_strtoul(options + 5, &options, 0);
port->membase = ioremap(port->mapbase, mapsize);
if (!port->membase) {
- printk(KERN_ERR "%s: Couldn't ioremap 0x%lx\n",
- __FUNCTION__, port->mapbase);
+ printk(KERN_ERR "%s: Couldn't ioremap 0x%llx\n",
+ __FUNCTION__,
+ (unsigned long long)port->mapbase);
return -ENOMEM;
}
mmio = 1;
@@ -168,9 +169,10 @@ static int __init parse_options(struct e
device->baud);
}
- printk(KERN_INFO "Early serial console at %s 0x%lx (options '%s')\n",
+ printk(KERN_INFO "Early serial console at %s 0x%llx (options '%s')\n",
mmio ? "MMIO" : "I/O port",
- mmio ? port->mapbase : (unsigned long) port->iobase,
+ mmio ? (unsigned long long) port->mapbase
+: (unsigned long long) port->iobase,
device->options);
return 0;
}
@@ -236,10 +238,10 @@ static int __init early_uart_console_swi
mmio = (port->iotype == UPIO_MEM);
line = serial8250_start_console(port, device->options);
if (line < 0)
- printk("No ttyS device at %s 0x%lx for console\n",
+ printk("No ttyS device at %s 0x%llx for console\n",
mmio ? "MMIO" : "I/O port",
- mmio ? port->mapbase :
- (unsigned long) port->io
Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
On Fri, 2007-07-13 at 15:45 +0200, Geert Uytterhoeven wrote: > On Fri, 13 Jul 2007, James Bottomley wrote: > > On Fri, 2007-07-13 at 15:25 +0200, Geert Uytterhoeven wrote: > > > kmap() just returns page_address() on ppc64, as there's no highmem. > > > kunmap() is a no-op. > > > > > So technically I could just use page_address() directly, but Christoph > > > wanted > > > me to keep the kmap()/kunmap() sequence because it's considered a good > > > practice. > > > > The point isn't what kmap and kunmap do ... it's the addresses they > > return. By and large, a kernel virtual address for a page is different > > from the user virtual address. If the cache is virtually indexed you > > get different cache lines for the same page ... and that sets you up > > with aliases you need to resolve. parisc is the same ... our > > kmap/kunmap are nops as well, but our kernel virtual addresses are still > > different from the user virtual ones. > > IC. > > - flush_kernel_dcache_page() is a no-op on ppc64 > (ARCH_HAS_FLUSH_KERNEL_DCACHE_PAGE is defined on parisc only). > > - For reference, drivers/scsi/ipr.c (another ppc64 driver) just uses a plain > kmap/memcpy/kunmap sequence > > So what should I do? Ask someone who knows the architecture ... Anton, Paulus or Benh ... I'm fairly certain PPC is VIPT and will need some kind of alias resolution ... perhaps its associative enough not to let the aliases be a problem. James ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
On Fri, 13 Jul 2007, James Bottomley wrote: > On Fri, 2007-07-13 at 15:25 +0200, Geert Uytterhoeven wrote: > > kmap() just returns page_address() on ppc64, as there's no highmem. > > kunmap() is a no-op. > > > So technically I could just use page_address() directly, but Christoph > > wanted > > me to keep the kmap()/kunmap() sequence because it's considered a good > > practice. > > The point isn't what kmap and kunmap do ... it's the addresses they > return. By and large, a kernel virtual address for a page is different > from the user virtual address. If the cache is virtually indexed you > get different cache lines for the same page ... and that sets you up > with aliases you need to resolve. parisc is the same ... our > kmap/kunmap are nops as well, but our kernel virtual addresses are still > different from the user virtual ones. IC. - flush_kernel_dcache_page() is a no-op on ppc64 (ARCH_HAS_FLUSH_KERNEL_DCACHE_PAGE is defined on parisc only). - For reference, drivers/scsi/ipr.c (another ppc64 driver) just uses a plain kmap/memcpy/kunmap sequence So what should I do? With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
On Fri, 2007-07-13 at 15:25 +0200, Geert Uytterhoeven wrote: > kmap() just returns page_address() on ppc64, as there's no highmem. > kunmap() is a no-op. > So technically I could just use page_address() directly, but Christoph > wanted > me to keep the kmap()/kunmap() sequence because it's considered a good > practice. The point isn't what kmap and kunmap do ... it's the addresses they return. By and large, a kernel virtual address for a page is different from the user virtual address. If the cache is virtually indexed you get different cache lines for the same page ... and that sets you up with aliases you need to resolve. parisc is the same ... our kmap/kunmap are nops as well, but our kernel virtual addresses are still different from the user virtual ones. James ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PS3 Storage Driver O_DIRECT issue
On Fri, 13 Jul 2007, Olaf Hering wrote: > This driver (or the generic PS3 code) has appearently problems with > O_DIRECT. > glibc aborts parted because the malloc metadata get corrupted. While it > is reproducible, the place where it crashes changes with every version > of the debug attempt. > I dont have a handle right now, all I know is that the metadata after a > malloc area get overwritten with zeros. > > > Can you have a look at this? > parted /dev/ps3da > print (a few times) I can't seem to reproduce this with parted 1.7.1-5.1 (from Debian etch/lenny/sid) and kernel 2.6.22-g77320894. With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Enable SPU switch notification to detect currently active SPU tasks.
On Fri, Jul 13, 2007 at 12:12:33PM +0200, Christoph Hellwig wrote: > > -static inline int spu_stopped(struct spu_context *ctx, u32 * stat) > > +static inline int spu_stopped(struct spu_context *ctx, u32 *stat) > > useless (and wrong) reformatting, please remove. Sorry, this looked like going the wrong way to me. I'm still not sure the reformatting belongs into this patch, but if it makes it easier for you we can keep it. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
On Fri, 13 Jul 2007, Jens Axboe wrote:
> On Fri, Jul 13 2007, James Bottomley wrote:
> > On Wed, 2007-07-04 at 15:22 +0200, Geert Uytterhoeven wrote:
> > > + kaddr = kmap_atomic(sgpnt->page, KM_USER0);
> > > + if (!kaddr)
> > > + return -1;
> > > + len = sgpnt->length;
> > > + if ((req_len + len) > buflen) {
> > > + active = 0;
> > > + len = buflen - req_len;
> > > + }
> > > + memcpy(kaddr + sgpnt->offset, buf + req_len,
> > > len);
> > > + kunmap_atomic(kaddr, KM_USER0);
> >
> > This isn't a SCSI objection, but this sequence appears several times in
> > this driver. It's wrong for a non-PIPT architecture (and I believe the
> > PS3 is VIPT) because you copy into the kernel alias for the page, which
> > dirties the line in the cache of that alias (the user alias cache line
> > was already invalidated). However, unless you flush the kernel alias to
> > main memory, the user could read stale data. The way this is supposed
> > to be done is to do a
> >
> > flush_kernel_dcache_page(kaddr)
> >
> > before doing the kunmap.
> >
> > Otherwise it looks OK from the SCSI point of view.
kmap() just returns page_address() on ppc64, as there's no highmem.
kunmap() is a no-op.
So technically I could just use page_address() directly, but Christoph wanted
me to keep the kmap()/kunmap() sequence because it's considered a good
practice.
> Well, even worse is that fact that it's using KM_USER0 from interrupt
> context.
So should I replace it by e.g. KM_IRQ0?
I'm not so familiar with these parts, and I couldn't find what these values
really mean.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone:+32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: [EMAIL PROTECTED]
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] PS3 improved video mode autodetection for HDMI/DVI
On Fri, 13 Jul 2007, Benjamin Herrenschmidt wrote: > > Since 720p is a broadcast mode, I can't make it default to fullscreen, as a > > part of the image will fall off on most monitors. > > Do you have any info from the EDID block that would tell you whether the > monitor displays the full picture (typical of flat panels) or not ? No, all I have is struct ps3av_info_monitor. With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Update mpc7448hpc2 device tree to be compatible for tsi109 chip
On Fri, 2007-07-13 at 11:58 +0800, Zang Roy-r61911 wrote: > From: Roy Zang <[EMAIL PROTECTED]> > > Update mpc7448hpc2 device tree to be compatible for tsi109 chip. Are there any actual changes in the drivers or platform files for tsi109? I seem to recall that Linux treated tsi108 and tsi109 identically at the moment. If there are changes coming that differentiate tsi109 and tsi108, please CC me on those so I can update the Holly board as well. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
On Fri, Jul 13 2007, James Bottomley wrote:
> On Wed, 2007-07-04 at 15:22 +0200, Geert Uytterhoeven wrote:
> > + kaddr = kmap_atomic(sgpnt->page, KM_USER0);
> > + if (!kaddr)
> > + return -1;
> > + len = sgpnt->length;
> > + if ((req_len + len) > buflen) {
> > + active = 0;
> > + len = buflen - req_len;
> > + }
> > + memcpy(kaddr + sgpnt->offset, buf + req_len,
> > len);
> > + kunmap_atomic(kaddr, KM_USER0);
>
> This isn't a SCSI objection, but this sequence appears several times in
> this driver. It's wrong for a non-PIPT architecture (and I believe the
> PS3 is VIPT) because you copy into the kernel alias for the page, which
> dirties the line in the cache of that alias (the user alias cache line
> was already invalidated). However, unless you flush the kernel alias to
> main memory, the user could read stale data. The way this is supposed
> to be done is to do a
>
> flush_kernel_dcache_page(kaddr)
>
> before doing the kunmap.
>
> Otherwise it looks OK from the SCSI point of view.
Well, even worse is that fact that it's using KM_USER0 from interrupt
context.
--
Jens Axboe
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
On Wed, 2007-07-04 at 15:22 +0200, Geert Uytterhoeven wrote:
> + kaddr = kmap_atomic(sgpnt->page, KM_USER0);
> + if (!kaddr)
> + return -1;
> + len = sgpnt->length;
> + if ((req_len + len) > buflen) {
> + active = 0;
> + len = buflen - req_len;
> + }
> + memcpy(kaddr + sgpnt->offset, buf + req_len,
> len);
> + kunmap_atomic(kaddr, KM_USER0);
This isn't a SCSI objection, but this sequence appears several times in
this driver. It's wrong for a non-PIPT architecture (and I believe the
PS3 is VIPT) because you copy into the kernel alias for the page, which
dirties the line in the cache of that alias (the user alias cache line
was already invalidated). However, unless you flush the kernel alias to
main memory, the user could read stale data. The way this is supposed
to be done is to do a
flush_kernel_dcache_page(kaddr)
before doing the kunmap.
Otherwise it looks OK from the SCSI point of view.
James
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Enable SPU switch notification to detect currently active SPU tasks.
On Fri, Jul 13, 2007 at 10:34:50PM +1000, Benjamin Herrenschmidt wrote:
>
> > > + if (unlikely(test_bit(SPU_SCHED_NOTIFY_ACTIVE,
> > > + &ctx->sched_flags))) {
> > > + clear_bit(SPU_SCHED_NOTIFY_ACTIVE, &ctx->sched_flags);
> >
> > this should use test_and_clear_bit
>
> This also looks like an abuse of atomics to effectively implement a lock
> or did I miss something ?
not really. We set a flag on the context to make sure some action is
performed when it comes through spu_run the next time. It's not exactly
elegant, but cleaning this up will have to wait for the grand spu_run
rewrite.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Enable SPU switch notification to detect currently active SPU tasks.
> > + if (unlikely(test_bit(SPU_SCHED_NOTIFY_ACTIVE,
> > + &ctx->sched_flags))) {
> > + clear_bit(SPU_SCHED_NOTIFY_ACTIVE, &ctx->sched_flags);
>
> this should use test_and_clear_bit
This also looks like an abuse of atomics to effectively implement a lock
or did I miss something ?
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] PS3 improved video mode autodetection for HDMI/DVI
> Since 720p is a broadcast mode, I can't make it default to fullscreen, as a > part of the image will fall off on most monitors. Do you have any info from the EDID block that would tell you whether the monitor displays the full picture (typical of flat panels) or not ? Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
PS3 Storage Driver O_DIRECT issue
This driver (or the generic PS3 code) has appearently problems with O_DIRECT. glibc aborts parted because the malloc metadata get corrupted. While it is reproducible, the place where it crashes changes with every version of the debug attempt. I dont have a handle right now, all I know is that the metadata after a malloc area get overwritten with zeros. Can you have a look at this? parted /dev/ps3da print (a few times) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] PS3 improved video mode autodetection for HDMI/DVI
Hi H�vard,
> On Thu, Jul 12, 2007 at 05:12:43PM +0200, Geert Uytterhoeven wrote:
> > On Thu, 12 Jul 2007, [iso-8859-1] H?vard Espeland wrote:
> > > On Thu, Jul 12, 2007 at 10:40:47AM +0200, Geert Uytterhoeven wrote:
> > > > If it fails, please add `#define DEBUG' to drivers/ps3/ps3av.c, send me
> > > > the
> > > > `Monitor Info' output in the kernel log (dmesg), and tell me which of
> > > > the
> > > > PS3 video modes (1-13) work and which don't. ps3av has a quirk database
> > > > for
> > > > monitors that advertise non-working modes, so it can probably be fixed.
> > > > (BTW, even if autodetect works fine, I always welcome this information)
> > > >
> > > > In case you have a big pile of monitors at your site, you don't have to
> > > > reboot
> > > > to try them all. Just plug in the new monitor and run `ps3videomode -v
> > > > 0' to
> > > > switch to the best resolution of the newly-connected monitor.
> > >
> > > Hi, the autodetect code does not work correctly with a LG L226WTQ
> > So your monitor advertises:
> >
> > Supported 60 Hz modes: 1080p 480p 720p 1080i (400d)
> > Supported VESA modes:VGA (0001)
> >
> > But 1080p and 1080i don't work. As 1080p is the best advertised mode, you
> > don't
> > get anything to see :-(
> >
> > Does this patch help? It should give you 720p by default.
> >
> > Index: ps3-linux-2.6/drivers/ps3/ps3av.c
> > ===
> > --- ps3-linux-2.6.orig/drivers/ps3/ps3av.c 2007-07-12 10:26:33.0
> > +0200
> > +++ ps3-linux-2.6/drivers/ps3/ps3av.c 2007-07-12 16:57:39.0
> > +0200
> > @@ -720,6 +720,10 @@ static const struct ps3av_monitor_quirk
> > {
> > .monitor_name = "DELL 2007WFP",
> > .clear_60 = PS3AV_RESBIT_1920x1080I
> > + }, {
> > + .monitor_name = "L226WTQ",
> > + .clear_60 = PS3AV_RESBIT_1920x1080I |
> > + PS3AV_RESBIT_1920x1080P
> > }
> > };
> >
>
> The patch gives me a picture, but it does not cover the whole screen.
> Ps3videomode returns mode 67, and if i add 128 to that number I get
Yep, 720p. Good.
> working fullscreen. Additionally, the break in ps3av_fixup_monitor_info
Since 720p is a broadcast mode, I can't make it default to fullscreen, as a
part of the image will fall off on most monitors.
> is misplaced and will only try the first quirk.
Woops, fixed, thanks!
> ps3av_hdmi_get_vid: Using supported resolution 9
>
> --
> H�vard Espeland
>
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone:+32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: [EMAIL PROTECTED]
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Enable SPU switch notification to detect currently active SPU tasks.
On Fri, Jul 13, 2007 at 12:12:33PM +0200, Christoph Hellwig wrote: > On Thu, Jul 12, 2007 at 06:45:40PM -0500, Bob Nelson wrote: > > We would like this patch included in -mm and in 2.6.23. > > Do you plan to submit oprofile support aswell? In that case it's fine > otherwise please send it together with the actual oprofile support. I just saw the oprofile patch is next, so this is okay. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] Implement arch disable/enable irq hooks.
On Thu, 2007-07-12 at 14:12 -0500, Scott Wood wrote: > +void generic_suspend_disable_irqs(void) > +void generic_suspend_enable_irqs(void) Oh hm on second thought, can we have these in some header file so we can call them if we need to use the ppc_md hooks? johannes signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] Implement arch disable/enable irq hooks.
On Thu, 2007-07-12 at 14:12 -0500, Scott Wood wrote:
> These hooks ensure that a decrementer interrupt is not pending when
> suspending; otherwise, problems may occur. For example, with deep sleep
> on the 831x, a pending decrementer will cause a system freeze because the
> SoC thinks the decrementer interrupt would have woken the system, but the
> core must have interrupts disabled due to the setup required for deep
> sleep.
> +/* Overrides the weak version in kernel/power/main.c */
> +void arch_suspend_disable_irqs(void)
> +{
> + if (ppc_md.suspend_disable_irqs)
> + ppc_md.suspend_disable_irqs();
> + else
> + generic_suspend_disable_irqs();
> +}
Looks good to me, thanks for the update with ppc_md.
johannes
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Enable SPU switch notification to detect currently active SPU tasks.
On Thu, Jul 12, 2007 at 06:45:40PM -0500, Bob Nelson wrote:
> We would like this patch included in -mm and in 2.6.23.
Do you plan to submit oprofile support aswell? In that case it's fine
otherwise please send it together with the actual oprofile support.
> +static void notify_spus_active(void)
> +{
> + int node;
> + /* Wake up the active spu_contexts. When the awakened processes
> + * see their "notify_active" flag is set, they will call
> + * spu_switch_notify();
> + */
Small style issue, this should be:
int node;
/*
* Wake up the active spu_contexts.
*
* When the awakened processes see their "notify_active" flag is set,
* they will call spu_switch_notify().
*/
> -static inline int spu_stopped(struct spu_context *ctx, u32 * stat)
> +static inline int spu_stopped(struct spu_context *ctx, u32 *stat)
useless (and wrong) reformatting, please remove.
> -static int spu_run_init(struct spu_context *ctx, u32 * npc)
> +static int spu_run_init(struct spu_context *ctx, u32 *npc)
Same here.
> -static int spu_run_fini(struct spu_context *ctx, u32 * npc,
> -u32 * status)
> +static int spu_run_fini(struct spu_context *ctx, u32 *npc,
> +u32 *status)
Same here.
> + if (unlikely(test_bit(SPU_SCHED_NOTIFY_ACTIVE,
> + &ctx->sched_flags))) {
> + clear_bit(SPU_SCHED_NOTIFY_ACTIVE, &ctx->sched_flags);
this should use test_and_clear_bit
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] Add PCI/PCI Express node for 8544DS board]
From: Roy Zang <[EMAIL PROTECTED]>
Add PCI/PCI Express node for 8544DS board.
---
arch/powerpc/boot/dts/mpc8544ds.dts | 211 +++
1 files changed, 211 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8544ds.dts
b/arch/powerpc/boot/dts/mpc8544ds.dts
index 43bf5c1..aab0bc6 100644
--- a/arch/powerpc/boot/dts/mpc8544ds.dts
+++ b/arch/powerpc/boot/dts/mpc8544ds.dts
@@ -143,6 +143,217 @@
fsl,has-rstcr;
};
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc8540-pci";
+ device_type = "pci";
+ interrupt-map-mask = ;
+ interrupt-map = <
+
+ /* IDSEL 0x11 J17 Slot 1 */
+ 8800 0 0 1 &mpic 2 1
+ 8800 0 0 2 &mpic 3 1
+ 8800 0 0 3 &mpic 4 1
+ 8800 0 0 4 &mpic 1 1
+
+ /* IDSEL 0x12 J16 Slot 2 */
+
+ 9000 0 0 1 &mpic 3 1
+ 9000 0 0 2 &mpic 4 1
+ 9000 0 0 3 &mpic 2 1
+ 9000 0 0 4 &mpic 1 1>;
+
+ interrupt-parent = <&mpic>;
+ interrupts = <18 2>;
+ bus-range = <0 ff>;
+ ranges = <0200 0 8000 8000 0 1000
+ 0100 0 e200 0 0080>;
+ clock-frequency = <3f940aa>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <8000 1000>;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc8548-pcie";
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = ;
+ bus-range = <0 ff>;
+ ranges = <0200 0 9000 9000 0 1000
+ 0100 0 e280 0 0080>;
+ clock-frequency = <1fca055>;
+ interrupt-parent = <&mpic>;
+ interrupts = <19 2>;
+ interrupt-map-mask = ;
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0 0 1 &mpic 0 1
+ 0 0 2 &mpic 1 1
+ 0 0 3 &mpic 2 1
+ 0 0 4 &mpic 3 1
+ >;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc8548-pcie";
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <9000 1000>;
+ bus-range = <0 ff>;
+ ranges = <0200 0 a000 a000 0 1000
+ 0100 0 e300 0 0080>;
+ clock-frequency = <1fca055>;
+ interrupt-parent = <&mpic>;
+ interrupts = <1a 2>;
+ interrupt-map-mask = ;
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0 0 1 &mpic 4 1
+ 0 0 2 &mpic 5 1
+ 0 0 3 &mpic 6 1
+ 0 0 4 &mpic 7 1
+ >;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc8548-pcie";
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = ;
+ bus-range = <0 ff>;
+ ranges = <0200 0 b000 b000 0 1000
+ 0100 0 e380 0 0080>;
+ clock-frequency = <1fca055>;
+ interrupt-parent = <&mpic>;
+ interrupts = <1b 2>;
+ interrupt-map-mask = ;
+ interrupt-map = <
+
+ // IDSEL 0x1a
+ d000 0 0 1 &i8259 6 2
+ d000 0 0 2 &i8259 3 2
+ d000 0 0 3 &i8259 4 2
+ d000 0 0 4 &i8259 5 2
+
+ // IDSEL 0x1
[PATCH 1/2] Add basic PCI /PCI Express support for 8544DS board
From: Roy Zang <[EMAIL PROTECTED]>
Add basic PCI/PCI Express support for 8544DS board.
Signed-off-by: York Sun <[EMAIL PROTECTED]>
Signed-off-by: Roy Zang <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/85xx/Kconfig |1 +
arch/powerpc/platforms/85xx/mpc8544_ds.c | 252 ++
2 files changed, 253 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/Kconfig
b/arch/powerpc/platforms/85xx/Kconfig
index 526ddde..6729e12 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -30,6 +30,7 @@ config MPC85xx_MDS
config MPC8544_DS
bool "Freescale MPC8544 DS"
+ select PPC_I8259
select DEFAULT_UIMAGE
help
This option enables support for the MPC8544 DS board
diff --git a/arch/powerpc/platforms/85xx/mpc8544_ds.c
b/arch/powerpc/platforms/85xx/mpc8544_ds.c
index 6fb90aa..e5ec8dd 100644
--- a/arch/powerpc/platforms/85xx/mpc8544_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc8544_ds.c
@@ -2,6 +2,8 @@
* MPC8544 DS Board Setup
*
* Author Xianghua Xiao ([EMAIL PROTECTED])
+ * Roy Zang <[EMAIL PROTECTED]>
+ * - Add PCI/PCI Exprees support
* Copyright 2007 Freescale Semiconductor Inc.
*
* This program is free software; you can redistribute it and/or modify it
@@ -12,13 +14,16 @@
#include
#include
+#include
#include
#include
#include
+#include
#include
#include
#include
+#include
#include
#include
#include
@@ -27,6 +32,7 @@
#include
#include
+#include
#include "mpc85xx.h"
#undef DEBUG
@@ -37,6 +43,17 @@
#define DBG(fmt, args...)
#endif
+#ifdef CONFIG_PPC_I8259
+static void mpc8544_8259_cascade(unsigned int irq, struct irq_desc *desc)
+{
+ unsigned int cascade_irq = i8259_irq();
+
+ if (cascade_irq != NO_IRQ) {
+ generic_handle_irq(cascade_irq);
+ }
+ desc->chip->eoi(irq);
+}
+#endif /* CONFIG_PPC_I8259 */
void __init mpc8544_ds_pic_init(void)
{
@@ -96,18 +113,252 @@ void __init mpc8544_ds_pic_init(void)
#endif /* CONFIG_PPC_I8259 */
}
+#ifdef CONFIG_PCI
+enum pirq { PIRQA = 8, PIRQB, PIRQC, PIRQD, PIRQE, PIRQF, PIRQG, PIRQH };
+
+/*
+ * Value in table -- IRQ number
+ */
+const unsigned char uli1575_irq_route_table[16] = {
+ 0, /* 0: Reserved */
+ 0x8,
+ 0, /* 2: Reserved */
+ 0x2,
+ 0x4,
+ 0x5,
+ 0x7,
+ 0x6,
+ 0, /* 8: Reserved */
+ 0x1,
+ 0x3,
+ 0x9,
+ 0xb,
+ 0, /* 13: Reserved */
+ 0xd,
+ 0xf,
+};
+
+static int __devinit
+get_pci_irq_from_of(struct pci_controller *hose, int slot, int pin)
+{
+ struct of_irq oirq;
+ u32 laddr[3];
+ struct device_node *hosenode = hose ? hose->arch_data : NULL;
+
+ if (!hosenode)
+ return -EINVAL;
+
+ laddr[0] = (hose->first_busno << 16) | (PCI_DEVFN(slot, 0) << 8);
+ laddr[1] = laddr[2] = 0;
+ of_irq_map_raw(hosenode, &pin, 1, laddr, &oirq);
+ DBG("mpc8544_ds: pci irq addr %x, slot %d, pin %d, irq %d\n",
+ laddr[0], slot, pin, oirq.specifier[0]);
+ return oirq.specifier[0];
+}
+
+/*8259*/
+static void __devinit quirk_uli1575(struct pci_dev *dev)
+{
+ unsigned short temp;
+ struct pci_controller *hose = pci_bus_to_host(dev->bus);
+ unsigned char irq2pin[16];
+ unsigned long pirq_map_word = 0;
+ u32 irq;
+ int i;
+
+ /*
+* ULI1575 interrupts route setup
+*/
+ memset(irq2pin, 0, 16); /* Initialize default value 0 */
+
+ irq2pin[6]=PIRQA+3; /* enabled mapping for IRQ6 to PIRQD, used by
SATA */
+
+ /*
+* PIRQE -> PIRQF mapping set manually
+*
+* IRQ pin IRQ#
+* PIRQE 9
+* PIRQF 10
+* PIRQG 11
+* PIRQH 12
+*/
+ for (i = 0; i < 4; i++)
+ irq2pin[i + 9] = PIRQE + i;
+
+ /* Set IRQ-PIRQ Mapping to ULI1575 */
+ for (i = 0; i < 16; i++)
+ if (irq2pin[i])
+ pirq_map_word |= (uli1575_irq_route_table[i] & 0xf)
+ << ((irq2pin[i] - PIRQA) * 4);
+
+ pirq_map_word |= 1<<26; /* disable INTx in EP mode*/
+
+ /* ULI1575 IRQ mapping conf register default value is 0xb9317542 */
+ DBG("Setup ULI1575 IRQ mapping configuration register value = 0x%x\n",
+ (int)pirq_map_word);
+ pci_write_config_dword(dev, 0x48, pirq_map_word);
+
+#define ULI1575_SET_DEV_IRQ(slot, pin, reg)\
+ do {\
+ int irq;\
+ irq = get_pci_irq_from_of(hose, slot, pin); \
+ if (irq > 0 && irq < 16)\
+ pci_write_config_byte(dev, reg, irq2pin[irq]); \
+
[PATCH 0/2] Add basic PCI/PCI express support for 8544DS board
These two patches add basic PCI/PCI Express support for 8544DS board. These patches are based on current Kumar's tree for_paulus. Roy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add support to OProfile for profiling Cell BE SPUs
On Friday 13 July 2007, Bob Nelson wrote: > We would like this patch included in -mm and 2.6.23. > > Subject: Add support to OProfile for profiling Cell BE SPUs > > From: Maynard Johnson <[EMAIL PROTECTED]> > Bob Nelson <[EMAIL PROTECTED]> > The patch itself looks ok, but unfortunately, you have a few formal mistakes in the submission. Most importantly, the long lines got wrapped by your mail client, so it won't apply. About the start of the mail, please put the 'We would like to...' part and everything else that is not supposed to show up in the changelog _below_ the introduction, separated from the changelog with a single line containing the string '---'. The Subject: line should not be in the mail body, it's only used if you want to use the 'quilt mail' tool, which will move it to the real subject of the mail. The From: line can only have one name in it. If you want to give credit to multiple people, that should be in the changelog text. Please resend. Arnd <>< > This patch updates the existing arch/powerpc/oprofile/op_model_cell.c > to add in the SPU profiling capabilities. In addition, a 'cell' > subdirectory > was added to arch/powerpc/oprofile to hold Cell-specific SPU profiling > code. > Also incorporated several fixes from other patches. Check pointer > returned from kzalloc. Eliminated unnecessary cast. Better error > handling and cleanup in the related area. 64-bit unsigned long > parameter > was being demoted to 32-bit unsigned int and eventually promoted back to > unsigned long. > > Signed-off-by: Carl Love <[EMAIL PROTECTED]> > Signed-off-by: Maynard Johnson <[EMAIL PROTECTED]> > Signed-off-by: Bob Nelson <[EMAIL PROTECTED]> > Acked-by: Arnd Bergmann <[EMAIL PROTECTED]> > Acked-by: Paul Mackerras <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] Kconfig cleanup revisited
On Friday 13 July 2007, Mark A. Greer wrote: > I really like what you've done here, thanks. > > The patches don't apply straight up so what other patches do these go > on top of? They are meant to apply on top of powerpc.git. I found now that the first patch has a trivial reject against the for-2.6.23 branch, but works fine for the master branch. Should I resend? Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] PS3 improved video mode autodetection for HDMI/DVI
On Thu, Jul 12, 2007 at 05:12:43PM +0200, Geert Uytterhoeven wrote:
> On Thu, 12 Jul 2007, [iso-8859-1] H?vard Espeland wrote:
> > On Thu, Jul 12, 2007 at 10:40:47AM +0200, Geert Uytterhoeven wrote:
> > > If it fails, please add `#define DEBUG' to drivers/ps3/ps3av.c, send me
> > > the
> > > `Monitor Info' output in the kernel log (dmesg), and tell me which of the
> > > PS3 video modes (1-13) work and which don't. ps3av has a quirk database
> > > for
> > > monitors that advertise non-working modes, so it can probably be fixed.
> > > (BTW, even if autodetect works fine, I always welcome this information)
> > >
> > > In case you have a big pile of monitors at your site, you don't have to
> > > reboot
> > > to try them all. Just plug in the new monitor and run `ps3videomode -v 0'
> > > to
> > > switch to the best resolution of the newly-connected monitor.
> >
> > Hi, the autodetect code does not work correctly with a LG L226WTQ
> > (native resolution 1680x1050). The detected mode (11) works fine without
> > fullscreen, but goes out of range with '-f'.
>
> This `supported resolution 11' is not the same as the mode number to pass to
> ps3videomode, it's a PS3AV_CMD_VIDEO_VID_* ID.
>
> Vid 11 corresponds to PS3AV_CMD_VIDEO_VID_1080P_60Hz (i.e. 1080p).
> While mode 11 is WXGA (i.e. 1280x768).
>
> (Upon further inspection, this `vid' is immediately converted to a mode
> number,
> so I'll change the code to use mode numbers instead, and cause less
> confusion).
>
> > Resolutions w/o fullscreen:
> > OK: 2, 3, 7, 8, 11, 12
> > BAD: 1, 4, 5, 6, 9, 10, 13
>
> Looks reasonable for a 1680x1050 monitor...
>
> > Resolutions with fullscreen:
> > OK: 2, 3, 7, 8
> > BAD: 1, 4, 5, 6, 9, 10, 11, 12, 13
>
> Euh, `-f' shouldn't make any difference for modes 11-13, as they're always
> fullscreen.
>
> > Monitor Info: size 96
> > avport: 00
> > monitor_id: 1e 6d 4e 56 d7 2a 03 00 03 11
> > monitor_type: 02
> > monitor_name: L226WTQ
> > resolution_60: bits: 400d native:
> > resolution_50: bits: native:
> > resolution_other: bits: native:
> > resolution_vesa: bits: 0001 native:
>
> So your monitor advertises:
>
> Supported 60 Hz modes: 1080p 480p 720p 1080i (400d)
> Supported VESA modes:VGA (0001)
>
> But 1080p and 1080i don't work. As 1080p is the best advertised mode, you
> don't
> get anything to see :-(
>
> Does this patch help? It should give you 720p by default.
>
> Index: ps3-linux-2.6/drivers/ps3/ps3av.c
> ===
> --- ps3-linux-2.6.orig/drivers/ps3/ps3av.c2007-07-12 10:26:33.0
> +0200
> +++ ps3-linux-2.6/drivers/ps3/ps3av.c 2007-07-12 16:57:39.0 +0200
> @@ -720,6 +720,10 @@ static const struct ps3av_monitor_quirk
> {
> .monitor_name = "DELL 2007WFP",
> .clear_60 = PS3AV_RESBIT_1920x1080I
> + }, {
> + .monitor_name = "L226WTQ",
> + .clear_60 = PS3AV_RESBIT_1920x1080I |
> + PS3AV_RESBIT_1920x1080P
> }
> };
>
The patch gives me a picture, but it does not cover the whole screen.
Ps3videomode returns mode 67, and if i add 128 to that number I get
working fullscreen. Additionally, the break in ps3av_fixup_monitor_info
is misplaced and will only try the first quirk.
dmesg:
ps3av_hdmi_get_vid: Using supported resolution 9
--
Håvard Espeland
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Add global-utilities node for mpc8544ds and mpc8572mds boards
From: Roy Zang <[EMAIL PROTECTED]>
Add global-utilities node for mpc8544ds and mpc8572mds boards
Signed-off-by: Roy Zang <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8544ds.dts |6 ++
arch/powerpc/boot/dts/mpc8568mds.dts |6 ++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8544ds.dts
b/arch/powerpc/boot/dts/mpc8544ds.dts
index 8285925..43bf5c1 100644
--- a/arch/powerpc/boot/dts/mpc8544ds.dts
+++ b/arch/powerpc/boot/dts/mpc8544ds.dts
@@ -137,6 +137,12 @@
interrupt-parent = <&mpic>;
};
+ [EMAIL PROTECTED] { //global utilities block
+ compatible = "fsl,mpc8548-guts";
+ reg = ;
+ fsl,has-rstcr;
+ };
+
mpic: [EMAIL PROTECTED] {
clock-frequency = <0>;
interrupt-controller;
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts
b/arch/powerpc/boot/dts/mpc8568mds.dts
index c6cd1d6..5eeb0e6 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -170,6 +170,12 @@
interrupt-parent = <&mpic>;
};
+ [EMAIL PROTECTED] { //global utilities block
+ compatible = "fsl,mpc8548-guts";
+ reg = ;
+ fsl,has-rstcr;
+ };
+
[EMAIL PROTECTED] {
interrupt-map-mask = ;
interrupt-map = <
--
1.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 0/6] PS3 Storage Drivers for 2.6.23, take 4
On Tue, 10 Jul 2007, Geert Uytterhoeven wrote: > On Wed, 4 Jul 2007, Geert Uytterhoeven wrote: > > This is the fourth submission of the new PS3 storage drivers: > > [1] ps3: Preallocate bootmem memory for the PS3 FLASH ROM storage driver > > [2] ps3: Storage Driver Core > > [3] ps3: Storage device registration routines. > > [4] ps3: Disk Storage Driver > > [5] ps3: BD/DVD/CD-ROM Storage Driver > > [6] ps3: FLASH ROM Storage Driver > > > > They are based on: > > - the current Linux kernel source tree, > > - plus the PS3 patches already submitted by Geoff Levand on linuxppc-dev, > > - plus the shost_priv() patch in scsi-misc (commit > > bcd92c9fbcc679ee95003083056f0441a1f474fa). > > > > All issues raised during the previous review rounds should be fixed. > > There were no more comments after the third submission. > > > > Paul already integrated Geoff Levand's PS3 patches and the first 3 patches > > in this series in the for-2.6.23 branch in powerpc.git. > > > > Maintainers of block/SCSI/misc, can you please ack the last 3 patches so > > Paul > > can take them, too? > > Ping block/SCSI/misc maintainers? Ping SCSI and misc maintainers? Please either ack patches 5 and 6, so Paulus can integrate them for 2.6.23, or tell me why they can't go in. Thanks again. With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc clk.h interface for platforms
On 11/07/07 21:34 +0100, Russell King wrote:
> On Wed, Jul 11, 2007 at 10:02:54AM -0700, David Brownell wrote:
> > On Wednesday 11 July 2007, Christoph Hellwig wrote:
> > > On Wed, Jul 11, 2007 at 08:56:58AM -0700, David Brownell wrote:
> > > > > Umm, this is about the fifth almost identical implementation of
> > > > > the clk_ functions. Please, please put it into common code.
> > > > >
> > > > > And talk to the mips folks which just got a similar comment from me.
> > > >
> > > > You mean like a lib/clock.c core, rather than an opsvector?
> > >
> > > I mean an ops vector and surrounding wrappers. Every architecture
> > > is reimplementing their own dispatch table which is rather annoying.
> >
> > ARM doesn't. :)
> >
> > But then, nobody expects one kernel to support more than one
> > vendor's ARM chips; or usually, more than one generation of
> > that vendor's chips. So any dispatch table is specific to
> > a given platform, and tuned to its quirks. Not much to share
> > between OMAP and AT91, for example, except in some cases maybe
> > an arm926ejs block.
>
> And also the information stored within a 'struct clk' is very platform
> dependent. In the most basic situation, 'struct clk' may not actually
> be a structure, but the clock rate. All functions with the exception of
> clk_get() and clk_get_rate() could well be no-ops, clk_get() just returns
> the 'struct clk' representing the rate and 'clk_get_rate' returns that
> as an integer.
>
> More complex setups might want 'struct clk' to contain the address of a
> clock enable register, the bit position to enable that clock source, the
> clock rate, a refcount, and so on, all of which would be utterly useless
> for a platform which had fixed rate clocks.
The patch that triggered this discussion is at the end.
It doesn't make any assumption on struct clk, it's just a
wrapper around functions from clk.h.
Point of this patch was to abstract exported functions, since
arch/powerpc/ can support multiple platfroms in one binary.
>
> > I've not seen a solid proposal for such a thing, and it's not
> > clear to me how that would play with with older code (e.g. any
> > of the ARM implementations).
>
> If people are implementing their own incompatible changes without reference
> to the API they're invalid implementations as far as I'm concerned. If
> they can't bothered to lift a finger to even _talk_ to me about their
> requirements they just don't have any say concerning any future
> developments IMO.
My changes were implemented according to clk.h API.
And honestly, I just wanted to rework clocks in some SPI driver and
others made me do all the clk work. ;-)
Domen
>
> IOW, talk to me and I'll talk back. Ignore me and I'll ignore them.
>
> --
> Russell King
> Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
> maintainer of:
clk interface for arch/powerpc, platforms should fill
clk_functions.
Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/Makefile|3 -
arch/powerpc/kernel/clock.c | 82
include/asm-powerpc/clk_interface.h | 20
3 files changed, 104 insertions(+), 1 deletion(-)
Index: work-powerpc.git/arch/powerpc/kernel/clock.c
===
--- /dev/null
+++ work-powerpc.git/arch/powerpc/kernel/clock.c
@@ -0,0 +1,82 @@
+/*
+ * Dummy clk implementations for powerpc.
+ * These need to be overridden in platform code.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+struct clk_interface clk_functions;
+
+struct clk *clk_get(struct device *dev, const char *id)
+{
+ if (clk_functions.clk_get)
+ return clk_functions.clk_get(dev, id);
+ return ERR_PTR(-ENOSYS);
+}
+EXPORT_SYMBOL(clk_get);
+
+void clk_put(struct clk *clk)
+{
+ if (clk_functions.clk_put)
+ clk_functions.clk_put(clk);
+}
+EXPORT_SYMBOL(clk_put);
+
+int clk_enable(struct clk *clk)
+{
+ if (clk_functions.clk_enable)
+ return clk_functions.clk_enable(clk);
+ return -ENOSYS;
+}
+EXPORT_SYMBOL(clk_enable);
+
+void clk_disable(struct clk *clk)
+{
+ if (clk_functions.clk_disable)
+ clk_functions.clk_disable(clk);
+}
+EXPORT_SYMBOL(clk_disable);
+
+unsigned long clk_get_rate(struct clk *clk)
+{
+ if (clk_functions.clk_get_rate)
+ return clk_functions.clk_get_rate(clk);
+ return 0;
+}
+EXPORT_SYMBOL(clk_get_rate);
+
+long clk_round_rate(struct clk *clk, unsigned long rate)
+{
+ if (clk_functions.clk_round_rate)
+ return clk_functions.clk_round_rate(clk, rate);
+ return -ENOSYS;
+}
+EXPORT_SYMBOL(clk_round_rate);
+
+int clk_set_rate(struct clk *clk, unsigned long rate)
+{
+ if (clk_functions.clk_set_rate)
+ return clk_functions.clk_set_rate(clk, rate);
+ return -ENOSYS;
+}
+EXPORT_SYMBOL(clk_set_rate);
+
+struct clk *clk_get_parent(stru
Re: [PATCH] fix showing xmon help
> On Thu, 2007-07-12 at 16:59 +0900, Ishizaki Kou wrote: > > In some configuration, xmon help string is larger than xmon output > > buffer. To show whole help string, this patch splits it into 2 parts. > > > > Signed-off-by: Kou Ishizaki <[EMAIL PROTECTED]> (snip) > I'm not sure I like the fix though, it's a bit of a kludge :) > > We don't actually need to printf() the help string, so what'd be nicer > is to add an xmon_puts() to arch/powerpc/xmon/nonstdio.c which just > calls xmon_write(s, strlen(s)) and use that for printing the help > string. Thank you for your suggestion. You're right. I'll send a new patch. Best regards, Kou Ishizaki ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Tickless Hz/hrtimers/etc. on PowerPC
On 12/07/07 13:07 +0100, Matt Sealey wrote: > Domen, > > You wouldn't have tried these on the Efika yet, would you? Not yet, but they worked on a mpc5200b based board (lite5200b). Domen > > -- > Matt Sealey <[EMAIL PROTECTED]> > Genesi, Manager, Developer Relations > > Domen Puncer wrote: > > On 11/07/07 19:06 +0100, Matt Sealey wrote: > >> Does anyone have the definitive patchset to enable the tickless hz, > >> some kind of hrtimer and the other related improvements in the > >> PowerPC tree? > > > > I use attached patches for tickless. > > Order in which they're applied: > > > > PowerPC_GENERIC_CLOCKEVENTS.patch > > PowerPC_GENERIC_TIME.linux-2.6.18-rc6_timeofday-arch-ppc_C6.patch > > PowerPC_enable_HRT_and_dynticks_support.patch > > PowerPC_no_hz_fix.patch > > tickless-enable.patch > > > > HTH > > > > > > Domen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
questions about mpc82xx_ads and porting to other, similar, platform
Hello all, I am trying to port kernel 2.6.22.1 to my own platform, which incorporates an mpc8275 chip. I'm using platform code for mpc82xx_ads as a template (is this right in the first place?). I have a couple of questions: 1. mpc82xx_ads.c uses init_scc_ioports function to initialize the scc uarts. However, this function is only used by the code in arch/powerpc/sysdev/fsl_soc.c, and spefically in fs_enet_of_init(), which is used to initialize the ethernet driver and not the cpm_uart driver. On the other hand, cpm_uart_of_init() function seems to be the one that initializes the uarts in cpm, and actually makes use of the device-id, model, rx-clock and tx-clock properties of the scc nodes in OF tree. So, AFAICT, init_scc_ioports should not be there, since it won't be actually called at all (although I have not actually tested this - I haven't yet managed to boot the kernel). Instead, cpm_uart_of_init should take care of everything, except for the pport initialization, which is done in u-boot anyway (at least in my case). Any thoughts on this? 2. I have also some questions regarding the device tree. Why are there two nodes regarding the interrupt controller in there? and in the top level node, what does this property means: reg = ; ? Finally, in the memory node, the reg property defines a second mem region, (f450 f4500020). What is this? maybe a special memory mapped peripheral of this board? If I have a board with many mem configurations (e.g. it uses a DIMM SDRAM what can be changed), what value should I place in the mem node? I have to change dts every time I insert a new DIMM? any help would be greatly appreciated, thank you in advance Alex ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Tickless Hz/hrtimers/etc. on PowerPC
On 12/07/07 18:11 +0400, Sergei Shtylyov wrote: > Hello. > > Domen Puncer wrote: > > >>Does anyone have the definitive patchset to enable the tickless hz, > >>some kind of hrtimer and the other related improvements in the > >>PowerPC tree? > > >I use attached patches for tickless. > >Order in which they're applied: > > >PowerPC_GENERIC_CLOCKEVENTS.patch > >That's my patch which used to have both description and signoff that I'm > not seeing in the attached version... Err, yes, sorry, I don't remember anymore where I picked them, but I'm pretty sure I didn't go delete description and signoff by hand. > > >PowerPC_GENERIC_TIME.linux-2.6.18-rc6_timeofday-arch-ppc_C6.patch > >This one should come first of all, I'd say... >Note that it breaks TOD vsyscalls, so you need my patch that removes > support for those for the time being (i.e. until Tony hopefully fixes this > :-). Also, there was a patch implementing read_persistent_clock() and > getting rid of the code setting xtime in time_init(). Attaching them > both... > > >PowerPC_enable_HRT_and_dynticks_support.patch > >Again looks like my patch with description/signoff missing for whatever > reason... > > >PowerPC_no_hz_fix.patch > >This has nothing to do with CONFIG_NO_HZ per se -- it fixes the > compilation error introduced by John's patch. > > >tickless-enable.patch > >That one doesn't look quite right... That's because I made it ;-) It did the trick of enabling tickless though. Domen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Tickless Hz/hrtimers/etc. on PowerPC
On Thu, 2007-07-12 at 21:04 +0100, Matt Sealey wrote: > We already have some ~20 for Efika support on top of 2.6.22 including > minor bugfixes and stuff, and the Gentoo genpatches stuff. I really > want > to get a good start on CFS, hrtimers, dynticks and so on though and > see > if we can push it to users and get out some decent testing and bug > reports. I think it will help everyone if it is not just a feature > which > hits mainline after 6 months through supposed maturity (when a lack of > bug reports may well also be down to lack of interest). Why haven't you submited those patches ? The merge window for 2.6.23 is open _now_ Ben ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 00/10] IB/ehca: Multiple Event Queues, MR/MW rework, large page MRs, fixes
> > [09/10] fixes a lot of checkpatch.pl warnings > > Are these warnings from earlier patches in the series, or problems > that already existed in the code? If they are coming from other > patches in the series, please just fix the earlier patches before I > merge them. Nam did a diff -Nurp empty_dir ehca | checkpatch.pl and fixed all the existing problems in the code. That's why this is such a big hunk - we've been doing the pointer-typecast thing wrong for a long time, for example. Joachim ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
