RE: [PATCH 1/3 v4] P4080/eLBC: Make Freescale elbc interrupt common to elbc devices
> -Original Message- > From: Wood Scott-B07421 > Sent: Friday, October 15, 2010 0:03 AM > To: Zang Roy-R61911 > Cc: Anton Vorontsov; linux-...@lists.infradead.org; dw...@infradead.org; > dedeki...@gmail.com; a...@linux-foundation.org; Lan Chunhe-B25806; Wood Scott- > B07421; Gala Kumar-B11780; linuxppc-...@ozlabs.org > Subject: Re: [PATCH 1/3 v4] P4080/eLBC: Make Freescale elbc interrupt common > to elbc devices > > On Wed, 13 Oct 2010 23:43:38 -0700 > "Zang Roy-R61911" wrote: > > > > Plus, I think the patch is not runtime bisectable (i.e. you > > > now do request_irq() here, but not removing it from the nand > > > driver, so nand will fail to probe). > > Nand driver does not need to request irq. It will use the irq requested by > lbc. > > remember, other lbc device may also need to use this registered irq. > > It should not be removed in nand driver. > > The point is that you need to make both changes in the same patch. But according to previous discussion, if lbc driver is registered successful, it will not be removed. (.remove function is dropped in the patch). that is not bisectable? nand driver will not touch the irq. all irq status process is in the lbc driver. Thanks. Roy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] add icswx support v2
On Wed, 2010-10-13 at 11:52 +1100, Michael Neuling wrote:
> In message <1286855108.14049.8.ca...@flin.austin.ibm.com> you wrote:
> > icswx is a PowerPC co-processor instruction to send data to a
> > co-processor. On Book-S processors the LPAR_ID and process ID (PID) of
> > the owning process are registered in the window context of the
> > co-processor at initial time. When the icswx instruction is executed,
> > the L2 generates a cop-reg transaction on PowerBus. The transaction has
> > no address and the processor does not perform an MMU access to
> > authenticate the transaction. The coprocessor compares the LPAR_ID and
> > the PID included in the transaction and the LPAR_ID and PID held in the
> > window context to determine if the process is authorized to generate the
> > transaction.
> >
> > This patch adds icswx co-processor instruction support.
>
> Can you describe the ABI a bit?
>
> How has this changed from version 1?
>
The icswx instruction itself does nothing but generating a cop-req
transaction on PowerBus. The cop-req transaction causes 1 cache
line of data (128 bytes) sent to the co-processor. This provides
a low latency mechanism for sending small amount of data without
the co-processor becoming a master on the PowerBus.
Since the transaction has no address and the processor does not
perform an MMU access to authenticate the transaction, the
co-processor relys on the the LPAR_ID and PID to determine if
the process is authorized to generate the transaction.
The OS needs to assign a 16-bit PID for the process. This
cop-PID needs needs to be updated during context switch. The
cop-PID needs to be destroied when the context is destroied.
Change log from v1:
- Change 2'nd parameter of use_cop() from struct task_struct *task
to struct mm_struct *mm.
- Check for mm == current->active_mm before calling mtspr().
- Add a lock to guard acop related operations.
- Check for POWER7 CPU.
- Move the definition of SPRN_PID from reg_booke.h to avoid
defining SPRN_PID in two different files.
- Rename pid to acop_pid.
- Change function name disuse_cop() to drop_cop().
- Add a comment to describe the two new fields in mm_context_t.
- Moving CONFIG_ICSWX from arch/powerpc/platforms/pseries/Kconfig
to arch/powerpc/platforms/Kconfig.cputype
All other comments will be addressed in a new patch.
> Patch has been whitespace munged aswell.
>
> More comments below...
>
> >
> > Signed-off-by: Sonny Rao
> > Signed-off-by: Tseng-Hui (Frank) Lin
> > ---
> > arch/powerpc/include/asm/mmu-hash64.h |5 ++
> > arch/powerpc/include/asm/mmu_context.h |6 ++
> > arch/powerpc/include/asm/reg.h | 12
> > arch/powerpc/include/asm/reg_booke.h |3 -
> > arch/powerpc/mm/mmu_context_hash64.c | 105
> >
> > arch/powerpc/platforms/Kconfig.cputype | 16 +
> > 6 files changed, 144 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/mmu-hash64.h
> > b/arch/powerpc/include/asm/mmu-hash64.h
> > index acac35d..6c1ab90 100644
> > --- a/arch/powerpc/include/asm/mmu-hash64.h
> > +++ b/arch/powerpc/include/asm/mmu-hash64.h
> > @@ -423,6 +423,11 @@ typedef struct {
> > #ifdef CONFIG_PPC_SUBPAGE_PROT
> > struct subpage_prot_table spt;
> > #endif /* CONFIG_PPC_SUBPAGE_PROT */
> > +#ifdef CONFIG_ICSWX
> > + unsigned long acop; /* mask of enabled coprocessor types */
> > +#define HASH64_MAX_PID (0x)
> > + unsigned int acop_pid; /* pid value used with coprocessors */
> > +#endif /* CONFIG_ICSWX */
> > } mm_context_t;
> >
> >
> > diff --git a/arch/powerpc/include/asm/mmu_context.h
> > b/arch/powerpc/include/asm/mmu_context.h
> > index 81fb412..88118de 100644
> > --- a/arch/powerpc/include/asm/mmu_context.h
> > +++ b/arch/powerpc/include/asm/mmu_context.h
> > @@ -80,6 +80,12 @@ static inline void switch_mm(struct mm_struct *prev,
> > struct mm_struct *next,
> >
> > #define deactivate_mm(tsk,mm) do { } while (0)
> >
> > +#ifdef CONFIG_ICSWX
> > +extern void switch_cop(struct mm_struct *next);
> > +extern int use_cop(unsigned long acop, struct mm_struct *mm);
> > +extern void drop_cop(unsigned long acop, struct mm_struct *mm);
> > +#endif /* CONFIG_ICSWX */
> > +
> > /*
> > * After we have set current->mm to a new value, this activates
> > * the context for the new mm so we see the new mappings.
> > diff --git a/arch/powerpc/include/asm/reg.h
> > b/arch/powerpc/include/asm/reg.h
> > index ff0005eec..9bbf178 100644
> > --- a/arch/powerpc/include/asm/reg.h
> > +++ b/arch/powerpc/include/asm/reg.h
> > @@ -170,8 +170,19 @@
> > #define SPEFSCR_FRMC 0x0003 /* Embedded FP rounding mode co
> ntrol
> > */
> >
> > /* Special Purpose Registers (SPRNs)*/
> > +
> > +#ifdef CONFIG_40x
> > +#define SPRN_PID 0x3B1 /* Process ID */
> > +#else
> > +#defineSPRN_PID0x030 /* Process ID */
> > +#ifdef CONFIG_BOOKE
> > +#defineSPRN_PID0 SPRN_PID/* Process ID Register 0 */
> > +#endi
Re: [PATCH v2] pseries: don't override CONFIG_PPC_PSERIES_DEBUG
On Thu, 2010-10-14 at 20:54 -0500, Linas Vepstas wrote: > On 14 October 2010 19:48, Nishanth Aravamudan wrote: > > eeh and pci_dlpar #undef DEBUG, but I think they were added before the > > ability to control this from Kconfig. It's really annoying to only get > > some of the debug messages from these files. Leave the lpar.c #undef > > alone as it produces so much output as to make the kernel unusable. > > Update the Kconfig text to indicate this particular quirk :) > > > > Signed-off-by: Nishanth Aravamudan > > OK, ignore my last email. > > Acked by: Linas Vepstas I guess I'll ack it too seeing I added PPC_PSERIES_DEBUG: Acked-by: Michael Ellerman > > --- a/arch/powerpc/platforms/pseries/Kconfig > > +++ b/arch/powerpc/platforms/pseries/Kconfig > > @@ -47,6 +47,12 @@ config LPARCFG > > config PPC_PSERIES_DEBUG > >depends on PPC_PSERIES && PPC_EARLY_DEBUG > >bool "Enable extra debug logging in platforms/pseries" > > +help > > + Say Y here if you want the pseries core to produce a bunch of > > + debug messages to the system log. Select this if you are having a > > + problem with the pseries core and want to see more of what is > > + going on. This does not enable debugging in lpar.c, which must > > + be manually done due to its verbosity. > >default y > > Umm, I see "default y" and you are not changing this but ... default y > ?? Really? Yes, default y if early debug is enabled. Unlike DEBUG_KERNEL, PPC_EARLY_DEBUG is a pretty good indication that you are doing some kernel development - because you have to choose exactly which platform you're working on. > Also, I am guessing that the lpar spam is due only to a handful of printk's, > while most of the rest will be infrequent. Just knock out the > high-frequency ones... No they're all related to the HPTE code, so you basically don't want any of them enabled unless you're debugging that, and most people aren't. cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/3 v4] P4080/mtd: Only make elbc nand driver detect nand flash partitions
> -Original Message- > From: Wood Scott-B07421 > Sent: Friday, October 15, 2010 0:01 AM > To: Zang Roy-R61911 > Cc: Wood Scott-B07421; Anton Vorontsov; linux-...@lists.infradead.org; > dw...@infradead.org; dedeki...@gmail.com; a...@linux-foundation.org; Lan > Chunhe-B25806; Gala Kumar-B11780; linuxppc-...@ozlabs.org; Hu Mingkai-B21284 > Subject: Re: [PATCH 2/3 v4] P4080/mtd: Only make elbc nand driver detect nand > flash partitions > > On Wed, 13 Oct 2010 20:09:02 -0700 > "Zang Roy-R61911" wrote: > > > > > > > + struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = NULL; > > > > > > > > > > No need for = NULL. > > > > Any harm? Or just personal habit or style? Can you explain about > > why? > > > > > > Besides not wanting superfluous code on general principle, it could > > > hide a bug if in the future the real initialization is missing on some > > > code path. It would become a runtime NULL dereference rather than a > > > compiler warning. > > > > Not exactly. > > Per my understand, if the pointer will definitely be assigned in code > > path, > > it is not necessary to init it when define. for example, > > > > char c; > > char b; > > char *a; > > if (condition) > > a = &c; > > else > > a = &b; > > ... > > > > for other case, if the path will not ensure the pointer assignment, it > > will be inited > > when define to avoid warning. for example, > > > > char c; > > char *a = NULL; > > if (condition) > > a = &c; > > ... > > Yes, but this patch looks like the former case, not the > latter. That is right. > Is GCC giving a warning without the initializer? no. we are on the same point. Thanks. Roy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] pseries: don't override CONFIG_PPC_PSERIES_DEBUG
On 14 October 2010 19:48, Nishanth Aravamudan wrote: > eeh and pci_dlpar #undef DEBUG, but I think they were added before the > ability to control this from Kconfig. It's really annoying to only get > some of the debug messages from these files. Leave the lpar.c #undef > alone as it produces so much output as to make the kernel unusable. > Update the Kconfig text to indicate this particular quirk :) > > Signed-off-by: Nishanth Aravamudan OK, ignore my last email. Acked by: Linas Vepstas > --- a/arch/powerpc/platforms/pseries/Kconfig > +++ b/arch/powerpc/platforms/pseries/Kconfig > @@ -47,6 +47,12 @@ config LPARCFG > config PPC_PSERIES_DEBUG > depends on PPC_PSERIES && PPC_EARLY_DEBUG > bool "Enable extra debug logging in platforms/pseries" > + help > + Say Y here if you want the pseries core to produce a bunch of > + debug messages to the system log. Select this if you are having a > + problem with the pseries core and want to see more of what is > + going on. This does not enable debugging in lpar.c, which must > + be manually done due to its verbosity. > default y Umm, I see "default y" and you are not changing this but ... default y ?? Really? Also, I am guessing that the lpar spam is due only to a handful of printk's, while most of the rest will be infrequent. Just knock out the high-frequency ones... --linas ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] ppc: don't override CONFIG_PPC_PSERIES_DEBUG
On 14 October 2010 12:48, Nishanth Aravamudan wrote: > These files undef DEBUG, but I think they were added before the ability > to control this from Kconfig. Right. > It's really annoying to only get some of > the debug messages! I don't get the big picture. Will there be some CONFIG_DEBUG_EEH in Kconfig? or just some option to turn on DEBUG for all powerpc-related files? Or maybe I am demonstrating my utter ignorance of some new whiz-bang Kconfig technology? Anyway, I see no harm in the EEH portion of the patch. --linas ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Questions on interrupt vector assignment on MPC8641D
Scott Wood wrote:
> On Thu, 14 Oct 2010 11:27:09 +0800
> "tiejun.chen" wrote:
>
>> tiejun.chen wrote:
>>> Scott Wood wrote:
On Wed, 13 Oct 2010 09:17:01 +0800
"tiejun.chen" wrote:
> Scott Wood wrote:
>> The crash is happening somewhere in mpic_set_irq_type():
> Agreed. That is just where I pointed out on my email replied for OOPS. To
> enable
> DBG to figure out 'src' and 'mpic->irq_count' from the file,
> arch/powerpc/sysdev/mpic.c,.
> ==
> int mpic_set_irq_type(unsigned int virq, unsigned int flow_type)
> {
> ..
> if (src >= mpic->irq_count)
> return -EINVAL;
> ^
> I think this OOPS may be from here.
No, it's after that. His board code is using the mpic's "isu" remapping
>>> I means OOPS is *from* here. According to David's call trace,
>>> mpic_set_irq_type() is the last issued function. And that corresponding
>>> return
>>> value, R3, is '0xffea', -22, and also '-EINVAL'.
>
> Just because that value is in r3 doesn't mean that src >=
> mpic->irq_count.
>
> Consider something like:
>
> cmplw r4, r5
> lir3, -EINVAL
> bgelr
Right absolutely and got it.
Thanks again
Tiejun
> ...
>
>
> -Scott
>
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] pseries: don't override CONFIG_PPC_PSERIES_DEBUG
eeh and pci_dlpar #undef DEBUG, but I think they were added before the ability to control this from Kconfig. It's really annoying to only get some of the debug messages from these files. Leave the lpar.c #undef alone as it produces so much output as to make the kernel unusable. Update the Kconfig text to indicate this particular quirk :) Signed-off-by: Nishanth Aravamudan --- arch/powerpc/platforms/pseries/Kconfig |6 ++ arch/powerpc/platforms/pseries/eeh.c |2 -- arch/powerpc/platforms/pseries/pci_dlpar.c |2 -- 3 files changed, 6 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig index c667f0f..3139814 100644 --- a/arch/powerpc/platforms/pseries/Kconfig +++ b/arch/powerpc/platforms/pseries/Kconfig @@ -47,6 +47,12 @@ config LPARCFG config PPC_PSERIES_DEBUG depends on PPC_PSERIES && PPC_EARLY_DEBUG bool "Enable extra debug logging in platforms/pseries" +help + Say Y here if you want the pseries core to produce a bunch of + debug messages to the system log. Select this if you are having a + problem with the pseries core and want to see more of what is + going on. This does not enable debugging in lpar.c, which must + be manually done due to its verbosity. default y config PPC_SMLPAR diff --git a/arch/powerpc/platforms/pseries/eeh.c b/arch/powerpc/platforms/pseries/eeh.c index 34b7dc1..17a11c8 100644 --- a/arch/powerpc/platforms/pseries/eeh.c +++ b/arch/powerpc/platforms/pseries/eeh.c @@ -21,8 +21,6 @@ * Please address comments and feedback to Linas Vepstas */ -#undef DEBUG - #include #include #include diff --git a/arch/powerpc/platforms/pseries/pci_dlpar.c b/arch/powerpc/platforms/pseries/pci_dlpar.c index 4b7a062..5fcc92a 100644 --- a/arch/powerpc/platforms/pseries/pci_dlpar.c +++ b/arch/powerpc/platforms/pseries/pci_dlpar.c @@ -25,8 +25,6 @@ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ -#undef DEBUG - #include #include #include -- 1.7.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] ppc: don't override CONFIG_PPC_PSERIES_DEBUG
On Thu, 2010-10-14 at 17:23 -0700, Nishanth Aravamudan wrote: > On 15.10.2010 [11:14:23 +1100], Michael Ellerman wrote: > > On Thu, 2010-10-14 at 10:48 -0700, Nishanth Aravamudan wrote: > > > Because the lpar and pci_dlpar code is pretty low-level & verbose, > > > perhaps it makes sense to add another Kconfig variable for really > > > low-level stuff? But it's annoying to have DEBUG *somewhat* effective, > > > especially in the EEH area when doing PCI stuff. > > > > I really don't think you want to enable the lpar debug by default. > > Have you tried it? It can make for a pretty unusable system, just > > because of the console spam. > > Yeah, you're right. After enabling it, I had to kill my boot and start > over w/o the lpar DEBUG on. :) > I assume dlpar_pci is similar? That should be OK to enable I think. Suck it and see I guess. > I dunno, would a patch to a least remove the EEH one be ok? Seems like > it isn't super-verbose, and does have some handy output. Yeah definitely. That undef was merged as part of a cleanup/fix patch but shouldn't have been. cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: msi_bitmap.c question
On Thu, 2010-10-14 at 15:56 -0700, Tirumala Marri wrote: > Hi, > > I am trying to resubmit a patch for MSI support for ppc4xx devices. > One of the review feedback was not to use the bit map as it is only > for the devices which don’t have hard wired mapping between interrupt > controller interrupts and MSI number. For example intr-ctrl0 interrupt > 20 goes to MSI-0, interrupt 21 goes to MSI-1 ..etc. But when I checked > freescale SoCs and cell SoCs they have interrupts hard wired to MSI > interrupts. > > > > Why do they have to use the bitmap and create irqhost, even though > they are one-to-one mapped between interrupt controller numbers and > MSI ? I'm not quite sure I understand your question. The MSI bitmap and the irq_host are two different things. The MSI bitmap is basically an allocator for hardware numbers that can be used for MSI. On some interrupt controllers that might be any interrupt that's not used, on others there are restrictions on which numbers can be used for MSI, it depends. So it's possible you don't need to use that code, but I don't know how your hardware works. The irq_host is the struct that controls mapping hardware irq numbers into linux irq numbers. The cell MSI code has no restrictions on what the MSI value is, so it just uses the Linux irq number directly using irq_create_direct_mapping(). cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] ppc: don't override CONFIG_PPC_PSERIES_DEBUG
On 15.10.2010 [11:14:23 +1100], Michael Ellerman wrote: > On Thu, 2010-10-14 at 10:48 -0700, Nishanth Aravamudan wrote: > > These files undef DEBUG, but I think they were added before the ability > > to control this from Kconfig. > > Perhaps. Some people, *cough*, have a tendency to merge those back in > again from time to time :) > > > It's really annoying to only get some of the debug messages! > > True, but .. > > > Signed-off-by: Nishanth Aravamudan > > > > --- > > Because the lpar and pci_dlpar code is pretty low-level & verbose, > > perhaps it makes sense to add another Kconfig variable for really > > low-level stuff? But it's annoying to have DEBUG *somewhat* effective, > > especially in the EEH area when doing PCI stuff. > > I really don't think you want to enable the lpar debug by default. > Have you tried it? It can make for a pretty unusable system, just > because of the console spam. Yeah, you're right. After enabling it, I had to kill my boot and start over w/o the lpar DEBUG on. I assume dlpar_pci is similar? I dunno, would a patch to a least remove the EEH one be ok? Seems like it isn't super-verbose, and does have some handy output. > Also these days there is CONFIG_DYNAMIC_DEBUG which is much smarter than > all this, but requires setup at runtime. True, I started looking into it, but only realized today that eeh.c had that #undef! :) Thanks, Nish -- Nishanth Aravamudan IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] ppc: don't override CONFIG_PPC_PSERIES_DEBUG
On Thu, 2010-10-14 at 10:48 -0700, Nishanth Aravamudan wrote: > These files undef DEBUG, but I think they were added before the ability > to control this from Kconfig. Perhaps. Some people, *cough*, have a tendency to merge those back in again from time to time :) > It's really annoying to only get some of the debug messages! True, but .. > Signed-off-by: Nishanth Aravamudan > > --- > Because the lpar and pci_dlpar code is pretty low-level & verbose, > perhaps it makes sense to add another Kconfig variable for really > low-level stuff? But it's annoying to have DEBUG *somewhat* effective, > especially in the EEH area when doing PCI stuff. I really don't think you want to enable the lpar debug by default. Have you tried it? It can make for a pretty unusable system, just because of the console spam. Also these days there is CONFIG_DYNAMIC_DEBUG which is much smarter than all this, but requires setup at runtime. cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
msi_bitmap.c question
Hi, I am trying to resubmit a patch for MSI support for ppc4xx devices. One of the review feedback was not to use the bit map as it is only for the devices which don’t have hard wired mapping between interrupt controller interrupts and MSI number. For example intr-ctrl0 interrupt 20 goes to MSI-0, interrupt 21 goes to MSI-1 ..etc. But when I checked freescale SoCs and cell SoCs they have interrupts hard wired to MSI interrupts. Why do they have to use the bitmap and create irqhost, even though they are one-to-one mapped between interrupt controller numbers and MSI ? Thx, Marri ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Possible kernel stack overflow due to fast interrupts
On Thu, 2010-10-14 at 13:45 -0700, Rick Tao wrote: > Hi, all, .../... > In the context of task A > a. NIP would point to the instruction after switch_to(). > b. MSR_EE is enabled in the call trace (finish_task_switch > -->finish_lock_switch-->spin_unlock_irq) > c. do something that would trigger an interrupt later on (such as timer) > d. call schedule() for context switch to task B. >In this step, > task B's stack is popped INT_FRAME_SIZE size for context restore. >Note that task B's ksp = X - INT_FRAME_SIZE > > In the context of task B again > a1. similar to step "a" above > > b1. similar to step "b" above > c1. interrupt occurs, go to step "1" above, and repeat!!! > > As you can see, task B's kernel stack space is reduced by INT_FRAME_SIZE > on each loop. It will eventually overflow. So if I follow you correctly, you are worried that by the time execution resumes in B, and before it pops the second frame off, it might get another interrupt and re-preempt... Now unless I missed something, that cannot happen because preempt_schedule_irq() does increment the preempt count: add_preempt_count(PREEMPT_ACTIVE); local_irq_enable(); schedule(); local_irq_disable(); sub_preempt_count(PREEMPT_ACTIVE); Which means that it won't preempt again in finish_task_switch, and so will eventually come back, turn EE back off, and pop off the stack frame. Or am I missing something ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] [v2] powerpc/85xx: add DIU support to the Freecale P1022DS reference board
On Thu, Oct 14, 2010 at 01:21:33PM -0500, Timur Tabi wrote: > Mark, can you pick up this patch for us? Because it depends on > "powerpc: rename immap_86xx.h to fsl_guts.h, and add 85xx support", it > will break the build if we apply to powerpc-next. > > You can grab the patch from http://patchwork.ozlabs.org/patch/67095/ Done, but I had to fix up what looked like an add/add conflict with headers in the file. Since I was editing that area of the file anyway I also dropped the #define DEBUG as it looked like a mistake. Please send followup patch(es) correcting things if I messed up any of that. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Oops while running systemtap on the p6 machine against the kernel version 2.6.36-rc7-git3
divya writes: > While running systemtap tests on the p6 machine , against the kernel > version 2.6.36-rc7-git3 Oops occured , here are the call trace Did the oops happen during a systemtap module startup vs. operation vs. shutdown? stap -V version string? > BUG: spinlock bad magic on CPU#6, stapio/20398 > -- 0:conmux-control -- time-stamp -- Oct/13/10 2:49:18 --res > lock: c0fcfa18, .magic: , .owner:/-1, .owner_cpu: 0 > Call Trace: > [c001effbfab0] [c0011934] .show_stack+0x6c/0x16c (unreliable) > [c001effbfb60] [c02c9274] .spin_bug+0xb0/0xd4 > [c001effbfbf0] [c02c953c] .do_raw_spin_lock+0x48/0x184 > [c001effbfc90] [c054af78] ._raw_spin_lock+0x10/0x24 > [c001effbfd00] [d3015908] .__stp_time_timer_callback+0x94/0x13c > [stap_75ce6f84d34f8665c9a6b8e27fb9ea95_818798] > [...] > kernel BUG at kernel/timer.c:681! > Oops: Exception in kernel mode, sig: 5 [#1] > SMP NR_CPUS=1024 NUMA pSeries > [...] > [c001effbfc50] [c001effbfd00] 0xc001effbfd00 (unreliable) > [c001effbfd00] [d301597c] .__stp_time_timer_callback+0x108/0x13c > [stap_75ce6f84d34f8665c9a6b8e27fb9ea95_818798] > [c001effbfdc0] [c009c2f8] .run_timer_softirq+0x1d8/0x2a8 We have had occasional problems in the past with something like this: http://sourceware.org/PR10651, but it never was tracked down to a systemtap bug per se, as opposed to suspicions that the kernel was not satisfying one of its guarantees w.r.t. del_timer_sync(). - FChE ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Possible kernel stack overflow due to fast interrupts
Hi, all, I am looking at the kernel source of 2.6.32. It appears to me that kernel stack can be easily getting overflowed in case of fast interrupts. Here is my observation, any comments? Thanks, Let's assume task A triggers the fast interrupts, and task B was running when the fast interrupt occur. In the context of task B (according to entry_32.S) 0. Assume task B's ksp = X 1. the interrupt causes exception, allocate exception frame space from the task B'stack (ksp = X - INT_FRAME_SIZE). 2. interrupt handler is invoked 3. ret_from_except, and resume_kernel is invoked 4. then preempt_schedule_irq is called, which in trun, __schedule() and context_switch is called. Assume it switches to task A. In this step, task B's stack is pushed another INT_FRAME_SIZE to save its context, so task B's ksp = X - 2 * INT_FRAME_SIZE now. In the context of task A a. NIP would point to the instruction after switch_to(). b. MSR_EE is enabled in the call trace (finish_task_switch -->finish_lock_switch-->spin_unlock_irq) c. do something that would trigger an interrupt later on (such as timer) d. call schedule() for context switch to task B. In this step, task B's stack is popped INT_FRAME_SIZE size for context restore. Note that task B's ksp = X - INT_FRAME_SIZE In the context of task B again a1. similar to step "a" above b1. similar to step "b" above c1. interrupt occurs, go to step "1" above, and repeat!!! As you can see, task B's kernel stack space is reduced by INT_FRAME_SIZE on each loop. It will eventually overflow. Thanks for your input. Rick ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: fix warning when compiling immap_qe.h
Fix the warnings genereted by arch/powerpc/include/asm/immap_qe.h when
CONFIG_PHYS_ADDR_T_64BIT is defined:
immap_qe.h: In function 'immrbar_virt_to_phys':
immap_qe.h:472:8: warning: cast from pointer to integer of different size
immap_qe.h:472:24: warning: cast from pointer to integer of different size
immap_qe.h:473:5: warning: cast from pointer to integer of different size
immap_qe.h:473:21: warning: cast from pointer to integer of different size
immap_qe.h:474:36: warning: cast from pointer to integer of different size
Note that the QE does not support 36-bit physical addresses, so even when
CONFIG_PHYS_ADDR_T_64BIT is defined, the QE MURAM must be located below the
4GB boundary.
Signed-off-by: Timur Tabi
---
arch/powerpc/include/asm/immap_qe.h | 21 +++--
1 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/immap_qe.h
b/arch/powerpc/include/asm/immap_qe.h
index 4e10f50..0edb684 100644
--- a/arch/powerpc/include/asm/immap_qe.h
+++ b/arch/powerpc/include/asm/immap_qe.h
@@ -467,13 +467,22 @@ struct qe_immap {
extern struct qe_immap __iomem *qe_immr;
extern phys_addr_t get_qe_base(void);
-static inline unsigned long immrbar_virt_to_phys(void *address)
+/*
+ * Returns the offset within the QE address space of the given pointer.
+ *
+ * Note that the QE does not support 36-bit physical addresses, so if
+ * get_qe_base() returns a number above 4GB, the caller will probably fail.
+ */
+static inline phys_addr_t immrbar_virt_to_phys(void *address)
{
- if ( ((u32)address >= (u32)qe_immr) &&
- ((u32)address < ((u32)qe_immr + QE_IMMAP_SIZE)) )
- return (unsigned long)(address - (u32)qe_immr +
- (u32)get_qe_base());
- return (unsigned long)virt_to_phys(address);
+ void *q = (void *)qe_immr;
+
+ /* Is it a MURAM address? */
+ if ((address >= q) && (address < (q + QE_IMMAP_SIZE)))
+ return get_qe_base() + (address - q);
+
+ /* It's an address returned by kmalloc */
+ return virt_to_phys(address);
}
#endif /* __KERNEL__ */
--
1.7.2.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Questions on interrupt vector assignment on MPC8641D
> Well, it was a coworker who added the workaround, so I assume we're > already aware of the issue. > > The description of NIRQ is vague enough that it's hard to argue that > Linux's expectations of what it means are justified. > Well, I now can actually interrupt the PPC from my host processor! (well, it segfaulted, but's my fault for not actually initializing my work queue structure. But I can get the interrupt into the part!) So thanks to all. I hope to get my code working, get past my delivery deadline on it, clean it up so it matches The One True Way Of Laying Out Kernel Code, and post it here for everybody to point and laugh at. Maybe around Christmas. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] [v2] powerpc/85xx: add DIU support to the Freecale P1022DS reference board
Mark, can you pick up this patch for us? Because it depends on "powerpc: rename immap_86xx.h to fsl_guts.h, and add 85xx support", it will break the build if we apply to powerpc-next. You can grab the patch from http://patchwork.ozlabs.org/patch/67095/ On Thu, Oct 7, 2010 at 2:36 PM, Timur Tabi wrote: > The Freescale P1022DS has an on-chip video controller called the DIU, and a > driver for this device already exists. Update the platform file for the > P1022DS reference board to enable the driver, and update the defconfig for > Freescale MPC85xx boards to add the driver. > > Signed-off-by: Timur Tabi > --- -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] [v2] powerpc/85xx: add DIU support to the Freecale P1022DS reference board
On Oct 13, 2010, at 8:39 PM, Tabi Timur-B04825 wrote: > Kumar Gala wrote: arch/powerpc/configs/mpc85xx_defconfig |3 + arch/powerpc/configs/mpc85xx_smp_defconfig |3 + arch/powerpc/platforms/85xx/p1022_ds.c | 213 +++- 3 files changed, 217 insertions(+), 2 deletions(-) >> I dropped this because of chicken/egg issue with guts.h > > If you pull from alsa-next, it should resolve that. > > Either that, or ask the alsa guys to apply this patch instead. Can you ask the alsa guys to pick it up. I'm happy to ack. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Questions on interrupt vector assignment on MPC8641D
On Thu, 14 Oct 2010 12:20:55 -0500 wrote: > > It comes from FRR[NIRQ]. It seems that this chip takes a > > less-than-useful interpretation of what that field means -- it gives > > the actual number of sources, not the size of the sparsely populated > > array. > Perhaps you might want to have a talk with your cow-orkers there, Scott, > since this is a Freescale part. Well, it was a coworker who added the workaround, so I assume we're already aware of the issue. The description of NIRQ is vague enough that it's hard to argue that Linux's expectations of what it means are justified. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC PATCH] ppc: don't override CONFIG_PPC_PSERIES_DEBUG
These files undef DEBUG, but I think they were added before the ability to control this from Kconfig. It's really annoying to only get some of the debug messages! Signed-off-by: Nishanth Aravamudan --- Because the lpar and pci_dlpar code is pretty low-level & verbose, perhaps it makes sense to add another Kconfig variable for really low-level stuff? But it's annoying to have DEBUG *somewhat* effective, especially in the EEH area when doing PCI stuff. --- arch/powerpc/platforms/pseries/eeh.c |2 -- arch/powerpc/platforms/pseries/lpar.c |3 --- arch/powerpc/platforms/pseries/pci_dlpar.c |2 -- 3 files changed, 0 insertions(+), 7 deletions(-) diff --git a/arch/powerpc/platforms/pseries/eeh.c b/arch/powerpc/platforms/pseries/eeh.c index 34b7dc1..17a11c8 100644 --- a/arch/powerpc/platforms/pseries/eeh.c +++ b/arch/powerpc/platforms/pseries/eeh.c @@ -21,8 +21,6 @@ * Please address comments and feedback to Linas Vepstas */ -#undef DEBUG - #include #include #include diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c index cf79b46..4b31a66 100644 --- a/arch/powerpc/platforms/pseries/lpar.c +++ b/arch/powerpc/platforms/pseries/lpar.c @@ -19,9 +19,6 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ -/* Enables debugging of low-level hash table routines - careful! */ -#undef DEBUG - #include #include #include diff --git a/arch/powerpc/platforms/pseries/pci_dlpar.c b/arch/powerpc/platforms/pseries/pci_dlpar.c index 4b7a062..5fcc92a 100644 --- a/arch/powerpc/platforms/pseries/pci_dlpar.c +++ b/arch/powerpc/platforms/pseries/pci_dlpar.c @@ -25,8 +25,6 @@ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ -#undef DEBUG - #include #include #include -- 1.7.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Questions on interrupt vector assignment on MPC8641D
Hallelujah and Huzzah! I finally got my vector! I back-ported the MPIC_BROKEN_FRR_NIRQS flag and code to our kernel, and the kernel is now letting me have my vector! Now I can actually see if the dang thing works! THANK YOU EVERYBODY for putting up with me on this! > It comes from FRR[NIRQ]. It seems that this chip takes a > less-than-useful interpretation of what that field means -- it gives > the actual number of sources, not the size of the sparsely populated > array. Perhaps you might want to have a talk with your cow-orkers there, Scott, since this is a Freescale part. > It's not very clear to me what distinction the MPIC code is > trying to make between irq_count and num_sources in the first place, > though. /me looks at Scott's email again. If you, working FOR Freescale, and following the Linux development (presumably for some time) are confused, imagine what I've been going through! Hot damn, and time for a quick version control commit, a hot lunch, and really testing the code. Thanks again! ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Questions on interrupt vector assignment on MPC8641D
On Thu, 14 Oct 2010 11:22:45 -0500 wrote: > As I read the code: > /* Read feature register, calculate num CPUs and, for non-ISU >* MPICs, num sources as well. On ISU MPICs, sources are counted >* as ISUs are added >*/ > greg_feature = mpic_read(mpic->gregs, MPIC_INFO(GREG_FEATURE_0)); > mpic->num_cpus = ((greg_feature & MPIC_GREG_FEATURE_LAST_CPU_MASK) > >> MPIC_GREG_FEATURE_LAST_CPU_SHIFT) + 1; > if (isu_size == 0) > mpic->num_sources = > ((greg_feature & MPIC_GREG_FEATURE_LAST_SRC_MASK) >>> MPIC_GREG_FEATURE_LAST_SRC_SHIFT) + 1; > So it would seem to me that the "greg_feature" is saying I have 88 > interrupts. > > I've tried setting the ISU size to 256: > mpic1 = mpic_alloc(np, res.start, > MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN , > 256, 256, > " MPIC "); > And that kills the kernel as we init the mpic. > > SO, I guess the question in, what sets "greg_feature", as it would seem to > be incorrect. It comes from FRR[NIRQ]. It seems that this chip takes a less-than-useful interpretation of what that field means -- it gives the actual number of sources, not the size of the sparsely populated array. If you look at current kernels, you'll find an MPIC_BROKEN_FRR_NIRQS flag to work around this. It's not very clear to me what distinction the MPIC code is trying to make between irq_count and num_sources in the first place, though. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3 v4] P4080/mtd: Only make elbc nand driver detect nand flash partitions
On Wed, 13 Oct 2010 20:09:02 -0700 "Zang Roy-R61911" wrote: > > > > > + struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = NULL; > > > > > > > > No need for = NULL. > > > Any harm? Or just personal habit or style? Can you explain about > why? > > > > Besides not wanting superfluous code on general principle, it could > > hide a bug if in the future the real initialization is missing on some > > code path. It would become a runtime NULL dereference rather than a > > compiler warning. > > Not exactly. > Per my understand, if the pointer will definitely be assigned in code > path, > it is not necessary to init it when define. for example, > > char c; > char b; > char *a; > if (condition) > a = &c; > else > a = &b; > ... > > for other case, if the path will not ensure the pointer assignment, it > will be inited > when define to avoid warning. for example, > > char c; > char *a = NULL; > if (condition) > a = &c; > ... Yes, but this patch looks like the former case, not the latter. Is GCC giving a warning without the initializer? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Questions on interrupt vector assignment on MPC8641D
I may have a clue (you might not think so, but...): I've configured the init thusly: mpic1 = mpic_alloc(np, res.start, MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN , 0, 256, " MPIC "); Which, as I read the code, should disable the ISU stuff. I've seeing this on boot: mpic: Setting up MPIC " MPIC " version 1.2 at e004, max 2 CPUs mpic: ISU size: 88, shift: 7, mask: 7f mpic: Initializing for 88 sources Now, since the interrupt number I want is 224, which, last time I checked, was > 88, this may be the root cause. As I read the code: /* Read feature register, calculate num CPUs and, for non-ISU * MPICs, num sources as well. On ISU MPICs, sources are counted * as ISUs are added */ greg_feature = mpic_read(mpic->gregs, MPIC_INFO(GREG_FEATURE_0)); mpic->num_cpus = ((greg_feature & MPIC_GREG_FEATURE_LAST_CPU_MASK) >> MPIC_GREG_FEATURE_LAST_CPU_SHIFT) + 1; if (isu_size == 0) mpic->num_sources = ((greg_feature & MPIC_GREG_FEATURE_LAST_SRC_MASK) >> MPIC_GREG_FEATURE_LAST_SRC_SHIFT) + 1; So it would seem to me that the "greg_feature" is saying I have 88 interrupts. I've tried setting the ISU size to 256: mpic1 = mpic_alloc(np, res.start, MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN , 256, 256, " MPIC "); And that kills the kernel as we init the mpic. SO, I guess the question in, what sets "greg_feature", as it would seem to be incorrect. Or, am I on the wrong trail? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3 v4] P4080/eLBC: Make Freescale elbc interrupt common to elbc devices
On Wed, 13 Oct 2010 23:43:38 -0700 "Zang Roy-R61911" wrote: > > Plus, I think the patch is not runtime bisectable (i.e. you > > now do request_irq() here, but not removing it from the nand > > driver, so nand will fail to probe). > Nand driver does not need to request irq. It will use the irq requested by > lbc. > remember, other lbc device may also need to use this registered irq. > It should not be removed in nand driver. The point is that you need to make both changes in the same patch. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Questions on interrupt vector assignment on MPC8641D
On Thu, 14 Oct 2010 11:27:09 +0800
"tiejun.chen" wrote:
> tiejun.chen wrote:
> > Scott Wood wrote:
> >> On Wed, 13 Oct 2010 09:17:01 +0800
> >> "tiejun.chen" wrote:
> >>
> >>> Scott Wood wrote:
> The crash is happening somewhere in mpic_set_irq_type():
> >>> Agreed. That is just where I pointed out on my email replied for OOPS. To
> >>> enable
> >>> DBG to figure out 'src' and 'mpic->irq_count' from the file,
> >>> arch/powerpc/sysdev/mpic.c,.
> >>> ==
> >>> int mpic_set_irq_type(unsigned int virq, unsigned int flow_type)
> >>> {
> >>> ..
> >>> if (src >= mpic->irq_count)
> >>> return -EINVAL;
> >>> ^
> >>> I think this OOPS may be from here.
> >> No, it's after that. His board code is using the mpic's "isu" remapping
> >
> > I means OOPS is *from* here. According to David's call trace,
> > mpic_set_irq_type() is the last issued function. And that corresponding
> > return
> > value, R3, is '0xffea', -22, and also '-EINVAL'.
Just because that value is in r3 doesn't mean that src >=
mpic->irq_count.
Consider something like:
cmplw r4, r5
li r3, -EINVAL
bgelr
...
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/5121: pdm360ng: fix touch irq if 8xxx gpio driver is enabled
Hi Grant, On Wed, 15 Sep 2010 22:12:57 +0200 Anatolij Gustschin wrote: > Enabling the MPC8xxx GPIO driver with MPC512x GPIO extension > breaks touch screen support on this board since the GPIO > interrupt will be mapped to 8xxx GPIO irq host resulting in > a not requestable interrupt in the touch screen driver. Fix > it by mapping the touch interrupt on 8xxx GPIO irq host. > > Signed-off-by: Anatolij Gustschin > --- > arch/powerpc/platforms/512x/pdm360ng.c | 26 ++ > 1 files changed, 22 insertions(+), 4 deletions(-) Can this patch go in for 2.6.37 ? Thanks, Anatolij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
eSDHC controller driver on MPC8308rdb
Hello,
(apologies for writing such a long e-mail, hope you can bother to read it all ☺
)
I have some difficulties with the eSDHC controller driver used on a MPC8308
evaluation board with kernel 2.6.36-rc7, and hope that some of you may be able
to help me with the debugging.
The driver is loaded properly, and binds to the eSDHC controller without
problems. When inserting a sd-card it is bound to the mmcblk-driver, so no
problems there either.
However, I am not able to read nor write to the card, I have attached output
with error messages below:
**
mmc0: new SDHC card at address 9155
mmcblk0: mmc0:9155 SD04G 3.69 GiB
mmc0: Too large timeout requested!
mmcblk0: retrying using single block read
mmc0: Too large timeout requested!
mmcblk0: error -84 sending status comand
mmcblk0: error -110 sending read/write command, response 0x0, card status 0x0
end_request: I/O error, dev mmcblk0, sector 0
mmc0: Too large timeout requested!
mmcblk0: error -84 sending status comand
mmcblk0: error -110 sending read/write command, response 0x0, card status 0x0
end_request: I/O error, dev mmcblk0, sector 1
…..
Debug output with no SD-card:
**
mmc0: clock 0Hz busmode 1 powermode 1 cs 0 Vdd 20 width 0 timing 0
mmc0: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0
of:sdhci-of e002e000.sdhci: desired SD clock: 40, actual: 0
mmc0: starting CMD52 arg 0c00 flags 0195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00010001
mmc0: req done (CMD52): -110:
mmc0: starting CMD52 arg 8c08 flags 0195
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00010001
mmc0: req done (CMD52): -110:
mmc0: clock 40Hz busmode 1 powermode 2 cs 1 Vdd 20 width 0 timing 0
mmc0: starting CMD0 arg flags 00c0
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x0001
mmc0: req done (CMD0): 0:
mmc0: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0
mmc0: starting CMD8 arg 01aa flags 02f5
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00010001
mmc0: req done (CMD8): -110:
mmc0: starting CMD5 arg flags 02e1
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00010001
mmc0: req failed (CMD5): -110, retrying...
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00010001
mmc0: req failed (CMD5): -110, retrying...
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00010001
mmc0: req failed (CMD5): -110, retrying...
…
I have the following in my dts:
sd...@2e000 {
compatible = "fsl,mpc8308-esdhc", "fsl,esdhc";
reg = <0x2e000 0x1000>;
interrupts = <42 0x8>;
interrupt-parent = <&ipic>;
clock-frequency = <0>;
};
Could this be a problem related the eSDHC controller (or the driver), or is it
the memory card? (a 4GB SanDisk Extreme SDHC card, which unfortunately is the
only card I have available at the moment.)
I will keep digging into drivers/mmc/host/sdhci.c in search of a solution, and
any tips to how I should proceed would be greatly appreciated!
--
Maria
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] spi/fsl_spi: Fix compile errors when building on ppc64
On Thu, Oct 14, 2010 at 08:55:47AM -0500, Kumar Gala wrote:
> We get the following when building on ppc64 due to lack of include of
> :
Applied.
g.
>
> In file included from drivers/spi/spi_fsl_espi.c:25:0:
> drivers/spi/spi_fsl_lib.h: In function 'mpc8xxx_spi_write_reg':
> drivers/spi/spi_fsl_lib.h:88:2: error: implicit declaration of function
> 'out_be32'
> drivers/spi/spi_fsl_lib.h: In function 'mpc8xxx_spi_read_reg':
> drivers/spi/spi_fsl_lib.h:93:2: error: implicit declaration of function
> 'in_be32'
> drivers/spi/spi_fsl_espi.c: In function 'fsl_espi_remove':
> drivers/spi/spi_fsl_espi.c:571:2: error: implicit declaration of function
> 'iounmap'
> drivers/spi/spi_fsl_espi.c: In function 'fsl_espi_probe':
> drivers/spi/spi_fsl_espi.c:602:2: error: implicit declaration of function
> 'ioremap'
> drivers/spi/spi_fsl_espi.c:602:24: warning: assignment makes pointer from
> integer without a cast
>
> Signed-off-by: Kumar Gala
> ---
> drivers/spi/spi_fsl_lib.h |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/spi/spi_fsl_lib.h b/drivers/spi/spi_fsl_lib.h
> index 15aa6c2..281e060 100644
> --- a/drivers/spi/spi_fsl_lib.h
> +++ b/drivers/spi/spi_fsl_lib.h
> @@ -18,6 +18,8 @@
> #ifndef __SPI_FSL_LIB_H__
> #define __SPI_FSL_LIB_H__
>
> +#include
> +
> /* SPI/eSPI Controller driver's private data. */
> struct mpc8xxx_spi {
> struct device *dev;
> --
> 1.7.2.3
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] spi/fsl_spi: Fix compile errors when building on ppc64
On Oct 14, 2010, at 9:12 AM, Grant Likely wrote: > On Thu, Oct 14, 2010 at 08:55:47AM -0500, Kumar Gala wrote: >> We get the following when building on ppc64 due to lack of include of >> : > > Is this an immediate problem (merge for .36), or is it a linux-next thing? > > g. .37 / next is fine. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] spi/fsl_spi: Fix compile errors when building on ppc64
On Thu, Oct 14, 2010 at 08:55:47AM -0500, Kumar Gala wrote:
> We get the following when building on ppc64 due to lack of include of
> :
Is this an immediate problem (merge for .36), or is it a linux-next thing?
g.
>
> In file included from drivers/spi/spi_fsl_espi.c:25:0:
> drivers/spi/spi_fsl_lib.h: In function 'mpc8xxx_spi_write_reg':
> drivers/spi/spi_fsl_lib.h:88:2: error: implicit declaration of function
> 'out_be32'
> drivers/spi/spi_fsl_lib.h: In function 'mpc8xxx_spi_read_reg':
> drivers/spi/spi_fsl_lib.h:93:2: error: implicit declaration of function
> 'in_be32'
> drivers/spi/spi_fsl_espi.c: In function 'fsl_espi_remove':
> drivers/spi/spi_fsl_espi.c:571:2: error: implicit declaration of function
> 'iounmap'
> drivers/spi/spi_fsl_espi.c: In function 'fsl_espi_probe':
> drivers/spi/spi_fsl_espi.c:602:2: error: implicit declaration of function
> 'ioremap'
> drivers/spi/spi_fsl_espi.c:602:24: warning: assignment makes pointer from
> integer without a cast
>
> Signed-off-by: Kumar Gala
> ---
> drivers/spi/spi_fsl_lib.h |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/spi/spi_fsl_lib.h b/drivers/spi/spi_fsl_lib.h
> index 15aa6c2..281e060 100644
> --- a/drivers/spi/spi_fsl_lib.h
> +++ b/drivers/spi/spi_fsl_lib.h
> @@ -18,6 +18,8 @@
> #ifndef __SPI_FSL_LIB_H__
> #define __SPI_FSL_LIB_H__
>
> +#include
> +
> /* SPI/eSPI Controller driver's private data. */
> struct mpc8xxx_spi {
> struct device *dev;
> --
> 1.7.2.3
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RTC rtc-cmos.c : Fix warning on PowerPC
>From 8435e5876fc3d629406c63b85bff82c25fc4bf75 Mon Sep 17 00:00:00 2001 From: Srikanth Krishnakar Date: Fri, 8 Oct 2010 18:07:06 +0530 Subject: [PATCH] RTC: rtc-cmos.c: Fix warning on PowerPC The following warning is seen while compilation of PowerPC kernel: CC drivers/rtc/rtc-cmos.o drivers/rtc/rtc-cmos.c:697:2: warning: #warning Assuming 128 bytes of RTC+NVRAM address space, not 64 bytes. Fix it by adding defined(__powerpc__). Signed-off-by: Srikanth Krishnakar --- drivers/rtc/rtc-cmos.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c index 5856167..7e6ce62 100644 --- a/drivers/rtc/rtc-cmos.c +++ b/drivers/rtc/rtc-cmos.c @@ -687,7 +687,8 @@ cmos_do_probe(struct device *dev, struct resource *ports, int rtc_irq) #ifdefined(CONFIG_ATARI) address_space = 64; #elif defined(__i386__) || defined(__x86_64__) || defined(__arm__) \ - || defined(__sparc__) || defined(__mips__) + || defined(__sparc__) || defined(__mips__) \ + || defined(__powerpc__) address_space = 128; #else #warning Assuming 128 bytes of RTC+NVRAM address space, not 64 bytes. -- 1.6.3.3.333.gdf68 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] spi/fsl_spi: Fix compile errors when building on ppc64
We get the following when building on ppc64 due to lack of include of
:
In file included from drivers/spi/spi_fsl_espi.c:25:0:
drivers/spi/spi_fsl_lib.h: In function 'mpc8xxx_spi_write_reg':
drivers/spi/spi_fsl_lib.h:88:2: error: implicit declaration of function
'out_be32'
drivers/spi/spi_fsl_lib.h: In function 'mpc8xxx_spi_read_reg':
drivers/spi/spi_fsl_lib.h:93:2: error: implicit declaration of function
'in_be32'
drivers/spi/spi_fsl_espi.c: In function 'fsl_espi_remove':
drivers/spi/spi_fsl_espi.c:571:2: error: implicit declaration of function
'iounmap'
drivers/spi/spi_fsl_espi.c: In function 'fsl_espi_probe':
drivers/spi/spi_fsl_espi.c:602:2: error: implicit declaration of function
'ioremap'
drivers/spi/spi_fsl_espi.c:602:24: warning: assignment makes pointer from
integer without a cast
Signed-off-by: Kumar Gala
---
drivers/spi/spi_fsl_lib.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/spi_fsl_lib.h b/drivers/spi/spi_fsl_lib.h
index 15aa6c2..281e060 100644
--- a/drivers/spi/spi_fsl_lib.h
+++ b/drivers/spi/spi_fsl_lib.h
@@ -18,6 +18,8 @@
#ifndef __SPI_FSL_LIB_H__
#define __SPI_FSL_LIB_H__
+#include
+
/* SPI/eSPI Controller driver's private data. */
struct mpc8xxx_spi {
struct device *dev;
--
1.7.2.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/fsl-booke: Add e500mc smp defconfig
On Thu, Oct 14, 2010 at 8:25 AM, Kumar Gala wrote: > +CONFIG_MATH_EMULATION=y Don't these chips have hardware FP? > +CONFIG_E1000=y > +CONFIG_E1000E=y Are you sure you want these on by default? We may use the E1000 cards in-house, but I don't know if our customers do. > +CONFIG_MSDOS_FS=m > +CONFIG_VFAT_FS=y > +CONFIG_NTFS_FS=y These should probably be off as well. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/fsl-booke: Add e500mc smp defconfig
The p4080, p3041, and p5020 (32-bit) SoCs from Freescale use the e500mc defconfig. There are enough minor differences between these SoCs and the existing P1xxx/P2xxx and MPC85xx SoCs to warrant a new defconfig. The biggest of those is the cachline size being different which we handle at compile time. Signed-off-by: Kumar Gala --- arch/powerpc/configs/e500mc_smp_defconfig | 178 + 1 files changed, 178 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/configs/e500mc_smp_defconfig diff --git a/arch/powerpc/configs/e500mc_smp_defconfig b/arch/powerpc/configs/e500mc_smp_defconfig new file mode 100644 index 000..39b5871 --- /dev/null +++ b/arch/powerpc/configs/e500mc_smp_defconfig @@ -0,0 +1,178 @@ +CONFIG_PPC_85xx=y +CONFIG_SMP=y +CONFIG_NR_CPUS=8 +CONFIG_EXPERIMENTAL=y +CONFIG_SYSVIPC=y +CONFIG_POSIX_MQUEUE=y +CONFIG_BSD_PROCESS_ACCT=y +CONFIG_AUDIT=y +CONFIG_RCU_TRACE=y +CONFIG_IKCONFIG=y +CONFIG_IKCONFIG_PROC=y +CONFIG_LOG_BUF_SHIFT=14 +CONFIG_BLK_DEV_INITRD=y +# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set +CONFIG_EMBEDDED=y +CONFIG_KALLSYMS_ALL=y +CONFIG_KALLSYMS_EXTRA_PASS=y +CONFIG_PERF_EVENTS=y +CONFIG_SLAB=y +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +CONFIG_MODULE_FORCE_UNLOAD=y +CONFIG_MODVERSIONS=y +# CONFIG_BLK_DEV_BSG is not set +CONFIG_P3041_DS=y +CONFIG_P4080_DS=y +CONFIG_P5020_DS=y +CONFIG_HIGHMEM=y +CONFIG_NO_HZ=y +CONFIG_HIGH_RES_TIMERS=y +CONFIG_BINFMT_MISC=m +CONFIG_MATH_EMULATION=y +CONFIG_SPARSE_IRQ=y +CONFIG_PCI=y +CONFIG_PCIEPORTBUS=y +# CONFIG_PCIEASPM is not set +CONFIG_NET=y +CONFIG_PACKET=y +CONFIG_UNIX=y +CONFIG_XFRM_USER=y +CONFIG_XFRM_SUB_POLICY=y +CONFIG_XFRM_STATISTICS=y +CONFIG_NET_KEY=y +CONFIG_NET_KEY_MIGRATE=y +CONFIG_INET=y +CONFIG_IP_MULTICAST=y +CONFIG_IP_ADVANCED_ROUTER=y +CONFIG_IP_MULTIPLE_TABLES=y +CONFIG_IP_ROUTE_MULTIPATH=y +CONFIG_IP_ROUTE_VERBOSE=y +CONFIG_IP_PNP=y +CONFIG_IP_PNP_DHCP=y +CONFIG_IP_PNP_BOOTP=y +CONFIG_IP_PNP_RARP=y +CONFIG_NET_IPIP=y +CONFIG_NET_IPGRE=y +CONFIG_NET_IPGRE_BROADCAST=y +CONFIG_IP_MROUTE=y +CONFIG_IP_PIMSM_V1=y +CONFIG_IP_PIMSM_V2=y +CONFIG_ARPD=y +CONFIG_INET_AH=y +CONFIG_INET_ESP=y +CONFIG_INET_IPCOMP=y +# CONFIG_INET_LRO is not set +CONFIG_IPV6=y +CONFIG_IP_SCTP=m +CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" +CONFIG_MTD=y +CONFIG_MTD_CONCAT=y +CONFIG_MTD_PARTITIONS=y +CONFIG_MTD_CMDLINE_PARTS=y +CONFIG_MTD_OF_PARTS=y +CONFIG_MTD_CHAR=y +CONFIG_MTD_BLOCK=y +CONFIG_MTD_CFI=y +CONFIG_MTD_CFI_AMDSTD=y +CONFIG_MTD_PHYSMAP_OF=y +CONFIG_MTD_M25P80=y +CONFIG_PROC_DEVICETREE=y +CONFIG_BLK_DEV_LOOP=y +CONFIG_BLK_DEV_NBD=y +CONFIG_BLK_DEV_RAM=y +CONFIG_BLK_DEV_RAM_SIZE=131072 +CONFIG_BLK_DEV_SD=y +CONFIG_CHR_DEV_ST=y +CONFIG_BLK_DEV_SR=y +CONFIG_CHR_DEV_SG=y +CONFIG_SCSI_MULTI_LUN=y +CONFIG_SCSI_LOGGING=y +CONFIG_SCSI_SYM53C8XX_2=y +CONFIG_ATA=y +CONFIG_SATA_AHCI=y +CONFIG_SATA_SIL24=y +CONFIG_SATA_SIL=y +CONFIG_PATA_SIL680=y +CONFIG_NETDEVICES=y +CONFIG_VITESSE_PHY=y +CONFIG_FIXED_PHY=y +CONFIG_NET_ETHERNET=y +CONFIG_E1000=y +CONFIG_E1000E=y +CONFIG_FSL_PQ_MDIO=y +# CONFIG_INPUT_MOUSEDEV is not set +# CONFIG_INPUT_KEYBOARD is not set +# CONFIG_INPUT_MOUSE is not set +CONFIG_SERIO_LIBPS2=y +CONFIG_SERIAL_8250=y +CONFIG_SERIAL_8250_CONSOLE=y +CONFIG_SERIAL_8250_EXTENDED=y +CONFIG_SERIAL_8250_MANY_PORTS=y +CONFIG_SERIAL_8250_DETECT_IRQ=y +CONFIG_SERIAL_8250_RSA=y +# CONFIG_LEGACY_PTYS is not set +CONFIG_HW_RANDOM=y +CONFIG_NVRAM=y +CONFIG_I2C=y +CONFIG_I2C_MPC=y +CONFIG_SPI=y +CONFIG_SPI_GPIO=y +# CONFIG_HWMON is not set +CONFIG_VIDEO_OUTPUT_CONTROL=y +CONFIG_USB_HID=m +CONFIG_USB=y +CONFIG_USB_DEVICEFS=y +CONFIG_USB_MON=y +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_EHCI_FSL=y +CONFIG_USB_OHCI_HCD=y +CONFIG_USB_OHCI_HCD_PPC_OF_BE=y +CONFIG_USB_OHCI_HCD_PPC_OF_LE=y +CONFIG_USB_STORAGE=y +CONFIG_MMC=y +CONFIG_MMC_SDHCI=y +CONFIG_MMC_SDHCI_OF=y +CONFIG_MMC_SDHCI_OF_ESDHC=y +CONFIG_EDAC=y +CONFIG_EDAC_MM_EDAC=y +CONFIG_EDAC_MPC85XX=y +CONFIG_RTC_CLASS=y +CONFIG_RTC_DRV_DS3232=y +CONFIG_RTC_DRV_CMOS=y +CONFIG_EXT2_FS=y +CONFIG_EXT3_FS=y +# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set +CONFIG_ISO9660_FS=m +CONFIG_JOLIET=y +CONFIG_ZISOFS=y +CONFIG_UDF_FS=m +CONFIG_MSDOS_FS=m +CONFIG_VFAT_FS=y +CONFIG_NTFS_FS=y +CONFIG_PROC_KCORE=y +CONFIG_TMPFS=y +CONFIG_JFFS2_FS=y +CONFIG_CRAMFS=y +CONFIG_NFS_FS=y +CONFIG_NFS_V3=y +CONFIG_NFS_V4=y +CONFIG_ROOT_NFS=y +CONFIG_NFSD=m +CONFIG_PARTITION_ADVANCED=y +CONFIG_MAC_PARTITION=y +CONFIG_NLS_ISO8859_1=y +CONFIG_NLS_UTF8=m +CONFIG_MAGIC_SYSRQ=y +CONFIG_DEBUG_KERNEL=y +CONFIG_DEBUG_SHIRQ=y +CONFIG_DETECT_HUNG_TASK=y +CONFIG_DEBUG_INFO=y +CONFIG_SYSCTL_SYSCALL_CHECK=y +CONFIG_CRYPTO_NULL=y +CONFIG_CRYPTO_PCBC=m +CONFIG_CRYPTO_MD4=y +CONFIG_CRYPTO_SHA256=y +CONFIG_CRYPTO_SHA512=y +CONFIG_CRYPTO_AES=y +# CONFIG_CRYPTO_ANSI_CPRNG is not set -- 1.7.2.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Oops while running systemtap on the p6 machine against the kernel version 2.6.36-rc7-git3
While running systemtap tests on the p6 machine , against the kernel version 2.6.36-rc7-git3 Oops occured , here are the call trace BUG: spinlock bad magic on CPU#6, stapio/20398 -- 0:conmux-control -- time-stamp -- Oct/13/10 2:49:18 --res lock: c0fcfa18, .magic: , .owner:/-1, .owner_cpu: 0 Call Trace: [c001effbfab0] [c0011934] .show_stack+0x6c/0x16c (unreliable) [c001effbfb60] [c02c9274] .spin_bug+0xb0/0xd4 [c001effbfbf0] [c02c953c] .do_raw_spin_lock+0x48/0x184 [c001effbfc90] [c054af78] ._raw_spin_lock+0x10/0x24 [c001effbfd00] [d3015908] .__stp_time_timer_callback+0x94/0x13c [stap_75ce6f84d34f8665c9a6b8e27fb9ea95_818798] [c001effbfdc0] [c009c2f8] .run_timer_softirq+0x1d8/0x2a8 [c001effbfec0] [c00952d0] .__do_softirq+0xe4/0x1b4 [c001effbff90] [c002a7a8] .call_do_softirq+0x14/0x24 [c0010af1f560] [c000dde4] .do_softirq+0x88/0xf0 [c0010af1f600] [c0095030] .irq_exit+0x50/0xac [c0010af1f680] [c0027660] .timer_interrupt+0x110/0x13c [c0010af1f710] [c0003718] decrementer_common+0x118/0x180 --- Exception: 901 at .smp_call_function_many+0x284/0x2d0 LR = .smp_call_function_many+0x268/0x2d0 [c0010af1fae0] [c00c55c4] .smp_call_function+0x3c/0x54 [c0010af1fb60] [c0094cdc] .on_each_cpu+0x24/0x84 [c0010af1fc00] [d3016738] ._stp_ctl_write_cmd+0x3b0/0x9c8 [stap_75ce6f84d34f8665c9a6b8e27fb9ea95_818798] [c0010af1fce0] [c01585f4] .vfs_write+0xd0/0x1b8 [c0010af1fd80] [c01587e4] .SyS_write+0x58/0xa0 [c0010af1fe30] [c00085b4] syscall_exit+0x0/0x40 [ cut here ] kernel BUG at kernel/timer.c:681! Oops: Exception in kernel mode, sig: 5 [#1] SMP NR_CPUS=1024 NUMA pSeries last sysfs file: /sys/module/stap_75ce6f84d34f8665c9a6b8e27fb9ea95_818798/sections/__param Modules linked in: stap_75ce6f84d34f8665c9a6b8e27fb9ea95_818798 ipv6 fuse loop dm_mod ibmveth sg sr_mod cdrom sd_mod crc_t10dif ibmvscsic scsi_transport_srp scsi_tgt scsi_mod [last unloaded: stap_75ce6f84d34f8665c9a6b8e27fb9ea95_818798] NIP: c009d090 LR: d301597c CTR: c009cfb0 REGS: c001effbf9d0 TRAP: 0700 Not tainted (2.6.36-rc7-git3-autotest) MSR: 80029032 CR: 28000482 XER: 0002 TASK = c00103422410[20398] 'stapio' THREAD: c0010af1c000 CPU: 6 GPR00: 0001 c001effbfc50 c0a31660 c0fcfa48 GPR04: 0001c8da 0070 0002 GPR08: c0ac7bf8 0006 c009cfb0 GPR12: d3017090 cf600f00 10008fd8 10008ff8 GPR16: c0a91180 0001 GPR20: c0010edb9030 c0010edb9430 c0010edb9830 c0010edb9c30 GPR24: 0001 001167a5b590dc41 c0fcfa18 0001c8da GPR28: c0fcfa48 d301597c c09a6470 0001c8da NIP [c009d090] .mod_timer+0xe0/0x24c LR [d301597c] .__stp_time_timer_callback+0x108/0x13c [stap_75ce6f84d34f8665c9a6b8e27fb9ea95_818798] Call Trace: [c001effbfc50] [c001effbfd00] 0xc001effbfd00 (unreliable) [c001effbfd00] [d301597c] .__stp_time_timer_callback+0x108/0x13c [stap_75ce6f84d34f8665c9a6b8e27fb9ea95_818798] [c001effbfdc0] [c009c2f8] .run_timer_softirq+0x1d8/0x2a8 [c001effbfec0] [c00952d0] .__do_softirq+0xe4/0x1b4 [c001effbff90] [c002a7a8] .call_do_softirq+0x14/0x24 [c0010af1f560] [c000dde4] .do_softirq+0x88/0xf0 [c0010af1f600] [c0095030] .irq_exit+0x50/0xac [c0010af1f680] [c0027660] .timer_interrupt+0x110/0x13c [c0010af1f710] [c0003718] decrementer_common+0x118/0x180 --- Exception: 901 at .smp_call_function_many+0x284/0x2d0 LR = .smp_call_function_many+0x268/0x2d0 [c0010af1fae0] [c00c55c4] .smp_call_function+0x3c/0x54 [c0010af1fb60] [c0094cdc] .on_each_cpu+0x24/0x84 [c0010af1fc00] [d3016738] ._stp_ctl_write_cmd+0x3b0/0x9c8 [stap_75ce6f84d34f8665c9a6b8e27fb9ea95_818798] [c0010af1fce0] [c01585f4] .vfs_write+0xd0/0x1b8 [c0010af1fd80] [c01587e4] .SyS_write+0x58/0xa0 [c0010af1fe30] [c00085b4] syscall_exit+0x0/0x40 Instruction dump: 7ffb4878 f9210070 e93e8078 8009 2f80 419e0010 7fa4eb78 7f83e378 4bfffcb1 e81c0020 7c74 7800d182<0b00> 7f83e378 38810070 3b40 Kernel panic - not syncing: Fatal exception in interrupt Call Trace: [c001effbf5b0] [c0011934] .show_stack+0x6c/0x16c (unreliable) [c001effbf660] [c0552094] .panic+0x9c/0x204 [c001effbf700] [c0028974] .die+0x268/0x2ac [c001effbf7a0] [c0028ca8] ._exception+0x88/0x174 [c001effbf960] [c0004f8c] program_check_common+0x10c/0x180 --- Exception: 700 at .mod_timer+0xe0/0x24c LR = .__stp_time_timer_callb
Re: [PATCH 2/3] fsl_rio: fix non-standard HID1 register access
On Oct 14, 2010, at 2:10 AM, Li Yang-R58472 wrote: >> Subject: Re: [PATCH 2/3] fsl_rio: fix non-standard HID1 register access >> >> >> On Oct 13, 2010, at 9:04 PM, Shaohui Xie wrote: >> >>> From: Li Yang >>> >>> The access to HID1 register is only legitimate for e500 v1/v2 cores. >>> Also fixes magic number. >>> >>> Signed-off-by: Li Yang >>> Signed-off-by: Shaohui Xie >>> --- >>> arch/powerpc/sysdev/fsl_rio.c |9 ++--- >>> 1 files changed, 6 insertions(+), 3 deletions(-) >>> >>> diff --git a/arch/powerpc/sysdev/fsl_rio.c >>> b/arch/powerpc/sysdev/fsl_rio.c index 4127636..dfff3b7 100644 >>> --- a/arch/powerpc/sysdev/fsl_rio.c >>> +++ b/arch/powerpc/sysdev/fsl_rio.c >>> @@ -1537,9 +1537,12 @@ int fsl_rio_setup(struct platform_device *dev) >>> #ifdef CONFIG_E500 >>> saved_mcheck_exception = ppc_md.machine_check_exception; >>> ppc_md.machine_check_exception = fsl_rio_mcheck_exception; -#endif >>> - /* Ensure that RFXE is set */ >>> - mtspr(SPRN_HID1, (mfspr(SPRN_HID1) | 0x2)); >>> + >>> +#ifndef CONFIG_PPC_E500MC >>> + /* Ensure that RFXE is set on e500 v1/v2 */ >>> + mtspr(SPRN_HID1, (mfspr(SPRN_HID1) | HID1_RFXE)); #endif /* >>> +!PPC_E500MC */ #endif /* E500 */ >> >> I've never really been happy with this code. We really should set >> HID1_RFXE in cpu_setup_fsl_booke.S instead. > > But this bit is not recommended to be set unless necessary. And it is only > required by SRIO for now. Than wrap it in a CONFIG_RAPIDIO in cpu_setup_fsl_booke.S - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Please pull 'next' branch of 4xx tree
On Thu, Oct 14, 2010 at 11:56:15AM +1100, Benjamin Herrenschmidt wrote: >On Wed, 2010-10-13 at 09:16 -0400, Josh Boyer wrote: >> On Tue, Sep 28, 2010 at 09:09:41AM -0400, Josh Boyer wrote: >> >Hi Ben, >> > >> >A few small updates for the next branch. A new board/SoC from AMCC, and >> >some 476 changes from Shaggy. Please pull. >> >> OK, below is a fixed up tree that drops the patch Shaggy said was >> broken, and rebases on top of your new -next branch. Please pull. > >please, rebase again without Shaggy's lazy flush patch. I'll handle that >one separately, I think it needs a little bit more massaging. The following changes since commit 4108d9ba9091c55cfb968d42dd7dcae9a098b876: powerpc/Makefiles: Change to new flag variables (2010-10-13 16:19:22 +1100) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git next Josh Boyer (1): powerpc/44x: Update ppc44x_defconfig Tirumala Marri (1): powerpc/44x: Add support for the AMCC APM821xx SoC arch/powerpc/boot/dts/bluestone.dts | 254 ++ arch/powerpc/configs/44x/bluestone_defconfig | 68 +++ arch/powerpc/configs/ppc44x_defconfig|9 +- arch/powerpc/kernel/cpu_setup_44x.S |1 + arch/powerpc/kernel/cputable.c | 15 ++ arch/powerpc/platforms/44x/Kconfig | 16 ++ arch/powerpc/platforms/44x/ppc44x_simple.c |1 + 7 files changed, 360 insertions(+), 4 deletions(-) create mode 100644 arch/powerpc/boot/dts/bluestone.dts create mode 100644 arch/powerpc/configs/44x/bluestone_defconfig ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][v2] powerpc/fsl: 85xx: add cache-sram support
Oct 13, 2010 at 8:00 PM, wrote: > From: Harninder Rai > > It adds cache-sram support in P1/P2 QorIQ platforms as under: > > * A small abstraction over powerpc's remote heap allocator > * Exports mpc85xx_cache_sram_alloc()/free() APIs > * Supports only one contiguous SRAM window > * Drivers can do the following in Kconfig to use these APIs > "select FSL_85XX_CACHE_SRAM if MPC85xx" You are missing the definition of this option in Kconfig like: +config FSL_85XX_CACHE_SRAM + bool + select PPC_LIB_RHEAP + The select won't work actually. Furthermore, MPC85xx config has been changed to FSL_SOC_BOOKE - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/3] fsl_rio: fix non-standard HID1 register access
>Subject: Re: [PATCH 2/3] fsl_rio: fix non-standard HID1 register access > > >On Oct 13, 2010, at 9:04 PM, Shaohui Xie wrote: > >> From: Li Yang >> >> The access to HID1 register is only legitimate for e500 v1/v2 cores. >> Also fixes magic number. >> >> Signed-off-by: Li Yang >> Signed-off-by: Shaohui Xie >> --- >> arch/powerpc/sysdev/fsl_rio.c |9 ++--- >> 1 files changed, 6 insertions(+), 3 deletions(-) >> >> diff --git a/arch/powerpc/sysdev/fsl_rio.c >> b/arch/powerpc/sysdev/fsl_rio.c index 4127636..dfff3b7 100644 >> --- a/arch/powerpc/sysdev/fsl_rio.c >> +++ b/arch/powerpc/sysdev/fsl_rio.c >> @@ -1537,9 +1537,12 @@ int fsl_rio_setup(struct platform_device *dev) >> #ifdef CONFIG_E500 >> saved_mcheck_exception = ppc_md.machine_check_exception; >> ppc_md.machine_check_exception = fsl_rio_mcheck_exception; -#endif >> -/* Ensure that RFXE is set */ >> -mtspr(SPRN_HID1, (mfspr(SPRN_HID1) | 0x2)); >> + >> +#ifndef CONFIG_PPC_E500MC >> +/* Ensure that RFXE is set on e500 v1/v2 */ >> +mtspr(SPRN_HID1, (mfspr(SPRN_HID1) | HID1_RFXE)); #endif /* >> +!PPC_E500MC */ #endif /* E500 */ > >I've never really been happy with this code. We really should set >HID1_RFXE in cpu_setup_fsl_booke.S instead. But this bit is not recommended to be set unless necessary. And it is only required by SRIO for now. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
