* Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Li Yang @ 2011-12-15 4:59 UTC (permalink / raw)
To: Scott Wood
Cc: Artem.Bityutskiy, dedekind1, linuxppc-dev, LiuShuo, linux-kernel,
shuo.liu, linux-mtd, akpm, dwmw2
In-Reply-To: <4EE903CE.1010903@freescale.com>
On Thu, Dec 15, 2011 at 4:15 AM, Scott Wood <scottwood@freescale.com> wrote=
:
> On 12/14/2011 02:41 AM, LiuShuo wrote:
>> =E4=BA=8E 2011=E5=B9=B412=E6=9C=8813=E6=97=A5 10:46, LiuShuo =E5=86=99=
=E9=81=93:
>>> =E4=BA=8E 2011=E5=B9=B412=E6=9C=8813=E6=97=A5 05:30, Scott Wood =E5=86=
=99=E9=81=93:
>>>> On 12/12/2011 03:19 PM, Artem Bityutskiy wrote:
>>>>> On Mon, 2011-12-12 at 15:15 -0600, Scott Wood wrote:
>>>>>> NAND chips come from the factory with bad blocks marked at a certain
>>>>>> offset into each page. =C2=A0This offset is normally in the OOB area=
, but
>>>>>> since we change the layout from "4k data, 128 byte oob" to "2k
>>>>>> data, 64
>>>>>> byte oob, 2k data, 64 byte oob" the marker is no longer in the
>>>>>> oob. =C2=A0On
>>>>>> first use we need to migrate the markers so that they are still in
>>>>>> the oob.
>>>>> Ah, I see, thanks. Are you planning to implement in-kernel migration =
or
>>>>> use a user-space tool?
>>>> That's the kind of answer I was hoping to get from Shuo. :-)
>>> OK, I try to do this. Wait for a couple of days.
>>>
>>> -LiuShuo
>> I found it's too complex to do the migration in Linux driver.
>>
>> Maybe we can add a uboot command (e.g. nand bbmigrate) to do it, once is
>> enough.
>
> Any reason not to do it automatically on the first U-Boot bad block
> scan, if the flash isn't marked as already migrated?
>
> Further discussion on the details of how to do it in U-Boot should move
> to the U-Boot list.
The limitation of the proposed bad block marker migration is that you
need to make sure the migration is done and only done once. If it is
done more than once, the factory bad block marker is totally messed
up. It requires a complex mechanism to automatically guarantee the
migration is only done once, and it still won't be 100% safe.
I would suggest we use a much easier compromise that we form the BBT
base on the factory bad block marker on first use of the flash, and
after that the factory bad block marker is dropped. We just relies on
the BBT for information about bad blocks. Although by doing so we
can't regenerate the BBT again, as there is mirror for the BBT I
don't think we have too much risk.
- Leo
^ permalink raw reply
* Re: [PATCH 1/1] ppc64: fix missing to check all bits of _TIF_USER_WORK_MASK in preempt
From: Benjamin Herrenschmidt @ 2011-12-15 1:04 UTC (permalink / raw)
To: Tiejun Chen; +Cc: linuxppc-dev
In-Reply-To: <1323681035-19350-1-git-send-email-tiejun.chen@windriver.com>
On Mon, 2011-12-12 at 17:10 +0800, Tiejun Chen wrote:
> -#else /* !CONFIG_PREEMPT */
> ld r3,_MSR(r1) /* Returning to user mode? */
> andi. r3,r3,MSR_PR
> - beq restore /* if not, just restore regs and return */
> + bne test_work_user
>
> + clrrdi r9,r1,THREAD_SHIFT /* current_thread_info() */
> + li r0,_TIF_USER_WORK_MASK
You meant _TIF_KERNEL_WORK_MASK ?
> +#ifdef CONFIG_PREEMPT
> + ori r0,r0,_TIF_NEED_RESCHED
> +#endif
No, include that in _TIF_KERNEL_WORK_MASK when CONFIG_PREEMPT, ie,
modify the definition of _TIF_KERNEL_WORK_MASK to include it
> + ld r4,TI_FLAGS(r9)
> + and. r0,r4,r0 /* check NEED_RESCHED and maybe _TIF_USER_WORK_MASK */
Comment is wrong after the above
> + bne do_kernel_work
> + b restore /* if so, just restore regs and return */
> +
> +test_work_user:
> /* Check current_thread_info()->flags */
> clrrdi r9,r1,THREAD_SHIFT
> ld r4,TI_FLAGS(r9)
For better scheduling, couldn't you have preloaded the TIF flags, then
checked for PR ?
Looks like this (also replaces do_work)
IE. ld r3,_MSR(r1)
clrrdi r9,r1,THREAD_SHIFT
ld r4,TI_FLAGS(r9)
andi. r3,r3,MSR_PR
bne test_work_user
test_work_kernel:
andi. r0,r4,_TIF_KERNEL_WORK_MASK
beq+ restore
#ifdef CONFIG_PREEMPT
/* Check if we need to preempt */
andi. r0,r4,_TIF_NEED_RESCHED
beq+ 2f
lwz r8,TI_PREEMPT(r9)
cmpwi cr1,r8,0
ld r0,SOFTE(r1)
cmpdi r0,0
crandc eq,cr1*4+eq,eq
bne 1f
/* ... copy comment about preempt here ... */
li r0,0
stb r0,PACASOFTIRQEN(r13)
stb r0,PACAHARDIRQEN(r13)
TRACE_DISABLE_INTS
1: bl .preempt_schedule_irq
/* preempt may have re-enabled and then disabled interrupts,
* so we may come here as soft-disabled & hard-enabled, but
* we really want hard disabled.
*/
#ifdef CONFIG_PPC_BOOK3E
wrteei 0
#else
mfmsr r10
rldicl r10,r10,48,1
rotldi r10,r10,16
mtmsrd r10,1
#endif
li r0,0
stb r0,PACAHARDIRQEN(r13)
/* Re-check if we need to preempt again */
clrrdi r9,r1,THREAD_SHIFT
ld r4,TI_FLAGS(r9)
andi. r0,r4,_TIF_NEED_RESCHED
bne 1b
2:
#endif /* CONFIG_PREEMPT */
andi. r0,r4,_TIF_OUR_NEW_FLAG
beq+ restore
... handle our new flag here
b restore
test_work_user:
andi. r0,r4,_TIF_USER_WORK_MASK
beq+ restore
/* ... move user_work here ... */
> andi. r0,r4,_TIF_USER_WORK_MASK
> - bne do_work
> -#endif
> + bne do_user_work
>
> restore:
> BEGIN_FW_FTR_SECTION
> @@ -693,10 +692,8 @@ ALT_FTR_SECTION_END_IFCLR(CPU_FTR_STCX_CHECKS_ADDRESS)
> b .ret_from_except_lite /* loop back and handle more */
> #endif
>
> -do_work:
> +do_kernel_work:
> #ifdef CONFIG_PREEMPT
> - andi. r0,r3,MSR_PR /* Returning to user mode? */
> - bne user_work
> /* Check that preempt_count() == 0 and interrupts are enabled */
> lwz r8,TI_PREEMPT(r9)
> cmpwi cr1,r8,0
> @@ -738,9 +735,9 @@ do_work:
> bne 1b
> b restore
>
> -user_work:
> #endif /* CONFIG_PREEMPT */
>
> +do_user_work:
> /* Enable interrupts */
> #ifdef CONFIG_PPC_BOOK3E
> wrteei 1
^ permalink raw reply
* Re: [PATCH 3/4] ppc32/kprobe: complete kprobe and migrate exception frame
From: Benjamin Herrenschmidt @ 2011-12-15 0:37 UTC (permalink / raw)
To: tiejun.chen; +Cc: linuxppc-dev
In-Reply-To: <4EE72AB8.4090502@windriver.com>
On Tue, 2011-12-13 at 18:36 +0800, tiejun.chen wrote:
> >> You need to hook into "resume_kernel" instead.
> >
>
> I regenerate this with hooking into resume_kernel in below.
.../...
> I assume it may not necessary to reorganize ret_from_except for *ppc32* .
It might be cleaner but I can do that myself later.
> >>> do_user_signal: /* r10 contains MSR_KERNEL here */
> >>> ori r10,r10,MSR_EE
> >>> SYNC
> >>> @@ -1202,6 +1204,30 @@ do_user_signal: /* r10 contains MSR_KERNEL here */
> >>> REST_NVGPRS(r1)
> >>> b recheck
> >>>
> >>> +restore_kprobe:
> >>> + lwz r3,GPR1(r1)
> >>> + subi r3,r3,INT_FRAME_SIZE; /* Allocate a trampoline exception frame */
> >>> + mr r4,r1
> >>> + bl copy_exc_stack /* Copy from the original to the trampoline */
> >>> +
> >>> + /* Do real stw operation to complete stwu */
> >>> + mr r4,r1
> >>> + addi r4,r4,INT_FRAME_SIZE /* Get kprobed entry */
> >>> + lwz r5,GPR1(r1) /* Backup r1 */
> >>> + stw r4,GPR1(r1) /* Now store that safely */
> >> The above confuses me. Shouldn't you do instead something like
> >>
> >> lwz r4,GPR1(r1)
>
> Now GPR1(r1) is already pointed with new r1 in emulate_step().
Right
> >> subi r3,r4,INT_FRAME_SIZE
>
> Here we need this, 'mr r4,r1', since r1 holds current exception stack.
Right.
> >> li r5,INT_FRAME_SIZE
> >> bl memcpy
>
> Then the current exception stack is migrated below the kprobed function stack.
>
> stack flow:
>
> -------------------------- -> old r1 when hit 'stwu r1, -AA(r1)' in our
> ^ ^ kprobed function entry.
> | |
> | |------------> AA allocated for the kprobed function
> | |
> | v
> --------|----------------- -> new r1, also GPR1(r1). It holds the kprobed
> ^ | function stack , -AA(r1).
> | |
> | |--------------------> INT_FRAME_SIZE for program exception
> | |
> | v
> ---|--------------------- -> r1 is updated to hold program exception stack.
> |
> |
> |------------------------> migrate the exception stack (r1) below the
> | kprobed after memcpy with INT_FRAME_SIZE.
> v
> ------------------------- -> reroute this as r1 for program exception stack.
I see so you simply assume that the old r1 value is the current r1 +
INT_FRAME_SIZE, which is probably fair enough.
BTW. we should probably WARN_ON if emulate_step tries to set the new TIF
flag and sees it already set since that means we'll lose the previous
value.
> >>
> >
> > Anyway I'll try this if you think memcpy is fine/safe in exception return codes.
> >
> >> To start with, then you need to know the "old" r1 value which may or may
> >> not be related to your current r1. The emulation code should stash it
> >
> > If the old r1 is not related to our current r1, it shouldn't be possible to go
> > restore_kprob since we set that new flag only for the current.
> >
> > If I'm wrong please correct me :)
>
> If you agree what I say above, and its also avoid any issue introduced with
> orig_gpr3, please check the follow:
> =========
> diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
> index 56212bc..277029d 100644
> --- a/arch/powerpc/kernel/entry_32.S
> +++ b/arch/powerpc/kernel/entry_32.S
> @@ -813,9 +813,40 @@ restore_user:
>
> #ifdef CONFIG_PREEMPT
> b restore
> +#endif
The above means that if !PREEMPT, a userspace return -will- fo into
your new code, while with PREEMPT it won't. This is inconsistent. Now
we should never need that for userspace returns (and indeed you should
double check in emulate step that you are only applying this when
regs->msr & MSR_PR is 0). The above branch should basically become
unconditional.
> -/* N.B. the only way to get here is from the beq following ret_from_except. */
> resume_kernel:
> +#ifdef CONFIG_KPROBES
Don't make this KPROBES specific. Anything using emulate_step (such as
xmon) might need that too.
> + /* check current_thread_info, _TIF_EMULATE_STACK_STORE */
> + rlwinm r9,r1,0,0,(31-THREAD_SHIFT)
> + lwz r0,TI_FLAGS(r9)
> + andis. r0,r0,_TIF_EMULATE_STACK_STORE@h
> + beq+ restore_kernel
So you are introducing a new symbol restore_kernel, you could just
branch to "restore". However, that would mean putting the preempt
case before the kprobe case. But don't we want to do that anyway ?
I don't like keeping that "offsetted" return stack accross a preempt.
> + addi r9,r1,INT_FRAME_SIZE /* Get the kprobed function entry */
> +
> + lwz r3,GPR1(r1)
> + subi r3,r3,INT_FRAME_SIZE /* dst: Allocate a trampoline exception
> frame */
> + mr r4,r1 /* src: current exception frame */
> + li r5,INT_FRAME_SIZE /* size: INT_FRAME_SIZE */
> + mr r1,r3 /* Reroute the trampoline frame to r1 */
> + bl memcpy /* Copy from the original to the
> trampoline */
> +
> + /* Do real store operation to complete stwu */
> + lwz r5,GPR1(r1)
> + stw r9,0(r5)
>
> + /* Clear _TIF_EMULATE_STACK_STORE flag */
> + rlwinm r9,r1,0,0,(31-THREAD_SHIFT)
> + lwz r0,TI_FLAGS(r9)
> + rlwinm r0,r0,0,_TIF_EMULATE_STACK_STORE
> + stw r0,TI_FLAGS(r9)
I think this needs to be an atomic operation, another CPU can be trying
to set _NEED_RESCHED at the same time.
> +restore_kernel:
> +#endif
> +
> +#ifdef CONFIG_PREEMPT
> +/* N.B. the only way to get here is from the beq following ret_from_except. */
> /* check current_thread_info->preempt_count */
> rlwinm r9,r1,0,0,(31-THREAD_SHIFT)
> lwz r0,TI_PREEMPT(r9)
> @@ -844,8 +875,6 @@ resume_kernel:
> */
> bl trace_hardirqs_on
> #endif
> -#else
> -resume_kernel:
> #endif /* CONFIG_PREEMPT */
>
> /* interrupts are hard-disabled at this point */
>
> Tiejun
Cheers,
Ben.
^ permalink raw reply
* [PATCH 2/2] offb: Add palette hack for qemu "standard vga" framebuffer
From: Benjamin Herrenschmidt @ 2011-12-14 23:58 UTC (permalink / raw)
To: linux-fbdev; +Cc: linuxppc-dev, kvm-ppc
We rename the mach64 hack to "simple" since that's also applicable
to anything using VGA-style DAC IO ports (set to 8-bit DAC) and we
use it for qemu vga.
Note that this is keyed on a device-tree "compatible" property that
is currently only set by an upcoming version of SLOF when using the
qemu "pseries" platform. This is on purpose as other qemu ppc platforms
using OpenBIOS aren't properly setting the DAC to 8-bit at the time of
the writing of this patch.
We can fix OpenBIOS later to do that and add the required property, in
which case it will be matched by this change.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
drivers/video/offb.c | 19 +++++++++++++++----
1 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/video/offb.c b/drivers/video/offb.c
index 915acae..da7cf79 100644
--- a/drivers/video/offb.c
+++ b/drivers/video/offb.c
@@ -41,13 +41,14 @@
/* Supported palette hacks */
enum {
cmap_unknown,
- cmap_m64, /* ATI Mach64 */
+ cmap_simple, /* ATI Mach64 */
cmap_r128, /* ATI Rage128 */
cmap_M3A, /* ATI Rage Mobility M3 Head A */
cmap_M3B, /* ATI Rage Mobility M3 Head B */
cmap_radeon, /* ATI Radeon */
cmap_gxt2000, /* IBM GXT2000 */
cmap_avivo, /* ATI R5xx */
+ cmap_qemu, /* qemu vga */
};
struct offb_par {
@@ -138,7 +139,7 @@ static int offb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
return 0;
switch (par->cmap_type) {
- case cmap_m64:
+ case cmap_simple:
writeb(regno, par->cmap_adr);
writeb(red, par->cmap_data);
writeb(green, par->cmap_data);
@@ -208,7 +209,7 @@ static int offb_blank(int blank, struct fb_info *info)
if (blank)
for (i = 0; i < 256; i++) {
switch (par->cmap_type) {
- case cmap_m64:
+ case cmap_simple:
writeb(i, par->cmap_adr);
for (j = 0; j < 3; j++)
writeb(0, par->cmap_data);
@@ -350,7 +351,7 @@ static void offb_init_palette_hacks(struct fb_info *info, struct device_node *dp
par->cmap_adr =
ioremap(base + 0x7ff000, 0x1000) + 0xcc0;
par->cmap_data = par->cmap_adr + 1;
- par->cmap_type = cmap_m64;
+ par->cmap_type = cmap_simple;
} else if (dp && (of_device_is_compatible(dp, "pci1014,b7") ||
of_device_is_compatible(dp, "pci1014,21c"))) {
par->cmap_adr = offb_map_reg(dp, 0, 0x6000, 0x1000);
@@ -371,6 +372,16 @@ static void offb_init_palette_hacks(struct fb_info *info, struct device_node *dp
par->cmap_type = cmap_avivo;
}
of_node_put(pciparent);
+ } else if (dp && of_device_is_compatible(dp, "qemu,std-vga")) {
+ const u32 io_of_addr[3] = { 0x01000000, 0x0, 0x0 };
+ u64 io_addr = of_translate_address(dp, io_of_addr);
+ if (io_addr != OF_BAD_ADDR) {
+ par->cmap_adr = ioremap(io_addr + 0x3c8, 2);
+ if (par->cmap_adr) {
+ par->cmap_type = cmap_simple;
+ par->cmap_data = par->cmap_adr + 1;
+ }
+ }
}
info->fix.visual = (par->cmap_type != cmap_unknown) ?
FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_STATIC_PSEUDOCOLOR;
^ permalink raw reply related
* [PATCH 1/2] offb: Fix bug in calculating requested vram size
From: Benjamin Herrenschmidt @ 2011-12-14 23:58 UTC (permalink / raw)
To: linux-fbdev; +Cc: linuxppc-dev, kvm-ppc
>From 448820776363da565f221c020f4ccb3c610faec3 Mon Sep 17 00:00:00 2001
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Wed, 14 Dec 2011 16:52:02 +1100
Subject:
We used to try to request 8 times more vram than needed, which would
fail if the card has a too small BAR (observed with qemu).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
drivers/video/offb.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
(I'm happy to carry that in the powerpc tree)
diff --git a/drivers/video/offb.c b/drivers/video/offb.c
index cb163a5..915acae 100644
--- a/drivers/video/offb.c
+++ b/drivers/video/offb.c
@@ -381,7 +381,7 @@ static void __init offb_init_fb(const char *name, const char *full_name,
int pitch, unsigned long address,
int foreign_endian, struct device_node *dp)
{
- unsigned long res_size = pitch * height * (depth + 7) / 8;
+ unsigned long res_size = pitch * height;
struct offb_par *par = &default_par;
unsigned long res_start = address;
struct fb_fix_screeninfo *fix;
^ permalink raw reply related
* [PATCH] powerpc: Fix old bug in prom_init setting of the color
From: Benjamin Herrenschmidt @ 2011-12-14 23:55 UTC (permalink / raw)
To: linuxppc-dev
We have an array of 16 entries and a loop of 32 iterations... oops.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/kernel/prom_init.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index cc58486..e3d0ecd 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -2079,7 +2079,7 @@ static void __init prom_check_displays(void)
/* Setup a usable color table when the appropriate
* method is available. Should update this to set-colors */
clut = RELOC(default_colors);
- for (i = 0; i < 32; i++, clut += 3)
+ for (i = 0; i < 16; i++, clut += 3)
if (prom_set_color(ih, i, clut[0], clut[1],
clut[2]) != 0)
break;
^ permalink raw reply related
* Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Scott Wood @ 2011-12-14 20:53 UTC (permalink / raw)
To: LiuShuo
Cc: Artem.Bityutskiy, dedekind1, linuxppc-dev, linux-kernel, shuo.liu,
linux-mtd, akpm, dwmw2
In-Reply-To: <4EE81ADD.6090104@freescale.com>
On 12/13/2011 09:41 PM, LiuShuo wrote:
> =E4=BA=8E 2011=E5=B9=B412=E6=9C=8813=E6=97=A5 05:09, Artem Bityutskiy =E5=
=86=99=E9=81=93:
>> On Tue, 2011-12-06 at 18:09 -0600, Scott Wood wrote:
>>> On 12/03/2011 10:31 PM, shuo.liu@freescale.com wrote:
>>>> From: Liu Shuo<shuo.liu@freescale.com>
>>>>
>>>> Freescale FCM controller has a 2K size limitation of buffer RAM. In
>>>> order
>>>> to support the Nand flash chip whose page size is larger than 2K byt=
es,
>>>> we read/write 2k data repeatedly by issuing FIR_OP_RB/FIR_OP_WB and
>>>> save
>>>> them to a large buffer.
>>>>
>>>> Signed-off-by: Liu Shuo<shuo.liu@freescale.com>
>>>> ---
>>>> v3:
>>>> -remove page_size of struct fsl_elbc_mtd.
>>>> -do a oob write by NAND_CMD_RNDIN.
>>>>
>>>> drivers/mtd/nand/fsl_elbc_nand.c | 243
>>>> ++++++++++++++++++++++++++++++++++----
>>>> 1 files changed, 218 insertions(+), 25 deletions(-)
>>> What is the plan for bad block marker migration.
> I think we can use a special bbt pattern to indicate whether migration
> has been done.
> (we needn't to define another marker)
>=20
> Do the migration our chip->scan_bbt as follow :
>=20
> /*
> * this pattern indicate that the bad block information has been migrat=
ed,
> * if this isn't found, we do the migration.
> */
> static u8 migrated_bbt_pattern[] =3D {'M', 'b', 'b', 't', '0' };
>=20
> static int fsl_elbc_bbt(struct mtd_info *mtd)
> {
> if (!check_migrated_bbt_pattern())
> bad_block_info_migtrate();
>=20
> nand_default_bbt(mtd); /* default function in nand_bbt.c */
> }
Hmm. This is OK as long as the bad block table never gets erased (which
could happen if a user wants it reconstructed, such as if buggy software
makes a mess of it on a developer's board). If it gets erased, we'll
end up migrating again -- and the place that factory bad block markers
would have been in is now data, so all blocks that have been written to
will show up as bad unless they happen to have 0xff at the right place.
How about a marker that is compatible with the bbt, so the same block
can be used in production (where scrubbing the bbt should never happen),
but that does not have to imply that the block is a bbt (so a developer
that might want to erase the bbt can set the mark elsewhere, preferably
just before the bbt)?
Or have two versions of the marker, one that is also a bbt marker and
one that is not.
When scanning the bbt, the driver would look for one of these markers
from the end of the chip backward. If not found, it concludes the chip
is unmigrated. In U-Boot, this would trigger a migration (or a message
to run a migration command). In Linux (and U-Boot if migration is a
separate command that has not been run) an unmigrated flash could be
read-only, with the possible exception of raw accesses if needed to
support an external migration tool.
-Scott
^ permalink raw reply
* Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Scott Wood @ 2011-12-14 20:15 UTC (permalink / raw)
To: LiuShuo
Cc: Artem.Bityutskiy, dedekind1, linuxppc-dev, linux-kernel, shuo.liu,
linux-mtd, akpm, dwmw2
In-Reply-To: <4EE8612C.9050104@freescale.com>
On 12/14/2011 02:41 AM, LiuShuo wrote:
> =E4=BA=8E 2011=E5=B9=B412=E6=9C=8813=E6=97=A5 10:46, LiuShuo =E5=86=99=E9=
=81=93:
>> =E4=BA=8E 2011=E5=B9=B412=E6=9C=8813=E6=97=A5 05:30, Scott Wood =E5=86=
=99=E9=81=93:
>>> On 12/12/2011 03:19 PM, Artem Bityutskiy wrote:
>>>> On Mon, 2011-12-12 at 15:15 -0600, Scott Wood wrote:
>>>>> NAND chips come from the factory with bad blocks marked at a certai=
n
>>>>> offset into each page. This offset is normally in the OOB area, bu=
t
>>>>> since we change the layout from "4k data, 128 byte oob" to "2k
>>>>> data, 64
>>>>> byte oob, 2k data, 64 byte oob" the marker is no longer in the
>>>>> oob. On
>>>>> first use we need to migrate the markers so that they are still in
>>>>> the oob.
>>>> Ah, I see, thanks. Are you planning to implement in-kernel migration=
or
>>>> use a user-space tool?
>>> That's the kind of answer I was hoping to get from Shuo. :-)
>> OK, I try to do this. Wait for a couple of days.
>>
>> -LiuShuo
> I found it's too complex to do the migration in Linux driver.
>=20
> Maybe we can add a uboot command (e.g. nand bbmigrate) to do it, once i=
s
> enough.
Any reason not to do it automatically on the first U-Boot bad block
scan, if the flash isn't marked as already migrated?
Further discussion on the details of how to do it in U-Boot should move
to the U-Boot list.
> And let user ensure it been completed before linux use the Nand flash c=
hip.
I don't want to trust the user here. It's too easy to skip it, and
things will appear to work, but have subtle problems.
> Even if we don't do the migration, the bad block also can be marked as =
bad
> by wearing. So, do we really need to take much time to implement it ?
> (code looks too complex.)
It is not acceptable to ignore factory bad block markers just because
some methods of using the flash may eventually detect an error (possibly
after data is lost -- no guarantee that the badness is ECC-correctable)
and mark the block bad again.
If you don't feel up to the task, I can look at it, but won't have time
until January.
-Scott
^ permalink raw reply
* RE: ARM + TI DSP device tree repesentation
From: Jeff Brower @ 2011-12-14 17:52 UTC (permalink / raw)
To: David Laight; +Cc: linuxppc-dev
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6D8AF13@saturn3.aculab.com>
David-
>> I am trying to locate the device tree for OMAP platform which
>> has ARM and TI DSP core.
>>
>> The background is that we are trying to understand how such
>> SOCs with dissimilar cores are represented in linux.
>
> Most likely linux runs on the ARM, and the DSP processor
> is loaded with specific code to perform certain functions.
>
> As such the DSP is probably a 'peripheral' not a cpu.
I think that's correct. However, some companies are developing OpenMP and OpenCL acceleration that lets the DSP cores
appear as additional CPU cores, with the idea being to offload compute-intensive operations from the ARM.
This works with OMAP because the DSP cores are CPUs with SIMD and VLIW, as opposed to other SoCs that have limited
"media processor" or GPU type cores that can't run arbitrary C/C++ code.
-Jeff
^ permalink raw reply
* Re: linux-next: build warnings after merge of the final tree
From: H. Peter Anvin @ 2011-12-14 16:47 UTC (permalink / raw)
To: Steven Rostedt
Cc: Stephen Rothwell, Peter Zijlstra, linux-kernel, linux-next,
Paul Mackerras, Thomas Gleixner, linuxppc-dev, Ingo Molnar
In-Reply-To: <1323880322.23971.33.camel@gandalf.stny.rr.com>
On 12/14/2011 08:32 AM, Steven Rostedt wrote:
> On Wed, 2011-12-14 at 18:15 +1100, Stephen Rothwell wrote:
>
>> Maybe caused by commit d5e553d6e0a4 ("trace: Include <asm/asm-offsets.h>
>> in trace_syscalls.c") from the tip tree. These warnings may have been
>> here for a while as it is hard to catch the new ones among the flood.
>>
>
> hpa,
>
> Was this change only needed for x86? If so, could you put that into
> asm/ftrace.h instead?
>
Yes (on both accounts). It was part of the syscall changes; I'll move
the include.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* Re: linux-next: build warnings after merge of the final tree
From: Steven Rostedt @ 2011-12-14 16:32 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Peter Zijlstra, linux-kernel, linux-next, Paul Mackerras,
H. Peter Anvin, Thomas Gleixner, linuxppc-dev, Ingo Molnar
In-Reply-To: <20111214181545.6e13bc954cb7ddce9086e861@canb.auug.org.au>
On Wed, 2011-12-14 at 18:15 +1100, Stephen Rothwell wrote:
> Maybe caused by commit d5e553d6e0a4 ("trace: Include <asm/asm-offsets.h>
> in trace_syscalls.c") from the tip tree. These warnings may have been
> here for a while as it is hard to catch the new ones among the flood.
>
hpa,
Was this change only needed for x86? If so, could you put that into
asm/ftrace.h instead?
-- Steve
^ permalink raw reply
* RE: ARM + TI DSP device tree repesentation
From: David Laight @ 2011-12-14 16:27 UTC (permalink / raw)
To: Aggrwal Poonam-B10812, linuxppc-dev; +Cc: Gala Kumar-B11780
In-Reply-To: <ACB6D0C0104CFF42A45A5D82A0DD4F3D014365@039-SN2MPN1-013.039d.mgd.msft.net>
=20
> I am trying to locate the device tree for OMAP platform which=20
> has ARM and TI DSP core.
>=20
> The background is that we are trying to understand how such=20
> SOCs with dissimilar cores are represented in linux.
Most likely linux runs on the ARM, and the DSP processor
is loaded with specific code to perform certain functions.
As such the DSP is probably a 'peripheral' not a cpu.
David
^ permalink raw reply
* Re: ARM + TI DSP device tree repesentation
From: Jeff Brower @ 2011-12-14 15:51 UTC (permalink / raw)
To: Aggrwal Poonam-B10812; +Cc: linuxppc-dev
In-Reply-To: <ACB6D0C0104CFF42A45A5D82A0DD4F3D014365@039-SN2MPN1-013.039d.mgd.msft. net>
Poonam-
> I am trying to locate the device tree for OMAP platform which
> has ARM and TI DSP core.
>
> The background is that we are trying to understand how such
> SOCs with dissimilar cores are represented in linux.
>
> Can somebody point me to the correct file.
Neither one of the cores are PowerPC -- you might have better luck looking under an Android Linux distribution.
Android is typically used on tablets and phones that contain OMAP.
-Jeff
^ permalink raw reply
* ARM + TI DSP device tree repesentation
From: Aggrwal Poonam-B10812 @ 2011-12-14 12:33 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org list; +Cc: Gala Kumar-B11780
Hello All
I am trying to locate the device tree for OMAP platform which has ARM and T=
I DSP core.
The background is that we are trying to understand how such SOCs with dissi=
milar cores are represented in linux.
Can somebody point me to the correct file.=20
Many Thanks
Poonam
^ permalink raw reply
* RE: [PATCH v2] Integrated Flash Controller support
From: Li Yang-R58472 @ 2011-12-14 11:13 UTC (permalink / raw)
To: dedekind1@gmail.com, Kumar Gala
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org list,
Liu Shuo-B35362, linux-kernel@vger.kernel.org Kernel,
linux-mtd@lists.infradead.org, Andrew Morton, David Woodhouse
In-Reply-To: <1322643080.24797.413.camel@sauron.fi.intel.com>
Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogQXJ0ZW0gQml0eXV0c2tpeSBbbWFp
bHRvOmRlZGVraW5kMUBnbWFpbC5jb21dDQo+U2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAzMCwg
MjAxMSA0OjUxIFBNDQo+VG86IEt1bWFyIEdhbGENCj5DYzogV29vZCBTY290dC1CMDc0MjE7IExp
IFlhbmctUjU4NDcyOyBMaXUgU2h1by1CMzUzNjI7IGxpbnV4LQ0KPmtlcm5lbEB2Z2VyLmtlcm5l
bC5vcmcgS2VybmVsOyBsaW51eC1tdGRAbGlzdHMuaW5mcmFkZWFkLm9yZzsgQW5kcmV3DQo+TW9y
dG9uOyBEYXZpZCBXb29kaG91c2U7IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnIGxpc3QN
Cj5TdWJqZWN0OiBSZTogW1BBVENIIHYyXSBJbnRlZ3JhdGVkIEZsYXNoIENvbnRyb2xsZXIgc3Vw
cG9ydA0KPg0KPk9uIFR1ZSwgMjAxMS0xMS0yOSBhdCAxOTo0NyAtMDYwMCwgS3VtYXIgR2FsYSB3
cm90ZToNCj4+IEFzIFNjb3R0IHNhaWQsIEkgd2FzIG1vcmUgYXNraW5nIGFib3V0IHRoZSAybmQg
cGF0Y2ggaW4gdGhlIHNlcXVlbmNlDQo+PiB3aGljaCBkaWQgdG91Y2ggTVRELiAgU2luY2UgdGhh
dCBvbmUgaXMgZGVwZW5kZW50IG9uIHRoaXMgcGF0Y2gsDQo+PiB3b25kZXJpbmcgaG93IHdlIHdh
bnRlZCB0byBoYW5kbGUgdGhlbS4NCj4NCj5JIGRvIG5vdCBoYXZlIHRpbWUgdG8gcmV2aWV3IGl0
LCBidXQgaXQgbG9va3MgT0ssIHNvIEknZCBzdWdnZXN0IHRvDQo+bWVyZ2UgaXQgdmllIHRoZSBz
YW1lIHRyZWUgYXMgdGhlIHJlc3Qgb2YgdGhlIHBhdGNoZXMuDQoNCkhpIEFydGVtLA0KDQpTbyB3
aGF0IGlzIHlvdXIgc3VnZ2VzdGlvbiBvbiB0aGlzIHBhdGNoPyAgQ2FuIHdlIHJlZ2FyZCB5b3Vy
IHByZXZpb3VzIGVtYWlsIGFzIGFuIEFDSyBhbmQgbWVyZ2UgaXQgdGhyb3VnaCB0aGUgcG93ZXJw
YyB0cmVlPyAgT3IgZG8geW91IHByZWZlciB0byBtZXJnZSB0aGVtIHRocm91Z2ggdGhlIE1URCB0
cmVlIHdpdGggS3VtYXIncyBBQ0sgaW5zdGVhZD8NCg0KLSBMZW8NCg==
^ permalink raw reply
* Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: LiuShuo @ 2011-12-14 8:41 UTC (permalink / raw)
To: Scott Wood, dedekind1
Cc: Artem.Bityutskiy, linuxppc-dev, linux-kernel, shuo.liu, linux-mtd,
akpm, dwmw2
In-Reply-To: <4EE6BC9B.4000602@freescale.com>
=E4=BA=8E 2011=E5=B9=B412=E6=9C=8813=E6=97=A5 10:46, LiuShuo =E5=86=99=E9=
=81=93:
> =E4=BA=8E 2011=E5=B9=B412=E6=9C=8813=E6=97=A5 05:30, Scott Wood =E5=86=99=
=E9=81=93:
>> On 12/12/2011 03:19 PM, Artem Bityutskiy wrote:
>>> On Mon, 2011-12-12 at 15:15 -0600, Scott Wood wrote:
>>>> NAND chips come from the factory with bad blocks marked at a certain
>>>> offset into each page. This offset is normally in the OOB area, but
>>>> since we change the layout from "4k data, 128 byte oob" to "2k=20
>>>> data, 64
>>>> byte oob, 2k data, 64 byte oob" the marker is no longer in the=20
>>>> oob. On
>>>> first use we need to migrate the markers so that they are still in=20
>>>> the oob.
>>> Ah, I see, thanks. Are you planning to implement in-kernel migration =
or
>>> use a user-space tool?
>> That's the kind of answer I was hoping to get from Shuo. :-)
> OK, I try to do this. Wait for a couple of days.
>
> -LiuShuo
I found it's too complex to do the migration in Linux driver.
Maybe we can add a uboot command (e.g. nand bbmigrate) to do it, once is=20
enough.
And let user ensure it been completed before linux use the Nand flash chi=
p.
Even if we don't do the migration, the bad block also can be marked as ba=
d
by wearing. So, do we really need to take much time to implement it ?
(code looks too complex.)
-LiuShuo
>> Most likely is a firmware-based tool, but I'd like there to be some wa=
y
>> for the tool to mark that this has happened, so that the Linux driver
>> can refuse to do non-raw accesses to a chip that isn't marked as havin=
g
>> been migrated (or at least yell loudly in the log).
>>
>> Speaking of raw accesses, these are currently broken in the eLBC
>> driver... we need some way for the generic layer to tell us what kind =
of
>> access it is before the transaction starts, not once it wants to read
>> out the buffer (unless we add more hacks to delay the start of a read
>> transaction until first buffer access...). We'd be better off with a
>> high-level "read page/write page" function that does the whole thing
>> (not just buffer access, but command issuance as well).
>>
>> -Scott
>
^ permalink raw reply
* linux-next: build warnings after merge of the final tree
From: Stephen Rothwell @ 2011-12-14 7:15 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
Cc: linux-next, Paul Mackerras, linux-kernel, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1476 bytes --]
Hi all,
After merging the final tree, today's linux-next build (powerpc allyesconfig)
produced these warnings:
In file included from arch/powerpc/include/asm/asm-offsets.h:1:0,
from kernel/trace/trace_syscalls.c:9:
include/generated/asm-offsets.h:15:0: warning: "NMI_MASK" redefined [enabled by default]
include/linux/hardirq.h:56:0: note: this is the location of the previous definition
include/generated/asm-offsets.h:128:0: warning: "CLONE_VM" redefined [enabled by default]
include/linux/sched.h:8:0: note: this is the location of the previous definition
include/generated/asm-offsets.h:129:0: warning: "CLONE_UNTRACED" redefined [enabled by default]
include/linux/sched.h:22:0: note: this is the location of the previous definition
include/generated/asm-offsets.h:165:0: warning: "NSEC_PER_SEC" redefined [enabled by default]
include/linux/time.h:40:0: note: this is the location of the previous definition
include/generated/asm-offsets.h:173:0: warning: "PGD_TABLE_SIZE" redefined [enabled by default]
arch/powerpc/include/asm/pgtable-ppc64-4k.h:17:0: note: this is the location of the previous definition
Maybe caused by commit d5e553d6e0a4 ("trace: Include <asm/asm-offsets.h>
in trace_syscalls.c") from the tip tree. These warnings may have been
here for a while as it is hard to catch the new ones among the flood.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] Only use initrd_end as the limit for alloc_bottom if it's inside the RMO.
From: Tony Breeds @ 2011-12-14 3:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt, LinuxPPC-dev; +Cc: Paul Mackerras, Anton Blanchard
From: Paul Mackerras <paulus@samba.org>
As the kernels and initrd's get bigger boot-loaders and possibly
kexec-tools will need to place the initrd outside the RMO. When this
happens we end up with no lowmem and the boot doesn't get very far.
Only use initrd_end as the limit for alloc_bottom if it's inside the
RMO.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
arch/powerpc/kernel/prom_init.c | 17 +++++++++--------
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index cc58486..940dc0c 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -1224,14 +1224,6 @@ static void __init prom_init_mem(void)
RELOC(alloc_bottom) = PAGE_ALIGN((unsigned long)&RELOC(_end) + 0x4000);
- /* Check if we have an initrd after the kernel, if we do move our bottom
- * point to after it
- */
- if (RELOC(prom_initrd_start)) {
- if (RELOC(prom_initrd_end) > RELOC(alloc_bottom))
- RELOC(alloc_bottom) = PAGE_ALIGN(RELOC(prom_initrd_end));
- }
-
/*
* If prom_memory_limit is set we reduce the upper limits *except* for
* alloc_top_high. This must be the real top of RAM so we can put
@@ -1269,6 +1261,15 @@ static void __init prom_init_mem(void)
RELOC(alloc_top) = RELOC(rmo_top);
RELOC(alloc_top_high) = RELOC(ram_top);
+ /*
+ * Check if we have an initrd after the kernel but still inside
+ * the RMO. If we do move our bottom point to after it.
+ */
+ if (RELOC(prom_initrd_start) &&
+ RELOC(prom_initrd_start) < RELOC(rmo_top) &&
+ RELOC(prom_initrd_end) > RELOC(alloc_bottom))
+ RELOC(alloc_bottom) = PAGE_ALIGN(RELOC(prom_initrd_end));
+
prom_printf("memory layout at init:\n");
prom_printf(" memory_limit : %x (16 MB aligned)\n", RELOC(prom_memory_limit));
prom_printf(" alloc_bottom : %x\n", RELOC(alloc_bottom));
--
1.7.6.4
^ permalink raw reply related
* Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: LiuShuo @ 2011-12-14 3:41 UTC (permalink / raw)
To: dedekind1, Scott Wood
Cc: Artem.Bityutskiy, linuxppc-dev, linux-kernel, shuo.liu, linux-mtd,
akpm, dwmw2
In-Reply-To: <1323724195.2297.11.camel@koala>
=E4=BA=8E 2011=E5=B9=B412=E6=9C=8813=E6=97=A5 05:09, Artem Bityutskiy =E5=
=86=99=E9=81=93:
> On Tue, 2011-12-06 at 18:09 -0600, Scott Wood wrote:
>> On 12/03/2011 10:31 PM, shuo.liu@freescale.com wrote:
>>> From: Liu Shuo<shuo.liu@freescale.com>
>>>
>>> Freescale FCM controller has a 2K size limitation of buffer RAM. In o=
rder
>>> to support the Nand flash chip whose page size is larger than 2K byte=
s,
>>> we read/write 2k data repeatedly by issuing FIR_OP_RB/FIR_OP_WB and s=
ave
>>> them to a large buffer.
>>>
>>> Signed-off-by: Liu Shuo<shuo.liu@freescale.com>
>>> ---
>>> v3:
>>> -remove page_size of struct fsl_elbc_mtd.
>>> -do a oob write by NAND_CMD_RNDIN.
>>>
>>> drivers/mtd/nand/fsl_elbc_nand.c | 243 +++++++++++++++++++++++++++=
+++++++----
>>> 1 files changed, 218 insertions(+), 25 deletions(-)
>> What is the plan for bad block marker migration.
I think we can use a special bbt pattern to indicate whether migration=20
has been done.
(we needn't to define another marker)
Do the migration our chip->scan_bbt as follow :
/*
* this pattern indicate that the bad block information has been migrate=
d,
* if this isn't found, we do the migration.
*/
static u8 migrated_bbt_pattern[] =3D {'M', 'b', 'b', 't', '0' };
static int fsl_elbc_bbt(struct mtd_info *mtd)
{
if (!check_migrated_bbt_pattern())
bad_block_info_migtrate();
nand_default_bbt(mtd); /* default function in nand_bbt.c */
}
- LiuShuo
^ permalink raw reply
* RE: [PATCH] mmc: sdhci-pltfm: Added sdhci-adjust-timeout quirk
From: Xie Xiaobo-R63061 @ 2011-12-14 3:27 UTC (permalink / raw)
To: Huang Changming-R66093, linuxppc-dev@lists.ozlabs.org
Cc: avorontsov@ru.mvista.com, linux-mmc@vger.kernel.org
In-Reply-To: <8A2FC72B45BB5A4C9F801431E06AE48F11644C44@039-SN1MPN1-006.039d.mgd.msft.net>
SGkgQ2hhbmdtaW5nLA0KDQpPSywgeW91IGNhbiBtZXJnZSBteSBwYXRjaCBpbnRvIHlvdXIgcGF0
Y2hlcy4NCg0KSGkgYWxsLA0KUGxlYXNlIGlnbm9yZSB0aGlzIHBhdGNoLiBDaGFuZ21pbmcgd2ls
bCBzZW5kIHRoZSBzaW1pbGFyIHBhdGNoLg0KDQpCUnMNClhpZSBYaWFvYm8NCg0KLS0tLS1Pcmln
aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEh1YW5nIENoYW5nbWluZy1SNjYwOTMgDQpTZW50OiAy
MDExxOoxMtTCMTPI1SAxNjowMA0KVG86IFhpZSBYaWFvYm8tUjYzMDYxOyBsaW51eHBwYy1kZXZA
bGlzdHMub3psYWJzLm9yZw0KQ2M6IGF2b3JvbnRzb3ZAcnUubXZpc3RhLmNvbTsgbGludXgtbW1j
QHZnZXIua2VybmVsLm9yZzsgWGllIFhpYW9iby1SNjMwNjENClN1YmplY3Q6IFJFOiBbUEFUQ0hd
IG1tYzogc2RoY2ktcGx0Zm06IEFkZGVkIHNkaGNpLWFkanVzdC10aW1lb3V0IHF1aXJrDQoNClhp
YW9ibywgSSBoYXZlIG9uZSBvdGhlciBzaW1pbGFyIHBhdGNoLCBidXQgdGhlIHByb3BlcnR5IGlz
ICdzZGhjaSxhZGp1c3QtdGltZW91dCcuDQpNYXliZSBJIGNhbiByZXBvc3QgaXQgd2l0aCBhZGQg
eW91ciBzaWduZWQtb2ZmLWJ5Pw0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy
b206IGxpbnV4cHBjLWRldi1ib3VuY2VzK3I2NjA5Mz1mcmVlc2NhbGUuY29tQGxpc3RzLm96bGFi
cy5vcmcNCj4gW21haWx0bzpsaW51eHBwYy1kZXYtYm91bmNlcytyNjYwOTM9ZnJlZXNjYWxlLmNv
bUBsaXN0cy5vemxhYnMub3JnXSBPbiANCj4gQmVoYWxmIE9mIFhpZSBYaWFvYm8NCj4gU2VudDog
TW9uZGF5LCBEZWNlbWJlciAwNSwgMjAxMSA0OjU1IFBNDQo+IFRvOiBsaW51eHBwYy1kZXZAbGlz
dHMub3psYWJzLm9yZw0KPiBDYzogYXZvcm9udHNvdkBydS5tdmlzdGEuY29tOyBsaW51eC1tbWNA
dmdlci5rZXJuZWwub3JnOyBYaWUgWGlhb2JvLQ0KPiBSNjMwNjENCj4gU3ViamVjdDogW1BBVENI
XSBtbWM6IHNkaGNpLXBsdGZtOiBBZGRlZCBzZGhjaS1hZGp1c3QtdGltZW91dCBxdWlyaw0KPiAN
Cj4gU29tZSBjb250cm9sbGVyIHByb3ZpZGVzIGFuIGluY29ycmVjdCB0aW1lb3V0IHZhbHVlIGZv
ciB0cmFuc2ZlcnMsIFNvIA0KPiBpdCBuZWVkIHRoZSBxdWlyayB0byBhZGp1c3QgdGltZW91dCB2
YWx1ZSB0byAweEUuDQo+IEUuZy4gZVNESEMgb2YgTVBDODUzNiwgUDEwMTAsIGFuZCBQMjAyMC4N
Cj4gDQo+IFNpZ25lZC1vZmYtYnk6IFhpZSBYaWFvYm8gPFguWGllQGZyZWVzY2FsZS5jb20+DQo+
IC0tLQ0KPiAgZHJpdmVycy9tbWMvaG9zdC9zZGhjaS1wbHRmbS5jIHwgICAgNSArKysrLQ0KPiAg
MSBmaWxlcyBjaGFuZ2VkLCA0IGluc2VydGlvbnMoKyksIDEgZGVsZXRpb25zKC0pDQo+IA0KPiBk
aWZmIC0tZ2l0IGEvZHJpdmVycy9tbWMvaG9zdC9zZGhjaS1wbHRmbS5jIGIvZHJpdmVycy9tbWMv
aG9zdC9zZGhjaS0gDQo+IHBsdGZtLmMgaW5kZXggYTllMTJlYS4uYjVkNmIzZiAxMDA2NDQNCj4g
LS0tIGEvZHJpdmVycy9tbWMvaG9zdC9zZGhjaS1wbHRmbS5jDQo+ICsrKyBiL2RyaXZlcnMvbW1j
L2hvc3Qvc2RoY2ktcGx0Zm0uYw0KPiBAQCAtMiw3ICsyLDcgQEANCj4gICAqIHNkaGNpLXBsdGZt
LmMgU3VwcG9ydCBmb3IgU0RIQ0kgcGxhdGZvcm0gZGV2aWNlcw0KPiAgICogQ29weXJpZ2h0IChj
KSAyMDA5IEludGVsIENvcnBvcmF0aW9uDQo+ICAgKg0KPiAtICogQ29weXJpZ2h0IChjKSAyMDA3
IEZyZWVzY2FsZSBTZW1pY29uZHVjdG9yLCBJbmMuDQo+ICsgKiBDb3B5cmlnaHQgKGMpIDIwMDcs
IDIwMTEgRnJlZXNjYWxlIFNlbWljb25kdWN0b3IsIEluYy4NCj4gICAqIENvcHlyaWdodCAoYykg
MjAwOSBNb250YVZpc3RhIFNvZnR3YXJlLCBJbmMuDQo+ICAgKg0KPiAgICogQXV0aG9yczogWGlh
b2JvIFhpZSA8WC5YaWVAZnJlZXNjYWxlLmNvbT4gQEAgLTY4LDYgKzY4LDkgQEAgdm9pZCANCj4g
c2RoY2lfZ2V0X29mX3Byb3BlcnR5KHN0cnVjdCBwbGF0Zm9ybV9kZXZpY2UgKnBkZXYpDQo+ICAJ
CWlmIChvZl9nZXRfcHJvcGVydHkobnAsICJzZGhjaSwxLWJpdC1vbmx5IiwgTlVMTCkpDQo+ICAJ
CQlob3N0LT5xdWlya3MgfD0gU0RIQ0lfUVVJUktfRk9SQ0VfMV9CSVRfREFUQTsNCj4gDQo+ICsJ
CWlmIChvZl9nZXRfcHJvcGVydHkobnAsICJzZGhjaSxzZGhjaS1hZGp1c3QtdGltZW91dCIsIE5V
TEwpKQ0KPiArCQkJaG9zdC0+cXVpcmtzIHw9IFNESENJX1FVSVJLX0JST0tFTl9USU1FT1VUX1ZB
TDsNCj4gKw0KPiAgCQlpZiAoc2RoY2lfb2Zfd3BfaW52ZXJ0ZWQobnApKQ0KPiAgCQkJaG9zdC0+
cXVpcmtzIHw9IFNESENJX1FVSVJLX0lOVkVSVEVEX1dSSVRFX1BST1RFQ1Q7DQo+IA0KPiAtLQ0K
PiAxLjYuNA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQo+IExpbnV4cHBjLWRldiBtYWlsaW5nIGxpc3QNCj4gTGludXhwcGMtZGV2QGxp
c3RzLm96bGFicy5vcmcNCj4gaHR0cHM6Ly9saXN0cy5vemxhYnMub3JnL2xpc3RpbmZvL2xpbnV4
cHBjLWRldg0KDQo=
^ permalink raw reply
* Re: CONFIG_NO_HZ added too much idle time in /proc/stat during throughput test.
From: Anton Blanchard @ 2011-12-14 3:17 UTC (permalink / raw)
To: Fushen Chen; +Cc: Peter Zijlstra, Thomas Gleixner, Linuxppc-dev Development
In-Reply-To: <CAEu=RPgnh-i-SFt4kiiAtDjLZ3A0cAHhk7ch56Uvv0uG_+HfCg@mail.gmail.com>
Hi,
> This is 2.6.32, but I think 2.6.36 is the same.
Sounds a bit like this, merged in 2.6.39.
Anton
--
commit ad5d1c888e556bc00c4e86f452cad4a3a87d22c1
Author: Anton Blanchard <anton@samba.org>
Date: Sun Mar 20 15:28:03 2011 +0000
powerpc: Fix accounting of softirq time when idle
commit cf9efce0ce31 (powerpc: Account time using timebase rather
than PURR) used in_irq() to detect if the time was spent in
interrupt processing. This only catches hardirq context so if we
are in softirq context and in the idle loop we end up accounting it
as idle time. If we instead use in_interrupt() we catch both softirq
and hardirq time.
The issue was found when running a network intensive workload. top
showed the following:
0.0%us, 1.1%sy, 0.0%ni, 85.7%id, 0.0%wa, 9.9%hi, 3.3%si, 0.0%st
85.7% idle. But this was wildly different to the perf events data.
To confirm the suspicion I ran something to keep the core busy:
# yes > /dev/null &
8.2%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 10.3%hi, 81.4%si, 0.0%st
We only got 8.2% of the CPU for the userspace task and softirq has
shot up to 81.4%.
With the patch below top shows the correct stats:
0.0%us, 0.0%sy, 0.0%ni, 5.3%id, 0.0%wa, 13.3%hi, 81.3%si, 0.0%st
Signed-off-by: Anton Blanchard <anton@samba.org>
Cc: stable@kernel.org
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
^ permalink raw reply
* Re: [PATCH] powerpc: Fix swiotlb ops for ppc64
From: Benjamin Herrenschmidt @ 2011-12-14 3:00 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev list
In-Reply-To: <C9D58E47-96F4-45ED-BE54-758D71B361FD@kernel.crashing.org>
On Tue, 2011-12-13 at 20:53 -0600, Becky Bruce wrote:
> The non-coherent "specialness" is in the dma sync stuff and no, I
> don't think the iotlb stuff deals with that properly.
>
> Do you not have a problem with 1)? If not then I think we can look at
> switching over; 2) was more of a secondary thing.
So let's switch over, avoid an #ifdef which is always a good thing...
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Fix swiotlb ops for ppc64
From: Becky Bruce @ 2011-12-14 2:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1323750427.19891.59.camel@pasglop>
On Dec 12, 2011, at 10:27 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2011-12-12 at 21:55 -0600, Becky Bruce wrote:
>> 1) dma_direct_alloc_coherent strips GFP_HIGHMEM out of the flags =
field
>> when calling the actual allocator and the iotlb version does not. I
>> don't know how much this matters - I did a quick grep and I don't see
>> any users that specify that, but somebody went through the trouble of
>> putting it in there in the first place and without knowing why I
>> wasn't willing to get rid of it. Now, since my patch it looks like
>> someone added a VM_BUG_ON into __get_free_pages() if GFP_HIGHMEM so
>> this would get caught. However, I don't know if we really want to
>> throw a bug there.
>>=20
>> 2) The iotlb code doesn't deal with the !coherent parts like 8xx. =
We
>> can work around that by setting up the dma_ops differently for that
>> case instead.
>=20
> Does the rest of it handle them ? I mean swiotlb_map_sg_attrs etc...
The non-coherent "specialness" is in the dma sync stuff and no, I don't =
think the iotlb stuff deals with that properly.
Do you not have a problem with 1)? If not then I think we can look at =
switching over; 2) was more of a secondary thing.
-B
^ permalink raw reply
* Re: CONFIG_NO_HZ added too much idle time in /proc/stat during throughput test.
From: Fushen Chen @ 2011-12-14 1:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Peter Zijlstra, Linuxppc-dev Development, Thomas Gleixner
In-Reply-To: <1323819246.7671.4.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 1524 bytes --]
This is 2.6.32, but I think 2.6.36 is the same.
Thanks,
Fushen
On Tue, Dec 13, 2011 at 3:34 PM, Benjamin Herrenschmidt <
benh@kernel.crashing.org> wrote:
> On Wed, 2011-12-14 at 00:28 +0100, Thomas Gleixner wrote:
> > On Wed, 14 Dec 2011, Benjamin Herrenschmidt wrote:
> >
> > > On Tue, 2011-12-13 at 12:42 -0800, Fushen Chen wrote:
> > > > On APM82181, "vmstat" (/proc/stat) doesn't show correct idle
> > > > percent, if kernel enables "CONFIG_NO_HZ" (Tickless System / Dynamic
> > > > Tick).
> > > >
> > > > When I run wireless throughput test with heavy traffic, "vmstat"
> shows
> > > > very high idle percent while "oprofile" shows very low idle percent.
> > > > During the test, the system is idle, but network traffic uses a lot
> of
> > > > hard IRQ and soft-irq time. "vmstat" would have the correct stats if
> > > > account_idle_ticks(ticks) in kernel/time/tick-sched.c doesn't add
> more
> > > > idle time in "vmstat". In the same test, if I disable "CONFIG_NO_HZ"
> > > > in kernel, idle percent in "vmstat" and "oprofile" would match.
> > > >
> > > > My APM82181 kernel configuration is "CONFIG_NO_HZ",
> "CONFIG_HZ_250=y",
> > > > "CONFIG_HZ=250", and "CONFIG_HIGH_RES_TIMERS".
> > > >
> > > > My question is that if kernel enables "CONFIG_NO_HZ", how would
> kernel
> > > > report correct stats.
> > >
> > > Hi Thomas ! Any idea what we're doing wrong ? :-)
> >
> > Not really, that had been an issue before and had been fixed. Peter ????
>
> Fusen, what kernel version is this ?
>
> Cheers,
> Ben.
>
>
>
[-- Attachment #2: Type: text/html, Size: 2237 bytes --]
^ permalink raw reply
* Re: CONFIG_NO_HZ added too much idle time in /proc/stat during throughput test.
From: Andreas Schwab @ 2011-12-13 23:57 UTC (permalink / raw)
To: Fushen Chen; +Cc: Linuxppc-dev Development
In-Reply-To: <CAEu=RPirE=H1N=KjHNjNRBM6H1fRvrugCw6ojqWaTNm2=WTfng__4707.66240400753$1323813396$gmane$org@mail.gmail.com>
Does this help?
<http://permalink.gmane.org/gmane.linux.ports.ppc.embedded/47530>
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ 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