[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKfKVtGegy2P_YWQAtKEzByN-+q+bq=uus4zNvO4sghXRjpGPQ@mail.gmail.com>
Date: Tue, 4 Aug 2015 11:04:52 +0530
From: Shubhrajyoti Datta <shubhrajyoti.datta@...il.com>
To: Lars-Peter Clausen <lars@...afoo.de>
Cc: Xander Huff <xander.huff@...com>, jic23@...nel.org,
bigeasy@...utronix.de, knaack.h@....de,
Peter Meerwald <pmeerw@...erw.net>,
Michal Simek <michal.simek@...inx.com>,
Sören Brinkmann <soren.brinkmann@...inx.com>,
linux-iio@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-rt-users@...r.kernel.org, linux-kernel@...r.kernel.org,
joe.hershberger@...com, joshc@...com, nathan.sullivan@...com,
jaeden.amero@...com
Subject: Re: [PATCH v3] iio: adc: xilinx-xadc: Push interrupts into threaded context
On Fri, Jul 24, 2015 at 6:08 PM, Lars-Peter Clausen <lars@...afoo.de> wrote:
> Hi,
>
> Sorry, but I don't think this patch has been sufficiently tested against a
> mainline kernel. The driver wont even probe the way it is right now.
>
> On 07/21/2015 01:14 AM, Xander Huff wrote:
>>
>> The driver currently registers a pair of irq handlers using
>> request_threaded_irq(), however the synchronization mechanism between the
>> hardirq and the threadedirq handler is a regular spinlock.
>
>
> If everything runs in threaded context we don't really need the spinlock
> anymore and can use the mutex throughout.
that should be better from the performance point of view.
>
>>
>> Unfortunately, this breaks PREEMPT_RT builds, where a spinlock can sleep,
>> and is thus not able to be acquired from a hardirq handler. This patch
>> gets
>> rid of the hardirq handler and pushes all interrupt handling into the
>> threaded context.
>
>
> We actually might as well run everything in the hardirq handler (which will
> be threaded in PREEMPT_RT). The reason why we have the threaded handler is
> because xadc_handle_event() used to sleep, but it doesn't do this anymore.
The point is why have the hard irq. If we use hardirq then not mutex
can be used and spinlock will
be busy.
is there something i may be missing?
>
>
--
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