On Sun, 4 Sep 2011 20:52:42 -0700
Ben Widawsky wrote:
> While I think the previous code is correct, it was hard to follow and
> hard to debug. Since we already have a ring abstraction, might as well
> use it to handle the semaphore updates and compares.
>
> I don't expect this code to make sema
Add ELD support for Intel Eaglelake, IbexPeak/Ironlake,
SandyBridge/CougarPoint and IvyBridge/PantherPoint chips.
ELD (EDID-Like Data) describes to the HDMI/DP audio driver the audio
capabilities of the plugged monitor. It's built and passed to audio
driver in 2 steps:
(1) at get_modes time, pars
On Mon, 5 Sep 2011 08:38:07 +0200
Daniel Vetter wrote:
> On Sun, Sep 04, 2011 at 09:38:56PM +, Ben Widawsky wrote:
> > Oops, you're totally right, I think I meant:
> > - I915_WRITE(GEN6_PMIMR, pm_imr & ~pm_iir);
> > + I915_WRITE(GEN6_PMIMR, dev_priv->pm_iir);
>
> Imo still racy w
I'd like to do more cleanups:
> + int aud_cntl_st;
> + int aud_cntrl_st2;
s/aud_cntrl_st2/aud_cntl_st2/
> + if (IS_IVYBRIDGE(connector->dev)) {
> + hdmiw_hdmiedid = GEN7_HDMIW_HDMIEDID_A;
> + aud_cntl_st = GEN7_AUD_CNTRL_ST_A;
> + aud_cntrl_st2 = G
On Sun, Sep 04, 2011 at 09:38:56PM +, Ben Widawsky wrote:
> Oops, you're totally right, I think I meant:
> - I915_WRITE(GEN6_PMIMR, pm_imr & ~pm_iir);
> + I915_WRITE(GEN6_PMIMR, dev_priv->pm_iir);
Imo still racy without the irqsafe rps_lock around it. gcc is free to
compile that in
Add ELD support for Intel Eaglelake, IbexPeak/Ironlake,
SandyBridge/CougarPoint and IvyBridge/PantherPoint chips.
ELD (EDID-Like Data) describes to the HDMI/DP audio driver the audio
capabilities of the plugged monitor. It's built and passed to audio
driver in 2 steps:
(1) at get_modes time, pars
ELD (EDID-Like Data) describes to the HDMI/DP audio driver the audio
capabilities of the plugged monitor.
This adds drm_edid_to_eld() for converting EDID to ELD. The converted
ELD will be saved in a new drm_connector.eld[128] data field. This is
necessary because the graphics driver will need to f
While I think the previous code is correct, it was hard to follow and
hard to debug. Since we already have a ring abstraction, might as well
use it to handle the semaphore updates and compares.
I don't expect this code to make semaphores better or worse, but you
never know...
Cc: Chris Wilson
Cc
On Sun, Sep 04, 2011 at 06:57:23PM +0800, James Cloos wrote:
> > "WF" == Wu Fengguang writes:
>
> WF> ... If only the stereo playback capability is reported, the user
> WF> won't be able to start 8-channel playback; if the 8-channel ELD is
> WF> reported, then user space applications may send
On Sun, Sep 04, 2011 at 08:08:37PM +0800, Chris Wilson wrote:
> On Sun, 4 Sep 2011 05:15:10 +0800, Wu Fengguang
> wrote:
> > Changes from v4: remove a debug call to dump_stack().
> > Thanks to Bossart for catching this!
> > ---
> >
> > Add ELD support for Intel Eaglelake, IbexPeak/Ironlake,
> >
Dear Paul,
On Sun, Sep 04, 2011 at 07:11:54PM +0800, Paul Menzel wrote:
> Dear Wu,
>
>
> I hope that is your first name.
My first name is Fengguang. "LAST NAME, FIRSTNAME" is the convention
in Intel emails. However I often forgot this and pick whatever comes
first...and happily accept both Feng
On Sun, Sep 04, 2011 at 10:10:30PM +0200, Daniel Vetter wrote:
> On Sun, Sep 04, 2011 at 07:56:57PM +, Ben Widawsky wrote:
> > On Sun, Sep 04, 2011 at 09:26:48PM +0200, Daniel Vetter wrote:
> > > On Sun, Sep 04, 2011 at 10:08:17AM -0700, Ben Widawsky wrote:
> > > > diff --git a/drivers/gpu/drm/
On Sun, Sep 04, 2011 at 07:56:57PM +, Ben Widawsky wrote:
> On Sun, Sep 04, 2011 at 09:26:48PM +0200, Daniel Vetter wrote:
> > On Sun, Sep 04, 2011 at 10:08:17AM -0700, Ben Widawsky wrote:
> > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > b/drivers/gpu/drm/i915/i915_irq.c
> > > index 55
On Sun, Sep 04, 2011 at 07:50:08PM +, Ben Widawsky wrote:
> So I would rework some of your comments a bit, and I also think it's
> about time we create a central place to cancel workqueue items. Mostly
> because I think this patch is subject to a deadlock with struct_mutex
> (you're holding it
On Sun, Sep 04, 2011 at 09:26:48PM +0200, Daniel Vetter wrote:
> On Sun, Sep 04, 2011 at 10:08:17AM -0700, Ben Widawsky wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 55518e3..3bc1479 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++
On Sun, Sep 04, 2011 at 09:17:24PM +0200, Daniel Vetter wrote:
> > > spin_lock_irq(&dev_priv->rps_lock);
> > > dev_priv->pm_iir = 0;
> > > + I915_WRITE(GEN6_PMIER, 0);
> > > spin_unlock_irq(&dev_priv->rps_lock);
> > >
> > > I915_WRITE(GEN6_PMIIR, I915_READ(GEN6_PMIIR));
> > I'm not sure t
On Sun, Sep 04, 2011 at 10:08:17AM -0700, Ben Widawsky wrote:
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 55518e3..3bc1479 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -415,12 +415,7 @@ static void gen6_pm_r
On Sun, Sep 04, 2011 at 05:23:30PM +, Ben Widawsky wrote:
> On Sun, Sep 04, 2011 at 05:35:02PM +0200, Daniel Vetter wrote:
> > The rps disabling code wasn't properly cancelling outstanding work
> > items. Also add a comment that explains why we're not racing with
> > the work item, that could a
On Sun, Sep 04, 2011 at 05:35:02PM +0200, Daniel Vetter wrote:
> The rps disabling code wasn't properly cancelling outstanding work
> items. Also add a comment that explains why we're not racing with
> the work item, that could again unmask interrupts.
>
> This also fixes a bug on module unload be
On Sun, 4 Sep 2011 17:35:00 +0200
Daniel Vetter wrote:
> Quoting Chris Wilson's more concise description:
>
> "Ah I think I see the problem. As you point out we only mask the
> current interrupt received, so that if we have a task pending (and so
> IMR != 0) we actually unmask the pending inter
On Sun, 4 Sep 2011 17:35:01 +0200
Daniel Vetter wrote:
> This patch closes the following race:
>
> We get a PM interrupt A, mask it, set dev_priv->iir = PM_A and kick
> of the work item. Scheduler isn't grumpy, so the work queue takes
> rps_lock, grabs pm_iir = dev_priv->pm_iir and pm_imr = REA
The rps disabling code wasn't properly cancelling outstanding work
items. Also add a comment that explains why we're not racing with
the work item, that could again unmask interrupts.
This also fixes a bug on module unload because nothing was properly
syncing up with that work item, possibly leadi
This patch closes the following race:
We get a PM interrupt A, mask it, set dev_priv->iir = PM_A and kick of the
work item. Scheduler isn't grumpy, so the work queue takes rps_lock,
grabs pm_iir = dev_priv->pm_iir and pm_imr = READ(PMIMR). Note that
pm_imr == pm_iir because we've just masked the i
Quoting Chris Wilson's more concise description:
"Ah I think I see the problem. As you point out we only mask the
current interrupt received, so that if we have a task pending (and so
IMR != 0) we actually unmask the pending interrupt and so could
receive it again before the tasklet is finally kic
Hi all,
Let's have some new ideas for races around the rps code.
Not yet tested (I can't hit the WARN anyway in my testing), I've just
wanted to get this out for discussion.
Yours, Daniel
Daniel Vetter (3):
drm/i915: close PM interrupt masking races in the irq handler
drm/i915: close PM int
On Sun, 04 Sep 2011 10:03:21 +0100
Chris Wilson wrote:
> On Sat, 3 Sep 2011 20:24:15 -0700, Ben Widawsky
> wrote:
> > I couldn't reproduce this one, but... Interrupt mask state is lost
> > if three interrupts occur before the workqueue has run.
> >
> > Should be straight forward to reproduce
On Sun, 4 Sep 2011 05:15:10 +0800, Wu Fengguang wrote:
> Changes from v4: remove a debug call to dump_stack().
> Thanks to Bossart for catching this!
> ---
>
> Add ELD support for Intel Eaglelake, IbexPeak/Ironlake,
> SandyBridge/CougarPoint and IvyBridge/PantherPoint chips.
>
> ELD (EDID-Like D
Dear Wu,
I hope that is your first name.
Am Sonntag, den 04.09.2011, 05:15 +0800 schrieb Wu Fengguang:
> Changes from v4: remove a debug call to dump_stack().
> Thanks to Bossart for catching this!
His first name is Pierre-Louis. I do not know how you address people at
Intel though.
> ---
I t
> "WF" == Wu Fengguang writes:
WF> ... If only the stereo playback capability is reported, the user
WF> won't be able to start 8-channel playback; if the 8-channel ELD is
WF> reported, then user space applications may send 8-channel samples
WF> down, however the user may actually be listening
On Sat, 3 Sep 2011 20:24:15 -0700, Ben Widawsky wrote:
> I couldn't reproduce this one, but... Interrupt mask state is lost if
> three interrupts occur before the workqueue has run.
>
> Should be straight forward to reproduce even without SMP. I'm pretty
> sure Dan Vetter was trying to explain
30 matches
Mail list logo
