On Thu, 29 Aug 2013, Ming Lei wrote:
> > In the end, this comes down to a decision about priorities. Do you
> > want to give higher priority to new events or to givebacks? Overall, I
> > don't think it matters.
>
> If possible, the events should be put higher priority, like events
> handling in
On Tue, Aug 27, 2013 at 10:39 PM, Alan Stern wrote:
> On Tue, 27 Aug 2013, Ming Lei wrote:
>
>> > Yes. A new spinlock would be needed to synchronize the top half and
>> > the bottom half. The same spinlock would also be used to avoid
>> > scheduling the tasklet when it is already running, like i
On Tue, 27 Aug 2013, Ming Lei wrote:
> > Yes. A new spinlock would be needed to synchronize the top half and
> > the bottom half. The same spinlock would also be used to avoid
> > scheduling the tasklet when it is already running, like in your
> > implementation.
>
> Then every HCD need to copy
On Mon, Aug 26, 2013 at 11:29 PM, Alan Stern wrote:
> On Mon, 26 Aug 2013, Ming Lei wrote:
>
>> > On Sat, 24 Aug 2013, Ming Lei wrote:
>> >
>> >> But the current interrupt from EHCI isn't be acked(USBSTS isn't cleared),
>> >> so EHCI HW don't know the irq has been handled, then it is reasonable
>>
On Mon, 26 Aug 2013, Ming Lei wrote:
> > On Sat, 24 Aug 2013, Ming Lei wrote:
> >
> >> But the current interrupt from EHCI isn't be acked(USBSTS isn't cleared),
> >> so EHCI HW don't know the irq has been handled, then it is reasonable
> >> that the EHCI interrupt still interrupts CPU.
> >>
> >> E
On Sun, Aug 25, 2013 at 10:45 PM, Alan Stern wrote:
> To begin with, the whole point of this RFC was to show that moving the
> entire IRQ handler (or even a large part of it) to a tasklet would have
> been at least as simple as moving the givebacks alone.
>
> Now that I realize the hrtimer and unl
To begin with, the whole point of this RFC was to show that moving the
entire IRQ handler (or even a large part of it) to a tasklet would have
been at least as simple as moving the givebacks alone.
Now that I realize the hrtimer and unlink pathways would have to be
changed too, it's not quite so
On Sat, Aug 24, 2013 at 12:06 AM, Alan Stern wrote:
> On Fri, 23 Aug 2013, Ming Lei wrote:
>
>> On Fri, Aug 23, 2013 at 4:39 AM, Alan Stern
>> wrote:
>> > This patch divides ehci-hcd's interrupt handler into a top half and a
>> > bottom half, using a tasklet to execute the latter.
>> >
>> > The
On Fri, 23 Aug 2013, Ming Lei wrote:
> On Fri, Aug 23, 2013 at 4:39 AM, Alan Stern wrote:
> > This patch divides ehci-hcd's interrupt handler into a top half and a
> > bottom half, using a tasklet to execute the latter.
> >
> > The conversion is very straightforward. The only subtle point is tha
On Fri, 23 Aug 2013, Matthieu CASTET wrote:
> Le Thu, 22 Aug 2013 21:39:17 +0100,
> Alan Stern a �crit :
>
> > This patch divides ehci-hcd's interrupt handler into a top half and a
> > bottom half, using a tasklet to execute the latter.
> >
> > The conversion is very straightforward. The only
Le Thu, 22 Aug 2013 21:39:17 +0100,
Alan Stern a écrit :
> This patch divides ehci-hcd's interrupt handler into a top half and a
> bottom half, using a tasklet to execute the latter.
>
> The conversion is very straightforward. The only subtle point is that
> we have to ignore interrupts that ar
On Fri, Aug 23, 2013 at 4:39 AM, Alan Stern wrote:
> This patch divides ehci-hcd's interrupt handler into a top half and a
> bottom half, using a tasklet to execute the latter.
>
> The conversion is very straightforward. The only subtle point is that
> we have to ignore interrupts that arrive whi
This patch divides ehci-hcd's interrupt handler into a top half and a
bottom half, using a tasklet to execute the latter.
The conversion is very straightforward. The only subtle point is that
we have to ignore interrupts that arrive while the tasklet is running
(i.e., from another device on a sha
13 matches
Mail list logo
