On Fri, 15 Apr 2011 15:36:22 -0400
Adam Jackson wrote:
> On 4/15/11 3:19 PM, Jesse Barnes wrote:
>
> > Or is there a CEA block extension that allows for more granularity?
>
> CEA has bits for the two YCbCr formats too, which we should also parse
> since there's plent
On Fri, 15 Apr 2011 12:19:31 -0700
Jesse Barnes wrote:
> On Fri, 15 Apr 2011 15:13:02 -0400
> Adam Jackson wrote:
> > info->color_formats = DRM_COLOR_FORMAT_RGB444;
> > if (edid->features & DRM_EDID_FEATURE_YCRCB444)
> > info->color
On Fri, 15 Apr 2011 12:19:31 -0700
Jesse Barnes wrote:
> On Fri, 15 Apr 2011 15:13:02 -0400
> Adam Jackson wrote:
> > info->color_formats = DRM_COLOR_FORMAT_RGB444;
> > if (edid->features & DRM_EDID_FEATURE_YCRCB444)
> > info->color
On Fri, 15 Apr 2011 14:29:50 -0400
Adam Jackson wrote:
> On 4/15/11 2:22 PM, Jesse Barnes wrote:
> > EDID 1.4 digital monitors report the bit depth supported in the input
> > field. Add support for parsing this out and storing the info in the
> > display_info structu
On Fri, 15 Apr 2011 15:13:02 -0400
Adam Jackson wrote:
> On 4/15/11 2:40 PM, Jesse Barnes wrote:
>
> > @@ -1461,6 +1462,15 @@ static void drm_add_display_info(struct edid *edid,
> > info->bpp = 0;
> > break;
> > }
On Fri, 15 Apr 2011 14:29:50 -0400
Adam Jackson wrote:
> On 4/15/11 2:22 PM, Jesse Barnes wrote:
> > EDID 1.4 digital monitors report the bit depth supported in the input
> > field. Add support for parsing this out and storing the info in the
> > display_info structu
On Fri, 15 Apr 2011 15:13:02 -0400
Adam Jackson wrote:
> On 4/15/11 2:40 PM, Jesse Barnes wrote:
>
> > @@ -1461,6 +1462,15 @@ static void drm_add_display_info(struct edid *edid,
> > info->bpp = 0;
> > break;
> > }
EDID 1.4 digital displays report the color spaces they support in the
features block. Add support for grabbing this data and stuffing it into
the display_info struct for driver use.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_edid.c | 10 ++
include/drm/drm_crtc.h |6
EDID 1.4 digital displays report the color spaces they support in the
features block. Add support for grabbing this data and stuffing it into
the display_info struct for driver use.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_edid.c | 10 ++
include/drm/drm_crtc.h |6
EDID 1.4 digital monitors report the bit depth supported in the input
field. Add support for parsing this out and storing the info in the
display_info structure for use by drivers.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_edid.c | 54
EDID 1.4 digital monitors report the bit depth supported in the input
field. Add support for parsing this out and storing the info in the
display_info structure for use by drivers.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_edid.c | 54
On Fri, 15 Apr 2011 09:23:38 -0500
Chris Bandy wrote:
> On 04/14/2011 12:42 PM, Jesse Barnes wrote:
> > /**
> > + * drm_sysfs_change_event - generate a DRM uevent indicating a display
> > config change
> > + * @dev: DRM device
> > + *
> > + * Send a ueve
On Fri, 15 Apr 2011 09:23:38 -0500
Chris Bandy wrote:
> On 04/14/2011 12:42 PM, Jesse Barnes wrote:
> > /**
> > + * drm_sysfs_change_event - generate a DRM uevent indicating a display
> > config change
> > + * @dev: DRM device
> > + *
> > + * Send a ueve
We've already seen that apps want to monitor the display config, and
some (like upowerd) poll for changes since we don't provide a
notification for general mode config changes, just hotplug events. So
add a new drm event, with CHANGE=1 set in the event, to allow for it.
Signed-off
We've already seen that apps want to monitor the display config, and
some (like upowerd) poll for changes since we don't provide a
notification for general mode config changes, just hotplug events. So
add a new drm event, with CHANGE=1 set in the event, to allow for it.
Signed-off
On Sat, 2 Apr 2011 09:24:10 +0900
Norbert Preining wrote:
> > Hm, ok so on resume we're checking GPU busyness, which is normal,
> > but end up hanging on the spinlock? Do you see what scrolls by
> > above the text you took a picture of (probably a "task hung"
> > message?).
>
> More than what I
On Sat, 2 Apr 2011 09:24:10 +0900
Norbert Preining wrote:
> > Hm, ok so on resume we're checking GPU busyness, which is normal,
> > but end up hanging on the spinlock? Do you see what scrolls by
> > above the text you took a picture of (probably a "task hung"
> > message?).
>
> More than what I
(probably a "task hung" message?).
Does this happen reliably? Does a previous kernel work ok?
--
Jesse Barnes, Intel Open Source Technology Center
--
Create and publish websites with WebMatrix
Use the most popular FR
(probably a "task hung" message?).
Does this happen reliably? Does a previous kernel work ok?
--
Jesse Barnes, Intel Open Source Technology Center
--
Create and publish websites with WebMatrix
Use the most popular FR
ditionals to our FDI
training code to support newer chips, I've split it into separate
functions entirely, leaving the old one alone. If, after awhile we've
decided that they really are mostly the same and we have things working
well, we can consider merging them again, but only a
ditionals to our FDI
training code to support newer chips, I've split it into separate
functions entirely, leaving the old one alone. If, after awhile we've
decided that they really are mostly the same and we have things working
well, we can consider merging them again, but only a
ink we've been doing well with this on the Intel
side at least; we add feature flags every time we change something, and
make sure userspace is forward and backward compatible). This is more
work for us, but I think it benefits the user in the end. And it could
be worse, at least we're
ink we've been doing well with this on the Intel
side at least; we add feature flags every time we change something, and
make sure userspace is forward and backward compatible). This is more
work for us, but I think it benefits the user in the end. And it could
be worse, at least we're
s regarding this
issue though, but it does seem a likely candidate.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
s regarding this
issue though, but it does seem a likely candidate.
--
Jesse Barnes, Intel Open Source Technology Center
; Why can't the gpu be reset/restarted when this happens? When a nic card
> gets hung it is reinitialized
> and restarted why not the gpu?
Yeah, we try to restart in this case, but often just end up back in the
same situation when the app runs again. We could be meane
; Why can't the gpu be reset/restarted when this happens? When a nic card
> gets hung it is reinitialized
> and restarted why not the gpu?
Yeah, we try to restart in this case, but often just end up back in the
same situation when the app runs again. We could be meaner about
things and SIGILL the app, but often it's an innocent bystander, and
the real problem is kernel object synchronization and/or the DRI driver
generating bad commands.
--
Jesse Barnes, Intel Open Source Technology Center
ery much custom to DRM.
If that's the only issue you have, we could easily rename that
structure or add conversion funcs to a smaller structure if that's what
you need.
Dave's point is that we can't ditch the existing code without
introducing a lot of risk; it would be better to start a library-ized
EDID codebase from the most complete one we have already, i.e. the DRM
EDID code.
Do you really think the differences between your code and the existing
DRM code are irreconcilable?
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
ery much custom to DRM.
If that's the only issue you have, we could easily rename that
structure or add conversion funcs to a smaller structure if that's what
you need.
Dave's point is that we can't ditch the existing code without
introducing a lot of risk; it would be better to start a library-ized
EDID codebase from the most complete one we have already, i.e. the DRM
EDID code.
Do you really think the differences between your code and the existing
DRM code are irreconcilable?
--
Jesse Barnes, Intel Open Source Technology Center
to VT switching suggest that the problems
> related to disabling part A may actually have been related to handover
> to the console driver before KMS.
Yes, definitely possible. We didn't have all the assertion checks we
have now, so we may have just been masking othe
to VT switching suggest that the problems
> related to disabling part A may actually have been related to handover
> to the console driver before KMS.
Yes, definitely possible. We didn't have all the assertion checks we
have now, so we may have just been masking other problems without
knowing it.
--
Jesse Barnes, Intel Open Source Technology Center
additional features it would provide (output
> > management, memory management, execution management)
>
> 3) its got documentation
Jeez, some people want it all.
You looking for docs for the ioctls and such?
--
Jesse Barnes, Intel Open Source Technology Center
additional features it would provide (output
> > management, memory management, execution management)
>
> 3) its got documentation
Jeez, some people want it all.
You looking for docs for the ioctls and such?
--
Jesse Barnes, Intel Open Source Technology Center
ich makes reallocation of the framebuffer
somewhat difficult.
IIRC plymouth or whatever Fedora is using these days uses the KMS APIs
though...
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@l
ich makes reallocation of the framebuffer
somewhat difficult.
IIRC plymouth or whatever Fedora is using these days uses the KMS APIs
though...
--
Jesse Barnes, Intel Open Source Technology Center
On Mon, 21 Mar 2011 20:50:20 +0100
Geert Uytterhoeven wrote:
> On Mon, Mar 21, 2011 at 20:25, Jesse Barnes wrote:
> > On Mon, 21 Mar 2011 19:19:43 +
> > timofonic timofonic wrote:
> >> So if KMS is so cool and provides many advantages over fbdev and
> >> s
On Mon, 21 Mar 2011 20:50:20 +0100
Geert Uytterhoeven wrote:
> On Mon, Mar 21, 2011 at 20:25, Jesse Barnes
> wrote:
> > On Mon, 21 Mar 2011 19:19:43 +
> > timofonic timofonic wrote:
> >> So if KMS is so cool and provides many advantages over fbdev and
> &g
On Mon, 21 Mar 2011 19:19:43 +
timofonic timofonic wrote:
> So if KMS is so cool and provides many advantages over fbdev and
> such... Why isn't more widely used intead of still relying on fbdev?
> Why still using fbdev emulation (that is partial and somewhat broken,
> it seems) instead using
On Mon, 21 Mar 2011 19:19:43 +
timofonic timofonic wrote:
> So if KMS is so cool and provides many advantages over fbdev and
> such... Why isn't more widely used intead of still relying on fbdev?
> Why still using fbdev emulation (that is partial and somewhat broken,
> it seems) instead using
not like we can't do
> "advanced" things like compositing using the CPU. Transparency may stretch
> it a bit on lower end CPUs, but you don't always need that.
There's nothing in DRM that precludes doing simple fbdev-like drivers
as well, though
not like we can't do
> "advanced" things like compositing using the CPU. Transparency may stretch
> it a bit on lower end CPUs, but you don't always need that.
There's nothing in DRM that precludes doing simple fbdev-like drivers
as well, though for many embedded uses I wouldn't expect it to provide
a whole lot of benefit.
--
Jesse Barnes, Intel Open Source Technology Center
On Fri, 18 Mar 2011 18:13:11 -0500 (CDT)
Ilija Hadzic wrote:
>
>
> On Fri, 18 Mar 2011, Jesse Barnes wrote:
>
> >
> > I like the new param check, but I'd still prefer a new ioctl to abusing
> > the old one.
> >
>
> It's not "
On Fri, 18 Mar 2011 18:13:11 -0500 (CDT)
Ilija Hadzic wrote:
>
>
> On Fri, 18 Mar 2011, Jesse Barnes wrote:
>
> >
> > I like the new param check, but I'd still prefer a new ioctl to abusing
> > the old one.
> >
>
> It's not "
param check, but I'd still prefer a new ioctl to abusing
the old one.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
ted code in each function is begging to get pulled out into
a separate 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
param check, but I'd still prefer a new ioctl to abusing
the old one.
--
Jesse Barnes, Intel Open Source Technology Center
ted code in each function is begging to get pulled out into
a separate function...
--
Jesse Barnes, Intel Open Source Technology Center
= connector->funcs->detect(connector, true);
> + mutex_unlock(&connector->dev->mode_config.mutex);
> +
How about adding a mutex assertion check in the detect hook as well? I
think we need a more generous sprinkling of those around the CRTC
helper code in general...
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
us = connector->funcs->detect(connector, true);
> + mutex_unlock(&connector->dev->mode_config.mutex);
> +
How about adding a mutex assertion check in the detect hook as well? I
think we need a more generous sprinkling of those around the CRTC
helper code in general...
--
Jesse Barnes, Intel Open Source Technology Center
On Fri, 11 Mar 2011 02:35:45 +0100 (CET)
"Indan Zupancic" wrote:
> drm/i915: Fix DPMS and suspend interaction for intel_panel.c
>
> When suspending intel_panel_disable_backlight() is never called,
> but intel_panel_enable_backlight() is called at resume. With the
> effect that if the brightness
On Fri, 11 Mar 2011 02:35:45 +0100 (CET)
"Indan Zupancic" wrote:
> drm/i915: Fix DPMS and suspend interaction for intel_panel.c
>
> When suspending intel_panel_disable_backlight() is never called,
> but intel_panel_enable_backlight() is called at resume. With the
> effect that if the brightness
On Thu, 3 Mar 2011 17:34:53 -0600 (CST)
Ilija Hadzic wrote:
> The fix/improvement I propose is to extend the request.type field
> in drmVBlank structure with additional 5 bits that I call high_crtc
> (there are lots of unused bits in that field). 5 bits covers for 32
> CRTCs, which seems to be th
On Thu, 3 Mar 2011 17:34:53 -0600 (CST)
Ilija Hadzic wrote:
> The fix/improvement I propose is to extend the request.type field
> in drmVBlank structure with additional 5 bits that I call high_crtc
> (there are lots of unused bits in that field). 5 bits covers for 32
> CRTCs, which seems to be th
> > Tested-by: Alex Riesen
>
> Guys, should I apply this, or will I get it through somebody's pull?
I'm worried that removing combo mode will break some working setups,
but if it's seen a lot of testing and is ok, then I'm fine with it, as
it definitely simplifies thing
> > Tested-by: Alex Riesen
>
> Guys, should I apply this, or will I get it through somebody's pull?
I'm worried that removing combo mode will break some working setups,
but if it's seen a lot of testing and is ok, then I'm fine with it, as
it definitely simplifies things.
--
Jesse Barnes, Intel Open Source Technology Center
On Wed, 16 Feb 2011 20:59:35 +0100
Alex Riesen wrote:
> On Wed, Feb 16, 2011 at 20:54, Jesse Barnes wrote:
> > On Wed, 16 Feb 2011 20:46:45 +0100
> > Alex Riesen wrote:
> >> > The backlight level on this Dell XPS M1330 reduces every time I reopen
> >> >
On Wed, 16 Feb 2011 20:59:35 +0100
Alex Riesen wrote:
> On Wed, Feb 16, 2011 at 20:54, Jesse Barnes
> wrote:
> > On Wed, 16 Feb 2011 20:46:45 +0100
> > Alex Riesen wrote:
> >> > The backlight level on this Dell XPS M1330 reduces every time I reopen
> >&g
t to the one set before closing the lid).
>
> It is this bug, I believe:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=25072
>
> I somehow missed it at first, and only noticed after sending the patch.
There's also this patch: https://patchwork.kernel.org/patch/499221/.
t to the one set before closing the lid).
>
> It is this bug, I believe:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=25072
>
> I somehow missed it at first, and only noticed after sending the patch.
There's also this patch: https://patchwork.kernel.org/patch/499221/.
On Fri, 11 Feb 2011 08:28:37 +0100
Francesco Allertsen wrote:
> On Thu, Feb 10, 2011 at 03:25:33PM -0800, Jesse Barnes wrote:
> > Does this kernel have the problem patch included? Or is it reverted?
>
> That was without the patch reverted, now I've reverted it and
On Fri, 11 Feb 2011 08:28:37 +0100
Francesco Allertsen wrote:
> On Thu, Feb 10, 2011 at 03:25:33PM -0800, Jesse Barnes wrote:
> > Does this kernel have the problem patch included? Or is it reverted?
>
> That was without the patch reverted, now I've reverted it and
On Fri, 11 Feb 2011 00:23:09 +0100
Francesco Allertsen wrote:
> On Thu, Feb 10, 2011 at 10:34:43AM -0800, Jesse Barnes wrote:
> > Since intel_reg_read won't work, can you try this patch instead? Just
> > patch it in, then cat /sys/kernel/debug/dri/0/i915_drpc_info
>
On Fri, 11 Feb 2011 00:23:09 +0100
Francesco Allertsen wrote:
> On Thu, Feb 10, 2011 at 10:34:43AM -0800, Jesse Barnes wrote:
> > Since intel_reg_read won't work, can you try this patch instead? Just
> > patch it in, then cat /sys/kernel/debug/dri/0/i915_drpc_info
>
>
> > That should work its way upstream shortly.
>
> I've tried to apply it on top of 2.6.38-rc4, and now it doesn't hang
> when I start X, but it hangs when I resume from suspend to RAM.
Since intel_reg_read won't work, can you try this patch instead? Just
patch
>
> > That should work its way upstream shortly.
>
> I've tried to apply it on top of 2.6.38-rc4, and now it doesn't hang
> when I start X, but it hangs when I resume from suspend to RAM.
Since intel_reg_read won't work, can you try this patch instead? Just
patch
On Wed, 9 Feb 2011 09:53:26 -0800
Jesse Barnes wrote:
> On Wed, 9 Feb 2011 09:50:47 -0800
> Jesse Barnes wrote:
>
> > On Wed, 09 Feb 2011 17:09:10 +
> > Chris Wilson wrote:
> >
> > > On Wed, 9 Feb 2011 13:52:38 +0100, Francesco Allertsen
> > &g
On Wed, 9 Feb 2011 09:53:26 -0800
Jesse Barnes wrote:
> On Wed, 9 Feb 2011 09:50:47 -0800
> Jesse Barnes wrote:
>
> > On Wed, 09 Feb 2011 17:09:10 +
> > Chris Wilson wrote:
> >
> > > On Wed, 9 Feb 2011 13:52:38 +0100, Francesco Allertsen > >
On Wed, 9 Feb 2011 09:50:47 -0800
Jesse Barnes wrote:
> On Wed, 09 Feb 2011 17:09:10 +
> Chris Wilson wrote:
>
> > On Wed, 9 Feb 2011 13:52:38 +0100, Francesco Allertsen
> > wrote:
> > > On Wed, Feb 02, 2011 at 09:59:54AM +, Chris Wilson wrote:
> >
On Wed, 9 Feb 2011 09:50:47 -0800
Jesse Barnes wrote:
> On Wed, 09 Feb 2011 17:09:10 +
> Chris Wilson wrote:
>
> > On Wed, 9 Feb 2011 13:52:38 +0100, Francesco Allertsen > gmail.com> wrote:
> > > On Wed, Feb 02, 2011 at 09:59:54AM +, Chris Wilson wrote:
erting the cleanup wasn't sufficient?
Francesco, if you revert the cleanup patch you bisected to, what
does /sys/kernel/debug/dri/0/i915_drpc_info report?
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
rtly.
reverting the cleanup wasn't sufficient?
Francesco, if you revert the cleanup patch you bisected to, what
does /sys/kernel/debug/dri/0/i915_drpc_info report?
--
Jesse Barnes, Intel Open Source Technology Center
On Tue, 01 Feb 2011 16:57:37 +
Chris Wilson wrote:
> On Tue, 1 Feb 2011 08:31:12 -0800, Jesse Barnes
> wrote:
> > The bisect is interesting, I'd have expected a failure when we
> > re-enabled rc6 on ILK or when we fixed up the ring buffer init.
>
> Yes,
On Tue, 01 Feb 2011 16:57:37 +
Chris Wilson wrote:
> On Tue, 1 Feb 2011 08:31:12 -0800, Jesse Barnes
> wrote:
> > The bisect is interesting, I'd have expected a failure when we
> > re-enabled rc6 on ILK or when we fixed up the ring buffer init.
>
> Yes,
hang?
>
> No, it doesn't have any effect.
Yeah I don't think we use that flag for rc6, though we probably should.
The bisect is interesting, I'd have expected a failure when we
re-enabled rc6 on ILK or when we fixed up the ring buffer init.
The cleanup patch should be just t
hang?
>
> No, it doesn't have any effect.
Yeah I don't think we use that flag for rc6, though we probably should.
The bisect is interesting, I'd have expected a failure when we
re-enabled rc6 on ILK or when we fixed up the ring buffer init.
The cleanup patch should be just t
On Wed, 12 Jan 2011 14:31:33 -0800
Linus Torvalds wrote:
> On Wed, Jan 12, 2011 at 2:22 PM, Jesse Barnes
> wrote:
> >
> > Ah, ok. So it could be our internal FDI link is underrunning; it goes
> > between the CPU and PCH and carries display bits.
>
> I'm no
On Wed, 12 Jan 2011 14:31:33 -0800
Linus Torvalds wrote:
> On Wed, Jan 12, 2011 at 2:22 PM, Jesse Barnes
> wrote:
> >
> > Ah, ok. ?So it could be our internal FDI link is underrunning; it goes
> > between the CPU and PCH and carries display bits.
>
> I'm no
On Wed, 12 Jan 2011 13:28:53 -0800
Linus Torvalds wrote:
> On Wed, Jan 12, 2011 at 12:27 PM, Linus Torvalds
> wrote:
> > On Wed, Jan 12, 2011 at 11:46 AM, Jesse Barnes
> > wrote:
> >>
> >> Since I doubt we're actually offloading to our video decode ker
On Wed, 12 Jan 2011 13:28:53 -0800
Linus Torvalds wrote:
> On Wed, Jan 12, 2011 at 12:27 PM, Linus Torvalds
> wrote:
> > On Wed, Jan 12, 2011 at 11:46 AM, Jesse Barnes > virtuousgeek.org> wrote:
> >>
> >> Since I doubt we're actually offloading to our
27;re actually offloading to our video decode kernels for
Flash video on your machine, it could very well be a memory bw issue.
Can you try this small patch to see if one of the low power watermarks
is giving you trouble (note: cut & pasted)?
It could also be the normal power watermarks though to
27;re actually offloading to our video decode kernels for
Flash video on your machine, it could very well be a memory bw issue.
Can you try this small patch to see if one of the low power watermarks
is giving you trouble (note: cut & pasted)?
It could also be the normal power watermarks though to
On Tue, 11 Jan 2011 11:25:39 -0800
Linus Torvalds wrote:
> On Tue, Jan 11, 2011 at 11:12 AM, Jesse Barnes
> wrote:
> >
> > Have you tried reproducing it using xset dpms force off or similar?
>
> That doesn't seem to do anything bad.
>
> In fact, I think the
On Tue, 11 Jan 2011 11:25:39 -0800
Linus Torvalds wrote:
> On Tue, Jan 11, 2011 at 11:12 AM, Jesse Barnes
> wrote:
> >
> > Have you tried reproducing it using xset dpms force off or similar?
>
> That doesn't seem to do anything bad.
>
> In fact, I think the
o trigger the watermark related issues
you've found?
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
o trigger the watermark related issues
you've found?
--
Jesse Barnes, Intel Open Source Technology Center
ersave=0 help any?
>
>Dave.
Arg. It's been ok on my ILK systems, but Chris has found some issues with out
watermarking code iirc; apparently we're underflowing the display FIFO, causing
all sorts of trouble. If it works before the pull of Dave's tree, can you
bisect?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
ersave=0 help any?
>
>Dave.
Arg. It's been ok on my ILK systems, but Chris has found some issues with out
watermarking code iirc; apparently we're underflowing the display FIFO, causing
all sorts of trouble. If it works before the pull of Dave's tree, can you
bisect?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
the server also fill these needs? It would be a
bigger API, but presumably would allow us to share fbs between early
boot and subsequent, accelerated usage. We'd still need to settle on
the basic allocation API, but we seem to manage that on the server
side...
the server also fill these needs? It would be a
bigger API, but presumably would allow us to share fbs between early
boot and subsequent, accelerated usage. We'd still need to settle on
the basic allocation API, but we seem to manage that on the server
side...
--
Jesse Barnes, Intel Open Source Technology Center
On Thu, 30 Dec 2010 10:49:33 +0800 (SGT)
Jeff Chua wrote:
>
> On Thu, Dec 30, 2010 at 4:16 AM, Jesse Barnes
> wrote:
>
> > Randy, Jeff and Alex, does the below help at all? If so, it may be the
> > minimal fix we want for 2.6.37.
>
> Jesse,
>
> Yes, t
On Thu, 30 Dec 2010 10:49:33 +0800 (SGT)
Jeff Chua wrote:
>
> On Thu, Dec 30, 2010 at 4:16 AM, Jesse Barnes
> wrote:
>
> > Randy, Jeff and Alex, does the below help at all? If so, it may be the
> > minimal fix we want for 2.6.37.
>
> Jesse,
>
> Yes, t
On Thu, 30 Dec 2010 00:35:15 +0100
Alex Riesen wrote:
> On Thu, Dec 30, 2010 at 00:20, Alex Riesen wrote:
> > On Thu, Dec 30, 2010 at 00:13, Jesse Barnes
> > wrote:
> >>> After closing and opening the lid (displays backlight is back)
> >>>
>
On Thu, 30 Dec 2010 00:35:15 +0100
Alex Riesen wrote:
> On Thu, Dec 30, 2010 at 00:20, Alex Riesen wrote:
> > On Thu, Dec 30, 2010 at 00:13, Jesse Barnes
> > wrote:
> >>> After closing and opening the lid (displays backlight is back)
> >>>
>
On Thu, 30 Dec 2010 00:09:56 +0100
Alex Riesen wrote:
> On Wed, Dec 29, 2010 at 22:53, Jesse Barnes wrote:
> >> > Doesn't change anything here. Display stays blank.
> >>
> >> Sounds like your problem is separate from SSC then, more likely related
> >
On Thu, 30 Dec 2010 00:09:56 +0100
Alex Riesen wrote:
> On Wed, Dec 29, 2010 at 22:53, Jesse Barnes
> wrote:
> >> > Doesn't change anything here. Display stays blank.
> >>
> >> Sounds like your problem is separate from SSC then, more likely related
if (IS_I85X(dev))
> >
> >
> > --
>
> Ugh, looks like I have confused things horribly. Sorry about this.
>
> 2.6.37-rc8 with no patches works for me. My original report was incorrect --
> I was using -rc7 when I thought I was using -rc8. :(
if (IS_I85X(dev))
> >
> >
> > --
>
> Ugh, looks like I have confused things horribly. Sorry about this.
>
> 2.6.37-rc8 with no patches works for me. My original report was incorrect --
> I was using -rc7 when I thought I was using -rc8. :(
Can you confirm that the above doesn't break your setup just in case we
need to apply it?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
e bug, looks like it is panel power
related. Can you try this patch?
If it doesn't work, can you send me the output of intel_reg_dumper from
before you turn off the display and after you try to turn it back on?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drive
e bug, looks like it is panel power
related. Can you try this patch?
If it doesn't work, can you send me the output of intel_reg_dumper from
before you turn off the display and after you try to turn it back on?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drive
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 pl
701 - 800 of 905 matches
Mail list logo
