[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGVrzcbxHA+S0yZbsrj8uMZR0hsb_ng=PB02zte7S0rCZWQpBg@mail.gmail.com>
Date: Thu, 5 Dec 2013 10:48:12 -0800
From: Florian Fainelli <f.fainelli@...il.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Marc Carino <marc.ceeeee@...il.com>,
Russell King <linux@....linux.org.uk>,
Christian Daudt <bcm@...thebug.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/6] ARM: brcmstb: add infrastructure for ARM-based
Broadcom STB SoCs
Hi Arnd,
2013/12/3 Arnd Bergmann <arnd@...db.de>:
>
>> + addr = ioremap(BPHYSADDR(BCHP_IRQ0_IRQEN), sizeof(u32));
>> + writel_relaxed(BCHP_IRQ0_IRQEN_uarta_irqen_MASK
>> + | BCHP_IRQ0_IRQEN_uartb_irqen_MASK
>> + | BCHP_IRQ0_IRQEN_uartc_irqen_MASK, addr);
>> + iounmap(addr);
>
> What does this part do? Isn't that something that should have been set
> up by the boot loader?
The bootloader will typically use the UART in busy-looping mode and
not rely on interrupts, also the bootloader currently does not know
much about how many UARTs there are in the system and how they are
going to be used.
One possible way to solve this would be to write a very small irqchip
driver which only implements the "irq_enable" method to allow these
interrupts to be forwarded to the GIC. Somewhere in the Device Tree we
would have an interrupt-map property which describes the mapping
between the bits in BCHP_IRQ0_IRQEN and their corresponding
peripherals (UARTA, B, C).
Would that work?
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists