* Re: PATCH powerpc: Merge asm-ppc*/hardirq.h
From: Christoph Hellwig @ 2005-09-14 11:05 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org, linuxppc64-dev
In-Reply-To: <1126643920.11056.53.camel@cashmere.sps.mot.com>
On Tue, Sep 13, 2005 at 03:38:40PM -0500, Jon Loeliger wrote:
> +#ifndef _ASM_POWERPC_HARDIRQ_H
> +#define _ASM_POWERPC_HARDIRQ_H
> +#ifdef __KERNEL__
the __KERNEL__ ifdefs is not needed. <asm/hardirq.h> is only included
from <linux/hardirq.h> which doesn't have anything user-visible.
> +
> +#include <linux/config.h>
not needed.
> +#include <linux/cache.h>
> +
> +#ifdef __powerpc64__
> +#include <linux/preempt.h>
> +#else
> +#include <linux/smp_lock.h>
> +#include <asm/irq.h>
> +#endif
We shouldn't need either of these include blocks at all.
> +
> +/* The __last_jiffy_stamp field is needed to ensure that no decrementer
> + * interrupt is lost on SMP machines. Since on most CPUs it is in the same
> + * cache line as local_irq_count, it is cheap to access and is also used on UP
> + * for uniformity.
> + */
> +typedef struct {
> + unsigned int __softirq_pending; /* set_bit is used on this */
> + unsigned int __last_jiffy_stamp;
> +} ____cacheline_aligned irq_cpustat_t;
I'd suggest just using a DECLARE_PER_CPU variable for last_jiffy_stamp.
In facct I plan to get rid of irq_cpustat_t completely at some point.
^ permalink raw reply
* RE: How to support LFS on ppc
From: Fillod Stephane @ 2005-09-14 9:47 UTC (permalink / raw)
To: linux-ppc-embedded
>I have a problem about Large File System on ppc. The following is my =
example code:
Actually not problem with LFS, but with int types.
>#define _FILE_OFFSET_BITS 64
>#include <sys/stat.h>
>#include <unistd.h>
>Int main()
>{
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 struct stat buf;
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 stat64("/3G",&buf);
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 printf("size of test =3D %ld =
\n",buf.st_size);
^^^
Try %lld instead. Or to be portable, #include <inttypes.h>
and printf("size of test =3D %" PRId64 "\n", buf.st_size);
--=20
Stephane
^ permalink raw reply
* Re: How to modify MTD driver for MX29LV320ABTC-90?
From: Debora Liu @ 2005-09-14 9:42 UTC (permalink / raw)
To: ÐìСÍþµÄEMAIL; +Cc: linuxppc-embedded
Hello, ???
In message < 2005-09-14 14:10:17 rober@opnet.com.tw> you wrote:
> init_tqm_mtd: chip probing count 0
> init_tqm_mtd: chip probing count 1
> TQM8xxL: No support flash chips found!
Creat yourself coder in drivers/mtd/maps
Debora Liu
deboralh@sinovee.com
2005-09-14
^ permalink raw reply
* SRAM support for the Pegasos II platform
From: Nicolas DET @ 2005-09-14 10:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Andrew Morton, Sven Luther, David Holm
[-- Attachment #1: Type: text/plain, Size: 307 bytes --]
Amiga............: SimpleMail http://simplemail.sourceforge.net/
Unix.............: Metamail ftp://ftp.bellcore.com/nsb/
Windows/Macintosh: Eudora http://www.qualcomm.com/
General info about MIME can be found at:
http://www.cis.ohio-state.edu/hypertext/faq/usenet/mail/mime-faq/top.html
[-- Attachment #2: Type: text/plain, Size: 412 bytes --]
Hello,
You can find enclosed or at the URL a patch for the 2.6.14-rc1.
http://arrakin.homedns.org/~nicolas/mv643xx_eth_chrp_pegasos_eth.c.2.6.14-rc1.diff
It allows (with drivers/net/mv643xx_eth.*) to take advantage of the SRAM of
the Marvell Discovery II for the network driver.
Reviews and comments welcome.
I hope it could be include in upcomming 2.6.14.
Regards,
--
Nicolas DET
MorphOS & Linux developer
[-- Attachment #3: mv643xx_eth_chrp_pegasos_eth.c.2.6.14-rc1.diff --]
[-- Type: application/octet-stream, Size: 4868 bytes --]
--- linux-2.6.14-rc1/arch/ppc/platforms/chrp_pegasos_eth.c 2005-09-14 08:14:44.275127904 +0200
+++ linux-2.6.14-rc1_nico/arch/ppc/platforms/chrp_pegasos_eth.c 2005-09-14 10:48:26.566874500 +0200
@@ -17,6 +17,21 @@
#include <linux/mv643xx.h>
#include <linux/pci.h>
+// Pegasos II location and size for the SRAM stuff
+// Only used for the ethernet driver ATM
+#define PEGASOS2_MARVELL_REGBASE (0xf1000000)
+#define PEGASOS2_MARVELL_REGSIZE (0x00004000)
+#define PEGASOS2_SRAM_BASE (0xf2000000)
+#define PEGASOS2_SRAM_SIZE (0x00008000)
+
+#define PEGASOS2_SRAM_BASE_ETH0 (PEGASOS2_SRAM_BASE)
+#define PEGASOS2_SRAM_BASE_ETH1 (PEGASOS2_SRAM_BASE_ETH0 + (PEGASOS2_SRAM_SIZE / 2) )
+
+#define PEGASOS2_SRAM_RXRING_SIZE (PEGASOS2_SRAM_SIZE/4)
+#define PEGASOS2_SRAM_TXRING_SIZE (PEGASOS2_SRAM_SIZE/4)
+
+//#define BE_VERBOSE
+
/* Pegasos 2 specific Marvell MV 64361 gigabit ethernet port setup */
static struct resource mv643xx_eth_shared_resources[] = {
[0] = {
@@ -44,7 +59,15 @@
},
};
-static struct mv643xx_eth_platform_data eth0_pd;
+static struct mv643xx_eth_platform_data eth0_pd = {
+ .tx_sram_addr = PEGASOS2_SRAM_BASE_ETH0,
+ .tx_sram_size = PEGASOS2_SRAM_TXRING_SIZE,
+ .tx_queue_size = PEGASOS2_SRAM_TXRING_SIZE/16,
+
+ .rx_sram_addr = PEGASOS2_SRAM_BASE + PEGASOS2_SRAM_TXRING_SIZE,
+ .rx_sram_size = PEGASOS2_SRAM_RXRING_SIZE,
+ .rx_queue_size = PEGASOS2_SRAM_RXRING_SIZE/16,
+};
static struct platform_device eth0_device = {
.name = MV643XX_ETH_NAME,
@@ -65,7 +88,15 @@
},
};
-static struct mv643xx_eth_platform_data eth1_pd;
+static struct mv643xx_eth_platform_data eth1_pd = {
+ .tx_sram_addr = PEGASOS2_SRAM_BASE_ETH1,
+ .tx_sram_size = PEGASOS2_SRAM_TXRING_SIZE,
+ .tx_queue_size = PEGASOS2_SRAM_TXRING_SIZE/16,
+
+ .rx_sram_addr = PEGASOS2_SRAM_BASE_ETH1 + PEGASOS2_SRAM_TXRING_SIZE,
+ .rx_sram_size = PEGASOS2_SRAM_RXRING_SIZE,
+ .rx_queue_size = PEGASOS2_SRAM_RXRING_SIZE/16,
+};
static struct platform_device eth1_device = {
.name = MV643XX_ETH_NAME,
@@ -83,7 +114,68 @@
ð1_device,
};
+/***********/
+/***********/
+#define MV_READ(offset,val) { val = readl(mv643xx_reg_base + offset); }
+#define MV_WRITE(offset,data) writel(data, mv643xx_reg_base + offset)
+
+static void __iomem *mv643xx_reg_base = NULL;
+
+static int Enable_SRAM(void)
+{
+ u32 ALong;
+
+ // Let's io remap the mv register to touch the SRAM config
+ if (mv643xx_reg_base == NULL)
+ mv643xx_reg_base = ioremap(PEGASOS2_MARVELL_REGBASE, PEGASOS2_MARVELL_REGSIZE);
+
+ if (mv643xx_reg_base == NULL)
+ return -ENOMEM;
+
+#ifdef BE_VERBOSE
+ printk("Pegasos II/Marvell MV64361: register remapped from %p to %p\n", (void *)PEGASOS2_MARVELL_REGBASE, (void *)mv643xx_reg_base);
+#endif
+
+ // First the SRAM config register
+ // We set it to 0 ATM -> No cache coherency, no parity check
+ MV_WRITE(MV64340_SRAM_CONFIG, 0);
+
+ // set the SRAM address on the CPU side
+ MV_WRITE(MV64340_INTEGRATED_SRAM_BASE_ADDR, PEGASOS2_SRAM_BASE >> 16);
+
+ // Now enable it (CPU side)
+ MV_READ(MV64340_BASE_ADDR_ENABLE, ALong);
+ ALong &= ~(1 << 19);
+ MV_WRITE(MV64340_BASE_ADDR_ENABLE, ALong);
+
+ // And now to the GB side on WB 4 (0->3) can be use for DRAM stuff
+ ALong = 0x02; // Integrated SRAM value
+ ALong |= PEGASOS2_SRAM_BASE & 0xffff0000; // Finally set the SRAM adress in the uppter par of the register
+ MV_WRITE(MV643XX_ETH_BAR_4, ALong);
+
+ // and the size ...
+ MV_WRITE(MV643XX_ETH_SIZE_REG_4, PEGASOS2_SRAM_SIZE & 0xffff0000);
+
+ // Finaly enable the window
+ MV_READ(MV643XX_ETH_BASE_ADDR_ENABLE_REG, ALong);
+ ALong &= ~(1 << 4);
+ MV_WRITE(MV643XX_ETH_BASE_ADDR_ENABLE_REG, ALong);
+
+#ifdef BE_VERBOSE
+ printk("Pegasos II/Marvell MV64361: register unmapped\n");
+ printk("Pegasos II/Marvell MV64361: SRAM at %p, size=%x\n", (void*) PEGASOS2_SRAM_BASE, PEGASOS2_SRAM_SIZE);
+#endif
+
+ iounmap(mv643xx_reg_base);
+ mv643xx_reg_base = NULL;
+
+ return 1;
+}
+
+
+/***********/
+/***********/
int
mv643xx_eth_add_pds(void)
{
@@ -93,9 +185,38 @@
{ }
};
- if (pci_dev_present(pci_marvell_mv64360)) {
+#ifdef BE_VERBOSE
+ printk("Pegasos II/Marvell MV64361: init\n");
+#endif
+
+ if (pci_dev_present(pci_marvell_mv64360))
+ {
ret = platform_add_devices(mv643xx_eth_pd_devs, ARRAY_SIZE(mv643xx_eth_pd_devs));
+
+ if ( Enable_SRAM() < 0)
+ {
+ // Humm, disable SRAM stuff
+ eth0_pd.tx_sram_addr = 0;
+ eth0_pd.tx_sram_size = 0;
+ eth0_pd.rx_sram_addr = 0;
+ eth0_pd.rx_sram_size = 0;
+
+ eth1_pd.tx_sram_addr = 0;
+ eth1_pd.tx_sram_size = 0;
+ eth1_pd.rx_sram_addr = 0;
+ eth1_pd.rx_sram_size = 0;
+
+#ifdef BE_VERBOSE
+ printk("Pegasos II/Marvell MV64361: Can't enable the SRAM\n");
+#endif
+ }
}
+
+#ifdef BE_VERBOSE
+
+ printk("Pegasos II/Marvell MV64361: init is over\n");
+#endif
+
return ret;
}
device_initcall(mv643xx_eth_add_pds);
^ permalink raw reply
* How to support LFS on ppc
From: JohnsonCheng @ 2005-09-14 9:12 UTC (permalink / raw)
To: linux-ppc-embedded
[-- Attachment #1: Type: text/plain, Size: 689 bytes --]
Dear All,
I have a problem about Large File System on ppc. The following is my example
code:
#define _FILE_OFFSET_BITS 64
#include <sys/stat.h>
#include <unistd.h>
Int main()
{
struct stat buf;
stat64("/3G",&buf);
printf("size of test = %ld \n",buf.st_size);
lstat64("/3G",&buf);
printf("size of test 2= %ld\n",buf.st_size);
return 0;
}
The conclusion is as following:
size of test = 2141735952
size of test 2= 805910402
But the real size of 3G file is 3145728000. I think it maybe the offset is
wrong, but I don't know how to correct it. Can someone give me some advise.
Thanks,
Johnson Cheng
[-- Attachment #2: Type: text/html, Size: 6370 bytes --]
^ permalink raw reply
* Account Review Team
From: PayPal @ 2005-09-13 20:48 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 5299 bytes --]
^ permalink raw reply
* Account Review Team
From: PayPal @ 2005-09-13 20:48 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/html, Size: 5299 bytes --]
^ permalink raw reply
* 1161 host
From: 汪 秀平 @ 2005-09-14 7:27 UTC (permalink / raw)
To: linuxppc-embedded
hello
1161 connect question:
don't connect usboperational state
bases: ISP1161xProgramming_Guide.pdf
_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
^ permalink raw reply
* How to modify MTD driver for MX29LV320ABTC-90?
From: 徐小威的EMAIL @ 2005-09-14 6:10 UTC (permalink / raw)
To: linuxppc-embedded
Hi All:
I used 2.4.25 linux at my custom MPC852T.My hardware has 2 *
MX29LV320ABTC, working at 16bit mode.Now i want to used MTD to partion
my flash and JFFS2.I want to know how
to modify MTD for MX29LV320ABTC.
init_tqm_mtd: chip probing count 0
init_tqm_mtd: chip probing count 1
TQM8xxL: No support flash chips found!
PS:My first flash address start at 0x40000000, second is 0x40400000
Best Regards,
Rober Hsu
^ permalink raw reply
* Re: PATCH powerpc: Merge asm-ppc*/sections.h
From: Arnd Bergmann @ 2005-09-14 2:35 UTC (permalink / raw)
To: linuxppc64-dev; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1126644202.11056.59.camel@cashmere.sps.mot.com>
On Dinsdag 13 September 2005 22:43, Jon Loeliger wrote:
> Here is a patch to merge asm-ppc*/sections.h.
>
> If anyone knows if we can do better here,
> please feel free to abuse, er, let me know!
Ok, I don't like this patch. IMHO for the architecture merge, we should
have a common implementation of this, either always using per-platform
sections or never using them, meaning that we get rid of this file.
At the very least, the __*func() macros should go away, they are completely
bogus.
Using the sections in arch/powerpc has the obvious advantage that it
reduces the size of the running kernel, but also has a certain amount
of bug-potential or at least makes the code slightly more ugly.
It is also easier to remove the feature in ppc than adding it in ppc64.
The users of the ppc64 function in_kernel_text() can probably be converted
to the generic is_kernel_text() function.
Arnd <><
^ permalink raw reply
* -dev and -embedded cross-posting
From: Eugene Surovegin @ 2005-09-13 22:23 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-ppc-embedded
In-Reply-To: <20050913175028.GB14889@dmt.cnet>
Guys,
let's not cross-post -dev posts here. In general, -embedded isn't
a totally separate list, it just covers embedded specific stuff, which
is not interesting to several loud -dev readers :). Things which
aren't embedded specific should go -dev.
I think, everybody *interested* in general PPC32 development issues
here, are also subscribed to -dev list.
Thanks.
--
Eugene
^ permalink raw reply
* Re: __switch_to test-and-branch ALTIVEC specific?
From: Kumar Gala @ 2005-09-13 21:43 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linuxppc-dev, cort, linux-ppc-embedded
In-Reply-To: <20050913203555.GB18639@dmt.cnet>
On Sep 13, 2005, at 3:35 PM, Marcelo Tosatti wrote:
> On Tue, Sep 13, 2005 at 02:05:57PM -0500, Kumar Gala wrote:
>
>> This probably has to due with what happens on a G4 system with a
>> kernel not build with Altivec.. However, I dont remember exactly what
>>
>
>
>> behavior is desired.
>>
>
> What would be the appropriate set of definitions to use, then ?
>
> #if defined (CONFIG_ALTIVEC || CONFIG_6xx) ?
That's probably better. Hopefully Ben will have some reason if what
you suggest is not sufficient.
- k
^ permalink raw reply
* PATCH powerpc: Merge asm-ppc*/sections.h
From: Jon Loeliger @ 2005-09-13 20:43 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org, linuxppc64-dev
Here is a patch to merge asm-ppc*/sections.h.
If anyone knows if we can do better here,
please feel free to abuse, er, let me know!
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
diff --git a/include/asm-powerpc/sections.h b/include/asm-powerpc/sections.h
new file mode 100644
--- /dev/null
+++ b/include/asm-powerpc/sections.h
@@ -0,0 +1,62 @@
+#ifndef _ASM_POWERPC_SECTIONS_H
+#define _ASM_POWERPC_SECTIONS_H
+
+#ifdef __KERNEL__
+
+#include <asm-generic/sections.h>
+
+#ifdef __powerpc64__
+
+#define __pmac
+#define __pmacdata
+
+#define __prep
+#define __prepdata
+
+#define __chrp
+#define __chrpdata
+
+#define __openfirmware
+#define __openfirmwaredata
+
+extern char _end[];
+
+static inline int in_kernel_text(unsigned long addr)
+{
+ if (addr >= (unsigned long)_stext && addr < (unsigned long)__init_end)
+ return 1;
+
+ return 0;
+}
+
+#else /* __powerpc64__ */
+
+#define __pmac __attribute__ ((__section__ (".pmac.text")))
+#define __pmacdata __attribute__ ((__section__ (".pmac.data")))
+#define __pmacfunc(__argpmac) \
+ __argpmac __pmac; \
+ __argpmac
+
+#define __prep __attribute__ ((__section__ (".prep.text")))
+#define __prepdata __attribute__ ((__section__ (".prep.data")))
+#define __prepfunc(__argprep) \
+ __argprep __prep; \
+ __argprep
+
+#define __chrp __attribute__ ((__section__ (".chrp.text")))
+#define __chrpdata __attribute__ ((__section__ (".chrp.data")))
+#define __chrpfunc(__argchrp) \
+ __argchrp __chrp; \
+ __argchrp
+
+/* this is actually just common chrp/pmac code, not OF code -- Cort */
+#define __openfirmware __attribute__ ((__section__ (".openfirmware.text")))
+#define __openfirmwaredata __attribute__ ((__section__ (".openfirmware.data")))
+#define __openfirmwarefunc(__argopenfirmware) \
+ __argopenfirmware __openfirmware; \
+ __argopenfirmware
+
+#endif /* __powerpc64__ */
+
+#endif /* __KERNEL__ */
+#endif /* _ASM_POWERPC_SECTIONS_H */
diff --git a/include/asm-ppc/sections.h b/include/asm-ppc/sections.h
deleted file mode 100644
--- a/include/asm-ppc/sections.h
+++ /dev/null
@@ -1,33 +0,0 @@
-#ifdef __KERNEL__
-#ifndef _PPC_SECTIONS_H
-#define _PPC_SECTIONS_H
-
-#include <asm-generic/sections.h>
-
-#define __pmac __attribute__ ((__section__ (".pmac.text")))
-#define __pmacdata __attribute__ ((__section__ (".pmac.data")))
-#define __pmacfunc(__argpmac) \
- __argpmac __pmac; \
- __argpmac
-
-#define __prep __attribute__ ((__section__ (".prep.text")))
-#define __prepdata __attribute__ ((__section__ (".prep.data")))
-#define __prepfunc(__argprep) \
- __argprep __prep; \
- __argprep
-
-#define __chrp __attribute__ ((__section__ (".chrp.text")))
-#define __chrpdata __attribute__ ((__section__ (".chrp.data")))
-#define __chrpfunc(__argchrp) \
- __argchrp __chrp; \
- __argchrp
-
-/* this is actually just common chrp/pmac code, not OF code -- Cort */
-#define __openfirmware __attribute__ ((__section__ (".openfirmware.text")))
-#define __openfirmwaredata __attribute__ ((__section__ (".openfirmware.data")))
-#define __openfirmwarefunc(__argopenfirmware) \
- __argopenfirmware __openfirmware; \
- __argopenfirmware
-
-#endif /* _PPC_SECTIONS_H */
-#endif /* __KERNEL__ */
diff --git a/include/asm-ppc64/sections.h b/include/asm-ppc64/sections.h
deleted file mode 100644
--- a/include/asm-ppc64/sections.h
+++ /dev/null
@@ -1,29 +0,0 @@
-#ifndef _PPC64_SECTIONS_H
-#define _PPC64_SECTIONS_H
-
-extern char _end[];
-
-#include <asm-generic/sections.h>
-
-#define __pmac
-#define __pmacdata
-
-#define __prep
-#define __prepdata
-
-#define __chrp
-#define __chrpdata
-
-#define __openfirmware
-#define __openfirmwaredata
-
-
-static inline int in_kernel_text(unsigned long addr)
-{
- if (addr >= (unsigned long)_stext && addr < (unsigned long)__init_end)
- return 1;
-
- return 0;
-}
-
-#endif
^ permalink raw reply
* PATCH powerpc: Merge asm-ppc*/hardirq.h
From: Jon Loeliger @ 2005-09-13 20:38 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org, linuxppc64-dev
Here is a patch to merge asm-ppc*/hardirq.h.
Does anyone know of a problem in ppc64 land that
will be caused by having added the jiffy_stamp
field into this cacheline-aligned structure?
Also, of note here, I dodged the hard question
of what to do with SMP and preemption and stuff.
Lots more work will have to be resolved to really
answer those questions. Let's start here for now...
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
diff --git a/include/asm-powerpc/hardirq.h b/include/asm-powerpc/hardirq.h
new file mode 100644
--- /dev/null
+++ b/include/asm-powerpc/hardirq.h
@@ -0,0 +1,36 @@
+#ifndef _ASM_POWERPC_HARDIRQ_H
+#define _ASM_POWERPC_HARDIRQ_H
+#ifdef __KERNEL__
+
+#include <linux/config.h>
+#include <linux/cache.h>
+
+#ifdef __powerpc64__
+#include <linux/preempt.h>
+#else
+#include <linux/smp_lock.h>
+#include <asm/irq.h>
+#endif
+
+/* The __last_jiffy_stamp field is needed to ensure that no decrementer
+ * interrupt is lost on SMP machines. Since on most CPUs it is in the same
+ * cache line as local_irq_count, it is cheap to access and is also used on UP
+ * for uniformity.
+ */
+typedef struct {
+ unsigned int __softirq_pending; /* set_bit is used on this */
+ unsigned int __last_jiffy_stamp;
+} ____cacheline_aligned irq_cpustat_t;
+
+#include <linux/irq_cpustat.h> /* Standard mappings for irq_cpustat_t above */
+
+#define last_jiffy_stamp(cpu) __IRQ_STAT((cpu), __last_jiffy_stamp)
+
+static inline void ack_bad_irq(int irq)
+{
+ printk(KERN_CRIT "illegal vector %d received!\n", irq);
+ BUG();
+}
+
+#endif /* __KERNEL__ */
+#endif /* _ASM_POWERPC_HARDIRQ_H */
diff --git a/include/asm-ppc/hardirq.h b/include/asm-ppc/hardirq.h
deleted file mode 100644
--- a/include/asm-ppc/hardirq.h
+++ /dev/null
@@ -1,31 +0,0 @@
-#ifdef __KERNEL__
-#ifndef __ASM_HARDIRQ_H
-#define __ASM_HARDIRQ_H
-
-#include <linux/config.h>
-#include <linux/cache.h>
-#include <linux/smp_lock.h>
-#include <asm/irq.h>
-
-/* The __last_jiffy_stamp field is needed to ensure that no decrementer
- * interrupt is lost on SMP machines. Since on most CPUs it is in the same
- * cache line as local_irq_count, it is cheap to access and is also used on UP
- * for uniformity.
- */
-typedef struct {
- unsigned long __softirq_pending; /* set_bit is used on this */
- unsigned int __last_jiffy_stamp;
-} ____cacheline_aligned irq_cpustat_t;
-
-#include <linux/irq_cpustat.h> /* Standard mappings for irq_cpustat_t above */
-
-#define last_jiffy_stamp(cpu) __IRQ_STAT((cpu), __last_jiffy_stamp)
-
-static inline void ack_bad_irq(int irq)
-{
- printk(KERN_CRIT "illegal vector %d received!\n", irq);
- BUG();
-}
-
-#endif /* __ASM_HARDIRQ_H */
-#endif /* __KERNEL__ */
diff --git a/include/asm-ppc64/hardirq.h b/include/asm-ppc64/hardirq.h
deleted file mode 100644
--- a/include/asm-ppc64/hardirq.h
+++ /dev/null
@@ -1,27 +0,0 @@
-#ifndef __ASM_HARDIRQ_H
-#define __ASM_HARDIRQ_H
-
-/*
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- */
-
-#include <linux/config.h>
-#include <linux/cache.h>
-#include <linux/preempt.h>
-
-typedef struct {
- unsigned int __softirq_pending;
-} ____cacheline_aligned irq_cpustat_t;
-
-#include <linux/irq_cpustat.h> /* Standard mappings for irq_cpustat_t above */
-
-static inline void ack_bad_irq(int irq)
-{
- printk(KERN_CRIT "illegal vector %d received!\n", irq);
- BUG();
-}
-
-#endif /* __ASM_HARDIRQ_H */
^ permalink raw reply
* Re: __switch_to test-and-branch ALTIVEC specific?
From: Marcelo Tosatti @ 2005-09-13 20:35 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, cort, linux-ppc-embedded
In-Reply-To: <A6CA30D6-DDC3-4AEF-8CA2-58CFA261F44B@freescale.com>
On Tue, Sep 13, 2005 at 02:05:57PM -0500, Kumar Gala wrote:
> This probably has to due with what happens on a G4 system with a
> kernel not build with Altivec.. However, I dont remember exactly what
> behavior is desired.
What would be the appropriate set of definitions to use, then ?
#if defined (CONFIG_ALTIVEC || CONFIG_6xx) ?
^ permalink raw reply
* Re: Marvell MV6436xx ethernet driver patch
From: Dale Farnsworth @ 2005-09-13 20:01 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20050913103539.GA17855@lst.de>
On Tue, Sep 13, 2005 at 10:35:39AM +0000, Christoph Hellwig wrote:
> anywya, I think the patch discussion is rather offtopic here. Network
> driver patches are discussed and reviewed at netdev@oss.sgi.com
The current address is netdev@vger.kernel.org
I responded privately to Nicolas' message (before I realized it was posted
here). Still, I think it worth mentioning that a workaround for the
mv643xx_eth TCP/UDP hw checksum issue is already in 2.6.14-rc1.
-Dale
^ permalink raw reply
* Re: __switch_to test-and-branch ALTIVEC specific?
From: Kumar Gala @ 2005-09-13 19:05 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linuxppc-dev, linux-ppc-embedded
In-Reply-To: <20050913175028.GB14889@dmt.cnet>
This probably has to due with what happens on a G4 system with a
kernel not build with Altivec.. However, I dont remember exactly what
behavior is desired.
- kumar
On Sep 13, 2005, at 12:50 PM, Marcelo Tosatti wrote:
> Hi,
>
> This test&branch looks AltiVec specific, any reason for not #ifdef'ing
> it
> out?
>
> --- arch/ppc/kernel/process.c.orig 2005-09-13 14:43:13.000000000
> -0300
> +++ arch/ppc/kernel/process.c 2005-09-13 14:43:51.000000000 -0300
> @@ -287,11 +287,13 @@ struct task_struct *__switch_to(struct t
> #endif /* CONFIG_SPE */
> #endif /* CONFIG_SMP */
>
> +#ifdef CONFIG_ALTIVEC
> /* Avoid the trap. On smp this this never happens since
> * we don't set last_task_used_altivec -- Cort
> */
> if (new->thread.regs && last_task_used_altivec == new)
> new->thread.regs->msr |= MSR_VEC;
> +#endif
> #ifdef CONFIG_SPE
> /* Avoid the trap. On smp this this never happens since
> * we don't set last_task_used_spe
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Interrupt mapping for MPC8541
From: Bizhan Gholikhamseh (bgholikh) @ 2005-09-13 18:35 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 615 bytes --]
Hi ALL,
We are developing a custom board mother board based on
MPC8541 processor trying to run with Linux 2.6.11. The custom board has
hardwire the
interrupt lines for PCI peripherals with specific interrupt number for
each peripheral.
The MPC8541 has on Ethernet chip which during boot process the Linux
kernel assign
interrupt number 96 to it. Unfortunately one of our PCI peripheral that
is hardwire need that
interrupt number and this causes conflict.
Is there anyway we can avoid reserving this interrupt number so kernel
does not assign it unless it is asked specifically?
Thanks,
Bizhan
[-- Attachment #2: Type: text/html, Size: 1982 bytes --]
^ permalink raw reply
* [PATCH] ppc32 8xx: use io accessor macros instead of direct memory reference
From: Marcelo Tosatti @ 2005-09-13 17:30 UTC (permalink / raw)
To: torvalds; +Cc: linux-ppc-embedded
Convert core 8xx drivers to use in_xxxbe/in_xxx macros instead
of direct memory references.
Other than making IO accesses explicit (which is a plus for
readability), a common set of macros provides a unified place for the
volatile flag to constraint compiler code reordering.
There are several unlucky places at the moment which lack the
volatile flag.
Signed-off-by: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
diff --git a/arch/ppc/8xx_io/commproc.c b/arch/ppc/8xx_io/commproc.c
--- a/arch/ppc/8xx_io/commproc.c
+++ b/arch/ppc/8xx_io/commproc.c
@@ -73,7 +73,7 @@ cpm_mask_irq(unsigned int irq)
{
int cpm_vec = irq - CPM_IRQ_OFFSET;
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr &= ~(1 << cpm_vec);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr, in_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr) & ~(1 << cpm_vec));
}
static void
@@ -81,7 +81,7 @@ cpm_unmask_irq(unsigned int irq)
{
int cpm_vec = irq - CPM_IRQ_OFFSET;
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr |= (1 << cpm_vec);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr, in_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr) | (1 << cpm_vec));
}
static void
@@ -95,7 +95,7 @@ cpm_eoi(unsigned int irq)
{
int cpm_vec = irq - CPM_IRQ_OFFSET;
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cisr = (1 << cpm_vec);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cisr, (1 << cpm_vec));
}
struct hw_interrupt_type cpm_pic = {
@@ -133,7 +133,7 @@ m8xx_cpm_reset(void)
* manual recommends it.
* Bit 25, FAM can also be set to use FEC aggressive mode (860T).
*/
- imp->im_siu_conf.sc_sdcr = 1;
+ out_be32(&imp->im_siu_conf.sc_sdcr, 1),
/* Reclaim the DP memory for our use. */
m8xx_cpm_dpinit();
@@ -178,10 +178,10 @@ cpm_interrupt_init(void)
/* Initialize the CPM interrupt controller.
*/
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cicr =
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cicr,
(CICR_SCD_SCC4 | CICR_SCC_SCC3 | CICR_SCB_SCC2 | CICR_SCA_SCC1) |
- ((CPM_INTERRUPT/2) << 13) | CICR_HP_MASK;
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr = 0;
+ ((CPM_INTERRUPT/2) << 13) | CICR_HP_MASK);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr, 0);
/* install the CPM interrupt controller routines for the CPM
* interrupt vectors
@@ -198,7 +198,7 @@ cpm_interrupt_init(void)
if (setup_irq(CPM_IRQ_OFFSET + CPMVEC_ERROR, &cpm_error_irqaction))
panic("Could not allocate CPM error IRQ!");
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cicr |= CICR_IEN;
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cicr, in_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cicr) | CICR_IEN);
}
/*
@@ -212,8 +212,8 @@ cpm_get_irq(struct pt_regs *regs)
/* Get the vector by setting the ACK bit and then reading
* the register.
*/
- ((volatile immap_t *)IMAP_ADDR)->im_cpic.cpic_civr = 1;
- cpm_vec = ((volatile immap_t *)IMAP_ADDR)->im_cpic.cpic_civr;
+ out_be16(&((volatile immap_t *)IMAP_ADDR)->im_cpic.cpic_civr, 1);
+ cpm_vec = in_be16(&((volatile immap_t *)IMAP_ADDR)->im_cpic.cpic_civr);
cpm_vec >>= 11;
return cpm_vec;
diff --git a/arch/ppc/syslib/m8xx_setup.c b/arch/ppc/syslib/m8xx_setup.c
--- a/arch/ppc/syslib/m8xx_setup.c
+++ b/arch/ppc/syslib/m8xx_setup.c
@@ -144,12 +144,12 @@ void __init m8xx_calibrate_decr(void)
int freq, fp, divisor;
/* Unlock the SCCR. */
- ((volatile immap_t *)IMAP_ADDR)->im_clkrstk.cark_sccrk = ~KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_clkrstk.cark_sccrk = KAPWR_KEY;
+ out_be32(&((immap_t *)IMAP_ADDR)->im_clkrstk.cark_sccrk, ~KAPWR_KEY);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_clkrstk.cark_sccrk, KAPWR_KEY);
/* Force all 8xx processors to use divide by 16 processor clock. */
- ((volatile immap_t *)IMAP_ADDR)->im_clkrst.car_sccr |= 0x02000000;
-
+ out_be32(&((immap_t *)IMAP_ADDR)->im_clkrst.car_sccr,
+ in_be32(&((immap_t *)IMAP_ADDR)->im_clkrst.car_sccr)|0x02000000);
/* Processor frequency is MHz.
* The value 'fp' is the number of decrementer ticks per second.
*/
@@ -175,28 +175,24 @@ void __init m8xx_calibrate_decr(void)
* we guarantee the registers are locked, then we unlock them
* for our use.
*/
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_tbscrk = ~KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_rtcsck = ~KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_tbk = ~KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_tbscrk = KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_rtcsck = KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_tbk = KAPWR_KEY;
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sitk.sitk_tbscrk, ~KAPWR_KEY);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sitk.sitk_rtcsck, ~KAPWR_KEY);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sitk.sitk_tbk, ~KAPWR_KEY);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sitk.sitk_tbscrk, KAPWR_KEY);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sitk.sitk_rtcsck, KAPWR_KEY);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sitk.sitk_tbk, KAPWR_KEY);
/* Disable the RTC one second and alarm interrupts. */
- ((volatile immap_t *)IMAP_ADDR)->im_sit.sit_rtcsc &=
- ~(RTCSC_SIE | RTCSC_ALE);
+ out_be16(&((immap_t *)IMAP_ADDR)->im_sit.sit_rtcsc, in_be16(&((immap_t *)IMAP_ADDR)->im_sit.sit_rtcsc) & ~(RTCSC_SIE | RTCSC_ALE));
/* Enable the RTC */
- ((volatile immap_t *)IMAP_ADDR)->im_sit.sit_rtcsc |=
- (RTCSC_RTF | RTCSC_RTE);
+ out_be16(&((immap_t *)IMAP_ADDR)->im_sit.sit_rtcsc, in_be16(&((immap_t *)IMAP_ADDR)->im_sit.sit_rtcsc) | (RTCSC_RTF | RTCSC_RTE));
/* Enabling the decrementer also enables the timebase interrupts
* (or from the other point of view, to get decrementer interrupts
* we have to enable the timebase). The decrementer interrupt
* is wired into the vector table, nothing to do here for that.
*/
- ((volatile immap_t *)IMAP_ADDR)->im_sit.sit_tbscr =
- ((mk_int_int_mask(DEC_INTERRUPT) << 8) |
- (TBSCR_TBF | TBSCR_TBE));
+ out_be16(&((immap_t *)IMAP_ADDR)->im_sit.sit_tbscr, (mk_int_int_mask(DEC_INTERRUPT) << 8) | (TBSCR_TBF | TBSCR_TBE));
if (setup_irq(DEC_INTERRUPT, &tbint_irqaction))
panic("Could not allocate timer IRQ!");
@@ -216,9 +212,9 @@ void __init m8xx_calibrate_decr(void)
static int
m8xx_set_rtc_time(unsigned long time)
{
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_rtck = KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sit.sit_rtc = time;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_rtck = ~KAPWR_KEY;
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sitk.sitk_rtck, KAPWR_KEY);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sit.sit_rtc, time);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sitk.sitk_rtck, ~KAPWR_KEY);
return(0);
}
@@ -226,7 +222,7 @@ static unsigned long
m8xx_get_rtc_time(void)
{
/* Get time from the RTC. */
- return((unsigned long)(((immap_t *)IMAP_ADDR)->im_sit.sit_rtc));
+ return (unsigned long) in_be32(&((immap_t *)IMAP_ADDR)->im_sit.sit_rtc);
}
static void
@@ -235,13 +231,13 @@ m8xx_restart(char *cmd)
__volatile__ unsigned char dummy;
local_irq_disable();
- ((immap_t *)IMAP_ADDR)->im_clkrst.car_plprcr |= 0x00000080;
+ out_be32(&((immap_t *)IMAP_ADDR)->im_clkrst.car_plprcr, in_be32(&((immap_t *)IMAP_ADDR)->im_clkrst.car_plprcr) | 0x00000080);
/* Clear the ME bit in MSR to cause checkstop on machine check
*/
mtmsr(mfmsr() & ~0x1000);
- dummy = ((immap_t *)IMAP_ADDR)->im_clkrst.res[0];
+ dummy = in_8(&((immap_t *)IMAP_ADDR)->im_clkrst.res[0]);
printk("Restart failed\n");
while(1);
}
@@ -306,8 +302,7 @@ m8xx_init_IRQ(void)
i8259_init(0);
/* The i8259 cascade interrupt must be level sensitive. */
- ((immap_t *)IMAP_ADDR)->im_siu_conf.sc_siel &=
- ~(0x80000000 >> ISA_BRIDGE_INT);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_siu_conf.sc_siel, in_be32(&((immap_t *)IMAP_ADDR)->im_siu_conf.sc_siel & ~(0x80000000 >> ISA_BRIDGE_INT)));
if (setup_irq(ISA_BRIDGE_INT, &mbx_i8259_irqaction))
enable_irq(ISA_BRIDGE_INT);
diff --git a/arch/ppc/syslib/m8xx_wdt.c b/arch/ppc/syslib/m8xx_wdt.c
--- a/arch/ppc/syslib/m8xx_wdt.c
+++ b/arch/ppc/syslib/m8xx_wdt.c
@@ -29,8 +29,8 @@ void m8xx_wdt_reset(void)
{
volatile immap_t *imap = (volatile immap_t *)IMAP_ADDR;
- imap->im_siu_conf.sc_swsr = 0x556c; /* write magic1 */
- imap->im_siu_conf.sc_swsr = 0xaa39; /* write magic2 */
+ out_be16(imap->im_siu_conf.sc_swsr, 0x556c); /* write magic1 */
+ out_be16(imap->im_siu_conf.sc_swsr, 0xaa39); /* write magic2 */
}
static irqreturn_t m8xx_wdt_interrupt(int irq, void *dev, struct pt_regs *regs)
@@ -39,7 +39,7 @@ static irqreturn_t m8xx_wdt_interrupt(in
m8xx_wdt_reset();
- imap->im_sit.sit_piscr |= PISCR_PS; /* clear irq */
+ out_be16(imap->im_sit.sit_piscr, in_be16(imap->im_sit.sit_piscr | PISCR_PS)); /* clear irq */
return IRQ_HANDLED;
}
@@ -51,7 +51,7 @@ void __init m8xx_wdt_handler_install(bd_
u32 sypcr;
u32 pitrtclk;
- sypcr = imap->im_siu_conf.sc_sypcr;
+ sypcr = in_be32(imap->im_siu_conf.sc_sypcr);
if (!(sypcr & 0x04)) {
printk(KERN_NOTICE "m8xx_wdt: wdt disabled (SYPCR: 0x%08X)\n",
@@ -87,9 +87,9 @@ void __init m8xx_wdt_handler_install(bd_
else
pitc = pitrtclk * wdt_timeout / binfo->bi_intfreq / 2;
- imap->im_sit.sit_pitc = pitc << 16;
- imap->im_sit.sit_piscr =
- (mk_int_int_mask(PIT_INTERRUPT) << 8) | PISCR_PIE | PISCR_PTE;
+ out_be32(imap->im_sit.sit_pitc, pitc << 16);
+
+ out_be16(imap->im_sit.sit_piscr, (mk_int_int_mask(PIT_INTERRUPT) << 8) | PISCR_PIE | PISCR_PTE);
if (setup_irq(PIT_INTERRUPT, &m8xx_wdt_irqaction))
panic("m8xx_wdt: error setting up the watchdog irq!");
diff --git a/arch/ppc/syslib/ppc8xx_pic.c b/arch/ppc/syslib/ppc8xx_pic.c
--- a/arch/ppc/syslib/ppc8xx_pic.c
+++ b/arch/ppc/syslib/ppc8xx_pic.c
@@ -6,6 +6,7 @@
#include <linux/signal.h>
#include <linux/interrupt.h>
#include <asm/irq.h>
+#include <asm/io.h>
#include <asm/8xx_immap.h>
#include <asm/mpc8xx.h>
#include "ppc8xx_pic.h"
@@ -29,8 +30,7 @@ static void m8xx_mask_irq(unsigned int i
word = irq_nr >> 5;
ppc_cached_irq_mask[word] &= ~(1 << (31-bit));
- ((immap_t *)IMAP_ADDR)->im_siu_conf.sc_simask =
- ppc_cached_irq_mask[word];
+ out_be32(&((immap_t *)IMAP_ADDR)->im_siu_conf.sc_simask, ppc_cached_irq_mask[word]);
}
static void m8xx_unmask_irq(unsigned int irq_nr)
@@ -41,8 +41,7 @@ static void m8xx_unmask_irq(unsigned int
word = irq_nr >> 5;
ppc_cached_irq_mask[word] |= (1 << (31-bit));
- ((immap_t *)IMAP_ADDR)->im_siu_conf.sc_simask =
- ppc_cached_irq_mask[word];
+ out_be32(&((immap_t *)IMAP_ADDR)->im_siu_conf.sc_simask, ppc_cached_irq_mask[word]);
}
static void m8xx_end_irq(unsigned int irq_nr)
@@ -55,8 +54,7 @@ static void m8xx_end_irq(unsigned int ir
word = irq_nr >> 5;
ppc_cached_irq_mask[word] |= (1 << (31-bit));
- ((immap_t *)IMAP_ADDR)->im_siu_conf.sc_simask =
- ppc_cached_irq_mask[word];
+ out_be32(&((immap_t *)IMAP_ADDR)->im_siu_conf.sc_simask, ppc_cached_irq_mask[word]);
}
}
@@ -69,9 +67,8 @@ static void m8xx_mask_and_ack(unsigned i
word = irq_nr >> 5;
ppc_cached_irq_mask[word] &= ~(1 << (31-bit));
- ((immap_t *)IMAP_ADDR)->im_siu_conf.sc_simask =
- ppc_cached_irq_mask[word];
- ((immap_t *)IMAP_ADDR)->im_siu_conf.sc_sipend = 1 << (31-bit);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_siu_conf.sc_simask, ppc_cached_irq_mask[word]);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_siu_conf.sc_sipend, 1 << (31-bit));
}
struct hw_interrupt_type ppc8xx_pic = {
@@ -93,7 +90,7 @@ m8xx_get_irq(struct pt_regs *regs)
/* For MPC8xx, read the SIVEC register and shift the bits down
* to get the irq number.
*/
- irq = ((immap_t *)IMAP_ADDR)->im_siu_conf.sc_sivec >> 26;
+ irq = in_be32(&((immap_t *)IMAP_ADDR)->im_siu_conf.sc_sivec) >> 26;
/*
* When we read the sivec without an interrupt to process, we will
^ permalink raw reply
* Re: gdb hangs on Linux 2.6.11 on 8xx
From: Marcelo Tosatti @ 2005-09-13 18:04 UTC (permalink / raw)
To: Aristeu Sergio Rozanski Filho; +Cc: linuxppc-embedded
In-Reply-To: <20050913172213.GA3964@oops.ghostprotocols.net>
On Tue, Sep 13, 2005 at 02:22:13PM -0300, Aristeu Sergio Rozanski Filho wrote:
> Hi Marcelo,
> after the last Chris post, I decided to double check if I wasn't doing
> something wrong. vanilla 2.6.13 hangs in the same way my patched 2.6.10 does.
>
> > How does the disassemble of __switch_to looks like?
> from 2.6.13 kernel
> Dump of assembler code for function __switch_to:
> 0xc00055a4 <__switch_to+0>: mflr r0
> 0xc00055a8 <__switch_to+4>: stwu r1,-16(r1)
> 0xc00055ac <__switch_to+8>: stw r31,12(r1)
> 0xc00055b0 <__switch_to+12>: mr r11,r4
> 0xc00055b4 <__switch_to+16>: stw r0,20(r1)
> 0xc00055b8 <__switch_to+20>: mfmsr r31
> 0xc00055bc <__switch_to+24>: rlwinm r0,r31,0,17,15
> 0xc00055c0 <__switch_to+28>: mtmsr r0
> 0xc00055c4 <__switch_to+32>: lwz r10,460(r4)
> 0xc00055c8 <__switch_to+36>: addi r3,r2,456
> 0xc00055cc <__switch_to+40>: addi r4,r4,456
> 0xc00055d0 <__switch_to+44>: cmpwi cr7,r10,0
> 0xc00055d4 <__switch_to+48>: beq- cr7,0xc00055e8 <__switch_to+68>
> 0xc00055d8 <__switch_to+52>: lis r9,-16354
> 0xc00055dc <__switch_to+56>: lwz r0,28880(r9)
> 0xc00055e0 <__switch_to+60>: cmpw cr7,r0,r11
> 0xc00055e4 <__switch_to+64>: beq- cr7,0xc0005604 <__switch_to+96>
> 0xc00055e8 <__switch_to+68>: bl 0xc0003024 <_switch>
> 0xc00055ec <__switch_to+72>: mtmsr r31
> 0xc00055f0 <__switch_to+76>: lwz r0,20(r1)
> 0xc00055f4 <__switch_to+80>: lwz r31,12(r1)
> 0xc00055f8 <__switch_to+84>: addi r1,r1,16
> 0xc00055fc <__switch_to+88>: mtlr r0
> 0xc0005600 <__switch_to+92>: blr
> 0xc0005604 <__switch_to+96>: lwz r0,132(r10)
> 0xc0005608 <__switch_to+100>: oris r0,r0,512
> 0xc000560c <__switch_to+104>: stw r0,132(r10)
> 0xc0005610 <__switch_to+108>: b 0xc00055e8 <__switch_to+68>
> End of assembler dump.
>
> > Chris oopsen is exactly what the 'icbi' patch fixes.
> notice that what I'm having here is not an oops
>
> but if for Chris works, I must be doing something wrong, sorry for the noise
Hi Aris,
gdb S 30106778 0 691 687 692 (NOTLB)
Call trace:
[c0005330] __switch_to+0x44/0x78
[c015beb0] schedule+0x30c/0x730
[c015c888] schedule_timeout+0xdc/0xe0
[c0068918] sys_poll+0x27c/0x404
[c0002810] syscall_dotrace_cont+0x24/0x38
flash_test t 100009E4 0 692 691 (NOTLB)
Call trace:
[c0005330] __switch_to+0x44/0x78
[c015beb0] schedule+0x30c/0x730
[c0026248] ptrace_stop+0x68/0x88
[c0026604] get_signal_to_deliver+0x130/0x2b4
[c00063dc] do_signal+0x38/0x464
[c0003034] do_user_signal+0x74/0xc4
flash_test is trying to handle a signal, can you print some information
about it in get_signal_to_deliver (before ptrace_stop), such as si_signo:
typedef struct siginfo {
int si_signo;
int si_errno;
int si_code;
ptrace_stop() calls do_notify_parent_cldstop() to wakeup gdb, maybe
there's something wrong during wakeup?
The box locks up completly or its just gdb that freezes?
^ permalink raw reply
* Re: gdb hangs on Linux 2.6.11 on 8xx
From: Aristeu Sergio Rozanski Filho @ 2005-09-13 17:22 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linuxppc-embedded
In-Reply-To: <20050913151132.GF10602@dmt.cnet>
Hi Marcelo,
after the last Chris post, I decided to double check if I wasn't doing
something wrong. vanilla 2.6.13 hangs in the same way my patched 2.6.10 does.
> How does the disassemble of __switch_to looks like?
from 2.6.13 kernel
Dump of assembler code for function __switch_to:
0xc00055a4 <__switch_to+0>: mflr r0
0xc00055a8 <__switch_to+4>: stwu r1,-16(r1)
0xc00055ac <__switch_to+8>: stw r31,12(r1)
0xc00055b0 <__switch_to+12>: mr r11,r4
0xc00055b4 <__switch_to+16>: stw r0,20(r1)
0xc00055b8 <__switch_to+20>: mfmsr r31
0xc00055bc <__switch_to+24>: rlwinm r0,r31,0,17,15
0xc00055c0 <__switch_to+28>: mtmsr r0
0xc00055c4 <__switch_to+32>: lwz r10,460(r4)
0xc00055c8 <__switch_to+36>: addi r3,r2,456
0xc00055cc <__switch_to+40>: addi r4,r4,456
0xc00055d0 <__switch_to+44>: cmpwi cr7,r10,0
0xc00055d4 <__switch_to+48>: beq- cr7,0xc00055e8 <__switch_to+68>
0xc00055d8 <__switch_to+52>: lis r9,-16354
0xc00055dc <__switch_to+56>: lwz r0,28880(r9)
0xc00055e0 <__switch_to+60>: cmpw cr7,r0,r11
0xc00055e4 <__switch_to+64>: beq- cr7,0xc0005604 <__switch_to+96>
0xc00055e8 <__switch_to+68>: bl 0xc0003024 <_switch>
0xc00055ec <__switch_to+72>: mtmsr r31
0xc00055f0 <__switch_to+76>: lwz r0,20(r1)
0xc00055f4 <__switch_to+80>: lwz r31,12(r1)
0xc00055f8 <__switch_to+84>: addi r1,r1,16
0xc00055fc <__switch_to+88>: mtlr r0
0xc0005600 <__switch_to+92>: blr
0xc0005604 <__switch_to+96>: lwz r0,132(r10)
0xc0005608 <__switch_to+100>: oris r0,r0,512
0xc000560c <__switch_to+104>: stw r0,132(r10)
0xc0005610 <__switch_to+108>: b 0xc00055e8 <__switch_to+68>
End of assembler dump.
> Chris oopsen is exactly what the 'icbi' patch fixes.
notice that what I'm having here is not an oops
but if for Chris works, I must be doing something wrong, sorry for the noise
--
Aristeu
^ permalink raw reply
* __switch_to test-and-branch ALTIVEC specific?
From: Marcelo Tosatti @ 2005-09-13 17:50 UTC (permalink / raw)
To: linuxppc-dev, linux-ppc-embedded
Hi,
This test&branch looks AltiVec specific, any reason for not #ifdef'ing it
out?
--- arch/ppc/kernel/process.c.orig 2005-09-13 14:43:13.000000000 -0300
+++ arch/ppc/kernel/process.c 2005-09-13 14:43:51.000000000 -0300
@@ -287,11 +287,13 @@ struct task_struct *__switch_to(struct t
#endif /* CONFIG_SPE */
#endif /* CONFIG_SMP */
+#ifdef CONFIG_ALTIVEC
/* Avoid the trap. On smp this this never happens since
* we don't set last_task_used_altivec -- Cort
*/
if (new->thread.regs && last_task_used_altivec == new)
new->thread.regs->msr |= MSR_VEC;
+#endif
#ifdef CONFIG_SPE
/* Avoid the trap. On smp this this never happens since
* we don't set last_task_used_spe
^ permalink raw reply
* Merge Question on asm-ppc*/rwsem.h
From: Jon Loeliger @ 2005-09-13 17:06 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org, linuxppc64-dev
Paul (or anyone, really),
I am not too familiar with some of the low-level machine
details that might (do!) influence some of the semaphore
implementations. I was hoping I might get you to give
me a quick nudge in the right direction here.
Here is a brief example of the differences found in
the ppc and pp64 versions of asm-ppc*/rwsem.h:
(ppc is -, and ppc64 is + here)
@@ -69,9 +74,7 @@
*/
static inline void __down_read(struct rw_semaphore *sem)
{
- if (atomic_inc_return((atomic_t *)(&sem->count)) > 0)
- smp_wmb();
- else
+ if (unlikely(atomic_inc_return((atomic_t *)(&sem->count)) <= 0))
rwsem_down_read_failed(sem);
}
If we add likely() to the PPC version, and then invert it,
we can get effectively this:
static inline void __down_read(struct rw_semaphore *sem)
{
if (unlikely(atomic_inc_return((atomic_t *)(&sem->count)) <= 0))
rwsem_down_read_failed(sem);
#ifndef __powerpc64__
else
smp_wmb();
#endif
}
Which begs the question, what is the "else smp_wmb();" clause
really doing for us in the ppc32 case, and can we either
get rid of it, or is it safe to add to the ppc64 case?
Thanks,
jdl
^ permalink raw reply
* Re: PATCH Merge kmap_types.h
From: Jon Loeliger @ 2005-09-13 16:42 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org, linuxppc64-dev
In-Reply-To: <1126039905.25148.66.camel@cashmere.sps.mot.com>
On Tue, 2005-09-06 at 15:51, Jon Loeliger wrote:
> Here is a patch to merge the ppc and pp64 version of kmap_types.h
>
> Signed-off-by: Jon Loeliger <jdl@freescale.com>
> Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
> ---
Paul,
Any reason why this patch for merging kmap_types.h
keeps slipping through cracks? Is it not applying
or something like that? Some merge issue I'm missing?
Thanks,
jdl
^ permalink raw reply
* Re: gdb hangs on Linux 2.6.11 on 8xx
From: Chris @ 2005-09-13 16:27 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20050913142513.GD10602@dmt.cnet>
Marcelo Tosatti wrote:
> Folks,
>
> Can you please upgrade to a recent kernel?
>
> A problem with ptrace has been fixed sometime ago, it might be what you're hitting.
>
> The fix is part of v2.6.13:
>
> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=bf85fa6c878aa3968df47d7f70a2b506c3e53b99
>
> If that does not work, complain.
>
OK, that works. Gdb and gdbserver behave as they should.
Thanks,
Chris.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox