On Thu, May 22, 2014 at 09:48:00AM +0200, Geert Uytterhoeven wrote:
> On Thu, May 22, 2014 at 9:32 AM, Jonas Bonn wrote:
> > On 05/21/2014 09:50 PM, Stefan Kristiansson wrote:
> >> I see two paths to go to get there though, and here's where I'd like some
> >> input.
> >> 1) Define the three
On Thu, May 22, 2014 at 9:32 AM, Jonas Bonn wrote:
> On 05/21/2014 09:50 PM, Stefan Kristiansson wrote:
>> I see two paths to go to get there though, and here's where I'd like some
>> input.
>> 1) Define the three different implementations as seperate irqchips,
>>with accompanying
On 05/21/2014 09:50 PM, Stefan Kristiansson wrote:
>
> I see two paths to go to get there though, and here's where I'd like some
> input.
> 1) Define the three different implementations as seperate irqchips,
>with accompanying IRQCHIP_DECLARE.
> 2) Add custom device-tree bindings and
On 05/21/2014 09:50 PM, Stefan Kristiansson wrote:
I see two paths to go to get there though, and here's where I'd like some
input.
1) Define the three different implementations as seperate irqchips,
with accompanying IRQCHIP_DECLARE.
2) Add custom device-tree bindings and determine the
On Thu, May 22, 2014 at 9:32 AM, Jonas Bonn jo...@southpole.se wrote:
On 05/21/2014 09:50 PM, Stefan Kristiansson wrote:
I see two paths to go to get there though, and here's where I'd like some
input.
1) Define the three different implementations as seperate irqchips,
with accompanying
On Thu, May 22, 2014 at 09:48:00AM +0200, Geert Uytterhoeven wrote:
On Thu, May 22, 2014 at 9:32 AM, Jonas Bonn jo...@southpole.se wrote:
On 05/21/2014 09:50 PM, Stefan Kristiansson wrote:
I see two paths to go to get there though, and here's where I'd like some
input.
1) Define the
On Wed, May 21, 2014 at 04:01:56PM -0400, Jason Cooper wrote:
> On Wed, May 21, 2014 at 10:50:57PM +0300, Stefan Kristiansson wrote:
> ...
> > I see two paths to go to get there though, and here's where I'd like some
> > input.
> > 1) Define the three different implementations as seperate
On Wed, May 21, 2014 at 10:50:57PM +0300, Stefan Kristiansson wrote:
...
> I see two paths to go to get there though, and here's where I'd like some
> input.
> 1) Define the three different implementations as seperate irqchips,
>with accompanying IRQCHIP_DECLARE.
> 2) Add custom device-tree
On Tue, May 20, 2014 at 08:18:16AM +0900, Thomas Gleixner wrote:
> On Mon, 19 May 2014, Stefan Kristiansson wrote:
> > +static void or1k_pic_ack(struct irq_data *data)
> > +{
> > + /* EDGE-triggered interrupts need to be ack'ed in order to clear
> > +* the latch.
> > +* LEVEL-triggered
On Tue, May 20, 2014 at 08:18:16AM +0900, Thomas Gleixner wrote:
On Mon, 19 May 2014, Stefan Kristiansson wrote:
+static void or1k_pic_ack(struct irq_data *data)
+{
+ /* EDGE-triggered interrupts need to be ack'ed in order to clear
+* the latch.
+* LEVEL-triggered interrupts
On Wed, May 21, 2014 at 10:50:57PM +0300, Stefan Kristiansson wrote:
...
I see two paths to go to get there though, and here's where I'd like some
input.
1) Define the three different implementations as seperate irqchips,
with accompanying IRQCHIP_DECLARE.
2) Add custom device-tree
On Wed, May 21, 2014 at 04:01:56PM -0400, Jason Cooper wrote:
On Wed, May 21, 2014 at 10:50:57PM +0300, Stefan Kristiansson wrote:
...
I see two paths to go to get there though, and here's where I'd like some
input.
1) Define the three different implementations as seperate irqchips,
On Mon, 19 May 2014, Stefan Kristiansson wrote:
> +static void or1k_pic_ack(struct irq_data *data)
> +{
> + /* EDGE-triggered interrupts need to be ack'ed in order to clear
> + * the latch.
> + * LEVEL-triggered interrupts do not need to be ack'ed; however,
> + * ack'ing the
In addition to consolidating the or1k-pic with other interrupt
controllers, this makes OpenRISC less tied to its on-cpu
interrupt controller.
All or1k-pic specific parts are moved out of irq.c and into
drivers/irqchip/irq-or1k-pic.c
In that transition, a couple of changes have been done:
- The
On Mon, 19 May 2014, Stefan Kristiansson wrote:
+static void or1k_pic_ack(struct irq_data *data)
+{
+ /* EDGE-triggered interrupts need to be ack'ed in order to clear
+ * the latch.
+ * LEVEL-triggered interrupts do not need to be ack'ed; however,
+ * ack'ing the interrupt
In addition to consolidating the or1k-pic with other interrupt
controllers, this makes OpenRISC less tied to its on-cpu
interrupt controller.
All or1k-pic specific parts are moved out of irq.c and into
drivers/irqchip/irq-or1k-pic.c
In that transition, a couple of changes have been done:
- The
16 matches
Mail list logo
