* [PATCH 1/3] powerpc: Add a #define for aligning to a long-sized boundary
From: Michael Ellerman @ 2008-07-17 7:17 UTC (permalink / raw)
To: linuxppc-dev
Add a #define for aligning to a long-sized boundary. It would be nice
to use sizeof(long) for this, but that requires generating the value
with asm-offsets.c, and asm-offsets.c includes asm-compat.h and we
descend into some sort of recursive include hell.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
include/asm-powerpc/asm-compat.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/asm-powerpc/asm-compat.h b/include/asm-powerpc/asm-compat.h
index 8ec2e1d..8f0fe79 100644
--- a/include/asm-powerpc/asm-compat.h
+++ b/include/asm-powerpc/asm-compat.h
@@ -22,6 +22,7 @@
#define PPC_STL stringify_in_c(std)
#define PPC_LCMPI stringify_in_c(cmpdi)
#define PPC_LONG stringify_in_c(.llong)
+#define PPC_LONG_ALIGN stringify_in_c(.balign 8)
#define PPC_TLNEI stringify_in_c(tdnei)
#define PPC_LLARX stringify_in_c(ldarx)
#define PPC_STLCX stringify_in_c(stdcx.)
@@ -43,6 +44,7 @@
#define PPC_STL stringify_in_c(stw)
#define PPC_LCMPI stringify_in_c(cmpwi)
#define PPC_LONG stringify_in_c(.long)
+#define PPC_LONG_ALIGN stringify_in_c(.balign 4)
#define PPC_TLNEI stringify_in_c(twnei)
#define PPC_LLARX stringify_in_c(lwarx)
#define PPC_STLCX stringify_in_c(stwcx.)
--
1.5.5
^ permalink raw reply related
* [PATCH 2/3] powerpc: Use PPC_LONG_ALIGN in uaccess.h
From: Michael Ellerman @ 2008-07-17 7:17 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <3756cbfb076b2fa0b93ec990aabfee73296443d9.1216279070.git.michael@ellerman.id.au>
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
include/asm-powerpc/uaccess.h | 21 +++++++++------------
1 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/include/asm-powerpc/uaccess.h b/include/asm-powerpc/uaccess.h
index 1a0736f..bd0fb84 100644
--- a/include/asm-powerpc/uaccess.h
+++ b/include/asm-powerpc/uaccess.h
@@ -6,6 +6,7 @@
#include <linux/sched.h>
#include <linux/errno.h>
+#include <asm/asm-compat.h>
#include <asm/processor.h>
#include <asm/page.h>
@@ -141,12 +142,11 @@ extern long __put_user_bad(void);
" b 2b\n" \
".previous\n" \
".section __ex_table,\"a\"\n" \
- " .balign %5\n" \
+ PPC_LONG_ALIGN "\n" \
PPC_LONG "1b,3b\n" \
".previous" \
: "=r" (err) \
- : "r" (x), "b" (addr), "i" (-EFAULT), "0" (err),\
- "i"(sizeof(unsigned long)))
+ : "r" (x), "b" (addr), "i" (-EFAULT), "0" (err))
#ifdef __powerpc64__
#define __put_user_asm2(x, ptr, retval) \
@@ -162,13 +162,12 @@ extern long __put_user_bad(void);
" b 3b\n" \
".previous\n" \
".section __ex_table,\"a\"\n" \
- " .balign %5\n" \
+ PPC_LONG_ALIGN "\n" \
PPC_LONG "1b,4b\n" \
PPC_LONG "2b,4b\n" \
".previous" \
: "=r" (err) \
- : "r" (x), "b" (addr), "i" (-EFAULT), "0" (err),\
- "i"(sizeof(unsigned long)))
+ : "r" (x), "b" (addr), "i" (-EFAULT), "0" (err))
#endif /* __powerpc64__ */
#define __put_user_size(x, ptr, size, retval) \
@@ -226,12 +225,11 @@ extern long __get_user_bad(void);
" b 2b\n" \
".previous\n" \
".section __ex_table,\"a\"\n" \
- " .balign %5\n" \
+ PPC_LONG_ALIGN "\n" \
PPC_LONG "1b,3b\n" \
".previous" \
: "=r" (err), "=r" (x) \
- : "b" (addr), "i" (-EFAULT), "0" (err), \
- "i"(sizeof(unsigned long)))
+ : "b" (addr), "i" (-EFAULT), "0" (err))
#ifdef __powerpc64__
#define __get_user_asm2(x, addr, err) \
@@ -249,13 +247,12 @@ extern long __get_user_bad(void);
" b 3b\n" \
".previous\n" \
".section __ex_table,\"a\"\n" \
- " .balign %5\n" \
+ PPC_LONG_ALIGN "\n" \
PPC_LONG "1b,4b\n" \
PPC_LONG "2b,4b\n" \
".previous" \
: "=r" (err), "=&r" (x) \
- : "b" (addr), "i" (-EFAULT), "0" (err), \
- "i"(sizeof(unsigned long)))
+ : "b" (addr), "i" (-EFAULT), "0" (err))
#endif /* __powerpc64__ */
#define __get_user_size(x, ptr, size, retval) \
--
1.5.5
^ permalink raw reply related
* [PATCH 3/3] powerpc: Use PPC_LONG and PPC_LONG_ALIGN in lib/string.S
From: Michael Ellerman @ 2008-07-17 7:17 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <3756cbfb076b2fa0b93ec990aabfee73296443d9.1216279070.git.michael@ellerman.id.au>
No change to the generated code.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/lib/string.S | 18 ++++++------------
1 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/lib/string.S b/arch/powerpc/lib/string.S
index 49eb1f1..64e2e49 100644
--- a/arch/powerpc/lib/string.S
+++ b/arch/powerpc/lib/string.S
@@ -13,13 +13,7 @@
#include <asm/ppc_asm.h>
.section __ex_table,"a"
-#ifdef CONFIG_PPC64
- .align 3
-#define EXTBL .llong
-#else
- .align 2
-#define EXTBL .long
-#endif
+ PPC_LONG_ALIGN
.text
_GLOBAL(strcpy)
@@ -160,9 +154,9 @@ _GLOBAL(__clear_user)
blr
.section __ex_table,"a"
- EXTBL 11b,90b
- EXTBL 1b,91b
- EXTBL 8b,92b
+ PPC_LONG 11b,90b
+ PPC_LONG 1b,91b
+ PPC_LONG 8b,92b
.text
_GLOBAL(__strncpy_from_user)
@@ -183,7 +177,7 @@ _GLOBAL(__strncpy_from_user)
blr
.section __ex_table,"a"
- EXTBL 1b,99b
+ PPC_LONG 1b,99b
.text
/* r3 = str, r4 = len (> 0), r5 = top (highest addr) */
@@ -208,4 +202,4 @@ _GLOBAL(__strnlen_user)
blr
.section __ex_table,"a"
- EXTBL 1b,99b
+ PPC_LONG 1b,99b
--
1.5.5
^ permalink raw reply related
* [PATCH 1/4] powerpc: ftrace: Use PPC_NOP_INSTR #define for NOP
From: Michael Ellerman @ 2008-07-17 7:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: srostedt
And move ftrace_nop into the only function it's used in.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/ftrace.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
index 3855ceb..78f4423 100644
--- a/arch/powerpc/kernel/ftrace.c
+++ b/arch/powerpc/kernel/ftrace.c
@@ -15,11 +15,10 @@
#include <linux/list.h>
#include <asm/cacheflush.h>
+#include <asm/code-patching.h>
#include <asm/ftrace.h>
-static unsigned int ftrace_nop = 0x60000000;
-
#ifdef CONFIG_PPC32
# define GET_ADDR(addr) addr
#else
@@ -35,6 +34,8 @@ static unsigned int notrace ftrace_calc_offset(long ip, long addr)
notrace unsigned char *ftrace_nop_replace(void)
{
+ static unsigned int ftrace_nop = PPC_NOP_INSTR;
+
return (char *)&ftrace_nop;
}
--
1.5.5
^ permalink raw reply related
* [PATCH 2/4] powerpc: ftrace: Use ppc_function_entry() rather than hand-rolled macro
From: Michael Ellerman @ 2008-07-17 7:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: srostedt
In-Reply-To: <d452d52afbde7001bf85070ee528d21bfa814d8d.1216279290.git.michael@ellerman.id.au>
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/ftrace.c | 10 +---------
1 files changed, 1 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
index 78f4423..1d6f174 100644
--- a/arch/powerpc/kernel/ftrace.c
+++ b/arch/powerpc/kernel/ftrace.c
@@ -19,14 +19,6 @@
#include <asm/ftrace.h>
-#ifdef CONFIG_PPC32
-# define GET_ADDR(addr) addr
-#else
-/* PowerPC64's functions are data that points to the functions */
-# define GET_ADDR(addr) *(unsigned long *)addr
-#endif
-
-
static unsigned int notrace ftrace_calc_offset(long ip, long addr)
{
return (int)(addr - ip);
@@ -49,7 +41,7 @@ notrace unsigned char *ftrace_call_replace(unsigned long ip, unsigned long addr)
* instruction that is going to be modified, without modifying the
* code.
*/
- addr = GET_ADDR(addr);
+ addr = ppc_function_entry((void *)addr);
/* Set to "bl addr" */
op = 0x48000001 | (ftrace_calc_offset(ip, addr) & 0x03fffffc);
--
1.5.5
^ permalink raw reply related
* [PATCH 3/4] powerpc: ftrace: Use create_branch() and cope with errors
From: Michael Ellerman @ 2008-07-17 7:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: srostedt
In-Reply-To: <d452d52afbde7001bf85070ee528d21bfa814d8d.1216279290.git.michael@ellerman.id.au>
Use create_branch() rather than doing it by hand. It's possible that
we are unable to create a branch to the address, if it's too far away,
in which case just return a nop. This will break the tracing, but
shouldn't crash the kernel at least.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/ftrace.c | 20 ++++++++------------
1 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
index 1d6f174..49a2049 100644
--- a/arch/powerpc/kernel/ftrace.c
+++ b/arch/powerpc/kernel/ftrace.c
@@ -19,11 +19,6 @@
#include <asm/ftrace.h>
-static unsigned int notrace ftrace_calc_offset(long ip, long addr)
-{
- return (int)(addr - ip);
-}
-
notrace unsigned char *ftrace_nop_replace(void)
{
static unsigned int ftrace_nop = PPC_NOP_INSTR;
@@ -35,16 +30,17 @@ notrace unsigned char *ftrace_call_replace(unsigned long ip, unsigned long addr)
{
static unsigned int op;
- /*
- * It would be nice to just use create_function_call, but that will
- * update the code itself. Here we need to just return the
- * instruction that is going to be modified, without modifying the
- * code.
- */
addr = ppc_function_entry((void *)addr);
/* Set to "bl addr" */
- op = 0x48000001 | (ftrace_calc_offset(ip, addr) & 0x03fffffc);
+ op = create_branch((unsigned int *)ip, addr, BRANCH_SET_LINK);
+
+ /*
+ * This routine is not allowed to fail, but create_branch() can.
+ * In that case, just return nop and cross our fingers.
+ */
+ if (!op)
+ return ftrace_nop_replace();
/*
* No locking needed, this must be called via kstop_machine
--
1.5.5
^ permalink raw reply related
* [PATCH 4/4] powerpc: ftrace: Use PPC_LONG and PPC_LONG_ALIGN asm macros
From: Michael Ellerman @ 2008-07-17 7:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: srostedt
In-Reply-To: <d452d52afbde7001bf85070ee528d21bfa814d8d.1216279290.git.michael@ellerman.id.au>
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/ftrace.c | 13 +++----------
1 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
index 49a2049..0e9fc10 100644
--- a/arch/powerpc/kernel/ftrace.c
+++ b/arch/powerpc/kernel/ftrace.c
@@ -14,6 +14,7 @@
#include <linux/init.h>
#include <linux/list.h>
+#include <asm/asm-compat.h>
#include <asm/cacheflush.h>
#include <asm/code-patching.h>
#include <asm/ftrace.h>
@@ -49,14 +50,6 @@ notrace unsigned char *ftrace_call_replace(unsigned long ip, unsigned long addr)
return (unsigned char *)&op;
}
-#ifdef CONFIG_PPC64
-# define _ASM_ALIGN " .align 3 "
-# define _ASM_PTR " .llong "
-#else
-# define _ASM_ALIGN " .align 2 "
-# define _ASM_PTR " .long "
-#endif
-
notrace int
ftrace_modify_code(unsigned long ip, unsigned char *old_code,
unsigned char *new_code)
@@ -85,8 +78,8 @@ ftrace_modify_code(unsigned long ip, unsigned char *old_code,
" b 2b\n"
".previous\n"
".section __ex_table,\"a\"\n"
- _ASM_ALIGN "\n"
- _ASM_PTR "1b, 3b\n"
+ PPC_LONG_ALIGN "\n"
+ PPC_LONG "1b, 3b\n"
".previous"
: "=r"(faulted), "=r"(replaced)
: "r"(ip), "r"(new),
--
1.5.5
^ permalink raw reply related
* how to allocate 9MB of memory in kernel ?
From: Misbah khan @ 2008-07-17 7:26 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I need to allocate 9 MB of memory in to the kernel space which i need to
mmap for the application to access.
I need to know what could be the best possible way of doing the same.
Please share your experience in this regard .
Thank you in advance
----Misbah <><
--
View this message in context: http://www.nabble.com/how-to-allocate-9MB-of-memory-in-kernel---tp18503022p18503022.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] Support for DS75 thermal sensor
From: Wolfgang Grandegger @ 2008-07-17 7:31 UTC (permalink / raw)
To: Jean Delvare; +Cc: Linuxppc-dev, lm-sensors, Detlev Zundel, Alan Clucas
In-Reply-To: <20080716162942.6fcb526d@hyperion.delvare>
Jean Delvare wrote:
> On Wed, 16 Jul 2008 10:18:26 -0400, Jon Smirl wrote:
>> On 7/16/08, Grant Likely <grant.likely@secretlab.ca> wrote:
>>> On Wed, Jul 16, 2008 at 12:10:59PM +0200, Jean Delvare wrote:
>>> > On Wed, 16 Jul 2008 11:50:15 +0200, Wolfgang Grandegger wrote:
>>> > > Jean Delvare wrote:
>>> > >
>>>
>>>>> Yep, as probing might not be acceptable in some cases, I makes sense to
>>> > > add a property to suppress probing:
>>> >
>>> > It'd rather make no-probing the default if possible. My understanding
>>> > is that all systems using i2c-mpc should have proper platform data.
>>>
>>>
>>> Total ACK. From my perspective, probing should be off by default because the
>>> typical use case in powerpc land is to trust data in the device tree. Add the
>>> property to turn on probing, not to turn it off. Also, you'll need to
>>> document the semantics of such a property. ie. what exactly does it
>>> mean when the probing property is present and the spi bus node has child
>>> nodes?
>> I've found this thread now. Why can't we totally remove probing from
>> i2c-mpc? These are embedded systems, not open boxes like a PC. If a
>> i2c client hasn't been converted to the new model yet, convert it
>> before deploying with the new i2c-mpc driver. It's not very hard to
>> convert the client drivers.
>
> I tend to agree. And the number of unconverted drivers is getting very
> low these days. Only 2 RTC drivers are left, and by the end of the day,
> almost all hwmon drivers will be converted as well.
Thinking more about it I also prefer removing the I2C_CLASS_HWMON flag
completely. It just affects HWMON devices anyhow and if there is still
an old style driver around, it should be converted.
Wolfgang.
^ permalink raw reply
* Re: [PATCH] Support for DS75 thermal sensor
From: Grant Likely @ 2008-07-17 7:33 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Jean Delvare, Linuxppc-dev, Alan Clucas, Detlev Zundel,
lm-sensors
In-Reply-To: <487EF54C.5020007@grandegger.com>
On Thu, Jul 17, 2008 at 09:31:24AM +0200, Wolfgang Grandegger wrote:
> Jean Delvare wrote:
>> On Wed, 16 Jul 2008 10:18:26 -0400, Jon Smirl wrote:
>>> I've found this thread now. Why can't we totally remove probing from
>>> i2c-mpc? These are embedded systems, not open boxes like a PC. If a
>>> i2c client hasn't been converted to the new model yet, convert it
>>> before deploying with the new i2c-mpc driver. It's not very hard to
>>> convert the client drivers.
>>
>> I tend to agree. And the number of unconverted drivers is getting very
>> low these days. Only 2 RTC drivers are left, and by the end of the day,
>> almost all hwmon drivers will be converted as well.
>
> Thinking more about it I also prefer removing the I2C_CLASS_HWMON flag
> completely. It just affects HWMON devices anyhow and if there is still
> an old style driver around, it should be converted.
I'm cool with that.
g.
^ permalink raw reply
* Re: how to allocate 9MB of memory in kernel ?
From: Marco Stornelli @ 2008-07-17 7:51 UTC (permalink / raw)
To: Misbah khan; +Cc: linuxppc-embedded
In-Reply-To: <18503022.post@talk.nabble.com>
Misbah khan ha scritto:
> Hi all,
>
> I need to allocate 9 MB of memory in to the kernel space which i need to
> mmap for the application to access.
>
> I need to know what could be the best possible way of doing the same.
>
> Please share your experience in this regard .
>
> Thank you in advance
>
> ----Misbah <><
You can use the mem option to tell to the kernel that you've got less
ram you really have. However you can read Linux device drivers chapter 8
"Obtaining Large Buffers" :).
Regards,
--
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it
marco.stornelli@coritel.it
+39 06 72582838
^ permalink raw reply
* Re: how to allocate 9MB of memory in kernel ?
From: Arnd Bergmann @ 2008-07-17 7:56 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Misbah khan
In-Reply-To: <18503022.post@talk.nabble.com>
On Thursday 17 July 2008, Misbah khan wrote:
> I need to allocate 9 MB of memory in to the kernel space which i need to
> mmap for the application to access.
>
> I need to know what could be the best possible way of doing the same.
>
If you don't need the memory to be physically contiguous, you can use
vmalloc to get the memory, but then you need to use remap_vmalloc_range
for mapping the memory into a user address space.
Arnd <><
^ permalink raw reply
* Re: how to allocate 9MB of memory in kernel ?
From: Sylvain Joyeau @ 2008-07-17 8:02 UTC (permalink / raw)
To: Misbah khan; +Cc: linuxppc-embedded
In-Reply-To: <18503022.post@talk.nabble.com>
Misbah,
Please, give some more details about your application: the answer(s)
heavily depends on the kind of memory you want to allocate: contiguous
(implied in DMA purpose) or not (for process memory sharing only).
--
sj
2008/7/17 Misbah khan <misbah_khan@engineer.com>:
>
> Hi all,
>
> I need to allocate 9 MB of memory in to the kernel space which i need to
> mmap for the application to access.
>
> I need to know what could be the best possible way of doing the same.
>
> Please share your experience in this regard .
>
> Thank you in advance
>
> ----Misbah <><
> --
> View this message in context: http://www.nabble.com/how-to-allocate-9MB-o=
f-memory-in-kernel---tp18503022p18503022.html
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--=20
------------------
Sylvain JOYEAU
Freelance Engineer
Software RT-OS R&D
sylvain.joyeau@gmail.com
T=E9l: +33-(0)667 477 052
"A good idea is one side of the coin. The other side is the practical
usefulness". J. Liedke.
^ permalink raw reply
* Re: how to allocate 9MB of memory in kernel ?
From: Misbah khan @ 2008-07-17 8:19 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200807170956.52101.arnd@arndb.de>
vmalloc can only allocate 128k i guess where in i need 9MB allocated when
driver is inserted and would be released only when its removed. mapping to
user space is not a concern
--- Misbah <><
Arnd Bergmann wrote:
>
> On Thursday 17 July 2008, Misbah khan wrote:
>> I need to allocate 9 MB of memory in to the kernel space which i need to
>> mmap for the application to access.
>>
>> I need to know what could be the best possible way of doing the same.
>>
>
> If you don't need the memory to be physically contiguous, you can use
> vmalloc to get the memory, but then you need to use remap_vmalloc_range
> for mapping the memory into a user address space.
>
> Arnd <><
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/how-to-allocate-9MB-of-memory-in-kernel---tp18503022p18503765.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: how to allocate 9MB of memory in kernel ?
From: Arnd Bergmann @ 2008-07-17 8:24 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Misbah khan
In-Reply-To: <18503765.post@talk.nabble.com>
On Thursday 17 July 2008, Misbah khan wrote:
> vmalloc can only allocate 128k i guess where in i need 9MB allocated when
> driver is inserted and would be released only when its removed. mapping to
> user space is not a concern
The 128kb limitation is in kmalloc, not vmalloc. The latter is
specifically meant to have no limitations on the memory size
(other than the available resources), at the expense of having
to create a new virtual mapping.
Arnd <><
^ permalink raw reply
* Re: how to allocate 9MB of memory in kernel ?
From: Misbah khan @ 2008-07-17 8:34 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <487EFA1E.8060804@coritel.it>
>>You can use the mem option to tell to the kernel that you've got less
>>ram you really have.
I really didnt got the point you made. Can you please elaborate it for my
understanding.
>>However you can read Linux device drivers chapter 8
i dont need to allocate large memory at the boot time also vmalloc and
kmalloc i cant use as it can allocate free page up to 128kb, hence if you
could suggest me a better technique i would really appriciate .
---Misbah <><
Marco Stornelli wrote:
>
> Misbah khan ha scritto:
>> Hi all,
>>
>> I need to allocate 9 MB of memory in to the kernel space which i need to
>> mmap for the application to access.
>>
>> I need to know what could be the best possible way of doing the same.
>>
>> Please share your experience in this regard .
>>
>> Thank you in advance
>>
>> ----Misbah <><
> You can use the mem option to tell to the kernel that you've got less
> ram you really have. However you can read Linux device drivers chapter 8
> "Obtaining Large Buffers" :).
>
> Regards,
>
> --
> Marco Stornelli
> Embedded Software Engineer
> CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
> http://www.coritel.it
>
> marco.stornelli@coritel.it
> +39 06 72582838
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/how-to-allocate-9MB-of-memory-in-kernel---tp18503022p18503965.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: how to allocate 9MB of memory in kernel ?
From: Misbah khan @ 2008-07-17 8:41 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <d194b8ce0807170102x4be8b7ccx33a6a09e6129a45b@mail.gmail.com>
In have a sdram of size 9MB which i would map to kernel space (ioremap woul=
d
do that ) the whole 9 MB kernel virtual memory i need to map to the
application , the application would read when driver has complited writing
and vice versa this implimentation would be in a circular buffer type. The
size of my RAM is 128 MB=20
Sylvain Joyeau wrote:
>=20
> Misbah,
>=20
> Please, give some more details about your application: the answer(s)
> heavily depends on the kind of memory you want to allocate: contiguous
> (implied in DMA purpose) or not (for process memory sharing only).
>=20
> --
> sj
>=20
>=20
> 2008/7/17 Misbah khan <misbah_khan@engineer.com>:
>>
>> Hi all,
>>
>> I need to allocate 9 MB of memory in to the kernel space which i need to
>> mmap for the application to access.
>>
>> I need to know what could be the best possible way of doing the same.
>>
>> Please share your experience in this regard .
>>
>> Thank you in advance
>>
>> ----Misbah <><
>> --
>> View this message in context:
>> http://www.nabble.com/how-to-allocate-9MB-of-memory-in-kernel---tp185030=
22p18503022.html
>> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>=20
>=20
>=20
> --=20
> ------------------
> Sylvain JOYEAU
> Freelance Engineer
> Software RT-OS R&D
> sylvain.joyeau@gmail.com
> T=C3=A9l: +33-(0)667 477 052
> "A good idea is one side of the coin. The other side is the practical
> usefulness". J. Liedke.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20
--=20
View this message in context: http://www.nabble.com/how-to-allocate-9MB-of-=
memory-in-kernel---tp18503022p18504063.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* mpc5200b PSC interrupt load on high baud rates
From: Oliver Rutsch @ 2008-07-17 9:02 UTC (permalink / raw)
To: Linuxppc-dev
Hi,
We're using the latest 2.4.25-Kernel from DENX on a custom mpc5200b board.
We have a RS485 device which sends continuously its data at a rate of
1.25 MBit/s. The problem here is that it takes nearly 90% of system time
just to read these data. I had a look into the driver
(arch/ppc/5xxx_io/psc.c) and the problem seems to be the RxRDY interrupt
of the PSCs. This interrupt is inserted every time when there's any data
in the FIFO. I found out, that most of the time the isr is reading only
1 or 2 bytes out of the FIFO, so the system is very busy to serve
thousands of interrupts.
Then I set the FFULL flag as the interrupt source in the mr1 register of
the PSC. I set an rx alarm level of 112 bytes (means that an interrupt
will be generated when FIFO>=400 bytes!) and rx granularity of 7.
With this the system load drops down under 1 percent!
But this approach has one big drawback: There will be no interrupt if I
receive less than 400 bytes. So this is not usable for "normal" SIO
operation.
Although not tested it looks like the same problem is in the driver for
the 2.6.25-Kernel (correct me when I'm wrong here).
So I have two ideas for better performance of this driver:
1. The interrupt will be generated by the FFULL flag. An endless kernel
timer will have every jiffy a look at the PSC FIFO status and pull out
any data if necessary. A look on the PSC FIFO status is a very short
operation so this timer shouldn't affect the system performance too
much. But maybe this adds some more latency when receiving only a few bytes.
2. The interrupt will be generated by the RxRDY flag. The isr only
starts reading if there are more than 400 bytes into the FIFO. But it
will start a kernel timer in order to pull out data less than 400 bytes.
Some pseudo code will look like this:
psc_isr()
{
if (FIFO>400)
read_fifo_data()
else
{
if (timer_not_already_started)
start_psc_timer()
}
[...]
}
psc_timer()
{
if (FIFO>0)
read_fifo_data()
}
So, any suggestions are welcome, what do you think?
Bye,
--
Dipl. Ing. Oliver Rutsch
EMail: orutsch@sympatec.com · Tel.:+49 5323 717514
Sympatec GmbH · Am Pulverhaus 1 · D-38678 Clausthal-Zellerfeld · Germany
Geschaeftsfuehrer: Dr.-Ing. E.h. Stephan Roethele · Handelsregister:
Amtsgericht Braunschweig, HRB 110809
^ permalink raw reply
* Re: how to allocate 9MB of memory in kernel ?
From: Marco Stornelli @ 2008-07-17 9:04 UTC (permalink / raw)
To: Misbah khan; +Cc: linuxppc-embedded
In-Reply-To: <18503965.post@talk.nabble.com>
Misbah khan ha scritto:
>>> You can use the mem option to tell to the kernel that you've got less
>>> ram you really have.
> I really didnt got the point you made. Can you please elaborate it for my
> understanding.
If you've got 128MB of ram you can use the mem option to tell to the
kernel the it can use only (128 - 9) MB of ram, after that you can use
that chunk of ram, however I think it's not the case if your goal is to
use a sdram as you said in the previous message.
>>> However you can read Linux device drivers chapter 8
> i dont need to allocate large memory at the boot time also vmalloc and
> kmalloc i cant use as it can allocate free page up to 128kb, hence if you
> could suggest me a better technique i would really appriciate .
>
The problem about 128KB is only for kmalloc. If I understood correctly
you need only to remap the 9MB of your sdram.
> ---Misbah <><
>
>
> Marco Stornelli wrote:
>> Misbah khan ha scritto:
>>> Hi all,
>>>
>>> I need to allocate 9 MB of memory in to the kernel space which i need to
>>> mmap for the application to access.
>>>
>>> I need to know what could be the best possible way of doing the same.
>>>
>>> Please share your experience in this regard .
>>>
>>> Thank you in advance
>>>
>>> ----Misbah <><
>> You can use the mem option to tell to the kernel that you've got less
>> ram you really have. However you can read Linux device drivers chapter 8
>> "Obtaining Large Buffers" :).
>>
>> Regards,
>>
>> --
>> Marco Stornelli
>> Embedded Software Engineer
>> CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
>> http://www.coritel.it
>>
>> marco.stornelli@coritel.it
>> +39 06 72582838
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>>
>
--
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it
marco.stornelli@coritel.it
+39 06 72582838
^ permalink raw reply
* [bugme-daemon@bugzilla.kernel.org: [Bug 7306] Yenta-socket causes oops on insertion of any PCMCIA card]
From: Dominik Brodowski @ 2008-07-17 9:14 UTC (permalink / raw)
To: linuxppc-dev
Hi,
on an Apple Powerbook G3 (Lombard) with a PPC 740 running at 333 MHz, the
PCI host bridge is condigured to allow "downstream" devices to use iomem
0xfd000000 - 0xfdffffff
However, when using it for PCMCIA purposes, there's a machine check. Any
ideas on why this PCI host bridge is mis-configured, and how to resolve this
issue (besides adding reserved=0xfd000000,0xffffff as kernel boot option)?
Best,
Dominik
----- Forwarded message from bugme-daemon@bugzilla.kernel.org -----
Subject: [Bug 7306] Yenta-socket causes oops on insertion of any PCMCIA card
To: linux-pcmcia@lists.infradead.org
From: bugme-daemon@bugzilla.kernel.org
Date: Thu, 17 Jul 2008 01:45:44 -0700 (PDT)
http://bugzilla.kernel.org/show_bug.cgi?id=7306
------- Comment #17 from linux@brodo.de 2008-07-17 01:45 -------
Now this contains interesting information:
pcmcia: parent PCI bridge Memory window:
means the PCI host bridge is configured to allow "downstream" devices to use
this memory area. However, when the PCMCIA socket tries to do so, you get the
machine check. So my question would be to the powerpc folks: why is the PCI
host bridge configured this way, even if this memory area is not usable?
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
_______________________________________________
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia
----- End forwarded message -----
^ permalink raw reply
* Is there relationship between address translation enabled and PLB timeout error?
From: Evangelion @ 2008-07-17 10:20 UTC (permalink / raw)
To: Linuxppc-dev
In-Reply-To: <487E57F6.7020602@grandegger.com>
Hello, all:
I am building a Linux kernel module for PPC405EP. My developing
board is PPChameleonEVB. I am debugging with BDI2000 and GDB, and my
problem is:
In GDB, a section of the codes is disassembled to:
mfmsr r0
ori r0,r0,32768
mtmsr r0
blr
From BDI2000, I have checked that after "ori", GPR0 contains
"0x00029030". This value should be written into MSR by "mtmsr" to set EE
bit of MSR as 1, but after single step in BDI, "mtmsr" does not work as
hoped. MSR becomes "0x00000030", GPR0 becomes some weird number, and
there is "Step timeout detected". Meanwhile, the board traps into "Data
machine check in kernel mode". I also have tried "wrteei 1" instead of
the codes above, but failed again. However, those codes works well in
PPC440EP Yosemite board.
I have compared PPChameleonEVB and Yosemite. It seems the most
significant difference is for PPChameleonEVB, address translation is
enabled by default (MSR[IR, DR] = 1), while for Yosemite, it is disabled
(MSR[IR, DR] = 0). And from the error message, I think there is a
problem with PLB because PLB0_BESR becomes 0x00c00000 from 0x00000000
and PLB0_BEAR becomes 0x03066004 when machine check happens. Based on
the processor manual, the PLB0_BESR shows the PLB Timeout Error Status
and the value means the error operation is reading the processor core
DCU. The PLB0_BEAR shows the address of the access on which a bus
timeout error occurred. So I have the following questions for this
moment:
1. Is it possible or not that address translation leads to the PLB
timeout error? If that is the cause, how to fix the problem?
2. Is the address in PLB0_BEAR a memory address (real address or
effective address) or a bus address (not an address in any kind of
memory)?
3. Are there other reasons for the machine check in this situation?
4. Is it an unrecoverable hardware problem (bug) or not?
Here is the debugging log:
405EP>ti
Core number : 0
Core state : debug mode
Debug entry cause : single step
Current PC : 0xc32b1008
Current CR : 0x84000084
Current MSR : 0x00021030
Current LR : 0xc32b46c4
405EP>rd
GPR00: 00029030 c1dd9d60 c1fe7bf0 00000000
GPR04: 00000001 00000000 c32b2c8c 00000000
GPR08: c3068000 c3068000 00000001 c3062000
GPR12: 00000000 10019dd8 c32c0000 c32b0000
GPR16: 00000001 c32b0000 00000002 7ff4f670
GPR20: 00000028 c32b0000 c32b0000 10011000
GPR24: c306a000 00000000 00000000 10012c6c
GPR28: c18e4000 c32c0000 00000000 00000000
CR : 84000084 MSR: 00021030
405EP>ti
Core number : 0
Core state : debug mode
Debug entry cause : JTAG stop request
Current PC : 0xc000490c
Current CR : 0x42000082
Current MSR : 0x00000030
Current LR : 0xc001f1b8
# Step timeout detected
405EP>rd
GPR00: 03929800 c02f3e60 c3066000 000102f1
GPR04: 00005424 00000007 c0146f3c c0260000
GPR08: 00000000 c02d0000 c3062000 00000000
GPR12: 00000000 10019dd8 c32c0000 c32b0000
GPR16: 00000001 c32b0000 00000002 7ff4f670
GPR20: 00000028 c32b0000 c32b0000 10011000
GPR24: c306a000 00000000 00000000 10012c6c
GPR28: c02f0000 00000152 c3066000 c02f0000
CR : 42000082 MSR: 00000030
==========================================
Here is the error message:
Data machine check in kernel mode.
PLB0: BEAR= 0x03066004 ACR= 0x00000000 BESR= 0x00c00000
PLB0 to OPB: BEAR= 0x04000000 BESR0= 0x00000000 BESR1= 0x00000000
Oops: machine check, sig: 7 [#1]
NIP: 00002AD0 LR: 000005A0 CTR: C000CC58
REGS: c02f3f50 TRAP: 0202 Not tainted (2.6.19.2-eldk)
MSR: 00021000 <ME> CR: 24000084 XER: 20000000
TASK = c3066000[0] '' THREAD: c02d2000
GPR00: 00029030 C1DD9CA0 C3066000 C1DD9CB0 00000001 00000000 C32B2C8C
00000000
GPR08: C3068000 00000000 00021032 01DD9CA0 030661B0 10019DD8 C32C0000
C32B0000
GPR16: 00000001 C32B0000 00000002 7FF4F670 00000028 C32B0000 C32B0000
10011000
GPR24: C306A000 00000000 00000000 10012C6C C18E4000 C32C0000 00000000
00000000
NIP [00002AD0] 0x2ad0
LR [000005A0] 0x5a0
Call Trace:
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
Kernel panic - not syncing: Attempted to kill the idle task!
<0>Rebooting in 180 seconds..
Thanks a lot for advice!
Best Regards
Evangelion
July 17th, 2008
__________________________________________________
¸Ï¿ì×¢²áÑÅ»¢³¬´óÈÝÁ¿Ãâ·ÑÓÊÏä?
http://cn.mail.yahoo.com
^ permalink raw reply
* increase lowmem value for ppc
From: Ruksen INANIR @ 2008-07-17 10:32 UTC (permalink / raw)
To: linuxppc-embedded
Is there a way to increase the lowmem value for ppc. The MAX_LOW_MEM is
defined as max 768 MB. But a value around 1.5 G works with no problem.
But when i try to increase this value to 1520 or more, kernel complaints
about no space for memory allocation when loading kernel modules.
I do not want to use HIGHMEM config. What is the max lowmem value for a
ppc system? What other setting are needed to use 1520 MB (or more) as
lowmem .
The ppc card has 2G on board memory. 2.4.22 kernel is used.
Thanks
^ permalink raw reply
* [PATCH] i2c-mpc: suppress I2C device probing
From: Wolfgang Grandegger @ 2008-07-17 10:37 UTC (permalink / raw)
To: Linuxppc-dev; +Cc: Jean Delvare
This patch suppresses I2C device probing by clearing the class field
of the "struct i2c_adapter" for the MPC I2C bus adapters. Some board
configurations which rely on probing must be fixed up by adding a
proper I2C device node to the DTS file, like the TQM85xx modules.
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
---
drivers/i2c/busses/i2c-mpc.c | 1 -
1 file changed, 1 deletion(-)
Index: powerpc/drivers/i2c/busses/i2c-mpc.c
===================================================================
--- powerpc.orig/drivers/i2c/busses/i2c-mpc.c
+++ powerpc/drivers/i2c/busses/i2c-mpc.c
@@ -312,7 +312,6 @@ static struct i2c_adapter mpc_ops = {
.name = "MPC adapter",
.id = I2C_HW_MPC107,
.algo = &mpc_algo,
- .class = I2C_CLASS_HWMON | I2C_CLASS_SPD,
.timeout = 1,
};
^ permalink raw reply
* Re: [PATCH] Support for DS75 thermal sensor
From: Wolfgang Grandegger @ 2008-07-17 10:39 UTC (permalink / raw)
To: Grant Likely
Cc: Jean Delvare, Linuxppc-dev, Alan Clucas, Detlev Zundel,
lm-sensors
In-Reply-To: <20080717073312.GB30474@secretlab.ca>
Grant Likely wrote:
> On Thu, Jul 17, 2008 at 09:31:24AM +0200, Wolfgang Grandegger wrote:
>> Jean Delvare wrote:
>>> On Wed, 16 Jul 2008 10:18:26 -0400, Jon Smirl wrote:
>>>> I've found this thread now. Why can't we totally remove probing from
>>>> i2c-mpc? These are embedded systems, not open boxes like a PC. If a
>>>> i2c client hasn't been converted to the new model yet, convert it
>>>> before deploying with the new i2c-mpc driver. It's not very hard to
>>>> convert the client drivers.
>>> I tend to agree. And the number of unconverted drivers is getting very
>>> low these days. Only 2 RTC drivers are left, and by the end of the day,
>>> almost all hwmon drivers will be converted as well.
>> Thinking more about it I also prefer removing the I2C_CLASS_HWMON flag
>> completely. It just affects HWMON devices anyhow and if there is still
>> an old style driver around, it should be converted.
>
> I'm cool with that.
Good, just sent a new patch.
Wolfgang.
^ permalink raw reply
* [patch] powerpc: implement pte_special for 64K pages
From: Nick Piggin @ 2008-07-17 10:44 UTC (permalink / raw)
To: Andrew Morton, Dave Kleikamp, Benjamin Herrenschmidt,
linuxppc-dev
This can be folded into powerpc-implement-pte_special.patch
--
Ben has now freed up a pte bit on 64k pages. Use it for special pte bit.
Signed-off-by: Nick Piggin <npiggin@suse.de>
---
Index: linux-2.6/include/asm-powerpc/pgtable-64k.h
===================================================================
--- linux-2.6.orig/include/asm-powerpc/pgtable-64k.h 2008-07-17 18:53:03.000000000 +1000
+++ linux-2.6/include/asm-powerpc/pgtable-64k.h 2008-07-17 20:30:06.000000000 +1000
@@ -70,11 +70,12 @@
#define PGDIR_MASK (~(PGDIR_SIZE-1))
/* Additional PTE bits (don't change without checking asm in hash_low.S) */
+#define __HAVE_ARCH_PTE_SPECIAL
+#define _PAGE_SPECIAL 0x00000400 /* software: special page */
#define _PAGE_HPTE_SUB 0x0ffff000 /* combo only: sub pages HPTE bits */
#define _PAGE_HPTE_SUB0 0x08000000 /* combo only: first sub page */
#define _PAGE_COMBO 0x10000000 /* this is a combo 4k page */
#define _PAGE_4K_PFN 0x20000000 /* PFN is for a single 4k page */
-#define _PAGE_SPECIAL 0x0 /* don't have enough room for this yet */
/* For 64K page, we don't have a separate _PAGE_HASHPTE bit. Instead,
* we set that to be the whole sub-bits mask. The C code will only
^ 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