On Wed, 29 Dec 2010 22:11:09 +0100
Alex Riesen wrote:
> On Wed, Dec 29, 2010 at 21:16, Jesse Barnes
> wrote:
> > On Wed, 29 Dec 2010 11:40:04 -0800
> > Linus Torvalds wrote:
> >> Chris - why did that lvds_ssc_freq thing suddenly start mattering? Can
> >> we
/* force disable until we can parse this correctly */
+ if (IS_GEN5(dev) || IS_GEN6(dev))
+ dev_priv->lvds_use_ssc = 0;
if (dev_priv->lvds_use_ssc) {
if (IS_I85X(dev))
--
Jesse Barnes, Intel Open Source Technology
/* force disable until we can parse this correctly */
+ if (IS_GEN5(dev) || IS_GEN6(dev))
+ dev_priv->lvds_use_ssc = 0;
if (dev_priv->lvds_use_ssc) {
if (IS_I85X(dev))
--
Jesse Barnes, Intel Open Source Technology Center
t use SSC on this platform" making the frequency
field meaningless.
We'll figure it out or disable SSC enabling altogether failing that
(risking interference with other components like wireless and sound).
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
t use SSC on this platform" making the frequency
field meaningless.
We'll figure it out or disable SSC enabling altogether failing that
(risking interference with other components like wireless and sound).
--
Jesse Barnes, Intel Open Source Technology Center
Aggressively disable vblanks
> > To: Andy Lutomirski , Jesse Barnes
> > , Chris Wilson ,
> > David Airlie
> > Cc: intel-...@lists.freedesktop.org, dri-devel@lists.freedesktop.org
> > Message-ID:
> > Content-Type: text/plain; charset="us-as
Aggressively disable vblanks
> > To: Andy Lutomirski , Jesse Barnes
> > , Chris Wilson > chris-wilson.co.uk>,
> > David Airlie
> > Cc: intel-gfx at lists.freedesktop.org, dri-devel at lists.freedesktop.org
> > Message-ID:
> > Content-Type: t
t
using simple bridge routing.
Acked-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
_vblank from
> userspace for testing? I know approximately nothing about libdrm or
> any userspace graphics stuff whatsoever.
Yeah, libdrm has a test program called vbltest; it should do what you
need.
--
Jesse Barnes, Intel Open Source Technology Center
all drm_wait_vblank from
> userspace for testing? I know approximately nothing about libdrm or
> any userspace graphics stuff whatsoever.
Yeah, libdrm has a test program called vbltest; it should do what you
need.
--
Jesse Barnes, Intel Open Source Technology Center
t
using simple bridge routing.
Acked-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
On Mon, 13 Dec 2010 18:21:20 +0100
Mario Kleiner wrote:
> On Dec 10, 2010, at 6:45 PM, Jesse Barnes wrote:
>
> > On Fri, 10 Dec 2010 16:00:19 +0100
> > Mario Kleiner wrote:
> >
> >>
> >>
> >> Original Message
> >>
On Mon, 13 Dec 2010 18:21:20 +0100
Mario Kleiner wrote:
> On Dec 10, 2010, at 6:45 PM, Jesse Barnes wrote:
>
> > On Fri, 10 Dec 2010 16:00:19 +0100
> > Mario Kleiner wrote:
> >
> >>
> >>
> >> Original Message
> >>
uest.sequence);
But this actually causes us to return the current count rather than the
requested count if the event requested is in the past, right?
> } else {
> list_add_tail(&e->base.link, &dev->vblank_event_list);
> + vblwait->reply.sequence =
request.sequence);
But this actually causes us to return the current count rather than the
requested count if the event requested is in the past, right?
> } else {
> list_add_tail(&e->base.link, &dev->vblank_event_list);
> + vblwait->reply
On Thu, 09 Dec 2010 20:33:18 +0300
Sergej Pupykin wrote:
> At Thu, 9 Dec 2010 09:18:14 -0800,
> Jesse Barnes wrote:
> >
> > On Wed, 8 Dec 2010 15:30:26 -0800
> > Greg KH wrote:
> > > What kernel version did these options first show up in? Does any
>
On Thu, 09 Dec 2010 20:33:18 +0300
Sergej Pupykin wrote:
> At Thu, 9 Dec 2010 09:18:14 -0800,
> Jesse Barnes wrote:
> >
> > On Wed, 8 Dec 2010 15:30:26 -0800
> > Greg KH wrote:
> > > What kernel version did these options first show up in? Does any
>
m_connector_enum_list[] =
> > { DRM_MODE_CONNECTOR_SVIDEO, "SVIDEO", 0 },
> > { DRM_MODE_CONNECTOR_LVDS, "LVDS", 0 },
> > { DRM_MODE_CONNECTOR_Component, "Component", 0 },
> > - { DRM_MODE_CONNECTOR_9PinDIN, "9-pin DIN", 0 }
m_connector_enum_list[] =
> > { DRM_MODE_CONNECTOR_SVIDEO, "SVIDEO", 0 },
> > { DRM_MODE_CONNECTOR_LVDS, "LVDS", 0 },
> > { DRM_MODE_CONNECTOR_Component, "Component", 0 },
> > - { DRM_MODE_CONNECTOR_9PinDIN, "9-pin DIN", 0 }
On Wed, 1 Dec 2010 19:41:31 +
Chris Wilson wrote:
> Signed-off-by: Chris Wilson
> Cc: Kristian Høgsberg
> Cc: Jesse Barnes
> ---
> drivers/gpu/drm/drm_irq.c | 19 ++-
> 1 files changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/dri
On Wed, 1 Dec 2010 19:41:31 +
Chris Wilson wrote:
> Signed-off-by: Chris Wilson
> Cc: Kristian H?gsberg
> Cc: Jesse Barnes
> ---
> drivers/gpu/drm/drm_irq.c | 19 ++-
> 1 files changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/dri
to volunteer to maintain this subsystem (I know
how much you love backlights, maybe you'd like to do it?) or you need to
get this patch over to akpm.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists
to volunteer to maintain this subsystem (I know
how much you love backlights, maybe you'd like to do it?) or you need to
get this patch over to akpm.
--
Jesse Barnes, Intel Open Source Technology Center
short circuit it before that.
So we should probably do it in setup_outputs or init_display once we've
figured out there's no LVDS. It's cool that the panel fitter still has
an effect even on non-LVDS platforms though, maybe we really should
treat it as a part of the CRTC
short circuit it before that.
So we should probably do it in setup_outputs or init_display once we've
figured out there's no LVDS. It's cool that the panel fitter still has
an effect even on non-LVDS platforms though, maybe we really should
treat it as a part of the CRTC rather than the LVDS encoder after all.
--
Jesse Barnes, Intel Open Source Technology Center
On Mon, 18 Oct 2010 21:57:05 +0200
Arnd Bergmann wrote:
> On Monday 18 October 2010 21:28:01 Jesse Barnes wrote:
> >
> > On Mon, 18 Oct 2010 21:13:59 +0200
> > Arnd Bergmann wrote:
> >
> > > On Monday 18 October 2010 20:56:48 Jesse Barnes wrote:
> >
On Mon, 18 Oct 2010 21:57:05 +0200
Arnd Bergmann wrote:
> On Monday 18 October 2010 21:28:01 Jesse Barnes wrote:
> >
> > On Mon, 18 Oct 2010 21:13:59 +0200
> > Arnd Bergmann wrote:
> >
> > > On Monday 18 October 2010 20:56:48 Jesse Barnes wrote:
> >
On Mon, 18 Oct 2010 21:13:59 +0200
Arnd Bergmann wrote:
> On Monday 18 October 2010 20:56:48 Jesse Barnes wrote:
> > Hm, the LVDS code should take care of panel fitting in
> > the !HAS_PCH_SPLIT case. Does this patch achieve the same thing as
> > yours? Maybe we were leavi
On Mon, 18 Oct 2010 21:13:59 +0200
Arnd Bergmann wrote:
> On Monday 18 October 2010 20:56:48 Jesse Barnes wrote:
> > Hm, the LVDS code should take care of panel fitting in
> > the !HAS_PCH_SPLIT case. Does this patch achieve the same thing as
> > yours? Maybe we were leavi
_fitter_pipe(struct drm_device *dev)
> +int intel_panel_fitter_pipe(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> u32 pfit_control;
>
Hm, the LVDS code should take care of panel fitting in
the !HAS_PCH_SPLIT case. Does this p
_fitter_pipe(struct drm_device *dev)
> +int intel_panel_fitter_pipe(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> u32 pfit_control;
>
Hm, the LVDS code should take care of panel fitting in
the !HAS_PCH_SPLIT case. Does this p
On Tue, 12 Oct 2010 10:46:52 -0500
Jason Wessel wrote:
> On 10/12/2010 10:38 AM, Jesse Barnes wrote:
> > On Tue, 12 Oct 2010 07:49:59 -0500
> > Jason Wessel wrote:
> >
> >
> >> Some devices such as the pre nv02 chips have enter and exit
> >> c
On Tue, 12 Oct 2010 10:46:52 -0500
Jason Wessel wrote:
> On 10/12/2010 10:38 AM, Jesse Barnes wrote:
> > On Tue, 12 Oct 2010 07:49:59 -0500
> > Jason Wessel wrote:
> >
> >
> >> Some devices such as the pre nv02 chips have enter and exit
> >> c
call to pass an argument
> to indicate if this is an entry or an exit from an atomic kernel mode
> set change. Individual drm drivers can properly save and restore
> state accordingly.
>
> Signed-off-by: Jason Wessel
> CC: Jesse Barnes
> CC: David Airlie
> CC: dri-devel at
call to pass an argument
> to indicate if this is an entry or an exit from an atomic kernel mode
> set change. Individual drm drivers can properly save and restore
> state accordingly.
>
> Signed-off-by: Jason Wessel
> CC: Jesse Barnes
> CC: David Airlie
> CC: dri-devel@lis
out, you're stuck fumbling
>> around in the dark trying to run 'xrandr' again.
>
>don't you do this already? both radeon/nouveau handle DP replug fine,
>I thought Intel would have been where I stole the code from.
There is some code to handle the interrupts, but I
out, you're stuck fumbling
>> ? ?around in the dark trying to run 'xrandr' again.
>
>don't you do this already? both radeon/nouveau handle DP replug fine,
>I thought Intel would have been where I stole the code from.
There is some code to handle the interrupts, but I
"Keith Packard" wrote:
>On Sun, 3 Oct 2010 08:10:48 -0700, Jesse Barnes
>wrote:
>
>> Do these fixes help with the DP issues you've been seeing, Keith?
>> Seems like the first one shouldn't change behavior since we ought to
>> time out on waiting
"Keith Packard" wrote:
>On Sun, 3 Oct 2010 08:10:48 -0700, Jesse Barnes
>wrote:
>
>> Do these fixes help with the DP issues you've been seeing, Keith?
>> Seems like the first one shouldn't change behavior since we ought to
>> time out on waiting
Seems like the first one shouldn't change behavior since we ought to
time out on waiting on vblank in that case, and the timeout is the same
as the msleep we used to use.
The second one looks like a good change, but really the pipe off change
is separate from the plane disable bug fix.
Seems like the first one shouldn't change behavior since we ought to
time out on waiting on vblank in that case, and the timeout is the same
as the msleep we used to use.
The second one looks like a good change, but really the pipe off change
is separate from the plane disable bug fix.
--
Jesse Barnes, Intel Open Source Technology Center
code is causing problems.
>
> If driver is utilising invalidate events detection can't happen in server
> side.
We could print a warning in this case at the very least. Maybe if we
try to swap again with the same dri2 invalidate stamp we could print an
error. Kristi
code is causing problems.
>
> If driver is utilising invalidate events detection can't happen in server
> side.
We could print a warning in this case at the very least. Maybe if we
try to swap again with the same dri2 invalidate stamp we could print an
error. Kristian?
Jesse
--
Jesse Barnes, Intel Open Source Technology Center
#endif /* __alpha__ */
>
> +#ifdef CONFIG_PCI
> return pci_domain_nr(dev->pdev->bus);
> +#else
> + return 0;
> +#endif
> }
>
> #if __OS_HAS_AGP
I think we fixed this, but I guess Linus hasn't pulled my tree yet...
--
Jesse Barnes, Intel Open Sourc
#endif /* __alpha__ */
>
> +#ifdef CONFIG_PCI
> return pci_domain_nr(dev->pdev->bus);
> +#else
> + return 0;
> +#endif
> }
>
> #if __OS_HAS_AGP
I think we fixed this, but I guess Linus hasn't pulled my tree yet...
--
Jesse Barnes, Intel Open Source Technology Center
d *startwrite, *startread;
> int offset;
> - int bytesperline = dev->vbi_width;
> + int bytesperline;
>
> if (dev == NULL) {
> em28xx_isocdbg("dev is null\n");
> return;
> }
> + bytesperline = dev->v
d *startwrite, *startread;
> int offset;
> - int bytesperline = dev->vbi_width;
> + int bytesperline;
>
> if (dev == NULL) {
> em28xx_isocdbg("dev is null\n");
> return;
> }
> + bytesperline = dev->v
oblems all because of this
line? Maybe because we wait for a longer period here now? Can you
check and see if we're timing out in the wait_for_vblank function?
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
oblems all because of this
line? Maybe because we wait for a longer period here now? Can you
check and see if we're timing out in the wait_for_vblank function?
--
Jesse Barnes, Intel Open Source Technology Center
.
Wait for vblank off will spin until the display line reg stops
incrementing, so it's important that we flush any previous writes to
shut off the pipe before waiting. So adding a POSTING_READ() above it
might help? But that still doesn't explai
.
Wait for vblank off will spin until the display line reg stops
incrementing, so it's important that we flush any previous writes to
shut off the pipe before waiting. So adding a POSTING_READ() above it
might help? But that still doesn't explain why it would cause the
hangcheck timer to notice a hang...
--
Jesse Barnes, Intel Open Source Technology Center
though, whitespace isn't top of my
> priorities most days.
I think you should just reject it, unless it comes as part of a series
with actual work in it. At least that's been my policy lately...
--
Jesse Barnes, Intel Open Source Technology Center
___
though, whitespace isn't top of my
> priorities most days.
I think you should just reject it, unless it comes as part of a series
with actual work in it. At least that's been my policy lately...
--
Jesse Barnes, Intel Open Source Technology Center
On Tue, 20 Jul 2010 16:34:39 -0700
Jesse Barnes wrote:
> On Wed, 21 Jul 2010 09:27:54 +1000
> Dave Airlie wrote:
>
> > On Tue, 2010-07-20 at 16:05 -0700, Jesse Barnes wrote:
> > > On Wed, 21 Jul 2010 08:54:30 +1000
> > > Dave Airlie wrote:
> > >
On Tue, 20 Jul 2010 16:34:39 -0700
Jesse Barnes wrote:
> On Wed, 21 Jul 2010 09:27:54 +1000
> Dave Airlie wrote:
>
> > On Tue, 2010-07-20 at 16:05 -0700, Jesse Barnes wrote:
> > > On Wed, 21 Jul 2010 08:54:30 +1000
> > > Dave Airlie wrote:
> > >
On Wed, 21 Jul 2010 09:27:54 +1000
Dave Airlie wrote:
> On Tue, 2010-07-20 at 16:05 -0700, Jesse Barnes wrote:
> > On Wed, 21 Jul 2010 08:54:30 +1000
> > Dave Airlie wrote:
> >
> > > On Tue, 2010-07-20 at 15:44 -0700, Jesse Barnes wrote:
> > > &
On Wed, 21 Jul 2010 09:27:54 +1000
Dave Airlie wrote:
> On Tue, 2010-07-20 at 16:05 -0700, Jesse Barnes wrote:
> > On Wed, 21 Jul 2010 08:54:30 +1000
> > Dave Airlie wrote:
> >
> > > On Tue, 2010-07-20 at 15:44 -0700, Jesse Barnes wrote:
> > > &
On Wed, 21 Jul 2010 08:54:30 +1000
Dave Airlie wrote:
> On Tue, 2010-07-20 at 15:44 -0700, Jesse Barnes wrote:
> > Make drm_edid_read take a new argument, edid_read, to allow drivers to
> > provide their own EDID fetch routine. Export the bit banging DDC over
> > i2
On Wed, 21 Jul 2010 08:54:30 +1000
Dave Airlie wrote:
> On Tue, 2010-07-20 at 15:44 -0700, Jesse Barnes wrote:
> > Make drm_edid_read take a new argument, edid_read, to allow drivers to
> > provide their own EDID fetch routine. Export the bit banging DDC over
> > i2
Use the GMBUS interface rather than direct bit banging to grab the EDID
over DDC. The hope is that this method will be more reliable than bit
banging for fetching EDIDs from buggy monitors or through switches.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_reg.h| 52
Make drm_edid_read take a new argument, edid_read, to allow drivers to
provide their own EDID fetch routine. Export the bit banging DDC over
i2c version of the EDID fetching routine and make the drivers use it.
This sets the stage for GMBUS support in the Intel driver.
Signed-off-by: Jesse
Use the GMBUS interface rather than direct bit banging to grab the EDID
over DDC. The hope is that this method will be more reliable than bit
banging for fetching EDIDs from buggy monitors or through switches.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_reg.h| 52
Make drm_edid_read take a new argument, edid_read, to allow drivers to
provide their own EDID fetch routine. Export the bit banging DDC over
i2c version of the EDID fetching routine and make the drivers use it.
This sets the stage for GMBUS support in the Intel driver.
Signed-off-by: Jesse
iguration into something they couldn't change. :)
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
iguration into something they couldn't change. :)
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
> kept opaque to the kernel as well and left open to interpretation by
> userland. What I am most unclear about is under which circumstances is
> this backchannel communication preferable to passing the extra information
> over the IPC that needs to be performed anyway in order
es should be
> kept opaque to the kernel as well and left open to interpretation by
> userland. What I am most unclear about is under which circumstances is
> this backchannel communication preferable to passing the extra information
> over the IPC that needs to be performed anyway in
f. Much of the
drm source has doxygen rather than kdoc style comments though, I need
to clean those up before I can actually include the source generated
info in the drm.tmpl.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
f. Much of the
drm source has doxygen rather than kdoc style comments though, I need
to clean those up before I can actually include the source generated
info in the drm.tmpl.
--
Jesse Barnes, Intel Open Source Technology Center
ow it won't light up" bug).
Signed-off-by: Jesse Barnes
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index b3779d2..32f67cb 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -315,8 +315,9 @@ static void drm_fb_helper_on(s
ow it won't light up" bug).
Signed-off-by: Jesse Barnes
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index b3779d2..32f67cb 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -315,8 +315,9 @@ static void drm_fb_helper_on(s
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_trace.h| 36 ++
drivers/gpu/drm/i915/intel_display.c |5
2 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915
Allows us to track each process that requests and completes events.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_irq.c |8 ++
drivers/gpu/drm/drm_trace.h | 57 --
include/drm/drmP.h |2 +
3 files changed, 53 insertions
Emit a trace point for vblank events. This can be helpful for mapping
drawing activity against the vblank frequency and period.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/Makefile |5 +++-
drivers/gpu/drm/drm_irq.c |3 ++
drivers/gpu/drm/drm_trace.h
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_trace.h| 36 ++
drivers/gpu/drm/i915/intel_display.c |5
2 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915
Allows us to track each process that requests and completes events.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_irq.c |8 ++
drivers/gpu/drm/drm_trace.h | 57 --
include/drm/drmP.h |2 +
3 files changed, 53 insertions
Emit a trace point for vblank events. This can be helpful for mapping
drawing activity against the vblank frequency and period.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/Makefile |5 +++-
drivers/gpu/drm/drm_irq.c |3 ++
drivers/gpu/drm/drm_trace.h
ic daily tests? To unload you need to unbind the fbcon interface
first, my script is like this:
echo 0 > /sys/class/vtconsole/vtcon1/bind
rmmod i915
rmmod drm_kms_helper
rmmod drm
modprobe i915
echo 1 > /sys/class/vtconsole/vtcon1/bind
If unload and re-load doesn't work please fi
ic daily tests? To unload you need to unbind the fbcon interface
first, my script is like this:
echo 0 > /sys/class/vtconsole/vtcon1/bind
rmmod i915
rmmod drm_kms_helper
rmmod drm
modprobe i915
echo 1 > /sys/class/vtconsole/vtcon1/bind
If unload and re-load doesn't work please file a bug and see if you can
bisect it.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
On Sun, 6 Jun 2010 17:36:24 +0100 (BST)
James Simmons wrote:
>
> > On Fri, 9 Apr 2010 15:10:50 -0700
> > Jesse Barnes wrote:
> >
> > > This set of 3 patches makes it a little more likely we'll get panic
> > > output onto the screen even when X is
On Sun, 6 Jun 2010 17:36:24 +0100 (BST)
James Simmons wrote:
>
> > On Fri, 9 Apr 2010 15:10:50 -0700
> > Jesse Barnes wrote:
> >
> > > This set of 3 patches makes it a little more likely we'll get panic
> > > output onto the screen even when X is
i, 2010-05-21 at 15:02 -0700, Jesse Barnes wrote:
>> > On Sat, 22 May 2010 00:57:30 +0300
>> > Maxim Levitsky wrote:
>> >
>> > > On Fri, 2010-05-21 at 00:14 +0300, Maxim Levitsky wrote:
>> > > > On Thu, 2010-05-20 at 09:28 -0700, Jesse Barn
i, 2010-05-21 at 15:02 -0700, Jesse Barnes wrote:
>> > On Sat, 22 May 2010 00:57:30 +0300
>> > Maxim Levitsky wrote:
>> >
>> > > On Fri, 2010-05-21 at 00:14 +0300, Maxim Levitsky wrote:
>> > > > On Thu, 2010-05-20 at 09:28 -0700, Jesse Barn
On Sat, 22 May 2010 00:57:30 +0300
Maxim Levitsky wrote:
> On Fri, 2010-05-21 at 00:14 +0300, Maxim Levitsky wrote:
> > On Thu, 2010-05-20 at 09:28 -0700, Jesse Barnes wrote:
> > > On Thu, 20 May 2010 04:27:07 +0300
> > > Maxim Levitsky wrote:
> > >
>
On Sat, 22 May 2010 00:57:30 +0300
Maxim Levitsky wrote:
> On Fri, 2010-05-21 at 00:14 +0300, Maxim Levitsky wrote:
> > On Thu, 2010-05-20 at 09:28 -0700, Jesse Barnes wrote:
> > > On Thu, 20 May 2010 04:27:07 +0300
> > > Maxim Levitsky wrote:
> > >
>
On Thu, 20 May 2010 04:27:07 +0300
Maxim Levitsky wrote:
> On Thu, 2010-05-20 at 04:13 +0300, Maxim Levitsky wrote:
> > On Wed, 2010-05-19 at 17:34 -0700, Jesse Barnes wrote:
> > > On Fri, 9 Apr 2010 15:10:50 -0700
> > > Jesse Barnes wrote:
> > >
>
On Thu, 20 May 2010 04:27:07 +0300
Maxim Levitsky wrote:
> On Thu, 2010-05-20 at 04:13 +0300, Maxim Levitsky wrote:
> > On Wed, 2010-05-19 at 17:34 -0700, Jesse Barnes wrote:
> > > On Fri, 9 Apr 2010 15:10:50 -0700
> > > Jesse Barnes wrote:
> > >
>
On Fri, 9 Apr 2010 15:10:50 -0700
Jesse Barnes wrote:
> This set of 3 patches makes it a little more likely we'll get panic
> output onto the screen even when X is running, assuming a KMS enabled
> stack anyway.
>
> It gets me from a blank or very sparsely populated black sc
On Fri, 9 Apr 2010 15:10:50 -0700
Jesse Barnes wrote:
> This set of 3 patches makes it a little more likely we'll get panic
> output onto the screen even when X is running, assuming a KMS enabled
> stack anyway.
>
> It gets me from a blank or very sparsely populated black sc
s also
more complex, so it just depends on your needs. Check out i915_gem.c
for details on how the driver specific portion of GEM should work
(basically cache domain management, buffer tracking, and execution
buffer management).
--
Jesse Barnes, Intel Open Source Technology Center
---
On Fri, 9 Apr 2010 15:10:50 -0700
Jesse Barnes wrote:
> This set of 3 patches makes it a little more likely we'll get panic
> output onto the screen even when X is running, assuming a KMS enabled
> stack anyway.
>
> It gets me from a blank or very sparsely populated black sc
On Fri, 9 Apr 2010 15:10:50 -0700
Jesse Barnes wrote:
> This set of 3 patches makes it a little more likely we'll get panic
> output onto the screen even when X is running, assuming a KMS enabled
> stack anyway.
>
> It gets me from a blank or very sparsely populated black sc
On Mon, 12 Apr 2010 10:05:00 +1000
Dave Airlie wrote:
> On Sat, Apr 10, 2010 at 8:11 AM, Jesse Barnes
> wrote:
> > Needed for panic and kdb, since we need to avoid taking the mode_config
> > mutex.
>
> One comment below.
Updated patch below.
--
Jesse Barnes, Inte
On Mon, 12 Apr 2010 10:05:00 +1000
Dave Airlie wrote:
> On Sat, Apr 10, 2010 at 8:11 AM, Jesse Barnes
> wrote:
> > Needed for panic and kdb, since we need to avoid taking the mode_config
> > mutex.
>
> One comment below.
Updated patch below.
--
Jesse Barnes, Inte
On Mon, 12 Apr 2010 10:05:00 +1000
Dave Airlie wrote:
> On Sat, Apr 10, 2010 at 8:11 AM, Jesse Barnes
> wrote:
> > Needed for panic and kdb, since we need to avoid taking the mode_config
> > mutex.
>
> One comment below.
>
> >
> > Signed-off-by: Jes
On Mon, 12 Apr 2010 10:05:00 +1000
Dave Airlie wrote:
> On Sat, Apr 10, 2010 at 8:11 AM, Jesse Barnes
> wrote:
> > Needed for panic and kdb, since we need to avoid taking the mode_config
> > mutex.
>
> One comment below.
>
> >
> > Signed-off-by: Jes
At panic time (i.e. when oops_in_progress is set) we should try a bit
harder to update the screen and make sure output gets to the VT, since
some drivers are capable of flipping back to it.
So make sure we try to unblank and update the display if called from a
panic context.
Signed-off-by: Jesse
This allows us to draw to the fbcon buffer in a panic situation, in case
the low level driver can flip to it at panic time.
Signed-off-by: Jesse Barnes
---
drivers/video/console/fbcon.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/console/fbcon.c b
This allows us to draw to the fbcon buffer in a panic situation, in case
the low level driver can flip to it at panic time.
Signed-off-by: Jesse Barnes
---
drivers/video/console/fbcon.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/console/fbcon.c b
At panic time (i.e. when oops_in_progress is set) we should try a bit
harder to update the screen and make sure output gets to the VT, since
some drivers are capable of flipping back to it.
So make sure we try to unblank and update the display if called from a
panic context.
Signed-off-by: Jesse
801 - 900 of 905 matches
Mail list logo
