On Fri, 11 Oct 2013 15:30:22 +0200
Sebastian Andrzej Siewior wrote:
> On 10/11/2013 02:37 PM, Steven Rostedt wrote:
> > On Fri, 11 Oct 2013 12:18:00 +0200
> > Sebastian Andrzej Siewior wrote:
> >
> >> * Mario Kleiner | 2013-09-26 18:16:47 [+0200]:
> >>
> >>> Good! I will do that. Thanks for
On 10/11/2013 03:30 PM, Sebastian Andrzej Siewior wrote:
On 10/11/2013 02:37 PM, Steven Rostedt wrote:
On Fri, 11 Oct 2013 12:18:00 +0200
Sebastian Andrzej Siewior wrote:
* Mario Kleiner | 2013-09-26 18:16:47 [+0200]:
Good! I will do that. Thanks for clarifying the irq and constraints
on
On 10/11/2013 02:37 PM, Steven Rostedt wrote:
> On Fri, 11 Oct 2013 12:18:00 +0200
> Sebastian Andrzej Siewior wrote:
>
>> * Mario Kleiner | 2013-09-26 18:16:47 [+0200]:
>>
>>> Good! I will do that. Thanks for clarifying the irq and constraints
>>> on raw locks in the other thread.
>>
>> Are
On Fri, 11 Oct 2013 12:18:00 +0200
Sebastian Andrzej Siewior wrote:
> * Mario Kleiner | 2013-09-26 18:16:47 [+0200]:
>
> >Good! I will do that. Thanks for clarifying the irq and constraints
> >on raw locks in the other thread.
>
> Are there any suggestions for "now"? preempt_disable_nort()
* Mario Kleiner | 2013-09-26 18:16:47 [+0200]:
>Good! I will do that. Thanks for clarifying the irq and constraints
>on raw locks in the other thread.
Are there any suggestions for "now"? preempt_disable_nort() like Luis
suggesed?
>-mario
Sebastian
--
To unsubscribe from this list: send the
On Fri, 11 Oct 2013 12:18:00 +0200
Sebastian Andrzej Siewior bige...@linutronix.de wrote:
* Mario Kleiner | 2013-09-26 18:16:47 [+0200]:
Good! I will do that. Thanks for clarifying the irq and constraints
on raw locks in the other thread.
Are there any suggestions for now?
On 10/11/2013 02:37 PM, Steven Rostedt wrote:
On Fri, 11 Oct 2013 12:18:00 +0200
Sebastian Andrzej Siewior bige...@linutronix.de wrote:
* Mario Kleiner | 2013-09-26 18:16:47 [+0200]:
Good! I will do that. Thanks for clarifying the irq and constraints
on raw locks in the other thread.
Are
On 10/11/2013 03:30 PM, Sebastian Andrzej Siewior wrote:
On 10/11/2013 02:37 PM, Steven Rostedt wrote:
On Fri, 11 Oct 2013 12:18:00 +0200
Sebastian Andrzej Siewior bige...@linutronix.de wrote:
* Mario Kleiner | 2013-09-26 18:16:47 [+0200]:
Good! I will do that. Thanks for clarifying the irq
On Fri, 11 Oct 2013 15:30:22 +0200
Sebastian Andrzej Siewior bige...@linutronix.de wrote:
On 10/11/2013 02:37 PM, Steven Rostedt wrote:
On Fri, 11 Oct 2013 12:18:00 +0200
Sebastian Andrzej Siewior bige...@linutronix.de wrote:
* Mario Kleiner | 2013-09-26 18:16:47 [+0200]:
Good! I
* Mario Kleiner | 2013-09-26 18:16:47 [+0200]:
Good! I will do that. Thanks for clarifying the irq and constraints
on raw locks in the other thread.
Are there any suggestions for now? preempt_disable_nort() like Luis
suggesed?
-mario
Sebastian
--
To unsubscribe from this list: send the line
On 25.09.13 09:49, Ville Syrjälä wrote:
On Wed, Sep 25, 2013 at 06:32:10AM +0200, Mario Kleiner wrote:
On 23.09.13 10:38, Ville Syrjälä wrote:
On Sat, Sep 21, 2013 at 12:07:36AM +0200, Mario Kleiner wrote:
On 09/17/2013 10:55 PM, Daniel Vetter wrote:
On Tue, Sep 17, 2013 at 9:50 PM, Peter
On 25.09.13 16:13, Steven Rostedt wrote:
On Wed, 25 Sep 2013 06:32:10 +0200
Mario Kleiner wrote:
But given the new situation, your proposal is great! If we push the
clock readouts into the get_scanoutpos routine, we can make this robust
without causing grief for the rt people and without the
On 25.09.13 16:13, Steven Rostedt wrote:
On Wed, 25 Sep 2013 06:32:10 +0200
Mario Kleiner mario.klei...@tuebingen.mpg.de wrote:
But given the new situation, your proposal is great! If we push the
clock readouts into the get_scanoutpos routine, we can make this robust
without causing grief for
On 25.09.13 09:49, Ville Syrjälä wrote:
On Wed, Sep 25, 2013 at 06:32:10AM +0200, Mario Kleiner wrote:
On 23.09.13 10:38, Ville Syrjälä wrote:
On Sat, Sep 21, 2013 at 12:07:36AM +0200, Mario Kleiner wrote:
On 09/17/2013 10:55 PM, Daniel Vetter wrote:
On Tue, Sep 17, 2013 at 9:50 PM, Peter
On Wed, 25 Sep 2013 10:49:36 +0300
Ville Syrjälä wrote:
> The preempt_disable/enable is not needed. The spinlock serves the same
> purpose already.
As stated, that was only for the -rt patch, as spin_lock_irqsave does
not disable preemption nor does it even disable interrupts.
But I agree,
On Wed, 25 Sep 2013 06:32:10 +0200
Mario Kleiner wrote:
> But given the new situation, your proposal is great! If we push the
> clock readouts into the get_scanoutpos routine, we can make this robust
> without causing grief for the rt people and without the need for a new
> separate lock
Sorry for the late reply, I was at Linux Plumbers, and had a bunch of
stuff to catch up on when I returned.
On Sat, 21 Sep 2013 00:07:36 +0200
Mario Kleiner wrote:
> Steven, would it then be acceptable to convert that "faster" lock into a
> raw_spinlock_t or is this unacceptable? If so, the
On Wed, 25 Sep 2013 06:32:10 +0200
Mario Kleiner wrote:
> I assume if a spin_lock_irqsave doesn't really disable interrupts on a
> RT kernel with normal spinlocks then local_irq_disable won't really
> disable interrupts either?
>
That is incorrect. On PREEMPT_RT, you are right about
On Wed, Sep 25, 2013 at 06:32:10AM +0200, Mario Kleiner wrote:
> On 23.09.13 10:38, Ville Syrjälä wrote:
> > On Sat, Sep 21, 2013 at 12:07:36AM +0200, Mario Kleiner wrote:
> >> On 09/17/2013 10:55 PM, Daniel Vetter wrote:
> >>> On Tue, Sep 17, 2013 at 9:50 PM, Peter Hurley
> >>> wrote:
> On
On 23.09.13 10:38, Ville Syrjälä wrote:
On Sat, Sep 21, 2013 at 12:07:36AM +0200, Mario Kleiner wrote:
On 09/17/2013 10:55 PM, Daniel Vetter wrote:
On Tue, Sep 17, 2013 at 9:50 PM, Peter Hurley wrote:
On 09/11/2013 03:31 PM, Peter Hurley wrote:
[+cc dri-devel]
On 09/11/2013 11:38 AM,
On 23.09.13 10:38, Ville Syrjälä wrote:
On Sat, Sep 21, 2013 at 12:07:36AM +0200, Mario Kleiner wrote:
On 09/17/2013 10:55 PM, Daniel Vetter wrote:
On Tue, Sep 17, 2013 at 9:50 PM, Peter Hurley pe...@hurleysoftware.com wrote:
On 09/11/2013 03:31 PM, Peter Hurley wrote:
[+cc dri-devel]
On
On Wed, Sep 25, 2013 at 06:32:10AM +0200, Mario Kleiner wrote:
On 23.09.13 10:38, Ville Syrjälä wrote:
On Sat, Sep 21, 2013 at 12:07:36AM +0200, Mario Kleiner wrote:
On 09/17/2013 10:55 PM, Daniel Vetter wrote:
On Tue, Sep 17, 2013 at 9:50 PM, Peter Hurley pe...@hurleysoftware.com
wrote:
On Wed, 25 Sep 2013 06:32:10 +0200
Mario Kleiner mario.klei...@tuebingen.mpg.de wrote:
I assume if a spin_lock_irqsave doesn't really disable interrupts on a
RT kernel with normal spinlocks then local_irq_disable won't really
disable interrupts either?
That is incorrect. On PREEMPT_RT,
Sorry for the late reply, I was at Linux Plumbers, and had a bunch of
stuff to catch up on when I returned.
On Sat, 21 Sep 2013 00:07:36 +0200
Mario Kleiner mario.klei...@tuebingen.mpg.de wrote:
Steven, would it then be acceptable to convert that faster lock into a
raw_spinlock_t or is
On Wed, 25 Sep 2013 06:32:10 +0200
Mario Kleiner mario.klei...@tuebingen.mpg.de wrote:
But given the new situation, your proposal is great! If we push the
clock readouts into the get_scanoutpos routine, we can make this robust
without causing grief for the rt people and without the need
On Wed, 25 Sep 2013 10:49:36 +0300
Ville Syrjälä ville.syrj...@linux.intel.com wrote:
The preempt_disable/enable is not needed. The spinlock serves the same
purpose already.
As stated, that was only for the -rt patch, as spin_lock_irqsave does
not disable preemption nor does it even disable
On Sat, Sep 21, 2013 at 12:07:36AM +0200, Mario Kleiner wrote:
> On 09/17/2013 10:55 PM, Daniel Vetter wrote:
> > On Tue, Sep 17, 2013 at 9:50 PM, Peter Hurley
> > wrote:
> >> On 09/11/2013 03:31 PM, Peter Hurley wrote:
> >>>
> >>> [+cc dri-devel]
> >>>
> >>> On 09/11/2013 11:38 AM, Steven
On Sat, Sep 21, 2013 at 12:07:36AM +0200, Mario Kleiner wrote:
On 09/17/2013 10:55 PM, Daniel Vetter wrote:
On Tue, Sep 17, 2013 at 9:50 PM, Peter Hurley pe...@hurleysoftware.com
wrote:
On 09/11/2013 03:31 PM, Peter Hurley wrote:
[+cc dri-devel]
On 09/11/2013 11:38 AM, Steven
On 09/17/2013 10:55 PM, Daniel Vetter wrote:
On Tue, Sep 17, 2013 at 9:50 PM, Peter Hurley wrote:
On 09/11/2013 03:31 PM, Peter Hurley wrote:
[+cc dri-devel]
On 09/11/2013 11:38 AM, Steven Rostedt wrote:
On Wed, 11 Sep 2013 11:16:43 -0400
Peter Hurley wrote:
The funny part is, there's
On 09/17/2013 10:55 PM, Daniel Vetter wrote:
On Tue, Sep 17, 2013 at 9:50 PM, Peter Hurley pe...@hurleysoftware.com wrote:
On 09/11/2013 03:31 PM, Peter Hurley wrote:
[+cc dri-devel]
On 09/11/2013 11:38 AM, Steven Rostedt wrote:
On Wed, 11 Sep 2013 11:16:43 -0400
Peter Hurley
On 09/17/2013 04:55 PM, Daniel Vetter wrote:
On Tue, Sep 17, 2013 at 9:50 PM, Peter Hurley wrote:
On 09/11/2013 03:31 PM, Peter Hurley wrote:
[+cc dri-devel]
On 09/11/2013 11:38 AM, Steven Rostedt wrote:
On Wed, 11 Sep 2013 11:16:43 -0400
Peter Hurley wrote:
The funny part is, there's
On Wed, Sep 18, 2013 at 6:52 PM, Peter Hurley wrote:
> Ouch. But thanks for clarifying that.
>
> Ok, so register access needs to be serialized. And a separate but
> related concern is that gen6+ resets also need to hold-off register
> access where forcewake is required.
>
>
> While I was
On Wed, Sep 18, 2013 at 12:52:07PM -0400, Peter Hurley wrote:
> On 09/17/2013 04:55 PM, Daniel Vetter wrote:
> > On Tue, Sep 17, 2013 at 9:50 PM, Peter Hurley
> > wrote:
> >> On 09/11/2013 03:31 PM, Peter Hurley wrote:
> >>>
> >>> [+cc dri-devel]
> >>>
> >>> On 09/11/2013 11:38 AM, Steven
On Wed, Sep 18, 2013 at 6:52 PM, Peter Hurley pe...@hurleysoftware.com wrote:
Ouch. But thanks for clarifying that.
Ok, so register access needs to be serialized. And a separate but
related concern is that gen6+ resets also need to hold-off register
access where forcewake is required.
On Wed, Sep 18, 2013 at 12:52:07PM -0400, Peter Hurley wrote:
On 09/17/2013 04:55 PM, Daniel Vetter wrote:
On Tue, Sep 17, 2013 at 9:50 PM, Peter Hurley pe...@hurleysoftware.com
wrote:
On 09/11/2013 03:31 PM, Peter Hurley wrote:
[+cc dri-devel]
On 09/11/2013 11:38 AM, Steven
On 09/17/2013 04:55 PM, Daniel Vetter wrote:
On Tue, Sep 17, 2013 at 9:50 PM, Peter Hurley pe...@hurleysoftware.com wrote:
On 09/11/2013 03:31 PM, Peter Hurley wrote:
[+cc dri-devel]
On 09/11/2013 11:38 AM, Steven Rostedt wrote:
On Wed, 11 Sep 2013 11:16:43 -0400
Peter Hurley
On Tue, Sep 17, 2013 at 9:50 PM, Peter Hurley wrote:
> On 09/11/2013 03:31 PM, Peter Hurley wrote:
>>
>> [+cc dri-devel]
>>
>> On 09/11/2013 11:38 AM, Steven Rostedt wrote:
>>>
>>> On Wed, 11 Sep 2013 11:16:43 -0400
>>> Peter Hurley wrote:
>>>
> The funny part is, there's a comment there
On 09/11/2013 03:31 PM, Peter Hurley wrote:
[+cc dri-devel]
On 09/11/2013 11:38 AM, Steven Rostedt wrote:
On Wed, 11 Sep 2013 11:16:43 -0400
Peter Hurley wrote:
The funny part is, there's a comment there that shows that this was
done even for "PREEMPT_RT". Unfortunately, the call to
On 09/11/2013 03:31 PM, Peter Hurley wrote:
[+cc dri-devel]
On 09/11/2013 11:38 AM, Steven Rostedt wrote:
On Wed, 11 Sep 2013 11:16:43 -0400
Peter Hurley pe...@hurleysoftware.com wrote:
The funny part is, there's a comment there that shows that this was
done even for PREEMPT_RT.
On Tue, Sep 17, 2013 at 9:50 PM, Peter Hurley pe...@hurleysoftware.com wrote:
On 09/11/2013 03:31 PM, Peter Hurley wrote:
[+cc dri-devel]
On 09/11/2013 11:38 AM, Steven Rostedt wrote:
On Wed, 11 Sep 2013 11:16:43 -0400
Peter Hurley pe...@hurleysoftware.com wrote:
The funny part is,
On 11.09.13 21:19, Steven Rostedt wrote:
On Wed, 11 Sep 2013 21:07:10 +0200
Mario Kleiner wrote:
On 11.09.13 20:35, Steven Rostedt wrote:
On Wed, 11 Sep 2013 20:29:07 +0200
Mario Kleiner wrote:
That said, maybe preempt_disable is no longer the optimal choice there
and there's some
On 11.09.13 17:16, Peter Hurley wrote:
On 09/11/2013 09:26 AM, Steven Rostedt wrote:
On Wed, 11 Sep 2013 07:28:09 -0300
"Luis Claudio R. Goncalves" wrote:
Hello,
I saw two different occurrences of "BUG: sleeping function called from
invalid context" happening on 3.10.1
[+cc dri-devel]
On 09/11/2013 11:38 AM, Steven Rostedt wrote:
On Wed, 11 Sep 2013 11:16:43 -0400
Peter Hurley wrote:
The funny part is, there's a comment there that shows that this was
done even for "PREEMPT_RT". Unfortunately, the call to
"get_scanout_position()" can call functions that use
On 11.09.13 20:35, Steven Rostedt wrote:
On Wed, 11 Sep 2013 20:29:07 +0200
Mario Kleiner wrote:
That said, maybe preempt_disable is no longer the optimal choice there
and there's some better way to achieve good protection against
interruptions of that bit of code? My knowledge here is a
On Wed, 11 Sep 2013 21:07:10 +0200
Mario Kleiner wrote:
>
>
> On 11.09.13 20:35, Steven Rostedt wrote:
> > On Wed, 11 Sep 2013 20:29:07 +0200
> > Mario Kleiner wrote:
> >
> >> That said, maybe preempt_disable is no longer the optimal choice there
> >> and there's some better way to achieve
On Wed, 11 Sep 2013 20:29:07 +0200
Mario Kleiner wrote:
> That said, maybe preempt_disable is no longer the optimal choice there
> and there's some better way to achieve good protection against
> interruptions of that bit of code? My knowledge here is a bit rusty, and
> the intel kms drivers
On 09/11/2013 09:26 AM, Steven Rostedt wrote:
On Wed, 11 Sep 2013 07:28:09 -0300
"Luis Claudio R. Goncalves" wrote:
Hello,
I saw two different occurrences of "BUG: sleeping function called from
invalid context" happening on 3.10.10-rt7. The first one happen
On Wed, 11 Sep 2013 11:16:43 -0400
Peter Hurley wrote:
> > The funny part is, there's a comment there that shows that this was
> > done even for "PREEMPT_RT". Unfortunately, the call to
> > "get_scanout_position()" can call functions that use the rt-mutex
> > "sleeping spin locks" and it breaks
On Wed, 11 Sep 2013 07:28:09 -0300
"Luis Claudio R. Goncalves" wrote:
> Hello,
>
> I saw two different occurrences of "BUG: sleeping function called from
> invalid context" happening on 3.10.10-rt7. The first one happened on
> drm_vblank_get() -> i915_g
On Wed, 11 Sep 2013 07:28:09 -0300
Luis Claudio R. Goncalves lclau...@uudg.org wrote:
Hello,
I saw two different occurrences of BUG: sleeping function called from
invalid context happening on 3.10.10-rt7. The first one happened on
drm_vblank_get() - i915_get_vblank_timestamp
On Wed, 11 Sep 2013 11:16:43 -0400
Peter Hurley pe...@hurleysoftware.com wrote:
The funny part is, there's a comment there that shows that this was
done even for PREEMPT_RT. Unfortunately, the call to
get_scanout_position() can call functions that use the rt-mutex
sleeping spin locks and
On 09/11/2013 09:26 AM, Steven Rostedt wrote:
On Wed, 11 Sep 2013 07:28:09 -0300
Luis Claudio R. Goncalves lclau...@uudg.org wrote:
Hello,
I saw two different occurrences of BUG: sleeping function called from
invalid context happening on 3.10.10-rt7. The first one happened on
drm_vblank_get
On Wed, 11 Sep 2013 20:29:07 +0200
Mario Kleiner mario.klei...@tuebingen.mpg.de wrote:
That said, maybe preempt_disable is no longer the optimal choice there
and there's some better way to achieve good protection against
interruptions of that bit of code? My knowledge here is a bit rusty,
On Wed, 11 Sep 2013 21:07:10 +0200
Mario Kleiner mario.klei...@tuebingen.mpg.de wrote:
On 11.09.13 20:35, Steven Rostedt wrote:
On Wed, 11 Sep 2013 20:29:07 +0200
Mario Kleiner mario.klei...@tuebingen.mpg.de wrote:
That said, maybe preempt_disable is no longer the optimal choice
On 11.09.13 20:35, Steven Rostedt wrote:
On Wed, 11 Sep 2013 20:29:07 +0200
Mario Kleiner mario.klei...@tuebingen.mpg.de wrote:
That said, maybe preempt_disable is no longer the optimal choice there
and there's some better way to achieve good protection against
interruptions of that bit of
[+cc dri-devel]
On 09/11/2013 11:38 AM, Steven Rostedt wrote:
On Wed, 11 Sep 2013 11:16:43 -0400
Peter Hurley pe...@hurleysoftware.com wrote:
The funny part is, there's a comment there that shows that this was
done even for PREEMPT_RT. Unfortunately, the call to
get_scanout_position() can
On 11.09.13 17:16, Peter Hurley wrote:
On 09/11/2013 09:26 AM, Steven Rostedt wrote:
On Wed, 11 Sep 2013 07:28:09 -0300
Luis Claudio R. Goncalves lclau...@uudg.org wrote:
Hello,
I saw two different occurrences of BUG: sleeping function called from
invalid context happening on 3.10.10-rt7
On 11.09.13 21:19, Steven Rostedt wrote:
On Wed, 11 Sep 2013 21:07:10 +0200
Mario Kleiner mario.klei...@tuebingen.mpg.de wrote:
On 11.09.13 20:35, Steven Rostedt wrote:
On Wed, 11 Sep 2013 20:29:07 +0200
Mario Kleiner mario.klei...@tuebingen.mpg.de wrote:
That said, maybe
58 matches
Mail list logo
