On Mon, Oct 3, 2011 at 9:52 AM, Bounine, Alexandre
wrote:
> Vinod Koul wrote:
>>
>> On Fri, 2011-09-30 at 17:38 -0400, Alexandre Bounine wrote:
>> Please CC *maintainers* on your patches, get_maintainers.pl will tell
>> you who. Adding Dan here
>
> Based on https://lkml.org/lkml/2011/2/14/67 and u
2011/9/30 Einar Már Björgvinsson :
> Hi all
>
> I am interested in enabling the GPU on the MPC5121 for 2d/3d acceleration.
> I've read some misleading informations about the status of support in Linux
> for this.
> What is the status today ? is it easily possible ? if so, how ?
There may be some s
printk only works for "registered consoles." Currently, the hvc_console
code calls register_console() from hvc_instantiate(), but that's only
used in the early console case. In hvc_alloc(), register_console() was
not called.
Add a call to register_console() in hvc_alloc(), set up the index in
th
On 10/05/2011 06:24 AM, smitha.va...@wipro.com wrote:
> Hi Scoot,
>
> When my ISR gets exeuted I get a below BUG. Could let me what I am
> doing wrong in the ISR?
>
>
> BUG: scheduling while atomic: IRQ-20/0x0fff/108
> Call Trace:
> [C3AEFEC0] [C0007CCC] (unreliable)
> [C3AEFEF0] [C001
On Wed, 2011-10-05 at 18:19 +0530, Suzuki Poulose wrote:
> #define __va(x) ((void *)(unsigned long)((phys_addr_t)(x) -
> PHYSICAL_START + KERNELBASE)
>
> where,
> PHYSICAL_START is #define'd to kernstart_addr variable, updated at
> boot
Wh
Not entirely relevant to the error you are seeing,
but your ISR is:
> irqreturn_t cpld_irq_handler(int irq, void * dev_id, struct
pt_regs *regs)
> {
> wake_up(&cpld_intr_wait);
> atomic_inc(&cpld_intr_data); /* incrementing this will
indicate the poll() that
On Wed, 5 Oct 2011, Gabriel Paubert wrote:
> On Wed, Oct 05, 2011 at 12:30:49PM -, Thomas Gleixner wrote:
> > The following series marks the obvious interrupts IRQF_NO_THREAD to
> > prevent forced interrupt threading - no guarantee of completeness :)
> >
> > The last patch enables the forced
On Wed, Oct 05, 2011 at 12:30:49PM -, Thomas Gleixner wrote:
> The following series marks the obvious interrupts IRQF_NO_THREAD to
> prevent forced interrupt threading - no guarantee of completeness :)
>
> The last patch enables the forced threading mechanism in the core
> code, which in turn
Hi Kumar,
I have been working on the CONFIG_RELOCATABLE support for PPC44x, trying to
process
the relocations generated by the compiler. Since the TLB size is 256M, we cannot
enforce a page aligned kernel load address.
I came across some issues with the __va() / __pa() translations, while the
Cascade handlers must run in hard interrupt context.
Signed-off-by: Thomas Gleixner
---
arch/powerpc/platforms/wsp/opb_pic.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6/arch/powerpc/platforms/wsp/opb_pic.c
=
Cascade interrupt must run in hard interrupt context.
Signed-off-by: Thomas Gleixner
---
arch/powerpc/platforms/85xx/mpc85xx_cds.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6/arch/powerpc/platforms/85xx/mpc85xx_cds.c
The following series marks the obvious interrupts IRQF_NO_THREAD to
prevent forced interrupt threading - no guarantee of completeness :)
The last patch enables the forced threading mechanism in the core
code, which in turn enables the "irqthreaded" commandline option.
Thanks,
tglx
___
IPI handlers cannot be threaded. Remove the obsolete IRQF_DISABLED
flag (see commit e58aa3d2) while at it.
Signed-off-by: Thomas Gleixner
---
arch/powerpc/kernel/smp.c |2 +-
arch/powerpc/platforms/powermac/smp.c |4 ++--
arch/powerpc/sysdev/xics/xics-common.c |6 +++---
All interrupts which must be non threaded are marked
IRQF_NO_THREAD. So it's safe to allow force threaded handlers.
Signed-off-by: Thomas Gleixner
---
arch/powerpc/Kconfig |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6/arch/powerpc/Kconfig
Hi Scoot,
When my ISR gets exeuted I get a below BUG. Could let me what I am doing
wrong in the ISR?
BUG: scheduling while atomic: IRQ-20/0x0fff/108
Call Trace:
[C3AEFEC0] [C0007CCC] (unreliable)
[C3AEFEF0] [C0017F10]
[C3AEFF00] [C0268818]
[C3AEFF50] [C0017F44]
[C3AEFF60] [C0018044]
[C3
On Tue, Oct 04, 2011 at 05:26:20PM -0300, Thadeu Lima de Souza Cascardo wrote:
I believe we have an endianess problem here. The source buffer is in
big endian - in x86 archs, it will rich the pci device unswapped since
both x86 and pci are little endian. In ppc, it wil be swapped by the
chipset so
16 matches
Mail list logo