On Thursday 15 November 2007, Haavard Skinnemoen wrote:
> On Thu, 15 Nov 2007 00:20:33 -0800
> David Brownell <[EMAIL PROTECTED]> wrote:
>
> > > > - gpio_direction_input()/gpio_direction_output() implicitly
> > > > request the pins, if they weren't already requested.
> > >
> > > Eek,
On Thu, 15 Nov 2007 00:20:33 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> > > - gpio_direction_input()/gpio_direction_output() implicitly
> > > request the pins, if they weren't already requested.
> >
> > Eek, that's completely wrong. Allowing to access a resource _before_
> > it is
On Wednesday 14 November 2007, Nick Piggin wrote:
> > > > All this does is prevent constant and needless checking for
> > > > "do you want to preempt me now?" "now?" "now?" in "now?" the
> > > > middle "now?" of "now?" i/o "now?" loops.
> > >
> > > Actually that's wrong.
> >
> > Certainly it's
On Thursday 15 November 2007 19:17, David Brownell wrote:
> On Wednesday 14 November 2007, Nick Piggin wrote:
> > > > > All this does is prevent constant and needless checking for
> > > > > "do you want to preempt me now?" "now?" "now?" in "now?" the
> > > > > middle "now?" of "now?" i/o "now?"
On Wed, 14 Nov 2007 22:50:17 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> > Since this is the code that runs under the lock
>
> No, there's more than that. This is what runs under it in
> the hot paths, yes, but the gpio request/free paths do
> more work than this. (That includes
On Wednesday 14 November 2007, Thomas Gleixner wrote:
> On Wed, 14 Nov 2007, David Brownell wrote:
> > > The protection of the chip list can be converted to a mutex and
> > > does not need to be a spinlock at all.
> >
> > No, we still need to use a spinlock to protect table changes.
> > The
On Thursday 15 November 2007 06:19, Nick Piggin wrote:
> On Thursday 15 November 2007 19:17, David Brownell wrote:
> > On Wednesday 14 November 2007, Nick Piggin wrote:
> > > > > > All this does is prevent constant and needless checking for
> > > > > > "do you want to preempt me now?" "now?"
On Thursday 15 November 2007 17:28, David Brownell wrote:
> On Tuesday 13 November 2007, Nick Piggin wrote:
> > > All this does is prevent constant and needless checking for
> > > "do you want to preempt me now?" "now?" "now?" in "now?" the
> > > middle "now?" of "now?" i/o "now?" loops.
> >
> >
On Thursday 15 November 2007 17:28, David Brownell wrote:
On Tuesday 13 November 2007, Nick Piggin wrote:
All this does is prevent constant and needless checking for
do you want to preempt me now? now? now? in now? the
middle now? of now? i/o now? loops.
Actually that's wrong.
On Thursday 15 November 2007 06:19, Nick Piggin wrote:
On Thursday 15 November 2007 19:17, David Brownell wrote:
On Wednesday 14 November 2007, Nick Piggin wrote:
All this does is prevent constant and needless checking for
do you want to preempt me now? now? now? in now? the
On Wednesday 14 November 2007, Thomas Gleixner wrote:
On Wed, 14 Nov 2007, David Brownell wrote:
The protection of the chip list can be converted to a mutex and
does not need to be a spinlock at all.
No, we still need to use a spinlock to protect table changes.
The reason for that is
On Wed, 14 Nov 2007 22:50:17 -0800
David Brownell [EMAIL PROTECTED] wrote:
Since this is the code that runs under the lock
No, there's more than that. This is what runs under it in
the hot paths, yes, but the gpio request/free paths do
more work than this. (That includes direction
On Thursday 15 November 2007 19:17, David Brownell wrote:
On Wednesday 14 November 2007, Nick Piggin wrote:
All this does is prevent constant and needless checking for
do you want to preempt me now? now? now? in now? the
middle now? of now? i/o now? loops.
Actually that's
On Wednesday 14 November 2007, Nick Piggin wrote:
All this does is prevent constant and needless checking for
do you want to preempt me now? now? now? in now? the
middle now? of now? i/o now? loops.
Actually that's wrong.
Certainly it's right for the mainstream kernel.
On Thu, 15 Nov 2007 00:20:33 -0800
David Brownell [EMAIL PROTECTED] wrote:
- gpio_direction_input()/gpio_direction_output() implicitly
request the pins, if they weren't already requested.
Eek, that's completely wrong. Allowing to access a resource _before_
it is assigned and
On Thursday 15 November 2007, Haavard Skinnemoen wrote:
On Thu, 15 Nov 2007 00:20:33 -0800
David Brownell [EMAIL PROTECTED] wrote:
- gpio_direction_input()/gpio_direction_output() implicitly
request the pins, if they weren't already requested.
Eek, that's completely
On Wed, 14 Nov 2007, David Brownell wrote:
> On Wednesday 14 November 2007, Thomas Gleixner wrote:
> > struct gpio_desc {
> >struct gpio_chip *chip;
> >int pinoffset;
> > };
>
> Eric Miao has a different notion of "gpio_desc" more analagous to
> the "irq_desc", so I'll not use
On Wed, 14 Nov 2007, David Brownell wrote:
> > The protection of the chip list can be converted to a mutex and
> > does not need to be a spinlock at all.
>
> No, we still need to use a spinlock to protect table changes.
> The reason for that is briefly:
>
> - gpio_request()/gpio_free() have so
On Wednesday 14 November 2007, Thomas Gleixner wrote:
> struct gpio_desc {
> struct gpio_chip *chip;
> int pinoffset;
> };
Eric Miao has a different notion of "gpio_desc" more analagous to
the "irq_desc", so I'll not use that name for such a structure.
Let me call yours a "struct
On Wednesday 14 November 2007, Haavard Skinnemoen wrote:
> On Wed, 14 Nov 2007 00:37:57 -0800
> David Brownell <[EMAIL PROTECTED]> wrote:
>
> > Although another point is related to "trivial": the data
> > is being protected through an operation too trivial to be
> > worth paying for any of that
On Wednesday 14 November 2007, Thomas Gleixner wrote:
> On Mon, 12 Nov 2007, David Brownell wrote:
> > > I'm still trying to understand what you've observed here. Is it the case
> > > that a single gpio operation went from 6.4 up to 11.2 usecs?
> >
> > That was a single bitbanged I2C bit
On Tuesday 13 November 2007, Nick Piggin wrote:
> > All this does is prevent constant and needless checking for
> > "do you want to preempt me now?" "now?" "now?" in "now?" the
> > middle "now?" of "now?" i/o "now?" loops.
>
> Actually that's wrong.
Certainly it's right for the mainstream
On Tuesday 13 November 2007, Nick Piggin wrote:
> > > But these ones
> > > are raw locks rather than normal locks probably because that
> > > they are trivially an innermost and correct lock.
> >
> > As in the $SUBJECT case, I'd say.
> >
> > Although another point is related to "trivial": the
On Mon, 12 Nov 2007, David Brownell wrote:
> > I'm still trying to understand what you've observed here. Is it the case
> > that a single gpio operation went from 6.4 up to 11.2 usecs?
>
> That was a single bitbanged I2C bit transfer, with embedded udelay()s.
> I believe that was four gpio
* David Brownell <[EMAIL PROTECTED]> wrote:
> > Why do you want to use raw_spinlock_t?
>
> Already answered elsewhere in this thread ... I'll highlight the point
> that such bitops shouldn't be preemption points.
raw_spinlock_t is a spinlock-internal implementation detail in the
On Wed, 14 Nov 2007 00:37:57 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> Although another point is related to "trivial": the data
> is being protected through an operation too trivial to be
> worth paying for any of that priority logic.
But isn't there any way we can remove the lock from
On Wednesday 14 November 2007 19:20, David Brownell wrote:
> On Tuesday 13 November 2007, Nick Piggin wrote:
> > I mean, if you have a
> > timing critical operation, then you should ensure you have priorities
> > set correctly so that you simply don't get preempted.
>
> Which is why bitops like
On Wednesday 14 November 2007 19:37, David Brownell wrote:
> On Tuesday 13 November 2007, Nick Piggin wrote:
> > Upstream, all spinlocks prevent preemption.
>
> I chose my wording carefully though. A preemption point is
> more than just a small region where preemption isn't allowed.
>
> It's one
On Tuesday 13 November 2007, Nick Piggin wrote:
> On Wednesday 14 November 2007 17:52, David Brownell wrote:
> > On Tuesday 13 November 2007, Andrew Morton wrote:
>
> > > > I'll highlight the
> > > > point that such bitops shouldn't be preemption points.
> > >
> > > Disagree. *everything* should
On Tuesday 13 November 2007, Nick Piggin wrote:
> > > > I'd be happy if, as originally presented, it were possible to just
> > > > pass a raw_spinlock_t to spin_lock_irqsave() and friends.
> > >
> > > that's a spinlock type abstraction of PREEMPT_RT, not of mainline.
>
> Even when you're talking
On Tuesday 13 November 2007, Nick Piggin wrote:
On Wednesday 14 November 2007 17:52, David Brownell wrote:
On Tuesday 13 November 2007, Andrew Morton wrote:
I'll highlight the
point that such bitops shouldn't be preemption points.
Disagree. *everything* should be a preemption
On Wednesday 14 November 2007 19:20, David Brownell wrote:
On Tuesday 13 November 2007, Nick Piggin wrote:
I mean, if you have a
timing critical operation, then you should ensure you have priorities
set correctly so that you simply don't get preempted.
Which is why bitops like
On Tuesday 13 November 2007, Nick Piggin wrote:
I'd be happy if, as originally presented, it were possible to just
pass a raw_spinlock_t to spin_lock_irqsave() and friends.
that's a spinlock type abstraction of PREEMPT_RT, not of mainline.
Even when you're talking about the -rt
On Wednesday 14 November 2007 19:37, David Brownell wrote:
On Tuesday 13 November 2007, Nick Piggin wrote:
Upstream, all spinlocks prevent preemption.
I chose my wording carefully though. A preemption point is
more than just a small region where preemption isn't allowed.
It's one of
* David Brownell [EMAIL PROTECTED] wrote:
Why do you want to use raw_spinlock_t?
Already answered elsewhere in this thread ... I'll highlight the point
that such bitops shouldn't be preemption points.
raw_spinlock_t is a spinlock-internal implementation detail in the
upstream
On Wed, 14 Nov 2007 00:37:57 -0800
David Brownell [EMAIL PROTECTED] wrote:
Although another point is related to trivial: the data
is being protected through an operation too trivial to be
worth paying for any of that priority logic.
But isn't there any way we can remove the lock from the
On Mon, 12 Nov 2007, David Brownell wrote:
I'm still trying to understand what you've observed here. Is it the case
that a single gpio operation went from 6.4 up to 11.2 usecs?
That was a single bitbanged I2C bit transfer, with embedded udelay()s.
I believe that was four gpio operations,
On Tuesday 13 November 2007, Nick Piggin wrote:
All this does is prevent constant and needless checking for
do you want to preempt me now? now? now? in now? the
middle now? of now? i/o now? loops.
Actually that's wrong.
Certainly it's right for the mainstream kernel. Dropping a
lock
On Tuesday 13 November 2007, Nick Piggin wrote:
But these ones
are raw locks rather than normal locks probably because that
they are trivially an innermost and correct lock.
As in the $SUBJECT case, I'd say.
Although another point is related to trivial: the data
is being
On Wednesday 14 November 2007, Haavard Skinnemoen wrote:
On Wed, 14 Nov 2007 00:37:57 -0800
David Brownell [EMAIL PROTECTED] wrote:
Although another point is related to trivial: the data
is being protected through an operation too trivial to be
worth paying for any of that priority
On Wednesday 14 November 2007, Thomas Gleixner wrote:
On Mon, 12 Nov 2007, David Brownell wrote:
I'm still trying to understand what you've observed here. Is it the case
that a single gpio operation went from 6.4 up to 11.2 usecs?
That was a single bitbanged I2C bit transfer, with
On Wednesday 14 November 2007, Thomas Gleixner wrote:
struct gpio_desc {
struct gpio_chip *chip;
int pinoffset;
};
Eric Miao has a different notion of gpio_desc more analagous to
the irq_desc, so I'll not use that name for such a structure.
Let me call yours a struct gpio_pin
On Wed, 14 Nov 2007, David Brownell wrote:
The protection of the chip list can be converted to a mutex and
does not need to be a spinlock at all.
No, we still need to use a spinlock to protect table changes.
The reason for that is briefly:
- gpio_request()/gpio_free() have so far been
On Wed, 14 Nov 2007, David Brownell wrote:
On Wednesday 14 November 2007, Thomas Gleixner wrote:
struct gpio_desc {
struct gpio_chip *chip;
int pinoffset;
};
Eric Miao has a different notion of gpio_desc more analagous to
the irq_desc, so I'll not use that name for such
On Wednesday 14 November 2007 17:52, David Brownell wrote:
> On Tuesday 13 November 2007, Andrew Morton wrote:
> > > I'll highlight the
> > > point that such bitops shouldn't be preemption points.
> >
> > Disagree. *everything* should be a preemption point.
>
> So it's wrong that uses the
>
On Tuesday 13 November 2007, Andrew Morton wrote:
>
> > > Why do you want to use raw_spinlock_t?
> >
> > Already answered elsewhere in this thread ...
>
> Can't say I really understood the answer. I don't think we
> actually know where all of this extra time is being spent?
Reading that,
On Wednesday 14 November 2007 06:22, David Brownell wrote:
> On Tuesday 13 November 2007, Ingo Molnar wrote:
> > * David Brownell <[EMAIL PROTECTED]> wrote:
> > > > > I speculate that either the design has changed (without fanfare),
> > > > > or else that stuff is in RT kernels and has not yet
On Tue, 13 Nov 2007 11:22:45 -0800 David Brownell <[EMAIL PROTECTED]> wrote:
> On Tuesday 13 November 2007, Ingo Molnar wrote:
> >
> > * David Brownell <[EMAIL PROTECTED]> wrote:
> >
> > > > > I speculate that either the design has changed (without fanfare),
> > > > > or else that stuff is in
On Tuesday 13 November 2007, Ingo Molnar wrote:
>
> * David Brownell <[EMAIL PROTECTED]> wrote:
>
> > > > I speculate that either the design has changed (without fanfare),
> > > > or else that stuff is in RT kernels and has not yet gone upstream.
> > >
> > > Well whatever. We shouldn't have
* David Brownell <[EMAIL PROTECTED]> wrote:
> > > I speculate that either the design has changed (without fanfare),
> > > or else that stuff is in RT kernels and has not yet gone upstream.
> >
> > Well whatever. We shouldn't have to resort to caller-side party
> > tricks like this to get
* David Brownell [EMAIL PROTECTED] wrote:
I speculate that either the design has changed (without fanfare),
or else that stuff is in RT kernels and has not yet gone upstream.
Well whatever. We shouldn't have to resort to caller-side party
tricks like this to get acceptable
On Tuesday 13 November 2007, Ingo Molnar wrote:
* David Brownell [EMAIL PROTECTED] wrote:
I speculate that either the design has changed (without fanfare),
or else that stuff is in RT kernels and has not yet gone upstream.
Well whatever. We shouldn't have to resort to
On Tue, 13 Nov 2007 11:22:45 -0800 David Brownell [EMAIL PROTECTED] wrote:
On Tuesday 13 November 2007, Ingo Molnar wrote:
* David Brownell [EMAIL PROTECTED] wrote:
I speculate that either the design has changed (without fanfare),
or else that stuff is in RT kernels and has
On Wednesday 14 November 2007 06:22, David Brownell wrote:
On Tuesday 13 November 2007, Ingo Molnar wrote:
* David Brownell [EMAIL PROTECTED] wrote:
I speculate that either the design has changed (without fanfare),
or else that stuff is in RT kernels and has not yet gone upstream.
On Tuesday 13 November 2007, Andrew Morton wrote:
Why do you want to use raw_spinlock_t?
Already answered elsewhere in this thread ...
Can't say I really understood the answer. I don't think we
actually know where all of this extra time is being spent?
Reading that, one could
On Wednesday 14 November 2007 17:52, David Brownell wrote:
On Tuesday 13 November 2007, Andrew Morton wrote:
I'll highlight the
point that such bitops shouldn't be preemption points.
Disagree. *everything* should be a preemption point.
So it's wrong that asm-generic/bitops/atomic.h
> > It seems info on raw spinlocks is out
> > of sync with current code. Allegedly it should be possible to just
> > pass a raw_spinlock_t pointer to spin_lock_irqsave() and friends
> > and have GCC sort out the right stuff ... but that didn't work.
> >
> > I speculate that either the
On Mon, 12 Nov 2007 14:32:53 -0800 David Brownell <[EMAIL PROTECTED]> wrote:
> On Monday 12 November 2007, Andrew Morton wrote:
> > On Fri, 9 Nov 2007 11:36:19 -0800 David Brownell <[EMAIL PROTECTED]> wrote:
> >
> > > Provide new implementation infrastructure that platforms may choose to use
> >
On Monday 12 November 2007, Andrew Morton wrote:
> On Fri, 9 Nov 2007 11:36:19 -0800 David Brownell <[EMAIL PROTECTED]> wrote:
>
> > Provide new implementation infrastructure that platforms may choose to use
> > when implementing the GPIO programming interface. ...
> >
> > ...
> >
> > +/*
On Fri, 9 Nov 2007 11:36:19 -0800 David Brownell <[EMAIL PROTECTED]> wrote:
> Provide new implementation infrastructure that platforms may choose to use
> when implementing the GPIO programming interface. Platforms can update their
> GPIO support to use this. In many cases the incremental cost
On Fri, 9 Nov 2007 11:36:19 -0800 David Brownell [EMAIL PROTECTED] wrote:
Provide new implementation infrastructure that platforms may choose to use
when implementing the GPIO programming interface. Platforms can update their
GPIO support to use this. In many cases the incremental cost to
On Monday 12 November 2007, Andrew Morton wrote:
On Fri, 9 Nov 2007 11:36:19 -0800 David Brownell [EMAIL PROTECTED] wrote:
Provide new implementation infrastructure that platforms may choose to use
when implementing the GPIO programming interface. ...
...
+/* gpio_lock protects
On Mon, 12 Nov 2007 14:32:53 -0800 David Brownell [EMAIL PROTECTED] wrote:
On Monday 12 November 2007, Andrew Morton wrote:
On Fri, 9 Nov 2007 11:36:19 -0800 David Brownell [EMAIL PROTECTED] wrote:
Provide new implementation infrastructure that platforms may choose to use
when
It seems info on raw spinlocks is out
of sync with current code. Allegedly it should be possible to just
pass a raw_spinlock_t pointer to spin_lock_irqsave() and friends
and have GCC sort out the right stuff ... but that didn't work.
I speculate that either the design has
Provide new implementation infrastructure that platforms may choose to use
when implementing the GPIO programming interface. Platforms can update their
GPIO support to use this. In many cases the incremental cost to access a
non-inlined GPIO should be on the order of a dozen instructions, so it
Provide new implementation infrastructure that platforms may choose to use
when implementing the GPIO programming interface. Platforms can update their
GPIO support to use this. In many cases the incremental cost to access a
non-inlined GPIO should be on the order of a dozen instructions, so it
66 matches
Mail list logo
