On Thu, Jul 28, 2011 at 03:50:00PM -0700, Keith Packard wrote:
> On Wed, 27 Jul 2011 09:03:31 -0700, Jesse Barnes virtuousgeek.org> wrote:
> > On Wed, 27 Jul 2011 02:21:24 -0700
> > Keith Packard wrote:
> > > So the work may get executed immediately rather than being run later at
> > > some point
On Thu, Jul 28, 2011 at 03:50:00PM -0700, Keith Packard wrote:
> On Wed, 27 Jul 2011 09:03:31 -0700, Jesse Barnes
> wrote:
> > On Wed, 27 Jul 2011 02:21:24 -0700
> > Keith Packard wrote:
> > > So the work may get executed immediately rather than being run later at
> > > some point?
> >
> > It s
On Wed, 27 Jul 2011 09:03:31 -0700, Jesse Barnes
wrote:
> On Wed, 27 Jul 2011 02:21:24 -0700
> Keith Packard wrote:
>
> > On Tue, 26 Jul 2011 12:12:25 -0700, Jesse Barnes
> > wrote:
> >
> > > I'd like to amend my reviewed by and say the lock shouldn't be held
> > > around the call to the drm
On Wed, 27 Jul 2011 09:03:31 -0700, Jesse Barnes
wrote:
> On Wed, 27 Jul 2011 02:21:24 -0700
> Keith Packard wrote:
>
> > On Tue, 26 Jul 2011 12:12:25 -0700, Jesse Barnes > virtuousgeek.org> wrote:
> >
> > > I'd like to amend my reviewed by and say the lock shouldn't be held
> > > around the
On Wed, 27 Jul 2011 02:21:24 -0700
Keith Packard wrote:
> On Tue, 26 Jul 2011 12:12:25 -0700, Jesse Barnes
> wrote:
>
> > I'd like to amend my reviewed by and say the lock shouldn't be held
> > around the call to the drm helper function. It queues some work that
> > also takes the mode config
On Wed, 27 Jul 2011 02:21:24 -0700
Keith Packard wrote:
> On Tue, 26 Jul 2011 12:12:25 -0700, Jesse Barnes virtuousgeek.org> wrote:
>
> > I'd like to amend my reviewed by and say the lock shouldn't be held
> > around the call to the drm helper function. It queues some work that
> > also takes
On Tue, 26 Jul 2011 12:12:25 -0700, Jesse Barnes
wrote:
> I'd like to amend my reviewed by and say the lock shouldn't be held
> around the call to the drm helper function. It queues some work that
> also takes the mode config lock, which will break. So you can drop it
> before that... Previou
On Tue, 26 Jul 2011 12:12:25 -0700, Jesse Barnes
wrote:
> I'd like to amend my reviewed by and say the lock shouldn't be held
> around the call to the drm helper function. It queues some work that
> also takes the mode config lock, which will break. So you can drop it
> before that... Previou
On Tue, 26 Jul 2011 08:23:13 -0700
Keith Packard wrote:
> On Tue, 26 Jul 2011 09:24:39 +0200, Daniel Vetter wrote:
> > Two things I've noticed:
>
> > - Why not dev->mode_config.mutex?
>
> You're right, of course. I noticed that just after posting that version
> and updated it; the updated vers
On Tue, 26 Jul 2011 08:23:13 -0700
Keith Packard wrote:
> On Tue, 26 Jul 2011 09:24:39 +0200, Daniel Vetter wrote:
> > Two things I've noticed:
>
> > - Why not dev->mode_config.mutex?
>
> You're right, of course. I noticed that just after posting that version
> and updated it; the updated vers
Two things I've noticed:
- Why not dev->mode_config.mutex? I was under the impression that
mode_config.mutex protects most of the modesetting state and
dev->struct_mutex protects things related to the gpu execution cores
(i.e. all things gem), with struct_mutex nested within
mode_config.mutex. It's
On Tue, Jul 26, 2011 at 1:54 AM, Keith Packard wrote:
> From 59b920597999381fab70c485c161dd50590e561a Mon Sep 17 00:00:00 2001
> From: Keith Packard
> Date: Mon, 25 Jul 2011 22:37:51 -0700
> Subject: [PATCH] Revert and fix "drm/i915/dp: remove DPMS mode tracking from
> ?DP"
>
> This reverts commi
On Tue, 26 Jul 2011 09:24:39 +0200, Daniel Vetter wrote:
> Two things I've noticed:
> - Why not dev->mode_config.mutex?
You're right, of course. I noticed that just after posting that version
and updated it; the updated version is on my drm-intel-fixes branch
already (having been reviewed by Jes
On Tue, 26 Jul 2011 09:24:39 +0200, Daniel Vetter wrote:
> Two things I've noticed:
> - Why not dev->mode_config.mutex?
You're right, of course. I noticed that just after posting that version
and updated it; the updated version is on my drm-intel-fixes branch
already (having been reviewed by Jes
On Tue, Jul 26, 2011 at 1:54 AM, Keith Packard wrote:
> From 59b920597999381fab70c485c161dd50590e561a Mon Sep 17 00:00:00 2001
> From: Keith Packard
> Date: Mon, 25 Jul 2011 22:37:51 -0700
> Subject: [PATCH] Revert and fix "drm/i915/dp: remove DPMS mode tracking from
> DP"
>
> This reverts commi
Two things I've noticed:
- Why not dev->mode_config.mutex? I was under the impression that
mode_config.mutex protects most of the modesetting state and
dev->struct_mutex protects things related to the gpu execution cores
(i.e. all things gem), with struct_mutex nested within
mode_config.mutex. It's
On Mon, 25 Jul 2011 22:52:15 -0400, Andrew Lutomirski wrote:
> Doesn't help :(
Oh, it helps, just not this issue :-)
> When I do 'xset dpms force off', one of two things happens. Either
> the display comes back all by itself or it never comes back until I
> power cycle it.
Oh. Right. Actual D
On Mon, 25 Jul 2011 22:52:15 -0400, Andrew Lutomirski wrote:
> Doesn't help :(
Oh, it helps, just not this issue :-)
> When I do 'xset dpms force off', one of two things happens. Either
> the display comes back all by itself or it never comes back until I
> power cycle it.
Oh. Right. Actual D
On Mon, Jul 25, 2011 at 1:37 PM, Jesse Barnes
wrote:
> On Mon, 25 Jul 2011 10:10:29 -0700
> Keith Packard wrote:
>
>> Hotplug detection is a mode setting operation and must hold the
>> struct_mutex or risk colliding with other mode setting operations.
>>
>> In particular, the display port hotplu
On Mon, Jul 25, 2011 at 1:37 PM, Jesse Barnes wrote:
> On Mon, 25 Jul 2011 10:10:29 -0700
> Keith Packard wrote:
>
>> Hotplug detection is a mode setting operation and must hold the
>> struct_mutex or risk colliding with other mode setting operations.
>>
>> In particular, the display port hotplug
Will test tonight.
It looks like there is a lot of hotplug activity when 'xset dpms force
off' gets run. (That's not a typo. I do mean "off," not "on."
See attached trace. perf rocks, even over ssh :)
--Andy
On Mon, Jul 25, 2011 at 1:37 PM, Jesse Barnes
wrote:
> On Mon, 25 Jul 2011 10:10:2
On Mon, 25 Jul 2011 13:40:58 -0400, Andrew Lutomirski wrote:
> Will test tonight.
Thanks.
> It looks like there is a lot of hotplug activity when 'xset dpms force
> off' gets run. (That's not a typo. I do mean "off," not "on."
Yup, that's what I've seen as well -- do a mode set to turn stuf
On Mon, 25 Jul 2011 13:40:58 -0400, Andrew Lutomirski wrote:
> Will test tonight.
Thanks.
> It looks like there is a lot of hotplug activity when 'xset dpms force
> off' gets run. (That's not a typo. I do mean "off," not "on."
Yup, that's what I've seen as well -- do a mode set to turn stuf
Will test tonight.
It looks like there is a lot of hotplug activity when 'xset dpms force
off' gets run. (That's not a typo. I do mean "off," not "on."
See attached trace. perf rocks, even over ssh :)
--Andy
On Mon, Jul 25, 2011 at 1:37 PM, Jesse Barnes wrote:
> On Mon, 25 Jul 2011 10:10:29
On Mon, 25 Jul 2011 10:10:29 -0700
Keith Packard wrote:
> Hotplug detection is a mode setting operation and must hold the
> struct_mutex or risk colliding with other mode setting operations.
>
> In particular, the display port hotplug function attempts to re-train
> the link if the monitor is su
On Mon, 25 Jul 2011 10:10:29 -0700
Keith Packard wrote:
> Hotplug detection is a mode setting operation and must hold the
> struct_mutex or risk colliding with other mode setting operations.
>
> In particular, the display port hotplug function attempts to re-train
> the link if the monitor is su
26 matches
Mail list logo
